Definition
SCADA (Supervisory Control And Data Acquisition, a data acquisition and monitoring system) is used for remote measurement and control in industrial automation, electric power, water services, and other fields. It collects on-site data through RTU, Modbus, IEC 104 and other protocols, achieving telemetry, remote signaling, remote control, and remote adjustment.
System architecture
SCADA usually includes: the field layer (RTU, PLC, sensors, instruments); the communication layer (4G, fiber optics, private network); the master station layer (data acquisition, human-machine interface, historical database, alarms); and the application layer (reports, analysis, integration with MES and GIS). The master station communicates with RTUs through protocols such as Modbus, IEC 104, DNP3, and OPC UA. Compared with DCS, SCADA focuses on wide-area data acquisition and monitoring, while DCS focuses on process control.
Application Areas
Power dispatch and distribution automation; water, gas, and heating pipelines; oil and gas pipelines; municipal, transportation, and environmental protection. Industrial gateways can convert field device data into protocols supported by SCADA, or integrate SCADA data into cloud platforms and IoT platforms.
What the Master Owns, and Aligning Timestamps
The master handles the four remote points, not loop regulation
The master's job is to gather geographically scattered sites into one picture that can be watched, and to issue a small number of discrete commands or setpoints when needed. The field device itself completes fast interlocks and protection. The master does not take part in every scan. A value in the master database is therefore "the engineering quantity from the last successful communication," and it should carry a timestamp and a quality beside it. Without a timestamp, dispatch cannot tell a current value from a freeze two hours old. If the display paints both in the same bright color, an operator issues a command from expired data.
Before a point is stored, finish ratio, polarity, deadband, and alarm class. The deadband suppresses a screen flood when a measurement chatters around a threshold. Too wide a deadband swallows a real slow change. Alarm class decides whether a confirmation is required and whether the alarm is pushed up a level. A system with no classes flashes every point during an incident, and the first real signal is buried. The field PLC or terminal is responsible for turning a raw channel into these points. The master should not guess the range a second time.
A wide-area link has to be allowed to drop
The condition for use is that the link may be interrupted and the service can still say what happened during the interruption. The uplink of a pipeline, a distribution network, or a pump station is not online at every moment. The terminal should keep a local sequence of events and freezes, and backfill by time after recovery. The master should accept late data and insert it into history, rather than overwriting the sample time with the time the backfill arrived. Control commands are the opposite. A command that was not executed before it timed out must be voided. It must not be carried out suddenly when the link returns. Field state has already changed, and a command applied late moves the wrong equipment.
Authority and interlocks are the premise of control. When a site is in local mode, under maintenance, or has bad communication quality, the button on the master should be unavailable, and it should say why. With dual masters or a main-standby switch, only one master may hold control. The standby may watch. Commands already in flight during a transfer of control have to be cleared.
Timestamps, alarm floods, and command interlocks
An alarm flood during an incident is the easiest way to wear the system out. One power failure produces a hundred communication-failure alarms. If each has to be acknowledged by hand, the initiating cause is pushed to the bottom of the list. Group alarms by site, and let the terminal report the cause rather than every communication failure derived from it. Second is time sync. If the master, the terminal, and the communications processor differ by more than the event resolution, the order of actions across sites is reversed and the incident analysis points at the wrong switch.
Third is the general interrogation when a site comes back online. The interrogation refreshes current values, but if it does not carry quality, old alarms from the outage pop up again, as if the incident had happened a second time. Separate "current state" from "a new event not yet acknowledged." The history store also has to avoid drawing a straight line through the whole outage from the last value before the break. Finally, if a command is selected and not executed for a long time, the selection should time out and be cancelled, so the next shift does not execute it without knowing a selection is still pending.
A standby-channel switch also has to stop both masters from running a general interrogation at once. If main and standby each pull every point, the terminal's communication task fills up, the field control cycle lengthens, and in a severe case the terminal declares a communication fault and drives outputs to the safe state. The switchover logic should stop interrogation on one side first, then hand control over, and leave the switchover time in the database, so communication alarms caused by the switch can be separated from a real site fault.
Do not leave two clock sources either. If the master uses one time source and the terminal uses another inside the communications processor, the sequence of events shifts as a whole after a switch. Name a single time source, and carry the terminal's own clock offset in the interrogation message. When the offset is too large, prohibit commands.