IO Link: Standardised Communication at the Lowest Field Level

01 September 2006

This interface for sensors and actuators represents the new standard for communication at the lowest field level. Integrated device parameterisation is provided by gateway and communication DTMs (Device Type Manager).

When the fieldbus era began, the main emphasis was on pure transmission technology. Today, automation is focusing more on intelligent end devices that not only offer additional functionality, but also extensive
diagnostic and status reporting. Automation providers are thus faced with the task of creating a suitable
communication path and an integrated engineering environment that can provide as well as control the
functionality of end devices.

Modern sensors and actuators already have extensive diagnostic and parameterisation functions. One of these ‘built-in’ features, for example, monitors the physical measuring devices by means of a lens contamination indicator for optical path sensors, warning thresholds for ageing and process-related control
variables or warning messages for environment-related faults. These functions are reported at the module via switching signals or device-specific displays.

Sensors and actuators that are part of a flexible production concept can also increase the productivity of the machine or system by dynamically adjusting their behaviour to prevailing conditions. As a result, they help reduce downtimes during setup as well as investment costs in new production equipment. Using these functions, however, requires an interface to the overlying engineering system that, so far, has not been
available.

Until now, the user has been forced to use proprietary software tools to access controller-dependent communication components. There was neither a uniform data structure nor any mechanisms for access control or data security. Hence, in cases where servicing was required, the user could not be certain whether the appropriate diagnostic software was installed on the notebooks used by maintenance
personnel or whether the correct data or even the correct password was available for re-parameterisation.

Requirements
In general, the requirements for a communication solution can be described in terms of ‘easy use,’ ‘high
availability,’ and ‘non-proprietary interfaces.’ The area of device parameterisation meets these requirements by using the FDT/DTM (Field Device Tool/Device Type Manager) standard, which will become an established platform for integrated configuration and diagnostics in factory automation. Software tools such as AutomationXplorer+ from Phoenix Contact offer a universal FDT framework application that serves as the basis for different DTM-based device descriptions or communication interfaces.

In this regard, device DTMs describe the functionality of the end devices while communication DTMs and
gateway DTMs represent, respectively, the network and the bridge between networks. FDT/DTM technology gives users an optimal means of universal, nonproprietary communication from the control level down to the end device level. The TCI interface (Tool Calling Interface), which has been integrated into AutomationXplorer+ and standardised by the Profibus User Organisation (PNO), can be used to access DTM-based communication descriptions from engineering environments that still have no FDT/DTM connection.

However, an interface technology that enables cost-effective communication using known topologies down to the sensor or actuator level has been missing. After the first proprietary developments of different device
manufacturers, the ‘IO Link’ research group was established under the auspices of the PNO. The objective of this group is to create a non-proprietary, network-independent and standardised interface that the engineering system can use to communicate with binary end devices in an efficient manner. The ‘IO Link’ research group is supported by the leading manufacturers of sensors and actuators and of industrial automation technology.

Tasks
To create this type of interface, three sets of tasks must be completed:

....Definition of a suitable technology that can be implemented into numerous end devices and master components by the majority of manufacturers in the shortest possible time and at the lowest possible cost;

....Definition of a transfer protocol that can ensure continuous data exchange in real-time. This protocol must include an option to map simple binary signals as well as complex analogue measurement data and configuration and diagnostic data. In addition, different communication methods with different transfer rates are necessary in order to cope with the resulting user data and remaining resources of the end devices; and

....Definition of network integration such as Interbus, Profibus and Profinet to promote wide-spread availability of IO Link.

Physical solution
IO Link involves a star-shaped, point-topoint connection from master to slave. Each master can have multiple ports to a slave. Depending on the implementation, the transfer route can feature a two or three-wire transfer mode. Communication and energy transfer are performed in multiplex operation in the two-wire transfer mode and separately in the three-wire transfer mode. Three transfer rates are available:

....4,800 Baud (COM 1)
....38,400 Baud (COM 2)
....230,400 Baud (COM 3)

Unshielded sensor-actuator cables (standard SAC cables) have been specified as the transfer medium. For connection requirements, the IO Link standard relies on common industrial round-plug connectors and M8 and M12 plugs. These plug connectors allow the user to fall back on a large installed base and existing
installation material and connection technologies, including Quickon or the Speedcon quick connection technology from Phoenix Contact. The signals are transmitted via 24 V pulse modulation and the standard UART protocol, which make special power supply sources unnecessary (Fig. 1).

By using the three-conductor connection scheme, full compatibility with the standard binary sensors and
actuators is achieved. In this case communication does not occur. A mixed operation of IO Link-enabled sensors and actuators and standard binary sensors and actuators is however possible. Furthermore, IO Link devices can alternate between the communication mode and the SIO switch mode (Serial Input Output). This function supports sensors that are unable to provide sufficient resources to process both the
measurement task and communication at the same time. This is why the corresponding end device is in
communication mode only when necessary. Integrity level 2 for communication is thereby achieved.

