Resolving PCS 7 V7.0 SP2 to STEP 7 V5.6 Compatibility Constraints

This reference covers the engineering situation in which an installed SIMATIC PCS 7 V7.0 SP2 station (with the embedded STEP 7 V5.4 toolchain, CFC V7.x, SFC V7.x and WinCC V7.0) must deliver the same control function on a workstation that has been rebuilt with STEP 7 V5.6, CFC V8.2 and WinCC V7.4 SP1. The technical reality is that the requested target combination is not a supported upgrade path. The PCS 7 V7.0 SP2 release line is permanently tied to STEP 7 V5.4; a direct jump to STEP 7 V5.6 / CFC V8.2 / WinCC V7.4 is blocked by the PCS 7 build matrix, the PCS 7 process library (APL/APLstyle) dependency, and the operator station architecture. This document identifies the root cause, lists the available migration routes, and provides the engineering workarounds required to make a workstation functionally equivalent.

1. Problem Definition

The customer request reduces to four statements:

1. Current OS/ES is installed with PCS 7 V7.0 SP2 (STEP 7 V5.4, CFC V7.x, WinCC V7.0).
2. Target installation must be STEP 7 V5.6, CFC V8.2, WinCC V7.4 SP1.
3. The user proposes to archive the PLC program (hardware, software, CFC) and the WinCC project from the existing PCS 7 system, then restore it on a fresh workstation that has only classic STEP 7 / CFC / WinCC (no PCS 7).
4. The user asks whether the existing SCADA/operator project can be re-opened unmodified in the new toolset.

Each of these statements contains a compatibility fault:

• PCS 7 V7.0 SP2 cannot host STEP 7 V5.6. The PCS 7 master installation enforces a specific STEP 7 service pack, and the build chain for V7.0 SP2 terminates at STEP 7 V5.4 SP3 HF12.
• WinCC V7.4 SP1 cannot natively open a PCS 7 OS project built on WinCC V7.0. The OS project database schema, the alarm/logging tag dictionary, the SFC visualization plug-in, and the APL block icons all changed between V7.0 and V7.4.
• STEP 7 V5.6 with CFC V8.2 is a standard SIMATIC toolchain, not a PCS 7 toolchain. The PCS 7 program uses the Advanced Process Library (APL) (and on some branches the APLstyle). APL is not part of standard STEP 7; opening a PCS 7 archive on a non-PCS 7 workstation produces unresolved block references (F-type and FB-type placeholders) for every APL block, including CTRL_PID, MOT_SPEED, MOT_REV, VALVE_ANA, VALVE_DIG, DOSE, OP_A, OP_D, OP_A_LIM, CTRL_S, ILC, ILCS, ILC_S, SIG_2, SIG_4, CH_AI, CH_DI, CH_AO, CH_DO, and the full set of driver/faceplate blocks.
• The "SCADA" term used in the request is ambiguous. PCS 7 does not have a SCADA station; it has an OS (Operator Station) that contains the WinCC runtime, the SFC visualization, the OS project editor, and the PCS 7 message configuration. A PCS 7 OS project is not portable into a plain WinCC V7.4 project.

2. Root Cause Analysis

The error is not a license error, a version mismatch warning, or a project corruption. It is a component binding failure caused by the PCS 7 release scheme. PCS 7 is delivered as a single coherent product set. Within that set, every component (STEP 7, SCL, CFC, SFC, WinCC, the PCS 7 Library, the PCS 7 OS, the Maintenance Station, the Web Option, the Information Server, the Batch option, the Route Control option, the Safety Matrix option) is locked to a specific release and service pack. Mixing components across PCS 7 release lines is not supported, and the official compatibility check is performed against the SIMATIC Compatibility Tool.

For the version pair in the case study, the tool returns the following binding:

Two structural factors amplify the version mismatch:

1. OS schema lock. WinCC V7.0 OS projects and WinCC V7.4 SP1 OS projects use different database layouts, different picture hierarchy tree schemas, and different alarm logging layouts. A V7.0 OS database cannot be opened in a V7.4 SP1 OS without an in-place OS upgrade that is only available when the OS server is bound to a PCS 7 V8.x or PCS 7 V9.0 engineering station.
2. APL icon and faceplate lock. The OS faceplate library is regenerated against the APL version installed on the engineering station. If the engineering station has standard STEP 7 + CFC V8.2, the faceplate scripts (C- and VB-scripted controls inside the picture) reference APL V8.2 block interfaces that do not match the block instances compiled from a PCS 7 V7.0 SP2 archive.

