5 General
5.1 External documents providing specifications for the profile

No other external documents are providing specifications in addition to the Normative references given in Clause 2.

5.2 Safety functional requirements

The following requirements apply for the development of this document:

Safety communication suitable for safety integrity level up to SIL 4 (see the IEC 61508 series) and PL e (see ISO 138491).

Combination of SIL 1 to 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.

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

5.3 Safety measures

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

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

Table 2 – Deployed safety 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.

5.4 Safety communication layer structure

This document is based on:

Safety applications and standard applications share the same standard OPC UA communication systems at the same time. The safe transmission function incorporates safety 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 or 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 require any additional functional safety assessment.

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

image007.png

Figure 2 – Safety layer architecture

Summary of the architecture:

Part: User Layer

The safety applications in the User Layer are either directly connected to the SafetyProvider or SafetyConsumer, or they are connected via a machine-specific or process-specific interface, which is described in companion specifications (e.g. sectoral).

The safety applications are expected to be designed and implemented according to the IEC 61508 series.

The Safety applications in the User Layer are not within the scope of this document.

Part: OPC UA Safety (Safety Communication Layer)

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 the IEC 61508 series.

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

When SafetyConsumers connect to SafetyProviders, they have prior expectations 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, it is not necessary for a SafetyProvider to know the SafetyConsumerID of the SafetyConsumer and will provide its process values to any SafetyConsumer requesting it.

SafetyProviders can not detect communication errors. All required error detection is performed by the SafetyConsumer.

If it is necessary for a pair of safety applications to exchange SafetyData in both directions, two pairs of SafetyProviders and SafetyConsumers shall be established, one pair for each direction.

The OPC UA Mapper implements the parts of the safety communication 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 communication layer can be implemented independent of the OPC UA Service being used.

Part: OPC UA Layer

Client/Server:

PubSub:

5.5 Requirements for CRC calculation

[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). For Client/Server communication, this means that a Method Call with all fields making up the RequestSPDU being zero shall be answered with all fields making up the ResponseSPDU being zero. Neither of these SPDUs shall be presented to the respective state machines.