 So, we're just at the start and we can now see how Linux is used in the system context. And what we did with Elisa then also, we looked into this Linux and tried to figure out what are Linux components, what are features which can be evaluated for safety. And then when you are looking into this feature set, you also need to make sure that you identify the gaps, maybe, which are in there and that there's more work to do and we'll see what kind of gaps could be in there for Linux specifically, but maybe also for any other commercial operating system or a real-time operating system, which is for this. Let's take a look into certain challenges. If you think about Linux and safety critical system, you can see all the benefits which Linux brings from the traditional ecosystem. You have a very large possibility of using Linux. There's a lot of devices out there and you already know there's a bunch of security feature how to harden your Linux kernel and also your Linux surrounding. This is something which can give you a large benefit because recently more and more products get connected and so get the safety products connected. And then if you see the large computing base, we have a good multi-core support, multi-level caches, large amount of caches, memory can be handled and it basically runs on almost every hardware. And another thing very nice to see is that we have experts and that we really have an exchange so we can go to maintainers and have a wide set of community discuss issues to discuss things to get an exchange. But there are a few capabilities which are not yet fully in the Linux part. If we look into it, safety critical traditional OS, typically it comes with a hard real-time capabilities. You can always argue what means hard real-time. There are the preempt RT patches in the Linux kernel so you get more real-time. But still it's not in the, maybe in the microsecond range or whatever you consider and so there's something which the traditional authors claim and they have been developed with safety in mind and with the safety compliant development process. This is actually one of the large challenges which you have. So even if you say that you have good concepts, it's quite often the first question is but have you developed it according to a certain process? So we're now up to challenge these differences and see what can we change about it. And we're a large group already now. We have a good set of members within the Lisa project, we recently have the Boeing joint. So they formed the aerospace work group. I cannot say too much about it yet because just in the starting phase, but if you maybe from aerospace, maybe you can even start then and join. So it would be a nice thing. We have, of course, Retta, Toyota, Intel, BMW group, which are all strong in there. And a large set of general members where a lot of workforce also comes from. You can see from the associate members that we also work with the automotive grade Linux. We use also the demo, we'll see this later. And we also have industry support. Here we can see the CIP project, for example, which also support us in the future. You can be part of our safety paths. You also have the OZADL in there mentioned. This is a smaller group. It was a CIL2Linux MP project, which exists in the OZADL before. And that's where we are going now in there. So if you want to learn more about Linux, get about the history of Linux and safety, you can also read some of the wire papers from OZADL. And you see the base from where we kicked off in May 2019. But it's also important to understand that even if we work on a path forward, we cannot solve all the problems for those who are building the product. So what we cannot guarantee is when you use whatever we are doing, that your system is safe. This is still the responsibility of the person who creates the final system and we are not doing it. We are enabling Linux, but we are not creating a safe Linux, which you just download and use, have it safe. It's also not easily possible. And then if you take things we are doing, we can also not make sure that you use the described processes and methodology, because this is also still in your responsibility. The third point, which is very interesting and I guess is becoming more and more important is that at the point where we would create an out of tree kernel version and say here is now our kernel version. We will maintain it forever. We cannot do this because there will be updates either for security reasons, for certain features, functionality, hardware support. So you need to move forward and this would always mean a re-certification. So therefore, keep in mind, if you have an upstream first, mainline first approach, this will be something very important to challenge also because the traditional product development also for the RTOS was fire and forget. Basically to the safe system, it's safe. There is no update. There is nothing needed in there. So at the point of production, you safely ignore whatever comes later on and this does not work anymore for all system, for Linux based system and also for RTOS based system or traditional safety aspect, right? And in the end, of course, you also still remain responsible for the legal obligation, the liability and so on. But we can bring a large step forward. It just means we need to collaborate with the industry. We need to collaborate with partners, with authorities and for this, we created the mission. The mission as such focuses on elements, process and tools and this should be amenable to safety certification. So a lot of work is done on software documentation. We check how these development workflow can look like and how later operation and adoption of the project can be done in the company. So if we see, we tackle this in the workgroups and the deliverables which the workgroups provide are a set many elements software, I would say everything which is related to Linux in the product. So this is a large set of the elements and to create your artifacts of the Linux, you need to have a good process description. So you need to see that the open source development process fits to a good set also to what you have in your company and maybe you have a set of process you follow the V model. So all these kind of things which the ISO may demand and we need to find equivalence and show that it's at least as good as you know already do to me. Then you will make use of a lot of tools because the better tool support you have, the better you come into the continuous integration, continuous certification parts. You have support for testing for analysis. So tools is a crucial element and all these things, if you start new on a project, need to be documented. I guess a lot of you have tried all things and figured out if the documentation would be better would get much forward. We're doing this in the workgroups as said we have currently eight workgroups. There are vertical workgroups which look into use cases. So the main party of this presentation is the automotive use cases group. But we also have the medical. They work on an open APS system. It's an automatic battery system and for diabetes type one. So here it's an open source project which was created without safety standard or medical safety standard but found an open source community and we're doing a lot of analysis in there and try to figure out what could be involved in their tracing workloads and so on. And the aerospace basically takes care just found it taking care of everything which flies seeing as what's the base description and these ideas and demands requirements which we have from the use cases go into the different cross collaboration workgroups. So the open source engineering process basically checks which approaches can be used. They guide us a lot on the system theoretic process analysis and help us to understand what we're doing. Based on this the safety architecture workgroup looks into specific elements of the kernel. They try to understand subsystem involvement on based on the use get bus more on a general case that you can later on use it for other applications as well. The Linux features they are looking into things if you know security parts you may see groups namespaces and some of their typical mentor access control the typical elements which you know I'm doing this to make my system secure. If I ask you the same question for safety it's not yet established and it will also be enough to just use this methodology as we said on the other slide but it will add certain elements. The systems workgroup then tries to combine these and bring this into a reference system which is downloadable running in a CI and being experienced with it. It also goes on a wider scope integrating more domain so that the architecture which you're drawing is looking more like real products. Tools investigation and code improvement they started hosting our server where CI runs they host tools like code checker, syscaller and so on and all these things then get documented either as source code deliverable in GitHub or we do certain blog posts to promote the work we write white paper put things on the Google Drive which is all publicly available and linked from the different workgroups and by this we come into Elisa deliverables and yeah going back to the four different topics not every workgroup is working as active as the others so what you can see that there are many workgroups which focus on the elements and software but as the process is more generic the main driver is the OSAP the open source engineering process workgroup and they also collaborate very actively with the medical devices workgroup. Tools are also coming from more directions so tools are getting created here and there because you find something handy you find something useful and shareable so this goes in there and then of course every workgroup works in documentation. You miss the aerospace in here it's basically because they just have been formed and start to write things. To give you some examples on what is in there we have for example the META ELISA layer this is the layer for the AGL demo. We have STPA analysis information so STPA stands for System Syratic Process Analysis and this is the methodology from the mainly driven by the MIT and it helps you to structure very large and complex systems and it's much easier if you know what the HARA from the ISA 26262 which is a health analysis risk assessments or FMEAs this gives a more graphical structured view and it's very helpful if you don't know all the system elements by detail yet so there it can be an additional part and it can be easily incorporated into your development process as an additional element. Some tools are what we use existing tools like code checker and run it against the kernel or another existing tool set is for kernel tracing and we especially the medical device wrote a longer white paper on how you can use different trace tools like PERV to figure out how a workload is used in a system which subsystems are called within the Linux kernel and yeah something completely new was a call tree tool this was developed in architecture where they figured out they need to understand which subsystem of the kernel goes into which other area who is calling which next system and this is then ended up in a call tree it's also on our GitHub and I said all the things which we are doing are getting documented if you look into these different parts in the workgroups they also contribute to a system we have also a mini summit on Wednesday so you get much more information there if you not have yet registered take a chance to register it's ten dollars cost by I guess it's worth the money and yeah what we can see of this is we work in the systems work for example on the largest set where we try to build up a system which involves also an RTOS hypervisor because it looks much more like you know from software defined vehicle maybe from other industrial architectures so it's actually also driven by an industrial use case real-world use case and we know and how the things and by this the use cases contribute to the Linux activities the architecture brings in things to clean up your parts features could get into the Linux and tool investigation code improvement goes into multiple folds items and the engineering process is surrounding around everything so that we common have a common element and you find things in this just to mention are we also collaborating with different other open source projects in the safety critical space so there's success projects where we regular meet with we have the sapphire integrated in there because they all provide a safety pass and depending on your use cases may be also a good thing to look at and as George Bernard Shaw has said if you haven't Apple another one has an Apple if you exchange the Apple boats have still one Apple but if we exchange ideas you have idea I have an idea then at the end we come up with two ideas and this set also on the wider scope we work together already long time since the beginning with the automotive grade Linux we see that there is now the Eclipse SDV movement and there's a Sophie from ARM and we see a lot of automotive players in there so we also reach out to them a little more on the importance just so there will be the keynote from Kate tomorrow she's talking also on how the different ecosystem parts are needed how security getting more important how safety plays a role in there what it means so IOT so this just said on this and finally we come to the details of our use cases we have a dashboard use case within the Lisa automotive workgroup so you know most like these instrument cluster quite well and if you own a car and if you're an old car your instrument cluster may be based on LEDs it turned over into our digital science maybe this is the first step from software defined vehicle right because the software defines what's happening next and this could mean there is more responsible to the operating system and as you want to centralize your traditional instrument cluster maybe with your infotainment hat unit similar like the AGL guys also bring demos together these days you see that more and more software involvement and she may ask the question isn't this something which I can purely base on Linux and this was also already you know the main thing was that we want to use it to derive safety requirements you're quite convinced that the safety requirements are very similar also to other use cases because the medical may serve the similar demands and also industrial areas and more complex use cases like others what's interesting about this telltale is I can tell you it's about this warning sign this check engine sign the gears thing and you directly understand and this makes it quite good to draw system architecture and also to explain to us so we don't need too much time on this another nice thing is that we can start without the real time kernel extensions because it would add a certain level of complexity but we don't need it yet because we can still operate with a watchdog mechanism and say we have a hundred milliseconds 200 milliseconds until something should be shown right and yeah how we have done this we have recently ported our instrument cluster demo to needlefish you see this mark there was a danger sign this is something where we created the signal source control list and by this you can corrupt the message which coming via can you can also trigger a save state which basically would trigger to reset and reboot the system and this is something which when we did it on Qt or Qt because we started our work on Koi but this time there was Qt so we are not yet on flutter I guess it's the new thing but I'm pretty sure from the underlying if we go down to the kernel and the interaction with the GPU we end up at a very similar state I'm not the flutter experts if someone wants to correct me please feel free and for now we will also stick to the Qt we may go over to flutter over the time but we have from the resources we're looking for volunteers to go to flutter but for analysis it would work out and this is basically how we start the activity we came up with a demo and we wanted if we figured out we need to understand more so we were using STPA and start to draw a system context the system context basically eliminates the usage of Linux it's more on a generic operation system it goes for control actions and saying what could be an unsafe action from one element to the other and what we see there's a crucial element of an external watchdog this is the e-gas approach is a traditional safety approach it's not the nicest news thing but still a very common one and we also go into deepers analysis so then it looks like this nobody can read this so it was basically just to show it and the main elements are still over there there's a driver a sensor actuator the watchdog mechanism and here this is also just part of the system so therefore we need the wider system right and if we bring this on another level you can still draw the same architecture and see that if you just change some elements you can say you have always a non-safety related part if you maybe have a camera part think about a rear view camera park distant control surround view then you have non-safety parts but you also have safety related things which may come from a camera you combine them in your system again and you take then a display to output maybe what you have to see from the rear view camera or surround view and in this triggering the work look you have more demands most likely on real-time capability because you don't want to be half in second delayed when your camera gets on right so you can extend certain functionality to this also park distance control is a use case if you take this there is the beep and you know all this when you start parking but then it's suddenly an audio interaction no longer display but the elements see that if the audio really played is the audio properly is there a distortion in there does it right it's very similar to the concept of a telltale where you also just look into in the end there's certain memory region in which a telltale should show up and is it's correct so you check a memory region against another and you need to make sure that it happens in a certain amount of time and this is a repeating pattern which you have in a lot of fields so what we are going on for the next part is we have an outlook so one thing which was figured out after we have done this long analysis we now would like to get more people getting attraction and we see that you need to have an entry point much more about this will be in the mini summit so a few sleds of size yeah quite a bunch of slides on this on Wednesday we're doing this together currently the setup of the CI which also was a shared stay with cash build so that you don't have to do the whole building process or you can just start with using images and this is in support with the and collaborations of tools investigation workgroup then we also figured out that if I show you these diagrams and if I especially show you the more detailed diagram you need to really have a documentation about the components so we first started with the unsafe control actions which is just from one module to the other and whenever someone you join the same questions come up again what does this mean because the word doesn't describe the functional in there therefore we figure we need to enhance this and along with this if we have a monitoring app included the safety monitor which we have written I wanted to have a quick start we dived into a lot of architectural analysis and now after one and a half years if we look again into the original source code we miss the full documentation of it so we will enhance this in the safety monitoring part and also see that where we have currently a lot of mock-ups and just hook in to show the basics we will go into more tell-tale checking mechanisms that you compare display content originally we didn't look into the checking mechanism as such because depending on which hardware you use you will later on use a much different comparison mechanism there's hardware with which has directly display comparison integrated as a module which may not be always open source IP you may start being very creative and use artificial intelligence was it or you simply go into frame buffer or loop bags and so on and by this we said don't concentrate first but now is the time to look into it make it better because we really go into the kernel level and in order to go into the kernel level we use the work which was done by the medical devices I mentioned that's in the beginning that they understand how the workload looks like they had the implementation they had a lot of documentation at hand and they could go into the stp na analysis into details and figure out which subsystems are involved and so for this part we will now start using the different work look tracing mechanisms to also see which subsystems are involved in our demo of the instrument cluster right and this comes closer to an end so you can see the evolution of the whole thing is that even if we start with a telltale use case which is not this fancy autonomous driving thing which everybody wants to do these days and it's not the full-fledged software defined vehicle it brings you down to a basic use case which is there to derive your requirements get your system understanding and you will need all this to wait on increase the use cases if you come with a large architecture which involves hyperbizes which have the RTOS which has multiple sensors multiple actuators you need to understand all this and see their interference what could go wrong what will they do together and this is all limited to the base with the telltale use case and then you can say okay I add something in here I start to increase the complexity with maybe a more fancy watchdog mechanism or I put in real-time capabilities which will be a large step I involve camera processing additionally for my graphics and this is a stepwise approach so don't try to win the race was looking at the full autonomous driving vehicle which will be the nice use case in the end but go a stepwise approach brings you much better insights and I hope that when we have done our analysis and you can see what elements from the kernel I used how different timings are involved with like you have rendering at different timing than checking and then also the GPU has a different timing than display has so by these different interactions we will all see the complexity how workloads and processes communicate in the Linux system because it's not all straightforward in there and then on the long run you may end up also with an autonomous driving use case and I see the lot of promotions which have been done a year or two back there I think it's always coming in waves that people say there's a full autonomous vehicle in another five years but somehow it's making also this little step nobody starts was a level five you start was level one level two level three level four level five so by this I would like to conclude on what I had to say as I said there is much more in the mini summit on Wednesday we have a dedicated hour full hour on the automotive part and another hour about the systems interactions to bring these two things together and you also get general insights into Elisa if you don't want to wait until Wednesday there's also large getting involved knowledge base the links are already in there uploaded the slides to scat.com so you have already access to it and you can see all these hyperlinks and check out reach out to me and I guess now it would be a good time for you to ask questions if there any yeah so the question is basically that in the extent projects there's a main line approach and it's a much smaller code base and you already have a lot of effort within the extent project to do this maintenance and how are we in Elisa approaching it so we will go continuously with a main line approach also we know there's a large change in code base and this does not work with the traditional approaches of a safety certification so what we do in there is on the one hand we look into continuous certification there's the one part that you can really distinguish or I can see I have an automated flow I can certify again for this you need to increase the large set of test sets and the tools around it and you can also see what the architecture workgroup does they split into safety related and non-safety related features so they do a lot of another this work and say these components are safe they have no interference with my safety related part and when the change comes in there I have less analysis to do compared to a safety relevant part additionally we have a lot of set of pre-existing software which is not there in the traditional ISO 26262 standard so there are certain components where you can make use of it of complex more complex software product but the large set is currently also a way to work with authorities and get into interaction to make more use of pre-existing parts not to say proven in you that's not what we want to do but to handle larger set of software and there another part also to get a little bit forward on this is some argumentation to have multiple instances of the operating system and being arguable to reduce certain safety level on this but this is just the new upcoming thing also autumn the automotive driving does a lot and they actually come up and say we want to have this differences in operating system to benefit from it so not having the main line but the main approaches work on the processes find safety related non-safety related elements in there reduce the kernel size configuration where you can reduce the packages which you use I guess redhead is saying for example they have the standard limits which has 4,000 packages they reduce it to 400 packages stripped down certain parts and here I work with us with the authorities to go on the next version of the ISO to also include elements making your life easier there thank you you mean the yeah so we have the HL cluster demo as a one part you're asking if the demo is based on HL and yeah we base the demo on the HL cluster demo as such and for the wider system which we have with the Xen and the Arto's part in there in the reference system there we are migrating from RT Linux to the HL one but currently we have really needlefish based instrument cluster demo and we take the sources add our meter Eliza layer strip down here and there and then build the complete thing so it's really based on the HL needlefish yeah the question is if there is a plan for these are to do certification on certain elements and what the overall strategy on this is so we see that our partners which are involved as companies they are doing their part in there they start certification of Linux kernel elements they start certification and qualification of tools and within Eliza we support this but Eliza as such we're not planning to do the certification that we come up at a day with a certified Linux kernel or something like this or subset of it this is done within the member companies they work on this and their output of it what they have done goes into what we are using so you will experience things you can make use of it but we're not doing it on our own yeah for the questions on about which companies doing certain safety certification we some partners that we have UL as member they are doing safety certification as such and they are supporting us in our work but you see from the companies which are from interest in Linux there is a code thing they are actively contributing and they even qualified certain tools there is an old webinar on this also and I'll talk from one of the Lisa workshop you can search for rough VR approach they can see the certification pause and the second strong to not to name it is also redhead they working also together with Exida Exida is also having good influence on the ISO 26262 and they are working then in collaboration also with General Motors General Motors not the member but this these in the three are round of three they are doing a lot set of certification work so question is fix it or kernel there's a runtime verification element in there I'm not sure actually we haven't done that yet right yeah what we have done in the past was looking also into evpf elements for examples evpf was used to rather mechanisms but no also we're not on 6.0 kernel yet we see a GL demo okay one minute left there would be chance for a last question if there are no questions there are some stickers and some blinking lights for these are branded so before you leave and if you've interest repron if you like and yeah I'm there the next days either come on Wednesday or see you're on and then just ask question whenever they pop up thank you so much