1 Scope

The scope of the OPC UA PROFINET Companion Specification is to define an OPC UA Information Model to represent the standardized object model (Object Dictionary) from PROFINET.

This OPC UA Information Model shall enable standard OPC UA Services to access the objects of PROFINET devices in a vendor independent way. The access can happen through an OPC UA Server directly integrated in the PROFINET device, or through an OPC UA Server aggregating Object Dictionaries of multiple PROFINET devices. This will allow the implementation of horizontal communication between PROFINET devices and OPC UA devices on the field level, as well the vertical communication initiated from devices in the process or enterprise level, e.g. for diagnostics, configuration, condition monitoring, visualization etc.

OPC Foundation

OPC UA is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Secure: encryption, authentication, authorization and auditing

Extensible: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

PROFINET Standardization Group (PNO)

The PROFIBUS and PROFINET user organization (PNO: Profibus Nutzerorganisation e. V.) was founded in 1989 and is the largest automation community in the world and responsible for PROFIBUS and PROFINET, the two most important enabling technologies in automation today. The PNO is member of PROFIBUS and PROFINET International (PI).

The common interest of the PNO global network of vendors, developers, system integrators and end users covering all industries lies in promoting, supporting and using PROFINET. Regionally and globally about 1,400 member companies are working closely together to the best automation possible. No other fieldbus organization in the world has the same kind of global influence and reach.

2 Normative references

The following referenced documents are indispensable for the application of this specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

[OPC 10000-1] OPC Unified Architecture - Part 1: Overview and Concepts – Version 1.04

[OPC 10000-2] OPC Unified Architecture - Part 2: Security Model – Version 1.04

[OPC 10000-3] OPC Unified Architecture - Part 3: Address Space Model – Version 1.04

[OPC 10000-4] OPC Unified Architecture - Part 4: Services – Version 1.04

[OPC 10000-5] OPC Unified Architecture - Part 5: Information Model – Version 1.04

[OPC 10000-6] OPC Unified Architecture - Part 6: Mappings – Version 1.04

[OPC 10000-7] OPC Unified Architecture - Part 7: Profiles – Version 1.04

[OPC 10000-9] OPC Unified Architecture - Part 9: Alarms and Conditions – Version 1.04

[OPC 10001-7] OPC Unified Architecture V1.04 - Amendment 7: Interfaces and AddIns

[OPC 10000-100] OPC Unified Architecture - Part 100: Devices – Version 1.02

[PN TAD] Topology and Asset Discovery – Guideline for PROFINET – Version 2.0 – Date: July 2017

[PN Service] IEC 61158-5-10, Industrial communication networks – Fieldbus specifications – Part 5-10: Application layer service definition – Type 10 elements

[PN Protocol] IEC 61158-6-10, Industrial communication networks – Fieldbus specifications – Part 6-10: Application layer protocol specification – Type 10 elements

[PN Diag] Guideline Diagnosis for PROFINET – Order No.: 7.142 – www.profibus.com

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and PROFINET are understood in this specification. This specification will use these concepts to describe the PROFINET OPC UA Information Model. For the purposes of this document, the terms and definitions given in [OPC 10000-1], [OPC 10000-3], [OPC 10000-4], [OPC 10000-5], [OPC 10000-7], [OPC 10000-100], as well as the following apply.

3.2 OPC UA for PROFINET terms

3.2.1 Asset

A piece of hardware and/or software which has a value for the user. In the scope of this document assets can discover properties like vendor, version or installation information by means of defined PROFINET services.

3.2.2 Startup Parameters

Device specific parameters which are set by the end user in the engineering system of the PLC. The parameter layout is described in the GSD file of the device. The configured values are transferred to the device during startup.

3.2.3 Tag-Function

The portion of the application specific device identification which defines the application specific function of an asset. The Tag Function is given during the planning phase of a plant e.g. by ECAD engineering tools. The specific usage of Tag-Function is defined by the OEM.

3.2.4 Tag-Location

The portion of the application specific device identification which defines the application specific location of an asset. Usually the TAG-Location is unique inside of a whole plant or OEM company. The Tag-Location is given during the planning phase of a plant e.g. by ECAD engineering tools. The specific usage of Tag-Location is defined by the OEM.

3.2.5 Edge Gateway

A physical device with one interface to the cell and an OPC UA interface to the factory.

3.3 Abbreviations and symbols

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table, the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see [OPC 10000-5]. In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see [OPC 10000-3]) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in 3.4.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this specification is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this specification, the symbolic name is unique.

The namespace for all NodeIds defined in this specification is defined in Annex A. The NamespaceIndex for this namespace is Server-specific and depends on the position of the namespace URI in the server namespace table.

Note that this specification not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this specification, because they are not defined by this specification but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is defined in Annex A.

If the BrowseName is not defined by this specification, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this specification. Table 110 provides a list of namespaces and their indexes as used in this specification.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in [OPC 10000-3]. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if it is server specific.

For all Nodes specified in this specification, the Attributes named in Table 3 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 4 shall be set as specified in the Table 4. The definitions for the Attributes can be found in [OPC 10000-5].

3.4.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 5 shall be set as specified in the table. The definitions for the Attributes can be found in [OPC 10000-5].

3.4.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 6 shall be set as specified in the table. The definitions for the Attributes can be found in [OPC 10000-5].

3.4.3.5 Methods

For all Methods specified in this specification, the Attributes named in Table 7 shall be set as specified in the table. The definitions for the Attributes can be found in [OPC 10000-5].

4 General information to PROFINET and OPC UA

4.1 Introduction to PROFINET

4.1.1 What is PROFINET?

PROFINET is the communication standard for automation from PROFIBUS & PROFINET International (PI). Its modular range of functions makes PROFINET a flexible system for all applications and markets. PROFINET is the networking solution of production and process automation, from applications with functional safety requirements and the entire spectrum of drive technology to isochronous motion control applications. The use of application profiles allows optimal usage of PROFINET in all areas of automation engineering.

4.1.2 System Model of a PROFINET System

IO controller: This is typically the Programmable Logic Controller (PLC) in which the automation program runs. The IO controller provides output data to the configured IO devices in its role as provider and is the consumer of input data.

IO device: An IO device is a distributed IO field device connected to one or more IO controllers via PROFINET. The IO device is the provider of input data and the consumer of output data from the IO controller.

IO supervisor: This can be a programming device (PG), personal computer (PC) or human machine interface (HMI) device for commissioning or diagnostic purposes.

A system unit contains at least one IO controller and one or more IO devices. IO supervisors are usually integrated only temporarily for commissioning or troubleshooting purposes.

4.1.3 Device Model of an IO Device

In its logical structure, a PROFINET field device is always modular in design. Modularity in the logical sense, however, does not require actual modularity in the electrical and mechanical design sense. An IO device is usually comprised of a communication module with Ethernet interface and (physical or virtual) modules assigned to it. The assigned modules handle the actual process data traffic. The access point for communication (Ethernet interface with data processing) is called the DAP (Device Access Point). The following structures are standardized for an IO device:

The device model consists of slots, subslots, modules and submodules.

The slot designates the insertion slot of a module in an IO field device. A field device usually has two or more slots.

A module is comprised of one or more submodules or provides available subslots into which submodules can be inserted.

The modules themselves have no task other than to provide structuring. The actual inputs and outputs (channels) are implemented in its submodules. The granularity of the channels (bitwise, bytewise or wordwise division of IO data) is determined by the manufacturer. Acyclic services always address submodules. Therefore, a module always contains at least one submodule.

The data content of a submodule is always accompanied by status information. The index specifies the data within a submodule inserted into a slot/subslot which can be read or written acyclically using read/write services. For example, parameters can be written to a module, or manufacturer-specific module data can be read out based on an index. Specific indexes are defined in the standard here. Additional indexes can be freely defined by the manufacturer.

The submodule is the owner of the user data, diagnostics, channels, actual configuration, records and I&M data. Cyclic IO data of the submodule in the device is addressed by specifying the slot/subslot combination of the insertion slot. They can be freely defined by the manufacturer. For acyclic data communication via read/write services, an application can specify the data of the submodule to be addressed using slot, subslot and index (Figure 2).

4.1.4 Communication Relationships

To establish communication between the higher-level controller and an IO device, the communication paths must be established. These are set up by the IO controller during system startup based on the configuration data received from the engineering system. This specifies the data exchange explicitly.

All data exchange is embedded into an AR (Application Relationship) (Figure 3). Within the AR, CRs (Communication Relationships) specify the data explicitly. As a result, all data for device modelling, including the general communication parameters, are downloaded to the IO device. An IO device can have multiple ARs established from different IO controllers, for example, for shared devices.

