HMI

HMI Programming Guide: Screens, Alarms, and Tag Mapping That Operators Actually Trust

A practical, vendor-neutral HMI programming guide covering screen hierarchy, ISA-101 layout, alarm management, and tag mapping between the PLC and the operator panel.

· 14 min read · By TryPLC Team

  • HMI
  • HMI Programming
  • ISA-101
  • Alarm Management
  • SCADA

HMI programming is what turns a working PLC program into a system an operator can actually run. The PLC closes the loops; the HMI is where humans see what is happening, acknowledge alarms, change setpoints, and decide whether to keep producing or shut down. A great HMI prevents accidents. A bad one causes them.

This guide covers what professional HMI programmers actually do day to day: screen hierarchy, ISA-101 layout, alarm management, tag mapping between the PLC and the panel, and the security and testing practices that separate hobby projects from production-grade systems.

TL;DR — Key Takeaways

  • HMI programming is design + binding. You design the screens and you bind every element to a PLC tag. Both parts matter.
  • Follow ISA-101. Muted gray backgrounds, color reserved for abnormal states, consistent four-level screen hierarchy (Overview → Unit → Detail → Diagnostic).
  • Alarm management is a separate discipline. Use ISA-18.2 priorities, deadbands, and rationalization. Aim for fewer than 1 alarm per 10 minutes per operator in steady state.
  • Never bind to physical addresses. Always go through symbolic PLC tags so wiring changes do not break screens.
  • Test like an operator. Force tags, simulate faults, and walk through every alarm before commissioning.

    • What is HMI Programming?

    An HMI (Human Machine Interface) is the screen — a panel-mounted touchscreen, a thin client, or a PC running visualization software — that an operator uses to interact with a machine or process. HMI programming is the engineering work that produces that interface:

  • Screen design — layout, navigation, colors, animation logic.
  • Tag mapping — connecting on-screen objects to PLC variables.
  • Alarm configuration — priorities, messages, acknowledgment behavior.
  • Security — user roles, permissions, audit trails.
  • Recipes and data logging — production parameters and historical trends.
  • Testing and commissioning — verifying every interaction against the real PLC.

    • The graphical part is the most visible, but on a real project it is usually 30–40% of the work. The rest is tag architecture, alarm rationalization, and integration testing.

    HMI vs SCADA vs DCS — Quick Disambiguation

    SystemScopeTypical Software
    HMIOne machine or skid, local panelSiemens WinCC Comfort, Rockwell FactoryTalk View ME, Pro-face GP-Pro EX
    SCADAPlant-wide supervision, multiple PLCs, historizationIgnition, FactoryTalk View SE, Wonderware/AVEVA, WinCC Unified
    DCSTightly integrated control + visualization for continuous processEmerson DeltaV, Honeywell Experion, ABB 800xA
    The HMI programming techniques in this guide apply across all three — the differences are mostly in scale, redundancy, and how tightly the visualization layer is coupled to the controller.

    Screen Hierarchy: The ISA-101 Four-Level Model

    ISA-101 defines a four-level screen hierarchy that has become the de-facto standard for industrial HMIs:

  • Level 1 — Plant / Area Overview. One screen, the entire process at a glance. Used by supervisors to see if anything is wrong. No detailed controls.
  • Level 2 — Unit / Process Overview. One screen per major unit (reactor, packaging line, CIP skid). All the equipment in that unit, with key process values and the ability to navigate deeper.
  • Level 3 — Detail / Faceplate. Individual equipment — a pump faceplate, a valve faceplate, a PID loop faceplate. This is where the operator starts and stops things and changes setpoints.
  • Level 4 — Diagnostic. Raw I/O, communication status, drive parameters. Used by maintenance, not operators.

    • A common rookie mistake is to put everything on Level 2 and skip the overview. Operators then lose situational awareness during upsets because they cannot see the whole plant on one screen.

    The ISA-101 Color Palette (and Why It Looks Boring)

    New HMI screens often look dramatic — black backgrounds, bright green pipes, blinking red lights. ISA-101 deliberately rejects that style. The recommended palette is:

  • Background: light or medium gray (#D0D0D0 to #E5E5E5). Not white, not black.
  • Equipment and pipes: medium gray, darker than the background. No process color coding.
  • Process values: black text on the gray background.
  • Abnormal conditions only: yellow (low priority alarm), orange (medium), red (high), magenta (critical).

    • The reason: when everything is colorful, nothing stands out. Reserving color exclusively for abnormal conditions means a single yellow indicator on an otherwise gray screen instantly draws the operator's eye. Studies by the Abnormal Situation Management Consortium have shown 30–40% faster operator response times on ISA-101-style HMIs versus traditional "Christmas tree" screens.

    Tag Mapping: Connecting the HMI to the PLC

    Every dynamic element on an HMI screen — a numeric value, an animated pump, a button, an alarm — is bound to a tag in the PLC. Good tag mapping is the single biggest determinant of whether an HMI project stays maintainable.

    The golden rules

  • Symbolic tags only. Bind to Pump_101.Run or Tank_201.Level_PV, never to %I0.3 or N7:42. If the I/O moves, the screens still work.
  • One source of truth. Define tags in the PLC, then import them into the HMI. Do not retype them — typos in tag names are one of the most common commissioning bugs.
  • Consistent data types. REAL for analog values, BOOL for digital, INT or an enum for states. Mixing types between PLC and HMI causes silent rounding or truncation.
  • Group by area. Use UDTs or structures: Pump_101.Run, Pump_101.Fault, Pump_101.Hours. The HMI faceplate then binds to the structure once.
  • Engineering units in the tag. Store the unit (degC, bar, %) as a tag property so the HMI can display it without hardcoding.

    • Example: a pump faceplate

    PLC UDT: PumpControl
    Run            : BOOL    // operator command
    Running        : BOOL    // confirmed feedback
    Fault          : BOOL    // any fault active
    FaultCode      : INT     // 0 = none, 1 = overload, 2 = no flow
    RunHours       : REAL    // accumulated run time
    InterlockOK    : BOOL    // safe to start
    HMI faceplate bindings:
    Start button   →  Pump_101.Run         (write BOOL)
    Status lamp    →  Pump_101.Running     (animate fill color)
    Fault banner   →  Pump_101.Fault       (visible when TRUE)
    Fault message  →  Pump_101.FaultCode   (lookup table → string)
    Hours display  →  Pump_101.RunHours    (numeric, 1 decimal)
    Start enable   →  Pump_101.InterlockOK (button greyed out when FALSE)

    Notice how the start button is greyed out when the interlock is not satisfied. That single design choice prevents dozens of "I pressed start and it did not work" support calls.

    Alarm Visualization and ISA-18.2

    Alarms are the most safety-critical part of an HMI. The relevant standard is ISA-18.2 / IEC 62682 Management of Alarm Systems for the Process Industries, complemented by EEMUA 191 in Europe.

    The four alarm priorities

    PriorityColorOperator Response TimeTypical Use
    LowYellow< 30 minTrend deviation, advisory
    MediumOrange< 10 minProcess value out of range
    HighRed< 3 minSafety-related, production impact
    CriticalMagenta + flashImmediateShutdown trigger, safety system trip

    Alarm rationalization checklist

    Before adding an alarm to the HMI, ask:

  • Does it require an operator action? If not, it is an event, not an alarm.
  • Is there a deadband? Without one, a value oscillating around the setpoint will chatter dozens of alarms per minute.
  • Is there an on-delay? A transient spike should not trigger an alarm.
  • Is the priority correct? Most "high priority" alarms in legacy systems are actually low priority. Be ruthless.
  • Can the operator do anything about it in the available time? If not, it belongs in the maintenance log, not the alarm summary.

    • A well-rationalized system averages fewer than 1 alarm per 10 minutes per operator in steady state. If your alarm list is full, the answer is rationalization, not bigger screens.

    Animation: Showing State, Not Decoration

    HMI animation should communicate state, not draw attention for its own sake.

  • Pumps and motors: fill color changes (gray → green) when running. Optional slow rotation of the impeller when on. No spinning when off.
  • Valves: color or fill state for open / closed / transitioning. Show the commanded state and the feedback state separately if they can disagree.
  • Pipes: stay gray. Do not animate flow with moving dashes — it is visual noise and creates motion sickness on large screens.
  • Tanks: vertical bar fill proportional to the level tag. Color band for normal range, change color only when outside it.
  • Trends: always include the setpoint, the process variable, and the alarm limits on the same chart.

    • Security and User Roles

    Modern HMIs support role-based access control. A typical setup:

  • Operator — start, stop, acknowledge alarms, change setpoints within configured ranges.
  • Supervisor — change setpoint ranges, override interlocks (with audit trail), reset run hours.
  • Engineer / Maintenance — access diagnostic screens, force I/O, modify alarm limits.
  • Administrator — create users, change roles, modify screens.

    • Every privileged action should be logged with username, timestamp, old value, and new value. This is mandatory for FDA 21 CFR Part 11 in pharma and increasingly expected in food and beverage and energy.

    Testing Your HMI Before Commissioning

  • Force every tag the screen reads from the PLC. Verify the on-screen value updates and the units are correct.
  • Trigger every alarm. Confirm the message, priority, color, and acknowledgment behavior.
  • Test every button with the interlocks both satisfied and not satisfied.
  • Walk through navigation from Level 1 to Level 4 and back. No dead ends.
  • Simulate a power loss mid-operation. The HMI should reconnect cleanly and show the current PLC state, not a stale snapshot.
  • Have an operator try it. They will find usability problems you never will.

    • A Practical Learning Path

    If you are new to HMI programming, work through these in order:

  • Pick one platform (WinCC, FactoryTalk View, or Ignition) and build a simple two-screen project — overview and pump faceplate — against a simulated PLC.
  • Add alarms with proper priorities and deadbands.
  • Implement user roles and audit logging.
  • Refactor to ISA-101 colors and notice how much calmer the screen feels.
  • Build a Level 1 overview for a multi-unit process.
  • Add trends and a recipe management page.

    • You can practice the underlying PLC logic — the tag structures, the interlocks, the alarm conditions — directly in the TryPLC editor without needing a physical HMI panel. Once the PLC side is solid, the HMI work becomes mostly screen design and binding.

    Summary

    Good HMI programming is invisible: the operator runs the plant without thinking about the screens. Achieving that takes a structured screen hierarchy (ISA-101), a disciplined color palette, rationalized alarms (ISA-18.2), symbolic tag mapping, and rigorous testing. The graphics are the easy part — the architecture decisions you make in the first week of a project are what determine whether the HMI is still serving operators well in ten years or being torn out and replaced.

    Frequently asked questions

    What is HMI programming?

    HMI programming is the work of designing the screens, alarms, navigation, and tag mappings that let an operator monitor and control a machine or process from a Human Machine Interface panel. It is not just drawing graphics — it covers screen hierarchy, alarm priorities, security, animation logic, and how every on-screen element is bound to a PLC tag.

    Which HMI software should I learn first?

    For Siemens shops, learn TIA Portal WinCC (Comfort or Unified). For Rockwell, learn FactoryTalk View ME and SE. For vendor-neutral work, Ignition by Inductive Automation is the most portable skill because it is used across many industries. The underlying concepts — screen hierarchy, alarm classes, tag bindings — transfer between all of them.

    What is the difference between HMI and SCADA?

    An HMI is the local operator interface for a single machine or skid, usually a panel on the equipment. SCADA (Supervisory Control and Data Acquisition) is a plant-wide system that aggregates data from many PLCs and HMIs, handles historization, and provides dashboards for supervisors. SCADA software like Ignition or FactoryTalk View SE can also act as an HMI, which is why the terms are sometimes used interchangeably.

    What is ISA-101 and why does it matter for HMI design?

    ISA-101 is the international standard for Human Machine Interfaces in process automation. It defines screen hierarchies (Level 1 overview, Level 2 unit, Level 3 detail, Level 4 diagnostic), a muted color palette that reserves bright colors for abnormal conditions, and consistent alarm representation. Following ISA-101 dramatically reduces operator error and is increasingly required by clients in oil and gas, pharma, and food and beverage.

    How should I map PLC tags to HMI tags?

    Use a single source of truth — a tag database in the PLC with descriptive names (Pump_101_Run, Tank_201_Level_PV) and import them into the HMI rather than retyping. Group tags by area or unit, keep data types consistent (REAL for analog, BOOL for digital, INT for states), and never bind an HMI element directly to a physical I/O address — always go through a symbolic tag so wiring changes do not break screens.

    How many alarms should appear on an HMI screen at once?

    Per the EEMUA 191 and ISA-18.2 guidelines, a well-designed system averages fewer than 1 alarm per 10 minutes per operator in steady state, and no more than 10 alarms in the first 10 minutes of a major upset. If your screens routinely show dozens of active alarms, the problem is alarm rationalization, not screen design — you need to remove nuisance alarms, set proper priorities, and add deadbands before adding more graphics.