Civil Engineering Reference
In-Depth Information
feasible because of their hardware independency and corresponding programming
on PCs. This is quite a new approach. However, this makes it even more difficult
for software-module suppliers to generate highly optimized code, which contradicts
the idea of a generalized applicability. Nevertheless, this method allows the test
of embedded software while not requiring any specific target hardware. In order
to execute the embedded code on a PC the object code must be generated for PC
execution. The resulting object code and its timing behaviour obviously are not
comparable with a code dedicated for an embedded system application.
6.4.3.3
Support of a Script Language for Test Implementation
All up to now widely spread solutions, which are based on a partial standard or a
quasi-standard of some automotive manufacturers, typically provide a textual docu-
ment form for test specification which finally must be transferred into an executable
code. Typically, this is achieved by a non-standardized script language, which is
adapted to the specific test object and which is human readable. Any one of these
script languages finally provide well-defined services, which can be combined in
different ways, configured and parameterized in order to specify a specific TC.
Calling these services implements the access to the functions of the test system such
as to the measurement tools, signal generators, log files and the evaluation.
6.4.3.4
Support of TTCN-3 Test Descriptions
AUTOSAR defines TTCN-3 as the notation form for any of its standardized test
specifications for conformance tests of all specified AUTOSAR software modules.
This also includes all of those software modules, which are applied in an AUTO-
SAR CAN software stack. Applying a compiler or interpreter on the TCs of this
test description language makes them executable. As such, this human-readable test
code is a test specification and, at the same time, an implementation of it. Any
one of the newly implemented AUTOSAR software modules must be checked for
conformance by well-defined, module-specific conformance tests in the future. For
that reason, a test system is required which executes the TTCN-3 conformance test
specification (abbrev. “CT-Spec”). This is to be applied for the so-called class B
tests in conjunction with the target hardware as well as for the PC based class A
tests. It is favourable to have the same, identical solution for both of these classes
in order to avoid specific and costly special solutions for one class only or only for
just some few software modules.
6.4.3.5
Adaptation of Test Candidates, Connection Between Test Object and
Test System
Neither tests written in TTCN-3 nor tests written in a script language can be ap-
plied without any further efforts to test a specific test candidate. Any test candidate
