Resolving SIMATIC NET OPC DX RT Status DOWN Error After Reboot

1. Problem Description

Bidirectional OPC Data Exchange (OPC DX) configurations between SIMATIC NET OPC DX Server and a third-party OPC DX server co-located on the same industrial PC fail to re-establish when the workstation recovers from an uncontrolled power loss, even though:

• Auto-logon successfully logs the operator back into Windows.
• The third-party OPC DX server is configured to run as a Windows service and is fully started before the SIMATIC NET components launch.
• The same configuration recovers cleanly after a graceful shutdown and restart.

The end-state after a hard reboot is consistent and reproducible:

The error reported inside the SIMATIC NET log file OPC_DX.err is:

*** SIMATIC NET OPC-Server DataAccess-V1.0A/2.05 DataExchange-V1.0 (C) SIEMENS AG 2004: Start [V01.03.00.6 release]
*** Instance: C:\Program Files\SIEMENS\SIMATIC.NET\opc2\bin\opcdxserver.dll
*** Date: 15. 8.2006
6:27:36,991|009C* >DllMain DLL_PROCESS_ATTACH
6:27:36,991|009C* <DllMain DLL_PROCESS_ATTACH
6:27:37,862|009C* -> DXInit
6:27:37,862|009C* > GlobalInitialize
6:27:37,862|009C* < GlobalInitialize
6:27:38,142|009C* <- DXInit [hr=0]
6:28:22,259|009C* -> DXStart
6:28:22,259|009C* <- DXStart [hr=0]
6:28:22,259|0120* FAILED ConnectIVar2: no connect since the RT Status is DOWN

Note the misleading [hr=0] on DXStart: the DX server returns success from DXStart(), but the internal connection attempt ConnectIVar2 still fails because the SIMATIC NET runtime (the S7DOS / PC Station subsystem) is not yet in the RUN state. The error code is the internal SIMATIC NET runtime state, not an HRESULT.

2. Reference Environment

The reported failure occurs on the following configuration, which is representative of legacy Windows XP/2003 industrial PC installations still in service:

Equivalent configurations on Windows 7 Embedded / Windows 10 IoT with SIMATIC NET V14 SP1 (or later) exhibit the same defect if the SIMATIC NET service is allowed to start in parallel with other OPC services without an explicit dependency.

3. Architecture of the Failure

OPC DX on SIMATIC NET relies on three coordinated components that are started in sequence by the PC Station:

1. SIMATIC NET Configuration Console (loaded configuration from PCStation.xml).
2. S7DOS / PC Station runtime (the S7OUCIAx / SIMATIC NET Configuration Server service) which brings the configured S7 connections to the CPU into RUN.
3. OPC DX Server (opcdxserver.dll), which only attempts ConnectIVar2 to a peer DX source server once the runtime is in RUN.

When the third-party DX service starts faster than the SIMATIC NET runtime, the OPC DX server receives a request to handshake with a peer whose underlying S7 transport is not yet up. The handshake fails once, DXStart returns hr=0, and the DX source connection is never retried until the operator toggles SourceServerConnected.

4. Root Cause Analysis

Three independent conditions must all be true to reproduce the fault:

1. No service dependency declared. The Windows service for the third-party DX server does not depend on the SIMATIC NET service (or vice versa), so the Windows Service Control Manager starts them in parallel.
2. SIMATIC NET PC Station is not in RUN when ConnectIVar2 is issued. The runtime has loaded the project but the S7 connection establishment is still in progress (typically 5–25 s after logon on legacy hardware).
3. OPC DX does not internally retry on RT Status is DOWN. Once ConnectIVar2 fails, the source connection transitions to disconnected and remains so until a manual trigger forces a re-handshake.

On graceful shutdown/restart the third-party service either does not start early enough or the SIMATIC NET Configuration Console times the DX start to coincide with the S7 connection being up; the race condition is masked. On hard power-loss recovery, both services come up in parallel, the race is exposed, and the DX server loses the only chance it takes to complete ConnectIVar2.

5. Diagnostic Checklist

Before changing configuration, confirm the diagnosis with the following sequence:

1. Open Start → Programs → Siemens Automation → SIMATIC → SIMATIC NET → Commissioning PC Station and read the status of the S7 connection to the CPU 315-2. It should report Connected with a valid Status of the S7 connection before proceeding.
2. Capture the timestamp of the S7DOS service reaching RUNNING from the Windows Event Log (Application log, source S7DOS, event id 1).
3. Open C:\Program Files\Siemens\SIMATIC.NET\opc2\bin\OPC_DX.err and confirm the presence of FAILED ConnectIVar2: no connect since the RT Status is DOWN on every cold boot.
4. Read the third-party DX service start time (Event Log → source Service Control Manager → event id 7036). The two events should be less than ~1 s apart for the race condition to occur.
5. In the OPC Scout (or any DA client), navigate to DX\Source Servers\<3rd Party>\Status and confirm ConnectionStatus=disconnected while SourceServerConnected=TRUE.

