Case Study: WinCC HMI — Batch Mixer Control Panel

Project Overview

This project delivers a complete operator interface for an industrial batch mixing station, built as a SIMATIC WinCC Comfort HMI panel project within TIA Portal and validated in WinCC Runtime Advanced. The HMI communicates with a PLC_1 [CPU 1212C DC/DC/DC] and exposes real-time process state to the operator through a structured Root Screen: tank visualisation, live numeric readouts for Level, Step, and Temperature, operator command buttons, and a fully configured alarm system surfacing both process anomalies and connection diagnostics.

The architecture separates concerns cleanly: the PLC owns all control logic; the HMI owns all presentation and operator interaction. Tags are declared once in the PLC and exposed via the HMI connection layer — no control logic executes on the panel. This separation is the same pattern used in pharmaceutical, food and beverage, and chemical processing installations worldwide, where a panel failure must never compromise PLC-level process safety.

Problem

A batch mixing process operating under PLC-level GRAPH sequential control required a structured operator interface that could satisfy the following requirements without embedding any control logic on the HMI side:

• Present live process state (tank level, active step, temperature) with sufficient context for an operator to assess process health at a glance
• Provide safe, interlocked operator commands (Start / Stop) mapped to PLC input tags
• Surface process anomalies — specifically high-temperature conditions — through a configurable alarm system with real-time triggering, alarm class assignment, and persistent alarm buffer logging
• Display connection-level diagnostics alongside process alarms so operators can distinguish between process faults and communication failures without leaving the runtime screen
• Compile and deploy without errors across TIA Portal's full HMI tag validation and alarm consistency checks

Solution Architecture

HMI Tag Map

Complete tag binding table for the Root Screen, mapping each visual element to its data source and access mode.

Project Screenshots

Alarm Configuration — Annotated

# DISCRETE ALARM — HIGH TEMP WARNING
# Trigger tag:  HighTempWarning (Bool, PLC-connected)
# Trigger bit:  0
# Detection:    Rising edge (0 → 1)
# Alarm class:  Warning
# Ack group:    0
# Text:         "HIGH TEMP WARNING – Mixer overheating"
# Appears in:   Alarm buffer (persistent after acknowledgement)
# Set by PLC when MixerTemperature analogue input > safety limit
# Decouples HMI alarm display from analogue threshold arithmetic —
# the PLC evaluates the condition; the HMI only reads the Bool flag.

# ANALOGUE ALARM — TEMPERATURE UPPER LIMIT
# Trigger tag:  MixerTemperature (Int/Real, PLC-connected)
# Mode:         Upper limit
# Threshold:    85 (engineering units)
# Independent of HighTempWarning Bool path —
# provides a second detection channel that fires directly
# from the raw process value, regardless of PLC flag logic.
# Increases alarm coverage: if the PLC flag fails to assert,
# the analogue alarm still fires on the raw tag value.

# SYSTEM / DIAGNOSTICS ALARMS
# Source:       @DiagnosticsIndicatorTag (SInt, WinCC internal)
# Auto-generated — no manual configuration required.
# Entries surfaced in runtime:
#   - Connection disconnected: HMI_Connection_1
#   - General connection error / Missing user rights
#   - Incorrect access point or module configuration
#   - Change to operating mode 'online'
#   - User administration imported successfully
# Unified with process alarms in single alarm buffer view —
# operator sees process faults and comm faults in one panel.

Engineering Decisions Worth Calling Out

• Alarm buffer over current-alarm view. Configuring the alarm view object in buffer mode rather than current-alarm mode ensures acknowledged and cleared alarms persist in the visible log. In batch processing, production engineers and quality teams require a timestamped fault history — current-alarm mode discards cleared entries, producing a gap in the batch record. Buffer mode satisfies this traceability requirement without additional historian configuration.
• Dual-channel alarm coverage for temperature. Both a discrete Bool alarm (sourced from a PLC-asserted flag) and an analogue upper-limit alarm (sourced directly from the raw temperature tag) are configured. This creates two independent detection paths: the Bool path fires when PLC-side logic evaluates the condition; the analogue path fires directly on the tag value regardless of PLC flag state. Either channel alone is a single point of failure; both together provide redundant coverage with no additional hardware.
• PLC-side control logic, HMI-side presentation only. No control logic executes on the HMI panel. Start / Stop buttons use SetBit / ResetBit event actions against PLC-connected Bool tags; the PLC's OB1 reads these as permissive inputs and applies all interlock conditions before acting. This separation means a panel reset, screen timeout, or WinCC runtime failure cannot drive an actuator to an unsafe state — the PLC's own logic gates every output.
• Unified diagnostic and process alarm view. Rather than configuring a separate diagnostics panel, @DiagnosticsIndicatorTag is exposed in the same alarm buffer as process alarms. When a HIGH TEMP WARNING fires alongside a "Connection disconnected" entry, the operator immediately sees both events in chronological order and can determine whether the process fault preceded or followed the communication loss — critical information for root cause analysis.
• IO field binding to CurrentStep (Int). Exposing the active GRAPH step number as a live IO field gives the operator actionable situational awareness ("Step 1 — Idle", "Step 4 — Mixing") rather than a binary Running / Stopped indicator. This is sourced directly from the GRAPH FB's S_NO output, requiring no intermediate PLC data conversion.
• KP700 Comfort panel selection. The KP700 Comfort supports the alarm buffer object, IO fields, animation bindings, and the full WinCC Comfort tag type set required by this application. A Basic panel would not support the alarm buffer persistence configuration or the analogue alarm type — panel selection was therefore driven by the alarm architecture requirements, not screen size alone.

