SemIsrael Blogs

Why holistic digital twins are needed to accelerate Software-Defined Vehicle development

In the automotive industry there is broad agreement that future vehicle development methodologies will need to transform to meet the needs of “Software-Defined Vehicle (SDV)”. The move from “Hardware-defined” to “Software-defined” will require significant restructuring of processes that have been in place in some cases for decades. Development lead times need to be shorter, and innovation needs to be faster, which goes against the grain of increased software and systems complexity. That’s why OEMs, Tier 1’s, Tier 2s and IP providers are all investigating the potential of virtualization, or “digital twin,” to address the SDV challenge.

Figure 1: Digital Twin address the challenges of the Software-Defined Vehicle

(Source all images: Siemens Digital Industries Software)

 

Complexity is slowing down the rollout of the SDV

Today’s SDV platforms are blighted by software and system level complexity, which often leads to software schedule delays, threatening value-add feature sets, and even resulting in the cancellation of vehicle platform programs. A potential solution is what’s known as “shifting-left” whereby software development and integration using virtual models is performed pre-silicon availability, but severe challenges remain in actually realizing a development flow that is fit-for-purpose.

The time and resources needed to develop and mature a complete vehicle electronics modeling platform is a significant barrier to the uptake of these new methodologies. There are many different types of models in different development environments to deal with, which have varying fidelities that require different timing domains. Synchronization of these domains presents real issues when trying to create an integrated and meaningful virtual simulation platform. Added to that, many current modeling techniques are also too slow for SW developers to use for coding and debug. So, trying to reconcile what is developed in the virtual world with what will eventually end up on the physical vehicle platform is a chasm developers find challenging to cross.

What is an “integration storm”?

Complexity is not the only issue facing automakers. The integration effort required to create a valuable asset from the disparate elements available, is for some OEMs and Tier1s an insurmountable task. Today’s hardware and software development happens largely in silos, with disparate teams working in parallel, often with no true insight on the progress of their colleagues. It’s no wonder then that in electronics development the system integration phase is the riskiest part of any project. Many issues occur when bringing together the final hardware to create the final system and they are often due to unforeseen system interdependencies. This can be referred to as an “integration storm”. Which at the later stages of development has the potential to cause catastrophic delays.  The likelihood of such issues is greatly increased when there is no common, continuous approach to design, test and validation.

Virtualization is needed at the system level, but this brings its own challenges

It goes without saying that the idea of using digital twin to provide greater insight and analysis, pre-hardware availability is a good one and has been used in some segments of the automotive industry for many years and adoption is increasing. But the lack of joined-up-thinking at the systems level means that outcomes are currently limited, it’s just too fragmented to tackle the “integration storm”

As an EDA vendor, working across the automotive electronics industry, Siemens has been well placed to identify the challenges associated with attempting systems level virtualization. These are the main issues observed that affect the whole value chain from OEMs to Tier 1’s, Silicon and IP providers:

  • There is a general lack of experience in virtual system-level modelling
  • Suppliers lack a consolidated validation environment that gives a full system view (and come to realize that the time and expense involved in developing one internally is often prohibitive)
  • Software and hardware teams are working independently of each other in isolation
  • Software workloads should drive hardware selection, rather than the other way around, this results in hardware that is out-of-date before it even hits the market
  • Modeling and simulation systems are not equipped to handle real-world stimulus and are not integrated with CI/CD/CC flows
  • There is rarely a system level test and validation strategy

The combination of all these issues boils down to a simple fact. Today it simply takes too long to build a meaningful digital twin, in many cases it can take years, negating the benefits which are supposed to include the ability to shift development left and accelerate time-to-market.

Figure 2: It takes years to develop a system level digital twin

Who needs to use system level virtualization and verification and why does it benefit them?

An additional level of complexity is derived from the fact that there is a broad cross section of engineers developing software across the automotive supply chain, all of whom are facing different challenges and have different end goals.

Let’s have a look at some of the major personas:

Systems architects: OEMs and Tier 1 architects need to determine the high-level structure of a vehicle’s complex electronic and electrical (E/E) systems and define how hardware and software components interact to achieve functional requirements. An SoC architect may need to integrate heterogeneous multi-core architectures, plus processors, graphics, AI engines, as well as various peripherals onto a single chip. Both groups need to adhere to strict safety and security standards.

  • Virtualization goal: They need a single holistic environment where they can run software workloads across an entire system, it needs to be customizable and fast so that multiple configurations can be evaluated cover the entire SDV development flow.

Software application developers: Again, this category can be segmented further, user space application developers, use generic OS level environments to write software, then the final software is “ported” to the hardware-relevant BSP. Virtual models could be used for this but are often too slow. Low-level firmware application developers on the other hand do not rely on fast models, they need fidelity, and accuracy so they can make significant use of today’s virtual models

  • Virtualization goal: User space developers want to be able to develop earlier, so need pre-silicon availability. They need faster models, and want the model base to be as close to the final BSP as possible to reduce porting efforts. Their results could be much more effective if they were able to access code from colleagues in other design teams to take account of interdependencies. If models were available that were fast and accurate, they could be used by both user space and BSP developers:

Software validation and testing engineers, including CI/CD integration: This team ensures that vehicle meets its performance and quality goals and all the relevant automotive standards. They design and execute tests and utilize simulation and testing tools to predict system behavior. In the SDV this is becoming a full vehicle lifespan process, as fixes and upgrades are introduced via Over-The-Air (OTA) updates.

  • Virtualization goal: Want to be able to start validating software, at the systems level, pre-hardware and be able to find where faults are occurring and feedback the issues to the systems architects so that the design can be iterated

HiL engineers (migrating to vHiL) are pushing to reduce the number of tests required in hardware, which are cost prohibitive. They want to virtualize as much as possible at the system level to eliminate the vast majority of fails before testing in hardware.

  • Virtualization goal: They need to build a full system platform to find errors early and to be able to spot those resulting from interdependencies. They also need greater insight into what is happening when the system fails.

Figure 3: Virtualization goals by person

Moving towards a holistic digital twin

Several of these virtualization goals could be considered cross persona. What they all need is the ability to perform virtualization at the systems level and to have an environment available that enables them to share results and utilize the learning of the other personas.

What is needed is a clear route to an integrated, customizable, cloud-based, holistic Digital Twin that can deliver on the needs of multiple personas. This is the only way to truly enable the cross-silo engineering required for SDV.

Kick start SDV development using pre-integrated digital twin

As discussed, the cost and integration effort to build out full system simulation models, not to mention the fact that it can take years, has prevented widespread use of system level digital twin by OEMs and Tier 1s.

That’s why Siemens EDA are taking a new approach by offering a pre-integrated system level digital twin for the ADAS and IVI market. Of course, there can be no one-stop-shop solution for complex automotive systems, but having a common platform that can be used across an organization to kick start development can greatly accelerate the adoption of virtualization. With such a digital twin, bring-up can happen in days, not months or years. Software development using the latest automotive IP such as the Zena-CSS from Arm can start immediately. The platform has the capability to offer scenario generation and to connect to real hardware so the design can be iterated using real world hardware. When it’s necessary to create a more accurate simulation of end users’ system it can then be customized to reflect the final design.

Figure 4: Example of holistic system level digital twin

By offering a common platform that can be used by multiple personas for cloud-based development, it is now possible for digital twin to be adopted at the systems level and to play a key role in accelerating SDV development in a scalable way.

Find out more about how to shift left with Siemens EDA’s digital twin solution: “PAVE360 puts a virtual car on every engineer’s desk”.

Bio

Heather Campbell is the Marketing Director for PAVE360 at Siemens EDA, focusing on accelerating development with Digital Twin to automotive customers worldwide. Prior to joining Siemens in 2022, Heather worked for several leading electronics vendors including Infineon, Texas Instruments and Freescale Semiconductor in a variety of Product Marketing and Management focused roles. She holds an MEng in Electronics and Electrical engineering from Strathclyde University.

Cadence Banner
MORE >
Real Intent Banner

GOLD PARTNERS