Integrating IO-Link Devices into CIP Networks
Pat Telljohann
Software Engineer
Rockwell Automation
Presented at the ODVA2014 Industry Conference & 16th Annual Meeting
March 11-13, 2014
Phoenix, Arizona, USA

Abstract:
IO-Link was introduced in factory automation in the year 2009 as a new communication interface for small
sensors and actuators. By now more than 50 companies are using IO-Link in their products and are supporting
IO-Link technology. This communication technology allows integration of small devices from different vendors
into a variety of field buses and PLCs. The current IO-Link Version (V1.1) is being standardized in IEC 61131-9.
This presentation describes the progress the ODVA IO-Link Integration SIG has made to define IO-Link Masterbehavior and other aspects of IO-Link integration into CIP.
Keywords:
IO-Link, Industrial Communication, IODD, IEC 61131-9, device description
Definition of terms:
Device Class information
A description of a device’s identity and capabilities. This information includes how the device is configured, I/O
connections supported by the device, the set of objects supported by the device, etc. For CIP devices, the Electronic
Data Sheet (EDS) holds this information, for IO-Link target devices, the IODD holds this information..
IODD (IO Device Description)
XML based document describing the data objects of an IO device. Provide information similar to an EDS file.
IO-Link Master
Device that bridges between IO-Link target devices and an automation system.
IO-Link Target Device
IO-Link sensor or actuator.

Introduction
The IO-Link SIG is charged with defining how IO-Link target devices are integrated into CIP systems via an IOLink master device. A paper was presented on this topic at the 2012 annual meeting; please refer to “Integrating IOLink Devices into CIP Networks”:
http://www.odva.org/Home/ABOUTODVA/GetInvolved/ODVAIndustryConferenceAnnualMeeting/ODVAIndustr
yConferenceAnnualMeetingLibrary/2012Library.aspx for introductory information. This paper provides an updateon the status of the IO-Link target device integration to CIP activity.
2014 ODVA Industry Conference

1©2014 ODVA, Inc.

Technical overview
The IO-Link technology defines a generic interface for connecting sensors and actuators to a master unit, which may
be combined with gateway capabilities to become a fieldbus remote I/O node.
The IO-Link technology covers a number of topics. The domain of devices is the sensors and actuators in the factory
automation field. These devices are near or direct in the process of a machine application.
The masters typically have a gateway application and are connected to a field bus. Therefore masters are connecting
IO-Link devices to a fieldbus or a PLC. IO-Link is closing the communication gap of the so called “last mile” tosmall devices.
The physical topology of IO-Link is point-to-point from each Device to the Master using 3 wires over distances up
to 20 m. The IO-Link physical interface is backward compatible with the usual 24 V I/O signaling specified in IEC
61131-2. 3 Transmission rates of 4,8 kbit/s, 38,4 kbit/s and 230,4 kbit/s are supported.
IO-Link is compatible to IEC 61131-2 and supports the digital input functionality “SIO” (standard input output) as
well as communication on sensor devices and also on masters. A master is able to switch at any time from SIO mode
to communication mode with the different transmission rates COM1, COM2 and COM3 and vice versa. While a
device supports exactly one transmission rate, the masters have to support all 3 transmission rates.
Once activated, the IO-link mode supports parameterization, cyclic data exchange, diagnosis reporting, identificationand maintenance information, and external parameter storage for device backup and fast reload of replacement
devices.
IO-Link/CIP Integration goals
The goals for integrating IO-Link target devices into a CIP system are as follows:
1.
2.
3.
4.

IO-Link target devices should be presented in CIP systems as if they are CIP devices (similar to Modbus
device integration – Volume 7).
IO-Link integration should be possible on existing EtherNet/IP, DeviceNet, ControlNet buses and on CIP
modular systems.
Integration of IO-Link target devices should not consume excessive system resources (like I/O
connections).
No changes required in IO-Link devices or IO-Link specification.

