Hardware in the form of ECUs (electronic control units) or vehicle prototypes is frequently used for functional tests of ECU software. However, this poses time and cost challenges in the development process, as prototypes are typically available only at later stages of the development cycle.
A recent study on testing ECUs with prototypes revealed that in approximately 60% of development cycles, no prototypes are available, and 10% of engineers are forced to run these tests on actual vehicles. Unavailability of prototypes and the high cost associated with their creation pose several challenges, such as:
- Limited testing capabilities
- Discovering integrations-related shortcomings only after ECU results become available
- Verifying design during the development stage and providing quick updates without hardware prototype
- Shrinking development cycles in the current market
It would be much better to test a module in full system context immediately after a change of the module and before the module proceeds to the next process step.
What is virtual ECU validation?
Any software functionality that can be executed without hardware is called a virtual ECU (vECU). Being hardware-independent, virtual ECUs offer the advantage of testing various scenarios in a simulated environment. Apart from being cost-effective, virtual ECUs help evaluate the software’s functionality and interaction with environmental and component models long before using hardware prototypes. This facilitates developers in testing their ECU software during the development stage, assuring its usability in the most viable way.
Benefits:
- Early discovery of integration issues
- Scalable environment
- Reduced validation efforts
- Stable and reliable testing environment
- Reuse of available hardware test cases
vECUs may have different utilization levels, depending on their use. Application-level vECUs contain selected parts of the application software and a complementary framework to make them executable. vECUs may also include the application software and parts of basic production software such as diagnostics and communication modules. vECUs can include complete application software and hardware-independent basic software—that is, everything except the hardware-dependent Microcontrollers Abstraction Layer.
How does it work?
With only a real production code and no dependency on hardware, a virtual ECU platform helps developers build ECUs by launching virtualized environments to test the intricacies of the software stack. This virtual control unit simulates relevant aspects of the real control unit, connecting input and output signals of the environment model so that the function software can read sensor values and set actuators.
Simulating vECUs does not depend on real-time execution. Scaling up the simulation to more powerful CPUs lets you run more tests in the same amount of time.
vECUs can be classified into the following categories:
Level 0 vECU (Controller Model)
Level 0 comprises the controller model (e.g., as a MATLAB Simulink model) or the C code generated from the controller model. This is the simplest vECU type and can only be used to test the control algorithm itself.
Level 1 vECU (Application Level)
Level 1 contains production codes of the application SW specific to the vECU. They communicate and operate at signal levels without using a bus or a network.
Level 2 vECU (Simulation BSW)
Level 2 vECUs provide simulated basic software (BSW) functionalities in addition to the content of Level 1 vECUs. They can communicate at the signal level, like Level 1 vECUs, and at the bus or network level.
Level 3 vECU (Production BSW)
Level 3 vECUs include not only production application software but also production basic software (production BSW) for tests of the BSW. Level 3 vECUs can be used to test a real ECU's hardware-independent software. They can also be used to test the BSW itself, e.g., testing the complete or parts of hardware-independent BSW functionality of a real ECU at different test levels (subsystem-test, stack-test, component-test).
Level 4 vECU (Target Binary)
Level 4 contains the production code compiled for the real ECU. Since it's the closest to a live system, and there are no code changes between the vECU and the code for the real ECU, Level 4 vECUs have the capability to include hardware dependency that helps assess possible faults and issues.
Visualization of the use of virtual ECU testing in an integration and test platform for various stages of a full vehicle (V-process)
Efficient testing of vECUs
The usability of ECU software in the system context can be investigated and tested at an early stage of the development process, providing an ideal basis for further enhancement. The synergy between the automotive OEM and the supplier is strengthened by enabling them to work jointly with the same artifacts. Through frontloading, i.e., the early validation of discrete sub-functions, the quality of the ECU software significantly improves, and the development process becomes more efficient. The realistic visualization enables ease of use and facilitates the acceptance of the validation results by different users. While this approach has helped save time and cost allowing manufacturers to invest more time in deploying new functions, it has also enabled ECU software to achieve higher maturity levels.
Future of mobility
Software-defined vehicles integrating aspects of connectivity within automobiles will cause disruptions in the mobility market, significantly altering the industry. Virtual ECU validation is one of the best ways to test complex products at early stages. Virtualization allows the simulation of automotive ECUs on a Windows PC executing in closed-loop with a vehicle simulation model. This approach enables the moving of certain development tasks from road or test rigs and HiL (hardware-in-the-loop) to PCs, where they can often be performed faster and cheaper. With Autonomous, Connected, Electric, and Shared (ACES) mobility and increased OEM investments in software-enabled features and connected vehicles, the automobile industry is all set for a significant transformation fueled by digital technologies.
Case study
The above analysis motivated Cyient to complement the conventionally established process by generating vECUs in the early stages. This feature enables the validation and testing of all embedded functions before the actual generation of the C code. Here vECU vendor tools such as VEOs/Silver/Virtual Target were used to validate the SW that is done by the control/automation desk.
References for virtual ECUs platforms supported by different vendors:
- dSPACE : Platform for PC-based simulation of models and ECU network communication
- Vector : Developing and Testing Virtualized AUTOSAR Software
- Danlaw : Virtual ECU Testing Using Mx-Suite
About the author
Naresh has 15+ years of experience in the automotive industry in system and software testing. He is Solution Architect at Cyient, providing expertise in automotive domain testing in functions such as ADAS (advanced driver assistant system—short-range radar, camera, etc.), body control modules (BCM), active safety systems (ABS/TC/YSC), and infotainment.
Let Us Know What You Thought about this Post.
Put your Comment Below.