Part 15: Safety
| Document number | OPC 10000-15 |
|---|---|
| IEC designation | IEC 62541-15 |
| Colloquially | Part 15 |
| Group | Utility |
Part 15 defines OPC UA Safety: a functional-safety protocol carried inside ordinary OPC UA traffic. A safety provider and a safety consumer exchange a protected data unit with its own identifiers, counter and checksum, so the OPC UA layer beneath can be treated as an untrusted black channel.
The black channel principle
OPC UA Safety does not make an OPC UA system safe. It defines a safety layer that assumes the communication underneath is unreliable and possibly malicious, and detects every relevant failure itself: corruption, loss, duplication, reordering, delay, insertion and addressing errors. That assumption is what lets the safety data ride over standard OPC UA - client/server or PubSub - with no safety requirement on the stack, the network or the switches in between. This is the same architectural approach the established fieldbus safety protocols take.
Provider, consumer and the protected data unit
A safety provider is the side holding the safety data; a safety consumer requests it and validates what comes back. The exchange carries a safety protocol data unit containing the payload plus the protective fields: identifiers binding the data to a specific provider and structure, a monitoring number that changes each cycle so a stale or replayed response is detected, and a checksum over the whole unit. The consumer enforces a timeout, and any failure drives the consumer to its safe state rather than to an error message.
Identifiers and configuration
The safety identifiers are the part people underestimate. A base identifier plus a provider identifier uniquely address the provider within its scope, and a structure signature binds the exchange to a specific safety data layout, so a consumer cannot be fooled by a correctly formed response from the wrong device or the wrong version of the right device. These values are engineering data, set during commissioning and covered by the safety assessment, not runtime configuration to be edited casually.
What it defines
| Concept | What it is |
|---|---|
| Safety provider | The application that owns and offers the safety data. Typically a safety controller or a safety-rated device. |
| Safety consumer | The application that requests and validates safety data, and that goes to its safe state on any validation failure or timeout. |
| Safety protocol data unit | The self-protecting message: payload plus identifiers, monitoring number and checksum. Opaque to the OPC UA layer carrying it. |
| Black channel | The assumption that the transport is untrustworthy. It is why OPC UA Safety needs no safety certification of the network or the OPC UA stack. |
| Monitoring number | A per-cycle counter carried in both directions so that a repeated, delayed or out-of-order response is detected rather than accepted. |
| Safety identifiers | A base identifier plus a provider identifier that uniquely address the provider, preventing a valid response from the wrong source being accepted. |
| Structure signature | Binds the exchange to a specific safety data layout, so a layout change on either side breaks the connection instead of misinterpreting fields. |
| Consumer timeout | The watchdog. Exceeding it is a safety-relevant event and drives the consumer to its safe state; its value is part of the response-time proof. |
| Mapping to OPC UA | The exchange is defined so it can run over client/server methods or over PubSub, which is what makes controller-to-controller safety over standard Ethernet possible. |
| Address-space representation | A published information model exposes the safety provider and consumer objects and their parameters so a tool can browse and configure them - Opc.Ua.Safety is at version 1.05.04, published 2025-02-05. |
Do you need to read it?
Machine builders and system integrators implementing a safety function that has to cross a machine boundary, and architects deciding whether a safety signal can share the standard network. Everybody else should know it exists so that a claim of OPC UA is secure and safe can be unpicked into two separate questions.
Traps that trace back to this part
- Safety and security are independent and you need both. The black channel assumption covers corruption and replay; it does nothing for confidentiality, authorisation or availability. Run the OPC UA layer with SignAndEncrypt and proper certificates underneath, and treat a blocked channel as a machine stop, because that is what a consumer timeout produces.
- The response-time budget covers the whole chain. Every hop, buffer, gateway and broker in the path consumes part of the safety function's response time, so inserting an OPC UA aggregating server or an MQTT broker into a working safety path can invalidate the timing proof even though the data still flows.
- You cannot implement the safety side on a general-purpose SDK and call it done. The safety layer has to come from a stack developed and assessed for functional safety, and the resulting device needs a functional-safety assessment. Conformance testing against OPC UA profiles says nothing about that.
- The safety identifiers and structure signature are commissioning data covered by the assessment. Changing a provider identifier or a safety data layout without going back through the change process is a safety-relevant modification, not a configuration tweak, and the protocol will correctly refuse to connect until both sides agree.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.