1 Scope

This specification was created by a joint working group of the OPC Foundation and IO-Link Community. It defines an OPC UA Information Model to represent and access IO-Link Devices and IO-Link Masters.

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.

Initially, the OPC standard was restricted to the Windows operating system. As such, the acronym OPC was borne from OLE (object linking and embedding) for Process Control. These specifications, which are now known as OPC Classic, have enjoyed widespread adoption across multiple industries, including manufacturing, building automation, oil and gas, renewable energy and utilities, among others.

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

IO-Link Community

Goal of the IO-Link Community is to develop and market IO-Link as a technology. The IO-Link Community works as a Committee C IO-Link (C) organized within the Profibus Nutzerorganisation e.V. (PNO). The IO-Link interface is in principle to be seen as being independent of the fieldbus systems of the PNO (PROFIBUS and PROFINET).

IO-Link is the first standardized IO technology worldwide (IEC 61131-9) for the communication with sensors and also actuators. The powerful point-to-point communication is based on the long established 3-wire sensor and actuator connection without additional requirements regarding the cable material. So, IO-Link is no fieldbus but the further development of the existing, tried-and-tested connection technology for sensors and actuators.

Each IO-Link device has an IODD (IO Device Description). This is a device description file which contains information about the manufacturer, article number, functionality etc. This information can be easily read and processed by the user. Each device can be unambiguously identified via the IODD as well as via an internal device ID.

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

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

OPC 10000-3, OPC Unified Architecture – Part 3: Address Space Model

OPC 10000-4, OPC Unified Architecture – Part 4: Services

OPC 10000-5, OPC Unified Architecture – Part 5: Information Model

OPC 10000-6, OPC Unified Architecture – Part 6: Mappings

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

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

OPC 10000-9, OPC Unified Architecture – Part 9: Alarms & Conditions

OPC 10000-100, OPC Unified Architecture – OPC UA for Devices

IO-Link Specification: IO-Link Interface and System Specification, Version 1.1.2, July 2013

IO-Link Addendum: IO-Link Addendum 2017 related to IO-Link Interface and System Specification V1.1.2, Version 2.0, December 2017

IODD Specification:

IO Device Description, Version 1.1, August 2011

IO Device Description, Version 1.0.1, March 2010

IO-Link Common Profile: IO-Link Common Profile Specification Version 1.0 July 2017

3 Terms, Definitions, and Conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and IO-Link are understood in this specification. This specification will use these concepts to describe the OPC UA for IO-Link 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, IO-Link Specification, and IODD Specification as well as the following apply.

3.2 OPC UA for IO-Link Information Model Terms

3.2.1 IO-Link Device

Device as defined in IO-Link Specification

3.2.2 IO-Link Master

Master as defined in IO-Link Specification

3.3 Abbreviations and Symbols

3.4 Conventions used in this Document

3.4.1 Conventions for Terms

Terms in this document are written in CamelCase. Only the first occurrence of a term is written in italic.

3.4.2 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-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.

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 Annex A. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

3.4.3 NodeIds and BrowseNames

3.4.3.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 NamespaceUri for all NodeIds defined in this specification 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 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 vendor-specific, including the NamespaceUri. But the NamespaceUri of those Nodes cannot be the NamespaceUri used for the Nodes defined in this specification, because they are not defined by this specification but generated by the Server.

3.4.3.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceUri 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’ 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 83 provides a list of namespaces used in this specification.

3.4.4 Common Attributes

3.4.4.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 vendor-specific.

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

3.4.4.2 Objects

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

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

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

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

4 General Information on IO-Link and OPC UA

4.1 Introduction to IO-Link

4.1.1 What is IO-Link?

IO-Link is the first standardized IO technology worldwide (IEC 61131-9) for the communication with sensors and actuators. The powerful point-to-point communication is based on the long established 3-wire sensor and actuator connection without additional requirements regarding the cable material. So, IO-Link is no fieldbus but the further development of the existing, tried-and-tested connection technology for sensors and actuators.

4.1.2 Basics of IO-Link

An IO-Link system consists of an IO-Link Master, IO-Link Devices and the cables that connect the IO-Link Devices to the IO-Link Master’s ports. The IO-Link Master establishes the connection between the IO-Link Devices and the automation system and maintains point-to-point connections to the IO-Link Devices. Figure 1 gives an example of a system architecture with IO-Link.

Figure 1 uses the following colour code: Green for Ethernet and Fieldbus connections, orange for IO-Link connections and black for non-IO-Link sensor/actuator connections. Note that IO‑Link Masters can be implemented at different levels of the hierarchy and be combined with different kinds of devices such as fieldbus masters, gateways, etc.

4.1.3 Device Description

Each IO-Link Device has an IODD (IO Device Description). This is a device description file which contains information about the manufacturer, article number, functionality etc. This information can be easily read and processed by the user. Each device can be unambiguously identified via the IODD as well as via an internal device ID.

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 OPC UA for IO-Link, 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 2.

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.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 3 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 3 the SomeType ObjectType defines two Properties: Property1 and Property2. All instances of SomeType 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.

4.2.3.2 Graphical Notation

Figure 3 uses a notation that was developed for the OPC UA specification. The notation is summarized in Figure 4. 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.

4.2.4 OPC UA Profiles

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.5 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.6 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 Combining OPC UA and IO-Link

5.1 System Architecture

This specification defines an Information Model for IO-Link Masters and Devices. An example of a system architecture, providing different deploy options for OPC UA applications, is shown in Figure 5. The OPC UA Server can directly be deployed on an IO-Link Master or a PLC connected to the IO-Link Master or another platform like a PC. The OPC UA Client can directly be connected to the OPC UA Server running on the IO-Link Master, it can be connected to the PLC running the OPC UA Server, or the PLC can forward the traffic from an OPC UA Client on top of the PLC to the OPC UA Server running on the IO-Link Master beneath the PLC. More deploy options are possible and not limited by this specification.

5.2 Use Cases

The use cases that shall be fulfilled by this specification were defined by the IO-Link / OPC UA Integration Requirements Version 1.0.0 document. This section summarizes the use cases in scope.

5.2.1 UC.001: Configure an IO-Link Master

Preparing the IO-Link Master for the respective application by adjusting its parameters. This use case is of relevance, if the IO-Link Master is not connected to a fieldbus and a PLC.

5.2.2 UC.002: Find IO-Link Masters

The user would like to know which IO-Link Masters are used in the plant/machine. He would like to find IO-Link Masters of all types and vendors in the same way using his SW-Tool. No vendor-specific implementation shall be needed.

5.2.3 UC.003: Find IO-Link Devices

To be able to parameterize the connected IO-Link Devices it must be possible to request the IO-Link Master to give the information about connected devices to each of its ports.

5.2.4 UC.004: Initial commissioning of IO-Link Device

The user wants to parameterize the IO-Link Device for its application.

5.2.5 UC.005: Configure device metadata

Add metadata to identify the role and position of a device in the machine or process. If the IO-Link Device does not support the IO-Link Common Profile with Application Specific Tag, Function Tag and Location Tag, these parameters shall be virtually provided in the OPC UA Server.

5.2.6 UC.006: Configure IO-Link subscriptions

Setup data subscriptions to master or device variables and events to be able to:

Calculate operation KPIs (e.g. OEE)

Generate SPC (statistical process control) charts

Measure process data for process optimization

5.2.7 UC.007: Disconnection of IO-Link Device

The user (OPC UA Client) gets informed that a certain subscription is not available anymore, i.e. due to a disconnected IO-Link Device, to identify reasons for gaps in logs.

5.2.8 UC.008: Read product identification

The user of an OPC UA Client can uniquely identify all connected IO-Link Masters by their serial number information and devices by vendor and device ID to recognize the status of the devices and facilitate the exchange. For each IO-Link Device and the IO-Link Master, the following data are provided for reading only:

IO-Link DeviceType Version (mandatory)

IO-Link Protocol Version (mandatory)

Vendor Name (mandatory)

Product Name (mandatory)

Product ID (mandatory)

Serial Number (mandatory)

Hardware Revision (optional)

Software Revision (optional)

Vendor Text (optional)

Product Text (optional)

Application Specific Tag (mandatory – see UC.005)

Function Tag (optional)

Location Tag (optional)

Implicit topology information (address of IO-Link Master and port number, where the IO-Link Device is connected to)

5.2.9 UC.009: Read diagnostics data

User shall have access to logged diagnosis events. General and specific access to diagnostic data after authorization. OPC UA Client may collect event information sent to him in a logging buffer. If the IO-Link Master provides event logging, this information should be accessible via OPC UA.

5.2.10 UC.010: Read operating and failure statistics

The maintenance staff would like to use the productivity of used devices to determine the characteristics of the device during the period of use and the number of failures to obtain a statement about plant availability.

The maintenance staffs receive data on the operating time and the failure times of the connected devices.

The data are generated in the IO-Link Master and updated on the OPC UA Server.

The IO-Link Master records for each connected IO-Link Device

the duration the device is connected

the duration the device has communicated without error

the duration the device was not communicable

how often the device has been plugged in

how often the device has been changed

how often the device was not accessible

The master cyclically updates the data on the OPC UA Server and stores it persistently.

The data has a resolution in seconds.

The duration refers to the time of the last reset (usually during commissioning).

5.2.11 UC.011: Reset operating and failure statistics

The maintenance staff can reset the operating and failure statistics.

5.2.12 UC.012: Optimize machine settings

A machine in production needs to be optimized. This can be done by changing parameters of IO-Link Devices (e.g. limit values).

5.2.13 UC.013: Plant and machine status supervision

The operator staff would like to get immediately informed by the machine regarding process productivity and plant availability. In case of degradation, the possible location or source of problem shall also be reported.

Every plant subsystem with OPC UA Server connectivity sends an event if a critical condition has been detected or a configured threshold has been reached. The subsystem can also contain IO-Link Master and Devices, where IO-Link Events are translated into OPC UA events. The reported events from these subsystems shall consist of:

the origin identity of the event

the unambiguous identity of the event

the absolute time of occurrence according to the subsystems time base

if the occurrence is temporal, the duration of the erroneous condition

if possible, the identity of the processed item

On the application level, the following is derived on this raw data:

an availability signal in traffic light encoding

notification towards the operator staff

5.2.14 UC.014: Faulty device replacement

The user would like to replace an IO-Link Master or IO-Link Device with transfer of the previous configuration to the new device.

5.2.15 UC.015: Firmware update

Update device firmware individually and in groups of identical devices for IO-Link Masters and IO-Link Devices.

Note: Due to ongoing work in the OPC UA for Devices working group to standardize the firmware update, this version of the specification intentionally does not address the firmware update.

5.2.16 UC.016: Asset Management

Manage all the assets in an automation network.

Maintenance staff is called to adjust one or more settings.

5.2.17 UC.017: Cloud-connectivity at Edge Gateway

For Industry 4.0 application, an OPC UA Server will be the virtual interface between the cloud and the sensors in the field.

