Debugging Embedded Systems Requirements before the Design Begins

Seite: 2/5

Anbieter zum Thema

Since it should be avoided to describe in detail those implementation choices during the specification process, there is nothing to simulate with existing tools. Hence the lasting blocking situation that has prevailed for 20 years, in which on one hand many tools and techniques have been developed and become largely widespread for the design, coding and test phases, while on the other hand the specification phase remains limited to the reference tool: a text editor, typically MS Word.

The result of such status quo is that 40 to 60% of the errors which are detected at the testing stage result from ambiguous, incomplete, erroneous or conflicting specifications. How to get out of this dilemma and its highly costly consequences for companies engaged in the development of complex systems?

Bildergalerie
Bildergalerie mit 11 Bildern

II. STIMULUS Operating Principles

Following a number of fundamental research results in the field of formal languages and validation methods, notably carried on in the work of the VERIMAG laboratory [8] [9], Argosim released STIMULUS, a highly innovating tool which specifically addresses the challenge described above. How? By applying the two following basic principles:

1.: STIMULUS considers requirements as constraints imposed on the specified system behavior. A constraints solver [10] is therefore able to compute the space of possible behaviors at a given execution cycle. A random generator can then produce a wide range of possible executions of the specified system without needing neither a design model nor a computer code.

2.: In order to make STIMULUS easily available to requirements practitioners who are used to express requirements in natural language, the requirements are formatted in text using the “boiler plates” methodology [11]. Since each textual template is also formally defined by means of constraints, STIMULUS makes it possible to write requirements that look very similar to their original formulation, while being executable.

The edition of formalized textual requirements is a key asset of the tool. Figure 1 gives an example of a simple requirement written in STIMULUS. This requirement was edited by “dragging and dropping” several predefined templates, namely When, DuringMore and Within. The set of predefined templates is not fixed and the user may build his own domain-specific templates by composing existing ones or raw constraints, and by associating it to some natural language sentence with “gaps”.

In addition to the textual form, STIMULUS also provides modeling features like stochastic state machines and blocks diagrams. The first will allow to describe operational modes of the system, while block diagrams will support a functional or architectural decomposition, with clear interfaces presenting the signals exchanged between sub-systems. The blocks hierarchy will also ease the refinement of high level requirements into low level requirements as well as the allocation of those latter requirements to the various sub-systems.

This approach makes it possible to bring simulation at the specification level, providing unprecedented debugging capabilities to perform early and effective validation of functional real-time requirements.

III. Validation of System Requirements

In order to illustrate how, in practice, STIMULUS makes things easy for system architects to formalize and debug requirements, this section will focus on some simple function from the automotive industry, namely a car headlights control system. One of the high-level requirements for the automatic mode is to prevent the headlights from flashing. In order to formalize such a requirement in STIMULUS, we will define a new template stating that a signal does not flash if, after an instability, the signal remains stable during at least 2 seconds.

Associating a sentence format with this new operator will make it possible to use it as a template within many requirements. This new operator may be textually formatted as “_ is not flashing”, cf. Figure 2, where the gap “_” will be replaced by any signal name or expression. The high-level requirement will then be formalized by applying the new “flashing” operator to the “headLight” signal, as in Figure 3.

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)