Limitations of traditional software development methods
Software becomes huge and changes in development method
Automotive software becomes huge day by day, traditional software development cannot support it. For example, engine control, fine control which support fuel economy improvement and exhaust gas regulations require higher performance and higher efficiency year by year. To realize it, code size is increasing accelerated. Attention is focused on Model-Based Development instead of traditional software development because it is necessary to reduce development manpower and increase reuse and development accuracy.
Model-Based Development
Model-Based Development mathematically models the development target and repeats simulating the model, it is a method to make a control and system. It is spreading rapidly in automotive development software.
In Model-Based Development, it is possible to immediately verify the designed model, it is possible to prevent development backtracking which was an issue.
In Model-Based Development, simulate the model which is modeled the control and plant. Simulating the model is called Model in the Loop Simulation (MILS). At the beginning of design, it is possible to verify the system by MILS.
In verifying this model, confirm that the results of the simulation using the code which is generated from the model and the result of simulating the model are the same, and confirm the generated code is correct. This test is called the Back-to-Back test.
Execute the generated code on the processor such as MCU and co-simulate between the model and processor, it is possible to verify the algorithm. Co-simulation by plant model and processor is called Processor in the Loop Simulation (PILS).
How to execute the code generated by the model on the processor easily?
Even if introducing the Model-Based Development, generating the code from the made model, doing the Back-to-Back test, manual work takes a lot of time to build the code, execute it on the MCU, set the debugger, and co-simulate. And even if constructing the environment, it is not easy to confirm the behavior and analyze the performance.
Embedded Target for RH850 Multicore can generate the code that is possible to run on the MCU by communicating with Embedded Coder® released by MathWorks, build the code and download it to the debugger, connect the model and debugger, it is possible to do PILS by co-simulation.
What is the Embedded Target for RH850 Multicore?
It is the development tool to construct the environment to do PILS at the RH850. Embedded Target for RH850 Multicore has the below functions, it is possible to construct the environment automatically.
- Automatic generation for RH850 project file for Renesas Integrated Development Environment CS+ (*1).
- Code generation from Simulink® model by Embedded Coder.
- Adding source code file to CS+ project file.
- Setting build tool
- Setting debug tool
- Executing debug tool
- Connecting Simulink and debug tool (supporting Cycle accurate simulator (*2) or evaluation board)
After connecting Simulink and the debugger, it is possible to do PILS with MCU by Simulink simulating. Confirm the result of PILS and result of MILS are the same on the Back-to-Back test.
*1 https://www.renesas.com/cs+
*2 https://www.renesas.com/rh850-cycle-accurate-sim
Single core PILS and analysis block performance
Embedded Target for RH850 Multicore can analyze the performance of subsystem block unit in the model by using a cycle accurate simulator or evaluation board. It is a unique function of Embedded Target for RH850 that other companies do not have.
At first, convert the model for analysis performance of the block. Select the measurement target block with the dedicated GUI, then convert the model.
Generate the code from the converted model for analysis performance of the block. It is possible to analyze the performance of the block by doing PILS. It is possible to confirm the result of each block performance visually by graph.
This explanation is for single core but the latest almost RH850 is multicore, therefore, the software also needs to support multicore.
In the case of using multicore, if the software that is executed on a single core is not changed to execute it, performance does not improve because behavior is the same as a single core. To improve the performance by executing multicore efficiently, it is necessary to parallel the software. Parallelization is described in the next chapter.
How to execute the code that was generated from the model easily on a multicore MCU?
To execute the software on multicore, it is necessary to parallel the software for multicore which enables the execution of software at the same time. After parallelizing the software, it is necessary to add the synchronous processing for multicore to be able to execute it in the correct order, it is necessary to add the exclusion control for multicore to not access the common resources at the same time. It is very difficult to parallel the software with these in mind.
The expected performance may not be obtained because the overhead of synchronous processing and exclusion control were large, and executing the software was paralleled with difficulty.
On Embedded Target for RH850 Multicore, by parallelizing the model and generating the code from the paralleled model it is possible to generate the code which can execute on multicore.
Parallel the model for multicore
It is possible to get the execution time of the block by the result of the analysis performance of the block. Consider the core allocation of the block base on the information.
Core allocation is assigning the core to each block with the dedicated GUI, then converting the model.
By this allocation, it is possible to convert the model for multicore.
Allocating green and blue blocks to the different cores
Back-to-Back test by multicore PILS
It is possible to do PILS with a multicore MCU by generated code. It is possible to do a Back-to-Back test by comparing the result of PILS and the result of MILS.
Analysis performance of multicore and validation-optimized multicore parallelization
It is possible to analyze the performance of a block on multicore the same as on a single core. It is possible to confirm the result of each block performance visually by a graph.
To be short, the total execution time compared with the above figure result, repeat considering the validation by multicore PILS, consider the optimized multicore allocation.
Explanation of the Model-Based Development which supports both single core and multicore. Renesas Electronics continues to maintain the Model-Based Development environment.
Embedded Target for RH850 Multicore + Multi-rate, a higher-end version of Embedded Target for RH850 Multicore supports the model which has some control rate (It is called Multi-rate model at Model-Based Development). Please visit the Embedded Target for RH850 Multicore page for more details, including for supporting multi-rate.