Therefore, the OPC UA Server has to apply the following functions:

Find all IO-Link Masters

Find IO-Link Devices

Download IODD of connected devices

Build up information model

Record all replacement of connected devices and update information model

Capture the status of connected devices

Read cyclic IO data

Read ISDU parameter sets

The Edge Gateway must find IO-Link Masters of all types and vendors in the same way. No vendor-specific implementation shall be necessary.

6 IO-Link Information Model Overview

6.1 Modelling Concepts

6.1.1 IO-Link Master

The configuration of the IO-Link Master is done by representing the IO-Link Master as Object having several Variables and Methods to view and to change the configuration. The ports of the IO-Link Master are modelled as individual Objects.

6.1.2 IO-Link Port

The configuration of an IO-Link Port is done by representing the IO-Link Port as Object having several Variables and Methods to view and to change the configuration. If the IO-Link Port has a connected or configured IO-Link Device, the device is referenced from the IO-Link Port.

6.1.3 IO-Link Device

The IO-Link Device is represented as Object having several Variables and Methods to view and to change the configuration. There is a generic ObjectType representing the common functionality of an IO-Link Device, and subtypes of it for the IODD extensions describing the type of a specific IO-Link Device in more detail and providing more intuitive configuration options.

6.1.4 IO-Link Events

Events can occur for different reasons. An IO-Link Master can generate vendor-specific Events; an IO-Link Port generates Events when the communication to the device fails, the device gets exchanged, etc.

The IO-Link Device itself provides event information. The IO-Link Master shall observe the event flag provided with each message. In case it is set, the IO-Link Master shall receive the event information via the acyclic communication mechanisms of IO-Link and forward it to the OPC UA Server and the server provides the received events via the OPC UA interface.

Events provided as IO-Link “Error” or “Warning” are mapped to OPC UA Alarms (see OPC 10000-9), events provided as IO-Link “Notification” as OPC UA Events.

Additional to the observation of the event flag there is the possibility to get information about the status of a stateful IO-Link Event (that is mapped to OPC UA Alarms) by using the DiagEntries of PortStatusList as defined in the SMI (see IO-Link Addendum) and the DetailedDeviceStatus (ISDU Index 0x0025).

6.1.5 Block operations: Up- and Download

An IO-Link Device can be configured by writing ISDU parameters. When a parameter of an IO-Link Device is written, the content is checked for consistency. This is useful, because it can happen that certain value combinations of some parameters are not valid configuration options.

When a single parameter is written, its value is checked against the other parameters that were configured before (or had this value by default). If the check fails, an error is returned. This behaviour causes problems if you want to change set of interdependent parameters.

Because of this, IO-Link provides block operations. If a device is set into the download state (via a system command) the device allows to write many parameters to the device without checking for consistency. When the block parameterization is finished (by sending another system command) the consistency of all changed parameters is checked as a whole. If all parameters are consistent, all changes are accepted, else all changes are rejected.

If the block operations are used to read several parameters, the device does not allow parameters to be changed during this time.

The needed IO-Link system commands (see IO-Link Specification) are mapped to OPC UA Methods.

To avoid concurrent access from different OPC UA Clients while the block operation is used by one OPC UA Client, the OPC UA Client should lock the IO-Link Device using the Lock Object defined in OPC 10000-100.

6.1.6 Managing IODDs

IODDs are managed as ObjectTypes in the server. A specific, well-defined Object called IODDManagement having well-defined Methods is used to load new IODDs to the Server (and thereby creating new ObjectTypes) or to delete IODDs from the Server.

6.1.7 Relating IO-Link Devices to IO-Link Ports

Depending on the configuration of an IO-Link Port and whether a physical IO-Link Device is connected to the IO-Link Port, either an Object representing the IO-Link Device is connected to the IO-Link Port or not. The following state machine describes, whether such an Object is there, and what ObjectType is used.

The top-level state machine defines the states “Port not configured as IO-Link” and “Select Device Instance Type”. In the first state the IO-Link Port is configured that no IO-Link Device is used (PortMode is either DEACTIVATED, DI_C/Q or DO_C/Q) and the optional Device Object is not available. In the second state the IO-Link-Port is configured to be an IO-Link Device (PortMode is either IOL_AUTOSTART or IOL_MANUAL) and the substates indicate whether a Device Object exists as well as the used ObjectType. Changes of the PortMode trigger transitions between the states. For the second state, additional transitions are defined that trigger the re-entrance of the state and thus the re-evaluation whether a Device Object exists as well as the used ObjectType. Those transitions include plugging in or off devices, changing the UseIODD Property or changes of IO-Link Port configuration Parameters.

The sub-state-machine of the “Select Device Instance Type” describes three states indicating, whether the Device Object exists and what ObjectType is used.

“Device not instantiated” indicates that the optional Device Object does not exist.

“IODD Device” indicates that the Device Object exists and the IODD is used and therefore the concrete ObjectType related to the IODD is used.

“IO-Link Device” indicates that the Device Object exists and the IOLinkDeviceType is used.

The sub-state-machine defines different choices to find the correct state.

When the PortMode is IOL_AUTOSTART but no device is connected, the “Device not instantiated” state is used.

When the PortMode is IOL_AUTOSTART and a device is connected, or the PortMode is IOL_MANUAL it is further decided if the “IODD Device” or the “IO-Link Device” state is used.

When the IODD representing the IO-Link Device is available in the server and the UseIODD Parameter is “True”, the “IODD Device” state is used, otherwise the “IO-Link Device” state is used.

Note that if an IO-Link Device is connected, the information of the connected IO-Link Device is used to identify the IODD, even if the IO-Link Port has a different device configured (Status = INCORRECT_DEVICE). Only when the PortMode is IOL_MANUAL and no device is connected (Status == NO_DEVICE || NOT_AVAILABLE) the configured device information is used to identify the IODD.

When the IO-Link Port is in the “IODD Device” state and the IODD is deleted (e.g. by the Method RemoveIODD using the force option) it changes to the “IO-Link Device” state.

When the IO-Link Port is in the “IO-Link Device” state and the IODD representing the IO-Link Device is added to the server (e.g. by the Method TransferIODD) and the UseIODD Parameter is “True” it changes to the “IODD Device” state.

Note that there can be limitations on what Variables can be accessed and what Methods can be executed from the Device Object (states “IO-Link Device” or “IODD Device”).

When the PortMode is IOL_MANUAL and no device is connected (Status == NO_DEVICE || NOT_AVAILABLE) the Device Object is available so OPC UA Clients can already be configured to use the configured IO-Link Device, but since no physical IO-Link Device is connected, all access to Variables or Methods requiring device access will fail (bad code). Providing the structure of the configured IO-Link Device is especially helpful if an IODD is used, since the structure defined by the IODD is already available to the OPC UA Client (specific Parameters etc.).

When the PortMode is IOL_MANUAL but the incorrect IO-Link Device is connected (Status == INCORRECT_DEVICE) accessing the Variables representing the process data (e.g. ProcessDataInput, ProcessDataOutput) will fail (bad code).

6.2 Model Overview

In Figure 7 an overview of the IO-Link Information Model is given. The IOLinkDeviceType represents IO-Link Devices. In case no IODD is available, this type shall directly be used to represent an IO-Link Device. If an IODD is available, a subtype is used representing the concrete IODD and providing the additional parameters, system commands, etc. defined in the IODD (see section 7.3). The IOLinkDeviceType inherits from TopologyElementType defined in OPC 10000-100 and thus provides basic grouping mechanisms (ParameterSet for parameters and MethodSet for Methods). It also uses basic Properties of a device like SerialNumber defined in OPC 10000-100. Section 7.1 defines details on those Properties and additional Properties like VendorId, Parameters like ApplicationSpecificTag and Methods like ReadISDU. The IO-Link Master is represented by an Object of IOLinkMasterType (see section 7.5). This ObjectType also inherits from the TopologyElementType and defines basic Properties, Parameters and Methods. For each port the IO-Link Master contains an Object of type IOLinkPortType (see section 7.6). The IOLinkPortType inherits from the TopologyElementType and thereby uses the same grouping mechanisms for Parameters and Variables. It defines Properties, Parameters and Methods for the IO-Link Port. If the port has an IO-Link Device connected, the IO-Link Device (Object of type IOLinkDeviceType) is connected to the port.

Instances of IOLinkDeviceType generate Events of type IOLinkDeviceEventType (see section 9.3) and IOLinkDeviceAlarmType (see section 9.8). An OPC UA Server might provide instances of the IOLinkDeviceAlarmType or its subtypes as Objects under the Alarms Object (see Figure 8).

Instances of IOLinkMasterType generate Events of type IOLinkMasterEventType (see section 9.6) and IOLinkMasterAlarmType (see section 9.11). Ports generate events of type IOLinkPortEventType (see section 9.5) and IOLinkPortAlarmType (see section 9.10). Both can provide instances of the IOLinkMasterAlarmType respectively IOLinkPortAlarmType under the Alarms Object (see Figure 8).

In the ObjectType hierarchy the mentioned events are grouped under the IOLinkEventType and the alarms under the IOLinkAlarmType (see Figure 8).

Figure 9 shows the entry points into the AddressSpace. The IOLinkMasterSet provides direct access to the Objects representing IO-Link Masters and indirectly to the Objects representing the IO-Link Devices connected to the Master. The IODDManagement Object contains the Object named IODDs pointing to all ObjectTypes representing an IODD.

Note: In order to figure out how many IO-Link Masters an OPC UA Server currently manages, an OPC UA Client can browse the IOLinkMasterSet and count all Objects of IOLinkMasterType or a subtype of it.

6.3 Mapping IODD information to OPC UA ObjectTypes

This section gives a rough overview on how IODD information is mapped to an OPC UA ObjectType. The formal definition is given in section 7.3.

An IODD consists of an IODevice containing meta data like DocumentInfo and ProfileHeader describing an IO-Link Device. In addition, it contains information about data types (DatatypeCollection), variables accessed acyclic (VariableCollection), process data (ProcessDataCollection), errors (ErrorTypeCollection), events (EventCollection) and menus to group information in user interfaces (UserInterface).

The user interface information consists of entry points for three different user roles (Observer, Maintenance, and Specialist), each one containing an identification menu and optionally parameter, observation, and diagnostics menus. Those menus can reference other menus or variables. Optionally, the user interface information also provides information how to display the process data directly (ProcessDataRefCollection).

The three entry points for the user roles are mapped to OPC UA FunctionalGroups. Each menu that is referenced directly or indirectly as part of such an entry point is also mapped as FunctionalGroup, referenced from its parent FunctionalGroup.

