Automotive Use Cases Analysis 🔗 **Source:** [Automotive Use Cases Analysis](https://www.youtube.com/watch?v=cjLdgcsF6ac) > [!note]+ Document Notes > 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 > <!-- deep-read:sections start --> ## 🧰 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, <!-- deep-read:sections end -->