Open search
Advertisement

CAN Newsletter magazine

Modularity without interoperability testing does not make sense

Conformance testing is not sufficient to prove the interoperability of devices. A “golden system” or plugfests are needed additionally.

(Photo: Adobe Stock)

This article originally appeared in the March issue of the CAN Newsletter magazine 2019. This is just an excerpt.

Increasingly, network system designers need to develop systems, which are highly configurable. In extreme, each system is unique. Modularization is the solution. Of course, to reduce the development effort, the module interfaces should be standardized. This can be done proprietarily or openly meaning that official standardization bodies such as ISO and IEC or industry associations such as CiA or SAE release such interface specifications.

In case of open network approaches, system designers demand increasingly conformance tested products. This is why in the automotive industry CAN conformance testing on the chip level is on the agenda since many years. Nearly all CAN protocol controllers used by automakers are conformance tested. Since the beginning, Bosch provided such a test tool to the CAN chipmakers. In the meantime, there are two CAN conformance test plans internationally standardized: ISO 16845-1 for the CAN data link layer and ISO 16845-2 for the CAN transceivers including those with low-power mode and selective wake-up capability. Typically, those conformance test systems are based on the conformance testing methodology and framework as standardized in the ISO 9646 series.

Impression from the Isobus plugfest in Bologna (Photo: AEF)

Conformance testing is also a topic for CAN-based higher-layer protocols such as CANopen. CiA provide since many years, a CANopen conformance test tool, which implements the CANopen test plan as specified in CiA 310-1. The CiA office uses this tool for conformance testing. The CANopen conformance testing is not mandatory. Unfortunately, there are some devices on the market claiming CANopen conformity, but they just may contain traces of PDOs and SDOs. Those products make the system designers unhappy. Lessons have been learnt: For CANopen FD devices conformance testing at CiA office is obligatory.

For the SAE J1939 protocols no conformance test plans exist. The J1939-based Isobus network standardized in the ISO 11783 series provides conformance test plans developed by the nonprofit AEF association. All Isobus-labeled electronic control units (ECU) must be conformance tested by one of the authorized test houses. Conformance testing is like spellchecking in human communication. It just tests the behavior of one single device. The device-under-test (DUT) is justified that its communication interface complies with the conformance test plan. Normally, the test set-up comprises the DUT and the lower tester (LT) generating test pattern and evaluating the response on the bus-lines. If also the interface to the higher-layers is tested, an upper tester (UT) is needed.

The LT and the UT are linked by means of an interface, in order to evaluate the reaction on the test pattern on the upper interface. As said, conformance testing does not prove the interoperability between devices. This is the same as in human communication: Spellchecking does not guarantee that the reader interprets correctly your text; it just demonstrates that you have not violated grammar rules and that the words are well spelled.

If you want to continue reading this article, you can download the PDF of Holger Zeltwanger. Or you download the full magazine. This is free-of-charge.

cw



Publish date
2019-03-12
Company

CAN in Automation

Breadcrumb
Advertisement
Ixxat