{"id":109727,"date":"2026-03-03T12:48:09","date_gmt":"2026-03-03T15:48:09","guid":{"rendered":"https:\/\/automotive.einnews.com\/article\/897224624"},"modified":"2026-03-03T12:48:09","modified_gmt":"2026-03-03T15:48:09","slug":"how-the-eclipse-software-defined-vehicle-sdv-is-revolutionizing-open-source-automotive-with-ansgar-lindwedel","status":"publish","type":"post","link":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/2026\/03\/03\/how-the-eclipse-software-defined-vehicle-sdv-is-revolutionizing-open-source-automotive-with-ansgar-lindwedel\/","title":{"rendered":"How The Eclipse Software Defined Vehicle (SDV) is Revolutionizing Open Source Automotive (with Ansgar Lindwedel)"},"content":{"rendered":"
<\/div>\n

In this RedMonk conversation, Kate Holterhoff speaks with Ansgar Lindwedel, Director of Software Defined Vehicle (SDV) Ecosystem Development at the Eclipse Foundation. They discuss the concept of Software Defined Vehicles, the evolution of software in the automotive industry, and the challenges faced by developers. Ansgar explains the importance of the Eclipse SDV working group, the trade-offs of proprietary operating systems, and the role of open source in building competencies. They also touch on safety in open source software development, the ecosystem of Eclipse SDV, the impact of AI on automotive development, and the future roadmap for the community.<\/p>\n

This RedMonk Conversation is sponsored by the Eclipse Foundation.<\/p>\n

Links<\/h2>\n

Kate Holterhoff (00:04)<\/strong>
and welcome to this Redmonk Conversation. My name is Kate Holterhoff. I\u2019m a senior analyst at Redmonk. And with me today, I have Ansgar. He\u2019s the director of Software-Defined Vehicle Ecosystem Development at the Eclipse Foundation. Ansgar, thanks so much for joining me on the MonkCast.<\/p>\n

Ansgar Lindwedel (00:19)<\/strong>
Thanks for having me, Kate. I\u2019m happy to be here.<\/p>\n

Kate Holterhoff (00:21)<\/strong>
All right, so let\u2019s start with some of the basics. What is a software defined vehicle and what makes the Eclipse SDV so important?<\/p>\n

Ansgar Lindwedel (00:29)<\/strong>
So interesting one. I I try to or I\u2019m getting this question quite regularly sometimes also from people who are not even from automotive and they ask me what are you doing and when I\u2019d say like I\u2019m looking on software defined vehicles they are like what and Pretty much you can if you try to look at it super abstract in the past usually a New car was designed coming from a hardware perspective like okay<\/p>\n

how much horsepower should the engine have? How do we want the suspension to be? How do we want the driving experience, et cetera? And then to enable all these, also in the meantime, very electronic components in the car, which are still hardware, to enable them doing what they need to do, you needed software. So software pretty much was the, yeah, we need that to let the hardware do what the hardware needs to do. And the software-defined vehicle is pretty much flip-siding that entire<\/p>\n

attempt of how to design the product. So you start from software first in terms of, okay, how do we want the software experience in the car? So what is the software experience the customer desires? What do they want from features, etc.? Then you design the entire software experience of the car and then you derive the hardware needs from what the software requires, which pretty much for automotive product engineering is the exact opposite of what the past 120 years look<\/p>\n

Kate Holterhoff (01:53)<\/strong>
All right, that\u2019s helpful. So I suspect many of our listeners don\u2019t know a ton about the history of software in vehicles. So can you give us a brief overview of when and why software really entered into the automobile industry? And maybe as part of that, can you talk about where we are today?<\/p>\n

Ansgar Lindwedel (02:09)<\/strong>
Yeah, sure. So maybe following my own professional career, so I\u2019ve been pretty much working in the automotive industry as a software engineer by studies since all of my professional life. I started working after university in 2005. Software at that time was exactly how I described it before. So it was the thing which you needed to put to hardware like any sensors or whatever.<\/p>\n

to enable the sensors to do what they do. So if you have an ultrasonic sensor at your car, who helps in parking your car and figuring out where\u2019s the next thing I don\u2019t want to bump into, it needed software to do that. And that was where software was, and often software still is. What is maybe interesting to people who are not in automotive embedded engineering is that<\/p>\n

All of these different hardware have their own little computers attached to it. We call them ECUs, electronic control units. And these ECUs, they run the pieces of software which then helps the hardware doing what the hardware needs to do. Sensing something, recording something, whatever. Or the most prominent software you can experience in a car as an end user is most likely your HMI, your navigation, your I have apps, I have my whatever.<\/p>\n

Google or Apple integration to have my favorite apps running on my car etc. so software in cars is often still super decentralized. So that means a modern super electronic car, so not electric but electronic, is having maybe a hundred of those ECUs. And it could also be that the software which is developed for these different hundred ECUs<\/p>\n

is completely independent from each other. There\u2019s interfaces for sure, but there\u2019s different approaches how to develop that software, how that software is going to be on those ECUs. And I think what happened over the course of the last<\/p>\n

years is that the electronic architecture of a car, so these ECUs, but then also the software accordingly got more more centralized. So that means instead of 100 different small ECUs in a car,<\/p>\n

you have more and more what the car industry is calling high-performance computer. If you talk to a cloud engineer at Google or Microsoft, they would smile and laugh about the high-performance compute. for cars, it\u2019s high-performance computers. Instead of having 100 different small ECUs, you integrate the functionality to maybe five, six big ECUs in a car and run the software more centralized, which then also comes with different software architectures working on those ECUs.<\/p>\n

Kate Holterhoff (05:02)<\/strong>
Okay, yeah, that helps me out. So I want to hear a little bit more about the Eclipse SDV working group and how is that currently structured?<\/p>\n

Ansgar Lindwedel (05:11)<\/strong>
So if you look at what I\u2019ve just described, how hardware was enabled by software and now more and more we are getting into the software defined vehicle, this also comes with challenges how to, so that changes the architecture, that changes also the way you develop the software. And that also has requirements on what kind of tools do you use for that, et cetera. And many of the software building blocks for modern software defined vehicles,<\/p>\n

That is software which you can say is not differentiating a BMW from a GM or from a Ford car, but it\u2019s what I call a foundational software. So every of these ECUs or high-performance computers needs an operating system running on it. It needs middleware technologies which helps you abstracting between the underlying hardware and the software applications running on top of it. You want to decouple that.<\/p>\n

Kate Holterhoff (05:58)<\/strong>
Mm-hmm.<\/p>\n

Ansgar Lindwedel (06:09)<\/strong>
You would also love to have one of these software platforms, which is not something you develop for each and every new car from the scratch, but something you evolve as a software technology. You\u2019re carrying over if you\u2019re manufacturing cars from the first generation of the vehicle to the second, to the third, and you evolve this instead of every time you build a new car, you develop all the new software. Once that is out of market, you throw everything away and develop something new for the next generation.<\/p>\n

of that car. And since many of these pieces are what I call non-differentiating, there\u2019s no meaning in what the industry did, let\u2019s say, if you look five or six years back, every car manufacturer, every big supplier worked on their own, they called it OS, even though it\u2019s not an operating system, but VW was doing a VW OS, Mercedes was doing an MB OS, all the others did pretty much the same, had some other names for it.<\/p>\n

And what they\u2019ve been investing into is building this foundation layer of software Which in the end is not really giving your brand and your product a differentiating feature But you need that software to build the application software on top which then is differentiating your car So everybody was investing a whole lot of resources a whole lot of money also in building that foundation level To not really have something differentiating for oneself afterwards<\/p>\n

So that was also the idea in 2021. I\u2019ve been still working with Bosch those days to create an open source initiative saying like, okay, it\u2019s just insane what we doing here. Why shall we all build that non-differentiating stack everybody for themselves? Let\u2019s just integrate those efforts and make that collaborative. And that is pretty much what Eclipse SCV is doing. So let\u2019s see.<\/p>\n

To build this non differentiating stack together, everybody can run that into the cars, the big suppliers can run that onto these use they are supplying to the car manufacturers, et cetera. We develop that once, we maintain that once instead of so many different times, which is reducing cost, which is making you quicker building that and maintaining that. That\u2019s pretty much what Eclipse SDV is all about.<\/p>\n

Kate Holterhoff (08:29)<\/strong>
And so let\u2019s pivot to talk about developer experience now. So help me to understand why current automotive development tools are disappointing modern developers and what specific improvements in the developer experience the SDV.Dev and SDV.Ops pillars, what they\u2019re delivering.<\/p>\n

Ansgar Lindwedel (08:49)<\/strong>
So if you\u2019re an automotive engineer, you\u2019re used to circumstances which for a cloud native engineer just maybe even sound insane. looking back at that 100 ECUs I\u2019ve been mentioning, it could be that those 100 ECUs are developed each by each with different tools.<\/p>\n

Kate Holterhoff (09:00)<\/strong>
Yeah.<\/p>\n

Yeah.<\/p>\n

Ansgar Lindwedel (09:11)<\/strong>
with different kind of what demands I have to develop that software. Obviously, since cars are a functional safety relevant product, it has a lot to do with functional safety. So you want your braking system to operate every time, 100%. So you cannot live. So if, I don\u2019t know, an app on your smartphone breaks and not operates and you cannot, I don\u2019t know, play your Angry Birds one day, nobody\u2019s going to die, right?<\/p>\n

If your braking system in car is not operating because software has a failure, that\u2019s a severe issue. So the kind of three, as well as other industries who build products, are having demands on functional safety, invests a lot into making sure that software is always up and running and making what they want the software to do.<\/p>\n

Also comes with that for these 100 ECUs, different context, different software which is running on it, it could be that an automotive engineer developing software for those ECUs is having maybe not 100, but a whole bunch of different tool sets, a whole bunch of different processes who needs to follow to develop that software. Also, these tools are not what a Linux developer from maybe a cloud native world is used to.<\/p>\n

So they are not CI native, it\u2019s very fragmented. Often you also have standards which are proprietary, so that means you also need proprietary tools. That also means that if there is something wrong at the tool chain and you would like to fix that, you cannot even do that because you would need to ask the provider of that tool chain to do that in their proprietary product.<\/p>\n

You don\u2019t have really an interoperable tool chain over the entire software in the car, but it\u2019s really a fragmented thing. And usually if you ask automotive engineers if they love or hate that, they obviously hate that because that is a lot of complexity dependencies you\u2019re having you don\u2019t want.<\/p>\n

how do we fix that? I think to say like in the future we only have or in five years down the road we only have one tool set and one way of producing software for cars that\u2019s maybe too ambitious. But streamlining that, defragmenting this massive fragmentation we are currently having and trying to be closer to what a cloud native tool chain and also<\/p>\n

the cloud-native way of developing software and releasing software is. That is what the community is working on if you look into SDV.Dev in particular.<\/p>\n

Kate Holterhoff (11:55)<\/strong>
OK, that helps. So let\u2019s go back to some of the things that you have mentioned earlier about this sort of traditional approach to foundational automotive software. And so you\u2019ve characterized how many companies, they\u2019re building their own operating systems. And that is just fundamentally an inefficient process, right? Can you explain the trade-off of that choice? I mean, there\u2019s got to be a reason why folks choose that, right? So what is the final d-?<\/p>\n

I guess turning point that has convinced major companies, so some of the automotive companies that you\u2019ve already mentioned, right, BMW, Mercedes, to embrace sharing this open source platform like the Eclipse SDV.<\/p>\n

Ansgar Lindwedel (12:34)<\/strong>
Yeah, so thanks. That\u2019s an excellent question from my point of view and it\u2019s also a personal perspective, right? So maybe I\u2019m not hitting everything and every aspect of what people have at their minds. My personal perspective on that question is that everybody was pretty much going through a learning curve. So if you look back 20 years and that also comes from that fact, what I\u2019ve been describing at the very beginning, software wasn\u2019t a product in the past. Software was something you needed.<\/p>\n

to make your product ready. And that means that many of the car manufacturers, the traditional car manufacturers, didn\u2019t even develop any piece of software themselves. So usually they carved all of these ECUs and hardware parts out to suppliers. So you saw the big Bosch\u2019s, Denso\u2019s, Continental\u2019s, whatever in this world. And they\u2019ve been building ECUs, including the software for the car manufacturers.<\/p>\n

So that means, let\u2019s say 20 years down the road, there has not been a software engineer working at an OEM. Maybe despite the ones working in IT making that every laptop works for their employees. But nobody who was developing software for the car because that was carved out to supply us. So then if you look back maybe 10 years, the OEM started saying like, software is getting more and more important. So we need to have the competency of software, which obviously is true.<\/p>\n

So if you realize that software is the dominating factor in how your product is experienced by the end customer, how you can also deliver new features into your product, you want to own the competency for sure. What from my point of view has been often the gut feeling and first choice of how to do that is we need to install software by a hundred percent. We need to do that all by ourselves. We cannot do that with suppliers.<\/p>\n

Because if we do it with suppliers, we don\u2019t have the competency. And I can understand this reflex to say like, okay, I need to own it to have the competency. But then we\u2019ve been seeing big car manufacturers building sometimes even huge new organizations within their companies to deal with software. They hired a lot of talents from the market, started building their software themselves.<\/p>\n

Obviously, they needed to start at the foundational level. So they\u2019ve been working on OS, on middleware, on all of these things we\u2019ve been discussing about. And then realizing that A, it\u2019s not the easiest thing to do. And B, also you\u2019re grounding a lot of resources into things which in the end are not differentiating. And from my point of view, open source is giving you exactly that kind of sweet spot and that trade off.<\/p>\n

That means you are still working in those projects. So you have own staff who are also building the competencies because they contribute to the project, et cetera. But you don\u2019t need to own that by 100%. What you want to own is the application software level above all this foundation level. the, I don\u2019t know, parking pilot, which is making your, and just randomly picking any brands, making your GM performing better than a Ford or a BMW.<\/p>\n

not judging, just an example here. But you want to own those software competencies where you can influence how good your product is performing, where the product is perceived by your end customer. But all the things which are below, you want to have the competencies because you want to also have an independency from somebody else. You want to be able to help yourself, but it doesn\u2019t mean you need to own everything. And that is exactly what open source enables you to do. So you don\u2019t need to have all the depth which is coming with zoning technology, but you still have the opportunity to gain the competence.<\/p>\n

Kate Holterhoff (16:30)<\/strong>
All right, I love that explanation of what open source is really successful at achieving, right? Okay, so I want to dig in a little bit deeper into, I guess, how the developers are encountering the Eclipse SDV. So can you help me to understand from the perspective of an enterprise IT or cloud native technology perspective, what is the fundamental difference between writing software<\/p>\n

for the hardware-defined vehicle of the past versus this software-defined vehicle that you\u2019ve been describing, which is the future, right? And how does the Eclipse SDV project change the day-to-day of these automotive engineers?<\/p>\n

Ansgar Lindwedel (17:12)<\/strong>
So from my point of view that is something which is not going to happen by just switching one switch and then from one day to the other it\u2019s going to be longer than we had it in the past and only how we want to have that in the future so that is also going to be an iterative kind of process but pretty much it goes back to what I\u2019ve been already describing about the tools you require etc. So in the past pretty much you had<\/p>\n

one kind of tool set, one kind of way of working per one of these 100 ECUs. Extreme example, not super accurate, but many different kind of ways, many proprietary standards you needed to follow, proprietary tools you needed to use, which are from one domain to the other you\u2019re developing software for, not interoperable. If you look at how a cloud native engineer is developing any applications for running in a cloud,<\/p>\n

etc., then usually this landscape of tools he or she is using, the way of how to develop, how to release, how to deploy the software is always the same. So it\u2019s more homogeneous than what the automotive engineers are used to nowadays. And pretty much the way it should work in the future is more the cloud native way of doing it. It\u2019s going to be<\/p>\n

different to the cloud-native because automotive will still have their specific needs etc. But to take the paradigms and the way cloud-native engineering is working and make that part of the automotive engineering world, that\u2019s pretty much how the future should look like.<\/p>\n

Kate Holterhoff (18:58)<\/strong>
So I want to pivot now to discussing safety. So the successful ASIL D safety assessment of the Eclipse Trustable Software Framework is a huge milestone. How does developing safety critical open source software for projects like S-Core differ from traditional open source? And what does this assessment truly prove about the viability of open source in these critical systems?<\/p>\n

Ansgar Lindwedel (19:22)<\/strong>
Yeah, so you\u2019re touching on one very important point I\u2019ve been mentioning before already, what makes automotive embedded engineering different to cloud native engineering. And that is the example I\u2019ve been giving early on. If your Angry Birds app on your smartphone crashes, you pretty much don\u2019t care. It\u2019s a little bit of frustration. But if a safety-relevant feature in your car isn\u2019t working, that\u2019s severe thing. So that means also in the future, it\u2019s going to be different<\/p>\n

the way you are developing functional safety relevant software in comparison to non-functional safety relevant software. What is special for open source is, since you have mentioned ASIL D. So ASIL D is pretty much a rating which comes from an ISO standard. That ISO standard in the automotive world which is applied is the so-called ISO 26262. That\u2019s a functional safety standard. And pretty much what that standard is describing is like,<\/p>\n

Hey, if you develop software and you want to develop a software for a functional safe context, like for example the software running on a raking ECU, then you need to do it like this. So it asks you to specify your requirements properly before you even start developing software. Then you should derive test cases proving that the requirements are implemented well once you test your software. Then\u2026<\/p>\n

You implement your software, you also make a traceability between requirements, test cases, the software, so that in the end, once you\u2019ve done your integration test, system test, etc., you prove that what you\u2019ve been specified in the very beginning is implemented in the software, it does what it needs to do, and it is not having any bugs. That\u2019s pretty much an abstract way describing how this standard is working.<\/p>\n

And then you also need to work processes in the development according to this requirements. If you look in open source projects, very rarely you find open source projects. And if I say very rarely, I\u2019d say never. Where people start writing down requirements before they code. Because usually open source projects starts with code, which also is an advantage of open source because usually<\/p>\n

You can innovate quicker because usually people start at code and implementations, see what it does, make it better afterwards, do iterations, etc. So how can you ever do functional safe code and produce functional safe code if you do it in open source following that paradigm? Most likely natural. And that is exactly where a trustful software framework also comes in because trustful software framework is pretty much an approach.<\/p>\n

how to deal with functional safety. Not only functional safety, it also covers things like cyber security, standards, et cetera, but pretty much a new approach of how do you make sure that the software you\u2019ve been developing is doing what it needs to do, is bug free, and therefore you can still prove that it\u2019s functional safe. And that still goes with you need to collect artifacts, which is proving that you\u2019ve done<\/p>\n

or the needful things to ensure that you\u2019re functional, safe, et cetera. But it\u2019s a different attempt, like in the past, processes were implemented on this ISO 26262. And by following these processes, you pretty much proved that you\u2019re functional and safe. And by getting that attestation, that trustable software can and applying that methodology and also tools which coming with it.<\/p>\n

This attestation says like if you do that, that is also a viable way of getting a functional safety certification to your software code. And this is a game changer for open source communities overall. That is not only something for Eclipse SDV, that is also true for many other open source communities because they always lack this functional safety thing.<\/p>\n

So any open source project which is working towards a product which is relevant in a context of functional safety benefits from this because now you have a methodology and an approach how to deal with functional safety in an open source developer project.<\/p>\n

Kate Holterhoff (23:48)<\/strong>
All right, thanks for that. Yeah, I mean, I don\u2019t think we can put too much emphasis on the safety part of the SDV, right? I think one of the things that interests me the most about the Eclipse software-defined vehicle is the ecosystem. And so what I mean by that is that there\u2019s an open source structure and community, there\u2019s events, it functions as a sort of innovation incubator.<\/p>\n

Can you talk to me a little bit more about what the ecosystem looks like, maybe the roadmap? Why is the ecosystem such a pivotal part of Eclipse SDV?<\/p>\n

Ansgar Lindwedel (24:22)<\/strong>
So the super simple answer to that is that obviously if you agree to what I\u2019ve been saying before, if you\u2019re an OEM, T or whatever, that it does not make sense to work on non-differentiating software alone, but you would like to do that in a collaborative manner with others, obviously you need others. So you need an ecosystem, right? And I like one.<\/p>\n

One quote from our first steering committee chair we had, which was a gentleman from Microsoft who helped us building the first meetings and committees. And he always used to say, like, there is no ecosystem beside the one you\u2019re building, right? So doing something in open source and doing it by just going somewhere on a public GitHub repo and dump a code base.<\/p>\n

doesn\u2019t build ecosystem because most likely either nobody\u2019s finding what you\u2019re doing or nobody\u2019s interested in what you\u2019re doing. So it\u2019s an effort to build that ecosystem to make that collaboration even work. How does that work in the Eclipse SDV? In the very beginning, 2022, when we founded the initiative, there has been 11 companies founding this initiative. That was the initiators were Bosch and Microsoft and then we\u2026<\/p>\n

Quickly for the launch we acquired nine different other companies Continental was involved, ZF was involved So now I started calling names and I\u2019m definitely going to be unpolite to someone I\u2019m forgetting members were<\/p>\n

Kate Holterhoff (26:02)<\/strong>
they\u2019ll forgive you.<\/p>\n

Ansgar Lindwedel (26:02)<\/strong>
but 11 industry members were saying this is a meaningful endeavor we should do that Interesting point was that day none of the OEMs have been yet part of the<\/p>\n

initiative. So that means there was a solid base of 11 big companies, very European, very German centric, starting this initiative. Then in the first year we\u2019ve been able to also attract two of the big OEMs, with VW and Mercedes into it. The year after we also attracted BMW into it. And that also was a pivotal moment for the community because obviously<\/p>\n

all that software everybody is working on, in the end needs to be adopted by OEMs, right? So none of the tiers, none of the software companies who are part of the ecosystem can decide what software to put into cars. In the end, that\u2019s a decision by an OEM. So the ecosystem needed OEMs. It also needs suppliers and software companies because that\u2019s the knowledge, that\u2019s the background they are having. They need to also build that into their ECUs, et cetera.<\/p>\n

So you need a diverse ecosystem. You need the ones who can contribute. You need the ones who also finally adopt the software, etc. And that has been all the time the balance trying to build or get members into the ecosystem from all the different perspectives. And then what has been the fact for the first three years until I\u2019d say last year or even the beginning of this year is that<\/p>\n

We had a critical mass of OEMs, tiers, software companies on board. They were very European-centric. So we always had members around the globe. But if you looked at our member structure, then it was very European and in Europe even very German-centric. And that is something which we\u2019ve been working on over the course of the last one one and a half years. At the beginning of this year, we had an announcement also during\u2026<\/p>\n

CES where we\u2019ve been able to show that OEMs, tiers, software companies from around the world are now also contributing and also committing to use this software in future cars. So we\u2019ve been able to grow the community in the US, in Korea. We are currently heavily investing also into the Japanese auto market because in the end<\/p>\n

If Germany or if Europe is solving these issues, that would already be helpful, obviously. But it would be even more helpful if that is not something where the European auto industry is developing their standard and then a Japanese auto industry is developing their but a different standard. And then maybe the Northern American one is doing it exactly a third time, because then you have three standards around the world. What\u2019s the meaning in that?<\/p>\n

So if we all agree that this is non-differentiating stuff, we should do that worldwide. This is what we\u2019ve been achieving over course of the last year, that this is not only a German initiative, but a worldwide collaboration.<\/p>\n

Kate Holterhoff (29:18)<\/strong>
Yes. Okay. I think having that global representation is going to be so important to the success of the project. So I appreciate you laying that you\u2019re thinking about right now. And yeah, helps me to sort of formulate what it is that you folks are doing.<\/p>\n

Okay. So the community has seen a surge in interest in Asia and the US. I\u2019m curious, what would you say is the key value proposition or unique challenge that Eclipse SDV is solving for the developers in these diverse regions? So we\u2019ve got South Korea, Japan, a lot of these you mentioned earlier. And how do they compare with the initial momentum from Europe and Germany specifically?<\/p>\n

Ansgar Lindwedel (30:01)<\/strong>
the same things, right? So all of these challenges which the German car industry or the European car industry is having, it\u2019s the same challenge what is there for the Japanese and for the American car industry, right? So this idea of saying, okay, I need this foundational software to be able to develop cars in a software defined vehicle manner, what we\u2019ve been talking before, everybody is having that challenge. And everybody is again also having the challenge that<\/p>\n

Kate Holterhoff (30:14)<\/strong>
Right.<\/p>\n

Ansgar Lindwedel (30:30)<\/strong>
using resources for something which is in the end not differentiating your product in the market probably doesn\u2019t make sense. So everybody is benefiting in the same way from such a collaborative effort. And that\u2019s from my point of view why the people are also interested in participating in international meetings we are doing, becoming part of the community. It\u2019s not an easy decision all the time because it has to do something with you need to<\/p>\n

realized that maybe you need to do something different to what you\u2019ve been doing up to until today, which always is a kind of pivot in strategy. And also there is many different kind of standardization efforts in the industry as well. So it\u2019s also a decision about, which one are the ones which I pick and invest into? I also understand that.<\/p>\n

But I\u2019m pretty confident that we do have, like I\u2019ve been mentioning it before, do have a critical mass of members now from the different kind of roads active in the community. They are working on software which is going to be releasable software by the end of 2026 to then base the serious development which they need to do with their products upon that. So we are on a good way and\u2026<\/p>\n

Hopefully we can catch as many of the companies around the world to be part of that initiative.<\/p>\n

Kate Holterhoff (32:00)<\/strong>
So, we\u2019ve gotten this far in the conversation without bringing up AI, and I\u2019m afraid that I can\u2019t let you get away with it much longer. So let\u2019s talk about the AI Special Interest Group here.<\/p>\n

You\u2019ve got projects like the Eclipse LMOs. What are some of these initiatives, and at a higher level, what would you say is the biggest long-term disruption that you are seeing from AI, the automotive development lifecycle?<\/p>\n

Ansgar Lindwedel (32:24)<\/strong>
Yeah, so I understand you cannot have a conversation about tech today without talking about AI It\u2019s always a little bit of stretch between Talking about meaningful stuff and just feeding the bus So from my point of view AI definitely will have and already have an impact on automotive engineering<\/p>\n

Kate Holterhoff (32:31)<\/strong>
It\u2019s true.<\/p>\n

Ansgar Lindwedel (32:47)<\/strong>
which from my point of view is on the one hand side obviously in how developers work. So you see that in the enterprise IT world, AI is already doing parts of the coding job. That is obviously also true for automotive engineering. So the automotive industry is expecting that they have developer efficiency increases by leveraging AI, vibe coding, et cetera.<\/p>\n

If you talk to developers, sometimes they say, like, OK, it\u2019s even increasing my workload because I need to review that bytecode and code and make it work again. But we can argue about it from my point of view. In the end, there\u2019s going to be opportunities to leverage AI to increase developer efficiency for sure. And it\u2019s already happening today. What adds to that from my point of view from an AI perspective is that<\/p>\n

Kate Holterhoff (33:22)<\/strong>
Yeah.<\/p>\n

Ansgar Lindwedel (33:40)<\/strong>
everything what you see about agentic AI and how those AI agents can also add value in products by being implemented into products is definitely a total different angle here. And I\u2019m getting to an age where I can say, like, I\u2019m not even sure if I want that, but I bet we are going to see cars in the future where a lot of AI agents are in who are trying to make your<\/p>\n

your life easier. Maybe sometimes they won\u2019t, but that\u2019s definitely a technology which is giving a huge potential of innovation. Think about how end customers like you and me driving around with a car could benefit from these technologies and how to deal with your car. Imagine like you\u2019ve been able to mutually discuss with your car, influence your calendar.<\/p>\n

whatever and your car becomes more or less your digital assistance instead of just a device which is bringing you from A to B. So another aspect of AI in automotive is also dealing with all these pain points I\u2019ve been discussing before. So different tools, different processes, processes to follow. So AI can also play a pivotal role from my point of view in making the use of these tools and the use of how to develop software for<\/p>\n

automotive system, AI can help relieving the pain which is coming from following these processes or dealing with different tools and make the developer life easier by pretty much putting that work and effort a developer has nowadays into the responsibility of an AI to do that. And that\u2019s also something which is<\/p>\n

in the scope of this AI special interest groups, especially the question of how can AI help making the tool landscape, which is there today, better and more convenient for developers.<\/p>\n

Kate Holterhoff (35:43)<\/strong>
Okay, yeah. Well, I appreciate you addressing the buzz here. I think that\u2019s, you know, it\u2019s useful. It\u2019s certainly top of mind for many of the folks who we talk to at RedMonk. So yeah, it\u2019s helpful to least bring it up, right?<\/p>\n

So we\u2019re about out of time. I\u2019m going to end us here on one last question. And that\u2019s about your roadmap here. So you have stated that 2026 is going to be a big leap for the community. And that includes the launch of Eclipse S-Core 1.0. And so beyond this technical milestone, I\u2019m interested in what would you say is the single most transformative experience or industry? that the Eclipse SDV will enable in say, you know, the next year, maybe 18 months.<\/p>\n

Ansgar Lindwedel (36:29)<\/strong>
So that\u2019s an interesting one. So what is the most transformative thing? So from my point of view, even though that you asked me about something beyond Eclipse S-Core, I need to mention Eclipse S-Core because developing<\/p>\n

and collaborative middleware stack, which then could be used abroad across the industry in just two years would be super transformative. If you look at how long these kind of endeavors took in the past, if they\u2019ve been successful at all, then that took longer time. Or you\u2019ve also seen many of the attempts failing because in the end it wasn\u2019t done to the final stage.<\/p>\n

Kate Holterhoff (37:06)<\/strong>
Mm-hmm.<\/p>\n

Ansgar Lindwedel (37:18)<\/strong>
Then having a joint software stack which the entire industry can use and we already see a lot of OEMs lining up saying like, yeah, we intend to use that also in our series production. You will see that hope. So from my point of view, the best thing which is going to happen is that every OEM then can refocus their priorities away from that middleware sync and focus their engineering capacities on<\/p>\n

building software application for the cars, which is then differentiating them. So you will see a lot of more, as the end user of a car, you\u2019ll see a lot of more new software features in your car coming to your car, coming also super frequently to your car, because the OEMs have time and money to invest into that instead of doing that foundation. And most likely,<\/p>\n

And that is going to be an interactive thing. Also, the developer experience for the developer of car software will then step-by-step change and we will see a lot of more adoption of open source technologies in modern cars.<\/p>\n

Kate Holterhoff (38:30)<\/strong>
Excellent. Okay. This has been such a great conversation I\u2019ve really enjoyed speaking with you Ansgar. Again, my name is Kate Holterhoff. I\u2019m a senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you\u2019re watching us on RedMonk\u2019s YouTube channel, please like, subscribe, and engage with us in the comments.<\/p>\n

<\/a><\/strong> <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

… software really entered into the automobile<\/span> industry? And maybe as part … mentioning before already, what makes automotive<\/span> embedded engineering different to cloud … obviously also true for automotive<\/span> engineering. So the automotive<\/span> industry is expecting …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-109727","post","type-post","status-publish","format-standard","hentry","category-news","wpcat-1-id"],"_links":{"self":[{"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/posts\/109727","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/comments?post=109727"}],"version-history":[{"count":0,"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/posts\/109727\/revisions"}],"wp:attachment":[{"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/media?parent=109727"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/categories?post=109727"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/new7.shop\/zerocostfreehost\/index.php\/wp-json\/wp\/v2\/tags?post=109727"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}