What is SCADA? How It Works, Components & Architecture

SCADA stands for Supervisory Control And Data Acquisition. It is a system that lets you watch and control industrial processes from one central place. It collects data from equipment in the field, shows it to operators on screens, raises alarms when something goes wrong, and sends control commands back to equipment.

SCADA is common in:

• Power grids
• Water and wastewater treatment
• Oil and gas pipelines
• Manufacturing plants
• Mining operations
• Building services

It is used when assets are spread across a wide area, or when you need one control room to see the whole operation.

In simple terms, SCADA does five things:

1. Data acquisition — Gets measurements from field devices.
2. Supervisory control — Lets operators supervise and send high-level commands.
3. Visualization — Shows the process clearly on screens.
4. Alarm handling — Tells people fast when something is wrong.
5. History and reporting — Stores data and turns it into trends and reports.

SCADA vs PLC vs DCS

These three get mixed up constantly, including in tenders and job titles. They’re not competitors — they’re different layers and different philosophies, and most real operations run at least two of them at once.

PLC — the one that controls. A PLC runs the control logic, close to the process, in real time. Tank level low → start the pump. Level high → stop it. Interlock violated → refuse the command. It scans its logic every few milliseconds, and it does not need a network, a server, or an operator to do its job. That independence is the design: a PLC keeps its process safe and running even when everything above it is down.

DCS — the one that orchestrates. A DCS coordinates a whole continuous process on one site — a refinery, a generation unit, a chemical train. Its controllers are distributed across the plant but engineered as one system: one database, one alarm philosophy, one set of operator stations, with control loops spread across controllers that depend on each other. That tight coupling is the strength and the weakness. It holds a complex process at setpoint beautifully, and it assumes the plant network underneath it stays healthy.

SCADA — the one that supervises. SCADA watches many mostly-independent things, often spread over huge distances, and gives operators one picture plus supervisory commands. The fast loops stay in the field, in PLCs and RTUs. Lose the link to a site and the site keeps running on its local logic — SCADA loses visibility, not control, because it never had the low-level control to begin with. That tolerance for broken communications is the core design difference from a DCS.

	PLC	DCS	SCADA
Role	Runs the control logic	Coordinates a whole process	Supervises and monitors
Scope	One machine or loop	One plant or site	Many sites, wide areas
Control loops	Inside the PLC	In distributed controllers	In the field (PLC/RTU), not the server
Speed	Milliseconds	Fast, tightly coupled	Seconds; polling-based
If comms fail	Keeps running	Degrades — loops depend on it	Field sites keep running alone
Typical home	Factory lines, machines	Refineries, generation, chemicals	Grids, pipelines, water networks

How they work together — one real example. A power station runs its boilers and turbines on a DCS: thousands of tightly coupled loops, one plant, one system. Inside the switchyard, PLCs and IEDs handle local sequences and protection. The transmission grid that the station feeds is supervised by the utility’s SCADA, which talks to the station over a gateway. Three systems, three philosophies, one megawatt-hour — and the boundaries between them are exactly where the interface lists, the protocols, and the security zones get decided.

The labels blur at the edges. A modern “SCADA” package on a fast plant network can behave like a small DCS; a DCS stretched across two sites starts to look like SCADA. Classify by the design intent — who owns the loops, and what happens when the network breaks — not by the logo on the box.

This is the short version. For the full taxonomy — how SCADA, DCS, and PLC-based systems fit inside ICS and OT, and why the terms get mixed up — see SCADA and ICS: The Difference and How They Fit Together.

Where Is SCADA Used?

Anywhere assets are spread out and one room needs to see them all. The sectors below account for most installations — and each one bends SCADA in its own direction.

Electric Power

The classic SCADA sector, and the most layered. Inside the substation: breaker and disconnector status, transformer temperatures and tap positions, feeder currents and voltages, protection relay events. The substation runs its own fast world — IEC 61850 between IEDs, protection acting in milliseconds without asking anyone — while the control center talks to the substation gateway over IEC 60870-5-104 or DNP3. Between control centers (utility to utility, TSO to DSO), ICCP/TASE.2 exchanges the operational picture. The point most non-power people miss: SCADA in a grid supervises but never protects. When a fault hits, the relays have already tripped the breaker before the control room screen even updates — SCADA’s job is telling the operator what just happened and helping restore.

Renewable Generation

A solar or wind plant is hundreds of small generators pretending to be one. SCADA aggregates them: inverter and turbine status and power, string or turbine-level alarms, weather stations, meteo-corrected performance ratios. Inverters typically talk Modbus TCP (often with the SunSpec register maps), which means server-side timestamps and heavy polling — a real design constraint at plant scale. Above the monitoring sits the power plant controller, holding the plant’s setpoints for active power, reactive power, and voltage against the grid code. On islanded and hybrid plants — generators plus PV — SCADA also carries the load-sharing picture: what the diesels do, what the PV contributes, and what gets shed when the margin runs out.

Water and Wastewater

The wide-area problem in its purest form: reservoirs, tanks, boreholes, lift stations, and dosing points scattered across a region, most of them unmanned. SCADA watches levels, flows, pump status, and chlorine residuals, and alarms on high levels, pump failures, intrusions, and power loss. Communications are the defining constraint — licensed radio and cellular dominate, so report-by-exception protocols earn their keep here. The other constant is regulation: water quality values and overflow events feed compliance reports, which makes the historian a legal record, not just an operations tool.

Oil and Gas Pipelines

Pressure, flow, temperature, and valve positions along the line; compressor and pump stations as the major sites. Distances are extreme and bandwidth is often thin — satellite links for remote block valves are normal — so the protocol’s event handling decides what’s feasible. The application that defines the sector is leak detection: the SCADA data feeds computational models comparing what went in against what came out, and the quality and timing of that data decides whether a leak is found in minutes or in headlines. Remote valve commands here carry the highest stakes of any SCADA action, which is why command confirmation and SBO discipline came from sectors like this one.

Manufacturing and Plant Utilities

Inside a factory, the production lines usually belong to PLCs or a DCS — but the utilities that keep them alive (boilers, compressors, chillers, water treatment, power distribution) are a natural SCADA layer. One system above many PLC-controlled packages, giving maintenance and energy teams a single picture. Energy monitoring has pushed hard here: sub-metering electricity, steam, air, and gas per line turns the historian into the data source for every efficiency project the plant runs.

Mining

Remote by definition, and increasingly operated from cities hundreds of kilometers away. SCADA covers dewatering pumps, ventilation fans (a safety-critical watch in underground mines), conveyors, crushers, and power distribution across the site. The trend that defines the sector is the remote operations center: one team supervising several mines through SCADA layers stacked on top of each site’s local systems — the same architecture pattern as a utility control center, applied to rock.

What Does a SCADA System Do?

1. Real-Time Monitoring

Shows live values — pressure, flow, speed, temperature, breaker status — with the update behavior defined per point, not per system. Fast-changing analogs may refresh every second; slow tank levels every minute; digital status points typically report only when they change. Under the surface, two mechanisms feed the screens: polling, where the server asks each device on a cycle, and report by exception, where the device speaks up when something changes (DNP3 and IEC 104 combine both — periodic integrity polls to resync the full picture, change events in between). Two details separate good monitoring from decoration: values are converted to engineering units with correct scaling, and every value carries its quality flag on screen. A number without units and quality is trivia, not information.

2. Operator Control (Supervisory Control)

Operators start and stop equipment, open and close valves, and change setpoints — with permissions checked per role. The word supervisory is the design boundary: the operator’s command adjusts what the local logic does; it doesn’t replace it. The PLC or RTU still enforces its permissives and interlocks, so a command that would violate them is rejected in the field, not trusted from the screen. Two more field rules live here. Control ownership: a local/remote selector at the site decides whether the control room may command the equipment at all — a technician working on a breaker puts it in local, and SCADA commands are locked out. And confirmation: every command should produce observed feedback (the new status) or a command-failure alarm. Critical objects add the select-before-operate ceremony described in function 7.

3. Alarm Management

Watches every configured point against its limits — high/low analog thresholds with deadbands so a noisy signal doesn’t chatter, and state-change alarms on digital points — then routes each alarm through priorities, categories, acknowledgement, and shelving. The alarm list is the operator’s to-do list, which is why its discipline matters more than its features: every alarm must demand an action, floods must be suppressed by design, and history must be kept for review. This is governed by its own standard, IEC 62682, and covered in depth in the Alarm Management section below.

4. Data Historian (Trends and Reports)

Stores time-series data built for one question: what was this value at that moment, and how did it get there? Points are stored periodically or on change beyond a deadband, at a resolution chosen per point — protection-adjacent signals need more than a boiler room temperature. On top of the raw storage sit trends for live troubleshooting (“did the pressure drop before or after the pump tripped?”), comparisons across runs or across sites, and scheduled reports: daily flow totals, energy use, regulatory submissions. Retention is a design decision — operational trending may need months at full resolution, compliance may need years. The time-stamping and quality rules that make any of this trustworthy are covered in the Historian Basics section below.

5. Event Logging and Audit Trails

Records what happened and who did it: every operator command with user and timestamp, every acknowledgement, every setpoint change, every login, and every configuration change on the system. Events differ from alarms — an event is a fact for the record, an alarm is a demand for action — and a healthy system logs far more events than it raises alarms. The log earns its storage twice. In troubleshooting, it answers “what changed right before this started?” — which is the correct first question in most incidents. In compliance and security, it’s the audit trail: regulators, and IEC 62443’s accountability requirement, both expect operator actions to be traceable to a named account. That only works if shared logins don’t exist — which is why they shouldn’t.

6. Remote Access (Carefully Controlled)

Lets engineers support the system without driving to it, and lets a backup control room operate when the main one can’t. It is also the most attacked door into OT, because it bypasses every physical control the site has. The pattern that works: no direct path from outside to any SCADA component — remote users land on a jump host in the DMZ, over VPN, with multi-factor authentication, and only from there reach the systems their role allows. Sessions are time-limited and, for third parties, recorded and enabled only for the duration of the job — a vendor’s standing 24/7 tunnel is an incident waiting for a date. Engineering access deserves the strictest treatment of all: it’s the path that can change logic, not just look at it.

