Eclipse S-CORE: Open by choice. Safe by design. Driving automotive innovation together!

This talk covers the Eclipse ASCOT project, an open-source initiative aimed at addressing automotive software development challenges and enhancing safety certification processes. The speakers, Philip and Björn from ETAS, discuss the project's goals, including the development of a complete middleware stack for high-performance computers in vehicles. They emphasize the importance of collaboration in open-source to streamline software development and resolve integration issues among different suppliers. The project aims to implement a robust process for creating safety-certifiable software, adhering to standards such as ISO 26262 and ASPICE. They highlight contributions from a diverse range of industry stakeholders and outline their efforts to achieve a stable release of the project by the end of the year.

Okay, uh thanks for joining the session directly after this break. So, you made it in time. Congratulations. Uh I have the pleasure to operate the clicker on the first two slides, and then I hand it over to Björn. Why so? Uh just briefly want to say who I am. I will take on later in the process where because I'm, as you can see at the bottom, I'm

safe open vehicle core committer, so in core committer mainly in the process side, so you get some insights into the fancy world of processes being open source into the S overall. And as this is an Eclipse event, still worth to mention I'm technical steering committee chair of the enabling Linux and safety applications. So, if you have some questions around Linux afterwards, uh you can approach me also

on this. Board member of Linux Foundation Europe. And yeah, thanks to my employer ETAS I have the pleasure to be here doing my work as automotive process lead, community manager. That's it from me, and we make this beautiful split of Björn can continue with more content than rather just introduction. Perfect. Thank you, Philip. So, my name is Björn. I'm part of the ASCOT project as well, and

I'm part of ETAS as well as Philip is, um holding the chair of the Eclipse SDV working group now in the meantime for a year, but within ASCOT mainly taking part in marketing communication activities, being active as a community community manager for ETAS, taking care that we're spreading the word, being around, being approachable, and uh promoting the project. Um what we brought today is like and we

had already several talks. We had the talk from Oliver earlier today putting uh ASCOT into it. We had the talk yesterday from the colleague um um from OMOBILE referencing Eclipse ASCOT. What we have with us today is an overview of the project. So, what is the goal of the project? Where we are at? How did we start? Um and then with some latest updates on what's coming

up, what are we currently doing, how are we we collaborating, and Philip will have a deep dive on all our efforts on on process. On how do we make this safety certifiable that Oliver was mentioning earlier today, something that we believe we can achieve within the project. Um, so starting with the why and why open source and how do we get there. So, on the right-hand side

you see slides that were presented from colleagues from BMW, I think 2 years ago. Yeah, mainly 2 years ago at AEK. Um, and they they have had challenges from the OEMs perspective. So, it is like move to HPCs, uh, centralization of EE architecture, complexity in software, all these kind of integration stuff uh, taking place in the end. Um, so um, challenges with the standardization. So, the software

for HPCs, perhaps there is a standard in place that is defined, but you cannot exchange it between different suppliers as the standard is implemented differently. So, there were a lot of good reasons to say we would like to change the way how we build the software. And there's the argumentation that collaborating in open source helps us to solve a lot of those these kind of problems. and

and this is like one of those value propositions that Eclipse S Co safe open vehicle core was founded on and and that that we are following up and and that we are working on. So, the idea is to really develop this full stack. So, you saw the architecture, perhaps the architecture picture earlier today, I will show later on as well. So, there is a complete set of

things that should be developed. Focus on non-differentiating parts. And I know saying this is easy, and I know that for a tier non-differentiating means something different than for an OEM perspective, right? And this is the challenge for us in our position as a tier, but we still believe that that it makes sense to collaborate on those topics. So, we don't need to reinvent the common library again

and again and again. It just makes sense to to implement it and to use it. Second value that we bring and what want to do is speed. So, it's not about It's It's really about code first and this is why we're part of the Eclipse Foundation, right? They Eclipse SDV working group was founded 3 years ago and had the claim code first. And this not reinventing the

