Configuring Siemens WinCC Faceplates with Dynamic Tag References

1. Overview: The Dynamic Faceplate Challenge

Reusable faceplates are the cornerstone of efficient HMI engineering. The goal is straightforward: build one faceplate graphic that reads from a user-defined tag or structure instance at runtime, so a single design element can display the state of any number of field devices (furnaces, pumps, valves, drives, etc.) without duplicating the screen object N times.

In Rockwell FactoryTalk View, this pattern is implemented through a tag placeholder: a display contains a relative reference such as #1.heater_temperature, and the placeholder #1 is substituted at runtime when a navigation button calls a macro like Display "Temperature" /T Furnace1. The same display can then visualize Furnace1, Furnace2, Furnace3, or Furnace4 by changing the substitution token.

The same objective exists in Siemens engineering environments, but the terminology and underlying mechanism differ significantly between WinCC flexible 2008 SP2 and the current TIA Portal V20 WinCC Unified runtime. Misunderstanding the difference is the most common reason engineers conclude that Siemens faceplates "cannot multiplex", when in fact the modern toolchain supports an equivalent (and more strongly typed) workflow through tag parameters.

2. Rockwell FactoryTalk View Tag Placeholder Reference Model

Understanding the Rockwell pattern clarifies the requirement being asked of Siemens. A FactoryTalk View SE/ME display file stores a tokenized reference rather than a fixed HMI tag name. When a button executes a navigation macro such as Display "Temperature" /T Furnace1, the runtime rewrites every #1 occurrence in the target display with the substitution string Furnace1. The resulting tag lookup becomes Furnace1.heater_temperature, which resolves against the HMI tag database.

This mechanism is purely string substitution and operates on the HMI tag namespace, not on a typed PLC structure. The same display object can therefore be repurposed for any tag whose name follows the same convention.

3. WinCC flexible 2008 SP2: Structure Multiplexing Is Not Supported

In the WinCC flexible 2008 SP2 generation (Update 13 and earlier), faceplates are built as reusable screen objects with a fixed set of interface tags. Each interface tag is a scalar or simple-type HMI tag, not a structure instance. When a faceplate is instantiated on a screen, the engineer wires each interface tag to a concrete HMI tag of the same type. There is no runtime token-substitution equivalent of #1.

Siemens Support documentation explicitly confirms the boundary:

• Dynamization of an object property using a tag is permitted, but only when the tag is the same type as the faceplate interface property.
• Address multiplexing is permitted on individual HMI tags (the indirect addressing feature), but cannot be applied to a structure-typed tag inside a faceplate interface.

Practical consequence: in WinCC flexible 2008 SP2, if you build a faceplate whose interface expects a structure like UdtHeater with members heater_temperature, heater_setpoint, and heater_run, the only way to reuse that faceplate for multiple heaters is to instantiate it once per heater on the screen and statically wire each instance to a different structure instance (e.g. DB_HMI.Heater[1], DB_HMI.Heater[2], etc.). The faceplate itself cannot be made to point to an arbitrary instance at runtime.

3.1 Why Structures Cannot Be Multiplexed in WinCC flexible

The WinCC flexible runtime binds faceplate interface tags to physical HMI tag addresses at compile time. Indirect addressing is implemented through a multiplex variable that points to a base address, but the multiplex mechanism operates on the address field of a scalar tag, not on the symbolic path of a structure member. Structures in WinCC flexible are symbolic containers whose offset arithmetic is not exposed to the multiplexing engine. Combining the two would require the runtime to compute a new base offset plus a structure member offset, which the 2008 generation does not perform.

4. Address Multiplexing Workaround for WinCC flexible 2008

When you must deploy a faceplate that visualizes a population of like devices in WinCC flexible, the established workaround is to flatten the structure into individually multiplexed tags. The technique is documented in the WinCC flexible Information System under "Multiplexing tags".

4.1 Configuration Steps

1. In the HMI tag list, define the base tag for the value to be multiplexed, e.g. HeaterTemperature[0], datatype Real, DB address DB100.DBD0.
2. Set the tag's Multiplexing property to Enable. The tag then accepts a multiplex index.
3. Define a tag to act as the index pointer, e.g. HeaterIndex (Word) whose current value (1..N) selects which instance is active.
4. In each faceplate property that should follow the index, configure the dynamization to use the multiplexed tag.
5. On the overview screen, write 1, 2, 3... to HeaterIndex to point the faceplate at the corresponding heater.