The communication channels for cyclic data exchange (IO data CR), acyclic data exchange (record data CR) and alarms (alarm CR) are set up simultaneously. Multiple IO controllers can be used in a PROFINET system (Figure 4). If these IO controllers can access the same data in the IO devices, this must be specified during parameter configuration (shared devices and shared inputs).

An IO controller can establish one AR each with multiple IO devices. Within an AR, several IO CRs on different APIs can be used for data exchange. This can be useful, for example, if more than one user profile (PROFIdrive, ENCODER etc.) is involved in communication and different submodules are required.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state of art security model (see [OPC 10000-2]).

A fault tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with semantic models such as PROFINET, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for examples. For a more complete overview see [OPC 10000-1].

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see [OPC 10000-4]) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 5.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has several Attributes including a unique identifier called a NodeId and a non-localized name called a BrowseName. An Object representing a ‘Reservation’ is shown in Figure 6.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 7 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all the children that can be present in an instance of the type. In the example in Figure 7 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeler to take an existing type and extend it. There are rules regarding sub-typing defined in [OPC 10000-3], but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeler may decide that the existing ObjectType in some cases needs an additional Variable. The modeler can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical references are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 8 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 9. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in [OPC 10000-3] and the base structure is described in [OPC 10000-5].

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionalities (see [OPC 10000-7])

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

5 Use cases

5.1 Introduction

This chapter contains the basic use case specification for the PROFINET integration to OPC UA. Its purpose is to define the scope and the requirements for the companion standard.

5.2 Architecture

5.2.1 Overview

The following figure contains the basic architecture for the integration of PROFINET to OPC UA. It is used to define the scope of the use cases in this document.

5.2.2 Description

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.

5.2.3 Information from GSD files and engineering tools

A natural language identification of objects in the namespace of the OPC UA Server requires information from the GSDML files involved and/or given by the engineering system of a PLC like module and submodule names, vendor specific diagnosis text messages or user comments to a module or submodule.

The mapping of PROFINET to OPC UA considers those data in the information model independent of the way the OPC UA Server gets it.

5.3 Use Case description

5.3.1 General

Use cases in this document are described in tables to have a unified representation. These tables contain the following rows:

Goal:
The objective of the use case.

Implements:
Relation to the corresponding requirement.

Preconditions:
One or more conditions which must be met as a precondition for the use case.

OPC UA mapping:
This section describes the behavior of the use case by an OPC UA viewpoint.

5.3.2 Asset management

5.3.2.1 General

The following asset management use-cases focus mainly on running applications and plants. During the commissioning phase changes in the assets are normal. The asset management phase begins after the acceptance tests of the commissioning phase.

5.3.2.2 PROFINET basics

The following chapters give a brief introduction to relevant PROFINET objects and services, which are used in the scope of the OPC UA integration use cases. A detailed definition of these terms can be found in documents from Chapter 2 or several printed documents which are available at www.profinet.com. Nevertheless, the reader of this document should be able to understand the basic PROFINET concepts without knowledge of all the details.

It is important, that the support of some PROFINET information below is not mandatory. Therefore, an optimal usability and features coverage can be achieved with devices which implement a maximum of optional PROFINET features. The requirement of the PROFINET specification is denoted by the capital (PN-M) for mandatory or (PN-O) for optional.

5.3.2.2.1 General

The following information is general for all PROFINET devices.

Device Information (PN-M):
Information that is related to the device with the PROFINET connection to the network. Examples are VendorID, DeviceID, DCP type identification, DNS Name of Station and IP-Address.

Physical Topology (PN-M):
PROFINET can discover the physical topology of installed devices as all devices exchange neighborhood information with the LLDP protocol.

Real Configuration (PN-M):
The real configuration of a PROFINET device contains slots and subslots with modules and submodules plugged in the device independent from any controller connection. Each module/submodule is identified by a module/submodule identification number which must be unique in the scope of one DeviceID. One defined submodule is the representative of the device; one submodule is the representative of a module. Therefore, the submodule is the carrier of all information. Modules and submodules which are installed in the real configuration of the device can be discovered with a PROFINET service. These modules/submodules are the carrier of the asset information.

