The rapid growth of IO-Link continues unabated. By the end of 2017, there were more than 8 million registered nodes and the number is anticipated to grow rapidly in the forthcoming years. This is why the IO-Link Community has been systematically engaged with functionally safe communication for the past few years, beginning with a study and then in depth with market requirements. Over 20 well-known companies in the field of functional safety were involved in version 1.0 of the “IO-Link Safety ‒ System Extensions” technical specification, which appeared in April of 2017. The concept of secure communication had been previously validated by the TÜV-SÜD technical inspection association in Germany. What’s happened since then?
The group’s agenda had three main topics: feasibility of the concept in different IO-Link device architectures, the new Standardized Master Interface (SMI) requested by customers and the test specification (including testing equipment).
Classical Functionally Safe Automation
For a clearer understanding, the technology of IO-Link Safety and a few significant advantages are presented here. The starting point is the classical connection of simple safety devices to Remote I/O at a fieldbus with a Functional Safety Communication Profile (FSCP) as shown on the left in Figure 1.
Depending on the sensor or actuator type, an FS AI (analog input), FS AO (analog output), FS DI (digital input) or FS DO (digital output) is required for the implementation of modern safety solutions. As is already the case with the basic IO-Link, the range of I/O modules is reduced to a single type with IO-Link Safety (the FS master), as shown in Figure 1.
Up until now, functional safety in automation has been characterized by switch-off functions like “emergency-off” and “emergency-stop,” and corresponding binary sensors such as switches, light barriers and laser scanners have been widespread. With IO-Link Safety, it will be possible to safely collect more analog measurements and then allow the safety controller to decide whether or not switch-off or safe stoppage is required.
Why IO-Link Safety?
Generally, these kinds of applications can also be implemented on the fieldbus level with an FSCP using safe field devices. Currently, there are already more than 10 FSCPs with regional focal points around the world, however. For device manufacturers, the development expenditure for communication interfaces would be greater than those for the actual safety technology if they are striving for worldwide marketing.
Figure 2 shows the solution with IO-Link Safety. An universal FS device with IO-Link Safety is compatible with all FSCPs if there is at least one FS master for this FSCP x. As there are usually specialized manufacturers addressing the use of IO-Link masters on specific fieldbuses, it’s only natural that these specialists would commit to the FS master version. FS device manufacturers can then fully concentrate on the safety task of their devices.
It will take a while for this market to become established. The migration strategy of IO-Link Safety will make this easier. IO-Link’s early history involved the transition from so-called SIO mode (switching mode) to IO-Link communication mode. This means that a device could be connected either in switching mode to a classical DI module or in communication mode to the new IO-Link master.
OSSDs
Safety switch-off sensors are also known as OSSDs (Output Switching Sensing Devices). These involve redundant signals which initially originated from relay outputs and which were switched in an antivalent fashion for the detection of cable faults. As the transition to electronic solutions took place, a change to equivalently switching signals also occurred, as an antivalent condition is no longer possible in case of a loss of power. Brief, staggered test pulses which are read back by the device and evaluated now serve to detect faults.
This is why it was decided to limit the multitude of existing test pulse solutions for IO-Link Safety to one type “C” class “1” solution which covers a very large number of market cases and which was defined in position paper CB24I of the German Electrical and Electronic Manufacturers’ Association (ZVEI). This is easily possible, as the maximum permissible cable length with IO-Link is 20 meters. IO-Link Safety is expected to provide very stable operation and simplification for users thanks to the elimination of filter and discrepancy time settings (staggering of the two signals). The solution is OSSDs.
With IO-Link Safety, the second OSSD signal is assigned to pin 2 of the M12 plug. This assignment is compliant with the specifications of the Automation Initiative of the German Automotive Industry (AIDA).
IO-Link Safety Communication
For communication mode, the tried-and-tested “Black Channel” principle as illustrated in Figure 3was selected for IO-Link Safety. A secure communication layer is placed on top of the existing communication stack of the IO-Link master (“master”) and the IO-Link device (“device”). In addition to handling management tasks, this layer consists of a protocol status machine for the reception and transmission of secure data (safety PDU) comprised of secure process data and an additional security code. The protocol is responsible for checking the timely reception of new data which originates from the correct sender and must be unaltered.
IO-Link Safety utilizes two protocol formats. One format is for small data volumes up to 3 octets with a correspondingly short security code, while the other is for up to 25 octets with a longer security code.
Figure 3also shows the connection of the IO-Link Safety communication layer of the FS master with the higher-level FSCP layer of the fieldbus. In the implementation, both layers can be implemented as software, e.g. in a single redundant unit.
Standardized Master Interface (SMI)
Over the past year, major customers requested improved harmonization of the behavior of the IO-Link master and approval to operate masters from various different manufacturers on a single master tool. When IO-Link was designed and specified several years ago, there were specialized fieldbuses, and only a few of these were based on Ethernet. At the time, a solution could not be addressed due to a lack of oversight knowledge. This has since changed. Ethernet-based fieldbuses have since become the rule, and experience has been gained in “docking” IO-Link with fieldbuses.
Figure 4shows the top layers of a master (in this case, an FS master) comprised of the configuration manager, parameter data keeping, acyclic communication, the diagnostic unit and cyclical process data exchange.
SMI specifies standardized services for each of these units, which can be called up from the gateway. The gateway ensures adaptation to the respective user protocols. For the FS PLC, this is the fieldbus with its FSCP. For the FS master tool, it is the Ethernet User Defined Protocol, for example.
IO-Link Safety had to expand the standard SMI for the configuration manager due to the safety parameters, for example. The splitter/composer for cyclical process data exchange is a special feature. Here, the safety PDU is separated from the non-safety-related process data in a received IO-Link message or composition before sending.
The SMI for IO-Link Safety is of crucial importance. Thanks to the SMI specifications for the FS master which have now been detailed, safety assessments can be moved up from the implementation level to the specification level, making implementation considerably easier.
Development Kit or Technology Provider?
The IO-Link Community is in the fortunate position of being the necessary driving force behind a development kit for IO-Link Safety. Among the member companies are so-called technology providers, which can lend assistance as early as the design phase of a device and offer technological components (stacks). For information on this, visit www.io-link.com.
Test Specification and Protocol Tester
As a result of these innovations, the test cases in the test specification must be expanded. As early as the design phase, both protocol status machines were simulated using computers with the goal of generating test samples for an automated protocol tester. The test samples are currently being optimized to prevent long testing times.
Further Work on Version 1.1
The integration of the SMI into version 1.1 of the IO-Link Safety specification has been carried out. This is currently being subjected to an international review lasting several months and can be downloaded from www.io-link.com. Nothing major has changed with the protocol itself.
At the same time, supplemental concept evaluations are being carried out at testing laboratories. Publication is expected over the next few months.
Dr. Wolfgang Stripf
Head of the Project Group “IO-Link Safety”