Embedded Control Software For and ECU: Development, Testing And Validation

An embedded control software is developed in three main steps. A controls engineer may be involved in one or all of these stages of the embedded control software development process.

?Phase 1: Desktop engineering: non-real-time, concept, modeling and simulation

?Phase 2: Hardware-in-the-loop (HIL) testing

?Phase 3: Prototype machine testing

Desktop engineering is the process we do in classroom and office environments. It is the concept development, coding, simulation, and analysis process of engineering. The control algorithm is developed and tested on a desktop-type computer environment using a mathematical model of the controlled plant. The simulations at this stage do not need to be real-time. This stage is also referred to as software-in-the-loop (SIL) and model-in-the-loop (MIL) testing. Increasingly, not only the plant but the environment in which the plant operates, and the disturbance signals as a result of the interaction are also very realistically modeled and visualized using ”video game software” tools such as Unreal Engine 4.0. That way, the simulation is presented in a visual, 3D, and realistic environment.

The second stage is the mid-level between pure software simulation and all actual hardware testing (on the actual machine, i.e. car or airplane), referred to as the hardware-in-the-loop (HIL) testing. In this stage, the control algorithm runs in real-time, on an actual ECU or simulated ECU, and the plant model also must run in real-time to work meaningfully. In order to be able to run the plant model run in real-time, the model often needs to be simplified compared to the plant model used in the” Desktop engineering” phase. The plant model is simulated in real-time, and sensor and actuator signals for the controller is simulated by the HIL system. As far as the ECU (controller) is concerned, the ECU is dealing with the actual plant, because it reads the input sensor signals (simulated and provided by the HIL system) and sends control output signals out which is processed by the HIL system again in real-time. Many logic errors should be caught and fixed at the HIL testing stage, i.e. 95% of all potential errors. In practice, the level at which part of the IO (sensors and actuators) are simulated or provided in hardware varies between the HIL testing implementations. Video game simulation software is also being integrated into HIL testing to provide an increasingly realistic 3D visualization environment.

The third stage of testing is done on the actual plant hardware, usually a prototype test machine. In this case, everything is intended to be an actual product. Embedded control systems are tested exhaustively before they are released as part of a product to the market. As part of the testing and validation process, we tune the control algorithm parameters (i.e. tune PID control algorithm gains or tune the values in a look-up table), before finalizing the code that will be “flashed” to the ECU memory. This activity and associated tools are also referred to as “Measurement, Calibration and Diagnostics” (MCD) tools.

The word “testing” refers to generating a defined set of conditions and determining what the system response is. “Testing” documents what happens under what conditions. This is done in all three phases; in 100% software simulated environment in Phase 1, partially simulated and partially hardware (ECU hardware) environment, and 155 % actual environment (both ECU and plant are actual hardware).

“Tuning” (also called “calibration”) refers to adjusting the parameters of a control software logic, such as adjusting the gains of a PID control algorithm. The word “validation” means that the system behaves or meets certain performance specifications exactly as required under the defined conditions. In other words, “validation” documents that the system does what it is supposed to do.