Resolving OPC UA Client Connection Errors to SINUMERIK 840D PLC

Problem Details: OPC UA Client Fails to Connect to SINUMERIK 840D

Engineers integrating OPC UA clients with a Siemens SINUMERIK 840D sl / SINUMERIK ONE controller frequently encounter a connection rejection from the controller's embedded OPC UA server. The client application — whether it is a TIA Portal HMI, a SCADA node such as Ignition, an in-house SDK, or a generic client such as UaExpert — reports one of the following symptoms at runtime:

• BadConnectionClosed or BadServerHalted after the TCP three-way handshake completes.
• BadIdentityTokenRejected when the client opens a session with Anonymous identity.
• BadUserAccessDenied on the first ServiceRequest following CreateSession.
• The client never even reaches CreateSession; discovery (FindServers / GetEndpoints) returns no endpoints or returns only endpoints that the client considers insecure.

The pattern is consistent across SINUMERIK 840D sl firmware versions ≥ 4.95, SINUMERIK ONE (≥ 6.13), and SINUMERIK 828D (≥ 4.95) when the runtime configuration shipped by Siemens is not modified by the user. This article documents the four classes of root cause, the diagnostic procedure to isolate each one, and the verified remediation steps that do not require opening a Siemens support ticket.

Architecture: OPC UA Server inside SINUMERIK

The SINUMERIK OPC UA server runs as a Linux service on the NCU (Numerical Control Unit) or PCU/IPC for SINUMERIK ONE. It exposes the controller's NCK, PLC, and drive variables as a typed address space that conforms to the OPC UA Companion Specification for CNC. The server is bound to TCP port 4840 by default and listens on all configured Ethernet interfaces of the X120/X130/X127 ports on the NCU.

The configuration is read on NCU power-up; changes to port, security policy, or user accounts require a NCU reboot. Note that SINUMERIK Operate exposes only a subset of the OPC UA server's settings — for full control, edit /user/sinumerik/opcua/opal_config.xml on the CF card and reboot the NCU.

Root Cause #1: Anonymous Authentication Disabled by Default

Beginning with SINUMERIK 840D sl V4.95 SP3 (released for HF7 and later) and all V6.x firmware, Siemens ships the OPC UA server with Anonymous identity token disabled. A client that opens an endpoint and presents only an Anonymous token receives BadIdentityTokenRejected (status code 0x80210000) immediately after ActivateSession.

This is the most common cause of the failure observed in the field, especially when porting applications from earlier SINUMERIK firmware or from generic S7-1500 OPC UA samples that did not require credentials.

Diagnostic steps

1. Confirm the SINUMERIK firmware version from the HMI: Commissioning → NC → NCK version. Record the full string, e.g. 04.95.07.00.
2. Open a Wireshark capture on the client machine and apply the filter opcua.
3. Trigger a connect from the client and locate the ActivateSessionRequest frame.
4. Expand OPC UA Security Header → User Identity Token → Policy Id. If it reads anonymous the client is the source of the problem.
5. Compare with a known-good client (e.g. UaExpert); the Policy Id there will read username or certificate.

Remediation

Either re-enable Anonymous on the SINUMERIK side (not recommended for production) or — preferably — configure the client to use Username/Password. On TIA Portal as an OPC UA client (TIA V17 and later):

1. Project tree → Devices & networks → OPC UA communication.
2. Select the configured OPC UA connection → Properties → Connection → Security → User identity.
3. Set Token type to User name and enter the credentials of an OPC UA user defined on the NCU.
4. Compile and download the PLC project.

For an SDK-based client the equivalent call is documented in the OPC UA specification part 4: UaClient.setUserIdentity(userName, password) must be invoked before activateSession(). The credential must match an account defined in Display Manager → OPC UA → User Management, not an HMI or PLC password.

Root Cause #2: Endpoint Discovery Returns Wrong URLs

Clients that use FindServers followed by GetEndpoints rely on the URLs that the server publishes. On a SINUMERIK NCU those URLs are constructed from the hostname at server start. If the NCU's hostname resolves to a virtual interface, an APIPA address, or an internal IPv6 link-local address, the client receives endpoints it cannot route to.

Remediation

1. On the NCU, log in via Display Manager and execute sc → netcfg → show. Confirm that X120 has the expected IPv4 address.
2. Edit /user/sinumerik/opcua/opal_config.xml and set the <Hostname> element to the FQDN that the client network resolves correctly.
3. Restart the OPC UA service: sc → opcua restart. A full NCU reboot is required for the change to persist across power cycles.
4. As a workaround in the client, hard-code the endpoint URL using the actual X120 IPv4 address and skip discovery. This is acceptable for point-to-point cell integrations but should be replaced by DNS-based discovery on larger plants.

Root Cause #3: Security Policy Mismatch

The SINUMERIK OPC UA server negotiates one of three security policies: None, Basic128Rsa15, or Basic256Sha256. Basic128Rsa15 is deprecated per OPC UA Specification Part 7 and is disabled by default on firmware ≥ 6.13. A client that insists on Basic128Rsa15 (for example, an older UaExpert profile) will fail to OpenSecureChannel with status BadSecurityChecksFailed (0x80120000).

Modern TIA Portal versions (V17, V18, V19) acting as OPC UA clients default to None for plain LAN segments and to Basic256Sha256 with the TIA Portal's own certificate when the user selects "Secure". If the client cannot present a certificate that the NCU's trusted-client list recognizes, the server responds with BadCertificateUntrusted (0x801A0000) during OpenSecureChannel.

Remediation — step-by-step certificate trust

1. Export the client's OPC UA application certificate (DER, .der) from the client configuration. In TIA Portal this is Options → Security settings → Certificates.
2. Transfer the file to a USB stick and insert it into the NCU's front USB port.
3. In SINUMERIK Operate: Commissioning → Network → OPC UA → Certificates → Import client certificate.
4. Reboot the NCU. The certificate is moved into /var/siemens/opcua/pki/trusted/ on power-up.
5. From the client side, accept the NCU's server certificate. The NCU's self-signed certificate is found at Commissioning → Diagnostics → OPC UA → Server certificate; export and import into the client trust list.

Root Cause #4: Service-Level Access Rights

This is the failure mode described in the original symptom — the client authenticates successfully with Username/Password, ActivateSession returns OK, and yet the very first read or browse returns BadUserAccessDenied (0x801F0000) or BadNotReadable (0x80140000).

On the SINUMERIK OPC UA server, user accounts are mapped to roles. Each role grants read/write access to a subset of the address space:

If the client uses a Username/Password pair that authenticates against an Operator account, any read on a writeable tag (or a write on a read-only tag) returns BadUserAccessDenied. This is by design and is independent of the OPC UA stack itself.

Diagnostic

1. Capture a session in Wireshark and identify the first ReadRequest after ActivateSessionResponse.
2. Note the NodeId in the request, for example ns=3;s=Channel/MachineAxis/ActPos.
3. On the NCU, run sc → opcua → acl who → user name. The output lists the roles assigned to that user.
4. Compare with the role table above. If the role does not include the requested path, the rejection is expected.

Remediation

1. Open Display Manager → OPC UA → User Management.
2. Edit the user account and assign the appropriate role. For OEM integrations, prefer a dedicated Integrator account over reusing an existing Operator account.
3. Optionally restrict the role's address-space scope to a specific sub-tree using the Access control list editor. This is the recommended approach for multi-cell plants where different OEMs must see only their machine axis data.

Diagnostic Procedure: Wireshark Capture and Decode

Wireshark (≥ 3.6, which added OPC UA Binary protocol dissection) is the single most useful tool for isolating any of the four root causes above. The full procedure:

1. Install Wireshark ≥ 3.6 on the client machine. Confirm the opcua dissector is present: Help → About → Plugins.
2. Start a capture on the interface facing the NCU. Use a capture filter host <NCU-IP> and port 4840 to reduce noise.
3. Trigger the connect from the client.
4. Stop the capture after the first failure appears in the client log.
5. Apply display filter opcua and inspect the conversation:

Wireshark's Decode As feature lets you force dissection if the port is non-standard: Decode As → OPC UA Binary on TCP port 4840.

Common OPC UA Status Codes Mapped to SINUMERIK

The status codes returned by the SINUMERIK OPC UA server follow the OPC UA Part 4 standard. The codes most frequently seen during connection setup are:

Procedure: Configuring the TIA Portal OPC UA Client to a SINUMERIK Server

For engineers using TIA Portal V17, V18, or V19 as the OPC UA client (a common configuration when a S7-1500 or S7-1500H PLC must consume CNC data from a SINUMERIK controller), the following sequence reliably establishes a session.

Prerequisites

