Resolving S7-1500 OPC UA Error 16#8601 in TIA Portal V16 (Project 109762770)

The Siemens application example 109762770_OPC_UA_PLCClient_16_PROJ_V1_1 ships a paired S7-1500 OPC UA Server and OPC UA Client configuration that demonstrates inter-PLC tag exchange over an OPC UA binary channel. When the project is downloaded unmodified and commissioned under TIA Portal V16 with PLCSIM Advanced, the OPC UA client block reports a transport-layer failure with the diagnostic signature:

• Status code: 16#8601
• Subfunction status: 16#803D_0000

This error terminates at the opcUaConnect instruction and prevents the client from establishing a session with the companion server PLC. The root cause is not in the protocol itself but in the firmware/runtime defaults, certificate handling, and endpoint URL embedded in the bundled project. The troubleshooting guide below consolidates the verified remediation paths and the architectural constraints imposed by the S7-1500 OPC UA stack.

Background: OPC UA on the SIMATIC S7-1500

OPC Unified Architecture (OPC UA) is the IEC 62541 cross-platform, service-oriented architecture that replaces the older OPC Classic (DA/HDA/AE) COM-based stack. It provides a single, secure, reliable transport for industrial data from sensor to cloud and is the recommended interoperability layer for S7-1500 controllers when communicating with third-party SCADA, MES, or cloud brokers. The OPC Foundation OPC UA landing page and the IEC 62541 specification reference describe the binary protocol, security profiles, and information modeling that the Siemens OPC UA server/client libraries implement.

For the S7-1500, Siemens provides two distinct OPC UA roles:

Problem Details: Error 16#8601 with SubfunctionStatus 16#803D_0000

When the SCL instruction opcUaConnect is forced to TRUE on the client PLC, the status outputs of the FB return:

status = 16#8601
subfunctionStatus = 16#803D_0000

According to the Siemens OPC UA client library documentation, the high word 16#86 indicates a connection-establishment error originating from the OPC UA client runtime. The subfunction status 16#803D_0000 corresponds to a transport-level or session-level rejection during the OpenSecureChannel / CreateSession handshake. Typical underlying causes include:

• Endpoint URL points to an IP address that is not reachable from the client PLC (wrong IP, wrong subnet, or wrong port).
• The server PLC has not yet published its endpoint (server still initializing, certificate not generated).
• The client certificate is missing, mismatched, or has been permanently associated with an endpoint (ClientID = 0 requirement on PLCSIM Advanced).
• Security policy mismatch (PLCSIM Advanced supports no security / None; the project example requires None).
• PLCSIM vs. PLCSIM Advanced: the project only operates against PLCSIM Advanced because PLCSIM does not provide the S7-1500 OPC UA server runtime.

Root Cause Analysis

Three independent defects exist in the V16 example project that converge on the 16#8601 status. Each is documented against the bundled data block and project settings.

Defect 1: Pre-populated Client Certificate in the V16 Project

The V16 archive contains a default OPC UA client certificate. Once this certificate is bound to the client configuration, the runtime cannot de-select it, and the trust chain with the server's trustedClients directory fails because the server's certificate store is empty. The V15.1 archive is delivered with an empty client certificate slot, which allows a fresh trust establishment on first run. The Siemens Application Example 109762770 download portal reflects this and offers separate V15.1 and V16 archives for that reason.

Defect 2: Hard-coded Endpoint URL in OpcUaClientInterface_Data

The instance DB OpcUaClientInterface_Data contains the connection parameter block Connection with the field ServerEndpointUrl. In the bundled project the start value is set to opc.tcp://10.11.22.113:4840, but the simulated server PLC is configured at 10.11.22.112. Because opcUaConnect consumes the literal string from the instance DB, the connect attempt is sent to the wrong IP and is rejected with a transport error.

Defect 3: PLCSIM Advanced Constraints

PLCSIM Advanced supports the S7-1500 OPC UA server runtime, but with two non-negotiable constraints:

1. Security policies must be set to None in both the server and client configuration. PLCSIM Advanced does not implement the cryptographic stack.
2. The ClientID on the client side must be set to 0 (anonymous), or the client will attempt to authenticate with a stored application instance certificate that PLCSIM Advanced cannot validate.

The subnet mask of the virtual PLCSIM Advanced network adapter must match the subnet declared in the project's PG/PC interface and PLC IP settings, or the simulated Ethernet layer will silently drop the OPC UA TCP frames to port 4840.

Solution: Step-by-Step Remediation

Apply the following sequence. Steps 1 and 2 are mandatory; steps 3-5 are verification and hardening.

Step 1: Use the V15.1 Archive (Recommended Path of Least Resistance)

