PCS 7 Multi-Project: Monitoring Two S7-400H from Each OS

Architecture Overview

In a Siemens PCS 7 plant, two fault-tolerant S7-400H stations frequently need to be supervised from a common pool of operator stations. The reference configuration described in this article consists of two independent PCS 7 projects, each with its own S7-400H automation system, its own OS server, and its own engineering database. The objective is to let every operator station (OS) in the control room view both H systems concurrently, switch between them on a per-operator basis, and keep the redundant Ethernet path intact so that a single cable or switch failure does not interrupt the operator view.

The end-state architecture is therefore a STEP 7 multi-project containing both AS projects, a single WinCC server image that holds S7 fault-tolerant connections to both H systems, and a RedConnect-enabled CP1613 in each OS that maintains two physical Ethernet paths through two managed switches. Because the original projects were developed as separate databases, the migration path involves three coordinated activities: collapsing the two STEP 7 databases into one multi-project, building fault-tolerant S7 connections in NetPro, and consolidating the WinCC graphics into one runtime database with area-based authorization for the user switching requirement.

Key architectural decisions to confirm with the project team before any code change: (1) whether the merged OS is intended to be a server or a client, (2) whether the merged project must survive an outage of either AS, and (3) whether the operator switching is required at runtime (live switch between plants) or only at login (operator selects one plant per shift). The configuration steps in this article assume a server-style OS that must survive the loss of either AS, with runtime area-based switching.

Prerequisites

Verify the following hardware, software, and licensing items before starting the reconfiguration. Missing items in this list are the most common reason that the combined project fails to compile or fails to come up at runtime.

Hardware

• Two S7-400H stations, each with at least one CPU 414-4H (6ES7414-4HM14-0AB0) or CPU 417-4H (6ES7417-4HT14-0AB0) pair. Both CPUs must be loaded with the same firmware version (for example V4.5.7 or V5.3.6) and configured in H mode.
• Two CP443-1 Ethernet modules per H station (6GK7443-1EX11-0XE0 for standard, 6GK7443-1GX11-0XE0 for advanced). Each module is configured with a unique IP address in the same Industrial Ethernet subnet.
• Two managed Ethernet switches that support the redundancy behavior expected by RedConnect (IEEE 802.1D Rapid Spanning Tree, port priority, or Siemens SCALANCE features). Third-party switches are acceptable but they must support at least 100 Mbit/s full duplex, MAC learning, and broadcast/multicast storm control.
• One CP1613 A2 (6GK1161-3AA01) per operator station. Older CP1613 (6GK1161-3AA00) and CP1613 A1 cards are no longer supported by current SIMATIC NET 2006 / 2007.
• Operator stations with at least 2 GB RAM, Windows XP Professional SP3 or Windows Server 2003 SP2, and a free PCI slot for the CP1613.

Software

• STEP 7 V5.5 + SP1 or later (PCS 7 V6.2 ships with STEP 7 V5.5 SP1).
• PCS 7 V6.2 SP1 with WinCC 6.2 RC 1024 (Runtime Communication) and the latest hotfixes.
• SIMATIC NET 2006 SP2 (or SIMATIC NET 2007 SP1) installed on the OS stations, not the older "Comfort" or "CD" driver referenced in some legacy CP1613 distributions.
• WinCC RedConnect option (6GK1704-1DW64-0AA0 or equivalent for V6.2).
• PCS 7 AS-OS Engineering option for the ES.

Licensing

• PCS 7 OS Server runtime license (6GK1704-1DW64-0AA0) with a count sufficient for 1024 tags (or upgraded to 2048 / 4096 / 8192 tags as required by the merged process tag list).
• Two AS runtime licenses, one per H station.
• WinCC RedConnect option enabled on every OS that uses fault-tolerant S7 connections.
• Authorizations assigned on the License Key USB stick (or License Key Disk) and visible in Automation License Manager.

Hardware Topology: CP443-1 and Switch Wiring

Each H station contains two CP443-1 modules. The standard wiring for a dual-switch RedConnect topology is shown in the diagram below. Connect CP443-1 of H-System 1 to Switch 1 and to Switch 2; repeat the same wiring for H-System 2. Connect the two switches with a single cross-link cable so that spanning tree or a vendor proprietary redundancy protocol can block one of the two paths. Each OS connects to both switches through a single CP1613 that has two MAC addresses, one for each switch path.

