Debugging Embedded Systems Requirements before the Design Begins

Over the last two decades, there has been a real movement towards requirements engineering [1]. However, the various tools that have been developed with the aim of improving the specifications development are mostly focused on requirements management and traceability (Doors, Reqtify, etc), and there is no practical upstream requirements validation tool available for checking their functional coherence before the design stage.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

As a result, over half of the faults detected during the testing phases result from specification mistakes [2]. This is particularly prejudicial in the case of critical embedded systems where specifications play a central role in the certification process. Argosim ambition is to change this situation by providing STIMULUS [3], the very first requirements simulation tool for real-time embedded systems.

STIMULUS combines the ability to formalize requirements into a text-based language which is both simple and expandable, but also and even more importantly, to simulate them by generating the possible behaviors of the specified system in the form of execution plots. The analysis of simulation results allows for the quick detection of incorrect, incomplete or even conflicting requirements. In practice, STIMULUS integrates seamlessly into the agile development processes [4], by allowing for the concurrent development of both the requirements and their test scenarios in a very incremental way.

Bildergalerie

Bildergalerie mit 11 Bildern

Test scenarios thus developed will make it possible to generate many test vectors that will be usable at the design validation stage, while the requirements will be reused as such in order to specify and verify test objectives. This paper describes the major innovation offered by the STIMULUS tool in the field of requirements engineering. It will present its operating principles which will be illustrated with a specification item relating to the automobile domain, starting with the definition and the development of the requirements through their simulation up to the embedded code validation tests against those requirements.

Keywords

Requirements Engineering, Textual Specifications, Simulation, Constraint Solving, Debugging, Validation, Automatic Testing, Real-time Embedded Systems.

I. The Requirements Engineering Challenge

Validating the specifications for embedded systems is a twofold challenge, especially in the case of critical applications. On one hand because any specification error results in design errors, whose correction will require costly iterations of the development process. On the other hand, because those systems are subject to safety standards that impose high quality criteria on the requirements [5]. Today, the functional validation of requirements relies on the three following approaches:

• The manual review of the specifications documents, which does not allow for the detection of any likely ambiguities nor subtle inconsistencies among the various specifications at stake.

• The use of syntactic or even semantic analysis tools [6], that help to create the requirements in a more formatted and structured format; again, despite such approaches allow to detect some mistakes, they do not provide any support to the system’s functional validation.

• The running of code validation tests once the system is implemented, which makes it possible to challenge the specifications, thus very late in the development cycle.

We can also mention formal verification tools [7] but they are intended for use exclusively by verification experts, not by system architects, and in practice, their scope of industrial application is restricted by both decidability and complexity issues. So why being still here in 2015, whereas the “model-based system engineering” approach appears everywhere and the use of simulation processes in systems design activities has stood out as an evidence over the last 20 years?

The reason for that is that contrary to the system designer, the system architect is expected to focus on the “what”, namely on what the system is supposed to do and not on the “how”, that is how to precisely execute the specified function [3]. In order not to interfere with the design process, the specification activity must avoid as much as possible to describe the implementation choices, in order words it must reduce the options available to those in charge of the implementation.

And that is where the simulation problem comes in: generally speaking, the term simulation refers to the execution of an algorithm, detailing step by step every data computation. The execution is therefore deterministic since, in other words, it has to do with implementing “how” the system will perform.

(ID:44841823)