 Good day, my name is Kate Stewart and I'm a director here at the Linux Foundation and I've been looking at a lot of issues around embedded and Safety critical Applications and working to see how we can get it so that we can be safely using open source projects in these very important and relevant realms that we're seeing a lot of innovation occurring one of the Inspirations for me has been Margaret Hamilton and she was the person that basically Programmed the Apollo Space mission and working with the team there and did the testing to make sure that the astronauts could get to the back safely over 50 years ago And a lot of the things that she was talking about then this slide is from the XE conference in 2019 2018 sorry and You know in there she's pretty much saying You know the challenges you had to build man-made software meaning that astronauts lives were at stake And that's pretty much the definition safety critical when people's lives are at stake We need to make sure that our software works and it has to work the first time it has to be reliable and tested and dependable so You need also to potentially be able to detect errors and recover in real time, you know fast forward to today and We've just finished seeing you know SpaceX's rockets and with a good capsule and go up to the space station and dock and You know those are all being run with Linux and so Making sure that we have you know these applications there and That the right level of safety analysis is important. It's gonna be key because we're still going back to space Other things are even like you know down the daily streets We're gonna be seeing more and more of these self-driving cars emerging and then we're gonna be having to see in the smart cities That have the infrastructure to support them There is IOT that's emerging as a very pervasive field that will be in cars and around us And at the part of it all is going to be the fact that we've got safety and then even to a more recent example obviously we're in the midst of one of the you know worst pandemics of my lifetime and When the first started searching earlier in the summer there was a lot of initial Momentum around making sure that there were open-source solutions for ventilators that were available That could be you know Testing reliability We're able to be manufactured And are able to use the field and so forth and an open source Initiative came up to look at which open source options are there for programming them and building them and you know we've seen these Systems and people are wanting to create people are wanting to help and open source gives them a way to do it so given that Open source is already being used in creative applications. So I guess the challenge is now how do we make it safe? And just a little bit more stats around this You know 99% of the code base is audited last year and had open source components in them And up those audited code bases over 70% we're made up of open source projects so This isn't all the case in safety critical space, but nonetheless It's here as a pervasive influence over technology and it is moving into the safety space This was from black depth report earlier this year and then so the type had a report last year that says they're seeing Double and triple digit growth in open source components and these are the components that make these really cool applications that they're already put together And there's no slowdown in sight. So open source is here and it is the seed for innovation So the challenge is now if we're going to be using open source in these safety critical applications, how can we make it safe? And when we talk about safety and safety critical there's a lot of standards out there and depending on certain domains There is the desire Certain things that they test but they have a lot of underlying common elements 61 508 is pretty much a general standard and a lot of the initiatives are focusing on it initially Because it's a key for automotive railways nuclear machine safety and industrial processes So if we can get the generic standards in place and it's a smaller gap to go the other domain specific ones However, all of these have in common as you know, Margot was saying is you know We need to minimize and mitigate the systemic faults and we need to make sure that it is safe Then it needs to be known tested and managed and needs to work and recover from problems And so these properties are still going to be needed here. Um, the thing is that the open source Has had a different methodology for development than these standards were written in front of and so the question is how can we reconcile the other challenge out here is the fact that Most companies are not able to today to accurately summarize the software that's running on their systems the modern digital infrastructure You know, it's a very sophisticated layering of software and you know, we build on the shelves of giants well in the same way some of the modern applications are building on layers and layers and layers of other information and you know As this XK CD cartoon neatly illustrates is the only the recent project out there that all this stuff is depending on that That's not as sustainable as we'd like and so how do we get these things sustainable? And how do we get this infrastructure to be clear and understood part of that's going to be coming up with some software transparency So These are the gaps that we're looking at with what we want to be going after and what we need to be going after for that matter and what We have Available to us today and so we've got to figure out how we can close these gaps between what the safety standards are looking for And what we have today in this rapid evolving exciting open source ecosystem So the first step is actually being able to Understand what you're actually running on your system and improving the software transparency by using some sort of standardized build materials um In the last couple years has been an excellent effort from NTIA They've basically been acting as a serve a neutral broker To try to bring off a bunch of stakeholders together and come up with a common definition of what a software build material is It should be and what a minimum viable Like what fields are you to really need to keep in a software build materials? and we need to make sure that these um This information is there and the connections between components to components and relationships are articulated and This covers, you know Open source and proprietary free and paid It's just a question of we need to figure out how we can map what's being used And you know when well actually pretty much any point in a software life cycle development There's a use for an s-bomb of software build materials because you need to know what you've got You need to know if you've added a patch to it. How has it been built? Is there any certifications are effective with it? You know, are there you know configs that have been used for the version you're using that might have a relevance in a safety argumentation All of these elements here um Could be you should be able to generate a software build materials at any point in your life cycle Is what it's coming down to and be able to ask for it a software build materials for any time you're taking and consuming In a piece of open source as part of a larger product And quite frankly you've wanted to know what else is in the product in addition to open source too So why is there a lot of people starting to wake up and start caring about this? Well, actually it's because there's money involved Um And the vulnerabilities and the impact of vulnerabilities are in the news, you know Pretty much every couple weeks you're seeing any vulnerability that's impacting someone and some of these are actually impacting people's lives Um, you know when there's a denial of service attack going on at a hospital and people can't get access to machines They need because they're being denied a service Um, that starts to impact people's lives So we there's a large a wide Um interest worldwide pretty much in improving the cyber security um in the supply chain And the initiatives that are happening in the u.s. Are mostly revolving around the software build materials coming out of the nta effort And determining how we make that better but you know What is emerging is you know, these things are true and we are seeing like things like containers emerge And containers um are abstracting and hiding even further all those detailed pieces that are being used in a system and so having that transparency And having that ability to understand exactly what you're looking at is a prerequisite for any type of safety analysis And we need to figure out how to get it there And we're also seeing some of the regulatory authorities The site weighing in on this now, especially in the safety crucial spaces like the FDA has Signaled that they will be looking for one. They have not given a date But it has been signaled. So the medical industry is paying, you know, very close attention to this and then uh, recently the um energy For the federal energy regular drug committee has weighed in and expect saying that they are expecting to see and have that expectation of that software transparency and so A lot of these stakeholders are coming together and working to actually come up with um, this minimum viable that I was chatting about And Here's um, like you say from the NERC SIP 13 Um, you know, it's all about supply chain risk management And it has that expectation that you will have some sort of way of understanding what software you're running So you can do the risk assessment. It's as simple as that So who should be using an SBOM? Well, pretty much anyone that's making a software and Deploying software on their systems. You should be asking for them if you for anything you're buying and you should also be Being able to produce them on the fly so that if there's a vulnerability coming out You'd be able to you should know what exactly is in your system and what you're running Whether you know you need to remediate or not And a lot of the aspects that are coming in could be coming in from the contractual the legal Or the technical from the vulnerability side But it also could be from the dependency side and it could be the analysis side the systemic analysis side To make sure your system is safe in context and then deploy and so All of these things are leading us to this type of presence And at the end of the day, um software build materials just make financial sense. Um, there's been quote. Um, that's come out from You know, it's sending, you know, saving hundreds of thousands of man hours rather than scrambling around fire drill mode If you know that you can just look it up as a query on your system And understand which components you have and where they're being deployed Where these software components are and what systems they've been deployed on Um, you can much more effectively manage our mediations as well as Ensure that the system can stay up and operational and fulfill any safety obligations you have with it So at the links foundation, we're looking at a few projects in this space to help with these efforts. Um There's common processes and norms, um working with open chain and that's now an ISO standard Um, that is able to specify what the obligations and expectations are We're looking and working towards building up common data formats. Uh, software package data exchange or spdx has been around for 10 years It's able to satisfy the minimum viable that's been, um, arrived at from the ntaa process And then we also are starting to work on pulling together all the tooling to make effective workloads for generating and consuming software build materials So you understand what you've got on your systems at any point in time And those workflows and are happening within the automated appliance tooling project your act And if you go actually into the specification, um for open chain, you'll actually see that You know right at the very start like, you know one section. It's a very it's a short specification. It's easy to read It's about 10 pages And it's calling for the material that you're summarizing and passing through the supply chain as the software build materials And it has open source components that are listed. And so this is part of pulling together Having sort of standard ways of exchanging the information and having standard formats that everyone can consume Um, it's going to be part of improving that transparency that we're all going to be looking for especially in the safety cases So next step is well, if there's a functional safety considerations um, how do we Focus on understanding the interface's quality and safety characteristics of the open source projects involved We need to actually, you know up the level of analysis information that's available and is a digestible uh for projects and so that When there are in a safety argumentation someone integrates them in with their value The system can be looked at and studied and determined that yes, there is a safety You know issue or and what are the mitigations we might have played to improve the risk things like that So that hasn't been a consideration to a large extent and a lot of open source projects up till now and that's starting to shift um, here at the links foundation, there's several of our projects that are actively Looking at being able to be used in functional safety Um from zephyr and cell 4 which have smaller footprints to you know acorn and sandwich or hypervisors Automotive grade linux is looking at and then alisa is looking at trying to pull these frameworks together to work with linux And so let me start with the bigger one, which is alisa and then i'll go down to one of the other ones So alisa Started off because it stands for enabling linux and safety critical applications, which is pretty much on spot for this Over the last, you know, 30 years linux has pretty much grown to be the most important open source project in the world And 69 of the embedded systems marketplaces already running linux by estimates that have come up in the last years and from other studies And as a result of that You know, we need to be able to handle linux in because a lot of these applications you were just sort of seeing They're using linux in them right now and the automotive cars And the you know space x rockets so forth These are all systems that have linux in them and we need to make sure that it's staying When it's being used as being safe. So we're trying to figure out how do we actually do? You know, how do we actually get the information and do the right level of analysis? And so at the end of at the heart of it, you know, you need to assess whether system is safe It's not linux itself is safe. It's how are you using linux? It's that safe and you have to understand your system For it to be effective Um, and that is at the key of the argument, you know, the thinking here is okay How do you know, how do we are we able to articulate how linux is being used and can we move that forward? So If understanding how you use it is at the key, you have to understand your system You have to understand the linux interactions. Okay, what apis are you using? You know, what dependencies may there be in your system that have also are working with linux? How are the interactions? How does it be configed? All of these are key elements here and you need to Work with when you're using depending on certain properties in linux like a schedule um, you need to ensure that the quality is there as well as The behaviors are as expected and when errors happen. Can you recover back to the you know the days of? Margaret, you know Hamilton's analysis for rockets same things who are holding true today, but we need we've got a very much more sophisticated code pace And so the safety standards, um You know were Designed with a certain methodology in mind Linux has evolved over 29 years And it's continuously being developed. And so it does have a very high level of quality You know, there's continuous improvement processes in place There's things that a lot of the standards are hinting that they want. They're just being expressed slightly differently in linux And there's a lot of evidence from the testing that goes on That the process quality and the process improvement quality already exists. There's you know, there's developed maintainers get together There's a self-reflection period every year To try to figure out what needs to be done better And we have a lot of testing infrastructures and frameworks that are out there that are working with linux Being able to pull this evidence together and make it accessible for people doing the safety analysis is at the heart of what Alyssa is going for So the mission statement for the project is to define maintain the common set of elements and which on processes and tools that can be incorporated into specific Linux based safety critical systems amenable to safety certification so What we need to do is you figuring out this gap closure that we're talking about There's a lot of information that safety standards are looking for There's a working group inside of Lisa that's looking at how to close those gaps And they're working with the kernel community On you know understanding what's there. We want to try to get you know elements upstream We want to get documentation published. We want to get this information available In the upstream as well as have reference material available for people who are going after safety argumentations drawn and then In the components like the scheduler like the memory management units things like that Well, there's various properties because people are depending on these systems to work And how do we do the right analysis of the interfaces coming into them? as well as Understanding these You know what will happen if a fault happens. Can we recover? And making sure that these components are well analyzed And so that people can build it into the rest of their analysis Part of the Lisa is also working with um, you know, okay You can't just look at Linux as known as we sort of said it has to be in the system So we've been looking for open source Applications that are available out there There's a medical devices working group that's looking at the open APS Which is an artificial pancreas loop system between a glucose monitor and an insulin pump That's a obvious project, but everything is nicely open. It's running on an raspberry pi So it gives us a basis to analyze down to what's linux doing in the system And then there's the automotive working group as well That is looking at various applications It will be in automotives that are using linux for like tail tail apps and so forth And doing the analysis again to figure out what parts of links are being used Um and building from there Um, Alisa is able to spin up any other working groups any it's a lot of interest in industrial and robotics And hopefully we'll get one of some of those going in the next year Key is that any applications we start looking at that will feed into the rest of the analysis need to be not under NDAs And we need to have them on open so we can do the analysis and collaborate Yeah, the heart Lisa is a collaboration. Um, we're not going to be engineering any specific system to be safe Um, you know, we can't ensure that people who are using it actually Read the documentation and understand the processes However, we're going to try to create some so that those who are motivated can And you know, we're not creating a standalone linux distro or anything like that It's just how do you use the upstream kernel and how to be effective At this and you know, we're not going to be able to leave you for any responsibilities under God's conditions But we are going to be trying to provide a path forward and people to collaborate with And so that's what Lisa's there. And so if you've got an interesting case, um, we'd encourage you to kind of look and work with us in the project When we're done, um We should hopefully have You know the assets help ready for um helping people go through safety certification So we want to have you know, here's your process here. So you do your analysis Here's the features you need to look at. Um, here's where evidence is Here's some tools to help you understand do your analysis in your system And we wanted to show that it's feasible to do this in some reference systems that everyone can look at like the key is A lot of this work happens right now in companies today under NDA so no one can see it So what we're trying to do is do things in the open so we can share it with others Um, we want to be able to help educate those system interpreters on the things that they need to look at And with the view that this seems to have to be maintained over industrial life cycles, which can be You know anywhere from you know two years, which is your standard end of life on your you know on a device or five years for your phone or you know 20 years for a piece of infrastructure in your city Or even longer in some cases um But there is um a lot of information and we want to make sure that the information we're putting brought providing Is accepted by the safety community and certification authorities And so that you know, there's multiple people people who are going to be doing these audits who understand the evidence It's there and can help educate slash make sure that the right factors are considered to make sure these systems are safe when this third party audits are happening And um, you know, we also for us to be effective here The latest community needs to be able to understand what we're doing and recognize it and make sure that you know Some of the things we'd like to upstream into the documentation as we do the analysis and you'll be able to share We have a way mostly the current community Is very much motivated to fixing bugs and a lot of these things are just bugs So we need to fix these bugs and we need to make sure that we've documented how you know the information that's out there And eventually we will want to have hardware to liable As well from the various vendors. We need the hardware vendors to be bought in because we're running on their silicon and their boards for that So if you want more information about elisa, um, I encourage you to probably go to our next 2021 virtual workshop We've been doing workshops roughly every quarter. We were doing it in person and then with the latest pandemic We've been having to switch to virtual We've actually had more people attending and we've had a lot more engagement as well So I think we're working on a format that helps encourage discussion and engagement. So You know, feel free to check us out Just lurk or I'll start participating in the discussions and if you want to get more engaged Feel free to sign up for the mail list. It's open to anyone and you can start looking at our sources and the github repos are there Now switching over from Linux and a big abstract system. Let's go and look down at what's happening on those sensors and actuators And um zephyr project is um been designed pretty much to work where Linux is just too big Linux doesn't get much smaller than it makes these days and a lot of The embedded space is you know, very very cost constrained footprint constrained very tight on memory and so Zephyr's been designed to act in this area and When we start the project off four and a half years ago We wanted to make sure that it would be able to be a real-time operating system And we built it right from the start with the view that we're going to be going after safety certifications and security certifications So we built it with safety and security in mind And the community is lined up around the fact that we are going to need to have some discipline in certain areas To be able to go after and work with the standards as they exist today So it's cross architecture has a broad base of hardware platforms is over 200 Boards have imported into it. It has vendor neutral governance. No one company own, you know is in dominant control of it And the checks and balances are in the governance document so that you know, the technical steering committee Determines, you know, which direction the projects are going It's permissively licensed which makes it suitable in certain from certain companies minds And it is, you know, very modular like the least kernel is and highly flexible And like the next kernel, it's also adopted the notion of a long-term support kernel And this is where we're encouraging people to work for for products and A subset of those the next LTS will actually be ready to go through the safety audits And so we're working towards that goal in the project now As you can see it's a rather full architecture These are on modular components that can be enabled as needed So this way you can sort of scale your footprint based on what your functionality you need is and then work from there And it's a wide range of communication technologies because it's iot. We need to obviously communicate off of these and so If you're interested in more details It is they're available from the project and as you can see, it's pre-fully featured OS at this point in time That lets people be let's it be a good RTOS basis for applications And we've actually been seeing our products emerge in the marketplace None of these here listed per se are safety critical, but they're wearables and they're getting into some of the performance So you're sort of seeing this project shift and as the safety critical Certifications emerge where it's expecting to see more of the safety critical applications coming in There it's a couple of products here that are being used in They were spun up very quickly. There's things like the distance or from phytech, which lets you know um You know with when you're coming within a zone of people the six foot zone and then the sentries from their technologies is also um, you know designed for monitoring the distances and the characteristics Including, you know, there's also the safety pods from breaking in the factories and for giving feedback if you're getting too close Or according to who you've been getting close to and things like that for tracking traceability So we're seeing this effort being deployed in situations that are going to be helpful for um us getting through this next few years And they can't they were able to spin up these applications very quickly from the product base So but like I said, we'll be getting after more safety critical We're wearing wearables type of deal right now But I think it's going to be emerging into getting into more of these tight loops and More of the safety critical functionality So we just we established our safety committee for the project in 2019. We are fine mature enough. We're meeting every two weeks and the participants are People who understand safety considerations and the implications in that committee and are working to help educate the rest of the community on that The initial target for the project is going to be 6108 sold level three and We've already been established our coding guidelines and those are being applied through the project right now And we're working on getting the continuous integration enforcement going in And then there's multiple safety activities that are going on to establish the traceability The requirements test covers the tooling and so forth And safety committee is taking the lead on this And then working with the tsc to make sure it goes through the entire ecosystem And we are also engaging with the certification authorities in this project right now Um, we're looking at how do we um You know, how do we basically go through the safety plans and the documentation? So it's a much more traditional safety path Then we're sort of doing a Linux At the heart of it, although um quality is going to be the foundation and high quality code and making sure that we have our Defix under control Um, it's not additional from because of safety But we have to have it there fundamentally for security as well as for safety We need to have that quality level there and What we've been trying to do though is with open source We have a very rapid change where new functionality is added and new features are added and so forth And so we've been working on a um development Repository and that has a release every four months And so it has a fairly frequent cadence and it comes up with Here's what we need to be doing um And here's new features and then we you know sort of make sure we have a release that we keep the squad Keep the squashing the bugs down things like that And then every two years we come up with our long-term support And we agree to maintain that and put security fixes and backports in Over time and then the safety and security process is we taking a subset of that LTS And that's that subset is what we'll be taking through the first certifications So that audible subset is you know, um, it's going to be established from that LTS and our LTS next LTS will be next year in the summer And we'll be keeping the code bases in sync with it and obviously the more rigorous processes We need and the traceability we need for those elements in there Are going to be um what we're focusing on The national processes are being you know developed by the safety and security committees and we coordinate with the technical steering committees And for this for Zephyr, we're basically trying to follow the more of a traditional beam model with Understanding you know the specification the features, you know making sure we've got the documentation the traceability You know the committers are known and information is known about them And then the goal is to improve the evidence That open source development can map So what we're looking at is okay as we understand Um our requirements for a reference system and Zephyr's components in there, you know Do we have um, you know the requirements documented and visible to everyone to provide feedback You know, how is the architecture going to work and then let's test all these steps all the way down And because Zephyr is a very modular framework. Um, we're taking advantage of that to just focus on some initial um elements There was Soon parts of that are stacked have been declared in focus initially and so the apis and then the basically subsets Of some of the devices in the kernel scheduler as well as interrupt handler power management So forth. These are all common elements that most systems need and that'll be the focus of the first You know our first one for 60.508 And then over time we hope to extend out to more and more of Zephyr as resources and interests emerge from our members and from the community as a whole You know some of the things that we've been talking about have been like crypto and the flash and the posix apis these are all elements that will probably be added as resources and Interest emerges in there. We've got this initial base. Um, stabilized So, um, right now we just finished putting out our 2.4 release and we have as part of that There was a project coding guidelines that were made visible We're working on our tooling processes right now And starting to work up the documentation that we're going to be needing for the safety scope And working on the tool evaluation so Engaging the certification authority. So we're working towards making sure we actually have all the evidence necessary For the augmentation and we're working towards having that ready. Um, when we get to the LTS Then we can be able to go through an assessment So if you're interested in learning more about Zephyr, um There's information up on our github repo or check out the website And um, we also have a Slack channel and there's a lot of orientation information out there too So feel free to have a look and subscribe to the mail list and work. Um, all's fine But certainly we welcome anyone's participation and um, obviously patches are welcome So in summary, um I think functional safety standards can coexist with the open source of projects, but we need to become efficient at scale and part of that efficiency at scale is, um Doing some abstraction and summarizing. Okay. Do we actually know all the components that are there? Can we put it our fingertips immediately? Um, and so can we need to look at getting that that part abstracted and getting that part automated And as you can sort of see, um In both Linux and Zephyr and the other projects, we need to make a very strict focus on quality and shrinking down the bugs And you know, we have to focus at that quality at each of those components has to be quality because when they're all put together We have to equality system. So we need to focus at quality at the project level And then we also need to quite frankly manage developer and certification authority expectations You know, we have to have all the fine scopes and we have to focus on our interfaces And then we have to understanding of, you know, the blocks inside those interfaces Um, and if we can get all of that pulled together I think we'll actually start to be in a really good position for doing the analysis and feeling confident that the software we're using in systems And particular for safety critical systems is as safe as we know how to make it With that, I will say thank you and I will be available in the channel for any questions you may have