7. Command Handling: Select-Before-Operate

Sending a command to a breaker or valve is the most dangerous thing SCADA does, so the protocols wrap it in ceremony. The classic pattern is select-before-operate (SBO): the operator first selects the object, the device confirms the selection, and only then does the execute command act — within a timeout. Two steps, so a single misclick or a corrupted frame can’t operate a breaker. IEC 60870-5 builds select/execute into its command types; DNP3 does the same with its select/operate model (direct-operate exists for lower-risk points). On top of the protocol, good systems add command feedback monitoring: if the breaker doesn’t report its new state within a set time, the operator gets a command-failure alarm instead of silence.

8. Sequence of Events (SOE)

When a fault trips half a substation, everything happens within a few hundred milliseconds — and the post-mortem question is always “what operated first?” SOE recording answers it: digital status changes captured at the device with millisecond-class timestamps, buffered, and reported to SCADA with their original time tags. This is why device-side timestamps and tight time sync matter: SOE from ten devices is only a sequence if their clocks agree. In power systems, SOE from relays and RTUs is the difference between reconstructing an incident and guessing about it.

9. Data Quality and Communication Status

Every value on an operator screen is a claim, and SCADA has to say how much to trust it. Quality flags do that job: valid, invalid, stale (not updated in time), blocked, or manually substituted. The protocols carry them — IEC 60870-5 quality descriptors, DNP3 flags — and the HMI must show them, typically by greying out or crosshatching untrusted values. The rule for operators is absolute: a stale “closed” is not a closed. Alongside per-point quality, the system tracks communication status per site and per channel, so a dead RTU shows as a comms failure on that station — not as a screen full of frozen values quietly pretending to be live.

Core Building Blocks of a SCADA System

A SCADA system is not one box. It is a stack of parts.

A. Field Instruments and Actuators (Level 0)

These are the physical devices that touch the process:

• Sensors: Pressure transmitters, flow meters, temperature probes.
• Switches: Limit switches, float switches.
• Actuators: Valves, motors, pumps, breakers.

They produce raw signals — analog (4–20 mA, 0–10 V), digital (on/off), or smart digital (HART, Profibus, IO-Link).

B. Controllers: PLCs and RTUs (Level 1)

These devices collect signals from instruments and run logic.

• PLC: Common in plants and factories. Good for fast logic and automation.
• RTU (Remote Terminal Unit): Common at remote sites. Built for harsh environments and low power. Often has strong communication options.

Their key jobs are to read inputs, run local control logic, write outputs, and send data upstream to SCADA. Local logic matters — it keeps the process safe if communications fail.

C. Communications Network

SCADA needs a data path between remote sites and the control center. Common options include fiber or copper Ethernet (in-plant), licensed or unlicensed radio, cellular (4G/5G/LTE), microwave links, satellite (for remote areas), and serial links (still found in older sites).

The important qualities of the network are latency, bandwidth, reliability, security, and coverage.

D. SCADA Servers (Level 2)

These run the SCADA software and handle data collection from PLCs and RTUs, alarm processing, the tag database, user login and permissions, command routing, and interfaces to historians and other systems.

Servers are often split into roles: I/O or communication servers, alarm servers, application servers, and redundant pairs (primary and standby).

E. HMI / Operator Workstations

HMI stands for Human-Machine Interface. This is what operators see and work with — mimic diagrams, trends, alarm lists, control popups, and maintenance pages.

HMI quality matters a lot. A poor HMI increases the chance of operator mistakes.

F. Historian and Reporting

A historian stores time-series data in a way that is efficient to query. It supports process improvement, incident review, compliance reporting, and KPI dashboards. Historians can be separate products or built into the SCADA platform.

G. Engineering Workstations

Used for system configuration, tag management, graphics editing, and PLC programming. Engineering access needs strong controls because it is a high-risk path into the system.

How Does SCADA Work?

Here is a typical cycle:

1. A sensor measures a value in the field.
2. A PLC or RTU reads the sensor.
3. The PLC/RTU sends the value to the SCADA server through a protocol.
4. SCADA updates the operator screen and checks alarm limits.
5. If a limit is exceeded, SCADA raises an alarm.
6. An operator acknowledges the alarm and may send a command.
7. The command goes back to the PLC/RTU.
8. The PLC/RTU carries out the action and reports the new status.
9. The historian stores the data for later trending and reports.

SCADA Architectures

Architecture is mostly a question of geography and consequence: how far apart are the assets, and what does it cost when part of the system goes dark? Four patterns cover nearly everything in the field.

1. Single-Site SCADA

One control room, one plant network, many PLCs — the “factory SCADA” pattern. Communications are the easy part: everything sits on Ethernet with bandwidth to spare, so straightforward polling works and update rates can be generous. The design work moves elsewhere: segmenting the network so the SCADA layer isn’t flat with the office LAN, structuring the tag database so it survives ten years of plant changes, and resisting the assumption that “it’s all local” means security can wait. A single site is where flat networks and default passwords survive longest, because nothing forces the discipline that a WAN forces. Where it fits: plants, utilities within one fence line. The catch: simplicity invites shortcuts that cost more later than a proper design would have cost up front.

