- 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 OPC UA Safety 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 Clause 6.4.