Simulink is a true life saver in large companies manufacturing safety-critical products, or where the software development is usually split into three different phases:
Specification phase: The algorithm is planned or updated by the specification team and a new specification is released
Development phase: The algorithm is implemented by the development team and a software release is made
Testing phase: The software undergoes an extensive testing phase both on simulated and on real hardware; only when the test results are positive, the testing team states that the software is ready for production
In every software project where safety is an issue, the software development starts only when a stable specification has been released.
Specifications are usually written as text documents where each sentence describes an atomic requirement and must be highly detailed.
The problem with specifications as text documents is that there isn't any way of verifying the correctness of the specified logic until the development phase or even the testing phase.
Every time that the specification is found to be incorrect or incomplete, the specification team must be notified and must make a new release. So the development team has to develop the new release, likewise the testing team will have to test the new software.
A specification error is one of the worst things that can happen in a big manufacturing company, often leading to production delays, while underspecified software can lead to unwanted behavior.
Simulink can be used to achieve the goal of writing correct and complete specifications, without losing anything in readability. Let's consider the following atomic requirement:
REQUIREMENT # 101:
If InputSignal is greater than 0, the InputSignalFlag variable must be set.
The corresponding Simulink block would be as follows:
What's the real deal? It is that you can test the requirement before it's released. With Simulink, it's easy to generate input signals and register the output as shown in the following diagram:
When viewing the display on Scope, the result will look like the following diagram:
But wait! Let's examine the textual requirement; it says that the flag must be set. It's unclear (not specified) whether the InputSignalFlag variable should be reset when InputSignal becomes 0 or less than 0.
But the difference is very clear in a specification done with Simulink. The following is the block diagram that describes the requirement with the InputSignalFlag variable remaining set until the end of the execution cycle:
We can see that the simulation result is very different from the previous one, as seen in the following diagram:
With textual requirements, there's always a gray area due to the fact that human languages, despite their richness (or because of it), have problems in describing a Boolean logic. And it's extremely difficult, if not impossible, to test the requirement before the release.
With Simulink models as requirements, there is no room for doubt. The requirement is complete and easily understandable by nonprogrammers, and a preliminary test can be made with little to zero effort by the very same team that wrote it.
The development team has the responsibility of maintaining and updating the software for a certain project or series of projects. The usual work flow for the embedded C developer of an automotive industry is shown in the following diagram:
The first problem developers are faced with is the code itself. A well-commented code with strict coding-style guidelines will be easily understandable and maintainable, but sadly, that's not the common situation. Code maintainability is a major issue almost everywhere, strictly dependent on code readability.
The second problem is the formal code-correctness checking. This means doing a static code analysis to check compliance with one or more sets of formal rules (for example, the MISRA-C rule set).
The third and the most important problem is code debugging. This is done by running the code to do an early testing (for example, with valgrind) and applying well-known input patterns to detect and correct the blocking bugs.
Simulink helps the pressed developer solve these problems in the following ways:.
Code readability: Being a graphical development tool, developers have an intuitive way of dividing the code into multilayered virtual blocks. The topmost layers give a representation of the functionality subsets implemented, while the lower layers contain the code primitives (logical and mathematical operators, memories, state machines, and so on).
Static code analysis: By using Simulink with code generation software (Simulink coder—formerly Real-Time Workshop—and DSpace TargetLink are the most popular), it is possible to produce error-free embedded C code. They guarantee that the produced code offers the same functionality described in the model.
Code debugging: During model development, Simulink offers the option to do an early testing; the developer can apply an input pattern to a well-known problematic algorithm and visualize the simulation result, inspect every signal, do a step-by-step debug, and stop the simulation on selected events on the same model used for code generation.
By using Simulink, the development team can apply the required updates in a shorter time and use the remaining time to perform a quick preliminary testing of the code.
Static code analysis becomes almost irrelevant since coding rules and conventions are enforced by the code generation software.
Finally, with the autogenerated code being free of syntax errors, the compilation phase is usually straightforward. This greatly helps the programmer who is not familiar with the C syntax.
The released code needs an extensive testing phase before being put into production. The testing team's objective is to confirm that the software is compliant with the specifications.
This usually involves breaking the specifications into atomic requirements and having one or more test cases for each requirement (the so-called functional testing), or defining what should never happen and automatically apply every possible combination of inputs to the software component (a subset of destructive testing).
By using Simulink models, the testing team can easily perform automatic model-in-the-loop (MIL) testing on their computers; the logical correctness is demonstrated by applying inputs to the Simulink models and comparing the outputs to the expected behavior. MIL testing easily spots failures in a very short time and generates a detailed test report, even pinpointing the model block where the problem resides. MATLAB already has everything needed to perform an MIL test, while automated tests can be coded using the MATLAB scripting language.
Once the MIL testing is successful, the software-in-the-loop (SIL) testing is performed by running the autogenerated code on standard computers. It is usually aimed at finding discrepancies between the model and the code behaviors, and it requires another software monitoring the process's I/O or the inclusion of debug headers into the tested code, or a mixture of both.
The next testing step is the processor-in-the-loop(PIL) testing, where the software is programmed into the target processor and debugged via an external high-speed bus connected to a standard computer, such as a JTAG connection. Of course this requires having the target processor available on a board with a testing connection.
The last step is to perform hardware-in-the-loop (HIL) testing, which is running the software on the target hardware connected to a real-time system. It requires a custom test bench to be purchased or made internally, and some test steps have to be executed manually.
The biggest advantage of MIL testing is to reduce the number of times SIL, PIL, and HIL tests are performed. This is because most of the problems are caught during the fast, nonexpensive MIL tests, thereby reducing the overall time spent to generate, build, and validate the produced code.