1 Scope

This document specifies the OPC UA Information Model to represent the Objects and services that comprise all kinds of drive characteristics and drive functionality in form of a drive functional model as defined in chapter 6.

OPC Foundation

OPC 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, authorisation 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 document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

OPC 10000-3, OPC Unified Architecture V1.05 - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture V1.05 - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture V1.05 - Part 5: Information Model

OPC 10000-5

OPC 10000-6, OPC Unified Architecture V1.05 - Part 6: Mappings

OPC 10000-6

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-8

OPC 10000-9, OPC Unified Architecture V1.05 - Part 9: Alarms and Conditions

http://www.opcfoundation.org/UA/Part9/

OPC 10000-18, OPC Unified Architecture - Part 18: Role-Based Security

OPC 10000-18

OPC 10000-23, OPC Unified Architecture V1.05 - Part 23: Common ReferenceTypes

OPC 10000-23

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

OPC 10000-81, OPC UA Field eXchange – Connecting Devices and Information Model –
Date: January 2023

http://www.opcfoundation.org/UA/FX/

OPC 40001-1, OPC UA for Machinery – Basic Building Blocks – Version 1.03.0 – Date: August 2023

http://www.opcfoundation.org/UA-Profile/Machinery/

OPC 40400-1, OPC UA for Powertrain – Asset Management – RC 1.0 – Date: Juni 2023

http://www.opcfoundation.org/UA-Profile/Powertrain/

OPC 30140 PN, OPC UA for PROFINET – Release V1.00.1 – Date: March 2021 –

Order No.: 30140

OPC 30142 RIO, OPC UA for PROFINET Remote IO – Release V1.0 – Date: May 2022

OPC 30143 ENC, OPC UA for PROFINET Encoder – Release V1.0 – Date: April 2023

Order No.: 30143

OPC 30144 GSD, OPC UA for PROFINET GSD Generic Model – Release V1.0 –

Date: June 2023 – Order No.: 30144

PI 3162 ENCP, Profile Drive Technology - Encoder Profile – Version 4.2 – Date: March 2017 –

Order No.: 3.162

PI 3172 PDP, Profile Drive Technology - PROFIdrive Profile - Version 4.2 –

Date: October 2015 – Order Nr:  3.172

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and Profile Drive Technology – Encoder Profile [PI 3162 ENCP] are understood in this document. This document will use these concepts to describe the PROFINET Drives 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-6, OPC 10000-7, OPC 10000-8, OPC 10000-9, OPC 10000-18, OPC 10000-23, OPC 10000-100, [OPC 10000-81], [OPC 40001-1], [OPC 40400-1], [OPC 30140 PN], [OPC 30142 RIO], [OPC 30143 ENC], [OPC 30144 GSD], [PI 3162 ENCP], [PI 3172 PDP] as well as the following apply.

Note that OPC UA terms and terms defined in this document are italicized in the document.

3.2 OPC UA for PROFINET Drives Terms from Profile Drive Technology – Encoder Profile [PI 3162 ENCP]

Excerpt from [PI 3162 ENCP], chapter 4.1.

3.2.1 Untitled

Data, which a device cyclically receives from the controller and which it outputs to the device application or the peripherals.

3.2.2 Untitled

Data, which a device cyclically sends to the controller.

3.2.3 Untitled

For Devices, all Input and Output Data (cyclic transmission).

3.2.4 Untitled

For a Drive Object (PROFIdrive), all Input and Output Data (cyclic transmission).

3.2.5 Untitled

For Devices, all data related to the control process (e.g. gain factor, state variables, …). The Process Data typically is mapped on parameters (access is with acyclic transmission).

3.3 Term defined for this document

3.3.1 Untitled

The Controller is a controlling device which is associated with one or more drives (axis). Related to the automation system, the Controller is the host for the overall automation (see [PI 3172 PDP], chapter 6.1.2).

3.3.2 Untitled

The P-Device (peripheral device) is a field device and the host device for the Drives (closed loop control, converter). The P-Device typically is associated with one or more Controller devices (see [PI 3172 PDP], chapter 6.1.2).

3.3.3 Untitled

The Supervisor typically is an engineering device which manages provisions of configuration data (parameter sets) and collections of diagnosis data from P-Devices and/or Controllers (see [PI 3172 PDP], chapter 6.1.2).

3.3.4 Untitled

A Drive Unit is a part of a P-Device containing one or multiple Drive Objects (see [PI 3172 PDP], chapter 6.1.2).

3.3.5 A Drive is understood in this specification as Device equipped with one or more motors controlled by the application which has control priority.

3.3.6 A PROFINET Drive is a Drive which is controlled over a PROFINET interface in normal operation.

3.3.7 Untitled

A Drive Object is a part of a Drive Unit and contains the Process Control Task. The Drive Object shall have Parameters as a minimum functionality (see [PI 3172 PDP], chapter 6.1.3.4).

3.3.8 Untitled

Drive Object type which is typically related to a motor (Drive Axis).

3.3.9 Untitled

A Telegram represents the cyclic data of one PN Submodule. A Telegram consists at least of one Input Telegram or of one Output Telegram or of both (see [OPC 30142 RIO], chapter 3.2.21). The Signals transmitted with one Telegram can be configured as described in [PI 3172 PDP], chapter 6.3.4.4.

3.3.10 Untitled

A Standard Telegram consists of Standard Signals supported by an Axis/DO which is specified in [PI 3172 PDP] and which can be configured to be included in the DO IO Data as described in [PI 3172 PDP], chapter 6.3.4.3.

3.3.11 Untitled

Signals are components of a Telegram.

3.3.12 Untitled

Standard Signals are defined as Signals which are part of a Standard Telegram. The Signals supported by a Axis/DO are defined in [PI 3172 PDP], chapter 6.3.4.2.

3.3.13 Untitled

A PN Submodule is the consumer or the provider of one Telegram and the addressable endpoint for PROFINET access (see [OPC 30142 RIO], chapter 3.2.25).

3.4 Abbreviated terms

Excerpt from [PI 3162 ENCP], chapter 4.2:

3.5 Conventions used in this document

3.5.1 Conventions for Node descriptions

3.5.1.1 Node definitions

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

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.6.2.2).

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 Other columns may be omitted and only a Comment column is introduced to point to the Node definition.

Each Type Node or well-known Instance Node defined shall have one or more ConformanceUnits defined in 10.1 that require the Node to be in the AddressSpace.

The relations between Nodes and ConformanceUnits are defined at the end of the tables defining Nodes, one row per ConformanceUnit. The ConformanceUnits are reflected in the Category element for the Node definition in the UANodeSet (see OPC 10000-6).

The list of ConformanceUnits in the UANodeSet allows Servers to optimize resource consumption by using a list of supported ConformanceUnits to select a subset of the Nodes in an Information Model.

When a Node is selected in this way, all dependencies implied by the References are also selected.

Dependencies exist if the Node is the source of HasTypeDefinition, HasInterface, HasAddIn or any HierarchicalReference. Dependencies also exist if the Node is the target of a HasSubtype Reference. For Variables and VariableTypes, the value of the DataType Attribute is a dependency. For DataType Nodes, any DataTypes referenced in the DataTypeDefinition Attribute are also dependencies.

For additional details see OPC 10000-5.

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

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.5.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.5.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.5.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.5.2 NodeIds and BrowseNames

3.5.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 document 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 document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document 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 document, because they are not defined by this document but generated by the Server.

3.5.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 11.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3. If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 56 provides a list of namespaces and their indexes as used in this document.

3.5.3 Common Attributes

3.5.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 document or if it is server-specific.

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

3.5.3.2 Objects

For all Objects specified in this document, the Attributes named in Table 8 shall be set as specified in the Table 8. The definitions for the Attributes can be found in OPC 10000-3.

3.5.3.3 Variables

For all Variables specified in this document, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.5.3.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.5.3.5 Methods

For all Methods specified in this document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information to PROFINET Drives and OPC UA

4.1 Introduction to PROFINET Drives

PROFINET is a widely used communication ecosystem for the OT level of industrial automation, and drives are a main component in automation systems for factory automation and process control. In the PROFINET ecosystem the PROFIdrive application profile is used for an interoperable drive interface on PROFINET and PROFIBUS. Because drives offer a lot of process and maintenance relevant information, they are predestined to offer their data via OPC UA to IT clients.

4.1.1 Drive Model

