Red Hat OpenShift Automotive 2022 OpenShift Commons Gathering, 6 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Eclipse Software Defined Vehicle:Building the Future of Automotive Michael Plagge Eclipse Foundation

Description

Eclipse Software Defined Vehicle: Building the Future of Automotive Together
Michael Plagge (Eclipse Foundation) | Daniel Krippner (Bosch) | Ansgar Lindwedel (Bosch) | Daniel Lueddecke (Microsoft) | Harald Ruckriegel (Red Hat)
OpenShift Commons Gathering on Automotive
April 6th 2022

full agenda here: https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_Automotive.html

A

Softly defined vehicle. What is this all about? I think software defined vehicle may be the latest addition to the set of software driven or automotive, driven open source projects, and the question is: why would you have something like a new initiative, and I think the idea here is that we at least try and that we think that we do a couple of things differently.

A

um First of all, let me give a short glimpse into the timeline of the software defined vehicle we started about, or six months ago we initially announced that we would plan to set up such working group back in end of october last year and then, within four months. We we collected an initial group of members who wanted to drive this initiative, and the first official string committee meeting took place on march 3rd.

A

So that means we are couple more or less up and running for one month and we see an enormous interest and, as uh we are more than happy- and I would like to say thank you to reddap to give the um us the opportunity to introduce software defined vehicle to a broader audience today. So what is different from other initiatives? You may be aware in the in the space of automotive.

A

um I think one of the very first things we discussed in the community is: how do we want to collaborate, so software defined vehicle at the current stage is more about how to collaborate than that. We talk about on what topics do we collaborate for sure? We have an idea of the scope, it should be automotive, it should be major parts of the automotive software stack, but for now the main main main main topic here is how how to work together and why we discussed we identified four gov five governance principles.

A

We would like to follow with this kind of collaboration and three out of these five governance. Principles are standard principles of the eclipse foundation, and these are transparency, openness and vendor neutrality. So, starting with openness, everyone can contribute. Everyone would like to join the software defined vehicle and is willing to follow. The government's rule set of the eclipse foundation is invited to join our activities around software defined vehicle transparency for open source foundation means we will have everything out in the open. So there will be no decisions behind closed doors.

A

um Everything will be documented, so for each and everyone what's like to contribute, uh you guys always see the the full transparency of what's ongoing. In that initiative and the third governance principle coming from the clips foundation contributed by the eclipse foundation, the vendor neutrality, I think in an open source setup, especially in automotive, where there are, let's say, various very strong players of different size from coming from different industries.

A

Nowadays, it's very important to find a field of level playing field where different organizations can make sure that no one is dominating the initiative. No one has more power than the others. um Just to give an example for each and every project, which will we see at the uh at the at the software defined vehicle initiative, trademarks will be owned by the eclipse foundation. Why is that the case? Because the trademark is an important asset for a project or for a working group?

A

So if one partner of that initiative would own the trademarks he would have more power than others, and so based on the vendor neutrality, um this trademark will be filed by the eclipse foundation, so no vendor no participant has more power than the others.

A

Next to this one, uh we clearly defined um and that's not clips foundation specific, but this is really software defined vehicle vehicle-specific.

A

We decided to follow a code-first approach and I will elaborate a little bit on the next slide. What we understand with the code first- and this may be the biggest differentiator to other initiatives out there and how why this is the case. I I I will explain on the next slide and the fifth principle is active participation.

A

I think we saw in the past couple of automotive initiatives where organizations join just out of a fear of missing out idea. I think that's not necessary for software defined vehicle because we are transparent. We are open. So everyone can. I regularly always watch what happens initiative, there's no real reason to join. If you do not plan to actively participate into the activities, we are currently planning to do at the software defined vehicle working group.

A

So what is this all about working group? As you can see, we cannot come up today with an fully blown architecture, diagram of the things we would like to do, and it's not even 100 clear what will be the finally all the domains and the scope which we plan to cover the software defined vehicle, and the main reason has already stated is that we plan to have a code first approach, so software defined vehicle will not be a specification activity.

A

So it's not that we define initially a domain and then try to cover this domain by 100 with specification. We- and I would call this a top-down approach so sitting together for two years to define the specification to agree on the specification.

