Introduction to ELISA  ## Metadata - Author: [[YouTube]] - Full Title: Introduction to ELISA - Category: #articles - Document Note: --- tags: [linux-safety, elisa-project, safety-critical-systems] author: ELISA Project source: YouTube reference: https://www.youtube.com/watch?v=RDnTKTQKpzs date created: 2024-12-20 15:30 --- # 🏷️ Title: Introduction to ELISA - Enabling Linux in Safety Applications ## 🧰 Action Inbox - [H1] Join ELISA working groups to contribute to safety processes — automotive, medical, aerospace #elisa - [H2] Review ELISA GitHub repositories for tools and documentation — open collaboration #opensource - [H3] Apply STPA methodology to analyze Linux subsystems — hazard analysis technique #safety-analysis ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [ELISA Project](https://elisa.tech/) - [Linux Foundation](https://linuxfoundation.org/) ## 📝 Summary - ELISA (Enabling Linux in Safety Applications) is creating processes and tools to enable Linux in safety-critical systems across automotive, medical, and aerospace domains - The project addresses gaps in safety certification processes for Linux by developing open methodologies, reference implementations, and documentation - Key stakeholders include major tech companies (Red Hat, Intel, Bosch), automotive organizations (AGL), and aerospace companies (Boeing) - Main risks include the complexity of analyzing Linux's vast ecosystem and ensuring compliance with industry safety standards - Bottom line: ELISA enables collaborative development of safety processes for Linux without requiring companies to work under NDAs ## 📖 Main Content The ELISA project addresses the challenge of using Linux in safety-critical systems where traditional safety standards weren't designed for open-source operating systems. Linux offers significant advantages including active development (9 commits per hour), extensive hardware support, multi-core capabilities, and a large expert community. However, safety certification requires proven development processes and deep system understanding. The project operates through multiple working groups focusing on vertical domains (automotive, medical, aerospace) and horizontal concerns (architecture, tooling, processes). They use System-Theoretic Process Analysis (STPA) as a key methodology for hazard analysis, decomposing systems into controllable components with defined interfaces. ELISA's approach emphasizes creating open examples and reference implementations, contrasting with the typical industry practice of keeping safety analyses proprietary and under NDAs. The project develops processes, tools, and documentation rather than creating a specialized Linux distribution. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=0) — [H1] ELISA Project Introduction and Goals - Key idea: ELISA enables Linux in safety-critical systems through collaborative processes - Evidence: "Define and maintain a common set of elements processes and tools... amenable to safety certification" #### ⏱️ [02:30](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=150) — [H2] Linux Strengths in Safety Context - Key idea: Linux has inherent qualities that support safety applications - Evidence: "Nine commits an hour and one commit bug fixes per hour on LTS... multi-core support... hardware support is unmatched" #### ⏱️ [04:45](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=285) — [H2] Safety Standards Gap - Key idea: Current safety standards weren't designed for Linux-style development - Evidence: "Standards were not written with something like Linux in mind" #### ⏱️ [06:15](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=375) — [H2] Collaboration Challenges - Key idea: Safety analysis happens in isolation under NDAs preventing knowledge sharing - Evidence: "All this stuff right now happens behind NDAs and no one has examples" #### ⏱️ [08:00](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=480) — [H1] ELISA Working Group Structure - Key idea: Multiple working groups address vertical domains and horizontal concerns - Evidence: "Safety architecture... Linux features... tools and investigation... systems" #### ⏱️ [12:30](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=750) — [H2] Reference System Approach - Key idea: Open reference implementations enable reproducible analysis - Evidence: "Making it so that we can actually get the use cases... real system be reproducible without special hardware" #### ⏱️ [15:45](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=945) — [H2] Safety Architecture Analysis - Key idea: Understanding Linux subsystem interactions is crucial for safety - Evidence: "What is subsystem to Linux how do they interact is it going to cause problems" #### ⏱️ [18:20](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1100) — [H2] Linux Features Group Focus - Key idea: Configuration options need safety analysis and documentation - Evidence: "Taking a look at the preempt RT since it's almost upstream and there wasn't much documentation available" #### ⏱️ [21:00](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1260) — [H1] STPA Methodology Introduction - Key idea: System-Theoretic Process Analysis enables systematic hazard analysis - Evidence: "Hazard analysis technique... looking at control actions and then the response from the control action" #### ⏱️ [25:15](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1515) — [H2] Medical Device Case Study - Key idea: Artificial pancreas system demonstrates open safety analysis - Evidence: "Everything is open source so we can talk about it... FDA approved now" #### ⏱️ [28:40](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1720) — [H2] Workload Tracing Approach - Key idea: Tracing tools identify kernel subsystem usage for safety analysis - Evidence: "Using strace and perf scope... system calls or frequencies of calls for specific workloads" #### ⏱️ [30:45](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1845) — [H2] Aerospace Applications - Key idea: Linux usage in aerospace is growing and needs safety processes - Evidence: "SpaceX has been pretty visible about it... Linux has gone to Mars... up in satellites" #### ⏱️ [32:30](https://www.youtube.com/watch?v=RDnTKTQKpzs?t=1950) — [H1] Open Collaboration Model - Key idea: ELISA operates as an open community for safety process development - Evidence: "Open Community anyone can join in at any point in time and participate" ## 📚 References - [ELISA Project Website](https://elisa.tech/) - [ELISA GitHub Organization](https://github.com/elisa-tech) - [Linux Foundation ELISA](https://www.linuxfoundation.org/projects/elisa/) - [STPA Handbook](https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf) ## 🗣️ Paraphrase - ELISA creates collaborative processes to enable Linux certification in safety-critical systems across automotive, medical, and aerospace industries - The project addresses the mismatch between Linux's open development model and traditional safety standards through open methodologies and reference implementations - Working groups focus on specific domains while developing horizontal capabilities like architecture analysis, tooling, and system-theoretic process analysis techniques ## 📰 Newsletter The ELISA project is revolutionizing how we approach Linux in safety-critical systems! Instead of each company working in isolation under NDAs, ELISA creates open processes and tools that everyone can use and improve. Key highlights include working groups covering automotive, medical, and aerospace applications, plus horizontal groups tackling architecture, tooling, and processes. They're using innovative approaches like STPA (System-Theoretic Process Analysis) and creating reference implementations with real systems like artificial pancreas devices. This collaborative approach means faster innovation, shared best practices, and reduced costs for safety certification. Whether you're working in automotive systems, medical devices, or aerospace applications, ELISA provides the foundation for bringing Linux into safety-critical environments. Resources: [ELISA Project](https://elisa.tech/), [GitHub Repositories](https://github.com/elisa-tech), [Working Group Information](https://elisa.tech/working-groups/) ## ✅ Action Items #### OSPO - Policy & Governance: Review ELISA safety processes for organizational adoption - Community Engagement: Participate in ELISA working groups relevant to organizational domains - Strategic Alignment: Align safety-critical Linux usage with ELISA methodologies #### Community - Contributors: Join ELISA working groups to contribute safety analysis expertise - Maintainers: Integrate safety documentation requirements into Linux subsystem maintenance - Ecosystem: Coordinate with ELISA on cross-project safety requirements ## 🧪 Hypotheses - Open collaboration on safety processes reduces certification costs compared to proprietary approaches - STPA methodology can effectively analyze Linux kernel subsystems for safety-critical applications - Reference implementations accelerate safety certification adoption across industries - Working group structure enables both domain-specific and cross-cutting safety concerns to be addressed ### 📊 Methodology - Comparative analysis of ELISA vs traditional safety certification approaches - Case study analysis of medical device (artificial pancreas) safety certification - Working group effectiveness measurement through deliverable tracking ### ❓ Questions - How will ELISA methodologies be validated against existing safety standards like ISO 26262 and DO-178C? - What mechanisms ensure ELISA processes remain current with rapid Linux kernel development? - How can smaller organizations without dedicated safety teams adopt ELISA methodologies effectively? ### 🔮 Future Research - Integration of AI/ML safety considerations with traditional Linux safety analysis - Extension of ELISA methodologies to other open-source safety-critical components - Development of automated safety analysis tools based on ELISA processes ### 💡 Implications - Practice: Safety engineers can leverage open processes instead of developing proprietary methodologies - Policy: Organizations may need to update safety policies to incorporate open-source analysis methods - Education: Engineering curricula should include STPA and open-source safety analysis techniques - Funding: Collaborative safety development may require different budget models than traditional approaches ### 🧠 Learning Styles Assessment Reading level estimate: Grade 14 (Technical/Professional) #### 👀 Visual learners - Present: System diagrams showing STPA control loops, working group organizational charts - Improve: Linux kernel architecture diagrams, safety analysis flowcharts, reference system visualizations #### 🔊 Aural learners - Present: Video presentation with speaker narration - Improve: Podcast series on safety methodologies, working group meeting recordings #### 🗣️ Verbal learners - Present: Technical terminology with context, analogies to traditional safety processes - Improve: Glossary of safety terms, comparison tables between standards #### 🧩 Kinesthetic learners - Present: GitHub repositories for hands-on exploration, reference implementations - Improve: Step-by-step safety analysis tutorials, interactive STPA workshops #### 🧠 Logical learners - Present: Systematic working group structure, methodical STPA decomposition - Improve: Decision matrices for tool selection, quantitative metrics for safety processes #### 🧑‍🤝‍🧑 Social learners - Present: Multi-company collaboration model, open working groups - Improve: Mentorship programs, cross-industry collaboration frameworks #### 🧘‍♀️ Solitary learners - Present: GitHub documentation for self-study, recorded presentations - Improve: Self-assessment checklists, individual learning paths through safety concepts #### 🌿 Naturalistic learners - Present: Real-world system examples (automotive, medical, aerospace) - Improve: Ecosystem thinking about safety interactions, lifecycle perspectives ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has spoken narration describing visual content - Improve: Structured headings in documentation, alt text for diagrams #### Keyboard navigation - Present: Standard YouTube controls accessible via keyboard - Improve: Ensure GitHub repositories follow accessibility guidelines #### Contrast and readability - Present: High contrast slides with clear text - Improve: Color-blind friendly diagrams, sufficient text size in technical drawings #### Text resizing and reflow - Present: YouTube player supports zoom functionality - Improve: Responsive documentation design, scalable diagram formats #### Media and captions - Present: Audio narration available - Improve: Closed captions, downloadable transcripts, audio descriptions of visual elements #### Forms and interactions - Present: Standard GitHub interaction patterns - Improve: Clear labels for submission processes, accessible error handling ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global industry participation (automotive, aerospace, medical) - Improve: Non-Western safety standard integration, developing country participation #### Inclusive language - Present: Technical terminology clearly defined in context - Improve: Plain language summaries, multilingual documentation options #### Neurodiversity support - Present: Structured presentation format, clear section divisions - Improve: Executive summaries, consistent navigation patterns #### Representation - Present: Industry diversity across working groups - Improve: Diverse speaker representation, varied use case examples #### Psychological safety - Present: Open collaboration emphasis, welcoming community language - Improve: Clear contribution guidelines, conflict resolution processes ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Linux challenges → need for processes → collaborative solution (strong) - Inductive strength: Multiple industry examples support general principles (moderate) - Causal reasoning: NDA isolation causes duplication → open processes reduce waste (strong) - Analogical strength: Traditional safety standards : proprietary systems :: ELISA : open source (strong) #### Fallacies - Appeal to authority: "SpaceX uses Linux" - legitimate example but not comprehensive proof of safety - False dichotomy: Implies proprietary vs open as only options - hybrid approaches exist #### Tone of voice - Overall tone: Professional and collaborative, emphasizing openness and industry cooperation with technical authority ### 🛡️ DARVO Analysis - Deny: No significant denials present - Attack: No attacks on critics or alternative approaches - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive framing of collaboration, factual presentation of technical challenges ## 🎯 Conclusion ELISA represents a paradigm shift toward open collaboration in safety-critical Linux development, moving away from isolated, NDA-protected analysis toward shared methodologies and reference implementations. The project's multi-domain approach (automotive, medical, aerospace) combined with horizontal technical capabilities (architecture, tooling, processes) positions it to standardize safety practices across industries. Practitioners should consider joining relevant working groups and adopting ELISA methodologies, particularly STPA for hazard analysis. The project's open approach promises to reduce certification costs and accelerate innovation in safety-critical Linux applications while maintaining rigorous safety standards. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] ELISA enables collaborative Linux safety certification > [!quote] Introduction to ELISA by ELISA Project via YouTube. Published 2024. Accessed 2024-12-20. > "Define and maintain a common set of elements processes and tools amenable to safety certification" Addresses industry need for standardized open-source safety processes. [view highlight](https://www.youtube.com/watch?v=RDnTKTQKpzs#H - Document Tags: [[h]] [[elisa]] [[safety]] [[opensource]] - Summary: Introduction to ELISA - URL: https://www.youtube.com/watch?v=RDnTKTQKpzs so welcome um we're here to talk today about Elisa and what's happening in the project as well as moving our and you know what's emerging and what's interesting so we've got a pretty good uh lineup here for you um for those who want to join we have a zoom room going and if you want to take a picture of that QR code the information is there and hopefully if you are wanting to interact with us we don't have a chat channel so if you wanted to get into the zoom room and chat or ask questions that may be a way of getting some interaction going between the virtual participants and the people here in the room today and I will just leave that up for another minute so let's go there we go so for today um we've got we're going to start off with a bit of an introduction about Lisa and then we'll be telling you discussion about the automotive use case that's one of our more active groups and then we will be having at 2 30 um we'll have you a virtual participant coming in and uh she'll be going through how we've been looking at analyzing the Linux kernel and subsystems we'll have a bit of a break and then come back looking at analyzing Linux as part of a wider system and then we will um I I think we've just heard that our Aerospace person can't make it today so we may not be skipping that part forward and trying to give a little bit of information there but not much and then just questions so that's the outline for today if people have things they want to interject into the schedule you know please come see us at the break Philip is here I'm here from the project and we're happy to take the discussion where we want it to go so with that what does it mean to have Linux in a safety critical system that's what Elise is standing for enabling Linux and safety critical systems well at the whole of it all we have to assess whether the system is safe and that requires understanding a system it's not just Linux it's actually understanding your system that Linux isn't participating in and you know understanding Linux in the context of that system and what parts of Linux are being used is what we have to be focusing on to do the analysis properly and then realistically Linux is a variety of components it's a very very rich ecosystem and so how do you assess which pieces are actually getting engaged in a potential safety function and then quite frankly we've got a lot of gaps here and how do we identify the gaps so these are the thinking that must have gone in behind the Elisa's story and you know in safety critical systems uh the latest code has a large development ecosystem which is the strength it's probably one of the most active projects out there um stats I keep in my head are nine commits an hour and one commit bug fixes per hour an LTS back porch so we see a lot of change happening in that code base there's a lot of focus on security there's a lot of analysis that goes on in this space for fuzzing and so forth and things that help improve the quality this multi-core support there's you know the hardware support is unmatched in the least kernel and we have many experts available so a lot of the pieces that we need are effectively there the challenge becomes okay can we have high real time well actually that's finally getting merged upstream and hopefully we should be there any day now and then you know do we have proven safety compliant development processes well that's the chat one of the bigger challenges because the standards were not written with something like Linux in mind and so how do we start doing the analysis in a way that we can actually be effective and this is you know how we tackle these differences and this has been the problem that's out there and we know Linux is being used in safety critical systems the people won't admit it because it's all under NDA but we know it's out there and the question is you know how do people do the analysis so they can trust it and what are the key requirements and so forth so how we can sort of get these tax gaps tackled is our challenge so what we've been trying to look at is you know functional safety at the heart of it seems to be about managing the risk in product development and you know to understand the risks in the system you have to understand the system and the kernel knowledge and not a lot of people have that deep Pro launch there's a lot of criminal experts out there that have the knowledge but surfacing it in a way that they people can consume it has been one of the challenges so I think you know there's a lot of starting points for understanding this but nothing's really pulling it together in a way that's digestible and consumable be it for the people who are doing the assessments or the developers doing things so what we need to do is figure out how we can you know collaborate between the people who are doing the assessments and the people who are actually developing products my apologies I am coming up I'm just getting over a cold and it's showing up anyhow part of the challenge right now for us is understanding the limits of what we can collaborate on you know this project is not one to make a system safe okay we can't engineer it we can't ensure that when we come up with processes that you'll apply them properly but we can at least come up with things that we can recommend and you know we kept creating out of tree leaves kernel that is fit for all safety critical applications there's always that continuous process Improvement that's happening and there are companies that want to make a business all of that and that's good but but we can and we can't relieve your responsibilities and legal obligations but we can provide people to collaborate with and build up industry norms so getting it to the stage where we all agree on a common way of doing things helps us move forward and these are some of the people who are collaborating today with us so we've got a fairly wide set of participants who I've been willing to be visible about saying they're trying to collaborate here to make this better including a lot of Open Source projects like cylinder structure Automotive grade Linux and so forth that are actually supporting the project and are participating in trying to figure out what a best practice is so the mission of Elisa is to Define and maintain a common set of elements processes and tools we have some code out there but that is not the main focus it's not like a project creating code it's a project creating processes and tools and we want to do this to make things amenable to safety certification so the scope does include software and documentation development and everything is being done under OSI approved license but um the hope is that we're coming up with processes and methodologies that people can apply outside of the context of this project in our work groups so how we observe approaching this from a technical strategy perspective well we have some deliverables coming out of the Elisa project and sorry what we're trying to get sorry what we're trying to get with them is examples all this stuff right now happens behind ndas and no one has examples so when they've worked out things they can't share it so they sort of know what they're doing and they may convince some assessors that they know what they're doing on the other hand they can't share it no one can listen from it learn from it given that they're all working with open source it seems like a bit of a waste so what we're trying to do is do things in the open try to work through Assessments in the open through ideas and methodologies so that we can have things that are reference for other people to build from and the assessors will have something to look at and thank you for your patience dealing with me with this cold so I thank you again now the way we're sort of working this structure ourselves is we've got some various working groups that some are focusing on verticals like Automotive medical and Aerospace you'll hear those today but then we have groups are looking at engineering processes for open source how do they work what's the architecture look like for the Linux kernel that's a safety architecture group that's what are the features how we decompose it how we explain the interfacing and then we have a whole bunch of config options right now in the Linux kernel how do they Implement safety when they're actually turned on or off so those groups we're looking at that we have another group that systems and that's trying to put it all together we've got the Linux kernel working with the Zen hypervisor working within our toss that's what systems are looking like today we've got all these pieces coming together and coming up with something reference becomes useful because it's an open place to experiment so we also are having tools and code implementations to help with this whole system inside and all of these together become the Elisa deliverables than what we're working on was a project so let's look a little bit more about those working groups I just introduced the safety architecture one is being led by Red Hat the safety architecture one is looking at the latest kernel and going down and doing analysis of parts of Link's kernel the list features one is the mobile ion Intel are taking sort of the point on that one of what is actually happening and they're sort of studying what's going on with which options and right now they're focusing on real time because that's almost Upstream the tool and investigation is coming up with tools that we work into the flows to make it available an electric bit and code thinker active there and then the osep one is the processes code think is being very active on taking the lead in that one and then systems Bosch which you'll hear from Philip a little bit later is how we put a reference system together and pull some of all this together so those verticals Aerospace is very new and Boeing is basically pulling together people in the industry to actually look at the problems for 178c and what the implications are for Linux the automotive working group Bosch is taking the point on that one and in medical devices we've got an open source project and so some of the facts from codethink and myself are looking at how we can actually decompose a problem and do the analysis properly um so this these are sort of what we're after you can see this for poetry yeah it does so you know this is the ATL dashboard there's a little dangerous thing up there that's it from a Telltale that's all you know basically there's a lot behind getting that there and getting it working and Philip will go into that details here is an insulin pump system everything is open source so we can talk about it see you know see the problem about talking about things and so these are the examples we've been using for doing some of the analysis up till now we'll find more over time the systems um working groups fitting everything together and making it so that we can actually get the use cases combining them in a real system having that real system be reproducible without special Hardware and then you know working with things like yocto and build systems and coming out with intermediate hypervisors and how these all can hook together is the challenge for us and hopefully if we can get this system set up then if people need to substitute other things in for their own environments they have places to plug into and help refine this reference that's what we're trying for anyhow now in terms of the artifacts and activities we're going after pretty much we're looking at Elements which are the software process for working with the elements tools to help us in documentation um there's elements from each of these working groups are doing parts of things and participating in these different ways and so we've got things like white papers we've been sending things up to the Linux kernel for documentation on how to go about doing traces for instance and using what's in the kernel to do the trace is to get the evidence you need for the flows how the qualities are doing what the code Checkers are the process is we've been really we started off medically working with stpa proved to be a very useful technique it's being used in automotive and in the architecture group now and so adopting some of these newer techniques and showing how they can be working from a system context is good we've also got things like meta Elisa for pulling all the pieces together foreign Philip will be basically going through the automotive and the systems working group in much more detail so I'm not going to spend much time right now um a little bit more on the safety architecture one though um you know what is subsystem to Linux how do you actually care like how do they interact is it going to cause problems these are things that people you know we have well-defined interfaces in the Linux kernel this API and so forth but with inside there are things that have been tested and known to be working by what but it's not documented anywhere effectively I think you find it in parts of documentation you find in Parts man Page by looking at it is from the safety perspective doesn't seem to be there so how do we get to the stage where we can actually explain that yes you're okay to use this and what are the requirements from the kernel that should be held to that you could count on for this type of work um what we're doing right now in this group is looking at STP analysis inside the kernel and looking at tools and techniques this team came up with a call tree analysis and a kernel s nav case nav tool for looking at representations of source code to try to understand how it all fits together and interacts I have to remember I'm better in the morning than in the afternoon anyhow um and so it's providing insights about how the kernel is all constructed that's what we're trying to do with this group so everything is up on GitHub now or at least it's in that direction and so if you want to go play with it it's there to play with for the Linux features in the safety critical system um there's all sorts of ways of trying to understand how the config options are there on the Kernel May interact with the safety side of it what actually this plays together with and understanding how the intervals and externals work and what you turn on when you don't turn on figuring out what's really relevant and get yeah it's all that understanding is what this group is trying to get at um what we're sort of doing with it right now is taking a look at the preempt RT since it's almost upstream and there wasn't much documentation available for it and so this group is basically going and taking a good look hard look at what's happening with the preempt and helping to document it from the perspective of the safety side so anyone who's interested in the RT side is welcome to join in on those discussions and look at the features and how they're interacting so you know how the memory protection Works how the fault handling is working the test infrastructure for checking that you've actually satisfied and you haven't changed anything and doing effectively audit of the system requirements that are interacting with the real time so so these are all the uh this is what this group is focusing on right now so if that's an interest area to you by all means please join in and then on the tool investigations what they're trying to do is um how do we make the kernel better how do we improve the quality of the kernel you know running the various um code Checkers and sis colors and so forth and sending patches and just starting to work with the process of the kernel so that we're not it's a good place to on-ramp into the kernel um and then help you to clean up the documentation that's what this team is looking at right now and they're mostly looking at some of the cict stuff Improvement they also interact to a large extent with the systems team with some of our CI flows now the osep group is looking at the processes and techniques for the safety engineering principles being implied to systems that have Linux kernel and so this in some ways is at the heart of what we're trying to do with this whole project and they're sort of trying to focus at a methodology of how do we actually start to explain this all and there's been a lot of discussions and a lot of analysis that have gone on there and I think the framework is starting to emerge so you can look on the mail list and see some recent discussions on that that Paul has put up and so I'm hoping you know we're sort of I think getting in that stage where we're moving it forward now but identifying a documenting the safety requirements using stpa is something that we've had some success with and so you'll see a bit of that there too so what is this stpa I keep on saying well it's system theoretic process analysis it's a it's a way of looking at things from the process of being decomposing a system down came out of MIT there's various working groups that have been using it in the safety space for a while now and everything is open so again it's a process that's open we can go and look at it you can see it you can take and build from it the idea behind is very basic um it's a hazard analysis technique and what it's doing is looking at okay different diagram of thought um you know there's inputs and outputs and you're looking at control actions and then the response from the control action and it's that control action and the response from the control action and being able to analyze the system in that way lets you start to get at the interfaces and this lets you start to segment the problem into something you conceptually decompose oops thank you it was there anyhow so as you see you've got controller with an algorithm or process you put a control action into your process that's getting controlled in feedback and what you do is you basically look at your entire system in this way and you successively decompose all the way down until the level you want what you want to focus on and so you know what we've been looking at is in like the medical devices we've been basically decomposing from a level one level two to level three and level three is effectively in the kernel frauds okay um and so hello the the background we came up with this is the artificial pancreas system and going down successfully that level one and level two analysis that you sort of see here we actually had to iterate it we actually came up with an initial level one and then we had to go down to level two and we went oh we forgot this so we could go back up to level one and realize oh we have to put the more information in and so this is a way that you can successively refine to actually get a common a good understanding of a system and build up consensus and so we started looking at you know what's happening with 62 304 for the soup requirements how does it interact with the formal standards and you know best and we started working on okay we're into level three right now we're trying to trace the kernel and so we can with a white paper on how to do the tracing and you'll be hearing more from shua a little bit later on that and how you can use some of the tools that are out there today to do the right level of tracing to get to the point where we can do a level three analysis and so um you know this is one of them and you know anything from the Elder developers the open APS system it's going to a a glucose monitor can you click this monitor there's an insulin pump and it's interacting with the human body all this is out there and actually it's FDA approved now there's actually been FDA approval and Analysis of it um as a system and there's other open source ones that have also got an FDA approval too and realistically someone I can point you at papers which uh there's been scientific studies there showing that this is doing a better job of monitoring glucose levels over time and keeping things at a reasonable perspective on the other hand it's a hobbyist project and people are not making advertising budgets out of it but it's a good system for us to analyze because it's all available it's not behind any ndas and so this was why we started looking at this so we're always looking for good open source systems so that we can go and look at from the safety implications and we found that SCPA was a really good technique for us to start to hone in on what was really important here and so as you can see when we take it down to level two also looking at the system itself it's running on a Raspberry Pi off the shelf Hardware right it's got a tool kit ready on it it's got an algorithm a lot of the algorithm is what the scientific papers will focus on we're focusing on what's happening with Linux what's happening in and out of Linux could Linux make things go wrong here and we find a lot of applications out there that safety critical have Linux sitting as a substrate that people are even paying attention to under there and so what we're trying to do is figure out okay what parts of this engage when this is running and how do we start looking at are the requirements necessary for the system to be effective being satisfied so well the recent stuff we've been working has been looking at the workload tracing and so using a straf and CS scope has been getting us most of it what we've been needing actually and so we've got the system calls or frequencies of calls for specific workloads which is what people will do in a safety analysis anyhow they'll basically have a whole series of workloads that they're going to talk through to work through and we're sort of you know coming up with this on our own and then look at what's happening from the tracing perspective to see what parts of the kernel are promote and then we can do an STP analysis on those pieces of the kernel and see how the triggers are working now Aerospace is a new one and I haven't been sitting in many of their meetings so I can't talk too much about them but what they're trying to do is um well you know for a fact that links is being used in various applications um basically SpaceX has been pretty visible about it that they're using Linux today and we know that you know others are wanting to do it and I know this group is trying to figure out okay well what do we really need to think about here when we're working with it based on these standards which are very high Assurance levels and so for the avionics industry you know how do we get to that insurance level and what sort of checks what we need I suspect there'll be elements of what we found in other groups however the working groups formed and if you're interested in the Aerospace use cases we're definitely interested in there's a spot for you to collaborate here um you know we know that it's being used it is a broader industry than just the uh safety critical here like you know things on the back of your mind your back of your seats things like that but there's also the places where it's moving into that safety critical space and that's where we want to make sure we get ahead of it we know that links has gone to Mars for instance we know that it's up in satellites there is aspects of it that are already being used in practice the question is when it comes safety critical do we have the right level of analysis um and do we have it visible so there are certain applications that they're looking at on the traditional Aerospace the air taxi stuff and various commercial drones these are the scenarios that this group is looking at to try to understand what the implications are so with that I will say um if any of this is interesting to you by all means it's an open Community anyone can join in at any point in time and you know participate in the meetings documentation and so forth what we're trying to do though is come up with processes and so there's if you so this process discussions that are going on and that's just part of trying to get a better consensus built up there's also tooling though so if you're interested in that's What Makes You Happy there's there's tools that we need no question and with that here's a link on the slides for all the various places where we're meeting for the various working groups as well as reviewing the content as it goes up to GitHub and reviewing the various repositories and with that is anyone have any questions if there's anyone online that has questions by all means we've got that Zoom meeting thing so feel free to chat put questions in the chat or respond on and anyone in the room no okay most of these people know so with that then I will hand it over to oh go for it yeah we'll put the slides up there no worries thanks we'll be there before the evening I guess yep just in time slides you know that drill drill don't you think I have my yeah yeah, Introduction to ELISA, YouTube, 01ka7pkt0y6shh80cs6bcdk7y6.