Siemens WinCC OS Compile and Download in Simatic Manager V7.x

1. Overview: Purpose of OS Compile and Download in WinCC V7.x

The OS Compile and Download function in Siemens Simatic Manager (Classic, with Step 7 V5.x and WinCC V7.x) is the formal engineering procedure that consolidates PLC-side tag definitions, connection configuration, and graphics changes into the WinCC Operator Station (OS) project and pushes the result to the Runtime OS. It is fundamentally more than a file copy.

Three things happen during a proper OS compile and download:

1. Tag mapping — Symbolic PLC tags (configured in the S7 program) are read, normalized, and written into the WinCC tag database (TagManagement) along with their data type, address, and any scaling.
2. Connection synthesis — Logical S7 connections from the ES are instantiated as WinCC channel connections (typically SIMATIC S7 Protocol Suite channels TCP/IP, Named Connections, Industrial Ethernet, or MPI/Profibus).
3. Project load — The compiled OS is transferred to the target runtime computer using either delta loading (changes only) or a complete project reload.

The function exists to enforce a single source of truth for process tags: the PLC program. Operators on the HMI never have to re-enter the same tag list a second time, and any name change in the S7 symbol table propagates to the OS automatically after a recompile.

2. System Architecture: ES, OS, and PLC Roles

A WinCC V7.x OS Compile and Download operation involves three logical components:

The Simatic Manager must be configured as an integrated project to expose the OS Compile menu entry under the WinCC OS object. Without integration, the engineer must manually maintain the WinCC tag list, which is the workflow the OS compile and download was designed to replace.

3. Prerequisites Before Compiling and Downloading

Before initiating a download, verify the following on the ES and the target OS:

• Step 7 project consistency — Run Save and Compile on every S7 program block in the project tree. Uncompiled blocks are not visible to the WinCC tag generator.
• OS connection to the AS — In the WinCC project, open Tag Management > SIMATIC S7 Protocol Suite and confirm the connection name matches the logical connection name in NetPro. A mismatch is the single most common cause of empty tag lists after a download.
• Symbol accessibility — In Step 7, open Options > Symbol Table and ensure the relevant DB, I, Q, M, and T/C symbols have their Accessible via HMI attribute set, or set the global option Symbolic names accessible via OPC/HMI in the CPU properties (only on S7-400 CPUs with adequate firmware).
• OS server name resolution — The target OS computer name must be reachable from the ES via the network. Ping by NetBIOS name, not just by IP. WinCC uses the computer name when re-binding the loaded project to the runtime environment.
• WinCC project password — If project protection is active, the downloader must have the configured author password. A wrong password aborts the download with a generic Project Loading Failed dialog.
• Free disk on target OS — A delta load typically requires 100–500 MB free; a complete project load requires enough to hold both the previous and the new project simultaneously (the runtime does not delete the old project until the new one has unpacked).

4. Step-by-Step: OS Compile Procedure

1. Open the integrated project in SIMATIC Manager. The WinCC OS application must be visible in the project tree directly under the S7 program folder.
2. Right-click the OS object (for example, OS(1)) and choose OS > Compile and Download Objects. This opens the compile wizard.
3. Select the scope:
   • Entire OS — recompiles every picture, every script, the entire tag database, and the entire alarm configuration.
   • Changes only — recompiles only the objects marked as changed since the last successful download. Default selection; recommended for live systems.
4. Confirm the AS-OS connections in the next dialog. The wizard lists every logical S7 connection it intends to push to the WinCC tag management.
5. Click Compile. The status window shows the number of tags, the number of connections, the number of pictures, and the number of scripts compiled. A successful compile ends with Compilation finished without errors. Warnings (for example, Tag X has no connection assigned) are non-fatal but should be reviewed.
6. Do not run the runtime during a full compile when the option Stop Runtime on target OS is implied by the load type you choose in the next step.

5. Loading Modes: Change-Only Delta vs Complete Project Load

Once the OS is compiled, the engineer selects the load type. WinCC V7.x supports two load modes that are fundamentally different in their runtime impact:

A delta load is the operation the field report referred to when it confirmed that Runtime on Target-OS would not be stopped during Compiling on ES. That statement is accurate: the compile itself runs only on the ES, and when paired with a delta download, the runtime on the target OS continues throughout. The runtime only stops when a complete project load is chosen.

