1 Scope

This specification was created by a joint working group of the OPC Foundation and the Ethernet POWERLINK Standardization Group (EPSG). It defines an OPC UA Information Model to represent the models from Ethernet POWERLINK.

OPC Foundation

The OPC Foundation defines standards for online data exchange between automation systems. They address access to current data (OPC DA), alarms and events (OPC A&E) and historical data (OPC HDA). Those standards are successfully applied in industrial automation.

The new OPC Unified Architecture (OPC UA) unifies the existing standards and brings them to state-of-the-art technology using service-oriented architecture (SOA). Platform-independent technology allows the deployment of OPC UA beyond current OPC applications only running on Windows-based PC systems. OPC UA can also run on embedded systems as well as Linux / UNIX based enterprise systems. The provided information can be generically modelled and therefore arbitrary information models can be provided using OPC UA.

Ethernet POWERLINK Standardization Group

The Ethernet POWERLINK Standardization Group (EPSG) was founded in 2003 as an independent association. Its goals are the standardisation, promotion and further development of POWERLINK technology, which was first presented to the public in 2001. POWERLINK is a patent-free, manufacturer-independent and completely software-based communication system for hard real-time that has been available as a free open source solution since 2008. The EPSG's POWERLINK office handles public relations, coordinates the implementation of shared projects and provides information for existing and prospective members.

The EPSG is working closely with the CiA (CAN in Automation) organisation to integrate CANopen with POWERLINK. CANopen is one of the most widely used application protocols today. Key benefits of this protocol include standardised device description files that make status information, parameter configurations, device characteristics and other relevant data available in transparent form on the network. A major decision made by the EPSG was to define the protocol's application layer as a carrier of all CANopen mechanisms. CiA, the international association of CAN users and manufacturers, was significantly involved in this development.

Ethernet POWERLINK uses the same concepts as CANopen for object dictionaries, device descriptions and communication mechanisms including process data objects (PDOs), service data objects (SDOs) and network management (NMT). As with CANopen, direct cross-traffic is also one of the essential features of POWERLINK. All CANopen applications and device profiles can be directly implemented in POWERLINK environments as well – the applications will not see a difference between the two protocols. For this reason, POWERLINK can also be referred to as "CANopen over Ethernet".

2 Reference documents

3 Terms, definitions, and conventions

3.1 Use of terms

Defined terms of OPC UA specifications, types and their components defined in OPC UA specifications and in this specification are highlighted with italic in this document.

Certain Ethernet POWERLINK related terms and names are used together with POWERLINK, especially in cases where the terms might lead to naming conflicts with existing OPCUA terms. For instance the term Managing Node (a device role in POWERLINK) contains the word Node that has a different meaning in OPC UA.

Table 1 contains a list with the most prominent examples for common terms that have different meanings in OPC UA and POWERLINK.

3.2 OPC UA for POWERLINK Information Model terms

For the purposes of this document, the terms and definitions given in the referenced OPC UA Specifications as well as the following apply.

3.2.1 Asynchronous POWERLINK Data

data in a POWERLINK network that is not time critical

3.2.2 Deterministic Communication

communication process with predictable timing behaviour (I.e. the time when a message reaches the recipient is predictable)

3.2.3 Isochronous POWERLINK Data

data in a POWERLINK network which is to be transmitted every cycle (or every nth cycle in case of multiplexed isochronous data)

3.2.4 Legacy Ethernet

ethernet as standardised in IEEE 802.3 (non-deterministic operation in non-time-critical environments)

3.2.5 NMT State

Network Management State of a POWERLINK Device

3.2.6 POWERLINK Controlled Node

POWERLINK Device without the ability to manage the SCNM mechanism

3.2.7 POWERLINK Device Profile

standardised or vendor specific definition of an object model

3.2.8 POWERLINK Managing Node

POWERLINK Device capable to manage the SCNM mechanism in a POWERLINK network

