Case study · MacLean Engineering

Building operator screens for heavy machines

An HMI, or human-machine interface, is the screen an operator uses to run a machine. Since 2021 I've worked on five of them for underground mining equipment, from in-cab displays on a battery-electric grader to tablet software for running machines by remote control. This is how that work is put together and what it has taught me.

C++Qt / QMLPythonOPC UAEmbedded LinuxDockerCI/CD

From sensor to screen

Every value an operator sees passes through the same five layers. My work is mostly in the bottom three.

Machine controller (PLC)
Reads sensors and drives the machine. It is the source of truth for every value on screen.
OPC UA
An industrial standard for publishing machine data. The display subscribes to the signals it needs and is told when they change.
Data layer (C++)
Checks each incoming value: right type, sensible range, good status. Bad or missing data is flagged instead of shown as if it were real.
View models (C++)
Turn raw signals into things an operator cares about: "parking brake on", "battery at 62%", "door open".
Screens (Qt / QML)
Reusable gauges, indicators and warning bars, laid out so the important thing is readable in a glance.

What matters on a machine

Never show a wrong number

On a machine, a stale or made-up value is worse than a blank one. If a signal is missing or invalid, the gauge says so clearly instead of freezing on the last good reading.

Readable in one glance

Operators are driving, not reading. Colour means something (green, amber, red), text is large, and warnings appear in the same place every time.

Build parts, not pages

A speedometer, a battery gauge or a tilt indicator is built once as a tested component, then reused across screens and machine models.

Test on real hardware early

Every release has a written test plan that is run on a simulation board with the real display and controller before it goes near a machine.

Three problems, and how I solved them

The crash that only happened with real data

A display was restarting on its own on the test bench. Nothing failed in normal testing.

I traced it to one signal that the controller sometimes published with no value at all. The code that handled live updates assumed there was always something there, and fell over when there was not.

The fix was a few lines: treat "no value" the same as "bad value" and show the gauge as unavailable. The more useful part was the test. I added a fake signal to our test server that sends exactly that empty value, wrote a test around it, and confirmed the test crashes on the old code and passes on the new code. That fault now gets caught automatically.

Why the gauge had no decimal places

A battery reading on screen jumped in whole numbers when the design called for decimals. The obvious move was to "fix the display".

Instead I followed the value backwards, from the screen to the data layer to the controller, and found the controller itself was sending whole numbers. No amount of display code could add precision that was never sent.

I wrote up what I found for the controls engineers so the change could be made at the source. Knowing where a problem really lives saves days of patching the wrong layer.

Testing remote control without a machine

Some machines can be run from a rugged tablet, with live camera views and machine status on screen. Testing that normally needs a machine, which is expensive and rarely free.

I set up a laptop to stand in for the machine and send the same messages a real one would, so the tablet software can be checked at a desk: status lights, fault codes in English and Spanish, and connection loss.

I also scripted the packaging step so a developer can build the same installer locally that the automated pipeline produces, instead of waiting on the pipeline to find out whether a build works.

This page describes my work in general terms. Screens, code and machine details belong to MacLean Engineering and are not shown here.

← Back to my experience and résumé