Expected Configuration (PN-M):
The expected PROFINET configuration is the result of the PROFINET engineering in the configuration tool of the PLC. It contains the devices, modules, submodules which are configured in the engineering system of the PLC, downloaded to the controller and transferred to the devices during startup.
The expected configuration can be read with a defined PROFINET service.

Module Diff Block (PN-M):
The difference between the expected configuration and the real configuration. The reference to the difference is the expected configuration. The module diff block can be read with a defined PROFINET service.

5.3.2.2.2 I&M

PROFINET defines Identification and Maintenance functions since PROFIBUS. As there is a long history, some restrictions in these data are possible. In general, I&M contain defined properties and values to identify the asset more precise as it is possible with IDs and without knowledge of the GSD file.

I&M0 – Electronic Faceplate (PN-M for device, PN-O for Modules):
Version Information of the submodule like serial number, HW-Version and FW-Version. I&M0 data are read-only.

I&M1 – function and location (PN-O):
A unique function and location of the device/submodule as visible strings. I&M1 data must be written by a PROFINET engineering tool or PLC before they can be used. The mapping to marking systems like IEC 81346 are in the responsibility of the user and not in scope of this document.

I&M2 – comment (PN-O):
A comment to the device as visible string. I&M2 data must be written by a PROFINET engineering tool or PLC before they can be used.

I&M3 – installation date (PN-O):
The installation date of the device. I&M3 data must be written by a PROFINET engineering tool or PLC before they can be used.

I&M4 – signature (PN-M and defined for Functional Safety):
If the submodule is configured by an external safety configuration tool, this tool can write a signature of the parameter set in I&M4 data of the submodule. With its signature it is possible to discover differences between a stored parameter set of the engineering tool and a parameter set in the field. I&M4 is only defined for safety devices.

I&M5 – additional information (PN-O)
Offers additional information about a communication module which is part on an IO device. If the device (e.g. a robot) is made by company A, and the communication module by company B, I&M0 contain information about the robot and company A, I&M5 contain information about the communication module and company B.

5.3.2.2.3 Asset management in PROFINET

In addition to the above I&M data which are only bound to the PROFINET address elements slot/subslot, additional end customer requirements for enhanced asset management capabilities are incorporated in the PROFINET specification. Definition of PROFINET asset management objects sometimes use data types already defined by I&M properties. In addition to them other asset management properties are available. Asset information can be bound to slots and subslots to extend information, which cannot be modelled with I&M properties. Moreover, the PROFINET specification defines a level-tree of assets which objects are independent from the slot/subslot addressing scheme.

The following picture shows a possible example of asset management usage in a modular IO device.

The green elements are the modules and submodules of the station carrying I&M information. Additional asset information like version info of the power supply, terminal blocks or connected sensors and actors can be described by means of asset management objects, which are not directly related to the slot/subslot model.

In addition to this example PROFINET AM can be used to manage all components with loadable software, which can be device or module firmware as well as application programs running on PLCs or robots.

The following asset management objects can be accessed via a defined acyclic read service.

AM_Info:
The scope of the asset information, which can be “full information”, “firmware only” or “hardware only”.

AM_Location:
The location of an asset within a device as 16 subsequent octets. The location can be either “slot/subslot” to extend I&M information or “level tree” to form hierarchical structures of assets.

IM_UniqueIdentifier:
A 128-bit globally unique identification of the asset created by the manufacturer e.g. by means of ISO/IEC 9834-8:2014.

IM_Annotation:
A manufacturer-specific identifier of the asset such as the asset’s name as Unicode string8 with the length of 64 octets.

IM_OrderID:
The order ID of the asset as UnicodeString8 with the length of 64 octets.

AM_SoftwareRevision:
The edition of the software of the asset as UnicodeString8 with 64 octets.

IM_Software_Revision:
Software revision in a special I&M coding of VisibleString[9].

AM_HardwareRevision:
The edition of the hardware of the asset as UnicodeString8 with 64 octets.

IM_Hardware_Revision
The hardware revision in I&M coding.

IM_Serial_Number:
A unique production number of the asset set by the manufacturer as VisibleString16.

AM_DeviceIdentification:
The unique device identification in the address space of an organization like VendorID & DeviceID for PI. Or OUI for IO-Link.

AM_TypeIdentification:
Used to identify the family of the asset and assigned by the manufacturer like “IO controller”, “IO device”, “IO-Module”. Standard and manufacturer specific values are defined in [3].

