Here we present our contributions to prototyping the future automotive cloud as the automotive industry is currently experiencing a challenging transformation:
- a lot of new electric cars are coming into the market;
- autonomous vehicles are on some streets already;
- the consumers are expecting to use digital services in the vehicle as convenient as they are used to it by using mobile phones.
As a consequence of these trends, a lot of customer-facing services will change. These services need to be created and seamlessly integrated, somehow, which heavily depends on infrastructure, connectivity infrastructure, IT infrastructure, in the vehicle, and the cloud.
How the automotive companies are turning into connected mobility providers
Porsche is in the midst of this transformation. The company is changing from a plain sportscar manufacturer devoted to design, into a connected mobility provider. This has a lot of implications. One of these is that the cars for a complete and integrated mobility solution need to be equipped with a set of connected car services; which is very different from driving an old 911 on a race track. To achieve this kind of connectedness, we use cloud technology and especially the concept of an “automotive cloud”. What this means we will explain in this article.
Based on Porsche use case, I would like to show you how we’re working on development in the automotive industry.
In our presentation during CF summit, Matthias Hub from Porsche recalled the famous cf push haiku:
Here is my source code
Run it on the edge and cloud
I do not care how
To tackle this challenge, we decided to start with a small pre-project, completely abstracted from the car to gather input on what an implementation project needs at least to cover. Specifically, we wanted to validate three points:
1. The digital twin concept. We’ve implemented a component called Vehicle Shadow, which is the service responsible for communication, as well as a state synchronization of every single vehicle registered in the platform. Our design was based on the concept of the current and desired state. The vehicle was reporting the current state to the platform, and on the other hand, the platform was trying to change the state in the vehicle to the desired value. Because of that, we were able to open doors remotely or to see the correct vehicle state after it went offline and then back online.
2. A very powerful license concept, we have been thinking of, was created to enable creating licenses fast and with ease, using predefined constraints, like geolocation or a limited number of usages. The ability of automatic synchronization between a vehicle and the cloud ensured that policies are propagated near real-time when the car is connected to the internet.
3. And at last, also to see what requirements are needed from a platform as a service. When you work with Cloud Foundry, you may focus on writing software as the underlying platform will do the rest for you. Furthermore, an event-driven IoT solution requires a resilient platform underneath. Deployment to Cloud Foundry is extremely developer-friendly, and deployment of several decoupled microservices to the cloud was easier than running them on my computer. The platform also leveraged services from the Volkswagen Cloud Foundry marketplace, e.g. for data storage.
We’ve used several technologies to develop such a solution – the state synchronization was implemented on top of the MQTT messaging protocol and stored in MongoDB NoSQL database. The vehicle was mocked using a docker container and within the container, we’ve developed VIWI microservices for controlling specific vehicle functionalities – VIWI as Volkswagen Infotainment Web Interface is a w3c standard on how to use REST within the infotainment. The remote calls were implemented using plain REST with the assumption that future vehicles will be using IPv6.
That project showed that the automotive industry needs to have a reliable IoT platform, unfortunately, there was no platform available at that time that could cover all our requirements including request/response and messaging out of the box. Also, it showed that Cloud Foundry, as a prototyping platform, worked out very well, especially when considering the available services via the marketplace.
After the impressive results from the incubation part, we continued to work on implementing it, especially to bring the system into a real vehicle.
The scope of the project
Digital Twin seems to be an ideal approach in the IoT ecosystem. It’s extensible, as we have integrated it with many vehicle subsystems without any changes in the source code. Additionally, we’ve created query language on top of the existing VIWI protocol in Device Shadow, which helped us to implement many features in our services.
“Subscriptions” is a process of gathering big data, where the cloud is subscribing to events from a vehicle. Based on those events, we can create specific services which e.g. may help the driver to avoid obstacles on the road. It’s worth mentioning that inside the vehicle there are dozens of microservices based on VIWI. Through our platform, service developers are able to subscribe to them transparently.
What were the automotive-specific implications?
The development of technologies built for the automotive industry creates a great challenge in testing, as an interesting question arises – how to test software that is used in a vehicle? I can give you a tip: containerization is the key. In this iteration, we’re focusing on real hardware components applied to the vehicle. Our solution needed to be tested from the start, to have a stable version during the integration window on target hardware. We decided to deploy our vehicle to the cloud to have automated end-to-end tests and in this case, we picked Kubernetes as a platform.
Our platform was utilizing Cloud Foundry and Kubernetes side by side, as both of them are designed for different use cases, e.g. Cloud Foundry is a great application runtime and it’s a superior external services provider through the marketplace. On the other hand, Kubernetes has native containers and persistent volumes support. From the start, we’ve focused on the vehicle’s software limitations, and it helped us to extend the existing IoT platform. One of the first requirements was containerized software for a vehicle. Because of that, it was much easier to create CI/CD pipelines with Concourse on top of CF and Kubernetes. VW Cloud Foundry installation was very useful additionally in terms of providing its marketplace with many services built on top of technologies like MongoDB, S3 or RabbitMQ.
However, the most important idea of this project was to implement an extensible platform able to run in different regions with different communication platforms. Verifying and validating different communication platforms is challenging, as different platforms have different communication protocols and creating unified architecture for that was a bit tricky, but in the end, we were able to provide One Digital Platform to rule them all.
Our solution – automotive cloud
The automotive cloud consists of several layers, including IoT agent and the IoT gateway. This implements the agent and the gateway paradigm in the IoT world, which allows a horizontally scalable solution, up to millions of devices. The platform supports synchronous communication from Gateway to Agent with a resource-based protocol like REST, as well as agent initiated communication implemented by messaging protocol.
Digital Twin component is very important here, which helps with vehicle state synchronization, as well as it simplifies the implementation of services by its abstraction and query language.
As the platform is extensible, we may add new services to the cloud, and they will be as well instantiated on the vehicle’s board. On the other hand, we have also an extensible solution in terms of the geographic area where we want to drive the car. If one communication platform is not available, we can use another, without any changes in the source code of service applications.
On top of that, we have our CI/CD pipelines provided by Concourse, and test framework which ensures the quality and reliability of our platform! We’ve created pipelines for continuous integration and deployment, as well as for end-to-end testing. With that, we’re able to deploy the car to the cloud and test it before installing the software on the real vehicle.
Using Cloud Foundry means also that external services can be consumed in a very elegant manner. Using the Service Broker API, our colleagues from Volkswagen, Audi, and Porsche have built quite some services which can be used in PoC as well as production projects. These services range from databases over legal services to development tools.
One exemplary service provided via Marketplace is Concourse. With every commit to the master branch, it builds the docker image. Here it’s worth mentioning that it may even use specialized base images which may run on vehicle computing units and they differ a lot from regular alpine or ubuntu image! In the next step, the image is pushed to a repository, then we’re creating the device and register it in Microsoft Azure IoT. When a device is registered, the IoT Edge running on the device pulls the latest image and runs it.
Prototyping the Future Automotive Cloud – Sum Up
Platform-as-a-service solutions are more and more popular. Along with various solutions to choose from, it’s hard to decide which one to pick. The good news is that you don’t need to pick just one. As Cloud Foundry and Kubernetes combined are superior and they let us, the developers, focus on features with a way of thinking: “Here is my source code, run it on the edge and cloud, I do not care how”. Also, we should focus on CI/CD from the beginning, especially in such a challenging industry as automotive, as the most valuable product is the one running on the client’s device, in this case – in a car.