3. Confirming Compatibility with the SIMATIC Compatibility Tool

Before any action is taken on the existing project, query the SIMATIC Compatibility Tool for the following product pairs and save the result as a PDF attached to the engineering file:

1. Source product: PCS 7 V7.0 SP2 → target product: STEP 7 V5.6
2. Source product: PCS 7 V7.0 SP2 → target product: WinCC V7.4 SP1
3. Source product: STEP 7 V5.4 SP3 → target product: STEP 7 V5.6 (this is the "in-toolchain" step)
4. Source product: WinCC V7.0 → target product: WinCC V7.4 SP1
5. Source product: STEP 7 V5.4 SP5 → target product: TIA Portal V20 (if TIA migration is on the table)

4. PCS 7 Architecture vs. Standard STEP 7 / WinCC

It is essential to understand the boundary between a PCS 7 workstation and a classic SIMATIC workstation, because the user's mental model — "I will move the program to a non-PCS 7 workstation" — assumes the boundary is at the file-system level. It is not. The boundary is at the engineering contract level.

Reading across the table: any project that uses the PCS 7 process tag types, the OS faceplate library, the PCS 7 message classes, or the SFC visualization cannot be operated on a non-PCS 7 engineering station without a full re-engineering effort that effectively rebuilds every OS picture and every block instance to a non-PCS 7 pattern.

5. Path A — Upgrade the PCS 7 Release Line to V9.0 (Recommended)

The first path is the one Siemens documents and supports: keep the workstation as a PCS 7 ES, and move it up the PCS 7 release line until the requested component versions are reached. The PCS 7 release that contains STEP 7 V5.6 and WinCC V7.4 SP1 is PCS 7 V9.0 (released 2018, SIMATIC PCS 7 V9.0 DVD set, ordering data: 6ES7 658-2XX..-....). The component binding for PCS 7 V9.0 is:

Procedure:

1. Verify the OS server and OS client hardware against the PCS 7 V9.0 installation manual. Newer PCS 7 releases drop support for older Windows Server editions. For PCS 7 V9.0 the supported Windows Server editions are Server 2012 R2 (64-bit) and Server 2016 (64-bit) for OS servers; Windows 7 SP1 / 10 (64-bit) for ES / OS clients.
2. Apply the in-line upgrade path PCS 7 V7.0 SP2 → V7.1 SP3 → V8.0 SP1 → V8.1 → V8.2 → V9.0. The intermediate SP updates are not optional; they install the migration scripts that re-write the OS database schema and the APL block call structure at each step. Skipping steps corrupts the OS project.
3. For each step, follow the upgrade manual. The PCS 7 V8.0 → V9.0 manual is published as entry 109746554 on the Siemens Industry Online Support. The same pattern exists for V7.x → V8.0 and V8.0 SP1 → V8.1.
4. Back up the complete project (S7 program + OS project + all archives) before each step. Verify that the backup can be restored in a clean directory before proceeding.
5. Run a project consistency check (CFC: Charts → Check Consistency; SFC: Options → Check Consistency; OS: OS Project Editor → Compile OS) after each upgrade step.
6. Download the upgraded project to the AS and verify against the I/O list before re-energizing the controlled process.

Pros: supported, validated, retains PCS 7 features (faceplates, SFC visualization, Maintenance Station, optional packages). Cons: a multi-step, multi-month rollout; hardware refresh for the OS servers is frequently required because the older x86 platforms are no longer compatible with newer Windows Server releases.

6. Path B — TIA Portal Migration of the STEP 7 Program

Path B assumes the user is willing to leave the PCS 7 OS world and re-host the control program on a TIA Portal engineering station, with a TIA Portal-based HMI (WinCC Professional / Unified) for the operator visualization. This is feasible only if the customer accepts the loss of PCS 7 faceplates and PCS 7 OS architecture, and is willing to commission a new HMI project.