5.3.2.3 Architecture

The architecture from Chapter 5.2.1 can be specialized for the usage within asset management. An asset management tool as OPC UA Client is connected to an OPC UA Server located in a PLC, Edge gateway or IO device. The PLC acts as IO controller for the underlying PROFINET system. The Edge gateway is scanning the underlying assets by means of DCP and implicit Read Services.

5.3.2.4 End User Requirements

The following end customer requirements are relevant for asset management. A more detailed description of these use cases can be found in [PN TAD].

The requirements are written from the perspective of an asset management tool user.

5.3.2.5 Asset discovery

The following use case describes the discovery of installed PROFINET assets.

5.3.2.6 Asset change detection

The following chapter describes criteria to detect changes in the assets. They may be useful to implement corresponding functionalities in the asset management tool.

5.3.2.6.1 Asset information changed

The user wants to be informed if assets in the plant or machine were changed. The following table describes criteria to detect changes.

Implements AM4.

5.3.2.6.2 Asset changed

The user wants to be informed if assets in the plant or machine were changed. The following table describes criteria to detect changes.

Implements AM4.

5.3.2.6.3 Asset installed

The user wants to be informed if assets in the plant or machine were added. The following table describes criteria to detect changes.

Implements AM5.

5.3.2.6.4 Asset removed

The user wants to be informed if assets in the plant or machine were removed. The following table describes criteria to detect changes.

Implements AM6.

5.3.2.6.5 Docking devices

Special cases in PROFINET are devices which are connected and disconnected to the network at runtime, like devices installed on a tool gripped by a robot. It is not guaranteed, that docking devices can be fully discovered by the scan cycle of Edge gateways. An IO controller may show information of docking devices in the local OPC UA Server.

5.3.2.6.6 Firmware or application program updated

One important use case of asset management is the detection of firmware updates in the plant or machine as well as a version change in a programmable application running on a PLC, robot or drive. The following table describes criteria to detect changes.

Implements AM2, AM3.

5.3.2.6.7 PROFIsafe device parameters changed

Sometimes it is important to know, if a safety parameter of a device in the plant or machine, set by an engineering tool, was changed. The following table describes criteria to detect changes.

Implements AM9.

5.3.2.6.8 Asset Localization changed

As special case for asset management is a change of a device in the physical topology. This is sometimes the case while finding errors in the field by exchange of devices.

Implements AM10.

5.3.3 PROFINET Diagnosis

5.3.3.1 General

PROFINET defines a comprehensive diagnostic model. The main focuses of this model are device diagnosis and network diagnosis. Diagnosis scenarios can appear during startup of a plant as well as during operation.

5.3.3.2 PROFINET Basics

Details of the PROFINET diagnosis concepts are contained in [PN Diag]. The main ideas are summarized in this chapter:

Each IO device maintains a global list of active diagnosis in a database called Diagnosis ASE.

All diagnosis entries are related to a channel of a submodule. The channel can represent a connected sensor or actor as well as the whole submodule. Submodule related diagnosis is marked with the channel number 0x8000.

If some relevant diagnosis or maintenance appears or disappears on a channel, an entry in the diagnosis ASE is added or removed. In this case, the IO controller is informed with diagnosis alarm to have event driven diagnosis information available in the PLC.

A supervisor like an Edge gateway or diagnosis tool can query the diagnosis ASE with a defined PROFINET record. If the ASE contains entries, the query is answered with a list of diagnosis entries. Otherwise the answer is empty to reduce the network load.

Each channel diagnosis entry contains a severity and a combination of error codes (see Figure 14). Some of these codes are system defined and can be decoded with the help of a general XML file available via PI. Vendor specific and profile specific error codes can be contained in the GSD file of the device.

5.3.3.3 Architecture

In the Diagnosis Use-Case a diagnosis tool is connected to a PLC, Edge gateway or the OPC UA Server of the device itself. The integrated OPC UA Server represents the subordinate PROFINET system or devices and their diagnosis state. There are differences in the available diagnosis information in IO controllers, Edge gateways or devices, which must be considered:

IO controller
An IO controller may form an OPC UA object model which is based on the expected configuration given by the engineering system. If there is no PROFINET connection (IOAR) between the controller and the device, the controller knows the reason (e.g. Device not found, duplicated names in the network, etc.). IO controllers are informed from the devices with a diagnosis alarm, if anything in the diagnosis ASE has been changed and may determine a time accurate diagnosis state.

