The central/zonal architecture proposed for use in software-defined vehicles (SDVs) serves as a platform on which software can be used for ongoing functional enhancements, including providing a uniform application runtime space for implementing the same services as are available on smartphones while enabling a new generation of services that link applications with low-level vehicle control.

Attempting to do so, however, poses a new set of difficulties because it involves the coexistence of software with both low and high levels of safety and security on the same flat high-performance computer (HPC) where they could interfere with one another.

Meanwhile, the evolution of HPC hardware has brought a transition first from single to multi-core CPUs, and then to heterogenous multi-core processors that incorporate multiple CPUs with different speeds and characteristics.
This opens up potential solutions for the problem of software coexistence raised above. By making explicit use of the different types of CPU cores in heterogenous multi-core processors, genuine software separation and isolation become possible.

This series of blogs shines a light on the concept of decoupling (separation of software and hardware and of software with different levels of safety and security), a key architectural requirement as SDVs move on from concept evaluation to enter the commercial development stage. The following topics will be covered:

• How can such an architecture be implemented on the heterogenous multi-core SoCs currently available from semiconductor vendors?
• How can ASIL safety requirements be achieved without compromising the ongoing agile evolution of SDV systems?
• The functionality provided by eMCOS®, a real-time OS that enables decoupling and is ideal for SDV development
  

We hope you will find it worth your while to read all three of these blogs as we discuss each of these topics.
In this, the first blog in the series, we take a deep dive into the question, “What is an SDV?”

Contents

1. SDV definition: Advances in hardware and software
   
   
2. SDV definition: What it means in terms of business and technology
   
   
3. SDV definition: Discussion with examples
   
   
4. Conclusion
   
   

SDV definition: Advances in hardware and software

To begin with, we will use the mobile phone and smartphone as examples to explore what is meant by an “SDV” in the context of advances in hardware.

Prior to the arrival of the smartphone in the 2000s, mobile phones with enhanced functions proliferated in Japan from the late 1990s. These came to be known colloquially as Galapagos phones for the way they evolved in isolation from the rest of the world.

Smartphones took over from mobiles phone from the late 2010s.

That is, the hardware of mobile phones and smartphones has evolved over a period of 20 years.

In quantitative terms, when expressed in FLOPS*, the computational performance of a supercomputer from the late 1990s was approximately two teraFLOPS^*. Measure the performance of a smartphone from 2022 by the same metric and it, too, would be able to execute software at a speed of two teraFLOPS. In other words, the story of hardware evolution can be told in terms of how people are now able to carry around as much computing power as that provided by a supercomputer a mere 20 or so years ago.

* The number of floating point operations per second (FLOPS) is a measure of computing performance.

While we have used smartphones as an example, it is easy to imagine how the same evolution in hardware has taken place in the automobiles and electrical appliances with which we are all familiar. 

Next, let’s consider how software has evolved.

Automotive software today exceeds more than 100 million lines of code.

Historically, the earliest use of software in the 1980s involved a few thousand lines of code and its first applications were in electronic engine control. Over the next 40 years, the volume of software code expanded 100,000-fold.

This 100,000-fold increase came about as software evolved in tandem with the evolution of hardware.

SDV definition: What it means in terms of business and technology

When you think of it this way, it would not be unreasonable to suggest that the vehicles built using this evolved hardware and software constitute SDVs. When the term was originally coined, however, this hardware and software evolution was only part of the story. The term also included a different meaning altogether. 

Here we will try to summarize the views of SDV industry experts. When you look at the text explaining SDVs on the web sites of automotive companies, you will find the term appearing alongside others such as “upgradable cars,” “software-centric,” “separation of hardware and software,” “updates and upgrades,” and “decoupling” (the topic of this blog).

To summarize, there are two different ways of looking at SDVs.

The first is business. The second is technology.

From a business perspective, it is all about using software to provide additional value. It facilitates the adoption of service-based business models, enabling agile development to continue so that new features that add value to vehicles can be made available after they go on sale.

In terms of technology, it enables a software-centric approach with the separation of hardware and software along with updates and upgrades, autonomous learning, and compatibility with the environment.

Put these different viewpoints together to obtain a definition of SDV and what you get is:

An SDV is a vehicle that uses software-centric technology to deliver new service-based business value.

As words alone do not do the topic justice, consider the following two examples:

The first is the microservice architecture (shown on the right of the figure below).

This server-side architecture emerged as something of a buzzword in the late 2010s.

The architecture (shown on the left) that was used prior to this was called a monolithic architecture.

SDV definition: Discussion with examples

Where these two architectures differ is that, in the monolithic architecture on the left, the UI, business logic, and data access layer are all lumped together and deployed on the computer as a single package.

With the microservice architecture on the right, in contrast, individual services are deployed as small “microservices” and the business logic and UI implemented by mixing and matching them as needed.

This allows for the quick replacement of independent modules (the microservices) in a way that closely resembles the “updating and upgrading” of SDVs. SDVs can be thought of as riding this trend.

Defining vehicles before the term “software-defined vehicle” was invented as “hardware-defined vehicles” (HDVs), we will look now at how the two compare.

The figure shows hardware-defined vehicles on the left and software-defined vehicles on the right.
Modeling of the systems on HDVs (on the left) takes a bottom-up approach that is founded in the underlying hardware.
In other words, it is based on a hardware-focused system concept that asks what hardware should be used and what software and systems that hardware will enable to be built.
This means that hardware can be optimized to make more efficient use of the resources it provides and thereby to cut costs.

SDVs (on the right) instead take a diametrically opposite approach that starts with the vehicle’s high-level applications and models the system from the top down.
By doing things this way, applications can be built without concern for the platform and hardware they are to run on provided that the platform provides the interfaces (referred to in the right-hand figure as the Abstraction I/F).

The similarity with the microservice architecture discussed above lies in how business value can be delivered simply by combining applications and interfaces.

Hopefully, this explanation has left you with an appreciation of the software-centric nature of SDVs and how they allow for rapid business value delivery without concern for the hardware.

Conclusion

This brings us to the end of the first blog post.
We hope you will come back for the next installment, which will focus on the series’ core topic of what decoupling means in the context of SDVs.

Additionally, eSOL offers a wide range of solutions that can accelerate SDV development:

• eMCOS®: A real-time OS platform that SDVs can use to get the best out of their HPCs
• AUBIST: AUTOSAR-compliant automotive platform software

If you are interested in finding out more, please feel free to contact us.