Configuring Third-Party OPC Client Connections to Redundant WinCC OS Servers and OpenPCS 7 in PCS 7

Connecting a third-party OPC Client (such as an external enterprise historian) to a SIMATIC PCS 7 WinCC OS Server requires resolving three core architectural dependencies: active runtime state, Microsoft DCOM security permissions, and licensing. The native WinCC OPC server (OPCServer.WinCC) only runs when WinCC Runtime is active. If the OPC server does not appear in remote network browse lists, engineers must configure DCOM permissions (dcomcnfg) for OPCEnum and WinCC, match Windows user credentials across workgroups or domains, and add the user to the SIMATIC HMI group. For decoupled, redundant third-party access without running WinCC runtime locally, Siemens provides the dedicated OpenPCS 7 station.

Executive Summary

In industrial manufacturing facilities, integrating real-time process data into enterprise historians (such as OSIsoft PI, AspenTech IP.21, or Canary Labs) or manufacturing execution systems (MES) frequently relies on classic OPC Data Access (OPC DA), Historical Data Access (OPC HDA), and Alarms & Events (OPC A&E). In a SIMATIC PCS 7 multi-client architecture featuring redundant OS Servers, commissioning engineers frequently struggle to establish remote OPC connections from third-party client stations. Symptoms include OPCServer.WinCC missing from network browsing dialogs, access denied faults during DCOM connection establishment, or failure to browse tag hierarchies. This technical article explains the communication mechanics of OPCServer.WinCC, provides definitive DCOM configuration steps, and introduces the OpenPCS 7 station for enterprise data decoupling.

WinCC OPC Architecture: Native OPC Server vs OpenPCS 7 Station

Siemens provides two distinct mechanisms for third-party OPC data access in PCS 7:

Native WinCC OPC Server (OPCServer.WinCC):
* Integrated directly into WinCC OS Servers and Single Stations.
* Provides OPC DA 2.05a / 3.0, OPC HDA 1.20, and OPC A&E 1.10 interfaces.
* Operational Dependency: The OPC server process is instantiated as an in-process / out-of-process COM server only when WinCC Runtime is actively running on the host OS Server. If runtime is deactivated, the OPC server shuts down.
OpenPCS 7 Station (Formerly SPOSA - Single Point of System Access):
* A dedicated PC station running OpenPCS 7 software acting as an independent communication gateway.
* Collects data from redundant OS Server pairs and automation stations, providing a single consolidated OPC endpoint.
* Automated Redundancy Handling: Automatically manages master/standby failover transparently to the third-party client.
* Does not require running the WinCC graphic runtime interface.

Prerequisites: WinCC Runtime Execution and OPCServer.WinCC State

A foundational operating requirement is that OPCServer.WinCC cannot be queried as a dormant service:

In Windows Services or local COM registries, OPCServer.WinCC requires the WinCC DataManager (CCDataMgr.exe) and project database to be active.
If a third-party client attempts to browse or connect while WinCC Runtime is stopped, connection attempts return Server Not Found or Class Not Registered.
The OS Server project must have the OPC Server option active in WinCC project properties.

DCOM Security Configuration for Remote OPC DA Clients

Classic OPC DA relies on Microsoft Distributed COM (DCOM), which requires strict security alignment:

OPCEnum Configuration: The OPCEnum service allows remote clients to query the server's COM registry to discover available OPC servers. In dcomcnfg, OPCEnum must have its Launch and Activation permissions configured to allow remote access.
OPCServer.WinCC DCOM Properties:
* Authentication Level: Must be set to Connect (or Default).
* Impersonation Level: Must be set to Identify.
* Access Permissions: Must grant Remote Access to the user account executing the OPC client software.
* Launch and Activation Permissions: Must grant Remote Launch and Remote Activation to the client user account.

Network Authentication: Workgroups, Active Directory Domains, and SIMATIC HMI

DCOM requires mutual Windows security authentication between the client computer and the OS Server:

Domain Environments (Recommended): Both the OS Server and the OPC Client PC belong to the same Windows Active Directory domain. The domain user account running the OPC client service is added to the local SIMATIC HMI group on the OS Server.
Workgroup Environments: Both computers belong to the same workgroup. An identical Windows user account (exact same username and exact same password) must be created on both the OPC client PC and the OS Server, and added to the SIMATIC HMI group on the server.
Windows Firewall: Port 135 (DCOM RPC Endpoint Mapper) and dynamic RPC ports must be opened, or configured via SIMATIC Security Control.

Step-by-Step Configuration Workflow for Remote OPC Connectivity

