Page 104 - 360.revista de Alta Velocidad - Nº 5

Meyer zu Hörste, Michael. Asbach, Lennart. Hardi, Hungar. Lemmer, Karsten.

The test rack adds two components to the test object:

• Adapter internal-external: The manufacturer shall provide a module which translates
between internal and masked interfaces. For its realization, interface drivers, simulators, or
existing test interfaces accessing internals of the device may be used. Even a test engineer
performing manual steps may be integrated via a suitable interface component.
• Adapter RaSTA-RTP: This module must be provided by the test laboratory.

The test rack serves to provide the test object with an interface which is on the same level of
abstraction as the specification. The remaining components of the test architecture are rather
standard:

• Test Execution Kernel: The kernel controls the test execution, i.e., it initializes the test
objects, starts test sequences (including parameter completion in advanced scenarios),
protocols the results, performs corrective actions (breaks and restarts if necessary) and
generally monitors the execution. The kernel will be partially automatized.

• Test Sequences: A data base with test sequences sharing the characteristics with those of
the on-board tests.

• Test Report: A data base for detailed result data and accumulated reports.

5. Validation

To be able to make qualified assertions of standard conformance, several arguments have to
spelled out. On the one hand, the correctness and completeness, resp. sufficient coverage, of
the test cases with respect to with respect to the specification has to be checked. This involves
techniques and methods form the domain of model based testing. Currently, manually derived
test suites are evaluated for their suitability. In future enhancements of the overall approach,
also test case generation from the specification models is intended to be considered.

Adapter design and validation will have to cope with the common problems of crossing abstraction
levels (namely atomicity and timing issues as well as value concretizations). For the internal-
external adapter a monitoring concept which observes its operation dynamically is envisioned.
The user interface of interlocking systems provides many information about internal states and
thus qualifies as an adequate point of observation.

6. The Role of Formal Methods

Formal methods are used increasingly in the testing process of rail equipment, albeit slowly.
They make their entry in one of two ways.
The first is via a formalisation of specification. This has a benefit in itself, as ambiguities,
omissions and inconsistencies are reduced when a specification is formulated in a more or
less rigorous notation. Examples from practice are the specifications of track-side equipment
mentioned in the previous section. While currently limited to single interfaces, it is intended to
specify the functional behaviour of, e.g., interlocking systems completely. Another example is
the development of formalising the ERTMS/ETCS SUBSET 026 in the project openETCS.

Besides the effect of improving the quality, a formalised specification is of course a necessary
basis for many further process enhancements. With respect to testing, formalised requirements
permit at the very least a systematic derivation and coverage analysis of test cases, and in
favourable scenarios even the automation of test case generation. For the latter, commercial
tools are already available (rttester, rhapsodyATG, etc.), though these tools are not yet widely
used in the rail domain.

102 360.revista de alta velocidad