Testing CANopen products
Reiner Zitzmann and Monika Mack, CAN in Automation -- Test & Measurement World, 3/1/2005
The CANopen standard has become accepted for many applications, including industrial machine control, off-road vehicles, medical equipment, and marine electronics. One advantage of the growing number of CANopen products is that the user can choose the "ideal" device for an application. In order for CANopen products to continue to gain wide acceptance, they must be able to communicate with each other according to the CANopen specification.
CAN in Automation (CiA) is an international organization that develops and supports CAN-based higher-layer protocols. CiA has developed a test tool to check the conformance of a device to the CANopen application layer and communication profile (CiA DS 301 version 3.0 or version 4.02). This profile defines the basic communication mechanisms for exchanging data over CANopen-based networks, and it covers the structure of the object dictionary, the network management, and boot-up, as well as communication objects such as process data object (PDO), service data object (SDO), sync, and time stamp.
CiA engineers test and certify CANopen devices at our laboratory. Once a device has passed the test, it achieves certification to CiA DS 301. All products that comply with the specification can communicate with each other. This testing covers only the static requirements; it does not address timing requirements within a network. Even though timing requirements are not specified in any CANopen document, the CiA engineers often detect inadequacies concerning timing requirements and relay these results to manufacturers to help them improve their products.
Conformance test steps
![]() |
| Fig. 1 This screen shot shows the CANopen conformance test. |
- correct value ranges,
- support of mandatory entries,
- references pointing to existing entries, and
- consistency.
The second step involves testing the physical device itself. The CiA staff tests the application layer services, tests the EDS against the object dictionary of the CAN-open device, and verifies the network states and transitions.
Approximately half of the devices submitted for testing do not pass the CANopen conformance test on the first attempt. Erroneously implemented SDO abort-codes or EDS-files or simple misinterpretations of the specification are the most common reasons for test failures.
Future stepsFor the future, CiA plans enhancements for the communication interface test. The first addition will be a test for compliance to CiA DS 302 with emphasis on programmable devices. Further plans to test devices according to CiA DS 304 (framework for safety-relevant communication) and CiA DS 307 (framework for marine electronics) also are under way.
![]() |
| Fig. 2 CiA tests the communication interface of a device for conformance to the CANopen standard. In the future, application interface and timing behavior also may be tested. |
The communication interface test checks whether a device receives messages, while the device profile test checks whether the tested device acts on the received messages. Tests for compliance to CiA DS 401 (generic I/O modules ) and CiA DS 402 (drives and motion controllers ) are in development. As with the tests for DS 301, these tests will address only the static behavior of a device.
The third part of the planned enhancements includes a test of the timing (dynamic behavior) within a CANopen network. With the upper tester, the reaction time of a PDO that is sent to the DUT can be checked; it could also test how the device behaves at a defined network busload.
A generic upper tester is suitable for very simple devices, such as the generic I/O modules defined in CiA DS 401. For the more complex devices defined in CiA DS 402, a generic upper tester is not possible.
All these planned enhancements of the CANopen conformance test may also have an influence on how a device is certified. It is conceivable to distinguish between different levels of conformance testing, with a different certification provided at each level.
One model suggests that if a device passes the existing conformance test, it will be assigned a basic certificate (level 0). Should the device pass the device profile test (part of the upper tester), it would reach a higher level of certification and receive a level 1 certificate, for example. Finally, only those devices that pass an additional dynamic test would reach the highest level of conformance (level 2).
The advantage of such a level-structured certification would be that manufacturers could decide which level of certification suits their customers needs since not all devices require certification on all three levels to fulfill their purpose. For implementing a device, the manufacturer may only need to consider the requirements of one of the three conformance levels. For CANopen implementation, such a tiered system offers users the opportunity to conform to levels best suited to match customer requirements. For further information about CANopen, visit www.can-cia.org/canopen.
| Author Information |
| Reiner Zitzmann has a degree as engineer for electrical engineering from the Friedrich-Alexander University Erlangen, Germany. Since July 2004, he has been working for CAN in Automation international users' and manufacturers' group as a technical secretary. |
| Monika Mack holds a Master's degree in English literature and in history from the Friedrich-Alexander University Erlangen, Germany. She has held media and marketing positions in the US and in Germany, and she has worked as technical editor and public relations manager for CAN in Automation since 2002. mack@can-cia.org |



