2. Multi-Site / Wide-Area SCADA

The classic pattern: a central control center supervising remote sites over links you don’t fully control — radio, cellular, satellite, leased lines. The whole design bends around communication failure, because it will happen. Field devices run autonomously on local logic; protocols report by exception to spare the bandwidth; RTUs buffer time-stamped events during outages and deliver them when the link returns, so the historian has no holes even when the screens did. Site and channel status get monitored as first-class points — a dead link must look like a dead link, not like a healthy site with frozen values. Larger systems add a geographically separate backup control center on the WAN, taking over when the primary can’t. Where it fits: grids, pipelines, water networks — anything measured in kilometers. The catch: every design decision, from protocol choice to alarm philosophy, has to assume the link is down when it matters most.

3. Redundant SCADA

Redundancy is a property you apply layer by layer, not a box you buy. Servers: a hot-standby pair, the standby mirroring the primary’s state and taking over on failure — or active/active where the platform supports it. Networks: dual LANs, and in substation-grade designs, redundancy protocols like PRP and HSR that make a network failure invisible with zero recovery time. Communications: two independent paths to critical sites (radio plus cellular is a common pair). Historians and gateways: doubled where their loss would blind operations. Two field rules govern all of it. First, decide per layer whether failover must be bumpless or a few seconds of gap is acceptable — the cost difference is large. Second, test the failover on schedule. A redundant pair that has never been switched over is a single system with double the electricity bill; the standby that “was always ready” and wasn’t is a classic finding in outage reviews. Where it fits: wherever the uptime target says so — which the requirements phase defined in numbers, not adjectives. The catch: complexity. Every redundant element is one more thing to configure, patch, and test.

4. Hybrid SCADA + IIoT / Cloud

The fourth-generation pattern layered on top of the others, not replacing them. SCADA keeps day-to-day operations exactly as before; edge gateways publish selected data outbound — typically MQTT — to cloud platforms for analytics, fleet dashboards, and long-term storage. Done right, the OT side only ever initiates outbound connections and the cloud never commands anything, which keeps the integration rules from the section below intact. The value is real: fleet-wide comparison across sites, machine-learning on years of historian data, dashboards for people who will never enter a control room. So are the new questions: who owns the data, what happens operationally when the cloud is unreachable (correct answer: nothing), and how the enlarged attack surface is governed. Where it fits: organizations with many sites and an appetite for analytics. The catch: the moment anyone proposes closing the loop — cloud commanding the field — the architecture conversation becomes a security conversation, and it should.

Most real systems combine these. A national grid operator runs a wide-area, fully redundant core with a hybrid cloud layer for analytics — three patterns, one system, each applied where its trade-off makes sense.

The Four Generations of SCADA

SCADA didn’t start as the networked system you see today. It grew through four stages, and knowing them explains a lot of what you’ll find in older sites.

First generation — monolithic (1960s–80s). One mainframe, one vendor, everything proprietary. No connection to any other system. Redundancy meant a second identical mainframe sitting idle. Security wasn’t a design topic because there was nothing to connect to.

Second generation — distributed (1980s–90s). The work split across multiple stations on a LAN — one machine for communications, one for the HMI, one for the database. Faster and cheaper than a mainframe, but the protocols were still proprietary, so you were locked to one vendor.

Third generation — networked (1990s–2000s). Open standards arrived: Ethernet, TCP/IP, and standard protocols like Modbus TCP, DNP3, and IEC 60870-5-104. Systems could span WANs and talk to equipment from different vendors. This is also the moment SCADA inherited every vulnerability of open networking — the reason SCADA security exists as a field.

Fourth generation — IoT and cloud (2010s–now). Edge gateways, MQTT, cloud historians, and web-based HMIs. Data leaves the plant for analytics and dashboards. Day-to-day control stays local, but the attack surface and the governance questions are bigger than ever.

Most real installations are a mix. It’s normal to find a third-generation core with fourth-generation edges bolted on — and the occasional second-generation box nobody dares to touch.

Benefits and Limits of SCADA

What SCADA gives you:

• One picture of the whole operation. An operator in one room sees hundreds of sites. Without SCADA, that visibility means trucks and phone calls.
• Faster response. Alarms reach an operator in seconds instead of waiting for the next site visit or a customer complaint.
• Fewer site visits. Remote monitoring and remote commands cut travel to unmanned sites — often the largest single saving in wide-area operations.
• Data you can act on. The historian turns operations into trends: pump efficiency drifting down, a valve cycling too often, energy use creeping up.
• An audit trail. Every operator action and alarm is logged. That matters for troubleshooting and for compliance.

What SCADA does not give you:

• It is not the safety system. Safety functions stay in the PLC or SIS. If a design relies on a SCADA screen to keep people safe, the design is wrong.
• It is not automatic control. The fast loops run in the field. SCADA supervises them; kill the SCADA server and a well-designed process keeps running.
• It is only as good as its alarms. A flooded alarm list trains operators to ignore it. The system then hides problems instead of revealing them.
• It is a target. Central visibility means central attack surface. The cybersecurity section below is part of the design, not an add-on.

Common SCADA Protocols

