Motion Control Resources
Model of Electronic Components and Communications of an Electric/Hybrid Vehicle’s Propulsion System for the Validation of Controllers
National Instruments Posted 05/18/2015
"The combination of this model with NI tools produces a state-of-the-art system for the development and validation of controllers in the automotive sector." - Miguel Allende Marcos, Tecnalia Research and Innovation
Implementing three models that emulate the unavailable functioning and communications electronic control units (ECUs) for an electric/hybrid vehicle propulsion system.
Using LabVIEW software to develop the real-time modeling of the virtual ECUs needed to test the control systems.
Tecnalia is experienced in the automotive sector and in the development of controllers embedded in powertrain ECUs. The systems are tested in the different V stages because of industry trends and recent ISO 26262 regulations. In the automotive sector, it is key that control systems be validated before they are installed in the vehicle. One of the stages previous to this installation is the integration of the implemented ECU with the other ECUs that it needs to interact and exchange data with if working correctly.
Initially we can carry out partial validations of the components, since each company involved in the project can be autonomous until the control software has been embedded in the microcontroller, generating an ECU. The problem arises when the integration (the stage before installation in the vehicle) starts, due to the fact that all the ECUs needed for data exchange might not be available at all times. To solve this problem, we needed to create a project to generate different virtual ECUs that could model the control systems found in a vehicle’s powertrain and:
- Validate the implemented ECU without needing to have the real ECUs
- Check communications
- Inject errors in sensors, in communications, and in the ECU’s functionality from which our system reads data to check the functioning of the ECU during the tests
Carry out automatic and repetitive tests to verify how robust the ECU is in different scenarios
For this project, our objective was to test the traction ECU of an electric vehicle with gear box. This ECU calculates the par set point of the inverter that controls the engine that moves the vehicle in function of:
- The conductor’s demands (accelerator, break, gear)
- The vehicle’s condition (ABS, ESP, TCS)
- The traction system’s condition (cell load, engine and inverter’s condition)
To achieve the required performance for the ECU, we had to build a complete powertrain model to generate all the information required to do the tests. Depending on the ECU being virtualized, there may be two distinctive parts in the code. One of the parts manages the actual physical model of the system to be controlled, and the other one monitors the system control and generation of communications. In this case, based on the system under test, we virtualized the following ECUs:
- Energy Storage System ECU — Since it was an electric vehicle, we modeled the workings of a battery, calculating the average values needed for its correct functioning, such as the instant current value when loading and unloading, the charge level, the voltage of the battery depending on the actual current, and the load and power levels in the car's electrical grid, depending on the demands of the engine and the auxiliary equipment also connected to it.
- Inverter ECU — In this case we modeled the power equipment’s (inverter’s) electrical behavior and also the behavior of the permanent magnets. The model’s available data is the current value of the engine’s par, depending on the par set point, the engine’s efficiency and the thermal image, the value of the speed in function of the vehicle’s speed and the current gear, as well as the value of the current in function of the engine’s par and the operating point (constant power zone or constant par zone).
- Accelerator ECU — This ECU receives the data from the accelerator and sends it through the communications network.
- Break ECU (ABS, ESP) — This ECU reads the driver’s breaking demand and calculates the breaking balance between the mechanical and the electrical breaks. Additionally, it also reads the wheel sensors and carries out the ABS and ESP functions, demanding par values from the equipment, based on the vehicle’s condition.
- Vehicle’s General ECU (Central ECU) — This ECU shows the driver on screen the most relevant data regarding the propulsion system, such as the engine speed, battery’s load charge levels, engine par, and more.
All the virtual ECUs need to be integrated in a real-time platform, so we use software that meets the following requirements:
- Can integrate the different ECUs to generate the complete plant model and the final code to be downloaded to the real-time system
- The ECUs can be implemented in programming languages other than LabVIEW software
- Models need to be interchangeable and the system has to be easy to use
- The ECUs can be connected/disconnected, depending on those available at each stage of the project
- Can connect to an HMI to visualize the working data
- Can possibly generate reports and records
VeriStand software met these requirements. Thanks to VeriStand, we reduced the programming and customizing times for each client and can concentrate our efforts testing and improving the model. That is why we programmed the virtual ECUs with LabVIEW and later compiled them for VeriStand and executed them on a dedicated PXI. Since some of them have physical models of the system, they are executed at a basic time of 1 millisecond. Internally, we set subtasks on the code to emulate the control software and the communications.
We downloaded the whole project on a dedicated PXI-8110 that received the vehicle’s necessary information from another PXI-8110 that had Dynacar, a longitudinal and lateral dynamics vehicle’s model, installed. The virtual sensors generated by Dynacar go to the virtual ECU PXI in the same way as they are read in the car, either through analogue signals or field bus.
Additionally, and since we are using PXI, the communication bus programming (CAN in this case) was extremely simple, using the NI-XNET module to define the messages with the data to be exchanged.
Many of the designed controllers need to be robust and stable when facing changes in the systems to be controlled. In this case, each virtual ECU can generate erroneous data, when functioning as well as when communicating, to test the replies from the designed controllers. Additionally, the ECU being tested has parameters that are modifiable by the user and need to be checked along the whole range.
To meet these two needs, we used TestStand software to carry out many automated tests, not only changing the model parameters, but also the parameters of the tested ECU. We used the CCP protocol to modify the last one, which is the standard automotive protocol for system parameterization.
Thanks to this model of electronic and communications components of an electric/hybrid vehicle’s propulsion system, we could reduce the integration times of the development ECUs, since they were previously tested with virtual models of unavailable ECUs. We also validated the control algorithms. Because it is a versatile system and the ECU can be connected or disconnected as required, it can be used in different phases of the project. All this reduces integration and testing times and generates significant saving on automotive control system development costs. The combination of this model with NI tools produces a state-of-the-art system for the development and validation of controllers in the automotive sector.
Miguel Allende Marcos - Tecnalia Research and Innovation
Maider Larburu López - Tecnalia Research and Innovation
Pablo Prieto Arce - Tecnalia Research and Innovation