IO-Link devices have from 1-32 bytes of input data and 0-32 bytes of output data. With most having only a couple
bytes of process data, it leads to some conflicts in these goals because representing IO-Link target devices as CIP
devices will result in using more I/O connection resources than if I/O data from all the IO-Link devices wereconsolidated at the IO-Link master device, much like is done with communication adapter module in a modular I/O
rack. Also, supporting one I/O connection per IO-Link device is not possible in existing DeviceNet networks
because the master/slave connection set limits the number of connections between a connection originator device
and a target device (the IO-Link master device).
Because of these conflicts the work produced by the IO-Link SIG may result in multiple IO-Link modelingdefinitions.
General integration model
To support IO-Link to CIP integration the IO-Link master device will provide the integration between CIP and IOLink. The IO-Link Master device will support an uplink CIP port and multiple downlink IO-Link channels. The
general flow of control will be from a CIP originator device through the IO-Link Master device to individual IOLink Target devices. The figure below shows the relationship between a CIP originator device, the IO-Link Masterdevice and IO-Link target devices. Note that the CIP subnet(s) item in the figure below shows how the path fromthe CIP originator device to the IO-Link Master device could cross multiple CIP subnets (via CIP router devices).

2014 ODVA Industry Conference2©2014 ODVA, Inc.

CIP Originator Device

CIP subnet(s)IO-Link Master Device

IO-Link Target Device
Channel 1
IO-Link Target Device
Channel 2…
…
IO-Link Target Device
Channel N

Integration items
The following sections describe the items being defined for IO-Link integration.
IO-Link Master models
Due to network capabilities, multiple IO-Link to CIP integration IO-Link Master models may be defined.
The models being considered are listed below.
Common to each model, the IO-Link Master will have the functionality of “translating” between the CIP
world and the IO-Link world. In particular, when accessing IO-Link device parameter data in the Mixed
and Virtual CIP Router models, the request is sent as a true CIP request to CIP objects that are being“translated” from IO-Link data components into something that has the look and feel of a true CIP object.
Scanner
The IO-Link Master scanner model provides indirect I/O and configuration access to IO-Link
target devices.
The IO-Link Master device provides a configuration mechanism for placing each IO-Link target
device’s I/O data into a “collected” I/O Connection exchanged between a CIP originator device
and the IO-Link Master device. This “collected” connection’s configuration would also define the
IO-Link data type information for the I/O connection data to allow for translation from/to IO-Link
data types to/from CIP data types.
An object will be defined that is implemented in the IO-Link Master device that allows IO-Link
target device attributes to be accessed. The instance number will be the IO-Link target device
channel number.
Virtual CIP Router
The IO-Link Master virtual CIP router model provides direct access to IO-Link target devices.
I/O connections are opened using the Forward Open service; a port segment is included in theconnection path that specifies the IO-Link target device channel number. Part of the configuration
data provided when opening I/O connections will be the IO-Link target device I/O connection data
type information, for translation from/to IO-Link data types to/from CIP data types.
The IO-Link Master device will provide a “virtual CIP device” for each I/O Link channel for
attribute and I/O access. Each virtual device will have its own Identity object; attributes and I/Owill be accessed via CIP routing.

2014 ODVA Industry Conference

3©2014 ODVA, Inc.

MixedThe IO-Link Master mixed model provides mixed direct and indirect access to IO-Link target
devices.
The IO-Link Master device is provided a configuration defining where to place the IO-Link target
device I/O in a collected I/O Connection exchanged between a CIP originator device and the IOLink Master device. This configuration would also define the IO-Link data type information for
the I/O connection data to allow for translation from IO-Link data types to/from CIP data types.
The IO-Link Master device will provide a “virtual CIP device” for each I/O Link channel for
attribute access. Each virtual device will have its own Identity object; attributes will be accessed
via CIP routing.
The Virtual CIP Router model provides the best CIP integration because I/O connections and attributeaccess work in a manner very similar to real CIP devices. However, this model will not work for
DeviceNet due to the number of connections. Also, this model may not be desirable because of number ofconnection resources consumed (connection resources are often scarce). In addition, this model may not bedesirable because originator devices would need to support routing, which some originator devices might
not already do.
The Mixed model provides the same attribute access model as the Virtual CIP router model, but I/Oconnection data is very different than for a typical CIP device. This model will work for DeviceNetbecause a single connection can be used to transport I/O data. This model still requires the originator
device to support routing for attribute access.
The Scanner model provides the poorest CIP integration because it treats all the IO-Link devices on themaster as nothing more than a smart I/O point and part of a flat addressing space on the master. The I/O
connection mechanism is the same as the Mixed model. The attribute mechanism does not require the CIP
originator device to support routing.
IO-Link master devices may need to support all three of these models if a decision is made that all CIP
originators must be able to talk to any IO-Link Master device.
Details to support I/O Link Master Models
The following sections describe details for supporting the various scanner models described above.
Identity Object
Within CIP systems the Identity Object is the object that enables discovering devices that exist on
a network. The most critical aspect of the Identity Object are the required instance attributes,
those are:
1. Vendor ID
2. Device Type
3. Product Code
4. Revision (major and minor)
5. Status
6. Serial Number
7. Product Name
The identity information for an IO Link target device is not identical to the CIP identity
information. IO-Link target devices have a 16-bit Vendor ID and 24-bit Product Code. The
Vendor ID values overlap with CIP vendor IDs, so the IO-Link Vendor ID must not be presented
as a CIP Vendor ID. CIP supports a 16-bit Product Code, so the 24-bit IO-Link Product cannot bepresented as a CIP product code. There is no IO-Link Device Type or Revision.

