Predictive maintenance for a chemical plant: where the forecast breaks down
A chemical plant can hardly ever stop: after a reactor or column is shut down, the operating mode has to be brought back up from scratch, and the batch goes to waste.
That is why unplanned production shutdowns almost always start with a single component — a pump bearing, a compressor seal, the tube side of a heat exchanger.
The failure itself is discovered after the fact: the shift sees a rise in temperature or a drop in flow rate when the service life is already exhausted. Early warning of a failure requires something else — a history showing how the component behaved in the weeks before the event.
Predictive maintenance at a chemical plant runs into the statistics problem. A failure of a particular size type occurs once every few years, while a model needs dozens of labeled examples.
Formally, asset management is described in ISO 55000, but the standard does not say where to get the labels.
The data exists, the connection does not. The reading archive is written continuously, but there is nothing to tie a segment of the curve to an event: repair logs are kept by hand, and wording like "tightened the gland" gives neither the component nor the cause. The gap between the archive and the repair decision is the main bottleneck.
Add noise to that: a vibration sensor picks up the neighboring line, alarm thresholds are set with a large margin, and the shift gets dozens of trips per day. People get used to them — and a real warning slips by.
Below we break down how this gets closed: where to install measurements, how to label the wear history of components and units, and how to take an equipment failure forecast all the way to a repair request.
What changes in production: measurable effects and metrics
Predictive maintenance metrics start not with the model but with reference points: without a fixed notion of "normal" for each unit, any deviation has to be interpreted manually.
We take the procedure for selecting monitored parameters, mode boundaries, and response rules from ISO 17359 — it also defines what counts as a sustained deviation and what counts as a one-off spike.
The key quantity is the early warning window, that is, the time between the first sustained drift of a reading and the moment the component loses its operating capability.
On pump and compressor fleets, agitated vessels, and plain bearings it is measured in hours and days: that is enough to shift the load to a standby unit, assemble a spare parts kit, and perform the replacement within a planned window.
If the window is shorter than one shift, the system works only as an emergency alarm, and there is nothing to plan with.
The second metric is the false alarm rate. A shift stops trusting alerts after roughly ten empty alarms in a row, so we calculate it not from the model but from the log of the operator's actual actions.
We reduce it through confirmation across several independent channels, a hold time for signal persistence, and separate thresholds for startup, transient, and steady-state modes.
The third group is equipment downtime: the number of unplanned shutdowns per period and their total duration.
This is also where the shift from calendar-based repair to condition-based maintenance becomes visible — the share of work assigned based on actual component wear rather than on operating hours since commissioning.
As that share grows, part life is consumed according to actual condition rather than "just in case," and fewer components are replaced prematurely.
Three approaches to failure forecasting: thresholds, statistics, models
The choice of approach is determined not by the maturity of the technology but by what is available at the input: failure labels, mode stability, and the cost of a false alarm.
Threshold rules designed according to ISA-18.2 deliver predictable behavior where setpoints are confirmed by the shop's process regulations.
A model is appropriate when a history of incidents tied to telemetry has been accumulated, and between these two extremes lie statistical methods — they need only a baseline of normal operation.
| Approach | When it applies | Where it runs into trouble |
|---|---|---|
| Threshold rules | Setpoints are defined by process regulations, process inertia is high, round-the-clock alarming is needed | Does not see slow drift, trips on mode changes, is configured manually |
| Statistical methods | A baseline profile and several weeks of steady operation exist, failures are few or there are no labels | Sensitive to seasonality and feedstock changes, do not separate the causes of a deviation |
| Model based on failure history | Dozens of documented incidents with component-level telemetry have been accumulated | Requires clean labels, is retrained when the scheme changes, does not explain causes |
In practice the approaches do not compete but are assembled into a cascade: rules catch fast emergency deviations, statistics catch drift over a shift or a week, and the model refines remaining useful life where there is enough data.
Sensor-based anomaly detection provides early warning, but the decision to take a component out for repair still rests on a confirmed indicator, otherwise trust in the system collapses after the first false alarm.
We start with a data audit: we count how many incidents are labeled, how often modes changed, and where telemetry is incomplete. That is what determines which of the three approaches will deliver results and which will have to be postponed until history accumulates.
Implementation stages: from data audit to handover into operation
We start not with the model but with the data: we export archives from the DCS and sensors, look at the polling frequency, the share of gaps, setpoint drift, and the format of shift logs.
The stages of implementing predictive maintenance are the same at any plant — what differs is the content of the steps, and the first result is a signal map with an assessment of how suitable each component is for early warning.
- Sensor and archive audit. We check recording depth and frequency, gaps, instrument replacements, and select the signals whose deviation genuinely precedes a failure.
- Failure labeling. From repair logs and operating hours we reconstruct the moment the failure began, not the moment it was recorded; we agree the warning window with the mechanics.
- Solution architecture. We decide what is computed on the industrial controller and what in the analytics loop; we fix the feature set, the observation window, and the thresholds.
- Model validation on history. Training on an earlier period, validation on the next one — without shuffling events. We calculate detection recall and the number of false alarms per component per month.
- Response procedure. Each signal is assigned a specific owner with the component, deadline, and checklist indicated; the alarm is confirmed or cleared according to the rule.
- Handover into operation. We hand over the configured system, documentation on features and thresholds, and the procedure for retraining and degradation monitoring.
After go-live we support the first period of operation until the signals start being handled routinely, and once a quarter we verify accuracy against new events.
What stays with the customer's team: configurations, architectures, procedures
The implementation of predictive maintenance ends not with a model demo but with the handover of a working package: following it, the duty shift, process engineers, and the I&C service act without our involvement.
Everything listed stays with you — in a version control system and an internal knowledge base, with a change history.
- Failure forecasting documentation set: which sensors and loops are involved, which features are derived, how to read the risk estimate and its accuracy.
- Trip rules and thresholds — separately for pumps, compressors, and heat exchangers, with a justification for each value and the procedure for revising it.
- Solution architecture — the signal path from the field level to the operator's warning card: where buffering happens, where validation, where computation, where notification.
- Warning response procedure — risk gradations, confirmation deadline, shift actions, and the escalation path to a mechanic or process engineer.
- Access roles for process data — separation of rights for the process engineer, analyst, and contractor, and logging of archive accesses.
- Model retraining rules — which events trigger it, which quality metrics must hold at no worse than the baseline, who approves the release of a new version, and how to roll back to the previous one.
- Maintenance manual — typical computation failures, health checks, and the procedure for stopping and restarting without losing accumulated statistics.
The package removes your dependence on us: the second shift is trained in a couple of duty cycles, and your engineers make configuration edits according to the described rules.
Case study: how sudden shutdowns at a plant were reduced
The predictive maintenance case began with a single component — a centrifugal pump in the coolant circulation loop. It caused four to six unplanned shutdowns per quarter: each one 6 to 12 hours of downtime, disassembly, and replacement of the bearing assembly and seals.
The crew performed scheduled rounds once every two weeks, and about 40% of the callouts ended with nothing — the equipment was fine, and the next failure occurred between rounds.
We collected the telemetry already coming from the component: vibration on three axes, bearing temperature, inlet and outlet pressure, motor current, flow rate, and medium composition. To this we added the repair history from the CMMS (exports from SAP) and operator logs.
Failures from past periods were labeled retroactively — from defect inspection reports and replacement records — otherwise the model would have learned from empty intervals.
We built the forecast on one component and did not spread ourselves thin: the model estimates the remaining useful life of the bearing assembly and provides an 8–12 hour window before parameters go out of bounds.
The trip threshold was selected to cut off false alarms — for the repair crew, missing a warning matters less than a wasted callout.
What changed over two quarters of operation: unplanned shutdowns on the component went from four to six down to one per quarter, average downtime from 9 to 3 hours, and the share of wasted callouts from 40% to 12%.
Replacements are now planned in advance and scheduled into a planned downtime window. The logic was transferred to neighboring pump groups, and the labeling and threshold scheme itself became a template for the rest of the shop's units.
What to do if the failure history is short or there are few sensors?
A forecast is built on events, not on observations. If a component has only three to five failures recorded, statistics cannot separate mode from noise: the model memorizes spikes and trips on startups and transient modes.
So we first determine what is missing — events, sensors, or labels — and only then choose the method.
There are four workable strategies, and on a single component they are usually combined.
| Option | When it fits | Limitations |
|---|---|---|
| Transfer from an analogous component | there is a similar component with a failure history | modes and sensor set must match, otherwise false alarms |
| Expert rules | the precursor is visible in one or two parameters | do not catch rare combinations, require revision after changes |
| Monitoring and accumulation | there is no data, but the component is critical | no forecast yet — only monitoring and labeling |
| Expanding the sensor set | the process is not measured where the failure originates | installation, synchronization, delay until first conclusions |
We take expert rules from the practice of process engineers and operators: temperature and pressure thresholds, the rate of parameter growth, deviation of ratios.
This is protection from day one and at the same time accumulation of labels — an operator confirming or dismissing a trip turns the telemetry stream into a training dataset.
Monitoring as a standalone mode: we fix a baseline profile per operating mode — startup, nominal, planned shutdown — and track drift instead of forecasting.
Once several dozen labeled incidents have accumulated, thresholds are replaced by a model trained on real precursors, and transfer from an analogous component serves as the starting point.
Common technical doubts before starting
The questions at the start sound the same at any plant: will the accumulated data be enough, what happens to the model after a unit is replaced, will the shift drown in false alarms, and where do the process parameters go. We answer to the point, without generalities.
Training data does not have to be perfect. We bring manual round logs, repair history, and readings from existing sensors onto a single timeline and label failures from reports and operating hours.
If the archive is short, we start with condition monitoring and build out the forecast as confirmed pre-failure states accumulate. Production data stays within the plant's perimeter throughout.
Will there be enough data if the logs were kept by hand for years?
A manual record is a ready-made label: the rounds inspector notes vibration, bearing heating, leaks, and unusual noise. We digitize the records and join them to the sensor data by time and component position.
We fill in the missing modes with operating hours — we launch the forecast once enough confirmed pre-failure states have accumulated, not on an empty archive.
What happens to the model after equipment replacement or a feedstock change?
Replacing a pump or heat exchanger, or switching to a different feedstock, shifts the distribution of features — data drift begins. We monitor it through input statistics and forecast quality, and when it goes out of bounds we trigger retraining on a fresh window.
Until retraining, the component is flagged as unverified: the forecast for it runs with reduced confidence rather than silently producing a wrong result.
How do you set the threshold to avoid false alarms?
We choose the threshold according to the cost of a miss and the cost of a false alarm: lower for a critical component, higher for a secondary one. Signals are aggregated over time so that a single spike does not raise the emergency status.
Initial tuning is done on history with a known outcome, and afterward based on feedback from the operations service.
Who maintains the model after launch?
We hand over a maintenance procedure: how often to check quality, when to retrain, what to do in the event of an emergency shutdown of a component.
Our engineers stay in touch — we analyze incidents, fine-tune features when the production scheme changes, and record the changes in the documentation so that the model's logic does not remain a "black box" for your I&C service.
Let's discuss the task: what we need from your side
We launch the pilot on a single component — that way the assessment rests on actual data rather than assumptions, and the first results are visible on a narrow scope. To come back with an assessment and a work plan rather than generalities, we need a starter package from you. Below is what we will ask for in a discussion of a predictive maintenance task.
- A list of components with criticality: where a failure stops the process, which downtime costs the most, and whether there has already been an unplanned shutdown. We use this list to choose the component for the pilot.
- Telemetry archives: an export covering the longest available period, the polling interval, and the sensor set — vibration, bearing temperature, pressure, flow rate, drive current.
- Repair and replacement logs: work orders, defect sheets, failure dates. Without them pre-failure states cannot be labeled — the model has nothing to learn from.
- Process regulations: setpoints, permissible ranges, startup and shutdown modes. Needed so the model does not mistake a normal transient process for an emergency.
- Contacts of a process engineer and the repair service — two or three people who will confirm the labels and say which wording of a warning is understandable to the shift.
- The output format of warnings: where they arrive (operator console, message to the duty officer, report), how many hours before failure, and what false alarm rate is acceptable.
- Accesses: read access to the historical database and a test environment without write permission to control systems; if needed, a confidentiality agreement.
With this package we come back with a pilot plan: the data collection scheme, the scope of labeling, quality metrics, and validation on a held-out period. Describe your task — we will come back with an assessment and a plan.
