Towards an open source, functionally safe software stack for the software defined vehicle

This talk features Dr. Oliver from Elektrobit, who discusses an open source functional safety stack for software-defined vehicles. He highlights the integration of Eclipse S-Core and Elektrobit Corvus Linux, aiming to facilitate safety-critical automotive applications. The speaker emphasizes the importance of OS integration, developer experience, and certification pathways necessary for deploying systems based on S-Core. He outlines the challenges and requirements for integrating various software elements and operating systems, focusing on hardware and process isolation. Dr. Oliver also showcases a demo involving a development container to streamline the process of testing and deploying applications built on the S-Core platform.

Uh good afternoon to you all and um a warm welcome. Um we would be closing the doors in a couple of seconds and uh I would like to say that like you know if you like to sit down you have a couple of places around. Um it is my honor to actually introduce um uh Felipe Presado uh from Right Com AG and also an ambassador to um

Eclipse SDV um and for Eclipse SDV um to the stage to as a moderator. Please welcome. So thank you very much I mean uh good afternoon everyone. I hope you are enjoying OCX. Uh so and if you are happy with OCX feel free to post online on LinkedIn on your social. Uh tell us how you are feeling about it of course as an ambassador of Eclipse SDV

I value a lot of the feedback and so we are all working to make this a a great event for all of you. So it's my pleasure to introduce Dr. Oliver. He's a senior expert for HPC and Linux uh systems. He works at Elektrobit and is going to be here with us to present an open source software stack designed for uh safety critical automotive applications uh based

on one of the key projects of the Eclipse Foundation on the SDV working group which is a Eclipse core uh and of course with intersection of Elektrobit Corvus Linux for safety applications. So Dr. Okay. Thanks everyone for joining in this session. I know I have strong competition in the AI track so thank you that you are here. Um I will be talking about as you see it

an open source functional safe stack for the software defined vehicle. Um I will of course pick out a few um aspects of it and talk about that not about the big thing and everything, right? That will never work. So, um I'm just a short So, um 20 years of more or less professional experience in software development. I have not always worked in automotive. Um 10 years I

did. Um I've used open source and work with open source since a long time. So, then basically joining AS Core is coming back to my my roots of software. Uh I joined soft AS Core last year. I'm a committer since this year and I'm many or most contributions are around OS integration and uh developer experience and that's exactly what I will try to emphasize in this talk.

Um So, what's the agenda? So, as I said, um the first thing I will try to is um look at the AS Core documents, um look at the the the aspects that are relevant for OS integration. So, basically the lower layers of AS Core. Um focus on safety applications, of course, because that's the point. And then map this to a Linux-based OS targeting safety applications. Of course,

I will use an example, which is our operating system, but I think in general, so always when there are specifics to this I think you can abstract it, right? So, this I I believe many of these things are somehow in one form or the other applicable to any operating system that you would like to introduce, right? So, that's that's that. Uh and then the last point is

developer experience, which seems a bit separate, but I think it's not. So, first thing down here and the rest there. I should click earlier. Sorry for that. first point. How would AS Core look in a project context? My take on it. So, you want to use it for serious production, so you take selected subset of modules from a platform release, preferably of course from a stable one,

and then integrate these into the specific environment, and the idea is that you have a a significantly less effort to implement and certify the solution because many parts of this went much work went into implement implementation, of course, here. But, a lot of work went also into cleverly preparing certification. So, this is where where ASCO, I think, is is really giving you an advantage as as a

consumer, right? So, how does that look like if you would choose a Linux-based OS? Um seems seems trivial because of course ASCO is being developed mainly on Linux, right? But, this is now the question, can we use it on a production system? I will be focusing on these aspects. There will be talks, I know, today which will be giving a bit of a a bit of a

broader introduction to ASCO in case you don't know the the whole system, how it works, how open it is. I I'm I know there will be talks about exactly that in this session later on. So, don't expect that from this talk, but that's I will have a different focus. So, for the integration of external software elements, there are is a model in ASCO which we have given

ourselves, and one of these external software elements is now the operating system, right? One one example. Um three-level model. No community is the first one that you can achieve, right? So, there are no guarantees, best efforts, your your module is mentioned and is maybe integrating in the CI, but that's that's actually that's actually it. There is some place to go for reporting problems, but that's that's it.

