Conformance and interoperability testing

Compatibility is just a marketing term. Testing of conformity is nice to have, but customers are more interested in interoperability. With CAN controllers, different test plan implementations can lead to different results. CiA and other consortia organize so-called plug-fests, where prototypes and just released devices are tested on interoperability.

By Holger Zeltwanger March 13, 2015

For many years, carmakers in the automotive industry have requested a conformance testing of CAN controller chips. The conformance test plan has been internationally standardized in ISO 16845. Everyone is allowed to implement the test plan to "certify" CAN controllers, but different test plan implementations can lead to different results. One product may pass one test and fail another one. Even worse, the testing may differ because of different test patterns or the test plan doesn’t specify the CAN-ID to be used. To overcome this, the original equipment manufacturers (OEMs) request all chipmakers to go to the same test house for conformance testing, C&S group in Germany. This means most of the CAN controllers on the market have been "certified" by this company.

The non-automotive CAN users often use standardized higher-layer protocols such as CANopen and DeviceNet. There are conformance test plans specified for both application layers. The related user organizations, CAN in Automation (CiA) and ODVA, provide conformance test services, which guarantee that all products are tested by the same test environment. In DeviceNet the conformance testing is mandatory; in CANopen it is optional. Keep in mind, conformance testing is just like spell checking; you proof the grammar and the spelling. This doesn’t guarantee that two products passing the conformance testing will understand each other, much like in human communication.

If you write the three-word sentence "I love you" correctly spelled, it can be still misinterpreted. Let’s assume you have been married for a long time and have not said these magic words for several years. While you’re out of town on a business trip, you include these three words in an e-mail to your spouse. I would guess that your darling will misinterpret the message and think, "What has happened on the business trip?" This is what I like to call interoperability.

In a technical communication system, this is compared to an in-system test. Of course, this test is just valid for this system and its devices. CiA also provides CANopen interoperability tests. They prove that CANopen devices can communicate with a PLC by Schneider Electric or another host controller. The physical layer also tests the bit-rates and the network length. In DeviceNet, those physical layer things are tested during conformance testing.

In general, compatibility only says that you can connect the device to the communication network. The next level of compatibility is the tolerating of the data link layer. In a CAN-based network, a situation may arise where some devices are using the 11-bit CAN identifier (CANopen by default and DeviceNet), while others are using just the 29-bit CAN-IDs (for example: J1939 and Isobus). The messages identified by the CAN-ID still have different meaning when using different higher-layer protocols, but they can just coexist. If you like to interconnect two CAN devices, they need to support the same higher-layer protocol. I remember a gentleman who came in for CANopen conformance testing. His product had already successfully passed the DeviceNet test, but his device failed in the CANopen test. Surprised, he said to me, "Both are based on CAN; why don’t they pass your test?"

If you want CANopen or DeviceNet products that can inter-work, they need to use process data with the same data types on the receiving and the transmitting side. You can exchange generic signals, such as a 16-bit analog value. If you like that the application functionality is compatible, you need standardized profiles. They define that a specific parameter or object is the motor speed given in meters per second, for example. This interoperability is what system designers like to have. The same is true for my daughters when they communicate by e-mail with their friends. They violate grammar and spelling rules, but they still understand each other. Of course, correct spelling and grammar increase the probability that there is no misunderstanding.

If a real inter-changeability of products is required, you also need to standardize the dynamic behavior of CANopen or DeviceNet products. This has not been done yet. It would freeze technology and offer no add-on value to compete against others-just the price matters, and eventually the quality.

CiA and ODVA have standardized many device, interface, and application profiles for CANopen, respectively DeviceNet. However, the exchangeability is still a challenge, because there are optional functions due to many variants on the market. Therefore, CiA has started to limit the number of functional permutations. The profiles are introducing device classes with different mandatory features. This invites device implementers to provide a reduced number of variants.

Conformance testing is a first proof that a product complies with a communication standard. Interoperability testing evaluates that different products can coexist in a network (not disturbing others) and are functionally compatible. CiA and other consortia organize so-called plug-fests, where prototypes and just released devices are tested on interoperability. CiA is doing this for generic CANopen devices, for special-purpose devices (e.g., for elevators), or for the new CAN FD products. The next CAN FD plug-fest will take place in Detroit at General Motors.

– Holger Zeltwanger is managing director, CAN in Automation; edited by Anisa Samarxhiu, digital project manager, Control Engineering, asamarxhiu@cfemedia.com 

Key concepts:

  • Compatibility only says that you can connect the device to the communication network.
  • If you want CANopen or DeviceNet products that can inter-work, they need to use process data with the same data types on the receiving and the transmitting side.
  • Conformance testing is just like spell checking; you proof the grammar and the spelling. This doesn’t guarantee that two products passing the conformance testing will understand each other, much like in human communication.

Consider this

How would you test a product to see that it complies with a communication standard?

ONLINE

Read more from Holger Zeltwanger and learn more about CANopen in the articles below.