Upgrading Block Types and Module Drivers During SIMATIC PCS 7 Version Migrations

Upgrading block types and module drivers during a SIMATIC PCS 7 version migration requires choosing between 'Software update without utilization of new functions' (retaining existing block behavior while updating only driver blocks) and 'Software update with utilization of new functions' (upgrading all technological libraries). In both cases, copy the target version's Basis Library blocks into the Master Data Library, execute 'Update Block Types' in the CFC Editor to synchronize block interfaces without losing instance parameter values, delete obsolete '@CFC' system charts, and compile the entire program with 'Generate module drivers' enabled.

Executive Summary

Migrating a SIMATIC PCS 7 automation system across software versions (such as transitioning from V7.0 to V7.1, V8.x to V9.0, or V9.0 to V9.1) requires a disciplined engineering procedure to ensure controller program consistency and prevent unintended plant shutdowns. A central milestone in this migration workflow is updating block types—spanning hardware channel drivers (CH_AI, CH_DI), diagnostic blocks (MOD_D1, RACK_410), and technological process control blocks (MotL, PIDConL).

If block types are updated incorrectly or partially, the engineering system will raise compiler exceptions such as 'Module driver not found' or 'Block interface mismatch', or worse, force an unnecessary CPU STOP during project download. Siemens defines two distinct migration pathways: updating without new functions (minimizing operational risk) versus updating with new functions (leveraging advanced APL features). This guide provides the complete technical blueprint for both pathways, detailing block synchronization, system chart cleanup, and online download management.

Architecture and Fundamental Mechanics

The PCS 7 software architecture establishes strict boundaries between user application logic, library definitions, and runtime execution blocks:

Block Interface Signatures and Work Memory: In Step 7 / PCS 7, every Function Block (FB) possesses a unique interface signature. When a block type is modified in a library (e.g., adding an input parameter or modifying internal variables), its signature changes. If a chart is compiled against an updated library definition without properly synchronizing the offline block folder, the controller detects an interface mismatch between the compiled code and the active instance Data Blocks (DBs) in controller work memory.
The Two Migration Strategies:
- Software Update WITHOUT Utilization of New Functions: This approach is designed for rapid migrations or running plants where minimizing CPU downtime is paramount. Technological blocks (APL / Standard Library) are left untouched at their legacy version, ensuring identical algorithmic behavior and avoiding the need to regenerate OS faceplates. ONLY the PCS 7 Basis Library driver blocks are updated to ensure compatibility with newer hardware and operating systems.
- Software Update WITH Utilization of New Functions: All technological and driver libraries are upgraded to the latest version. This enables new APL features (e.g., enhanced interlock diagnostics, new alarm states), but mandates recompiling OS server data, updating block icons on all WinCC screens, and executing a full AS-OS compile.
Role of the Master Data Library (MDL): The Master Data Library is the single source of truth for all S7 programs within a PCS 7 multiproject. When updating blocks, the engineer copies new blocks from the system libraries into the MDL. Running 'Update Block Types' propagates the updated interfaces across all charts in the multiproject while preserving all parameterized setpoints, alarm limits, and signal interconnections.
Regeneration of System Charts (@CFC): System-generated charts prefixed with @ contain the dynamic diagnostic network. During major migrations, old diagnostic blocks in @CFC charts can conflict with the new compiler. Manually deleting obsolete @CFC charts before compilation ensures that the Driver Generator instantiates a clean, defect-free diagnostic architecture.

Step-by-Step Implementation Procedure

Follow these steps to execute a complete block type and module driver upgrade during a PCS 7 version migration:

Archive the Multiproject:
- In SIMATIC Manager, select 'File > Archive...'.
- Save a full compressed backup of the entire multiproject to external storage before making any modifications.
Populate the Master Data Library (MDL):
- Open the target PCS 7 libraries in SIMATIC Manager:
- For updates without new functions: Open 'PCS 7 Basis Library '.
- For updates with new functions: Open both 'PCS 7 Basis Library ' and 'PCS 7 Advanced Process Library '.
- Copy the required blocks (FBs and FCs) from the library Blocks folder.
- Open the project's Master Data Library Blocks folder and paste the copied blocks, confirming overwrite.
Execute 'Update Block Types':
- In SIMATIC Manager, select the Master Data Library Blocks folder.
- Select 'Options > Charts > Update Block Types...'.
- In the selection dialog, choose the target S7 programs / AS stations to be updated.
- Click 'Next'. The wizard displays a comparison list showing block names, old versions, and new versions.
- Review the list and click 'Finish'. The engineering system parses all charts, updates block headers, and updates instance data structures while retaining all custom parameter values.
Remove Obsolete System Diagnostic Charts:
- In each AS project's Component View, expand the Charts folder.
- Select and delete all charts prefixed with @CFC (e.g., @CFC_AS, @CFC_RXT).
- (Do NOT delete user-created charts!).
Save and Compile Hardware Configurations:
- Open HW Config for each AS station.
- Select 'Station > Save and Compile'. Ensure zero errors.
Compile Program with Driver Generation:
- In SIMATIC Manager, select the Charts folder.
- Select 'PLC > Compile > Charts as Program...'.
- In the compile dialog, select 'Entire program' and verify that 'Generate module drivers' is checked.
- Click 'OK'. Allow the compiler to synthesize new @CFC charts and generate updated machine code.
Download to Controller:
- If the controller is an S7-400H or CPU 410-5H and the migration path supports online download (CiR / redundant update), download program changes in RUN mode.
- If block interface expansions altered instance DB structures significantly, execute the download during a planned plant maintenance window in STOP mode.

Verification

Verify that the CFC compilation log reports zero errors.
Open several technological CFC charts: confirm that block versions in the header display the new library revision and that all signal lines remain connected.
Open the newly created @CFC charts: confirm that all hardware racks and I/O modules have corresponding driver blocks instantiated.
Switch CFC to Test Mode (Online): verify that channel driver blocks read live field signals (QualityCode = 16#80) without errors.
In WinCC OS Runtime (if new functions were utilized), verify that faceplates open correctly and reflect updated APL features.

Limitations and Operational Precautions

Executing 'Software update with utilization of new functions' requires updating OS block icons via the OS Project Editor and running a full AS-OS compile, which can disrupt active operator monitoring if performed during live production. Changing block interfaces in non-redundant automation systems mandates a CPU STOP to download altered instance data blocks. Verify all software media, licensing entitlements, and firmware compatibility with an authorized Siemens distributor or the Siemens Industry Mall.

Engineer FAQ

What is the primary difference between migrating with vs without new functions?

'Without new functions' updates only Basis Library driver blocks to run on newer PCS 7 versions without touching user logic. 'With new functions' updates all technological blocks, requiring OS faceplate and icon regeneration.

Will running 'Update Block Types' reset my tuning parameters in CFC?

No. The 'Update Block Types' tool updates block interface definitions while preserving all configured parameters, setpoints, and interconnections.

Why must I compile the entire program instead of changes only?

When module drivers are updated across major versions, the Driver Generator must re-evaluate all hardware modules and diagnostic links across the entire project.

Can block types be updated while the CPU is in RUN?

Yes, if the update does not modify the structure or length of instance DBs. However, major version jumps that alter block internal memories will require an AS STOP unless using redundant H-system upgrade procedures.

What happens if I forget to delete the old @CFC charts before compiling?

The compiler may retain obsolete driver block instances, leading to duplicate block calls, address collisions, or 'Module driver not found' compiler errors.