Interoperability of CAN FD transceivers
The C&S Group has developed an interoperability test system according to the CAN FD physical layer interoperability test specification and have offered interoperability testing since November 2016.
Since Bosch released the first version of the CAN FD protocol specification, the first CAN FD transceivers, supporting communication in the CAN FD fast phase at higher data rates are available. Automotive manufacturers are currently working intensively on realizing the first CAN FD systems within their vehicle architectures.
One building block to achieve this goal is to guarantee the correct inter-action of all components within the target-distributed system—the interoperable behavior. After having addressed CAN FD conformance testing in the new international standards, ISO 16845-1 and ISO 16845-2, requirements from original equipment manufacturers (OEMs) and silicon vendors were collected and aligned, and test cases have been drafted and specified to enable interoperability of CAN FD transceivers in a multi-vendor environment.
The first release of the "Interoperability test specification for high speed CAN transceiver or equivalent devices" was published in June 2016. What are the differences between conformance testing (CT) and interoperability testing (IOPT)? The basic idea of conformance testing is testing to determine whether a product or system meets some specified standard that has been developed for efficiency or interoperability.
Fundamentals on conformance testing include:
- To apply conformance testing, a specified standard must exist.
- Different implementations of a standard are existing or planned.
- The conformance test does not ensure the quality of the specified standard itself; it verifies the adherence of implementations of the standard to the standard.
Interoperability is a property referring to the ability of diverse products or systems to work together (to be able to interact, to communicate).
Fundamentals on interoperability testing include:
- Interoperability is a property that is based on intended functional.
- Interoperability is relevant, if multiple entities shall interoperate.
- Specified standards shall describe interoperable products and systems, i.e. the intended functional behavior.
- Consequently, interoperability is a result of adherence of implementations to their specified standard.
It can be assumed that a solution of a single supplier, even if it would not adhere to the specified standard, is basically interoperable with other implementations of the same kind. If all share the same non-standardized behavior, they have a good chance to "interact" apparently correct. If another implementation is introduced, a non-standardized behavior of an implementation might prevent the expected (specified) behavior in certain situations that are difficult to find in system-level tests and by try-outs.
Therefore, the conformance test and the interoperability test need to be considered in case of multi-supplier solutions. If multiple suppliers create products or components based on the same specified standard, there is unfortunately a certain chance to create implementation containing deviations. Of course, each supplier has got their own ideas on how to realize a product as well specific knowledge and a specific idea on the product. This means different suppliers may read the specified standard differently. Even a message, note, or text can result in different interpretations depending on the reader.
The goal of all network and application designers is interoperability and a correct application and system behavior. To achieve this goal, interoperability testing in addition to conformance testing is one further building block. Such interoperability tests are performed on standard system and typically care for the behavior of the application that is realized by a distributed system. The benefit is that such tests can be set up quite easy, by a simple mock-up. The implementations are tested for basic operations but also for stress conditions in terms of configuration, functionality, and error scenarios.
In that way, it can be proven that each implementation adheres to the specified standard and that all nodes in a system can rely on the respective capabilities, ranges and limits given by the standard. The scope of the interoperability tests specification is the definition of test cases and test requirements to realize a test plan for the verification of high-speed transceivers or equivalent devices regarding their interoperability, even if provided by different manufacturers.
The aim of the interoperability tests is to increase the probability of collaboration of CAN high-speed transceivers within a CAN system and to increase the confidence level in this regard. The interoperability tests, which are defined within this test specification, are based on a predefined reference environment. The tests are performed within the reference environment, using predefined settings to ensure a high level of repeatability and comparability of the test results. The defined interoperability tests are focused on the transceivers or equivalent devices; for that reason, the additional devices, like common mode chokes or electrostatic discharge components, are not in use. The defined reference environments contain wire harness and passive components (resistances and capacitors) only.
The behavior of a transceiver or equivalent device can be represented by a state machine. The transitions from one state to another represent reactions to certain events such as mode change requests, bus failures, ground shifts (or their combinations). The defined interoperability tests verify the sequential behavior of the IUT in reference to the specified sequential behavior.
The C&S Group has developed an interoperability test system according to the CAN FD physical layer interoperability test specification and offer interoperability testing since November 2016.
Christoph Wosnitza, C&S Group. This article originally appeared on CAN in Automation’s (CiA)’s website. CAN in Automation is a CFE Media content partner. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, email@example.com.
See additional stories from CAN in Automation linked below.
Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.