SCADA System: What is it? (Supervisory Control and Data Acquisition)

What is SCADA?

SCADA stands for Supervisory Control and Data Acquisition. The term describes a control system architecture that gathers data from field sites, presents it through human-machine interfaces (HMIs), records events and measurements, manages alarms and sends authorised supervisory commands.

SCADA servers communicate with field controllers such as programmable logic controllers (PLCs), remote terminal units (RTUs) and equipment that implements PID controllers. Those local devices interface with sensors and actuators and normally continue their configured control if the supervisory connection is lost.

In control systems engineering, SCADA software collects time-stamped operational data, displays current conditions and trends, records alarms and events and stores selected history. “Real time” here means within the latency required by the application, not zero delay.

Operators use the HMI to supervise remote or distributed assets and, where authorised, issue commands such as changing a setpoint or starting equipment. Interlocks and automatic protection must remain in the local controller or a separate safety system rather than depend on an HMI session.

Utilities and industrial sites use SCADA when operators need a central view of equipment spread across a plant or a wide geographic area. The architecture combines telemetry, supervisory commands, alarms, history and operator displays.

SCADA data can support operating decisions and maintenance. It can also supply reports. Its value depends on correct tags, reliable timestamps, validated alarm logic, suitable retention and protected access.

Remote operation is possible only through an engineered and authorised connection. It should use strong authentication, least privilege, monitored access paths and network separation; a SCADA server should never be exposed directly to the public internet.

Pipeline operators use SCADA to collect pressure, flow, valve-state and equipment data from distributed sites. The system can help an operator detect abnormal conditions and coordinate a response, but telemetry alone does not prove that a leak has occurred.

Leak detection may compare measured flow, pressure and inventory against an engineered model. If configured criteria are met, SCADA displays the condition and generates an alarm for a defined operator action. Instrument accuracy, communications loss and process transients can affect the result, so operators need procedures and independent protective measures.

A SCADA installation connects field instruments through PLCs or RTUs. It also includes communications equipment, control servers, HMI stations, engineering workstations and often a historian. Redundant servers and communication paths may be used where the availability requirement justifies them.

A historian or database stores selected time-series data, alarms and events for trends, reports and audits. Retention and backups are system-design choices, not simply a local hard-disk file. Structured Text programming normally runs in a PLC or compatible controller; SCADA software uses its own configuration, scripting and application tools.

SCADA is used in energy, food and beverage, oil and gas, electric power, water, wastewater, transport and manufacturing systems.

SCADA History

Before computer-based supervisory systems, operators used local instruments, annunciators, control panels, pushbuttons, relays and timers. Telemetry later brought measurements and commands between remote stations and a central control room.

Relay systems can implement substantial automation , but large panels are costly to change and provide limited central data handling. Digital computers and programmable controllers made more flexible supervision, logging and communication practical.

Industrial computer control developed during the 1950s and 1960s, while telemetry itself predates digital SCADA. The later combination of computers, communications and field controllers produced recognisable SCADA architectures.

The term SCADA came into use around the early 1970s as computer-based supervisory control and data acquisition systems became established.

Later systems moved from central mainframes to distributed and networked architectures well before the early 2000s. The technology did not make every process fully automatic; local controllers, operators and independent safety functions still have separate roles.

Current systems can support multiple control centres and web clients. Some also provide managed remote access. The required availability and security controls depend on the consequences of delayed, lost or unauthorised communication.

An operator does not need to be a software developer, but does need training in the process, HMI, alarm response and abnormal operating procedures. Engineers and administrators need additional competence for configuration, cybersecurity, backup and change control.

SCADA Basics

Objectives of SCADA

1. Monitor: Display selected process states and measurements at their configured update rates.
2. Measure: Receive measured values from field instruments through controllers or data-acquisition equipment.
3. Data Acquisition: Acquire time-stamped data from remote terminal units (RTUs), PLCs, intelligent devices and data loggers.
4. Data Communication: Exchange commands, measurements, quality flags, alarms and diagnostics between control centres and field sites.
5. Controlling: Send authorised supervisory commands while local controllers enforce interlocks and fast control.
6. Automation: Support schedules, calculations, reports and coordinated actions without replacing independent safety protection.

A SCADA application normally runs on one or more control servers, with HMI and engineering clients connected over an operational-technology network. A complete implementation can also include historians, time sources, security servers and backup control facilities. The three broad parts below are:

• Master terminal unit (MTU) or SCADA control server
• Remote terminal unit (RTU), PLC or intelligent field device
• Communication network, including its protocols and network topology.

Master Terminal Unit (MTU)

The MTU is the central SCADA control server, not necessarily a PLC. It communicates with RTUs and PLCs, processes and stores their data, serves HMI displays, manages alarms and exchanges approved data with other operational systems.

Remote Terminal Unit (RTU)

An RTU is installed at a field site and interfaces with sensors, actuators or intelligent electronic devices. It acquires values and status, performs configured local logic and sends selected data to the control centre. Capabilities vary widely by model.

