The following pages describe an example of how model based development for function development may look, from specification to verified final product. Working in a model based manner offers the possibilities of short iterations, early verification and a high degree of reusability throughout the process.
Development begins with simulation on a computer and moves on towards verification of the algorithms on a prototype system connected to the system to be controlled. When this, after a number of iterations, results in a well-functioning system, the code is adapted for the target system. In order to be able to verify that the demands are met through controlled and repeatable tests, the target system is subsequently connected to a simulator which simulates the system to be controlled.
A first step is to create a model of the functionality to be implemented.
In order to assess whether the function has a desired behaviour it is beneficial to perform a simulation of the model. This requires stimuli for the model. For example, if it is a logic function it could very well be enough to connect a number of signal generators to the model; however, if it is e.g a controller there must be a feedback system. In this case, a model of the system to be controlled is required: a so-called environment model.
The environment model should be detailed enough to recreate the behaviour, and the level of detail differs greatly depending on what is being implemented.
An environment model allows the creation of a feedback system which can simulate the behaviour of both the developed function and the environment and can thereby already verify that the model fulfils the desired functionality even during the design phase.
|Automotive Simulation Models (ASM)|
|VEOS, PC based simulation platform|
3. Implementation on a real-time system
Having verified the functionality in a simulation environment, it is suitable to verify that the developed algorithm works in practice, with the available sensors and actuators.
The test is preferably performed on a high-end system where limitations in computational capacity do not limit the behaviour, and where there is space to run non-optimised code allowing for inspection of each individual signal in the model in order to analyse the behaviour.
Before building new production hardware it is also advantageous to first verify the need for an electrical interface, thereby eliminating the need for creating several versions.
Generally, not everything works as intended on the first attempt; however, with a good toolchain for quickly modifying the model, compiling it and downloading it onto the real-time platform, it is possible to swiftly move towards a working system exhibiting the intended behaviour.
|Real-Time Interface (RTI)|
4. Evaluation and calibration
Running the application on a real-time system with a physical connection to the controlled system, the next step is optimising its performance. In order to do this, it is necessary to control parameters, but also to have the possibility to view and log signals.
A good evaluation and calibration tool connected to the real-time system provides for quickly creating an intuitive layout which visualises the signals. It is then possible to e.g compare step responses in order to tune a controller, or simpler things such as simulating an input from a user interface and making sure everything is interpreted correctly.
5. Code generation for a target system
When the model, after a number of iterations, recreates the desired behaviour, it is time to implement it on the target system.
The target system has, generally for cost-related reasons, a number of limitations on computational capacity and thus, the code created for it must be optimised. If, e.g, only integer arithmetic is supported, input and output signals must be scaled a certain factor and these scalings must be inherited and adjusted through calculations.
Model based development allows a production code generator to create the C code based on specifications in the model. The code generator keeps track of e.g how different scalings shall be interpreted and the only requirement is to verify the behaviour. The production code generator also optimises the code so that nothing is ever calculated if it is not used.
In order to analyse whether the optimised production code created by the model truly corresponds to the intended behaviour, it is desirable to simulate the code (Software-In-the-Loop) and compare it with the simulated model (Model-In-the-Loop). The code generator does not itself introduce any errors, but since the user has the possibility of influencing the code, using e.g fixed-point implementations requires verification that the scaling does not lead to quantifying effects.
By having the model as a basis for the code, it is simple to switch from fixed-point to floating-point implementations or from standard C code to AUTOSAR.
6. Integration into software projects
Usually not the entire code base is implemented in a model based manner; drivers and other low level calls are implemented in a classic coding environment. It is then simple to export the generated C files in order to integrate them into the rest of the project.
Within larger projects the code is to be integrated into a software architecture, e.g AUTOSAR. By running integration simulations against virtual hardware it is possible to identify any problems and verify the behaviour at an early stage. Read more on this interaction in the software architecture process example.
|VEOS, PC based simulation platform|
7. Verification in a HIL environment
Once the final control unit is done, it must be verified. This can be done in the specific machine where it is to be installed, but there are many advantages to performing the tests in a laboratory environment where the other parts of the machine are simulated. Here, the environment model created during the model development is reused. This enables the possibility of creating automated tests which are possible to recreate over different software and hardware versions. It is possible to test both functionality and electrical interface but also diagnostics.
The connection of the finalised control unit to a simulator is called Hardware-In-the-Loop (HIL) and there is more to read about this in the process example of verification.