In Figure 10, an example of such a mapping is given. On the left hand, parts of an IODD are shown. On the right, the representation as ObjectType in OPC UA is shown. The IODevice is mapped to an ObjectType. The UserInterface information is mapped mainly to Objects of FunctionalGroupType. The Observer Object is directly connected to the ObjectType, its submenu Diagnostics is referenced by the Observer Object. The Diagnostics menu contains two conditional menus in the IODD, which are both mapped as optional Objects under the Diagnostics Object. The M_OR_Diagnosis_1132 menu references two Variables. This is mapped by referencing the corresponding variables of the ParameterSet. Some details of the mapping like handling conditions or additional information for Variables like EngineeringUnits are not shown in the figure and defined in section 7.3.

7 OPC UA ObjectTypes

7.1 IOLinkDeviceType ObjectType Definition

7.1.1 Example

In Figure 11 an example of an instance of the IOLinkDeviceType is shown. This example is using only the mandatory InstanceDeclarations, and excluding several mandatory Methods, in order to give an overview on the ObjectType. Several Properties are directly connected to the Object, whereas the Parameters are connected via the ParameterSet, Methods via the MethodSet and both organized via different FunctionalGroups (Identification and General).

7.1.2 Overview

The IOLinkDeviceType provides the generic information of an IO-Link Device and is formally defined in Table 8.

The IOLinkDeviceType ObjectType is a concrete type and can be used directly, if the server does not have an IODD describing the device. If the server has such an IODD, a subtype shall be created representing the concrete IODD (see section 7.3 for details).

The ObjectType inherits the following InstanceDeclarations directly or indirectly from the TopologyElementType defined in OPC 10000-100.

The optional Object ParameterSet is used to reference all Parameters and shall be provided. Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The optional Object MethodSet is used to reference all Methods and shall be provided. Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The optional Object Identification shall be provided and shall reference the Parameters defined in Table 9. Those Parameters together uniquely identify the device (see OPC 10000-100 for details). Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The Object <GroupIdentifier> has the ModellingRule OptionalPlaceholder and is intended to group the Parameters. It is already used in the ObjectType to define the General Object.

The optional Object Lock can be supported by a server to provide locking capabilities (see OPC 10000-100 for details). This is intended to prevent different clients and users to configure an IO-Link Device at the same time. The DeviceAccessLocks is used to disable the configuration of an IO-Link Device in general while it is set.

The ObjectType uses some InstanceDeclarations the same way as the DeviceType defined in OPC 10000-100.

The Variable SerialNumber of DataType String shall be mapped to ISDU Index 0x0015 (Serial Number). If the device does not support this ISDU Index, the Variable shall not be provided.

The Variable Manufacturer of DataType LocalizedText shall be mapped to ISDU Index 0x0010 (Vendor Name). As the name is intended to be locale-agnostic in IO-Link, the server may provide it with any LocaleId, the string shall be mapped to the text part of the LocalizedText. If the device does not support this ISDU Index, the VendorID (0x07 and 0x08 of Direct Parameter Page 1) shall be used, and either provided as integer representation in the text-part or by translating it internally to the Vendor Name managed by the IO-Link Community.

The Variable Model of DataType LocalizedText shall be mapped to ISDU Index 0x0012 (Product Name). As the name is intended to be locale-agnostic in IO-Link, the server may provide it with any LocaleId, the string shall be mapped to the text part of the LocalizedText. If the device does not support this ISDU Index, the DeviceID (0x09, 0x0A and 0x0B of Direct Parameter Page 1) shall be used, and provided as integer representation in the text-part.

The Variable HardwareRevision of DataType String shall be mapped to ISDU Index 0x0016 (Hardware Revision). If the device does not support this ISDU Index, the Variable shall not be provided.

The Variable SoftwareRevision of DataType String shall be mapped to ISDU Index 0x0017 (Firmware Revision). If the device does not support this ISDU Index, the Variable shall not be provided.

The Variable DeviceHealth of DataType DeviceHealthEnum shall be mapped to ISDU Index 0x0024 (Device Status). If the device does not support this ISDU Index, the Variable shall not be provided. The mapping of the concrete values is defined in Table 10.

The ObjectType defines additional InstanceDeclarations:

The mandatory Object General shall reference the Parameters and Methods defined in Table 11. It provides Parameters and Methods that are generally available on IO-Link Devices based on the IO-Link Specification.

The read-only Variable MinCycleTime shall be mapped to address 0x02 of Direct Parameter Page 1. The value shall be mapped to Duration (see 12.2.7.2 for details).

The read-only Variable RevisionID shall be mapped to address 0x04 of Direct Parameter Page 1. The value (one byte) shall be mapped to a String using the following rules: The MajorRev (Bit 4 to 7) shall be mapped to an Integer without leading zeros, the MinorRev (Bit 0 to 3) shall be mapped to an Integer without leading zeros and composed to a String as “<MajorRev>.<MinorRev>”. For example, the RevisionID for IO-Link 1.1 shall become the String “1.1”.

The read-only Variable VendorID shall be mapped to address 0x07 and 0x08 of Direct Parameter Page 1. The value (two bytes) shall be mapped to an UInt16, using Big Endian and 0x07 being the most significant byte (MSB).

The read-only Variable DeviceID shall be mapped to address 0x09, 0x0A and 0x0B of Direct Parameter Page 1. The value (three bytes) shall be mapped to an UInt32 (using the lowest three bytes), using Big Endian and 0x09 being the MSB.

The writable, optional Variable DeviceAccessLocks shall be mapped to ISDU Index 0x000C. The value (RecordT of BooleanT of length 16) shall be mapped to an UInt16, where the lowest bit represents the first Boolean of the record. The Variable gives information whether the parameterization of the device is locked in general, the local parameterization or the local user interface is locked (details see IO-Link Specification). By writing the Variable the locks can also be changed. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable ProfileCharacteristic shall be mapped to ISDU Index 0x000D. The value (array of UIntegerT16) shall be mapped to an array of UInt16. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable VendorText shall be mapped to ISDU Index 0x0011. The value (StringT) shall be mapped to a String. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable ProductID shall be mapped to ISDU Index 0x0013. The value (StringT) shall be mapped to a String. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable ProductText shall be mapped to ISDU Index 0x0014. The value (StringT) shall be mapped to a String. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The optional Alarms Object is used to group all alarms of the instance, in case the server supports representing the alarms as Objects in the AddressSpace. If the server does not support this, the Object shall not be provided.

7.1.3 Variables of ParameterSet

In Table 12, the Parameters of the ObjectType, referenced via the ParameterSet Object, are defined.

The writeable Variable ApplicationSpecificTag shall be mapped to ISDU Index 0x0018. If the device does not support this ISDU Index, the server shall provide the Variable nevertheless as it can be written by the client. The server shall persist the value, i.e. the value shall still be available after restart of the server. It is recommended to use the default value “***”. To allow clients to distinguish if the ApplicationSpecificTag is managed in the device or by the server, the Variable contains the read-only Property StoredInDevice as defined in Table 13. The value shall be “True” if the IO-Link Device supports the Index, and “False” otherwise.

Note: If the ISDU Index 0x0018 exists but its value is not permanently stored in the device, the server shall nevertheless not store the value persistently.

The writeable Variable FunctionTag shall be mapped to ISDU Index 0x0019. If the device does not support this ISDU Index, the server shall provide the Variable nevertheless as it can be written by the client. The server shall persist the value, i.e. the value shall still be available after restart of the server. It is recommended to use the default value “***”. To allow clients to distinguish if the FunctionTag is managed in the device or by the server, the Variable contains the read-only Property StoredInDevice as defined in Table 14. The value shall be “True” if the device supports the Index, and “False” otherwise.

Note: If the ISDU Index 0x0019 exists but its value is not permanently stored in the device, the server shall nevertheless not store the value persistently.

The writeable Variable LocationTag shall be mapped to ISDU Index 0x001A. If the device does not support this ISDU Index, the server shall provide the Variable nevertheless as it can be written by the client. The server shall persist the value, i.e. the value shall still be available after restart of the server. It is recommended to use the default value “***”. To allow clients to distinguish if the LocationTag is managed in the device or by the server, the Variable contains the read-only Property StoredInDevice as defined in Table 15. The value shall be “True” if the device supports the Index, and “False” otherwise.

Note: If the ISDU Index 0x001A exists but its value is not permanently stored in the device, the server shall nevertheless not store the value persistently.

The read-only Variable ErrorCount shall be mapped to ISDU Index 0x0020. The value (UIntegerT of length 16) shall be mapped to an UInt16. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable DetailedDeviceStatus shall be mapped to ISDU Index 0x0025. The value (ArrayT of OctetStringT3) shall be mapped to an Array of an Array of Bytes having the length of 3 (the inner Array). (The OctetStringT3 is mapped to an Array of Bytes of length 3 and the ArrayT to an Array.) The first entry in the inner Array is the first octet. If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

The read-only Variable ProcessDataInput shall be mapped to the cyclically data transferred from the device. The value shall be mapped to a Byte[]. The Variable is of type ProcessDataVariableType (see section 10.1). The ProcessDataLength Variable of ProcessDataVariableType shall be mapped to address 0x05 of Direct Parameter Page 1. The PDDescriptor Variable of ProcessDataVarableType shall be mapped to ISDU Index 0x000E if the device supports the ISDU Index, otherwise the optional Variable shall not be provided. If the PD status of the cyclic communication is set to 1 (invalid data), the StatusCode of the ProcessDataInput shall become a bad code.

The Variable ProcessDataOutput shall be mapped to the cyclically data transferred to the device. It is vendor-specific, if the Variable is writeable. The value shall be mapped to a Byte[]. The Variable is of type ProcessDataVariableType (see section 10.1). The ProcessDataLength Variable of ProcessDataVariableType shall be mapped to address 0x06 of Direct Parameter Page 1. The PDDescriptor Variable of ProcessDataVarableType shall be mapped to ISDU Index 0x000F if the device supports the ISDU Index, otherwise the optional Variable shall not be provided. If the IO-Link Device has not received the IO-Link Master command ‘ProcessDataOutputOperate’, the StatusCode of the ProcessDataOutput shall become a bad code

The optional, writable Variable OffsetTime shall be mapped to ISDU Index 0x0030. The value shall be mapped to Duration (see 12.2.7.2 for details). If the device supports the ISDU Index, the server shall provide the Variable, otherwise it shall not provide the Variable.

7.1.4 Methods of MethodSet

In Table 16, the Methods of the ObjectType, referenced via the MethodSet Object are defined. The first three Methods provide access rather on the protocol level and require the user calling the Methods to understand those protocol-level data transfers. The other Methods are specific IO-Link system commands mapped to OPC UA Methods.

7.1.4.1 ReadISDU

The Method ReadISDU reads parameters from the device using the ISDU mechanism.

Signature

	ReadISDU (
		[in]	UInt16		Index,
		[in]	Byte			SubIndex,
		[out]	Byte[]		Result,
		[out]	UInt16		ErrorType,
		[out]	Int32			Status
		);
	

7.1.4.2 WriteISDU

The Method WriteISDU writes parameters on the device using the ISDU mechanism.

Signature

	WriteISDU (
		[in]	UInt16		Index,
		[in]	Byte			SubIndex,
		[in]	Byte[]		Data,
		[out]	UInt16		ErrorType,
		[out]	Int32			Status
		);
	