Some kind of preview. And this is the first step that you can reach. Um then there is a second level of integration, which is Eclipse S-Core. If you put it on a system, so in this case of course operating system, it functionally works and it's shown in the CI and uh S-Core acts basically as a integrator on in in in in the CI and makes sure that

it functionally continues to work. So, basically if you change a module, it should not break um the integration. That's the second level. And the third level is then of course it they build on top of each other, right? So, I actually have a funny funny animation here. Last one is certifiable. If you if you achieve the first two and now you can also show that um the

paperwork is correct, no? That that um all the assumptions of use of S-Core are fulfilled, of the operating system are fulfilled, everything fits together, nothing is missed, uh all tests have worked, all evidence is there, and so on. That's the last level. as I said, one important special case is here the external software element is an operating system. And that's what I will uh focus on, of

course. So, I I now um need need to understand what is important uh from S-Core and from the requirements, from the from the modules, from the features, from all the aspects, how it is documented. What is important for this integration, right? What do I need to do? What do I need to focus on? What do I need to look at to be able to do the integration?

And that's what I will try to explain now um because I think it's relevant um especially when you consider that there should be multiple operating systems supported by ASCOT, right? You want to integrate there or there or there, right? Not just one choice, but multiple. So, you need to make sure from the start that this can work. So, this is I think a relevant analysis. Um I

mean, for some it's maybe obvious, not for others. Um I think there are some caveats. So, let's take a look. and then I will try to sort the different things that I find into the different levels. So, what is relevant already to achieve even community, right? And what is relevant to achieve functional and what would be relevant to achieve a certifiable level. So, to sort them in

a if you want in a road map, right? What do I need to do first? What do I need to do second and so on. I'm now going through a few aspects and if you I I'm not sure if the slides will be available. All of these things are links into the ASCOT documentation. So, um direct correspondence to that in the ASCOT documentation. So, for example, um

there is something that is called assumptions on the environment. Um there an external health management is assumed to exist. A safe hardware platform is assuming or assumed to exist, right? So, when I put ASCOT and now I'm talking about this green boundary, when I put it into an environment like an operating system and it um probably the SOC, um there are assumptions. So, safe hardware platform, process

isolation is assumed to exist. You must your environment must offer this. So, this is clearly something that you need to know and that you need to accommodate for, right? External health management, I would say is already important for functional integration because this is really important if it's if your function if your system isn't integrated even with the external health management for a safety system, that's nonsense, right?

So, you have to do Um safe hardware platform, I guess what one could always debate now, but I would say you can put it here into the certifiable level. Um usually they are not direct I would not expect much direct impact of the hardware platform now on S-Core or on the integration. Um if you choose the wrong one, it will not work. But uh and you will

not get your certification, but if you choose the right one, I would say that should work. And process isolation similar, I would expect that the on environment does this properly and you do not have to do extra stuff in the integration. So, that's why I put it to certifiable. this is now some kind of special thing. It's not just the S-Core itself, which has the green box

bar, but the individual modules are each a safety element out of context. I mean, never mind the busy slide with the with the text. I'm sorry for that, but um I will explain it, right? The each element is a software element out of context. You can choose you can pick some of these. Maybe you want to replace module A for whatever reason in your product or in

your project with another module with a proprietary module. Who knows, right? But you need to of course then fulfill the assumptions that make them fit together. So, this is what you would have to do. Um for my analysis, I'm of course not not assuming this and I I I assume only S-Core modules. Um what is important maybe is some of these modules could have in theory also

direct assumptions on the environment themselves. So, this is how the documentation is structured. I couldn't find any until now. Just to make you aware, um the the all the So, there is no module that in only has local assumptions on the bigger environment. It could have, but it doesn't at the moment. Okay, so we can disregard this part. then there are now integration relevant stakeholder requirements. So,

this is a different type of documentation in ASIL. Um and all of again, all of this is links and I don't know if you can if you will get the slides, but in anyway, you will find these things in uh open documentation on GitHub, right? So, everything that I show is is clearly open. I mean, one of the big advantages of ASIL actually. So, also the requirements.

