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