Hi,
I recently read a number of articles about how to offload workloads onto containers that run on vehicles. TheChief IO article here [0] summarizes some of the things tried out there and these are the experiments I've read in detail:
- Mercedes-Benz did a POC [1] where they run containers in a vehicle to run relevant tasks. The focus here is on the development and CI/CD of these software.
- Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster in the vehicle. Again, the focus here is the development ease and CI/CD. Development teams simply develop and distribute software just like a web application. There's also mentions of used concepts like digital twins, request queuing (in the vehicle when offline) and few other interesting concepts.
How do these efforts align or relate with the automotive initiative? What I understand from CentOS automotive SIG and the POCs I mentioned above is that there are a lot of overlapping areas (being independent of the underlying hardware, faster software distribution, etc.) done in different levels (OS/Kube).
Context: I am a Knative (https://knative.dev) contributor at Red Hat. I was thinking about experimenting with Knative Eventing on the far edge, or even better, mentor a Google Summer of Code contributor this summer for that, and later I found out about the experiments done with Kubernetes on vehicles.
[0] https://thechief.io/c/editorial/how-kubernetes-is-shaping-the-future-of-cars... [1] https://customers.microsoft.com/en-us/story/784791-mercedes-benz-r-and-d-cre... [2] https://kubernetes.io/case-studies/denso/ [3] https://www.denso.com/jp/ja/-/media/global/business/innovation/review/25/pap...
On Mon, Mar 7, 2022 at 11:52 PM Ali Ok aliok@redhat.com wrote:
Hi,
I recently read a number of articles about how to offload workloads onto containers that run on vehicles. TheChief IO article here [0] summarizes some of the things tried out there and these are the experiments I've read in detail:
- Mercedes-Benz did a POC [1] where they run containers in a vehicle to
run relevant tasks. The focus here is on the development and CI/CD of these software.
- Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster
in the vehicle. Again, the focus here is the development ease and CI/CD. Development teams simply develop and distribute software just like a web application. There's also mentions of used concepts like digital twins, request queuing (in the vehicle when offline) and few other interesting concepts.
How do these efforts align or relate with the automotive initiative? What I understand from CentOS automotive SIG and the POCs I mentioned above is that there are a lot of overlapping areas (being independent of the underlying hardware, faster software distribution, etc.) done in different levels (OS/Kube).
Some of this aligns well with our current initiative, while the other seems wildly unrealistic to me.
We believe that deploying applications in the car via containers is a good idea for a couple of core reasons:
* More isolation between apps at runtime means more robust, safe, secure software. * Containerized applications can be updated and managed independently of each other and the host os version. * Containerization enforces a development model with strict interface boundaries, similar to what you'd call a "microarchitecture" in the cloud (although not necessarily using the exact same tech). This matches what the expected development model is in the new "Software Defined Vehicle" world. * The abstracted interfaces described above allow containers to run outside of the actual car, using virtualized components for the rest of the car. This is great for doing CI and development in the cloud and on a developers local machine.
Kubernetes is highly valuable in this model both for the CI/dev environment and for running the cloud side of the services required for a network-connected car.
However, running kubernetes itself in the car itself is not a great idea. The requirements that the code running in the vehicle is operating under are very different from the cloud. For functionally safe code like this you must know exactly ahead of time exactly what is running where and when, in a predictable, repeatable fashion, ideally with a minimum of unnecessary code running (as everything has to be validated in a very expensive process). The dynamical nature of kubernetes just isn't a great fit, as well as the high resource requirement and the fact that most of the abstractions it provides wrt multi-node distribution and management just isn't needed.
Our plan is instead to run containers in the car more directly, managed using systemd.
Thanks Alexander. It makes much more sense now.
We believe that deploying applications in the car via containers is a good
idea for a couple of core reasons:
I saw no references to containers on the SIG related pages. Is running containers in the car a stretch goal, or not in the scope of the SIG?
I know it is very early on the project, but I am looking forward to seeing any demos :)
Also, as a side effect, what would be exciting for me as a consumer is, using the smartphone analogy I saw around smart cars, the future where people mod their cars with custom software they buy on an app store. Like you flash ECUs for better HP these days, but with verified software on a button click :)
On Tue, Mar 8, 2022 at 2:11 PM Alexander Larsson alexl@redhat.com wrote:
On Mon, Mar 7, 2022 at 11:52 PM Ali Ok aliok@redhat.com wrote:
Hi,
I recently read a number of articles about how to offload workloads onto containers that run on vehicles. TheChief IO article here [0] summarizes some of the things tried out there and these are the experiments I've read in detail:
- Mercedes-Benz did a POC [1] where they run containers in a vehicle to
run relevant tasks. The focus here is on the development and CI/CD of these software.
- Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster
in the vehicle. Again, the focus here is the development ease and CI/CD. Development teams simply develop and distribute software just like a web application. There's also mentions of used concepts like digital twins, request queuing (in the vehicle when offline) and few other interesting concepts.
How do these efforts align or relate with the automotive initiative? What I understand from CentOS automotive SIG and the POCs I mentioned above is that there are a lot of overlapping areas (being independent of the underlying hardware, faster software distribution, etc.) done in different levels (OS/Kube).
Some of this aligns well with our current initiative, while the other seems wildly unrealistic to me.
We believe that deploying applications in the car via containers is a good idea for a couple of core reasons:
- More isolation between apps at runtime means more robust, safe, secure
software.
- Containerized applications can be updated and managed independently of
each other and the host os version.
- Containerization enforces a development model with strict interface
boundaries, similar to what you'd call a "microarchitecture" in the cloud (although not necessarily using the exact same tech). This matches what the expected development model is in the new "Software Defined Vehicle" world.
- The abstracted interfaces described above allow containers to run
outside of the actual car, using virtualized components for the rest of the car. This is great for doing CI and development in the cloud and on a developers local machine.
Kubernetes is highly valuable in this model both for the CI/dev environment and for running the cloud side of the services required for a network-connected car.
However, running kubernetes itself in the car itself is not a great idea. The requirements that the code running in the vehicle is operating under are very different from the cloud. For functionally safe code like this you must know exactly ahead of time exactly what is running where and when, in a predictable, repeatable fashion, ideally with a minimum of unnecessary code running (as everything has to be validated in a very expensive process). The dynamical nature of kubernetes just isn't a great fit, as well as the high resource requirement and the fact that most of the abstractions it provides wrt multi-node distribution and management just isn't needed.
Our plan is instead to run containers in the car more directly, managed using systemd.
--
Alexander Larsson Red Hat, Inc alexl@redhat.com alexander.larsson@gmail.com _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
Hey Ali!
Thanks for the great insight here, it's something I have thought about myself a number of times. See more inline!
Leigh
On Wed, Mar 9, 2022 at 2:34 PM Ali Ok aliok@redhat.com wrote:
Thanks Alexander. It makes much more sense now.
We believe that deploying applications in the car via containers is a good
idea for a couple of core reasons:
I saw no references to containers on the SIG related pages. Is running containers in the car a stretch goal, or not in the scope of the SIG?
If you check out https://wiki.centos.org/SpecialInterestGroup/Automotive you can read the charter which states the SIG *is meant to be a neutral public space for collaboration between third parties interested in open development of software targeted at in-vehicle automotive use cases. *
To that end, containers running within a car is something that would be a welcome discussion and contribution and I'd love to get experts like you and others engaged!
I know it is very early on the project, but I am looking forward to seeing any demos :)
Also, as a side effect, what would be exciting for me as a consumer is, using the smartphone analogy I saw around smart cars, the future where people mod their cars with custom software they buy on an app store. Like you flash ECUs for better HP these days, but with verified software on a button click :)
On Tue, Mar 8, 2022 at 2:11 PM Alexander Larsson alexl@redhat.com wrote:
On Mon, Mar 7, 2022 at 11:52 PM Ali Ok aliok@redhat.com wrote:
Hi,
I recently read a number of articles about how to offload workloads onto containers that run on vehicles. TheChief IO article here [0] summarizes some of the things tried out there and these are the experiments I've read in detail:
- Mercedes-Benz did a POC [1] where they run containers in a vehicle to
run relevant tasks. The focus here is on the development and CI/CD of these software.
- Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster
in the vehicle. Again, the focus here is the development ease and CI/CD. Development teams simply develop and distribute software just like a web application. There's also mentions of used concepts like digital twins, request queuing (in the vehicle when offline) and few other interesting concepts.
How do these efforts align or relate with the automotive initiative? What I understand from CentOS automotive SIG and the POCs I mentioned above is that there are a lot of overlapping areas (being independent of the underlying hardware, faster software distribution, etc.) done in different levels (OS/Kube).
Some of this aligns well with our current initiative, while the other seems wildly unrealistic to me.
We believe that deploying applications in the car via containers is a good idea for a couple of core reasons:
- More isolation between apps at runtime means more robust, safe, secure
software.
- Containerized applications can be updated and managed independently of
each other and the host os version.
- Containerization enforces a development model with strict interface
boundaries, similar to what you'd call a "microarchitecture" in the cloud (although not necessarily using the exact same tech). This matches what the expected development model is in the new "Software Defined Vehicle" world.
- The abstracted interfaces described above allow containers to run
outside of the actual car, using virtualized components for the rest of the car. This is great for doing CI and development in the cloud and on a developers local machine.
Kubernetes is highly valuable in this model both for the CI/dev environment and for running the cloud side of the services required for a network-connected car.
However, running kubernetes itself in the car itself is not a great idea. The requirements that the code running in the vehicle is operating under are very different from the cloud. For functionally safe code like this you must know exactly ahead of time exactly what is running where and when, in a predictable, repeatable fashion, ideally with a minimum of unnecessary code running (as everything has to be validated in a very expensive process). The dynamical nature of kubernetes just isn't a great fit, as well as the high resource requirement and the fact that most of the abstractions it provides wrt multi-node distribution and management just isn't needed.
Our plan is instead to run containers in the car more directly, managed using systemd.
--
Alexander Larsson Red Hat, Inc alexl@redhat.com alexander.larsson@gmail.com _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
On Wed, Mar 9, 2022 at 3:34 PM Ali Ok aliok@redhat.com wrote:
Thanks Alexander. It makes much more sense now.
We believe that deploying applications in the car via containers is a good
idea for a couple of core reasons:
I saw no references to containers on the SIG related pages. Is running containers in the car a stretch goal, or not in the scope of the SIG?
There are some docs on it here: https://sigs.centos.org/automotive/building/containers/
Although I hope to extend the examples soon to be more automotive related.
automotive-sig@lists.centos.org