Open Source Safety Elements - Out of Context?
summary
Explains what a Safety Element out of Context actually provides: a certificate alone does not prove fit for purpose, the integrator must check scope and assumptions of use, obtain a safety manual with obligations, and perform system‑level qualification. Project work includes writing ~400 requirements for a minimal Zephyr kernel, mapping requirements to architecture, implementing coding guidelines, and collecting V&V evidence in a text format (strictdo requirements repo). Plans include a machine‑readable exchange via a SPDX safety profile and targeting IEC 61508 SIL3 and ISO 26262 compliance; formal methods aren’t used yet due to lack of formal specs.
AI-written summary · about
chapters (11)
- 0:00Introduction to safety elements
- 1:45Speaker background and motivation
- 3:31What is a safety element out of context
- 7:27Safety is a system property
- 9:38Creating a safety element out of context
- 11:03Scope and standards in SE for
- 13:12Systematic capability and requirements
- 15:19SPDX safety profile development
- 16:03Call to action for open source projects
- 17:10Q&A on formal verification
- 18:57SPDX safety profile status
related talks
53mBridging Safety and Architecture: Zephyr’s Path To IEC 61508 Complian...
42mZephyr Functional Safety BOF
53mTutorial: Functional Safety Basics for Open Source Software Developers
55mZephyr: An Ideal Platform for Introducing Processes of Safety-Critical Embedded Systems
32mDeveloping Open Source for Safety and Security
48mDeveloping Open-Source Software RTOS with Functional Safety in Mind
48mDeveloping Open-Source Software RTOS with Functional Safety in Mind
34mOpen Source in Safety Critical Applications: the Next Frontier