The TIA Portal migration rules are documented in the TIA Portal help, in the section Migrating projects to a TIA Portal project → Migrating STEP 7 projects (S7-300/S7-400), available at TIA Portal V20 migration documentation. Key rules for a PCS 7 V7.0 SP2 source:

• Source minimum: The STEP 7 program to be migrated must be a STEP 7 V5.4 SP5 (or higher, up to V5.6) program. PCS 7 V7.0 SP2 contains STEP 7 V5.4 SP3 — which is below V5.4 SP5. The migration tool will refuse the source, or will import only the hardware and not the program blocks. Therefore the source must first be opened in a STEP 7 V5.4 SP5 (or V5.4 SP3 HF12) station to bring it up to a migratable level.
• CFC / SFC / APL blocks: TIA Portal does not import CFC, SFC, or APL. Every CFC chart, every SFC chart, and every APL block instance has to be either (a) manually re-implemented in TIA Portal as a TIA CFC / TIA SFC / TIA process tag type, or (b) retained as a "non-migrated" plug-in that runs on a parallel classic STEP 7 V5.6 station. Option (b) is impractical for an OS-coupled PCS 7 program.
• Hardware: S7-300, S7-400, ET 200S, ET 200M, ET 200Pro, ET 200SP HA, ET 200iSP, and most analog/digital I/O modules are supported for migration. Some older 6ES7 modules (e.g., FM 350-1 / -2 counter modules, FM 351 / FM 352 cam controllers, CP 441 point-to-point, IM 308C) are migrated as unsupported and must be re-engineered. Verify the I/O list against the TIA Portal hardware catalog before quoting the migration effort.
• S7-400H and S7-400F/FH: Migration of PCS 7 AS 410 / AS 400F / 400H systems is supported in TIA Portal V16 and later, but only with a F-capable CPU and the F-runtime license on the target.
• OS project: The WinCC V7.0 OS project is not migrated. The TIA Portal HMI must be built from scratch as a WinCC Professional / WinCC Unified project.

Procedure for Path B:

1. On a staging engineering station, install the latest STEP 7 V5.6 + CFC V8.2 + SCL V5.6 + PLCSIM V5.4 SP8 (the highest classic STEP 7 line). Open the PCS 7 V7.0 SP2 archive. The CFC/SFC charts will load but the OS project will be flagged as invalid (because the OS project is bound to the PCS 7 OS server, not to STEP 7).
2. Export the S7 program only: PLC → Manage Station → Archive. Do not include the OS project in this archive.
3. Install the TIA Portal (V17 or later; V20 is the current line for new deployments). Run the Migrate project wizard. Select the S7 archive from step 2 as the source.
4. For every block type that TIA Portal reports as cannot be migrated, decide on a case-by-case basis. The typical cases for a PCS 7 V7.0 SP2 source are: APL FBs (CTRL_PID, MOT_SPEED, etc.) — re-implement as a TIA process tag type; custom FBs — port manually.
5. After the migration completes, recompile the program. Resolve any compile errors (typically block interface changes — TIA Portal strict type checking rejects implicit conversions that classic STEP 7 accepted).
6. Download the migrated program to a test rack (S7-PLCSIM or a hardware test bench). Validate bit-for-bit against the original using the PCS 7 FAT documentation.
7. Build a new TIA Portal HMI project for the operator visualization. Use TIA Portal Process Tag Types (PTF) to mirror the faceplate functions. The faceplate look-and-feel will differ from the original PCS 7 faceplates unless the customer funds a custom Unified Comfort Panel design.

Pros: long-term path to the current SIMATIC toolchain; licenses and HMI hardware are easier to source for TIA Portal. Cons: a full re-engineering project with PCS 7 fidelity loss; faceplate and OS faceplate logic must be rebuilt; FAT (Factory Acceptance Test) and SAT (Site Acceptance Test) effort is high.

7. Path C — Build a Parallel Classic STEP 7 V5.6 + WinCC V7.4 SP1 Workstation with Manual Re-Engineering

The third path addresses the user's literal request: bring a new workstation, install only classic STEP 7 V5.6 + CFC V8.2 + WinCC V7.4 SP1, and re-use the existing PCS 7 archives. The conclusion is the same as in the field report: this path requires re-engineering. Specifically:

1. Open the S7 archive on the classic STEP 7 V5.6 station. The S7 program (HW Config, netpro, the S7 blocks not derived from APL) loads. The CFC charts load only if the workstation has CFC V8.2 installed and licensed. The APL block instances load but the block types are missing, producing compile errors of the form FB / FC <number> not found.
2. Source the missing block types. There are three options:
   • Buy a PCS 7 V9.0 ES license and use it on the new workstation, which restores the full APL. This effectively converts Path C into Path A.
   • Open a parallel license of PCS 7 V7.0 SP2 and use it to export the APL block types as a stand-alone library. This requires confirming the license terms; APL is licensed for use inside a PCS 7 ES and is not redistributable to a non-PCS 7 station.
   • Manually port the FBD/LAD/SCL of every missing block from the PCS 7 source. For a typical mid-sized PCS 7 program (50-200 APL instances), this is several engineer-weeks of effort.
3. The OS project cannot be carried over. The PCS 7 OS project is bound to the OS server engine of PCS 7. Open a new WinCC V7.4 SP1 project on the new station and rebuild the operator pictures manually.
4. The SFC visualization has to be re-implemented as WinCC SFC visualization (which is a WinCC option, not a PCS 7 option) and re-linked to the SFC instances on the AS.

8. Archive, Restore, and Project Transfer Procedure

Whichever path is selected, the archive / restore cycle is the same. Use only Siemens standard archive formats.

8.1 Archiving the Source PCS 7 V7.0 SP2 Project

1. Open SIMATIC Manager on the source ES. From File → Archive, select User archive (compressed) and choose the S7 program of every AS plus the OS project. The S7 program and the OS project are separate archive objects and must be archived separately.
2. Save the archive to a network share with a name that records the PCS 7 version, the S7 program name, and the date: e.g., PCS7V70SP2_AS01_PIDX_20251018.zip.
3. Generate an MD5 or SHA-256 hash of the archive and store it in the project quality file. This step protects against silent corruption during transfer.
4. Document the source-side S7 program signature, the OS project signature, and the operator picture count. After restore, the same numbers must match.

8.2 Restoring on the Target Workstation

1. Install the target toolset first (Path A: PCS 7 V9.0; Path B: TIA Portal V17 or later; Path C: classic STEP 7 V5.6 + CFC V8.2 + WinCC V7.4 SP1). Confirm the installations by opening the SIMATIC Manager or TIA Portal once.
2. On the target workstation, in SIMATIC Manager (or TIA Portal for Path B), open File → Retrieve and select the S7 archive. SIMATIC Manager prompts for the destination project path; choose a clean directory (no prior .S7P or .S7L files).
3. For Path A: also retrieve the OS archive and run OS Project Editor → Compile OS. The OS Compile rewrites the OS database schema against the target PCS 7 release.
4. For Path B: after the S7 migration completes, open the TIA Portal project and run Compile → Software (rebuild all). Resolve any type errors before attempting the download.
5. For Path C: after the S7 archive is restored, install the missing block types (per section 7 step 2) and recompile. Resolve the compile errors that reference the missing FBs / FCs / DBs.
6. Re-hash the restored project directory and store the hash in the quality file.

9. WinCC Configuration Migration Specifics

Because the user explicitly asks about WinCC, a closer look at the WinCC side is required.

9.1 OS Project (PCS 7) vs. WinCC Project (Classic)

A PCS 7 OS project contains:

• WinCC pictures (.pdl) with PCS 7-specific controls (APL faceplates, status displays, SFC visualization plug-in, group displays, area overview)
• WinCC tag database with PCS 7 message classes and PCS 7 state logic
• Alarm logging and tag logging databases in the WinCC V7.0 schema
• OS server / OS client project files in the PCS 7 layout
• OS project editor configuration (area, unit, picture hierarchy)

A classic WinCC V7.4 SP1 project contains none of these PCS 7-specific objects. The OS project editor, the APL faceplate controls, the PCS 7 message configuration, and the SFC visualization plug-in must all be re-built on the new station.

9.2 WinCC V7.0 → V7.4 SP1 In-Place Upgrade