Protocols define how the SCADA server talks to PLCs, RTUs, and gateways. The choice matters more than most people think: it decides how the system handles events, time stamps, slow links, and security. Here is what each one is actually good at — and where it falls short.

Modbus (RTU / TCP). The simplest and the most widely supported protocol in industry. Request-response: the client asks, the device answers. That simplicity is also the limit. There are no events, no time stamps, and no security in the base protocol — the server must poll everything, all the time. Fine for meters and PLCs on a plant network. Weak over slow wide-area links, because re-reading unchanged values burns the bandwidth you don’t have.

DNP3. Built for utilities and it shows. The outstation stores events locally with time stamps and reports by exception — only what changed, when it changed. It can also send unsolicited responses without waiting to be polled. That makes it efficient over slow or unreliable links, which is exactly the SCADA problem. Secure Authentication (SAv5) adds message-level security. Dominant in North American power and water.

IEC 60870-5-101 / 104. The international counterpart to DNP3, dominant in power systems outside North America. 101 runs over serial links; 104 carries the same application layer over TCP/IP. Same core strengths: time-tagged events, report by exception, and a cause-of-transmission model that tells the master why each message arrived — spontaneous change, interrogation reply, or command confirmation.

IEC 61850. Not a classic SCADA polling protocol — a substation automation framework. MMS handles the client/server SCADA-type traffic. GOOSE carries peer-to-peer trip and interlock signals between relays in a few milliseconds. Sampled Values streams digitized measurements from merging units. It lives inside the substation; the control center usually still talks IEC 104 or DNP3 to the substation gateway.

OPC UA. An integration layer more than a field protocol. It models data instead of just moving registers, runs on any platform, and has security built in from the start — certificates, signing, encryption. This is the standard bridge between SCADA and the MES/enterprise world, and it replaces the old Windows-bound OPC DA wherever systems get modernized.

MQTT / Sparkplug B. Publish-subscribe with tiny overhead. Devices report by exception to a broker; subscribers get the data with no polling at all. Built for exactly the case of many remote sites on cellular or satellite. Raw MQTT defines no payload format and no state awareness — Sparkplug B adds both (topic structure, birth and death certificates), which is what makes it usable for SCADA rather than just telemetry. The protocol of choice in fourth-generation designs.

Which protocol for which job

If you need	Pick	Why
Simple polling on a plant network	Modbus TCP	Supported by everything, easy to troubleshoot
Events + time stamps over weak links	DNP3 or IEC 104	Report by exception, local event buffering
Power sector, Europe / international	IEC 60870-5-104	The regional standard for control centers
Power and water, North America	DNP3	The regional standard, SAv5 security
Inside the substation	IEC 61850	GOOSE speed, Sampled Values, engineered data model
SCADA-to-enterprise integration	OPC UA	Security and information modeling built in
Hundreds of sites on cellular / satellite	MQTT Sparkplug B	Minimal bandwidth, no polling, state awareness

Two rules of thumb from the field. First: the protocol’s event and time-stamp behavior matters more than its raw speed — a slow link with report-by-exception beats a fast link with dumb polling. Second: security is not equal across these. Modbus has none natively; DNP3, IEC 104, IEC 61850, and OPC UA each handle it differently, and the differences drive your network segmentation design. The full breakdown of every protocol is in the communication protocols guide.

Key Design Goals

SCADA design is about trade-offs. These goals come up in most projects.

Availability

Operators need the system running. Downtime can stop production or reduce safety. Typical measures include redundant servers, redundant power, redundant network paths, and regular backup and restore tests.

Reliability

Data should be correct, and commands should work as expected. This requires good tag quality checks, proper scaling and units, clear communication status indicators, and handling for stale data and bad quality flags.

Performance

The system must refresh screens fast enough for operators. Performance depends on poll rates, number of tags, alarm rates, historian load, and graphics complexity.

Safety

SCADA is not the safety system in most designs, but it must not make safety worse. Safety functions stay local in the PLC or SIS. SCADA commands go through permissives and interlocks in PLC logic. Manual vs. auto states and control ownership must be clear.

Maintainability

These systems run for 10 to 20 years. People change. Vendors change. Good maintainability needs naming standards, documentation, template-based graphics, a clean alarm philosophy, and configuration management.

Alarm Management

Alarms are one of the main reasons SCADA exists. They are also the most commonly ruined function in the system. Bad alarming doesn’t just annoy operators — it trains them to ignore the screen, and then the one alarm that mattered scrolls past with the noise.

This problem is common enough that it has its own standard: IEC 62682 (the international version of ISA-18.2) defines the alarm lifecycle, from philosophy through rationalization to monitoring and audit. Its core demand is simple: every alarm must require an operator action. If nothing needs to be done, it’s an event for the log — not an alarm.

What a working alarm setup looks like:

