Looking towards safety
summary
Argues that SPDX can carry functional safety evidence end-to-end, mapping V‑model artifacts into machine‑readable outputs and enabling deterministic impact analysis rather than manual spreadsheets. Proposes creating design asbom, source asbom and build asbom (and a runtime ASOM) so requirements, architecture, test reports and traceability live as linked SPDX documents. Piloting the approach on the seha operating system, showing automatic backward trace from failing executable to toolchain, source, requirement and test, and generating updated safety artifacts on change.
AI-written summary · about
chapters (11)
- 0:00Functional safety challenges
- 1:24What functional safety means
- 3:31Documentation and evidence needs
- 6:22Why SPDX matters
- 8:51ASOMs and safety lifecycle
- 11:42Seer OS pilot project
- 13:30Dependency model impact analysis
- 16:01Traceability benefits
- 17:28Dependency model advantages
- 18:53ASOMs and V-model
- 19:16How to get involved
related talks
07mTooling and Sharing Traceability Discussion
31mSoftware Bill of Materials (SBoM) for dummies
53mDocumenting the Design of the Linux Kernel
16mranslate FOSS licenses into code
45mAdding Testable Code Specifications in the Linux Ke...
25mMaking Automatically Compliant Design Documents With Infrastructure as Code
29mStop Documentation Debt: Industrialize Your ADRs and READMEs with Spec-kit
31mAutomating Linux Kernel Documentation for Safety-Criti...