On this page7 sections
Start with the layers
ISA-95 (IEC 62264) describes a functional hierarchy that is a practical way to divide responsibilities in an integrated system. The standard concentrates on the interface between business systems and manufacturing operations; the lower levels are defined by what they do rather than by the product that does it.
| Level | Function | Typical systems |
|---|---|---|
| 0 | The physical production process | Process equipment and the variables being measured and manipulated |
| 1 | Sensing and manipulating the process | Transmitters, analyzers, valves, drives and the I/O that connects them |
| 2 | Monitoring, supervisory and automated control | PLC and DCS control logic, HMI, SCADA and alarm handling |
| 3 | Manufacturing operations management | Historian, batch management, production, quality and maintenance systems |
| 4 | Business planning and logistics | Enterprise resource planning, scheduling and business reporting |
The Purdue reference model, widely used with IEC 62443 for network zoning, numbers the same hierarchy slightly differently: sensors, analyzers and final elements at level 0, controllers and their I/O at level 1, HMI and SCADA at level 2, site operations such as the historian at level 3, and the DMZ between the plant and business networks at level 3.5. The functions are the same; only the numbering differs.
Whichever numbering is used, two design rules follow. Control belongs at the lowest level that can perform it: interlocks and loops run in the controller, never only in the SCADA server, so supervision can fail without the process losing control. And data flows upward through defined interfaces: SCADA reads from controllers, the historian reads from SCADA or the controllers, and business systems read from level 3 rather than from the plant floor.
Choose protocols per boundary
No single protocol is right for every link. Choose by the boundary, the data volume, the determinism required, the security needed and what the devices on each side genuinely support.
- Modbus RTU
- Serial, usually over RS-485, with a single client — formerly called the master — polling each server device in turn. Simple and widely supported, but it carries only bits and 16-bit registers: floating-point values span two registers, and word order must be confirmed for each device.
- Modbus TCP
- The same register model over Ethernet, on TCP port 502. Faster and easier to route, but it inherits the lack of data types, and classic Modbus TCP has no built-in authentication.
- PROFIBUS DP / PA
- A master–slave fieldbus with cyclic data exchange. DP connects remote I/O, drives and devices; PA carries process instrument data and power on the same two wires and, with intrinsically safe design, suits hazardous areas.
- PROFINET
- Industrial Ethernet between an IO controller and IO devices, with cyclic real-time data exchange and device descriptions supplied as GSDML files.
- EtherNet/IP
- The Common Industrial Protocol (CIP) over standard Ethernet, with implicit messaging for cyclic I/O and explicit messaging for configuration and diagnostics.
- OPC UA
- A platform-independent, service-oriented standard with an information model, subscriptions and built-in security — authentication, signing and encryption. The usual choice between controllers, SCADA, historians and higher-level systems; the default port is 4840.
- OPC DA (OPC Classic)
- Built on COM/DCOM. Still common in existing plants, but DCOM is difficult to secure and to route through firewalls, and operating-system security hardening has broken some legacy connections. Plan migration to OPC UA, using a wrapper or gateway where replacement is not yet possible.
Polling, exception reporting and the scan budget
With polling, the SCADA server or controller requests data from each device on a fixed cycle. Load is predictable, but unchanged values are sent again and again, and every point's update time is set by the full cycle. With report-by-exception, a device or server sends a value only when it changes by more than a deadband — the model behind OPC UA subscriptions and many telemetry protocols. Bandwidth falls sharply, but the design needs periodic integrity checks so that a lost update or a silent device is detected rather than trusted.
On serial networks, estimate the polling budget before committing to update rates. A worked example for Modbus RTU:
Step 1: Define the request
Read 100 holding registers from each of 10 devices at 19.2 kbit/s. Modbus RTU sends 11 bits per character: start, 8 data bits, parity and stop.
Step 2: Count the characters
Request: address, function, start address, quantity and CRC — 8 bytes. Response: address, function, byte count, 200 data bytes and CRC — 205 bytes. Adding the 3.5-character silent interval before each frame gives about 220 character times per transaction.
Step 3: Convert to time
220 × 11 = 2,420 bits, and 2,420 ÷ 19,200 ≈ 0.126 s per device. Ten devices need about 1.26 s of line time per cycle.
Step 4: Add the real-world terms
Add each device's response time, which varies and should be measured, and any retries. An offline device costs a full timeout on every cycle: with a 1 s timeout, one failed device takes this cycle from about 1.3 s to over 2 s.
The same arithmetic shows when to split a network into more segments, read only the registers actually needed, or move the link to Ethernet.
Tag design: one name, everywhere
A tag naming convention is an integration interface, not a documentation nicety. Base it on ISA-5.1 functional identification, add the plant hierarchy, and keep attributes separate from the tag name so every layer addresses them the same way. A typical structure is unit, function and loop number, with attributes appended — U20-FIC-2015.PV, .SP, .OUT, .MODE — and alarm limits and states as further attributes. The same name should appear in the controller, the SCADA database, the historian and the alarm journal.
- Maintain one master tag database — normally the I/O and signal list — and generate controller and SCADA tags from it rather than typing them twice.
- Agree engineering units, ranges, data types and scaling per signal in that list, not screen by screen.
- Never reuse a retired tag name for a different signal; history and alarm records will silently merge.
- Document the naming rule, including exceptions for packaged units, before engineering starts.
Alarms, history and time
Alarm management. ANSI/ISA-18.2, and its international counterpart IEC 62682, defines an alarm as an indication to the operator of an equipment malfunction, process deviation or abnormal condition that requires a response. It describes a lifecycle from alarm philosophy through identification, rationalization, design, implementation, operation, maintenance, monitoring, management of change and audit.
In practice: generate alarms where the condition can be time-stamped accurately, often in the controller; set priority by consequence and the time available to respond; and design out floods, chattering and standing alarms. ISA-18.2 also recommends alarm performance metrics — for example, an average in the order of one alarm per ten minutes per operator position is regarded as very likely to be acceptable.
Historian. Store values with the source time stamp, not the time they arrived. Use store-and-forward so that a network outage delays history instead of losing it, and set deadband and compression per signal class rather than one global value — a flow used for accounting needs different settings from a room temperature.
Time synchronization. Every controller, server and workstation should take time from one reference, typically over NTP, which on a well-designed LAN commonly holds clocks to within a millisecond or so. Where sequence-of-events resolution matters, time-stamp at the I/O module or controller, and consider PTP (IEEE 1588). Store time in UTC and convert only for display.
Segment the network: zones and conduits
IEC 62443 describes a control system as zones — groups of assets with common security requirements — connected by conduits, the controlled communication paths between them. Applied to PLC–SCADA integration, it usually means:
- Controllers and I/O networks in their own zone, reachable only from the supervisory zone.
- SCADA servers and engineering workstations in a supervisory zone, with engineering access controlled and logged.
- A demilitarized zone (DMZ) between the control system and the business network — often drawn as level 3.5 in Purdue-based reference architectures — so business users read from a replicated historian rather than connecting to control assets.
- Remote access terminated in the DMZ through a managed gateway with time-limited authorization, never by direct connection to a controller.
- Every conduit documented: which systems communicate, over which protocols and ports, and in which direction.
Integration design checklist
- Signal list frozen with tag names, ranges, units, data types and owning system.
- Protocol and driver chosen for each boundary, with device support confirmed.
- Polling or subscription rates calculated against network capacity.
- Communication-failure behavior defined: what the controller does, what the operator sees, how values are flagged as bad or stale.
- Alarm philosophy agreed and alarms rationalized before graphics are built.
- Historian scope, sample rates and compression defined per signal class.
- Time source and synchronization method defined for every device.
- Zones, conduits, firewall rules and remote-access method documented.
- Backup and restore of controller and SCADA configurations tested.
Engineering questions
- What does a typical SCADA integration project involve?
- A survey of existing controllers, networks and signals; a signal list and naming convention; protocol and network design; SCADA database, graphics, alarm and history engineering; factory and site testing against the signal list; and commissioning with the operators. On brownfield sites, much of the effort goes into establishing what is actually installed.
- Should new projects still use OPC DA?
- Generally not. OPC UA provides the same data access with platform independence, a richer information model and built-in security. OPC DA persists in existing plants; where it must remain, isolate it and plan migration to OPC UA.
- Is Modbus still suitable for new integration work?
- For simple devices with a modest number of values — meters, drives, packaged instruments — Modbus RTU or TCP remains practical and widely supported. It is less suited to large data sets, structured data or links that need security, where OPC UA or a native industrial Ethernet protocol is usually a better fit.
- Should interlocks be implemented in the PLC or in SCADA?
- In the PLC or controller. SCADA supervises, displays and records; it should never be the only place a process interlock exists, because the interlock would then depend on the server, the network and the polling cycle.