So, for example, operating system uh shell support uh POSIX operating systems. That's basically what it says. Okay, this you always need, right? This is what you can expect. Um you must have the programming languages that are used by ASIL, which are mainly two, C++ 17 and Rust. So, this already for any integration, you will have to have a compiler, right? sounds obvious, but maybe it's not so

simple for safety system, right? So, okay. Um processes and thread management um in the end, there is a requirement of course, the first process, so for example, the launch manager, which is a component of ASIL, must be launched by the environment. So, this must be done for functional integration, quite important. Um there is a table of safety mechanisms and I picked out a few. Safe safe a

safe software platform state. So, some unrecoverable error occurs and now the ASIL life cycle has detected this and I would expect a test for this, right? That you have a test that shows that this works. Um that this is then reported to the external health monitor and external health monitor here means again, the environment. So, there is a clear integration requirement that you Right? Your the ASIL

system has to needs to have the ability to report to the external system, "Hey, something then went wrong." and this must work. and then, okay, state-of-the-art safety mechanisms to check hardware and software errors by using hardware or software OS-provided features. I think this is something openly formulated, I think this can be looked at in a later stage in the now that was the requirement level. Now I'm

looking at a few modules. Uh I I don't know if you've ever seen this picture, probably not, so it doesn't really matter. So it's um I guess a maybe an even outdated list of modules that are existing in ESCORE. And also this, you go to the web page, it's there, right? And probably even in an updated version, so that's nothing nothing special and I see that my

color coding doesn't work on this monitor. I will try to I will try to fix that. So of course I didn't use white to to indicate the potentially relevant modules that have would have been nonsense. So, let me try to fix this. Um starting from Oh no, I think I even have slides for that, so I Ah, it's fine. With that it's fine. So, one quite important

part of of our ESCORE is the communication mechanism. Um and there are the IPC binding for it. Um it If you look at the description of it, it uses memory shared and message passing, which are some some modules uh down here basically. So that's fine, right? Down here means there is a basic library, which is also part of ESCORE, which gives abstractions that the rest of the

platform can use. And this this part here or sub sub parts of it are actually doing the mapping to the operating system, to the concrete operating system. So here is also where um actually an OS abstraction operating system abstraction layer called module lives and file system and time and concurrency. So, things that are really tying the system to the or the S core to the operating system,

right? There you need to closer look and I will come to it. But now, for example, here Lola it's higher up in the stack it should use certain methods from base libs, which would be fine, right? So, no dependency to the external environment. There is also something called OS RAM FS and they are using some system calls and ACL so access control layer is of the operating

system. So, there it's getting a bit tricky, right? All of this, of course, needs to be supported by the operating system under under it in the end, right? Through libraries, through through system calls, through something. There there is the the glue. And that must match, right? Now, I cannot simply say, "Okay, I can I can use all of this like I want." That's the point I'm trying

to make, right? You have to be clear what you use, how you use it, um clear architecture and clear location um of um of your tie of your glue code or binding code to the operating system. And you have to pay attention there quite early during development, I would say, because the later you do it, the more expensive it gets to to fix things if they would

not match. But it's easy to get this into a state where it only works for one system, Um so, that's actually needs investigation, right? Already for the beginning, okay, maybe it works. It will work quite easily because, as I said, Linux is already being used as a development system. You can run S-Core on it, no problem, from the start. But, if you go to certifiable, hmm, let's

see. And that's actually the point I'm trying to make. Then, another thing, launch manager, and and this area here, life cycle, clearly has a tying up to the operating system and to the health monitoring, right? So, there explicitly you need to implement something. And that's even in the architecture, there is things that you have to implement something called the watchdog proxy, never mind what that is. Um,

launch manager needs to be tied up to the external health monitor. This kind of stuff, it's already described. Okay, that's fine. Um, what comes Yeah, that's Ah, sorry, I mixed it up now with the health monitor, but that's okay. Um, um, sends signals to launch manager and so on, uses IPC, should be fine, and then uses lib ACL, so there is a usage of a certain library.

Hmm. You need to be able to say I mean, this one is then certain suddenly part of the application that that runs here. This is an application that will run on your system. It's part And this is this library is suddenly part of it. That means it's part of your qualification. Is it safe? Can you use it? Hmm. Needs to be looked at, right? Um, and similar,