7.1.4.3 SystemCommand

The method SystemCommand executes an IO-Link SystemCommand as defined in IO-Link Specification.

IO-Link SystemCommands shall be executed by an ISDU write request on Index 0x0002, or, in case ISDUs are not supported, via a write on Index 0x0F on Direct Parameter Page 1.

Signature

	SystemCommand (
		[in]	Byte				Cmd,
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.4 ParamUploadFromDeviceStart

This method executes the SystemCommand 0x01.

Signature

	ParamUploadFromDeviceStart (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.5 ParamUploadFromDeviceStop

This method executes the SystemCommand 0x02. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ParamUploadFromDeviceStop (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.6 ParamDownloadToDeviceStart

This method executes the SystemCommand 0x03. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ParamDownloadToDeviceStart (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.7 ParamDownloadToDeviceStop

This method executes the SystemCommand 0x04. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ParamDownloadToDeviceStop (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.8 ParamDownloadToDeviceStore

This method executes the SystemCommand 0x05. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ParamDownloadToDeviceStore (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.9 ParamBreak

This method executes the SystemCommand 0x06. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ParamBreak (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.10 DeviceReset

This method executes the SystemCommand 0x80. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	DeviceReset (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.11 ApplicationReset

This method executes the SystemCommand 0x81. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	ApplicationReset (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);
	

7.1.4.12 RestoreFactorySettings

This method executes the SystemCommand 0x82. The same argument description as for ParamUploadFromDeviceStart (see 7.1.4.4) applies.

Signature

	RestoreFactorySettings (
		[out]	UInt16			ErrorType,
		[out]	Int32				Status
		);

7.2 IOLinkIODDDeviceType

7.2.1 General information on IODDs

IODDs are defined in IODD Specification. When referencing this specification, we include the XML schema files defining IODDs and the standard definitions XML documents. By default, the IODD Specification Version 1.1 is referenced. If there are deviations between the Version 1.1 and Version 1.0.1, this is indicated in this specification.

When referencing parts of an IODD the following notation is used:

Refencing an XML element of another XML element: <parent element>/<child element>, for example DeviceIdentity/VendorUrl.

Referencing an XML attribute of an XML element <parent element>/@<attribute>, for example DeviceIdentity/@vendorId.

There are places where instances of an XML type are referenced, for example instances of VariableT or MenuT. In that case we reference to IODD Variables or IODD Menus.

7.2.2 Example

In Figure 12 an example of an instance of the IOLinkIODDDeviceType is shown. This example is using only the mandatory InstanceDeclarations, in order to give an overview on the ObjectType. Several Properties are directly connected to the Object, whereas the Parameters are connected via the ParameterSet, Methods via the MethodSet and both organized via different FunctionalGroups (Identification, General and Profiles).

7.2.3 Overview

The IOLinkIODDDeviceType provides the structure that all ObjectTypes generated based on IODDs have to provide and is formally defined in Table 17.

The IOLinkIODDDeviceType ObjectType is an abstract type. Concrete subtypes are generated for concrete IODDs (see section 7.3 for details).

The mandatory Object ParameterSet is inherited from the supertype and overridden in order to add parameters defined in section 7.2.4.

The mandatory Object Specialist groups all menus of the SpecialistRoleMenuSet defined in an IODD.

The mandatory Object Maintenance groups all menus of the MaintenanceRoleMenuSet defined in an IODD.

The mandatory Object Observer groups all menus of the ObserverRoleMenuSet defined in an IODD.

The Object IODDInformation provides information about the IODD and is only provided on the ObjectType, not the instances of the ObjectType. Therefore, it does not have a ModellingRule. Its content is defined in 7.2.5.

The Object DeviceVariants provides information about the IO-Link Device variants supported by the ObjectType. It references all device variants (Objects of Type DeviceVariantType) with a HasComponent Reference. Device variants are defined by the subtypes of this ObjectType.

The mandatory Object DeviceVariant provides information about the currently used device variant on the instance.

The mandatory read-only Property VendorURL maps to the IODD DeviceIdentity/VendorURL element.

The mandatory read-only Property DeviceName maps to the IODD DeviceIdentity/DeviceName element. Localization should be considered. In IODD Specification Version 1.0.1 there is no IODD DeviceIdentity/DeviceName element defined. Instead of, the IODD DeviceVariant/ProductName element shall be used. Localization should be considered.

The optional read-only Property VendorLogo maps to the IODD DeviceIdentity/VendorLogo element, if the optional element is provided.

The optional Object DeviceTypeImage defined in OPC 10000-100 is overridden in order to reference Images of the DeviceVariant Object (see section 7.2.6).

7.2.4 Variables of the ParameterSet Object

In Table 18, the Variables of the ParameterSet Object of the IOLinkIODDDeviceType, are defined.

The optional, read-only Variable SupportedAccessLocks maps to the IODD Features/SupportedAccessLocks element. The lowest bit of the Byte references to parameter, the next to dataStorage, the next to localParamaterization and the next to localUserInterface as defined in SupportedAccessLocksT. The OptionSetValues Property shall be filled with those names for locale “en”. Servers might provide translations to other languages. In IODD Specification Version 1.0.1 there is no IODD Features/SupportedAccessLocks element. Therefore, the OPC UA Variable SupportedAccessLocks is not provided for IODDs following the IODD Specification Version 1.0.1.

7.2.5 Variables of the IODDInformation Object

In Table 19 the Variables of the IODDInformation Object of the IOLinkIODDDeviceType are defined.

The mandatory, read-only Property Version maps to the IODD DocumentInfo/@version attribute.

The mandatory, read-only Property ReleaseDate maps to the IODD DocumentInfo/@releaseDate attribute.

The mandatory, read-only Property Copyright maps to the IODD DocumentInfo/@copyright attribute.

The mandatory, read-only Property IOLinkRevision maps to the IODD ProfileHeader/ProfileRevision element.

7.2.6 Variables of the DeviceTypeImage Object

In Table 20, references of the DeviceTypeImage Object of the IOLinkIODDDeviceType, are defined.

7.3 ObjectTypes generated based on IODDs

7.3.1 General

This clause defines how ObjectTypes shall be generated based on IODDs. For each IODD managed by the Server, the Server shall have an ObjectType as subtype of the IOLinkIODDDeviceType (see section 7.2).

The IsAbstract Attribute of the generated ObjectType shall be set to “False”.

The BrowseName Attribute of the generated ObjectType shall be mapped to the IODD DeviceIdentity/DeviceName element using the default language. The DisplayName should use the localization provided by the DeviceName.

The optional Description Attribute is vendor-specific and might be omitted.

7.3.2 NodeId of generated ObjectTypes and their InstanceDeclarations

Each NodeId that is used to describe the generated ObjectTypes shall use the Namespace “http://opcfoundation.org/UA/IOLink/IODD” and the identifierType String. The String of the NodeId of the ObjectType shall be composed of the VendorId, the DeviceId (in DeviceIdentity) and the version of the IODD (in DocumentInfo) using the format: “<VendorId>|<DeviceId>|<version>” like “888|67335|V1.1”. The InstanceDeclarations use this prefix followed by the BrowsePath. Variables and Methods, which might have several BrowsePaths use the BrowsePath coming from ParameterSet respectively MethodSet, Objects representing menus use the first BrowsePath that is defined in the IODD. The format is: “<ObjectTypeNodeId>||<BrowseName>[:<BrowseName>]”. The BrowseName only contains the String part, not the NamespaceIndex. An example is “888|67335|V1.1||ParameterSet:V_LifeTimeYears” as string-part of the NodeId of a Variable.

Defining the NodeIds of ObjectTypes based on IODDs is necessary so that OPC UA Clients accessing different OPC UA Servers implementing this specification and using the same IODDs can identify that they actually deal with the same types.

7.3.3 Namespace of the BrowseNames

The BrowseNames used when generating ObjectTypes and their InstanceDeclarations shall use the Namespace “http://opcfoundation.org/UA/IOLink/IODD”.

7.3.4 Mapping to InstanceDeclarations inherited from IOLinkIODDDeviceType

In general, on the instance all rules defined on the IOLinkIODDDeviceType or its supertypes shall apply. When a new ObjectType is created, some InstanceDeclarations of the supertype are overridden in order to provide information from the IODD like VendorId.

The VendorID shall be filled with the IODD DeviceIdentity/@vendorId.

The DeviceID shall be filled with the IODD DeviceIdentity/@deviceId.

The Manufacturer shall be filled with the IODD DeviceIdentity/@vendorName.

The VendorText shall be filled with the IODD DeviceIdentity/VendorText, taking the default language.

The DeviceClass shall be filled with the IODD DeviceIdentity/DeviceFamily.

7.3.5 Mapping of IODD Menus

For each menu of the IODD UserInterface/MenuCollection that is referenced directly or indirectly form the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet or the IODD UserInterface/SpecialistRoleMenuSet, an Object of ObjectType FunctionalGroupType is created.

The BrowseName of the Object shall be the Id of the IODD Menu. The DisplayName shall be the Name of the IODD Menu. Localization should be considered. The optional Description Attribute is vendor-specific and might be omitted.

For each IdentificationMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasIdentificationMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each ParameterMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasParameterMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each ObservationMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasObservationMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each DiagnosisMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet an HasDiagnosisMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

In Figure 13 an example of how to map IODD menus is shown. On the left, an excerpt of an IODD is shown, and on the right, the OPC UA representation.

For each IODD Menu that has been added all MenuRefs shall reference the corresponding Objects with an Organizes Reference. If at least one IODD UIMenuRef does not provide an IODD MenuRef/Condition element, the ModellingRule shall be Mandatory, otherwise it shall be Optional.

In Figure 14 another example of how to map IODD menus is shown. On the left, an excerpt of an IODD is shown, and on the right, the OPC UA representation. In this example, IODD Menus contain other IODD Menus.

7.3.6 Mapping of IODD Variables

For each IODD Variable defined in the IODD an OPC UA Variable is created that is referenced from the ParameterSet with a HasComponent Reference. The ModellingRule shall be Mandatory for each of those Variables.

Each Object representing a menu referencing the Variable via a VariableRef not defining a Button shall reference the Variable with an Organizes Reference.

Each Object representing a menu referencing the Variable via a RecordItemRef not defining a Button shall reference the corresponding Sub-Variable with an Organizes Reference.

The BrowseName of the Variable shall be the Id of IODD Variable and the DisplayName the Name of the IODD Variable. Localization should be considered. The Description Attribute shall be the Description of IODD Variable. Localization should be considered.

The VariableType, DataType, ValueRank and ArrayDimensions are set according to section 12 depending on the Datatype or DatatypeRef. In addition, the VariableRef or RecordItemRef defines some characteristics that need to be considered.

If at least one VariableRef contains a unitCode the Variable shall have the Property EngineeringUnits. If more than one VariableRef references the IODD Variable and all VariableRefs contain the unitCode, the EngineeringUnits shall have the ModellingRule Mandatory, otherwise the ModellingRule Optional. The value of EngineeringUnits is vendor-specific because several VariableRefs might define different unitCodes. It might be omitted on the InstanceDeclaration.

If at least one VariableRef contains a displayFormat the Variable shall have the Property DisplayFormat (see section 13.6). If all VariableRefs contain the displayFormat, the DisplayFormat shall have the ModellingRule Mandatory, otherwise the ModellingRule Optional. The value of DisplayFormat is vendor-specific. It might be omitted on the InstanceDeclaration.

The same rules apply for the sub-variables referenced based on the RecordItemRefs.

The accessRightRestriction is ignored on the ObjectType and only considered on the instances.

In Figure 15 an example is shown of how to map IODD Variables referenced from an IODD Menu to OPC UA.

In Figure 16 another example is shown. In this example, the VariableRefs to the same IODD Variable contain different information.

In Figure 17 an example on how to map RecordItemRefs is shown.

7.3.7 Mapping of Methods from IODD Menus

VariableRefs and RecordItemRefs can define Buttons. Those IODD Buttons are mapped to OPC UA Methods.

For each Button-defining VariableRef or RecordItemRef from an IODD Menu that is used in the mapping (see section 7.3.5) an OPC UA Method is created, that is referenced with a HasComponent Reference from the MethodSet Object.

In case several VariableRefs or RecordItemRefs have the same characteristics (Description, ActionStartedMessage, buttonValue, and in case of RecordItemRefs same subindex), only one Method is created.

The Objects representing the IODD Menus shall reference the corresponding Methods with Organizes References.

If at least one Object representing an IODD Menu referencing the Method has the ModellingRule Mandatory the Method shall have the ModellingRule Mandatory, otherwise Optional.

The BrowseName of the Method shall be the Id of the IODD Variable combined with the buttonValue. The format is “<Id>|<buttonValue>”. In the unlikely case that the IODD Variable is referenced several times as Button with the same buttonValue but different other characteristics (Description and ActionStartedMessage), the additional Methods have a BrowseName postfixed by a number using the format “<Id>|<buttonValue>_<n>” where “n” is the occurrence in the order of the IODD, starting with a 2 for the second occurrence.

The DisplayName shall be the Description of the IODD Button, if a Description is provided. Localization should be considered. If no Description is provided, the DisplayName should be the BrowseName. The optional Description Attribute is vendor-specific and might be omitted.

The Methods shall not have input- or output-arguments. If the optional ActionStartedMessage of the IODD Button is provided, there shall be a Property with BrowseName “ActionStartedMessage” and the DataType String, providing the ActionStartedMessage of the IODD Button.

Note: The way a button is modelled inside an IODD VariableRef element changed from IODD Specification Version 1.0.1 to Version 1.1. The information modelled in IODD Specification Version 1.1 in the elements Description and ActionStartedMessage is not provided in IODD Specification Version 1.0.1.

The server-internal implementation of the Method shall implement the IODD Button according to the IODD Specification.

An example on how to map IODD Buttons to OPC UA Methods is shown in Figure 18.

7.3.8 Mapping of StdVariableRef and StdRecordItemRef

The StdVariableRefs (standard variable references) reference to standardized information, that is already defined in the IOLinkDeviceType. In Table 21, an overview of the mapping is given.

The StdRecordItemRefs (standard record item references) reference to standardized information, that is already defined in the IOLinkDeviceType. In Table 22, an overview of the mapping is given.

In both cases, the following rule applies.

If there is an InstanceDeclaration on the IOLinkDeviceType:

If the StdVariableRef or StdRecordItemRef is not defining a Button and the InstanceDeclaration is a Variable, the InstanceDeclaration shall be overridden in the new created type and referenced from all Objects representing IODD Menus having such a reference. If a default value is defined, the OPC UA Server shall use this as Value of the Variable, if several different default values are defined, the first one defined in the IODD shall be used. Other characteristics defined on the StdVariableRef of StdRecordItemRef are ignored.

For VendorID and DeviceID there are two resp. three StdRecordItemRefs used. In the mapping, whenever an IODD Menu references at least one of them, the whole Variable (VendorID or DeviceID) is referenced.

If the StdVariableRef or StdRecordItemRef is defining a Button, the rules defined in 7.3.7 apply.

If there is no InstanceDeclaration on the IOLinkDeviceType defined, the same rules as for VariableRef and RecordItemRef defined in 7.3.6 and 7.3.7 apply.

Note that for V_SystemCommand the mapping described in this section applies, although there is a representation in the IOLinkDeviceType (SystemCommand Method), because the IODD provides useful new information about the supported system commands.

7.3.9 Mapping of ProcessDataCollection and ProcessDataRefCollection

The ProcessDataCollection gives an interpretation of the input and / or output process data.

For each entry of the collection (IODD ProcessData) having an IODD ProcessDataOut of type ProcessDataItemT, for each IODD ProcessDataOut, a new sub-variable of the OPC UA Variable ProcessDataOutput is created, having the BrowseName composed of the ProcessData id and the ProcessDataItem id (“<ProcessData id>|<ProcessDataItem id>”). If the ProcessData has a Condition, the Variable becomes optional, otherwise mandatory. In order to add a sub-variable to the ProcessDataOutput Variable defined on the IOLinkDeviceType, the ProcessDataOutput Variable needs to be overridden on the new created IODD-based subtype.

For each entry of the collection (IODD ProcessData) having a ProcessDataIn of type ProcessDataItemT, for each ProcessDataIn, a new sub-variable of ProcessDataInput is created, having the BrowseName composed of the ProcessData id and the ProcessDataItem id (“<ProcessData id>|<ProcessDataItem id>”). If the ProcessData has a Condition, the Variable becomes optional, otherwise mandatory. In order to add a sub-variable to the ProcessDataInput Variable defined on the IOLinkDeviceType, the ProcessDataInput Variable needs to be overridden on the new created IODD-based subtype.

In both cases the DisplayName shall be the Name element of the ProcessDataItem. Localization should be considered. The DataType is chosen for the Datatype element or DatatypeRef element according to section 12.

The ProcessDataRefCollection can provide additional characteristics for the created Variables, like unitCode and displayFormat. Note that the optional ProcessDataRefCollection and its child elements are not supported by IODD Specification Version 1.0.1.

If the ProcessDataRef contains a unitCode the Variable shall have the Property EngineeringUnits as mandatory. The value shall be as defined in the ProcessDataRef (see Annex C).

If the ProcessDataRef contains a displayFormat the Variable shall have the Property DisplayFormat (see 13.6) as mandatory. The value shall be as defined in the ProcessDataRef.

In Figure 19 an example is shown on how to map an IODD ProcessDataCollection.

7.3.10 Mapping of DirectParameterOverlay

In case the DirectParameterOverlay is defined in the IODD, the mapping shall be the same as for Variables with respect to the DataType (RecordT). The BrowseName shall be “DirectParameterPage2”, and the DisplayName the same for locale “en” and might provide translations. A vendor-specific Description might be provided.

7.3.11 Mapping of Default Values

In different places of the IODD default values can be defined.

The DirectParameterOverlay can define default values for the individual entries

The StdVariableRef can define default values

The Variable can define default values

The RecordItemInfo and StdRecordItemRef can define default values

In all cases the default value shall be provided as value of the corresponding Variables on the ObjectType. In case of StdVariableRefs the Variables are already defined in the supertype and need to be overridden on the IODD-based type in order to provide the default value.

An example on how to map DefaultValues is shown in Figure 20.

7.3.12 Mapping of DeviceVariantCollection

All entries of the DeviceVariantCollection are mapped to instances of DeviceVariantType according to section 7.7. The Objects are referenced from the DeviceVariants Object with a HasComponent Reference.

The first entry of the DeviceVariantCollection is also mapped to the DeviceVariant Object.

In Figure 21 an example is given.

7.3.13 Mapping of EventCollection

Information about Events (Notification) is not mapped to additional EventTypes, but the IOLinkIODDDeviceEventType is used.

When an IO-Link Device sends a Notification, and the server manages the IODD for the IO-Link Device, an Event of the IOLinkIODDDeviceEventType is generated according to the EventType definition.

Information about Alarms (Warning and Error) is not mapped to additional EventTypes, but the IOLinkIODDDeviceAlarmType is used. If the OPC UA server supports Alarm Objects represented in the AddressSpace, the server may provide the Alarms Object on the ObjectType and provide all possible Alarms as Objects based on the IODD.

When an IO-Link Device sends a Warning or Error, and the server manages the IODD for the IO-Link Device, an Event of the IOLinkIODDDeviceAlarmType is generated according to the EventType definition.

7.4 Creation of Instances based on ObjectTypes generated out of IODDs

When an instance is created based on an ObjectType generated out of an IODD, two scenarios need to be considered.

Either an IO-Link Device is connected and thus conditions can be evaluated or

no IO-Link Device is connected but the IO-Link Port is configured in IOL_MANUAL (see section 6.1.7).

In the second case all optional Objects, Variables and Methods are omitted and only the mandatory Objects, Variables and Methods are provided. Except for VendorID and DeviceID, which shall expose the configured DeviceID and VendorID on the IO-Link Port, all Variables cannot be read or written and all Methods cannot be executed. The server shall report a Bad_NoCommunication StatusCode in those cases.

In the first case the Conditions on the MenuRefs and ProcessData are evaluated and the Objects and Variables are only provided when they are referenced (either directly or indirectly) based on the Condition evaluation.

Some characteristics of a Variable like the unitCode (see Annex C), displayFormat (see section 13.6) and additional accessRightRestriction are defined in the VariableRef of the IODD. A Variable can be referenced by several VariableRefs. Typically, in an IODD all valid VariableRefs (from menus which are active based on the Condition) to the same Variable use the same characteristics. But this is not required. Since the characteristics are exposed in OPC UA on the Variable, and not the reference to the Variable, the following rules apply for creating an instance.

The Variable referenced from the ParameterSet Object uses the characteristics as defined by the first active menu in the MenuCollection of the IODD. For a VariableRef with different characteristics a new Variable is defined referenced by the initially created Variable with a HasComponent Reference. It provides the different characteristics and uses the same BrowseName and mapping as the initial Variable. All VariableRefs that have characteristics that already have a Variable representing the characteristics shall reference that Variable.

In addition to the AccessLevel defined in section 12, the accessRightRestriction of the VariableRef and the accessRights on the IODD Variable shall be considered. Also, the offset and gradient to change the raw value coming from the IO-Link Device shall be considered.

In case the raw value is changed in the Variable (offset and/or gradient are defined in the IODD), there shall be a Sub-Variable on the OPC UA Variable instance with the BrowseName “RawValue” providing the raw value from the IO-Link Device.

When the IODD provides default values for a Variable in OPC UA, and the server has not already read the value from the IO-Link Device, the default value should be provided with StatusCode Uncertain_InitialValue.

The DeviceVariant Object is filled with the DeviceVariant according to the ProductID of the IO-Link Device. If the IO-Link Device does not provide this optional parameter or ProductID does not correspond to a DeviceVariant specified in the IODD, the OPC UA Server shall use the first DeviceVariant defined in the IODD.

If the optional DeviceSymbol or DeviceIcon Variable exist on the DeviceVariant Object, the DeviceTypeImage Folder defined in OPC 10000-100 shall be provided. The DeviceTypeImage Folder shall reference the DeviceSymbol and the DeviceIcon with a HasComponent Reference if those Variables are provided on the DeviceVariant Object.

When the blockParameter attribute is defined and set to “False” in the IODD, the Methods ParamUploadFromDeviceStart, ParamUploadFromDeviceStop, ParamDownloadToDeviceStart, ParamDownloadToDeviceStop, and ParamBreak shall have the Executable Attribute set to “False”.

When the dataStorage attribute is defined and set to “False” in the IODD, the Method ParamDownloadToDeviceStore shall have the Executable Attribute set to “False”.

In Figure 22 an example of an Object based on an IODD is shown.

In Figure 23, an example of an Object based on an IODD is shown, where an IODD Variable is referenced by VariableRefs with different characteristics.

7.5 IOLinkMasterType ObjectType Definition

7.5.1 Example

In Figure 24 an example of an instance of the IOLinkMasterType is shown. The example is using only the mandatory InstanceDeclarations, in order to give an overview on the ObjectType. Several Properties are directly connected to the Object, whereas the Parameters are connected via the ParameterSet, Methods via the MethodSet and both are organized via different FunctionalGroups (Identification, Capabilities, Statistics and Management).

7.5.2 Overview

The IOLinkMasterType provides information of an IO-Link Master and is formally defined in Table 23.

The IOLinkMasterType ObjectType is a concrete type and can be used directly. Vendors may create subtypes of the IOLinkMasterType to add vendor-specific extensions.

The ObjectType inherits the following InstanceDeclarations directly or indirectly from the TopologyElementType defined in OPC 10000-100.

The optional Object ParameterSet is used to reference all Parameters and shall be provided. Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The optional Object MethodSet is used to reference all Methods and shall be provided. Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The optional Object Identification shall be provided and shall reference the Parameters defined in Table 24. Those Parameters together uniquely identify the IO-Link Master (see OPC 10000-100 for details). Therefore, the ObjectType overrides the Object and changes the ModellingRule to Mandatory.

The Object <GroupIdentifier> has the ModellingRule OptionalPlaceholder and is intended to group the Parameters. It is already used in this ObjectType by adding the Objects Capabilities, Management and Statistics. Vendors may add vendor-specific Objects to group additional Parameters.

The optional Object Lock can be supported by a server to provide locking capabilities (see OPC 10000-100 for details). This is intended to prevent different clients and users to configure an IO-Link Master at the same time. Locking an IOLinkMasterType Object includes locking all its ports and the IOLinkDeviceType Objects connected to the ports.

The ObjectType defines additional InstanceDeclarations:

The mandatory Object Capabilities shall reference the Parameters defined in Table 25. Servers may add vendor-specific Parameters or Methods to this Object.

The mandatory Object Management shall reference the Methods defined in Table 26. Servers may add vendor-specific Parameters or Methods to the Object.

The mandatory Object Statistics shall reference the Parameters and Methods defined in Table 26. Servers may add vendor-specific Parameters or Methods to the Object.

The mandatory, read-only Variable DeviceID shall be mapped to MasterID of the MasterIdent structure defined in the SMI (see IO-Link Addendum). The value (three bytes) shall be mapped to an UInt32, using Big Endian.

The optional, read-only Variable ProductID provides a vendor-specific product or type identification like the ProductID of the IOLinkDeviceType. The implementation is vendor-specific.

The optional, read-only Variable ProductText provides additional, vendor-specific product information like the ProductText of the IOLinkDeviceType. The implementation is vendor-specific.

The optional, read-only Variable RevisionID contains the IO-Link protocol version supported by the IO-Link Master, like the RevisionID of the IOLinkDeviceType. The same rules as defined for RevisionID in IOLinkDeviceType apply (see section 7.1).

The optional, read-only Variable VendorID of type UInt16 shall be mapped to VendorID of the MasterIdent structure defined in the SMI (see IO-Link Addendum), using the same type.

The optional Variable VendorURL provides a link to the website of the vendor of the IO-Link Master. The implementation is vendor-specific.

The optional read-only Variable IOLinkStackRevision provides the revision of the IO-Link stack implementation used by the IO-Link Master. The implementation is vendor-specific.

The mandatory Variable MasterConfigurationDisabled indicates whether configuration changes are allowed via OPC UA. If set to “True”, nearly all configuration settings become read-only and cannot be changed via OPC UA anymore. The Variable setting is vendor-specific, including whether it can be changed via OPC UA. For example, if a fieldbus is currently active on the IO-Link Master, a server might set this Variable to “True”.

That includes in detail following rules:

The Method Restart of the IO-Link Master becomes not executable.

For all Ports of the IO-Link Master the Method UpdateConfiguration becomes not executable.

For all Ethernet configurations connected to the Fieldbus the configuration becomes read-only.

The Method ResetStatistics on the Port and ResetStatisticsOnAllPorts on the IO-Link Master shall still be executable.

There is no direct relation between the MasterConfigurationDisabled Variable and the Lock Object. The Lock Objects prevents different OPC UA Clients to configure the IO-Link Master at the same time whereas the MasterConfigurationDisabled Variable indicates that the IO-Link Master is in a state within it cannot be configured by any OPC UA Client. When the MasterConfigurationDisabled Variable is set to “True” Servers may prevent the usage of the Lock Object for all Clients.

The Port<n> Object of ModellingRule MandatoryPlaceholder represents the ports of the IO-Link Master. For each port of the IO-Link Master one Object of type IOLinkPortType shall be provided, where <n> represents the number of the port. For example, a master having two ports has the Objects Port1 and Port2. How the counting starts (e.g. Port0 or Port1) is vendor-specific.

The optional Alarms Object is used to group all alarms of the instance, in case the server supports representing the alarms as Objects in the AddressSpace. If the server does not support this, the Object shall not be provided.

7.5.3 Variables of ParameterSet

In Table 28, the Parameters of the ObjectType, referenced via the ParameterSet Object, are defined.

The mandatory, read-only Variable MaxNumberOfPorts shall be mapped to MaxNumberOfPorts of the MasterIdent structure defined in the SMI interface (see IO-Link Addendum).

The mandatory, read-only Variable MaxPowerSupply shall provide the overall amount of power provided together on all ports of the IO-Link Master in ampere. For example, a 4-port IO-Link Master may provide max. 2 A on each port but an overall MaxPowerSupply of 6 A, so not each port can consume 2 A at the same time. The Variable shall provide the EngineeringUnits Property defined in OPC 10000-3, having the value set to {namespaceUri = “http://www.opcfoundation.org/UA/units/un/cefact”; unitId = 4279632; displayName = {“en”,"A"}; description = {“en”, "ampere"}} (for ampere). The Property shall be read-only and have the ModellingRule Mandatory, so it is reflected on all instances.

The mandatory, writeable Variable ApplicationSpecificTag provides the same information as the ApplicationSpecificTag defined for an IO-Link Device on the IO-Link Master level. The server shall manage the value in a persistent manner. If a fieldbus mapping of the IO-Link Master exists providing the same information, consistency shall be provided by the OPC UA Server.

The mandatory, writeable Variable FunctionTag provides the same information as the FunctionTag defined on an IO-Link Device on the IO-Link Master level. The server shall manage the value in a persistent manner. If a fieldbus mapping of the IO-Link Master exists providing the same information, consistency shall be provided by the OPC UA Server.

The mandatory, writeable Variable LocationTag provides the same information as the LocationTag defined for an IO-Link Device on the IO-Link Master level. The server shall manage the value in a persistent manner. If a fieldbus mapping of the IO-Link Master exists providing the same information, consistency shall be provided by the OPC UA Server.

The mandatory, read-only Variable MasterType shall be mapped to MasterType of the MasterIdent structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the DataType Byte. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain the content as defined in Table 29.

Servers are allowed to add additional entries into the EnumStrings array. Servers may provide translations of the texts in different locales.

The optional, read-only Variable DateOfLastStatisticsReset contains the timestamp of the answer to the last call of the Method ResetStatisticsOnAllPorts. The timestamp information shall be as precise as possible. If the ResetStatisticsOnAllPorts Method was never called then DateOfLastStatisticsReset indicates the startup time. The optional Variable shall be provided when the optional Method ResetStatisticsOnAllPorts is provided.

The following Variable indicates the incidents since DateOfLastStatisticsReset. The server should persist statistics, also when the IO-Link Master or the OPC UA Server is restarted. However, if the statistics become inconsistent, the server is allowed to do an internal reset. This will result in the update of DateOfLastStatisticsReset. If the value of a counting Variable becomes larger than the maximum value of the DataType, the value shall remain on the maximum value.

The optional, read-only Variable NumberOfIOLinkMasterStarts indicates how often the IO-Link Master was started since DateOfLastStatisticsReset. This includes starts on power up as well as warm starts and restarts due to errors. This variable is reset with the Method ResetStatisticsOnAllPorts to 0. When the IO-Link Master starts for the very first time, the value is 1 as it has started once.

7.5.4 Methods of MethodSet

In Table 30, the Methods of the ObjectType, referenced via the MethodSet Object are defined.

7.5.4.1 Restart

The Method Restart restarts the IO-Link Master.

Signature

	Restart (
		[in]	Duration		Delay,
		[out]	Int32			Status
		);
	

7.5.4.2 ResetStatisticsOnAllPorts

The optional Method ResetStatisticsOnAllPorts resets all statistic data, including statistic data of the ports of the IO-Link Master. Statistic data of a port are all Parameters referenced by the Statistics Object of the IOLinkPortType Object starting with “NumberOf” and potentially vendor-specific extensions. Statistic data directly on the IO-Link Master includes the Variable NumberOfIOLinkMasterStarts and potential vendor-specific extensions. As soon as statistic data is provided by the server, the optional Method shall be provided.

Signature

	ResetStatisticsOnAllPorts (
		[out]	Int32			Status
		);
	

7.6 IOLinkPortType ObjectType Definition

7.6.1 Example

In Figure 25 an example of an instance of the IOLinkPortType is shown, using only the mandatory InstanceDeclarations, in order to give an overview on the ObjectType. The Object does not have Properties, its Parameters are connected via the ParameterSet, Methods via the MethodSet and both organized via different FunctionalGroups (Capabilities, Statistics, SIOProcessData, Configuration (containing another FunctionalGroup ConfiguredDevice), and Information). Note that SIOProcessData only points to optional Parameters not used in this example.

7.6.2 Overview

The IOLinkPortType provides information of one port of an IO-Link Master and is formally defined in Table 8.

The IOLinkPortType ObjectType is a concrete type and can be used directly. Vendors may create subtypes of the IOLinkPortType to add vendor-specific extensions.

The ObjectType inherits the following InstanceDeclarations directly or indirectly from the TopologyElementType defined in OPC 10000-100.

The optional Object ParameterSet is used to reference all Parameters and shall be provided. Therefore, the ObjectType overrides the Object and changes its ModellingRule to Mandatory.

The optional Object MethodSet is used to reference all Methods and shall be provided. Therefore, the ObjectType overrides the Object and changes its ModellingRule to Mandatory.

The optional Object Identification is not used in this ObjectType.

The Object <GroupIdentifier> has the ModellingRule OptionalPlaceholder and is intended to group the Parameters. It is already used in this ObjectType by adding various FunctionalGroupType Objects. Vendors may add vendor-specific Objects to group additional Parameters.

The optional Object Lock can be supported by a server to provide locking capabilities (see OPC 10000-100 for details). This is intended to prevent different clients and users to configure an IO-Link Master at the same time. Locking the Port also locks the connected IO-Link Device.

The ObjectType defines additional InstanceDeclarations:

The mandatory Variable DeviceConfigurationDisabled indicates whether configuration changes of the connected IO-Link Device (Device Object) are allowed via OPC UA. If set to “True”, nearly all configuration settings become read-only and cannot be changed via OPC UA anymore. The Variable setting is vendor-specific, including whether it can be changed via OPC UA. For example, if a fieldbus is currently active on the IO-Link Master, a server might set this Variable to “True” on all its ports.

That includes in detail following rules:

For the IO-Link Device connected to the IO-Link Port (Device Object) all Parameters become read-only.

For the IO-Link Device connected to the IO-Link Port (Device Object) all Methods defined in the IOLinkDeviceType except ReadISDU become not executable.

For the IO-Link Device connected to the IO-Link Port (Device Object) all Methods created based on the IODD become not executable unless the Methods only trigger the reading of ISDUs.

The Method ResetStatistics on the IO-Link Port and ResetStatisticsOnAllPorts on the IO-Link Master shall still be executable.

There is no direct relation between the DeviceConfigurationDisabled Variable and the Lock Object on the IOLinkDeviceType. The Lock Object prevents different OPC UA Clients to configure the IO-Link Device at the same time whereas the DeviceConfigurationDisabled Variable indicates that the IO-Link Master is in a state that does not allow the IO-Link Device to be configured by any OPC UA Client. When the DeviceConfigurationDisabled Variable is set to “True” Servers may prevent the usage of the Lock Object for all Clients.

The mandatory Object Capabilities shall reference the Parameters defined in Table 32. Servers may add vendor-specific Parameters to the Object.

The mandatory Object Configuration shall reference the Parameters and Methods defined in Table 33. Servers may add vendor-specific Parameters and Methods to the Object.

The mandatory Object ConfiguredDevice of the Configuration Object shall reference the Parameters defined in Table 34. Servers may add vendor-specific Parameters to the Object.

The mandatory Object Information shall reference the Parameters defined in Table 35. Servers may add vendor-specific Parameters to the Object.

The mandatory Object SIOProcessData shall reference the Parameters defined in Table 36. Servers may add vendor-specific Parameters to the Object.

The mandatory Object Statistics shall reference the Parameters defined in Table 37. Servers may add vendor-specific Parameters to the Object.

The optional Alarms Object is used to group all alarms of the instance, in case the server supports representing the alarms as Objects in the AddressSpace. If the server does not support this, the Object shall not be provided.

7.6.3 Variables of ParameterSet

In Table 38, the Parameters of the ObjectType, referenced via the ParameterSet Object, are defined.

The mandatory, read-only Variable PortClass shall be mapped to the corresponding entry in PortTypes of the MasterIdent structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the DataType Byte. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain the following content, defined in Table 39.

Servers are only allowed to add additional entries into the EnumStrings array according to the IO-Link Addendum or updates to the IO-Link Specification, also updating element number 1 once it is defined. Servers may provide translations of the texts in different locales.

The mandatory, read-only Variable MaxPowerSupply shall provide the maximum amount of power provided on the port. The Variable shall provide the EngineeringUnits Property defined in OPC 10000-3, having the value set to {namespaceUri = “http://www.opcfoundation.org/UA/units/un/cefact”; unitId = 4279632; displayName = {“en”,"A"}; description = {“en”, "ampere"}} (for ampere). The Property shall be read-only and have the ModellingRule Mandatory, so it is reflected on all instances. Note that the IOLinkMasterType also provides a MaxPowerSupply and potentially not all ports can consume the MaxPowerSupply at the same time.

The mandatory, read-only Variable Pin2Support indicates whether the port does support Pin2 at all. “False” means it is not supported, “True” means it can be supported. If it is supported, the Parameter Pin2Configuration can be used to configure how to use it and in case it is used to read or write values the Parameter Pin2ProcessData can be used to access the value.

All Variables provided directly under the Configuration Object are read-only. To change the configuration, the UpdateConfiguration Method defined in Table 43 needs to be executed. The Method call ensures that all configuration data is provided at once by the client in a consistent state.

The mandatory, read-only Variable CycleTime shall be mapped to the PortCycleTime of the PortConfigList structure defined in the SMI (see IO-Link Addendum). The data type mapping is defined in 12.2.7.2, having “0” as special meaning for “as fast as possible”.

The mandatory, read-only Variable ValidationAndBackup shall be mapped to “Validation&Backup” of the PortConfigList structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the Byte DataType. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain for locale “en” exactly the text as defined in the SMI. Servers are not allowed to add additional entries into the EnumStrings array, only based on updates of the IO-Link Specification. Servers may provide translations of the texts in different locales.

The mandatory, read-only Variable PortMode shall be mapped to PortMode of the PortConfigList structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the DataType Byte. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain the following content, defined in Table 40.

Servers are allowed to add additional entries into the EnumStrings array. Servers may provide translations of the texts in different locales.

The mandatory, read-only Variable Pin2Configuration shall be mapped to “I/Q behaviour” of the PortConfigList structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the Byte DataType. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain for locale “en” exactly the text as defined in the SMI. Servers are not allowed to add additional entries into the EnumStrings array, only based on updates of the IO-Link Specification. Servers may provide translations of the texts in different locales.

The mandatory, read-only Variable UseIODD defines whether the server shall use an IODD for the connected IO-Link Device or not. Details on the selection process are defined in section 6.1.7.

The mandatory, read-only Variable DeviceID shall be mapped to DeviceID of the PortConfigList structure defined in the SMI (see IO-Link Addendum), both of data type UInt32.

The mandatory, read-only Variable VendorID shall be mapped to VendorID of the PortConfigList structure defined in the SMI (see IO-Link Addendum), both of data type UInt16.

The mandatory, read-only Variable Baudrate shall be mapped to TransmissionRate of the PortStatusList structure defined in the SMI (see IO-Link Addendum). The UInteger8 shall directly be mapped to the Byte DataType. The EnumStrings Property of the MultiStateDiscreteType shall be used according to the values defined for the TransmissionRate in IO-Link Addendum, and shall at least provide all valid Values supported by the IO-Link Master.

The mandatory, read-only Variable ActualCycleTime shall be mapped to the MasterCycleTime of the PortStatusList structure defined in the SMI (see IO-Link Addendum). The data type mapping is defined in 12.2.7.2.

The mandatory, read-only Variable Quality shall be mapped to “PortQualityInfo” of the PortStatusList structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the Byte DataType. The Variable is of VariableType OptionSetType defined in OPC 10000-5. The mandatory Property OptionSetValues of the VariableType, which is an array of LocalizedText, shall contain the following content, defined in Table 41. Servers are not allowed to add additional entries into the OptionSetValues array, only based on updates of the IO-Link Specification. Servers may provide translations of the texts in different locales.

The mandatory, read-only Variable Status shall be mapped to PortStatusInfo of the PortStatusList structure defined in the SMI (see IO-Link Addendum). The Unsigned8 is mapped directly to the Byte DataType. The Variable is of VariableType MultiStateDiscreteType defined in OPC 10000-8. The mandatory Property EnumStrings of the VariableType, which is an array of LocalizedText, shall contain the following content, defined in Table 42.

Servers may update the values for 7-253 when the IO-Link Specification gets updated. Servers may provide translations of the texts in different locales.

The date since connection is running or not running is shown in SourceTimestamp of the Status. Because of this a server that supports persistent statistics shall not change the SourceTimestamp of Status on restart of the IO-Link Master or OPC UA Server.

The optional Variable Pin2ProcessData provides the process data value of the Pin2. The DataType is vendor-specific.

The optional Variable Pin4ProcessData provides the process data value of the Pin4. The Variable shall only be provided when the PortMode is set to “DI_C/Q (Pin4)” or “DO_C/Q (Pin4)”.

The optional, read-only Variable DateOfLastStatisticsReset contains the timestamp of the answer to the last call of the Method ResetStatistics, respectively ResetStatisticsOnAllPorts defined on the IOLinkMasterType. The timestamp information shall be as precise as possible. If the reset Methods were never called then DateOfLastStatisticsReset indicates the startup time. The optional Variable shall be provided when the optional Method ResetStatistics is provided.

The following Variables indicate the incidents since DateOfLastStatisticsReset. The server should persist statistics, also when the IO-Link Master or the OPC UA Server is restarted. However, if the statistics become inconsistent, the server is allowed to do an internal reset. This will result in the update of DateOfLastStatisticsReset. If the value of a counting Variable becomes larger than the maximum value of the DataType, the value shall remain on the maximum value.

The optional, read-only Variable NumberOfCycles contains the number of IO-Link frames on the wire since DateOfLastStatisticsReset. One cycle consists out of one request and response pair.

There are several reasons for the case that an IO-Link Master cannot receive a valid response of an IO-Link Device. It could be that electromagnetic interference (EMI) destroys a packet or that the device is not communicating or that the device was plugged off. If a master cannot receive a valid response, it sends the same frame once more (first retry) and if it gets no answer to this repetition, it sends the frame a third time (second retry). If there is no answer to the second retry, the communication is aborted.

The optional, read-only Variable NumberOfRetries contains the number of retries since DateOfLastStatisticsReset.

The optional, read-only Variable NumberOfAborts contains the number of times the communication was aborted since DateOfLastStatisticsReset.

The optional, read-only Variable NumberOfDeviceHasBeenExchanged contains the number of times a device with different RevisionID, VendorID, DeviceID or SerialNumber has been plugged in since DateOfLastStatisticsReset.

The SourceTimestamp of the counting Variables shall contain the time when the incident occurred and shall not change on restart of the OPC UA Server. This allows Clients to figure out when the variable changed the last time, e.g. when there was the last retry.

7.6.4 Methods of MethodSet

In Table 43, the Methods of the ObjectType, referenced via the MethodSet Object are defined.

7.6.4.1 ResetStatistics

The optional Method ResetStatistics resets all statistic data of the ports. Statistic data of a port are Parameters referenced by the Statistics Object of the IOLinkPortType Object starting with “NumberOf” and potentially vendor-specific extensions. As soon as statistic data is provided by the server, the optional Method shall be provided.

Signature

	ResetStatistics (
		[out]	Int32			Status
		);
	

7.6.4.2 UpdateConfiguration

The Method UpdateConfiguration takes all configuration data as input and updates the configuration of the port. The Method execution ensures that a client provides all configuration data at the same time in a consistent way and thus the server can deploy the configuration in one operation. If the configuration is not valid, the server returns a corresponding Status. As defined in the SMI (see IO-Link Addendum) depending on the configuration some arguments are treated as “don’t care”. For example, when the PortMode is IOL_AUTOSTART, the DeviceID, VendorID and ValidationAndBackup are ignored. The server shall not check those arguments and accept configurations with all possible values.

Signature

	UpdateConfiguration (
	 (
		[in]	Duration		CycleTime,
		[in]	Byte			ValidationAndBackup,
		[in]	Byte			PortMode,
		[in]	Byte			Pin2Configuration,
		[in]	Boolean		UseIODD,
		[in]	UInt32		DeviceID,
		[in]	UInt16		VendorID,
		[out]	Int32			Status
		);
	

7.7 DeviceVariantType

The DeviceVariantType provides information of a specific IO-Link Device variant as defined in the IODD. It is formally defined in Table 44.

An instance of DeviceVariantType maps to an IODD DeviceVariant.

The mandatory, read-only Property ProductId maps to the IODD DeviceVariant/@productId attribute.

The mandatory, read-only Property Name maps to the IODD DeviceVariant/Name element. Localization should be considered. For IODDs following the IODD Specification Version 1.0.1 the IODD DeviceVariant/ProductName element shall be used. Localization should be considered.

The mandatory, read-only Property Description maps to the IODD DeviceVariant/ Description. Localization should be considered. For IODDs following the IODD Specification Version 1.0.1 the IODD DeviceVariant/ProductText element shall be used. Localization should be considered.

The optional, read-only Variable DeviceSymbol maps to the IODD DeviceVariant/@deviceSymbol attribute. The defined path to an image in deviceSymbol shall be resolved and the file shall be provided as Image.

The optional, read-only Variable DeviceIcon maps to the IODD DeviceVariant/@deviceIcon attribute. The defined path to an image in deviceIcon shall be resolved and the file shall be provided as Image.

8 OPC UA Objects, Variables and Methods

8.1 General

This section defines Objects, Variables and Methods with NodeIds defined in this specification. Clients can directly use those NodeIds to access the instances, and use the functionality.

8.2 IODDManagement Object

The IODDManagement Object is used to manage IODDs. It contains Methods to load IODDs into the server and to remove IODDs. An example of an AddressSpace containing the IODDManagement Object and several IODD-based ObjectTypes is shown in Figure 26.

The IODDManagement Object is formally defined in Table 45. The IODDManagement Object shall be referenced from the Objects Object defined in OPC 10000-5 with an Organizes Reference.

The TransferIODD Object is used for a temporary file transfer (see OPC 10000-5 for details on the TemporaryFileTransferType). It is used to load new IODDs into the server, and, optionally, to read IODDs managed in the server.

The IODD provided by a vendor can consist of several files, providing the main XML-based file as well as optionally language files and images referenced in the main file (see IODD Specification). For loading and reading IODDs those files shall always be zipped into one file, representing the full IODD information of the device.

To load an IODD into the server, a new temporary file shall be created using the GenerateFileForWrite Method (defined in OPC 10000-5 as part of the TemporaryFileTransferType). The generateOptions argument of the Method shall be left as BaseDataType, meaning the Client shall pass a Null for that argument. After the file is written to the server, the Client shall call the CloseAndCommit Method (defined OPC 10000-5). Depending on the server implementation, the result of the operation is either directly returned in the Method call or via a state machine (see OPC 10000-5 for details).

The following rules for loading IODDs apply:

Servers shall reject IODDs they cannot interpret (e.g. using an unsupported version or invalid XML).

Server may reject an IODD if the checksum is invalid (see IODD Specification for details).

If the IODD to be loaded is already managed in the server (same DeviceID and VendorID).

The server may reject the loading operation if the IODD is used (there is an Instance of the ObjectType in the AddressSpace).

If the server loads the IODD it shall remove the previous version of the IODD (meaning removing the ObjectType) and assign potential Instances to the new ObjectType). In that case, the NodeIds of the Instances, including all Instances derived from InstanceDeclarations, shall not change.

If the server cannot manage the IODD due to limited resources it shall reject the loading.

Rejecting an IODD after calling the CloseAndCommit Method means that either the CloseAndCommit call directly returns a bad code or the returned completionStateMachine ends in the Error State (see OPC 10000-5 for details).

Note that the successful loading of an IODD typically leads to creating a corresponding ObjectType in this server. This is the recommended behaviour. However, it is allowed that servers do not create such an ObjectType before the ObjectType is used (e.g. by connecting a corresponding IO-Link Device to the IO-Link Master) due to limited resources of the server.

The server may also provide the capability to read an IODD managed by the server. In this case, the GenerateFileForRead Method (defined OPC 10000-5 as part of the TemporaryFileTransferType) is used to create a temporary file. This Method is mandatory on the TemporaryFileTransferType. If the server does not support reading an IODD the Executable Attribute of the Method shall be set to “False”. The generateOptions argument of the GenerateFileForRead Method shall be set to NodeId. The Client shall provide the NodeId of the ObjectType representing the IODD to create a temporary file for that IODD. Depending on the server implementation, the result of the operation is either directly returned in the Method call or via a state machine (see OPC 10000-5 for details). If the server supports this operation, a zipped file like for loading an IODD is returned.

The IODDs Object is used to group all ObjectTypes representing IODDs managed in the server. It shall reference all those ObjectTypes directly with an Organizes Reference.

8.3 RemoveIODD Method

The Method RemoveIODD removes an IODD from the server and is used by the IODDManagement Object (see 8.2).

The following rules for deleting IODDs apply:

If the IODD is used (meaning there is an instance of the ObjectType in the AddressSpace of the Server) and the force flag is set to “False” the operation shall fail. Clients need to remove the usage of the IODD first before it can be deleted.

If the IODD is used (meaning there is an instance of the ObjectType in the AddressSpace of the Server) and the force flag is set to “True” the operation shall succeed and remove all instances of the corresponding ObjectType in the AddressSpace.

Signature

	RemoveIODD (
		[in]	NodeId		IODD,
		[in]	Boolean		Force,
		[out]	Int32			Status
		);
	

Method Result Codes (defined in Call Service)

8.4 IOLinkMasterSet Object

The IOLinkMasterSet Object is referencing all Objects of IOLinkMasterType managed in the Server with an Organizes Reference (see Figure 9). It is formally defined in Table 46. The IOLinkMasterSet Object shall be referenced from the Objects Object defined in OPC 10000-5 with an Organizes Reference.

Since later versions of this specification might change the parent of this Object, Clients aware of this standardized Object shall not access it via its parent but directly via its standardized NodeId.

9 OPC UA EventTypes

9.1 General

The IOLinkEventType defines the base structure for all EventTypes providing simple Events (Notifications) defined in this specification. Subtypes are defined to distinguish between events originating from IO-Link Device, IO-Link Masters and ports of the IO-Link Masters.

The IOLinkAlarmType defines the base structure for all EventTypes providing alarms (Errors and Warnings) defined in this specification. Subtypes are defined to distinguish between alarms originating from IO-Link Device, IO-Link Masters and ports of the IO-Link Masters.

9.2 IOLinkEventType

The IOLinkEventType is the base EventType for Events generated from IO-Link Devices or IO-Link Masters. It is formally defined in Table 47.

The EventType inherits the Properties of the BaseEventType.

The mandatory Property EventId is a vendor-specific unique identification of the Event.

The mandatory Property EventType reflects the type of Event, so either the NodeId of the IOLinkEventType or a subtype.

The content of the Properties SourceNode, SourceName, Time, ReceiveTime, and Message is defined by its subtypes.

The optional Property LocalTime shall not be provided.

The Property Severity reflects the mode of IO-Link events. The IOLinkEventType or subtypes shall only be used for “Notification” and the severity shall be “200”.

The Property IOLinkEventCode is defined by the subtypes of the EventType.

9.3 IOLinkDeviceEventType

The IOLinkDeviceEventType is the base EventType for Events generated from IO-Link Devices. It is formally defined in Table 48.

The following rules for the inherited Properties apply.

The mandatory Property SourceNode shall be the NodeId of the object representing the IO-Link Device the event originates from.

The mandatory Property SourceName shall be the string part of the BrowseName of the Object representing the IO-Link Device the Event originates from.

The mandatory Property Time shall be the time the IO-Link Master receives the Event from the IO-Link Device.

Note that the event might have been generated already at an earlier time (more than communication delays) in the IO-Link Device, before it was received by the IO-Link Master.

The mandatory Property ReceiveTime shall be set to the time the OPC UA Server receives the event. In case the OPC UA Server runs on the IO-Link Master, this might be the same value as the value of Property Time.

In case the IO-Link event code is not described in an IODD, the mandatory Property Message shall be set to “IO-Link EventCode: 0x<xxxx>” for the English locale, where xxxx is the event code as hexadecimal representation. For example, for event code 0x18FF the message shall be “IO-Link EventCode: 0x18FF”. The server may provide different locales containing a translation of that string. In case the IO-Link Specification defines a specific string (Table D.1 of IO-Link Specification) for a specific event code, the server may also use that string instead of the generic message. For example, for event code 0x4000 the string “Temperature fault – Overload” is defined and can be used alternatively as Message.

The mandatory Property IOLinkEventCode shall provide the two-octet event code of the IO-Link Device as UInt16.

9.4 IOLinkIODDDeviceEventType

The IOLinkIODDDeviceEventType is the EventType for Events generated from IO-Link Devices based on IODD information. It is formally defined in Table 49.

The following rules for the inherited Properties apply.

The mandatory Property Message shall be mapped to the corresponding IODD Event/Description element. Localization should be considered. If the optional element Description is not provided, the mandatory element Name shall be used.

The mandatory Property Name shall be mapped to the corresponding IODD Event/Name element. Localization should be considered.

9.5 IOLinkPortEventType

The IOLinkPortEventType represents Events triggered by a concrete port of an IO-Link Master. It is formally defined in Table 48.

The following rules for the inherited Properties apply.

The mandatory Property SourceNode shall be the NodeId of the Object of IOLinkPortType the event originates from.

The mandatory Property SourceName shall start with the string part of the BrowseName of the Object of IOLinkMasterType the IO-Link Port is connected to, followed by a “.” and the string part of the BrowseName of the Object of IOLinkPortType the Event originates from.