WinCC V7.x supports a direct in-place upgrade from V7.0 to V7.4 SP1 only when the workstation has a licensed PCS 7 V8.0 or V9.0 ES. The WinCC installer on a plain classic SIMATIC station refuses to perform a cross-version OS upgrade. To perform a WinCC V7.0 → V7.4 SP1 migration of a PCS 7 OS project, follow the PCS 7 upgrade manual exactly — do not attempt the WinCC V7.0 → V7.4 SP1 standalone upgrade.

Within the PCS 7 upgrade path, the OS database schema, the picture layout, the alarm logging tables, and the SFC visualization are all upgraded by the OS Project Editor → Compile OS step at the end of each PCS 7 upgrade. Do not skip this step and do not re-use an OS database that has been opened by an older version of WinCC — the database is version-tagged and re-opens are blocked.

10. CFC and SFC Migration Specifics

CFC V8.2 in the classic STEP 7 V5.6 toolchain is functionally complete for a non-PCS 7 project. The classic CFC V8.2 supports:

• Run-time groups (OB 1, OB 35, OB 100, OB 102, custom OBs)
• Block icon generation for WinCC (only for the standard FBs shipped with CFC V8.2; APL faceplate generation requires the PCS 7 APL library)
• Type-instance concept: type FBs in the chart, instance DBs on the AS
• Sequential function charts (SFC) for state-based control

The migration of a PCS 7 CFC V7.x program to CFC V8.2 is normally an in-place upgrade, performed by simply opening the chart on the CFC V8.2 station. CFC V8.2 reads the chart container, migrates the run-time groups, and re-compiles against the V8.2 block library. The exception is the APL block instances: if the target station does not have the APL, the instances are marked type missing. In the classic CFC V8.2 without APL, the standard FBs (CTRL_PID is the classic FBs version, not the APL version) can be used, but their faceplate icons are minimal compared to the APL faceplate.

SFC V8.2 in the classic toolchain supports the same step / transition / branch / parallel construct as the PCS 7 SFC V7.x. The OS-side SFC visualization, however, is an OS option that is installed on the OS server (WinCC SFC option). For PCS 7, the SFC visualization is integrated into the OS picture and uses the PCS 7 message configuration. For classic WinCC V7.4 SP1, the SFC visualization is a WinCC option that must be licensed separately; without the license the SFC instances are visible in the AS but not in the OS.

11. Verification and Validation

After the migration, perform the following checks before returning the system to the customer.

11.1 Static Checks

1. CFC consistency: In CFC V8.2, run Charts → Check Consistency on every chart. Resolve every reported error. The most common residual is type version mismatch between an instance and the master type FB; resolve by re-running Type → Update Instances.
2. SFC consistency: Run Options → Check Consistency on every SFC chart. Resolve every reported error.
3. STEP 7 / S7 program consistency: Run PLC → Check Block Consistency in SIMATIC Manager. Resolve every reported error.
4. OS compile: For Path A, run OS Project Editor → Compile OS. For Path C, run WinCC Explorer → OS Project Editor equivalent. The OS compile must complete without errors and without warnings about orphaned tags.
5. HW Config compile: Recompile the hardware configuration and verify that the GSD files for the distributed I/O are present and current.

11.2 Dynamic Checks (Test Bench)

1. Download the program to an S7-PLCSIM V5.4 SP8 instance or to a hardware test bench with the same CPU type (e.g., 6ES7 416-3XXXXX for an AS 410).
2. Exercise every input/output pair against the I/O list. For analog loops, ramp-test every CTRL_PID instance against the original FAT (Factory Acceptance Test) results; deviation must be < 0.5% of span.
3. Force every motor block (MOT_SPEED, MOT_REV) through every state (start, stop, fault, reset, interlock release). Compare the state transitions against the FAT sheet.
4. For SFC instances, run through every transition condition and verify that the active step, the holding time, and the transition logic match the original.
5. Verify every operator picture: open the picture, click every button, verify that the underlying tag changes, verify that the alarm is generated when the simulation forces a fault.
6. Re-archive the verified project with a new archive name. The new archive is the "as-built" record.

12. Troubleshooting Matrix

13. Decision Summary

FAQ