OPC UA Safety specifies a safety communication layer (SCL) allowing safety-related devices to use the services of OPC Unified Architecture for the exchange of safety-related data. A device which implements OPC UA Safety correctly will be able to exchange safety-related data and hereby fulfill the requirements of the international specifications IEC61508 and IEC61784-3. OPC UA Safety uses a monitoring number, a timeout, a set of IDs and a cyclic redundancy code for the detection of all possible communication errors which may happen in the underlying OPC UA communication channel. These measures have been quantitatively evaluated and offer a probability of failure per hour (PFH) and a probability of failure on demand (PFD) sufficing to build safety related applications with a safety integrity level of up to SIL4.

OPC UA Safety itself is an application-independent, general solution. The length and structure of the data sent is defined by the safety application. However, application-dependent companion specifications (addressing for example electro-sensitive protective equipment, electric drives with safety functions, forming presses, robot safety, and automated guided vehicles) are expected to be defined by application-experts in appropriate OPC UA companion specifications.

The following requirements apply for the development of the OPC UA Safety technology:

1. Safety communication suitable for Safety Integrity Level up to SIL4 (see IEC 61508) and PL e (see ISO 138491).
2. Combination of SIL 1 – 4 OPC UA Safety devices as well as non-safety devices on one communication network.
3. Implementation of the safety transmission protocol is restricted to the safety layer.
4. The transmission times are monitored by timers implemented in the safety layer.
5. Safety communication meet the requirements of IEC 617843:2017.
6. [RQ4.1] The OPC UA Safety stack is intended for implementation in safety devices exclusively. Exceptions (e.g. for debugging, simulation, testing, and commissioning) shall be discussed with a notified body.

OPC UA Safety is based on:

• the standard transmission system 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 standard or black channel elements 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" (“Black Channel”) does not need any additional functional safety assessment.

The basic communication layers of OPC UA Safety 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-Interface, which is specified 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 in the scope of this part.

Part: OPC UA Safety

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

Safety data is transmitted by point-to-point communication (unidirectional). Each unidirectional connection 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 an a priori expectation regarding the pair of SafetyProviderID and SafetyBaseID. 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. “pub/sub” or “client/server”. Therefore, the remaining parts of the safety layer can be implemented independent on which OPC UA service is used.

Part: OPC UA layer

Client/Server:

• 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.

[RQ4.2] All technical measures for error detection of OPC UA Safety shall be implemented within the SCL in devices designed in accordance with IEC 61508 and shall meet the target SIL.

Runs on top of:

OPC UA Client/Server (TCP/IP) with the Method Service Set.

From an architectural point of view: easy extensibility for other ways of communication (e.g. OPC UA pub/sub).

goal: no modification of existing OPC UA framework.

Modest requirements on safety network nodes:

No clock synchronization is needed (no requirements regarding the accuracy between clocks at different nodes).

Within the SafetyConsumer, a safety-related, local timer is required for implementing the SafetyConsumerTimeout. The accuracy of this timer depends on the timing requirements of the safety application.

“Black Channel” principle: No functional safety requirements for neither non-safety network nodes, the OPC UA stack, nor underlying networks such as Ethernet.

“Dynamic” systems:

Safety communication partners may change during runtime,

and/or increase/decrease in number.

Well-defined text-strings are used for diagnostic purposes.

Cyber-security is part of OPC UA and is not covered by this part, see Clause 4.6.

Safety communication and standard communication are independent. However, standard devices and safety devices may use the same communication channel at the same time.

Functional safety can be achieved without using structurally redundant communication channels (single channel approach). Redundancy may be used optionally for increased availability.

For diagnostic purposes, the last SPDU sent and received is accessible in the information model of the SafetyProvider.

The state machines of OPC UA Safety are independent from the OPC UA Mapper, allowing for a simplified exchange of the mapper.

Length of user data: 1-1500 bytes, structures of basic data types, see Clause 6.4.

Ready for wireless transmission channels.

In the final application, an appropriate security environment needs to be in place for protecting both the operational environment and the safety-related systems.

For this purpose, a threat and risk analysis (TRA) according to IEC 62443 needs to be carried out on a final application system level.

An adequate reduction of risk against malevolent attacks is necessary for a meaningful application of this part. OPC UA Safety does not describe any measures which will lower the risk of malevolent attacks, but addresses the topic “functional safety”, only.

During compliance tests to OPC UA Safety, security aspects are not part of the scope, as it is assumed that the underlying base mechanisms (i.e. methods) already provide adequate security.

[RQ4.3] For the realization of OPC UA Safety, the following measures shall be implemented:

• MonitoringNumber
• Timeout with receipt in the SafetyConsumer
• Set of IDs for the SafetyProvider
• Data Integrity check

Together, these safety measures address all possible transmission errors as listed in IEC 617843:2017, Clause 5.5, see Table 3.

[RQ4.4] The safety measures shall be processed and monitored within the SCL.

Table 3 – Deployed measures to detect communication errors

Communication error	Safety measures
	MonitoringNumber a	Timeout with receipt b	Set of IDs for SafetyProvider c	Data integrity check d
Corruption	–	–	–	X
Unintended repetition	X	X	–	–
Incorrect sequence	X	–	–	–
Loss	X	X	–	–
Unacceptable delay	–	X	–	–
Insertion	X	–	–	–
Masquerade	X	–	X	X
Addressing	–	–	X	–
a Instance of "sequence number" of IEC 617843. b Instance of "time expectation" (Timeout) and "feedback message" (Receipt) of IEC 617843. c Instance of "connection authentication" of IEC 617843. d Instance of "data integrity assurance" of IEC 617843, based on CRC signature.

The SafetyConsumer is specified in such a way, that for any communication error according to Table 3, a defined fault reaction will occur.

In all cases, the faulty SPDU will be discarded, and not forwarded to the safety application.

Moreover, if the error rate is too high, the SafetyConsumer is defined in such a way that it will cease to deliver actual process values to the safety application but will deliver fail-safe substitute values instead. In addition, an indication at the Safety Application Program Interface is set which can be queried by the safety application.

In case the error rate is still considered acceptable, the state machine repeats the request, see Clause 11.4.