Continental_Virtualization-w-DigitalTwins_v003.00_02_40_06.Still025.jpg
  • Homepage
  • Software
  • Software Enablers
  • CAEdge Framework
  • Virtualization
  • Art of Development

    • The Fine Art of Development

    Testing and Optimization Without Target Hardware 

    How do you test electronic systems and software for a car that doesn’t even exist yet? How do you get a system ready for market without driving millions of test kilometers? Continental makes it possible thanks to virtualization.

    Software needs ingenious solutions

    We  are all familiar with the “chicken and egg” dilemma. The question is: which of  the two came first and where to begin – with the chicken or the egg? – in order  to reach a specific goal. For example, how do you get a chicken without having  an egg? It might surprise you to learn that this is also a common dilemma in  automotive technology. Today, we are used to our vehicles offering us  superlative comfort and excellent driver support in both everyday and critical  situations. And everything needs to be absolutely reliable. The key here lies  in sensor technology and, above all, the software that goes with it. This is why modern vehicles run more software than any other mobile system. And there  is no end in sight to the ever-growing lines of code required.

    Today,  software has become so important in cars that it is the vehicle electronics  (hardware) that are being adapted to the requirements of the software.  Nowadays, it is the software that calls the shots. The electrical and electronic architecture of vehicles is therefore being completely overhauled, and the concept on everyone’s lips is the software-defined vehicle (SDV). Here, the most important step is to make the software independent of the hardware. This separation makes it possible to develop software one-time only and then run it on a variety of hardware – that is, to reuse it. Separating the two components allows the different development cycles for software and hardware to  be maintained. Software updates generally happen much more often than hardware  ones.

    In  order to host this mass of software (after all, it needs to “run” somewhere), a car needs to be equipped with high-performance computers. This is where the new  high-performance computer (HPC) device class comes in. These devices are home  to the massive amount of in-car software needed for today’s vehicles. The small  “catch” is that the sheer volume of software and the degree of networking  between the systems, plus the large number of people involved in software  projects, makes the programming so complex that software development for cars  is one of the most challenging tasks for engineers to master. Automotive  software development only works with tools, processes and automated routines  that are sophisticated and provenly reliable down to the last detail – not to  forget: testing, testing and more testing.  Because in the “end product” car, the software must operate reliably without  any ifs or buts.

    Which  brings us back to our chicken-and-egg dilemma: the de facto situation today is  that hardware prototypes are only available in limited quantities. Moreover,  these prototypes only become available later on in the development process,  while development cycles are simultaneously becoming ever shorter and faster.  This leaves less time for development – and even less time for testing new  software. So what’s the solution?  

    The HPC as a “super brain”

    For an automotive system supplier with enormous responsibility for quality such as Continental Automotive, this dilemma is of course nothing new. It is part of everyday life. The high level of responsibility the company bears for its customer projects, as well as the challenge of mastering the constantly increasing level of software and system complexity, cannot be managed with manual processes. Other solutions are called for – and Continental has created them. This innovation has its deepest roots in the pioneering achievement of being the first tier 1 to successfully bring a new type of high-performance computer (HPC), complete with vehicle software, into volume production.  

    What makes this possible? Testing, testing and more testing... and the earlier, the better. And here we are again, back to the chicken and egg, because how do I test software on hardware that I do not even have yet? In a nutshell, the answer is by pretending that I already have the HPC for the future vehicle. Rather than waiting for a hardware prototype of the HPC to become available and then loading it with software to test it, I simulate the entire HPC in the cloud and test run my newly developed software on that virtual device. This is made possible through a solution called a virtual ECU Creator (vECU Creator, for short), which Continental has developed together with Amazon Web Services (AWS). The control unit (which can be a high-performance computer or HPC, for example) that I simulate in this way is referred to as a virtual ECU, or vECU. The vECU Creator can thus be used to simulate a so-called digital twin of the as yet unavailable ECU hardware. In a sense, you get the chicken before the egg has even been laid...

    Millions of test kilometerswithout leaving the room

    A software developer can use the vECU Creator to create a digital twin of an HPC while the HPC itself is still under development. However, not all HPCs are the same. Depending on the area of application and vehicle domain for which the device is intended (e.g. the cockpit), HPCs differ from one another in certain aspects, even if the basic structure remains the same. With such a digital twin of the physical HPC, the developer can take a shortcut: instead of waiting until hardware prototypes become available, the software testing phase begins while the HPC is still being developed. The whole thing looks complicated – and it is. A great deal of experience with software and hardware projects is required, especially in the field of HPC.  
    Figure 1: Digital twin of a physical high-performance computer (HPC)

    Digital twin of a physical high-performance computer (HPC)  

    With the vECU, around 80% of software development work, including testing, can be carried out on the HPC simulated in the cloud. Only around 20% then actually requires testing of the real hardware. This 80% represents a huge time saving since the development work is carried out without any prototypes. The wave of integration and testing work that normally “piles up” until hardware is finally available is reduced several times over, and programming can be carried out faster and more effectively. Specifically, I can send my new software onto a million kilometers of virtual test track each day without it ever leaving the room – and without burning fuel, emitting CO2 or wearing down tires. 

    Developers can choose their virtual ECU from a wide range of ready-to-use virtualized hardware devices. These can be typical control devices based on micro-controllers as well as HPCs or so-called zone controllers. Once the desired chipset and middleware have been selected, the vECU is generated in the programmer’s development environment and he or she can start testing the code right away. Any ECU based on the common AUTOSAR Classic, AUTOSAR Adaptive, QNX, Linux and Android operating systems can be simulated for test purposes using the vECU Creator. These various operating systems each run independently in so-called partitions without interfering with one other. The connections for the respective peripherals (such as a display, a CAN bus or an audio input/output) are also simulated. The individual partitions process data at the same speed as the real hardware and communicate with one another and with their peripherals in real time – all of this in the cloud, without being limited by the lack of hardware.

    The entire process is referred to as “shift left.” What is meant here is that the start of the test phase is brought forward by developing hardware and software simultaneously – in other words, it is shifted to the left on the typical timeline of a development project. This “shift left” with continuous testing during development is gaining growing acceptance within the industry.  

    The big picture

    The vECU Creator is integrated into the Continental Automotive Edge Framework, or CAEdge for short. The process just described for the virtualization of an HPC serves to identify early on whether a specific software fulfills its purpose and to eliminate bugs. Instead of on the road, this early review and optimization takes place in the cloud, in keeping with the catchphrase “from road to cloud".
    Figure 2: Time savings through the use of hardware virtualization

    Time savings through the use of hardware virtualization       

    This allows new functions/applications based on software to be developed more quickly and reliably, which in turn speeds up market launch. This is important in the automotive industry because the development cycles for software are much shorter and faster than the product life cycle of a car. To bridge this gap, the CAEdge framework provides a complete environment that includes everything developers need for the simulated development and testing of new software. This ecosystem for developers supports software-defined vehicle projects from the initial architecture concept through to integration of the software on the target hardware.  

    The entire CAEdge framework is in the cloud, meaning that developers from around the world can access it and use the simulation tools. The virtual hardware (vECU) is also accessible to everyone with access to the framework at the same technical level. This allows distributed development projects – which are commonplace today – to be organized to optimal effect. On the framework, new applications can be up and running in a vehicle within a few days and tested over many virtual test kilometers. The software can be shared with others and, overall, brought to market much faster than before – in the case of Continental’s Smart Cockpit HPC, in 18 months from the start of the project instead of the usual three to four years! So the chicken and egg dilemma has been solved.