2014 ODVA Industry Conference

4©2014 ODVA, Inc.

It is most likely that a fixed Vendor ID, Device Type, Product Code and Revision will be reported
for all IO-Link target devices similar to what is done for Modbus devices and the IO-Link Vendor
and Product Code values will be returned in a yet-to-be-defined IO-Link Identity attributes.
It is also likely that a new Identity Object, mechanism will be used to indicate additional identity
information is available. This new mechanism is in the process of being defined in the CIP
System SIG. The Identity Object Status Attribute bit 1 definition will be used to indicate that
additional identity information is available. A new service, Extended_Get_Attributes_All, will bedefined that provides the additional identity information. This service includes meta-data in the
response data to help the client understand the content of the response.
The value returned for the Serial Number attribute will be 0 (same as Modbus). The IO-Link
target device serial number (vendor-specific format up to 16 characters) will be returned with theadditional identity information in response to the Extended_Get_Attributes_All service.
The value returned for the Product Name attribute will be the first 32 characters of the IO-Link
target device Product Name. The full IO-Link Product Name will be returned with the additional
identity information in response to the Extended_Get_Attributes_All service.
Device Class Information
For CIP devices Device Class information exists in the device’s EDS file. For IODD devices
Device Class information exists in the device’s IODD file. An IODD to EDS translation definition
may be created to allow a client to create an EDS file from an IODD file. The IODD file isassociated to the IO-Link device using the IO-Link Vendor ID and Product Code values.
Device Keying
For CIP devices the Format 4 Electronic Key Segment will be used to verify the device being
communicated with is the expected device. For IO-Link a new Electronic Key Format will bedefined to verify the IO-Link device being communicated with is the expected device.
Attributes
CIP defines object attributes for holding various properties of objects and defines services for
attribute access, services like Get_Attribute_Single, Get_Attributes_All, Set_Attribute_Single and
Set_Attributes_All. These services all require an application path to identify the attribute(s) being
addressed.
IO-Link defines index and sub-indexing for addressing device properties and services foraccessing these properties.
A mapping of IO-Link index/sub-index to CIP application path will be defined and the existing
attribute services can be used for accessing the attributes, sub-index properties will be accessedusing Get_Attribute_Single and Set_Attribute_Single services, index properties will be accessedusing Get_Attributes_All and Set_Attributes_All services. Note that these CIP services may not
be supported or may not succeed in all cases because of differences between CIP and IO-Link datatypes (see Data Types section below).
A typical CIP path to access an attribute looks like “20 99 24 01 30 03”, where the 99 identifies
the class of the object being addressed, the 01 identifies the instance of the object being addressed
and the 03 identifies the attribute being addressed. For I/O Link attribute addressing, the 99
identifies the class of the object being addressed, the 01 identifies the index being addressed andthe 03 identifies the sub-index being addressed.

2014 ODVA Industry Conference

5©2014 ODVA, Inc.

