Equipment anomaly detection: where time is lost
A typical scenario across different production sites looks the same: a pump or gearbox bearing assembly writes vibration and temperature to the archive for years.
Values slowly creep upward but do not cross the setpoint, and equipment anomaly detection turns into a statement of fact — the signal arrives when the unit is already humming and is taken out of service.
The reason is not lack of sensors but control logic. The setpoint is taken from the nameplate limit, not from the unit's own norm: a fresh bearing and a unit after repair produce different background, load changes by shift, temperature drifts with season.
GOST ISO 17359 says the same: condition is assessed by trend and a combination of signs, not by a single point. When one rule applies to the entire fleet, the pre-failure condition of a unit is visible only at the final stage — hours before destruction.
The cost of late notification is made up of simple things: unplanned line shutdown for a shift or more, urgent search for the unit in the warehouse or from a supplier, batch scrap, emergency call during the night shift.
Post-mortem analysis also returns nothing — engineers open an already destroyed unit and do not see how bearing assembly wear developed.
We explain how this is closed: from data acquisition from already installed sensors to a model that knows the norm of a specific unit and raises a signal at the stage when replacement is still planned.
What early detection of deviations in unit operation gives
The model builds a baseline profile of the unit from historical data — vibration, current, bearing temperature — separately for each load mode. Deviation is assessed not by a single threshold but by a combination of features, so early warning comes hours or days before failure.
The engineer receives not an “emergency” signal but a specific unit, degree of deviation, and window in which inspection should be performed.
Condition-based repair makes sense when the effect is measurable. Therefore before implementation we fix a set of metrics and compare them before and after:
- Share of unplanned shutdowns — how many failures moved into planned work.
- Reaction time to deviation: from first warning to intervention decision; reduced from weeks of rounds to hours.
- Unit remaining life — how much is left to limit state based on signal dynamics, not nameplate service life.
- Repair planning — work window is known in advance, crew and spare parts are prepared for a specific date.
- Warning accuracy — share of confirmed deviations and number of false positives per shift.
- Observation coverage — share of units and modes for which training data and a working model are available.
- Transition to condition-based maintenance: some scheduled works are canceled, replacement criterion is actual wear (ISO 17359).
Implementation pays off not through the model but through a change in procedure: shift and repair service work from one priority list. For the first weeks after launch we observe threshold behavior under real load — and only then put warnings into operation.
Approaches to unit condition monitoring: comparison of modes
The three approaches differ in how much knowledge about the unit itself must be embedded before launch and how they behave in rare modes. At a live site, the choice is determined not by “model accuracy” but by how many false positives operations is ready to handle per shift.
| Option | When it fits | Limitations |
|---|---|---|
| Threshold rules | Unit physics is known, there is a clear boundary between normal and defective, and each trigger needs predictable review | Does not see slow drift and combinations of parameters; setpoints have to be moved manually, and the flow of false positives grows with the number of rules |
| Statistical models | Operating mode is stable, telemetry is sufficient to estimate the norm on a sliding window | Break down when mode changes, seasonality, and after repair: the model treats new unit behavior as deviation |
| Learning on historical data | Labeled failures and emergency cases have been accumulated, and there is data to validate quality | Rare failure classes are poorly represented, the model inherits labeling errors, and requires retraining when changes occur |
| Hybrid approach | Critical units where missing a failure costs more than an extra inspection | Harder to implement and maintain: rules, a model, and maintained labeling are needed simultaneously |
In practice the scheme is assembled in layers: threshold rules provide the baseline and clear review, statistics cover drift, and learning on historical data covers subtle feature combinations.
We tune sensitivity based on feedback from operations, otherwise the share of false positives erodes trust in the system faster than it can demonstrate value.
Implementation stages: from fleet audit to handover to operations
Implementing equipment anomaly detection is an engineering project, not installing a model on a server. The order of steps is fixed: first we describe the fleet and measurement channels, then build labeling, and only then enable notifications.
A skipped stage comes back as a flow of false positives that the duty shift stops trusting within a couple of weeks.
- Fleet audit. We go around units, record critical assemblies, sensor composition, and what is missing. Output — a list of objects with implementation priority and a clear coverage area.
- Data collection scheme. We determine where telemetry comes from: historian, gateways, polling frequency, archive depth. Each signal is linked to unit, operating mode, and repair log.
- Data labeling. We consolidate operational logs, work orders, and records of unplanned shutdowns. Separately label normal modes — startup, warm-up, load change — otherwise the model treats them as deviation.
- Notification setup. We set importance levels, confirmation window, and notification route by shift. Goal — one clear action per signal, not a queue of hundreds of identical messages.
- Validation on real failures. We run the system on incidents that already happened from the archive. We calculate what share of failures were caught and how long before shutdown — this is the working acceptance criterion.
- Handover to operations. Duty procedures, shift training, dashboard with current metrics, and procedure for revising thresholds when operating modes change.
What the customer receives: documentation package
The documentation package is not an appendix to the system but its working part: from it the shift engineer restores telemetry reception after a failure, and the analyst adds a new feature without contacting us.
Therefore the package includes everything that describes the signal path from sensor to generated notification — with actual thresholds, averaging windows, and filter settings, not placeholders.
- Sensor placement and telemetry collection diagram: installation points, polling frequencies, transmission channels, list of tags with units of measurement and allowable ranges.
- Labeling rules: how to record a confirmed failure and a false positive, what window is marked before and after the event, how labels are reconciled between shifts.
- Access policies: roles of operator, analyst, and support engineer, scope of rights to telemetry history and models, procedure for granting and revoking access, action logging.
- Response procedure for a trigger: grading by importance levels, what the operator checks in the first minutes, at what point the next line is engaged, who decides to stop the unit.
- Instructions for the shift operator: how to read the anomaly score, how a short-term spike differs from a developing defect, where the incident comment is entered.
- Model description: list of monitored units, features on which the solution is built, applicability limits, and conditions requiring retraining.
- Support procedure: how to submit a new labeled dataset, how to request a rebuild and threshold update, whom to contact when fact diverges from forecast.
Case: reducing unplanned shutdowns in a production area
A continuous-cycle area — three PromLine bottling lines, several dozen signals from drives, pumps, and vibration sensors.
Deviations were sought by rounds once per shift: the operator recorded a problem when the unit had already tripped into protection or bearing temperature was rising, and with it the risk of a nighttime shutdown.
We collected telemetry history for several months and, together with mechanics, labeled episodes that ended in downtime.
The model was trained on normal operation of each line separately: it compares the current profile of the unit with its own norm and raises a signal when divergence steadily grows, not when a parameter crosses the emergency setpoint.
Metrics before and after in the same area over a comparable period:
- detected deviations — from 6-8 to 20-24 per month with the same operator staff;
- share of findings caught before the emergency setpoint grew from a quarter of cases to eight out of ten;
- average time from first sign to personnel response — from 40 minutes to 8;
- unplanned shutdowns due to unit wear — from 7-9 per quarter to 2-3.
The system does not prevent some episodes: a sudden bearing failure or a break in the supply line develops faster than deviation statistics accumulate.
We separated them into reporting so that the duty shift knows the model’s applicability limits and does not wait for a hint where there will be none.
What if sensors are already installed on the equipment?
Almost always sensors are already installed and writing to a historical archive — then work begins not with hardware upgrade but with revising what has actually been accumulated.
We look at which channels are written continuously, at what sampling interval, whether timestamps follow a single standard, and how data has historically been linked to repair and shutdown logs.
Often at this step you can already see that half the signals are unused and that three or four channels have an archive suitable for training without modifications.
Suitability of the archive is determined not by its length but by coverage of modes: startups, warm-up, seasonal load changes, operation on different products. Ideally history contains several confirmed failures — the model is calibrated on them.
If there are no failure labels, we build training on normal behavior: the model describes the norm for each mode, and deviation from it becomes a signal, so an archive without failures is also workable.
Incomplete channels are the most common problem. A sensor is listed in the scheme but is written rarely, noisy, stuck at a constant, has long gaps, or duplicates the manual inspection log.
For each channel we calculate reliability metrics, mark it with a quality flag, and either restore gaps or combine it with correlating signals into an indirect indicator. Clearly useless channels are excluded so they do not dilute the picture.
We integrate into the control room without breaking the current loop: assessment runs on top of existing polling, we do not switch anything or change the sampling scheme.
A deviation message arrives where the operator already works, indicating the channel, start time, and degree of deviation from the norm, so the decision is made by context, not by a single spike.
As a result, start is possible on current telemetry. As a separate item, we record which three to five channels should be added later — they give the greatest sensitivity gain, and this is included in the modernization plan without stopping production.
Technical doubts: common questions from engineers
The solution is tested not in a demo but on a real telemetry stream: technical service cares about model behavior on an incomplete archive, under mode changes, and on false positives. Below are the five questions most often asked before start.
Will data be enough if the archive is incomplete?
We build the norm profile from the channels that actually exist: a gap is supplied as a separate feature so that loss of signal is not read as process deviation.
Thresholds are calibrated on normal modes — the model looks for deviation from the norm rather than imitating examples of failures that may not have been in the archive.
How are seasonal mode fluctuations accounted for?
Features include environmental and load parameters: temperature, shift pattern, line operation intensity. The norm is calculated over a sliding window adjusted for the current mode, so the same threshold does not trigger equally in heat and frost.
What to do with false positives?
Sensitivity is configured for each unit, and on starts and stops we add a dead band. “False” labels from the duty shift go into retraining, and noise decreases from iteration to iteration. The goal is not zero signals but a stream that the shift does not stop reading.
How is model retraining arranged?
By procedure and as labeling accumulates: training in shadow mode, comparison with the production version by miss rate and detection time, then switchover. Versions are stored, and rollback to the previous one takes minutes.
Who is responsible for the system after handover?
We hand over documentation, configured thresholds, the retraining procedure, and monitoring access — the operations service runs the system itself. If an external loop is needed, we support it: we monitor metrics and update the model when the process changes.
Let's discuss the task: what we need from you to start work
To come back with a scope estimate and work plan, we do not need a full documentation package — a minimal set of information about the process and data is enough.
We ask not for formality: the answers determine which class of models is applicable, how much time data preparation will take, and where the boundary between “anomaly” and normal mode will run.
- Problem statement: which class of failures we catch — gradual degradation of a unit, sudden parameter going out of bounds, or an atypical operating mode; what we consider a miss and what a false alarm.
- Source data: which channels are written, at what frequency, what the archive depth is, and whether it contains labeled failures and repairs.
- Equipment context: fleet composition, nameplate mode limits, maintenance procedure, and repair log — they show what was considered normal at each point in time.
- Target metrics: what share of failures may be missed and how many false positives per shift the dispatcher can tolerate — this directly sets the triggering threshold.
- Loop and access: where the telemetry archive is stored, how data reaches the model, what restrictions apply to export outside the perimeter, and who is responsible for extraction.
- Work plan and timelines: data reconnaissance, baseline model, threshold calibration on historical incidents, pilot operation on a live stream — we agree timelines by stage after reconnaissance.
- Team composition: on your side — process engineer, reliability engineer, and data access owner; on ours — data engineer, modeling specialist, and implementation engineer.
Send what you have, even in draft form: describe the task, and we will come back with a scope estimate, work plan, and timelines by stage.
