HMI & SCADA

HMI vs SCADA — the essential distinction

The terms HMI and SCADA are often used interchangeably, but they describe different scopes of operator interface. Understanding the difference prevents over-engineering small applications and under-engineering large ones.

An HMI (Human–Machine Interface) is an operator interface for a single machine or cell. It shows live process values, allows the operator to issue commands (start, stop, setpoint changes), and usually displays an active alarm list. Hardware HMIs are dedicated touch panels (typically 4 to 21 inches) with embedded software; software HMIs run on industrial PCs or thin clients. An HMI communicates with one or a small number of PLCs, usually via a direct Ethernet or serial connection.

A SCADA (Supervisory Control and Data Acquisition) system is a plant-wide or geographically distributed architecture. It collects data from many PLCs, RTUs, or field devices via a supervisory network, presents it to operators through multiple workstations, stores it in a process historian, and supports control commands. SCADA systems include alarm management servers, trending clients, report generation, and often integration with MES or ERP systems. The "supervisory" in SCADA is key — a SCADA system supervises; it does not directly execute the control logic that runs on the PLCs below it.

The High-Performance HMI philosophy

Traditional operator displays filled screens with saturated colours, animated graphics, and 3D effects that looked impressive but were hard to use in abnormal situations. The High-Performance HMI (HPHMI) approach, documented by the ASM Consortium and aligned with ISA-101, takes the opposite philosophy: grey backgrounds, muted colours for normal states, and colour reserved for abnormal conditions so that problems stand out immediately.

Key HPHMI display principles include:

• Minimal animation: Static displays are faster to read and less fatiguing than moving graphics. Animate only what changes in the real process.
• Colour for abnormal state only: Use grey, dark blue, and white for normal running. Reserve red for alarms, yellow for warnings, and green for confirmed normal after an abnormal state.
• Trend displays visible at all times: Process trends should be one click or no clicks away from any process view. Operators who can only see current values cannot detect gradual drift.
• Consistent navigation: Every screen should have the same navigation structure. An operator responding to an alarm at 2 AM should not have to hunt for the right screen.
• Overview → Group → Unit → Detail hierarchy: Screens should be navigable from plant overview down to individual device level in a consistent hierarchy.

Alarm management to ISA-18.2

Poorly managed alarm systems are a significant contributor to industrial incidents. The Texas City refinery disaster (2005) and the Three Mile Island incident (1979) both involved operators overwhelmed by alarm floods during abnormal situations. ISA-18.2 (Alarm Management for the Process Industries) provides a lifecycle framework for designing, implementing, and maintaining alarm systems.

The ISA-18.2 alarm philosophy starts with a definition: an alarm is "an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a response." The key word is response — if no action is required or possible, it is not an alarm and should be removed or reclassified.

Key alarm rationalisation principles:

• Alarm rate benchmark: ISA-18.2 targets a maximum of 1 alarm per 10 minutes under normal conditions. More than 10 per minute constitutes a "flood" requiring investigation.
• Priority: Use no more than three priorities (Critical/High/Medium) in most systems. Fewer priorities means operators can immediately understand the urgency.
• Dead band: Every alarm setpoint needs an appropriate dead band to prevent chattering alarms as a process variable oscillates near the threshold.
• Shelving vs suppression: Shelving hides an alarm temporarily (with a timeout) when it cannot be acted on; suppression hides it based on process state. Both must be logged.

Historian architecture and configuration

A process historian is a database optimised for time-series data. It collects tag values from PLCs and controllers, stores them efficiently using compression algorithms, and makes them available for trending, reporting, and analysis.

The two dominant historian platforms in industrial automation are OSIsoft PI (now AVEVA PI System) and Wonderware Historian (now AVEVA Historian). Both use a client-server architecture: a data collection server (interface nodes) collect data from PLCs via OPC DA, OPC UA, or proprietary protocols, and forward it to the historian server. Trend clients and report tools query the server.

Key historian configuration decisions:

• Sample rate vs exception-based reporting: Historians can collect at a fixed rate (every 1 second) or use exception-based reporting where values are only stored when they change beyond a deadband. Exception reporting saves storage and network bandwidth; fixed-rate sampling simplifies analysis.
• Compression: Swinging-door compression (the default in PI System) stores only the minimum points needed to reconstruct the trend within a specified deviation. It dramatically reduces storage at the cost of some fidelity for slowly changing signals.
• Event frames / batch records: Link time-series data to production records (batch number, shift, product code) so that process data can be retrieved in the context of the events that caused it.

Platform notes

FactoryTalk View (Rockwell Automation)

FactoryTalk View Site Edition (FT View SE) is Rockwell's SCADA-level HMI platform, running on Windows with redundant server support. FactoryTalk View Machine Edition (FT View ME) is the embedded HMI platform for PanelView terminals. Both use RSLinx Classic or FT Linx for PLC communication. FT View SE integrates with FactoryTalk Historian (PI System-based) for data logging.

Ignition (Inductive Automation)

Ignition is a software-based SCADA/HMI platform with a subscription licensing model that includes unlimited clients and tags. It runs on Windows, Linux, and macOS; clients are HTML5 web applications (Perspective module) requiring no client installation. Ignition uses the Cirrus Link MQTT modules for cloud connectivity and supports OPC UA natively. Popular for new installations due to its lower per-client licensing cost.

Siemens WinCC

WinCC (Windows Control Centre) comes in several editions: WinCC Runtime (standalone), WinCC Runtime Professional (TIA Portal integrated), and WinCC Open Architecture (WinCC OA, formerly PVSS, for very large distributed systems). WinCC is deeply integrated with TIA Portal for Siemens S7 PLC projects but supports OPC UA for non-Siemens devices.