MBA-Based Runtime Behavior Verification / App. Ex. 1

MBAT Automotive Use Case 1 “Brake by Wire”: this pattern is used in its scenario 5 “TCG based on Test Model”.

Participants / Artefacts:

System Designer

Tester

Developer: needs to be aware of some common coding-testing rules so that the end code will be testable.

ViTAL tool (MDU): Model-based analysis tool; using East-ADL models whose internal components behaviors are described with Uppaal PORT TA models.

Farkle (Extended Farkle, ENEA) tool suite: Test execution platform, extended with features to parse abstract test cases and generate executable test scripts (concrete test cases) from them.

Comments: In this specific application of the pattern, we check that the order of states and transitions at runtime match what is expected according to the designed models ( – test objective). If there is any deviation, it is possible to see on the transition between which two states a violation and deviation from the expected behavior has occurred (- defect localization). Moreover, by time-stamping each visited state at runtime, we also make it possible to check if the clock constraints specified in Timed-Automata (TA) models are respected at runtime or not.

These goals are achieved by the following activities for this particular use-case:

– Requirements (in natural language) are retrieved from the requirements repository.

– Requirements are formulated in TCTL.

– The model of the brake-by-wire system (EAST-ADL model describing system components and Timed Automate models describing the behavior of each component) are analyzed in ViTAL to verify TCTL properties.

– As the result of the aforementioned analysis a trace is generated consisting of a set of states and transitions (plus input values that trigger such transitions). This is used and referred to as an abstract test case.

– An executable test script is generated from the abstract test case which verifies that by providing same inputs to the SUT, the same set of states and transitions are traversed and visited.

– By executing the test script, any possible discrepancy between the expected behavior of the system captured in the models, and the actual behavior of the system at runtime is detected.

– If there are timing constraints in the model, by including timestamps at runtime for each visited state, it also becomes possible to infer if the timing constraints on states and transitions are respected during the execution of the system or not.

The following figure shows the overall structure of the involved tools (More detailed description of the approach and the steps above can be found in the following published paper: http://bit.ly/1o07Zp2 )