This document specifies a safety communication layer (SCL) allowing safety-related devices to use the services of OPC UA for the safe exchange of safety-related data. A safety device that implements OPC UA Safety correctly will be able to exchange safety-related data and hereby fulfill the requirements of the international specifications IEC 61508 and IEC 61784-3. This document 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 communication channel. These measures have been quantitatively evaluated and offer a probability of dangerous failure per hour (PFH) and a probability of dangerous 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.

[RQ4.1] All technical measures for error detection described in this document 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 with the Method Service Set.
• OPC UA PubSub.
• From an architectural point of view: easy extensibility for other ways of communication.
• goal: no modification of existing OPC UA framework.
• The state machines of this document are independent from the OPC UA Mapper, allowing for a simplified exchange of the mapper.
• Ready for wireless transmission channels.
• 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.
• End-to-End Safety: Functional safety data is transported between two safety endpoint devices across a standard network that is not functionally safety compliant. This includes the lower transport layers such as the OPC UA stack, underlying physical media, and non-safety network elements (e.g. routers and switches).
• “Dynamic” systems:
• Safety communication partners may change during runtime,
• and/or increase/decrease in number.
• Well-defined text-strings are used for diagnostic purposes.
• 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 i.e. a single channel approach can be used. 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.
• Length of user data: 1-1500 bytes, structures of basic data types, see 6.2.5.

In the final application, an appropriate security environment is needed 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 is needed 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 document. This document does not describe any measures which will lower the risk of malevolent attacks, but addresses the topic “functional safety”, only.

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