Civil Engineering Reference
In-Depth Information
6.4.3
Requirements on Tests and Test Systems
Standards require conformance tests checking whether an implementation is com-
pliant to its corresponding standard. This does not imply that all such implementa-
tions must provide the same source code. However, they must match the given spec-
ification, e.g. their interfaces, functionality and configurability if specified so. As
such, e.g. software modules for communication systems such as CAN must match
some requirements which are explained subsequently.
6.4.3.1
Hardware-Dependency, Test Support on Target Platform
Some parts of the CAN-Software-Stack are hardware dependent. Therefore, drivers
for CAN controllers are significantly different with regard to their interfaces to the
hardware while the interface towards the higher software layers can be standard-
ized, as it is the case, for example, in AUTOSAR. Functionality and performance of
a CAN driver can only be reasonably tested in conjunction with the target hardware
which, in most cases, is an embedded CAN controller. Finally, this is the only way
to check whether the control function of the driver achieves the desired behaviour
of the CAN controller towards the bus. A CAN driver applied onto the wrong CAN
hardware is not functional. This implies that the real hardware cannot be substituted.
Under the assumption that the applied CAN controller is proven to be confor-
mant, any potential failure must come from the software when performing further
tests. The standardized and accessible interfaces to the test candidate, therefore, are
the software interfaces towards the next higher software layers as well as the digital
signals and, in conjunction with a CAN bus driver, the analog bus signals. Insofar,
the lower layer of the CAN controller software is accessed while passing through
the CAN controller. This is a typical method which is applied if the direct interface
of a test candidate is either not standardized or not directly accessible. Test descrip-
tions and test system must consider this kind of structure. From an abstract point of
view the addressed protocol layers below the tested layer belong to the service pro-
vider which only acts as a transfer station for test messages or stimuli. AUTOSAR
identifies the combined tests of software modules as “class B” tests.
6.4.3.2
Test of Hardware Independent Software Module in Absence
of a Target Platform
The said class B tests are neither new nor unusual. Software such as OSEK/VDX
NM and implementations of customer specific quasi-standards of automotive man-
ufacturers quite often are tested in conjunction with the target hardware or target
platform correspondingly. This is performed in most cases while applying a cor-
responding evaluation platform and specific test solutions. This is a reasonable
process, because the software code is developed, applied and optimized for spe-
cific micro-controllers. Class B tests therefore are not new, but very common. The
