July 17, 2023
The gunfire from the attacking Iranian gunboats had subsided barely minutes ago as the radar operator stared intently at the USS Vincennes’s combat display system.
The adrenaline from the engagement was only just starting to dwindle when an unidentified aircraft appeared on-screen taking off from the joint military and civil airport, Bandar Abbas, in Iran. Amidst the clutter of onscreen data, two pieces were missing: the aircraft’s IFF squawk and its altitude.
In order to confirm whether this was friend or foe, the operator needed to pull up a separate work system on a much smaller screen, but in the heat of the moment the process was rushed and the call was made to engage the aircraft.
Seconds later a pair of MH200 missiles streaked out of the Ticonderoga’s vertical launch system colliding with Iran Air Flight 655 and leaving 290 civilians dead.
The radar system in question was the Raytheon Aegis combat defence system, one which provides a real-world case of where HMI failures have directly led to the deaths of innocent people.
It may seem a tad dramatic to state that this tragedy was almost entirely down to bad UI (user interface), but the numerous investigations done in the aftermath of it will tell you exactly that; for something like a ship to rely on information provided through an onboard interface, that information must be clear, accurate, and easily obtainable, and the Aegis system on the USS Vincennes was the antithesis of this.
Mission critical systems often do their job with minimal user input, and it’s only when used in situations of extreme duress that usability flaws can have serious consequences.
When the MV Derbyshire sank in 1980, inaccessible information and poor wheelhouse controls were deemed to be a large contributing factor to the crew’s inability to understand the ship’s integrity in the extreme weather conditions which eventually led to its sinking.
Having worked extensively in the automotive industry and being at the forefront of HMI evolution over the past decade, we at Conjure are immensely interested in how this evolution translates to other industries within the mobility sphere.
Firstly, however, we must unpack the history and evolution of HMI as a concept and as a practice in order to fully understand why it’s become such an integral part of the operation of machinery and the user experience.
Originally, prior to the first iterations of HMIs, things like punch-cards were used for data storage tasks and one had to type text commands into a command-line interface in order to instruct machines to perform particular tasks.
This was a lengthy process of course, not least because of the abundance of commands that had to be memorised in order for productivity to be anywhere near “quick”, but also because if a spelling mistake or anything minor like this was made, the programmer would have to retype it until it was correct.
It wasn’t until Ivan Sutherland and Xerox’s Palo Alto Research Centre came along in the 60s-70s that a GUI (Graphical User Interface) became available, and the industry standard shortly thereafter.
The idea that GUIs effectuate was to provide instinctual visual controls by which a user would operate a machine, system, or instrument, with the ultimate aim of improving the productivity of both workers and machines.
Even after these incredible breakthroughs in the HMI field, it took decades for interfaces to be readable and the craft of information prioritisation and presentation to be perfected. To highlight the importance of a well-functioning HMI, it’s important to look back at UI failures which have led to disaster.
One of the most notable of these is the incident mentioned at the start of this piece, where the USS Vincennes shot down a passenger plane because the information conveyed on the ship’s onboard combat display system was either incorrect, or incorrectly relayed, or both.
Eric J. Lerner, a writer for Aerospace America, notes that although the three large displays on the Aegis system showed every contact within its range, “to get speed, range, and altitude”, one had to explicitly punch up that information, which was subsequently displayed on a comparatively small 12-inch monitor.
Most importantly, this display “did not include rates of change”, forcing crew-members to “compare data taken at different times and make the calculation in their heads, on scratch pads, or on a calculator — and all this during combat.”
The final piece of information which led to Captain Rogers making his call was that the aircraft was descending towards the ship, whereas in actual fact it was ascending — another failure of the interpretation of the information displayed on the Aegis system.
You could say that this was over aggression from the US Naval Captain, but in fact it’s one of a long line of disasters, the common denominator in each of which is a failure in at least one aspect of the UI.
From the Kegworth Air Crash in 1989, to the Strasbourg Crash of 1992, all the way to the Three Mile Island nuclear disaster and the Emergency Management Agency warning the entire island of Hawaii in 2018 that there was an incoming ballistic missile, when in fact it was meant to be a drill, all follow the same patterns of bad UIs not taking into account human factors when being designed.
Now, in terms of making a well-functional and intuitive HMI these days, that is in itself an art form in so far as there is no exact textbook on how to achieve it.
There are a few basic tenets it should adhere to, however. At its core, an HMI is there to retrieve data from Programmable Logic Controllers (PLCs) and input/output sensors and present it to the user, therefore the first thing it needs to be able to do is communicate with all major PLC brands with their respective protocols.
It also must be able to work in a range of environments, including harsh ones — such as the ones in which you would tend to find boats — and it should have all the latest ports for comprehensive connectivity. Data logging capabilities should be included as well.
Looking at the aesthetics of it is where it gets rather interesting, though. It stands to reason that the UI (user interface) should be as accessible as possible for ease of use, but you’d be surprised at the sheer volume of badly thought out, convoluted UIs there are being produced on a mass scale.
After all, an HMI is judged on its usability, which includes how easy it is to learn as well as how productive the user can be. Task success rate, user distraction levels, and clarity in different conditions are all factors that affect the success of an HMI and are factored in throughout the design process.
The possibilities for how these systems could evolve and integrate with future designs for interiors, wheelhouses, or any type of “control room” truly are endless. As always, Conjure’s experience and expertise in HMI make us very excited to see how it plays out.