Edge gateways:
An Edge gateway may show IO controllers and IO devices which can be discovered during the scanning process. An Edge gateway may determine the expected configuration of the devices with a normative record. The reason for an e.g. unreachable device can be different from an IO controller. Supervisors like Edge Gateways are not informed with an alarm if something in the diagnosis ASE of the devices has been changed. They can be as time accurate as the scanning time is configured.

Devices:
The IO device represents the diagnosis state of the included modules and submodules. In addition it knows if there is a running AR to the IO controller.

5.3.3.4 Use Cases

5.3.3.4.1 Discover differences between the expected configuration and the field

5.3.3.4.2 Discover reachable configuration

5.3.3.4.3 Connection Diagnosis

5.3.3.4.4 Submodule state diagnosis

5.3.3.4.5 Device diagnosis or maintenance update

5.3.3.4.6 Network diagnosis or maintenance

5.3.4 Read/Write Record

5.3.4.1 General

This use case describes the reading and writing of PROFINET records via objects in the OPC UA Server. This use case is intentionally not provided in this companion specification because access to low level data records is a potential security problem and the access to additional application data via the OPC UA Server shall be done in a high-level object-oriented access.

6 PROFINET OPC UA Information Model

Today OPC UA information models focused on the functional aspects of a dedicated device and the management of parameters in a device parameter set, are typically based on the OPC UA for Devices (DI) base information model (defined in [OPC 10000-100], referenced as OPC UA DI also in this document). In contradiction to this the I4.0 system modelling, including multiple aggregated devices and controllers, requires the representation of several different aspects of the system and therefore will lead to more sophisticated modelling approaches. Such a system model approach using four different independent partial models called “Facets”, linked together by typified references is shown in Figure 16. Here the Asset partial model contains an independent model related to orderable components (assets). The Physical Network partial model contains the independent model of the ethernet network structure. The PROFNET partial model contains all communication related aspects of the PN Controllers and Devices in the system. The Function partial model at least represents the application function aspect of the system. Objects out of the different partial models are connected to each other by typified references expressing semantic information about their relationship.

To be future proof and easily integrable to different base modelling approaches, this Companion Specification defines the PROFINET information model as an independent partial model using the OPC UA Interface and AddIn technology (See [OPC 10001-7]) . This gives the opportunity to connect the same unique PROFINET base information model to the OPC UA DI base model and to use the same PROFNET base model as partial model for the PROFINET communication aspect in the “Facet” modelling approach as shown in Figure 16.

The base information model in chapter 6.3 defines all common types of the PROFINET OPC UA information model.

The Annex B shows how to use the base information model together with OPC UA for Devices.

6.1 Conventions used in the mapping to PROFINET properties

The mentioned values are obtained by the blocks (optionally also subblocks) and fields given in the description. The following syntax is used: “Block | field”.

6.2 General conventions

All variables are read-only unless stated otherwise explicitly.

6.3 Base Information Model

6.3.1 OPC UA Object Types

The first 4 chapters of the base information model include the object types for the internal module/submodule structure of a PROFINET device and controller.

Figure 17 shows a simplified example for a module/submodule object structure. The container folders have been skipped in the figure.

The Device View includes devices in the PROFINET network and their real existing modules and submodules.

The Controller / Application View includes the PROFINET connections (Application Relationships) and the expected modules and submodules which have been configured in the PROFINET controller.

Both views relate to each other by non-hierarchical references.

The chapter 6.3.1.7 includes the object types for the PROFINET network mapping.

The chapter 6.3.1.8 includes the 2 object types for the asset identification within a PROFINET device.

6.3.1.1 Object instances lifetime

All object instances of the base information model represent the online view on the PROFINET network.

All PROFINET objects modeled in this specification are only created in the address space when the OPC UA Server detects their PROFINET counterpart. The objects are removed from the address space when the OPC UA Server detects their absence in the PROFINET network or PROFINET device.

The chapter 6.10 of [PN TAD] describes the possible ways of implementing the PROFINET device discovery. The chapter 11.3 of [PN TAD] describes the detection of the real modules and real submodules of a device and how to get their identification and asset data.

All these ContainerType objects only exist if objects are available in the container.

6.3.1.2 Domain

