Automate
HMI development for people who are wearing gloves
An HMI is used by someone standing up, under time pressure, often in poor light, sometimes in gloves, and occasionally during a fault when it matters most. We design operator interfaces for that reality — clear state, obvious next action, alarms that say what to do, and nothing decorative competing for attention.
The problem
Most HMI screens are designed for the buyer, not the operator
Photorealistic tanks, animated pipes, gradients everywhere, and a dozen values in the same size and colour so nothing stands out. It demos well and it fails in a fault, when the operator has thirty seconds and needs to know one thing.
- 01
Operators keep a paper crib sheet next to the panel
- 02
Important values are the same size and colour as unimportant ones
- 03
Alarm text is a code that requires a manual to interpret
- 04
Navigation takes four taps to reach the screen used most often
- 05
The panel is obsolete and no replacement runs the original project file
What we build
Concrete deliverables
Nouns, not adjectives. This is what actually gets handed over.
- 01
Operator task analysis
What the operator does in a normal shift, in a changeover and in a fault — the three cases the screens must serve, in that order of frequency and that reverse order of stakes.
- 02
Screen hierarchy and navigation
Overview, area and detail levels with the most-used screen reachable in one action, and consistent placement so muscle memory works.
- 03
High-performance graphics
Neutral background, grey process elements, colour reserved for abnormal state, and value hierarchy driven by importance rather than by layout convenience.
- 04
Alarm presentation
Plain-language alarm text stating condition and required action, priority indicated by more than colour, and a filterable history.
- 05
Recipe and changeover screens
Parameter sets, guided changeover sequences and confirmation steps that reduce operator-dependent variation.
- 06
HMI migration
Moving obsolete panels to current hardware, rebuilding screens to a modern standard rather than transcribing the old layout.
How it works
The technical path, step by step
Where the engineering decisions actually get made.
- 01
Watch a shift
We observe the panel in use. The paper crib sheet taped to the machine tells you more about the current HMI than any specification.
- 02
Define the hierarchy
Which screens exist, what each one is for, and how the operator moves between them under time pressure.
- 03
Design to a standard
A consistent template: fixed header with machine state, fixed alarm banner, consistent control placement, and a defined colour meaning.
- 04
Build and review
Screens built, reviewed with actual operators before commissioning, and revised. This review is where most of the value is created.
- 05
Commission and train
Deployed with a short training session and a follow-up after operators have lived with it for a couple of weeks.
Protocols & technologies
Specifics, because vague answers cost you money later
Chosen per site according to what is installed, not according to what we would prefer to work with.
| Technology | Where it is used | Engineering note |
|---|---|---|
| Siemens Comfort / Basic Panels | TIA Portal WinCC | The default in Siemens-based lines. |
| Allen-Bradley PanelView | FactoryTalk View ME | Standard in Rockwell architectures. |
| Weintek / Delta / Mitsubishi GOT | Cost-sensitive machine panels | Very common on Indian machine builds and retrofits. |
| Web-based HMI | Tablet and browser interfaces | Where a fixed panel is not required and mobility helps; served from an edge device so it works without internet. |
| Modbus / OPC UA / native driver | HMI to controller | Chosen for diagnostics quality as well as speed. |
Brownfield
Replacing an obsolete panel
When a panel fails and its project file will not open in any current software, the machine is effectively down. We rebuild the interface on current hardware — usually improving it substantially in the process, because a rebuild is the one chance to fix a screen layout that everyone has been working around for a decade.
Works with
- Obsolete panels with no available replacement
- Projects whose source file is lost
- Mixed panel brands across one plant, standardised to one convention
- Machines where the original builder is unreachable
- Adding a tablet interface alongside an existing fixed panel
Use cases
What people actually ask us for
Each one is a situation followed by the outcome it produces — not a feature list.
Fault response time
NowOperators take too long to identify what stopped the machine.
AfterA fault screen that names the condition, the location and the required action in plain language.
Changeover consistency
NowChangeover time varies by two hours depending on who does it.
AfterA guided changeover sequence with parameters enforced and steps confirmed.
Panel obsolescence
NowThe HMI has failed and no equivalent hardware is available.
AfterRebuilt on current hardware to a modern standard, with the layout improved rather than copied.
Downtime reason capture
NowStop reasons are guessed later from memory.
AfterA two-tap reason prompt on the HMI at the moment of the stop, feeding the monitoring system directly.
Standardising across a plant
NowEvery machine's interface works differently.
AfterOne convention across all panels, so an operator moving between machines is not relearning.
Implementation
How a project runs
Eight stages, each producing something you own. Full detail on the process page.
- 01
Discover
1–2 conversations
- 02
Audit
1–3 days on site
- 03
Design
1–2 weeks
- 04
Engineer
2–8 weeks per phase
- 05
Integrate
1–2 weeks
- 06
Deploy
Your shutdown window
- 07
Monitor
First 4–6 weeks
- 08
Optimise
Ongoing, if you want it
OEE and downtime reason capture
The half of machine monitoring that is usually done badly: capturing why a machine stopped, in under five seconds, in a way operators will actually keep doing.
Read the write-upQuestions
HMI Development — common questions
What is 'high-performance HMI' and why does it look so plain?
It is a design approach where the screen is deliberately low-contrast and grey during normal operation, so that any colour or movement means something abnormal. It looks unimpressive in a demo and performs far better in a fault, because the eye is drawn to the one thing that changed instead of competing with animated pipes. If a stakeholder wants the photorealistic version, we will show both and let the operators decide.
Can we use tablets instead of fixed panels?
Often yes, for supervisory and monitoring use. For direct machine control, a fixed panel is usually still correct — for safety, reliability and because a tablet's battery dies. A common arrangement is a fixed panel for control plus a browser-based view on a tablet for supervision and reason-code entry.
Our HMI project file is lost. Can it be recovered?
Sometimes the running project can be uploaded from the panel; sometimes it cannot, depending on the hardware and how it was downloaded. Where recovery is impossible, we rebuild from observation of the running machine and from the PLC program. We establish which situation you are in during the survey, before quoting.
Do you support Indian language interfaces?
Yes. Most modern HMI platforms support multi-language projects with runtime switching. The practical constraints are font availability on the panel hardware and screen space for longer strings — both of which we account for in the layout rather than discovering at commissioning.
How do you decide what goes on the main screen?
By watching a shift. The values an operator checks most often go in the most prominent position, the controls they use most often go where their hand naturally rests, and everything else goes one level down. The paper note taped to the machine is usually a precise specification of what the current screen is missing.
Show us the panel
A photo of the current screen and the crib sheet next to it tells us most of what we need to know.