Civil Engineering Reference
In-Depth Information
hardware or software layers of the communication system. Therefore, testing of all
involved components is a condition sine qua non. Especially, non-widely applied
and non-standardized software may lead to problems because independent tests do
not exist which may have discovered any misinterpretation of the original standard
or the specification correspondingly. Quite often, the problems are due to the design
and not (only) due to the implementation. If a supplier performs tests of his imple-
mentation against his design on its own, the supplier is not being able to discover
such kinds of problems, because he or she performs tests on the implementation but
not on the design specification. Standardized solutions are less vulnerable, as more
commonly conformance tests are applied for quality assurance.
Synchronization between UT and LT is required when timing measurements are
to be performed. Furthermore, more precise and complex test scenarios can be per-
formed, if a common time base at all interfaces of the test object is available. With-
out that common time base certain features even cannot be tested. Tests executed on
the target hardware give a clear example for that situation, because actions onto the
software interface of the test object are required to be correlated with test messages
on the bus.
Particularly the software of the driver layers always must be tested in conjunc-
tion with the corresponding target hardware. There are evident reasons for that. The
interface between driver and target hardware is not standardized and as such would
require complex efforts for interfacing the IUT to any one of the test systems. How-
ever, the interfaces of the drivers to the higher software layers (the offered services)
as well as the bus itself represent the nearest standardized and adjacent accessible
interfaces which are independent from any corresponding target hardware.
For synchronized test scenarios, it quite often turns out to be a good solution to
install the common time base for UT and LT within the LT itself. The LT provides
the well-known and constant performance as compared to the host microprocessor
of the target platform on which the UT is executed. For highly accurate measure-
ment tasks, the UT can be stimulated by distinct trigger signal to execute actions
at predefined points of time. However, as mentioned above, this requires the pre-
defined specification of the desired actions at the occurrence of the next trigger
event which causes problems for the interpretation of the TC description at runtime.
Fully deterministic, sequentially and timely predictable test scenarios can only be
achieved by a test runtime phase in real time as well as corresponding preparation
and post-processing phases. In the preparation phase, the corresponding measure-
ment devices are initialized and the desired message and control data files are set
up, which are executed interrupt-free at test runtime and thus at distinct speed.
Adaptation efforts of a test system to all test candidates of a kind are the same if
those test candidates provide unique and standardized interfaces. As such, tests not
only require comparably low set-up efforts, but also require top benchmarks, e.g.
data throughput over time and reaction times can be explicitly measured. Thereby,
implementations of various suppliers can be compared.