Key wiring rules:

1. Each CP443-1 must occupy a unique IP address in the same subnet (for example 192.168.0.11 and 192.168.0.12 for H-System 1; 192.168.0.21 and 192.168.0.22 for H-System 2). The virtual MAC address of the redundant pair is automatically derived by the CP443-1 firmware; do not attempt to set it manually.
2. Use straight-through RJ45 cables, not crossover, because all modern managed switches auto-MDIX.
3. Disable Spanning Tree on the cross-link between the two switches and enable RSTP on the uplink ports, or use a vendor proprietary redundancy protocol. Spanning tree must not be allowed to block the path to the CP443-1 during normal operation.
4. The CP1613 in each OS uses two MAC addresses that are bound to two different subnets in the same configuration. The WinCC RedConnect driver binds the connection to the second MAC if the first path fails.

STEP 7 Multi-Project Creation

STEP 7 supports grouping independent S7 projects into a multi-project. The multi-project is the engineering object that makes it possible to edit both H systems in one session and to load programs to both H systems from a single engineering station. Cross-project S7 connections and the cross-project plant hierarchy become visible inside the multi-project without any further setup.

1. Open SIMATIC Manager and close any active project.
2. Select File > Multiproject > New. Give the multi-project a meaningful name such as PlantCombined_MP and store it in a dedicated folder.
3. Select File > Multiproject > Insert S7 Project and select the first H project (for example HSystem1_S7). The project appears as a sub-node of the multi-project.
4. Repeat the previous step to insert the second H project (HSystem2_S7).
5. Open Options > Cross-Project Functions and verify that the cross-project S7 connections are visible. In PCS 7 V6.2 the cross-project function also surfaces the plant hierarchy for both projects.
6. Right-click the multi-project root and select Multiproject > Save As to take a baseline snapshot of the empty multi-project before any migration work begins.

Multi-Project Folder Layout

The recommended folder structure for a PCS 7 multi-project that hosts two H stations is shown in the code block below. Following this layout avoids path-length issues on Windows XP and Windows Server 2003 and keeps the archive footprint manageable.

D:\PCS7_Projects\PlantCombined_MP\
   PlantCombined_MP.s7p
   HSystem1_S7\
       HSystem1_S7.s7p
       Library\
   HSystem2_S7\
       HSystem2_S7.s7p
       Library\
   WinCC_Merged\
       WinCC_Merged.mcp

NetPro Configuration of Fault-Tolerant S7 Connections

WinCC can only talk to an S7-400H station through a fault-tolerant S7 connection, which is what RedConnect implements on the wire. A normal S7 connection sees only the active CPU at any given moment; if the active CPU fails, the connection is broken until the standby CPU takes over and the application reconnects. A fault-tolerant S7 connection survives the switchover because both CP443-1 modules advertise the same virtual MAC address, and the OS-side RedConnect driver treats the two physical paths as one logical path.

1. In each subordinate S7 project, open NetPro.
2. Select the CP443-1 module that is configured for the OS subnet, right-click and choose Insert New Connection.
3. In the Insert New Connection dialog, choose S7 Connection Fault-Tolerant as the connection type.
4. Select the partner: the partner is the OS station, identified by the MAC address or IP of the CP1613. WinCC exposes the OS as a "SIMATIC S7 Station" with a specific module type that you must set to WinCC RedConnect OS.
5. Assign a unique local connection ID (for example 101 for H-System 1, 201 for H-System 2) so that WinCC can bind the correct tag set to the correct connection.
6. Tick Establish active connection on the OS side and tick Send keep-alive with a 30 s interval.
7. Save and compile NetPro. The compile result should list two redundant S7 connections per OS, one for each CP443-1.

CP1613 and RedConnect Configuration

A frequent failure mode of mixed-vintage PCS 7 installations is that the CP1613 is bound to the legacy "CD" (Communication Driver) protocol stack that ships with older SIMATIC NET CDs, instead of the proper "Softnet-S7" or "Hardnet-S7" stack that RedConnect requires. This is the exact failure mode described in the source troubleshooting: the OS cannot see the AS tags even though the project was imported correctly. The fix is to install SIMATIC NET 2006 SP2 (or 2007 SP1) on the OS station and to re-bind the CP1613 to the Softnet-S7 protocol.