3.2.9 POWERLINK Device

device in a POWERLINK network

3.2.10 POWERLINK Object

data object, addressed by Index and Sub-Index

3.2.11 POWERLINK Object Dictionary

repository of all POWERLINK Objects accessible over POWERLINK communications

3.2.12 POWERLINK Record

record data type (as defined in the POWERLINK specification EPSG DS 301)

3.2.13 POWERLINK XML Device Description

XML file for the description of the objects in a POWERLINK Object Dictionary (also called XDD)

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. That implies that the referenced Node has a HasModelParent Reference with the Node defined in the Table as TargetNode (see OPC 10000-3 for the definition of ModelParents).

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. In Table 3 examples are given.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a NodeId of a TypeDefinitionNode, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding TypeDefinitionNode. The symbolic name of the NodeId is used in the table.

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 of this document points to their definition.

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, i.e. 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.2.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 document 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 namespace for this specification is defined in Annex A. The NamespaceIndex for all NodeIds defined in this specification is server specific and depends on the position of the namespace URI in the server namespace table.

Note: This specification does not only define concrete Nodes, but also requires that some Nodes have to be generated, for example one for each device type available in the frame application. 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 by 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 server specific and depends on the position of the namespace URI defined in this specification in the server namespace table.

If the BrowseName is not defined by this specification, a NamespaceIndex prefix like ‘0:EngineeringUnits’ 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 56 provides a list of namespaces used in this specification.

3.4.3 Common Attributes

3.4.3.1 General

For all Nodes specified in this specification, the Attributes named in Table 4 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 5 shall be set as specified in the table.

3.4.3.3 Variables

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

3.4.3.4 VariableTypes

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

4 General information about Ethernet POWERLINK and OPC UA

4.1 Introduction to Ethernet POWERLINK

4.1.1 General

Ethernet POWERLINK is a communication profile for Real-Time Ethernet (RTE). It extends Ethernet according to the IEEE 802.3 standard with mechanisms to transfer data with predictable timing and precise synchronisation. The communication profile meets timing demands typical for high-performance automation and motion applications. It does not change basic principles of the Fast Ethernet Standard IEEE 802.3 but extends it towards RTE. Thus, it is possible to leverage and continue to use any standard Ethernet silicon, infrastructure component or test and measurement equipment like a network analyser.

POWERLINK provides mechanisms to achieve the following:

Transmit time-critical data in precise isochronous cycles. Data exchange is based on a publish/subscribe relationship. Isochronous data communication can be used for exchanging position data of motion applications of the automation industry.

Synchronise networked POWERLINK Devices with high accuracy.

Transmit less time-critical data asynchronously on request. Asynchronous POWERLINK Data communication can be used to transfer IP-based protocols like TCP or UDP and higher layer protocols such as HTTP, FTP, etc.

POWERLINK manages the network traffic in a way that there are dedicated time-slots for Isochronous and Asynchronous POWERLINK Data. It takes care that always only one networked device gains access to the network media. Thus, transmission of Isochronous POWERLINK Data and Asynchronous POWERLINK Data will never interfere and precise communication timing is guaranteed. The mechanism is called Slot Communication Network Management (SCNM). SCNM is managed by one particular networked device – the POWERLINK Managing Node (MN) – which includes the MN functionality. All other nodes are called POWERLINK Controlled Nodes (CN).

4.1.2 Key features

POWERLINK provides the following key features:

Ease-of-Use to be handled by typical automation engineers without in-depth Ethernet network knowledge.

Up to 240 networked real-time devices in one network segment

Deterministic communication guaranteed

Down to 100 μs cycle times

Ultra-low jitter (down to <1μs) for precise synchronisation of networked devices

Standard compliant

IEEE 802.3 Fast Ethernet

IP based protocols supported (TCP, UDP, etc.)

Integration with CANopen profiles EN 50325-4 for device interoperability

Implementation based on standard Ethernet chips - no special ASICs necessary

Direct peer-to-peer communication of all POWERLINK Devices (publish/subscribe)

Hot plugging

Seamless IT-integration – routing of IP protocols

POWERLINK supports Client/Server and Producer/Consumer communication relationships.

The POWERLINK communication profile is based on CANopen communication profiles DS301 and DS302. Based on these communication profiles, the multitude of CANopen device profiles can be used in a POWERLINK environment without changes.

A main focus of POWERLINK is ease of use. Ethernet technology can be quite complex and confusing for machine and plant manufacturers, which are not necessarily networking experts. The following features have thus been implemented:

Easy wiring, flexible topologies (line structures, tree structures or star structures). The network is adapting to the needs of the machine.

Utilisation of well-known industrial infrastructure components

Simple address assignment by switch is possible

Easy replacement of devices in case of failure

Straight-forward network diagnostics

Simple engineering separated from end user IT infrastructure

Easy integration of RTE network with IT infrastructure

4.1.3 POWERLINK device model

A POWERLINK Device is structured as follows (see Figure 2):

Communication – This function unit provides the communication objects and the appropriate functionality to transport data items via the underlying network structure.

POWERLINK Object Dictionary – The POWERLINK Object Dictionary is a collection of all the data items that have an influence on the behaviour of the application objects, the communication objects and the state machine used on this device.

Application – The application comprises the functionality of the device with respect to the interaction with the process environment.

Thus the POWERLINK Object Dictionary serves as an interface between the communication and the application. The complete description of a device’s application with respect to the data items in the POWERLINK Object Dictionary is called the device profile.

4.1.4 POWERLINK Object Dictionary

The most important part of a POWERLINK profile is the POWERLINK Object Dictionary. The POWERLINK Object Dictionary is essentially a grouping of POWERLINK Objects accessible via the network in an ordered, pre-defined fashion. Each object within the dictionary is addressed using a 16-bit index.

The overall layout of the standard POWERLINK Object Dictionary is shown by Table 8. This layout closely conforms to other industrial serial bus system concepts.

The POWERLINK Object Dictionary may contain a maximum of 65536 entries which are addressed through a 16-bit index.

The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types like BOOLEAN, INTEGER, floating point, string, etc. These entries are included for reference only; they cannot be read or written.

Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of standard data types and are common to all devices.

Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composed of standard data types but are specific to a particular device.

Device Profiles may define additional data types specific to their device type. The static data types defined by the device profile are listed at indices 0060h - 007Fh, the complex data types at indices 0080h - 009Fh.

