Replacing CMTs in Siemens PCS 7 V9.0 SP2: Safe Migration Guide

Overview of CMT, EMT, CM, and EM in PCS 7

Siemens PCS 7 separates reusable control logic from instantiated automation objects through a four-tier type/instance hierarchy. The CMT (Control Module Type) and EMT (Equipment Module Type) are the type-level templates stored in the Master Data Library (MDL). The CM (Control Module) and EM (Equipment Module) are the instantiated runtime objects located in the Plant Hierarchy (PH). A single CMT can be instantiated hundreds of times across an SFC, an S88 batch hierarchy, or a process cell, and each instance is referenced by a unique tag name (for example, TIC_1101). Each instance carries its own parameter values, block I/O connections, operator faceplate references, and WinCC Runtime tag allocations.

Replacing a CMT in a live engineering project without breaking the instance bindings, the operator faceplate connections, or the historian and trend allocations is one of the most delicate refactoring operations in PCS 7 engineering. This article documents three field-proven procedures for replacing a CMT (for example, ABC) with a successor CMT (for example, BBB) in PCS 7 V9.0 SP2 while preserving the existing CM instances, their tag names, and their assignment to the EM technological interface.

Key Terminology and Reference Architecture

The migration challenge reduces to: keep the instances (CM, EM), keep the tag names, and only swap the type behind them. PCS 7 V9.0 SP2 added a dedicated engineering feature for exactly this case.

What Changed in PCS 7 V9.0 SP2

The "PCS 7 Engineering System Collection V9.0 SP2" update (and the corresponding DVD image distributed by Siemens Customer Support) ships CFC V9.0 SP3, even though the public download channel labels the same package as "SP2 Upd2 for CFC". The relevant functional delta for CMT migration is the introduction of the Assignment CM tab inside the Technological List Editor, and the ability to change the type assignment of a control module individually.

Per the official Siemens release notes, this is the key new behavior:

"The type assignment of a control module (CM) can be changed individually. This allows, for example, for a single control module (CM) to be easily switched to another version."

That sentence is the entire foundation of the third migration method described in this article. Without V9.0 SP2, the operation must be performed manually through the Master Data Library or through rename-and-replace, both of which are described below for completeness and for sites that have not yet installed the update.

Prerequisites and Pre-Migration Analysis

Before any CMT swap is performed, the following preconditions must be met. Skipping this checklist is the single largest source of corrupted projects in the field.

1. Project state. The S7 project must be in a clean compiled state. Run Compile > Charts as Program and Compile > OS and verify that no warnings remain in the output log. Any pre-existing inconsistency will be silently absorbed by the migration and resurface at download time on the AS.
2. Type and instance parity. Both CMTs (ABC and BBB) must exist in the same Master Data Library. If BBB lives in a separate project or in a transport package, it must be imported and the project re-compiled first.
3. Interface compatibility check. The successor CMT BBB must expose the same I/O block names that are wired in the existing CMs. If block names have been renamed (for example, I_LIT to PV_IN), the EM Technological interface, the SFC, and the OS faceplate will all need re-wiring after the swap.
4. Archive before touching anything. Use SIMATIC Manager > File > Archive or the TIA equivalent. Keep at least one full archive on a network share and one offline. This is the only valid rollback path.
5. WinCC / Operator Station sync state. The OS server project must be reachable and the WinCC Explorer must not be in an unsaved state. If the OS project is open on a separate engineering station, close it first to avoid exclusive file locks on the OS database.

Inventory: Where the CMT Is Referenced

Before swapping, build a reference list of every place the source CMT ABC is touched. A typical site will see references in at least the following locations:

• The Master Data Library itself (the type definition).
• CM instances in SFC and CFC charts under the plant hierarchy.
• The EM Technological interface (symbolic I/O of the EM block).
• WinCC faceplate assignments (the OS reference to the CM tag name).
• WinCC archive and trend tags (historians reference the CM by tag name).
• Messages and alarm classes (CM-attributed messages travel with the tag name).

Use Options > Cross References on the source CMT to generate the complete reference list. The CMT swap is safe only if the tag names of the new CMT instances match the tag names of the old ones, because every downstream consumer (WinCC faceplates, archives, SFCs) addresses the CM by tag name, not by GUID.

Method A: Rename-and-Replace in Place

This is the lowest-risk method for projects on V9.0 SP1 that have not yet been upgraded to the SP2 Engineering System Collection. It works by keeping the existing CM instances attached to their EM and renaming around them.

Step-by-Step Procedure

1. Pre-condition. Project is compiled and synchronized. Both CMTs ABC and BBB exist in the same MDL.
2. Create new CM instances from the new CMT BBB in the relevant folders of the plant hierarchy. Leave them with their default names (for example, BBB_001, BBB_002).
3. Rename the old CM instances by prefixing them with a marker character (for example, oABC_001). The Process Object View (POV) is the fastest way to do this for a large instance count; sort by the type column and apply the rename in bulk.
4. Rename the new CM instances from BBB_001 to the original tag names (for example, TIC_1101). The tag names are now attached to CMT BBB, not CMT ABC.
5. Update the EM Technological interface. Open the EM chart, insert the new CM (now under CMT BBB) at the appropriate input/output of the EM block, delete the wiring to the old CM (now oABC_001), and re-wire the symbolic connection to the new CM.
6. Delete the old CM instances (the renamed oABC_* entries).
7. Compile the program and verify that no I/O connection warnings appear.

Observed behavior. In practice, on PCS 7 V9.0 SP1, the CMs kept their assignments in the EMT even after the rename, which is what made the operation fast. The EM block will report "updated without synchronization" — you may run a sync, but nothing visible changes. This is expected and harmless; the connection table is updated on the next OS compile.

Method B: Master Data Library Migration

