Debugging Embedded Systems Requirements before the Design Begins

Seite: 4/5

Anbieter zum Thema

IV. Validation of the System Implementation

Until now, we’ve shown how to use STIMULUS to validate functional requirements before any design or coding takes place. We are now going to illustrate in this section how to reuse the various requirements and test scenarios in order to validate the system implementation, once it is available. The principle is to:

1. Substitute the executable requirements with the system code to be tested inside the block diagram. For that purpose, we need to define some external system in STIMULUS that will embed the compiled code of the system implementation and define the same interface (inputs/outputs) as the system of executable requirements. When simulating this new block diagram, the compiled code will be stimulated by the same test scenarios as the requirements.

Bildergalerie
Bildergalerie mit 11 Bildern

2. Check that the system implementation behaves as specified in the requirements by turning the requirements into observers, or test oracles. STIMULUS will then automatically report any requirement violation occurring during simulation. In practice, one simply need to drag&drop any system of requirements beside the block diagram and turn it into monitoring mode, represented by a light blue eye icon, as illustrated in Figure 9.

For the purpose of our demonstration, we tested a system implementation written in C. We used the block diagram to connect the C code with the previously defined scenario in which:

  • The switch is set to AUTO;
  • The light intensity is between 55 and 75%.

The STIMULUS simulator produces results similar to those of Figure 8 but this time, headLight is produced by the compiled code which replaces the executable requirements. The STIMULUS interface makes it possible to monitor requirements violations panels, in which the green color and the “true” state indicate that the requirements are constantly satisfied by the compiled code, whereas the red color and the “false” state indicates a requirement violation. The left-hand side panel of Figure 10 reports that no requirement violation has been observed during the whole simulation when using the previous test scenario.

In order to validate the system under a wide range of fast mode and luminosity changes, the constraints of the previous scenario may be relieved, so as to let STIMULUS generate less likely situations and combinations that might have been omitted. It is for instance possible to define a second scenario in which:

  • The switch may change at any time to ON, OFF or AUTO;
  • The light variation is simply restricted to + or - 10% per cycle.

After 200 cycles, the STIMULUS simulator now reports at least one violation for the REQ_003.1, signaled by the red color and the state “false” inside the right panel of Figure 10. The precise time step at which the requirement has been violated can be observed inside the simulation plot by selecting the requirement in the monitoring panel. The requirement monitoring diagram displays the problem soon after the 175th cycle, as shown in Figure 11. By zooming in for a closer look, it appears that the problem occurred:

  • Just after the light intensity reached the hysteresis zone, within 60 and 70%;
  • Just after the OFF switch turned to AUTO.

In this particular setting, the code generates the OFF value for headLight, while REQ003.1 required the value ON for headLight. This bug symptom can then be analyzed to find its cause in the C code. The test case revealing the fault may be exported into the non-regression tests database.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:44841823)