Most modern plants log process parameters every second, store years of it in historians, and act on almost none of it. The gap is not data collection — it is the connection between what is stored and a decision someone can act on.
Most modern manufacturing plants are already data-rich. PLCs log process parameters every few seconds. SCADA systems aggregate them. Historians — OSIsoft PI, Wonderware, Ignition — store years of it. Maintenance systems have every work order and failure event. Quality systems have inspection records going back a decade. By any measure, these plants have more data than they know what to do with. Most of it sits unread.
The gap is not collection. It is the connection between what is collected and the decisions that get made on the floor. A maintenance engineer learns a pump is failing when it trips a breaker or starts making noise — not because a pattern in the vibration data flagged it three weeks earlier. A quality engineer traces a batch failure by pulling historian data after the fact — not by catching the process drift while it was still preventable. The historian has the signal. Nobody built the path from signal to decision.
Key insight: The question is rarely whether you have enough data. Plants almost always do. The question is whether there is a working path from the data to a specific operational decision — and for most use cases, that path does not exist yet.
"The historian has ten years of operational data. The maintenance team still finds out about failures when the equipment stops running."
The Three Use Cases Worth Starting With
Plant sensor data supports a large number of potential AI applications, but three are consistently the most mature and the most tractable as starting points.
Predictive maintenance is the most discussed. The idea is straightforward: detect patterns in sensor data (vibration, temperature, pressure, current draw) that precede equipment failure and alert maintenance teams early enough to schedule planned repairs rather than emergency ones. The value is real — unplanned downtime is significantly more expensive than planned maintenance — but the implementation is harder than the pitch suggests, for reasons covered below.
Process parameter optimisation is often underestimated. Most manufacturing processes have dozens of tunable parameters — temperatures, pressures, speeds, timings — and the settings in use today reflect historical practice more than systematic optimisation. ML models trained on historical process data and quality outcomes can identify parameter combinations that consistently produce better output, fewer defects, or lower energy consumption.
Quality correlation analysis bridges the two: finding which upstream process parameters correlate with downstream quality failures. When a batch fails inspection, the root cause is often a process excursion that happened hours or days earlier. AI can find those correlations in historical data and flag real-time excursions before the affected product reaches inspection.
Predictive maintenance gets the attention. Process optimisation and quality correlation analysis are often faster to value
Predictive Maintenance: What It Actually Requires
Predictive maintenance works well under specific conditions and is regularly oversold outside of them.
The conditions where it works reliably: assets with continuous sensor coverage (vibration sensors, temperature probes, current monitors), a meaningful history of failure events, and failure modes that have detectable precursor signatures in the sensor data. Rotating equipment — pumps, motors, compressors, fans — fits this profile well. The failure modes are well-understood, the sensor technology is mature, and the pattern recognition challenge is tractable.
Where it struggles: assets with infrequent failures (not enough training examples), assets without sensor coverage (the model has nothing to work with), and failure modes that happen too quickly for early detection to help (catastrophic failures with no ramp-up signature).
The implementation challenges are largely about data. Failure event history needs to be accurate and complete — if the maintenance system logs only major failures and not early interventions, the model cannot learn what precedes failure. Sensor data needs timestamps that align with the maintenance records. And the sensor coverage needs to match the assets where predictive maintenance would have the most value, which is often not the case — critical assets are sometimes the least instrumented.
Predictive maintenance works for well-instrumented rotating equipment with a failure history. It does not generalise automatically to assets without sensors or without failure data
The Data Quality Problem
Historian data has well-known quality issues that are easy to overlook when the focus is on the ML model.
Sensor drift is common. A temperature probe that was correctly calibrated two years ago may be reading 3–5 degrees high today if it has not been recalibrated. The drift is gradual and rarely alarming, so it goes unnoticed — but a model trained on data from a drifted sensor learns a systematically wrong picture of normal operating conditions.
Missing data is pervasive. Network outages, PLC reboots, historian configuration changes, and sensor failures all create gaps. Short gaps can be interpolated. Long gaps — days or weeks — create training data that does not represent the full operating range.
Inconsistent tagging is the hardest problem. Different engineers use different conventions for naming the same measurement point across lines or sites. A model built for one line cannot be transferred to an identical line on the other side of the facility without a tag mapping exercise that can take weeks.
None of these are blocking problems. They are scoping problems. A realistic AI project plan for plant data accounts for data assessment, cleaning, and gap-filling before model development. Projects that skip this step tend to produce models that perform well in validation and poorly in production.
Sensor drift, missing data, and inconsistent tag naming are the norm in historian data, not the exception — scoping needs to account for them
Getting Data Out of the Historian
A step that is consistently underestimated: actually accessing the data.
OSIsoft PI is the dominant historian in process manufacturing. It stores data efficiently and has mature query interfaces, but access requires IT involvement, firewall rules, and often a data extraction layer that is not built yet. Many organisations have PI on the plant floor network and a corporate analytics environment on a separate network — and no clean path between them.
Wonderware, Ignition, and other historians have similar access challenges. The data is there; getting it into a form that a data science team can work with requires infrastructure that is usually not in place.
The practical approach: start by identifying one or two assets or production lines with good sensor coverage, clear failure history, and an accessible data feed. Build the extraction pipeline for that scope first. Expand once it is working. Trying to build a plant-wide data platform as the first step is a 12-month infrastructure project that delays any actual AI work by a year.
The data extraction pipeline is frequently the longest part of the project — plan for it, do not treat it as a prerequisite someone else has handled
The Right First Project
Given the data challenges, the right first project is usually narrower than the roadmap suggests.
A tractable starting scope: one asset class (say, all centrifugal pumps on a specific production line), with existing vibration and temperature sensors, at least 18 months of historian data, and a maintenance system with reasonably complete failure records. Build the failure prediction model for that scope. Instrument it. Run it alongside the maintenance team's existing process for 60–90 days to establish that the alerts are credible before changing any workflows.
The first project's primary output is not the model — it is the data pipeline, the alert infrastructure, and the trust that the maintenance team develops in the system. Those are the foundation that makes everything else possible. A narrow, credible first deployment is worth far more than an ambitious, unreliable one.
Narrow scope, credible alerts, and trust from the maintenance team — that is what a successful first predictive maintenance project produces
Originally published on the CobuildX blog.
Top comments (0)