The short answer
SCADA Architecture
A SCADA system is a set of services with data flowing between them. I/O servers poll the controllers through drivers and fill a real-time tag database; the alarm server watches the tags against limits; the historian records them; and clients present displays that read the tags and write commands back. Those services can all run on one machine at a small site or be split across redundant servers and thin clients at a plant, and the architecture is chosen from how much the site can afford to lose when something fails.
Key points
- Every SCADA platform has the same five jobs: talk to controllers, hold live tags, alarm, historize, and display; the differences are in how they are packaged.
- Data flows controller to driver to tag database to client; a fault at any hop looks like frozen values downstream.
- A single machine is fine until it is the only copy of the configuration and the history.
- Clients should hold no configuration of their own; a display that works only on one machine is a liability.
- Where the servers sit on the network, and what can reach them from outside, is a security architecture decision as much as a SCADA one.
The services
- I/O server, or driver host
- Runs the protocol drivers that talk to controllers, RTUs, drives, and meters over Ethernet, serial, and radio. It polls on scan groups, or receives unsolicited data on protocols that support it, and writes the results into the tag database. It is where communication diagnostics live.
- Tag database, or runtime
- The real-time image of the plant: every tag with its value, quality, and timestamp. Everything else reads from it and writes to it. It also runs scripts, calculations, and derived tags.
- Alarm server
- Evaluates tags against limits and states, manages alarm state and acknowledgment, applies priorities, shelving, and suppression, and feeds the alarm displays and the notification system.
- Historian
- Stores tag values over time, compressed, and answers queries for trends and reports. On small systems it is a module of the runtime; on large ones a separate product on its own server.
- Clients
- The displays. Thick clients run the display engine locally and connect to the servers; thin and web clients render displays served from a server in a browser or a lightweight viewer. Operators, engineers, and managers get different clients with different permissions.
- Supporting services
- Reporting, notification by phone or text, remote access gateways, and integrations to maintenance, billing, or laboratory systems.
The data path
A level in a wet well becomes a number on an operator screen by a chain of steps, and knowing the chain is most of troubleshooting. The transmitter drives 4 to 20 mA into the controller input. The controller scales it and holds it in a tag. The I/O server polls the controller on its scan interval and writes the value, with a quality and a timestamp, into the tag database. The alarm server compares it against the high level limit. The historian stores it when it changes by more than its deadband. The client subscribes to the tag and paints it. A frozen value on the screen is a failure at one of those hops, and each hop has its own diagnostics.
Topologies
| Topology | What runs where | Suits | What it loses when it fails |
|---|---|---|---|
| Standalone | Every service and the client on one PC, often a panel PC in the control room | A single station or a small plant | Everything: control view, alarms, and history, until the PC is rebuilt |
| Server and clients | Services on one server; clients on operator workstations and remote PCs | A plant with several operator positions | The server is still a single point of failure, but clients can be replaced in minutes |
| Redundant servers | Two servers, one active and one standby, synchronizing tags, alarms, and history; clients fail over automatically | A plant that cannot be blind for an hour | Very little, if failover is tested; the redundancy page covers what it does not cover |
| Distributed | I/O servers at remote sites or plants, a central runtime and historian, clients everywhere | A utility with several plants and many remote sites | A site keeps polling locally when the link to the center is down, and catches up after |
Clients
A client should be interchangeable. Any client, on any machine, with the right credentials, shows the same displays from the same server, and replacing a failed operator workstation is a matter of installing the client and pointing it at the server. The failure mode to design out is the workstation that has displays, scripts, or driver configuration of its own that exist nowhere else. Thin and web clients make this natural; thick clients need the discipline of keeping every display on the server and deploying from there.
Where it sits on the network
The SCADA servers talk to the controllers on the control network and to clients, the historian, and the enterprise on networks above it. In the Purdue model they sit at level 2 and 3, with a firewall between them and the controllers below and a demilitarized zone between them and the business network above. Remote access, for an on-call operator or a vendor, comes in through that DMZ, never straight to the servers. Anything that can reach the SCADA server can, in most platforms, write to any controller it is connected to, so the network around it is part of the design and the cybersecurity section covers it.
Virtualization and time
Modern SCADA servers are usually virtual machines on a host in a rack, which makes redundancy, backup, and rebuilding far easier than on a dedicated PC in a panel. It also means the host, its storage, and its network are now part of the control system and have to be maintained as such. Time synchronization across everything, servers, clients, controllers, and RTUs, from one reliable source, is the small architectural detail that decides whether the alarm log and the historian agree about when something happened.
Frequently asked questions
- What is the difference between SCADA and HMI?
- The HMI is the display the operator uses. SCADA is the whole system behind it: communication with the controllers, the live tag database, alarming, and history, of which the HMI is the visible part. A panel touchscreen is an HMI; a plant control room runs SCADA.
- Do I need a separate historian?
- A small system does fine with the historian built into the SCADA platform. A plant that keeps years of high-resolution data, serves it to reports and analytics, and cannot afford to lose it wants a dedicated historian on its own server with its own backup.
- Should clients be thick or thin?
- Thin and web clients keep every display on the server and make workstations interchangeable, which is what you want. Thick clients are needed where a platform requires them or where local performance matters, and then the displays still belong on the server.
- Can the SCADA server be a virtual machine?
- Yes, and it usually should be. Snapshots, backups, and failover are all easier. The host and its storage become part of the control system and need the same care and the same network placement.
Related topics
- What Is SCADA?Supervisory control and data acquisition: the layer that collects data from controllers across a system, presents it to operators, records it, and lets them intervene.
- HistoriansWhat a process historian does that a database does not, how data gets into it, how compression and retrieval work, how to size and keep it, and the settings that quietly throw data away.
- SCADA RedundancyWhat redundant SCADA servers protect against and what they do not, how failover works for tags, alarms, history, and clients, the network and controller layers beneath it, and why an untested failover is not redundancy.
- The Purdue ModelThe reference architecture most segmentation designs still start from: what each level contains, where the DMZ goes, and how it maps to a water utility.
- Values Frozen On ScreenThe HMI shows numbers that are not changing while the plant runs. Whether the controller, the communication driver, the tag server, or the display stopped, and the order to check them in.
- SCADA ServersWhat the servers in a SCADA system do and what a utility should expect of them: the I/O, alarm, historian, and client roles, physical versus virtual, redundancy, sizing, placement, backup, patching, licensing, and monitoring.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.