Configuring WinCC Client as OPC Server for Remote Access

Overview

Siemens WinCC stations running as Operator Clients (OS Clients in classic WinCC V7 / PCS 7 nomenclature, or WinCC RT Professional Clients in TIA Portal) can simultaneously act as OPC DA Servers and OPC UA Servers. This dual role lets a third-party OPC client located outside the HMI LAN (for example, an on-shore engineering station that needs to consume tags from an off-shore WinCC Server project) treat the WinCC Client as a transparent data gateway instead of bridging remote OPC connectivity across an WAN directly to the OS Server.

The deployment pattern in the original engineering request is:

• Off-shore: WinCC OS Server holding the live process image, alarm buffer, and historical archive.
• On-shore: WinCC OS Client connected over WAN/TCP to the off-shore server (it already receives all tag values via the redundant/distributed client license path).
• On-shore: Customer OPC Client that must read — and in some cases write — selected WinCC tags without owning a WinCC runtime license.

This reference walks through both the classic WinCC V7 / PCS 7 OPC DA configuration (the original question) and the modern OPC UA configuration for WinCC RT Professional V20 documented in the Siemens TIA Portal help system.

Architecture: Server – Client – External OPC Client

When a WinCC station is configured as both an OS Client and an OPC Server, the data path is:

The OS Client is a fully licensed WinCC runtime; it therefore carries the full OPC server stack, so any 3rd-party OPC client that supports OPC DA 2.05/3.0 or OPC UA can subscribe directly to its local tag cache without disturbing the OS Server image. This eliminates the need for an OPC tunnel, OPC proxy, or an external bridging server.

OPC Standards Supported by WinCC

For new deployments, plan for OPC UA — DCOM-bound OPC DA is increasingly fragile across segmented networks and on modern Windows Server SKUs where the DCOMSS activation filter is tightened by default.

Prerequisites

1. The station designated as the on-shore WinCC Client must be installed with a valid WinCC Runtime licence. An operator license is the minimum; no Server license is required because the OS Client simply mirrors the off-shore server's image.
2. Verify the OS Client successfully starts in graphics Runtime and that at least one tag from the off-shore project updates on a faceplate.
3. For OPC DA: identical (or compatible) Windows user accounts must exist on both the WinCC station and the customer OPC client machine, or DCOM must be configured with anonymous / specific account overrides.
4. For OPC UA: the runtime PC must trust (or be able to download) the certificate chain of any connecting OPC UA client.
5. Firewall: open TCP 49320 for OPC UA binary, plus DCOM ports 135 + a dynamic range for OPC DA (see Network section below).

WinCC V7 / PCS 7: OS Client as OPC DA Server

The WinCC V7 installer registers the OPC DA Server automatically as soon as the WinCC Runtime is installed. No additional configuration is required to enable the OPC service; you must only allow external clients to enumerate and bind to it through DCOM.

Step-by-step

1. Confirm the OPC Service is running. Launch dcomcnfg → Component Services → Computers → My Computer → DCOM Config. Look for the OPC.SimaticHMI.HRT entry (the ProgID; ProgIDs that begin with OPC.SimaticHMI. <Suf> identify the active WinCC OPC services).
2. Set the launch & activation account. Right-click the OPC DA server entry → Properties → Identity. For a remote OPC client connecting across workgroups, switch from Launching user to The following user and supply a domain or local service account that exists on both machines with matching password.
3. Grant permissions in DCOM. On the Security tab, add the OPC client's Windows account to Launch, Activation, and Access permissions. If the customer uses an OPC DA bridge such as Matrikon, Kepware, or the Allmendinger product that speaks OPC UA → DA, the bridge service account is the principal you must authorize.
4. Allow the WinCC service through Windows Firewall. Open inbound TCP 135, the EPM port, and a contiguous high-range block such as 49152–65535 for the OPC DA callback.
5. Browse the server. On the customer OPC client box, run OPC Expert (any compliant DA browser) and connect to the WinCC OS Client by its network name. The full tag namespace of the on-shore project (mirrored from the off-shore server) becomes visible under the server's Tags branch.

WinCC RT Professional V20: OPC UA Server Activation

The Siemens TIA Portal V20 documentation Configure WinCC OPC UA Server (RT Professional) describes the activation procedure in detail. The following procedure mirrors those steps in the order they appear in the manual.

Step-by-step

1. Open the WinCC project in TIA Portal V20 and select the RT Professional station.
2. Right-click the HMI device and choose Runtime settings → Services.
3. Tick OPC UA Server. Optional: tick OPC UA Historical Access if the customer needs archive data.
4. Build and download the project. On the runtime station the service Siemens S7 OPC UA Server (or the equivalent WinCC RT Professional service) is registered and listens on TCP 49320 by default.
5. Configure the accessible tag space by editing OPCUASERVERWINCCPRO.XML. By default all HMI tags are exposed; you can restrict by prefix or by namespace index.
6. Push Start Runtime. Within ~10 s the UA server's local discovery server registers an endpoint and customer clients can connect.

OPCUASERVERWINCCPRO.XML — Anatomy

Located at %ProgramFiles%\Siemens\Automation\WinCC RT Professional\OPC\UA\, this XML file controls three properties: the endpoint port, the security policies offered, and the user-token policies accepted.

