Put the H in HMI

Engineering
#1

This article was from August 2019 shortly after NTSB report on McCain came out. Who knows why the great algorithm in the ether brought it up to me now but it did seem to jostle loose some subterranean thoughts on automation.

So is the navy throwing out the baby with the bath water or making a meaningful improvement? It’s hard to tell from reporting like this. But the interesting part for me related to HMI’s.

Easy enough to agree with this:

“This is a classic case of information overload and a poorly thought out Human Machine Interface,”

I’m assuming by “mechanical controls” they are referring to the IO devices only and I hope so. Automation people can run away with themselves if you let them. I think assuming “young sailors” will naturally find touch screen control better or more efficient is not warranted in every context. That may not be the right choice no matter who you are.

Making critical manual input to an automation system via wheels, levers and big knobby things seems intuitive no matter what your age is and (speaking from an ECR perspective) achieves the end result with minimum of distraction from the OODA LOOP while executing an action. Example silence an alarm.
Noise.
Glance at top row of a screen to see what the current alarm is and
Find pointing device (if not touch screen)
Move cursor to silence button on screen.
Click
Navigate to alarm page or look at a display you may have set up to be left on the alarm page.
Check if the alarm was part of a sequence and ORIENT / DECIDE

An improvement?
Add manual silence buttons to the console, we had 5 or 6 over the length of the console. Easier to silence the audible notification and maintain focus on the alarm information, plant information and next steps.

Power Management is great and starting a DG set for routine DG change over is not too burdensome to navigate to a screen click a few buttons, respond to pop-ups etc BUT what about if DP calls and says we need one now? We put in a big switch on the console “start next engine” within reach of the phone.

These are trivial things for automation to handle but developers can get too enamored with their own toolbox/feature set. It seems to me the first version out to crew is usually deficient in these simple things.

If your console is only a display or even multiple displays I think you are making it harder to operate. Certain key parameters should still be meters in a fixed position on the console and simple indication lights can easily be left out of the design which make it easier to OBSERVE and ORIENT.

Wonder if there are studies that show by dropping your head down, limiting your field of focus / attention to a few square inches of screen at a time perhaps involving a sequence of eye movements / physical actions (cursor navigation / button clicking) actually slows down problem solving sequence of thoughts?

I’ve come to appreciate what I will call “reliable remote control” and even in automated unattended plants never design out those options in the software.

Hope the navy asks a few old plant operators to contribute to the next generation of HMI they have in mind. Ideally the functional description of the system would go beyond “must be able to make load dependent starts of DG’s” and include more on the HMI side.

6 Likes
#2

This issue is so close to my heart. When HMIs were all levers, dials, buttons, and gauges a lot of thought went in to making them visible, intelligible, meaningful. The goal wasn’t to make them beautiful, but they often were, because we love all things that satisfy the maxim (borrowed from evolutionary biology): Form Fits Function.

I am so irritated by local control panels which have touch screens and mimics that are too small, above eye-level, not cleanable, and not durable.

And another thing: as we replace florescent tubes with LEDs, our ambient light levels improve, but it makes the panels less visible. I used to be able to see if the red light or the green light was illuminated from across the room. Now have to walk over and cup the light with my hand, or shade my eyes to try to see past the bright lights.

1 Like
#3

Somewhat related, your post reminds me of the design process in a government agency in a sector I worked in where land engineers would order the launches to be used for hydrographic surveys. The aftermarket displays relevant to the job of surveying were purchased by them on advice from the survey technicians. The operator was last in line and was left with the task of mounting the displays wherever they would fit without blocking the view out the window. The result was operator fatigue and cramps from having to look at the necessary displays in all the wrong places; down and to either side of the panel. As an operator, no suggestions that would improve the process ever succeeded in penetrating the shield protecting their fragile egos.
In this aspect, the navy did a much better job than this other agency, which shall remain nameless, at locating the displays where they belonged.

1 Like
#4

