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.

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.

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.

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

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.

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.

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.

image010.png

Figure 6 – State machine describing if an Object is connected to an IO-Link Port

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