The difference between an HMI that took three weeks and one that took three months is usually faceplates — or their absence.
The pattern
Define a UDT per equipment class (motor, valve, PID loop). Build one faceplate bound to that type: status header, operate area, interlock list, fault details, maintenance counters. Every instance on every screen is then a drag, a tag assignment, done. Two hundred motors, one popup to maintain.
Design rules we hold to:
- The faceplate shows why it will not run. An interlock list with plain-text conditions kills the number-one operator call (“it won’t start”).
- Manual/auto and simulate/force live in the faceplate with access control — not scattered as hidden buttons per screen.
- Keep faceplates dumb. Logic belongs in the PLC block; the faceplate displays and writes commands. HMI-side cleverness dies at the first panel swap.
Versioning is the real feature
Faceplates live in a TIA library as types; instances update when you release a new version. This is what makes a fleet maintainable: fix the interlock display once, roll it to every machine deliberately. Without library discipline, faceplates degrade into forty diverging copies — worse than no faceplates.
FAQ
Comfort Panels or Unified? New projects with a long life should evaluate WinCC Unified — its faceplate model is more powerful (and different enough that migration later is real work).
Performance impact of many faceplate instances? Instances themselves are cheap; over-fast acquisition cycles on hundreds of bound tags are not. Set acquisition per need, not per default.
Zone Otomasyon builds library-based HMIs your team can extend without us — that is the point. See our approach.