In addition to the normative references given in Clause 2, the OPC Test Lab Specification [6] provides information on the testing principles used for Conformance Units referenced in 10.4.

The following requirements apply for the development of this document:

Safety communication suitable for Safety Integrity Level up to SIL4 (see IEC 61508) and PL e (see ISO 138491).

Combination of SIL 1 – 4 devices according to this document as well as non-safety devices on one communication network.

Implementation of the safety transmission protocol is restricted to the safety layer.

The safety-relevant time-out monitoring is implemented in the safety layer.

Safety communication meet the requirements of IEC 617843.

f)[RQ5.1] This document is intended for implementation in safety devices exclusively. Exceptions (e.g. for debugging, simulation, testing, and commissioning) shall be discussed with a notified body.

[RQ5.2] For an implementation of this document, 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, 5.5, see Table 2.

[RQ5.3] The safety measures shall be processed and monitored within the SCL.

Table 2 – 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	–
aInstance of “sequence number” of IEC 617843. bInstance of “time expectation” (Timeout) and “feedback message” (Receipt) of IEC 617843. cInstance of “connection authentication” of IEC 617843. dInstance 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 2, 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 9.4.

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

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.

PubSub:

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

[RQ5.4] Any CRC signature calculation shall start with a preset value of “1”.

[RQ5.5] Any CRC signature calculation resulting in a “0” value, shall use the value “1” instead.

[RQ5.6] SPDUs with all values (incl. CRC signature) being zero shall be ignored by the receiver (SafetyConsumer and SafetyProvider).