Virtualization, Collaboration, and Software at SDV Europe

The SDV Europe conference took place in Berlin (Germany) last week. It was a meeting of technical experts and business leaders from all over Europe, focusing on the current state of software-defined vehicle (SDV) technology and applications. The conference mixed talks with structured interactive workshops, providing a platform for the exchange of ideas and plenty of time for networking and discussions. It was great fun!

The most important observation is that SDV is not just a buzzword. As a speaker said, "The current message for SDV is 'Let's make it real.'" And making it real requires changes to technology and tools—as well as processes and organizations.

Collaboration

One thing that is clear is that SDV will require much closer collaboration between suppliers and customers. Where traditionally companies would buy a complete point solution for a specific function or subsystem as a physically installable unit, with SDV, the emphasis shifts to software and its deployment on shared physical computers. This changes how deliveries and deliverables are handled—moving towards something much more like traditional IT.

SDV also requires faster collaboration. In a traditional flow, based on requirements and deliverables, making a change to a component can take a considerable amount of time as bureaucracy and project planning get in the way. It is not unusual to hear about software fixes taking many months to get delivered. That does not work in an SDV world.

Instead, as illustrated above, a more agile model can be used where a supplier sends a series of deliverables to the customer and gets feedback to guide the next delivery. This is better, but it still suffers from some friction. In the extreme, we might see companies working together in shared source code repositories.

Note that the fact that we are talking about collaboration between companies for SDV applications shows the maturity of SDV. Successful SDV projects used to require vertical integration inside a single OEM, but today SDV systems are being built from components from both commercial vendors and incorporating open-source software.

Indeed, open source is another hot topic in the automotive industry. Several open-source projects aim to build non-differentiating common software bases for the SDV. However, using open-source code in vehicles requires very careful consideration of licenses.

Virtualization

Virtualization for software development and testing is a key supporting technology for SDVs. You cannot depend on hardware rigs for software testing—they are never available in sufficient amounts, or early enough, or flexible enough. Automotive software developers need to be able to run and test code as soon as it is built, and this can only be realized by using virtualization, i.e., by simulating both the computer systems as well as the environment in which it is operating.

VLAB is commonly used to virtualize the ECU hardware for such setups, allowing the target software to run as-is, interacting with a simulation of the vehicle and the world in which it operates. The virtual test rigs complement the physical test rigs, allowing testing at scale without using physical test rigs except for final testing before release.

In addition, it is not uncommon to virtualize a network of ECUs—for example, zonal controllers alongside their geographical control nodes. Or zonal controllers connected to the vehicle's main "HPC" nodes. Or multiple zones. Or an old-school ECU-rich network. Whatever the architecture of the vehicle happens to be.

Virtualization and collaboration also combine nicely with cloud-based development environments. It is much easier to collaborate on software when new software builds can be tested immediately in the same environment as the build—and using pure software virtualization and simulation definitely makes that much easier than relying on physical hardware test rigs sitting in a lab somewhere.

Artificial Intelligence

There were several talks and discussions on how AI is used to implement vehicle features. For example, using AI to create smart adaptive and learning user interfaces, where the vehicle learns the habits and preferences of the driver/user and, as a result, gets more personalized over time.

AI is also playing a huge role in how the industry is implementing autonomous driving. The original idea was to explicitly program rules into the software stack, but that has been replaced by learning approaches—i.e., teaching AI systems how to drive by example.

Finally, AI is a tool for software developers that creates automotive software, everything from standard copilot approaches to methods that create tests from natural-language specifications. Automotive software development can clearly benefit from developments in the "IT" world at large—keeping in mind the safety requirements that are much stronger in automotive and aerospace compared to your average web application.

Unexpected Discoveries

Any good conference will bring up something novel or interesting or unexpected. In this case, my award for "most unexpected technology" goes to tire intelligence. The key idea is that the tires are the only part of the car that touch the road—and as a result, they can tell you a lot about what is going on.

For example, the current actual friction between each tire and the surface is very useful for ABS brakes and other safety features. It can be done without tire-mounted sensors (TMS), but with TMS, much more precision and many more features are possible. Even a simple thing like tracking the total runtime and wear on a tire helps maintain safety (and enable predictive maintenance for fleets). Software is eating the world—and reaching into every corner of the car, including something so obviously physical as tires.

As an aside, a TMS is the epitome of an automotive-grade electronic component. They need to be reliable in extreme cold and heat, and the batteries inside need to last as long as the tire itself. Nobody would accept having to charge the car tires every week… but we can build these things today!

What Can You Do with an API?

Implementing software-defined vehicles typically involves defining various hardware-independent APIs and accompanying middleware solutions. But which APIs should be made available? And how can the fundamental safety of a vehicle be guaranteed and certified when over-the-air updates and app stores add new software to the existing fleet?

As an example, we discussed the concept of a motion API. In theory, such an API could let an app control where the car is going. It would allow new functionality to be delivered as pure software (just like we have physical aftermarket additions today). One obvious application could be an automated parking app—give the app access to cameras and other sensors, and it will take care of parking your car for you. This already exists, but if we use the "car is a smartphone on wheels" analogy, it seems that there is always a market for slightly better versions of standard functions.

A motion API could also be used for more unorthodox purposes. Imagine a novelty app that lets your car follow you as you walk, like a very large puppy. Big fluffy ears and giant bug eyes are included in the package! It could also enable slightly mad applications, such as an app that burns donuts for you autonomously.

Then reality hit—what would an OEM actually allow, and what would they be legally able to allow? The smartphone analogy is quite useful here, too. While applications can make use of the camera and microphone of a phone, access is usually controlled to some extent. However, when it comes to driving the wireless interfaces, applications are only allowed access to very high-level APIs that maintain the correct functionality of the wireless certification on the phone.

On the topic of software updates, it is also worth noting that there must be room for software growth in the hardware. Memory and processing capacity need to be over-provisioned compared to the needs of the release software, and it makes perfect sense to ship a car with sensors that will only be used in later software releases.

Such discussions are part of the fabric and point of conferences.

Learn more about Cadence VLAB and automotive solutions.