What if you could create a virtual prototype of a product (e.g., ECU), test its functions and make design changes before even creating a physical prototype? This is virtual validation.
Virtual validation is a process used to test and verify the software in a controller. This includes simulation of ECU(s) in multiple environments and conditions to ensure the proper functioning of the controller. Virtual validation enables the design and implementation of the system before investing significant capital in development. In other words, virtual validation reduces costs and market lead time, as well as increases the quality and robustness of the ECU’s software. The use of virtual validation is increasing in the automotive industry and as vehicle manufacturers test new technologies in both electric and autonomous vehicles. Virtual validation allows companies to simulate batteries and electronic design systems, perform test drives for millions of kilometers and millions of lines of code without manually building a prototype. Aviation and defense are other industries that benefit greatly from virtual validation, where prototyping can be both expensive and very difficult. Virtual validation is often referred to as Software-In-the-Loop simulation (SIL) since the test object’s software is plugged into the simulation loop.
Benefits of Virtual Validation:
- Software verification in an early stage
- Keep software testing and hardware integration testing separate
- Ability to scale the test environment to perform parallel tests, both locally and in the cloud.
- The test development can be done in parallel with the software development. That way the set of tests is ready whenever hardware is available to be tested in a HIL simulator.
Virtual validation enables you to bring forward parts of a project’s integration testing. How? Through simulation and by working in a parallel process where the real and virtual development phases interact with each other in time.
Virtual Controllers
A virtual controller is a software that represents a real controller (ECU) in a simulation. Virtual controllers come in many different forms, such as purely function code, to more advanced implementations with production code and basic software implementations.
In the early stages of testing and validation, you often want to be able to test the latest version of your feature without having to integrate it into the hardware-specific software. You can then easily simulate only the function code together with the model for the surroundings. This can be achieved in different ways, for example by having the function code in an FMU or Docker container.
Control systems used for ADAS/AD functions often make decisions based on sensors and therefore require realistic sensor data for functionality to be validated. In some cases, it is enough to get information about what the sensors see, e.g. an object list, but in the end the function still needs to be validated together with its algorithms for interpreting sensor data.
This requires injecting raw data from the sensors, either real recorded data or artificial, simulated, sensor data. Regardless of the source of the data, one must be able to inject it into the format that the controller expects. For
Regardless of where the data comes from, one must be able to inject it into the test object in the format that the controller expects. When the real hardware is tested, a device that collects and converts the sensor data into the expected format of the test object is needed. This device can be a dSPACE Environment Sensor Interface Unit (ESI Unit). The ESI Unit can transform multiple streams of data from different sensors and play the information from them to the test object in real-time and synchronized with each other. In the SIL case, no hardware is used, but it is still important that the stream of sensor data is in the correct format and that the data from the different sensors is played at the right time. For this application, there is a virtual ESI Unit (v-ESI) that integrates between the sensor simulation/playback and the test object and also closes the loop with the feedback of data from the test object to the simulation.
At a later stage, you need to test your finished production code in an environment as similar to the real one as possible. In these cases, a so-called virtual ECU, V-ECU, can be used. A V-ECU consists only of a real production code and does not require any special hardware, unlike what we call Soft ECU, which is just a simplified model of the behavior.
V-ECUs may have different levels of abstraction, depending on what they are used for:
- Application-levelofV-ECU’s contain selected parts of the application software, and a complementary framework to make them executable
- V-ECU may also include the application software and parts of the production basic software, such as diagnostics and communication modules.
- V-ECU can include complete application software and hardware independent basic software,basicallyeverything except the hardware-dependent MicroController Abstraction Layer.
dSPACE Toolchain
The dSPACE toolchain offers many opportunities to create a complete validation process. Fengco and dSPACE offer tools for all stages of the process, both for the creation of the virtual ECU and the test environment that generates stimuli/sensor data in the expected format.
Generating V-ECU's
There are different ways to create a V-ECU depending on what it is to be used for, the needs of the project and whether the development is based on AUTOSAR or not. Feature and software developers working only with individual components can create a V-ECU directly with TargetLink in Simulink. The result is a simple V-ECU with only a specific part of the application layer of the ECU software and enables basic functional tests. Integration testers who want to test a more complex network of features can combine software components, functions, or non-AUTOSAR code from different sources in SystemDesk to create the ECU’s software architecture. They can then use the SystemDesk V-ECU Generation Module to create a complete V-ECU. This includes the run-time environment (RTE) and, if necessary, basic software in addition to the application layer. The V-ECUs are used for PC-based simulation with VEOS.
V-ECUs can have different levels of abstraction, depending on what they are used for:
- V-ECUs at the application level contain selected parts of the application software, the operating system, the RTE, and required parts of the basic software typically provided by DSPACE.
- V-ECUs can also include the application software and parts of the production basic software, such as Dem, NvM, and COM.
- V-ECUs can include the complete application software and hardware-independent basic software, except modules for the Microcontroller Abstraction Layer (MCAL).
Virtual Controller Simulation
When it comes to simulation of virtual controllers and external models, it can be done on everything from the user’s own computer to an external simulation in the cloud.
If a third-party solution is used to create the virtual ECU, you can integrate it via dSPACE V-ESI.
For PC-based simulation, the VEOS simulation platform is used, which executes the entire environment directly on a PC in simulated real-time with high performance. Time can be scaled as much as the hardware allows, while the execution order and the time perceived by the ECU remains deterministic. This allows for connecting different ECU’s and external models either directly through ports or simulated buses such as CAN, LIN, or Ethernet.
One of the biggest benefits of virtual validation is the independence of on-site hardware. When the test object is only software, there is no requirement to have the test environment on premise. By moving the test environment to the cloud, several new possibilities arise, such as parallel simulation, where different tests can run against the same test object at the same time. dSPACE VEOS integrates easily into the customer’s on-site data center or directly into the cloud, and SIMPHERA offers a complete cloud test environment that includes everything from simulation models and testing platform to managing parameters and scheduling tests. By using SIMPHERA in a cloud managed by dSPACE, you also don’t have to think about maintenance and updates. You can instead focus on the important part – testing your software. A pure cloud-based solution also provides the possibility of flexible and scalable computational power – increase or decrease the number of calculation nodes according to your specific needs.
If you want to connect your production code with what is to be controlled, such as real actuators, before the ECU hardware is available, you can execute V-ECUs on dSPACE prototyping solutions, such as MicroAutoBox.
If you want to test the integration of the virtual ECU with existing physical ECU’s, it is possible to mix them in a SCALEXIO HIL simulator. The V-ECU ports are then connected to physical IO and bus communications are routed to physical buses so that the other ECU(s) can communicate with it with the same interface as it would with the finished, real, ECU.
