Understanding OS Compilation Warnings: 'The Structure Type Has Been Changed Since the Last Compilation'

In SIMATIC PCS 7, during an incremental OS compilation ('Compile Changes'), the warning log entry stating that a structure type has been changed and associated structured tags will be deleted is a standard database synchronization notice. It indicates that a block type interface (such as CTRL_PID or an SFC Type) was modified in Step 7. Because WinCC structure types are project-wide, WinCC deletes and regenerates the template to match the new schema. In single-AS systems, this warning is harmless. In multi-AS architectures, however, compiling only one controller will orphan tags in other uncompiled controllers. To resolve this safely, engineers must update the block type across all AS programs and select all controllers during the OS compilation.

Architecture of WinCC Structure Types and AS-OS Tag Mapping

In SIMATIC PCS 7, process blocks instantiated in CFC (e.g., CTRL_PID, MotL, VlvL) do not generate hundreds of isolated floating tags in WinCC. Instead, the AS-OS Engineering compiler maps each block instance to a unified WinCC Structure Type.

A Structure Type acts as an object-oriented template: for example, structure type CTRL_PID defines element tags .PV_In, .SP, .LMN, .Manual, and .Status1. When an instance TIC_101 is compiled, WinCC creates a single structured tag TIC_101 whose internal elements inherit the properties of the master structure type definition.

Root Cause Analysis: Why Structure Type Changes Trigger Warnings

When an engineer modifies a block interface in Step 7—such as adding an auxiliary input pin, changing an engineering unit attribute, or updating an SFC Type—the compiler must reconcile the WinCC database:

Global Scope of Structure Types: Structure types inside a WinCC .mcp project are global; they do not belong to an individual controller.
Atomic Regeneration: Microsoft SQL Server and WinCC Tag Management cannot dynamically alter an active structure type schema while instances exist. To apply the change, the compiler deletes the obsolete structure type and all instantiated tags, writes the new definition, and regenerates the instance tags.
Warning Notification: The compiler outputs this warning to alert the engineer that all existing tags bound to this structure will be briefly deleted and recreated.

The Multi-AS Architecture Hazard: Orphaned Tags Across S7 Programs

While harmless in single-controller projects, this warning represents a critical hazard in multi-AS environments:

The Discrepancy Trap: Suppose an OS Server monitors AS01, AS02, and AS03. An engineer updates CTRL_PID in AS01 to version V2, but leaves AS02 and AS03 running version V1.
Tag Annihilation: When the engineer compiles AS01 to the OS, the compiler deletes the master CTRL_PID structure type and rebuilds it as V2. Because AS02 and AS03 were NOT included in this compilation and still hold V1 blocks, the compiler cannot generate the tags for AS02 and AS03!
Runtime Outage: Faceplates for all PID controllers on AS02 and AS03 immediately disconnect, displaying yellow exclamation marks and broken tag links.

Step-by-Step Procedure to Safely Reconcile Structure Type Changes

To prevent tag loss across multi-AS plants when a block type or SFC Type changes:

Synchronize Master Library: Copy the updated block type (or SFC Type) into the project's centralized Master Library.
Update Block Types Across ALL S7 Programs: In SIMATIC Manager, open each AS program in turn. Open CFC, navigate to Options > Block Types..., and update the modified block type across AS01, AS02, and AS03.
Compile All CFC Programs: Compile the CFC charts across all affected controllers.
Execute Multi-AS OS Compilation:
- In SIMATIC Manager, right-click the OS Server and select Compile.
- In the 'Select the S7 programs' window, ensure the checkboxes for ALL controllers sharing this structure type are checked.
- Execute compilation. The compiler creates the new structure type and cleanly recreates all instance tags across all automation stations.

Comparison of OS Compilation Scopes and Structure Type Impacts

The following table compares OS compilation scopes when structure types are altered:

Compilation ScopeMulti-AS HandlingWinCC Runtime ImpactTag PreservationRisk LevelChanges Only (Single AS Checked)Fails to update unchecked AS controllersMinimal runtime interruptionDestroys instance tags on unchecked AS stationsHigh (Orphans tags)Changes Only (All AS Checked)Updates all AS controllers simultaneouslySeamless online update100% Preserved across all stationsLow / RecommendedEntire OS (With Memory Reset)Completely rebuilds all structures from scratchRequires stopping WinCC Runtime100% Clean rebuild (Deletes obsolete tags)Safest for Major TurnaroundsDelta Compile without CFC CompileUses stale offline DB dataUnpredictableMismatched tag addressesCritical Failure Risk

Verification

Verify tag management integrity after OS compilation:
1. Inspect the OS compilation log; confirm that compilation finishes with '0 Errors'.
2. Open WinCC Explorer on the Engineering Station; expand Tag Management > Structure Types.
3. Select the modified structure type (e.g., CTRL_PID); verify that the element list reflects the new parameter interface.
4. Expand the Tag Management hierarchy under Named Connections; confirm that tag instances from all AS controllers are populated with valid data types.
5. Open WinCC Runtime; confirm that faceplates across all automation stations display live process values without communication dropouts.

Limitations and Operational Precautions

Never perform an OS compilation that deletes and recreates structure types while critical plant operations depend on active WinCC archiving or script calculations, as the momentary recreation of tags can cause transient script errors. In large projects, always create a project backup prior to updating global block types or executing OS compilations.

Engineer FAQ

Is the 'Structure type has been changed' warning dangerous?

In a single-AS project, no. It is an informational warning indicating that WinCC had to recreate the structure tag template. In a multi-AS project, it IS dangerous if you only compiled one AS, because tags on the other AS controllers will be deleted until they are also compiled.

Why did my faceplates show yellow exclamation marks after OS compilation?

This occurs when an updated structure type deleted old tags, and the compilation did not include all S7 programs that use that block, leaving the uncompiled controllers' tags deleted from the WinCC database.