Repository navigation
Standards at a glance
LionDriver follows standards-informed development: its work products are structured after these standards and cite their clauses. No compliance is claimed, because no assessment has been performed. The assurance strategy, WP-M-01 explains how each standard is tailored to an open-source, supervised Level 2 system.
| Standard | The question | Main work products |
|---|---|---|
| ISO 26262, functional safety | What if something breaks? | HARA, WP-C-03 · functional safety concept, WP-C-04 · technical safety concept, WP-S-03 · hardware and software requirements |
| ISO 21448, SOTIF | What if nothing breaks but the system still gets it wrong? | SOTIF hazards, WP-C-05 · insufficiencies and triggering conditions, WP-C-06 · validation strategy, WP-V-02 · explained on SOTIF and ISO 26262 |
| ISO/SAE 21434, cybersecurity | What if someone attacks it? | TARA, WP-C-09 · cybersecurity goals and concept, WP-C-10 · cybersecurity case, WP-K-03 · explained on Cybersecurity and ISO/SAE 21434 |
| ISO/PAS 8800, AI safety | How far can a learned component be trusted? | AI system definition and requirements, WP-C-11 · ML engineering, WP-W-10 · explained on AI safety and ISO/PAS 8800 |
| UL 4600, safety case | Is the whole argument convincing? | Safety case, WP-K-01 · machine-readable records |
| Practice | Where it is applied |
|---|---|
| Automotive SPICE | Capability baseline, WP-M-13: a self-assessment, not a formal assessment. Target CL2 for the system, software, support and management processes, CL1 for machine learning and hardware |
| Systems engineering and requirements management | System requirements, WP-S-01 · traceability procedure, WP-P-06 · trace data |
| Safety analysis | ASIL decomposition (explained) · freedom from interference · dependent failures · FTA and FMEA · STPA |
| Simulation, SIL and HIL | Embedded software testing, WP-W-08 · SOTIF verification and validation, WP-V-02 |
| Fault injection | WP-V-05 |
| Independent review | Confirmation measures plan, WP-M-06 · verification review procedure, WP-P-05 |
| IEC 61508 | Referenced for the supplier safety documentation of the safety microcontroller (component qualification, WP-H-07) |
One shared hazard log, in the HARA with SOTIF and TARA cross-references, and one requirements database,
in assurance/trace/, hold the five standards together
(Integrated standards: one system, not five explains how):
| Topic | Primary standard | Interface |
|---|---|---|
| Hazards from malfunctions | ISO 26262-3 HARA | Shares the hazard list and situation catalogue with the SOTIF hazard identification, so there is one hazard log |
| Hazards from insufficiencies and misuse | ISO 21448 | Uses the same hazardous events; severity and controllability reuse the HARA ratings |
| ML models | ISO/PAS 8800, ASPICE MLE | Model errors feed in as SOTIF functional insufficiencies; data and model lifecycle in WP-W-10 |
| Cyber attacks that cause safety hazards | ISO/SAE 21434 TARA | Damage scenarios link to HARA hazards; cybersecurity goals that protect safety goals are traced both ways |
| Process capability | Automotive SPICE | The ISO 26262 work products double as ASPICE information items; each register entry carries its process ID; explained on ASPICE: is the process capable? |
The learned driving stack proposes; a small deterministic layer on the panda microcontroller checks before anything reaches the car. Most of the tailoring follows from concentrating ASIL effort there.
Figure 4-1 of WP-M-01 assurance strategy, pinned to §4.1 and §4.2 so CI detects when it may be stale.
ISO 26262 assumes an OEM or supplier developing a series-production item. LionDriver is an open-source aftermarket retrofit built from inherited software on commercial hardware. The strategy records thirteen tailoring decisions, each needing confirmation by an independent assessor. The ones that shape the project most:
- The item boundary is the comma device, the harness and the LionDriver software as installed. Vehicle ECUs are outside the item, with assumptions of use, because LionDriver cannot change them or obtain evidence for them.
- The safety envelope is re-verified to the ASIL from the HARA. Requirements, architecture and unit design are back-filled from the existing code, then fully verified. The learned driving stack is handled as QM plus SOTIF.
- Proven in use is not claimed for any element. The openpilot fleet history is supporting evidence only.
- Independence. The author of a work product never reviews it. With a single maintainer, confirmation reviews of the HARA, the safety plan and the safety case, and the functional safety assessment, need an external assessor.
- Regulatory. US market, where no type approval applies to an aftermarket retrofit. NHTSA's Standing General Order crash reporting is the model for field monitoring.
The full table is in WP-M-01 §5. Which
clauses each assurance folder answers to is in
assurance/README.md.