• An alarm philosophy document. One document that defines priorities, limits, and rules before anyone configures a single alarm. IEC 62682 makes this the foundation; in practice it’s what keeps ten engineers from inventing ten alarm styles.
• Rationalized alarms. Each one justified: what happened, what the operator must do, how much time they have. Priority follows consequence and available response time — not how loudly a department asked for it.
• Meaningful text with guidance. “Pump 3 motor overload — check MCC breaker, then reset overload” beats “P3_FLT” every shift.
• Flood suppression. One communication failure must not fire 200 derived alarms. Group, suppress, and shelve by design.
• Maintenance suppression with an expiry, so suppressed alarms don’t become forgotten alarms.
• Measured performance. The benchmark widely used from EEMUA 191: around one alarm per operator per 10 minutes in steady state is manageable; sustained floods mean the system, not the operator, has failed. Review the numbers after every incident.

Time and Data: Historian Basics

If you want trends and event records you can trust, time is the first design decision — not an afterthought.

Where the timestamp is born. The best timestamp comes from the device that saw the event: the RTU, relay, or PLC. DNP3 and IEC 60870-5-104 carry device timestamps in the protocol. Modbus doesn’t — values get stamped when the server receives them, so every Modbus point inherits the polling delay. Know which of your points carry real time and which carry arrival time; they don’t mean the same thing in an investigation.

Synchronization. Device timestamps are only comparable if the clocks agree. NTP is the workhorse and is fine for most process data. Where events must line up to the millisecond — protection and substation work — PTP (IEEE 1588) does the job, and the power sector profiles it as IEC/IEEE 61850-9-3. Pick the sync method per zone based on what the data has to prove.

What to store. Periodic sampling (every 1 s, 5 s, 1 min) for analog trends; exception-based storage (on change beyond a deadband) where bandwidth or storage is tight. Deadbands are a real engineering choice: too wide and the trend lies, too narrow and the historian drowns.

Store the quality, not just the value. Every stored value should carry its quality flag — good, invalid, substituted, stale. A trend that hides bad-quality periods will mislead exactly when you need it most: during the incident review.

A historian is not just storage. It’s the system’s memory, and the evidence base for every “what actually happened at 03:12” conversation you’ll ever have.

Cybersecurity in SCADA: What the Standards Require

SCADA security starts from a priority order that inverts everything IT security assumes. IT protects confidentiality first, then integrity, then availability. IEC 62443-1-1 flips it for control systems: availability first, integrity second, confidentiality last — because a stopped process costs money and can hurt people immediately, while a leaked raw process value is close to worthless out of context. Every control below follows from that inversion. Any measure that risks availability to protect confidentiality has the priorities backwards.

The same standard defines seven foundational requirements that a secure control system has to satisfy. They make a better checklist than any vendor’s, so this section uses them as the skeleton.

Restrict Data Flow — segmentation, zones, and conduits

Partition the system into zones (groups of assets sharing security requirements) connected by conduits (the controlled communication paths between them). In practice that means: an OT control network for SCADA servers and PLC traffic, an OT DMZ for anything shared with IT, and firewalls enforcing which protocols and ports may cross each conduit. Each zone gets a target security level from risk assessment — not every zone needs the same protection, and pretending otherwise wastes budget where it isn’t needed and underprotects where it is. The zone model and its levels come straight from IEC 62443; the layout follows the reference architecture most engineers know from the Purdue-style level model.

Access Control and Use Control — who gets in, what they can do

Two separate requirements, and the split matters. Access control decides who can reach a device or system at all. Use control decides what an authenticated user may do — an operator acknowledges alarms and changes setpoints; only an engineer downloads PLC logic. In practice: unique accounts (no shared logins), role-based permissions, separate admin accounts for engineering work, and remote access only through MFA, a jump host, and time-limited sessions with recording where possible. Remote access deserves the paranoia: it bypasses every physical control the site has.

Data Integrity and Data Confidentiality — the protocol problem

Integrity protects process values and commands from unauthorized change; confidentiality protects them from reading. Here the field bites back: Modbus has neither, and plenty of deployed devices can’t do either. Where the protocol supports security — DNP3 SAv5, IEC 62351 for the 60870 and 61850 families, OPC UA’s built-in certificates — use it. Where it doesn’t, the zone boundary does the job instead: an insecure protocol confined inside a well-guarded zone is a managed risk, the same protocol crossing zones unprotected is an incident schedule.

Timely Response to Events — monitoring and logging

You can’t respond to what you don’t see. Central log collection, alerts on unusual logins and configuration changes, and OT-aware network monitoring that understands industrial protocols. The requirement says timely — detection without a response plan and a person who owns it doesn’t satisfy anything.

Resource Availability — redundancy, backups, patching

The availability requirement covers the unglamorous work. Redundant servers and communication paths. Backups of SCADA servers, historians, HMI configurations, PLC programs, and network device configs — tested by restoring them, because an untested backup is a hope, not a control. And patching, done the OT way: asset inventory first, vendor-validated patches, planned windows, and documented compensating controls for what genuinely can’t be patched. NIST SP 800-82 is the reference for running this as a program rather than a heroic annual effort.

None of these stands alone. IEC 62443 calls the combination defence in depth: layers, so that one failed control is caught by the next instead of becoming the incident. A firewall rule that slips, caught by monitoring. A stolen credential, limited by use control. That layering — not any single product — is what the standards actually require.

Integration With Other Systems

SCADA data is worth money outside the control room. Management wants production dashboards. Maintenance wants equipment history. Billing wants meter totals. The pressure to connect SCADA to the business network is permanent — and so is the risk, because every integration path is also a path back in.

