8.4 DCS, PLC, SCADA Architecture and Interfaces

Architecture is an implementation choice with consequences

NCEES 2.E asks for system design covering architecture, hardware, interfaces, and related constraints: advantages and disadvantages of system architecture, distributed architecture, remote I/O, buses, and wireless. This section is 2.E architecture in this guide’s chapter map: where the computer sits, what it talks to, and what still runs if a server dies. Full industrial cybersecurity (firewalls, IEC 62443-style levels, security lifecycle) is chapter 9. Here, security appears only as where you must not plug things.

IEC 61511-1:2018 (supplied) still governs the SIS box on the diagram: independent sensors, logic solver, and final elements from the basic process control system (BPCS). A pretty DCS graphic is not a SIF.

DCS versus PLC versus SIS versus SCADA/HMI

These names describe roles, and modern products blur marketing labels. Answer from job and failure domain, not from a vendor brochure.

• DCS (distributed control system) — plant-wide regulatory control: hundreds to thousands of analog loops, integrated engineering database, operator consoles, alarm subsystem, and redundancy as a normal option. Controllers are distributed by unit but engineered as one system. Typical: refinery, chemical, power boiler.
• PLC (programmable logic controller) — rugged cyclic controller optimized for discrete and high-speed machines, packaging, skids, and smaller analog counts. Can be networked into a plant system. Typical: compressor skid package, discrete manufacturing cell, filter press.
• SIS (safety instrumented system) — IEC 61511-1 logic solver executing safety instrumented functions, with certified hardware, application program constraints (often LVL), diagnostics, and independence from BPCS. Typical: ESD, HIPPS, burner management when specified as SIS.
• SCADA (supervisory control and data acquisition) + HMI — supervisory view over geographically dispersed assets (pipelines, well pads, water networks, substations). Controllers/RTUs in the field do local control; SCADA polls, commands, alarms, and historizes. SCADA is not a substitute for a 50 ms anti-surge PID inside a local controller.

HMI is the human interface. It can sit on a DCS console, a PLC panel-view, or a SCADA server farm. It is Level 2 supervisory, not Level 1 control, unless you have incorrectly put the only copy of a PID in a PC (an exam “do not do this” for anything that must keep running).

Hardware layers: controllers, I/O, servers, historians

Controllers execute the scan. I/O converts 4–20 mA, thermocouples, discretes, and bus devices into the image. Local I/O shares the controller’s cabinet or a short, highly available link. Remote I/O extends that image over a network (copper, fiber, wireless) to marshaling in the field. Buses (FOUNDATION Fieldbus, PROFIBUS, EtherNet/IP, PROFINET, Modbus, WirelessHART) move I/O or peer data; each has distance, determinism, and hazardous-area implications.

Servers host HMI, batch, asset management, and OPC interfaces. Historians store time-series for trends longer than the controller’s RAM. If the historian or HMI server dies, regulatory control should continue in the controllers. If the controller dies, the HMI showing last values is a tombstone, not a loop.

OPC (originally OLE for process control; today often OPC UA) is an interface, typically supervisory: HMI, historian, and MES reading/writing tags. OPC Classic/DCOM across Windows domains is a known fragile, hard-to-secure pattern. OPC UA can be architected with authentication and encryption. Neither protocol is the PID. Putting an OPC client on the SIS network as a convenience historian tap is an architecture-level security and independence mistake (details in chapter 9; here: don’t).

Redundancy: simplex versus duplex

Redundancy is not a moral good; it is a consequence-of-loss choice:

• Simplex controller — one CPU. Loss = lose those loops until you recover. Acceptable when process dynamics and consequence allow (many tank-farm monitors, some utility skids) and you have spare parts and a repair-time assumption.
• Redundant controllers — synchronized pair, bumpless switchover. Used where loss of control quickly becomes loss of containment, surge, or a unit trip you cannot afford.
• Redundant I/O or redundant networks — separate failure domains from CPU redundancy. A dual CPU with a single remote-I/O ring still dies if that ring dies.
• Redundant servers/historians — protect view and archive, not the loop.

IEC 61511-1 redundancy and voting (1oo2, 2oo3) for SIF are safety calculations, not a reason to run all plant PID in the SIS.

Worked example: remote versus local I/O, simplex versus redundant

Loop A — compressor anti-surge. Recycle valve on the skid. Surge events evolve in tens to a few hundred milliseconds. Loss of the loop can wreck the compressor. Architecture: local I/O (or an equivalently fast, dedicated deterministic link) on a redundant (or otherwise highly available) controller whose scan is sized for the loop. Do not put this PV/OP on the same 800 m remote-I/O drop as tank gauges, and do not execute anti-surge in SCADA at 5 s poll. A package PLC on the skid talking up to the DCS for supervision is a valid split: fast loop local, supervisory DCS remote.

Loop B — tank-farm level. Eight atmospheric tanks, 800 m from the control house, level dynamics in minutes, independent containment alarms and SIS/gauging as specified elsewhere. Architecture: remote I/O or bus transmitters back to a simplex or redundant PLC/DCS controller is acceptable if the network is engineered (fiber, diagnostics, failover) and a communications loss has a defined fail action (hold last versus fail-safe). Simplex is often justified if the consequence of a 4-hour controller repair is “no remote move of transfer pumps,” not “destroy a 11,000 rpm rotor.”

Exam contrast. Remote I/O is chosen for distance, cabinet heat, hazardous-area marshalling, and constructability—not to save a few meters of cable on a surge valve. Redundancy follows how fast and how bad loss is, not “DCS always duplex, PLC always simplex.” A PLC anti-surge skid is often redundant; a DCS tank-farm controller might be simplex.

Typical levels (field, control, supervisory)

Think in three exam-useful layers (Purdue/ISA-95 goes higher into MES/ERP; those are out of scope here):

1. Field — transmitters, switches, valves, motors, local panels.
2. Control — DCS/PLC controllers, remote I/O, SIS logic solver on its own I/O.
3. Supervisory — operator HMI/SCADA, engineering station, historian, OPC servers.

Security implication (architecture only): keep SIS and BPCS segregated; do not bridge them with an undocumented PC; place OPC and business interfaces above the control layer, not beside the safety solver. Access control on engineering stations is the same human-factors rule as section 8.1.

DCS versus PLC versus SCADA

Read the diagram left-to-right as authority to act. The SIS path from field to final element does not depend on the HMI server. The historian and OPC hang off supervisory, reading the control layer. If an exam item asks what still runs after a SCADA host fails, the answer is the controllers and SIS, plus any local panels—not the OPC client on a laptop.