wheel is one of those key objectives of the project. Comes with discussions, but it comes in the process that we're saying bring us what is available. We figure out how it fits in, whether it fits in. We have a fair and transparent process and on these kind of criteria to select it. So, we're we're really following the the value of speed. Abstraction and extensibility, one of those

examples Tilo was mentioning earlier today on the open SOVD is something where it's a clear clear message from both sides of the project. It's not part of Eclipse S-core open SOVD project, but it will integrate. It was discussed from the beginning on and this is something we need as well as on the upper layers on doing application development and as well as on the down down on

the southbound APIs with regards to the operating system or the hardware layers where we all have discussions in it. We do have Electrobit, we have Red Hat, we have QNX support in it. So, it's like what we really need. Quality and efficiency, the last one on the slide, um something where we're having and having and had a lot of efforts already in the past in order to

set up a process. How do we do an automotive software development project in an open source context with in the meantime more than 250 individual contributors that were active in the past 12 months in it. And this is hell of an effort and is painful for sure for a lot of people in the project, but I think still we are doing very good in delivering on our

values. I have this slide with me as it just shows the hype curve somehow. there's this MOU that was supported and prepared by the VDA last year in June and was presented at the AEK and initially there were 11 or 12 companies saying, "Hey, we would like to collaborate in open source. We would like to develop and and and go the path forward." And over A score

is one of those projects that we can agree on that might have an arguable stake in it. Um and this was extended now at the CES at the beginning of the year with another 21 companies and the messages on at this is that it started Germany-centric um the discussions in the project and the project itself, but in the meantime it's going international. So there's now um LG's

supporting it. There's and and assigning the MOU and we will see it later on. They're active in the project as well in the meantime. So it's we are heavily investing and and inviting that this is not only a German or European act even though it's supported and funded as well and and gets support from Ecarva all those initiatives, but this can only fly and and be successful

whether and once it's international and on a global scale in use. So this is why we had the community meetup in Korea in December. This is why we were active on the community meetup in Japan last year. and we're still promoting and and asking for support and involving people. So the scope of the project was described earlier today, but the main focus of the project itself lies

on the programming environment on the middleware. We do offer support to the operating system. We do have support from Qualcomm as well, and there's a joint a joint press release in in order to to get it up and running, but in the meantime we've seen examples running on NXP as well. So, it's like the community is picking up. And the for sure is that enabling this app

layer and the APIs to the app layer something we need to do. The impressive part, at least from my point of view, and I know lines of code is not a measure for quality. Lines of code is is but what it shows is like the the curve that we get adoption. The curve that we are providing and and working on the goal of not re-implementing and reinventing

everything, but using already a serious ready production code, for example, from BMW that brought in was brought in, but as well from other companies. And it all started with Accenture, with BMW, with Mercedes-Benz. The group of Tilo was in there from the beginning on. with ETAS and with ESR Labs or whomever. And QNX, not to forget, but in the meantime there are contributions from Elektrobit and Red

Hat seeing a value in it to say we support it with our operating system layer below and ensure that this is part of of Eclipse SCM project. So, once you go to the reference integration repo that was already mentioned earlier today, you will get the downloads for Auto SAR as well as for Elektrobit CAR Bus as well as the support for the QNX. Uh highlight really like

LG is now stepping in and and and providing support as well. We do have Schaeffler, Valeo. So, it's no longer only those three or five companies providing support for the project and giving uh resources to the project. Um but others stepping in and and this is what we really want to achieve and what we're really seeking for to make this a community effort and something that is

developed and adopted by the community. we will have a look at the timeline later on as well, but in general the project started um officially end of uh 4. Uh we had a first release of an alpha end of 25 and now we're somehow iterating to a 1.0 by the end of the year. sometimes we just faster releases and then we revoke them because something wasn't really

in the process working right, but this is just the way on on iterating this and the great thing about it, it's all public available. So, you can have the fun and follow every discussion as it is described and and publicly available. trying to really follow those five five challenges to be addressed. So, first then we need to follow requirements, we need to follow a process because we

