SCADA Architecture Explained: RTU, PLC, HMI, and How They Connect
Every SCADA deployment follows the same architecture — whether it monitors 50 sensors on a single Raspberry Pi or 50,000 tags across three continents. The pieces are the same. The difference is in how they are connected, what runs where, and how much complexity the integrator absorbs versus the software handles.
This article walks through the five layers of SCADA architecture, how they evolved, and what a modern SCADA deployment actually looks like in 2026 — when a single binary can replace a rack of servers.
The Five Layers of SCADA Architecture
Every SCADA system — from a 1980s Wonderware deployment to a modern Voltrus setup — follows the same architectural model. The layers are defined by their function, not their physical location. Understanding these layers is the difference between drawing a system diagram that makes sense and one that collapses the first time a network switch goes down.
Layer 0 — Field Devices
Sensors and actuators. Temperature sensors, pressure transmitters, flow meters, level switches, valve positioners, and motor contactors. These devices measure or control physical processes. They output 4-20mA analog signals, 0-10V, dry contacts, or digital pulses. Field devices have no intelligence — they measure and report. The key constraint: field devices produce raw signals that need interpretation. A 4mA current loop means one thing on a -40°C to 85°C temperature transmitter and something completely different on a 0-100 PSI pressure transducer.
Layer 1 — Controllers (PLC and RTU)
Programmable Logic Controllers and Remote Terminal Units convert raw field signals into engineering values. A PLC reads the 4-20mA signal, applies the scaling formula, and stores the result as a floating-point number in a register. This is where the raw electrical signal becomes usable data. PLCs also execute control logic — ladder logic programs that make decisions based on sensor values and command actuators. RTUs serve the same role in remote locations (substations, wellheads, pumping stations), often with battery backup and cellular/satellite communication.
Layer 2 — Communication Network
The communication layer connects controllers to the SCADA server. In traditional architecture, this was RS-485 serial cable running Modbus RTU. Modern deployments use Ethernet with Modbus TCP, OPC-UA, or proprietary protocols like Siemens S7 or Allen-Bradley EtherNet/IP. The communication layer is where most SCADA integration work happens — configuring IP addresses, setting up protocol drivers, mapping register addresses, and handling communication failures. This layer is the source of most SCADA deployment delays. Every protocol speaks a different dialect. Every PLC manufacturer uses different address formats.
Layer 3 — SCADA Server (Data Acquisition and Processing)
The SCADA server polls controllers on a fixed cycle (every 500ms, every 1 second, every 5 seconds), processes the data, evaluates alarm conditions, stores time-series data, and serves data to clients. This is where the SCADA software itself lives. In traditional architecture, this layer is distributed across multiple servers: a data acquisition server, a historian database server, an alarm server, and an application server. In modern single-binary architectures like Voltrus, all of these functions run in one process on one machine, including redundancy handling with automatic failover.
Layer 4 — Clients (HMI and Dashboards)
Clients display data to operators, engineers, and managers. In traditional architecture, this meant a Windows application installed on a control room PC — the HMI. Modern SCADA clients are web-based dashboards accessible from any browser, on any device. The same dashboard that runs on the control room monitor also runs on the maintenance manager's tablet and the plant director's phone at 2 AM. Clients are read-only by design — they display data and allow alarm acknowledgment, but they do not store or process data.
Data Flow: From Sensor to Dashboard
A single data point in a SCADA system travels this path:
- Physical process — A pump motor draws 42 amps. The current transformer on the motor cable produces a proportional 4-20mA signal.
- Field device — The current transducer converts the 4-20mA signal to a value representing 0-100 amps, scaled to 4mA = 0A and 20mA = 100A.
- PLC input — The PLC analog input module reads the signal, applies the scaling, and stores the value
42.0in Data Block 1, Offset 12. - Communication — The SCADA server sends a Modbus TCP Read Holding Register request (function code 03) to the PLC, requesting the register at address 40013 every 1 second.
- SCADA server — The server receives
42.0, timestamps it with millisecond precision, stores it in the time-series database, evaluates alarm conditions (is 42A above the 40A warning threshold?), and pushes the value to connected dashboards via WebSocket. - Client dashboard — The dashboard widget updates from 41.8 to 42.0. The trend line continues. If the value exceeded 40A, the alarm indicator turns yellow and the alarm list shows the new entry.
This entire loop — from sensor change to dashboard update — takes less than 2 seconds in a properly configured system. In Voltrus, with local Modbus TCP polling at 500ms intervals and WebSocket push to dashboards, the total end-to-end latency is under 800 milliseconds.
Modern vs Traditional SCADA Architecture
The traditional SCADA stack is distributed by necessity — it was built in an era when a single server could not handle data acquisition, historian storage, alarm processing, and web serving simultaneously. The result is a multi-server architecture that looks like this:
Traditional: PLC → OPC Server (Kepware) → SCADA Gateway (Ignition) → SQL Database (SQL Server) → Web Server → Browser Client. Five separate software components, each requiring installation, configuration, licensing, and maintenance. Each adding latency, failure modes, and upgrade complexity.
Modern (Voltrus): PLC → Voltrus (single binary: protocol driver + data acquisition + historian + alarm engine + web server + WebSocket stream) → Browser Client. One process. One configuration file. One thing to install, update, and monitor.
The architectural simplification is not cosmetic. It directly reduces the number of things that can break in production. A traditional SCADA stack has at least 5 inter-component interfaces where failure can occur. Voltrus has zero internal interfaces — everything runs in one process. When something goes wrong, you check one log file on one machine.
Protocols in the Architecture
The communication layer is where protocol support becomes critical. A SCADA platform's value is directly proportional to the number of protocols it speaks natively — because every protocol adapter you add is another component that can fail.
Voltrus supports these protocols natively, with no middleware:
- Modbus TCP — The universal industrial protocol. Every PLC, every power meter, every VFD speaks Modbus.
- MQTT — Lightweight IoT protocol. Ideal for remote telemetry over cellular or satellite.
- Siemens S7 — Direct connection to S7-1200 and S7-1500 PLCs without TIA Portal.
- Allen-Bradley EtherNet/IP — Native tag browsing on ControlLogix and CompactLogix.
- OPC-UA — The enterprise standard for cross-vendor interoperability.
- DNP3 — Utilities and water/wastewater SCADA protocol.
- BACnet/IP — Building automation and HVAC integration.
Each protocol is handled by a dedicated driver that runs within the Voltrus process. No external protocol servers. No middleware licensing. No translation layers that strip metadata or add latency.
Deployment Models: Edge, On-Premise, and Hybrid
SCADA architecture also determines where components run physically. Three common deployment models:
Edge Deployment
The SCADA server runs on a Raspberry Pi or ARM gateway in the same cabinet as the PLC. Data is collected, processed, stored, and served locally. This is the most reliable model — no network dependency between the SCADA server and the controllers it monitors. Voltrus on a Raspberry Pi 5 with an SSD can handle 5,000+ tags with sub-second polling.
On-Premise Central Server
The SCADA server runs on a plant-floor server (Linux or Windows) and connects to multiple PLCs across the facility network. All data stays local. All dashboards are served from the plant network. This is the traditional model for mid-size facilities.
Hybrid (Edge + Central + Remote Access)
Multiple edge instances (one per production line or remote site) collect data locally. A central instance aggregates data from all edges for fleet-wide dashboards. Remote access is provided via VPN or secure tunnel — not by exposing the SCADA server to the internet. This is the model for multi-site deployments.
SCADA Architecture That Ships as One Binary
Voltrus: all five layers in a single executable. No SQL Server, no Java, no Docker, no middleware. $249-$999 lifetime.
Explore VoltrusFrequently Asked Questions
What are the five layers of SCADA architecture?
The five layers are: Field Devices (sensors and actuators), Controllers (PLCs and RTUs), Communication Network (Modbus TCP, OPC-UA, S7, etc.), SCADA Server (data acquisition, alarms, historian), and Clients (HMI dashboards and web interfaces). Every SCADA system follows this model whether it monitors 50 sensors on a Raspberry Pi or 50,000 tags across multiple sites.
What is the difference between a PLC and an RTU?
A PLC is installed in a factory or plant floor, executes control logic, and converts raw sensor signals into engineering values. An RTU does the same job but is designed for remote locations such as substations, wellheads, and pumping stations, typically with battery backup and cellular or satellite communication for sites without wired network infrastructure.
How long does it take for sensor data to reach a SCADA dashboard?
In a properly configured system, the complete path from physical sensor change to dashboard update takes under 2 seconds. With Voltrus polling Modbus TCP devices at 500ms intervals and pushing updates to browsers via WebSocket, the total end-to-end latency is under 800 milliseconds.
Can I run SCADA on a Raspberry Pi?
Yes. Modern SCADA platforms like Voltrus ship as a single binary that runs on a Raspberry Pi 5 with an SSD, handling 5,000+ tags with sub-second polling. This edge deployment model is ideal for remote pump stations, small production lines, or any site where a full server rack is impractical.
What protocols does a modern SCADA system need to support?
A modern SCADA platform should support Modbus TCP (universal industrial protocol), MQTT (lightweight IoT telemetry), Siemens S7 (direct PLC connection), EtherNet/IP (Allen-Bradley), OPC-UA (cross-vendor standard), DNP3 (utilities and water/wastewater), and BACnet/IP (building automation). Native protocol support without middleware adapters reduces failure points and deployment complexity.