Even though AI is being used to replace procedural coding for many embedded applications, there is still, and will be for a long time, code that is written manually to deal with complicated inputs to control connected systems. Even in AI based systems there are programmer coded steps for responses to AI identified inputs. All of this code will start with specifications that are most often written in natural language form. Based on these written requirements testers will create test cases and developers will write code. According to Yves Génevaux, Sales Director for the STIMULUS product at Dassault Systèmes, there is a better way to develop embedded systems that start with executable specifications.
I spoke with Yves recently and he described the process they have used to help a large number of prominent corporations improve quality and reduce development and testing times. STIMULUS allows the creation of specifications in a way that resembles natural language but uses templates to create executable specifications. For instance, instead of writing “when the switch mode is OFF, headlights shall be ON”, the user creates a formalized requirement that reads “When switch is ‘ON, headlight shall be ‘OFF”. It is possible to nest executable templates and create Booleans as well. Inputs and outputs may also be defined as analog values.
Yves pointed out that many functional failures can be found to originate in faulty specifications, which is the last place developers tend to look during debug. Yves showed me how, with an executable specification, inconsistencies and errors can be found quickly in STIMULUS. This can change weeks of debug into an avoidable problem altogether. He cited one example where a major subway system supplier had spent weeks doing fruitless debug before they decided to employ STIMULUS. It took one day to rewrite the specification in STIMULUS, one day to find the conflicting requirements, and one week to rewrite the code and determine that is was compliant with its specification. This saved Millions of dollars in penalties for late contract delivery.
The benefits of an executable specification extend to developing test suites. The traditional method is for the test team to pick a set of requirements and write tests for them. More mistakes can be made here, and completeness is always difficult to obtain. It is always a struggle to get and quantify the level of test coverage for specifications. STIMULUS allows testers to automatically generate as many test cases as they like. These are run automatically, with the results available in a graphical interface. When there is hardware in the loop, STIMULUS performs automatic analysis of test log files to determine proper functionality.
Another example that Yves offered involved a tier one automobile supplier developing an emergency steering wheel function to take control in order to avoid an obstacle. The function was specified with 20 requirements. After using STIMULUS 12 conflicts were detected in the specification that had escaped notice previously. In addition, at least 8 more functional errors were discovered rapidly among the 20 requirements.
Yves was quick to point out that system complexity is not a major issue for STIMULUS. In larger systems each subsystem can be validated separately, then a set of subsystems can be validated as a whole and its behaviour compared to the upper level specification. This approach allows validating the specifications of very complex systems without any scalability issue.
STIMULUS represents a major shift in methodology that comes with big benefits. To help understand this Yves has created a library of videos that can be accessed on his LinkedIn profile. The clips that I reviewed showed the operation of STIMULUS and the tool set up. These videos can be found here on LinkedIn.Share this post via: