Resolving WinCC Runtime OPC UA Client Errors to Siemens TCSB v3

Problem Overview

When configuring Siemens WinCC Runtime Advanced as an OPC UA client against a SIMATIC TCSB v3 (TeleControl Server Basic) OPC UA server, the HMI tag configured for the OPC UA connection state - or any other process value - displays the placeholder string ### instead of the actual value. Runtime logging shows no explicit error code, the OPC UA connection state indicator in the runtime appears nominal, and third-party OPC UA clients (such as UA Expert) on the same engineering workstation read the same tags without issue. OPC Classic DA browsing from the same WinCC Runtime Advanced works normally, indicating the runtime itself is functional and that the failure is isolated to the OPC UA channel path between WinCC and TCSB.

This defect has two independent root causes that frequently appear together and that must both be cleared before the tag updates:

1. An OPC UA NodeId address typed with incorrect case in the WinCC tag configuration. OPC UA is a strictly case-sensitive protocol; the browse tree shown by WinCC or by external OPC UA clients can mislead the engineer because browse names often appear in mixed case while the formal NodeId string requires canonical capitalisation.
2. An untrusted server certificate in the WinCC Runtime OPC UA PKI store. Even when the OPC UA endpoint is configured with Security = None, WinCC Runtime still performs a certificate trust check before exchanging application URIs, and an unknown server certificate results in the tag being silently dropped from subscription.

Affected Environment and Components

TCSB exposes its data on TCP port 4852 by default. The discovery URL syntax opc.tcp://<hostname>:4852 is the canonical endpoint advertised by the TCSB OPC UA server. The hostname - not the IP address - must be used in the discovery URL and in subsequent address components because OPC UA uses the hostname as the application URI basis for certificate matching. If the certificate is issued for CN=TCSBHost but the runtime connects to 10.0.0.5, the application URI mismatch will also trigger a rejection even after the certificate is moved to certs\.

Root Cause #1: OPC UA NodeIds Are Case-Sensitive

OPC UA identifies nodes by NodeId, and the string-form NodeId follows the structure ns=<namespace-index>;s=<identifier> for string identifiers. The browse view in WinCC and in third-party clients surfaces the address using the browse name (for example connectionstate), but the underlying identifier that the server accepts is the canonical capitalised form. Browsing a node and copy-pasting the path verbatim therefore often produces an identifier that the server cannot resolve, and the runtime renders the resulting Bad_NodeIdUnknown status as ###.

The original (failing) connection-state NodeId pasted from the WinCC browse dialog:

ns=TCS;s=tcs:[projectname.stationname.101]connectionstate

The same NodeId in the canonical form accepted by TCSB:

ns=TCS;s=TCS:[projectname.stationname.101]ConnectionState

Specifically the corrections are:

• The namespace prefix TCS must be uppercase; tcs is rejected.
• The instance identifier ConnectionState uses PascalCase (C and S capitalised).
• The project name and station name within the square brackets are case-sensitive: [ProjectA.StationB.101] and [projecta.stationb.101] resolve to different nodes, and an unknown node name typically returns Bad_NodeIdUnknown which WinCC then renders as ###.
• For data block references the block name must be uppercase, e.g. DB1, not db1.
• Process value type qualifiers are also case-sensitive and must use uppercase identifiers (for example :BOOL rather than :bool).
• The numeric station suffix .101 is not case-sensitive in itself but must match the TCSB station number exactly; if the station is configured with suffix .102, .101 returns Bad_NodeIdUnknown.

Root Cause #2: Untrusted Server Certificate in the WinCC Trust Store

WinCC Runtime Advanced performs a server-certificate trust evaluation before it allows the OPC UA session to subscribe to tags. This evaluation runs even when the endpoint is configured with SecurityPolicy = None, because the trust evaluation is part of the OPC UA application-layer authentication step, not of the transport encryption step. When the TCSB server certificate is not yet in the WinCC trust store, the runtime places the certificate in the rejected folder rather than accepting it. The OPC UA session is then closed at the OpenSecureChannel stage, and every subscribed tag is marked invalid.

Third-party OPC UA clients (such as UA Expert from Unified Automation) implement a one-click "accept server certificate" workflow in the GUI. WinCC Runtime Advanced has no equivalent interactive prompt; certificate handling is performed silently against the file system, and the engineer must move files between folders manually.

The certificate store layout for WinCC Runtime Advanced is:

C:\ProgramData\Siemens\CoRtHmiRTm\OPC\PKI\CA\default\rejected
C:\ProgramData\Siemens\CoRtHmiRTm\OPC\PKI\CA\default\certs
C:\ProgramData\Siemens\CoRtHmiRTm\OPC\PKI\CA\!TCSB1\certs

Two sub-folders are typically present:

• default - contains certs\ (trusted) and rejected\ (rejected) subfolders.
• !TCSB1 - a server-specific trust folder named after the TCSB instance (note the leading exclamation mark that distinguishes instance folders from the default folder). For multiple TCSB instances additional folders !TCSB2, !TCSB3 etc. will be created.

When the WinCC Runtime is started for the first time against a new TCSB server, the TCSB server certificate is placed in ...\default\rejected\. Until that certificate is moved to ...\default\certs\, the OPC UA session is rejected and all tags return ### regardless of how the address is typed.

Diagnostic Logging Locations

Before applying the fixes, capture the current OPC UA status to confirm the suspected root cause:

When reviewing the CoRtHmiRTm trace, look specifically for the string Bad_CertificateUntrusted (hex status code 0x801A0000) which confirms the certificate path is the active fault, or for Bad_NodeIdUnknown (hex status code 0x80340000) which points to the case-sensitivity fault.

Resolution: Correct the OPC UA Tag Address Case

Apply the following corrections in the WinCC tag configuration inside TIA Portal:

1. Open the WinCC project in TIA Portal and navigate to HMI Tags.
2. Open the OPC UA connection properties and confirm the discovery URL is opc.tcp://<hostname>:4852 with Security Policy = None.
3. Open the tag whose address displays ###. Do not rely on the browse dialog - type the address manually in the correct case.
4. For the connection state tag of a station, use exactly:

   ns=TCS;s=TCS:[<ProjectName>.<StationName>.101]ConnectionState

   Replace <ProjectName> and <StationName> with the actual TCSB project and station names, preserving their original case as configured in TCSB.
5. For a data block (DB) variable access, use:

   ns=TCS;s=TCS:[<ProjectName>.<StationName>.101]DB1.<VariableName>

   Note that DB1 must be uppercase; db1 will be rejected.
6. For a process value with type qualifier, ensure the type identifier uses uppercase:

   ns=TCS;s=TCS:[<ProjectName>.<StationName>.101]<ProcessValueName>:<TYPE>

7. Compile the project and download to the WinCC Runtime target.
8. Trigger a runtime restart so the new tag configuration is reloaded into the OPC UA subscription.

Resolution: Trust the TCSB Server Certificate

Apply the following on the PC that runs WinCC Runtime Advanced. The procedure requires local administrator rights.

1. Confirm hostname resolution: open an elevated command prompt and run ping <TCSB-hostname>. The command must return a response from the configured hostname, not from an IP address. If ping fails by hostname, edit C:\Windows\System32\drivers\etc\lmhosts (uncomment the lmhosts sample entry first) or add a DNS entry so the hostname resolves.
2. Stop the WinCC Runtime.
3. Open Windows Explorer and navigate to:

   %ProgramData%\Siemens\CoRtHmiRTm\OPC\PKI\CA\default\

4. Open the rejected subfolder. Locate the TCSB server certificate file (DER-encoded .der file with a long hex-style name based on the certificate thumbprint).
5. Move (or copy) the certificate file into the certs subfolder:

   %ProgramData%\Siemens\CoRtHmiRTm\OPC\PKI\CA\default\certs\

6. Optionally, repeat the move into the !TCSB1 instance folder to permanently trust the TCSB instance certificate:

   %ProgramData%\Siemens\CoRtHmiRTm\OPC\PKI\CA\!TCSB1\certs\

7. Restart the WinCC Runtime.
8. Re-test the tag value. The ### should be replaced by the live value.

For deployments using WinCC Runtime Professional instead of Advanced, refer to the Siemens application example on TCSB certificate management which details the equivalent procedure for the Professional runtime certificate store and WinCC Unified trust configuration: TCSB Certificate Management with WinCC Professional (PDF).

Configuration Reference for TIA Portal V13 SP1

The original case-sensitivity problem was identified and documented in the Siemens application example "Monitoring of remote measuring points using an RTU3030C" (entry ID 109739240), with the relevant guidance on page 39. The example notes:

• OPC UA distinguishes between upper and lower case in the address string.
• In TIA Portal V13 SP1 the address must be corrected manually; the portal does not normalise the case on import.
• The correction applies to the namespace prefix, the instance identifier, the project name, the station name, the data block identifier, and the process-value type qualifier.

Handling Multiple TCSB Stations

For deployments that aggregate multiple TCSB stations into one WinCC Runtime, the certificate step must be repeated for each station's certificate if each station terminates its own TLS handshake. In practice, all stations connect to a single TCSB OPC UA server endpoint on port 4852, so a single server certificate move is sufficient - but each station address must still be entered in the correct case:

ns=TCS;s=TCS:[MyProject.PumpStation01.101]ConnectionState
ns=TCS;s=TCS:[MyProject.PumpStation02.101]ConnectionState
ns=TCS;s=TCS:[MyProject.PumpStation03.101]ConnectionState