A

We try to follow a different approach and our approach is code first, so we expect the next couple of weeks code, contribution, project contributions by various different organizations or regular calls with very organization which wants to contribute code to this initiative.

A

That's the first point. So we try to start with real software and see how we can combine these different software projects and artifacts into a meaningful stack, and if there is a gap, we need to identify this gap and need to see how we can fill this gap. If there are, let's say the need for specification between different comp software components, this working, who will do this specification or, let's say, define abstract apis, but it's not starting from a specification perspective.

A

A second differentiator is that we are not necessarily built around consensus. So if you look, what specification activities or other software activities have been done in the past was always to define these deck. I'm quite convinced that the software defined vehicle working group. We will not see the one and only software defined vehicle software stack. I more believe that or when we discuss internally, which or in the in the community.

A

It's more that we discuss about the concept of distributions, so we can imagine to have competing software components and competition is good for innovation and other purposes sometimes, and and that then, if you would need to have a full stack that the the parties would need, the stack can decide which software component from a different specific domain should be chosen and to be added to the distribution.

A

So we think about a stack as an distribution where, for one and for one specific person there could be a software component, a or software component b in that distribution. So there's no necessarily the need to build um um consensus, and this is one very interesting aspect.

A

I think I have been now in automotive for about 20 years, and I saw a lot of initiatives failing because um an organization or initial set of organizations defined a fully qualified software stack or fully qual, qualified setup and other organizations say hey, that's not what I want to do so I don't want to join, because I don't see place for my ideas to realize that initiative and with software defined vehicle there's a different approach.

A

So we are open for this kind of competition, so we are welcoming each and every kind of software contributions uh in the future, so working groups, what are they about? The software defined vehicle is initially working. Group and working groups are about vending neutral governance. I already worked a little bit on this one ecosystem, development, marketing that what we are doing today and we will do much more in the future.

A

Well, as I said, we are just one more month down the road, but that's really to build the ecosystem and build um and and convince other organizations to join because at the end software defined vehicle. We only be successful if we would be able to win as much players from the industry to support this initiative.

A

Then it's about um collaboration management. That's really how we set up the different working streams, with this code. First idea in mind to get the things together to finally be able to deliver a software solutions, end-to-end solutions for the problem, um which should be addressed within software-defined vehicle um specification development. As I said, I'm quite sure um we are not specification driven initially, but we will have the need for developing specifications defining abstraction layers between different software layers, and this will be done in the working group and for sure branding on compatibility.

A

So if we add a little bit more down the road, if software components are there, then having a branding for the software component, this will be one part of the of the activities we plan to do.

A

But now you could say wait he talked about code, for this is hardly anything has to do with the code and that's true. The working group itself will not deal with soft uh with resource code itself. So that's the eclipse foundation. We have two different vehicles to do something I think the one I just described working groups and then we have projects and projects are the vehicle, the organizational structure where software's really developed. So what we plan right now with our code first approach is to onboard projects and projects are initially independent from workings.

A

What projects can associate with working groups and working groups then can crush project?

A

um Do some sort of cross project alignment so aligning on feature set on aligning on time schedules and that what the working group is about at the same time, the projects, then are, let's say, independent uh development structures at the eclipse foundation and what we currently do now after after we have set up the working group, we discussed with the various organizations which want to contribute code to the software defined vehicle initiative and projects, plus the working group at the end of the day, will define what what will happen in the software defined vehicle setup.

A

Coming to my final slide deck. It's quite interesting to see. That's the members who already enrolled to software defined vehicle working group by march 31st, and that means one week ago we have at least a couple of discussions with more members, and I see we will see a much bigger group of organizations which have joined in four weeks from now, as you can see, there's one logo missing, that's continental and it's interesting to see.

A

We started to subscribe from membership by march uh by february, 2nd and all of these members were able to do the paperwork. um One of the issues we have with couple of these very big organizations to discuss about logo, usage policies and that's the fact why the county logo is not showing up here. We will so we will sort this house quite soon and then we will also have the conti logo here, but I think we have an interesting set of of of of tier ones, with uh bosch, zeref and conji.

