API 670 is not, strictly speaking, a monitoring standard. It is a machinery protection standard — and that distinction matters more than most reliability engineers give it credit for. The Fifth Edition, published in 2014, defines the minimum requirements for instrumentation and protective systems on centrifugal compressors, steam turbines, expanders, and pumps. Understanding what it actually mandates — versus what vendors claim it mandates — is the starting point for any serious condition monitoring deployment in midstream service.
What API 670 Actually Covers
The standard specifies the design, installation, and testing requirements for machinery protection systems (MPS), with three core instrumentation categories: radial shaft vibration (via eddy-current proximity probes), axial position (thrust position), and casing (housing) vibration via accelerometers. It also covers speed sensing, phase reference keyphasor signals, temperature monitoring on bearings and seals, and the trip/alarm logic architecture for the monitor rack itself.
On proximity probe specifications, API 670 requires the use of API 670-qualified transducer systems — typically eddy-current systems such as Bently Nevada 3300 or equivalent — and mandates that radial proximity probe pairs be installed at 90° ± 5°, oriented at 45° to the vertical axis (the X-Y convention). Gap voltage on standard 5 mm probes should fall in the range of −10 to −18 VDC at calibrated nominal gap. The standard specifies dynamic range, sensitivity (200 mV/mil nominal), and cable length limitations that affect signal integrity for long runs in field installations.
The monitor rack specifications define analog signal processing, alert/alarm/danger setpoints, and relay output requirements. Critically, API 670 specifies that danger shutdown signals must have OK status confirmation — the system cannot trip on a failed sensor, only on a valid high-vibration signal. This has direct implications for how false-positive suppression logic must be designed in any downstream software layer.
What API 670 Does Not Cover
This is where the standard is frequently misread. API 670 establishes minimum protection — it defines when a machine must be automatically tripped to prevent immediate mechanical failure. It says nothing meaningful about early-warning trending, nothing about frequency-domain analysis, and nothing about integrating historian data into anomaly detection workflows. A facility can be fully API 670 compliant with a Bently Nevada System 1 rack providing raw proximity probe data, while having no capability whatsoever to detect a developing bearing defect at the BPFI (ball pass frequency of the inner race) three weeks before failure.
We are not saying API 670 is inadequate — it is doing exactly what it was designed to do, which is prevent catastrophic mechanical events. We are saying that API 670 compliance and condition monitoring capability are two different things that should not be conflated in a capital project or a reliability program.
Radial Vibration: Alert Levels and the Relationship to ISO 20816
API 670 does not prescribe numeric alert setpoints in absolute terms. Instead, it references the equipment OEM's maximum allowable vibration levels and the concept of alert/danger bands scaled to those levels. Typical practice in midstream gas compression applies API 670's guidance alongside ISO 10816 (now ISO 20816) for casing-mounted accelerometer readings, where velocity is expressed in mm/s RMS. For proximity-probe-based radial shaft vibration, displacement in mils peak-to-peak is the relevant unit.
A common industry starting point for centrifugal compressor radial shaft vibration is an alert at 1.0× the manufacturer's maximum continuous speed vibration limit and a danger (trip) at 1.25×. For a 10,000 RPM centrifugal compressor with an OEM-specified limit of 1.0 mil p-p, that works out to a danger setpoint at 1.25 mils p-p. In practice, high-performance compressors on clean natural gas service often run well below 0.5 mils p-p under normal conditions, which is why a 1.0 mil alert provides substantial lead time before a mechanical event — unless the onset of failure is rapid, which in the case of surge-induced rub events, it often is.
Casing Accelerometers: The Sensor Type API 670 Allows but Doesn't Require for All Equipment
API 670's scope for casing-mounted accelerometers specifically addresses equipment where shaft-riding proximity probes are not practical — smaller equipment, rolling element bearing machines, and certain centrifugal pumps. This matters for midstream pipeline pump stations, where a multi-stage centrifugal pump on API 610 specification may have rolling element bearings rather than journal bearings, making proximity probes inappropriate. In those cases, the relevant vibration measurement is acceleration in g RMS or velocity converted from the accelerometer signal, measured on the bearing housing.
For a real-world deployment at a gas gathering system's field compression station in the Permian Basin area, an operator might have five Caterpillar G3612 gas engine-driven reciprocating compressors protected per API 670 plus six inlet separation scrubber pump sets on accelerometers only. The vibration data from both populations can be aggregated into an AVEVA PI historian using OPC-DA connections from the Bently Nevada System 1 monitor racks, but the data density and frequency content differ significantly. The reciprocating compressors produce periodic impulse signatures driven by piston rod loading frequency; the centrifugal pumps produce broadband noise with superimposed bearing defect frequencies.
Integrating API 670 Data Streams into Condition Monitoring Workflows
Modern historian-based condition monitoring layers on top of API 670 protection systems without replacing them. The workflow is: the MPS rack handles real-time protection (analog trip logic, sub-100ms response); the historian captures the same signals at a configurable scan rate (typically 1-second to 1-minute tags in PI System); the ML layer processes historian-stored data over multi-day windows to produce trend features — RMS trend, spectral energy in defined frequency bands, Weibull-based failure probability curves.
The important OT/IT architecture point is that well-designed historian integrations read only from the historian — they never write back to the protection system and have no path to influence the MPS rack logic. This read-only access model is essential for maintaining the integrity of the API 670 protection layer and satisfies the network segmentation requirements that OSHA 1910.119 Process Safety Management programs typically impose on safety-instrumented system boundaries.
When configuring PI tags for condition monitoring (as opposed to process control), it is worth tagging bearing temperatures, lube oil header pressure, seal gas differential pressure, and process suction/discharge pressures alongside vibration channels. These process variables become essential covariates in anomaly detection models — a vibration increase that correlates with a rising bearing temperature and a falling lube oil header pressure has a very different diagnostic meaning than a vibration increase with stable process conditions.
Where Modern Monitoring Goes Beyond the Standard
API 670 defines trip and alert logic in terms of threshold crossing. Contemporary condition monitoring tools operate in the spectral and statistical domain. Bently Nevada System 1 software and Emerson AMS Machinery Manager both provide frequency-domain analysis natively; they can display FFT spectra computed from high-speed waveform data captured through the monitor rack's dynamic data interface. SKF @ptitude and similar platforms extend this to bearing defect frequency tracking — specifically BPFI (ball pass frequency inner race), BPFO (ball pass frequency outer race), FTF (fundamental train frequency), and BSF (ball spin frequency) — which are geometric functions of bearing dimensions and shaft speed.
The practical gap is that these envelope demodulation and spectral analysis capabilities require high-frequency data sampling (typically 10–40 kHz for acceleration signals, far above what an SCADA historian stores), and they require configuration effort to set up bearing defect frequency markers for each specific bearing part number in each machine. API 670 compliance does not ensure that any of this diagnostic infrastructure is in place. In a typical midstream operator's fleet, a significant fraction of equipment may be protected but not monitored — the protection system will prevent a catastrophic failure, but will not provide advance warning sufficient to enable condition-based maintenance planning.
Bridging that gap — building the data infrastructure and analytical layer on top of existing API 670 protection systems — is what rotating equipment condition monitoring programs are designed to accomplish. The standard provides the floor; the monitoring program provides the margin above it.
Interested in connecting your existing SCADA historian and API 670 protection data to a condition monitoring layer? Talk to our engineering team.
