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.