4 Overview of OPC UA Safety
4.1 General
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 IEC 61508 series and IEC 61784-3. This document uses a MonitoringNumber, a timeout, a set of IDs and a cyclic redundancy check (CRC)code for the detection of all possible communication errors which can happen in the underlying OPC UA standard transmission system. These safety 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.
4.2 Implementation aspects
[RQ4.1] All technical measures for error detection described in this document shall be implemented within the SCL in devices designed in accordance with the IEC 61508 series and shall meet the target SIL.
4.3 Features
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 necessary (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 SafetyData 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 can change during runtime,
either an increase or decrease, or both, in the number of safety communication partners can occur.
Well-defined text-strings are used for diagnostic purposes.
Safety communication and standard communication are independent. However, standard devices and safety devices can use the same standard transmission system at the same time.
Functional safety can be achieved without using structurally redundant standard transmission systems i.e. a single channel approach can be used. Redundancy can 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 octet to 1 500 octets, structures of basic DataTypes, see 6.2.5.
4.4 Security policy
In the final application, an appropriate security environment is necessary to protect both the operational environment and the safety-related systems.
This document does not cover security aspects, nor does it provide any requirements for security.
A threat and risk analysis (TRA) according to the IEC 62443 series shall be carried out on a final application system level.
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.