Testing & Runtime Validation

The complete HMI was validated in SIMATIC WinCC Runtime Advanced, confirming end-to-end tag binding, alarm triggering, and alarm buffer population without a physical PLC. Key validation steps:

• Compile pass: zero errors, two warnings — warnings reviewed and accepted as non-blocking (HMI-internal tag default value notices, not structural faults)
• Runtime launch: Root Screen renders correctly with all IO fields initialised; status indicator circle displays green when process state is active
• Tag simulation: Level, Step, and Temperature IO fields confirmed live-updating against simulated tag values (+10, +1, +90 respectively visible in runtime screenshot)
• Discrete alarm: HighTempWarning forced to TRUE — "HIGH TEMP WARNING – Mixer overheating" appears in alarm buffer with correct timestamp, Status I (Info/Active), and acknowledge group 0
• Analogue alarm: MixerTemperature simulated above 85 — upper-limit alarm fires independently of the Bool path, confirming dual-channel coverage
• Diagnostics alarm population: alarm buffer correctly surfaces connection-level entries (disconnected, mode change, module configuration) alongside process alarms in a single chronological view, without requiring manual configuration of those entries
• Alarm persistence: after acknowledging the HIGH TEMP WARNING, the entry remains visible in buffer mode — confirmed the view is not configured in current-alarm mode

Challenges Faced

The most persistent challenge was alarm triggering behaviour during initial configuration. The HIGH TEMP WARNING alarm failed to appear in the runtime view despite the trigger tag being asserted. Root cause: the alarm view object had been placed in current-alarm mode rather than buffer mode, and the alarm was firing and immediately clearing before the operator could observe it. Switching to buffer mode and configuring the alarm trigger for rising-edge detection resolved the issue — the alarm now fires on the 0→1 transition and persists in the buffer until explicitly acknowledged.

The second challenge was the distinction between discrete and analogue alarm types. Initial attempts to configure the temperature alarm as a discrete Bool alarm produced incorrect trigger behaviour when the temperature tag was an Int rather than a Bool. Understanding that analogue alarms operate on threshold comparisons against numeric tags — not bit-level reads — required a structural reconfiguration of that alarm's trigger definition, switching from discrete to upper-limit analogue mode.

The third challenge was tag architecture hygiene. Early in development, several display tags were declared as HMI-internal tags and manually assigned test values, which masked genuine PLC-connection issues. Migrating all process-relevant tags to PLC-connected definitions — and using only @DiagnosticsIndicatorTag as an HMI-internal system tag — produced a clean separation that made subsequent debugging significantly more tractable.

TIA Portal's HMI compiler also surfaced non-obvious warnings when IO field format masks did not match the declared data type of the bound tag. Resolving these required aligning the display format (integer vs floating-point) with the PLC tag type, which in turn surfaced a type inconsistency between CurrentStep (Int) and an early IO field configured for Real display — corrected by standardising the tag type across the PLC interface and HMI binding.

Key Learning Outcomes

• Designing and implementing industrial operator interfaces using Siemens SIMATIC WinCC Comfort in TIA Portal
• HMI tag architecture: correctly separating PLC-connected tags from HMI-internal tags and understanding the data flow implications of each
• IO field binding, animation configuration, and event action assignment for buttons without HMI-side scripting
• Discrete alarm configuration: trigger tag, trigger bit, alarm class, alarm text, and acknowledge group assignment
• Analogue alarm configuration: upper-limit threshold detection against numeric PLC tags, independent of Bool flag logic
• Alarm buffer vs current-alarm view modes and the traceability implications of each for batch process logging
• WinCC diagnostics alarm architecture: @DiagnosticsIndicatorTag and auto-generated connection-level fault surfacing
• Dual-channel alarm coverage as a redundancy strategy: Bool flag path + raw analogue threshold path
• HMI / PLC separation of concerns: presentation layer owns display and operator input; PLC owns control logic and interlock evaluation
• Runtime validation in SIMATIC WinCC Runtime Advanced: simulating tag values, forcing alarm conditions, and validating buffer persistence
• TIA Portal compile cycle discipline: resolving format-mask / data-type mismatches and interpreting warning vs error distinction
• KP700 Comfort panel capability boundaries and how alarm architecture requirements drive panel hardware selection

Tools & Technologies

• Siemens TIA Portal V18 (Cloud)
• SIMATIC WinCC Comfort (HMI engineering environment)
• SIMATIC WinCC Runtime Advanced (runtime validation and simulation)
• KP700 Comfort HMI panel (7" keypad panel, WinCC Comfort target)
• S7-1212C DC/DC/DC (CPU, PLC side of HMI connection)
• GRAPH (IEC 61131-3 SFC) for PLC-side sequence control (GRAPH FB providing S_NO / CurrentStep output)
• TIA Portal HMI tag editor, alarm editor, and screen canvas
• WinCC Comfort animation and event action editors