I was recently lucky enough to visit the latest ship to be added to the Royal New Zealand Navy’s fleet a supply tanker. The bridge had obviously had operators input and while it had a huge amount of military equipment the arrangement of the conn and other equipment was in my opinion, from a civilian Mariners perspective, best in class.
Why is it not possible to have a button that silences any or all alarms on the bridge in the same way as in the machinery space? The bridge watch keeping alarm buttons would be fine for this purpose. The purpose of an alarm is to alert and not distract.
I was lucky enough to be deep sea and during the day when a fault developed with the telegraph system. A piercing alarm charmed us all on the bridge for about 30 minutes until the electrician found the alarm and a faulty sensor buried in a cabinet. There was no visual indication of what was causing the alarm.
The ECR has the benefit of a visual indication of the fault with the traffic lights in the machinery space and a detailed display in the ECR so a decision can be as to whether an alarm is critical or not.

#5

There can be a middle ground. My truck’s touch-screen (HMI) has many more functions than could ever fit in a dashboard of knobs and buttons. But Volume and Temperature still have their own physical knob, likely because they are the most used and adjusted and can be felt easily without taking eyes off the road. I remember back when companies started putting volume on the steering wheel. That was great, but now there’s easily 10 buttons on the wheel and I have to look to see which one I want.

As they mentioned, a throttle lever can be fly-by-wire and still be a physical lever. And why not, it is one of the most important control inputs on the bridge along with helm steering. It’s an easy glance to see the setting. Because it can be put on a screen does not mean it should. Reserve the screen for the nice to know not the need to know.

The tankers I was on were unattended ERs, but still had a full console and you could see the flashing lights of the individual alarms. Immediately apparent where the problem focus area needs to be. But the first Drillship I went to that was unattended had just two computer screens. Two screens from which to view the entire plant, all equipment parameters, tank levels, trends, alarms. Literally thousands of alarms to scroll through, or tabbing through pages to find what is actually in alarm that matters.

Actual user generated improvement unfortunately comes with cost. Sometimes during new commissioning we could ask Kongsberg to make slight changes to the UI mimics, and sometimes they would up until they would decide its a change order that needed be paid for. Obviously the company wouldn’t pay for that. Rockwell Automation was somewhat more receptive to UI improvements because they actually wanted to improve the product.

1 Like
#6

In my experience the Engine room console still had the individual cards with a fault light built in so you could see which equipment was alarming. The screen showed the alarms but the computer listed them in priority . I agree with you that a drill ship adds extra complexity with multiple machinery locations and may require more than the number of watch keepers than the norm.

#7

We’re well beyond those days. Put up incoming alarm page and you will see in reverse chrono order all alarms coming in, whether they were acknowledged (as opposed to silenced), whether they are still active vs cleared. There would also be ways to look at just outgoing ie cleared and acknowledged.

The alarm page is available on any operating station monitor but I find that more or less dedicating one to incoming alarms and having it at a convenient point on the console such that you always look there on audible. If I had my way on layout I’d have it on top of console angled down or more than one if the console was long.

The cards are now just channels on IO modules in a rack distributed around the ship and talking to the PLC on a network.

#8

Similar to the discussion here:

Decades ago, the European car companies of Ford and GM invented linear speedometers with a drum inside, turning to show different colors left and right at the given speed. Not for long, they came back to the old round speedometer… the ‘new, better’ one was counterintuitive.

If someone looks at his wristwatch and you ask him immediately what time it is, he often cannot say it; he has to relook it up. He knows the train goes at 15 minutes past X… but the brain looks probably if the big hand is at right and transmits: you are largely on time.

#9

I have a modest proposal.

Since daily rounds are required, and UI screens on machines are unreliable, hard to read, and have many other deficiencies, let us do away with them and return to traditional analogue UIs. But let us not be Luddites. Give each unit Bluetooth capability, and each MED a tablet. When you are near the unit,it can update your e-logbook with readings, confirmed and acknowledged by the person holding the tablet against the analogue readings. If something is visually amiss, a photo can be added. Tablets commonly have accelerometers, so vibratonal data may also be collected. The watchkeeper can be prompted to answer certain question as she moves through the spaces.

Result: log is fully digital, takes less time, is more standardised, and contains more data.

A bluetooth could put the full power of the data and control of each machine in your hand, in living colour, without the frustrations of badly designed physical local UIs.

4 Likes
#10

Tablet/phone accelerometers are shit for vibration analysis. Ask me how I know.

I like the rest of your idea though.

#11

I agree, interesting article but I’m not sure what is being said here:

There seems some irony that today’s sailors – especially younger sailors who grew up in the days of smartphones and tablet devices – aren’t more readily accustomed to touchscreen interfaces.