The rule that governs all of it: data flows up freely; nothing talks down to the control system directly. Every good pattern below is a variation of that rule. Every OT incident that started on the IT side broke it somewhere.

Pattern 1: Historian replication. The SCADA historian in the OT zone replicates to a second historian in the DMZ or on the IT side. Business users query the replica; they never touch the OT historian. This is the default pattern and it covers most needs — reports, dashboards, analytics all read from the copy. Use it when: the business needs process data, which is almost always. Watch out: the replication link is OT-initiated and one-directional. If IT tools can write back to the OT historian, the pattern is broken.

Pattern 2: OPC UA gateway in the DMZ. An OPC UA server in the DMZ exposes a defined set of tags to enterprise clients. OPC UA carries its own security — certificates, signed and encrypted sessions — and its information model lets you publish exactly what’s needed and nothing else. Use it when: MES or other enterprise applications need live values, not just history. Watch out: scope creep. The tag list exposed through the gateway grows quietly over the years. Review it like you review firewall rules.

Pattern 3: MQTT broker in the DMZ. Edge devices or the SCADA system publish selected telemetry to an MQTT broker; cloud and IT applications subscribe. The OT side only ever opens outbound connections, which firewalls love. Use it when: data needs to reach cloud analytics or many consumers cheaply. Watch out: the broker becomes critical infrastructure the moment operations starts trusting a dashboard fed by it. Secure it and make it redundant like one.

Pattern 4: Data diode. A hardware one-way link. Data physically can only flow out of the OT zone — there is no return channel to attack. Use it when: regulation or risk demands provable one-way transfer: generation plants, critical substations, high-consequence sites. Watch out: one-way means one-way. No acknowledgements, no retransmission requests. The receiving side needs to tolerate gaps, and anything needing two-way traffic needs a different pattern.

Three lines that should survive every design review:

1. No SCADA server ever talks directly to the internet.
2. No enterprise application ever talks directly to a PLC.
3. Every integration lives in the DMZ, crosses a firewall on each side, and follows the segmentation rules of IEC 62443 zones and conduits.

If a proposed integration can’t be drawn as “OT pushes up to a DMZ layer, IT reads from the DMZ layer,” redesign it before it ships. Retrofitting the DMZ after the connection exists is ten times the work — and it usually happens right after the incident that proves the point.

SCADA Lifecycle: How the Standards Frame It

A SCADA system lives 10 to 20 years. The standards bodies noticed that most problems come from treating it as a project with an end date instead of a system with a life. IEC 62443-1-1 defines a security lifecycle in three phases — Assess, Develop and Implement, Maintain — that runs in parallel with the engineering lifecycle below. The point of the pairing: security is decided at every stage, not bolted on at the end.

1. Requirements and Scope — the Assess phase

Define sites and assets, tag counts, alarm philosophy, reporting needs, and uptime targets (including what “downtime” actually means for your operation). This is also where IEC 62443 puts risk assessment: partition the system into zones and conduits, assess the risk per zone against the organization’s risk tolerance, and assign each zone a target security level — SL(target). Doing this now costs a workshop. Doing it after the network is built costs a redesign.

2. Design

Network diagrams, server architecture, redundancy design, naming standards, user roles, and interface lists (protocols, IPs, ports). The zone boundaries from step 1 become firewall placements and conduit definitions here. Devices and countermeasures get selected against the SL(target) of the zone they’ll live in — a controller destined for a high-target zone needs the security capability to match, and that’s a procurement criterion, not an afterthought.

3. Build and Test — FAT and SAT

Run a Factory Acceptance Test (FAT) in a lab environment, then a Site Acceptance Test (SAT) on the real installation, with loop checks and point-to-point tests. IEC 62381 is the reference that formalizes what FAT, SAT, and SIT each cover for automation systems. The 62443 addition: test the security functions with the same rigor as the process functions. A FAT that proves the alarms work but never checks that the zone boundaries hold is half a FAT.

4. Commissioning and Cutover

Migration steps, a rollback plan, operator training, and alarm tuning after go-live. This is where the achieved security level — SL(achieved) — gets validated against the target for each zone. If achieved falls short of target, the standard gives you exactly two honest options: add compensating countermeasures, or formally accept and document the residual risk. Quietly ignoring the gap is not on the list.

5. Steady Operations — the Maintain phase

Backups and restore tests, health checks, alarm reviews, access reviews, and patch cycles. The reason 62443 makes Maintain a full phase and not a footnote: security degrades on its own. New vulnerabilities appear, attacker tooling improves, countermeasures age. SL(achieved) is a function of time — it only goes down between audits. So the phase runs on triggers: scheduled reviews, new vulnerability disclosures, and process changes all send you back to reassess. IEC 62443-2-1 wraps this loop into a cybersecurity management system (CSMS), and NIST SP 800-82 gives the equivalent guidance for OT programs.

The engineering lifecycle ends at handover. The security lifecycle never ends — that’s the single most useful thing the standards say about SCADA.

Common Mistakes in SCADA Projects

Mistake 1: Treating SCADA as just “screens”