I think I can skip through these now. Um, it's similar for other aspects, right? So, for example, here the There is explicitly a module called operating system abstraction layer, and it uses certain libraries. Works already, but for certifiable, this needs to be investigated. If if you have all of these in your final system, if you have all of these, um, so that you can actually use them

safely. Same here. I I will skip over this. It's um, same argument, basically. Uh, for time, there is not yet any implementation, but I would assume for example that there is a connection to real-time clocks. So, maybe maybe there you even end up with hardware dependency, but let's see. Um it's uh being pitched at the moment. So, summary, I guess I don't need to go through all

the details again. The idea is always the same. For certain things, for certain functionality, it's quite um easy to reach. Then, for especially the area of base libraries, interprocess communication, shared memory, where it's getting closer to the operating system, you need to pay a close look. Um and it would be probably good to do it already now. um it remains uh open and and usable. Okay. Next

page is similar. I think these are actually not so critical because you have to implement them anyway. I mean, there is a clear extension point of S-core for the reporting, right? As I said, health signals and so on, that's no problem. File system probably again needs some investigation, but that's all. there are certain features upcoming which are not yet implemented in S-core, but you can see the

feature requests already, and I think they would have connections to the environment. So, for example, cross-VM communication extension. I'm not sure this is the final name now, but there is an idea that your S-core not just focuses on one OS instance, but you have a communication across multiple. And there, of course, you suddenly really depend on the environment. Right? You have two instances of operating system, how

do you do the communication? It's not longer or the setup of the communication, it's no longer the the question of only S-core, it's certainly the environment. now come to the mapping and I guess I need to pay a bit of attention on the time here. So, um mapping to a Linux for safety applications. Now, I have all of these inputs and now I need to map it.

Um I will use a certain nomenclature, so let me introduce it quickly. So, Linux for safety applications, I mean here a Linux system that provides a dependable execution environment for safety-related functions. I will use an example, but I think it's not so important that it's this example. Um you could the the the necessity is there for many or for for all of these, right? Then I what

I call high integrity applications are applications which execute safety-related functions. High integrity virtual machine means it's a virtual machine that is able to execute such functions. It doesn't mean that the I mean this usually gets people get it wrong. It doesn't mean that the VM itself needs to be safe. Um and low integrity is the rest. So, let's put it like this. how can it look like?

I have here um a typical setup with a low integrity virtual machine. There is some Linux kernel or whatever kernel applications running running on it. I have a second virtual machine. So, of course I have a hypervisor that uh separates them, organizes the resources, and so on. That's the usual thing. And then I have on this one um I have a kernel for Linux for safety operations

and I have a high integrity applications, platform health manager, um the usual things that are there, and of course hardware. And um yeah, here you can see what are dependable components, what are not dependable components. And um the key parts here is uh yeah, usually ex- methods of the CPU are used to isolate things horizontally and vertically so that you can actually say uh um or separate

the resources clearly, right? On hard based on hardware. So, that's the that's an important point. So, how does it look like now if I put a minimal S-Core on it? Of course, it looks like this. Right? So, you have you the platform health manager, I think that's the term adaptive autosar. So, that is the launch manager. You need to implement the watchdog proxy, which is not a

part of deployment specific. For testing, it would be something for re-product, it would look a bit different, but you need You can put more applications. They will report health there, and then you need uh there is a detail again. And for the specific solution here, you need a health signal handler, which basically receives something from this. There's a connection, and reacts when something goes wrong, right? But,

that is in the hypervisor layer in our uh in our solution, so that basically the reaction to health problems is not with the virtual machine anymore, right? the the machine is out, it doesn't it doesn't work anymore. So, what do you do then? That's here. Um a bit of details on the isolation, you will see later why I'm going into these details now. Oh, wrong button. Um

there is from the previous picture basically here, you have a high integrity application, which is connected with Um another one, they talk to the launch manager. There is an isolation going on based on hardware between these. Um and the launch manager and the watchdog proxy have a connection here, and the kernel is isolated as well. And the hypervisor is running of course the system. Okay, so um

Linux kernel is isolated, can be updated at the speed that you want. So this is for example important for safety security updates of course. You will want to update this thing. Of course also the software but also this one. I think that was mentioned in other talks as well the importance of this. you have with this some freedom of interference temporal spatial communication shared memory is protected

so maybe I don't need to go into these details now. The communication between what? High integrity applications here they can communicate of course. They can do so securely and safely and this is also guaranteed by the system and startup integrity of course there's also so you need to secure and safe boot otherwise the whole system is not secure and safe of course. So now mapping these aspects

what I presented in the first part right the aspects of S-Core now mapping them Let's go through the different categories and see how that would work. So basics. Eclipse S-Core supports ARM 64 so that's one of the statements so it's also linked here. This Linux for safety application also requires certain ARM 64 features. That's how it is right that's a technical choice or technical implementation so that

looks good right good match good match in this case. Um details need to be checked of course there are always details right but in general this looks good. POSIX OS of course not a problem. Programming languages of course you need then C++ and Rust compilers for Linux arm 64 and base libraries and so on to make this work, right? There is a significant effort that is actually

part of S- Core to at least for the Rust compiler because this is there, of course. We know Ferrous Ceedling exists, but it's just a compiler. The libraries which you use must also be part of the qualification and tools like code coverage and so on. So this is an ongoing process, but I think it's going on well. Which is actually part um of of some part some

efforts of this are driven by S- Core. Let's put it like but of course there are also other open parts. So arm compiler LLVM qualification group which is trying to do an to work on qualification for the LLVM compiler in the open and also this is a link and then the Rust working Rust special interest group. So work is ongoing, maybe not completely finished, but okay, looks

good. And I think there was a thumbs up for using Rust for S- Core earlier this year. Basically the analysis was concluded and people said you can use it it will it will not be a blocker in a later release of S- Core that we have used it, which is good, I think. third-party libraries These are used at the moment. I think maybe even more. I'm not

claiming an exhaustive list. They exist for Linux, of course, right? and this is sufficient to just make it work. For certifiable you need a qualification or replacement or some method. You need to deal with this, right? Because if something is part of application execution, then it needs to be qualified. That's simple as that. So, I would say this is a detailed analysis that must be done. Um

file system concurrency similar if they map basically in the end to libraries or to certified compiler libraries. So, something like the the standard library that comes with your Okay? It's not? Well, again something to look at. And now um process isolation. So, in this case is done based on hardware. Um but a price I don't want to say. It's a implementation detail for this specific solution, right?

And then again I'm using this as an example. I guess every system has their own specifics, right? And you always need to look at the specifics. So, here it's like this. You cannot simply allocate shared memory just like that and say, "I want that this process talks to that one. I will I want to set up some shared memory like I Because this boundary here is there

to protect the applications from each other. it needs to manage the connections between them and needs to, for example, set up the shared memory that you get configure before. It It does the setup already. So, it needs to be checked, for example, that the S-core IPC implementation can work with this kind of stuff, that it gets the shared memory set up already from the start. It cannot

do it just on its own. Um there is a detail here which needs to be checked. Similar here. in this specific solution um of course each HI process as I said high integrity process is isolated from the kernel. So, the kernel cannot write to it. No way. Physically impossible based on hardware. But you want that the kernel can write to it. You want to make system calls.

You want to read data. You want to write. This is how it works. So, um there must be a way to do it and of course there is a way to do it, but it means you cannot freely choose whatever you want uh from the from the big market of uh system calls that the the um the kernel offers. Many work. Any can make can be made

to work, but it could be detailed work required. If a certain system call that is not yet supported, you need it. Okay, then it needs then then needs to be talk and needs to be in in analysis. Um again, this is some some detail of the system, but there are always details, right? So, this this if you want that seL4 runs on a certain operating system, you

need to look at this. Um if you want that it is really in the end qualifiable. similar here. Okay, this is uh shared memory communication. I will skip it, but it's it's similar similar thing. And here for startup and health, I think this is relatively straightforward because you simply need to implement the watchdog proxy and so on. Okay, that was already foreseen by the uh by the

designers of seL4 and and no problem, right? You just need to do it. It was already clear from the beginning. Uh secure boot, yeah. Let's skip over it. Okay, so um summary for this part and I think I need to be quick with the next community level is already achievable. I think it's even achieved for this one. Okay, that was not difficult. Functional level to get this

running, launch manager integration to system startup. So, of course this needs to happen, right? So, you you you start a system that claims that ESCo is running on it. Need to launch this. You need to have the watchdog proxy configured or implemented correctly uh in a way that it works for testing or for example for the uh commercial variant where it looks a bit different, but in

the end it's always um an implementation of this. The integration tests and the minimum of that is of course on an emulated system, which which is um at the moment basically QEMU running on reference integration. And the reference integration, when I say this, this is an actual repository in ESCo that does the reference integration of all modules, right? So, and there there these things are existing. Okay,

so community, I would say check. Functional, I'm working on that. Uh it's not complete yet, especially in this area here, but I think this should not be a problem. Interesting, it will get here, but that is let's say the the the the step after. Yeah. It This will be a challenge, but that's how it is. Uh otherwise, we cannot claim that it works. Um because there, yeah,

you see it, The the library usage, system call compatibility, setup, startup, tracing, reference hardware, blah blah blah, all all kinds of things. Development experience, I think I will cut short here a bit because otherwise, I will run out of time. to give a demo here. And that's where I will simply conclude because I think this is quite interesting. So, as I said, there is a repository called

I hope it's readable. Um that is where things come together in my own understanding. That is where the modules are put together, tested together. There are demos. There is a deployment on different operating systems. And the best of course it's open source of course and you can just use it and you can start exploring here quite easily. I mean this is of course some some showcase but

still it is working. So for example, you go here, you have a GitHub account, you can go to code, you can go to code spaces. You can create a new one which I would have to do now, right? Create a code space. But I will now reuse an existing one. So now I'm cheating a bit. I tried this yesterday. So I will open the existing one because

um you will see in a second. So let's see. It's This is how it will look like. It will start what is essentially Visual Studio Code in the cloud. Um one of the aspects that we have been contributing to S Core is a development container. So a Docker container that contains let's say not all tools yet. I would claim it would be a good idea but not

many tools that are used in S Core, especially the ones that you need to And that enables you to simply launch this wherever you want. Uh of course this also works locally on your machine when you can launch containers, right? You get to get clone and then you do whatever I I just did. Demo effect here or Ah, network. My presentation is also coming from the network,

but okay. I was fearing that. I am prepared. Yeah, should have worked then. Didn't work, but it would look like this. Right? You saw this screenshot. now it's a Now it's the second best to demo this is a screenshot PowerPoint slideshow of a demo I did I I recorded. So, it looks like this. Um it will start the development container. you can you have to click away

a few warnings or whatever. Um then, at some point you will end up being able to do this. And the simple thing is score starter, so that's a command that is part of the repository. When you enter this, you will get a little menu where you can choose the operating system that you want to try out, that you want the demos to be deployed. I highly recommend

the third one, but the others are fine as well. Um what it will do is build the whole in the cloud in this container. It will literally pick out the latest source code from all the modules, build it, and yes, that sounds time-consuming, and it is. This is why I prepared or tried to prepare the the demo. Um then it is build it, put it into a

system image, and it build it, and it will take several minutes, and you should end up with something like this, which is the starter uh kit or the the starter uh executable. It's called it's just a showcase, of course, right? It's not the real S-Core or anything. But, it uses several modules, so you can, for example, here, pick uh from a little menu, you can select examples

to run, and and then start it, and then it does, for example, here, some little communication example with Lola running on an emulated ECU in the cloud, in your browser. And I think this is really a fast startup. And I I I checked with the guys from Theia, and I think that would also work with them, just that they're not having this tight integration. And they do

not have a open or there is a not the direct start like this, but it would work. So, you can use Eclipse Theia as well, which is, of more natural choice, maybe, here at this conference, right? But, yeah. So, last slide. And I skipped a bit, but I think that says it all. I think no unexpected challenges, from my point of view. There are challenges, we need

to look at it. There are open points that need to be need doing and watching already now. It would be better the earlier do you do it that the better it is, right? But, it is not unsolvable. Um steps are outlined, I would say, and leading over to functional and, hopefully, finally, also certifiable So, I think that's good the case, and the developer experience I had to

skip a bit of it, but I would say the emphasis is here. Entry barrier is really low. I mean, everyone can try it out. It's a showcase, but this the reference integration enables you also to get a workspace with all the modules, you can literally change lines of code, run the build again, and it will get deployed into an emulated ECU. In the setup I just showed,

it's not much work. If you have any inclination to software development, that will work immediately. I think this is really a good thing. Okay, and with that stop. Thanks for listening. Thank you, Oliver. I think it's a pretty impressive body of work done in a collaborative way in the open source. Um I would like to ask or invite the audience for any questions. Hi. Thank you. Really

great presentation. So, one question to this EP corpus. So, is that also open source or is that only an image alone and Um everything is running? The the operating system, you mean, right? Okay. So, the part that is being used here is a variant. It's not the commercial Um it's called a fast dev variant, which will give you information about the system calls I mentioned earlier, right?

So, you get basically warnings when you use one that is not yet supported, let me put it like is not yet open source, but this is more technical reasons. We will open source it because it's obviously a patch to the Linux kernel, right? So, you need no need to mention anything else. Um this will happen. The commercial variant, which will then include also the hypervisor and so

on, it's not open source, I have to say. I mean, I would really like to give a different answer, this is where investments have been made and so on, right? So, it's that's how it is. This part is a commercial product, yeah. Thanks. But this is part of the Yeah. But this is part of the answer to the session from Sven Erik earlier today in where is

still money to be earned, where is the business model for whom collaborating in Eclipse S Core exactly in these kind of ways. So, we do you implementations, we do have a full stack. You can start, but for sure there are things that the company is not willing to give out, but to license in order to get payback on their investments. Exactly, yeah. That's that's part of the

answer. I mean, we try to give something to ASCOT by for example, doing this integration. I think it's valuable to the middleware. But of course, on the other hand it's integrating with our product, yeah. That's how it is. Any more questions? I have one. Please. How far are we from having a vehicle running on ASCOT? Powered by ASCOT. I think I'm the wrong guy to answer The

the there will be more presentations on ASCOT from people who are not more knowledgeable on that, but I I think the goal the vehicle that runs it on the street I think it will take a bit of time still. The start of the project that aims for that, I think maybe not so far away anymore. I think there are some ideas to get this, I don't know,

end of this year and beginning next year to at least start with something. I would not expect that every ASCOT module is used right away in the first project, right? But at least some parts. Full support for for the answer, but next step to go there is the hack fest at the Hochschule in Esslingen where we do have support from BMW, Mercedes, Porsche uh bringing vehicles, bringing

automotive hardware in order to start integrating on on on the automotive hardware. Far away from being certified or certifiable, but going exactly steps into that direction. I have a more now let's say technical question. Uh so, you explained on freedom of interference between the components in the early part of the presentation. You said you can pick modules from ASCOT. Mhm. Um maybe you can reiterate a little

bit on the freedom of interference with here. So, what is Mhm. already there and what will be on the integrator user side to re- evaluate on when you take such few components and and mix it up with some others and Um the parts that I mentioned were freedom from interference guaranteed by the operating system, I have to say, not by S Core. So, um for example, the

health manager and so on. I have to say I'm not the best to answer that for the details of S Core. I can I can say something for the operating system that I mentioned, but that's really then one detail. I'm I'm not sure you're asking for that. I more or >> Yeah, yeah. So, in in the first part of the presentation, you can pick modules and then

later I missed a little bit what you have to do if you have picked on the freedom of interference between the S from modules. Then >> It's Okay, between the modules. if you would deploy it to this type of operating system and it's different processes, then at least specially they are separated, but that is not a feature Um if you make them communicate again over shared memory,

then you will need to use, for example, the communication framework that comes with S Core. And if you use this correctly, then I think it will give you freedom from interference for for this communication, right? >> Yeah, but you have to certify it on your own then. And the I I It's out of the box. There will be support for this. This is a part of the

promise from S Core that you will not have to derive all the test cases and all the requirements and specification everything that you need. You need to derive it again from your own? No. Um, this comes with the the open source product, right? And we'll support you in this process, but of course the final certification of the concrete system in context in your product. Yeah. I just

want to Sorry to interrupt everyone on the great conversation. This is exactly why we like to have Eclipse and Eclipse Foundation and the working group. I invite you all to meet and so that we keep the schedule so that we can have our next speaker on the stage. Again, thank you Oliver for the great presentation. Thank you for the audience of the session. Thank you very much.