Application Hierarchies

Scope / Goals

The aim of the sub-group of the Harmonization Working Group is to create and maintain a living document (whitepaper) on OPC UA application hierarchies.

OPC UA allows a variety of system architectures, including different options where OPC UA applications are deployed (in the PLC, on the field device, in some IPC gateway or edge device, etc.). Aggregating servers allows to collect information from various smaller servers like field devices and to provide a higher-level system view.
Companion specifications typically only define an information model without requiring or enforcing any specific deployment scenarios. Although this is intentionally left open from a companion specification perspective, it is desirable to give guidelines to application developers.

The aim of this activity is to prepare a whitepaper that describes different architecture options and discuss the pros and cons of these options. The whitepaper should address:

• Where to deploy OPC UA applications in a system hierarchy?
• How to deploy security in a system, what are reasonable system boundaries?
• How to deal with different, contradictory requirements like access to field-device information for centralized applications, e.g. maintenance on the one hand, and information hiding and restricting access to system data from a centralized, controlled access point?
• What rules or design patterns for OPC UA application hierarchies and interactions between them should be applied?
• Should traditionally subordinate devices (like End of Arm Tool on robot, camera/lighting on vision system) equipped with their own OPC UA Servers be
  • Accessible only through the superordinate device? If so, implement by network isolation or by access rules?
  • Freely accessible? If so, what are the technical and legal (functionality guarantees, product warranty, intellectual property) aspects of this?
• How are devices treated
  • which are connected via gateways (e.g. IO-Link device (EoAT) -> IO-Link gateway with OPC UA Server -> PLC?)? For example, are the servers expected to map the devices to a Companion Specification?
  • which do not have the capability to run an OPC UA Server, but whose information should be provided to higher level systems (for Asset Management, Condition Monitoring, etc.), e.g. classical fieldbus or I/O devices connected to PLC or robot controls (e.g. a simple gripper connected via I/O, fieldbus, … to a PLC/robot)
• Are gateways / higher-level OPC UA servers bound to pass on or aggregate certain values or are standards useful for use-cases like energy management to be handled in similar fashion in diverse devices?