A SCADA system (Supervisory Control and Data Acquisition) is the software-and-hardware layer that lets operators monitor and control an industrial process in real time — it reads live measurements from field devices such as PLCs and RTUs, shows them on dashboards, raises alarms, and sends control commands back down. That is its immediate job. But a SCADA system's most valuable long-term output is the data it quietly records: a time-stamped history of the process that, if it is clean, becomes the foundation for predictive maintenance, energy optimisation and OEE.
What a SCADA system actually does
A SCADA system sits above the control layer, not inside it. The fast, deterministic work — opening a valve, holding a temperature, tripping on a fault — is done by PLCs (programmable logic controllers) and RTUs (remote terminal units) at the machine. SCADA polls those devices over protocols like Modbus or OPC UA, aggregates their signals into named tags, drives the operator HMI, logs alarms and events, and lets a human supervise and intervene across a whole line, plant or distributed network.
Supervise and control is the visible half. It is real, it is important, and it is what most definitions describe. It is also the half you notice only when something goes wrong. The other half — the half nobody sees on the screen — is doing something far more durable in the background.
The part most 'what is SCADA' pages skip: the historian
Behind the live screen, a SCADA system continuously writes tag values to a historian: a purpose-built time-series database. Every temperature, pressure, flow, motor current, valve position and setpoint is stored with a timestamp, often for years. Open a historian export and you get a wide table — a timestamp column and then hundreds or thousands of tag columns, each a slice of the process at that instant.
This export is the asset. It is a physical record of how your process actually behaved — not how the P&ID says it should behave, but what really happened at 03:00 on a bad night in February. Ranking 'what is SCADA' articles almost never mention the historian, because from a definitional standpoint it is a footnote. In practice it is the whole point. Everything analytical you might later want to do depends on it being there, and being usable.
Why bad tag naming quietly breaks any later analysis
Inconsistent tag naming is the single most common reason historian data can't be used. If the same pump is called PMP_01 in one area, P-101 in another, and Pump1_Feed in a third — or if units drift between bar and kPa, or a tag was reused for a different sensor after a retrofit — then a dataset that looks complete is silently ambiguous. Nobody notices during operations, because operators read the screen by context. It surfaces years later, when someone tries to compare assets across the plant and discovers the tags don't line up.
Cleaning this up after the fact is slow, expensive detective work: cross-referencing loop diagrams, interviewing the people who built the system, reconstructing what a tag meant in 2021. A consistent naming convention, applied from the start and documented, costs almost nothing during commissioning and protects the value of every year of data that follows.
Sample rates and dead-banding: signal you can never get back
Two configuration choices decide how much real information the historian actually keeps. The first is the sample rate — how often a tag is logged. Store a fast-moving vibration or current signal once a minute and the events that matter, which happen in seconds, are simply gone. You cannot recover resolution you never recorded.
The second is dead-banding (exception-based logging): to save storage, a historian often only records a value when it changes by more than a set threshold. Sensible in principle, but set the dead-band too wide and you erase the small drifts and early wobbles that are exactly the signature predictive models look for. The data will look tidy. It will also be blind to the thing you most wanted to catch. These settings are worth deciding deliberately, per tag class, not left at whatever the default was on install day.
Five years of clean process data is an asset most plants underuse
Most plants are already sitting on this asset and treating it as exhaust. A SCADA historian that has been running for five years, with consistent tags and honest sample rates, is a labelled record of your equipment's entire recent life — every start-up, every trip, every gradual degradation. That is precisely the raw material modern analytics needs, and it is expensive and slow to create from scratch.
With that history in hand, predictive maintenance stops being a vendor slide and becomes tractable: you can learn what a bearing's data looks like in the weeks before failure, because you have those weeks recorded, repeatedly. The same data drives energy optimisation — correlating consumption against production, load and ambient conditions to find the waste — and it feeds OEE, where accurate downtime and rate data turn a vague 'we could run better' into a specific loss you can attack.
From historian export to value
The honest sequence is: get the export, then check whether it is trustworthy before you model anything. Are the tags consistent and documented? Is the sample rate fast enough for the question? Did dead-banding erase the signal you need? Are the timestamps aligned across sources? These unglamorous questions decide whether a project takes weeks or quietly stalls. Skipping them is the most common way an ambitious analytics effort dies.
At Crux Digits we usually start here with a fixed-price audit: pull a representative historian export, assess data quality against the outcome you actually want, and tell you plainly whether the foundation is there — before anyone commits to a proof-of-concept or a production build. You own the code and the IP throughout, and the work is built to be EU AI Act- and GDPR-aware from the start. If you have a SCADA system running, the most useful next step is rarely more sensors. It is finding out what the data you already have is worth.
Frequently asked questions
What is a SCADA system in simple terms?
A SCADA system is software and hardware that lets operators monitor and control an industrial process in real time. It reads measurements from field devices like PLCs and RTUs, displays them on dashboards, raises alarms, and sends control commands back — all while recording the data to a historian for later use.
What is the difference between SCADA and a PLC?
A PLC does the fast, real-time control at the machine — it decides in milliseconds whether to open a valve or trip on a fault. SCADA sits above it: it collects signals from many PLCs and RTUs, presents them to operators, logs events, and enables supervision across a whole line or plant. The PLC controls; SCADA supervises and records.
What is a historian in a SCADA system?
A historian is the time-series database inside a SCADA system that stores every tag value with a timestamp, often for years. It is where the process's actual history lives — temperatures, pressures, flows, currents, setpoints — and it is the raw material for predictive maintenance, energy analysis and OEE. For most plants it is the SCADA system's most valuable and most underused output.
Why is consistent tag naming so important?
Consistent tag naming decides whether your historian data can ever be analysed. If the same asset has different tag names across areas, or units drift, or a tag was reused after a retrofit, the data looks complete but is silently ambiguous — and comparing assets or training models becomes slow, error-prone detective work. A documented convention applied from day one costs almost nothing and protects years of data.
How does SCADA data enable predictive maintenance?
SCADA data enables predictive maintenance by providing years of recorded equipment behaviour — every start-up, trip and gradual degradation — as labelled training data. If sample rates are fast enough and dead-banding hasn't erased the early signals, a model can learn what an asset's data looks like in the weeks before failure. Without that clean history, predictive maintenance stays theoretical, which is why a data-quality check should come before any model.