HMI, Alarms, Data and Cybersecurity
Operator screens, alarm management and its numbers, recipes and user levels, logging, and securing the control network.
Designing the screens
The human-machine interface (HMI) is how operators see and control the machine. Design it for the operator, not the programmer: someone tired, in a noisy plant, at the end of a shift, who has to decide what to do in seconds. ISA-101 is the standard guide. A well-designed HMI shows the state of the machine at a glance, makes the next action obvious and the abnormal conditions stand out.
| Level | Content | Notes |
|---|---|---|
| Level 1 | Overview of the whole machine: state, key numbers, alarms | Always visible; no more than about 1 to 2 screens |
| Level 2 | An area or a unit: controls and values | Where the operator works |
| Level 3 | Detail of one device: set-points, diagnostics, interlocks | On demand, for maintenance |
| Level 4 | Help, trends, history, maintenance pages | Rarely used but vital |
- Use gray and calm colors for normal conditions and reserve bright colors (red, amber) for abnormal ones, so that a problem stands out. A screen full of bright colors has no way to show urgency.
- Show values with units, ranges and limits, and the state of devices by shape and text as well as by color (about 8 % of men have a color-vision deficiency).
- Use consistent symbols, layout and names across all screens, from the same library; a motor looks the same everywhere.
- Show trends where a value’s history matters (temperature, pressure) and a clear mode and state banner (auto, manual, stopped, fault).
- Fewer clicks for common actions, confirmation only for dangerous ones, and a clear way back; no hidden menus.
- Make the text large enough to read from where the operator stands, in the language of the user.
- Test with the operators using a prototype: they find problems the designers cannot see.
Alarm management
An alarm is a signal that tells the operator something needs a response, with a consequence if it is ignored. ISA-18.2 (and IEC 62682) set out the life cycle: philosophy, identification, rationalization, design, implementation, operation, monitoring and change control. The rule of thumb: every alarm needs an action, an owner and a priority; if no action is needed, it is not an alarm but a message or a log entry.
| Priority | Meaning | Typical share of alarms (ISA-18.2 guidance) |
|---|---|---|
| Critical | Immediate action to avoid serious consequences | About 5 % |
| High | Prompt action | About 15 % |
| Medium | Action within minutes | About 30 % |
| Low | Awareness; action when convenient | About 50 % |
- Each alarm records: the cause, the consequence, the corrective action, the response time and the owner.
- Use deadband and delay so that a value that hovers at the limit does not chatter on and off.
- Suppress by state: an alarm that is meaningless when the machine is stopped should be suppressed then, by logic that is itself documented.
- Stale and standing alarms are a sign of trouble: review them.
- First-out indication in a trip sequence shows the alarm that started the cascade.
- Changes to an alarm (limits, priorities) go through change control (see Documentation, Handover and Lifecycle).
The numbers of alarms
The ISA-18.2 guidance for a manageable load is, on average, no more than about one alarm per operator per 10 minutes (about 144 a day), a peak of no more than 10 in any 10 minutes, and no more than a few intervals a day over that. More than that and the operator cannot respond to each one.
Worked example: reading an alarm log
- The log has 818 alarms in 24 hours, an average of 5.7 per 10 minutes and 34.1 per hour. The target is about 144 a day; the log is 5.7 times that.
- 10 of 144 intervals (6.9 %) exceed 10 per 10 minutes, with a peak of 33. These floods hold 300 alarms, 37 % of the day’s total, from a few events: the cascade after a trip.
- At about 10 seconds to read and respond to each, 6 alarms an hour is a workload of 1.7 %, which is fine; but in a flood of 30 in 10 minutes the operator would need 30 × 10 s = 5 minutes of continuous attention in a 10-minute window, while still running the process: in practice too much, so the important alarm is lost among the rest.
- The cure is rationalization: of 1 200 configured alarms, a review might find that only about 22 % (264) need an operator action; the rest become messages, are suppressed by state, or get a deadband and a delay. A trip should raise the first-out alarm and suppress the consequential ones.
- Chattering alarms are often 30 % of the load: a limit of 80 on a signal with noise of ±0.6 crosses the limit (say) 18 times in a minute without a deadband; with a deadband of 2.0 (return at 78) it crosses 1 time.
| Priority | Share | At 144 alarms a day |
|---|---|---|
| Critical | 5 % | 7 per day |
| High | 15 % | 22 per day |
| Medium | 30 % | 43 per day |
| Low | 50 % | 72 per day |
Users, recipes and changes
| User level | Can do | Protection |
|---|---|---|
| Operator | Start, stop, acknowledge alarms, select a recipe | No password, or a badge |
| Supervisor | Change set-points within limits, edit recipes, reset counters | Password |
| Maintenance | Manual mode, device tests, bypass with a record | Password and a log |
| Engineer | Change the program and the configuration | Strong password, locked cabinet |
- Separate the rights: an operator should not be able to change limits, a supervisor not the program, and each change should be logged with who, when and the old and new value.
- Recipes (product settings) are data, not code: store them in the controller or a database, with limits on every value, a version and an approval for changes.
- Confirm dangerous actions and show the effect of a setting before it is applied.
- Audit trails are a requirement in regulated industries (21 CFR Part 11, EU Annex 11): electronic records and signatures with unique users, secure time stamps and no way to delete the history.
Worked example: the size of a recipe store
40 recipes of 60 values at 8 bytes each is 19 200 bytes (19.2 kB): trivial for a controller or a database. The effort is not the storage but the validation and change control: who may change a value, within what limits, and how it is shown that the right recipe ran with a batch.
Logging and data
- Log what you will need later: production counts and rejects, downtime with reasons, the process values that explain a quality problem, alarms and operator actions, and the versions of programs and recipes.
- Time-stamp at the source with a synchronized clock (see Time Stamps and Clocks), and send the data in a structured way (OPC UA, MQTT; see Industrial Communication).
- Store with a plan: a historian or a database with downsampling and retention (see Storage, Formats and Data Rates).
- Plan the dashboards and reports with the users: OEE, downtime Pareto, quality trends (see Telemetry, Databases and Dashboards).
Worked example: historian volume
500 tags logged once a second at 12 bytes per value (a time stamp, a value and a quality code) produce 500 × 86 400 × 12 = 518.4 MB a day. With a deadband (store a value only when it changes by a set amount) the volume falls to about 12 %: 62.2 MB a day, 22.71 GB a year. A year of that is nothing for a modern disk: the cost is in choosing, naming, checking and using the tags (see the Planning page of the Data Logging guide).
Cybersecurity
A machine on a network can be attacked, or broken by a mistake, from far away. The standard framework is IEC 62443: divide the system into zones of similar security needs, connect them only through controlled conduits, give each zone a target security level, and keep the risk managed through the life of the machine. The aims are the same as for safety: assess the risk, reduce it with layers of defense, verify, and keep it under change control.
- Never expose a controller to the internet. Remote access goes through a gateway or VPN with strong authentication, logging and a way to switch it off.
- Segment the network: the machine network separate from the plant and office networks, with a firewall that allows only the traffic needed.
- Least privilege and strong accounts: unique users, no shared or default passwords, administrator rights for few people.
- Keep the software current and manage patching with the supplier; test updates on a spare first.
- Protect the engineering laptop and the USB ports: a common route for malware is a contractor’s laptop or a memory stick.
- Turn off what you do not use: unused ports, services and protocols (web servers, FTP, discovery).
- Monitor and log access and changes, and keep backups that an attacker cannot reach.
Zones and conduits
| Zone | Level (Purdue) | Typical contents |
|---|---|---|
| Enterprise / plant network | 4 | IT firewall, internet access |
| Demilitarized zone (DMZ) | 3.5 | Historian replica, remote access gateway, patch server |
| Supervisory / site operations | 3 | SCADA, engineering stations |
| Control zone (cell / line) | 2 | PLCs, HMIs, drives, switches |
| Field zone | 1 | Sensors, I/O, safety devices |
The details of networks, VLANs and firewalls are in Industrial Communication. For a machine, the practical result is: a firewall or a router between the machine’s control network and the plant network, the PLC and HMI on a private subnet, and one defined path for data (OPC UA or MQTT, outbound) and one for support (a VPN with approval).
Passwords, remote access and patching
Worked example: why length matters
- An 8-character password of mixed letters and digits (62 symbols) has 628 = 218 340 105 584 896 possibilities. An attacker testing 10 billion guesses a second (offline, against a stolen hash) gets through all of them in 6 hours.
- A 12-character one has 3.2e+21 possibilities: 10 242 years at the same rate. Length beats complexity: use long passphrases, a password manager, and no defaults.
- Online attacks are slower but lock-out and rate limits matter: make sure the device has them.
- A known vulnerability is actively exploited within weeks of publication; if patches can be applied only in 4 maintenance windows a year (an average wait of 46 days), the machine stays exposed for about that long. Reduce the exposure by network design (segmentation) when patching is slow.
- Use certificates and encrypted protocols where supported (OPC UA with security, TLS for MQTT, SSH instead of Telnet).
- Keep a list of every device, its software version, its network addresses and its support status (see Documentation, Handover and Lifecycle).
- Plan for incident response: who is called, how the machine is isolated, how it is restored from a known-good backup.
Backup and recovery
- Back up every program and configuration: the PLC, HMI, drives, safety controller, switches, firewall, SCADA, with the version of the engineering tools.
- Keep copies offline or immutable, so that malware that encrypts the network cannot reach them, and test a restore from them on a spare.
- Write the recovery procedure and practice it: it is the difference between an hour and a week of downtime.
- Include the passwords and licenses (in a secure place) with the backup.
Related
- System Integration: the overview of this guide.
- System Architecture and Component Selection: networks and zones in the architecture.
- Documentation, Handover and Lifecycle: change control and backups.
- Industrial Communication and Data Logging.
FAQ
How many alarms are too many?
ISA-18.2 guidance is on average about one alarm per operator per 10 minutes, with no more than 10 in any 10-minute period. Many plants have far more; rationalization (removing, suppressing and re-prioritizing) brings the number down.
What makes a good HMI?
A clear overview, calm colors for normal conditions and bright ones for abnormal, consistent symbols, values with units and limits, few clicks for common actions, and testing with the real operators.
Is a firewall enough for cybersecurity?
No. It is one layer. Combine segmentation, strong accounts, patching, backups, monitoring and a response plan, as IEC 62443 describes.
Should operators be able to change set-points?
Within limits and with a log, for the values they need to run the process. Changes to limits, programs and configuration belong to higher user levels.
References
- ISA-101, Human-machine interfaces for process automation systems; ISA-18.2 and IEC 62682, Management of alarm systems; EEMUA 191.
- IEC 62443 (all parts), Industrial communication networks: IT security for networks and systems; NIST SP 800-82, Guide to operational technology security.
- 21 CFR Part 11 and EU GMP Annex 11 (electronic records) for regulated industries; the HMI and SCADA vendors’ style guides.
Last reviewed: October 2026. Alarm numbers and guesses per second are illustrative: use the standard’s guidance and your plant’s data.