CAN in Automation offers the service of an official test laboratory, where CANopen devices can be certified. The rules and regulations for testing CANopen devices can be found here. CANopen device certification is worth manufacturers’ as well as customers’ while:

• manufacturers can prove to their customers that their products are CANopen compliant
• customers can be sure, that CiA certified devices are CANopen compliant
• certification by a neutral third party is more trustworthy than device self certification by the manufacturer

Preparation for CANopen device certification

In order to arrange a test session at CiA testing laboratory, please fax this order form to CiA office and/or contact CAN in Automation: ct-test(at)can-cia.org. In advance of a device certification, please consider the following topics:

1. Device pre-testing saves time and money. Therefore it is recommended to send pre-tested devices to CiA office for certification. The CANopen conformance test tool used for certification is available here.
2. Certification of a CANopen device is only possible together with an EDS that represents exactly the unconfigured device to be tested.
3. 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 40Vdc at 6 A, 230Vac at 16A as well as 400V three-phase at 16A per phase are available.

Device or family certification

CAN in Automation offers to certify a single CANopen device (device certification) as well as a group of very similar CANopen devices (family certification).

• Device certification: Certification of single devices that have successfully completed the CANopen conformance testing at CAN in Automation.

• Family certification: Certification of a product family by means of conformance evaluation of a representative number of similar devices of that product family (e.g. modular device in different configurations).

CANopen device testing

CANopen device testing is done by means of the CANopen conformance test tool. The test tool executes the following test steps:

1. Test of consistency and completeness of the EDS
2. Test of correct implementation of SDO and PDO
3. Test of correct implementation of the CANopen object dictionary
4. Test of correct implementation of SYNC-, Emergency- and Error control protocol
5. Test of correct behavior of the CANopen NMT state machine
6. 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.

Documentation

In case of a successful device certification, the device is listed on CiA website in the chapter certified CANopen devices. 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

Fees for device certificaton at CiA testing laboratory

Effective from January the 1^st 2008, CAN in Automation adapts the prices for CANopen device certification at CiA testing laboratory. The new fees for certification services are illustrated in the table below. Generating the certificate, which indicates that  a device has passed the test successfully, is already included in the certification fees.

To top

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 certification 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 1001_h shall be 1, further bits may be set additionally.

5) In case an Error History (Object 1003_h) 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 8210_h.

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 1000_h. Otherwise the part "device profile number" of Object 1000_h shall be equal to 0.

10) In case store/restore (Objects 1010_h/1011_h) 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. 06090030_h).

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. 100B_h).

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.

To top