4.2 Constraints

• Each multiplexed tag must be of the same data type and occupy a contiguous address block of equal stride (e.g. DBD0, DBD4, DBD8... for Real).
• The number of multiplex slots is fixed at compile time (the array size of the base tag).
• Each structure member you want to display must have its own multiplexed tag. If your structure has 10 members, you create 10 multiplex tags per faceplate property.
• Multiplexing does not help if your PLC uses symbolic UDTs whose offsets are managed by the compiler rather than by hand.

5. TIA Portal V20 RT Unified: Tag Parameter Approach

The mechanism that maps to the Rockwell #1 placeholder is the tag parameter in TIA Portal V20 WinCC Unified faceplates. A tag parameter is declared in the faceplate type editor, exposed in the Properties window of every faceplate instance, and resolved against a structure instance that you assign per instance (compile time) or via dynamization (runtime).

According to the official Siemens documentation, the dynamization of an object property using a tag parameter is "only possible for interfaces of faceplate instances." In other words, the tag parameter mechanism is the formal Siemens answer to the tag-placeholder requirement.

Reference: Dynamizing an object property using a tag parameter (RT Unified) - TIA Portal V20 Documentation

5.1 Conceptual Comparison

6. Prerequisites for Tag Parameter Configuration

Before building a multiplexed faceplate in TIA Portal V20, verify the following:

1. Engineering framework: TIA Portal V20 (or V18/V19 with feature pack) with WinCC Unified PC or Unified Comfort Panel runtime installed.
2. PLC UDT: A UDT (USER-DATATYPE) defined in the S7-1500/S7-1200 program that contains all members the faceplate must display (analog values, setpoints, status bits).
3. DB instance: A global DB or instance DB that contains an array of the UDT, e.g. ARRAY[1..16] OF "UdtHeater", with each element representing one field device.
4. HMI connection: An HMI connection configured in "Devices & Networks" with the PLC as the partner.
5. Tag visibility: The HMI tag must be reachable through the connection; configure "Access" rights in the DB if attribute-based access protection is enabled.
6. Faceplate container: A screen (or popup) on which faceplate instances will be placed.

7. Step-by-Step: Building a Multiplexed Faceplate in TIA Portal V20

7.1 Define the PLC UDT

1. In the PLC project tree, expand PLC_x > Program blocks > PLC data types.
2. Add a new UDT named UdtHeater.
3. Declare members:

   TYPE "UdtHeater"
   VERSION : 0.1
      STRUCT
         heater_id            : UINT;      // device identifier
         heater_temperature   : REAL;      // process value in degC
         heater_setpoint      : REAL;      // operator setpoint in degC
         heater_run           : BOOL;      // run command from operator
         heater_state         : WORD;      // status word from PLC
         heater_alarm_active  : BOOL;      // aggregated alarm flag
      END_STRUCT;
   END_TYPE

4. Compile the PLC program so the type is published to the HMI connection.

7.2 Build the HMI Tag Array

1. In the HMI project, expand HMI tags > Default tag table.
2. Create a new HMI tag of type WString (or array) that references the PLC array. The tag name might be Heaters, with PLC path DB_HMI.Heater[1..16].
3. Confirm the tag table shows the element data type as UdtHeater. If not, the HMI connection has not received the type definition; recompile the PLC software.

7.3 Create the Faceplate Type

1. Right-click the HMI project > Add new faceplate.
2. Open the faceplate type editor. In the Interface section, add a new tag parameter named HeaterParam of PLC data type UdtHeater.
3. Add secondary parameters as needed (e.g. Tag_Status of type WString for alarm text).
4. Place visual elements (IO fields, bars, status icons) on the faceplate canvas.
5. For each IO field, configure the Process value property: click the dynamization icon, select Tag, and choose the relevant structure member of HeaterParam (e.g. HeaterParam.heater_temperature).

7.4 Instantiate the Faceplate on a Screen

1. Open the target screen (e.g. Overview_Heaters).
2. From the toolbox, drag the faceplate onto the canvas. The faceplate instance is created.
3. Select the instance. In Properties > Interface > HeaterParam, click the dropdown and select the element of the tag array, e.g. Heaters[1] for Furnace 1.
4. Repeat for Heaters[2], Heaters[3], ... up to the device count.

7.5 Runtime Dynamization of the Tag Parameter

