Using HMI Styles Inside TIA Portal Faceplates: Siemens Guide

Problem Statement

Engineers working with TIA Portal V15.1, a TP900 Comfort HMI, and an S7-1515F PLC frequently need to apply global HMI Styles to objects that live inside reusable Faceplates. The intuitive workflow — open the Faceplate editor, select an object, pick a style from the Style gallery — is not supported. The Style library is a global project resource, while a Faceplate type is an encapsulated, version-controlled black box. Attempting to drag, rename, or re-skin a style inside the Faceplate editor produces no effect, and rebuilding the Faceplate from scratch to absorb style changes destroys every property assignment on every instantiated occurrence on every screen.

This reference documents the only Siemens-supported mechanism for binding HMI Styles to Faceplate content: passing the Style Item name as a configuration parameter on the Faceplate interface, and consuming it on each contained object via the Style item appearance property. It also documents a development technique for adding newly styled objects to an existing Faceplate without rebuilding the type.

Prerequisites

• Siemens TIA Portal V15.1 (or compatible) with WinCC Comfort/Advanced V15.1 engineering component installed.
• SIMATIC TP900 Comfort HMI panel (6AV2 124-1JC01-0AX0 family, 9" widescreen, 800 × 480 pixels) targeted as the runtime device.
• SIMATIC S7-1515F CPU (6ES7 515-2FM02-0AB0 or compatible F-variant) configured as the HMI connection partner.
• An existing project containing at least one global Style (Project tree → HMI → Styles > <style name>) with one or more defined Style items (for example HeaderDark, BodyLight, AlarmActive).
• An existing Faceplate type (Project tree → HMI → Faceplates → <FP name>) used by one or more Faceplate instances on process screens.
• Read access to the official Siemens support entry: 109773506 — Faceplates and Styles in TIA Portal.

Root Cause: Why Direct Style Editing Fails Inside the Faceplate

Siemens documentation states explicitly: "Styles and style items can be assigned to faceplate instances. However, there is no direct connection between the faceplate types and styles, so selection and preview of a style item in the faceplate editor is not possible." The architectural reason is that a Style is a project-global, dictionary-based resource evaluated at compile time on a per-instance basis, whereas a Faceplate type is a templated, self-contained container that the editor cannot cross-reference into the Style repository. The editor therefore cannot render a style preview, cannot offer a style picker, and cannot guarantee that the named style item still exists when the Faceplate is compiled.

Because of this, any attempt to:

• Open the Faceplate editor and change a contained object's appearance via the Styles task card — has no effect.
• Re-create the Faceplate from a styled screen to absorb new style assignments — destroys all property bindings on every instance.
• Switch a global Style and expect automatic propagation into Faceplate internals — only succeeds where style items are wired through the Faceplate interface.

are unsupported. The supported alternative routes the style name through the Faceplate interface.

Architecture: HMI Styles, Style Items, and Faceplate Encapsulation

Three concepts must be clearly separated before any implementation step is taken.

The Style item name therefore functions as a string-typed contract between the Style repository and any container (Faceplate, screen, library object) that wants to opt into that visual variant. The string is resolved at compile time against the active Style; if the name does not exist, the appearance falls back to the object's base properties without a build error.

Step-by-Step: Assigning a Style Item to a Faceplate Instance

1. Open the Faceplate type in the editor (Project tree → HMI → Faceplates → <FP name> → double-click).
2. Select the target object inside the Faceplate (button, text field, rectangle, IO field, etc.).
3. In the Properties window, expand the Appearance group and locate the property Style item appearance. This is a string-typed field; it is not a drop-down picker.
4. Enter the literal name of the desired style item exactly as defined in the Style. Example: @Style.item.HeaderDark or simply HeaderDark depending on the project convention established in TIA Portal V15.1. The string is case-sensitive.
5. Close the Faceplate editor. Do not expect the appearance to update inside the editor; the Style is not resolved against the Faceplate type.
6. Open every process screen that contains a Faceplate instance. Select each instance and, in its Properties window, verify (or assign) the Style item appearance of the contained object through the instance's interface — this step propagates the style binding from the type to the instance.
7. Compile the HMI (right-click HMI device → Compile → Software (all)). The Style is now resolved against the active Style in the Style repository.
8. Download to the TP900 Comfort and verify the appearance on the panel.

Step-by-Step: Adding New Styled Objects to an Existing Faceplate

The problem of expanding an existing Faceplate with new objects that must carry the project Style is solved without rebuilding the type by using a development screen as a staging area.

1. Create a temporary development screen in the HMI project (Project tree → HMI → Screens → Add new screen → Dev_StyleStage).
2. Place the new object on the development screen and assign the desired HMI Style to it via the Styles task card. Confirm the visual is correct on this screen.
3. Select the styled object on the development screen, Ctrl+C.
4. Switch to the Faceplate editor, place the cursor at the desired insertion point, and Ctrl+V. The object is pasted into the Faceplate while still carrying its style assignment.
5. Re-wire any required Faceplate interface tags (e.g. Tag, Visible, Enabled) to the pasted object using the standard Faceplate interface editor.
6. Compile the HMI and verify each instance on its host screen.

This technique preserves the Faceplate type identity, all existing property bindings, and the Style binding of the new object. It does not allow changing the Style of an object that was added to the Faceplate before this procedure was established — for that, the Style must be passed as an interface parameter (see next section).

Interface Parameter Configuration for Style Propagation

To allow a single Faceplate type to adopt different style items at runtime — for example, a header that toggles between HeaderDark and HeaderLight based on an operator role — the style item name must be promoted to a Faceplate property on the interface.

1. Open the Faceplate interface editor (right-click the Faceplate in the project tree → Interfaces).
2. Add a new property of category Display (or General), name it e.g. HeaderStyle, and set its data type to String or WString. The default value should be a known style item name, for example "HeaderDark".
3. Select the header object inside the Faceplate. In Properties → Appearance, set Style item appearance to a formula that reads the interface property, for example: 'Faceplate.HeaderStyle' or a script expression that returns the current value of the HeaderStyle tag.
4. Compile. On every instance, the Style item appearance field of the instance is now driven by the interface property, which can be bound to a PLC tag (e.g. DB_HMI.Config.HeaderStyle) for runtime switching.

Style Item Name Resolution Rules

• Resolution is case-sensitive. HeaderDark and headerdark are distinct strings; only one will match.
• Resolution is performed at compile time against the active Style assigned to the HMI device.
• If the named style item does not exist in the active Style, the object renders with its base appearance — the build does not warn or fail.
• If the HMI device has no Style assigned, Style item appearance is ignored entirely.
• Switching the active Style on the HMI device re-resolves every Style item appearance binding in the next compile; no manual patching of Faceplates is required.

Validation and Verification

1. Compile the HMI (right-click TP900 → Compile → Software (all)). Inspect the compile log for any warnings related to faceplate, style, or property resolution.
2. Start RT simulation on the engineering PC (Start → Programs → Siemens Automation → TIA Portal V15.1 → HMI RT Simulation). The TP900 project is simulated with the connected S7-1515F logic.
3. Open every screen that hosts a Faceplate instance. For each instance, confirm visually that the style item is rendered (color, border, font, etc.).
4. Where the style is driven by an interface property bound to a PLC tag, toggle the tag value in the PLC (use a watch table in TIA Portal) and confirm the appearance switches on the simulation.
5. Download to the TP900 Comfort, repeat the tag-toggling test against the real panel, and confirm visual switching.
6. Save a project screenshot per Faceplate variant for the commissioning dossier.

Limitations and Edge Cases

• No style preview inside the Faceplate editor. Engineers must validate on the instance (screen, RT, or panel). Plan extra time in commissioning for visual verification.
• No style picker in the editor. Style item names are typed, not selected. Establish a naming convention and a review checklist to prevent silent typos.
• No automatic style migration. If a Style item is renamed in the Style editor, every Faceplate that referenced the old name silently falls back to base appearance. Use the project-wide cross-reference (Project tree → HMI → Styles → right-click → Cross-references) to find affected Faceplates before renaming.
• Style scope is per HMI device. A Style defined in one HMI's project tree is not visible to another HMI. If multiple panels share Faceplate types, the Style repository must be replicated on each HMI device.
• Library Faceplates shipped from Siemens (e.g. from the WinCC Faceplate Library) typically hard-code style items internally. Re-skinning them requires creating a project-local copy of the Faceplate type and then applying the procedure above.
• Unified Comfort vs WinCC Unified: the behaviour described applies to the Comfort panel family running WinCC Comfort/Advanced. SIMATIC WinCC Unified (TIA Portal V16+) introduced a different Style concept with first-class support inside Faceplate containers; the V15.1 procedure documented here is not interchangeable.

Firmware and Software Version Considerations

Troubleshooting Matrix

FAQ