SCADA is a full system — communications, servers, security, procedures, and training. Design the whole stack, not just the HMI.

Mistake 2: Too many alarms

If everything is an alarm, nothing is. Use an alarm philosophy and focus on alarms that require action.

Mistake 3: Poor naming and no standards

Messy tag names lead to mistakes and slow troubleshooting. Create naming rules early and use templates.

Mistake 4: Remote commands with weak interlocks

A wrong click can cause damage. Put permissives and interlocks in PLC logic. Use command confirmations and control ownership rules.

Mistake 5: No real disaster recovery plan

Many sites only discover this gap during an outage. Document recovery steps, test restores, and keep spares and system images.

Mistake 6: Weak security defaults

Default passwords and flat networks are common failure points. Segment networks, enforce MFA for remote access, and remove unused services.

Practical SCADA Checklist for IT/OT Teams

Run through this honestly — “yes” means you can show the evidence, not that someone believes it’s probably fine. Every question maps to a section above, so a “no” tells you exactly where to read.

Operations

• Are communication failures unmistakable on screen? (A dead RTU shows as a comms alarm on that station — not as frozen values pretending to be live.)
• Can operators see data quality per point? (Stale, invalid, and substituted values are visually distinct. A stale “closed” is not a closed.)
• Does every command produce feedback or a failure alarm? (Silence after a command is never an acceptable outcome.)
• Is control ownership visible? (Operators can see when a site is in local and their commands are locked out.)

Alarms

• Does every configured alarm require an operator action? (If nothing needs doing, it’s an event — IEC 62682’s core rule.)
• Is there an alarm philosophy document, and does the configuration actually follow it? (Check three random alarms against it.)
• Are alarm rates measured? (Steady state near one alarm per operator per 10 minutes; floods investigated as system failures, not operator failures.)
• Do suppressed and shelved alarms expire and get reviewed? (Suppression without expiry is how alarms disappear forever.)

Time and Data

• Do you know which points carry device timestamps and which carry server arrival time? (DNP3/IEC 104 points vs Modbus points mean different things in an investigation.)
• Are clocks synchronized, and is sync monitored? (NTP as baseline; PTP where SOE must line up to the millisecond. A drifted clock fails silently.)
• Are historian deadbands reviewed per point? (Too wide and trends lie; too narrow and the historian drowns.)
• Would the SOE record survive a comms outage? (Events buffered at the device with original time tags, delivered on reconnection.)

Engineering

• Are tag names consistent with a written standard? (Pick five tags from different years — do they follow the same rule?)
• Are graphics template-based? (One fix in the template fixes every screen; hand-drawn screens rot individually.)
• Is every change tracked — who, what, when, why? (Configuration management is the audit trail’s engineering half.)
• Can you rebuild the current configuration from what’s in version control or backups? (Not last year’s configuration — the current one.)

Infrastructure

• Is redundancy present at every layer the uptime target requires? (Servers, networks, comms paths, historian — per layer, not assumed.)
• Has failover actually been exercised, on schedule, with the result documented? (A standby that has never taken over is a hope.)
• Are backups automated AND restore-tested? (The test is a restore, not a green checkmark in the backup tool.)
• Do backups cover everything needed to rebuild — servers, historian, HMI configs, PLC programs, network device configs? (The forgotten switch config is a classic recovery-day surprise.)

Security

• Are networks segmented into zones with controlled conduits between them? (OT, DMZ, IT — with firewalls enforcing which protocols cross.)
• Does every zone have an assigned target security level from a risk assessment? (If nobody can name it, the assessment didn’t happen.)
• Is remote access MFA + jump host + time-limited, with vendor sessions enabled per job? (No standing 24/7 vendor tunnels.)
• Are accounts unique and role-based, with separate admin accounts for engineering? (Shared logins break the audit trail by design.)
• Is there an asset inventory current enough to patch from? (You can’t secure what you haven’t listed.)
• Are unpatchable systems documented with compensating controls? (Written down and reviewed — not just known in someone’s head.)

Integration

• Does all IT/cloud access go through the DMZ — replica historian, OPC UA gateway, or MQTT broker? (Nothing on the enterprise side reads OT systems directly.)
• Are all OT-side connections outbound-initiated? (The field pushes up; nothing dials down.)
• Can any enterprise application reach a PLC? (The only correct answer is no.)
• Is the exposed tag/topic list reviewed like a firewall rule set? (Integration scope grows quietly — audit it on a schedule.)

Recovery

• Is there a written, current recovery procedure — and has someone other than its author executed it? (The author’s knowledge is not a procedure.)
• Do you know your actual recovery time from bare hardware? (Measured in a test, not estimated in a meeting.)
• Are spares and system images on hand for the components whose lead time exceeds your downtime tolerance?

If most answers are yes with evidence, the system is in better shape than the majority running today. The “no” items, in this order — recovery, backups, segmentation, alarms — are where the next incident is already scheduled.

FAQ

Summary

A SCADA system is the control room layer that helps teams monitor, alarm, trend, and supervise industrial processes. It sits above PLCs and RTUs. It relies on communication networks and server infrastructure. Done well, SCADA improves uptime and response time. Done poorly, it creates alarm noise, confusion, and security risk.