6. Use Case: Model-Based Design#
The usefulness of mathematical models has been long-recognized in domains such as aerospace, civil, and electrical engineering. Model-based software development attempts to apply this concept to the software engineering domain. While ISO 26262 does not require the use of model-based development, the value and importance of the model-based engineering paradigm is emphasized in Annex B of ISO 26262-6.
Fig. 6.1 Model-based development using Simulink/Stateflow and C.#
Figure 6.1 shows an idealized view of a model-based development process using Simulink/Stateflow and C, which consists of three phases.
In the first phase, requirements are gathered. Many of these requirements will be logical in nature, such as mutually exclusive conditions, limits on values which are sent to an output device, or actions which must be performed in a specific order.
In the second phase, an executable model is developed based on the requirements. This model is tested as much as possible to ensure that it satisfies all the requirements before proceeding to the next phase.
In the third phase, C code is produced from the model. This code may consist of components which were written by hand or automatically generated. The behavior of this code must be tested to ensure that its behavior matches the behavior of the model.
Fig. 6.2 Overview of a model-based build and test process.#
Figure 6.2 shows a fairly simple model-based build and test process which could be automated as a Jenkins pipeline. The process consists of 4 steps, each of which is represented by a labeled box in Figure 6.2. These 4 steps are explained as follows:
Test Model. Reactis tests the model of the system under development. Any runtime errors dectected will be logged in the HTML test execution report. The inputs and outputs produced by the model for all tests are saved in a test suite, which is used in the back-to-back test (step 3).
Generate Code. If the model passed testing, C Code is generated from the model by hand or using a code generator, such as Embedded Coder[1] or TargetLink[2].
Back-to-Back Test. Reactis for C takes the test suite generated by Reactis in step 1 and executes it with the C code generated in step 2. Significant differences between the C code output and model output are flagged as errors.
Compile Code. If the back-to-back test passed, the C code is compiled into its final form (e.g., a binary library or executable).
Reactis plays a vital role in this process, by detecting design/modeling errors (in step 1) and performing back-to-back testing to ensure that the C code behavior matches the model behavior (in step 3). A particular strength of Reactis is that the test suites are easily interchangeable between Reactis and Reactis for C, making it easy to execute a test suite generated from the model on the C code and vice-versa. Throughout the testing process, Reactis will detect and flag any runtime errors which occur, including memory errors such as reading past the end of an array or accessing heap-allocated data which has been recycled. Additionally, the Validator component of Reactis can be used to create requirements (in the form of assertions and user-defined targets) which will be tested on both the model and C code.