Virtualized Automotive Software Development: Introduction (1/3)
Author: Meik Schmidt
We live in a world filled with complex technical systems, many of which we interact with daily. Mobile phones, laptops, headphones, and smart wearables are only a few examples. Among the most sophisticated of these systems are modern cars. They integrate dozens of so-called Electronic Control Units (ECUs) - small embedded computers that rely on increasingly complex software. ECUs control everything from infotainment to critical safety mechanisms like airbags.
With new technologies evolving, the complexity of ECUs and the software running on them continues to grow. Advanced Driver Assistance Systems (ADAS) and Artificial Intelligence (AI) are only two examples of such technologies. Currently, modern vehicles are run by about 100 million lines of code (LOC) and research indicates that automotive software size roughly increases tenfold every ten years [1]. This would result in 1 billion lines of code in the next decade. Figure 1 illustrates this increasing complexity of software. Keeping this in mind, software is becoming the key differentiator and unique selling point for customers. This trend is particularly evident as the industry discusses the concept of the Software-Defined Vehicle (SDV). It describes that the customer's decision to buy a car is more influenced by the vehicle's software than the hardware, which leads to a rapid shift in how automotive companies develop and design their products.
The described development presents significant opportunities, but it also carries substantial risks. In a few words: the more software is used, the more bugs it contains. While bugs can never be completely avoided, they must be detected early and reduced to a minimum to prevent financial or physical damage. Moreover, security-related software features must comply with many industrial standards. ISO26262 is probably the most well-known. It defines the functional safety of a car's electronic components and the prerequisites it must adhere to. Standards like this ensure vehicles can be operated safely without unnecessary risks.
If a bug remains undetected during development, the consequences are severe. It can put the safety of many people at risk and lead to costly recall campaigns, which happen regularly and easily result in damages of several million euros. In 2024, 22% of all recalls were software-related [2]. This fraction has continuously increased over the past years and is expected to keep rising. Figure 2 displays this evolution clearly.
Costly callbacks could almost always be prevented with thorough testing during development. The exact savings from early bug detection are hard to estimate. However, many scientific papers attempt to quantify them. They show that a bug found during maintenance – after the product has been released – can be up to 100 times more expensive than one found during the design phase [4]. Consequently, early detection of software-related bugs can save automotive companies millions in costs.
This circumstance is well-known in the industry. And even though comprehensive testing is already in place and common practice, critical defects are still detected too late. This happens primarily because testing on physical hardware is often carried out very late in the development cycle or is limited by cost, availability, or hardware maturity. One approach to address this issue is to develop the software running on ECUs early and execute it in realistic virtual environments. These environments should simulate the hardware as accurately as necessary. Ideally, the software should run inside the virtual environment exactly as it would on physical hardware, without any modification. In addition, development tools like debuggers, test frameworks, analysis tools, and external simulators should seamlessly integrate with these virtual environments. Developers must be able to use them just the same way they would use physical hardware. This is where Virtual Platforms (VPs) or virtual ECUs (vECUs) come into play. They enable early, cost-effective, and hardware-independent testing, and support all of the use cases mentioned above. So, if VPs promise all this – how do they actually work?
Accurate Hardware Simulation with Virtual Platforms
Virtual Platforms (VPs) are software-based models that replicate the behavior of ECUs or more generally, System-on-Chips (SoCs) and Microcontroller Units (MCUs). They are typically implemented using standards such as SystemC TLM-2.0, allowing developers to model electronic components at a high level of abstraction. A key advantage of VPs is that they simulate target hardware with sufficient accuracy to execute unmodified target software, which is the exact same binary that would run on physical hardware. To achieve this, a typical VP includes models of CPUs, memory, peripheral devices, and a shared bus connecting all these components. An example is shown in the figure below, which displays a simplified version of an open-source ARM VP available on GitHub [5]. It consists of a model of an ARM CPU subsystem, system memory, a global interrupt controller, a UART interface, an SD host controller interface (SDHCI), an Ethernet host controller, and a random number generator (RNG). All components are connected via a common system bus. Software compiled for the target architecture (ARM) can be loaded into the VP's memory and executed directly on the virtual CPU. During execution, the interaction between software and the (virtual) hardware – such as I/O or interrupt behavior – can be observed, tested, and analyzed under realistic conditions.
This testing approach offers several advantages. First, no physical hardware prototype is required. The software can be executed and verified entirely in a virtual environment, allowing software development to begin before any physical hardware is available. This methodology is known as Hardware-Software Co-Design and often referred to as 'shift-left', as it enables parallel development of hardware and software, thereby reducing overall project duration and accelerating time-to-market.
VPs are also highly configurable, modifiable, and scalable. The hardware configuration can be easily changed if necessary. If testing reveals that the initial hardware configuration does not meet the project's requirements – for example, if the available memory is insufficient – the VP can easily be adapted. This makes early hardware exploration possible, helping teams identify optimal configurations long before physical prototypes exist.
Since VPs are implemented entirely in software, multiple developers can work simultaneously on separate instances without competing for scarce hardware resources. In addition, VPs typically offer native interfaces to external development tools. For instance, MachineWare's VPs support integration with GNU Debugger (GDB) via dedicated ports, enabling debugging low-level software such as operating system kernels or device drivers. Even debugging user-space applications works in the same way as on a real system. Screenshot 1 shows how debugging of a device driver might look like. A CAN module (more specific M_CAN) is available in the current version of AVP64. Visual Studio Code (right side) is used to debug the corresponding device driver while the VP is booting a Linux operating system (left side).
As shown, using VPs in isolation already provides a wide range of benefits. However, in real-world systems, the SoC modeled by the VP is typically just one part of a much larger setup – often interacting with external components such as sensors, actuators, or communication interfaces. These components are usually simulated using different tools or simulators from other vendors. To simulate the overall system, all these simulators must work together within a unified simulation environment. Achieving such a setup is challenging, but fortunately, there are standardized interfaces and frameworks designed specifically for this purpose.
Virtual Platforms and Co-Simulation
Simulating a system composed of multiple interacting subsystems is a challenging task, but it is essential for the same reasons VPs are used in the first place. When the complete system is evaluated in a virtual environment, bugs can be detected earlier, reducing the risk and costs of late-detected bugs and recall campaigns. In practice, the various subsystems found in complex technical systems are often developed by different companies, each providing its own simulation tools. To enable system-level testing, these simulators must be connected and able to exchange data during execution. Because this requirement is common in industry, several standardized interfaces have been developed to support such co-simulation scenarios. These standards allow simulators and tools from different vendors to be coupled into one unified simulation environment. Two notable examples are the Functional Mock-Up Interface (FMI) and Vector’s SIL Kit – both of which are supported by MachineWare's VPs.
We created several demos to showcase real-world application scenarios using our VPs with various external simulators and tools, leveraging these standardized interfaces. In the next blog post, we will present one of these demos, illustrating how our VPs integrate with external simulation environments and highlighting the benefits of this approach. We will explore the technical setup, the challenges encountered during integration, and how our solution enhances co-simulation efficiency. By examining this use case, we aim to provide insights into the practical advantages of virtual prototyping in complex system development.
Summary
As automotive systems grow more complex and software-driven, early and thorough testing becomes critical to ensuring reliability, safety, and compliance with industry standards. Virtual Platforms (VPs) offer a powerful solution by enabling realistic, hardware-independent software development and validation. They not only support accurate hardware modeling but also allow seamless integration with external simulators for full-system co-simulation. This blog post highlighted the growing need for such technologies and introduced how MachineWare’s VPs address these challenges. In the next post, we’ll dive into a real-world co-simulation example to demonstrate the practical benefits of this approach.
References
- https://www.researchgate.net/publication/327285609_Revealing_the_Complexity_of_Automotive_Software
- https://www.techspot.com/news/104849-software-fixes-now-account-over-20-car-recalls.html
- https://www.digitaljournal.com/tech-science/new-data-reveals-the-changing-face-of-automotive-recalls
- https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC
- https://github.com/aut0/avp64