How to Resolve WinCC OPC DA 'Bad, No Communication' Errors After Migrating to PCS 7 V8.1

To resolve the issue where WinCC OPC DA Client tags report 'Bad, no communication' (16#00) in Runtime after migrating to SIMATIC PCS 7 V8.1—even though OPC Scout browses and reads tags successfully—engineers must reconfigure DCOM asynchronous callback permissions and Windows Firewall RPC ports. In OPC DA Classic, browsing and initial reading use synchronous calls, but runtime tag subscriptions rely on asynchronous callbacks (IOPCDataCallback) where the external OPC Server initiates inbound network connections to WinCC. The resolution requires running the Siemens Security Controller to repair DCOM access/launch ACLs, configuring Windows Firewall to permit incoming RPC traffic from the external server, ensuring the SIMATIC HMI group has DCOM remote activation rights, and verifying consistent 32-bit/64-bit DCOM proxy registrations.

The Asynchronous Callback Architecture in OPC DA Classic

OPC Data Access (OPC DA V2.05a / V3.0) is built directly upon Microsoft Component Object Model (COM) and Distributed COM (DCOM).

The operational communication pipeline between WinCC (OPC Client) and a third-party controller (OPC Server) involves two separate network conversations:
1. Outbound Channel (Client -> Server): WinCC initiates an RPC call to the remote OPC Server to browse items, define tag groups, and perform synchronous reads (IOPCServer, IOPCItemMgt).
2. Inbound Callback Channel (Server -> Client): To deliver efficient, exception-based data updates without continuous polling, the remote OPC Server establishes a connection back into the WinCC computer via the IOPCDataCallback COM interface.

If the inbound callback is blocked by network firewalls, hardened Windows security policies, or missing DCOM access control lists (ACLs), the client establishes the initial connection but runtime tags immediately transition to 'Bad, no communication'.

Why OPC Scout Succeeds While WinCC Runtime Fails

A frequent diagnostic dilemma during PCS 7 migrations is observing that diagnostic utilities (like Siemens OPC Scout or Matrikon OPC Explorer) display live data, while WinCC Runtime tags flatline with bad quality:

OPC Scout Behavior: By default, OPC Scout often utilizes synchronous polling (IOPCSyncIO::Read). Synchronous calls travel exclusively along the outbound client-to-server connection and do not require the server to initiate an asynchronous reverse callback.
WinCC Runtime Behavior: WinCC is optimized for high-performance process visualization and strictly utilizes asynchronous group advice loops (IOPCAsyncIO2 with IConnectionPoint). If DCOM blocks the reverse callback path, WinCC's advise loop times out, flagging the tags as uncommunicative.

Configuring DCOM Security via Component Services (dcomcnfg)

In PCS 7 V8.1 (running on Windows 7 SP1 or Windows Server 2008 R2 / 2012), Microsoft introduced stricter DCOM default policies that break legacy cross-machine callbacks:

Open dcomcnfg (Component Services).
Expand Component Services -> Computers -> My Computer.
Right-click My Computer -> Properties:
* Under Default Properties: Ensure 'Enable Distributed COM on this computer' is checked, and Default Impersonation Level is set to Identify.
* Under COM Security -> Access Permissions -> Edit Limits:
- Grant Local Access and Remote Access to ANONYMOUS LOGON, Everyone, Interactive, SYSTEM, and the local SIMATIC HMI group.
- Under Launch and Activation Permissions -> Edit Limits:
- Grant Local Launch, Remote Launch, Local Activation, and Remote Activation to Everyone, Administrators, and SIMATIC HMI.

Step-by-Step Resolution: Security Controller and Firewall Exceptions

Follow this engineering sequence to restore bidirectional OPC communication:

Step 1: Run Siemens Security Controller

On both the WinCC OS Server and the remote OPC Server machine, open:
Start -> All Programs -> Siemens Automation -> Security Controller.
Click Repeat Settings.
This restores all default Siemens DCOM rules, user group permissions, and local firewall exceptions.

Step 2: Configure Windows Defender Firewall Inbound Rules

In Windows Firewall with Advanced Security, create an Inbound Rule:
* Rule Type: Program.
* Program Path: C:\Program Files (x86)\Siemens\WinCCin\CCDataServer.exe and CCProjectMgr.exe.
* Action: Allow the connection.
Create an inbound port rule for TCP Port 135 (RPC Endpoint Mapper) and the configured dynamic RPC port range (e.g., ports 49152–65535).

Step 3: Recreate OPC Connection in WinCC Tag Management

In WinCC Explorer, open Tag Management.
Right-click the OPC channel unit -> System Parameters.
Verify that the connection points to the correct remote machine name.
Open the OPC Item Manager, re-browse the external server, and re-import tags to refresh COM CLSID registry keys.
Activate Runtime and verify tag quality.

OPC DA Diagnostic State and Verification Reference Matrix

The following table outlines the diagnostic states, underlying causes, and corrective actions for OPC DA integration:

Observed Quality CodeDiagnostic Tool ResultUnderlying DefectCorrective Action16#00 (Bad, No Comm)OPC Scout shows GoodReverse DCOM callback blockedGrant Remote Access to ANONYMOUS LOGON in dcomcnfg16#18 (Bad, Config Error)Item Manager browse failsTarget OPC Server service stoppedStart service on remote machine; check user rights16#1C (Bad, Out of Service)Item Manager shows tagsCLSID registry corruptionDelete and recreate connection in WinCC Tag ManagementTag items invisible in browseFirewall blocking Port 135RPC endpoint mapping rejectedOpen TCP Port 135 on remote OPC server16#80 (Good)WinCC Runtime updatesFull bidirectional handshake OKNormal operation

Ensuring proper bidirectional RPC communication guarantees stable third-party subsystem data flow.

Verification

To verify that the OPC DA connection is fully functional:
1. In WinCC Explorer, open WinCC Channel Diagnosis.
2. Select the OPC channel unit; verify that the connection status indicates 'Connected / OK'.
3. Open a WinCC process picture containing the imported OPC tags.
4. Verify that the quality code displays 'Good' (16#80) with zero connection warnings.
5. In Windows Event Viewer -> System and Application logs, confirm that zero DCOM Error 10016 entries are recorded.

Limitations and Operational Precautions

OPC DA Classic relies on DCOM, which is inherently vulnerable to network latency and firewall restrictions; consider migrating to modern OPC UA for robust security.
Granting Remote Access to ANONYMOUS LOGON must be restricted to isolated plant control networks protected by industrial perimeter firewalls.
Both participating computers must use identical local administrative user accounts and passwords if operating in a workgroup environment without Active Directory.
Always validate final license quantities, module availability, and MLFBs against the applicable Siemens catalog and authorized distributor quotation.

Engineer FAQ

Why did the OPC connection work in PCS 7 V7.0 but break after upgrading to V8.1?

PCS 7 V7.0 operated on Windows Server 2003 / Windows XP, which had permissive default DCOM policies. PCS 7 V8.1 operates on Windows 7 / Server 2008 R2, where Microsoft enforced strict DCOM authentication filtering.

Can I convert the legacy OPC DA connection to OPC UA in WinCC V8.1?

Yes. WinCC V8.1 includes an OPC UA Client channel. If the third-party system supports OPC UA, migrating eliminates all DCOM configuration complexity and operates cleanly over a single TCP port.

What does DCOM Error 10016 in the Windows Event Viewer indicate?

Error 10016 indicates that an application was denied Local or Remote Activation permissions for a specific COM CLSID. The event log provides the exact GUID that must be granted rights in dcomcnfg.