CANopen FD device conformance testing
CiA tests the conformance of CANopen FD 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 FD device is only possible together with an XDD 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.
Device or family conformance testing
CiA offers conformance testing of a single CANopen FD device as well as a group of very similar CANopen FD devices (family test). The CANopen FD conformance testing is performed using the CANopen FD conformance testing procedure.
Although device testing is focused on the CANopen FD 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 FD network,
- wiring errors,
- etc.
CANopen FD conformance test procedure
The CANopen FD test procedure provides basic elements of the CANopen FD conformance test plan (specified in CiA 1310-1). The CANopen FD test procedure is base for CANopen FD conformance testing, till an official CANopen FD test tool is available. It includes the following test steps:
| # | Test step |
|---|---|
| 1 | Check the availability of the XML-based Device Description |
| 2 | Check the availability of the vendor-ID |
| 3 | Check, if the vendor-ID is related to the device manufacturer |
| 4 | Check, if all mandatory data objects are supported in the XDD file |
| 5 | Adjust net-ID, node-ID, and bitrate and check, if DUT registers itself in the network by transmitting boot-up message |
| 6 | Check, if boot-up write service is issued correctly |
| 7 | Check, if USDO upload expedited unicast service operates correctly, by accessing any supported data object |
| 8 | Check, if USDO download expedited unicast service operates correctly, by accessing any supported data object |
| 9 | Check, if USDO upload expedited broadcast service operates correctly, by accessing any supported data object |
| 10 | Check, if USDO download expedited broadcast service operates correctly, by accessing any supported data object |
| 11 | Check, if USDO upload segmented unicast service operates correctly, by accessing any supported data object |
| 12 | Check, if USDO download segmented unicast service operates correctly, by accessing any supported data object |
| 13 | Check, if USDO access is accepted from any USDO client |
| 14 | Check, if USDO remote upload expedited unicast service works, by accessing any supported data object |
| 15 | Check, if USDO remote download expedited unicast service works, by accessing any supported data object |
| 16 | Enable Heartbeat write service, trigger NMT state change(s) and verify the correct Heartbeat write service issuing |
| 17 | Check, if the USDO access is only supported in NMT state pre-operational and NMT state operational |
| 18 | Set synchronous counter overflow value, enable SYNC producer and verify counting of the SYNC counter |
| 19 | If supported, trigger EMCY write service and check correctness |
| 20 | If supported, trigger TIME write service and check correctness |
| 21 | Check, if all mandatory data objects are supported in the DUT |
| 22 | Check the content of the data object 1000 01h to 1000 08h for validity |
| 23 | Check, if all data objects supported by XDD file are also implemented in the DUT |
| 24 | Check, if synchronous PDOs can be triggered synchronously, cyclically |
| 25 | Check, if synchronous PDOs can be triggered synchronously, acyclic |
| 26 | Check, if event-triggered PDOs can be triggered by the event timer |
| 27 | Check, if PDO can be disabled according to PDO mapping procedure |
| 28 | Check, if PDO mapping can be changed according to PDO mapping procedure |
| 29 | Scan the object dictionary for hidden objects |
Test report and documentation
The company who ordered conformance testing receives the following technical documentation after the successful certification:
- CANopen FD certificate for the tested device or family,
- CANopen FD "certified" logo with number for the certified device resp. device family,
- test log, generated during testing procedure,
- detailed test report, generated by the CiA test engineer.
Certification data in public access
In case of a successful certification, the device can be listed on CiA website on request.
Conformance testing fees
Preparing the test report and the CANopen FD 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.
| Service | Fee non-CiA members | Fee CiA members |
|---|---|---|
| Basic rate per device test session (certificate incl.) | EUR 1000,00 | EUR 750,00 |
| Basic rate per family test session (3 device test sessions and certificate incl.) | EUR 2000,00 | EUR 1500,00 |
| Rate per hour | EUR 100,00 | EUR 100,00 |
Erroneous CANopen FD implementations
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 FD 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 1001h shall be 1, further bits may be set additionally.
- In case an error history (object 1003h) 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) 8210h.
- For CANopen FD conformance testing, an "error free" DUT is expected at DUT initial start up.
- Only if a 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.
- In case store, restore or both (objects 1010h/1011h) are supported, the DUT shall not trigger an internal reset command but shall wait for an external NMT reset command.
- 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 FD according to CiA 1301 version 1.0.0 or higher shall not support objects, which are reserved for compatibility reasons.
- However it is not the main subject of the CANopen FD conformance test, detected errors in the lower layers (e.g. generation of CAN error frames) may prevent successful device certification as well.