brands · South Africa
WinCC Unified Screens: Tags, Faceplates and Quality Tests
Learn WinCC Unified tag acquisition, faceplate interfaces and instance binding, with worked tests for data quality, stale values and independent displays.
WinCC Unified screen design starts with a data contract: which value an object displays, where that value comes from, how it is updated and what the operator sees when it cannot be trusted. Faceplates make a design reusable, but they also repeat mistakes if their interfaces or instance bindings are wrong. A good first project therefore tests two independent instances and several abnormal data states.
This guide uses Siemens WinCC Unified V20 documentation for the engineering workflow, checked on 13 September 2026. Match the instructions to your installed version and HMI target. The worked example is a fictional display model with independently tested expected results. It is not a downloadable Unified project, a commissioned HMI or evidence of native runtime testing.
We operate PLC Simulation Software and may benefit from the product links below. Its general learning resources do not establish Siemens approval, native WinCC project support or access to Siemens engineering licences.
Establish the HMI target and the tag contract
Record the engineering release, target device or runtime, PLC family and intended connection before creating screens. A statement that the project uses TIA Portal is not enough to identify every supported HMI feature. Keep an inventory of the actual project components so an instructor or reviewer can reproduce the environment.
For each displayed value, document its name, data type, units, permitted range, update requirement and meaning when quality is poor. Distinguish the source value from its presentation. A temperature of zero, an unavailable temperature and a last-known temperature of zero should not silently become the same screen state.
For each operator entry, describe the requested action separately from the resulting equipment state. A button press expresses an intention. The screen needs suitable feedback to establish whether the receiving logic accepted that intention and what happened afterwards. The fictional example below is read-only, so it deliberately avoids implying that changing a display performs a physical command.
If project tags are unfamiliar, begin with TIA Portal tags and project basics. For a wider view of supervisory information, read the SCADA learning guide. A clear data contract makes both topics easier because it identifies which system owns each fact.
Configure acquisition using Unified terminology
The checked V20 page on defining a tag's acquisition cycle describes two modes: cyclic in operation and on demand. The former updates a tag periodically while it is displayed or archived; the latter updates when requested, for example through the documented update function or a script. The acquisition settings are in the tag's Inspector properties under Settings.
Choose an update requirement for the information being displayed, then configure and test it in the actual project. A shorter configured interval is not proof that the entire sensor-to-screen path meets the same response time. Acquisition, communication, processing and rendering are different stages.
A value-change script trigger is also a different concept from the acquisition mechanism that supplies the value. Do not label an acquisition mode “on change” simply because an event can react to a changed tag. Keep the source update requirement, event condition and visible result as separate entries in the test plan.
For a training exercise, begin with a small set of tags whose behaviour you can trace. Add logging, scripting and more instances after the simple path is understood. If a value stops changing, first determine whether the source changed and whether the HMI acquired the new value before rewriting the screen object.
Separate faceplate tags from appearance properties
A faceplate type describes reusable content; a faceplate instance places that content in a screen with particular connections and settings. The interface is the boundary between the reusable type and the project that uses it. Treat that boundary like a small specification rather than a collection of convenient names.
Siemens documents interface tags in a Unified faceplate type as the communication interface linked to project tags through the faceplate container. Its guidance also warns that renaming an interface tag can reset values already connected at the container to their defaults. Review the affected instances after an interface change.
The V20 interface-property example demonstrates a separate appearance property: a colour exposed by the faceplate type and assigned to an object's background. This illustrates why a process-data connection and a configurable visual property should not be treated as the same thing.
For the fictional measurement card below, define a channel identity, numeric measurement, quality classification and observation time as input information. Define a descriptive label and unit text as presentation settings. The precise native data types and bindings must be selected for the installed environment; these educational names are not a Siemens built-in faceplate interface.
Keep the reusable component focused. A measurement card does not need unrelated recipe settings or hidden command logic. A smaller interface makes it easier to identify an unconnected input, review a version change and demonstrate that two instances remain independent.
Instantiate and check two different connections
The V20 instructions for creating a faceplate instance describe using a released library version in a screen, then connecting tags and assigning properties in the container's Miscellaneous interface settings. The documentation also distinguishes device classes: a Runtime Advanced faceplate type cannot simply be used as a Unified HMI faceplate. Check the type and target together.
Create two instances for the assessment, named Channel A and Channel B in the learning notes. Give them visibly different labels and deliberately different test values. If both display the same number throughout development, an accidental shared binding may remain invisible.
Record each instance's source connection in a small mapping table. Include the actual project tag for the measurement, the quality input and the timestamp or age information used by the application. Reviewing only the displayed label is insufficient because a correctly labelled card can read another channel's data.
Use the project tools and runtime evidence to verify the mapping. A screenshot of a number establishes appearance at one moment, but it does not prove which tag produced it. Change one classroom source at a time and observe which instance responds. Keep the exercise isolated from operational equipment.
Quality is information, not a replacement number
The V20 TagResult quality-code reference describes quality, substatus and limit information, including bad, uncertain and good categories. When more than one status applies, the documented result reflects the poorest quality. Interpret the complete applicable code instead of assuming every nonzero code means success.
The worked model uses the simplified words Good, Uncertain and Bad as already-interpreted inputs. It does not reproduce the native numeric encoding or provide a script for decoding every connection's status. That translation is a separate implementation task requiring the matching vendor reference and actual runtime evidence.
Quality and freshness answer different questions. A successfully read value can still be older than the display's accepted age. A newly timestamped value can have poor quality. The screen should avoid presenting either case as an ordinary current measurement merely because a numeric field can render it.
Worked display model: value, quality and age
Define a fictional measurement card for a percentage. Its configured identity is A or B. Each input packet has a matching channel identity, a finite numeric value from zero to 100, a recognised quality word and a non-negative whole-number observation timestamp in milliseconds. The current time is also a non-negative whole number in the same clock domain.
The exercise accepts an age of zero through 2,000 milliseconds inclusive. Age is current time minus observation time. A future observation time is invalid rather than fresh. The same-clock assumption is explicit: subtracting unrelated device clocks would not establish a meaningful age without additional time coordination.
Evaluate the following rules in order. A wrong channel identity produces Binding mismatch. A malformed field, unrecognised quality word, out-of-range value or invalid time produces Invalid data. Bad quality produces Unavailable. Uncertain quality produces Uncertain. A remaining Good packet older than 2,000 milliseconds produces Stale. Otherwise the card is Current.
Only Current displays the measurement as a current number. Every other state displays a dash in the numeric area and a text explanation. The model does not retain the previous number. A design that keeps a last-known value could also be specified, but it would need an unmistakable label and separate tests. Do not accidentally implement that different design by leaving an old field untouched.
This ordering is part of the contract. A wrong channel with bad quality still reports Binding mismatch. A malformed value with Bad quality reports Invalid data. A well-formed Uncertain packet that is also old reports Uncertain under this single-status model. A production interface might show several diagnostics, but that is not what this simplified assessment specifies.
Boundary table with expected answers
Set the configured channel to A and current time to 10,000 milliseconds. Unless a row says otherwise, use a packet for A with Good quality and value 42.5. The following table isolates freshness, validity and channel identity so each expected result can be checked independently.
| Changed input | Result | Numeric display | Reason |
|---|---|---|---|
| Timestamp 10,000 | Current | 42.5 | Age zero |
| Timestamp 8,000 | Current | 42.5 | Age exactly 2,000 |
| Timestamp 7,999 | Stale | Dash | Age 2,001 |
| Timestamp 10,001 | Invalid data | Dash | Observation is in the future |
| Value 0, timestamp 9,000 | Current | 0 | Valid zero measurement |
| Value 100, timestamp 9,000 | Current | 100 | Valid upper boundary |
| Value 100.1, timestamp 9,000 | Invalid data | Dash | Outside the declared range |
| Bad quality, timestamp 9,000 | Unavailable | Dash | Numeric value is not presented as current |
| Uncertain quality, timestamp 9,000 | Uncertain | Dash | Quality policy rejects a current number |
| Packet for B, timestamp 9,000 | Binding mismatch | Dash | Wrong channel identity |
Test malformed inputs separately: a missing number, a numeric-looking string, an unknown quality word and a fractional timestamp are invalid under this contract. A fractional measurement such as 42.5 is valid. This distinction prevents a broad “whole numbers only” validation rule from rejecting legitimate measurement data.
The local reference model verifies these cases. That result establishes consistency between the fictional specification and its test implementation. It does not demonstrate native Unified tag binding, network performance, device compatibility or a completed Siemens project.
Recovery and two-instance tests
Begin with Channel A showing 25 from a Good packet observed at time 9,000 while the current time is 10,000. Re-evaluate the same packet at time 11,001. It is now Stale and the numeric display becomes a dash. If the implementation leaves 25 visible without qualification, it violates this exercise's rule even though the number was once valid.
At current time 11,002, accept a new Good packet observed at 11,000 with value zero. The card becomes Current and displays zero. A common mistake is to treat zero as equivalent to a missing value. This sequence exposes that defect while also proving recovery from a stale state.
For independence, supply Channel A with 25 and Channel B with 75, both fresh and Good. Change A to zero while leaving B unchanged. The expected displays are zero and 75. Then mark A's quality Bad. A becomes Unavailable while B remains Current at 75.
Finally, deliberately pass B's packet to A's configured card. The identity check should report Binding mismatch. This check only works because the fictional packet contains an independently supplied identity. If an implementation invents the identity from the card's own label, it cannot detect a crossed source binding. Native projects still require a real mapping test.
Include combined-condition cases to verify precedence. A B packet with Bad quality sent to A remains Binding mismatch. An A packet with a missing value and Bad quality remains Invalid data. An old, well-formed Uncertain packet remains Uncertain. These cases stop the order of conditions from changing unintentionally during a visual redesign.
The PLC program testing guide helps structure evidence around a symptom and its cause. For reusable controller logic behind the interface, the Siemens FB instance guide explains a related distinction between a reusable definition and independent stored state.
Screen behaviour to assess beyond the number
A readable measurement card needs a clear label, unit and status explanation. Colour can reinforce a state, but the text should carry the meaning independently. Give the learner a monochrome screenshot and ask which channel is stale. If the answer depends entirely on colour, the diagnostic information is incomplete.
Check the layout at the intended device size and with the longest realistic label. A tidy engineering view can conceal clipped runtime text. Include a long status such as Binding mismatch and confirm that it remains readable without covering the measurement or another control.
If navigation opens and closes the screen, repeat the stale-data test after returning. The first visible number should comply with the same contract as a continuously open screen. Do not assume navigation itself refreshes every piece of information required by the application.
For a multi-user project, identify which settings are shared and which belong to an individual session. The checked Unified runtime tag guidance distinguishes system-wide internal tags from local-session tags and notes that session-local values are lost when that session ends. A shared process fact and a user's navigation preference need deliberate ownership.
Diagnose a screen that looks connected but is wrong
Work from evidence at successive boundaries. First establish the intended source value in the classroom project. Then inspect the HMI tag and its connection, the faceplate container mapping, the object's binding and the rendered state. Record the first boundary at which the observed value differs from the expected one.
If every instance shows A's value, inspect the bindings before changing update rates. If values are correct but appear old, investigate acquisition and the freshness policy. If the screen shows a dash, identify whether the model classified the packet as invalid, unavailable, uncertain or stale. Replacing every dash with zero destroys that distinction.
When a browser cannot reach a runtime, use the configured deployment details and the matching Siemens setup documentation. This guide does not prescribe a universal port, certificate workaround or restart behaviour. A connection problem and a screen-binding problem require different evidence. Record the actual error before altering configuration.
The industrial communication troubleshooting guide provides a broader sequence for separating addressing, transport and application data. Keep any diagnosis within the authorised training environment and preserve the original project before a controlled change.
Use this topic in a South African training plan
When comparing WinCC Unified courses in South Africa, request the precise target, engineering release and amount of individual practical access. Ask whether learners build and bind their own faceplate instances, test poor-quality data and investigate a deliberately crossed connection. A slide about reusable graphics does not establish those practical outcomes.
Use the Siemens training hub to connect HMI learning with controller fundamentals. Regional learners can also compare the Durban Siemens course enquiries and Sasolburg regional training route, while confirming actual delivery details directly with providers.
For general preparation, inspect the product's HMI simulator learning page and PLC program testing resources. Confirm the current scope before buying. General simulation can support reasoning about displays and tests, while native WinCC engineering remains a separate practical requirement.
A training centre can assess this exercise with the requirement table, two instance mappings, boundary results and one corrected defect. The training-centre evaluation guide helps connect that evidence to a purchasing decision. Keep software-model results and native runtime results clearly labelled in the learner's portfolio.
WinCC Unified questions and answers
Is a faceplate interface tag the same as a visual property?
They serve different purposes in the documented workflow. Use the tag interface for the project-data connection and the appropriate property interface for configurable presentation. State the intended meaning of each entry before choosing its native type and binding.
Is on-change the acquisition mode recommended here?
No. The checked V20 acquisition documentation describes cyclic in operation and on demand. An event that reacts to a value change is a separate mechanism. Select and test the acquisition arrangement against the information the screen needs.
Why can a good-quality value still be stale?
Quality describes the accepted status of the value, while freshness compares its observation time with the current time under a declared clock and age policy. The fictional model requires both Good quality and age no greater than 2,000 milliseconds before displaying a current number.
Does a faceplate identity field prove the native binding is correct?
Only when that identity is independently supplied by the source and checked meaningfully. A label copied from the screen cannot validate its own connection. Test two distinct sources and trace the real container mappings in the native project.
What is the most useful first faceplate assessment?
Use two read-only measurement cards with different sources. Check valid zero, upper and lower boundaries, stale data, poor quality, recovery and a deliberately crossed binding. This gives a small, reproducible exercise whose correctness can be assessed before adding commands or a large screen library.