<?xml version="1.0" encoding="UTF-8"?>
<UAServer xmlns="http://opcfoundation.org/UA/2008/01/UAServer">
  <EndpointUrl>opc.tcp://<HMI_PC>:49320</EndpointUrl>
  <SecurityPolicies>
    <SecurityPolicy uri="http://opcfoundation.org/UA/SecurityPolicy#None">
      <UserTokenPolicy tokenType="Anonymous" />
    </SecurityPolicy>
    <SecurityPolicy uri="http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256">
      <UserTokenPolicy tokenType="UserName_password" />
    </SecurityPolicy>
  </SecurityPolicies>
  <ServerCertificate>
    <Store path="LocalMachine\My" />
    <!-- used for the server's own application certificate -->
  </ServerCertificate>
  <TrustedClients>
    <Store path="LocalMachine\TrustedPeople" />
  </TrustedClients>
  <Mapping>
    <HmiTagNamespace>2</HmiTagNamespace>
  </Mapping>
</UAServer>

Editing this file is required when:

• You must run on a port other than 49320.
• You wish to disable SecurityPolicy#None (recommended for any production deployment).
• You must pin down the set of accepted client certificates (whitelist).
• You need to expose only a subset of the HMI tag tree (then layer a Mapping rule under the namespace entry).

Endpoint, Security, and Certificate Management

1. Generate or import the WinCC OPC UA server's application certificate (CN may equal the WinCC station name).
2. Distribute the customer OPC client's certificate to the WinCC station's Trusted People store (LocalMachine\TrustedPeople).
3. Create a WinCC user for the customer connection and add it to the operator group that owns the desired tags.
4. Set the Windows firewall rule to allow inbound TCP 49320 only from the customer's source IP range.

Network, DCOM, and Firewall Considerations

OPC DA

DCOM requires a fixed service account, an open TCP/135 EPM port, plus an open dynamic range that must be hard-pinned in the registry. Best practice:

1. Set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\DCE-style endpoints to a 50-port static block, e.g. 5000–5050.
2. Allow inbound TCP 135, the static block, and outbound UDP 137/138 only if NetBIOS is needed for legacy enumeration.
3. Force Kerberos — NTLMv2 on domain boundaries is fine; never use NTLMv1 for cross-domain DCOM.

OPC UA

Single TCP port. If the on-shore network is fronted by an IDS/IPS, exempt TCP 49320 to avoid the OPC UA hello/Ack messages being shaped as "port scans" — a common reason the connection hangs at the OpenSecureChannel step.

Bandwidth & update rate

Tags that the customer subscribes to are mirrored from the off-shore OS Server to the on-shore OS Client by the standard WinCC distributed-server mechanism. The WAN round trip is incurred once per tag update; the customer OPC traffic then adds a second hop over the LAN. Size the off-shore link for:

Throughput (kbps) ≈ N_tags × avg_payload_bytes × 8 / Update_interval_ms × 1.25

with a 25% safety factor for retransmits. For typical WinCC tag updates (16-byte value ± 16-byte metadata) at 1 s, 1,000 tags fit in ~32 kbps with the safety factor.

Allmendinger OPC UA Extension for SIMATIC WinCC

For legacy WinCC V7 deployments that lack an OPC UA option license, a third-party UA server can be hosted alongside WinCC on the OS Client to forward tag values, alarms, and historical data to UA clients. The Unified Automation case study OPC UA Extension for SIMATIC WinCC documents this pattern. It's a viable bridge when:

• You cannot modify the WinCC installation on the off-shore server, only the on-shore client.
• The customer OPC UA client must reach WinCC but the off-shore WAN cannot be reached.
• You need historical access to the WinCC Tag Logging archive in UA HDA form.

Performance, Tag Limits, and Optimization

Architectural rule of thumb: one customer OPC client should be limited to ~2,000 actively-subscribed tags to leave enough WinCC internal bandwidth for graphics, alarms, and archive reads.

Verification and Test Tools

1. From the customer OPC client, browse with any OPC DA / UA browser (Siemens OPC Scout, Softing opcEasy, Unified Automation UaExpert). You should see every WinCC tag you permitted.
2. Read a known-good tag, e.g. HMI_Tag_TankLevel, and confirm both quality (192) and value match the faceplate.
3. Subscribe to a fast-changing tag (e.g. pump speed) and confirm delivered updates over 60 s. If you see fewer updates than expected, inspect DataChange suppression — groups in DA default to 100 ms with 0% deadband.
4. Force a tag change from the WinCC project to confirm write-back path.
5. Restart the WinCC OS Client and confirm the customer connection re-establishes within ≤ 30 s.

Troubleshooting Matrix

Field-Commissioning Notes

• Document the exact OPC UA server endpoint URL and customer-side trust list in the project Functional Specification; on-shore / off-shore turnover is where trust mismatches most often surface.
• Always test with a third OPC client (e.g. UaExpert) in addition to the customer's actual client, to isolate client-side vs server-side problems.
• When the WinCC OS Client is also used as a graphics station, ensure that adding the OPC UA server role does not displace its audio / Alarm-OCX path — review Windows service start-order if alarms fire late.
• Keep a backup of the original OPCUASERVERWINCCPRO.XML; hot editing during runtime can break connections but is recoverable because the OS Client does not need a project download for plain OPC-UA changes (RT Professional restarts the service only when the file is newer than the in-memory copy).

Related Engineering References

The Siemens documentation portal entry Configure WinCC OPC UA Server (RT Professional) details the OPCUASERVERWINCCPRO.XML structure, the lifecycle of the OPC UA application certificate, and the runtime-service interactions in TIA Portal V20.

For WinCC V7 deployments without the OPC UA option, the Allmendinger plug-in referenced in the Unified Automation case study OPC UA Extension for SIMATIC WinCC exposes the same WinCC tag namespace over UA, including historical data and alarms, without changes to the underlying WinCC project.

FAQ