A device may optionally provide the structure of the supported complex data types (indices 0020h - 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-Index 0 provides the number of entries at this index, and the following sub-indices contain the data type encoded as UNSIGNED16 according to 7.1 Primitive DataTypes.

POWERLINK Specific Static Data Types shall be described at indices 0400h – 041Fh. These entries are included for reference only; they cannot be read or written. POWERLINK Specific Complex Data Types shall be described at indices 0420h – 04FFh

The Communication Profile Area at indices 1000h through 1FFFh contains the communication specific parameters for the POWERLINK network. These entries are common to all devices and addressed by this companion specification.

4.1.5 Index and Sub-Index usage

A 16-bit index is used to address all entries within the POWERLINK Object Dictionary. In the case of a simple variable, the index references the value of this variable directly. In the case of records and arrays, however, the index addresses the whole data structure.

To allow individual elements of structures of data to be accessed via the network a Sub-Index is defined. For single POWERLINK Object Dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32 etc. the value for the Sub-Index is always zero. For complex POWERLINK Object Dictionary entries such as arrays or records with multiple data fields the Sub-Index references fields within a data-structure pointed to by the main index. The fields accessed by the Sub-Index can be of differing data types.

4.2 Introduction to OPC Unified Architecture

4.2.1 General

The main use case for OPC standards is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC DA provides functionality to browse through a hierarchical namespaces containing data items and to read, write and to monitor these items for data changes. The classic OPC standards are based on Microsoft COM/DCOM technology for the communication between software components from different vendors. Therefore classic OPC server and clients are restricted to Windows PC based automation systems.

OPC UA incorporates all features of classic OPC standards like OPC DA, A&E and HDA but defines platform independent communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose.

The OPC UA network communication part defines different mechanisms optimised for different use cases. The first version of OPC UA is defining an optimised binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security, access control and reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers.

The OPC UA Information Model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed.

The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines eight classes of Nodes to represent AddressSpace components. The classes are Object, Variable, Method, ObjectType, DataType, ReferenceType and View. Each NodeClass has a defined set of Attributes.

This specification makes use of three essential OPC UA NodeClasses: Objects, Methods and Variables.

Objects are used to represent components of a system. An Object is associated to a corresponding ObjectType that provides definitions for that Object.

Methods are used to represent commands or services of a system.

Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them. An example for Properties of Objects is the PowerlinkAttributes Property of the PowerlinkVariableType.

DataVariables represent the contents of an Object. DataVariables may have component DataVariables. This is typically used by Servers to expose individual elements of arrays and structures. This specification uses DataVariables to represent data like the CumulativeCount_U32 of a DLL_ErrorCntRec_Type Object.

4.2.2 Graphical notation

OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualised. Figure 3 shows the symbols for the six NodeClasses used in this specification. NodeClasses representing types always have a shadow.

Figure 4 shows the symbols for the ReferenceTypes used in this specification. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubtype Reference. The most important References like HasComponent, HasProperty, HasTypeDefinition and HasSubtype have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol.

Figure 5 shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubtype Reference. The Object_A has the components Variable_1, Variable_2 and Method_1.

To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType like for ObjectType_Y in the example. The instance Nodes used to describe an ObjectType are instance declaration Nodes.

To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol.

4.3 Use cases

4.3.1 Access to a POWERLINK Object Dictionary from an OPC UA Client

An OPC UA Client can use standard OPC UA Services to browse and access POWERLINK Objects defined in this document.

Possible use cases for this access are diagnostics, condition monitoring, configuration management, visualisation etc.

Figure 6 shows logical links between an OPC UA Client and a POWERLINK Object Dictionary.

Since OPC UA Clients are typically operating in standard Ethernet networks using CSMA/CD and the POWERLINK network uses SCNM the physical connection will be established through standard TCP/IP routing mechanisms which may be implemented on the POWERLINK Managing Node (Figure 7) or on a POWERLINK Controlled Node (Figure 8).

Another option to access POWERLINK Objects is an OPC UA Server that represents a group of POWERLINK Devices within one Information Model as shown in Figure 9.

4.3.2 Access to POWERLINK Objects through untrusted networks

The SDO protocol defined by POWERLINK is a Client/Server protocol to access POWERLINK Objects in a POWERLINK Object Dictionary, but this protocol does not support security.

The definition of SDO services over OPC UA allows secure SDO connections between POWERLINK Devices using the standard security mechanisms provided by OPC UA.

5 POWERLINK model overview

5.1 Overview

Figure 11 shows the general model and the central object types of this companion specification.

POWERLINK Objects are represented by OPC UA Variables as part of the PowerlinkConnectionPointType and its subtypes. A PowerlinkConnectionPointType contains common Variables while the subtypes contain only the Variables that are specific to the POWERLINK Controlled Node and the POWERLINK Managing Node.

Instances of subtypes of PowerlinkConnectionPointType are used to represent the POWERLINK Object Dictionary of a POWERLINK Device. The subtypes of ConnectionPointType are used to extend a Device (not limited to PowerlinkDeviceType) by one or more POWERLINK Object Dictionaries.

The PowerlinkDeviceType is used to represent a typical POWERLINK Device and defines a standardised way to generate the mandatory Properties for a DeviceType (like SerialNumber, RevisionCounter, etc.) from values of certain POWERLINK Objects. In case a Device implements more than one POWERLINK interface (by implementing multiple ConnectionPoints), the selection of the ConnectionPoint as source for the DeviceType Properties is implementation specific.

Figure 12 shows an example for a Device (DeviceExample1) that implements an instance of a POWERLINK Controlled Node and another Device (DeviceExample2) that implements two instances of a POWERLINK Managing Node.

The focus of this document is the detailed specification of the POWERLINK Objects of the communication profile EPSG DS 301 and EPSG DS 302, but it also defines the modelling rules for the implementation of specific POWERLINK Device Profiles.

Figure 13 shows how to add device profile specific POWERLINK Objects to the existing definition for the communication profile. The modelling rules are defined in 5.2.

5.2 Modeling concepts

5.2.1 POWERLINK Objects and their attributes

One of the very significant differences between POWERLINK and OPC UA is that OPC UA provides metadata to each object directly through the Server, whereas POWERLINK can transport metadata only through XDD files or specification documents. Table 9 and Table 10 show examples for object definitions in the POWERLINK Communication Profile EPSG DS 301.

Figure 14 shows the same information in the XDD format defined in EPSG DS311.

Table 11 lists the attributes that are specified for POWERLINK Objects, and how they are mapped to OPC UA mechanisms.

5.2.2 PowerlinkArrayType

The VariableType PowerlinkArrayType is formally defined in Table 12 and represents POWERLINK Objects of the type ARRAY as defined in 5.2.

The Property PowerlinkAttributes provides the information of the XML-Attribute ‘accessType’ from the POWERLINK XML Device Description.

The Property Index provides the Index of the object in the POWERLINK Object Dictionary.

The Property NumberOfEntries provides the value of Sub-Index 0 of the POWERLINK Object. For most POWERLINK Objects this value is read-only. For a few, like ERR_History_ADOM or PDO_RxMappParam_XXh_AU64, this Property is also writable.

The optional Property Range provides the Value Range of the array elements.

The optional Property DefaultValue provides the default value of the array elements. The DataType of this Property shall be identical to the DataType of the DataVariable itself.

5.2.3 PowerlinkRecordType

The VariableType PowerlinkRecordType is formally defined in Table 13 and represents POWERLINK Objects of the type RECORD as defined in 5.2.

The Property Index provides the Index of the object in the POWERLINK Object Dictionary.

The Property NumberOfEntries provides the value of Sub-Index 0 of the POWERLINK Object.

5.2.4 PowerlinkVariableType

The VariableType PowerlinkVariableType if formally defined in Table 14 and represents POWERLINK Objects of the type VAR as defined in 5.2.

The Property PowerlinkAttributes provides the information of the XML-Attribute ‘accessType’ from ‘Object’ and ‘SubObject’-Elements in the POWERLINK XML Device Description. The DataType PowerlinkAttributes is formally defined in 7.3.1.

The Properties Index and SubIndex provide the address information of the object in the POWERLINK Object Dictionary.

The optional Property Range provides the Value Range of the POWERLINK Object.

The optional Property DefaultValue provides the default value of the POWERLINK Object. The DataType of this Property shall be identical to the DataType of the DataVariable itself.

Note 1 to entry:

The Properties Index and SubIndex serve two purposes. It is not only additional information for the Client, but it also allows a generic implementation to interpret an imported Information Model because it already provides the required addressing information.

6 OPC UA ObjectTypes for POWERLINK Communication Profile EPSG DS 301

6.1 PowerlinkDeviceType

6.1.1 General

This OPC UA ObjectType represents a Device with one or more POWERLINK interfaces.

Figure 15 shows an overview for the PowerlinkDeviceType with its Properties and related components. It is formally defined in Table 15.

6.1.2 PowerlinkDeviceType Definition