When the requirement is to change the wired instance at runtime (e.g. the operator clicks a button "Show Furnace 5" and the faceplate should follow), the tag parameter itself can be dynamized. Per the V20 documentation, this dynamization is permitted only at the faceplate instance interface.

1. Select the faceplate instance on the screen.
2. Open the Properties window, navigate to Interface > HeaterParam.
3. Click the dynamization icon next to the value field.
4. Choose Tag and bind to a string tag that contains the desired instance name, e.g. SelectedHeater holding the string Heaters[5].
5. From a button event, write the string to SelectedHeater; the faceplate re-resolves the parameter and the IO fields update.

Equivalent JavaScript (WinCC Unified scripting) for the button event:

// "Show Furnace 5" button click handler
export function Button_Furnace5_OnClicked(item) {
    let tag = Tags("SelectedHeater");
    tag.Write("Heaters[5]");
    // The faceplate instance bound to SelectedHeater will
    // re-evaluate the tag parameter and refresh its members.
}

8. Tag Parameter Configuration Reference

9. Verification Procedure

After deploying the faceplate to a Unified PC runtime or Unified Comfort Panel, validate the multiplexing behavior end-to-end:

1. Compile consistency: In the TIA Portal, run Compile > Software (rebuild all). Any unresolved tag parameter generates an error in the "Info > Compile" pane with a clickable reference to the offending faceplate instance.
2. Online tag diagnosis: In the runtime, open Diagnostics > Connections > Tag monitoring. Verify that the array tag Heaters shows good quality (0x00000000 = "good") for all expected elements.
3. Write/read round-trip: From the HMI, change the setpoint of Furnace 1. Verify the value lands in DB_HMI.Heater[1].heater_setpoint using the PLC's watch table.
4. Runtime dynamization: Click the navigation button. The status icon of the new selection should change within one screen update cycle (typically 250 ms in Unified).
5. Alarm behavior: Force an alarm in Furnace 2 from the PLC. The faceplate wired to Heaters[2] should show the alarm state; the faceplate wired to Heaters[1] should remain unaffected.

10. Limitations and Edge Cases

• Parameter scope: A tag parameter is bound to a single instance. If the same faceplate type must be used for two different UDTs (e.g. UdtHeater and UdtPump), declare a second parameter with the other data type, or use a generic "Variant" parameter (V20 supports PLC data type Variant as a parameter type, with appropriate interface guards).
• Pointer-style dynamization: The runtime cannot dereference a pointer stored in a PLC tag to a faceplate parameter. The dynamized value must be a literal string, an HMI tag, or a script-returned string.
• Cross-project re-use: A faceplate type defined in the HMI library can be reused across projects, but the tag parameter must be re-wired on every instance in every project. There is no global "default parameter" across instances.
• OPC UA exposure: If the same UDT is exposed via OPC UA, the server provides the same symbolic path the HMI uses for the tag parameter. A SCADA client can therefore target any element of the array with no extra engineering.
• Panel vs PC runtime: Unified Comfort Panels and Unified PC runtimes implement the tag parameter feature identically, but the PC runtime additionally supports script-driven re-resolution at sub-second rates. Panels may have a longer refresh latency under heavy alarm load.

11. Migration Path from WinCC flexible 2008 to TIA Portal V20

Existing WinCC flexible 2008 projects that flatten structures into multiplexed tags should be migrated in three steps:

1. Convert the legacy HMI tags to a UDT array in the S7-1500 project. The compiler will warn about any tags whose type does not match the UDT member type.
2. Recreate the faceplate in TIA Portal V20 as a faceplate type with a single tag parameter of the UDT data type. Re-link the IO fields to members of the parameter.
3. On the migrated overview screen, replace the N faceplate copies with N instances of the new faceplate type, each wired to a different array element. The script that wrote to the multiplex index tag in the legacy system can be removed.

12. Summary

The Rockwell tag-placeholder pattern does not have a direct equivalent in WinCC flexible 2008 SP2, where structures cannot be multiplexed into a faceplate instance. Address multiplexing on individual tags remains the available workaround in that generation. In TIA Portal V20 RT Unified, the equivalent capability is provided by the tag parameter of the faceplate type, which accepts a structure instance and can be dynamized at runtime through a tag or script. Engineers porting legacy faceplates or designing new multiplexed HMIs should adopt the tag-parameter pattern in TIA Portal V20 to eliminate the duplication that the older faceplate workflow forces.