Real World Engineering

This is a blog from the trenches—written by engineers at Maverick Technologies who are implementing and upgrading control systems every day across every industry. This isn’t what they teach you in engineering school. These are lessons learned from years on the job, encountering the obstacles and issues that are part of the real world of control and process engineering.

Real World Engineering

Real-world HMI design considerations for improved safety

Real-world scenarios need to be taken into account when designing HMI. There should be no unnecessary functions that can potentially cause safety issues like they did for an airliner at Nashville International Airport in 2015.

June 20, 2017


In December 2015, a Southwest Airlines Boeing 737-300 turned off the runway and drove into a ditch at the Nashville International Airport. The tower controller accidentally turned off the taxiway lights.

The root cause of the matter was a screen saver function on the touch-screen lighting control panels in the air traffic control tower, which timed out and went blank after approximately 5 minutes of inactivity. The blank screen, according to the NTSB's final report on the accident, prevented, "The tower controllers from having an immediate visual reference to the status of the airfield lighting."

When commissioning a human-machine interface (HMI), is time spent to observe the real world function? Looking for unexpected results of features that might not be part of the design? In this example it was hardware screen saver feature. Some workstations still have this feature. Was it part of the design or just a feature that was left on after installation? Every feature on a HMI should be deliberate, and included as part of the design. If the feature is not needed, it should be removed or disabled.

In the same event, a poor aircraft HMI contributed to injuries to nine of 138 passengers and crew on board. The injuries occurred during the evacuation using the aircraft escape slides. The blaring of a "gear unsafe" alarm in the cockpit complicated this process. The NTSB report said that the horn, "Could not be silenced without disabling a circuit breaker or running a checklist procedure for an unrelated scenario."

Are these audible alarms unnecessary? Have they been checked for sound level? For an audible alarm to be useful, it must be at least 10 dB above the ambient background noise in order to be easily heard. When an alarm is too loud, it provides distraction and can impede response to an emergency.

When designing a HMI or an entire control room, take a step back and gather the whole picture. Evaluate the cause and effect diagram with the entire operating team, and perform actual tests of every audible alarm. This will go a long way to improving HMI and the operational safety and alarm response.

This post was written by Bruce Billedeaux. Bruce is a senior consultant at Maverick Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. Maverick delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization, and more.

Maverick Technologies is a CSIA member as of 6/20/2017.


click me