Explore model-based testing for production hardware

Time Partition Testing (TPT) is a model-based testing technique, which is based on hybrid, hierarchical, parallel running automatons with continuous behaviour. These use a real-time semantics, support continuous signal processes and―with the help of so-called variation points―enable modelling of a number of test cases in a common automaton. Hence, with TPT all test cases for a test object are managed in a common test model.

As a result of this approach, the overview still remains manageable and maintenance-friendly even for complex tests with hundreds of test cases, whereby the tests themselves are formally precise and automatically executable. A consistent solution—from the requirements specification, through test modelling and automated test execution to test evaluation and documentation—is possible by means of coupling with the requirements management tool DOORS (Dynamic Object-Oriented Requirements System) and an integrated automated test evaluation.

The advantage of TPT lies in the clear graphic modelling of signal-oriented behaviour for automated executable and evaluable tests. Differences between the individual test cases are modelled by behaviour variants on the states and transitions. Therefore, each state and each transition in the automaton cannot only define one, but potentially any number of alternative signal definitions or transition conditions, which in turn can stimulate different specific test procedures.

States and transitions, for which more than one variant was defined, are called variation points. With TPT, the specific test cases are defined by selecting and combining variants for all variation points. Different combinations define different test cases. Figure 1 shows a section of the main window of the TPT software with an example automaton.

With TPT, modelling of the test cases takes place irrespective of the platform during test execution. Therefore, the same tests can be reused in all phases of the development from early Model in the Loop (MiL), through Software in the Loop (SiL) and Processor in the Loop (PiL) to subsequent Hardware in the Loop (HiL) without having to make any alterations. TPT can be deployed for control of the target and for setting/reading values for HiL-tests with various run-time environments, for example, LABCAR from ETAS or dSPACE systems. Another advantage of the platform-independent test cases is that the results can directly be compared.

With support of the Universal Debug Engine (UDE) from PLS, users can now execute tests that were modelled and managed by means of TPT, even in real-time on the actual target hardware, for example, an embedded control device.

The basis for this is the software interface provided by the UDE. It is based on the Component Object Model (COM) from Microsoft and offers almost all functions of the debugger such as FLASH programming, run control, reading and writing of target memory in symbolic and numerical form, trace data acquisition and analysis, and much more (figure 2).

Via the software interface, the debugger is controllable within the user interface by macros or externally by scripts. All scripting languages that can handle COM components—such as JavaScript, Perl, Python, VB Script or also PowerShell—can be used. Hence, programming of automatable processes therefore does not take place in a proprietary syntax, but in the language chosen by or familiar to the developer and, namely, by making full use of the objects, properties and methods provided by the UDE software application programming interface (API).