have the promise to be safety certifiable. So, important, the project itself will not be safety certified. So, this is something earlier today was the question raised on where is the business model for somebody? So, the project takes care that we do have a lot of things done in terms of processes, in terms of documentation, deliverables, and so on that makes it possible for somebody to take it

and do a certification on this. So, and there's value and there is a willingness to pay, hopefully, by somebody who will wants to bring it to the street. Right? Timeline and reliability. I mentioned this. This is an automotive software development project in open source. This means in the end there are deadlines that people want to meet in order to bring something to a street. So, we need

to be reliable. We need to ensure that we can be trusted and that we can deliver on on our promises we had. Existing code something I already mentioned and don't want to overstress. Global something what we are seeking for and and trying to adopt and and we see a lot of interest and having discussions as well with just one in Japan on what does it mean for

the Japanese community and how we handle it. So, something we are really looking into. And for sure business will change. So, this is this is sure. So, tier one needs to figure out what does it mean for me? What does it mean for my traditional businesses? How do I sell a piece of software to to an OEM? How do I perhaps sell it to an distributor who

is selling a software to an OEM? Um but we see chances and believe in this Now, this is speaking for us that this is possible. So, this is why we are supporting it and why we are in. All right. Um Philip will go into into details on on this topic. Um So, a V-model is something we are trying to implement not we are trying we are implementing

in the open source. Um that we are getting along these artifacts that are needed in order to fulfill this. We are in constant exchange and and auditing with Exida from the beginning on. So, initially we discussed this and there is constant constant auditing. Philip will will give you further insights on this. But this is one of these proof points where we are sure and how we ensure

as a project that we will capable to prove and and deliver on our promises. the other promises we are delivering. So, it took us 11 months to have a first release and officially it's not an Eclipse release, but we call it still release. Um, this is like um we we shipped something. Um, it was an alpha release and it was a huge milestone for the project. So,

it was happening in November and it helped us a lot for integrating things in order to get our checklists right, in order to have documentation scopes staying order to show the community look, go there, test it out, give us your feedback, give us your bug reports, involve yourself in the project and and use it and try it out. So, this was a real big step for us.

Don't want to go into the details on on what was really in, but there was something up and running and usable that come that came with it. So, this something is extensive documentation. So, in the project there's the rule of everything is code. We're using Sphinx needs, we're using a lot of it's it's too small. A lot of open source tools as well in order to build

and run and Oliver gave you an a short glimpse on the developer experience with the having everything run and set up in GitHub. for sure there detailed release notes that are coming with with the project. those artifacts required for being safety certifiable is something that is not yet there and available for every module that is in the repo, but the project ceases and we see first modules

that were already production ready that came with those artifacts needed. So, the feature request itself, so what should be done? The architecture description of a module the requirements and the safety plannings and all in a in a traceable way, but something Philip will have a a deep dive as well in there later on. Um in order to make this something safety Architecture No, I forgot one. or

two. So, and it's not readable. The same as we had earlier today. Let's go for this. Um so, a lot of building blocks in there. And And I don't want to hide There's a lot of similarity to what an auto uh AUTOSAR adaptive stack is offering, right? And we see components that were in in an AUTOSAR adaptive that are now being cleared out so that we don't

have any copyrights and IP or infringements. So, this is one of those challenges in the project that we're facing in order to to make this stack happen. We see that there's a 0.5 and a a scope for 1.0 by the end of the year, and we're still gathering um gathering feature requests and having next uh upcoming uh upcoming decision round on what should be contributed, how it

should be integrated, what is going on there. So, um we now see, for example, some IP, something where there will be a pitch uh from LG. Um we do have um I don't know, time. Time is something where contributions uh will be done. Um so, this is up and running, and we're we're really following the process, and in a democratic way that there are clear parameters on

on on how to decide in the project. So, the project has the rule that we want to decide on one on one implementation because we do want to establish one standard first of all. What comes afterwards, who's forking and not bringing back and so on and so on, is something that might happen, but the project itself has the idea to have one standard that works for the

