Overview VCU development mainly uses the "V" process, all control strategies and imitation models are based on the basic module of block mapping, including system framework design based on user needs, model development based on system framework and automatic code generation, underlying development and code integration, model in the ring test, hardware in the ring test, real car calibration test verification. As shown in Figure 1. The development process of automotive electronic control system has strong hierarchical level, with software development from macro to micro step-by-step development, hardware testing from micro to macro-level verification, software development and hardware testing cross-cutting, mutual support characteristics. In the development process of automotive electronic control system development process system, V process has gradually become a recognized development model.
V process shows the V-process for vehicle controller development developed using models for the application layer. With the increase of micro-control storage space and the improvement of running speed, as well as the efficiency of automatic code generation of models comparable to C code, model development has become the preferred development method of automotive electronic software, and has become the mainstream in the world.
1. User Demand. Software requirements development The first step in software development is to define functional requirements, and complete and accurate requirements definitions and inputs are the guidance for subsequent software development. Software development requirements generally include interfaces with other ECUs (including electrical and communication interfaces), functional requirements for applications, diagnostic calibration requirements, and so on. Software development requirements are ultimately documented, such as communication protocols, diagnostic protocols, pin definitions, and so on. Common requirements development tools include RegMan, Stimulus, Rhapsody, Rotation DOORS, and more to complete requirements definition, requirements analysis, and track and manage changes to requirements throughout the development process.
2. System Framework Design
The most widely used and recognized software architecture for the automotive industry is autoSAR architecture. The core concept of the automated SAR architecture is abstract microcontrollers and ECU(electronic control unit), enabling application layer software to implement microcontrollers and ECU independently and concretely, while configuring standard service programs. Because AUTOSAR is a very complete system, in the development process, it is necessary to analyze the basic software modules needed for VCU hardware resources and user functional requirements, design a software architecture that meets the actual needs of the software framework to complete the software framework design, and also design the framework of the application layer program. The application layer framework design should meet the requirements of clear logic, clear division of functions and low coupling. A good application layer architecture facilitates the independent development and testing of each submodule and facilitates software upgrades and updates. Software issues can be found and resolved more quickly during commissioning and maintenance. System development tools that support automated SAR architecture include synchronous dSPACE development, ISOLAR-A developed by Bosch, PREEvisoni developed by Vector, etc.
3. Model Development
The model development stage needs to complete the interface definition and flowchart document first, do the input and output interface according to the interface definition document, program according to the flowchart, and realize the functional requirements. Automotive electronic software written in C code requires compliance with MISRA-C rules, regulates the limited use of C language for automotive electronic software combination, improves software reliability, and reduces software security risks. Similarly, the use of models to develop automotive electronic software also requires compliance with certain model rules, to avoid the embedded software arbitrary use of Simulink resulting in poor code quality, increased risk of insecurity and other adverse effects.
3.1 Model programming rules typically follow MAAB(Mathworks Automotive Advisory Board) rules from MATLAB, or refer to model programming rules that are tailored to the MAAB rules for their own use. MAAB rules are used in scope for control logic built with tools such as MATLAB, Simulink, and State flow. MAAB has developed hundreds of rules that specify the modules that are allowed to be used, syntax usage, and so on, and its rules are divided into three levels of forced use, high recommendation, and recommendation. Mandatory rules are mandatory in programming, highly recommended rules need to be met to the best of their ability, recommended rules can improve the quality of software products, but non-compliance will not lead to serious problems with software products. It is essential to read and familiarize yourself with the rules of MAAB before you develop the model.
4. Code Integration
Application layer using model development, after development and testing, need to generate C code, and integrated into the project, and the underlying C code combined compilation, and finally generate brush program file s19. Therefore, before the joint compilation, it is necessary to complete the underlying code writing, complete the underlying and application layer interface code, and call the generated functions in the project to achieve the integration and compilation of all C code.The C code is generated by the Simulink model and can be used using the Embeded Coder tool that comes with MATLAB or a third-party tool, such as dSPACE Target Link. B after compilation, the program can be brushed into the VCU for subsequent HIL bench testing and real vehicle testing. In addition to functional implementations, attention should be paid to the Flash and RAM resources used after code generation, and performance metrics such as the MCU load rate occupied by program execution prevent code from exceeding the MCU carrying range, thus creating uncertainty about the execution of VCU functions.
5.Model in the loop
Once the model is developed, model-in-the-loop (ModelIn Loop, MIL) testing can be performed, and MIL testing is divided into single-element testing and integration testing.
6.Hardware in loop
Hardware in the loop Test (Hardware In Loop. HIL) refers to a closed-loop test system in which data and signals communicate between the hardware controller and the simulator. During the HIL test phase, the ECU is the finished state that has been brushed into the program, while the external interface relies on a real-time simulation system for simulation.
HIL test systems typically consist of the following:
1) Real-time imitation Allah machine, you can download the vehicle model, call each board resources.
2)I/O board. Output or capture digital signals, analog signals.
3) CAN communication board, simulates the communication of other ECUs of the vehicle, communicates with the ECU under test.
4) Program-controlled adjustable power supply, for the target ECU and HIL bench to provide low-voltage DC power supply,
5) Fault injection channel, to achieve automatic fault injection or manual fault injection.
6) Simulated load. Pull-up or drop-down loads can be implemented to provide the required load for the ECU output.
7) The computer communicates with the real-time imitation Allah machine, controls the test operation, observes the test results.
In the HIL test stage, in addition to the positive functionality of the test E C U, key performance such as the negative load rate of the microcontroller, message delivery cycle drift, and the CCP calibration and UDS data flow and DTC settings provided by the sending software are also required.
In the field of HIL testing, the most famous is the equipment provided by German dSPACE, in addition to the United States NI equipment also has a certain market occupancy rate. The key to HIL testing is the accuracy of the model, the integrity of the test case, and the degree of automation.
7. Bench testing and real vehicle testing
The final stage of VCU development is bench and vehicle testing, which is defined for testing on benches and vehicles according to functional requirements, and calibration parameters based on the results of the tests to optimize control results so that the VCU meets the expected functional requirements. In the real vehicle testing phase, it is necessary to observe the variables inside the VCU in real time and modify the parameter values in real time in order to obtain different control effects and achieve the purpose of optimizing the control effect, a process called calibration. The calibration of the VCU uses the CCP protocol, and when generating code at the application layer, the data that needs to be measured and the parameters of the calibration (including parameters, curves, MAPs, etc.) are generated into the A2L file, loaded into the A2L file through software such as INCA or CANape, enabling on-line measurement data, and real-time adjustment of parameter requirements.
The CAN bus-based calibration protocol (CCP)is a software interface protocol that connects development tools and VCU to define how module calibration, data acquisition, and access to running data in Flash are performed. In the vehicle controller. CCP enables the following functions:
1)Real-time online testing
2） Each sensor is detected and calibrated
3） An adjustment to an alarm or error value.
Fault diagnosis(UDS)with similar but functionally different functions similar to the CCP parameter calibration defines the specific type of fault and the interface protocol for features such as Flash brushing, which defines the fault level and the corresponding fault code, and in autoSAR compliant, CAN brushes Bootloader to complete program updates through the UDS protocol. As a result, the UDS implements the following functions in the vehicle controller:
1.）Engineers on-site real-time troubleshooting
2）Extraction of vehicle fault status parameters and problems
3）CAN brushes the user program.
In summary, V-process development can significantly shorten the development cycle of VCU, save development costs, and ensure the high quality of code and the reliability of control systems, while providing a visual interface platform for future new control functions.
Comments