If all five items match, the root cause is service ordering and the resolution in §6 applies directly.

6. Resolution — Service Dependency Configuration

Force the third-party DX service to start only after the SIMATIC NET runtime is in RUNNING, and force the OPC DX server to start only after the third-party service is up. This eliminates the race entirely.

6.1 Identify the exact service names

sc queryex type= service state= all | findstr /i "simatic kepware"

Typical results on a SIMATIC NET 2005 V6.3 install with KEPwareEX:

6.2 Add explicit dependencies

Open an elevated command prompt and execute:

REM KEPwareEx must wait for the SIMATIC NET runtime
sc config "KEPwareServerEx" depend= "S7OUCIAx/OPCServer"

REM Optional: the SIMATIC NET OPC DX server must wait for KEPwareEx
sc config "OPCServer" depend= "S7OUCIAx/KEPwareServerEx"

Verify with:

sc qc "KEPwareServerEx"
   [DEPENDENCIES]
   : depends on S7OUCIAx
   : depends on OPCServer

6.3 Reorder the OPC DX start delay (alternative)

If you cannot modify the third-party service (for example, on a supported vendor build), insert a 30-second delay before the SIMATIC NET OPC DX component. This is done by editing the SIMATIC NET PC Station project and changing the OPC DX module's start-up time from 0 to 30 seconds under Properties → Startup:

1. Open Station Configuration Editor.
2. Select the OPC DX index.
3. Open Properties → Startup Parameters and set Delay [s] = 30.
4. Save the station and re-download to the PC Station.

7. Resolution — Manual Re-Handshake Workaround

If a service restart is impossible in the field, the operator can restore the DX connection with a single tag toggle from any OPC DA client, including the SIMATIC NET OPC Scout:

Item path : DX\Source Servers\<3rd Party>\Status\SourceServerConnected
Action    : Write FALSE (forces disconnect)
Wait      : 500 ms
Action    : Write TRUE  (forces re-handshake)
Verify    : Read ConnectionStatus → must be "connected" within 3 s

Scripted equivalents are straightforward in VBScript, PowerShell, or C# using the OPC Automation wrapper. Sample PowerShell:

$opc = New-Object -ComObject OPC.Automation
$server = $opc.Connect("OPC.SimaticNET", "<host>")
$server.OPCGroups.Add("DXFix").IsActive = $true
$item = $server.OPCGroups.Item("DXFix").OPCItems.AddItem(
    "DX\Source Servers\KEPwareEx\Status\SourceServerConnected", 1)
$item.Write(0)            # FALSE
Start-Sleep -Milliseconds 500
$item.Write(1)            # TRUE

8. Resolution — Hardening the Configuration

9. Verification Procedure

1. Reboot the PC by pulling the mains plug while the OS is running. Allow the BIOS to power-on after AC restore.
2. Log in via auto-logon. Do not interact with the desktop.
3. From a remote terminal, read the Event Log Application entries for S7DOS (event id 1, PC Station is in RUN) and for the KEPwareEx service (event id 7036, state RUNNING). The KEPwareEx start must be after the S7DOS RUN entry.
4. Open OPC Scout and verify DX\Source Servers\KEPwareEx\Status\ConnectionStatus=connected.
5. Read three process values from the CPU 315-2 via DX; values must update within the configured poll rate.
6. Repeat steps 1–5 three consecutive times. A stable fix will pass all three cycles.

10. Field-Commissioning Notes

• Different network adapters: the bidirectional DX uses NIC-1 to reach the S7-300 and NIC-2 to reach the KEPwareEx field network. The Service Control Manager dependency is independent of the network adapter, so the same fix applies.
• Firewall: the SIMATIC NET runtime uses UDP port 102 (ISO-on-TCP) to the CP 343-1 and TCP ports 38410–38413 for DX peer traffic. Confirm Windows Firewall allows these on both NICs after each patch Tuesday.
• Anti-virus: exclude C:\Program Files\Siemens\SIMATIC.NET and the third-party OPC server installation folder from real-time scanning. AV-induced service start jitter has been observed to re-introduce the race even after dependencies are configured.
• Virtualization: if the runtime is moved to a VM, configure the VM to start before user logon (Automatic start, not Manual) and replicate the same DependOnService chain inside the guest.

For additional background on the OPC DX specification itself, see the OPC Foundation — OPC Data Exchange (DX) overview, and the SIMATIC NET OPC DX Programming Interface manual distributed with the SIMATIC NET PC Software DVD.