participants developing in it and working in it. So, we had the discussion earlier how to get started, and I want to bring this. Um and we share the slides later on for sure somehow um so that you have the links in it. So, first of all, is available in Git. Everything is done in GitHub discussions in in the repo in the different repos. Um so, we are

living this pull request thing on the one hand side and we're documenting every kind of meeting in the issues and in the uh no, it's a discussions. In the discussions uh within the GitHub. freely and publicly available. Um there's the reference integration repo that Oliver mentioned already. This is the point where we bring bring together everything. So, every module has an own release cycle, can be integrated,

but within the reference integration repo, everything is bundled together and comes with it. And with the 0.5 release, there's an extensive handbook giving you insights uh that are broader than just the module description, but it gives you a step-by-step guide on how to start, what are the principles, what are we following in there. Just to prove it, I didn't go for the live demo at all because

of I thought it might might not work out, but there's this reference integration repo which was done in order to make make it easy and make the low entry barrier for the project itself to start. There's as well not only the the reference integrated repo to be built and run and executed, but there's also the scramble app, which is just pops up thing to send something to

leverage the orchestrator. So, a very easy mechanism, a very first mechanism that shows that the project is capable to deliver something. You can you can do something with it. And this was the scope of 0.5 at all, having a POC that shows, "Hey, you can start, run, and execute something at a very basic and and first step." Last but not least, there's others as well adopting and

and this is what we really appreciate in in the project that somebody in the community is capable to just use something which is even in the incubation wrapper. Um so it wasn't really something that was already into the into the main path of of the project and and and bring it into a demo and creating a a video and showing, "Hey, this is S-Core. It's working like

this. You can use it and you can leverage it without any support of the project." So people adopting this and and this is really what we're seeking for. Timeline-wise, we're somewhere somewhere beginning now first quarter gone 2026. We are iterating releases. We're improving on the releases as I mentioned. We had a 0. No, 0.6 release exactly 1 day or 2 days before Bonn uh community meeting take

took place and we figured out, "Hey, our release process wasn't working properly because there was one module that was incompatible." Tests were were working out uh but but we had to revoke it. But it's just the way it is. Um it's it's I I don't have to hide it as a public, right? Uh we can talk about it, but we learned from this and we're trying to

approve and improve on this and and this brought us I think two steps ahead uh on what we experienced there. And I think having said this, um Philip will take over and and talk to you on how the processes are shaped and Yeah. Okay, maybe picking up the 0.6 release which we revoked. In principle, you can see the work in progress, right? Same applies for the process.

There's a lot of process definition done in the past, but to pick everybody up in the scale which we currently have. So if you look into statistics, we are in the phase of 200-plus developers and we cannot speak to every developer and start say start read here, right? So therefore, um the tooling comes into picture and tooling requirements are very important so that you really say like

this is something when we need to make a check. Checking everything from every single contributor in such a large-scale project will not work because we also don't know the contributors, so we bring up a lot of automation to tools, automation requirements for the tools are very important. And uh in this way, well, we saw that the unit testing were running, so you can actually see results from

the unit test execution we had certain component test. We even had feature integration test for some cross-working functionality, but we missed that this communication module, which was causing some issues, were on the wrong version because there and not everything was yet in place, right? But this is improving, it's just moving on, it's getting into more streamlined way because we need to also see as the pre-development was

done and it's serious ready components partially. They also need to adopt to the process, right? So, we try to do everything that it can be picked up by others using the open source tools and so on. And what we are targeting currently we mainly execute as Fiona showed on the other side, it's based on ISO 26262 audits. So, we were auditing the process and also after short

time like on intermediate audit interim audit three or four uh Exida came to us and say that's all nice. You're building up here an ivory castle or whatever, you need to show me how it works in practice. And in the timeline until January, we could really show like this is how parts, components, elements in the uh AS core repositories pick up on what we have defined in

process. We were supporting piloting so that really people from the process team go into feature teams and support in there. And yeah, you can see also ISO 21434, we do a mixture there, we do an abstract modeling, and the ultimate goal on this would be that you as developer come, you have maybe no access to the standards, not part of daily life, but due to the automation,

