SCADA Architecture Best Practices for Industrial Plants

Architecture decisions you cannot easily undo

A SCADA system is usually specified in a few weeks and then lived with for fifteen years. The decisions that matter most — network topology, redundancy model, tag and alarm structure — are also the ones that are hardest to change once production depends on them.

1. Segment the network properly

Follow a Purdue-model style separation: control devices on Level 1 and 2, supervisory servers on Level 3, and business systems on Level 4, with firewalls and a DMZ between the control and enterprise layers. Historian replication into the DMZ lets business users query data without any inbound path to the control network.

2. Choose a redundancy model deliberately

• Server redundancy — hot standby SCADA servers with automatic failover, for continuous processes.
• Network redundancy — ring topologies with rapid spanning tree or PRP/HSR where a link loss is unacceptable.
• Controller redundancy — redundant processor pairs where a single PLC stop halts production.

Redundancy that has never been failover-tested under load is not redundancy. Test it during commissioning and re-test it annually.

3. Rationalise alarms before go-live

Follow ISA-18.2 principles: every alarm must be actionable, have a defined operator response, and have a defined consequence of inaction. A steady-state target of fewer than six alarms per operator per hour is achievable and transforms operator effectiveness. Nuisance alarms are the single largest cause of operators ignoring the system.

4. Design high-performance HMI screens

Grey-scale backgrounds, colour reserved exclusively for abnormal conditions, analogue indicators showing deviation from normal rather than raw numbers, and a consistent screen hierarchy from plant overview to unit detail. The goal is that an operator can identify an abnormal condition from across the control room.

5. Structure tags and templates from day one

A documented tag naming convention plus reusable object templates mean adding the tenth pump takes minutes instead of hours, and the twentieth engineer to touch the system can still read it.

6. Plan for security and recovery

Role-based access control, no shared operator logins for engineering functions, patch management windows agreed with operations, and — most importantly — tested restores. A backup that has never been restored is an assumption, not a plan.

7. Document as-built, not as-designed

Network diagrams, I/O lists, alarm databases and control narratives should be updated at commissioning and kept current. The cost of missing documentation is always paid later, usually during an outage.

Reliamation designs and delivers SCADA and HMI systems to these standards, from greenfield builds to modernisation of legacy platforms. Book a free consultation to review your architecture.

Frequently Asked Questions

What are the layers of a SCADA architecture?

Field devices, control layer (PLC/RTU), supervisory layer (SCADA servers and HMI), and the data/reporting layer. Each layer should be separable so failure in one does not cascade.

Do I need redundant SCADA servers?

If unplanned downtime costs more per hour than the redundancy hardware and licensing, redundancy pays for itself. Continuous-process plants almost always justify it.

How should SCADA networks be segmented?

Use a purpose-built OT network separated from IT by a DMZ, with controlled data flow for reporting traffic only. Flat shared networks are the most common risk we find.