Planning the interface between an HMI (human-machine interface) and a PLC is a data-architecture task: the tags the PLC exposes, the screens operators navigate, the alarms that demand response, the network path that carries them, and the control boundaries that decide what an operator can safely command. Interface projects fail in the planning gaps — tag lists that drift from code, alarms that flood screens, permission models that nobody administers. This guide structures HMI-PLC planning into its working parts — tag strategy, screen hierarchy, alarm philosophy, network paths, wiring and cabinet context, and the testing that proves the interface — with the standards that govern each layer. It supports design and procurement discussions; final installation, code, safety, testing, cybersecurity, and qualified engineering requirements must be confirmed for the actual project.
Tag strategy: the contract between code and screen
Tags are the interface. A disciplined tag database names every PLC variable used by the HMI (and usually SCADA) with consistent conventions — device, function, and signal type encoded in the name — and records each tag’s data type, scaling, engineering units, and access level. Analog values carry scaling data in one place; status values carry decoded states, not raw integers displayed as numbers. The tag list is version-controlled alongside the PLC code because the two are one system: every code revision that touches a tag must update the HMI project, and acceptance tests verify tags against the I/O list point by point. Projects that skip this discipline discover the drift at commissioning, one unexplained number at a time.
Screen hierarchy designed for operators under stress
| Level | Content | Design intent |
|---|---|---|
| Overview | Line or machine state, running/stopped/faulted at a glance | Situation awareness in seconds |
| Unit / area | Machine sections or process areas with key values | Navigate to the problem area |
| Detail | Device-level status, manual commands, tuning parameters | Act with context |
| Diagnostics / maintenance | Fault history, I/O forcing (restricted), counters | Technician workspace, permission-gated |
The hierarchy principle: three interactions or fewer from any alarm to the screen where it can be acted on. Navigation that buries the cause of a stop five screens deep converts a two-minute reset into a shift-long hunt.
Alarm philosophy: fewer, meaningful, owned
An alarm that does not demand a response is noise competing with the ones that do. Plan alarms as a system: every alarm has a defined operator action, priority, and deadband; chattering and stale alarms are engineered out at design (time delays, hysteresis); and alarm floods during shutdowns are anticipated with suppression logic or shelving. The ISA-18.2 / IEC 62682 alarm-management framework — identification, rationalization, performance monitoring — applies at project scale: rationalize the alarm list against the control narrative before implementation, not after six months of operator complaints. Record the alarm matrix (condition, priority, message text, response) as a deliverable, and test it: every configured alarm is forced at FAT and appears on screen with correct text and priority.
Network paths and protocols
| Path | Typical protocols | Planning points |
|---|---|---|
| PLC to HMI panel | Native Ethernet protocols, Modbus TCP, industrial Ethernet variants | Segmented machine network or VLAN; deterministic needs stated |
| PLC to field devices | PROFINET, EtherNet/IP, Modbus RTU/TCP, fieldbuses | Device diagnostics mapped to tags; failure behavior defined |
| HMI/PLC upward to SCADA/MES | OPC UA, MQTT-class publish-subscribe | Namespace and data model agreed with IT; cybersecurity zones per IEC 62443 |
| Remote access | Managed VPN or gateway with logging | Authentication, accountability, and network separation designed in |
Every network boundary is also a cybersecurity boundary: the IEC 62443 series structures zones and conduits, and any remote-access provision belongs in the design with authentication and logging — not as a bolt-on modem discovered during a service call.
Control boundaries and permissions
Decide, in writing, what the HMI can command versus display. Manual commands exist per mode; setpoints have authorized ranges enforced in PLC logic (never only in screen validation); parameter pages and forcing are permission-gated by role; and safety functions are implemented in the safety layer, with the HMI showing their status but never executing them. The permission model — users, roles, credentials, and who administers them — is an operational deliverable: an HMI shipped with default credentials and no owner has an unowned back door, whatever the project schedule said.
Define the system boundary
Separate the control cabinet, field devices, PLC, HMI or supervisory software, networks, site conditions, and responsible engineering disciplines before selecting a configuration.
Inputs to document
| Input | Why it matters |
|---|---|
| Equipment and interfaces | Sets layout, entries, clearances, signals, power, network paths, and service access. |
| Process and environment | Guides sensor choice, material, heat, corrosion, moisture, and exposure review. |
| Installation and maintenance | Controls mounting, isolation, access, labels, replacement, and service sequence. |
| Validation and records | Defines drawings, testing, alarm checks, software handover, and supplier documentation. |
Do not transfer a competitor automation performance, cybersecurity, safety, or compliance claim to the complete project without project-specific evidence.
Wiring, cabinet, and standards context
The HMI panel mounts in the control cabinet door or on an operator console, wired to the PLC over the planned network path — the cabinet itself is engineered per the machine panel standards: IEC 60204-1 with IEC 61439-1/-2 assemblies in IEC markets, NFPA 79 with UL 508A in North America. PLC programming follows IEC 61131-3. HMI design practice references ISA-101 guidance on performance-oriented screens (hierarchy, color discipline, situation-awareness principles), and alarm management follows ISA-18.2 / IEC 62682 as noted above. Cybersecurity for the interface layers follows IEC 62443. The panel-side engineering around the PLC is covered in our PLC control panel applications guide.
Frequently asked questions
How many screens is right for one machine?
As few as the hierarchy needs — typically one overview, a few unit screens, and diagnostics. Screen count grows with machine complexity, not with developer enthusiasm; if operators ask for a printed map of your navigation, the hierarchy failed.
Where should scaling live, PLC or HMI?
In one defined place — convention favors the PLC exposing engineering units, with the HMI displaying tags. Scaling duplicated in both places eventually disagrees with itself.
What is an acceptable alarm rate?
Management frameworks target on the order of one alarm per ten minutes per operator as a sustainable steady-state, with defined burst handling during upsets — the actionable point is that rates are monitored against rationalized design, and floods are engineered down, not tolerated.
Should the HMI write setpoints directly?
Writes go through PLC logic that enforces ranges, interlocks, and mode conditions — the screen is a window, not the guard. Validation done only in the HMI is bypassed the first time someone edits the screen project.
How do we test the interface completely?
Tag-by-tag verification against the I/O list, every alarm forced and observed, permission matrix exercised per role, and failure scenarios — cable pull, PLC stop, HMI restart — proving the defined fallback behavior. The follow-up test most projects skip: operator walkthrough with the actual future users, which reliably finds the navigation and wording problems engineering never will.
Procurement scenarios
For a first machine with an engineered HMI, order the interface deliverables explicitly — tag database, alarm matrix with rationale, screen set as reviewable designs before code — and hold a mid-project review at the screen-design stage, when changes cost hours rather than rework. For plants standardizing multiple machines, fix one HMI platform and one tag-naming convention across all suppliers, and make both contractual; the standard is what makes machine three’s screens legible to the operators of machine one. For export deliveries, confirm language versions, keyboard/layout implications, and the cybersecurity documentation for remote access at order stage — localization and access questions discovered at commissioning are the recurring schedule cost in this product class.
ElectricalCabinet.net engineers HMI-PLC interfaces as part of complete control packages — see the PLC machinery guide for the control side and PLC panel applications for the enclosure engineering.
EN