CANopen device conformance testing

CiA tests on request the conformity of CANopen devices. This includes devices developed and manufactured by yourself or devices bought on the market. CANopen device conformance testing is worth, because:

  • Manufacturers can prove to their customers that their products are CANopen compliant.
  • Customers can be sure, that CiA certified devices are CANopen compliant.
  • Testing by an independent third party is more trustworthy than device self-tests by the manufacturer.

Preparation for CANopen device certification

In order to arrange a test session at CiA testing laboratory, please contact CiA office. In advance of a device conformance testing, you may consider the following topics:

  • Device pre-testing saves time and money. Therefore it is recommended to send pre-tested devices to CiA office for conformance testing.
  • Testing of the CANopen device is only possible together with an EDS that represents exactly the not configured device to be tested.
  • Providing special equipment (e.g. special power supplies, special connectors, etc.) and brief installation guidelines safe time and money as well. At the CiA testing laboratory, plugs for the most often used connectors (e.g. D-Sub9, open-style, M12 mini-style, etc.) are available. With regard to power supply, up to 40 VDC at 6 A, 230 VAC at 16 A as well as 400 VAC three-phase at 16 A per phase are available.

Device or family certification

CiA offers to test a single CANopen device as well as a group of very similar CANopen devices (family test). The CANopen conformance testing is performed by means of the CANopen conformance test tool. The tool executes the following test steps:

  • Test of consistency and completeness of the EDS
  • Test of correct implementation of SDO and PDO
  • Test of correct implementation of the CANopen object dictionary
  • Test of correct implementation of SYNC-, Emergency- and Error control protocol
  • Test of correct behavior of the CANopen NMT state machine
  • Test of correct store-/restore behavior

Although device testing is focused on the application layer, implementation failures in lower communication layers may prevent a certification as well. Examples for such failures could be:

  • Erroneous Node-ID adjustment mechanisms
  • Device generates actively error frames in the network
  • Wiring error
  • etc.

Documenting the conformance test

In case of a successful test, the device is listed on CiA website, if desired. In addition the device manufacturer receives the following documentation:

  • CANopen certificate for the tested device resp. device family
  • CANopen certified logo for the tested device resp. device family
  • Test results, generated by the CiA conformance test tool
  • Detailed test report, generated by the CiA test engineer

Conformance testing fees

Effective from January the 1st 2014, CiA has adapted the prices for CANopen device testing at CiA testing laboratory. The fees are given in the table below. Generating the test report and the “certificate”, which indicates that a device has passed the test successfully, is already included in the fees.

Additional tests and support after completed testing, in which the product failed to comply, will be charged separately.

Service Fee non-CiA members Fee CiA members
Basic rate per device test session
(certificate incl.)
1000,00 €
(1190,00 € incl. German VAT)
750,00 €
(892,50 € incl. German VAT)
Basic rate per family test session
(3 device test sessions and certificate incl.)
2000,00 €
(2380,00 € incl. German VAT)
1500,00 €
(1785,- € incl. German VAT)
Rate per hour 100,00 €
(119,00 € incl. German VAT)

Erroneous CANopen implementations

An erroneous implementation of the subsequently listed topics may not necessarily be detected by the conformance test tool, but may prevent a successful device testing as well. Therefore it is recommended to check, whether the subsequently listed topics are implemented correctly in the device to be certified:

  1. In case the Heartbeat protocol is adjusted, the device under test (DUT) shall not respond to guarding requests.
  2. In case Life Guarding is supported and the DUT is in NMT state operational, the DUT shall transit to NMT state pre-operational in case of a Life Guarding Event.
  3. In case Heartbeat consumer is supported and the DUT is in NMT state operational, the DUT shall transit to NMT state pre-operational in case of a Heartbeat error is detected.
  4. In case of an device internal error, Bit 0 of Object 1001h shall be 1, further bits may be set additionally.
  5. In case an Error History (Object 1003h) is supported, the DUT shall report occurred errors consistent to the transmitted EMCY messages.
  6. In case the DUT generates emergency messages, the emergency message shall transmit 8 data bytes, coded according to CiA 301.
  7. In case the DUT generates emergency messages, reception of a too short PDO shall be indicated by an Emergency Error Code 8210h.
  8. For CANopen conformance testing, an "error free" DUT is expected at DUT initial start up.
  9. Only if a CANopen device profile (CiA 4xx) is supported by the DUT, the related profile number shall be provided in Object 1000h. Otherwise the part "device profile number" of Object 1000h shall be equal to 0.
  10. In case store/restore (Objects 1010h/1011h) is supported, the DUT shall not trigger an internal reset command but shall wait for an external NMT reset command. 
  11. In case RTR is disabled in the TPDO's COB-ID, triggering this PDO by RTR shall not be possible. In case the CAN-controller does not support to disable the functionality to answer to RTRs, configuration of a TPDO's COB-ID - with an Bit30 equal to 1 - shall be rejected by an appropriate SDO abort code (e.g. 06090030h).
  12. Adjustment of Node-ID/Bit rate via the DUT's object dictionary prevents typically passing the test. It is highly recommended not to adjust these parameters via the object dictionary.
  13. Devices supporting CANopen according to CiA 301 V4.0 or higher shall not support objects, which are reserved for compatibility (e.g. 100Bh).
  14. However it is not the main subject of the CANopen conformance test, detected errors in the lower layers (e.g. generation of CAN error frames) may prevent successful device certification as well.

General conditions

All deliveries and supplies of CAN in Automation are based on the General Conditions for the supply of products and services of the electrical and electronics industry ("GL")* for commercial transactions between businesses

recommended by ZVEI - Zentralverband Elektrotechnik- und Elektroindustrie e. V.
– as of January 2018 –
You may order a copy from the CiA office.


*"Grüne Lieferbedingungen" The original German text shall be the governing version.