 Hi, this is your HOSPIL Bhakti and we are here at Open Source Summit in Vancouver and today we have with us, once again, Phillip Amman, your chair of ELISA Project Technical Steering Committee. First of all, welcome to the show again. Thanks a lot. It's a pleasure to be here once more. Last time I think we met in Dublin, we sat down and got an update, but it's always good to tell, you know, remind viewers. So, talk a bit about what is ELISA project all about. Right, yeah. So the ELISA project is about enabling Linux and safety applications. It's an interesting topic from this perspective that we see more and more complexity in products from medical, industrial, especially also aerospace, automotive railways. It's getting more and more computation performance in there. So we get the question, how do I solve this complexity? And the idea which the ELISA project brings as we have such a strong ecosystem with Linux, we can see how we ease the path for using it also in functional safety use cases. So meaning functional safety for potential loss of human life where life is on risk, where there's a damage. So it's important to differentiate to security, cybersecurity. So it's not about the attacking surface from outside who wants to go into the system, but it's more that our software, which we create our system, which we proved is functional safe for people to use that you have the trust and using it when you enter a car that there will not be an accident because of the car. This is the major challenge in there when it gets to the project is how to comply to the strong regulation. There are many regulations coming up more and more, and these were made for traditional development. So you have in-house software development, you have strong processes which are enforced by your standards which you have in-house. And here this is where the ELISA project comes in. We try to find a way how to bring things together with our partners and members. And thanks for also drawing the line between safety and security. It is not about the security of systems. It's about safety application as you said. So I want to also understand if you can give some kind of idea to our viewers as well. When we look at these safety applications, when we look at elevators, they have a lot of safety mechanisms. You talked about car, airlines, cruise ships. So give us an example, an idea about where it is being used. So what you can see is if you go in the car, for example, you get something where you don't believe that it's a safety application or safety feature is for a warning sign. When you put in the gear, if you hear the beep from the rear gear, this is already all safety relevant because warning signs also like check and engine also. These need to be visible because you need to know that something could go wrong with your car. But also if you are, as you say, for an elevator, there are these light checks that the door will not close when you have a hand in it. This is safety functionality. And a lot of this is done with hardware mechanisms, small microcontrollers. And also an airbag in the car would be a safety functionality. But here it's a very interesting topic. It's not the safety functionality that the airbag opens. It's safety functionality that it's not open unintentionally because it's about reducing the risk that something happens. But it was a risk before that you just get into the car. But it would be an unacceptable risk that it opens while you drive, because then you will most likely die in the accident. So these are all considerations for safety in medical. We have a medical use case. There is an open artificial pancreas system, which is an insulin pump. And of course you need to make sure that only at the right amount of insulin is getting into your blood circuit. So this is something which is also safety related function or if you have little autonomous robots moving around that they don't hurt someone when moving that they stop as soon as someone gets in direction. And you see that in this way there is a lot of similarity when it comes to sensors actuators bringing things together in smaller applications, industrial ones, medical aerospace also for aerospace. They are quite crazy. We have the new working group in this recently started in the beginning of the year and they have even more safety standards and it's really really important that they are strongly enforced and you feel there's really a safety culture in these companies to make sure that the airplane would never crash. And so they even do redundancy. They build up triple or at least twice systems so that even if one system failed there is redundancy to pick up another function again so that at least two out of three will always work. Talk a bit about the origin of the project. Who is driving it and where do you see how much deployment is there or you're at the very early stage in the actual deployment. So we are to get this up front. We are still in a quite early phase because it's a new project and safety development always takes time and we have a very large challenge with a large Linux ecosystem. The fundamental idea is that you build a Linux or safety system for the purpose of the safety functionality. So it's concentrated on this little piece. There is no configuration, no flexibility is just made for this purpose and if you see this in contrast to how a Linux operating system is so flexible and runs everywhere. You see this challenge in there. But it comes also started with an automotive drive. So the Lisa project roughly 2019 more or less. And in this time it was that we see before we have many, many, many different electronic control units basically a little bit of electronics all distributed in the car and they get centralized because the computation is much more performant in these days. And when it gets centralized the system complexity from distributed system goes into a central system. And you ask from the beginning what is the motivational driver to use proprietary RTOS development and you have to develop everything all over again the driver the surrounding the ecosystem. And the traditional safety critical RTOS is also not always capable of all the new features because they get certified. And we try to get a continuous certification because we know there are new features which may be interesting for others to be used and this is something which a bunch of traditional RTOS cannot handle. And if you are able to handle your overall development with an RTOS device get connected and when they connect they also need to get update and then there is safety functionality involved which need to get up to which need to be certified again. There's a very expensive one. So there was a need to change something. If you just extrapolate the traditional way there is no way to go forward. And it was a good time to start 2019 and what we see also now from the evolution over the time that came the aerospace involved so Boeing has strong interest they are now the premium member and they also started the aerospace work group. They're just in the beginning of it. They try to find more peers and to consolidate what is our mission for this work group. But they always said wow it's great to see and discuss with those from the automotive because in the end we share a common problem or same problem space. Now as the Linux RT patches are getting into the kernel and it's print chaos left or something. So the main work was done suddenly also industry hooks up because the industry had their real time demands and their discussions. Do we have a very strong real time, which means very very hard timings or is real time sometimes also a bit relaxed. And for industrial application they say the real time availability and a currency which the Linux kernel brings. This is something which is suddenly usable for us and then for industrial applications Linux comes into picture. And what we haven't touched is they use also computer vision systems and we have AI machine learning and all disease needs drivers and there is a much better support in the Linux ecosystem for chip sets for computation performance than when you transfer it all to commercial artists. And so you have another motivation to go there. And I feel personally that a lot of this driving in Linux is a commercial topic. Well you of course get a much larger benefit with all the experts in Linux you have so many skilled engineers. And if you think about open source you have a certain amount of influence but you cannot really fully steer an individual maintainer maintainer identifies with its component her component say this is my topic. I'm responsible for it I feel strongly responsible. And I make sure that it's stable it's robust and should get in. And this is a lot of safety culture. And it's safety culture which gets transparent so everybody can read the code can see how reviews are done, how testing is done or or not aware a gaps in specification and this can be filled in the community. And a lot of the other development is just in house. And you see that there is a swarm intelligence because there's so many people had a chance to look we see it in Elisa every day. It's an intense discussion because there are different interests different perspectives how to reach safety. Each company has the same goal but they sometimes may take a different approach. And then there's room for discussing and say oh have you considered this how do you treat this part. Let's glue the things together and make it even better system. And this is something which can just happen in the open and not in a commercial development environment or much harder. So it's not possible but when we are talking about RTOs of course you have a sister projects which is Zephyr. But the thing is the scope I mean we talked to Zephyr community all the time you know the scope of different projects is different you know so there are a lot of limitations as well. So there are limitations of Linux kernel that's where Zephyr comes into the picture there is a footprint of Zephyr that's where Linux plays a big role. When you mentioned Zephyr that's a very good because we have the systems workgroup and in this we're explicitly collaborating with Zephyr and also with the Xen hypervisor because what we see a later system in use will most likely in many cases not be a plain Linux. But the effort makes sense to create a system context and when we look into system context we could have taken any hypervisor or any RTOs in there. But why we took also collaborating with Zephyr and Xen is that both have a safety track both are open source and you really see the differences while some parts which work for Xen hypervisor for example they go in and say we have a very good process we have established quality. It's very hard to get code in our parts but we know we have things like dynamic memory allocation which is a challenge for some people who create a safety system say let's see we don't use it mainly so maybe we can get it completely out of it that we don't need it anymore. Something which we cannot do from the Linux kernel because it avoids dynamic memory allocation so that's one part where we go in a different perspective but where we could already because still getting this hard and process how do you treat coding guidelines testing documentation. We have to share the same problem space same as with Zephyr they have also a strong benefit of a small code base similar to Xen it's a much smaller code base. And also they had safety in mind when they started development they had their safety cathedral ideas and what they also said they kept it open and a little bit closed. So it was like for members and so on and they also just know a few weeks back like some months to around the embedded world timing. They opened and they partially opened so that we have now the active discussion and there also it's going to meet on Tuesdays every other week and then also release our members work and then we have connecting spots also. There was Nicole Poplar who she's active in both communities and we did some work in the past also together so also with respect to SPDX we can touch on this a little later because as bombs is also a topic which is relevant later on for Xen for that fire and for the Linux part and a software bill of material also becomes relevant for safety parts so we can see how do we add evidence to our elements into such a system as bomb, not only for a single software part or Linux system. And so we are really actively collaborating. And it's, it's a good chance. And we also see that some people hesitate to say let's go. Maybe we don't want to go now for a full Linux and we don't have the full use for it but we look for something which is open source and has a safety pass. If they know Linux they have a lower entry hurdle to go into Zafire. If they know Zafire and start building up on this, the mechanisms like device trees, kernel configuration parts, you feel similarity for the Linux work and by this, you will get a benefit in a transition path for your data use case so therefore it's it's really a close coloration and in the systems work which we have, we actually meet together with the Xen team, with the Zafire team, with the Octo people, automotive grade Linux is also involved because they provide the use case and we have a strong collaborative environment. And what we see is that we also not only reach out to them we also go into other directions so we have recently been at the Linnaro Connect in London and we discussed there how the Linnaro ARM ecosystem can benefit from our work and we can benefit from them. And as Sophie is in there as a software defined vehicle we had discussion with the Sophie people in there. And when you talk about Sophie who come to eclipse as TV. I'm talking a lot from automotive because I'm from the automotive background right. So, they share this, they also talk about mixed criticality workloads, how do we get Linux in there. They don't limit it to links they also take commercial artists and to account. But the main reference they all also build on Linux and there we can collaborate together benefit from the use cases which get in when they share use case and we're not bound to our use case we're hoping to just also go for another use case. What are the next set of challenges that you are looking at solving for the larger ecosystem because as you mentioned the project is at a very early stage of deployment or user. And second is that what are the challenges that are there for the project. So the challenges which we currently tackle and this is something which gives also strong benefit to the community. One part are the RT patches where we say we contribute with documentation because just as the patches get in to the kernel tree. It's not possible for others to use utilize them because they need documentation they need maybe requirements design elements around when we start with a documentation. And we also want to bring this upstream that we say we work on upstream patches to have better documentation that we don't keep it locally. Another thing which we see which is also valuable for other projects and communities. Sure was kind of was presenting it yesterday also the day before our mini summit about tracing workloads. This is something which already went upstream and it's quite proud that we have this visible now it went into the six dots here it's that when you run Linux you want to understand what subsystems are involved which calls and they often are to figure out what is relevant for us. And this becomes visible now and we hope that we will also be able by tracing workloads for automotive from medical for aerospace that we see repeating pattern and say these are really crucial elements and even independent from the use take use case you take your end up in there and here are some some major challenges which we are facing is we were basing a lot of our work also on simulation on QAMO which is a good and start start prototyping. But there's industry demand also put it on Singapore computers to hardware and there to really find something which gives a good support for folks and sapphire and Linux Linux support is widely used but as soon as you want to bring it more into a system you need more support in there and then for new joining sweet we have new joining people coming in they need to get an entry point right so they say I bring this background. So we recently work on a big picture document we start this will take it in our workshops that says what's your role. Okay if you are in this role approach this project from this perspective because we cannot give the same message to a Colonel developer like to a safety engineer. If they are not the same business in the end. And for this we work on a big picture document and we also improve our CI CD system. We did a prototyping on this for the automotive workgroup. And in this one it's really it's a dependency queue so we start with a documentation the documentation matches the docker container the docker container should be a help but you can also just use the documentation to create something. The docker is pulled by our pipeline, the pipeline creates an image the image gets tested. And whenever something changes from documentation point of view from the docker file from the sources which we build to the image. The build process is such the Q a more version of something changed there will see and identify it. And it also makes life easier for others to start. Maybe you don't know how to build a system but you want to look into how the workload is being done. Then you just download the Q a more image and to just start it on your PC. And we see then later on if you want to get hands on with interfaces and real hardware watch stocks will set this up on hardware we plan to have something ready for the embedded or saw some it's not clear if we make it because it's an aggressive timeline and. This is a really a major challenge. And the other one is that you see, there are other companies larger Linux service providers which have also very strong workforce they have the business case behind it and we are a community project. So I believe we also need a little bit more of growth to have more participants to get some graphics engineers in there who say okay we, we understand how to do graphics drivers and we can support you and giving a good understanding how you put graphics with automotive together. Maybe someone who knows more about AI machine learning because this is also just popping up again and again. I guess one challenge which we also face is to to satisfy the requirements of our members because they have ideas on use cases and for some for the automotive use cases. The companies of course looking into other system driver systems autonomous driving and this is friendly but it's gross a large complexity and it's sometimes better to start with a smaller step and we need to see how do we get the different things together. So this is one of our major challenge to really with the workforce we have to. Yeah, and since you mentioned. AI and autonomous car and we are looking at the native AI to be there, and then it comes to safety applications. Of course, I will play some role as you know and it's still already playing you know. So talking about when we look at the few as but you also really said you know that yeah the scope is massive but we have to look at a smaller smaller steps we cannot just take a leap. But if you look at the larger picture what is but in the future you see of this project. It's a good point because see the AI and machine learning just gets in computer vision maybe just the pre stay because it's much more deterministic. But also a I shares a little comparable hurdle in there because you say neural networks and so they are not deterministic and for safety application you need to be to show this is a deterministic process I can really break it down and really can have a one on one trace it may be very complex. And he's in the end. Linux is still deterministic to a certain extent but on the other hand also not. And this is the similar topic which AI some mechanisms which we may put in for for the Linux system and how we say these are tools. How we make sure that we get a say more closer to the safe Linux can also work for AI models that you say okay and practices and definitely we need to get them in where I'm hesitating currently is to say to give a full responsibility for example to an AI. I would say it's more monitoring the I continuously similar like we monitor now a Linux system and say we we built the system that is as safe as possible but we need a safety net we just safety net which can take over control. And this is something which you also already see so there are sometimes fallback solutions suddenly. I experienced it once that there was an issue I was on the way to the airport for a business trip. And we were on the highway and suddenly the car slowed down from 150 kilometers per hour to 80. And this was because they had identified an error message or whatever at least the current but there is something with the engine. So we go down we still are operatable but we have just a limited feature set we can only drive 80 to the airport. It increased my pressure because I will be in time but I felt good that there is something like this and that the car itself identified. We have an issue with the engine if we drive full speed so we go down to a lower speed to not risking the engine to be disturbed and this I had a much better feeling to also come to the airport. Parallel to the AI model would be the AI gives us a lot of chance a lot of possibilities and maybe this enables us to go into more feature rich environment more functionality but it could be that send there is a monitoring says OK I take over or I inform you to take over and say here we identified something at this monitoring this watching mechanisms. It's the similarity of that to the Linux we say we watched it but we give more responsibility to the next but we know there is a way back maybe not as feature which maybe not as nice from the experience but there is a way out. And this is where I comes in and where we just started to discuss but. We also saw there is this brings together this linear story and the Xen because Xen is also heavily driven driven by Xilinx AMD and they also brought up some community hardware which is used in the narrow which is there and this is actually an AI robotics hardware which can also be used for telonetics and CC use autonomous use case automotive use cases and then we got combine automotive robotics industrial AI. In a little hardware and. So this is something where we eat the past also for our members to say that's not it's not this warning sign forever. We just took a warning signs and automotive for this instrument cluster because they're very good good easy to understand you don't need to much send those actuators. But we try all our ways to show this is the way how it goes into others and to more complex use cases and how we also help pick up other industries. Philip thank you so much for taking time out today and that of course it was an update on the project you know also its future the scope and you know as you also said it's early phase but some you know use cases are also there. So thanks for those as usual and I would love to chat with you again so thank you. Yeah, I thank also a lot for the question it was a good part to think about so and I guess we see each other again somewhere in next conferences or so. So it wasn't very much pleasure for me to be here today. Thank you so much. Thank you.