Connect OPC UA to Siemens S7-1500

Before you start

• A CPU firmware level that includes the OPC UA server, and the runtime licence or option that activates it. Neither is safe to assume from a datasheet you read once; both depend on the exact CPU order number.
• TIA Portal at a version that matches the CPU firmware. A project engineered on an older TIA version may not expose the server settings you are looking for.
• The licence present on the CPU before the server will serve. Treat licence procurement as lead time on the project plan, not as a configuration step you do on commissioning day.
• A network path to TCP 4840 from wherever the client runs, or a reverse-connect arrangement if the CPU sits below a Purdue layer boundary that only permits outbound connections.
• A disciplined clock. The CPU validates certificate validity periods, so clock skew between PLC and client presents as a certificate fault rather than as a time problem.

Setting it up

1. Enable the server in the CPU propertiesIn the device configuration, open the CPU properties and find the OPC UA server settings. Enable the server and note the endpoint TIA reports, normally opc.tcp://<plc-ip>:4840. Set the application name deliberately: it propagates into the ApplicationUri and into the CPU's own application instance certificate, and changing it later invalidates every trust relationship you have built.
2. Decide per tag what is exposedPLC tags and data-block members carry accessibility attributes that control whether they are visible to HMI and OPC UA and whether they may be written. A tag with the visibility attribute cleared simply does not appear in the address space; a tag that is visible but not writable appears and then refuses the write. Set these attributes as a deliberate interface decision, not by leaving the defaults.
3. Build a server interface instead of exposing the whole programTIA lets you define a server interface: a curated set of nodes with names you choose, decoupled from internal symbol names. Do this. It gives you a stable contract, so internal refactoring of the program does not break the client, and it keeps the address space small enough for an embedded server to browse quickly.
4. Map a companion specification onto the interface if you have oneImport the companion NodeSet2 file with SiOME, map PLC tags onto the model's variables, and export the result back into the TIA project as a server interface. The client then browses MachineIdentificationType and a state machine rather than a data-block tree, and the same client code works on the next machine.
5. Configure security and certificates before you configure dataChoose the security policies and message security modes the CPU will offer, decide between anonymous and username identity tokens, and generate the CPU's server certificate through the project's global security settings. The certificate must carry every hostname and IP address a client will actually dial in its Subject Alternative Name, plus the ApplicationUri as a URI entry.
6. Compile, download, then browse with an independent clientDownload the hardware configuration, then connect with UaExpert or opcua-commander on a security None endpoint first to prove reachability, and only then on a signed and encrypted endpoint. The first secure attempt normally fails with BadCertificateUntrusted; move the client certificate from the CPU's rejected list to its trusted list and trust the CPU certificate on the client side.
7. Read the NamespaceArray and resolve indexes at runtimeRead the server's NamespaceArray once per connection, build a namespace URI to index map, and store namespace URI plus identifier in your configuration. Never store the raw ns= number. This is what stops the next program download from breaking your client.
8. Check the CPU's own limits before you size subscriptionsThe technical data for the CPU states maximum sessions, subscriptions, monitored items and the minimum supported sampling and publishing intervals. Size the client to those numbers, and remember the server shares the CPU with the cyclic program.

What the address space looks like

Unless you build a server interface, the address space is a Siemens-shaped tree rather than a companion-specification model: a node named for the PLC with folders for global and instance data blocks, inputs, outputs, memory, counters and timers underneath. Identifiers are strings that mirror the TIA symbol names, so a data-block member arrives as something like ns=3;s="MyDB"."Speed" with array elements indexed in the identifier. Structures declared in the program surface as structured values, which your client can only decode if it supports the server's chosen type description mechanism. A server interface replaces all of this with the names and hierarchy you defined, and a SiOME-mapped companion model replaces it with standard types under the standard namespace URIs.

The traps

• The licence is the most common schedule risk on the whole integration. A server that will not start because an option was never ordered looks exactly like a firewall problem for the first afternoon. Confirm the current licence and firmware requirements with Siemens before anyone books commissioning time.
• Namespace indexes are assigned at server start and can shift after a program download or a firmware change. A client with a hardcoded ns= number then fails with BadNodeIdUnknown on nodes that are still perfectly present. Resolve indexes from the NamespaceArray at connect time.
• Getting the CPU to accept the client's certificate is the single biggest deployment hurdle in practice, and it is a two-sided operation: the client must trust the CPU and the CPU must trust the client. Plan a trust-list procedure, or a PKI, before the first machine rather than after the tenth.
• A tag that is visible but not marked writable will accept the write request and return a Bad status. Always read back after writing during commissioning, and check the returned StatusCode rather than trusting that no exception was raised.
• Embedded servers carry far lower session, subscription and monitored-item limits than a PC-based server. Three clients each opening their own session with their own publishing interval can exhaust a CPU that a single well-designed client would not notice.
• Timestamp behaviour on PLC-embedded servers is often thin: SourceTimestamp may be no more informative than ServerTimestamp, and the CPU clock may be local time with no offset. Decide which timestamp you store, verify what the CPU actually populates, and keep NTP on everything.
• Certificate validity periods are enforced against the CPU clock. A CPU that lost its clock over a long power-down rejects valid certificates with a time error until the clock is corrected.

Getting OEE data out of it

You can get availability, counts and reasons from an S7-1500, but only what the program computes. Nothing is standardised by default: state comes from whatever boolean or integer the programmer used, counts from whatever counter exists, and reasons from fault words. Ask for a state model and a counter in the PLC rather than edge-detecting a running bit in your client, because the client sees only sampled values and will miss short stops between samples. If the machine builder can be persuaded to publish a server interface mapped to Machinery or MachineTool types, availability and counts become portable across vendors and the mapping stops being per-machine work. Planned production time, shift calendars, standard cycle times and order context are not in the CPU and must come from MES or ERP.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.