WinCC Internal Tag Runtime Persistence: BOOL Value Not Retained After Runtime Stop

Engineers using SIMATIC WinCC V7 or WinCC Unified to track plant work orders, lockouts, or alarm acknowledgements with internal BOOL tags frequently observe tag values resetting to 0 after stopping or deactivating Runtime. Integer and floating-point internal tags on the same project persist correctly, while BOOL tags appear to ignore the Runtime Persistence setting. This reference documents the underlying behavior of the Runtime Persistence flag, the mandatory interaction with the Start Value property, the data-type-specific retention rules, and the step-by-step configuration procedure that produces reliable persistence on both WinCC V7 and WinCC Unified (TIA Portal V20).

1. Problem Description

A WinCC V7 project contains internal tags (one BOOL used as a work-in-progress indicator and one UINT16 used as a counter) configured with the Runtime Persistence checkbox enabled in the tag properties. After Runtime (RT) is started, the engineer writes 1 to the BOOL and writes a non-zero value to the UINT16. RT is stopped, the project is deactivated, and WinCC Explorer is closed.

When the project is restarted:

• The UINT16 returns the last runtime value (persistence works).
• The BOOL returns to 0 (persistence appears to fail).

This behavior was reproduced on multiple installations running WinCC V7.0 SP2, WinCC V7.0.2.0, and WinCC V7.0.2.1 on Windows XP embedded and Windows 7. It also surfaces on PCS 7 V7.1 SP3 engineering stations that host a WinCC V7 component and on workstations with the SICAM PAS CC add-on installed.

2. Root Cause Analysis

Runtime Persistence was introduced for internal tags in WinCC V7.0 to allow HMI-resident values to survive a Runtime stop, project deactivation, or even WinCC Explorer close-and-exit. The mechanism stores the last runtime value of each persisted tag to the project database on the engineering station/runtime server and re-applies it on the next RT start.

Independent field testing demonstrates that the Runtime Persistence checkbox alone is not sufficient to guarantee retention. The Start Value checkbox must also be enabled, and an explicit initial value must be assigned. Without a defined start value, the persistence layer has no anchor point for the first start and the BOOL variable is re-initialized to its default state (FALSE/0) on subsequent starts.

The reason BOOL tags are reported more often as failing is engineering convention: BOOL tags are frequently left with an undefined Start Value (Start Value checkbox disabled), because the default BOOL semantics of "off / not in use" seem adequate. Floating-point and integer tags used in HMI faceplates are usually configured with explicit Start Values because the engineer is already specifying a valid engineering range.

3. Solution

Configure both the Start Value checkbox and the Runtime Persistence checkbox, then supply a defined initial value (0 or 1 for BOOL; 0 or the expected engineering low-scale value for numeric types). Save the project, recompile, and restart Runtime to verify.

3.1 WinCC V7 Procedure

1. Open WinCC Explorer and load the project.
2. In the Tag Management editor, right-click Internal Tags and select New Tag or open the existing tag.
3. On the General tab, set the data type (Binary Tag for BOOL, Unsigned 16-Bit Value for UINT16, Floating-Point Number 64-Bit IEEE 754 for REAL, etc.).
4. Switch to the Limits/Reporting tab (in some service packs this is labeled Properties / Limits/Reporting).
5. Locate the Start Value group. Enable the Start Value checkbox.
6. Enter the initial value in the adjacent numeric input: 0 for a safe default BOOL, 1 if the tag should start in the active state.
7. On the same tab, enable the Runtime Persistence checkbox.
8. Click Apply then OK. The tag now has a defined anchor value and a persistence directive.
9. Repeat for every internal tag that must survive an RT stop.
10. Save the project. Right-click the project in the WinCC Explorer tree and select Rebuild to regenerate the RT database.
11. Activate Runtime. Change the tag value through a script, a button event, or a faceplate I/O field.
12. Deactivate Runtime (do not close WinCC Explorer on the first test).
13. Reactivate Runtime and confirm the previous value is restored.

3.2 WinCC Unified (TIA Portal V20) Procedure

In WinCC Unified the persistence behavior is documented as: Internal tags are stored in the memory of the HMI device. Therefore, only this HMI device has read and write access to the internal tags. See the official Siemens TIA Portal V20 - Internal Tags (RT Unified) reference for the canonical definition.