To establish a verified third-party OPC connection to a PCS 7 OS Server:

Verify WinCC Runtime Status: Confirm WinCC Runtime is active and healthy on the OS Server.
Add Client Account to SIMATIC HMI Group:
* On the OS Server, open Computer Management -> Local Users and Groups -> Groups.
* Open SIMATIC HMI and add the domain user or matching local user.
Run SIMATIC Security Control: On both stations, execute SIMATIC Security Control to ensure necessary DCOM and firewall exceptions are applied.
Configure DCOM Settings (dcomcnfg):
* Open dcomcnfg.exe on the OS Server.
* Navigate to Component Services -> Computers -> My Computer -> DCOM Config.
* Locate OPCEnum and OPCServer.WinCC.
* In Properties -> Security, customize Launch and Access permissions to grant SIMATIC HMI full Local/Remote permissions.
Test Local Connection: On the OS Server, run a local OPC test client (e.g. Siemens OPC Scout). Confirm tags browse and update.
Connect Remote Client: On the third-party PC, point the OPC Client to the OS Server IP/hostname and select OPCServer.WinCC.

Third-Party OPC Integration Architecture Comparison Matrix

The following table compares direct OS Server OPC access against the OpenPCS 7 architecture:

| Parameter / Feature | Direct Connection to OS Server (OPCServer.WinCC) | Dedicated OpenPCS 7 Station | Modern OPC UA Gateway (V9+) |
|---|---|---|---|---|
| Primary Protocol | Classic OPC DA / HDA (DCOM) | Classic OPC DA / HDA / A&E | OPC Unified Architecture (TCP/IP) |
| WinCC Runtime Dependency | Mandatory on target server | Independent of local runtime | Built-in OPC UA Server service |
| Redundancy Management | Manual client-side switching | Automated transparent failover | Supported via redundant UA endpoints |
| OS Server CPU Load Impact | Moderate (Direct client queries) | Minimal (Buffered by OpenPCS 7) | Minimal (High-speed binary encoding) |
| Licensing Requirement | Included with WinCC RT license | OpenPCS 7 license required | OpenPCS 7 or WinCC UA license |
| Recommended Scenario | Single small historian client | Enterprise multi-client Historian/MES | Modern cross-network cloud gateways |

Verification

To verify robust remote OPC data exchange:

Remote OPC Browse Test: On the third-party client PC, launch an OPC test client (e.g. OPC Scout or Matrikon OPC Explorer). Confirm that OPCServer.WinCC appears in the server catalog.
Tag Hierarchy Navigation: Connect to the server. Confirm that the WinCC tag structure (Plant Hierarchy folders, @Area, and technological block tags) is browsable.
Active Value Polling: Add a group of analog tags (e.g. MonAnL.PV_Out#Value). Confirm that quality codes indicate 192 (Good) and timestamp updates cyclically without communication timeouts.

Redundancy Management and Automated Failover via OpenPCS 7

When connecting to redundant OS Server pairs:

Directly connecting an OPC DA client to Master Server A means that if Server A fails or restarts, the third-party client loses communication unless the third-party client implements custom dual-server failover logic.
OpenPCS 7 Solution: The OpenPCS 7 station continuously monitors both Server A and Server B. If the active server fails, OpenPCS 7 switches its internal data provider to the partner server without disconnecting the third-party OPC client, ensuring zero historical data loss.

Limitations and Operational Precautions

Never disable Windows Firewall or assign Everyone with full DCOM permissions to bypass authentication errors. Exposing industrial DCOM ports across corporate networks creates severe cybersecurity vulnerabilities.

When procuring OpenPCS 7 software, client access licenses, or enterprise historian interfaces, all licensing packages and MLFBs must be validated against official Siemens catalogs and confirmed through an authorized Siemens distributor quotation.

Engineer FAQ

Can a third-party OPC client connect to WinCC when runtime is stopped?

No. OPCServer.WinCC is an active runtime component; if WinCC runtime is not running, the server is unreachable.

What Windows user group is mandatory for OPC access?

The connecting Windows user account must be a member of the local 'SIMATIC HMI' user group on the WinCC OS Server.

Why does OPCEnum fail to list servers remotely?

OPCEnum requires specific DCOM Launch and Access permissions in dcomcnfg; if remote access is unassigned, browsing fails.

Does OpenPCS 7 require a dedicated physical computer?

OpenPCS 7 can run on a dedicated physical PC, an OS Client station, or a certified virtual machine connected to the Terminal Bus.

Configuring Third-Party OPC Client Connections to Redundant WinCC OS Servers and OpenPCS 7 in PCS 7