 Okay, so I'll give it a start Oh passcode Five three three seven five six at the passcode So mighty nine for nine But only if you join the zoom you can see it right here, right? I don't know if someone maybe can share it on the platform Okay, you're good Okay, then I'll kick it off with the automotive work group first of all, let's Take a short look on what we are aiming for so we want to see and discuss the conditions prerequisites whatever is needed in the automotive sector to target use cases there we Want to derive requirements from the use case and what it means to the kernel what it means to the development process of it We know there is the iso 2 6 2 6 2 which put high demands on the safety in the car and Yeah, and to start with we are very open for any use case Which could come up and the first use case which we took What the dashboard? Why have we selected the dashboard there are multiple reasons than there one is that it comes with A good explainable system So if we take the dashboard with warning signs warning signs are the gear indication warning signs are The check engine oil pressure whatever you can expect and they need to be there Displayed as safety information because if something is wrong with your car, you need to be informed Another thing which is happening is that in the past it were originally were light bulbs Then they turned into LEDs and the LEDs are now going into the display so you can see it's much more software driven than in the past But this gives you another reason to put it in because the next thing is someone may wants to start nice Blending around it wants to make it more pretty wants to have some animated whatever things in there to have the Telltale experience matching the whole car infrastructure The another thing which is nice of this is that it's not only software driven these days It's also that It has a good timing constraint So if you imagine the use case you're driving on the highway with a maximum speed suddenly a light bulb goes on So I because everybody of you will just hit the emergency brake check the manual and look what the light Means or maybe you just wait for some time to look for the next parking place or even go home Because the thing well my car will not die. It feels just driving normal But I know should know about it this gives you more relaxed timing constraint than hard real-time demands The last benefit which we have in with this use case is that there is already a demo Implementation of it available which was created by the automotive grade Linux. They mentioned us as a partner project and Typically also referred to us if it comes to the questions and their instrument cluster use case working groups and so on the latest release Which a GL did I guess is called There was one last octopus I guess and We are still a needlefish the main reason why we are a needlefish is that it's our demos QT based with the latest license changes of Q People moved on and say well It's not so commercially attractive for automotive anymore for some members at least and by this the main track is now going to flutter There's a new rendering framework, but the lower layers Where we are looking in into the kernel into the graphic subsystem. It's basically independent from this upper layer So and what we did as extension with these meter Eliza Layer, which we put to the york to tools is that we add this little Danger sign, which you can see there In real systems, you would not put this danger sign so this danger sign is for you illustrating that we are in the system that we hook on do some modifications and This illustrate this just we detected the fault This is danger and then we would reboot trigger watchdog or whatever and go into a safe state All right You will find a lot of these Instructions in the meter Eliza on the github repo. So just go on github.com a leader tech meter Eliza Slides will be uploaded as mentioned. So for this, there's no need to click on it now It provides a longer description on it how to use it and it gets combined with a work group automotive We did this because we had people hopping on and off the discussion the work groups And we discussed it again and just again how things look like and well documentation is very important It's not only important for safety It's also important for open source and principle and you want to make life easy for people to hook on so we started with this description We moved on a little bit on this we figured out that while some people may use open-soothed tumbleweed rather than many others using maybe Fedora Linux or Go also for you going to use so by this we saw there are differences Next thing what we did was setting up a docker container so that you have a docker file Then some people were didn't want to run the docker file to create the image So we were providing the image and we were growing this step-by-step And from time to time there are always people who want to start from scratch again So they just follow the instructions Currently we have a new joining in the group is said. Oh, yeah, I know there is this docker file I know everything is available, but I want to read the instructions again And actually I found already two broken links because your project just updated things and that's where we Want to have something continuously running so that things really work whenever you join in and for this We also set up a continuous integration. We did this together with the tools investigation and code improvement work group We have a git lab runner. You may wonder why source code is on github while the CI runs in git lab It was a little better for the user handling and the forking of it if you use the github actions you couldn't fork repositories and you can You need much more Configuration and can have some pitfalls if you don't do it right people may have access to your servers And we have a server underneath and this is better maintainable with GitLab and here it's actually in this way that when someone joins The group and is listed in the git lab. This person can actively It just trigger a pull request in github on a local branch on a fork Refer this in the git lab CI and do a run So it could be if you want to save computation performance if you don't have a disk space or whatever So these kind of things you can do with the CI It's not only building it's also checking that the system boots because if it would just build you don't know if things work out of the box and When it's built we also do a QAM a boot and share later on The rendered image so you can see that it really goes into rendering. It's not the one with the danger sign Which I took a screenshot From but there's all the danger sign in there. However what we figured out it's not always the build Which costs the issue it could be just recently that the cooks are can stack which we are using had The client and server certificates expired. So 7th of April We suddenly saw our CI failing when like what has gone wrong. So we were looking all the sources We couldn't find the sources Changes in there. We saw there was something on master but the master was not changed by us or we were not pulling it and Well, you could argue if we would have put it directly to a GL It may have been seen easier But we're not yet there that we say we are as stable that we would like to provide our Modifications to a GL what we did instead also then for the analysis We have an open qa setup running hosted by code thing on their servers And what you can see with this orange line in there You can basically move it from left to right It's from gnome testing and so on where we do a qa more emulation Reboot the system and you can move the slider to see an expected and the real rendered also So you do basically a initial run you take check the timings and then you can just see that the danger is in there And for the broken part You could see that there was just the danger in the reference but no longer in our rendering part All right, and then next to it you have the full information You also get a video recording of the testing phase in the logs You have the serial outputs you could we could see okay our signal source control at which we have there as a mock This was still operating. We could see how at the boot go on. Is there any version change and so on? so this is from the testing part and Then further we go for Pipeline flow so what we had in here is that we said From a development perspective We start with a meter Eliza Within the meter Eliza. There are the bit bake recipes the bispe recipes Can point to everything you can even add also component if you want to go there and then This meter Eliza is taken from the Docker file So it's very third in the Docker file we generate the docker image from it and this generated docker image Which would you download so either you download your meter Eliza you download a docker file Which pulls the meter Eliza or you download the pre-made docker image and we generate this on a regular base So we do it more or less once a week that we build from scratch and every night We just do a diff or using an ass state build and then also this docker image is the base for the GitLab CI which means the GitLab basically is Acting like the user so if you're using the system also GitLab is using it whenever something would broke in the docker image Or in the docker file or in meter Eliza the CI will show it So there's really a dependency flow in there to the documentation around and then later on The GitLab of course builds the QEMO image the QEMO image as built and downloadable for someone Is there to then go into the open QA so the open QA grabs it does the testing What is missing currently as a link back is that the open QA is not reporting back to the GitLab So if the GitLab CI is running It does not really do the check it could say well our CI passes Because from their this perspective the booting work there is an image generated You need to check manually while we have this little intermediate step and therefore now Another part is there that we also work on as bomb generation So we are just switching it on we figured out that some Function were not there so we were giving it back to AGL and then was not an AGL topic It was more the Yocto project topic. So They discussed it there and added some feature did some back porting For us because we're not on latest Yocto version And so this is just getting enabled Additionally also we as mentioned we have CS state So that we have cache point reason there if you would do a normal build He takes you 100 gigabyte or something like this. This will not be there, right? Yeah, so As already mentioned partially this gives you various starting points which are all interconnected and For me personally the most fancy one is that you can really just change two lines pointing to a new GitHub branch and Just let the whole flow go through that the things compile get the queue open QA run Without even the need that you don't things locally and this is very helpful because When someone contributes a new feature in GitHub or a new bug fix whatever gets in We can just simply point to this PR Let the testing be done and make a comment in the GitHub will request that the checks worked out up to the test cases we are doing and But this nobody has to manually check it. It's basically two lines changes We could most likely also automate some part there, but we haven't done this yet Right I guess I have One picture here, so let me just shortly see if I can start this So you just see it in operation Was pretty fast, I guess we still have the time for it Let's try to run it from within the presentation, but it never works as you like to So the right screen So what you can basically see is we open the terminal to Start the QM or image so the instrument cluster is booting just normal and then You can see that we have the terminal window so Here we log in and Start our signal source control app the signal source control app is a mock Which has different options so you can see you can interrupt the next message you can Hook or blocks a system and by this is for us a checking interface. This is just the visual part There's just a command line interface which is run in our testing You would not need to do so, but the open QA test for example this does the check also via the control app and The original pros wire name pipe, but it's hard to interact with it So we just have a little bit of graphics command line interface for it So if we run like this now something was not rendered properly anymore you see the danger sign propping up and The watchdog gets triggered and soon we should see that the things reboots the rest of the system You could see was still operating but there was some corrupt messages, so we just start the system up and similarly Guess we do another run and then there should be the danger sign detected So we do have one question in the chat. Oh, cool. Nice Well, we had two and I just went and answered one of them, but okay Then I'll just so What is QMU me relating for this example? Would what would the equivalent be on an automotive target? Yeah The QMU basically represents the standard AGL system and We took this QMU because it's an easy access. It's not something which would go into the real system later on so we basically Yeah, just need an easy starting point for people to do something and this is a good question because if you would do the full Analyst of your system, you will see most likely different slightly different interfaces because it's an x86 architecture rather than arm architecture, which is heavily used in automotive. So We just the this is a demo. This is a startup This is good for checking things, but it's not as good as you would go with the real hardware setup and Yeah, the equivalent automotive target on this would be you would take some hardware set up We were looking with reference hardware from AGL We have for the systems work group later and I will talk about the Xilinx example One said it was a Xen Which we also now look into maybe the automotive work group We were discussing also options like an orange pie which gives you arm hardware But still if you go to automotive and come up with the raspberry pie an orange pie rock pie Whatever you take they just say well, that's hobbyist hardware if you suddenly pick up something like ST micro NXP Qualcomm Samsung renaissance if you take this kind of hardware if it's more or less a similar thing, right? Just was a not as good BSP support Maybe like the community of suddenly it becomes attractive and this is what we want to bring in there and also find a hardware later On which is not only going for instrument cluster use case, but for telematics artists and so on so this would be the upcoming part Right the S-bomb was all to the second question where does the S-bomb come into play So the S-bomb will be in the built phase So we will try we will build the whole system it grabs all the information Which is in there for your to we know that it will not be complete and 100% correct because it can just be as correct As the data which is provided So if there are any issues and in the certain component if there is dual licensing multiple licensing this way not be perfect and As this is is the docker image stage or before basically it's Not taking the docker image as such, but it's going Afterwards it's going in the build the docker image is there to enable our build to do the octa build and the SPD x generation As bomb generation is in the octa build if we talk about the systems work group later on There we need to see how we combine this because we were most like not only have the octa build We also have the bass Western there and the xan build We may go everything into your clothes that we have just one bill to about the multiple would also be there And then it's inside the docker, but not the S-bomb for the docker image Container will be an interesting topic also on top later on good Got this is a main answer for the question. Let me get back to my slides All right, we already touched the STPA a little bit by Kate in the session before What I really like about this STPA thing is it's I get asked is it a replacement for something do I need to do this things I Make my way around with the answer and they will that's something which is the where Available it's quite new and a lot of the other techniques are coming from the 70s and 80s and haven't evolved too much And this gives you an additional view and if we're talking about safety and it can add value to your safety analysis Why not using it and here as mentioned this? Interaction with complex system it really helps you to just understand and we have pre-existing software, which is also not Typical in the automotive safety world, but here you can really look into a system model the things you already know and get this as a support So for our example, we started with a fairly simple drawing with this delta requester can signal and so on We took it to a next level where more interactions were in there Well, it goes through all these parts here and Just they what we learned for example about this phase was There are examples of save rendering engines. So there was some I guess some cute Library which was aimed and got an easel. I guess even a ZLD qualification But it turned out it if I read it correctly that it's mainly a tool qualification And anyway, it's a good thing to sell and it will definitely improve the quality of the component because it's developed according to it But whatever goes in there in the forward path basically need to be checked until the display and all the mechanisms which you're doing are pointless If you make to make sure that things are in there So you cannot make everything safe in this forward part You will always have a backward checking element in there which guarantees it could be In the display comparison go on audience question What you mentioned things like a soul and other things like that and I was just concerned that the audience may not know What those things are? Oh, yeah, so the easel is the automotive safety integrity level which ranging from Qm quality managed up to Azel D. I guess I just lost the mic could be Okay, good. I don't hear myself anymore. So it was just good. Perfect. I couldn't hear myself anymore. So there was just confused so The easel D would be really something for autonomous driving very high level more more Messeds tools to be used Testing in-depth and so on while lower level easel A and B you could find for lower level of safety others functionality are breaking and so on Actually breaking as a higher one break easy. So the easel D this is one of the very crucial things but our rendering of the telltale's for example, it's just an easel B level and There if you're coming from aerospace basically just turn around there. I guess it's going with zero C Highest level and then it goes up to five where it's lowest level. So here higher letter means higher level of safety to be fulfilled All right. Yeah, and this is basically here The parts so and for our part for this display rendering You would do a check in the backward pass and need to make sure that whatever got rendered is properly rendered And here you would do the check so whatever mechanisms you do in the forward pass is nice But it's not the one which you need to do in the end because you need to make sure what there So and this caused a lot of discussion because we were saying what do we do? What do we do properly for forward backward and this gives to the original first slide? Basically, which Kate was showing Understand your system sufficiently and do the measures where you need to and you need to understand your Linux system that you put the mechanism that the right places and The next picture which I want to see about this control structure is not following STPA It's not an STPA diagram But we see these three different regions of it the one region this yellow part is basically The functioning part. It's the plane function which you do which you would like to do as good as possible and Then you want to make sure that what you have done is running properly. This is the Kind of orange little bit orange style color here You would do checks you make sure that you have a monitoring and whatever gets rendered is really properly rendered and the last part of it is this really dark orange one at the watchdog because This is a fundamental system part of our work this challenge response watchdog is Something which is very much known in automotive. It's also in other industries used and basically this watchdog Make sure it's clever enough Checking elements in there and for us it means if we don't have real time scheduling in the Linux kernel So there could potentially be something in a very very seldom case which caused something to stock Which caused delayed execution and here this watchdog would send continuously messages So it's outside of the Linux system It's external watchdog for now with the watchdog module and does this check and this is just the last safety case and If you do a proper system design, this would never be triggered. So it's intended not to be used It's just your final safety net that nobody will Buy and then we have a safe state We have all this discussed we started with a demo as I show how it all was set up So this first QM or demo was done more than a year back I guess almost two years back and then we start all this discussion to write down Demand design how does the system operate and now we're at a state again where we need to map the model and the implementation so we need to understand much more which subsystems are involved and Then also involve the workload tracing which will be the next session by sure and also have an improved Implementation why do we need to an improved implementation so far? We have mocked certain things so we are not doing for rendering check We concentrated on the fundament of the watchdog But not on the specific rendering mechanisms and if we want to do a workload tracing the workload should represent reality and Here we did from our analysis from the discussion figure out Oh, we mocked up a little bit too much if we really want to understand the workloads so What we see is We have now a CI we can easily modify. So whenever we improve this For a step-by-step whatever we do on this additions. We can check it properly and We need to improve the Information on how the components are involved. What does it mean for display checking so that you really understand? This is this component. This is safety monitor. This is the tell-tale checking and so on so we update this We update the monitoring app as next step and this is the part needed to have the workload tracing Further outlook on things. We also want to do is to merge the automotive use case into the systems work group demo because Currently we are plain Linux system and whoever works with automotive will most likely ask where at the auto So where the RTOS? How do you handle these kind of things? Oh, I'm running in an SDV software defined vehicle environment I want to use containers I would like to have virtualization involved and for this we pick it up to see how does our analysis change When we involved this kind of system. We had the part about the QMO here comes a part that we We're discussing currently the exciting sue one or two. This came from the demo from Stefano shown last year during open source someone of America and We may then move forward maybe to a Zecria system which gives you also AI in their AI vision parts robotics So for wider use cases and not limiting us to an instrument cluster We still see a lot of room to trim down the kernel configuration Trim down the image size because it's based on the plane yok to pokey We may not need all the things example could be we have thrown out the Wi-Fi driver because we believe that we don't need The Wi-Fi was in the instrument cluster at least not for the initializes if someone comes up and finds a fancy feature Was it who knows and what we also make as a hypothesis and assumption We have workloads tracing for medical and we hope to see Similarities when we trace it to certain kernel parts kernel subsystems So that both things together will give us an idea which is really crucial Which is maybe more relevant to more use cases where we need to concentrate on first and get a high value for a lot of other industries and Yeah, we don't see it as a safety element out of contact whatever we do because we say Any safety element out of context always runs in an assumed context So our assumed context is a tell tale if we would Certify something or not we but a project would use it to certify based on this tell to use case It doesn't mean that you can do an other system out of it But maybe an other system will have Similar demands to the kernel similar check them there may be stronger real-time requirements But this need to be there Because in the end what would really burns down from this use cases checking a memory region against another memory region within a specified time and This is maybe also something which goes to the medical devices where you need to make sure that Whatever you said as glucose monitoring level goes forward in the proper things Yeah last part on this if you see this drawing I just took two examples You could have park distance control, which you know from your ultrasonic beeping part if you go there Or you can even end up with certain camera use cases and basically you see very similar things the We have another sensor rather than maybe the engine sends a signal to say check engine The beep sends the this the ultrasonic sensor sends a distance rather than showing it on the screens You have a speaker and for camera. It would be more image data which need to be processed And this gives you a scaling factor. It gives you a base all will require a watchdog mechanism and Yeah, so we hope that we can go further with more advanced use cases and also fulfill certain others requirements and by going with the hardware from Currently a QA motor or something like the exciting spot or Well, well, so basically look for something which gets a good community support which gets a good PSP supports It could be anything else as well Just which is available to others We may have something which also goes into telematics others and so on Right, do we have something more in the chat any questions from the audience? Yeah, there was a question the last is the S-bomb intended as an input into the docker image It could be an input for the duck image basically We would most likely see it as an artifact and see the changes of the artifact which goes in so there's not a direct demand for this because Yeah, the S-bomb of the docker image would be another question It could be a double ass bomb There's one for the build system and the alignment around it how we build this thing what is involved there our first S-bomb approach went more into The S-bomb of the system in use so there's a S-bomb of the device use not the tools which have been used to generate the image Which would anyway also need an S-bomb in the end if it's all still based and then you are with the S-bomb within the docker That's two parts of it