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

Previous Next