SCADA (Supervisory Control and Data Acquisition) is the supervision layer of an industrial process: it collects field controller variables in real time, renders them on operator mimic screens, runs the alarm system, records short-term trends and lets operators send setpoints and commands to the equipment that executes the control.
Architecture: field, server and operator stations
A SCADA system is organised in three planes. The field plane holds the equipment that measures and acts: PLCs and RTUs (Remote Terminal Units). The RTU comes from telemetry over dispersed installations (water networks, pipelines, electrical substations) where the link was radio or a leased line and the device had to survive alone for hours, buffering timestamped events until communication returned. Most Ethernet-capable PLCs now cover that role, so the PLC/RTU distinction is more historical than functional.
The SCADA server is where the system lives. It holds a communications driver layer that polls devices over their native protocols, an in-memory tag database keeping the current value of each signal with its quality and timestamp, an alarm engine evaluating conditions over those values, a trend logger writing a subset of tags to disk and, almost always, a scripting engine for derived calculations and supervisory automation. On critical installations the server is duplicated as a redundant pair, one node active and one in hot standby ready to take over.
The operation plane is the client stations: the control room seats where mimics are drawn, alarms acknowledged and commands issued. On a small installation all three planes collapse into a single industrial PC next to the cabinet. Licensing typically goes by tag count and connected clients, and that commercial detail has a technical consequence that returns below: it shapes how many signals get declared and how many get historised. In the ISA-95 functional hierarchy, SCADA sits at level 2, above automatic control and below production execution.
What a SCADA actually does
Supervise. The server asks for each tag value on a cycle typically between half a second and two seconds, against a PLC scan cycle measured in milliseconds. The consequence is structural: what appears on screen is an undersampled version of the process, and a pulse shorter than the poll period may never show up unless the PLC latches it into a flag the SCADA does get to read.
Send setpoints. The flow is bidirectional: the operator changes a setpoint, starts a pump or switches a mode, and the SCADA writes that value into the controller. Whether the order is admissible is decided by the PLC, through its interlocks and permissive conditions. SCADA is not part of the safety chain: functional safety functions are implemented in the control layer, normally in a dedicated safety controller, and must still hold with the SCADA switched off.
Alarm. The alarm engine compares values against limits, with hysteresis and delay to avoid chattering, and drives a life cycle per alarm: raised, acknowledged by the operator, cleared and, where applicable, suppressed. That alarm and event log is a different database from the trend store, and the discipline of keeping it usable (prioritisation, flood suppression, periodic review) has a standard of its own, ISA-18.2.
Trend. A SCADA stores the evolution of a subset of signals so the operator can look backwards. That subset, its logging frequency and its retention horizon are configuration parameters rather than properties of the system, and they are almost always sized for the shift or the week.
Where it shows up on the plant floor
SCADA is the norm in any process governed from a control room: pumping stations and municipal water treatment, solar plants and substations, food and beverage packaging lines, ceramic kilns and dryers, cold stores, compressor rooms and factory utility plants. In Spanish industry the usual case is not a new installation but an inherited one: the system came with the line ten or fifteen years ago, the licence is tied to a specific version, the control room PC runs an operating system frozen for driver compatibility, and the project was written by an integrator who may no longer be around. Underneath, protocols of several generations coexist: OPC-UA on recent machines, Modbus on auxiliary equipment and meters, vendor-native controller protocols in the core of the line, and IEC 60870-5-104 or DNP3 in water and electricity.
SCADA, HMI and MES: three layers that get confused
All three put production information on a screen, and the similarity ends there. The HMI is the local interface of one machine or cell: it lives in the cabinet, usually on a touch panel, its scope ends at the equipment it drives, and its purpose is to let whoever stands at the line operate it. SCADA aggregates: it integrates several machines or a whole area, keeps the short history, centralises alarms and provides the overview. The boundary is one of scope and architecture, not of looks: plenty of HMIs have richer screens than many SCADA systems.
The MES answers a different question. It does not watch process variables but production execution: which order is running, with which raw material batch, on which machine, with which operator, how much was declared good and how much rejected, and what traceability remains. SCADA knows the kiln is at 180 °C; MES knows those 180 °C belong to a specific work order for a specific product and batch. They are therefore not alternatives: the context MES contributes is exactly what SCADA lacks. The full comparison is in the MES vs SCADA guide.
Why a SCADA is not a data platform
SCADA is optimised for the present and for operation, not for analysis. Its core is an in-memory current-value store; history is a by-product of the trend view rather than an archive designed to be queried. Five limits explain why that gap is not closed by adding disk.
Retention and sampling. Logging is sized for the operational horizon (hours, shifts, sometimes months) and age-based deletion is the default policy. On top of that, storage happens by exception, with a deadband that discards small movements: whatever failed to cross the threshold was never written, and that loss cannot be recovered retroactively.
Proprietary schema. The history lives in binary files or in a private schema inside a relational engine, half documented and designed to be read by the product itself through its SDK. Querying it reliably from outside is not opening a table; it is an integration job with its own learning curve.
No business context. A SCADA tag carries an address, a description, units and little else. It carries no work order, batch, part number, shift or operator. Without that context a value answers no management question: knowing there was a 22-minute stoppage says nothing about which product was not made, or what it cost.
Flat model. Tags are named to draw the mimic and to the taste of whoever built it, not to be analysed. A reusable asset hierarchy rarely exists, so two identical lines end up with different naming and comparing them requires a manual mapping that has to be redone every time someone adds a signal.
Criticality and load. The SCADA server is control room equipment: it carries live supervision, sits on an isolated network segment, usually runs a frozen operating system version and has no maintenance window. It is not the place to run heavy analytical queries or to install data tooling, because any added load competes with the function it exists for.
In one sentence: a SCADA answers “what is happening now and what happened in the last few hours” well, and “what happened, with which product, compared with which month” badly. The sensible architecture neither replaces the SCADA nor promotes it to corporate repository: it leaves it supervising and places a data layer beside it, a historian for the time series plus a model that adds context, which receives the telemetry and serves it to the rest of the business. That pattern is developed in the industrial data platform guide.
What it takes to move SCADA data into a data layer
There are three routes and they are not equivalent. The first is reading the live value from the SCADA itself, which almost always exposes an OPC-UA server (or, on older installations, the previous generation, OPC DA, tied to Windows and DCOM and needing a converter in between). That is the short path: years of signal engineering already solved in a single connection. The second is extracting its history and alarm log, over SQL or the product interface; it is the only way to recover what already happened and the only source of downtime reasons. The third is reading the PLCs in parallel with an industrial gateway, which frees capture from SCADA availability and licensing at the cost of rebuilding the signal map.
Latency and cycle accumulate. Between the physical event and the data layer there are at least four stages: the PLC scan cycle, the SCADA driver poll period, the logging deadband and the northbound publication period. Each one is a low-pass filter. For process trends, consumption or shift indicators the whole chain is more than enough. To reconstruct a sequence of events with millisecond resolution, meaning which signal tripped what, the data has to be taken where it is generated, at the PLC, which can timestamp within its own cycle.
The timestamp has an owner. By default the SCADA stamps a value when it receives it, not when it happened. OPC-UA distinguishes two stamps, source and server, and the engineering rule is to propagate the source one whenever it exists and to synchronise clocks over NTP; lose that distinction and the history is dated with communication latency baked in.
Addressing is inherited. The SCADA namespace is its tag list, with whatever naming the person who drew the mimics chose. Reading from there inherits that naming as is, inconsistencies between lines included. Normalising it into an asset model with stable names, the step that makes two equivalent machines comparable, is the job of the data layer, and fits naturally into a Unified Namespace.
It does not interfere with control, but it can disturb supervision. Reading is passive: it does not modify logic or interlocks and does not require stopping the line. The real risk is load and network. A server sized for three operator seats can degrade if aggressive OPC clients are added, and a bulk history export at peak time competes with control room trends; the first is bounded by grouping signals and tuning the subscription period, the second by scheduling extractions off-peak or against a replica. On the network side, access is handled with a dedicated read-only account and one rule not to break: the flow is one-way, the data layer reads from the SCADA and never writes into it. What usually mediates is a gateway or an OPC-UA client that republishes values over MQTT with local buffering, so a link outage delays data rather than losing it.
And one source that is systematically forgotten: the alarm and event log. Downtime reasons live there, and downtime reasons are what turn an OEE percentage into an action plan. They do not sit in the tags but in the SCADA database, so extracting them is a different integration from reading variables.
Related terms
SCADA relies on PLCs as the source of data and the organ of execution, delegates long-term history to the historian and hands order management and traceability to the MES; moving its data towards management systems is the scope of OT/IT integration. In the service catalogue, building and modernising these layers is PLC, SCADA and HMI engineering, and connecting them to the rest of the company is OT/IT integration.