The PROFIdrive Drive Model is defined in [PI 3172 PDP] and defines the “Drive Object” (DO) as the main architectural element. The DO is the representative for the Drive Axis functionality further defined in [PDP] and is also used to represent additional auxiliary drive functionality like Infeed, Encoder and Control Units as an option. Therefore, being the main architectural object, the DO is used for the addressing of different axis within a Drive Device, by using the unique DO-ID or the assigned PROFINET module number. Figure 1 shows the PROFIdrive device model, where the P-Device represents the PROFINET Device hosting the Drive Objects as representatives for a Drive Axis functionality. The Drive Unit is used for internal Device structuring only and is not of further relevance for the functional information model.

4.1.2 Drive Object

The Drive Object (DO) is the main component of the Drive functional model. Figure 2 shows the general architecture of the PROFIdrive Drive Object and its related PROFINET communication services. Main purpose of this companion specification is the functional model of a Drive Axis which is contained in the blue “Process Control Task” block of Figure 2. All information’s about the “Process Control Task” are available as parameters in the related “Parameter Data Base” and therefore accessible via PROFINET acyclic communication and the related “Parameter Manager”. As an option, the “Setpoint Values” and “Actual Values” used to control the “Process Control Task” by PROFINET cyclic data telegrams, are also part of the OPC UA Axis Information Model (see folder PNSignals in Figure 10).

4.1.3 Axis type Drive Object

The main Drive Object types, which are the scope of standardization in the PROFIdrive profile, are of axis type. The Axis Drive Object types contain an electric, pneumatic or hydraulic actuator like a motor, together with the actor related control structures as shown in Figure 3. Mandatory functionality of all Axis Type Drive Objects is the Axis state machine for the control of the actor power stage and control functions. In addition, every Axis Type Drive Object offers a standardized fault buffer for the management and tracing of fault and warning situations of the axis. The amount and quality of control structures inside the Axis Drive Object is dependent on the overall application scenario, where the drive axis is embedded. For the classification of such standardized application scenarios, the PROFIdrive standard defines the PROFIdrive Application Classes.

Other logical objects which are defined in the context of a PROFIdrive Axis/DO:

Objects for DO identification.

Parameters for accessing information and settings of the individual function modules.

Objects for drive control (for example, control words and status words).

Objects for setpoint processing (for example, setpoint values and actual values).

Objects for diagnostics and monitoring (for example, messages, alarms, faults).

Objects for integrated sensor interface(s).

4.1.4 Axis types and PROFIdrive Application Classes

For the standardization of commonly used axis types PROFIdrive [PI 3172 PDP] defines the PROFIdrive Application Classes as defined in [PDP] and shown in Table 12. These Application Classes are the base for the definition of the DriveAxisTypes in this Companion Specification (see Figure 12).

4.1.5 Drive Communication Model

Most PROFINET Drives still support the PROFIdrive profile. PROFIdrive offers an interoperable interface for the access to standard parameters and vendor specific parameters. This offers the possibility for an edge device to use the PROFIdrive profile as a standardized interface for the access to drive data via PROFINET and PROFIBUS.

Nevertheless, the OPC UA information model of this specification is not limited to PROFIdrive devices, because the mandatory parts of the information model are independent from PROFIdrive and quite common to all drives, independent on their communication interface. Therefore, all drives with PROFINET interface and their own OPC UA Server on board can use the Information Model out of this specification. Additional benefit for drives with PROFIdrive (using PROFINET or PROFIBUS) is, that brownfield Devices can be represented by an OPC UA Server in an edge or proxy Device (like a PLC cell Controller) by using a generic mapping based on the PROFIdrive application model and using the PROFIdrive parameter channel as generic transport interface.

Figure 4 shows different possibilities for Vertical Communication and IT integration of PROFINET Drives in a typical automation scenario. Drive A in Figure 4 has it’s own OPC UA server on board. The onboard OPC UA Server of Drive A contains the standardized information model out of this companion specification and may contain in addition vendor specific extensions to the standardized Information Model as well as additional independent vendor specific Information Models. Because of PROFINET being real switched Ethernet, the PROFINET network in the OT areas is used to access the local OPC UA Servers in the OT area independent from the PROFNET communication.