1. Open the Siemens Support entry 109762770.
2. Download the V15.1 project archive, not the V16 archive.
3. Open the V15.1 archive in TIA Portal V15.1 (or upgrade it to V16 via Project > Upgrade).
4. Compile both the server and client stations and download to two PLCSIM Advanced instances.

The V15.1 archive ships without a default client certificate, so the trust handshake completes on first connect.

Step 2: Correct the ServerEndpointUrl

If you must use the V16 archive, edit the data block before download:

1. In the project tree, open OpcUaClientInterface_Data (or the equivalent instance DB on the client station).
2. Navigate to Connection.ServerEndpointUrl (string, WString).
3. Replace the start value with the actual IP of the server PLC, for example: opc.tcp://10.11.22.112:4840.
4. Recompile and download both stations.

Step 3: Configure Security Policy to None for PLCSIM Advanced

1. Select the server PLC, then Properties > OPC UA > Server > Security.
2. Uncheck Security policy None is the only allowed policy in PLCSIM Advanced, so uncheck all Basic128Rsa15, Basic256, Basic256Sha256 entries.
3. Select None as the only enabled security policy and confirm No application authentication is allowed.
4. Repeat on the client PLC under Properties > OPC UA > Client > Security.

Step 4: Set ClientID to 0 in the Instance DB

1. Open the client instance DB.
2. Set the Connection.ClientId (or analogous token) to 0 to force anonymous authentication.
3. Ensure the local opc.tcp stack is configured without a client certificate reference.

Step 5: Verify PLCSIM Advanced Network Settings

1. Open PLCSIM Advanced and create two virtual instances. The first PLC must occupy the IP declared in the ServerEndpointUrl.
2. Confirm that the virtual Ethernet adapter PLCSIM Advanced installs (typically a TAP or Npcap-based interface) has a subnet mask identical to the project, e.g. 255.255.255.0 for a 10.11.22.0/24 network.
3. From the host, run ping 10.11.22.112 and telnet 10.11.22.112 4840 to confirm L3 and L4 reachability before debugging the PLC program.

Verification Procedure

After applying the remediation, validate the connection with the following checks:

1. Watch table on the client: Force opcUaConnect = TRUE. Expect status = 16#0000 and subfunctionStatus = 16#0000_0000. The connect output should latch to TRUE.
2. Server diagnostics: Open the server PLC online > Diagnostics > OPC UA and confirm at least one active session in the session list.
3. Tag readback: Force opcUaRead for a known server tag (e.g. a tag in OPC_UA_Data_DB). The output buffer should populate within one cycle.
4. Third-party client test: Use an external OPC UA client (e.g. UA Expert) to subscribe to the server's namespace. If the third-party client can connect, the server is healthy and any remaining 16#8601 is on the client side.

Troubleshooting Matrix

Configuration Parameters Reference

The following data block fields govern OPC UA client connectivity and must be reviewed whenever a 16#8601 is observed.

Production Hardware Considerations

The constraints above apply to PLCSIM Advanced. Real S7-1500 CPUs lift the security restrictions and allow signed certificates, but introduce new ones:

• CPU firmware: V2.6 or later is required for the full security profile set; V2.9 or later is recommended for the latest OPC UA features.
• Global Discovery Server (GDS): For multi-server fleets, push certificates from a central GDS via the SIMATIC Automation Tool or the OPC UA GDS push mechanism.
• Firewall traversal: TCP 4840 must be open between client and server subnets. On segmented plant networks, configure NAT or a dedicated DMZ for OPC UA traffic.
• Namespace indexing: When you add or remove tags on the server, the namespace version increments. Clients should re-read the namespace rather than cache it across controller restarts.

Why V15.1 Works but V16 Fails (Project Internals)

The V15.1 archive was generated against a TIA Portal V15.1 toolchain that pre-dates changes to the OPC UA client certificate handling in V16. In V16, the OPC UA configuration UI began persisting a self-signed client certificate at project creation time as a convenience, which inadvertently hard-binds the client identity to a certificate that the server trust store has never seen. The V15.1 archive leaves this field empty so the first opcUaConnect generates a fresh certificate and the trust exchange completes. The Siemens Support team has not republished a V16 archive with the defect patched, so the official workaround is to use V15.1 or to manually re-issue the client certificate against the server trust list.

Diagnostic Logging on the Server

For deeper investigation beyond the 16#8601 status, enable the OPC UA server's diagnostic trace:

1. Online > Diagnostics > OPC UA > Trace
2. Set the trace level to Verbose and the output to File.
3. Reproduce the failed opcUaConnect.
4. Download the trace and search for Bad_CommunicationError or Bad_SecurityChecksFailed.

A Bad_CommunicationError with no preceding OpenSecureChannel entry typically indicates a TCP-level failure (wrong IP, wrong port, blocked firewall). A Bad_SecurityChecksFailed after a successful OpenSecureChannel indicates a certificate or trust problem.

Frequently Asked Questions