IO-Link is growing at a remarkable rate around the world. By the end of 2019, there were already 16 million reported nodes. Since June 2019, a new base specification V1.1.3 has been available, which incorporates previous experience and simplifies and unifies integration into higher-level systems by means of a standardized master interface (SMI). In a “package” with the IODD specification and the test specification, it forms the core of the IO-Link system, around which a whole range of complementary specifications are grouped (Figure 1).
Since the base was completed, two working groups have been busy developing the appropriate satellites, i.e. IODD and test specification. The motives and objectives to be considered in this process will be explained in the following paragraphs.
Certification or Manufacturer’s Declaration
Now that IO-Link has spread globally, the question of IO-Link certification, which has not existed with IO-Link from the very beginning, arises time and again. The manufacturers of sensors and actuators were simply not used to incorporating such an additional process step in their numerous simple and cost-effective devices. The additional costs would have cancelled out the advantages of IO-Link. They already had comprehensive quality assurance for their devices, including input/output signals according to IEC 61131-2, and for the specific device technology. Therefore, a manufacturer’s declaration was created –and is accepted by end-users.
As a result, this path was also followed when the first professional basic specification V1.1.2 was completed in 2014. Low-cost test facilities for Devices and Masters should be available for use during development, production, and in the field. The successful application of these test facilities should then also be a prerequisite for the manufacturer’s declaration. Fortunately, right from the start there were member companies who wanted to bring such products to the market as technology providers, and finally did so successfully. While this path was quite easy for Devices, the Masters needed a little help to get started due to the smaller number of units and extra complexities.
The basis for such an approach was a test specification that was jointly developed by the companies and accepted by their quality managers. An important question was the degree of test coverage achieved. As always, when it comes to business issues, the IO-Link community was careful with the level of coverage and associated claims.
Claim of the Community
The most important goal was and is the interoperability between a Master Port and a Device. Since a Device also includes a complete electronic device description (IODD), it must be verified that the description matches the Device. The IODD itself is checked for compliance by a freely available IODD checker.
In addition, it is extremely important that neither the Master Port nor the Device is destroyed by the respective partner device (e.g. by out-of-spec voltages). The electromagnetic compatibility (EMC) test must also be regulated for all devices using the appropriate IEC standards.
Not covered by the IO-Link test specification (see Figure 1) are:
- Technology specific functions of a Device
- Performance stress tests, e.g. simultaneous operation of Master Ports
- Master gateways to higher-level systems (responsibility of the respective integration specification or IT protocol)
- Device profiles (responsibility of the profile specification)
- System extensions (e.g. functional safety or wireless)
- Master tools
- Compliance with other standards and directives/laws
History and New Situation
The first test specification V1.1.2 was already surprisingly good on the Device side, although there was no previous experience and the Device implementations were still fresh.
On the master side it was not that easy. There was no available knowledge to specify a uniform interface for all potentially possible upper level systems such as fieldbuses, IT systems, etc. As a result, this part of the test specification proved to be difficult and a special interface to master testers had to be developed and specified separately. Masters had to implement this interface additionally to run the tests.
Over the years, several CRs (Change Requests) for Test Specification V1.1.2 had accumulated in the database, which was processed by the corresponding Working Group and has now been incorporated into a so-called CorrVersion 1.1.2. This version is intended for test equipment manufacturers to maintain their “old” systems and is only available in the project database.
The lack of a uniform master interface “upwards” has led to a corresponding lack of uniformity in the behavior of Masters on the market. Customers therefore demanded largely uniform behavior of Masters and an interface that makes any master tool usable for different masters (at least for the most important basic functions). This interface is called SMI (Standardized Master Interface) and is described in the base specification V1.1.3. It is also designed to be used in test systems (Figure 2).
For the new version of the test specification, numerous IO-Link member companies have made their previous experience available. Newly delegated experts brought insights from their company’s internal test suites and from new Master implementations and enriched the lively discussions. The test cases were developed in about 60 teleconferences, each lasting more than 3 hours.
Rules for the Test Specification
All test cases are recorded and described in a datasheet (template). They should be largely independent and run completely.
The following criteria had to be considered when selecting a new test case proposal:
- Was there a CR in the database in the past?
- Were there any requests from customers?
- Is the proposal due to a change or new function in the basic specification?
- How high is the risk if the test case is not included?
- How high is the implementation effort and the influence on the delivery schedule?
Exception rules in the event of missing implementation of functions or if test cases do not pass are set out in a new document entitled “Exception Management” (see the download area of the IO-Link website).
Procedure
The test cases are divided into three groups:
- Physical Layer (PL)
- Device
- Master
It made sense to divide the working group into three corresponding teams to work in parallel. For each chapter there was a mentor who was responsible for revision proposals or new proposals.
Future new versions of existing specifications should always be started with a “Call-for-Experts” to form a homogeneous working group and to give new and international companies a chance to participate.
Brand New Master Test
Figure 2 shows the new architecture of a Master Tester System, consisting of a PC on which the Master Tester Program runs. Access to the Master as a Test Object (EUT) is usually provided via an Ethernet interface for the transport of SMI services.
Via a second interface, e.g. USB, a special controllable and observable “Pseudo Device” is supplied with instructions. This unit connected to a Port of the Master via IO-Link (SDCI) is called MTU (Master-Tester-Unit).
A test case usually starts with the presetting of the test object via corresponding SMI services and the presetting of the MTU via MTU instructions. These presettings can be called up under a name and are reused in several test cases (presetting macros).
A similar situation applies to the test procedures. Here, there are procedure macros consisting of SMI services for the test object (EUT) and MTU instructions for the Master-Tester-Unit (MTU).
In this way the master test cases are quite easy to understand and handle.
Testers and Test Systems
The test cases from all three groups are now complete, will be incorporated into the new test specification V1.1.3, and then subjected to intensive review, first internally and then in the IO-Link community in the usual way.
The technology provider companies are already working at great pace on the new versions so that they can deliver as soon as possible after the specification has been approved.
The expected Device testers and Master testers in accordance with Test Specification V1.1.3 are the prerequisite for the inclusion of IO-Link Safety protocol tests.
Continuous Improvement
The release of the new version of a specification is an important step. But for a system that is frequently implemented and deployed, a means to collect any necessary corrections, improvements, and comments, is required. IO-Link provides its CR database for this purpose, the access to which can be found on the second page of every IO-Link specification.