The right way: the automotive platform of the future must be built based on existing components. However, two obstacles stand in the way of automotive OEMs on their journey towards the software-defined car. One is proprietary approaches, the other is a gap in the platform. What needs to be done?
In these times of digitization, drivers also want to be able to use their individual service ecosystems in their cars - as seamlessly as possible. And that was the quintessence of our last article. The maximum amount of effort needed to provide apps in the car should be the touch of a button, and that's only if they are not directly integrated into the in-car platform. Typical services that are already being delivered today, basically as accessories, are entertainment services such as Spotify and Parkinfo. But they are the exceptions. The vast majority of apps that exist outside of the vehicle environment are residents of the internet. Which of course means they also play by the rules that apply there, such as continuous innovation, integration, delivery, and deployment. Weekly, and sometimes daily updates and extensions of the system through agile approaches - that doesn't really fit in with the rather long development cycles of cars. So if we try to combine app ecosystems and cars, we get into a systemic imbalance.
However, speed also plays a decisive role for vehicle manufacturers - and I'm not talking about the top speed of a car here, but the speed with which products and digital services make it onto the market. It's obvious that automotive OEMs can also benefit from the app culture for their "go-to-market".
The connected car platform of the future will play a decisive role here. It is based on some mature components that are already available, but some extras are still needed for it to fit into the software-defined era.
Existing components include the connected car services themselves as well as external devices. In addition to users' smartphones, these can be other connected things such as electric charging columns or connections to the smart home. Furthermore, this also includes the automotive fleet of an OEM with its respective in-vehicle platforms and the cloud backend - usually based on industry-agnostic IaaS and PaaS solutions of the hyperscalers. Mobile connectivity is another core component, and the telco edge as an optional component. This is a must for critical services nowadays, but in the future it will also be used for optional services, in order to give drivers an improved user experience.
However, at the heart of these components - between industry-agnostic PaaS and in-car services - is a gap that determines the success of the automotive platform. And so far, hyperscalers have only been able to close this gap to a limited extent. Here, the agile app world and the proprietary electric/electronic automotive world eye one another critically. The solution to this situation is a kind of negotiator between the two sides: an automotive PaaS. This additional component is the centerpiece that requires a powerful connected car platform. The automotive PaaS uses established standards of the app world to bring services into the car quickly.
Until now, vehicle manufacturers have relied on their own standards for the provision of apps in cars. However, this approach does not increase the attractiveness for apps. App developers are at home in the standards of the internet and the cloud. And they will not develop twice based on different standards for what is, when compared with the gigantic internet world, a small IoT end device world for cars. This means that if car manufacturers want their vehicles or in-vehicle platforms to allow easy and fast access to the world of apps, they must comply with the current standards of the app world.
The automotive PaaS does just that: It opens the car door for app developers and thus promotes the app culture "on board". It provides app developers with all the tools they need within the framework of a library, so that they can make their apps automotive-specific with minimal effort. To put it in a nutshell: It's not worth reinventing the wheel; it's better instead to get on the moving internet train. This is the fastest means of transport when it comes to bridging the gap between car and app. And the standardized platform not only benefits external developers, but also helps to develop car-specific apps. These include typical native vehicle features such as monitoring, public key infrastructure (PKI), digital twins or over-the-air functionality. A platform for everyone, with which the consistent orientation towards driver benefits can be realized, which avoids a vendor lock-in, and which also serves all regional markets.
This realization shouldn't actually be anything new: Established industry standards have proven their value in the past by avoiding unnecessary effort, by reducing costs and by leading to finished products faster. The added value for the driver is not created at platform level, but rather in the services that are offered. Why the automotive industry had to relearn this lesson in the software-defined era is not really clear to me.
One challenge remains: How to make the leap from a proprietary platform to a new standardized platform? This is only possible if the existing proprietary platform is carefully transformed in the direction of a standardized platform. And this is precisely what will become another challenging task in the coming years – if OEMs follow the outlined path. Adjustments during ongoing operations have always been unpopular. However, this creates the basis for ensuring the car can be managed consistently over many years - and it "knows what drivers want". It also enables OEMs to meet these requirements quickly and efficiently. And this could be a differentiating feature in the app era to come.
At the same time, the unified platform offers another advantage that should not be underestimated – which relates to the operation of the vehicle fleet. The services provided via the automobile development platform also benefit the Vehicle Operation Center (VOC). The VOC enables central monitoring and control of the entire vehicle fleet. The VOC allows the OEM to optimize the fleet during operation, for example via over-the-air updates, and to bundle the information that is returned. Linking development and operation - this concept is not new either: We are talking about a kind of DevOps for consistent, worldwide fleet management.
Enriched with these three components as well as a future-proof solution for connectivity that is convincing in all of the respective markets, both technically and commercially, the connected car platform should represent the future. Well, as far as we can foresee today. But not even Nick Marshall can help us look into the future.