Debugging Embedded Systems Requirements before the Design Begins
Anbieter zum Thema
The resulting requirement is both readable and non ambiguous, since it can be executed with a perfectly defined semantics. It is possible to refine this high-level requirement REQ_003 by specifying more precisely the lighting controller behavior with low-level requirements describing some hysteresis behavior:
- REQ_003.1: if the switch is turned to AUTO, and the light intensity is at or below 70% then the headlights should stay or turn immediately ON. Afterwards the headlights should continue to stay ON in AUTO as long as the light intensity is not above 70%
- REQ_003.2: if the switch is turned to AUTO, and the light intensity is above 70% then the headlights should stay or turn immediately to OFF. Afterwards the headlights should continue to stay OFF in AUTO as long as the light intensity is not below 60%
- REQ_003.3: if the switch is in position AUTO, the headlights are OFF, and the light intensity falls below 60%, then the headlights should turn ON if this condition lasts for 2s
- REQ_003.4: if the switch is in position AUTO, the headlights are ON, and the light intensity is above 70%, then the headlights should turn OFF if this condition lasts for 3s
Upon careful reading of these requirements, one may take it for granted that the hysteresis behavior has been correctly specified and will prevent any flashing of the lights. We are going to demonstrate that this may not be the case. These four requirements can be specified with predefined templates from the STIMULUS standard library, which will offer a textual formulation close to the natural language. For instance, Figure 4 gives the STIMULUS formulation for the REQ_003.1 requirement.
But since STIMULUS allows to generate different possible executions of the specified system, how does the lighting controller behave within such formulation? Are the low-level requirements describing some hysteresis behavior that is compatible with the high-level requirement stating that the lights should not flash? Before simulating requirements, we can specify basic hypotheses for the light intensity behavior as well as the automatic mode command.
In other words, we can describe a test scenario for the requirement. If no starting scenario is provided, STIMULUS will generate random data by default for the system’s input signals. As recommended in safety standards, we propose to describe a test scenario in STIMULUS that will for instance induce light luminosity fluctuations between 55% and 75%, corresponding to the interesting fluctuation range in automatic mode.
The test scenarios are connected to the low-level requirements (block REQ_All) through the block diagram of Figure 5, which in turn relates to the high-level requirement specified in parallel. STIMULUS will simulate the whole of it and try to induce behaviors satisfying both low-level and high-level requirements as well as the test scenarios. The test scenarios are also specified in the form of textual constraints, allowing to generate an equivalence class of test vectors.
For instance, the Loop75To55 scenario induces a light intensity fluctuation between 75 and 55%, with a dedicated “goes up and down” operator whose definition only determines the light intensity limits and the alternated up and down phases, but not the light intensity variation amplitude, cf. Figure 6. As for the ForceAuto scenario, it simply forces the automatic mode by assigning the switch value to AUTO. The simulation of all the requirements, including the block diagram with low-level requirements and test scenarios, as well as the high-level requirement, will produce the plot of Figure 7.
After 10 cycles, STIMULUS automatically detects a requirement conflict and highlights the various requirements responsible for the conflict. In this particular case, there is a violation of the high-level requirement (the headlights should not flash) by a low-level requirement. Each time STIMULUS reports a conflict, it also identifies automatically the minimal set of conflicting requirements.
Then, the simulator’s debugging features (error messages, highlight of active and inactive requirements, access to the various signal values at any time of the execution, etc) allows users to thoroughly analyze the conflict, identify its cause in order to modify the faulty requirements or add some missing ones. Once the faults are corrected (in this particular case, the use of the AsLongAs operator within the REQ_003.1 and REQ003.2 requirements should be replaced by a When operator), one gets the expected behavior, and the absence of conflict indicates that the low-level requirements now satisfy the high-level requirement, see Figure 8. Here, STIMULUS made it very quickly possible to:
- Formalize the requirements and generate behaviors for the specified system;
- Detect a conflict between requirements (in this case between the high- and low-level requirements);
- Correct faulty requirements and validate them through some iterative simulation process.