Testing - CAN System Engineering - page 297

The first step on the way to a desired interoperability of CAN modules from dif-
ferent manufacturers in a CAN bus system was so taken with the publication of the
standard ISO 11898.

6.2.2.2 Risks of Complex Bus Systems

Due to the use of CAN in exceedingly complex and safety-related systems, a use
of CAN modules without prior checking is not feasible. Several risk factors can
restrict the proper communication between the CAN modules in such a significant
way that the entire bus system is no longer able to fulfil its function:

• Faults in the implementation: Standardized interfaces are only the “outside”, but
not the realization of the implementation. By implementing this freedom, can
faults be built into a device, at which the blur of interpretation 3 has an important
part? Especially those errors which lie in the blur of interpretation may not be re-
cognized in the accompanying development tests. Errors in the implementation
are often only seen when the module is embedded in its real environment with
all its influences and interactions.
• Interdependence of a module with its environment: The interdependence of a
module with its environment is one of the most common sources of faults in a
bus system. The networks themselves and their tasks are characterized by a very
large and still growing complexity. Therefore runs the number of possible events,
event sequences and combinations of events that result from the interaction of
the various components and the effects of component and network environment,
gets very large indeed. Thus, the probability is very low that in the specification
of the module all requirements are defined, which result from later applications.
• Gaps or errors in the underlying implementation of a standard: Information ab-
out the first publications of the ISO 11898 standards can be found at [CIA10] the
citation “[….] the ISO standard 11898 for CAN was published in November of
1993. [….] Unfortunately, all published CAN specifications and standardizati-
ons contained errors or were incomplete”. These early times are long gone, yet
gaps can occur in a standardized specification or subsequently become relevant.
During the development of a specification, the boundary conditions of the sub-
sequent use of the object of specification are often not considered or considered
just insufficiently. The reason for this lies mainly in the fact that not all later
applications are known and can be known. The type and depth of the aforemen-
tioned interdependence of a module with its environment are often ignored when
creating the specification. The development of a test specification is therefore
always a kind of “test for completeness” of the relevant product specification.

3 According to Sect. 6.1, blur of interpretation means: in the interpretation of a specification for
the purpose of implementation, small deviations between the intended content of specification
(goal of the author) and implementation (interpretation of converter ligands) can occur.