This method is the most invasive but also the most controlled, and is the recommended fallback when Method A fails (for example, when the CMTs have substantially different I/O names).

Step-by-Step Procedure

1. Create an empty project as a staging area.
2. Copy the successor CMTs from the live project (or from the external library) into the Master Data Library of the empty project.
3. Rename the successor CMTs to the names of the original CMTs (for example, rename BBB to ABC). At this point the empty project contains type ABC built from the new code.
4. Delete all CMTs from the Master Data Library of the live project that has the old CM instances. This is destructive and irreversible without an archive.
5. Copy the renamed successor CMTs (now under the original name ABC) from the staging project into the live project MDL.
6. Synchronize the CMTs with the CMs. Right-click the CM instance in the plant hierarchy and run Synchronize with Type. Because the new CMT (now named ABC) has a different version stamp, PCS 7 will offer to "update with changes" — accept the dialog to bind the existing CMs to the new CMT code.

The end state is: same instance, same tag name, same EM wiring, but the code behind the CM is the new BBB implementation under the name ABC. This is the cleanest result for downstream consumers, because no tag name change has occurred anywhere in the project.

Method C: Technological List Editor (PCS 7 V9.0 SP2 Native)

This is the recommended method for any site running PCS 7 V9.0 SP2 or later with CFC V9.0 SP3. It uses the new Assignment CM tab in the Technological List Editor to change the type assignment of an individual CM, without renaming, without deleting, and without going through the Master Data Library.

Step-by-Step Procedure

1. Open the Technological List Editor from the plant hierarchy: right-click the relevant folder > Technological List Editor.
2. Navigate to the Assignment CM tab. The tab is only populated when the CMTs involved have a compatible interface. If the tab is empty, the underlying CMT I/O is not compatible and Method A or B must be used instead.
3. Select the target CM instance from the list. The left column shows the current type assignment; the right column shows available successor types.
4. Choose the successor CMT (for example, BBB) and confirm. The dialog will show a diff of block I/O changes; review carefully.
5. Accept the change. The CM instance is now backed by the new CMT, with the original tag name and the original EM wiring preserved.
6. Compile the chart and download to the AS. Verify that the OS faceplate still shows the correct tag name and that all block I/O is connected.

This is the only method that can be performed on a per-instance basis. For a project with 100 CM instances, this means it is now possible to migrate a subset (for example, a single process cell) to the new CMT, run it on the AS in parallel with the legacy CMT, and migrate the rest of the plant only after the new CMT is field-proven. The release notes explicitly call out this use case as the design intent.

Parameter and Live-Value Preservation

Regardless of the chosen method, the live values on the AS (tuned PID gains, valve positions, alarm limits, runtime counters) are not part of the CMT definition. They live in the online DB on the AS. The migration procedures described above operate only on the offline engineering database. To preserve the live values through a download, follow this sequence:

1. On the live AS, open the CFC chart and select Chart > Read Back to upload all online values into the offline engineering database. This will overwrite any default values in the new CMT instances.
2. Perform the CMT migration using Method A, B, or C above.
3. After the migration, verify the parameter values in the offline chart. If the read-back in step 1 happened after the migration, the new CMT default values will be in place — this is usually not what is wanted.
4. Download to the AS. The download will write the offline values to the online DB. Live tuning is preserved.

Verification and Commissioning Checks

After the migration and the download, the following verification sequence is mandatory before the plant can be put back into production.

1. Cross-reference scan. Run Options > Cross References on the successor CMT and confirm that the reference count matches the pre-migration count on the source CMT. A mismatch indicates a missed instance.
2. WinCC OS compile. Compile the OS and check the log for "tag not found" warnings. Each warning points to a faceplate that lost its CM reference.
3. Faceplate test. On the OS, open a faceplate for at least one migrated CM and verify the live values match the pre-migration snapshot. Open a faceplate for a non-migrated CM and verify it still works (sanity check that the EM wiring is intact).
4. EM I/O scan. In the CFC chart of each affected EM, expand the EM block and confirm that the symbolic connections to the migrated CMs are intact and that no input or output is shown in red.
5. Alarm test. Force a low-priority alarm on a migrated CM and verify that the message text and the operator acknowledgment path work end to end. Alarm classes travel with the CMT, not the CM instance, so a swapped CMT with a different alarm class will change the message routing.
6. Trend test. Open a trend for a migrated CM and verify that historical data continues. The trend tag is bound to the CM tag name, so as long as the tag name is preserved, the historian will continue to record.
7. SFC test. If the migrated CMs are referenced from an SFC, run the SFC in test mode and step through at least one transition to confirm that the step conditions resolve correctly with the new block I/O.

Rollback Strategy

If any of the verification checks fail, the rollback is the pre-migration archive from the prerequisites. The recovery sequence is:

1. Stop the AS (do not perform a "hot" rollback on a live process).
2. De-archive the project in a clean directory.
3. Open the de-archived project in the engineering station and compile.
4. Download to the AS.
5. Verify by reading back the live values from the AS and comparing to the pre-migration snapshot.

A partial rollback is possible only with Method C, because Method C migrates one instance at a time. The other two methods are all-or-nothing for the affected CMT.

Field-Proven Pitfalls and Edge Cases

Summary Recommendation

For any site running PCS 7 V9.0 SP2 or later with CFC V9.0 SP3, use the Technological List Editor (Method C). It is the only method that operates per instance, supports partial migrations, and is the official Siemens-supported path documented in the release notes. Fall back to Method A for V9.0 SP1 sites that cannot upgrade, and use Method B only when the CMT I/O is not backward compatible and a full re-mapping of the EM wiring is required. In all cases, archive before, read back before, verify faceplates after, and keep a rollback path on a separate physical disk.

FAQ