6. Runtime Behavior During OS Operations

The most common confusion in the field report is the difference between compile, download, and runtime stop. They are independent events:

During a complete project load, the WinCC project loader re-binds the loaded project to the target OS computer name before the runtime is restarted. This is the behavior described in the source: after the loading the computername in the project is changed to the name of the Target-OS, before the runtime is started again. The consequence is that if the project is loaded onto a different OS computer (for example, swapping a redundant server), the computer name in the project gets re-bound to the new hardware automatically.

7. Redundant OS Server Pair Operation

When the OS is configured as a redundant WinCC server pair, the behavior of the download changes again:

• The same compiled project is loaded sequentially to both OS servers.
• One server remains in runtime at all times; the redundant partner stops runtime, takes the load, restarts runtime, and re-synchronizes with its partner via the WinCC redundancy API.
• The ES initiates the load to the master server; the master pushes the change to the standby automatically. The engineer does not need to perform two separate downloads.
• Delta loads can be performed in this configuration without bringing the visualization down — the partner server keeps serving operators during the entire procedure.

For a single-OS setup (such as the WinCC 7.4 SP1 installation described in the source), the engineer connects the ES directly to that one OS, performs either a delta or complete download, and there is no redundancy synchronization step.

8. Version Control Integration with VersionDog

Production environments typically pair WinCC with an external version control tool. The field report uses VersionDog from AUVESY as the change-data-capture and backup system. The recommended closed-loop procedure for a single-OS plant is:

1. Restore the current production version of the S7 project and the WinCC project from VersionDog to the ES. This guarantees the ES is synchronized with the live system before any edit.
2. Edit the WinCC project (graphics, scripts, tag mappings) and, if required, the S7 program on the ES.
3. Compile the OS in the integrated project to merge any PLC tag changes into the WinCC tag database.
4. Download the compiled changes to the Runtime OS — delta for in-flight fixes, complete for structural changes.
5. Verify the change on the Runtime OS: open the affected pictures, watch the affected tags live, exercise the alarm line if alarms were changed, and check the archive configuration if archives were touched.
6. Archive the updated ES project back into VersionDog. A new version is created because the project has been changed.
7. VersionDog periodically compares the project stored in its archive to the project running on the target OS and the S7 program in the PLC, flagging any drift. If the ES is later rebuilt or another engineer takes over, they pull the same production version from VersionDog and the cycle repeats.

9. Verification After a Download

Once the download reports success, perform the following checks on the Runtime OS:

1. Runtime state — Confirm the WinCC Explorer shows Runtime active (green indicator). If the runtime is stopped after a complete load, restart it manually with WinCC Explorer > Runtime > Start.
2. Tag connection quality — Open WinCC Explorer > Tag Management on the runtime and inspect the connection status indicators. A red channel means the OS cannot reach the AS; verify the network path and the S7 connection name.
3. Picture compilation — Open the affected pictures in Runtime. Look for missing objects, broken dynamic dialogs, or empty placeholder text where a tag was not resolved. These symptoms indicate a tag that was not properly mapped during the OS compile.
4. Alarm system — Trigger a known alarm and confirm it appears in the alarm line with the correct class, priority, and acknowledgment behavior.
5. Archive continuity — Open the Tag Logging editor and confirm the active archive is still receiving values. A complete project load can break in-memory archive connections if the archive configuration was changed in the same load.
6. Author trace — On the ES, open the OS Project Editor > Change Log to confirm the load was recorded and to keep an audit trail for the version control archive.

10. Troubleshooting Matrix

11. Best-Practice Checklist for Production Plants

• Treat the ES project as a single source of truth — never edit the Runtime OS files directly.
• Use delta loads by default; reserve complete project loads for structural changes and object deletions.
• Maintain the ES in lockstep with the Runtime via a version control tool (VersionDog, Git, or Siemens SIMATIC Version Trail if licensed).
• Schedule complete project loads for planned downtime windows, even if delta loads are sufficient for the technical change.
• Keep the S7 symbol table and the WinCC tag naming convention aligned — name changes in the PLC symbols automatically rename the OS tags, and a stale name match can silently break a delta load.
• Document the load mode (delta vs complete) in the change ticket so the operator knows whether to expect a brief pause or a full runtime restart.
• For redundant OS pairs, always verify both servers are running the same project version after a load — drift between partners is the leading cause of split-brain visualization.