From SCADA Data to Maintenance Decisions in 15 Minutes

Most SCADA implementations are richer than anyone actually uses. The historian is logging thousands of tags. Events are timestamped to the millisecond. Alarm sequences are preserved. And yet, the maintenance planner is still making decisions from a weekly report that summarizes all of that into four aggregate numbers and a paragraph of free text from the shift supervisor. We've seen this gap at facilities running OSIsoft PI, Ignition, and in-house historian builds alike. The data is there. The pipeline to act on it is not.

What SCADA Captures vs. What Maintenance Actually Needs

SCADA is designed for real-time process control and event logging. It does both well. What it doesn't do is translate that data into the form a maintenance engineer needs to decide: is this equipment degrading, and if so, what's the failure mode and how much time do I have?

A SCADA historian stores event logs: discrete state changes, alarm activations, operator acknowledgments, setpoint modifications. These are accurate and complete. But maintenance decisions require trending signals, which are a different thing entirely.

Trending signals are derived quantities: the rate of change of a measured variable over time, the moving variance of a vibration reading, the correlation between motor current draw and ambient temperature. None of these exist natively in a SCADA historian. They have to be computed from the raw tag data, and that computation step is exactly where most plants stop.

SCADA provides	Maintenance needs
Timestamped tag values	Trended signals with rate-of-change
Alarm event log	Pre-alarm leading indicator signatures
Operator action log	Intervention history correlated to asset state
Raw vibration amplitude	Spectral envelope over time, harmonic tracking
Motor current instantaneous	Current signature analysis, load trending

The gap between column 1 and column 2 is where predictive maintenance either happens or doesn't. In our experience, closing it requires an explicit data pipeline, not a dashboard refresh.

Building the Pipeline: From Historian to Analytics

Here's the thing about most SCADA-to-analytics integrations: the hard part isn't the connectivity. OPC-UA, REST API, database replica, CSV export over SFTP: all of these work. The hard part is the signal engineering between extraction and analysis.

Step 1: Aggregation windows. Raw SCADA tag data is sampled at 1-10 second intervals for most process variables. For predictive maintenance analytics, you generally don't want raw samples. You want aggregated windows: 1-minute mean and standard deviation, 15-minute percentile ranges, 1-hour trend slopes. The window size should match the failure mode time scale. A bearing that degrades over weeks wants a 15-minute window. A pump that cavitates intermittently needs 1-second burst capture.

Step 2: Outlier filtering. Raw historian data contains spikes from instrument faults, communication dropouts, and maintenance calibration events. These are real events but not process signals. Feeding them unfiltered into a trend model produces false positives. We use a rolling 3-sigma filter with a minimum run length of 3 consecutive points before confirming an anomaly as genuine rather than instrumental. A single outlier point gets tagged and excluded from trending, not removed from the record.

Step 3: Feature engineering for the two most valuable signal types. Vibration and motor current are the highest-information signals for rotating equipment health.

For vibration: compute the RMS envelope in time domain, then derive the crest factor (peak/RMS ratio). A rising crest factor with stable RMS indicates impulsive events, the early signature of bearing race defects. The overall RMS rising while the crest factor stabilizes indicates a different degradation mode: misalignment or imbalance. These two cases require different maintenance responses, and confusing them wastes intervention time.

For motor current: the relevant features are load-normalized current (actual current divided by expected current at the current load point), harmonic content at 2x line frequency (indicates stator issues), and current imbalance across phases. None of these come out of the SCADA historian directly. They require calculation against a baseline load model.

Fact: in our deployments, these five derived features (RMS envelope, crest factor, load-normalized current, harmonic content, phase imbalance) account for over 70% of successfully predicted failure events across pump, compressor, and conveyor assets.

Closing the Loop: From Analytics Back to CMMS Work Orders

The data pipeline from historian to analytics is half the problem. The other half is what happens when the analytics finds something.

In most plants, the analytics output goes to a dashboard that the reliability engineer checks when they remember to. Real talk: that's not a predictive maintenance program, that's a monitoring program. The difference is the feedback loop to the CMMS.

A properly closed loop looks like this:

1. Analytics layer detects a trending anomaly that crosses a configured severity threshold for a specific asset and failure mode.
2. An alert is generated with: asset ID, failure mode hypothesis, current severity score (0-100 scale), estimated remaining useful life if the trend continues, and recommended intervention type (inspect, lubricate, replace bearing, etc.).
3. The alert is written to the CMMS (SAP PM, IBM Maximo, Infor EAM, or equivalent) as a work notification in the appropriate priority class.
4. The maintenance planner sees the notification in the existing scheduling workflow. No new system to check. No separate screen.
5. When the work order is completed, the CMMS records the actual finding. That finding is fed back to the analytics layer as a confirmed or disconfirmed prediction, updating the model's calibration for that asset type.

Step 5 is where most implementations fail. The write-back from CMMS to analytics is technically simple but organizationally hard: it requires the maintenance technician to record findings in a structured field rather than a free-text notes field. In our experience, compliance with structured finding codes runs at about 60% without a deliberate training program, and above 85% with one. That 25-point difference in data quality drives a measurable difference in model accuracy over 12-18 months of operation.

A Realistic Implementation Timeline

We've helped plants close this loop in as little as 6 weeks for a focused asset class (for example, all cooling water pumps on a single production line). Full plant coverage across all critical asset classes typically takes 6-9 months, not because the technology is slow, but because signal validation, baseline establishment, and CMMS integration require engineering time that can't be shortcut.

Start narrow. Pick 5-10 assets where failure history is documented and the cost of an unexpected failure is clearly understood. Get the pipeline working end-to-end on those assets, including the CMMS write-back. Prove the loop. Then scale.

The goal isn't to deploy the most sophisticated analytics. The goal is to make maintenance decisions faster and with better information than the weekly shift report. That's achievable. We've seen plants cut unplanned downtime on targeted asset classes by 30-40% in the first year, not through heroic engineering but through consistent, closed-loop data use.

If you want to talk through what the data pipeline looks like for your historian environment specifically, our team is available for a no-obligation technical discussion.