This document is based on:

  • the standard transmission system according to OPC UA
  • an additional safety transmission protocol on top of this standard transmission system

Safety applications and standard applications are sharing the same standard OPC UA communication systems at the same time. The safe transmission function incorporates measures to detect faults or hazards that originate in the standard transmission system which have a potential to compromise the safety subsystems. This includes faults such as:

  • Random errors, for example due to electromagnetic interference on the transmission channel;
  • Failures / faults of the standard hardware;
  • Systematic malfunctions of components within the standard hardware and software.

This principle delimits the assessment effort to the “safe transmission functions”. The “standard transmission system” does not need any additional functional safety assessment.

The basic communication layers of this document are shown in Figure 2.


Figure 2 – Safety layer architecture

Summary of the Safety layer architecture:

Part: Application layer

The safety application is either directly connected to the SafetyProvider / SafetyConsumer, or it is connected via a machine-specific or process-specific interface, which is described in companion specifications (e.g. sectoral).

The Safety application layer is expected to be designed and implemented according IEC 61508.

The Safety application layer is not within the scope of this document.

Part: OPC UA Safety

This layer is within the scope of this document. It defines the two services SafetyProvider and SafetyConsumer as basic building blocks. Together, they form the safety communication layer (SCL), implemented in a safety-related way according to IEC 61508.

Safety data is transmitted using point-to-point communication (unidirectional). Each unidirectional data flow internally communicates in both directions, using a request/response pattern. This allows for checking the timeliness of messages using a single clock in the SafetyConsumer, thus eliminating the need for synchronized clocks.

When SafetyConsumers connect to SafetyProviders, they have prior expectation regarding the pair of SafetyProviderID and SafetyBaseID (e.g. by configuration). If this expectation is not fulfilled by the SafetyProvider, fail-safe substitute values are delivered to the safety application instead of the received process values. In contrast, a SafetyProvider does not need to know the ID of the SafetyConsumer and will provide its process value to any SafetyConsumer requesting it.

SafetyProviders are not capable of detecting communication errors. All required error detection is performed by the SafetyConsumer.

If a pair of safety applications needs to exchange safety data in both directions, two pairs of SafetyProvider and SafetyConsumer must be established, one pair for each direction.

The OPC UA Mapper implements the parts of the safety layer which are specific for the OPC UA communication service in use, i.e. “PubSub” or “Client/Server”. Therefore, the remaining parts of the safety layer can be implemented independent of the OPC UA service being used.

Part: OPC UA layer


  • The SafetyProvider is implemented using an OPC UA server providing a method.
  • The SafetyConsumer is implemented using an OPC UA client calling the method provided by the SafetyProvider.


  • The SafetyProvider publishes the ResponseSPDU and subscribes to the RequestSPDU.
  • The SafetyConsumer publishes the RequestSPDU and subscribes to the ResponseSPDU.