1. Open the TIA Portal project and navigate to HMI Tags under the Unified Comfort Panel or Unified PC runtime node.
2. Double-click the internal tag to open the tag editor.
3. In the Properties inspector, expand the Value group.
4. Set Initial Value to a defined value (for BOOL: true or false; for INT: 0 or the engineering low scale).
5. Expand the Persistence group and enable Persistent. In WinCC Unified this is the direct equivalent of the V7 Runtime Persistence checkbox.
6. Compile the HMI device (right-click the device > Compile > Software (rebuild all)).
7. Download to the panel or start the Unified PC Runtime simulation.
8. Modify the tag value via a button configured with the SetTagValue system function or via a script.
9. Stop the runtime (or power-cycle the panel) and restart. The previous value will be restored.

4. Why BOOL Behaves Differently

The behavior is not a bug in the BOOL data type - it is a side-effect of the Start Value initialization path. When Start Value is disabled, BOOL defaults to FALSE on each RT start because the runtime initializes the tag using a zero-length memory pattern. Numeric types happen to retain the last-written pattern because the WinCC V7 memory manager treats uninitialized-but-persisted DWORD slots as preserve rather than zero. BOOLs share the same storage slot (a BYTE/DWORD), but the persistence layer flags a BOOL with an undefined Start Value as not initialized and applies the zero-fill default.

Engineering implication: always define a Start Value for any BOOL tag whose state carries semantic meaning (work-in-progress, alarm-acknowledged, valve-open-request). The cost of setting Start Value = 0 is zero; the cost of an undefined BOOL on a power-up race is a missed alarm or an incorrect faceplate state.

5. Verification Procedure

1. Create a test project containing one BOOL internal tag and one UINT16 internal tag.
2. Enable Start Value = 0 for both and Runtime Persistence for both.
3. Start RT. Use the WinCC Tag Simulator or a button script with SetTagBit / SetTagWord to set BOOL = 1 and UINT16 = 12345.
4. Stop RT.
5. Deactivate the project.
6. Close WinCC Explorer completely (verify via Task Manager that CCExplorer.exe is gone).
7. Re-open WinCC Explorer, load the project, activate RT.
8. Read both tags. Both must equal the last-written value.

5.1 Diagnostic Logging

Enable the WinCC RT diagnostic file to capture persistence events:

• Open WinCC Explorer > Computer node > right-click the local computer > Properties > Runtime tab.
• Check Activate diagnostic file and set the path (default: C:\Program Files\Siemens\Automation\WinCC\Diagnose\).
• Restart RT and review WinCC_Sys_.log for lines containing Persistence, Restore, or Tag init.

6. Architecture and Storage Location

The following SVG diagram shows the persistence storage path for WinCC V7 internal tags on a single-user project and on a client/server project. For WinCC Unified, replace the WinCC V7 database with the Unified runtime memory model documented in the official Siemens reference.

7. Migration to WinCC Unified

When migrating a WinCC V7 project to a Unified Comfort Panel or Unified PC Runtime, the persistence attribute is preserved if the tag is re-imported with the same name and data type. The Start Value mapping is direct: V7's Start Value becomes Unified's Initial Value. V7's Runtime Persistence becomes Unified's Persistent property in the tag inspector.

8. Version-Specific Notes

9. Edge Cases and Field-Proven Caveats

• Client/Server projects: Runtime Persistence applies to the server's project database. Clients read the persisted value from the server on connect, but the persistence write is performed only on the server. Verify the server (not just the client) is configured with the tag's persistence enabled.
• Redundant server pairs: When a WinCC V7 redundant server pair fails over, the preferred server's persisted values are used. If both servers have diverged, manual archive synchronization is required.
• SICAM PAS CC add-on: Power-utility substation projects frequently use SICAM PAS CC on top of WinCC V7. Persistence behaves identically, but the add-on writes its own process tags that are not affected by Runtime Persistence - they must be tracked through SICAM PAS configuration.
• Tag rename: Renaming a persistent tag creates a new tag identity; the old persistence record is orphaned. The renamed tag will start from its Start Value.
• Data type change: Changing BOOL to UINT16 or vice versa resets the persistence slot. The tag starts from Start Value.
• Project duplication: Copying a project duplicates the persistence database. Both projects will then retain their own values independently.
• Multiple RT instances: Running RT twice on the same project (e.g., test and production) corrupts the persistence file. Use separate project folders.
• Power loss mid-write: The persistence layer commits to the SQL database on RT stop, not on every value change. A hard power loss before RT stop reverts to the last successful commit.

10. Troubleshooting Matrix

11. Frequently Asked Questions