A supervisory control and data acquisition system, or SCADA, collects operational data from distributed equipment, presents it to operators, records events and trends, and may issue supervisory commands. It normally sits above local controllers rather than replacing them. Fast, safety-critical or availability-critical control should remain close to the process unless the applicable design and safety case explicitly support another architecture.
The practical distinction is simple:
- Monitoring shows what the system reports.
- Control requests a change.
- Verification establishes whether the intended equipment and physical process reached the required state.
Those are separate capabilities. A successful protocol response does not automatically provide all three.
The reference architecture, evidence model and commissioning method below are recommended engineering patterns, not universal standards requirements. Their exact fields, limits, timeouts and acceptance rules belong in the applicable project contract, regulation or safety case.
SCADA is a system role, not a single product or protocol
SCADA describes a supervisory function spanning field equipment, communications, servers, operator interfaces and operational procedures. NIST describes SCADA systems as collecting data from, and issuing commands to, geographically remote field stations from a central location. It also distinguishes supervisory coordination from local control loops involving sensors, controllers and actuators (NIST SP 800-82 Rev. 3).
A typical stack contains:
- Physical process: electrical loads, generators, pumps, HVAC equipment, batteries, breakers or production assets.
- Field instrumentation: meters, environmental sensors, digital inputs, relays and actuators.
- Local control: PLCs, protection devices, equipment controllers or building controllers executing deterministic logic.
- Site integration: remote terminal units, protocol gateways or edge computers that normalize data and bridge interfaces.
- Communications: serial, Ethernet, private WAN, cellular or other site-to-control-centre links.
- Supervisory applications: alarm handling, HMI screens, command workflows and operator access control.
- Historian and event records: time-series values, quality, alarms, commands and audit evidence.
- Enterprise applications: energy analytics, maintenance systems, reporting and planning tools.
This hierarchy matters during a communications failure. If a central SCADA server becomes unreachable, an appropriately designed local controller can continue protecting equipment and maintaining essential operation. The operator may lose visibility or supervisory control, but the local process should not become dependent on an unreliable wide-area round trip unless that dependency has been deliberately engineered.
SCADA, BMS and EMS have different centres of gravity
The terms overlap, so system names alone are poor procurement specifications. Define responsibilities, writable interfaces and sources of truth explicitly.
| System | Primary responsibility | Typical scope | Typical outputs | Main boundary |
|---|---|---|---|---|
| SCADA | Operational supervision and data acquisition | Industrial processes, utilities or geographically distributed assets | Live state, alarms, trends, commands and event records | Does not by itself prove physical response or energy savings |
| BMS or BAS | Building equipment automation | HVAC, lighting, access and other building services | Schedules, setpoints, equipment status and alarms | Usually focused on building systems rather than portfolio-wide energy analysis |
| EMS or EMIS | Energy analysis and performance management | Buildings, campuses or portfolios | Normalized energy data, KPIs, benchmarking, fault analysis and measurement workflows | May consume SCADA or BMS data without owning real-time control |
ASHRAE's BACnet material places building automation around applications such as HVAC, lighting, safety, security and energy management (ASHRAE BACnet). The U.S. Department of Energy defines energy management information systems more broadly as software tools that monitor, analyse and sometimes control building energy use, with integration, historian, application and supervisory-control components (DOE EMIS overview).
An energy project may therefore use all three:
- The BMS controls air-handling equipment.
- SCADA supervises electrical infrastructure and site status.
- The EMS combines meter, tariff, weather and operating data to identify or verify improvements.
Engineering judgement: keep each control loop in the system best able to meet its timing, safety, availability and maintenance requirements. Avoid giving multiple platforms competing write authority over the same point.
Protocol choice does not settle the data contract
Protocol support is only the start of interoperability. The project must still define point identity, data type, units, scaling, byte order, timestamps, quality, writable behaviour, alarm semantics and recovery after interruption.
| Protocol | Good fit | Important implementation decision |
|---|---|---|
| Modbus TCP or RTU | Simple register-level acquisition and control where the device map is stable | Control register addressing, scaling, signed values, word order and exception handling. For Modbus/TCP, MODBUS/TCP Security is a separate specification using TLS and X.509v3 certificates. It should not be assumed from basic Modbus/TCP support and does not apply to serial Modbus RTU (Modbus specifications). |
| BACnet/IP | Integration with building automation objects, schedules, alarms and trends | Specify the required objects, properties, services, command priorities and device profiles. "BACnet compatible" is not a complete point or conformance specification (ASHRAE Standard 135 resources). |
| OPC UA | Typed information models, status, timestamps, alarms, subscriptions and richer system integration | Agree namespace ownership, certificates, supported profiles and information models. OPC UA subscriptions include sequence numbers and mechanisms for detecting missed notification messages, but application recovery still needs testing (OPC UA Part 1). |
| MQTT | Decoupled publish/subscribe telemetry across constrained or intermittent links | Define topic ownership, payload schema, retained-message policy, session behaviour, expiry, ordering and deduplication. MQTT quality of service applies separately to each MQTT sender-to-receiver delivery leg, such as publisher to broker and broker to subscriber. It does not automatically cover the complete business workflow (MQTT 5.0). |
A useful point contract should carry more than a value. Recommended contract requirement: define, for every consequential point, an asset identifier, point identifier, engineering unit, source timestamp, ingestion timestamp, quality or validity state, source system and update expectation.
OPC UA illustrates why this distinction matters. Its DataValue structure separates the value, status code, source timestamp and server timestamp, and requires clients to check status severity before using a value (OPC UA Part 4, DataValue). Other protocols or payloads can represent the same concepts differently, but dropping them during translation makes stale or invalid data look authoritative.
A multi-site energy architecture should preserve local autonomy
- Field instrumentation
- Local control
- Site integration
- WAN boundary
- Supervision and history
At the field boundary, a gateway can collect wireless or wired measurements, translate protocols and buffer configured data before passing it upstream. For example, EpiSensor's public Gateway material describes routing data from wireless sensor networks to external platforms and supporting interfaces including Modbus, OPC UA, BACnet, CAN and MQTT(S) (EpiSensor Gateway).
That capability should be treated as an integration building block, not universal compatibility. The selected hardware, driver, register map, security mode and equipment combination still require qualification.
For multi-site monitoring, use a consistent semantic model above the gateways while retaining raw source identity below it. A portfolio point such as site/import_active_power should remain traceable to its physical meter, source register or object, unit conversion and acquisition time. Otherwise, a plausible chart can conceal a swapped phase, incorrect multiplier or replayed value.
Local buffering also needs an explicit replay contract. Decide how the central historian will distinguish live samples from backfilled samples, reject duplicates and expose gaps. Arrival time alone is insufficient because replayed data may arrive hours after it was measured.
Command acknowledgements need an evidence ladder
- Request authorised
- Endpoint accepted
- Controller processed
- State verified
- Outcome measured
A control workflow should expose several distinct states:
| Evidence stage | What it proves | What it does not prove |
|---|---|---|
| Authorised | The requester passed the defined access policy | The command was transmitted |
| Accepted | The supervisory application accepted the request | A downstream endpoint received it |
| Protocol endpoint acknowledged | A named protocol endpoint accepted responsibility for a message | A subscriber, controller or device acted |
| Device acknowledged | The target application or controller processed the command | The physical process changed |
| State verified | Returned telemetry matches the requested device state | The wider process outcome was achieved |
| Outcome verified | Independent measurement confirms the intended physical result | Continued performance after the observation window |
MQTT provides a precise example. For a client publishing at QoS 1, the broker is the receiving endpoint. Its PUBACK means the receiver accepted ownership of that application message. The specification explicitly allows the receiver to acknowledge before completing onward delivery. It is therefore not evidence that a subscriber received the message, that a PLC executed a command or that a contactor moved.
Consider a remote load-shed request. The supervisory application can record authorisation and dispatch. The gateway or broker can record message acceptance. The local controller can report command processing. A device-status input can show the resulting state, and a meter can confirm the expected load change. Only the later stages provide physical-response evidence.
Recommended contract requirement: define the required evidence stage for each command class, the authoritative feedback point, correlation identifier, timeout, retry policy, duplicate handling and safe response to missing confirmation. Those values are project-specific. They should not be inferred from protocol defaults.
Common SCADA failures occur at the interfaces
Many consequential SCADA failures occur at system interfaces and can produce believable but incorrect data:
- A register is read correctly but decoded with the wrong word order.
- Power is labelled as energy, or watts are presented as kilowatts.
- A gateway timestamp is replaced with historian arrival time.
- Communications fail, but the last value remains green and unqualified.
- Backfilled data creates duplicates or false event ordering.
- Two supervisory systems overwrite the same setpoint.
- An MQTT acknowledgement is presented as equipment confirmation.
- A WAN-dependent command path bypasses appropriate local interlocks.
- An HMI is commissioned visually without comparison to the source device.
- Alarm shelving, operator actions or configuration changes are not auditable.
The corrective pattern is traceability: physical point to controller, controller to gateway, gateway to SCADA, and SCADA to historian or analytics. Each transformation should have an owner and a testable contract.
Commission against evidence, not screen appearance
The following is a recommended commissioning pattern, not a universal minimum. Exact test coverage and acceptance limits belong in the project specification and safety case.
- Confirm identity. Match the physical asset, device address, register or object, SCADA tag and historian series.
- Inject known states. Use safe, authorised changes or test signals to exercise normal, boundary and invalid conditions.
- Verify units and transformations. Compare source values with gateway output, SCADA display and stored history.
- Verify time and quality. Check source time, ingestion time, clock behaviour, stale-state handling and bad-quality propagation.
- Interrupt communications. Test field-link and WAN loss separately. Record local behaviour, alarm timing, buffering and recovery.
- Test replay. Confirm that backfilled samples preserve measurement time and do not create duplicates.
- Exercise commands safely. Record authorisation, dispatch, protocol response, device feedback and independent process evidence.
- Test security boundaries. Confirm identities, certificates or credentials, least-privilege access, permitted flows and audit records.
- Prove restart and recovery. Restart relevant components under controlled conditions and verify configuration, subscriptions and data continuity.
- Retain evidence. Store test inputs, timestamps, expected outcomes, observed outcomes, software or configuration versions and approved exceptions.
For cybersecurity, NIST recommends characterising and segmenting IT and OT devices, mapping required data flows and permitting only authorised communications between segments. It also recommends authenticated, encrypted communications between geographically distributed sites (NIST SP 800-82 Rev. 3). These are recommendations unless made binding by an applicable regulation, standard, contract or organisational policy.
The final acceptance question is not "Does the dashboard have data?" It is: can the operator trace each consequential value and command to authoritative evidence, detect when that evidence is stale or incomplete, and predict what the system will do when a component or communications path fails?