1. On the OS station, run SIMATIC NET > Communication Settings.
2. Locate the CP1613 and confirm the bound protocol is Softnet-S7 REDCONNECT. If it shows CD or TCP/IP, click Change and select the Softnet-S7 RedConnect protocol.
3. Configure the two MAC addresses. The first MAC is the one on the main subnet (for example 192.168.0.101) and the second MAC is on the redundant subnet (for example 192.168.0.103). Both must be reachable from the corresponding CP443-1.
4. Set the redundancy mode to S7-REDCONNECT (Mode 4). Other modes (1, 2, 3) cover standard single-network, two-network, and OS-server redundant scenarios and do not provide the seamless S7-400H switchover behavior required here.
5. Save the configuration and restart the SIMATIC NET service.
6. Run SIMATIC NET > Diagnostics > Connection Status to confirm that both connections are in the "OK" state.

CP1613 A2 Hardware Reference

RedConnect Connection State Machine

The CP1613 driver in Mode 4 cycles through a small state machine during a fault. The diagram below summarizes the visible state transitions. The transitions are typically observable in the SIMATIC NET diagnostic buffer and in the WinCC tag quality code.

WinCC Project Consolidation

WinCC does not have a multi-project concept that matches the STEP 7 multi-project. The migration path is therefore to consolidate the two separate WinCC databases into a single WinCC database that contains the S7 connections, tag tables, graphics, and user administration of both H systems. The two approaches are listed below.

Approach A: Single WinCC Server with both S7 connections

1. Open WinCC Explorer on the ES.
2. Right-click Tag Management and add a new driver SIMATIC S7 REDCONNECT. Inside the driver, create two connection units: one for H-System 1 (TSAP 01.01, IP 192.168.0.11/12) and one for H-System 2 (TSAP 01.01, IP 192.168.0.21/22).
3. Import the tag list from the original H-System 1 project. Use Options > PCS 7 > Import Tags and select the S7 program of H-System 1 from the multi-project.
4. Repeat for H-System 2.
5. Open the Graphics Designer and import the pictures from the original H-System 1 project. Rename the picture prefix to P1_ to avoid name collisions with the H-System 2 pictures.
6. Repeat the import for H-System 2 with the picture prefix P2_.
7. In the User Administrator, define two areas: Area_H1 and Area_H2. Grant each operator group the appropriate area authorization.

Approach B: OS Server with redundant pair, one server per AS

If the two H systems are in physically separate control rooms and only need to share operators in a common control room, keep two OS servers and add a pair of OS clients that connect to both. The clients see a single combined plant view. This approach is less invasive but requires one extra Windows license and one extra CP1613 pair.

TSAP and Connection Parameter Mapping

The Transport Service Access Point (TSAP) is the addressing primitive of the S7 protocol. A mismatch between the NetPro connection TSAP and the WinCC channel unit TSAP is the most common cause of "connection established but no tags updating". Use the mapping below when consolidating the two projects.

User-Based Screen Switching

Because both projects are now inside a single WinCC database, the operator can switch between the two views through a standard WinCC login/logout cycle combined with area authorization. The configuration steps are:

1. In the User Administrator, create groups OPERATOR_H1 and OPERATOR_H2. Add the operator user names to one or both groups.
2. Open the Area tab and create two authorization areas: H1_Overview and H2_Overview.
3. In the Graphics Designer, open the start picture and assign the level H1_Overview to all H-System 1 picture elements. Repeat with H2_Overview for the H-System 2 elements.
4. On the start picture, add two buttons: one calls OpenPicture("P1_Overview.pdl") and the other calls OpenPicture("P2_Overview.pdl"). Set the Operator authorization on each button to the corresponding area.
5. Compile the runtime database and start WinCC Runtime.

The resulting behavior: an operator who logs in as a member of OPERATOR_H1 sees only the H-System 1 buttons; a member of OPERATOR_H2 sees only the H-System 2 buttons; a member of both groups sees both buttons and can navigate freely between the two plants. This satisfies the requirement that the project order be able to monitor every project by every OS with operator-level control over which plant is currently active on the screen.