A

With software very software experienced organizations like like, like microsoft, red hat and suse. We have hardware manufacturers like like arm and nxp. We have service organizations like capgemini and accenture and dmi.

A

So I think, as of today, we already have a good mixture of different organizations with different backgrounds, different knowledge which would like to support and cooperate in the software defined vehicle group, and we would see a lot of more members joining the next weeks and now I've come to end with my presentation and would like to invite the my colleagues from the community to may share their view on software defined vehicle and first experiences from their talk with others after the first four to six weeks live.

A

So ansca or daniel.

B

Yeah, then, let me have a start uh um thanks. First of all, michael so we've been uh having our little fun uh on the backstage already that you're doing the work for all of us and presenting that. uh Thank you very much, and thanks harad for for having us on your comments. um So um yeah as as you mentioned, michael uh um what we've been discussing, uh I think two weeks ago um beside what is part of the uh working group or what is part of the projects I think already have or nisha.

B

I mentioned a little things on their slides already, so we are looking at three major parts which you can also check. If you want to read through our charter, one is, we are looking at technology on the edge side. The other is. We are looking at technology on the cloud side and then the most important thing from from at least my perspective is we're looking at making the developers life easier in the future. That's also the perspective. What what bosh? From our perspective we want to solve our own problems, making the developers life easier.

B

um One important thing from my point of view is- uh and you mentioned that already, but I want to underline that when we've been sitting, I think two weeks back in the first steering community meeting. We all agreed that everything what we want to do is about technology for sure, but to make it happen, it's mainly about people, it's mainly about trust, and it's mainly about doing things together.

B

Even though maybe we are in a competition um and that's an important thing which we want to shape and therefore yeah, we are happy to see many more logos when we, when we are going to talk next time about the initiative and obviously also see first projects code and and technical scope as well.

C

Yeah, maybe I can add something from from our and my personal perspective there as well.

C

I mean, I think, it's pretty obvious, that we all live in a world of limited resources and limited time right, um which basically means that, unless somebody finds a jar of unlimited resources at the end of some rainbow or invent a time machine, we pretty much are stuck to the problem of that.

C

We cannot solve every problem on our own on time, which is kind of the very initial fundamental thinking of why we actually have a strong belief in that the especially the open source approach that we chose for the software defined vehicle and all the solutions that need to be built to to. Basically, um you know work on all these challenges.

C

The the open source approach is pretty much exactly that thinking, because there are so many things where we believe that it is kind of uh there is no need in terms of differentiate on very low level technology pieces. So why not solving that kind of challenges for once in that industry and then comes the limited resources and time problems. So nobody can do that on their own, so why not bring everybody together and solve these challenges for sure this is nothing easy.

C

I mean it sounds easy when you tell that and talk about that, um but it's for sure not. So there is quite some work already ongoing with respect to scope and first contributions where we see exactly that kind of non-differentiating problems to be solved, and then you have a little bit of echoing from you if you could go and mute again. Thank you um and one one thing. I would like to add and then hand it happily over to the group.

C

Again I mean it is for sure about solving technology problems, especially solving them in the code in a code. First approach as michael was sharing.

C

What I also see in sense, though, is that a couple of players, if not the majority of players in the automotive industry, is actually asking for help in terms of please help us to become a more software driven company and if you take basically the sense of collaboration in the open source space, you have a pretty huge portion of the answer on how to become a software driven company so that the kind of working in that environment, also for oems and tier ones, and so on, in that open source environment will ultimately enable them to become a more software-driven company, which is kind of a nice side effect.

C

If you want so where you can see that it's not just about technology, but also about the whole transformational thing that is going on. For I don't know how many years in the industry.

D

Yeah, perhaps also an um additional thought so so daniel. I I I like your comments upon reuse and I think also um it's a true sign that together we are stronger and that's our approach here, and I think this is. This is exactly the approach of eclipse software-defined vehicle initiative for uh open collaboration there and um from from from our redhead perspective.

D

This is the right approach, because we we are believing that innovation happens in open collaboration with standardization and also based uh also upon open source, and um I think I think this is very important in in our initiative that we want to focus to implementation, but the reuse of implementation from an open source perspective, and I think, with with our true partner um eclipse there uh providing this initiative.

