Civil Engineering Reference
In-Depth Information
6.4.3.8
Test of Time Behaviour, Performance, Throughput
CAN software modules are expected to provide sufficient throughput to handle all
message traffic even at high bus loads. All this is expected from any of the soft-
ware layers of the CAN software stack; otherwise buffer overruns, loss of data
must be encountered and finally predictability and application functionality would
fade away. Besides this worst-case scenario and because of competition reasons,
it makes sense to specify, require and measure throughput as well as performance.
A comparably excessively slow implementation will not prevail in the market, as
well as a faulty or resources-wasting one—all this is for the benefit of the appli-
cants. Therefore, it is highly recommended to specify appropriate benchmarks for
standardized software modules which evaluate and compare the performance of
implementations. Such kinds of tests focus directly on the timing behaviour of soft-
ware modules and their target systems. Therefore, corresponding methods for test
execution in real time, timing control and synchronization of test-system entities
are required. Up to now these kinds of tests have not been discussed so much and
they are not widely applied. Insofar the customers—mostly automotive manufactur-
ers—must rely on corresponding statements of their suppliers. However, nota bene,
standardization is an important prerequisite for comparability. It is recommended
to do performance-comparing tests when interfaces and functionality are the same.
6.4.4
Test-System Architecture for Embedded Software Tests
Assuming a modular design, software can be tested module by module. As such,
software is comparable to layers of the ISO/OSI-layered model. The basic prin-
ciples of ISO 9646 standard are applicable as well. All accessible interfaces of the
software module are surrounded by the tester, whereas the logical assignment of LT
and UT to higher or lower software layers can be done either way, depending from
the orientation of the interfaces.
Interfaces of neighbour modules of the same layer are served as well by the tes-
ter. In order to avoid conflicts coming from the assignment of either UT or LT—this
problem cannot be resolved sufficiently clearly due to the ambiguous orientation to
either the higher or lower logical layer—temporarily the term “lateral tester” can
help out, which addresses those interfaces.
6.4.4.1
The Residual System, Tests in Conjunction with the Application
Quite often, a software module cannot be fully separated from its surrounding sys-
tem, for instance, if it requires a specific operating system or if it is highly interwo-
ven with the application. These parts of the surrounding system must remain on the
target platform and can be called “residual system” (RS). As the RS has an impact
on the test, the specific characteristics of the RS must be taken into account when
