CANopen CC device conformance testing

CiA tests on request the conformance of CANopen CC devices.

This includes devices developed, manufactured or purchased by the conformance testing requester.

In advance of a device conformance testing, you should consider that 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 CC 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.

For more details on preparation to the CiA conformance testing and guideline for the filling out order form see here.

CiA offers conformance testing of a single CANopen CC device as well as a group of very similar CANopen CC devices (family test). The CANopen CC conformance testing is performed using the CANopen CC conformance test tool. The tool executes roughly the following major tests:

• test of consistency and completeness of the electronic data sheet (EDS),
• test of correct implementation of service data objects (SDOs) and process data objects (PDOs),
• test of correct implementation of the CANopen CC object dictionary (OD),
• test of correct implementation of SYNC-, emergency- and error control protocols,
• test of correct behavior of the CANopen CC network management (NMT) finite state automaton (FSA),
• test of correct store and restore behavior.

Although device testing is focused on the CANopen CC application layer, implementation failures in lower layers may prevent a successful conformance approval. Examples for such failures could be:

• erroneous Node-ID and bitrate adjustment mechanisms,
• device under test (DUT) generates actively error frames in the CANopen CC network,
• wiring errors,
• etc.

In case of a successful certification, the device can be listed on CiA website on request.

Effective from January the 1st 2014, CiA has adapted the prices for CANopen CC conformance testing at CiA testing laboratory. Preparing the test report and the CANopen CC certificate, indicating successful device or family certification is already included in the fees.

Additional tests and support after accomplished conformance testing, in which the product failed to comply, is charged separately.

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

• In case the heartbeat protocol is adjusted, the device under test (DUT) shall not respond to guarding requests.
• In case life guarding is supported and the DUT is in network management (NMT) state operational, the DUT shall transit to NMT state pre-operational in case of a life guarding event.
• 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.
• In case of an device internal error, Bit 0 of object 1001_h shall be 1, further bits may be set additionally.
• In case an error history (object 1003_h) is supported, the DUT shall report occurred errors consistent to the transmitted emergency message(s).
• In case the DUT generates emergency messages, the emergency message shall transmit 8 data bytes, coded according to CiA 301.
• In case the DUT generates emergency messages, reception of a too short process data object (PDO) shall be indicated by an emergency error code (EEC) 8210_h.
• For CANopen CC conformance testing, an "error free" DUT is expected at DUT initial start up.
• Only if a CANopen CC 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.
• In case store, restore or both (objects 1010_h/1011_h) are supported, the DUT shall not trigger an internal reset command but shall wait for an external NMT reset command. 
• In case remote transmission request (RTR) is disabled in the transmit PDO (TPDO's) communication object identifier (COB-ID), triggering this PDO by RTR shall not be possible. In case the controller area network (CAN) controller does not support disabling the functionality to answer to RTR frames, configuration of a TPDO's COB-ID - with an Bit 30 equal to 1 - shall be rejected by an appropriate service data object (SDO) abort code (e.g. 06090030_h).
• Adjustment of Node-ID and bitrate using the DUT's object dictionary prevents typically passing the test. It is highly recommended not to adjust these parameters using the object dictionary.
• Devices supporting CANopen CC according to CiA 301 version 4.0.0 or higher shall not support objects, which are reserved for compatibility reasons (e.g. 100B_h, 100E_h, 100F_h).
• However it is not the main subject of the CANopen CC conformance test, detected errors in the lower layers (e.g. generation of CAN error frames) may prevent successful device certification as well.