HMI design is trending toward a collaborative effort between owner, end user, and integrator.
By: Allan Evora
An HMI (Human Machine Interface) is a collection of hardware (computers) and software used to monitor and interact with the control system and processes at your facility.
ISA-101 a great standard defined by the International Society of Automation that covers the HMI lifecycle. It’s really a change in philosophy about how HMIs should be designed. All control system integrators should be moving towards it.
Basically, the standard provides guidance on how to develop, design, build, program, and operate HMIs to achieve a safer, more effective facility under any operating condition.
HMIs are overly complex
It’s widely known that HMIs have become overly complex. Getting relevant information in front of the operator has become harder and harder with the amount of information and data coming from the control system. Unfortunately, the amount of data will only get worse with IIoT.
Right now, control system integrators are plagued by the status quo. The standard has been flashy graphics that look cool, but don’t provide any more context or information than a simple on or off indication.
Take a look at this HMI. It’s hard to tell what’s wrong with the system, isn’t it? Your attention is all over the place.
These types of HMIs are not conducive to facilitating an optimal experience.
A user who isn’t as familiar with the system could actually miss something, which might cause a problem to escalate, simply because he couldn’t distinguish it. This is especially apparent with new hires who haven’t been involved with the facility or process. They’re still responsible for responding to abnormal situations.
An HMI designed with ISA-101 principles, however, improves a user’s ability to predict, diagnose, and properly respond to abnormal situations.
Optimized HMI
An optimized HMI, such as one that uses situational awareness, only highlights problem areas. Processes working fine are suppressed. In this example, it’s easy to see that the level in the tank is low, a fault related to gas pressure, and low pressure in the fresh air intake.
Situational awareness is just one type of philosophy that addresses how HMI design must improve the user’s ability to diagnose and properly respond to problems.
By making HMIs less noisy, a safer environment is created. Relevant conditions and a quicker response time could mean the difference between a process that goes out of control and possibly endangers human lives, and a process that doesn’t.
The HMI lifecycle
It’s not all just about situational awareness, however. ISA-101 outlines an entirely new HMI lifecycle to be considered by both the customer and the control systems integrator.
Develop a philosophy
The first step in the lifecycle is for a customer to develop their HMI philosophy. In the past, this was done by the control system integrator, but ISA-101 is putting more of an emphasis on customizing an HMI to a particular user. After all, the type of resources available to a facility, how those facilities are managed, and the skillset of the end users is different at every facility.
Integrators will have to stop forcing their own standard, and be more open toward incorporating HMI standards that align well with a particular owner’s HMI philosophy.
Part of this process is understanding exactly who the stakeholders are. One of the reasons HMIs were developed so colorfully in the past is because upper management (buyers who write the checks, not users), thought color/animation looked really cool. But end users don’t necessarily value flashiness.
With this new philosophy, a control system integrator might have to satisfy a few different stakeholder’s needs.
For example, on a recent project, we were asked to utilize the ISA-101 standard. We weren’t even 25% into the project, when the facility owner told us he still wants a pretty screen with 3-D pipe renderings and high-level status info. Turns out, in order to fulfill his goal of building similar facilities, he has to attract investors. He understands that users will still use the ISA-101 approved HMI, but needs to be able to switch to a “sexy” HMI when investors tour the facility.
After a customer develops their philosophy, the control system integrator should be able to sit down with owners and users and get answers to questions like:
- What’s your security philosophy?
- What’s your ultimate goal for the facility?
- Who are the stakeholders?
- Is the HMI strictly in a control room, or are users also using tablets?
- Who has access to what type of information?
A note about security:
When your HMI provides the ability to change or control a particular element, security must be taken into account. For example, many electrical distribution systems have ability to open and close circuit breakers, which would deenergize anything downstream of the breaker. That may not be a capability you want everyone in your facility to have access to.
In addition, any critical control command should include the Select Before Operate prompt that asks the operator if they are sure before executing the command.
Develop a style guide
A style guide determines how the control system integrator will stylize the HMI. It’s the embodiment of how you implement your philosophy.
The key is consistency. It should provide guidance on colors, alarm indications, on/off states, symbols, navigation, and ways to provide context to users.
Context is especially important. Instead of displaying analog values, it’s important to show trends. A number by itself doesn’t provide context. If the value is represented by a line chart that shows past values, a user has some indication of what will happen in the future. If he/she sees the value is trending up, they may be able to predict an action in order to prevent an important process parameter going outside its range.
Perhaps your philosophy is: I don’t want users to need more than three clicks to get anywhere in the HMI. In order to implement that philosophy, your style guide may dictate what type of navigation you can use (e.g., a navigation tree or buttons on the bottom.)
Develop a library/toolkit
The last step to the HMI lifecycle is developing a library or toolkit, which is completed by the control system integrator.
We create symbols, representations, navigation, and put it in a library. This is very similar to object-oriented programming. It gives the integrator the ability to rapidly develop an application, because they can use pre-created symbols.
Most integrators develop a library of objects they could reuse with more than one customer. Technically, this reduces the cost of developing an HMI. However, with ISA-101, any particular integrator’s library might not align with the customer’s philosophy or style guide.
This step is a HUGE shift in how integrator’s think.
Having a toolkit is especially important when an owner has multiple systems. For example, we have a current project with a large utility. They already developed standards before we became a partner. Now, we can use those pre-developed libraries and toolkits to deliver an HMI for a new solar farm in a more cost-effective manner because our customer already invested the resources.
As an owner, if part of your strategy is having multiple partners or system implementers, this standard will greatly benefit you in making sure your end users or operators have a common experience.
HMI design should involve both the customer and integrator
Steve Jobs once said, “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” This philosophy might work when developing a consumer product that has to appeal to the masses, but has no place when developing an HMI that will incorporate a customer’s specific standards and design philosophies. Systems integrators must engage the customer.
Developing an HMI should be a collaborative process. The status quo is moving toward ISA-101. With more emphasis on involving the end user in the design or development of philosophy, comes a move toward more effective HMIs.
