Anyone who has spent time in a control room quickly realizes that shift operators are not short on skill. They understand their processes, often better than the process engineers who designed them. What they lack, however, is a well-designed interface. Too often, the human-machine interface presents information in a scattered, overly dense, and poorly prioritized way. And that is where problems start.
For a long time, the human-machine interface was the poor relation of automation projects. Investment went into programmable logic controllers, sensors, and field networks. The HMI was configured at the end of the project, often under tight budget constraints, and sometimes handed to someone without real operational experience. The result was cluttered process screens, inconsistent use of color with no real standards, and alarms that piled up without any clear logic. In the end, post-incident analyses often showed that the operator did have the necessary information available, but did not see it or interpret it correctly because the interface was not fit for purpose.
That era is not entirely over, but the industry has clearly shifted its approach.
The academic definition, a hardware and software system that enables a human to interact with an automated process, says very little about what this looks like in practice.
In an industrial control context, a human-machine interface is first and foremost a process overview screen: a graphical, animated representation of the plant with its pipes, tanks, valves, motors, and live values updating in real time. It also includes trend charts that show whether a temperature has been rising for the past two hours. Alarm displays show events with priority levels and timestamps. Control functions allow operators to take action, such as opening a valve, starting a pump, or adjusting a setpoint.
All of this runs on top of software layers that vary in complexity depending on the architecture: SCADA systems for distributed infrastructure, DCS for continuous processes, or hybrid solutions in large industrial sites.
Each comes with its own strengths, migration constraints, and ecosystem of integrators. Ignition, in particular, has seen rapid adoption in recent years thanks to its server-based licensing model and web-native architecture, a major advantage for teams looking to avoid the cost and complexity of deploying heavy client software on every operator workstation.
The first industrial human-machine interfaces were hardwired mimic panels. One indicator represented one physical state in the plant. It was simple, direct, and unambiguous. Operators familiar with these panels could read them almost like a language, spotting anomalies before consciously identifying them, often through subtle peripheral color changes in their field of vision.
The arrival of computerized terminals in the 1980s, followed by the rise of graphical interfaces in the 1990s, changed everything. Displays became configurable, the amount of available information exploded, and operators could suddenly monitor a hundred times more data points from a single workstation. And that is exactly where the problems started. More information does not necessarily mean better understanding. Early graphical SCADA systems often produced poorly structured interfaces with inconsistent color usage and no real standards, red everywhere, sometimes meaning normal status, sometimes an alarm, depending on how the system had been configured.
The frameworks we use today, such as the ISA-101 standard for HMI design in process automation and EEMUA 191 for alarm management, emerged in part from this collective realization. There was a need to bring order and introduce a level of design discipline that the industry had not established on its own.
Spending a night shift in a large control room is revealing in more ways than one. It quickly becomes clear that the environment imposes constraints that very few HMI designers fully take into account. Low lighting is used to preserve screen readability. Fatigue builds as the shift goes on. Rotating teams mean an operator may return to a process after a long absence and suddenly face an unfamiliar situation. Above all, there is the constant need to maintain a coherent mental model of a system that is continuously changing.
Human factors specialists refer to this as “situational awareness”, a concept borrowed from aviation and naturally adapted to safety-critical industrial environments. It describes the ability to perceive what is happening, understand what it means, and anticipate what is likely to happen next. A well-designed HMI supports situational awareness. A poorly designed one actively undermines it.
There is arguably no better indicator of industrial HMI quality than alarm management. Not because alarms are the most visible part of the system, but because they expose, in concentrated form, most of the design flaws accumulated over time.
The phenomenon of “alarm floods” is well documented in the industry. During an incident, dozens or even hundreds of alarms can trigger in rapid succession, often because each subsystem has its own alarm logic with no overall prioritization. Some facilities report more than 300 alarms in under ten minutes during a major upset. At that point, operators can no longer respond effectively. They either acknowledge alarms mechanically or, worse, stop acknowledging them altogether.
The EEMUA 191 guideline provides clear benchmarks. In normal operating conditions, an operator should not have to deal with more than 6 to 12 alarms per hour. During a process upset, the critical threshold is roughly one alarm every ten seconds. Beyond that, human processing capacity is overwhelmed. Internal studies in petrochemical plants have shown that some sites operate consistently above these limits without anyone ever formally recognizing it as a problem.
Alarm rationalization is a long and often tedious process that requires teams to revisit years of accumulated configuration. Modern HMIs increasingly provide more advanced tools to support this work, including alarm log analytics, detection of frequently recurring unresolved alarms, and context-aware suppression mechanisms based on process state.
The question comes up regularly in tenders and modernization projects: should we still think in terms of SCADA, DCS, or HMI? The most accurate answer is that these distinctions are becoming less and less relevant.
Historically, SCADA systems were used to supervise geographically dispersed assets, such as water distribution networks, gas pipelines, or electrical substations spread across hundreds of kilometers. DCS systems were designed for continuous, centralized processes, like a distillation column or a cement kiln. The HMI was the presentation layer for either of them. Today, platforms such as AVEVA System Platform or Ignition provide a unified architecture that can cover both use cases, with a common HMI layer accessible through a web browser.
This convergence has significant practical consequences. It simplifies architectures, reduces the number of systems that need to be maintained, and makes data easier to access from different types of devices. But it also creates new pressure on engineering teams. Operators accustomed to modern digital tools in their daily lives are increasingly less tolerant of HMIs with multi-second refresh delays and interfaces that feel stuck in the early 2000s. The gap between mainstream consumer digital experiences and what some industrial control systems offer is now so visible that it is starting to create training challenges in certain sectors.
The move toward web-based HMIs built on standards such as HTML5, SVG, and WebSockets represents a real technological shift for the industry. In theory, it allows process screens to run directly in a standard browser, without a heavy client application, with centralized updates handled on the server side. The maintenance benefits are real.
But this architectural openness has a downside that industrial cybersecurity teams know well. An HMI accessible through a web browser is potentially accessible from the corporate IT network, and in some cases beyond, if segmentation is not strictly enforced. Best practices therefore require strict discipline: physically separated OT and IT zones, industrial demilitarized zones (DMZs), and multi-factor authentication for all remote access. These are requirements precisely defined in the IEC 62443 standard.
Industrial cybersecurity was long treated by many operators as a theoretical concern. The prevailing argument was that OT systems are isolated, air-gapped, and therefore unreachable from the outside. Over the past few years, however, a series of documented incidents has seriously undermined that assumption.
The 2021 Oldsmar case in Florida is a good example. An attacker remotely accessed the HMI of a drinking water treatment plant and briefly increased the caustic soda dosage to dangerous levels. The intrusion was made possible by a remotely accessible HMI without strong authentication, operating on a poorly segmented network. It is a scenario that many industrial sites would struggle to confidently rule out in their own infrastructure if they were completely honest about it.
According to Claroty’s The Global State of Industrial Cybersecurity 2023, 75% of surveyed industrial organizations experienced at least one cyberattack with a direct operational impact over the previous twelve months. The most common attack vectors included remote access to HMIs and SCADA systems, particularly through poorly secured remote access tools.
Designing a good industrial HMI requires a certain degree of humility. The humility to acknowledge that the operator using the system day in, day out often understands its real-world requirements better than the engineer designing it from an office.
Bill Hollifield, author of The High Performance HMI Handbook, helped popularize a design approach focused on actual operational performance rather than aesthetics or feature richness. His recommendations can seem counterintuitive at first: mostly grayscale process screens, minimal use of bright colors, and less emphasis on raw numeric values in favor of trend-based indicators.
Behind this apparent simplicity is a strong underlying logic. If everything is highlighted, nothing stands out. If red is used for normal conditions on some equipment, it loses its value as an alarm signal. In industrial HMI design, color discipline is not a matter of preference, but a matter of safety.
Modernizing an HMI in a live industrial installation is a delicate exercise. Too often, projects begin with the ambition of a complete overhaul and end up as uncomfortable compromises, producing hybrid interfaces that inherit the drawbacks of both generations without the benefits of either.
The most effective approach, and one that is consistently confirmed by field experience, is a layered migration strategy, organized by area and by decreasing criticality. It starts with an audit of the existing system: how many alarms are triggered per hour under normal operation, which process screens are used most often, and where operators lose the most time navigating. This data helps establish real priorities, not assumptions made in engineering offices.
The design phase that follows is most successful when operators are involved from the outset.
These are questions that the people working on the process every day are best positioned to answer.
Resistance to change in these projects is often misunderstood. It is not irrational. An operator who has mastered an existing HMI, even an imperfect one, knows that the transition period is when they are most exposed and least efficient.
The HMI is the visible layer, the process screens, synoptic diagrams, and control panels that operators interact with directly. SCADA refers to the full system, including field data acquisition, communication, storage, and visualization. In practice, the terms are often used interchangeably, and modern platforms typically combine both functions within a single software environment.
ISA-101 (ANSI/ISA-101.01-2015) is the main reference for designing process HMIs. EEMUA 191 provides detailed guidance on alarm management, including quantitative benchmarks. For industrial cybersecurity, IEC 62443 is essential, and its requirements have a direct impact on how HMIs are deployed and secured.
Alarm log analysis is the first indicator. If alarm rates regularly exceed 12 per hour under normal operating conditions, there is likely a structural issue. Operator interviews are equally important, as they often reveal daily friction that has never been formally documented, such as excessive navigation steps, poorly placed information, or inconsistent use of color. These field insights are often more revealing than formal audits.
Unsecured remote access remains the primary issue, including remote desktop tools left active, shared accounts without traceability, and outdated operating systems that have not been patched for years. Targeted phishing against operators and maintenance staff is also increasingly common. The response relies on network segmentation, strong authentication, and, above all, maintaining an accurate inventory of what is actually exposed to external access.
Plant availability always takes priority. Replacing an HMI in a continuously operating facility requires maintenance windows, staff training, and a period of increased operational risk. As a result, many operators extend existing systems for as long as possible. This is understandable, but it creates software support challenges and increasing cybersecurity exposure, especially when vendors no longer provide patches. The current trend is moving toward replacement cycles of roughly 8 to 12 years.
Copyright © 2026. MOTILDE. All rights reserved.