ISO 20816 Vibration Severity Explained: Setting Alarm Thresholds for Wireless Condition-Monitoring Sensors
4.5 mm/s RMS. On a 55 kW pump motor, that number marks the edge between "run it for years" and "start planning the outage." On a 450 kW fan, the same reading sits near the top of the acceptable range. The number is the same, the machines are different, and a monitoring system that applies one threshold to both will either miss the pump or nuisance-alarm on the fan.
Most vibration-monitoring projects that stumble do so at this step. The hardware works, the radio links hold, the dashboard looks good, and then the alarm thresholds are set by whatever number someone remembers, or by the sensor datasheet's measurement range, or by a default shipped with the gateway. The first month produces either silence while a bearing degrades or a flood of alerts that teaches operators to ignore the system.
Here is the rule this post is built around: set vibration alarms in three layers. The first layer is an absolute limit from the machine's class under ISO 20816, which says what is acceptable for that kind of machine. The second is a baseline-relative limit, which says what is unusual for this particular machine. The third is a trend limit, which says how fast things are changing. Each layer catches failures the others miss, and a wireless sensor that reports an overall velocity value every few minutes has enough information to run all three.
An absolute limit tells you the machine is in trouble. A baseline limit tells you it is different. A trend limit tells you it is getting worse. You want to hear about the third one first.
What the Standard Measures
ISO 20816 is the current family of standards for evaluating the mechanical vibration of machines from measurements on non-rotating parts. It replaced the older ISO 10816 series part by part, and where the two overlap the zone boundaries are the same: a reading classified in a given zone under ISO 10816-3 is classified in the same zone under ISO 20816-3. Maintenance documents and acceptance reports that cite the older number are still describing the same limits.
For general industrial machinery, the measured quantity is broadband RMS vibration velocity in millimetres per second, taken on bearing housings or other accessible non-rotating structure, over a frequency band of roughly 10 Hz to 1,000 Hz. Velocity is used, rather than acceleration or displacement, because it correlates well with the vibration energy that damages machines across the 10 to 1,000 Hz range typical of rotating equipment.
The standard divides machines into groups by power and shaft height. For the industrial machines covered in part 3 (rated above 15 kW, running between 120 and 30,000 rpm):
Group 1: large machines, rated above 300 kW up to 50 MW, and electrical machines with shaft height of 315 mm and above.
Group 2: medium machines, rated 15 kW to 300 kW, and electrical machines with shaft height from 160 mm up to (not including) 315 mm.
It also distinguishes rigid and flexible supports. A machine's support is rigid or flexible according to the relationship between the machine's lowest natural frequency in the measurement direction and its operating speed: a flexible support has a natural frequency that is lower than the machine's operating speed range in a significant way. Rigid foundations allow lower vibration limits than flexible ones for the same zone.
Four evaluation zones classify a reading:
Zone | Meaning |
A | Typical of newly commissioned machines |
B | Acceptable for unrestricted long-term operation |
C | Normally considered unsatisfactory for long-term continuous operation; the machine can usually run for a limited period until a remedy is arranged |
D | Vibration severe enough to cause damage |
The zone boundaries for the two groups, in mm/s RMS, are:
Group and support | A / B | B / C | C / D |
Group 1 (above 300 kW), rigid | 2.3 | 4.5 | 7.1 |
Group 1, flexible | 3.5 | 7.1 | 11.0 |
Group 2 (15 to 300 kW), rigid | 1.4 | 2.8 | 4.5 |
Group 2, flexible | 2.3 | 4.5 | 7.1 |
These values are widely published and consistent across sources for the rigid cases. Always confirm them against the edition of the standard you are working to, particularly for flexible supports, before putting a number into a customer's alarm configuration.
So the 55 kW pump motor is a Group 2 machine on a rigid base, and 4.5 mm/s is its Zone C and D boundary. The 450 kW fan is Group 1 on a rigid base, and 4.5 mm/s is its Zone B and C boundary. Same number, two machines, two meanings.
What Alarm and Trip Mean in the Standard
Beyond the zones, the standard's general guidance (ISO 20816-1) describes two operational limits. As commonly summarised, an ALARM is set relative to a baseline measured on the machine when it is healthy: a value above that baseline by an amount equal to about 25 percent of the upper limit of zone B. A TRIP (a limit at which action to stop the machine is considered) is generally set within zone C or D and not above about 1.25 times the upper limit of zone C. The text also expects alarm values to be reviewed when the machine's baseline legitimately changes after maintenance.
Take those as the shape of the guidance and check the exact wording in the standard before quoting it in a specification. The point for a monitoring designer is structural: the standard itself recommends a baseline-relative alarm in addition to the absolute zones, which is the second of the three layers above.
ISO zones are the backstop, not the early-warning system. Bearing defects appear long before overall velocity moves.
What the Standard Does Not Cover
A wireless sensor reporting one overall velocity number cannot see everything, and ISO 20816 zones are not a diagnostic tool. Four limits matter in practice:
Early bearing defects. A rolling-element bearing with an early spall produces small high-frequency impacts that barely move the 10 to 1,000 Hz overall velocity. By the time overall velocity rises, the defect is advanced. Early bearing detection uses acceleration, envelope analysis, or high-frequency band measures, not the zone limits.
Gearboxes. Gear mesh frequencies are often well above the band the zone limits address, and the severity zones do not cover them.
Very slow machines. Below about 120 rpm the standard's frequency assumptions break down.
Reciprocating machinery and special cases. Reciprocating compressors, engines, and similar machines are covered by other standards or practice.
The practical consequence: treat the ISO zones as the backstop that says the machine is in trouble, and use baseline and trend layers, plus acceleration or envelope features where your sensor provides them, to catch problems earlier.
Getting a Correct Overall Velocity Number
A wireless node built on a MEMS accelerometer measures acceleration. Turning it into the quantity the standard uses means integrating once to velocity and restricting the band to 10 to 1,000 Hz. Done naively in the time domain, integration accumulates drift. Done in the frequency domain, it is simple and stable.
# overall_velocity_rms.py -- ISO-style band-limited RMS velocity from accelerometer data
import numpy as np
def velocity_rms_mm_s(acc_g, fs, f_lo=10.0, f_hi=1000.0):
"""Band-limited RMS velocity (mm/s) from one axis of acceleration in g.
Integration is done in the frequency domain: v(f) = a(f) / (2*pi*f)."""
a = np.asarray(acc_g, dtype=np.float64)
a = a - a.mean() # remove DC / gravity offset
n = len(a)
A = np.fft.rfft(a)
f = np.fft.rfftfreq(n, 1.0 / fs)
band = (f >= f_lo) & (f <= f_hi)
V = np.zeros_like(A)
V[band] = A[band] * 9.80665 * 1000.0 / (2j * np.pi * f[band]) # g -> mm/s per Hz-bin
v = np.fft.irfft(V, n) # band-limited velocity, mm/s
return float(np.sqrt(np.mean(v ** 2)))
# Sanity test: 50 Hz sine, 0.1 g peak. Expected RMS velocity =
# (0.1 * 9.80665 * 1000) / (2*pi*50) / sqrt(2) = about 2.207 mm/s
fs = 8000.0
t = np.arange(0, 2.0, 1.0 / fs)
sig = 0.1 * np.sin(2 * np.pi * 50.0 * t)
print(velocity_rms_mm_s(sig, fs))
The sanity test at the bottom of the listing is the habit to copy: feed the function a pure sine of known acceleration amplitude and frequency and confirm that the result equals the analytical value (for a sine of peak acceleration A at frequency f, the RMS velocity is A divided by 2 pi f, divided again by the square root of 2). For 0.1 g peak at 50 Hz that is about 2.21 mm/s, and the code above returns it to within a fraction of a percent. If your own implementation is off by more than a few percent on that test, fix it before any threshold is set. Three details cause most errors:
Sample rate and anti-aliasing. To cover 1,000 Hz you need a sample rate of at least a few kilohertz with an analogue or digital anti-aliasing filter. Some low-power sensors sample slower and only see part of the band.
Sensor bandwidth. Many low-cost MEMS accelerometers have an effective bandwidth and noise floor that limit accuracy at both ends of the 10 to 1,000 Hz band. Read the datasheet's noise density and bandwidth and compare the noise-equivalent velocity to your Zone A/B boundary.
Low-frequency noise. Integration amplifies low-frequency noise. A noisy sensor produces an overall velocity floor that can sit above a small machine's Zone A limit, which makes small machines look worse than they are.
Many industrial vibration transmitters compute the overall value inside the sensor and expose it over a fieldbus, which sidesteps the maths and moves the question to the vendor: ask whether the overall value is band-limited to 10 to 1,000 Hz RMS velocity, and over what averaging window.
Reading an RS-485 Vibration Transmitter
Industrial vibration transmitters commonly speak Modbus RTU over RS-485. A typical read of the overall velocity register looks like this. The register addresses are placeholders; use the register map in your sensor's documentation.
// Modbus RTU: read 3 holding registers starting at 0x0000 from slave 0x01
// Frame: [addr][func][start_hi][start_lo][qty_hi][qty_lo][crc_lo][crc_hi]
uint8_t req[8] = { 0x01, 0x03, 0x00, 0x00, 0x00, 0x03, 0, 0 };
uint16_t modbus_crc16(const uint8_t *buf, size_t len) {
uint16_t crc = 0xFFFF;
for (size_t i = 0; i < len; i++) {
crc ^= buf[i];
for (int b = 0; b < 8; b++)
crc = (crc & 1) ? (crc >> 1) ^ 0xA001 : (crc >> 1);
}
return crc;
}
void build_request(void) {
uint16_t crc = modbus_crc16(req, 6);
req[6] = crc & 0xFF; // CRC low byte first on the wire
req[7] = crc >> 8;
}
// Response (example layout; confirm against your sensor's register map):
// [addr][func][byte_count][v_rms_hi][v_rms_lo][temp_hi][temp_lo][accel_pk_hi][accel_pk_lo][crc_lo][crc_hi]
// v_rms scaled e.g. 0.01 mm/s per count; temp scaled 0.1 degC per count.
Two practical habits keep a Modbus link trustworthy. Validate the CRC of every response and count failures as a health metric. And space polls at a rate the sensor's documentation supports, since many transmitters need a minimum gap between requests, which echoes the lesson of any undocumented serial device: measure the timing, do not assume it.
Sensor Placement Decides Whether the Number Means Anything
Alarm thresholds are only as good as the measurement behind them. A velocity reading taken at the wrong place or with a poor mount can be several times the true bearing-housing value, or half of it.
Measure at the bearing housing, not on a thin cover, guard, or fan shroud. Thin sheet metal resonates, and the reading reflects the panel, not the machine.
Measure radially in two directions (horizontal and vertical) at each bearing where the machine permits, and axially where axial loads matter. A single sensor on a motor drive-end bearing, mounted horizontally, is the minimum for a first deployment.
Mount rigidly. A stud mount gives the best high-frequency response. Epoxy or a purpose-made adhesive pad is good. A magnet is convenient for surveys and unreliable for permanent installation, because its mounted resonance lowers the usable frequency range.
Protect the cable and connector from vibration fatigue and from induced noise. Keep sensor cables away from motor power cables, and use shielded twisted pair with the shield terminated at one end.
Record the position. Take a photo and write the location in the asset register, so a replacement sensor goes in the same place and the baseline remains valid.
A change in sensor position is a change in baseline. After replacing or moving a sensor, treat the first weeks as a new commissioning, not a continuation of the old trend.
Running State, Load, and Speed: The Conditions That Fool Thresholds
A vibration level means nothing without the machine's operating condition. A pump at half load, a motor on a variable-frequency drive at 70 percent speed, and a fan with a partly closed damper produce different baselines. Three controls keep the layers honest:
Gate alarms on running state. Evaluate thresholds only when the machine is running. A sensor that cannot tell whether the machine is on will alarm on start-up transients and on idle noise. If no run signal is available, infer it from the vibration itself (overall velocity above a small "running" threshold sustained for some seconds) or from motor current.
Record the operating context with each reading. Speed, load, or at least a run flag. Baselines are then built per operating condition, not averaged across them.
Use persistence and hysteresis. Require several consecutive readings over a limit before raising an alarm, and require the reading to fall comfortably below the limit before clearing it.
A compact state machine implements the three layers with persistence and hysteresis:
// Three-layer vibration alarm with persistence and hysteresis (runs on gateway or node)
typedef enum { OK, WARN, ALARM, TRIP } vib_state_t;
typedef struct {
float baseline; // mm/s, learned at commissioning for this operating state
float zone_bc; // ISO B/C boundary for this machine
float zone_cd; // ISO C/D boundary for this machine
float alarm_abs; // baseline + 0.25 * zone_bc (ISO-style baseline alarm)
float trend_limit; // mm/s per day considered abnormal
uint8_t persist_n; // consecutive samples required
float hyst; // fraction below limit required to clear (e.g. 0.9)
uint8_t count; // internal
vib_state_t state;
} vib_cfg_t;
vib_state_t vib_update(vib_cfg_t *c, float v_now, float slope_mm_s_per_day, bool running)
{
if (!running) { c->count = 0; return c->state; } // gate: no alarms when stopped
bool over_trip = v_now >= c->zone_cd;
bool over_alarm = v_now >= c->alarm_abs;
bool over_trend = slope_mm_s_per_day >= c->trend_limit;
if (over_trip) { c->state = TRIP; }
else if (over_alarm) { if (++c->count >= c->persist_n) c->state = ALARM; }
else if (over_trend) { if (++c->count >= c->persist_n && c->state < WARN) c->state = WARN; }
else if (v_now < c->hyst * c->alarm_abs) { c->count = 0; c->state = OK; } // hysteresis
return c->state;
}
Trend estimation can be as simple as a least-squares slope over the last 7 to 14 days of daily medians, taken in a fixed operating state. The daily median is robust against transients, which is why it beats the mean.
The Pump That Drifted
A representative composite, genericised: a process plant monitors a fleet of 75 kW centrifugal pump motors, each fitted with a wireless vibration node that reports overall RMS velocity and temperature every five minutes over a low-power wide-area link. The motors are Group 2 machines on rigid bases.
Commissioning captured a two-week baseline per pump, in the normal operating state. For one pump the median overall velocity settled at 1.1 mm/s, comfortably in zone B. The thresholds followed from the standard and the baseline:
Layer | Value for this pump | Basis |
Zone A/B | 1.4 mm/s | ISO 20816-3, Group 2, rigid |
Zone B/C | 2.8 mm/s | ISO 20816-3, Group 2, rigid |
Zone C/D (trip) | 4.5 mm/s | ISO 20816-3, Group 2, rigid |
Baseline alarm | 1.1 + 0.25 x 2.8 = 1.8 mm/s | Baseline plus 25 percent of zone B upper limit |
Trend warning | 0.05 mm/s per day sustained for 7 days | Plant maintenance practice |
Eleven weeks later, the trend layer fired first. The pump was still at 1.5 mm/s, below the baseline alarm and well inside zone B, and the daily median had climbed steadily for nine days. A technician took a handheld spectrum measurement and found a rising component at twice running speed, the signature of shaft misalignment. A scheduled realignment was done during a planned shutdown. Had the plant relied on the absolute zones alone, the first warning would have arrived at 2.8 mm/s, some weeks later, with a likely unplanned shutdown. Had it relied on the baseline alarm alone, the warning would have come at 1.8 mm/s, a few days later than the trend alert.
A second event from the same fleet shows the opposite failure. One pump's sensor reported 3.4 mm/s from the first day, apparently in zone C, while the maintenance team's handheld measurement on the bearing housing showed 1.2 mm/s. The node had been stuck onto the fan cover with an adhesive pad. The cover was resonating, so the sensor reported the cover, not the bearing. Moving the node to the bearing housing brought the reading to 1.2 mm/s. The lesson is that an alarm investigation begins with a handheld cross-check, because an alarm can be about the sensor's mount instead of the machine.
Wired Transmitter or Wireless Node
Both approaches can deliver the overall velocity number the standard asks for, and the choice follows from the site more than from the physics.
Factor | Wired transmitter (RS-485 or 4 to 20 mA) | Wireless node (battery, low-power radio) |
Installation effort | Cable runs and terminations; more work per machine | Mount and commission; fast across many machines |
Power | Continuous from the loop or a supply | Battery, so duty cycle and reporting interval set the life |
Data richness | Continuous polling; high-rate data possible | Limited by airtime; summary values plus bursts on demand |
Measurement control | Vendor-computed overall value, sometimes configurable bands | Depends on node firmware; sample rate and averaging are design choices |
Reliability in electrically noisy plants | Good with correct shielding and termination | Good, but link quality needs a survey around large metal and drives |
Best for | Critical machines, continuous protection, tight integration with a control system | Wide coverage of many non-critical machines, retrofit with minimal downtime |
A common and sensible pattern uses both: wired protection on the few machines whose failure stops the plant, wireless monitoring on the many auxiliary machines where a trend is enough. Choosing one technology for every machine is usually a budget decision that bends the engineering.
What to Send Over a Constrained Radio Link
A wireless node cannot stream raw waveforms over a low-power wide-area link. It sends summaries, and the design question is which few numbers preserve the most diagnostic value in a few bytes. A payload that serves the three-layer alarm scheme and leaves room for later analysis looks like this:
// 14-byte periodic uplink: enough for absolute, baseline and trend layers
typedef struct __attribute__((packed)) {
uint32_t seq; // monotonic, for loss detection and replay protection
uint16_t v_rms_x100; // overall velocity, 0.01 mm/s per count (0..655.35 mm/s)
uint16_t v_rms_axial_x100;
int16_t temp_x10; // 0.1 degC per count
uint8_t state_flags; // bit0 running, bit1 over-alarm, bit2 sensor-fault, bit3 low-battery
uint8_t crest_x10; // crest factor x10, a cheap hint at impacting
} vib_uplink_t; // 14 bytes
Two additions make the data far more useful. The crest factor (peak divided by RMS of the waveform) costs one byte and flags impulsive vibration that overall RMS alone hides, such as early bearing damage or loose parts. And a burst on alarm policy lets the node send a short, higher-detail record only when something is wrong: when a state change occurs, the node captures a snapshot (for example a coarse spectrum with a few dozen bins, or the amplitudes at one, two, and three times running speed) and sends it in a few additional messages. That keeps airtime and battery low in normal operation while giving the analyst something to diagnose with when an alert arrives.
Reporting interval is a design lever with a clear cost. At five-minute intervals, a node sends 288 uplinks per day. At 15 minutes it sends 96, cutting transmit energy by two thirds. Most slow-developing faults such as misalignment, imbalance, and looseness change over days, so a 15-minute interval costs little diagnostic value for the trend layer. Keep the faster interval for machines with fast failure modes, and use the state-change burst for urgency.
A Trend Estimator That Ignores the Noise
The trend layer is only as good as its slope estimate. A least-squares fit over raw samples is dragged around by start-up transients, load changes, and the occasional bad reading. A median-based estimator is robust and simple. The Theil-Sen estimator takes the median of the slopes between all pairs of points, which tolerates a sizable fraction of outliers.
# trend.py -- robust slope over daily medians (mm/s per day)
import numpy as np
from scipy.stats import theilslopes
def daily_median_slope(timestamps_s, v_mm_s, run_flags, days=10):
"""Use only readings taken while running; take one median per day; fit Theil-Sen."""
t = np.asarray(timestamps_s); v = np.asarray(v_mm_s); r = np.asarray(run_flags, bool)
t, v = t[r], v[r]
day = (t // 86400).astype(int)
d_unique = np.unique(day)[-days:]
med = np.array([np.median(v[day == d]) for d in d_unique])
if len(med) < 5:
return None # not enough history to claim a trend
slope, intercept, lo, hi = theilslopes(med, d_unique.astype(float))
return slope, (lo, hi) # slope with a confidence interval
# A trend warning requires the whole interval to be above zero and the slope above the limit:
# if slope >= trend_limit and lo > 0: raise WARN
The confidence interval is the part that stops false alarms. A slope that is high but has an interval spanning zero is noise, and the right action is to wait for more data. Requiring the lower bound above zero before raising a warning ties the alert to evidence instead of a single fluctuation.
A baseline taken on a machine that already has a fault teaches the system that the fault is normal.
Commissioning Day: A Baseline That Holds Up
The baseline is the second layer, and a bad one quietly corrupts everything downstream. A baseline taken in the first hour after installation, on one operating state, with a machine that already has a developing fault, teaches the system that the fault is normal. A disciplined commissioning routine avoids that.
Check the machine first. Confirm with a handheld measurement that the machine is healthy before capturing a baseline. A machine that already reads in zone C is a maintenance finding, not a baseline.
Capture each operating state separately. Record the states the machine actually runs in: for a variable-speed pump, perhaps 60, 80, and 100 percent speed; for a fan, damper positions that the process uses. Label each reading with its state.
Collect long enough. Two to four weeks of data per state covers daily cycles, temperature swings, and process changes. A shorter window risks a baseline from an unrepresentative few days.
Use the median, not the mean, and store the spread (for example the interquartile range). The spread tells you how noisy the machine normally is, which sets the persistence you need.
Record the context: ambient temperature, product being processed, recent maintenance. When a baseline later needs revising, this record explains why.
Revisit after maintenance. A bearing replacement or a realignment legitimately lowers the baseline. Reset it deliberately and record the event, so that a drop is not mistaken for a sensor fault.
Operators will see the results through a dashboard, and a few choices there determine whether the system is used. Show each machine's current state against its ISO zones as a simple coloured bar, show the trend as a short line over the last month, and show the running state clearly. Alerts should carry the context an engineer needs: the measured value, the threshold crossed, the baseline, the slope, and the operating state. An alert that says "vibration high" invites a phone call; an alert that says "overall velocity 1.9 mm/s, baseline 1.1, rising 0.06 mm/s per day for 8 days, running at 100 percent speed" invites a work order.
The trend layer fired nine days into a slow rise, weeks before any absolute limit was touched.
When These Thresholds Are the Wrong Tool
Machines outside the standard's scope: below about 120 rpm, under 15 kW, reciprocating machines, and gearboxes dominated by mesh frequencies. Use manufacturer limits, other standards, or analysis from your own history.
Machines that run in many distinct states. A machine that cycles between very different loads and speeds needs a baseline per state; a single threshold works badly.
When early fault detection is the goal. For bearings and gears, add acceleration, envelope, or high-frequency band features. The zone limits are a late alarm by design.
When the data cannot be trusted. A node with a poor mount, an undersized sample rate, or an uncalibrated sensor gives numbers that look precise and mean little. Fix the measurement first.
Starting on Monday
Classify every machine: rated power, shaft height, speed range, and whether its support is rigid or flexible. Record the ISO group and the zone boundaries in the asset register.
Choose sensor positions at bearing housings, photograph and record them, and mount rigidly.
Validate the measurement chain: check band, sample rate, and scale against a handheld reference on a few machines before trusting any fleet-wide number.
Capture baselines for two to four weeks per operating state, using daily medians.
Set the three layers per machine: ISO zones, baseline-plus-25-percent alarm, and a trend limit appropriate to the machine.
Gate on running state, and add persistence and hysteresis before any alarm reaches an operator.
Define the response: who looks at a warning, who attends an alarm, and what the handheld cross-check procedure is.
Review after 30 and 90 days: tune persistence and trend limits against what the system found and missed.
Back to 4.5 mm/s
The number from the first paragraph stays the same on every machine, and what it means changes with each. A monitoring system earns trust by knowing the difference: the standard tells it where the dangerous zones are, the baseline tells it what normal looks like for this machine, and the trend tells it which way things are moving. The most useful alert is the quietest one, the slope that bends upward weeks before any absolute limit is touched.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments