Systems Engineering ​​​​​​​STIMULUS ​​​​​​​

Last Friday, we explained how you can develop and validate functional requirements using simulation. How can you develop easily many test cases to stimulate the requirements and achieve the desired level of confidence?

2. Functional test cases generation:

A strong system validation requires to automate the creation of numerous test cases to validate the system once developed. A test case is composed of two parts: a sequence of inputs that stimulates the system, and the test oracle, the expected result.

If created randomly, then many inputs are produced that make no sense at all. A better solution would be to define a set of constraints on the inputs and between these inputs, and inside this set of constraints, generate numerous test vectors randomly. If a class of test vectors is defined and as many test vectors as required are generated automatically, then there is no need to develop individual test vectors. Such a set of constraints could look like this:

Concerning the test oracle, rewriting the requirements in the form of the expected result for each generated test vector, it is still too much work. The best solution is to use the requirements themselves; it is actually the ideal test oracle.

You could even say that the only reason for defining the expected results under the form of a given value, for a given output, at a given cycle, one by one, for every combination of inputs, is simply the fact that free text requirements are not usable as such for that purpose. What is wrong in “free text requirements”, is not “requirements”, it is the “free text” part.

Therefore, we have addressed the two challenges here:

• The test objectives, the requirements, can be first validated so as to make sure they are correct.
• We have means to generate a huge number of text vectors to stimulate the specification or the actual system. That’s the input part of the “test vectors”.
• The output part of the test vectors, the test objectives, can simply be the requirements themselves.
• As the functional specification is a set of rules defining the relationships between inputs and outputs. A very powerful test solution consists of stimulating the system with numerous generated test vectors and making the specification observe the inputs and outputs. The Observer warns of the violation of any requirement.

The solution can even be enhanced by the use of several Observers, one embedding the specification, another a set of safety requirements. The second Observer will aid the realization of the functional safety objectives:

To summarise, nowadays validation of critical embedded systems needs a new type of tool that:

1. simulates the requirements so as to have trustable test objectives,
2. generates numerous test vectors in a controlled manner, for each identified use case,
3. stimulates the compiled code or an FMU generated by Simulink or SCADE for instance,
4. embeds the requirements in Observers

All this provides a complete and unprecedented automation of the functional tests.

STIMULUS from Dassault Systèmes fulfils all these challenges and proves very effective on many critical systems in the automotive domain.

One STIMULUS application example out of many:

• A Tier-1 automotive supplier had specified an “emergency steering wheel” function supposed to take control of the steering wheel in order to avoid an obstacle in front of the car. The function is obviously very safety critical and was composed of twenty requirements;
• Twelve conflicts were automatically detected by STIMULUS, and had gone unnoticed so far;
• The other eight requirements also included some errors.

Capturing the specification in STIMULUS, simulating it to detect errors and fixing them only took two days of work, thus saving tedious and costly iterations during the project.

NB: This example concerns one function only but STIMULUS applies also on large and complex distributed systems.

Try STIMULUS.

@TC ​​​​​​​

Last episodes: