 software-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. First of all, let me give a short glimpse into the timeline of the software-defined vehicle. We started about six months ago. We initially announced that we would plan to set up such a working group back in end of October last year. And then within four months, 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. So that means we are more or less up and running for one month. And we see an enormous interest. And we are more than happy. And I would like to say thank you to Red App to give 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 space of automotive? 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 if 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 topic here is how to work together. And while we discussed, we identified five governance principles we would like to follow with this kind of collaboration. And three 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 ruleset of the Eclipse Foundation is invited to join our activities around software-defined vehicle. Transparency for the Open Source Foundation means we will have everything out in the open. So there will be no decisions behind closed doors. Everything will be documented. So for each and everyone, what's like to contribute has always the full transparency of what's ongoing in that initiative. And the third governance principle coming from the Eclipse Foundation, contributed by the Eclipse Foundation, is 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 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. Just to give an example for each and every project which will we see 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. So if one partner of that initiative would own the trademarks, you would have more power than others. And so based on the vendor neutrality, this trademark will be filed by the Eclipse Foundation. So no vendor, no participant has more power than the others. Next to this one, we clearly defined, and that's not Eclipse Foundation specific, but this is really software-defined vehicle specific. 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 why this is the case, I will explain on the next slide. And the fifth principle is active participation. I think we saw in the past a couple of automotive initiatives where organizations join just out of here of missing out idea. I think that's not necessary for software-defined vehicle because we are transparent, we are open so everyone can regularly and 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. So what is this all about working group? As you can see, we cannot come up today with a fully blown architecture diagram of the things we would like to do. And it's not even 100% clear what will be the finding all the domains and the scope which we plan to cover the software-defined vehicle. And the main reason, as I already stated, is that we plan to have a code first approach. So software-defined vehicle will not be a specification activity. So it's not that we define initially a domain and then try to cover this domain by 100% with specification. And I would call this a top-down approach or sitting together for two years to define the specification, to agree on the specification. 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 have regular calls with organization which wants to contribute code to this initiative. 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's 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 software components, this working group will do the specification or let's say define abstract APIs, but it's not starting from a specification perspective. 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 the stack. I'm quite convinced that at 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 are in the community, it's more that we discussed 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 that then if you need to have a full stack that 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. So we think about a stack as a distribution where 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 consensus. And this is one very interesting aspect. I think I have been now an automotive for about 20 years and I saw a lot of initiatives failing because an organization or initial set of organization defined a fully qualified software stack or fully 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. So we are open for this kind of competition. So we are welcoming each and every kind of software contributions in the future. So working groups, what are they about? The software defined vehicle is initially working group and working groups about vendor 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. As I said, we are just one month down the road but that's really to build the ecosystem and build 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. Then it's about 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 software solutions end to end solutions for the problem which should be addressed with the software defined vehicle. Specification development, as I said, I'm quite sure. We are not specification driven initially but we will have the need for developing specifications, defining abstraction layers between different software layers. This will be done in the working group and for sure branding and compatibility. So if we had a little bit more down the road if software component are there then having a branding for the software component this will be one part of the activities we plan to do. But now you could say, wait, he talked about code for it. This is hardly anything has to do with the code and that's true. The working group itself will not deal with resource code itself. So that's the Clips 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 is really developed. So what we plan right now with our code first approach is to onboard projects and projects are initially independent from working groups what projects can associate with working groups and working groups then can cross project, do some sort of cross project alignment. So aligning on feature set, aligning on time schedules and then what the working group is about. At the same time, the projects then are, let's say independent development structures at the Clips Foundation. And what we currently do now 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 will happen in the software defined vehicle setup. Coming to my final slide deck, it's quite interesting to see that's the members who are ready and rolled to the 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, we started to subscribe from membership by February 2nd and all of these members were able to do the paperwork. One of the issues we have was a couple of these very big organizations to discuss about logo usage policies and that's the fact why the Conti logo is not showing up here. We will sort this out quite soon and then we will all have the Conti logo here. But I think we have an interesting set of tier ones with Bosch, ZF and Conti with software, very soft experience organizations like Microsoft, Red Hat and SUSE. We have hardware manufacturers like ARM and NXP we have service organizations like Capgemini and Accenture and DMI. 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 will see a lot of more members joining the next weeks. And now I come to end with my presentation and would like to invite my colleagues from the community to may share their view on software defined vehicle and first experiences from that talk with others after the first four to six weeks life. So Ansgar or Daniel? Yeah, then let me have a start. Thanks first of all Michael. So we've been having our little fun on the backstage already that you're doing the work for all of us and preventing that. Thank you very much. And thanks Harald for having us on your comments. So yeah, as you mentioned Michael, what we've been discussing I think two weeks ago beside what is part of the working group or what is part of the projects I think already Harald mentioned or Nisha mentioned a little things on bare slides already. So we're looking at three major parts which you can also check if you wanna 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 at least my perspective is we are looking at making the developers life easier in the future. That's also the perspective what Bosch from our perspective we want to solve our own problems making the developers life easier. One important thing from my point of view is and you mentioned that already but I want to underline that, Michaë. When we've been sitting I think two weeks back in the first day of community meeting we all agreed that everything what we wanna 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 even though maybe we are in a competition. And that's an important thing which we wanna shape and therefore we are happy to see many more logos when we are going to talk next time about the initiative and obviously also see first project code and technical scope as well. Yeah, maybe I can add something from our and my personal perspective there as well. I think it's pretty obvious that we all live in a world of limited resources and limited time, right? 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 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 basically work on all these challenges. The open source approach is pretty much exactly that thinking because there are so many things where we believe that it is kind of 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 problem. So nobody can do that on their own. So why not bring everybody together and solve these challenges? For sure, this is nothing easy. I mean, it sounds easy when you tell that and talk about that, 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. Daniel, we have a little bit of echoing from you if you could go on mute again. Thank you. And one thing I would like to add and then I'll hand it happily over to the group 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. What I also see and 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 essence 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 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 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. Yeah, perhaps also an additional thought. So Daniel, I like your comments upon reuse and I think also it's a true sign that together we are stronger and that's our approach here. And I think this is exactly the approach of Eclipse Software Define Vehicle Initiative for open collaboration there. And from our redhead perspective, this is the right approach because we are believing that innovation happens in open collaboration with standardization and also based also upon open source. And I think this is very important in our initiative that we want to focus to implementation but the reuse of implementation from an open source perspective. And I think with our true partner Eclipse there providing this initiative, this makes absolutely sense. And maybe I can also, so then not just a pretty face, right? So I can also add maybe a couple of thoughts here. One maybe also another aspect of what Daniel was already saying 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 in target vision, whatever the details are going to be, but this has been in the air now for quite some time and a lot of organizations and a lot of communities are forming around that idea. So I believe this is whatever the specific ideas are gonna be, but it's something that the time has come for, right? And we are not the only ones out there obviously. So everybody here, most of the people in the crowd probably have heard and seen, for example, the SOFI, the ARM initiative and there's also established players out there like the Kulisa guys, et cetera. We all know about each other. We are tentatively in beginning to talk to each other. And so I guess beyond the challenges that Ansgar and Daniel, et cetera, 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 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. 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. 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 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. But I think a couple of these initiatives are already 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 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. I think we see at the moment an enormous shift in how things are done in the automotive industry and Nyshal and Herot already introduced this in the initial presentation. And the question for the automotive industry how to deal with it, right? And one other aspect, I think Daniel Nudek already mentioned that there's shortage on developers. 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 experienced with 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 and the third OEM. So having a certain scale at a platform in the non differentiating parts may be key for the success for the automotive industry to still keep the access to the end custom because again, music streaming, I don't see that VW will operate a music streaming service. I don't see that any other OEM will operate a music streaming service. But still they would need some sort of music streaming service in the car, right? Because we've talked about autonomous driving, there may be more and more time where the passengers will want to be entertained in the car. So how to get now this service and music streaming is just an example into the car without losing access 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 developed by the community, then yeah, so everyone could contribute from this kind of setup. So thanks for that, Michael. And I see we got a very interesting question from the audience, thanks for that. And you can put your questions here also on the chat for us. The question is, how is Eclipse approaching and 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. 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, I heard quite often that automotive software, that automotive capabilities cannot develop software. And I would clearly say that's not true. We have a million of cars on the road with safety critical software, the steering systems, the braking systems. And you hardly hear any news that these systems has failed. So the focus for the automotive software on the past year was very much about safety. And so they make a tremendous job, right? Nobody sits into the car, gets into the car and says, mm, I'm not sure if my software is working. So nobody's concerned entering a car even with a 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 with five stars NCAP ranking. Nowadays, you cannot sell a car without five stars NCAP ranking. So safety has become something which is hygienic factor. If your car is not safe, you cannot sell it. 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 of the NCAP test just to give an example. So that means in the past software, the car has to be safe, secure, on time, feature complete. It still has to be safe. But with over the air update, we have a huge big shift in technologies. And with over the air update, you can get rid of on time and feature complete. But OEM still sink in the dimension of on time and feature complete, which is a little bit 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 will not have a hundred percent feature, a complete system in the beginning, but they will maybe start with 50% feature. And then we'll time by time, by updates, will extend the set of features. And you see how this happening, right? Tesla is one example, Volkswagen with the ID cars. This is a second example. So having this kind of additional features, additional value for the customer, and maybe even also bug fixing. And that's something which will be a game changer. But the OEMs just start to understand this and to dig into this, at least from my understanding. And they're still very much 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 air update, that's something which still needs to get more spreaded. And I think software defined vehicle, which exactly something which enables this new trend of having these chances over over the air update and deploying new function and new features to the car. And so we have discussions. We had discussions. We have discussions with OEMs. And I'm quite convinced that we see first representative of OEMs 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 months. As soon as we have significant code contributions, I think this initiative will be very, very relevant for OEMs as well. And if we have some OEMs here in the audience, you're welcome to join the Eclipse of software defined vehicle and please contact Michael Placke for that. We are very happy about the collaboration. But Ansgar, no, just to raise that question, right? You were in discussion with OEMs as well without providing names. What is your feedback you get if you talk about software defined vehicle? So I'm completely relating to what you have been saying, Michael, there's one dimension more beside the fact that all of the OEMs and it's including the tier ones. 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 a safety critical system. So it's important. But on the other hand side, we can 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, future E2Ec architectures, some of them already today 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 then in the end. And that's from my point of view, a 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. 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, there starts to be a certain appreciation for the approach, especially the open source approach because as of today in 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 lock in with anybody of the tier industry and obviously they are having a hard time to deciding on either of that options, right? So choosing that more collaborative way and especially then again in the open source room kind of enables them to take what is there in terms of reusing that which is kind of buying but not actually buying. But at the same time giving them a stage on where they can actually contribute and where they can somehow live there I wanna make and do something on my own life. So this is kind of the nice, another nice side effect if you want so of that collaboration model which again I see a starting appreciation at various OEMs actually, yeah. So thanks for the great discussion and very excited about the Eclipse Software Define 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.