4 Introduction to OPC UA Safety ToC Previous Next

4.5 Features of OPC UA Safety ToC Previous Next

Runs on top of: OPC UA Client/Server (TCP/IP) with the Method Service Set. From an architectural point of view: easy extensibility for other ways of communication (e.g. OPC UA pub/sub). goal: no modification of existing OPC UA framework. 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. “Black Channel” principle: No functional safety requirements for neither non-safety network nodes, the OPC UA stack, nor underlying networks such as Ethernet. “Dynamic” systems: Safety communication partners may change during runtime, and/or increase/decrease in number. Well-defined text-strings are used for diagnostic purposes. Cyber-security is part of OPC UA and is not covered by this part, see Clause 4.6. 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 (single channel approach). 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. The state machines of OPC UA Safety are independent from the OPC UA Mapper, allowing for a simplified exchange of the mapper. Length of user data: 1-1500 bytes, structures of basic data types, see Clause 6.4. Ready for wireless transmission channels.

Previous Next