What is a high performance HMI, I hear you ask?
Over the last few decades Human Machine Interfaces (HMIs) have evolved to the needs of the ever changing industry requirements. Factors that have influenced these changes are:
- Increased size and complexity
- Increased volumes and capacity
- Increased levels of automation
- Staffing/Education challengers
- Diversity and turnover of staff
- Remote operations
Historically, in the 70’s, control boards were large banks of dials, lights and switches which progressed to digital monitors with graphical representations of the dials and switches, then to 3D plant layouts.
This evolution of the HMI was intended to replace the complex monitoring requirements of the analogue dials, lights and switches but in fact only increased the complexity of information to the operator, causing information overload.
High Performance HMI
As an example, modern HMI screens typically look like the one below left. Although pleasant to see, much of the graphic is irrelevant to the control and only adds noise to the operator. Removing the unnecessary graphics you can see there is not a lot actually being displayed. The pleasant look only adds noise to the operator overloading them visually so they don’t see the underlying data.
In the above example, after removing the noise, what is left isn’t all that informative. Sure, you know the gas pressure is 120. However, is that bar, milli-bars, psi or even kPa? There is an indication that the pressure is high. What does this mean? What should it be? Is it still going up or on its way back down? How far away from the intended target pressure is it? Is it just outside of range or is the plant about to explode? None of these questions can be answered without some background knowledge to the process.
Information is data in context made useful. Data on its own is relatively meaningless.
The idea of a high performance HMI is to give context to the data being displayed. To highlight all the ways of doing this through the new Situational Awareness graphics library would be too much detail to go into here. However, as an example of a SA control have a look at the following:
Here is an example of the improved operator feedback that can be achieved by using situational awareness.
Situational Awareness Alarming
In addition to providing context to existing information, the SA graphic library also provides new controls for displaying alarms. As you might have noticed from the above example of a level indication control, the industry trend has shifted away from the traditional colourful displays and is now moving back to monochrome displays. The philosophy around this is that on an overview screen there should be no colour, apart from grey scale to indicate normal running or stopped conditions, if everything is running as expected.
Colour is only introduced if an abnormal condition is present as in the overview screen below. Without any prior knowledge of the plant an observer can immediately know that there is something wrong with the Turbidity level in the water plant as their eye is drawn directly to the yellow flashing border around the level indicator. Also, because of the added context given to the 0.50 value the observer can deduce that the value is way above the target value and therefore very high.
In this context colour becomes very important and should therefore only mean one thing so as not to confuse the operator. In addition to this we also need to limit the amount of alarming that the operator is bombarded with. In the past we would typically alarm everything to the alarm logger no matter how trivial, but now we need to only alarm on what is vital to running the plant and log other situations as events. So, what is an alarm?
Alarm Definition
As per the ISA 18.2 standard – An alarm is an audible and/or visual means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a user response. If an alarm situation can be resolved automatically without user intervention it should not be raised as an alarm but rather logged as an event.
A response must be more than simply acknowledging the alarm. A response must involve requiring the operator to action something to correct the situation. Therefore alarms need to be also categorised based on required response times.
It is imperative that alarms:
- Have sufficient detail for the operator to act upon them
- Do not overwhelm the operator
- Are not duplicated
- Do not become used for simply indicated normal situations
- The response times should be determined from the operator’s perspective
- If in doubt what level the alarm should be, err on the side of less severity.
Categorising Alarms
Here is an example of how we break down alarms into the required categories. An important step in the setup of alarms is to stop, think and standardize the implementation to keep it consistent.
All available alarms are categorized into Critical, High, Medium and Low.
Best Practices: Alarm Signaling in the HMI Displays
Here is shown the same pressure indicator as described earlier showing data with context, along with alarm borders with their various alarm conditions. Right away an observer can see which alarm is of the highest priority and requires immediate attention. In addition to this, because they can observe where the present value is at in relation to operational parameters, they can act on potential problems before they go into alarm. For example, if used in conjunction with a pen trend control, the operator can visualize how the value is changing over time and can predict where it is heading long before the situation gets out of control.
Benefits, include 40% reduction in time to respond to typical alarms
Below is a table that shows the benefits that can be achieved by adopting these standards.
Summary
Industry is moving towards High Performance HMIs, where the Situational Awareness philosophy is being broadly adopted by leading DCS and automation suppliers like Rockwell and Wonderware/Schneider Electric.
By adopting and incorporating the philosophies inherent in Situational Awareness and the associated methodologies in building High Performance HMIs, there is a measurable increase in user response time to detecting and handling plant critical alarms whilst also decreasing overall downtime associated with failures and undetected issues.
Operators are more likely to be alerted to changing situations prior to them becoming critical, averting alarm conditions and possible damage to plant or waste of product. This is achieved by simplified alarming using contextualized data.
By Chris Van Duin & Scott Deruniec
Reference Material