D

This makes absolutely sense. Yeah.

E

And maybe I can also so not just a pretty face right, so I can also add maybe a couple of thoughts here, one maybe also a another aspect of what was what daniel was already um saying.

E

What I think is kind of indicative and interesting right now and for the last one or two years, maybe, and this entire software-defined vehicle idea. Let's say you know and then target vision, whatever the details are going to be, but this has been in the air now, for you know for quite some time and a lot of a lot of organizations and a lot of communities are forming around that idea. So I believe this is whatever these specific ideas are going to be.

E

But it's it's something that the time has come for right and uh we are not the only ones out there. Obviously so, and everybody here or most of the people in the call probably have heard and seen, for example, the sophie the arm initiative and there's also established players out there, like the kumisa, guys, etc.

E

um We all know about each other. um We are tentatively beginning to talk to each other, and so I guess beyond the challenges that um you know and daniel etc, you have been already bringing up the problem that I want to get to is that we have so many building blocks and pieces on the table that we, you know, need to begin to integrate them and make them work usefully together. If we get there, that's a good place to be, and that's where we need to get to in the next one or two years.

E

So I hope we can get that going together, but fingers crossed with all of these kind of partners and the motivation that's going around the industry right now. I think we can get something going.

A

I think that's a very important point. This is not about reinventing the wheel right, it's not about do stuff, which other organizations already did. I think here the the more important approach from my perspective would try to get in contact with this organization. Try to overcome perhaps formal issues that maybe specifications are only available to members of these organizations, and we will really follow an open source approach where everyone would be entitled to use results of what we are doing.

A

But I think um a couple of these initiatives already are quite let's say I would not say old, but let's say 10 years on the road 15 years on the road, and maybe now it's time also for them to to rethink the approach which may have been appropriate when they set up their governance and other structures. 15 years ago, 10 years ago, that's still appropriate.

A

I think we see the at the uh at the moment an enormous shift in in how things are done in the automotive industry and nisha, and harold already introduced this in in the initial presentation and the question for the automotive industry how to deal with this right and one other aspect. I think daniel luedek already mentioned that um there's a shortage on on developers.

A

Another aspect would be a scale right, so it does not help if each and every oem has its own solution, because if we talk about at the end features which are experienceable to the car buyer, there may also have the need for third-party components, and I can't see any third-party service suppliers who would be interested to maintain a version for one oem and the second oem at the search oem.

A

So having a certain scale at a platform for in the non-differentiating parts, may be key for the success for the automotive industry to um yet to still keep the access to the to the end customer because, again, um music streaming, I don't see that vw will operate a music streaming service.

A

I don't see that any other oem will operate a music streaming server so, but still they would need some sort of music streaming service in the car right, because, if talk about autonomous driving, there may be more and more time where the passengers will be want to be entertained in the car. So how to get now.

A

This service and music stream is just an example into the car without losing access to the to the end customer and having a platform of significant size could make such an approach interesting for third parties, and if that platform is let's say, an open source platform which is current, which is developed by the community. Then then yeah. So everyone could contribute from from this kind of of setup.

D

So so, thanks for that, uh michael and I I see we, we got a very interesting question from the audience. Thanks for that- and you can put your questions here also on on the chat for us. The question is: how is eclipse approaching and engaging engaging automotive oems as part of a software-defined vehicle working groups? What are some of the interesting challenges you've seen in bridging them into the project? Perhaps.

A

That's that's very interesting. I could elaborate for this for hours, but I think we don't have so much time, but one of the very interesting things here.

A

I heard quite often that automotive software, that automotive campers, cannot develop software and, I would clearly say that's not true: we have million of cars on the road with safety, critical software, the steering systems, the braking systems, and you hardly hear any news there. These systems has failed, so the focus for the automotive software in the past years was very much about a safety and- and so they make the tremendous job right.

A

Nobody go sits into the car, gets into the car and says: I'm not sure if my software is working so nobody's concerned entering a car, even the huge amount of software inside the car, but the focus safety has become more and more hygienic factor. So previously, 10 years ago, you could sell a car which five stars ncap ranking. Nowadays you cannot sell a car without five stars, ncip ranking, so safety has become something which is hygienic factor. If your car is not safe, you cannot um sell it.