Attributes may be accessed using a port segment to specify the IO-Link target device channel
number or an object in the IO-Link Master device may be defined that allows access to IO-Link
target device attributes (see Scanner Model section above).
Configuration
The application configuration is typically delivered to a CIP target device in the data segment in
the Connection Path attribute of the Connection Manager Forward Open service. A secondary
method for delivering application configuration to CIP target devices is by a series of
Set_Attribute_Single services as specified by the CfgAssemblyExa keyword in the device’s EDS
file. These same mechanisms will be defined for IO-Link, however, because IO-Link does notdefine the concept of a configuration assembly (which is where the application configuration data
is delivered from the data segment) a script of index/subindex and values will be defined for data
segment delivery or Set_Attribute_Single delivery.
The IO-Link Master device supports a mechanism for backing up the IO-Link target device
configuration. A block of configuration data can be uploaded for backup from an IO-Link target
device to the IO-Link Master device, the format of this data is unknown by the IO-Link Masterdevice. When an IO-Link target device is replaced the IO-Link Master device can download thisbackup configuration to the IO-Link target device.
When new configuration is provided from the CIP originator device to an IO-Link target device,
the IO-Link Master device will need to perform a backup operation.
In addition, it is likely some mechanism will be defined to associate the configuration delivered by
the CIP originator device with the current IO-Link target device configuration. This mechanism
will most likely be some sort of configuration signature. The benefit of this signature is the CIP
originator device will only need to deliver the configuration data when the configuration signature
is different.
Data Types
CIP data types are transmitted in little-endian order, IO-Link data types are transmitted in bigendian order. In addition there is not a one to one match between from IO-Link data types to CIP
data types. To deal with these issues all of these will be defined:
1.
2.
3.

The mapping of IO-Link data types to CIP data types.
Attribute services that can specify the IO-Link data types being set or gotten, these
services will be IO-Link specific services.
A mechanism to deliver I/O data IO-Link date type information to the IO-Link master.

These definitions will be used to allow an originator device to communicate with an IO-Link target
device using CIP data types.
For attribute access, there may be 3 types of access available:
1. Open service access (Get_Attribute_Single, Get_Attributes_All, Set_Attribute_Single
and Set_Attributes_All) – these services will be required to exchange data in CIP data
type format. The IO-Link Master device would be required to understand the IO-Link
format for the attributes being accessed. Because of the CIP data type format
requirement, implementation of the open services will be optional and if implemented
may return an error when the IO-Link format information is not available.
2. IO-Link specific service access for CIP data types (similar to Get_Attribute_Single,
Get_Attributes_All, Set_Attribute_Single and Set_Attributes_All) – these services will
include IO-Link format information in the service request to allow the IO-Link Master totranslate the IO-Link data types to CIP data types.
3. IO-Link specific service access for raw data (similar to Get_Attribute_Single,
Get_Attributes_All, Set_Attribute_Single and Set_Attributes_All) – these services will

2014 ODVA Industry Conference

6©2014 ODVA, Inc.

not provide IO-Link format information in the service request, the IO-Link Master device
will return the raw IO-Link data types.
NOTE: Either type 1 or 2 support will be required so a client can exchange data using CIP datatypes.
I/O Connections
The data exchanged in the I/O connections will be in CIP data type format (see Data Types above).
Depending on the IO-Link Master model (see above), IO-Link device I/O connection data may beexchanged in a direct I/O connection or multiple IO-Link target device I/O data may be combined
into a single connection.
If the IO-Link device I/O connection data is exchanged in a direct I/O connection the translationfrom Forward Open parameters to IO-Link behavior will be defined.

**************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible use of CIP
Networks and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because CIP Networks may be applied in many diverse
situations and in conjunction with products and systems from multiple vendors, the reader and those responsible for specifying CIP
Networks must determine for themselves the suitability and the suitability of ideas, opinions, and recommendations expressed herein for intended
use. Copyright ©2014 ODVA, Inc. All rights reserved. For permission to reproduce excerpts of this material, with appropriate attribution to theauthor(s), please contact ODVA on: TEL +1 734-975-8840 FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org.
CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP aretrademarks of ODVA, Inc. All other trademarks are property of their respective owners.

2014 ODVA Industry Conference

7©2014 ODVA, Inc.