When the project name contains spaces or special characters, wrap the bracketed segment in single quotes when used in script or dynamic address construction; the literal NodeId string itself is unaffected.

Update Rate, Deadband and Subscription Behaviour

Once the connection is established, the OPC UA subscription configured in the WinCC tag properties controls how often the runtime polls TCSB. Recommended settings for a TeleControl HMI:

Verification Procedure

After applying both fixes, verify the connection end-to-end:

1. From the WinCC Runtime PC, run ping <TCSB-hostname>. A successful reply by hostname (not IP) is required.
2. Start the WinCC Runtime. Open the configured HMI screen.
3. Confirm the ConnectionState tag shows a value other than ###. Typical valid values are 0 (disconnected) and 1 (connected).
4. Open the WinCC Runtime diagnostics (or the CoRtHmiRTm log under %ProgramData%\Siemens\CoRtHmiRTm\Logs\) and confirm no OPC UA Bad_NodeIdUnknown or Bad_CertificateUntrusted entries are present.
5. Cross-check the value with UA Expert (or any other OPC UA client) reading the same NodeId. The two values must match.
6. Force a state change on the TCSB station (for example, take the station offline and back online) and confirm the value updates within the configured update interval (default 1 s).
7. Reboot the WinCC Runtime PC and confirm the tags resume updating without manual certificate movement - this confirms the certificate is permanently trusted.

OPC UA Address Reference Table

OPC UA Status Code Quick Reference

Troubleshooting Matrix

Backup and Restore of the Trust Store

For fleet deployments of WinCC Runtime Advanced that talk to a single TCSB server, capture the certificate set once on the engineering PC and deploy it as part of the runtime image:

1. After confirming the OPC UA connection works on the engineering PC, copy the entire %ProgramData%\Siemens\CoRtHmiRTm\OPC\PKI\CA\ tree.
2. On each runtime PC, replace the same path with the copied tree before the first runtime start. This eliminates the per-PC certificate-movement step.
3. If the TCSB server certificate is renewed (for example, after a server hardware swap), repeat the certificate-movement procedure on every runtime PC; pre-deployment of the old certificate no longer applies.

Related Topology Alternatives

Where the native WinCC Runtime Advanced OPC UA channel is not appropriate (for example, on SIMATIC HMI Comfort Panels that pre-date OPC UA client support, or where a third-party aggregation server is already present), the OPC UA topology can be reorganised:

• Third-party OPC UA extension for SIMATIC WinCC: a plug-in channel that exposes the full OPC UA client feature set to WinCC. See the Unified Automation case study on OPC UA extension for SIMATIC WinCC.
• TOP Server as OPC UA aggregation hub: when the Comfort Panel cannot act as a direct OPC UA client, an OPC UA server such as TOP Server can aggregate the TCSB data and serve it to WinCC flexible. See the Software Toolbox FAQ on Communicating with a Simatic HMI Comfort Panel via OPC UA.
• WinCC Unified OPC UA client: for TIA Portal V16 and newer projects, the WinCC Unified OPC UA client documentation describes the equivalent client configuration and supports both alarm and data subscription from TCSB, with built-in certificate management via the TIA Portal Unified Certificate Manager.

Migration Path to WinCC Unified

For new projects, WinCC Unified (TIA Portal V16+) provides a more robust OPC UA client experience and resolves the case-sensitivity issue at the engineering layer through the TIA Portal OPC UA Companion Specification importer, which validates NodeIds against the server's address space at design time. When migrating an existing WinCC Runtime Advanced project that subscribes to TCSB:

1. Re-export the TCSB address space using UA Expert's CSV export.
2. Import the CSV into the WinCC Unified OPC UA client configuration.
3. Validate that the imported NodeIds match the canonical capitalisation shown in the reference table above.
4. Deploy the WinCC Unified project and confirm certificate trust via the TIA Portal Certificate Manager instead of file-system manipulation.

Security Considerations Beyond Security = None

The procedures above assume Security Policy = None, which is appropriate for trusted LAN segments. For WAN or untrusted network deployments between WinCC Runtime and TCSB, switch both ends to Basic128Rsa15 or Basic256Sha256 with self-signed certificates. In this configuration:

• Both WinCC Runtime and TCSB must trust each other's certificates - the WinCC client certificate must be exported from %ProgramData%\Siemens\CoRtHmiRTm\OPC\PKI\CA\default\certs\ and imported into the TCSB trusted clients store.
• The TCSB server certificate must be moved from rejected\ to certs\ on the WinCC Runtime PC as described above, but additionally the certificate must be valid (not expired, not outside the certificate validity window of the runtime PC clock).
• The application URI in the certificate must match the hostname used in the discovery URL, otherwise Bad_CertificateUriInvalid (hex 0x801A0004) is raised.

FAQ