Resolving PCS 7 OS Compile Errors After Project Integration

1. Problem Overview: OS Compile Failure After PCS 7 Project Integration

Adding a new AS (Automation Station) and a new branch of the Plant Hierarchy (PH) into a live PCS 7 multiproject is one of the highest-risk engineering activities in a SIMATIC environment. The standard procedure assumes the integrator is working inside the original multiproject shell on the master ES, with consistent STEP 7 / PCS 7 versions, a synchronized master data library, and a controlled OS project editor pass. When the new engineering is performed in a separate, single-user project on a satellite ES, and then merged into the running plant, the OS compile step almost always produces non-obvious failures: alarms appear that should not exist, tag addresses look "shifted" relative to the S7 symbols, and CFC interlocks no longer toggle from the OS even though the chart logic is correct. The root cause is rarely a WinCC bug; it is a desynchronization between the AS program compilation, the AS-OS connection data, the WinCC tag database, and the Plant Hierarchy mapping used by the OS project editor.

This article documents the field-proven procedure for diagnosing and recovering from a failed OS compile after such an integration, with concrete menu paths, parameter values, log file locations, and verification checks used on PCS 7 V8.x and V9.x systems. Where the official Siemens documentation is the controlling reference, the relevant manual entry is hyperlinked so the integrator can verify against the source of truth.

2. Symptoms Reported in the Field

The following symptoms, observed together, are the signature of a project-integration desync rather than a controller fault:

3. Root Cause Analysis

Three structural causes account for the majority of OS compile failures after integration. They are listed in the order they should be investigated.

3.1 Cause A: The New Project Is a Single-User Project, Not a Subproject of a Multiproject

PCS 7 is designed around the multiproject object in SIMATIC Manager. Each AS, each ES, and each OS pair lives in its own subproject. Plant Hierarchy, master data library, and shared symbols are stored once at the multiproject level. When the satellite engineer builds the new PLC and Plant Hierarchy in a standalone S7 project on a laptop, the resulting database, instance DBs, and PH tree cannot be transferred into the live multiproject by simple file copy. The WinCC tag database, the S7 program compilation, and the OS project editor all read from the multiproject root, not from a copied subproject. The OS compile therefore either silently drops the new tags or binds them to wrong DB numbers.

Reference: see the SIMATIC PCS 7 Engineering System (V9.0) manual, section "Working with the multiproject".

3.2 Cause B: AS-OS Connection Data Was Not Regenerated

The AS-OS connection data is the mapping table that the OS project editor uses to know which STEP 7 tag (symbol, DB number, byte offset, bit) corresponds to which WinCC tag and which faceplate block instance. Every time the AS program is recompiled, instance DBs may be renumbered. The OS project editor must be re-run; the WinCC tag database alone is not sufficient. If the integrator only does a tag export/import (as the original poster reported trying), the WinCC tags are updated but the faceplate-to-instance assignment and the PH-to-chart mapping are not, which is exactly why the operator input "would not change" the interlock: the faceplate was still pointing at the previous instance DB.

3.3 Cause C: Plant Hierarchy Was Rebuilt Rather Than Merged

The Plant Hierarchy in PCS 7 is the tree that WinCC uses for area-oriented authorization, picture selection, and alarm filtering. If the new branch was constructed in a different PH on the satellite project, the OS pictures compiled in the live project will not contain the new units, and any reference from a CFC chart to a PH path will resolve to nothing. The symptom is "shifted" tags: the chart is still bound, but it is bound to the wrong PH node, so the runtime picture lookup fails.

4. Pre-Integration Inventory

Before opening either project, capture the following on paper or in a controlled change log. This is the single most important preventive measure.

1. PCS 7 version and HF level of the live system, e.g. "PCS 7 V9.0 SP2 HF3". Confirm on the master ES via SIMATIC Manager > Help > About and on the OS servers via WinCC Explorer > Help > About.
2. STEP 7 version of every subproject in the multiproject. Mixing V5.5 and V5.6 subprojects is supported but documented; mixing with TIA Portal subprojects is not supported in classic PCS 7.
3. The complete PH tree as a screenshot, including unit, function, and sub-function nodes. Save as PNG.
4. Export of the S7 program source: in SIMATIC Manager, File > Export to Text Format for every chart folder that will be touched.
5. Export of the WinCC tag database: WinCC Explorer > Tag Management > right-click on the S7 driver > Export, and the same for the OS project editor output under OS Project Editor > Export Compilation Log.
6. List of all custom master data library elements in use, including APL block instances that were copied and modified. The master data library lives in the multiproject root, so it must be present on the satellite ES at the same revision.
7. A backup of every S7 project file (.s7p, .s7l, .s7r) and every WinCC project file (.mcp). The default path is C:\Program Files\Siemens\Automation\PCS7\s7proj for S7 and C:\Program Files\Siemens\Automation\PCS7\WinCC\ProjectName for WinCC.

5. Correct Multiproject Integration Procedure

The following sequence is the controlled path. Any deviation must be justified in writing in the change log.

5.1 Set Up the Satellite ES Against the Master Multiproject

Do not build a standalone S7 project. Instead, on the satellite ES, open the live multiproject over the network share or copy the entire multiproject directory to the laptop. The path must be writable. All subprojects must open without "incompatible version" warnings. If a warning appears, install the matching PCS 7 version. See the PCS 7 installation manual for the supported coexistence matrix.

5.2 Insert the New AS into the Multiproject

In SIMATIC Manager, right-click the multiproject object, choose Insert New Object > SIMATIC S7 Station. The new AS appears as a subproject. Do not copy the new AS into an existing subproject; it must be a peer of the existing AS stations at the multiproject level.

5.3 Extend the Plant Hierarchy

Open the Plant Hierarchy view at the multiproject level. Add the new unit, function, and sub-function nodes in the correct position. Do not rebuild or rename existing nodes; doing so will invalidate the OS pictures and the alarm routing for the live plant.

5.4 Build the CFC and SFC Charts Under the New PH

Create the new charts in the new AS, drag them from the catalog, and place them in the appropriate PH nodes. Use the master data library copies, not local copies, for any APL block. Compile the S7 program for the new AS only: right-click the AS > Compile and Download Objects.

6. Step-by-Step Recovery Procedure for an Already-Broken Integration

If integration has already been attempted and the OS compile has produced the symptoms in section 2, perform the following recovery in this exact order.

1. Stop both OS servers and put the plant on manual / maintenance mode. This is a safety action, not a software action. Coordinate with operations.
2. Restore the multiproject from the backup taken in section 4, item 7. Do not try to "fix forward"; the desync is structural.
3. Verify that the restored state matches the live plant state by doing a CFC online compare on every AS. Right-click the AS > CFC > Chart Comparison. All charts must show status "Identical".
4. Re-open the multiproject on the master ES (not the satellite). Confirm PCS 7 version is identical to the backup.
5. Re-insert the new AS and the new PH branch following section 5.
6. Compile the S7 program of the new AS only. SIMATIC Manager > Options > Compile Multiple OS / Compile OS is not the right tool at this stage; that is the WinCC step, not the STEP 7 step. The S7 compile is AS > right-click > Compile and Download Objects.
7. Open the WinCC project that owns the new AS pair in WinCC Explorer.
8. Run the OS Project Editor. The menu is WinCC Explorer > OS Project Editor. Use the settings in section 7.
9. Recompile the OS. WinCC Explorer > right-click the OS > Compile / Recompile OS. Capture the full log to a file: right-click the OS > Compile OS With Log File. The log is written to <WinCC project>\<OS name>\CompileLog.txt by default.
10. Cross-check the tag database for the new AS: Tag Management > S7 PROTOCOL SUITE > TCP/IP > the new connection > Tags. The DB numbers must match the S7 symbol table. Section 8 details the verification.
11. Activate the OS server in test mode, not live. Verify faceplate operation on a redundant pair before taking it to production.

7. OS Project Editor Settings

The OS Project Editor is the single most important step. The values below are the field-proven settings for a cement plant multiproject with mixed AS-410 and AS-400 stations.

The full parameter list is documented in the PCS 7 OS Configuration manual.

8. CFC and SFC Re-Integration

CFC charts compiled before the integration will reference instance DBs whose numbers may change if the AS was recompiled. The chart itself is regenerated on compile, but the OS faceplate still references the old instance DB unless the OS project editor is re-run.

To verify: open a faceplate in runtime, click the block icon to open the standard loop display, and check the instance DB number shown in the title bar. Cross-reference against the S7 program: right-click the block instance in the CFC > Block Properties > Instance DB. The two numbers must be identical. If not, the OS project editor was not run for that chart's AS scope.

For SFC (Sequential Function Chart) instances, the same logic applies but with one additional constraint: the SFC instance DB contains the step and transition state that the SFC visualization reads. If the SFC was recompiled in the new AS, the SFC visualization will show the previous state until the OS project editor is rerun and the OS is reactivated. The verification is identical: open SFC visualization > check instance DB > compare to SFC chart properties.

9. WinCC Tag Database Reconciliation

When a tag export/import is performed manually, the integrator typically opens Tag Management > S7 PROTOCOL SUITE > the connection > Properties and confirms the connection name, IP address, and rack/slot. The connection itself is rarely wrong. The tag addresses inside the connection are.

Use the following structured comparison to find "shifted" tags:

1. Export the S7 symbol table to CSV: SIMATIC Manager > Options > Symbol Table > Export to CSV.
2. Export the WinCC tag list to CSV: Tag Management > right-click the connection > Export Tag List.
3. Diff the two CSVs on the Address column. A constant offset across all tags of one AS indicates that the instance DBs were renumbered during the AS recompile and the OS project editor was not re-run.
4. For each tag with a non-matching address, do not edit the tag manually. Re-run the OS project editor. The tag address will be corrected in place.

10. Compile and Runtime Log Files

The following log files must be captured for every integration attempt and archived in the project documentation directory.

11. Verification Checklist Before Returning the Plant to Operations

1. On the master ES, run CFC > Chart Comparison on every AS in the multiproject. Result: "Identical" for every chart. Any "Different" status must be reconciled before OS reactivation.
2. On the test OS client, open the plant picture for the new unit. Verify that the unit symbol is present and that the area color reflects current authorization.
3. From the test OS client, force a tag value that is bound to a CFC block instance in the new AS. Verify in CFC online that the value arrives. If it does not, the OS project editor was not run for that AS scope.
4. Trigger an alarm in the new AS from CFC online. Verify that the alarm appears in the test OS alarm log, with the correct PH path and the correct message text. If the message text is wrong, the message configuration was not regenerated.
5. Switch from test OS to production OS, with the standby server in standby. Trigger a server failover and verify that no tags drop and no faceplates lose state.
6. Sign off the integration in the change management system. Capture the log files from section 10 and attach them to the change record.

12. Preventive Practices for Future Integrations

The original poster's situation is recoverable, but the cost is high. The following practices prevent the same class of failure on the next integration:

• Engineer the new AS and PH inside the live multiproject on a test ES, not a standalone project on a laptop.
• Hold the satellite ES to the same PCS 7 version and HF level as the master ES. Document the version in the change record.
• Run the OS project editor after every S7 program compile of any AS, not only the new one, while the integration is in progress.
• Maintain a single source of truth for the master data library. The satellite ES must read from the same library revision, or block type changes will not propagate.
• Run the verification checklist in section 11 on a test OS before any production OS reactivation.

FAQ