An HMI standard for a machine builder

Starting point

The builder had developed six machine models from the same family at different times with different engineers. The result: a separate interface on every model. On one model the Start button sat on the left of the screen, on another on the right; on one a temperature alarm was red, on another orange. Alarm texts had been rewritten in every project, so the same fault was described in six different sentences.

That carried two concrete costs. The first was commissioning: on each new machine the interface was largely drawn from scratch, and once the screen count passed thirty this was measured in days. The second was the field: when a customer bought two different models, operator training was given twice and the service team had to start every phone call with “which model?”. Multilingual support had never been built — on an export order the texts were edited one by one inside the HMI project, and that project branched off as a copy specific to that customer.

The system built

The work was split into three layers.

Interface library. Parametric screen objects (faceplates) were written for recurring equipment: motors, valves, heaters, drives. Each object has a matching data block type on the PLC side; the interface object binds to that block and no further code is written. Building a new machine means placing the object on a screen and pointing it at an instance.

Screen hierarchy. ISA-101 thinking was followed: a machine overview at the top, section screens below it, equipment detail and diagnostic screens at the bottom. Navigation follows the physical flow, not a menu tree. Colour is used only for state and alarms; process graphics stay in greyscale, so a red indicator genuinely draws attention.

Text and alarm source. All interface texts and alarm sentences were pulled out of the HMI project into a single text table. Language is selected at runtime, with no separate project copy. The alarm list was given common numbering and a severity classification: the same fault carries the same number and the same sentence on every model.

We describe the automation side of these requirements on the industrial automation page, and the library and version management side on the software and application development page.

The hard part

The hardest part was not technical but a matter of fit: machines were already running in the field, and some of them had legacy PLC data structures that did not match the standard. A library object expects a specific data block type; on an older machine that type does not exist.

There were two options. Migrate the PLC programs of the older machines to the standard as well — touching running systems, which means field risk. Or keep a separate library version per legacy model — precisely the sprawl the project was trying to escape.

The route chosen was a third one: an adapter block layer on the PLC side. A thin block that copies legacy tags into the standard data block without touching the logic. That kept the interface side on a single version while leaving the control logic of the older machines unchanged. The adapter layer is only loaded during a retrofit and is absent on new machines.

The second difficulty was text length. Turkish and German strings are noticeably longer than their English counterparts, and fixed-width buttons overflowed. The fix was to size critical text areas against the longest language and put a character limit on the text table — when the limit is exceeded the build warns, so nobody finds a truncated label on site.

Measurement and acceptance

Acceptance was defined around two metrics. The first is interface commissioning time: engineering days spent on a new machine model from project kick-off to SAT signature. For a reference model before the standard, that figure was extracted from records; afterwards it is measured the same way.

The second is conformance to the standard: each screen’s colour usage, navigation depth and alarm numbering are audited against a checklist. Checklist items are pass/fail, with no room for interpretation.

FAT was run in the workshop against simulated field signals — every screen, every alarm and every language was walked through one by one. SAT was completed on site on a real machine with a signed protocol. The numeric threshold of the acceptance criterion is written into the contract; what we describe here is the method, not a result.