Factory Resetting and Decommissioning SIMATIC PCS 7 ES/OS Stations - Project Purging and System Separation

Unlike SIMATIC S7-400 automation system CPUs that feature a physical memory reset (MRES/Urlöschen) to restore factory conditions, PCS 7 PC stations (Engineering Stations and Operator Stations) have no single factory reset command. Recommissioning or redeploying existing IPC hardware—such as repurposing PCS 7 V7.2 IPC547 workstations into an autonomous plant section—requires a systematic purging workflow: creating a baseline Multiproject archive, decoupling subprojects in SIMATIC Manager, resetting WinCC runtime project databases (clearing .mdf/.ldf runtime segments and DCF cache files), re-parameterizing Simatic Shell, and performing clean OS full compilation and download.

The Concept of 'Urlöschen' in PC Stations vs Controllers

In industrial automation, engineers familiar with PLC controllers frequently associate decommissioning or re-initialization with 'Urlöschen' (Overall Reset / MRES). On an S7-400 CPU, an MRES clears work memory, resets communication buffers, and re-initializes memory cards to a clean hardware state. However, on PC-based stations (IPC547, IPC647, or IPC847 running Windows operating systems), software state is distributed across the Windows Registry, Microsoft SQL Server databases, WinCC project directories, and SIMATIC Manager archives.

Attempting to wipe a PC station without following structured DCS separation procedures inevitably leaves behind database locks, stale WinCC redundancy connections, and obsolete cross-project references. When an operating plant separates a consolidated multiproject into two autonomous systems (e.g., modernizing one unit to PCS 7 V9.0 while maintaining an independent legacy unit on V7.2), the separation must be orchestrated at the Multiproject engineering level rather than attempting manual file deletions in the operating system.

Decoupling and Purging Multiproject Architectural Components

When dividing a legacy plant or redeploying existing IPCs, the project topology must be split systematically to ensure neither station retains communication dead-ends or unresolved cross-AS pointers.

Decommissioning PhaseAction in SIMATIC ManagerAction on Target OS PC Station1. Multiproject BackupExecute File -> Archive -> Multiproject to removable mediaVerify OS Runtime is deactivated and closed2. Plant Subproject SeparationUse File -> Multiproject -> Remove from Multiproject for obsolete unitsClose WinCC Explorer completely3. Hardware ReconfigurationDelete retired PC stations from HW Config and NetProClear obsolete network adapter IP configurations4. Cross-Reference PurgeRecompile AS-OS cross-references and NetPro connectionsPurge project directory temporary and DCF files5. WinCC Database ResetGenerate a fresh OS project target via Project DuplicatorReset Tag Logging / Alarm Logging SQL databases6. Clean System DownloadPerform Download Entire Program and Download Entire OSRe-initialize Simatic Shell multicast settings

This structured separation guarantees that the retained legacy IPCs (such as IPC547C running PCS 7 V7.2) operate completely independently from the new modernization island (e.g., IPC547G running PCS 7 V9.0).

IPC Station Recommissioning and WinCC Reset Workflow

To redeploy an existing IPC station and completely purge historical runtime artifacts and project residues, execute the following step-by-step procedure:

Full Archive Creation: On the Engineering Station, create a compressed ZIP archive of the entire Multiproject via File -> Archive in SIMATIC Manager.
Separate Subprojects: In SIMATIC Manager, open the Multiproject. Select the subproject containing the stations to be decommissioned, right-click, and select Multiproject -> Remove from Multiproject. Save the detached project as an independent single project.
Deactivate and Clear WinCC Runtime on IPC: On the physical IPC, close WinCC Runtime and WinCC Explorer. Navigate to the project storage directory. If the station is receiving a completely different project, delete the entire project folder contents, or use the WinCC Project Duplicator tool to overwrite the directory cleanly.
Purge WinCC Database Cache: If reusing the existing OS project shell, delete the <ProjectName>.DCF file in the WinCC project directory. This forces WinCC to rebuild its configuration cache upon the next launch, removing corrupted server references.
Reset Historical Archive Segments: Open the WinCC project in WinCC Explorer. In Tag Logging and Alarm Logging, verify archive configurations and perform an archive reset if historical logs must not carry over to the new process unit.
Reconfigure Simatic Shell and Terminal Bus: Open Windows Explorer, select This PC -> Simatic Shell, open Settings, and verify that the active network adapter matches the terminal bus NIC. Ensure encrypted communication settings match the engineering station.
Complete OS Compilation and Download: On the ES, open the OS compile wizard, select Entire OS with With Memory Reset, and perform a full OS download to the target IPC station path.

Verification

Execute the following tests to verify that the IPC station is completely clean and operational:

Simatic Shell Visibility: On both the ES and the redeployed IPC, open Simatic Shell and confirm that all active stations appear without error or yellow warning flags.
WinCC Project Launch Check: Open the newly downloaded OS project on the IPC. Confirm that WinCC opens without reporting missing database links, stale server package references, or DCF lock errors.
Runtime Activation and Process Communication: Activate WinCC Runtime. Verify that process values update smoothly, alarms from the connected AS trigger correctly, and no error messages regarding disconnected partner servers appear in the WinCC alarm control single-line header.

Limitations and Operational Precautions

When redeploying legacy PCS 7 hardware, technical teams must observe strict compatibility boundaries:

Hardware and OS Release Matrix: An IPC547C running PCS 7 V7.2 operates on Windows XP or Windows 7 (32-bit). It cannot run PCS 7 V9.0 (which mandates Windows 10 Enterprise LTSB/LTSC 64-bit or Windows Server 2016/2019).
Network Isolation: When splitting a site into two independent DCS systems (e.g., Plant 1 on V7.2 and Plant 2 on V9.0), ensure terminal buses and plant buses are logically or physically isolated (separate VLANs or subnets) to prevent broadcast/multicast packet interference and duplicate station naming conflicts.
Commercial Procurement and Licensing Disclaimer: When reallocating or modernizing PCS 7 software licenses, verify exact licensing requirements and software package entitlements against official Siemens catalog documentation. Valid license keys must be installed via Automation License Manager (ALM) for each active runtime instance.

Engineer FAQ

Is there an automated 'factory reset' utility for WinCC OS runtime?

No single tool resets an OS station to factory settings. A clean state is achieved by closing WinCC, deleting the existing project folder, removing stale .DCF files, and performing an 'Entire OS' download from SIMATIC Manager.

Why must I delete the .DCF file when reusing an OS project?

The .DCF (Database Configuration File) caches local computer names, server package references, and connection parameters. If an IPC is renamed, moved, or detached from a multiproject, deleting the .DCF forces WinCC to rebuild the cache cleanly from SQL Server data, preventing phantom server connection errors.

Can I mix PCS 7 V7.2 IPCs and PCS 7 V9.0 IPCs in the same Multiproject?

No. A SIMATIC PCS 7 Multiproject must maintain software version uniformity across all engineering and server stations. Different PCS 7 versions cannot coexist within a single shared engineering database; they must be managed as separate projects.