The SDV: Why you need Automotive Cloud

In the era of modern connected vehicles, the term Automotive Cloud (AC) is often used. Even more so when we talk about Software Defined Vehicles (SDVs), Automotive Cloud is an essential foundation of SDV architectures. But what is an automotive cloud? A simple answer is: all the backends of the connected vehicle. But the next question is: how many backends do we need, and with what functionality? Of course, people want to know how much it will cost to build and operate. So let’s try to clarify the picture.

Let’s take a step back and look at an old-school, unconnected car: chassis, body, engine with all the powertrain, radio, music, and navigation. How could such a car take advantage of the Internet and connectivity? Perhaps by enriching the navigation with current traffic flow information, or perhaps by extending the search for Points of Interest (POIs) by also providing the driver with relevant updates about specific POIs. So an obvious task for an automotive cloud is to connect the vehicle to the Internet and thus enhance more or less existing in-car functionality.

But what about bringing new functionality – enabled by automotive clouds – into the car? Let’s take a look at predictive maintenance. Typically, we drive to the repair shop when a check light comes on telling us something might be wrong with our car. In contrast, predictive maintenance is the proactive repair or replacement of parts to reduce unexpected breakdowns, minimize downtime and optimize overall vehicle performance. To do this, the vehicle periodically sends telemetry and diagnostic data to the Automotive Cloud, which applies data analytics based on predictive models and processes notifications and alerts.

As we can see, the vehicle consumes the latest Internet data (proxied by AC) to enhance navigation and infotainment capabilities (in-vehicle infotainment – IVI), and the Automotive Cloud consumes vehicle data to enable the predictive maintenance functionality. There are many other useful functions that follow this simple pattern. But things get even more interesting when the Automotive Cloud is opened to the driver, who becomes a digital user. Mobile apps or web portals will be introduced to connect the user with his or her own vehicle, showing the current vehicle status or offering, as mentioned before, predictive repairs. In addition, the user could be offered personalization features in infotainment or navigation, such as remote POI management.

Another simple new feature category introduced by Automotive Clouds is remote control of the vehicle. This can be useful, for example, to configure the independent vehicle heater or to open the car from a remote or mobile device. In this communication pattern, the Automotive Cloud sends commands to the car, but no data or other content. A more sophisticated communication approach is required to enable software updates over the air (OTA updates). The car and the AC must negotiate the need for the update and the digital artifacts actually needed. In addition to command-based communication, scalable and efficient software download repositories are required. This is where things get really complex.

Depending on the type of software or digital artifacts to be updated, extensive release processes are required in the AC/OTA backend, but even more extensive installation processes are required in the vehicle. As updates of module configurations, infotainment applications or AutoEdge services may only require light release and installation processes, OTA updates of the entire vehicle or multiple ECUs are limited by regulations. We will cover OTA updates in detail in a future dedicated blog post.

Finally, we realize that Automotive Clouds require multiple modules and sub-modules, and many of them need to communicate with the vehicle to fulfill a variety of functional and non-functional use cases. Thus, vehicle details of specific ECUs, installed software versions, or any essential capabilities need to be mirrored to the backend of an automotive cloud. Therefore, we introduce the notion of Automotive Cloud Digital Twin (or simplified: Digital Twin), which mirrors all required vehicle information and capabilities to the backend. Such a digital twin could, for example, provide an inventory of static information such as parts lists or vehicle metadata such as model codes, year of manufacture, country of manufacture, etc. Data collection repositories for any kind of telemetry data are also required. Appropriate vehicle capabilities could be exposed by the digital twin to other AC modules. Finally, we can assume that the digital twin provides low-level business communication protocol with the vehicle but exposes high-level API to other AC modules.

Let’s see what we have so far: Internet in the vehicle, digital twin of the vehicle in the AC, OTA pipeline for regular software updates, digital connection to the driver/owner/user. The AC both enables connected vehicles and mirrors the vehicle’s capabilities to the digital world as we have only known it from the workshop (garage). This provides the basis for new and more advanced business models, such as the introduction of shops or marketplaces. Depending on the specific business model and technical deployment, infotainment applications, AutoEdge services, function-on-demand licenses, connected service licenses, etc. can be sold to users. In addition, all the telemetry data provided by the digital twin enables the potential for innovative vehicle data products or B2B business models with insurance companies or other players.

Feel free to read our recent paper „Who owns the Future of Mobility“ (https://valtech-mobility.de/core-topics/software-defined-vehicle/) to learn more detailed facts about the involvement of connected vehicles, autonomous driving, and mobility and transportation as a service (Maas/TaaS). The combination of Digital Twin and OTA updates allows for highly sophisticated approaches such as the so-called Big Loop. Here, digital artifacts such as AI models in the vehicle are continuously updated and improved by telemetry data regularly received via digital twin capabilities. To complete the collection of examples of potential advanced business models, OEMs may open their SDV / AC platforms to third parties, similar to what we are used to from smartphones or smart TVs.

Finally, we could now let go of any limits and recognize that AC is the key enabler to embed smart cars in the current and future digital word of smart home, smart city, beyond mobility. Find your own example of feature you would like to see in a smart car, then you will immediately appreciate the capabilities provided by connected vehicle, digital twin, OTA updates, shops and marketplaces.

In this blog post we have focused purely on business value of Automotive Clouds. In the next part coming soon we are going to highlight challenges and obstacles.