In SDV (Software-Defined Vehicle) development, HW/SW Decoupling

SDV (Software-Defined Vehicle) is one of the most frequently heard terms in the automotive field. However, within the company, we don’t hear it as much during development. Internally, we use the term MB.OS (Mercedes-Benz Operating System) much more frequently. Nonetheless, it is clear that SDV is widely used in media and other company blogs.

 

Despite this, I can’t help but feel that, like the term ‘ubiquitous’ before it, SDV seems to repurpose existing technology under a new label. Many people in various places talk about the term SDV differently. Here, I would like to discuss one aspect of this concept, which is the development environment for automotive software that allows software to be developed independently of hardware.

Ref: 출처: https://techblog.samsung.com/blog/article/277

 

In a blog post on Samsung Electronics’ tech blog, https://techblog.samsung.com/blog/article/277, the concept of a “cloud-native platform” is discussed. Automotive software development faces challenges due to the complexity of hardware configurations and difficulties in securing hardware. If we could develop software in a virtual environment without hardware and utilize the binaries tested in that environment on actual targets without recompilation, development and integration speeds would increase significantly. This concept is also well-explained in a presentation by Hyundai Motor Company, detailed in this Brunch article.

 

These virtual environments can be implemented in various ways. Each VM (such as Linux VM and Android VM) can be set up to communicate using QEMU images, or you can use the QNX hypervisor to run QEMU ARM64 Linux and Android images on AWS Marketplace.

 

We are not yet at a stage where we can say these methods are fully mature. Many efforts are underway to provide such environments, with the goal of developing and pre-validating in these environments before conducting final hardware tests on actual targets. Ideally, this process uses the same binaries to identify and resolve issues consistently and proactively.

 

To reduce the number of hardware units, multiple ECUs are being consolidated into fewer, smaller units, allowing various operating systems to run and perform different functions within a single ECU. This integration increases software complexity and raises the challenge of effective modularization. Dependency issues are also prevalent and need to be addressed, but eliminating legacy systems is not easy. The key point here is that increased software complexity makes creating virtual development environments challenging.

 

In summary, efforts are being made to develop automotive software independently of hardware through virtualization. The term “vECU” is sometimes used. This can involve setting up environments on developers’ PCs or in the cloud. The ultimate goal is to use the same binaries in both virtual and real environments, facilitating fast development and pre-validation, and enabling easy debugging by replicating the same issues. Despite the potential obstacles posed by complexity and legacy code/architecture, overcoming these challenges could enable frequent updates via OTA (Over-the-Air), a major component of SDV.

 

In the next post, I plan to briefly discuss how to deploy a guest VM on a QNX hypervisor on AWS as part of this virtualization approach.