“It is a bit confusing, since it contradicts conventional wisdom about the value of providing younger service people with familiar tools and with the established value of so many other touchscreen interfaces,” said Charles King, principal analyst at Pund-IT.

In what populations is this conventional wisdom? The general public or the UI experts?

#12

This discussion has been ongoing for a very long time. I was told the throttle controls on turbo-electric T2 tankers in WW2 could have been done with a few buttons and a couple reostat type dials but concept was too foreign for the engineers of the period. To give them a better “feel”, large clunky levers were used instead.

Edit, Here is a picture of the T2 tanker control console. Note the levers…

image
image624×800 108 KB

#13

As far as I know, this ‘wisdom’ is an assumption rooted in the belief that millennials are an alien species who have some-kind of special relationship with technology whereby there is one UI to rule them all and it is a touchscreen.

Scale of the human body (height, mostly), what detail is determinable (distance and display size mostly, but also angle and how much detail to display on a screen), and hardyness to conditions seem to all be factors that were retired as design considerations, in favour of being seen as ‘next generation.’

3 Likes
#14

I’d say an expert in some field using the term “conventional wisdom” uses the term meaning that the common assumption is incorrect.

#15

Yea, taking “younger service people” who are assuredly familiar with driving a car with a steering wheel and accelerator, and asking them to helm a 500 ft ship with a touch-screen because they grew up with an iPhone doesn’t seem like conventional anything.

I love tech and fancy screens and full automation, it’s what keeps me engaged in the industry. But even though I only did it handful of times I miss running steam throttles on maneuvering bells. Horsepower literally at your fingertips, feeling and hearing the turbines as you spin the throttle wheel…put that on a screen and still works, but it’s a little sad too.

1 Like
#16

Sad is the least of it. Broken and dangerous, most of all.

fat-finger issues, guessing the wrong soft key because the screen is scrambled, paralax…

Also, here’s another idea (listen up, Kongsberg): I want this valve to move. Its controlled remotely,but I’m local. I call the operator on the radio and explain what I want. I also touch a button on the controller, which lights up the valve on the screen. Now there’s no confusion about what valve are we talking about.

#17

Just read the comments - this is the second one.

Agreed … take a look at “Cognition in the Wild” by Ed Hutchins, 1995. Good insights there.

I’ve only read excepts but it does seem like good insights. For some reason people think RTFM doesn’t apply to human behavior,

#18

This seems doable. However, there is something all those freestanding PLC’s with small, hard to read displays and unintuitive navigation schemes have in common. A serial communications port. Important data can be brought into the main SCADA system and displayed on screen pages. Rounds for readings should not be eliminated though but maybe have them read actual thermometers and gages and levels. To truth test the system. A tablet for recording these would also be a good idea. Maybe with optional methods to data entry beyond typing. Enter data using a thermometer (or gage or tank level) graphic that has a spot that acts as a slider which you move like a slider till you see the correct value then tap enter. Download as you suggest back in the ECR wireless into a log program.

It’s like I always say, next time we build a ship we’re going to do it right.

1 Like
#19

Or maybe just incomplete.

#20

I manufacture an emissions control system that is used on the generators of very large yachts. The control interface is a touch screen (6" X 3.5") HMI with a home screen that displays two guages, temperature and pressure in good old fashioned analog steam gauge form. In the lower center of each gauge is a box that displays the numerical reading.

The setpoint display is also a button that when pressed brings up a setpoint entry box on top of the active display. the new setpoint is entered keypad style, hit enter, and the box goes away. It is simple, uncluttered, does not require sliding a finger or stylus on a tiny and hard to manage input. The system is built for engineers who need information and a degree of control, not for IT folks or computer nerds.

There is room on the screen off to one side to present switch box to select auto or manual operation, another to display a setpoint, and another to display operating hours. There is a “button” to select a history page that when selected will change the page to a log file of operating parameters logged each minute of operation. Complete logs are also recorded on a removable USB drive for analytic purposes. The HMI has the capability to connect to the vessel network for remote monitoring of alarms, display, and control though most users do not use this feature.

It is not difficult to design a useful HMI that provides the user with all the information required without overload or increasing the workload. Different levels of users have different access levels. The watchstander gets what he needs and is not swamped with too much information yet a great deal of information is available to those who need it and can use it.

That is my philosophy when designing the human machine interface. But then I am a grumpy old steam engineer.

4 Likes