6.3.1.2.1 IPnDomainType

The Nodes object of the Domain includes all device and controller nodes which belong to the PROFINET domain.

6.3.1.3 Node

6.3.1.3.1 IPnEquipmentType

If the IM component is provided, it must contain the data of the representative submodule for the device in accordance with the I&M0FilterDataDevice block (See [PN TAD] – Identification & Maintenance).

The Assets and IM objects are optional. If the interface is used with the OPC UA facet model, the asset data can be part of another facet (See chapter 6 “PROFINET OPC UA Information Model” and Figure 16 – “Facet” modelling approach for I4.0 System Modelling).

The <Assets> objects are only assets which are directly related to this device. Assets related to the modules or submodules are components of these objects.

The server may provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the device object includes the diagnosis information of the whole device including the one of all real modules and real submodules. An OPC UA Server might provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

Mapping to PROFINET properties:

6.3.1.3.1.1 ShowLocation Method

This optional method shall trigger a perceivable signal which allows the identification of the physical device represented by the device object the method is invoked on. This is usually accomplished with a blinking LED.

The method has no parameters (no [in] and no [out] parameters) and no return value.

Signature

	ShowLocation (
		);

6.3.1.3.2 PnEquipmentContainerType

The <PnEquipments> shall have the references and components defined in Table 26 and Table 27.

Mapping to PROFINET properties:

6.3.1.3.3 IPnDeviceType

The BrowseName of a device object instance shall be the content of the NameOfStation variable of the first interface sub module. If the NameOfStation variable is not set, the content of the MAC Address variable of the first interface sub module shall be used. The MAC address string should use the canonical format (separated with -, e.g. AC-FD-CE-EC-03-80).

If the GSDDescription property is provided, it must contain the InfoText with Device Id from the GSD (see mapping table below).

Mapping to PROFINET properties:

6.3.1.3.4 IPnControllerType

6.3.1.4 Application Relationship

6.3.1.4.1 PnApplicationRelationType

The BrowseName of an application relationship object instance shall be the Id in standard GUID string format.

The Modules container object is the root of the configuration hierarchy consisting of the expected modules of the application relationship and their expected submodules (See chapter 6.3 - Base Information Model and Figure 17 – Object Structure).

The State variable has always the value CONNECTED on devices since the object only exists if an AR is established.

An IsPnApplicationRelationControllerInterface reference points to the interface object of the controller used for the AR. If the AR relates to the device an IsPnApplicationRelationDeviceInterface reference points to the interface object of the device. See sections 6.3.2.11 and 6.3.2.12 also.

Mapping to PROFINET properties:

6.3.1.4.2 PnApplicationRelationContainerType

Mapping to PROFINET properties:

6.3.1.5 Module

6.3.1.5.1 IPnModuleType

The properties Slot and IdentNumber must contain the data as described in the mapping table provided for the subtypes IPnRealModuleType and IPnExpectedModuleType.

Mapping to PROFINET properties:

6.3.1.5.2 IPnRealModuleType

The BrowseName of a module object instance shall be the content of the Slot variable in decimal number string format.

If the IM component is provided, it must contain the data of the representative submodule for the module in accordance with the I&M0FilterDataModule block (See [PN TAD] – Identification & Maintenance).

The server may provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the real module object includes the diagnosis information of the whole module including the one of the real submodules of the module. An OPC UA Server may provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

Mapping to PROFINET properties:

6.3.1.5.3 PnRealModuleContainerType

The <Modules> shall have the references and components defined in Table 35 and Table 36.

Mapping to PROFINET properties:

6.3.1.5.4 IPnExpectedModuleType

The BrowseName of a module object instance shall be the content of the Slot variable in decimal number string format.

An IsPnRealModule reference points to the real module which is the real realization of the expected module. See section 6.3.2.9 also.

Mapping to PROFINET properties:

6.3.1.5.5 PnExpectedModuleContainerType

The <Modules> shall have the references and subcomponents defined in Table 39 and Table 40.

Mapping to PROFINET properties:

6.3.1.6 Submodule

6.3.1.6.1 IPnSubmoduleType

The properties GSDName and GSDDescription must contain the data from the GSD, as described in the mapping table provided for the subtypes IPnRealSubmoduleType and IPnExpectedSubmoduleType.

6.3.1.6.2 IPnRealSubmoduleType

