Aim of the current PROFINET OPC UA companion standard is the mapping of PROFINET concepts and functions to the corresponding concepts of OPC UA. For this mapping, an architecture of devices and instances helps to define the scope, responsibilities and borders.

The upper area of the architecture contains engineering tools or software which acts as OPC UA Client for the devices implementing the OPC UA Servers. It is important to understand, that these engineering tools can be specialized for a certain end customer use-case like asset management and diagnosis. A combination of responsibilities in one tool is possible as well. Moreover, this document does not suggest any implementation of these tools. They can be located as OPC UA Client FB in one PLC, as software parts of an ERP system, developed by an end customer or a vendor of the Edge gateways or PLCs. The requirements of the specialized engineering tools are described in the corresponding use case chapter. Scope of this document is the communication between those OPC UA Clients and OPC UA Servers implementing the defined PROFINET information model.

The interface between the OPC UA Clients and the PROFINET devices is built by components which are OPC UA Servers and implements the role of PROFINET IO controller, IO supervisor or IO device. Each of these components support the whole or parts of the standardized PROFINET OPC UA information model, depending on the information that is available:

• PLC:A PLC may map all configured and connected PROFINET devices to OPC UA. The OPC UA information model in PLCs is built based on the expected configuration downloaded from the PLC specific engineering system to the PLC. It is not necessary to have an online connection to the connected devices. In this case the relevant parts of the information model have an appropriate status variable. The standardized PROFINET specific OPC UA objects may be provided in addition to other OPC UA objects like e.g. PLCopen DA variables.In cascaded Systems as shown above, every automation device with PROFINET IO controller functionality like e.g. robots is able to show the underlying devices as part of their specific information model in the same way as a PLC. An asset management or diagnosis tool may connect to all devices with IO controller functionality to have a complete view to all devices by the perspective of an IO controller.If the underlying devices are not in the same IP network as the IO controller, OPC UA offers a way like aggregation or direct access through firewalls.
• Edge gateway:An Edge gateway may discover the connected PROFINET devices and their configuration and diagnosis with PROFINET services. It does not have information of devices configured in the PLC but not operational in the network. The standardized OPC UA PROFINET objects are provided in addition to other product specific OPC UA objects of the Edge gateway.If the underlying devices are not in the same IP network as the Edge gateway, OPC UA offers a way like aggregation or direct access through firewalls.
• IO device:An IO device may discover the local PROFINET interface, their configuration and diagnosis, the local slot/subslot configuration, direct neighborhood and application relationships (ARs) to all IO controllers in shared device scenarios. It does not have information of other devices in the network. But in addition, an IO device may offer asset and diagnostics information via a local OPC UA Server which cannot be get by a PLC or Edge gateway. This is e.g. the case, if there is no PROFINET connection to an IO controller or the dynamics is higher than the scan cycle of an Edge gateway. A local representation of a PROFINET information model as part of an IO Device must be considered by the mapping of PROFINET to OPC UA.

In each of the above OPC UA Servers, the whole or parts of the standardized PROFINET OPC UA information model are contained. It is important that in all cases the same information is represented in a consistent manner.