Drives B, C and the Drive Axis modules in the IO-Station are brownfield Devices or cost sensitive Devices, offering only a PROFINET PROFIdrive interface without having an own OPC UA Server. For Vertical Communication and IT integration of these Drive Devices, they have to be proxied by an edge Device or the cell Controller PLC acting as proxy for the Information Model of the PROFINET Devices under its control. The proxy Devices use PROFINET communication and the PROFIdrive parameter channel to access data on the PROFIdrive Drive Devices in the OT level. With PROFIdrive Devices, the proxies can use a generic mapping of standardized PROFIdrive data into the standardized Information Model defined in this companion specification. In addition, also for these PROFINET only Devices, it is possible to extend the standardized Information Model by vendor specific extensions by using the PROFINET GSD Generic companion specification OPC UA part 30144 (see [OPC 30144 GSD]). With the GSD Generic approach, it is possible to advertise all information on additions to the OPC UA Information Model and related PROFINET data communication by additions to the standard PROFINET GSD. Therefore, the GSD Generic approach is easily applicable for brownfield Devices and plain PROFINET Devices.

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 Drives, 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 visualisation 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 a number of Attributes including a unique identifier called a NodeId and non-localized name called as 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 of 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 modeller 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 modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller 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 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 required 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 functionality (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. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of of what the data means in these 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

Table 13 lists possible use cases of interest for OPC UA Clients. Typically, the use case consists of utilization of OPC UA standard mechanisms and data processing at the Client site.

6 OPC UA for PROFINET Drives Functional Information Model Overview

6.1 Introduction to OPC UA for Drive Information Model

The Drive Information Model specifies Objects and Services representing Axis type Drive Objects. Although this specification uses concepts and definitions specified by the PROFIdrive profile (see [PI 3172 PDP]), the represented Drives do not necessarily comply to PROFIdrive. Instead, this specification aims to support all kinds of drives supporting a PROFINET communication interface. As a benefit for a PROFIdrive represented by the OPC UA information model out of this specification on an edge device, this specification defines the PROFIdrive parameter to be used to read out the variables and properties of the information model via acyclic PROFINET communication.

The comprehensive Information Model describes all aspects of a device or automation system, containing the asset partial model related to orderable components and the functional partial model related to the application function part of the system (see [OPC 30140 PN], chapter 6). The asset types to be used for the asset partial model are specified in [OPC 40400-1] (OPC UA for Powertrain, Part1: Asset Management). This specification document defines the functional model of a Drive axis, in a PROFIdrive device typically represented by a Drive Object. The possible connections (relations) enable the navigation between related Objects representing the same entity in different partial models are shown in [OPC 30140 PN], chapter 6; see D.1 also. For a Drive device it is also possible to add additional functional models like Energy Management [OPC PE] or analog and digital IO-Channels [OPC RIO] to the comprehensive Information Model, if this functionality is supported by the Drive device. For examples of the comprehensive Information Model see the appendix (see Figure 10).

OPC UA for PROFINET Drives defines all Objects and types provided by an OPC UA Server allowing OPC UA Clients to access data and services of Axis type Drive Objects by providing Axis Objects. As specified in [OPC 30142 RIO], the Information Model is divided into a PROFINET aspect and a functional aspect. The PROFINET aspect offers optional detailed Telegram information (See [OPC 30142 RIO]), the functional aspect provides an Information Model for Axis type Drive Objects. The optional Signal Objects (see [OPC 30142 RIO]) in the PROFINET aspect relate to components of the Axis Objects in the functional aspect by dedicated 0:RepresentsSameEntityAs References (see Figure 10).

The Axis Objects serve as the root containers for modelling of Axis type Drive Objects. The functional aspect of a Drive contains as many Axis Objects as needed to represent the Axis type Drive Objects of the PROFIdrive P-Device.

Figure 10 shows the organization of the Axis Object. The components of this DriveAxisType Object representing an Axis Object are part of the four different sub-aspects “Signals”, “Actual and Command Values”, “Diagnosis” and “Axis Properties”.

The concrete ObjectTypes representing Axis type Drive Objects like VelocityDriveAxisType (see section 7.2) and FrequencyDriveAxisType (see section 7.3) are derived from the abstract DriveAxisType base ObjectType (see section 7.1). The base type contains all Variables and Properties common for all Axis Objects.

Within the Axis Object, the mandatory “Actual and Command Values” sub-aspect is mainly consisting of Variables which contain the setpoint and measurement values of an axis like velocity and acceleration represented as physical values in floating point data types. These Variables are used to address the use case for axis monitoring on a control panel and the use case for data mining.

In the optional “Signals” sub-aspect, the “PNSignals” folder Object contains the Variables representing the Signal as transmitted in the PROFINET Telegram as Value. These “Signals” address the use case for supervision or debugging of the original Signal values transmitted between the Motion Controller and the Drive Axis. If such a Signal contains the same information as a Variable out of the “Monitoring” folder, the Variables of these two sub-aspects are connected using the 0:RepresentsSameEntityAs ReferenceType (see Figure 11). Note, that Variables which are connected by the 0:RepresentsSameEntityAs ReferenceType may have the same DataType and Value or may have different DataType and Value, e.g. the velocity actual value as monitoring Variable is represented in float and unit U/min, while as Signal Variable represented in INT32 and unit % and N4 normalized.

The “Diagnosis” sub-aspect yields diagnosis data by providing the DiagnosisAlarmType Events. The Logbook Object provides access to the DriveAxisType Object’s fault buffer.

The “Axis Properties” sub-aspect contains a collection of values which are of special interest for the functional identification and behaviour (configuration) of the Axis Object. These values are organized into several containers further structuring the sub-aspects.

Figure 11 shows a reduced Axis Object model with the relationships of the Signal Objects in the PROFINET aspect with the Variables providing concrete Values in the functional aspect. The figure shall give a basic understanding by demonstrating the model organization using Standard Signals transmitted with Standard Telegram 1 (see [PI 3172 PDP], chapter 6.3.4.3.2 and 6.3.4.4). As described, the transmitted Signals are given by the selection of one of the Standard Telegrams or by the setup of the free telegram configuration.

The “VelocityActualValue” and “VelocityCommandValue” 0:AnalogUnitType Variables in the “Actual and Command Values” sub-aspect contain the numeric representation of the “NIST_A” and “NSOLL_A” Standard Signals allowing Clients easy access to the numeric values of the represented Signals. The AxisState Variable contains the current state of the axis state machine, as it is encoded by related bits in value of the “ZSW1” Standard Signal. The AxisState Variable is encoded as 0:MultistateDiscreteType allowing Clients to obtain the state of the Axis/DO as numeric value as well as in string form. These Variables are linked to their Signal Variable counterpart in the “Signals” sub-aspect using 0:RepresentsSameEntityAs References (see Figure 11).

The “01_ZSW1”, “02_NIST_A”, “01_STW1” and “02_NSOLL_A” Signal Objects in the PROFINET aspect represent Standard Signals provided by the Axis Object. These Standard Signals are also linked to their counterpart Variables in the functional aspect of the Information Model using 0:RepresentsSameEntityAs References (see Figure 11).

The “ZSW1”, “NIST_A”, “STW1” and “NSOLL_A” Variables in the “Signals” sub-aspect provide the raw Signal Values encoded as unsigned integer data types.

6.2 PROFINET Drive Security

Servers shall allow Method invocation only for Sessions using user accounts with the right to invoke Methods. There shall exist user accounts with restricted rights (that is, no Method invocation unless explicitly allowed for all users for a specific Method) for Clients performing data acquisition or diagnosis also.

If well-known Roles are supported by the Server, role-based security (see [OPC 10000-18] shall be applied. Method invocation shall only be possible if the well-known “Operator” Role is granted to the Client’s Session. This applies to all Methods except for those where the restriction is lifted explicitly.

All Variables are read-only. Modifying the content of Variables shall only be possible by invoking a “Set-” Method.

7 OPC UA ObjectTypes

Figure 12 shows the organization of the ObjectTypes used to model Axis Objects. All Axis ObjectTypes are derived from the abstract DriveAxisType providing the functions common to all Axis ObjectTypes.

7.1 DriveAxisType

The DriveAxisType ObjectType contains the Variables and Properties common for all Axis Objects. This ObjectType is specified as abstract and cannot be used directly.

General Properties

The ApplicationTag Variable contains information given by the overall application. The purpose is to provide additional semantic information about the represented Axis/DO role or labelling in the context of the specific overall application context (machine, site or plant). Therefore, plant operators and/or application engineers are responsible to set the content of the ApplicationTag with information used for site management, asset management or other administrative purposes, e.g. “Production Line <m>/Machine <n>/x-Axis”. Furthermore, information like “tag-function” out of the PROFINET I&M-1 record or the “descriptor” out of the I&M-3 record may be used as content of the ApplicationTag Variable.

However, as a default, vendors might generate the ApplicationTag string out of the PROFINET device structure given by standard PROFINET configuration data as initial content of the Variable. The generic default string is “<NameOfStation>/Drive Axis Nr. <axis number>”, where the <NameOfStation> is the NameOfStation of the PROFINET Drive device and the <axis number> is the PROFINET device module number representing the related PROFIdrive axis DO.

The Client can change the Value of this Variable by invoking the SetApplicationTag Method.

Before invoking a Method of the DriveAxisType Object, Clients must gain exclusive write access (“lock” the DriveAxisType Object) using the Lock Object.

The Lock Object ensures exclusive Method call for one Client. The Client locks the DriveAxisType Object by invoking the InitLock Method of the Lock Object. The Client invokes ExitLock to release the lock. The scope of the lock comprises all components of the DriveAxisType Object.

SetApplicationTag Method

This Method sets the Value of the ApplicationTag Variable. The security constraints defined in chapter 6.2 apply.

Signature

	SetApplicationTag (
		[in] 0:String	 ApplicationTag
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 15.

The AxisType Property contains the mechanical drive type of the represented Axis/DO modelled as AxisTypeVariableType (see 9.1).

The Value shall be 0 (reference “LINEAR_MOTION”) for linear axis drives and 1 (reference “ROTATORY_MOTION”) for rotatory axis drives.

Some components of the DriveAxisType have additional subcomponents which are defined in Table 16. For detailed descriptions of the Variables see Table 33.

The child Nodes of the DriveAxisType have additional Attribute values defined in Table 17.

PNSignals folder in Signals sub-aspect

The PNSignals folder contains Signal Variables representing the Signals as defined in [PI 3172 PDP], chapter 6.3.4.2, Table 86. The supported Standard Signals are determined by the configured Standard Telegram modular telegram configuration and may also be freely configured (see [PI 3172 PDP], chapter 6.3.4.4). The Axis/DO IO Data configuration may also contain profile- or vendor-specific Signals with signal No. 100 and greater.

The Server shall provide as many <SignalName> Variables as are needed to represent the configured Signals. The placeholder template string shall be replaced with the Signal’s abbreviation as specified in [PI 3172 PDP], Table 86. For profile- and vendor specific Signals the abbreviations specified by the profile or vendor apply. For vendor specific Signals, the SignalNumber Property shall always be provided for the representing Signal Variable.

The DataType provided for the Signal Variables shall be provided according to the length of the Signal as specified in [PI 3172 PDP], chapter 6.3.4.2, Table 86: For 16-bit Signals, the DataType shall be 0:UInt16. For 32-bit Signals, the DataType shall be 0:UInt32. For Signals with sign, the corresponding signed DataTypes 0:Int16 and 0:Int32 shall be provided.

Monitoring folder in Actual and Command Values sub-aspect

The Monitoring folder contains Monitoring Variables describing measurements of the Axis/DO which are of interest for monitoring (see derived Axis/DO ObjectTypes and Table 33) encoded as numeric data type. If the corresponding Standard Signal is configured and its representation is provided in the PNSignals folder, the Monitoring Variable shall be linked to the Signal Variable using a 0:RepresentsSameEntityAs ReferenceType.

Figure 13 Shows the possible components of the “Monitoring” folder common for all derived Axis Object types, as described in Table 16.

The AxisState Variable contains the actual state of the Axis/DO internal state machine modelled as 0:MultiStateDiscreteType defined in [OPC 10000-8].

The ControlPriority Variable contains the leading control context (PROFIBUS, PROFINET, setup tool, …) of the Axis/DO also modelled as 0:MultiStateDiscreteType.

The ControlMode Variable contains the currently active control function in the overall control cascade modelled as 0:MultiStateDiscreteType.

The content of the EnumStrings lookup table Property is defined in Table 17 for all these 0:MultiStateDiscreteType Variables. The “Locale” field of the 0:LocalizedText structures is Server specific.

For a description of all Variables and Properties in the “Monitoring” folder see Table 33.

Maintenance folder in Axis Properties sub-aspect

The Maintenance folder contains optional properties defined by the 2:IOperationCounterType Interface specified in [OPC 10000-100] as well as parameters yielding capacity related information. Figure 14 shows the possible components of the “Maintenance” folder common for all derived Axis Object types, as described in Table 16.

For a description of the Variables and Properties in the “Maintenance” folder see Table 33.

LimitSupervision folder in Axis Properties sub-aspect

The LimitSupervision folder contains Variables with Values describing limit values for motor current, torque, and the like. These limit Variables differ between concrete derived Axis ObjectTypes and are specified separately for each derived Axis ObjectType.

For a description of the Variables in the “LimitSupervision” folder see Table 33.

CharacteristicsConverter folder in Axis Properties sub-aspect

The CharacteristicsConverter folder contains Variables with Values describing key data of the Drive’s converter. Figure 15 shows the possible components of the “CharacteristicsConverter” folder common for all derived Axis Object types, as described in Table 16.

For a description of the Variables in the “CharacteristicsConverter” folder see Table 33.

CharacteristicsMotorAndControl folder in Axis Properties sub-aspect

The CharacteristicsMotorAndControl folder contains Variables with Values describing key data of the Drive’s motor and its key control features. Figure 16 shows the possible components of the “CharacteristicsMotorAndControl” folder common for all derived Axis Object types, as described in Table 16.

The FeedbackMode Variable shall contain the Value “FEEDBACK_SENSOR_1” if only one sensing device is present, which is the motor sensor in this case.

For a description of the Variables in the “CharacteristicsMotorAndControl” folder see Table 33.

VelocityProfile folder in Axis Properties sub-aspect

The VelocityProfile folder contains Variables describing key properties of brake ramps. The folder contains the properties mandatory for each derived Axis Object types. Figure 17 shows the components of the “VelocityProfile” folder common for all derived Axis Object types, as described in Table 16.

Diagnosis sub-aspect

The 3:LogbookType Object defined in [OPC 30143 ENC] provides Methods for accessing the Drive’s fault buffer (see [PI 3172 PDP] Fault Buffer Mechanism). These Methods can be used by Clients to obtain the active diagnosis entries (that is, get all fault entries without “Event going” timestamp) or apply custom filter criteria (see [OPC 30143 ENC] chapter 7.5 LogbookType for details). In conjunction with establishing a Subscription for one of the supported EventTypes of the 3:LogbookType Object Clients can synchronize themselves with the current diagnosis status and will receive Notifications for each change of the diagnosis status subsequently, such as coming, going and the like. The possible values for the EventCode are defined in [PI 3172 PDP], see Table 57.

The Server might provide DiagnosisAlarmType Events and / or 3:LogbookEventType Events.

Safety Object in Actual and Command Values sub-aspect

The optional SafetyType Object has SafetyFunctionType Object components describing safety functions. For each available safety function, basic settings regarding selection and activation status are provided (see 7.8 and 7.9).

7.2 VelocityDriveAxisType

The VelocityDriveAxisType is an DriveAxisType with a speed command interface. Figure 18 shows a block diagram demonstrating the basic organization and control flow for this axis type. If the Drive is a PROFIdrive the VelocityDriveAxisType is used to represent AC1 Drive Objects using a speed command interface.

Figure 19 shows the components added by the VelocityDriveAxisType ObjectType to the DriveAxisType it is derived from.

The formal definition of the VelocityDriveAxisType ObjectType can be found in Table 18.

The components of the VelocityDriveAxisType have additional subcomponents which are defined in Table 19.

7.3 FrequencyDriveAxisType

A FrequencyDriveAxisType is a DriveAxisType with a frequency command interface. Figure 20 shows a block diagram demonstrating the basic organization and control flow for this axis type. If the Drive is a PROFIdrive, the FrequencyDriveAxisType is used to represent AC1 Drive Objects using a frequency command interface.

Figure 21 shows the components added by the FrequencyDriveAxisType ObjectType to the DriveAxisType it is derived from.

The formal definition of the FrequencyDriveAxisType ObjectType can be found in Table 20.

The components of the FrequencyDriveAxisType have additional subcomponents which are defined in Table 21.

7.4 PositioningDriveAxisType

A PositioningDriveAxisType is an DriveAxisType with a motion trajectory command interface. Figure 22 shows a block diagram demonstrating the basic organization and control flow for this axis type. If the Drive is a PROFIdrive the PositioningDriveAxisType is used to represent AC3 Drive Objects using a motion trajectory command interface (program submode or MDI submode).

Figure 23 shows the components added by the PositioningDriveAxisType ObjectType to the DriveAxisType it is derived from.

The formal definition of the PositioningDriveAxisType ObjectType can be found in Table 22.

Some components of the PositioningDriveAxisType have additional subcomponents which are defined in Table 23.

7.5 VelocityServoDriveAxisType

A VelocityServoDriveAxisType is an DriveAxisType with a velocity command interface. Figure 24 shows a block diagram demonstrating the basic organization and control flow for this axis type. If the Drive is a PROFIdrive, the VelocityServoDriveAxisType is used to represent AC4 Drive Objects using a speed command interface.

Figure 25 shows the components added by the VelocityServoDriveAxisType ObjectType to the DriveAxisType it is derived from.

The formal definition of the VelocityServoDriveAxisType ObjectType can be found in Table 24.

Some components of the VelocityServoDriveAxisType have additional subcomponents which are defined in Table 25.

7.6 PositionServoDriveAxisType

A PositionServoDriveAxisType is an DriveAxisType with a position command interface. Figure 26 shows a block diagram demonstrating the basic organization and control flow for this axis type. If the Drive is a PROFIdrive the PositionServoDriveAxisType is used to represent AC5 Drive Objects.

Figure 27 shows the components added by the PositionServoDriveAxisType ObjectType to the DriveAxisType it is derived from.

The formal definition of the PositionServoDriveAxisType ObjectType can be found in Table 26.

Some components of the PositionServoDriveAxisType have additional subcomponents which are defined in Table 27.

7.7 TraversingTaskType

The TraversingTaskType represents a traversing task.

The TraversingTaskNumber Variable contains the number of the traversing task currently executed. Interpretation of TraversingTaskNumber:

If no traversing task is executed (TraversingTaskNumber == -1), the Value of all other Variables shall be 0. If a traversing task is executed (TraversingTaskNumber >=0), the AxisState Variable contains one of the values belonging to the S45 sub state machine (see [PI 3172 PDP], Figure 35 also).

The TargetPosition Variable contains the target position for the traversing task generator.

The Velocity Variable contains the desired speed for the traversing task generator.

The Acceleration Variable contains the desired acceleration for the traversing task generator.

The PositioningMode Variable contains the information if the TargetPosition Variable has to be interpreted as absolute or relative position encoded as 0:MultiStateDiscreteType defined in [OPC 10000-8]. The StateMachineState Variable contains the state of the positioning mode substate machine also encoded as 0:MultiStateDiscreteType. The content of their EnumStrings lookup table Properties is defined in Table 29.

The following table contains descriptions of the semantic for all possible Values of the PositioningMode Variable.

7.8 SafetyType

The SafetyType contains SafetyFunctionType Variables describing basic settings for safety functions.

The STO Object represents the status of the “Safe torque off” safety function.

The SS1 Object represents the status of the “Safe stop 1” safety function.

The SS2 Object represents the status of the “Safe stop 2” safety function.

The SOS Object represents the status of the “Safe operating stop” safety function.

The SLS Object represents the status of the “Safely limited speed” safety function.

The SDI Object represents the status of the “Safe direction” safety function.

The SLA Object represents the status of the “Safely limited acceleration” safety function.

The SLP Object represents the status of the “Safely limited position” safety function.

If a specific safety function is supported by the Axis/DO, the representing SafetyFunctionType Object shall be provided.

7.9 SafetyFunctionType

The SafetyFunctionType represents the status of one safety function.

The SelectionState Variable represents the selection status of the represented safety function.

The ActivationState Variable represents the activation status of the represented safety function.

The Limit Variable represents the speed limit if representing the SLS safety function or the acceleration limit if representing the SLA safety function. Shall only be provided for these two safety functions.

7.10 OPC UA Variable Mapping to Drive Properties

Table 33 lists the OPC UA Variables and the drive properties represented by those Variables which are components of the drive ObjectTypes above.

The Variables listed are components of a parent folder which belongs to the Axis Object. The parent folder is specified in the row preceding the rows specifying the Variables which belong to this very folder.