• TIA Portal V17 Update 9 or later (V19 Update 1+ recommended for stable SINUMERIK ONE connectivity).
• SINUMERIK 840D sl ≥ 4.95 SP3 or SINUMERIK ONE ≥ 6.13.
• NCU user account of role Integrator or higher created in Display Manager.
• Ethernet connectivity on X120; NCU reachable at ping <NCU-IP> from the engineering station.

Step-by-step

1. Open the TIA Portal project that owns the S7 PLC.
2. Project tree → Devices & networks → Network view → Connections.
3. From the catalog, drag OPC UA → OPC UA client into the connection table.
4. Right-click the connection → Properties → General. Set Server endpoint URL to opc.tcp://<NCU-IP>:4840.
5. Properties → Security:
   • Security policy: Basic256Sha256 (or None only on air-gapped commissioning networks).
   • Authentication mode: User name.
   • Enter the Username/Password created in Display Manager.
6. Compile the project. TIA Portal will warn if the certificate of the SINUMERIK server is not trusted; click Trust server certificate.
7. Download to the S7 PLC.
8. On the NCU side, accept the S7 PLC's client certificate (Display Manager → OPC UA → Trusted clients).
9. Reboot the NCU once; subsequent connections do not require a reboot.

Verification

1. In the S7 PLC's online diagnostics, open OPC UA client → Diagnostics → Connection status. The state should read Connected.
2. Open a watch table referencing the imported OPC UA tags. Values should update at the configured sampling interval (default 250 ms).
3. On the NCU, run sc → opcua → sessions. The output must list the S7 PLC's ApplicationUri with role Integrator.

Procedure: Connecting Ignition or Third-Party SCADA

SCADA platforms such as Ignition by Inductive Automation use the same OPC UA stack but expose the client configuration through a different UI. The mapping from a SINUMERIK server is:

1. In the Ignition gateway, Config → OPC UA → Servers → Create new OPC UA server connection.
2. Endpoint URL: opc.tcp://<NCU-IP>:4840.
3. Security policy: Basic256Sha256 → Sign and Encrypt.
4. Authentication: Username & Password.
5. Click Discover. The Ignition client requests GetEndpoints and populates the list.
6. Enable Accept server certificate on first connection.
7. Browse from Config → OPC UA → Servers → Tag browser. The CNC address space appears as a tree under /.

Procedure: Programmatic SDK Client (Java / .NET / C)

For an in-house SDK-based client, the canonical connect sequence must follow OPC UA Part 4 §5.6. The minimum code path that survives all four root causes is:

1. DiscoveryClient.getEndpoints(endpointUrl) — confirm the server is reachable and collect the list of supported policies.
2. Select the policy the client supports. If multiple are returned, prefer Basic256Sha256.
3. Load or generate the client application certificate. For an SDK client, this is done with the SDK's CertificateUtils class.
4. Call UaClient.setApplicationUri(...), UaClient.setApplicationName(...), and UaClient.setCertificate(...).
5. Call UaClient.setSecurityPolicy(policy) matching the chosen endpoint.
6. Call UaClient.setUserIdentity(userName, password). Do not call the overload that sets Anonymous unless the server explicitly accepts it.
7. UaClient.connect() — this internally issues OpenSecureChannel, CreateSession, and ActivateSession.
8. On success, UaClient.getSession().getSessionId() returns a valid NodeId. On failure, the SDK throws UaServiceResultException carrying one of the status codes listed above.

Failure on step 7 with BadUserAccessDenied on the very next Read call confirms root cause #4. The remediation is to either change the role assignment on the NCU side or to drop the read scope to the path the role allows.

Procedure: Verifying the Fix

After applying any of the remediations above, validate with the following checklist:

Troubleshooting Matrix

Map the failure mode to the root cause and the fix in one table:

Safety and Operational Notes

Reference: Official Siemens Documentation

Authoritative material on the OPC UA server embedded in SINUMERIK controllers is published in the following manuals, all available on the Siemens Industry Online Support portal:

• SINUMERIK 840D sl / SINUMERIK ONE OPC UA Server Programming Manual — describes the address space, role model, and the configuration file opal_config.xml.
• SINUMERIK Operate Commissioning Manual — section on OPC UA user management in Display Manager.
• TIA Portal Help → Configuring OPC UA — client configuration in V17, V18, V19.
• OPC UA Specification Parts 4 and 7 published by the OPC Foundation — normative status codes and security policies referenced throughout this article.