An RTU may buffer time-stamped data during a communication outage and forward it after service returns. RTUs and PLCs are overlapping controller categories, not devices that necessarily contain one another. Both can perform local control without continuous MTU commands when designed to do so.

Communication Network

The communication network carries telemetry and commands between control centres and field sites. Links may use licensed or unlicensed radio, cellular, microwave, satellite, copper or fibre optic cables. Engineers must account for bandwidth, latency, loss, error detection, time synchronisation, redundancy and cybersecurity.

Functions of SCADA Systems

A SCADA system can provide these functions:

• Acquire and display operational data with quality and timestamp information
• Let authorised operators interact with field controllers through an HMI
• Record alarms, events, operator actions and selected measurements
• Issue supervisory commands and setpoint changes under controlled permissions
• Store history and produce trends, reports and audit records

SCADA Software

SCADA selection should begin with operational requirements, consequence of failure, lifecycle support and the site’s automation and cybersecurity architecture. Review at least these areas:

• The lifespan of the software: Check the vendor’s support policy, upgrade path, operating-system compatibility, security updates, licence terms and migration tools against the site’s planned service life.
• Request for Information: Ask suppliers to document architecture, capacity, protocols, availability, cybersecurity controls, support, training, backup, recovery and total lifecycle cost.
• Historian Software: Confirm timestamp sources, data quality, compression, retention, query performance, replication, backup and restore. A historian must preserve context as well as values.
• SCADA technology: Select supported protocols and platforms that meet current requirements and have a maintainable security path. Do not adopt a feature only because it is new, or retain an obsolete component only because it still runs.
• Alarm Supervision and Management: Evaluate alarm rationalisation, priority, shelving, suppression, acknowledgement, audit and performance reporting against the site’s alarm philosophy. Alarm management is a lifecycle, not a split between “system-defined” and “user-defined” alarms.

The following product names illustrate established SCADA and HMI platforms. Product ownership, naming, versions and support change, so verify them with current vendor documentation before selection.

AVEVA Plant SCADA, formerly Citect SCADA

Citect SCADA is now sold as AVEVA Plant SCADA, so the linked legacy Schneider Electric. page must not be used as a current version reference. AVEVA describes Plant SCADA as plant visualisation and supervisory-control software. Check the current release, compatibility matrix and support lifecycle directly with AVEVA.

AVEVA InTouch HMI, formerly Wonderware

Wonderware InTouch is now AVEVA InTouch HMI. This established HMI product predates the recent rebrand. The linked Wonderware page reflects the former brand; current AVEVA documentation should govern product and licensing decisions.

AVEVA InTouch provides operator visualisation and can be deployed alone or with other AVEVA operations products. Connectivity depends on the selected communication drivers, protocols and licences. Confirm compatibility with every controller and required redundancy mode rather than assuming universal PLC support.

Experion SCADA – Honeywell

Honeywell offers Experion SCADA and HMI platforms for remote automation, including integration with ControlEdge controllers and RTUs. C200 and C300 are controller families, not PLC software platforms. Architecture and supported interfaces depend on the selected Experion product and release.

Honeywell’s current material lists interfaces for Honeywell and selected third-party controllers. Verify each protocol, driver version, data model and support arrangement for the intended devices.

iFIX – General Electric

IFIX, styled iFIX, is now part of GE Vernova’s Proficy HMI/SCADA portfolio. It provides operator visualisation and alarming, with supervisory-control functions. Screen technology and web-client capabilities vary by version, so the current technical documentation must support any HTML5 claim.

iFIX can connect to third-party controllers through supported drivers and gateways; it does not require a GE-branded PLC. Confirm the exact driver, protocol security, tag capacity and redundancy support for each planned connection.

Ignition – Inductive Automation

Ignition is an industrial application platform from Inductive Automation for SCADA, HMI, IIoT and related applications. “Industry 4.0” is not one compliance standard, so suitability must be judged against the required modules, protocols, security controls and lifecycle.

Ignition 8.3 was released in September 2025 as a long-term-support line. Controller connectivity depends on built-in or third-party modules, so verify each device and protocol. Use vendor release notes for the current maintenance release rather than fixing a patch number in a design specification.

SIMATIC WinCC – Siemens

Siemens offers several WinCC products, including current SIMATIC WinCC V8 releases. Product names that share “WinCC” can target different architectures, so verify the exact edition, supported PLCs, client model, redundancy and security certification.

Vendor size or age does not establish fitness for a project. Base the choice on verified requirements, lifecycle support, local competence, integration tests, cybersecurity assessment and recovery testing.

SCADA Applications

SCADA architecture can scale from one plant to many remote sites. Reliability and flexibility depend on the server, network, field-control, power, backup and recovery design rather than on the SCADA label alone.

Applications include geographically distributed utilities and central supervision of industrial plants. SCADA supports operations; it does not replace process protection, safety systems, physical security or trained operators.

Common sectors include chemicals, gas pipelines, water and wastewater, communications infrastructure and power systems.