due to the description, due to the things how the community works, you're automatically compliant to A-SPICE ISO 21434 and ISO 26262. Of course, this is also increases the hurdle for entry for those which are not from an automotive industry, not used to all these kind of environment. Um yeah, you can see this color coding there a little bit. There's a yellow parts of those which are not

yet completed to this first maturity level two, which means the managed process. This seems everything is in practice automated, especially for verification. We're still in the generation of reports, streamlining things, and so on. We are miss a full integration of the reference hardware. That's why it's yellow and you see the other one are security because we first looked into as we had more experts on this functional

safety than the security experts. Now security picks up and it's getting more and more in. Right. Um short glimpse on what happened in January. There was three days audit on the first year. And we were very confident when we entered. Uh we were a bit disappointed when we left, but the auditor was still quite confident and they said, "Well, it was working well." And we said, "Well,

really?" At least for me it was quite yeah, quite a thing and then I was like, "Okay, is it really good?" We can see that we had a lot of items with high maturity. So, from architecture, quality management, and so on. We had also major planning items and these reports are something while we have almost everything open, these are not open. So, you do not see exactly

the Exida reports which they provide, everything which is in there is put into the epics. So, we work on an epic. The epic is broken down into the process areas and it shows the deviations, actions, open points, not started. And by this you can basically get a trace to everything which need to be worked this was then taken. So, here is just a screenshot from the sub

item sub issues of the epic we worked on. It's an earlier screenshot. Now, most of the green ones are marked as complete. Uh still some parts are open and we use this with the interim audit on April 17th. We're still again waiting for the report because in the report generation of Exela, there's still a lot of manual work. So, they take screenshots, see, compare, does it really

fit? And then add their values and say that's okay and not okay. Um I expect it to come in the next week. But still we will create new epics out of it so that we can follow up on the items and you can still really transparency see where something open and not. And by this total the 1.0 release, we come from this managed process to the level

three, maybe a little bit more in improving part. And uh so, it's not a mix It's not a wrong representation, right? We're really not fully there from the level one, level two, but we try to get above the level two to the three, maybe in the range of four at the end of the year because we want to be really fully operational for the one and we

will have another three days audit in November and I will come back in January and tell you how disappointed I am that it was not going as I expect. But still we are already now on a good process and yeah. As you can see uh just taking the theme of the previous slide, we had the interim audit done. We will have audit again. It's the eighth audit

then. You can see many audits happen. So, they are following us all the time, which helps. And I have the wrong heading in the copy pasting of the slide. So, you can ignore this, please. now the really thing actually. As Björn mentioned, we work on Doxis code. So, a lot of elements are handled as swings needs element. We have Well, if we go for the V-model, so

we're not strictly following a V-model from a time perspective, but you will find all the artifacts and elements which are necessary for the V-model. So, you find requirements, architecture, code, things got linked. And by this, the highest level is a stakeholder requirement, then a feature requirements, bringing things into cluster, and on the lowest level of software, well, we work on a unit, then we have dynamic architecture,

static architecture, and these ID files which you have, you will put in your needs elements. You say this is belongs, this is satisfied by, and then if you come to a test case, you will say this partially or fully verifies as a test property. And by this, we get all the data, we get all the rendering, all the things we need. And I I just took some

screenshots uh from persistency model. You can really see there is a default values that is something which is currently feature requirement, right? In this little box there. If you follow the one back, it points to a stakeholder requirement. If I bring all in, it would be far too much. And it also shows you, well, this is satisfying a stakeholder requirement, and the feature is fulfilled by certain

architectural elements. And it goes on and says, well, here you see this is a feature requirement. The feature requirement itself, you see the satisfied in the beginning on the top, you see it satisfied below. So, it says it satisfied the feature requirement, presents default values by a component requirement. And the component requirement again has then a test thing. You currently don't see the feature testing, this will

come. Not everything is yet fully traceable, not everything is implemented yet. So, we also need to implement a lot lot of tests currently while bringing things in. And by this, you can follow this way all the way there. It's a little bit messy. You can click yourself when you follow the links slides and shade later on, so you can click your way through. You can look into

other modules, and you will not always find this brilliant traceability. So, it's just like the first module it's going in due to the rapid pace of many developers. It's getting there in addition. And then the next step would be even This looks more messy. You see the test and here's the partially verifies and another partially verifies. So, you can really see when the test is written, you

get in properties. And by the test properties, the next XML file is generated during the execution and this XML file is brought then back into SwingS needs reports. And you can draw uh draw reports or pie charts and whatever. And Now, I'll come to thing We try to do a reuse wherever possible. And this means I told you about two requirement and the tooling is very important.

So, we draw diagrams for the software parts. So, we have and you get all you can also get tables and so forth. I mean, it's composing data which you have at hands, right? Well, therefore you can see here's the software thing. And then there are other tools and we have the same kind of this is an implemented requirement, implemented tested and so on. The same chart, same

modeling, same interaction to just represent two different sides of it because we need to look into tool qualification a lot later on if we make so much use of automation. And therefore you can find all the testing for the tool, the requirements for the tools and all these. it's really generated so you can uh decide you make a this need language in the SwingS needs part. You

do a need pie which basically tells you this is my pie chart. And then you say what do you want to have and which test cases you take in so you can easily generate reports, figure out what is skipped, what is not executed, is there something which fails. So, you can see test report and then you see this little empty table and a heading which says this

table is supposed to be empty because it shows failed results but we are not accepting failed test cases. So, if your report shows a failed test result, the CI would not work. Still we show it in the report that it's there. Uh we also sometimes may skip something due to an improvement not being ready and so on. So, this is this pie chart explaining it how you

phrase it, how it goes into the different way, and how it's created by the types and language. And um it also generates reports. We have code QL in there. We have GCA and this was from the 0.6 release. Uh you can see reference integration links. If you go for reference integration, you will also find it. And you can see how many uh unit tests are executed. You

can see also that some parts of C++ are stronger than some Rust parts. Yet, because Rust is more in development, we said there are mature components coming in. Not all the mature components are available as Rust. Some are extended by Rust, rewritten in Rust, made in as an alternative to in Rust. And you can also see the coverage numbers. Um I put them in because when you

see statistics saying, "Oh, we want to achieve 100% coverage." It's super unrealistic. Of course, there can be deviations. But, I mean, how do you want to argue a 99%? How do you want to argue a 90%? Why is 90% good enough if the 10% includes all the critical things? 90% then there's nothing. So, we target 100. And at some point, you just get a confidence and it's

even more interesting maybe to say, "Let's just execute the coverage on a higher level of testing rather than on the lowest level to just really make use of what you get there." But, you should have the chance to see this. And we are already quite high because you can see some of the components are being used in a production environment. So, we can have had the numbers

like 5, 95% or so. some parts are not there. Function branch coverage this is not there for us tooling yet. So, that's in discussion with Ferro scene, with the people in the project discussing how do we get these coverage values in so that we also have the benefits from there. Uh it's an ongoing activity. And then, well, from a developer, you can see this in execution of

unit tests and so on in pull requests. You can also execute things locally and therefore I just feel like it's obvious for if you're in development but we have a lot of checks there depending on which repo you are. They are sometimes differ. We also unifying this. There is a new unified workflow consideration to have really reference integration being executed in the same way for all the

different components. And as a developer you just can go into your VS code. There is a docker container. I Oliver also mentioned this in the earlier talks. If you missed it, just look later on the recordings. But this by this you can really try things out and just say, "Okay, I start something here. I compile. I get warnings when I haven't linked feature requirements. If I was

not hearing thing the proper swing so needs element and so on." So everything of this is basically covered in the environment process and forced and we go often for iterations. We see there's something new. So we have a grace period where things are warning. People can correct these kind of things. Then when they are mainly corrected and the deadline has passed, then we switch things on. Then

maybe the builds break for a day but latest at this point of time we cleaning up the missing parts and then we operational again. And by this we continuously improving also from the process side and yeah, at some point in time towards end of the year hopefully most of the infrastructure part requirements are implemented. So more and more things get enforced by tooling. So you have no

way to escape from the process and do not even maybe need to read the process. You can read up front to avoid some pain but you don't have to because you will anyway pushed into what the process will tell you. Right. This is it. Um now you're super curious and want to write processes on your own. I know everybody loves processes and want to be a process

person. Um so just go into GitHub. Uh check for the minutes of the meetings to see where you get in. Uh if you have if you're unsure, go into the Slack channel. Um You can find it on the meeting calendar. We actually completely spammed the Eclipse STV meeting calendar, so I guess it always titled with ESCORE, and if you want to go to another group like Open

SOVD, which has also several meetings, um find these little slots in between, right? This is where ESCORE is not in front. my personal thing which I figured out join three meetings before you uh start asking too many questions because normally in the first meeting, it doesn't matter which project you are. It's not ESCORE related. You will not understand a lot. You can read a little bit of

minutes, but you typically get in after some time because these are productive working meetings where we cannot always pick up a new person, but don't hesitate to speak up. Ask your question. Often the meeting start early because there's not too much to discuss to align. So, you can also just point out and say well later on if there is some time I have a question or so,

just raise your hand. Everybody's welcoming. If you hesitate to speak up in a meeting, go to Slack. So, that's basically the up possibilities you have. Yeah, we have also ways to interact. There is a security contribution pitch 5 days. A little bit short notice, but this is happening more times. So, when you think now, oh I really want to contribute also something in the field of security,

you can prepare a pitch, tell you where you are, what you want to see, how you see it in ESCORE. Come there, go to the presentation, and present the things in a workshop. Uh you know, there Tilos said there will be a small one also in SOVD when you're really into diagnostics, and it's not such a super huge one, but it will be someone coming up. And

so, with this, we have a lot of call for contributions still to fill the 1.0 things for 1.0 and it's just a place and chance to exchange. So, in summary, what Brian explained from the beginning, we're mainly targeting HPCs. This is an important thing for us. Um we have really code first, which you can see on the code lines, and that not all artifacts are always fulfilled

yet on the requirement and architecture, but they will come to give you certifiable code place, which you can use later on in your product development. If you want to take the certification, or you take a trusted partner for getting you the certification done. Um we scale also globally. We see a wider requests from a bunch across the globe. Uh on OEM side, tier side, also different use

cases, passenger cars, commercial vehicles. And I mean that I'm not cheating. You can hear if you go out, look at the slide somewhere, look at the other presentation, you hear ASIL quite often. Uh Maybe sometimes far too often, but anyway. yeah. The 1 out of 0 is coming end of the year. Everybody's really invited. Uh nobody will ask, no, maybe maybe ask where you come from, but

they don't care where you come from as long as you contribute. Uh so everybody's welcome. It's just like setting the scene where you may have your questions answered. And by this, we have still a little bit of time of 7 or 8 minutes for questions. Thank you very much, Björn and uh Philip. Uh I would like to actually open the floor for questions. Any questions? Easy. Here

you go. Thank you. Uh thanks for this great presentation. Real great uh with you. Uh about this uh what is the assessment or an audit with Exida? So, what you have uh assessed there or the assessors? Is it only the process, the part 9 of the ISO? Does he um we look into part 4 8 9 6. Uh we have a tailoring. So, if you go just

on the process description website, you can go to standards, and then in the standard there's a long list and they tell you like management the safety analyst part. This is all in um you can see also what's tailored or you go to a process area of interest. There you also find it. This thing is it's ISO, right? And ISO we cannot publish the ISO standards. So it's

a little bit of cryptographic how things are. You will read something like a standard requirement called software underscore underscore and then you will know that the software is part six and then 942 will point you to uh unit verification because that's it. So you can basically take the numbers behind. The first indicate the The last the four numbers behind will tell you which chapter you are and

then you can see which requirement maps to it. By this who has the standard can see what's in, what's out, why it's out with tailoring and reasoning why it's tailored. some part could be hardware software integration. We're not treating hardware software integration because we are just the middleware stack. We will create an assumption of use and the assumption of use will tell you what you have to

do as a user as core which we cannot fulfill just from the nature of the project. And by this you still don't need to use the standard. You still just need to fulfill our assumption. Okay. Yeah. Thanks. Uh and then the next question so it's to 26262, yes? But we are now not in this world where this uh spec is defined for. So that was for microprocessors,

deterministic, 100,000 lines of code. So the whole methodology in this is this applicable for this or what the what's the Uh the nice thing about the whole So not everything is always applicable and I was super surprised when I was sitting in the audit and uh we were discussing about some part and I was I mean I had I was uncertain on the thing and I said

like I I would interpret the ISO in this way and see that they expect this from us. And then we also had a longer discussion with the auditors and then it was just the response was to say like you should consider if you tailor it out because this part of the ISO is meant for something different and it may not be applicable for your exact use case.

Um for not answering like it was built it's more built for micro control than the huge systems, but you see that the scope of software which we have was also the scope of software in other projects which have been certified. So if you get a safety-certified stack middleware stack which has a similar comparable feature set and this was able to be developed for high microprocessors which went

to audits and assessment, why shouldn't it work for us? All right, it's just like we need to stretch the ISO here and there, but this is not an ISO thing. This is a general complex software product thing right here. Um but so far we're going through things the ISO should help you. It's a list of best practices. It should show and help you to create a safe

product. And it helps you where it can and other standards so um with first testing and for security we look into ASPICE. This also helps us improve the quality of everything. Yeah. Last question about the timeline. So there was this SOP 2030. So that means at least more than 5 years for this middleware stack. And we have to compete with this China speed they always mentioned and

they develop a car from the green field in 2 years. And there are several of these stacks with AI support, with cloud support. Is this do you think that's the right or What do you or is it too slow? You can see parts here. I mean we end up for start of development series production right in this toward the end of the year and this is already

2 years time. Um I don't have it in this one. I had it in another time in another slide set where it says well if you want to go fast, walk alone. If you want to go far, walk together. And if you see like the lead order which was like a little little storm out there where they open source a thing and so on and then check

with the other Chinese it's a one one company one shot push to something and there is no collaboration and there is not scaling one. And nothing prevents you from pulling in the as a people, we also need to make a realistic time and because we make it hardened and secure and safe all the things together and we take the discussion in the community which may slow down

things, but um I see also like if you check with the partners with the distributors of A score um going into SOP in 28 is something which need to be on the agenda for many. So then you have already the 2 years pulling and um Yeah, I mean the China speed would be 15 months from writing the RFQ and then going into production, right? Um but this

is typically also not like starting fully from scratch, but building up on the existing knowledge database so and the real fast thing will come when you build the first time on A score. Your next generation will be that speed of China speed. We still have about time for one question if you'd like. Here we go. So, thanks for the talk. Um is there any plans or are

there any plans from your side to team up with the guys from the Trustable Software Framework? Um I take this. this one. Yes, exactly. It's a s Trustable Software Framework, the yellow one in the bottom. So we use it currently as the end low and JSON parser which is a pre-existing software component. They make use of Trustable and you will also find respective needs elements which represent

the assertions and the tenants of Trustable. It's just not the mainstream. Uh you also need to see that Trustable is a nice and beautiful thing, my personal perspective. Uh still if you go to TUV with Trustable, it may be much harder. Or UL or uh, Bureau assessor. Or if you need to go to Exida, right? Exida is the one who support the Trustable. The question is like

how is the adoption rate, how far the things go, and if you target the 28 SLP, where we also still have QNX in there as like the trusted fundament, while we also support Linux. I think the Trustable will evolve. Uh, I was talking to Tilo, hopefully maybe we can get a little bit closer with personal thing again, um, for the open SLVD, this could be maybe a

good citizen for using Trustable and bring it together with us, Carl. Let's see. But we are not refusing or so to use, we just focused on the past before. And we started before Trustable started in the open with our partners, so yeah. Okay, thank you. Thank you so much, and with that, I >> Thank you both.