 Thank you. Thank you everybody for joining today this session. Today, we talk about the community efforts that we have today in the automotive Linux functional safety segment. I will explain what we think these efforts are from the radar perspective, where also read that stands with respect to each of these efforts and what are the challenges and the next step. I have a few words about myself. I am Gabriele Paoloni, I work as a senior principal software engineer in Red Hat. I am currently the technical leader for the Red Hat in Vehicle OS solution. My background, you know, I joined Red Hat pretty recently in July this year. Prior to that, I was working in Intel Mobileye for industrial and automotive solutions. And I'm also pretty involved in the Linux Foundation RISA project where I take what I have the governing board chair position and I'm also leading the safety architecture working group. Okay, so agenda for today. So the first topic. So we'll talk about the open source and standardization approach of Red Hat. And then we go over all the different initiatives where Red Hat is involved so far. So we'll talk about Elisa, then we'll go about the ISO standardization community. We'll talk about the CentOS automotive special interest group. Then we'll touch about the ARM and the SOA fee consortium. And so we'll talk about the AutoSAR adaptive. And finally, in the last slides, we'll discuss about what are the challenges in harmonizing all these different initiatives in a constructive way for the overall Linux ecosystem. And especially we'll talk about the challenges of these initiatives to communicate to be synchronized with each other. And finally, there will be question and answers. So from Red Hat as a company, all our business is heavily based on the open source. Okay, and this is true also for the automotive segment. There is no difference. So you can see that so in this pyramid that are different layer where, you know, on the bottom part we have all the open source projects. And the open source projects constitute the ingredients that, you know, that we use as a baseline for our Linux distributions. We have other ecosystem based projects where, you know, we integrate the different ingredients and we also develop, you know, like specific features. And finally, you know, we have, we create our own internal, our own internal distributions where we focus specifically on downstream, you know, business functionalities, right. This is where we differentiate and where we make money. Now, when it comes to the automotive segment, our baseline, so where we start from is Red Hat Enterprise Linux and Red Hat Enterprise Linux for Edge. So this is our robust baseline that we use and that will build on top in order to deliver our in vehicle OS. So, now, let's talk about the different collaboration opportunities that we have today in the automotive Linux ecosystem. Okay. Next one is Elisa. Okay, so in Elisa, we discuss Elisa is a Linux Foundation project. Okay, so where we discuss reference use cases. We discuss development process practices. We discuss system architectures we also discuss tooling different tools. Okay. So this is, you know, quite open with the collaboration from different members. Then, another important part is the ISO 26262 working group. So, indeed, certifying Linux poses new challenges. Okay, so the ISO 262 standard as of today is not suitable. You know, to certify Linux, it was not designed for complex pre-existing software component like Linux. And therefore, we need to be able, you know, to collaborate also in the ISO 262 working group, in order to find new ideas and new ways, you know, to standardize a new methodology that is suitable for Linux and in general for complex pre-existing software components. And then we have CentOS. So, CentOS is indeed a red-out-honed open ecosystem where that is providing an open platform where all the potential red-out partners, customers can, you know, prototype and, you know, can also deliver new features. Okay. And this is indeed very important from the red-out perspective because, you know, it allows to get automotive features upstream first. Okay. Before we integrate them in the in-vehicle OS. Then there is also the ARM-SWIFI consortium, okay, where this is an ARM-driven initiative to create a reference architecture for the edge, specifically for the automotive segment. And indeed, you know, we also recognize from the red-out point of view that it is really, really important to, you know, to take an active role in this initiative. And also, last but not least, we have the AutoSale Adaptive. So AutoSale Adaptive has been around for some years now, and it is indeed another reference architecture aimed to deliver automotive and infotainment application. So these are all the current opportunities where that we recognize as red-out is to be very, very important in the automotive ecosystem and where we play and want to continue playing like a leadership role. Okay. So, some bit of more details about each of these projects. So, Elisa, so the acronym stands for Enabling Linux in Safety Application. Okay. The definition of Elisa is to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based safety critical systems that are amenable to safety certification. And Elisa, we have different working groups. Now, this picture is a bit outdated because there is actually in the meantime there has been a new working group that has been created. However, the principle is still valid. So on the left you can see that there are the automotive and medical working group. So these are domain-specific working groups where the respective use cases are discussed and are analyzed. Okay. So these, the analysis of the use cases lead to the generation of requirements for the Linux kernel itself. Okay. And these requirements are further elaborated in the other working groups. So in the safety architecture working group, we define, you know, we develop safety analysis to, with respect to the allocated requirements in the kernel development working group that now has, I mean, that now has further evolved into two other working groups. But so here in the kernel development working group, the idea is to discuss how, what are the best development process practices that we can leverage out of the current Linux kernel development. And also to figure out what are best Linux kernel configuration and features to meet, you know, the safety requirements. So there is the tool investigation and code improvement working group that is focused on tools that can be like, for example, study code analysis tools for the C-Schooler to, you know, to provide the fuzzing of testing. So and all these working groups working together, what they do, they generate a baseline of evidences, effectively, of best practices of best configurations of tools that can be reused by downstream vendors, like Red Hat, for example. Okay. So, yeah, so this is in summary what what we do in Elisa. So the project started in early 2019. And right now we have grown up from four initial to grown up to four premium members and 15 general members. And, yeah, the main focus right now is automotive, but we are also trying to push for other segments, like especially now we're pushing for the industrial tool, for example. Okay, now, another initiative that is very, very important, as I said, is the ISO 26262 standard. So the ISO organization is, you know, is hierarchically divided into committees, subcommittees, working group. Specifically, when it comes to the software component, you know, we have the WG8 that is responsible for defining the best practices and, you know, and the evolution of the standard for when it comes to the qualification and certification of software elements. Okay. Now, here the problem is that, as I said, the ISO 26262, as of today, is not suitable to qualify pre-existing software products and components, okay. So the ISO 26262 was initially designed to certify, to qualify either, you know, like simple software components developed from scratch, or, you know, to qualify pre-existing simple software components. And this is historically true just because functional safety was mainly, you know, adopted by simple MCU, simple system. But right now, as you know, with the evolution of, you know, of the compute of the computational capabilities and with the, you know, introduction of the artificial intelligence and robotics. And looking at, you know, autonomous driving vehicles where the computation power is really huge. And the complexity, you know, increases together with the computation power. Therefore, as of today, you know, the current ISO 26262 standard is not, you know, is not suitable and must be changed. So, how to change the standard, there was an initiative that is called ISO-PAS, the PAS stands for Publicly Available Specification, that was, this was started in early July by Intel Mobileye. And this, the aim was to address, you know, the current limitation of the standards, okay. And on September 10, you know, there was a new working item proposal that was approved, and we have now entered the preparatory stage. Okay, so there is now a working draft where all the international members of the ISO are collaborating, are discussing. And from the red dot point of view, we joined the ISO-PAS through the Italian delegation, okay, and I am personally, you know, an active member, okay, of this ISO-PAS so because from our point of view, we recognize that in order to be successful, we need to align, especially on a long term basis, red dot need to align with the directions that are taken by this ISO-PAS, effectively, you know, by the, we need to align with the ISO 26262 community, otherwise we cannot win, okay. Then, CentOS Automotive Seek, okay, so the goal of the CentOS Automotive Special Interest Group is to provide an open source home for red dot enterprise Linux-oriented automotive work. Okay, and we need also to attract and encourage open development of automotive software between commercial and non-commercial partner, okay. And the goals of this Special Interest Group are to first create an open source related, an open source software related to automotive, then to incorporate upstream projects that are related to automotive. And finally to, you know, to build a CentOS variant for automotive based on red dot enterprise Linux Edge. So the idea is that, you know, we deliver a reference freely available code baseline where all the potential red dot partners can collaborate with respect to, you know, bug fixing, trying, you know, with respect to experimenting on new hardware platforms with respect to, you know, having new features that are, you know, valuable for the automotive segments, okay. So, as of today, I think so we have, so this initiative started pretty recently. I think it was something around last September. And so we are meeting regularly and as of today we have already a repository and manifest build instruction so you are really encouraged to, you know, to join us if you like. Okay. And what else. So, yes, so we have the, we talked, we mentioned the ARM SWAFI, so SWAFI stands for Scalable Open Architecture for Embedded Edge, okay. Okay, so this is an initiative that aims to bring together different automakers, semiconductor suppliers and open source and other software vendors, okay. And the idea is to create a reference architecture with reference architecture for the edge with that can also enable mixed critical. So it is effectively a containerized, containerized based architecture where that can allow, you know, mixed criticality between, you know, between functional safety and non functional safety containers, right. So, and so that effectively autonomous drive and ADAS application can run together with the infotainment or other less critical workloads. Okay. And this is also quite clear from from the picture. From read that point of view realize that this initiative is quite important. And here we are playing leadership role, in fact, we are part of the, of the governing board of the SWAFI. And this also this project started pretty recently, I think, again, also this one was around the kickoff was around September, something like that. Okay. So, and, again, you know, we will continue, you know, to collaborate with with ARM and all the other partners that are part of the SWAFI to continue, you know, pushing and making, you know, this reference architecture. So, and last. So, Autosar. So what is Autosar Autosar, it is a development partnership of car manufacturers. Okay. And other companies from electronics we conductors and software that are involved in the automotive industry. Okay. And to deliver a standardized software architecture for automotive systems. Okay. And, and as of today, Autosar delivers and maintains two different platform, one is the Autosar classic platform, and the other is the Autosar adaptive platforms. And so the classic platform, it is more suitable for systems with safety criticality that is quite high up to be, however, with the, you know, a competition power that is low. And effectively, it fits well. Simple issues use cases, whereas the adaptive platform is more is more intended for complex. Autonomous driving and ADAS application and systems, and also it allows to have mixed criticality of infotainment together with with critical workloads. Okay. And from read that point of view, we are mainly interested in the Autosar adaptive platform. In order to, you know, to, to play a role in that regard, so what we are doing today. So we are a partner, we are in partnership with the Autosar vendors. Okay, so to ensure that our red dot in vehicle was can fully can be fully compatible with Autosar, and also optimized, you know, with respect to it right so our goal here is, you know, to make sure that our operating system is is usable by any OEM that wants to support the Autosar adaptive middleware. Okay, so this is effectively the goal from from a company point of view. So, in this picture, you can see that there are, you know, different aspects of a system stock effectively. You can see that we have requirements, architecture, code and testing, and we have tools, and then, you know, across all these blocks of architecture, there is the methodology, effectively the functional safety methodology. Okay. And in this picture, you can see that all the different initiatives fits, you know, into different aspects of these of these stack. Okay, and you can see that we have Autosar that is, you know, spanning across requirements, architecture, code and testing, so a fee that is mainly focused on the architecture itself. Elisa, Elisa is mainly focused on architecture, code and testing, tools and methodology, and then we have the ISO 26262 that indeed is mainly focused on the methodology itself. So, now this, all these initiatives right now are evolving in a sort of pretty independent way. However, they are conceptually, you know, related to each other. So, from the radar point of view, indeed, we have our own, you know, stake into each of these projects, if you like, but in order to be really, really effective, I think so we believe that is important to find a way to have these initiatives to collaborate with each other. Okay, so that's, you know, they can effectively evolve in a synchronized way. I can give you an example. In the Automotive Working Group, we are evaluating the Autosar requirements, okay, and we are also, you know, time by time synchronized with the Autosar members, okay, so this is just an example. However, you know, there should be, we believe that there should be initiatives to allow these initiatives to communicate, you know, to be synchronized with each other. And it is not trivial. And especially because sometimes there are licenses limitation and mismatches, okay. So if you hear another example, I think it is effectively forbidden to discuss the current material of the ISO 26262 of the ISO PAS outside, you know, the ISO PAS task force itself. Okay, so it is forbidden, you know, to have like an open discussion on that material. So this is a limitation. Okay, so this is, again, yet another example, but you know, in general, so the point here is that we need to find a way possibly to coordinate these, these programs, okay, and as of today, I don't have, like, an answer, like, like a final answer. So, and with this slides, I have made it to the end, so if you want to, you know, to raise questions, or if you have comments, please just raise your hand. I will take this. You can also type in the chat. Whatever you like. Anybody? Okay. Yeah, I cannot see that either. Oh, there is one. Hello. Yes, I can hear you now. Yes. Okay, yeah, I actually wrote the question on the chat of the session, but anyway, the question is the SOP is actually read by ARM, so you think that are the main target hardware or architecture will be your ARM 64? Hi, I think so. I mean, I mean, from what I know, this is, I mean, I'm not personally involved in the SOP, okay, so I cannot give you like an answer that is under percent sure, but from what I know, yes, so the hardware should be the ARM 64, especially because one of the important, one of the important topic is the standardization, so, and I think from what I know I don't think that there is like so much standardization that can be enforced on ARM 32 platforms, but again this is, take this with a pinch of salt, I mean, you're, okay, so I should say that I'm not part of the, personally, I'm not part of the working group, so. Do you, do you think that are, what the, I'll say, or their place or, I'll say the meta place to discuss this topic, continue to discuss this topic. So where is the best place, do you think you, who do you think that are the, I'll say, there are some, yeah, CentOSC? Okay, so I think, from what, okay, so, from what I've seen so far, I mean I will tell you, you know, from my experience, okay, so from what I've seen so far one of the main difficulty is the licenses mismatch, okay. So, the, then, okay, so it is true, we have licenses mismatches, okay, but there are, the people are the same. So, effectively, I can tell you that some of the people that are part of Elisa are also part of the ISOPAS initiative, right, so there is a common subset of people. So, now, what we can, an effective way could be, you know, to, for example, could be to, to have a sort of restricted discussion group that could align, for example, Elisa with the ISOPAS, where these people, you know, can, can, can work as a sort of, you know, communication channel, however, you know, bearing in mind that the ISOPAS material cannot be disclosed on the other side, okay, so it's effectively, you know, it's a sort of, it should be a sort of informal, you know, collaboration, I mean, now this is right now the way I could see this happening because other than that, unless somebody come up with some smart idea, I cannot, I cannot see that. Like other, for other programs like Autosar, okay, so Autosar, the specification are publicly available, so, you know, I mean, we are, we can, we are open, you know, to discuss about them, okay, so effectively, what we can do, we can say, okay, so these are the requirements from Autosar, okay, how can Linux satisfy this requirement, okay, and that is, you know, kind of an open discussion that can be, there is nothing preventing that, right, so, because, you know, but I think that there are some code, coding will be required for like implementing that Autosar in a kernel, or Linux kernel, or Linux as a Linux application, yeah, so that are, maybe we need some actual project, what's the open source version of the Autosar or something like that. That's a problem, I mean, so effectively I don't think it is, if we do something like that, it could be, from my understanding that could be a violation of the Autosar license. So, the developing, you know, an open source version of the Autosar, so effectively these are, you know, the kind of, you know, the kind of limitations that we have so far, right, so, yeah, I mean, I don't have like, so this is something that we are trying to experiment to, you know, as right now, so. Okay, so that's the big barrier to getting to the Autosar space. Yes, effectively yes. So this is the barrier, because, as I said, I don't think we can create an open source distribution of the Autosar middleware, okay, but there is nothing preventing something like, I'll give you an example, okay, so Autosar Mondays to have an health monitor, right, so, and, you know, an important part of the health monitor is the washdog, right. So then we can say, okay, we can leverage the Linux washdog subsystem in order to support the Autosar washdog, and then we can say, okay, but can we rely on the, on the, on the Linux kernel washdog subsystem, and what are the challenges, okay, so we can do this kind of analysis, right, but, you know, I mean, but the point is, we cannot, I don't think we can build an Autosar middleware, right, we can, but but we can discuss, but there are the challenges in having the operating system to support the Autosar middleware, we can do that, yes. Okay, thank you very much. Can we enable Dan to speak? Yeah, can you hear me? Yes, yes, I can. Great, great, yeah. No, I just found this discussion very interesting. I just want to share my experience, we, at AGL we tried to collaborate with Autosar, but it was not possible because obviously we're not a member, and so we couldn't get access to any of the artifacts, any kind of documents, any kind of spec or any kind of anything. So how do you propose that this would work like in an open source context with Autosar? So the specs are publicly available. So I'll give you an example. So we, when we were in discussion with Autosar, they requested that we investigate whether we would adopt Autosar coding standards. And I thought it was a good idea. I said, okay, let's do that. Can we have the coding standards? And they told us no. We can't, we don't have that, you know, we can't give you the coding standards. And so I don't know what you mean by the specs are fully open, and I guess it's not everything is fully open. I don't know. I mean, probably I don't know if they have like a sort of tool to check, you know, the compliance of the code. So they have an Autosar C++ guideline that is freely available. And that is the specification where you have a mapping to all the MISRA checks that must be satisfied. Okay. I can point you to that anyway. Okay, yeah, yeah. And on top of that, I, yeah. I mean, from that point of view what we are doing, we are collaborating directly with the Autosar vendors to effectively to, you know, to overcome this problem of, you know, of being Autosar members effectively. I say yes. But yeah, so I told, I mean my understanding is that all the specification and requirements are publicly available. I mean, understanding, I'm sure because I downloaded them by myself. So, and yeah, I can point you to the latest release, the 20.11 release, I think. Yeah. So, and, as I said, one thing that it is doable for sure is go over this specification and requirements and, and, you know, thinking how the OS can be compliant to this then. You know, the practical challenges. Okay, but we cannot get, we cannot build an Autosar reference midway. Yes, we can't. I don't think this is possible, right. Yeah. So, effectively, we cannot do, you know, like the next step of, you know, enabling a community, like an open source community for Autosar that is a challenge. Yeah, I think it's impossible, I think, actually. Yeah, I have to be perfectly frank. Yeah, I don't think it's possible. Yeah. Okay. Okay. Any other questions. So, right. So by the way, since we were talking about the Autosar C++ guidelines, so this is the publicly available spec. You can click on the link and I will load them. So, if there are no more questions then I would like to really thank you all for attending. Thank you guys for the pleasure to present, you know, to lead this session, and I wish you, you know, very nice continuation of the open source summits. Okay. Great. So, thank you guys, and have a nice day.