A

So it's not any longer differentiator, because each car, which has would want to have a chance to be sold, needs to have a five-star ranking in the ncip test. Just to give an example. So that means in the past software at the kawam has to be safe, secure on time feature complete.

A

It still has to be safe, but with over the air update, we have a huge, a big shift in technologies and with over-the-air update you can get rid of um of of on time and future complete, but oem still think in the dimension of on time and feature complete, which is a little bit, um something which comes from the past but which needs to be overcome, and I think in the future we'll see more and more manufacturers.

A

We will not have a 100 percent feature complete system uh in the beginning, but they will maybe start with 50 feature and then will time by time by updates um will will extend the set of features, and you see how this happening right. Tesla is one example.

A

Volkswagen with the id cards is a second example so having this kind of additional features, a digital value for the customer and maybe even all the bug, fixing and that's something which will which will be a game changer and but the oems just start to understand this and to dig into this, at least from my understanding and and they're, still very much um uh addicted to this old way of doing software and having this new way of doing software, where you can may update your features via the over the update, that's something which still needs to get more spread, and I think software defined vehicles which exactly um something which enables this new trend of having these chances over the update and deploy a new function and new features to the car.

A

And so we have discussions. We had discussions, we have discussion with oems and I'm quite convinced that we see first representative of oem's onboarding software defined vehicle the next weeks. But this is a longer story. I think there's a lot of interest, but I think the oems will, especially in the beginning, look who will contribute code and what will happen in the first month is as soon as we have significant code contributions.

A

I think this initiative will be very relevant relevant for for oems as well.

D

And if we have some oems here in the audience, you're welcome to join the eclipse software defined vehicle and please contact michael plucker. For that. We are very happy about the collaboration.

A

But but but anska don't just raise that question right. You want discussions with oems as well and without providing names. What is what is your your your feedback? You get if you talk about software defined vehicle.

B

So I'm completely relating to to what you have been saying: okay, uh there's one dimension more besides the fact that uh all of the rams- and it's including the tier ones.

B

So it's true for us as well, so we've been very much dedicated on developing safe software, obviously because everything what we have been running as software has been running in safety critical systems, so it's important, but on the other hand, side we've been also implementing software functions in a safe context in the past, simply because we had no other idea where to do it, which maybe doesn't mandatory need to be safe, which is maybe from a functional safety perspective, a qm function and that's also something which, from my point of view in the future uh future e2 architectures.

B

Some of them already today, uh will enable us to more focus on developing qm software in a qm context and therefore also get rid of many of the overwhelming processes we have and everybody has to fulfill solving daniel's problem as well in terms of resources. So software developers can maybe focus more on developing software innovations instead of generating documentations, which we need for the final safety release.

B

Then, in the end- and that's from my point of view, the second big thing which we are currently looking into, which will change the way software developers are going to software, develop application software for vehicles in the future.

C

Maybe to add one thing there real quick, I mean whenever we are talking to oems from a microsoft perspective, I mean we can clearly sense that there is.

C

There starts to be a certain appreciation for the approach, especially the open source approach, um because, as of today, an oem could either decide on doing something on their own hire x thousand people and trying to solve all the software problems and a car oem might have or go for a full vendor log in with anybody of that of the tier industry, and obviously they are doing they are having a hard time to deciding on either of that options right.

C

So choosing that more collaborative way, and especially than again in the open source room kind of enables them to take. What is there in terms of reusing that which is kind of kind of buying, but not actually buying, but at the same time giving giving them a stage on where they can actually contribute and when, where they can somehow you know, live there, I wanna make and do something on my own life. So so this is kind of the nice um another nice side effect.

C

If you want so of that collaboration model, which again I see, I see a starting appreciation at various oems actually.

D

So thanks for the great discussion and very excited about the eclipse, software-defined vehicle and also to our audience, please join it's about active participation. Please contact us if you're interested and colleagues. Thank you very much for your time for the great discussion here looking forward to work very tightly with you together. Thanks for that.

C