Resolving S7-1500 OPC UA Client Error 0x8012_0000 in TIA V16

Problem Overview

When commissioning an S7-1500 CPU as an OPC UA Client in TIA Portal V16 Update 4, the instruction block (SFB "OPC_UA_Connect") may complete with BUSY = 0 and ERROR = 1, refusing to establish the secure channel to the target server even though tag import succeeds in the editor. The CPU returns the following diagnostic triple on the connection instance DB:

• OPCUA_Status = 16#8601 — generic "Error during connect" wrapper reported by the FB layer.
• OPCUA_Diag_Status = 16#8601 — identical wrapper, propagated from the lower stack.
• OPCUA_Diag_Subfunction_Status = 16#8012_0000 — the actual root-cause status code from the OPC UA stack.

On its own, the manual only documents the outer 16#8601 code. Decoding the subfunction code is the key to a real fix: 16#8012_0000 maps to OPC UA standard status code BadCertificateInvalid (numeric value 0x80120000), meaning the certificate the client has been asked to trust is rejected by the runtime as malformed, expired, not yet valid, or self-signed without an installed trust anchor.

Affected Hardware and Software

Error Code Decoding

The OPC UA status triple is hierarchical. Always read the subfunction status first; the outer two words are usually just the wrapper from the FB layer.

The high word 0x8012 identifies the OPC UA communication segment, while the low word 0x0000 is the symbolic index. The 0x8012_xxxx namespace is reserved by the OPC UA specification and is implemented verbatim in the SIMATIC OPC UA stack. A complete decoder is part of every OPC UA client DB instance as a comment block; the relevant OPC UA Part 4 status codes most often seen on a 1516F client are listed in the next section.

Common OPC UA Subfunction Codes

Root Cause Analysis

During tag import, the TIA Portal editor uses the developer's local Windows certificate store and accepts the server certificate transiently. At runtime, the CPU holds its own certificate store in the project file system under System Memory > OPC UA, and the runtime OPC UA stack validates the server's certificate against the trust list in Global security settings > Certificate manager of the CPU. The 0x80120000 response means one of the following is true:

1. The server certificate has not been installed into the CPU's trusted certificate store before download.
2. The certificate was installed but the project was recompiled and downloaded without re-including the certificate folder, wiping the runtime trust list.
3. The server certificate's validity window has expired or is not yet valid (clock drift between the engineering station and the PLC, or the server has been recertified).
4. The server certificate uses an unsupported signature algorithm (e.g., MD5 or SHA-1) rejected by the OPC UA stack on the S7-1500.
5. The client identity certificate (instance certificate of the OPC UA client on the 1516F) is missing or self-signed, so the server cannot verify the client's application URI during the OpenSecureChannel call.

Prerequisites

• TIA Portal V16 Update 4 or later installed with the S7-1500 support package.
• CPU 1516F-3 PN/DP online connection via PN/IE.
• OPC UA server project with at least one exported DER (binary) certificate file, .der, for the server.
• PLC has an OPC UA client runtime license available (CPU 1516F carries OPC UA client capability as standard from firmware V2.8 onward; verify under CPU properties → OPC UA → Runtime licenses).

Solution: Install and Trust the Server Certificate

The fix is to install the server certificate into the CPU's Trusted Certificates and Root Certification Authorities store and, if mutual TLS is configured, install the client's instance certificate on the server side. The procedure is fully aligned with the official Siemens OPC UA programming guide referenced in the support FAQ 109762770.

Step-by-step certificate trust configuration

1. Open the S7-1500 project in TIA Portal V16 Update 4 and select the CPU in the project tree.
2. Navigate to Properties → Protection & Security → Certificate manager.
3. Switch the view to Trusted certificates and root certification authorities.
4. Click Add and browse to the server certificate file (DER format, .der, exported from the OPC UA server project). The certificate will appear with issuer, subject, validity dates, and fingerprint.
5. Confirm with OK. The certificate is now associated with the offline project.
6. Compile the project (Hardware) and download to the CPU. TIA Portal will also push the trusted certificate to the runtime certificate store during download.
7. If the CPU was already online and certificates were installed previously, force a Certificate manager → Update on the target system operation via Online → Certificate manager → Update.

Step-by-step client instance certificate configuration

1. Open Properties → Protection & Security → Certificate manager → Device certificates.
2. Generate a new client certificate (or import an existing PKI-issued one). Set Application URI to the value referenced in the OPC UA client's connect FB parameter — this URI must match the server's expectation for mutual TLS.
3. Export the client certificate in DER format and install it in the Trusted store of the OPC UA server project.
4. Recompile and download the CPU project.

OPC UA Client FB Wiring

The certificate work must be paired with a correct FB call. The minimum sequence in the S7-1500 user program (SCL) is shown below. The connect FB returns busy=0, error=0 when the secure channel is established and the session is open.

// OPC_UA_Connect instance: "dbOpcUaClient"
#dbOpcUaClient(REQ        := TRUE,
               Connection := "OpcUa_Conn_1",
               URI        := 'opc.tcp://192.168.0.20:4840',
               Timeout    := T#5s);

IF #dbOpcUaClient.BUSY = 0 AND #dbOpcUaClient.ERROR = 0 THEN
    // Trigger namespace index resolution
    #dbGetIndex(REQ := TRUE, Connection := "OpcUa_Conn_1");
    // Trigger cyclic read of imported tag list
    #dbReadList(REQ := TRUE, Connection := "OpcUa_Conn_1");
END_IF;

IF #dbOpcUaClient.ERROR = 1 THEN
    // Decoded on the HMI as alarm text
    #sStatusCode  := UINT_TO_STRING(#dbOpcUaClient.OPERATING_STATE);
    #sDiagCode    := UINT_TO_STRING(#dbOpcUaClient.DIAG_STATUS);
    #sSubCode     := DWORD_TO_HEX_STRING(#dbOpcUaClient.DIAG_SUBFUNCTION_STATUS);
END_IF;

Verification

1. After the certificate is installed and the project is downloaded, set the connect FB REQ in the user program (or via the watch table forcing dbOpcUaClient.REQ := TRUE).
2. Observe the instance DB outputs:
   • BUSY = 0, ERROR = 0, STATUS = 16#0000 — successful connection.
   • BUSY = 0, ERROR = 0, STATUS = 16#0000 with the next call to OPC_UA_ReadList returning data — session is fully usable.
3. Read OPCUA_Diag_Subfunction_Status after the call. It must be 16#00000000 (Good) or, for an unsuccessful call, a different code from 16#8012_0000.
4. Check the CPU diagnostic buffer for entries under OPC UA. A successful connect is logged with event ID Connection established (secure channel + session).
5. Use an external OPC UA client (e.g., UA Expert) to validate the same server endpoint independently. This separates server-side issues (cert problem on the server) from client-side issues (cert trust on the 1516F).

Connection State Machine

The OPC UA client state machine on the S7-1500 is a strict subset of the OPC UA Part 4 secure channel lifecycle. The diagram below summarizes the transitions and the most common failure points.

Troubleshooting Matrix

Related Configuration: S7-1200 as OPC UA Server

If the 1516F is connecting to an S7-1200 server, the same certificate workflow applies. The reference document S7-1200 OPC UA Server Documentation (PDF) describes how the server cert is generated and exported. Configuration of the S7-1500 as an OPC UA server (rather than client) requires TIA Portal V16 or higher, S7-1500 CPU firmware ≥ V2.8, and CP 1543-1 firmware ≥ V2.2 when the CP is used as the OPC UA endpoint. The same certificate trust chain concept applies symmetrically.