Definition
SCADA (Supervisory Control And Data Acquisition) refers to a system architecture that centrally monitors geographically dispersed assets and issues control commands when necessary. It is commonly used in electricity, water, oil & gas, and rail transit. Traditionally, it relied on dedicated lines, radio, or private networks; 4G/5G cellular and IoT platforms reduce access costs, allowing numerous RTU/PLC substations to connect to the central SCADA server through secure tunnels.
Relationship with the Internet of Things
The Internet of Things emphasizes massive connections and cloud platform analysis, while SCADA emphasizes real-time performance and closed-loop control. The two can be integrated: edge gateways still ensure local interlocking and millisecond-level response, while the cloud handles historical data and AI. Cellular link jitter is greater than fiber, so critical control must be evaluated for whether it is allowed to be issued over the public network.
Security
SCADA systems have always been targets of network attacks; cellular access requires zero trust, zonal isolation, and auditing. On the module side, unnecessary ports should be closed, and firmware updates should be signed.
Protocols, Human-Machine Interface, and Historical Database
Traditional SCADA commonly uses protocols such as Modbus, DNP3, and IEC 104 to connect PLCs and RTUs; modern systems tend to adopt OPC UA and Web HMIs. Planning for historical databases should include compression, partitioning, and backup strategies, with long-term trend analysis relying on high-quality timestamps. Alarm management should suppress jitter and flooding in accordance with ISA-18.2 principles. Redundant servers and hot standby switching should be practiced during the engineering phase to verify that no data is lost and there are no blind spots on the displays.
Integration with IoT Platforms
The cloud can handle predictive maintenance and cross-regional comparisons, but control commands are still recommended to go through secure tunnels with approval. MTU, latency, and billing models of cellular links differ from fiber, so remote desktops and file synchronization should be rate-limited and compressed. Regulated industries (power, water) must comply with industry supervision and MLPS (Multi-Level Protection Scheme) assessments, with systematic log retention and disaster recovery drills.
Engineering Practice Supplement
Regarding "SCADA," it is recommended to architecturally distinguish between real-time control links and non-real-time telemetry links: control and interlocks should be closed-loop locally whenever possible, with cellular used for monitoring, configuration, and OTA. On the cloud platform side, observability metrics (connection duration, message delay distribution, error codes, reconnection reasons) should drive optimization, rather than just checking "connectivity." Documentation deliverables should include interface descriptions, error code tables, extreme operating conditions, and known limitations; test deliverables should include test cases, data, and conclusions, facilitating third-party retesting or audits.
Telemetry Period and the Remote-Control Confirm Window
SCADA brings geographically separate stations into one monitoring picture. Telemetry is a measurement, continuous or periodic. Status is switch and alarm state. Control is an open, close, or setpoint issued after a person confirms it. Local interlocks must finish inside the station. They do not depend on a round trip to the center. The center's value is to see many stations, keep history, and issue commands when the procedure allows it. The cellular module appears on the uplink of a remote terminal or gateway. It is fit for sending telemetry and status that have already been formed. Its jitter means a control command can take several seconds from the press to confirmation in the field. Conditions on site can change in that time, so control needs select, execute, and confirm. A single register write is not the end.
The condition of use is to decide first which points may leave the station. Protection trips and emergency stops stay on local hardwire or the station controller. Energy, level, and access state can be sent up. The timestamp has to be applied inside the station. Do not stamp it when the center receives it. Alarms need a deadband and a delay, or one chattering contact floods the operator. A hot-standby switchover has to be rehearsed until both the picture and the history have no gap. Proving that a server process can be started is not the rehearsal.
When an Interlock May Be Sent over the Public Network
The most dangerous misuse is to put interlock logic in the cloud. A cellular outage removes protection from the site, or a command arrives late when the equipment is already in another state. Next is sending every telemetry point at the fastest period. The narrowband link fills, and a real status change waits behind it. Third is a historian that stores by receive time. Station clocks disagree, and incident playback places a later point first. If the remote maintenance port and control share one tunnel with no authentication, the module becomes a bypass into the station network.
Plant cyclic data should not be pulled out of the real-time ring just to put it on a screen. The boundary is in PROFINET. If the point list enters the center through an information-model subscription, deadband and certificates are in OPC. Do not merge the refresh periods of the two paths into one "communication normal" indication.
The point list should mark each item as a station interlock, telemetry that may be sent up, or control that may be issued remotely. Without that mark, integration turns a trip condition into a cloud rule as well. Control must have select, execute, and confirmation from the field. On confirm timeout, return to unselected. Do not stop on "command sent," leaving the next shift unsure of the real switch position. Alarms should record how many times the deadband suppressed them. Otherwise the operator believes the site is not chattering, while storage has already dropped a large number of changes. The source of each station's timestamp should be visible on the picture. Receive time can only be an auxiliary column. During a hot-standby switch, the history curve should not show a blank or a doubled point. While cellular is down, the station keeps running on local logic. What is sent after recovery is history with the station timestamp, not the incident order rewritten at the moment of recovery. Catch-up data with no station timestamp should be marked on its own. It should not be drawn on the same continuous curve as live points. A catch-up point with no station timestamp should enter the event list only, so the moment communication recovered is not drawn as a process inflection.