Interfacing SIMATIC PCS 7 AS 410 Controllers with Third-Party OPC DA Servers

A SIMATIC PCS 7 AS 410 controller cannot natively act as an OPC DA (Data Access) client because classic OPC DA relies on Microsoft COM/DCOM protocols that run exclusively on Windows operating systems, whereas the AS 410 controller operates a specialized real-time firmware kernel. To exchange signals between an AS 410 and a third-party OPC DA server, you must employ an intermediate gateway. The standard solutions are utilizing the WinCC OS Server OPC Channel to bridge data via tag scripting, installing an S7 Communication driver on the third-party PC to poll the AS directly, or deploying a hardware or software OPC bridge.

Technical Foundations of OPC DA and COM/DCOM Architecture

Classic OPC Data Access (OPC DA 2.05a and OPC DA 3.0) is built on Microsoft's Component Object Model (COM) and Distributed COM (DCOM) infrastructure. In OPC DA, communication relies on Windows binary Remote Procedure Calls (RPC), Windows registry object identifiers (CLSIDs), and Windows user security authentication (NTLM / Kerberos).

Because of this deep dependency on the Windows OS subsystem, both the OPC DA Server and OPC DA Client must execute within a Microsoft Windows environment.

Why AS 410 Controllers Cannot Act as Native OPC DA Clients

Process automation controllers, including the Siemens CPU 410-5H (6ES7410-5HX08-0AB0) and CP 443-1 communication processors (6GK7443-1EX30-0XE0), run proprietary embedded real-time operating systems (VxWorks / proprietary microkernels). They lack Windows subsystems, registry services, and DCOM execution layers.

Consequently, the CPU 410 cannot initiate an outbound DCOM connection to query an external third-party OPC DA server. Any architecture requiring data exchange between an AS 410 and an OPC DA server must place a Windows-based PC or protocol gateway between them.

Integration Architecture 1: WinCC OS Server as Communication Gateway

In SIMATIC PCS 7 systems with an existing OS Server, WinCC provides an integrated bridging solution:

OPC Channel Client: In WinCC Tag Management, add the OPC channel (OPC.chn). Configure an OPC connection pointing to the third-party OPC DA server. WinCC acts as an OPC DA client, reading process tags into WinCC internal tags.
SIMATIC S7 Protocol Suite: WinCC already maintains high-speed Named Connections or S7 Industrial Ethernet links to the AS 410 controller.
Data Bridging: Transfer data between the OPC tags and the AS 410 S7 tags using:
- WinCC Global Action (C or VBScript): Triggered on tag change or cyclic timer (e.g. 1 s), copying values from OPC tags to PLC tags.
- Dynamic Wizard / Tag Interconnection: Direct link mapping in WinCC runtime.

Integration Architecture 2: S7 Communication / SIMATIC NET Drivers

An alternative that avoids loading the SCADA script engine is implementing native S7 communication directly on the third-party machine:

S7 Communication Driver: Many third-party OPC servers (such as Kepware KEPServerEX, Matrikon, or Softing) include optional Siemens S7 communication drivers. The third-party software connects directly to the CPU 410 via ISO-on-TCP (port 102) and reads/writes DB addresses directly using S7 protocol.
SIMATIC NET OPC Server: Install SIMATIC NET on the third-party PC. Configure an S7 connection to the AS 410. Then, run an OPC-to-OPC bridge utility (such as Siemens OPC Data Control or Softing dataFEED) to bridge tags locally.

Modern Alternative: OPC UA via CP 443-1 OPC UA

For facilities migrating to modern open standards, OPC Unified Architecture (OPC UA) eliminates DCOM dependencies:

By adding a CP 443-1 OPC UA module (6GK7443-1UX00-0XE0) to the AS 410 rack, the controller gains embedded OPC UA Server and OPC UA Client capabilities directly on the rack.
If the third-party system supports OPC UA, the AS 410 can communicate directly across standard Ethernet TCP/IP without intermediate Windows servers or WinCC script engines.

Comparison of AS 410 to Third-Party OPC Integration Architectures

The table below contrasts the technical characteristics of each integration approach:

Integration ApproachGateway HardwareProtocol to AS 410Protocol to 3rd PartyPerformance / DeterminismWinCC OS Server GatewayExisting WinCC OS ServerS7 Named ConnectionsOPC DA (COM/DCOM)Medium (100 - 500 ms; script-dependent)3rd-Party Native S7 DriverThird-party PCISO-on-TCP (Port 102)Internal to 3rd PartyHigh (50 - 100 ms; direct S7 read/write)SIMATIC NET + OPC BridgeDedicated Gateway PCS7 ProtocolOPC DA BridgeHigh (Deterministic software bridge)CP 443-1 OPC UA ModuleAS Rack CP 443-1 ModuleDirect Backplane BusNative OPC UA (TCP)Highest (Hardware real-time client/server)

Verification

Verify signal exchange between the third-party OPC server and the AS 410:

If using the WinCC gateway, open WinCC Channel Diagnosis (WinCCChnDiag.exe). Confirm both OPC and SIMATIC S7 Protocol Suite show green status.
In WinCC Tag Management, verify that the OPC tag reflects current process values from the third-party server.
In CFC, open the destination block online; verify the input parameter receives updated values.
Modify a value in the third-party system and measure the propagation latency to the AS 410 controller logic.

Limitations and Operational Precautions

Observe the following safeguards when engineering OPC DA cross-system connections:

DCOM Security Hardening: Microsoft Windows DCOM hardening updates (KB5004442) enforce strict authentication. Ensure DCOM authentication levels (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) match between Windows nodes.
Script Engine Reliability: Using WinCC global scripts for process interlocks is not recommended for critical safety or fast shutoff logic; scripts depend on Windows desktop process scheduling and can lag under high operator load.
Quality Code Propagation: Ensure the gateway script checks the OPC Quality Code (Good = 16#C0) before transferring values into the AS 410 to avoid passing stale or invalid data into controller logic.

Engineer FAQ

Can an AS 410 controller run an OPC DA client block directly in CFC?

No. Classic OPC DA requires Microsoft COM/DCOM runtime libraries that only exist on Windows operating systems. The AS 410 real-time firmware cannot execute COM/DCOM calls.

What is the simplest way to get data from WinCC OPC channel to an S7 channel without scripts?

WinCC does not provide an automatic cross-channel tag linker in Tag Management without scripting or additional tools. You can use an event-driven VBScript on tag change, or deploy a local OPC bridge utility like Siemens OPC Data Control.

Can the CP 443-1 communicate via OPC DA directly?

No. Standard CP 443-1 modules (6GK7443-1EX30-0XE0) only support ISO, TCP/IP, UDP, and S7 communication. Only the specialized CP 443-1 OPC UA (6GK7443-1UX00-0XE0) supports OPC protocols natively, and it supports OPC UA, not classic OPC DA.