The BrowseName of a sub module object instance shall be the content of the Subslot variable in hexadecimal number string format (e.g. 0x8001).

If the IM component is provided, it must contain the data in accordance with the I&M0FilterDataSubmodule block (See [PN TAD] – Identification & Maintenance).

The server can provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the real submodule object includes only the diagnosis information of the real submodule. An OPC UA Server might provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

An IsPnInterface reference exists if the submodule is an interface submodule. See section 6.3.2.13 also.

An IsPnPort reference exists if the submodule is a port submodule. It points to the PnPortType object. See section 6.3.2.14 also.

Mapping to PROFINET properties:

6.3.1.6.3 PnRealSubmoduleContainerType

The <Submodules> shall have the references defined in Table 44 and Table 45.

Mapping to PROFINET properties:

6.3.1.6.4 IPnExpectedSubmoduleType

An IsPnRealSubmodule reference points to the real submodule which is the real realization of the expected submodule. See section 6.3.2.10 also.

Mapping to PROFINET properties:

6.3.1.6.5 PnExpectedSubmoduleContainerType

The <Submodules> shall have the references and subcomponents defined in Table 48 and Table 49.

Mapping to PROFINET properties:

6.3.1.6.6 PnSubmoduleStateType

Mapping to PROFINET properties:

6.3.1.7 Network

This chapter includes all object types needed to represent the physical network topology of a PROFINET network.

Figure 18 shows an example which illustrates the relations between network objects of a single port PROFINET device and a 4 port Ethernet switch.

The Ethernet interface, ports and cables are represented by objects in the address space. This Ethernet objects relate to each other by CommLinkTo references. This enables the OPC UA Server to represent the physical network topology of the PROFINET network.

6.3.1.7.1 IPnInterfaceType

The BrowseName of an interface object instance shall be the PROFINET interface id with the range 1..16 in decimal number string format.

The NameOfStation variable may be set with the SetNameOfStation method. Nevertheless, the variable itself shall always be read-only.

The CommLinkTo reference points to an EthernetInterfaceType object instance. An object of the IPv4FeatureType must be implemented in this EthernetInterfaceType object instance.

Mapping to PROFINET properties:

6.3.1.7.1.1 SetNameOfStation Method

This optional method writes the NameOfStation remanent to the PROFINET device and sets the NameOfStation variable accordingly.

Signature

	SetNameOfStation (
		[in]	String NameOfStation
		);
	

Method Result Codes

6.3.1.7.2 PnInterfaceContainerType

The <Interfaces> shall have the references defined in Table 53 and Table 54.

6.3.1.7.3 PnPortType

The PnPortType Object Type includes the port specific data of a port submodule.

A PnRealSubmoduleType instance representing a port submodule has an IsPnPort reference to a PnPortType object instance.

Mapping to PROFINET properties:

6.3.1.7.4 PnPortContainerType

6.3.1.7.5 PnPortStatisticType

The port statistic counters can be read from a PROFINET device with the Read PD Port Statistic PROFINET service.

6.3.1.7.6 NetworkComponentType

The NetworkComponentType is the abstract base ObjectType for different types of network components.

The Enabled variable indicates if the network component is activated (Enabled == True) or deactivated (Enabled == False).

6.3.1.7.7 EthernetInterfaceType

The EthernetInterfaceType is used to represent Ethernet network interfaces.

The MacAddress Variable is read only and represents the unique Layer2 source MAC address of the related interface.

Mapping to PROFINET properties:

6.3.1.7.8 EthernetPortType

The EthernetPortType is used to represent Ethernet ports.

The PhysAddress Variable is read only and contains a MAC address representing the Port.

6.3.1.7.9 NetworkComponentFeatureType

The NetworkComponentFeatureType is the abstract base ObjectType for different types of network components.

6.3.1.7.10 IPv4FeatureType

The IPv4FeatureType is used to represent IPv4 settings of a network interface.

Mapping to PROFINET properties:

The IpAddress Variable describes the IPv4 address on the interface.

The SubnetMask Variable describes the IPv4 Subnet mask on the interface.

The DefaultGateway Variable describes the IPv4 address of the default gateway.

The DhcpEnabled Variable specifies whether the DHCPv4 Client functionality for this interface is enabled.

6.3.1.8 Identification

6.3.1.8.1 PnIdentificationType

Mapping to PROFINET properties: