 from the agenda point of view. We come to the analysis of Linux as part of a system which basically is an overview about the systems work group and how important the view on the system level is. As set by Kate in the beginning, the use of Linux in aerospace may be a little bit limited so therefore after the systems work we will enter into the QA discussions and yeah, but this also means I have one or two more minutes if I need, but I don't have too many slides. I saw we may be late. The last many summits we have always been late so they shortened this one, but yeah, but first I need to find my mouse again. Another time, here we go. So here we go. Right, the next part is about the systems work group. And the systems work group is not that old. There have been other work groups before with the medical devices, automotive and so on. And the initial idea was to have it more as an industrial IoT work group as a new vertical in there, but we figured out that there's also repetitive architectures in various systems and then we need something to put the different working groups into a context of a system. So we want to enable other working groups. We want to have a reproducible reference system. The reference system is not seen as a safe reference system. It's basically an exemplary system and based on real-world architectures. What this means we'll see a little bit later and therefore we also encourage a lot of communication with other communities which are belonging or here to the system context of it. With that, sometimes you can also start a little bit smaller. So from this use case, we would like to go more on evolutionary paths. And for now we always have safety in mind when we're doing these things, but they are not safety focused as much at the other work groups where there's really a use case on it. We said we could maybe also just start with this beautiful vacuum cleaner in there and say there is not really a safety part in there unless the vacuum cleaner hits you maybe. Or the cat, yes. This could be something in there, but then an evolutionary level could be also to just go in towards agriculture mining which is not the ISO 26262 from an automotive perspective but they have relaxed safety requirements because they are in an isolated environment but there is an excuse if I say it like such, but in the end the vacuum cleaner which moves autonomously in the room, it's similar like a lawnmower or whatever or some agricultural goes autonomous on a larger field because there is not expected to be humans in there. It's not a full speed, it's not a highway, less interactions, more autonomy in there. And then this gives a lot of learning for the system. And this is really the idea of the systems work group that you can get an understanding of a system, get seen how it's used and that you can extrapolate and add more and more responsibility to the different use cases. So this, I basically have put in this figure where you can see that's how things could go similar like from the previous session with automotive where you may start with a telltale with an instrument cluster which doesn't look like anything to do with artists but maybe it's close to park distance control. Maybe it's closer than also to a camera based system. And by this it brings us forward. We saw the system part already a little bit how all the things get in. This was also in the initial slides from Kate. So if you draw a system architecture these days you will find a hyper-vider in there typically for automotive, for other industries as well because you have different virtual machines if it's not directly hyper-vider it could also be that you just go one level up and have a containerized environment which you may enable for security reasons. First of all, not for the safety consideration of it but there will be container architectures. Hands up information, there's no container consideration as of such or as such as of now in our system so we are not integrated containers because we're not yet there. But where we started with was to see what's left and right so there's often not only the microprocessor but also microcontroller. And if you take the working groups they mainly concentrate on native Linux so that's why architecture results, Linux feature results will directly go into the Linux machine domain whatever you call it from the hyper-vider part but you can start seeing the interactions with other system elements. The code improvement also goes in there while the tools of course also go into the wider scope of building such a system so it could be seen that the Yachter tooling where we have been in discussions with Yachter project and they're also the open source engineering process. Of course the STPA and other parts of the open source engineering process go along all these different areas so they are everywhere so I just put them on the outer frame. And then last but not least you see that the use cases will tailor the system so they bring it down to what you really need and this could be also that the Linux should be getting another option. So while we start with an AGL which is Yachter based if you want to reconstruct a system you may have a Debian based one so the CIP project or the purchase which both are Debian distro could be an alternative to get in to see what does this mean if you create a system suddenly out of it. What does it mean if you create an Aspom with Debian rather than the Yachter tooling here and then Xan and Zafaris the additional projects around it. These were also the first projects which we reached out to more or less directly in the beginning of system work they were also the Xan projects starting with the demo last year. Additionally we got a strong support by AGL so they are also joining regularly on our meetings that we're discussing the use cases they also have a setup with alternative virtualization not with Xan hypervisor but they were also the provider of potential hardware or at least supported hardware. We have discussions with Sophie and Eclipse SDV they are not really in-depth and we want to enhance this because here I guess there are discussions about mixed criticality workloads and we add these then there maybe we can contribute their last extensions. There's also the Yachter project involved more generally for building the system. Yachter also provide layers for Xan provide layers for that fire so there's the idea of also bringing things together that we all build the whole system with Yachter which would be nice to show you can create a large system just using one build tool. On the contrary you can also say if I use Vast and other tools involved there and maybe have a meta tooling around this makes it more interchangeable and as you can say I can tailor something and I'm compatible with more than one tool. The Naro of course also due to the ARM ecosystem due to the close connection to Sophie is an interesting partner here we've been there two weeks back on the Naro Connect to discuss about it and the main idea always is to say well if you have an Apple and I have an Apple if we exchange these Apple both of us still have one Apple but if we have an idea if you have an idea you have an idea if we exchange the ideas we have both two ideas and that's where these things come up and especially also with Xen, Zafire we share this problem space of safety certification in open source. So here the strong relationship plays into picture and therefore I'm also referencing Stefanos Tork from last year he formed the base for our aesthetic partitioning if you see what he has done he built a reference system with Linux RT, Zafire the Linux Domnir and Xen underneath his intention was basically very similar he said I developed all these features I'm going on conferences for years now always giving new features of Xen and Xen and then the people come and say but how do I reproduce it how can I experience it and that was what he presented last year he showed this is how things get together but from his perspective he was not concentrating much on where do I get my Zafire image from where do I get my Linux image from he just took a root file system tied things together and said they will be there people will know I show something about Xen features and that's where we hooked on and said we want to do something more and we had it in the automotive session we have it here again there was this QEMO part and as Stefanos was going out he also based this on a QEMO because he could directly show it live in the conference have something to share easily but in the end people would like to see it to run on real hardware so therefore we said let's try to bring things up on real hardware and involve different parties so we checked with Automotive Grade Linux what hardware do you support what's in there we checked with the Xen project where is the good Xen support check with the Octo project where can we build with Zafire as well and by this we get things a little together the SPDX is not really for the hardware selection it's basically more for the tools around it but just for the completeness that I mentioned and then the funniest thing started because we come up with a lot of challenges first thing is we need to find the hardware and all the different pieces are there they have never really been combined then you need certain support so we were reaching out and we get also other communities involvement sometimes they are in there sometimes they are not depending on which tool support you get better or worth the part you need to have a larger outreach so it can either speeds up or slows down then the original demo was just on Linux RT pre-made RFS but we wanted to bring a use case on top so then we have a new I call it OS distro whatever you want to do a new image, a new build in there and this needs to get built then later on so we were also looking how can we make use of the CI how can we make use of tools we started a way around with the MOLIN which is a built, metabill tooling which can basically build Android it's comparable to cars if you've heard about it and this was bringing things together but we were not really experts on MOLIN and it's just a smaller tool so there was another challenge on it and what really broke our neck in the end were proprietary drivers so there were graphics GPU drivers which were available and they were available for native but they were not there as downloadable for a virtualized Xen environment and there was also not a direct pass for it so we were there there's a, I'll make a reference it's in the presentation tomorrow on the reproducible reference image but we ended up with a pull request we were in discussion with the CI we put it in the git lab and then we saw, okay we cannot build the full image we sort of maybe mocking something up because people who have the hardware have also a chance to get into the binaries and maybe we just need some header files or so but it was too much in there and by this we said maybe better start small and see what works already so we have the working environment as mentioned from the previous automotive session here we have a full setup and we'll just move over now again to an additional hardware to better supported hardware and for this part we were considering currently the XU 102 the good part about this is the Xilinx hardware is very close to what Stefanos set up on QAMO so they are very closely related because the QAMO from Xilinx is very in-depth too and very close to the hardware so you can even get image one-on-one further we cannot easily take the QAMO part because performance issues may pop up if we do ARM emulation on this and for this part we are considering this but it's just the first step because the XU 102 which is still quite in use it's quite expensive and we would like to come to hardware which is affordable by communities and we first thought about going for all the Altra 96 boards as an alternative option from Leonardo and there's also an Altra 96 V2 from Xilinx which would be supported but both are also a little bit older from the hardware such and then it's a question how long will they be supported? How long will we have a product out of it? So therefore we also now started considering maybe the KIA KIA board which is for AI for robotics which gives a wide use case scope but we didn't start off with this one because we made our trials with the other hardware before and so if you're not having one-on-one match it gives you harder discussion and to make critical resources, human resources in there the life as easy as possible we said better spend in the initial phase a little more money on the hardware but then have a good direct outreach to experts and then take this understanding to bring it forward to more hardware. Here, what we already did on the other hardware was to replace a Linux RT by an AGL not exactly the automotive use case but we had the AGL part in there we also put a Debian image on it we could see that the graphics were working all this but it was more the trial not really a documented full flow in there but we saw that it was not an issue to go from the original setup with the tooling on the other hardware so we believe this will go on easily and then as we already did the first step was believe that it's easier to have it in the CI most problematic part maybe the shipping later on again if you know about shipping hardware across the globe it's never easy so therefore the usage of later community hardware would say in the range up to three, four hundred dollars more or less this is something which is crucial because then you avoid a lot of shipping problems and export control regulations and so on the S-bomb is started we know that there is support for Xen and Zephyr so this could be something which and Yokto, exactly yeah I missed the Yokto part here because we have it already thanks for pointing it out and then the ultimate part of it is to have this setup with three different wisdom archers with the wide virtualization and Linux involved that and working in a similar way like for automotive where someone just adds a pull request to one of these elements and it's directly get checked you can replace parts and by this you have a reproducible setup which is stable and if we take the previous session with sure she explains how things look like she may not want to do one hundred gigabyte download building, wasting time on her machine while she want to trace a workload and by this she could just download a pre-made image getting maybe debug symbol and she will definitely figure out something which does not work as she expects so she can open a PR we can check the PR directly and it gives a much more direct flow and a chance for everybody to hook up on the level where needed and this is basically the evolutionary step from the automotive use case where it worked doing the trials on previous hardware being blocked by proprietary drivers and then now go over to a full setup I put a little bit a summary on why we have these activities and how it creates certain flexibility because it's not just for setting up we have a rather Linux Foundation projects focus in there but it also means we have a good network established from outreach and so on it makes communication sometimes easy but it's not limited to it so we also have for example the purchase outreach which is on a stronger Bosch focus so that's why we can just get it in and have some experts which basically just not concentrating on it for now and more concentrating on Yocto and AGL but anyway, but by this if we start with Yocto and I have mentioned the small in-tool before we have two build tools we can see where's the benefit of the one and the other and if the system builds with both we will see what are interfaces how are differences in there and I don't become dependent on Yocto I don't be dependent fully on Mullen and by this I have a flexible part and I see this is an interface here I can exchange something and I will learn by documenting it and someone taking it has an easier way of getting it into CI CD pipeline then similar with AGL as I mentioned before one is Yocto based image the other image is a Davion image and by this you're more flexible and creating later on your flavor of Linux because these are the two major ones which I see currently in the embedded scope maybe more but if we make it compatible for both we have a chance to see the both parts QMO plus the embedded hardware is also to see on the one end we will, I'm pretty sure we will keep both in there because the QMO is just cool you just start things up, build it, test it, run it but it's not representing it's not so nice for demoing it and showcasing it on fares because it's just looking like here's the PC it runs on a PC whereas people want to touch, see, feel something and it also helps us then having the hardware and the interfaces but if we are relying on maybe on certain hardware interface or whatever we can see it back in the QMO because they may not be there and we can say okay what is the difference we get in architectural differences which typically x86 which we're using the QMO on plus an ARM architecture and this gives us also the flexibility here to swap things yeah the SPDX, ASPOM generation is maybe not so much for the flexibility in the end the flexibility comes in if we have the different systems if we grow things together and the idea is to really have a single source full system ASPOM so we have no cycle on the X interactions for now because there's anyway conversion from A to B possible and a lot of things but just to see how all the things get together and yeah also with the Xen and Zephyr part it's just to show this is an example part and it's prepared to model real-world architectures and basically the initial thing where you saw the setup from the Linux RT plus Xen and Zephyr which Stefano was doing is based on an industrial customer use case which she has so he did not just invented the system it was a system which was used in the customer project so what comes next then on our roadmap I said 23 plus it all depends of course how many people join and how many workforce we have this question comes quite often when it will be done the more support we get the faster it goes but for now yeah the first step will be to merge the automotive use case into this I have shown this on another slide that we already had the AGL in there but we just took the plain AGL image and not the modifications from the meter Eliza should be just one more step in there and anyway in one system setup so it should work out easily we're not bound to the use case at shot we could also go for another use case because we're just setting up a system architecture now so if someone brings a good use case a good benefit requirements to the system or workforce potentially this can also be good for reaching out to Sophie, Eclipse, S.T.V. and Linaro that's a good recommendation similar like Linaro from the Linaro discussions there was the information to say oh let's go with the Korea maybe because the community support is stronger than with the Ultra 96 which are both there in Linaro yeah of course a major thing it's just an example but the Linux Features workgroup they look into certain topics which support safety OSEP part will be also there all the workgroup results should get into the system so that the workgroups can experience what does it mean if my enhancement, my work is operating in a system environment but also vice versa that others can really experience the system so that's where the CI really brings benefits I mentioned containers and a cloud connection I haven't mentioned but I mean everything is better with containers and everything is better with cloud so and if it's just for selling what we definitely have for this use case is a later system will most likely be connected to the internet and there will be even if it's not the cloud it depends on what gets computed is it AI based so the AI part I missed in this list but this is where does the workload run is there workload digital twin whatever and you need to faith and you need to have this in your consideration and if this is in the reference system maybe someone comes my use case is not relevant to it most likely people ten years back have also not thought that the USB printer connected to the router may suddenly be exposed to the internet and you can print from whatever remote because there were no security settings enabled in a USB connection for printer so for this I guess it's good for having the mind in there even if you don't make a strong use of container if you don't make a strong use of cloud connection the later product may have it and if it doesn't have it now if there's a right for updates for many years and the people ask like update my program I have a software defined environment there will be most likely something like this coming up and yeah the idea was also not to tailor this down if we had the automotive use case we can see how do we bring in the medical devices use case in the aerospace use case the open APS may not be the ideal use case for it because it has a full setup it is a certain scope it's on the Raspberry Pi but if we find a new use case additional one this could be a good enhancement for this so for this we have our regular calls on US friendly time so it's Monday evenings European time some morning time I guess it's would be here 8 a.m. more or less this time so there should be a good range it's also a little bit the automotive alternative meeting I have to say so it's you can pick up information from automotive on the Monday meeting because the automotive workgroup meets on Wednesday morning European time which is not very US friendly then but more Asia friendly and by this we just get the one and the other side to get there meeting minutes everything is open the repository is not as nicely populated at the other workgroup so we're still working on this you find the work in progress pull request for example in there on their original reference system which we build also with some screenshots all the demo already looked like with graphic support and send with the fire enabled but you will not be able to reproduce as such to the proprietary drivers and by this I come to the end of my presentation I have to question this is nice this gives us some time so so what the first question which is what the past forward given the limited support for graphics that you might be using is there open source and a look for acute working with q a mom I see this two parts so for the q m or this was and q this was easy the graphics drivers underneath so we could also go for flutter and other parts but this is not on the graphics drivers so there's a base support for q m on graphics graphics support but we already saw if we go for arm emulated q m o versions then graphics is another story so suddenly may not have graphics in there anymore what we did now was basically really looking for a supported hardware we know that sightings is working on certain graphics support and to see our use case what could be ways out of it so that we don't fall into the same problem again is first of all going for open source graphics driver which are partially there but still not full with a sense of port we have strong gpu developer where we can better outreach to to get information from them get support there plus we may limit from a multi display use case start with the one display use case so the idea was to have an infotainment system next to an instrument cluster similar like architectures are built the time given which we have and the resources could be that we start with just one set up and we say let's just render one this makes easier graphic sharing experience functionality but it's not about the safety split of a gpu hardware abstraction this is basically the things in there and the new hardware which we selected has the idea having a better gpu support yeah then there's this question is this something that anyone can duplicate that the overall intention for now you can just duplicate the linux automotive work group part which is just a linux cell but we have a session on this also in june so i hope by the june time frame for the embedded open source on the park we show you how the whole set up will run on xu one or two and then giving us three a quarter further toward the autumn never know how things work out so i would already show it today more or less as such a setup but uh... given the june time frame currently quite confident that we show a setup which you can also reproduce by buying the hardware and we may be even also sharing just maybe two other laps cia op kernel cia laps or so lava workers that people can also make use of a hardware trying things out if there any documentation of the system architecture that represents both the emulated and the working system we started with this documentation which showed the uh... not the emulated to the emulated documentation there in forms of presentation forms of a little bit of documentation on xilinx website so it's more like grabbing pieces of it this was the idea of the work to really write down the things and we have this work in progress for request for the other hardware but then we stopped at this point because there is documentation which is local steps but it's not someone who can really reproduce and improve the documentation because this helped in the automotive work group there was a first person writing down the documentation then someone from the group just followed the description reproduce it found issues by it because the environment is not always identical then we had a one months more to stop and we looked at it a month later again figured out well there's still something which sounded natural before so improve this we're now bringing all these pieces forward so i guess we will have a pull request by the june time frame and then it's a lot of documentation it's basically more documentation than doing things so therefore when you want to duplicate it you need the documentation for at this documentation which we have in the working progress pull request i guess it's not sufficient for someone who wants to do it and uh... way then forward to have a full description then i mentioned requirements somewhere and the question then is also are there requirements for the system that have been captured we have use case from the automotive the automotive work group captured requirements also on so functional requirements non-functional requirements and so on but we were concentrating creating reference system an example system and will then see on the use cases on the demand from the other work groups from what we set up maybe also from so if he and uh... the eclipsed if he that there are requirements to the system and then we can capture them and also see how they implemented but we really concentrated on getting a system set up and see how it fits the work group at the work groups can integrate that others can integrate and pull things out and we'll see also that request feature request buck reports bring us closer to the requirements handling because we provided service infrastructure malls and the use case function requirements powerful this will come in and then we can but i guess we will also have already implicit requirements explicit requirements over the last here where we are talking we just haven't written them all down and for requirements to yeah we should start doing writing things on this down so for not for every part we're doing we're fully safety compliant process in all working groups from the workforce we're bringing we have to start somewhere and uh... and i was mentioning the other working at the related project for example that fire they also recently opened their safety track to public there was more less member parts and say again only part of it part of it is open but they can see that on the mailing list there's discussion going on for requirements to what to use how to write down requirements what we have done in the lease are automotive work group regarding requirements we were actually going into all week we started writing down requirements and then it's really nice to see what what happens there is this isa two six two six two process there is uh... isa nine thousand one cmm i there's a whole lot of processes and if you at least from my experience if you give it to developers is always why should i follow all these processes right where is this and it just ads something on top of my normal work i don't have the time for whatever the good reasons not for many so i'm not doing it but what we figured out in the automotive work group and this i found very interesting we started with nothing and then it was like okay a new person came in ask the same question again and another person comes asking questions all we need to write down our design so we started to write down some design parts which we're doing and say oh here look there there's something which we have music but this is like this and this and oh no we have another requirement so we start to write down requirements and it's like i have this requirement and i have another element there suddenly i have two requirements three four five and i figured there is suddenly an easel maybe attached so that we say okay the safety relevant not safety on higher level of it's just a qm quality managed parts that we had to fill in attributes and then what happens is you write down one our requirement and another one they may arrive and they may be related to each other so you need to trace between requirement see that they fit to each other so we had the next thing and uh... at this time we used i always make the tool plane it's either free plane or free mine whatever you check which answer the mind map and we use the mind mapping tool and the nice thing is that you can write your own little extensions and we have this extension then written down by the former automotive work group please so greetings to you if you listen to this he has written this tool put it also in the github where you can actually trace down the requirements and when you change something uh... you can see okay here's a conflicting party our dependency so we were doing is because we needed this and we had this also for our design part we start with the design writing it down and plant you melons and we figured out plant you know it's nice to write down it's code based but how to establish a good trace ability and see something from the design changes so we went on to uh... papyrus which is eclipse project this was much nicer for traceability but much harder for the ramp up of people that then we had some people who could work with it we had good traceability but the others were not trained for the tools so the work got stuck on this and they start writing other things again so we changed back to another tool and this was going forward and back but it shows you how suddenly things get interconnections and how such an isa two six two six two and isa nine thousand one and cmmi was created and why it was there and that you need traceability and just from trying things out see there's a demand you need a tool and that we had this demand and you see it now also for the safety force ever partially opened in the first thing is that's discussed about a requirement in the requirements to work because we have many different parties and interacting and if you have a small project where you may be two engineers and you just working closely to each other you may not see the strong demand of writing down all the design decisions writing all the requirements but as soon as someone enters the project you start on this and then it's three four five if it scales and will only scale if you have proper documentation proper requirements and then that's experienced life while we were doing it and this is it was really really nice thing to just see that there is a demand for it no more question from the audience shaking hats I got some online questions right cool then we are close to the end we don't have the aerospace session unfortunately uh... I guess we do a virtual follow-up here and there is one also overall tomorrow for those who are not everyone who joined virtually will also be able to join virtually tomorrow hopefully and otherwise there will be recordings so and this gives you a full session we have also more on the critical software summit next day I guess also all tracks for tomorrow so you will also see a talk from Stefano on the safety certification steps by extent project uh... some of these cases involvement where a linux is used and also related topics from security asperm generation so how they fit in these systems and there's also the reproducible environment so some more story about what I've said about the systems and automotive then because it was very nice to have a little bit of audience here some good questions in the chat participation thanks a lot for your time