Protocol-specific solution
IO Link guarantees a deterministic transfer of process data in a typical cycle time of 2 ms with a parallel transfer of service data. Service data are transferred to the process data without interaction. In communication mode, up to 32 bytes of input and output data can be addressed as cyclical process data. In the alternate switch mode, the switching signals are sent in real-time and only service data flows through the communication channels.

Process data are divided into binary and analogue signals:

Binary signals: Switching information is transferred through continuous communication or, as before, in switch mode; and

Analogue signals: Analogue values are digitised and transferred through continuous communication.

Compatibility
One of the key requirements in the IO Link interface specification was full compatibility with the installed base as well as fieldbus neutrality. This is accomplished at wiring level through the use of a star topology and both unshielded SAC cables and standard M8 and M12 plug connectors. The COM 1, COM 2 and COM 3 communication modes and the SIO switch mode ensure the implementability of a variety of existing sensors and actuators. The integration of standard fieldbus systems helps protect the investments made by
device manufacturers in fieldbus connectors, infrastructure elements and configuration tools. Hence, wide support is provided by sensors, actuators and hubs.

Work on the IO Link specification, which has already been approved by the DKE (German Commission for Electrical, Electronic & Information Technologies of DIN and VDE) for IEC standardisation, is almost complete. The standard describes the physical properties, the IO Link transfer protocol and integration in
different networks in order to allow fieldbus-neutral and worldwide usage. The activities of the participating
manufacturers relating to independent, proprietary solutions are merged into the ‘IO Link’ standard.

Implementation
Intelligent sensors with an ASIC or microcontroller structure enable direct integration of IO Link functionality with the hardware. This requires only a few modifications. The information that is now available (e.g. availability of the dialog-enabled WT 18-3 light scanner of Sick AG) ranges from the serial number of the device and current parameter values such as the scanning range to the diagnostic reports on lens contamination or faults in the application environment (Fig. 2).

The devices of many sensor
manufacturers will soon feature an IO Link interface. Investment security is ensured through full compatibility with older standard systems that do not communicate. IO Link sensors can thus be used on standard I/O components and vice versa.

Master devices can be produced in a variety of different versions, as the example of Phoenix Contact components reveals:

....As an IP 65/67 device in the ‘standalone’ version, as an IO Link hub with integrated fieldbus interface such as the Fieldline Stand-Alone or as an IP 20 device like the Inline Block IO; and

....As an IP 65/67 local bus device in the ‘Fieldline Modular’ version or as an Inline Modular device in the IP 20 protection class.

All Phoenix Contact devices transmit IO Link signals to the controller via UART. The controller maps both the process and the diagnostic data according to the specific fieldbus. The difference between the modular device and the block or stand-alone version lies in the interconnection of a local bus system that links the modular components to a standard bus connector for Interbus, Profibus, or Profinet. The specific gateway or communication DTMs ensure that information is transmitted consistently and that communication relationships are maintained. If the Fieldline modular devices in IP 65/67 protection class are used, distributed stations can be designed based on a mixed configuration of IO Link and standard IO ports.

Outlook
IO Link will become the established standard for sensor-actuator communication beneath the traditional fieldbus and sensor-actuator bus systems. The use of a standard interface, which enables the connection of both binary as well as analogue sensors to the fieldbus and sensor-actuator bus systems, significantly reduces project planning and installation costs. Even the wiring costs are lower due to low variation among the I/O components.

This also applies to startup and setup times, which are minimised by transparent parameter storage. Based
on universal FDT/DTM communication, the time and costs associated with initial parameterisation and reparameterisation (e.g. if the machine is retrofitted) is greatly reduced. Machine downtimes can be brought to a minimum by means of differentiated diagnostics. If a fault occurs, the entire process map down to the lowest level is shown and the exact cause of the fault is recorded.

Fieldbus neutrality and compatibility with the installed base help protect the previous investments made by
manufacturers and users. Existing, non IO Link-enabled sensors can be used on IO Link without any problems. The type of the installation and the installation material remain the same. Given this background, it can be assumed that communication with FDT/DTM down to the lowest field level via the IO Link will be the catalyst for further advances in the area of sensor and actuator technology. The problem of communication falling short of the ‘last metre’ is thus solved.

Enquiry Code S231
Authors: Dipl.-Ing. Christian Gemke, Business Unit for Automation Systems, Phoenix Contact GmbH & Co. KG, Blomberg; and Dipl.-Ing. (FH) Zdenko Hrncjar, Product Manager, Sick AG, Waldkirch


Contact Details and Archive...

Related Articles...

Print this page | E-mail this page