Diagnosing PCS 7 OS Server AS Communication Loss with CP1613

A redundant PCS 7 OS server pair losing communication with the Automation Station (AS) is one of the most disruptive faults a plant operator can face, because the redundancy model hides the failure until a failover event exposes the broken partner. This reference consolidates the field procedure for isolating the failure to the correct layer (physical network, CP1613/CP1623, Station Configuration Editor, WinCC channel, S7-400H redundancy), restoring service, and building a repeatable diagnostic routine that does not require a console session on every fault.

1. PCS 7 OS-AS Architecture and Failure Modes

A PCS 7 OS server connects to the AS through one of two primary paths:

• Softnet / S7 OPC channel via a standard Ethernet NIC, using TCP/IP and the S7 protocol.
• IEAS (Industrial Ethernet / AS) via a Siemens CP1613, CP1623, or CP1628 PCIe/PCI card, with the SIMATIC NET hard-net driver and the S7 connection configured in the Station Configuration Editor.

For redundant OS server pairs, both partners share an identical WinCC/OS project. They communicate with the AS through independent CP443-1 modules in the AS rack (typically two for redundancy), and through independent OS server NICs/CPs. Plant Bus (Industrial Ethernet) switches — most often SCALANCE X/XB/XC families — provide the physical path.

Typical failure modes observed in the field:

2. Separating the S7-400H REDF Fault from OS-AS Communication

The S7-400H redundancy fault indicator (REDF LED on the CPU, or the diagnostic buffer entry "Redundancy loss") reflects a problem inside the fault-tolerant CPU pair — for example a mismatch between the configured redundancy topology in HW Config and the physically inserted modules, or a fiber-optic redundancy link failure. The complete troubleshooting tree is in the Siemens SIMATIC S7-400H Fault-Tolerant Systems manual.

Confirm the AS is healthy from the OS side before proceeding:

1. Open WinCC Explorer on the suspected OS server.
2. Right-click Server → Properties → Connections; check the S7 connection status (green = connected, red = disconnected, yellow = connecting).
3. In the WinCC Channel Diagnosis tool, observe the connection state and the last error code.
4. Cross-check with the redundant partner OS server. If only one server shows the fault, the problem is local to that server's hardware or configuration, not the AS.

3. CP1613 / CP1623 Hardware State and Driver Verification

The CP1613 (PCI), CP1623 (PCIe), and CP1628 (PCIe, 2-port) are the classic IEAS cards used in PCS 7 OS servers. They run the SIMATIC NET "hardnet" protocol stack and are configured through the SIMATIC Station Configuration Editor, not through Windows networking.

Common hardware states:

3.1 Where to look for the CP state

The CP1613's logical state is reported in two places:

• SIMATIC Station Configuration Editor (Start → Siemens Automation → Station Configuration Editor). The CP1613 entry should show RUN, not STOP. If it is STOP, the configuration block was never downloaded or has been cleared.
• SIMATIC Diagnostics (Start → Siemens Automation → SIMATIC Diagnostics). Open the online view, navigate to the OS server's PC station, and inspect the CP1613 diagnostic buffer for entries such as "Station failure", "Connection aborted", or "Index invalid".

The CP1613 must also appear in Device Manager under SIMATIC devices with no yellow bang. A missing or errored entry here means the SIMATIC NET driver set was not installed correctly, which can be triggered by Windows updates on unsupported OS releases. Refer to the PCS 7 V9.1 Readme for the supported Windows / SIMATIC NET combinations.

4. Restoring the CP1613 to RUN (Recovery Procedure)

The field-proven recovery procedure when the CP1613 is in STOP and the OS server cannot reach the AS is:

1. On the OS server, close WinCC Runtime and any project open in WinCC Explorer.
2. Open SIMATIC Station Configuration Editor.
3. Right-click the CP1613 entry and select Delete. This removes the indexed configuration without touching the underlying WinCC project on disk.
4. From the Station menu, choose Import Station (or Open) and select the .XDB / station file exported from the engineering station that matches this OS server.
5. Confirm the S7 connection names referenced by WinCC match the imported configuration.
6. Click Download to Station Target. The CP1613 should transition from STOP to RUN within seconds. The Link LED on the SCALANCE port lights as the connection comes up.
7. Restart WinCC Runtime. Verify tag updates from the AS.

If the CP1613 returns to STOP after the download, capture the SIMATIC Diagnostics buffer before the next attempt; the most common cause is a duplicate IP address on the Plant Bus segment or a MAC address collision introduced after a NIC replacement.

5. Station Configuration Editor — Common Misconfigurations

Most CP1613 STOP states originate in the Station Configuration Editor rather than in hardware. Verify each item below against the documented plant standard:

Always compare the running configuration against the engineering project's master station file. Drift between the two is the single largest source of "it worked yesterday" failures on PCS 7 OS servers.

6. Network Layer Diagnostics on the Plant Bus

The Plant Bus is most often a SCALANCE X-200/XC-200/XR-500 ring or a star. Each SCALANCE port LED must be inspected for both servers:

• Green steady — link up, no traffic issues.
• Green blinking — link up, traffic present (normal during heavy polling).
• Off — physical layer fault. Check SFP, patch cable, patch panel, and the switch port configuration.
• Amber / yellow — port disabled or in standby; check SCALANCE Web UI or TIA diagnostics.

From the OS server console:

1. Open a command prompt and run ping <CP443-1_IP> -t for 60 seconds. Stable replies confirm IP reachability.
2. Run arp -a and verify the AS CP443-1 MAC addresses resolve correctly.
3. Open SIMATIC Diagnostics and inspect the OS server's own CP1613 statistics for Connection aborts, Send errors, and CRC errors. CRC errors above ~1 per 10⁶ frames indicate a marginal cable or SFP.
4. On the SCALANCE, open the Information → Port Statistics page and compare error counters on the port facing the faulty server against a known-good port.

7. WinCC Channel and Project Verification

Once the CP1613 is in RUN and the Plant Bus is reachable, confirm the WinCC project uses that connection:

1. In WinCC Explorer, open Computer → Properties → Startup. Confirm the S7 connection names listed here match the names imported into the Station Configuration Editor (case-sensitive).
2. Open Tag Management → SIMATIC S7 PROTOCOL SUITE → S7 Connection. Right-click and select Connection Status. A healthy connection shows "Established".
3. Use the WinCC Channel Diagnosis tool (Start → Siemens Automation → Channel Diagnosis). It exposes live connection state and the last S7 error code, which maps to the SIMATIC NET error class:

For the canonical list see the WinCC Information System channel diagnostics page.

8. S7-400H REDF Fault — Quick Triage

If REDF is lit on one of the H-CPUs, treat it on a parallel track. The minimum triage is:

1. Open the diagnostic buffer of the master CPU in STEP 7 → HW Config → CPU → Module Information → Diagnostic Buffer.
2. Look for entries tagged "Redundancy loss", "Link failure", or "Rack failure".
3. Verify both CPU 0 and CPU 1 are physically present, both redundancy fiber-optic modules (IF 960 or similar) are seated, and both fiber links show link LEDs.
4. In HW Config of the S7-400H station, confirm the Fault-tolerant setting is active and the partner CPU slot matches the physical layout.
5. For deeper procedures refer to the S7-400H Fault-Tolerant Systems manual.

9. Building a Repeatable Diagnostic Routine

To avoid ad-hoc "log in and check" sessions on every fault, codify a diagnostic runbook:

9.1 Passive indicators (always monitored)

• WinCC redundancy control tag @RedundancyState and partner status tag.
• SIMATIC Diagnostics online view subscribed to the OS server PC stations.
• SCALANCE port status sent to a central NMS via SNMP traps (loss-of-link traps).
• Windows event log entries for S7oiehsx64 / SIMATIC NET sources.

9.2 Active diagnostic script (run from a maintenance terminal)

The following PowerShell snippet captures the minimum evidence in one shot:

# Capture core evidence for OS-AS communication troubleshooting
$ts = Get-Date -Format "yyyyMMdd_HHmmss"
$out = "C:\Diag\OS_AS_$ts"
New-Item -ItemType Directory -Path $out | Out-Null

# 1. Network reachability
Test-Connection -ComputerName "<CP4431_IP>" -Count 10 | Export-Csv "$out\ping.csv" -NoTypeInformation

# 2. SIMATIC Station state via OPC UA on the local station (requires SIMATIC NET diagnostic API)
#    See the SIMATIC NET diagnostic interface documentation for full usage.

# 3. SCALANCE trap receiver status
Get-EventLog -LogName Application -Source "SIMATIC*" -Newest 200 | Export-Csv "$out\applog.csv" -NoTypeInformation

# 4. WinCC channel diagnosis export (manual step: open WinCC Channel Diagnosis and save report)
Write-Host "Now open WinCC Channel Diagnosis on the affected server and save the report to $out"

9.3 Health-check indicators to log daily

Trending these values exposes drift before it produces a fault — for example a slowly increasing CRC error count indicates a degrading SFP that can be replaced during a scheduled outage.

10. Verification After Recovery

Once the CP1613 has been re-downloaded and the OS server is back online, confirm full operation:

1. WinCC Runtime is started; both servers show Master and Standby states respectively.
2. Open an S7 connection diagnostic view; all configured connections show Established.
3. Force a tag update from an AS binary input and verify the change appears in the OS faceplate within one scan cycle.
4. Trigger a manual failover (WinCC Explorer → Server Data → Redundancy → Switch Master) and confirm the previously faulty server can take over the master role and the formerly-master server reconnects as standby.
5. Inspect the SIMATIC Diagnostics buffer for any residual warnings.

Document the fault, the corrective action, and the time-to-recovery in the plant maintenance log. The trend of such events over months is the input to a hardware refresh decision — typically CP1613 cards approaching end-of-life, or NIC firmware / driver mismatches after Windows patching.