Automotive Use Cases Analysis  ## Metadata - Author: [[YouTube]] - Full Title: Automotive Use Cases Analysis - Category: #articles - Document Note: --- tags: [automotive, safety, linux-kernel, embedded-systems] author: ELISA Project source: YouTube reference: https://www.youtube.com/watch?v=cjLdgcsF6ac date created: 2024-12-28 19:30 --- # 🏷️ Title: Automotive Use Cases Analysis - Dashboard Safety Implementation ## 🧰 Action Inbox - [H1] Set up continuous Docker image builds — weekly full builds, nightly dev builds #automotive #ci-cd - [H2] Implement SBOM generation in Yocto build process — ISO 26262 compliance requirement #safety #compliance - [H3] Migrate from QEMU to real automotive hardware — Raspberry Pi to NXP/Qualcomm evaluation boards #hardware #testing ## 🧭 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 GitHub](https://github.com/elisa-tech) - [Automotive Grade Linux (AGL)](https://www.automotivelinux.org/) ## 📝 Summary - The ELISA automotive workgroup analyzes safety requirements for automotive dashboard systems under ISO 26262 - Dashboard telltales provide a good starting use case with explainable systems, relaxed timing constraints, and existing demo implementations - The team has built comprehensive CI/CD infrastructure using Docker, GitLab runners, and OpenQA for automated testing - Safety analysis using STPA methodology reveals need for both forward-path safety measures and backward-path verification - Next steps include workload tracing, hardware migration, and integration with broader automotive system contexts ## 📖 Main Content The ELISA automotive workgroup focuses on analyzing Linux kernel safety requirements for automotive applications under ISO 26262 functional safety standard. They selected dashboard telltale systems as their primary use case because these warning indicators represent safety-critical information that drivers must receive reliably. The dashboard use case offers several advantages: it provides explainable system behavior (warning lights have clear meanings), has evolved from hardware LEDs to software-driven displays, allows for aesthetic customization while maintaining safety, and has more relaxed timing constraints compared to hard real-time systems. When a warning light appears, drivers typically have seconds to minutes to respond rather than microseconds. The team built extensive development and testing infrastructure including Docker containerization, continuous integration via GitLab runners, and automated testing through OpenQA. This infrastructure allows developers to modify code and automatically validate changes without manual testing overhead. Safety analysis using Systems-Theoretic Process Analysis (STPA) methodology revealed that safety cannot be achieved through forward-path rendering alone. Any safety-critical display system requires backward-path verification to confirm that rendered output matches intended output, along with external watchdog mechanisms as final safety nets. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=0) — [H1] Automotive Workgroup Introduction and Objectives - Key idea: Analyze automotive safety requirements and derive kernel requirements under ISO 26262 - Evidence: "We want to see and discuss the conditions prerequisites whatever is needed in the automotive sector to Target use cases" #### ⏱️ [02:30](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=150) — [H2] Dashboard Use Case Selection Rationale - Key idea: Dashboard telltales provide explainable safety-critical systems with manageable timing constraints - Evidence: "Warning signs are the gear indication warning signs are the check engine oil pressure whatever you can expect and they need to be there displayed as saved information" #### ⏱️ [05:15](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=315) — [H2] Technology Evolution from Hardware to Software - Key idea: Automotive displays evolved from light bulbs to LEDs to software-driven displays - Evidence: "Originally with light bulbs then they turned into LEDs and the LEDs are now going into the display so you can see it's much more software driven" #### ⏱️ [07:45](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=465) — [H2] Relaxed Timing Constraints Advantage - Key idea: Dashboard warnings allow seconds to minutes for driver response unlike hard real-time systems - Evidence: "Every course everybody of you will just hit the emergency brake check the manual and look what the light means" #### ⏱️ [10:20](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=620) — [H2] AGL Partnership and Demo Implementation - Key idea: Automotive Grade Linux provides existing dashboard demo implementation as starting point - Evidence: "There is already a demo implementation of it available which was created by the automotive grade Linux" #### ⏱️ [12:50](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=770) — [H2] Qt Licensing Challenges and Flutter Migration - Key idea: Qt license changes drove automotive industry toward Flutter rendering framework - Evidence: "With the latest license changes of cute people moved on and say well it's not so commercially attractive for automotive anymore" #### ⏱️ [15:30](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=930) — [H2] Safety Indication Implementation - Key idea: Danger sign implementation demonstrates fault detection and safe state transition - Evidence: "This danger sign is for you illustrating that we are in the system that we hook on do some modifications" #### ⏱️ [18:45](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=1125) — [H1] Docker and CI/CD Infrastructure Development - Key idea: Comprehensive containerization and automation infrastructure supports multi-platform development - Evidence: "We started with this description we moved on we figured out that some people may use open source Tumbleweed rather than others using maybe Fedora Linux" #### ⏱️ [22:10](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=1330) — [H2] GitHub and GitLab Integration Strategy - Key idea: GitHub for source control, GitLab for CI/CD provides better access control and server security - Evidence: "Source code is on GitHub while the CI runs in gitlab it was a little bit better for the user handling" #### ⏱️ [25:40](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=1540) — [H2] Build Verification Beyond Compilation - Key idea: CI system performs boot testing and image rendering verification, not just compilation - Evidence: "It's not only building it's also checking that the system boots because if it would just build you don't know if things work out of the box" #### ⏱️ [28:15](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=1695) — [H2] External Dependency Monitoring - Key idea: Build failures often result from external dependency changes, not code modifications - Evidence: "It's not always the build which caused the issue it could be just recently that the cooks are stack which we are using had the client and server certificates expired" #### ⏱️ [31:20](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=1880) — [H2] OpenQA Automated Testing Integration - Key idea: OpenQA provides visual regression testing with timeline scrubbing and video recording - Evidence: "You can basically move it from left to right where we do a qmo emulation reboot the system and you can move the slider to see an expected and the real rendered output" #### ⏱️ [34:50](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=2090) — [H1] Complete Development Pipeline Flow - Key idea: Integrated pipeline from meta-eliza recipes through Docker to automated testing - Evidence: "From a development perspective we start with the meta elizer within the meta lighter there are the bit big recipes" #### ⏱️ [38:30](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=2310) — [H2] SBOM Generation Implementation - Key idea: Software Bill of Materials generation integrated into Yocto build process for compliance - Evidence: "We also work on aspomb generation so we are just switching it on we figure out that some function were not there" #### ⏱️ [42:15](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=2535) — [H1] STPA Safety Analysis Methodology - Key idea: Systems-Theoretic Process Analysis provides modern safety analysis approach for complex software systems - Evidence: "What I really like about this stpa thing is it's quite new and a lot of the other techniques are coming from the 70s and 80s" #### ⏱️ [46:40](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=2800) — [H2] ASIL Safety Integrity Levels - Key idea: Automotive Safety Integrity Levels range from QM (quality managed) to ASIL-D (highest safety requirements) - Evidence: "The Azle D would be really something for autonomous driving very high level while lower level A and B you could find for lower level of safety" #### ⏱️ [49:25](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=2965) — [H1] Forward vs Backward Path Safety Architecture - Key idea: Safety requires both forward-path rendering quality and backward-path verification mechanisms - Evidence: "You cannot make everything safe in this forward part you will always have a backward checking element in there which guarantees" #### ⏱️ [52:50](https://www.youtube.com/watch?v=cjLdgcsF6ac?t=3170) — [H2] External Watchdog as Final Safety Net - Key idea: Challenge-response watchdog provides ultimate safety mechanism outside Linux system - Evidence: "This Watchdog makes sure it's clever enough checking elements and does this check and this is just the last safety case" ## 📚 References - [ELISA Project GitHub Repository](https://github.com/elisa-tech) - [Automotive Grade Linux](https://www.automotivelinux.org/) - [ISO 26262 Functional Safety Standard](https://www.iso.org/standard/68383.html) - [OpenQA Testing Framework](https://openqa.opensuse.org/) ## 🗣️ Paraphrase - The automotive workgroup analyzes how to make Linux kernel components safe enough for automotive dashboard systems that display critical warning information to drivers - They built comprehensive development infrastructure using Docker containers and automated testing to make it easy for contributors to modify and validate automotive safety systems - Safety analysis revealed that automotive displays need both high-quality rendering and separate verification systems to ensure drivers receive accurate warning information ## 📰 Newsletter **Automotive Safety Meets Open Source: ELISA Project Tackles Dashboard Systems** The ELISA project is pioneering automotive safety analysis for Linux-based dashboard systems. Their comprehensive approach combines modern safety analysis methods with robust CI/CD infrastructure, making it easier for developers to contribute to safety-critical automotive software. Key highlights include automated Docker-based development environments, OpenQA visual testing, and STPA safety analysis methodology. The team discovered that automotive safety requires both forward-path quality measures and backward-path verification systems. This work directly impacts the future of software-defined vehicles and demonstrates how open source methodologies can meet automotive safety standards. Resources: [ELISA Project](https://elisa.tech/), [Automotive Grade Linux](https://www.automotivelinux.org/), [Yocto Project](https://www.yoctoproject.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Present automotive safety findings at embedded Linux conferences - Education: Create workshop materials for STPA safety analysis methodology - Developer experience: Improve Docker container documentation and setup guides - Community management: Facilitate automotive workgroup monthly meetings and discussions #### OSPO - License Compliance: Monitor Qt licensing impacts on automotive open source adoption - Security Management: Implement SBOM generation for automotive supply chain transparency - Software Inventory: Track automotive-grade Linux component dependencies - Community Engagement: Strengthen partnership with Automotive Grade Linux project #### Community - Maintainers: Support AGL maintainers with safety analysis feedback and requirements - Contributors: Create good-first-issue programs for automotive safety testing - Ecosystem: Coordinate with automotive hardware vendors for evaluation platforms #### Automotive - Safety Analysis: Complete STPA analysis for dashboard telltale systems - Hardware Migration: Transition from QEMU emulation to automotive-grade hardware platforms - Standards Compliance: Align implementation with ISO 26262 functional safety requirements - Workload Tracing: Integrate kernel workload analysis for performance characterization - Testing Infrastructure: Enhance OpenQA integration with GitLab CI feedback loops - Documentation: Create comprehensive automotive safety analysis methodology guides ## 🧪 Hypotheses - Dashboard telltale systems provide optimal entry point for automotive Linux safety analysis due to explainable behavior and relaxed timing constraints - STPA methodology reveals safety requirements missed by traditional automotive safety analysis approaches from the 1970s-1980s - Backward-path verification is mandatory for safety-critical display systems regardless of forward-path rendering quality - Automated testing infrastructure reduces barriers to automotive safety development contribution ### 📊 Methodology - Implement comprehensive CI/CD pipeline with Docker containerization and OpenQA testing - Apply STPA safety analysis to automotive dashboard use case - Compare traditional FMEA approaches with STPA findings for complex software systems ### ❓ Questions - How can SBOM generation be made complete and accurate for complex Yocto-based automotive systems? - What are the performance implications of backward-path display verification on automotive Linux systems? - How should safety analysis change when moving from single-system to containerized/virtualized automotive architectures? ### 🔮 Future Research - Integration of automotive use cases with broader ELISA systems workgroup demos - Migration from QEMU emulation to automotive-grade hardware platforms (NXP, Qualcomm, STMicro) - Extension to additional automotive use cases including park distance control and camera systems ### 💡 Implications - Practice: Automotive developers need both forward and backward safety verification mechanisms - Policy: SBOM generation becomes mandatory for automotive supply chain transparency - Security: External watchdog systems provide final safety net for software-defined vehicles - Education: Modern safety analysis methods (STPA) complement traditional automotive approaches - Funding: Investment needed in automotive-grade hardware platforms for realistic testing ### 🧠 Learning Styles Assessment Reading level estimate: Grade 14 (Technical/Professional) #### 👀 Visual learners - Present: System architecture diagrams, CI/CD pipeline flows, safety control structures - Improve: Additional hardware migration diagrams, STPA process visualizations #### 🔊 Aural learners - Present: Conference presentation format with verbal explanations - Improve: Audio summary of key safety concepts and technical requirements #### 🗣️ Verbal learners - Present: Technical term definitions (ASIL, STPA, AGL), automotive context explanations - Improve: Glossary of automotive safety terminology, analogy-based explanations #### 🧩 Kinesthetic learners - Present: Docker setup instructions, hands-on demo implementation, CI/CD pipeline interaction - Improve: Step-by-step safety analysis worksheets, hardware evaluation board tutorials #### 🧠 Logical learners - Present: Safety analysis methodology, pipeline dependency flows, systematic testing approach - Improve: Decision trees for safety analysis steps, requirements traceability matrices #### 🧑‍🤝‍🧑 Social learners - Present: Workgroup collaboration model, community contribution processes - Improve: Peer review processes for safety analysis, - Document Tags: [[ci]] [[safety]] [[hardware]] [[automotive]] [[compliance]] - Summary: Automotive Use Cases Analysis - URL: https://www.youtube.com/watch?v=cjLdgcsF6ac okay so I'll give it a start right I've been oh passcode five three three seven five six at the passcode so my ID 949 only if you join the zoom you can see it right here I don't know if someone maybe can share it on the platform okay you're good okay then I'll kick it off with the automotive work group first of all let's take a short look on what we are aiming for so we want to see and discuss the conditions prerequisites whatever is needed in the automotive sector to Target use cases there we want to derive requirements from the use case and what it needs to the kernel what it means to the development process of it we know there is the iso 26262 which put High demands on the safety in the car and yeah and to start with we're very open for any use case which could come up and the first use case which we took while the dashboard why have we selected the dashboard there are multiple reasons in there one is that it comes with good explainable system so if we take the dashboard with warning signs warning signs are the gear indication warning signs are the check engine oil pressure whatever you can expect and they need to be there displayed as saved information because if something is wrong with your car you need to be informed another thing which is happening is that in the past it were originally with light bulbs then they turned into LEDs and the LEDs are now going into the display so you can see it's much more software driven than in the past but this gives you another reason to put it in because the next thing is someone may want to start nice blending around it wants to make it more pretty wants to have some animated whatever things in there to have The Telltale experience matching the whole car infrastructure another thing which is nice of this is that it's not only software driven these days it's also that it has a good timing constraint so if you imagine the use case you're driving on the highway with the maximum speed suddenly a light bulb goes on so every course everybody of you will just hit the emergency brake check the manual and look what the light means or maybe you just wait for some time to look for the next parking place or even go home because you think well my car will not die it feels just driving normal but I should know about it so this gives you more relaxed timing constraint than hard real-time demands the last benefit which we have in with this use case is that there is already a demo implementation of it available which was created by the automotive grade Linux they mentioned us as a partner project and typically also refer to us if it comes to the questions in their instrument cluster use case working groups and so on the latest release which AGL did I guess is cold or there was one last octopus I guess and we are still on needlefish the main reason why we are a needlefish is that it's our demo is QT based with the latest license changes of cute people moved on and say well it's not so commercially attractive for automotive anymore for some members at least and but this the main track is now going to flutter there's a new rendering framework but the lower layers where we are looking in into the kernel into the graphics subsystem it's basically independent from this upper layer so and what we did as extension with this meta elizer layer which we put to the OCTA tools is that we add this little danger sign which you can see there in real systems you would not put this danger sign so this danger sign is for you illustrating that we are in the system that we hook on do some modifications and this illustrates this just we detected the fault this is danger and then we would reboot trigger watchdog or whatever and go into a safe state all right you will find a lot of these instructions in the meter Elisa on the GitHub repo so just go on github.com slides will be uploaded as mentioned so for this there is no need to click on it now it provides a longer description on it how to use it and it gets combined with the work group Automotive we did this because we had people hopping on and off the discussion the work groups and we discussed it again and did again how things look like and well documentation is very important it's not only important for safety It's always important for open source and principle and you want to make life easy for people to hook on so we started with this description uh we moved on a little bit on this we figured out that well some people may use open source Tumbleweed rather than many you others using maybe Fedora Linux or go also for Ubuntu so by this we saw there are differences next thing what we did was setting up a Docker container so that you have a Docker file then some people were didn't want to run the docker file to create the image so we were providing the image and we were growing this step by step and from time to time there are always people who want to start from scratch again so they just follow the instructions currently we have a New Journey in the group who said oh yeah I know there is this Docker file I know everything is available but I want to read the instructions again and actually I found already two broken links because the Octo project just updated things and it's where we want to have something continuously running so that things really work whenever you join in and for this we also set up a continuous integration we did this together with the tools investigation and code improvement work group we have a gitlab runner you may wonder why source code is on GitHub while the CI runs in gitlab it was a little bit better for the user handling and the forking of it if you use the GitHub actions you can Fork repositories and you can you need much more configuration and can have some pitfalls if you don't do it right people may have access to your servers and we have a server underneath and this is better maintainable with gitlab and here it's actually in this way that when someone joins the group and is listed in the gitlab this person can actively uh it just trigger a pull request in GitHub on a local branch on a fork refer this in the gitlab CI and do a run so this could be if you want to save computation performance if you don't have a disk space or whatever so these kind of things you can do with the CI it's not only building it's also checking that the system boots because if it would just build you don't know if things work out of the box and when it's built we also do a q aim of boot and share later on the rendered image so you can see that it really goes into rendering it's not the one with the danger sign which I took a screen share from but there's also the danger sign in there however what we figured out it's not always the build which caused the issue it could be just recently that the cooks are stack which we are using had the client and server certificates expired so 7th of April we suddenly saw our CI failing or like what has gone wrong so we were looking all the sources we couldn't find the sources changes in there we saw there was something on Master but the master was not changed by us or we were not pulling it and well you could argue if we would have put it directly to AGL it may have been seen easier but we're not yet there that we say we are as stable that we would like to provide our modifications to AGL while we did instead also then for the analysis we have an open QA setup running hosted by code thing on their service and what you can see with this Orange Line in there you can basically move it from left to right it's from genome testing and so on where we do a qmo emulation reboot the system and you can move the slider to see an expected and the real rendered ausbook so you do basically a initial run you take check the timings and then you can just see that the danger is in there and for the broken part you could see that there was just the danger in the reference but no longer in our rendering part all right and then next to it you have the full information you also get a video recording of the testing phase in the logs you have the serial outputs you could we could see okay or signal Source control at which we have there is a mock this was still operating we could see uh how at the boot go on is there any version change and so on so this is from the testing part and then further we go for a the pipeline flow so what we had in here is that we said from a development perspective we start with the meta elizer within the meta lighter there are the bit big recipes the best Bay recipes can point to everything you can even add also a component if you want to go there and then this meteorizer is taken from the docker file so it's very third in the docker file we generate the docker image from it and this generated Docker image which would you download so either you download your metabolizer you download a Docker file which pulls the metabolizer or you download the pre-made Docker image and we generate this on a regular base so we do it more or less once a week that we build from scratch and every night we just do a div or using an as state build and then also this Docker image is the base for the gitlab CI which means the git lip basically is acting like the user so if you're using the system also get lapis using it whenever something would broke in the docker image or in the docker file or in metabolizer so see I will show it so there's really a dependency flow in there to the documentation around and then later on the gitlab of course builds the qaml image the qmo image as built and downloadable for someone is there to then go into the open QA the open QA grabs it dot the testing what is missing currently as a link back is that the open QA is not reporting back to the gitlab so if the gitlab CI is running it doesn't really do the check it could say well our CI passes because from there this perspective the booting work there is an image generated you need to check manually but we have this little intermediate stab and therefore now another part just there that we also work on aspomb generation so we are just switching it on we figure out that some function were not there so we're giving it back to AGL and then was not an AGL topic it was more the Octo project topic so they discussed it there and added some feature did some backboarding for us because we're not on latest October version and so this is just getting enabled additionally also we as mentioned we have CS state so that we have cache binaries in there if you would do a normal ability it takes you 100 gigabyte or something like this this will not be there right here so uh as already mentioned partially this gives you various starting points which are all interconnected and for me personally the most fancy one is that you can really just change two lines pointing to your new GitHub branch and uh just let the whole flow go through let the things compile get the Q open QA run without even the need that you Dove things locally and this is very helpful because when someone contributes a new feature in GitHub or a new bug fix whatever it gets in we can just simply point to this PR let the testing be done and make a comment in the GitHub request that the checks worked out up to the test cases we are doing and by this nobody has to manually check it it's basically two lines changes we could most likely also automate some part there but we haven't done this yet right I guess I have one picture here so let me just shortly see if I can start this just so you just see it in operation I was pretty fast so I guess we still have the time for it I try to run it from within the presentation but it never works as you like to so moving into the right screen and whoops so what you can basically see is uh we'll open the terminal to start the qmo image so the instrument cluster is booting just normal and then you can see that we have the terminal window so here we log in and start our signal Source control app the signal Source control app is a mock which has different options so you can see you can interrupt the next message you can hook or block the system and by this is for us a checking interface this is just the visual part there's just a command line interface which is run in our testing you would not need to do so but the open QA test for example this does the check also via the control app and the original process by a name pipe but it's hard to interact with it so we just have a little bit of Graphics command line interface for it so if we run like this no something was not rendered properly anymore you see the danger sign propping up and the Watchdog gets triggered and soon we should see that the things reboot is the rest of the system you can see while still operating but there was some corrupt messages so we just start the system up and similarly I guess if we do another run and then there should be the danger sign detected so we do have one question in the chat oh cool nice um we had well we had two and I just went and answered one of them but okay cool then I'll just so um what is cumu emulating for this example uh would what would the equivalent be on an automotive Target close the yeah um the qmo basically represents the standard AGL system and we took this qmo because it's an easy access it's not something which would go into the real system later on so we basically uh yeah just need an easy starting point for people to do something and this is a good question because if you would do the full Anonymous of your system you will see most likely diff slightly different interfaces because it's an x86 architecture rather than arm architecture which is heavily used in automotive so we just the this is a demo this is a startup this is looked for checking things but it's not as good as you would go with the real hardware setup and yeah the accrual Automotive Target on this would be you would take some hardware setup um we were looking with reference Hardware from AGL we have for the systems work group later on I will talk about the exciting's example from uh because it was accent which we also now look into maybe the automotive work group we were discussing all the options like an orange Pi which gives you arm Hardware but still if you go to automotive and come up with the Raspberry Pi an orange pie Rock pie whatever you take they just say well that's hobbyist hardware if you suddenly pick up something like St micro uh nxp Qualcomm Samsung green as Renaissance if you take this kind of Hardware if it's more or less a similar thing right just with a not as good bsp support maybe like the commuter suddenly it becomes attractive and this is what we want to bring in there and also find a hardware later on which is not only going for instrument cluster use case but for telematics others and so on so this would be the upcoming part right the s-bomb was also the second question where does the s-bomb come into play uh so the s-bomb will be in the build phase so we will try we will build the whole system which grabs all the information which is in there for your octo we know that it will not be complete and 100 correct because it can just be as correct as the data which is provided so if there are any issues and in a certain component if there is dual licensing multiple licensing this way not be perfect and it's this is uh is the docker image stage or before basically it's not taking the docker image as such but it's going afterwards it's going in the build the docker image is there to enable our build to do the Octo build and the spdx generation as bomb generation is in the OCTA build if we talk about the systems work group later on there we need to see how we combine this because we will most like not only have the October we also have the Best Western there and the example we may go everything into yorkto that we have just one build tool about the multiple would also be there and then it's inside the docker but not the Aspen for the docker image container will be an interesting topic also on top later on good got this some main answer for the question let me get back to my slides right we already touched the sdpa a little bit by Kate in the session before um what I really like about this stpa thing is it's I get asked is it a replacement for something do I need to do the things uh I make my way around with the answer and say well that's something which is aware available it's quite new and a lot of the other techniques are coming from the 70s and 80s and haven't evolved too much since then and this gives you an additional View and if we're talking about safety and it can add value to your safety analysis why not using it and here as mentioned this interaction with complex system it really helps you to just understand and we have pre-existing software which is also not typical in the Automotive Safety world but here you can really look into a system model the things you already know and get this as a support So for our example we started with a fairly simple drawing with this Delta requester can signal and so on we took it to a next level where more interactions were in there uh I will not go through all these parts here and just they what we learned for example about this phase was there are examples of safe rendering engines so there was some I guess some cute uh Library which was aimed and got an Azle I guess even Azle D qualification but it turned out if I read it correctly that it's mainly a tool qualification and anyway it's a good thing to sell and it will definitely improve the quality of the component because it's developed according to it but whatever goes in there in the forward pass basically need to be checked onto the display and all the mechanisms which you're doing are pointless if you make make sure that things are in there so you cannot make everything safe in this forward part you will always have a backward checking element in there which guarantees it could be the display comparison go on audience question but you mentioned things like asol and other things like that and I was just concerned that the audience may not know what those things are oh yeah so the Azle is the Automotive Safety Integrity level which ranging from qm quality managed up to uh Azle D I guess I just lost the mic would be okay good I don't hear myself anymore so it was just you good perfect I couldn't hear myself anymore so I was just confused so um the Azle D would be really something for autonomous driving very high level more and more uh best tools to be used testing in-depth and so on while lower level A and B you could find for a lower level of safety RS functionality are breaking and so on actually braking is a Higher One breaking news this is one of the very crucial things but our rendering of the telltales for example is just an Hazel B level and um you know if you're coming from Aerospace basically just turn around there I guess it's going with seriously highest level and then it goes up to five where's the lowest level so here higher letter means higher level of safety to be fulfilled all right yeah and this is basically here the parcel and for our part for this display rendering you would do a check in the backward path and need to make sure that whatever got rendered is properly rendered and here you would do the check so whatever mechanisms you do in the forward pass is nice but it's not the one which you need to do in the end because you need to make sure what there so and this caused a lot of discussion because we were saying what do we do what do we do properly for forward backward and this gives to the original first slide basically which Kate was showing understand your system sufficiently and do the measures where you need to and you need to understand your Linux system that you put the mechanisms at the right places and the next picture which I want to show about this control structure is not following stpa it's not an stpa diagram but we see these three different regions of it the one region this yellow part is basically the functioning part it's the plain function which you do which you would like to do as good as possible and then you want to make sure that what you have done is running properly this is the kind of orange little bit orange style color here you would do checks you make sure that you have a monitoring and whatever gets rendered is really properly rendered and the last part of it is this really dark orange one at the Watchdog because this is a fundamental system part of our work this challenge response Watchdog is something which is very much known in automotive it's also in other Industries used and basically this Watchdog makes sure it's clever enough checking elements in there and for us it means if we we don't have real time scheduling in the Linux kernel so there could potentially be something in a very very seldom case which caused something to stock which cause delayed execution and here this Watchdog would send continuously messages to its outside of the Linux system it's external Watchdog for now with the Watchdog module and does this check and this is just the last safety case and if you do a proper system Design This would never be triggered so it's intended not to be used it's just your final safety net that nobody will die in that we have a safe state we have all this discussed we started with a demo as I show how it all was set up so this first qmo demo was done more than a year back because almost two years back and then we start all this discussion to write down demand design how does the system operate and now we're at the state again where we need to map the model and the implementation so we need to understand much more which subsystems are involved and then also involve the workload tracing which will be the next session by shua and also have an improved implementation why do we need to an improved implementation so far we have mocked certain things so we are not doing full rendering check we concentrated on the fundament of the Watchdog but not on the specific rendering mechanisms and if we want to do a workload tracing the workload should represent reality and here we did from our analysis from the discussion we figured oh we mocked up a little bit too much if we really want to understand the workloads so what we see is we have now SCI we can easily modify so whenever we improve this part step by step whatever we do on this editions we can check it properly and we need to improve the information on how the components are involved what does it mean for display checking so that you really understand this is this component this is safety monitor this is The Telltale checking and so on so we update this we update the monitoring app as next step and this is the part needed to have the workload tracing right a little further outlook on things we also want to do is to merge the automotive use case into the systems work group demo because currently we are playing Linux system and whoever works with Automotive will most likely ask where the Autos are worth the rtos how do you handle these kind of things oh I'm running in an sdv software defined vehicle environment I want to use containers I would like to have virtualization involved and for this we pick it up to see how does our analysis change when we involve this kind of system we had the part about the qmo here comes apart that we were discussing currently the exciting Su 102 this came from the demo from Stefano shown last year during open source summer North America and we may then move forward maybe to the Korea system which gives you also AI in their AI Vision Parts robotics so for wider use cases and not limiting us to an instrument cluster we still see a lot of room to trim down the kernel configuration trim down the image size because it's based on the plane octopokey we may not need all the things for example could be we have thrown out the Wi-Fi driver because we believe that we don't need the Wi-Fi within the instrument cluster at least not for the initial analysis if someone comes up and finds a fancy feature with it who knows and what we also make as a hypothesis and assumption we have workloads tracing for medical and we hope to see similarities when we trace it to certain kernel Parts kernel subsystems so that both sings together will give us an idea which is really crucial which is maybe more relevant to more use cases where we need to concentrate on First and get a high value for a lot of other Industries and yeah we don't see it as a safety element of contact whatever we do because we say any safety element out of context always runs in an assumed context so our assume context is a Telltale if we would certify something or not we but a project would use it to certify based on this Delta use case it doesn't mean that you can do an auto system out of it but maybe an auto system will have similar demands to the kernel similar check them there may be stronger real-time requirements but this need to be there because in the end what it really boils down from this use case is checking a memory region against another memory region within a specified time and this is maybe also something which goes to the medical devices where you need to make sure that whatever you set as glucose monitoring level goes forward in the proper things yeah last part on this if you see this drawing I just took two examples you could have Park distance control which you know from your ultrasonic beeping part if you go there or you can even end up with certain camera use cases and basically you see very similar things the you have another sensor rather than maybe the engine sends a signal to say check engine the beep sense it is the ultrasonic sensor stands a distance rather than showing it on the screens you have a speaker and for camera it would be more image data which need to be processed and this gives you a scaling Factor it gives you bass all will require a watchdog mechanism and uh here so we hope that we can go further with more advanced use cases and also fulfill certain others requirements and by going with the hardware from currently a q a more towards something like the exciting spot or well so basically look for something which gets a good Community Support which gets a good bsp support so it could be anything else as well um just which is available to others we may have something which also goes into telemedics others and so on right do we have something more in the chat any questions from the audience yeah there was a question the last is the s-bomb intended as an input into the docker image it could be an input for the document basically we would most likely see it as an artifact and see the changes of the artifact which goes in so there's not a direct demand for this I because yeah the PS4 of the docker which would be another question it could be a double Aspen then there's one for the build system and the environment around it how we build this thing what is involved there our first s-bomb approach went more into uh the Aspen of the system in use so there's the airspomb of the device used not the tools which have been used to generate the image which would anyway also need an as-bomb in the end if it's Source two based and then you are with the airspawn within the docker but it's two parts of it, Automotive Use Cases Analysis, YouTube, 01ka7ppx8r6rt0zf694tem0qkx.