Electric Power Generation, Transmission and Distribution

Electrical utilities use SCADA to receive measured current, line voltage and equipment status. Authorised operators may supervise circuit breaker operations involving equipment such as a vacuum circuit breaker or SF6 circuit breaker. Protection relays and switching procedures remain required.

Manufacturing Units

Manufacturers use SCADA to supervise production equipment, utilities, process conditions, alarms and quality-related data. Fast machine sequences normally run in local controllers rather than on the SCADA server.

Mass transit and Railway Traction

Transit systems use SCADA to supervise traction power, stations, tunnels and supporting utilities. Signalling and crossing protection are safety-critical systems with their own certified control requirements; a general SCADA layer must not be described as their sole controller.

Water, Waste Water Utilities and Sewage

Water and wastewater utilities use SCADA to monitor flow, tank level, water-quality measurements, pressure, pumps and valves across treatment and distribution assets.

Buildings, Facilities and Environments

Facilities use supervisory systems to monitor and control HVAC, cooling, lighting, energy and environmental conditions. Building automation systems overlap with SCADA but may use different products and standards.

Water Security: The Role of the SCADA System

Water utilities must manage unauthorised access, loss of view, false data and unsafe commands as operational risks. The linked 2018 cyber risk paper is background material; current design should follow applicable government guidance and a documented OT risk assessment.

A water SCADA communication network can extend across the distribution system. Control-room workstations present an authorised view of the process. Network zones, firewalls, managed remote access and recovery plans must protect the control centre and field links.

Within a plant, PLCs may control dosing, filters and pumps over an operational local area network. RTUs often serve remote pump stations, storage tanks and valve sites. The exact split depends on local autonomy, communications, environmental conditions and maintenance needs.

An RTU can communicate over a wide-area radio network as shown below. SCADA alarms may help coordinate operations and physical-security response, but connection to surveillance does not establish adequate security or remove the need for site-specific patrols and physical controls.

Security-device status can be continuous. Cameras and sensors still cannot guarantee surveillance of every place. Connecting video, motion, access-control or card-reader systems to an OT network requires an architecture and risk review. Alarm floods require rationalisation, prioritisation, suppression rules, testing and ongoing performance monitoring.

Thermal Power Plants

thermal power plants use automated monitoring and control, with operators responsible for supervision and defined interventions. Alarms should identify an abnormal condition that requires a timely response, with the cause, consequence and action documented.

SCADA and plant-control systems give power plants consistent time-stamped measurements and event records. They support inspection and diagnosis but do not remove sensor errors, software faults or operator mistakes.

Automation can improve repeatability and give operators better process visibility. It does not by itself increase thermal efficiency or prevent human error. PLCs, distributed control systems, protection and SCADA each have defined roles in supervising and controlling the process.

Forestry, Pulp and Paper Industry

Pulp and paper sites use supervisory systems for process visibility, energy monitoring and coordination across production areas. Drives, protection and safety functions use dedicated equipment that can exchange status with SCADA.

SCADA can gather data from the wood yard, chippers, digesters, evaporators, refiners, stock preparation, dryers, presses and paper machines. Local PLC or distributed-control logic performs the direct control, while SCADA provides the wider operating view.

Difference Between PLC and SCADA

A PLC acts as a field controller. The wider SCADA architecture communicates with PLCs, RTUs and intelligent devices. Each layer has its own timing, availability and operator-interface role.

A programmable logic controller reads local or networked inputs, executes scheduled control logic and updates outputs. It is normally installed in an industrial enclosure and selected for the required environment, I/O, response time, communications and safety functions.

A SCADA system operates at the supervisory layer and may acquire data through PLCs, RTUs, protection relays or other field devices. A PLC can work without SCADA, and a SCADA system need not contain a PLC. Correctly designed local control continues through a loss of supervisory communication.

SCADA historians can retain time-series values, alarms, events and operator actions for analysis or audit. PLCs may buffer or log data, but central long-term retention is usually assigned to a historian with defined timestamps, quality, backup and retention rules.

Supervisory commands are a normal SCADA function, not inherently an unwanted condition. Local controllers should normally handle fast loops, interlocks and defined communication failures. Operators remain responsible for permitted mode changes, setpoints, starts, stops and abnormal situations described by operating procedures.

The HMI sends high-level requests; the PLC validates them against local permissives and interlocks. A trip condition must use an engineering limit with correct units and response time. The original example of 100 metres per second is not a generally valid pump-flow threshold.

SCADA is primarily the monitoring, data-acquisition, alarm, history and authorised supervisory-control layer during routine and abnormal operation. It can communicate with PLCs, but those controllers are field components connected to the architecture rather than a mandatory part of every SCADA definition.

A PLC reads inputs, executes its program and writes outputs at configured task and I/O update rates. When connected to SCADA, it exchanges values, quality, status and permitted commands over a protocol with its own latency and failure modes. The PLC must reject commands that violate local interlocks or access rules.