Sample C Action for Picture Switching

The C action below can be attached to the mouse-click event of a button to switch pictures and verify that the destination picture exists before the call. Place the snippet in the Graphics Designer on the button that has the operator authorization H1_Overview or H2_Overview.

#include "apdefap.h"
void OnClick(char* lpszPictureName, char* lpszObjectName,
             char* lpszPropertyName, UINT nFlags, int x, int y)
{
    /* Determine the target picture based on which area
       authorized this button. */
    if (0 == strcmp(lpszObjectName, "btnH1")) {
        if (0 == PDLRTIsPictureExist("P1_Overview.pdl")) {
            PDLRTSetPropEx(0, "lpszPictureName", 0,
                            "P1_Overview.pdl", 0);
            OpenPicture("P1_Overview.pdl");
        } else {
            /* Log and abort: picture is missing. */
            sysLog(0, "MISSING P1_Overview.pdl", 0);
        }
    } else if (0 == strcmp(lpszObjectName, "btnH2")) {
        if (0 == PDLRTIsPictureExist("P2_Overview.pdl")) {
            OpenPicture("P2_Overview.pdl");
        } else {
            sysLog(0, "MISSING P2_Overview.pdl", 0);
        }
    }
}

Verification and Commissioning

After the multi-project and WinCC database are consolidated, run the following checks in order. Each step must pass before moving to the next; a failure at step N usually means that an earlier step was completed only partially.

1. STEP 7 consistency: open the multi-project, run PLC > Compile and Download Objects on each AS. The download must complete without error code 0040-0Fxx (configuration inconsistency).
2. CP443-1 link check: from the ES command prompt, run ping 192.168.0.11 -t while a colleague unplugs the redundant link. The ping must continue to respond through the surviving CP443-1.
3. RedConnect diagnostic: on the OS station, open the SIMATIC NET Configuration Console and confirm that both S7 connections show Established. Disconnect the cable to Switch 1; within 90 s both connections should re-establish on Switch 2.
4. WinCC tag subscription: in the WinCC Tag Management, right-click the H-System 1 connection and select Diagnosis. The status should read OK and the quality code of every tag should be Good (0xC0). The quality code Bad (0x00) indicates a wrong TSAP or a wrong S7 connection ID.
5. User switching: log in as an H1 operator, confirm that H2 buttons are hidden. Log out and log in as an H2 operator, confirm that H1 buttons are hidden. Log in as a member of both groups and confirm that both button sets are visible.
6. Switchover test: while WinCC Runtime is running, trigger a CPU switchover on H-System 1 by stopping CPU 1 in the STEP 7 HMI panel. The WinCC tags should not lose quality; the connection should switch over to CPU 2 within 1-2 s. Use WinCC Tag Logging's diagnostic buffer to verify.
7. Power-off test: turn off Switch 1 entirely. The redundant connection should re-establish through Switch 2. After restoring Switch 1, the connection should re-balance. The total interruption should not exceed 90 s, which is the default RedConnect keep-alive timeout.
8. Archive test: trigger a process alarm on H-System 1 and on H-System 2, confirm that both alarms arrive in the WinCC Alarm Logging buffer and that the user sees the correct area code prefix (H1 or H2) in the message line.
9. Time synchronization: verify that both H systems and both OS stations point to the same time source. Inconsistent time between the two AS projects will produce wrong sequence-of-events ordering in the alarm log. Use a single SICLOCK or a single NTP source for all four devices.

Troubleshooting Matrix

OS Server vs. OS Client Licensing

A common question during the migration is whether the OS in the control room should be a server or a client. The decision has a direct impact on the RedConnect configuration. A server OS holds the S7 connections and the data archive; a client OS connects to the server OS and has no S7 connections of its own. For a single-control-room installation with two H systems, the most common topology is one server OS with two RedConnect S7 connections (one per H) and N client OS stations that connect to the server. If a second control room is required, a second server OS must be installed and both server OS stations must run a server-server redundancy pair.

Frequently Observed Event Log Codes

The Windows application event log is the first place to look when WinCC tags start misbehaving. The table below lists the codes most often observed on an OS that runs a RedConnect S7 connection to two S7-400H stations.

FAQ