Why Open-Source Software Is Essential in the Software-Defined Vehicle Era

As software becomes the primary factor determining vehicle value, the software-defined vehicle (SDV) is shifting from a buzzword into an implementation premise. An SDV is not a fixed architecture finalized at the time of shipment. Rather, it is a design concept in which new features, performance improvements, and security updates will continue to be added throughout the vehicle’s lifecycle.

Under this premise, conventional automotive software development methods—closed implementations tightly coupled with specific hardware and the accumulation of locally optimized patches—are rapidly becoming unsustainable. In the SDV era, competitiveness is determined not by whether a product can be built and shipped once, but by whether it can continue to be developed over time.

Figure 1. The evolution from hardware-defined systems to SDVs.

Technical Requirements for Today’s Automotive Software

Automotive software in the SDV era faces three major technical requirements. The first is the ability to support long-term, continuous updates. Security fixes, regulatory compliance updates, and functional expansion will continue to increase. Software must be designed with the expectation that it will continue to evolve.

The second technical requirement is reusability across the entire supply chain. As original equipment manufacturers (OEMs), tier-1 suppliers, semiconductor vendors, and software vendors participate at different phases of development, the code base becomes more fragmented and integration and validation costs increase exponentially.

The third requirement is the ability to keep up with the speed of technological evolution. Linux kernels, U-Boot (Universal Boot Loader), virtualization technologies, and real-time operating systems (RTOS) all evolve in short cycles, and fixing a system to a specific version will become technical debt in the future.

Few approaches can satisfy all three requirements simultaneously. One practical solution is a development approach that places open-source software (OSS) at the core.

Figure 2. Legacy distributed ECUs vs. SDV integrated architecture.

Using OSS Alone Is Not Enough to Achieve SDV

It is often misunderstood as a simple statement that “SDVs cannot be realized without OSS.” In theory, it may be possible to build everything using closed software. However, the real issues are development speed and sustainment cost.

In automotive development, the following issues occur repeatedly:

• The accumulation of local patches causes significant divergence from the original code, making it difficult to keep up with later versions.
• The lack of application programming interface compatibility across vendors causes integration and testing to break down.
• Security responses are always delayed.
• Large-scale rework becomes necessary whenever new technologies or tools are introduced.

These problems arise not from whether the software is open source or closed, but from taking the wrong approach to software itself.

Figure 3. Downstream fragmentation vs. upstream-first development.

The OSS Utilization Strategy Required for SDV: Upstream First

The essence of the OSS utilization strategy required in the SDV era can be summarized by the concept of “upstream first.” This development strategy means that when software changes are needed, they are not applied locally; instead, they are reflected in the source code (upstream) in coordination with the OSS community.

These are the reasons why the upstream-first approach is important:

• Single source of truth
• Higher quality through reviews by knowledgeable community members and continuous integration
• Joint validation across multiple companies
• Easier migration to the next long-term support (LTS) release and to new technologies

In SDVs, what matters more than whether something works today is whether it can continue to be updated five years from now. Code incorporated upstream becomes a “seed” that continues to evolve with the community.

The Value of Reference Implementations as Seen in AGL and SoDeV

Automotive Grade Linux (AGL) is a representative project that supports the use of OSS for SDVs from an implementation standpoint. AGL is not driven by specification definition; instead, it advocates a code-first approach and has built a common foundation (unified code base) based on working implementations.

For SDV use cases, a software-defined vehicle reference platform (SoDeV) has been presented as a virtualization-based reference implementation. In SoDeV, multiple guest operating systems—including Linux, AGL, Android Automotive, and Zephyr—can coexist on top of a type 1 hypervisor platform such as Xen. Hardware dependencies are decoupled through virtual input/output (VirtIO). As a result, SoC-specific device drivers are eliminated.

The significance of such reference implementations is substantial. OEMs and suppliers can begin not from scratch, but from a common foundation that anyone can discuss, and can focus on their own areas of differentiation.

Device Virtualization with VirtIO: A Technical Foundation for Making SDV Real

