By: Yves Génevaux, Ken Nathan, Fabien Gaucher, Bruno Jofret

In this paper, we consider the level of maturity of Systems Engineering as compared with other phases of embedded systems development. Although much progress has been made over the years with the introduction of Requirement Management tools, Traceability tools and support for organising the elaboration of an architecture with Model Based Systems Engineering (MBSE), essentially through various SysML flavours, there still remains a vast area for improvement.

It is known that 70% of the errors introduced during the various activities of an embedded system development project are actually introduced during the specification phase, whereas only 4% of the errors are discovered during this phase:

Given that the general consensus is that the earlier you find the errors, the more efficient and cost effective it is, it is clear that the processes and tools used during the specification phase need to be improved.

A blocking factor to improvement is that most of the information on the expected behaviour of the system and of its components remains in a number of requirements written in natural language. Imagine dozens or even hundreds of requirements that are to be considered in parallel and any of them can be activated at any moment. The human brain is simply not designed to handle such large parallelisms. Conflicts, missing requirements, ambiguities and semantics that do not actually reflect their designer’s intentions are numerous. Even if MBSE is applied rigorously, a very large amount critical functional information is simply out of the model, radically reducing the hope one can have for the accuracy and correctness of the model.

How can we improve the situation? What recipe, what fundamental principles should be applied in order to make the specification less error prone, effective and supported by easy-to-use tools?

We believe three key points should be taken into account by a better method:

1. The fact that SysML-based specification models ignore the behaviour of the requirements is a severe limitation. The requirements are not part of a model and therefore any attempt to propose a more effective process should ensure that any model includes the requirements.

2. The requirements can no longer be based on free text, or informal templates. This permits the introduction of too many mistakes. However, any solution should remain very close to natural language and should also allow customisation so every company can implement company specific variations according to its particular needs.

3. Simulation is a must. In the embedded system world, behaviour matters.

In order to meet these challenges Argosim is proposing an approach that is both disruptive and, in keeping with the previous practices of the industry, supported by a user-friendly tool called STIMULUS. Our proposal meets the 3 key points mentioned above:

1. The STIMULUS model allows the description of the system architecture and the interfaces between the architecture components with a hierarchy of Block Diagrams. The expected behaviour of these components can be described using textual requirements and hierarchical state-machines.

2. The textual requirements are written using a set of predefined templates, or "operators". The library of operators is customisable and extendable by the user.

3. The state-machines and the textual requirements have executable semantics; therefore, simulation is possible. You can now debug a specification in the same way you would debug a piece of code. More easily in fact.

With these principles the requirements are not only clear and executable, they are an intrinsic part of the specification model, which is what System Architects have been lacking to date. They are "In the Loop". Exactly the same as the other "In the Loop” concepts adopted by the industry in order to improve its verification processes. Starting from the end of the V-Cycle:

- HIL: Hardware In the Loop. The objective is to test the system in conditions as close as possible to the production context.

- SIL: Software In the Loop: Various execution and emulation environments help in executing and debugging the code.

- MIL: Model In the Loop: During the Design phase, the models can be activated using simulation so the future system behaviour can be verified as early as possible.

That “early as possible” point has now shifted further up the left-hand side of the V cycle.

RIL: Requirements in the Loop: During the Specification phase, the Requirements are part of an executable model, which allows the limits of the approaches described at the beginning of this paper to be overcome.

How does RIL in STIMULUS work?

Following a number of recent research results in the field of synchronous languages and verification methods, STIMULUS applies the two following basic principles:

1. STIMULUS considers requirements as constraints imposed on the specified system behaviour. A constraints solver is therefore able to compute the space of possible behaviours at a given execution cycle.

2. Use Cases are defined as a set of constraints on the inputs and between the inputs. The constraints solver defines the space of the "acceptable" inputs for a given Use Case and can generate one, ten or thousands of test vectors. This will allow an automatic exploration of the envelope of possible system behaviours. STIMULUS then produces classical simulation plots displaying the evolution of the inputs and outputs during the execution of the model.

Many benefits come from the RIL approach:

1. The requirements elicitation process is supported by a tool. Since one requirement is enough to start simulating, an iterative process can be used to define the requirements incrementally.

2. Missing and conflicting requirements are identified automatically.

3. You can verify that a specification complies with safety requirements, putting the latter in Observers whilst the specification is simulated by STIMULUS. If the specification violates the safety requirements, the Observer will report it.

4. You can verify the compliance of code with its requirements automatically. Again, using an Observer that contains the specification whilst the code (compiled in a DLL, or an FMU generated by a third-party tool) is executed by STIMULUS. You then have a completely automatic, functional validation environment.

5. Different versions of the same specification can be compared. One is executed while the other one is put into an Observer. It becomes possible to verify different hypothesis, variants of the same specification, or the impact of a change.

6. The functional coverage is directly measured by STIMULUS without having to use traceability links, which are always subject to errors. STIMULUS will indicate the requirements that have not been tested during a test campaign so you can design new use cases that will increase the functional coverage.

7. The consistency between the requirements of different levels of the system can be verified, which has been extremely difficult to do so far. You can verify if the refinement of the requirements, from the top level down to lower levels, is correct.

Conclusion: STIMULUS is a major breakthrough in System Engineering and is usable by any System Architect, any Requirement or Safety Engineer, any Test Engineer. In the embedded system industry, every project is now facing an alternative:

Explore a possible better way of working.

OR

Do nothing. Carry on as before and continue to face all the consequences of injecting multiple errors in to the specification. Developing the wrong system, the wrong test cases until one realises, at the end of the project, that the deadlines and the budget cannot be met because of the long corrections loops that were required. Fingers crossed that the error doesn’t make it in to production!

"Find the errors when you make them instead of later": this well accepted recommendation is now also applicable at specification time.

Watch the v2018 STIMULUS video here: https://www.youtube.com/watch?v=aiu5pQRgm7o

More STIMULUS videos are here: https://argosim.com/product-videos/