One of the key technical pillars for making SDV architectures scalable in practice is device virtualization. To consolidate dozens of distributed ECUs into a centralized or zonal architecture, multiple OSs must be able to run simultaneously on a single high-performance SoC.

In such an environment, systems are designed on the assumption that multiple platforms will coexist in parallel, such as a high-function Linux-based OS for in-vehicle infotainment and the cockpit; an RTOS for actuator-control domains; and software stacks that satisfy functional safety requirements. In this configuration, simply virtualizing the OS is insufficient. A critical issue is how to share devices—including displays, cameras, storage, and networking—safely and efficiently.

VirtIO plays an important role here. VirtIO defines a standardized paravirtualized interface between guest OSs and back-end drivers operating in the host or in a privileged domain. By abstracting hardware-specific details behind a common virtual interface, it achieves strong decoupling between software and hardware. As long as the VirtIO back end complies with the specification, guest OSs can migrate across different SoC generations and hardware configurations using common VirtIO front-end drivers. This decoupling has several important implications:

• Improved software reusability across vehicle generations
• Clear separation between safety-critical and non-critical domains
• Reduced long-term maintenance cost by limiting hardware-dependent code

VirtIO is not merely a virtualization optimization technology; it is a core technology that structurally enables continuous software evolution in SDV.

Figure 4. SoDeV reference architecture with Xen and VirtIO.

Renesas’ Efforts in OSS-Based Virtualization

Renesas has been actively involved in developing this virtualization ecosystem, particularly within automotive OSS communities. In the context of AGL and SoDeV, Renesas is advancing efforts to make virtualization practical for real automotive applications across both the SoC enablement layer and the upstream software layer.

At the SoC level, Renesas designs with isolation, interrupt management, and the performance characteristics required by type 1 hypervisors such as Xen in mind. In addition, Renesas supports efforts to make OSS compliant with functional safety requirements such as ISO 26262. Linux kernels, U-Boot, Yocto layers, and virtualization-related components are maintained upstream as much as possible to minimize proprietary differences.

In SoDeV-based reference architectures, VirtIO virtualizes major devices, including display and input subsystems, enabling multiple guest domains to share physical resources via standardized back-end drivers. This approach is consistent with the upstream-first philosophy in that it evolves together with global OSS communities rather than being confined to vendor-specific implementations.

Figure 5. OSS-ready reference platform for SDV evaluation.

Reference Hardware That Connects Architecture and Reality

The effectiveness of an SDV architecture using VirtIO depends on whether it can be evaluated and validated in development environments. For that reason, reference hardware plays an important role in connecting the concept of SDVs with day-to-day engineering.

The Sparrow Hawk board, which is equipped with the Renesas R-Car V4H SoC, provides a pre-integrated environment for Linux, AGL, Xen, Zephyr, and VirtIO. In addition, because it works closely with upstream development communities, the latest versions of the complex software architectures required to realize SDVs—including virtualization, mixed-OS configurations, and device sharing—can be readily used.

This significantly lowers the barrier to entry for SDV development while simultaneously accelerating feedback to OSS communities.

OSS in the SDV Era is a Culture

In conclusion, OSS in the SDV era goes beyond being a mere component or a cost-reduction measure. It is a development culture built on continuous evolution and a common language for growing software beyond the boundaries of individual companies.

When this cycle turns—contributing back upstream, sharing reference implementations, and opening evaluation environments—SDV becomes, for the first time, a “developable reality.”

SDV is not only a shift in architectural thinking but also a technical challenge that calls into question development attitudes. How the industry engages with OSS will ultimately determine its success.

For more information, please visit:

R-Car V4H High Performance AI Single Board Computer

Automotive Grade Linux Releases Open Source SoDeV Reference Platform for Software-Defined Vehicles and Welcomes Five New Members

Keynote: AGL SoDeV: Leading the Software-Defined Vehicles Revolution – Dan Cauchy

Featured image used courtesy of Adobe Stock. All other images used courtesy of Renesas.