An open-source driving platform derived from openpilot, integrating functional safety, SOTIF, cybersecurity, AI safety, and transparent engineering assurance while preserving broad vehicle compatibility.
Documentation · Wiki · Architecture · Living Safety Case · Vehicle Compatibility · Roadmap · Getting Started · Contributing
Important
LionDriver is research and development software. It is a driver-assistance system: the driver must stay attentive and in control at all times. It is not certified, makes no claim of ISO 26262 compliance or ASIL capability, and is not approved for unsupervised operation.
LionDriver publishes its safety argument as it is built: the claims, the evidence for each one, the known counter-evidence against it, and what has and has not been reviewed. Every figure is generated from the records in assurance/case-records/ and checked by CI on every pull request.
Development · baseline BL-002 at bf6ce8c · 36 claims (0 with accepted evidence) · 50 evidence items (0 accepted) · 42 open defeaters · records digest 2a45377b928e
Assurance status represents recorded engineering evidence and review state. It does not constitute certification or approval for unsupervised operation.
Open the full Living Safety Case → lifecycle status, values as text, what the dashboard guarantees, and how the records fit together · safety case (WP-K-01) · known gaps
LionDriver keeps openpilot's driving stack and its central safety design: a large, learned driving stack (the doer) whose commands pass through a small, deterministic safety layer on the panda microcontroller (the checker) before they reach the car. LionDriver adds the engineering record around it, and the gap assessment states plainly where the inherited checker does not yet meet what the safety goals require.
| Layer | Role | State |
|---|---|---|
| Core driving platform | Perception, prediction, planning, control, driver monitoring, HMI | Implemented, inherited from openpilot |
| Safety envelope | Actuator limits, engagement and release on driver input, message checks | Implemented, inherited; hardening proposed in the technical safety requirements |
| Vehicle integration | Vehicle interfaces, ECU compatibility, hardware configurations, calibration, diagnostics | Implemented, inherited; vehicle operating assumptions drafted |
| Safety and assurance | Functional safety, SOTIF, cybersecurity, AI safety, safety case, traceability, V&V, change impact analysis | Draft work products, not yet reviewed |
More in the architecture overview.
LionDriver is built on openpilot's vehicle support and keeps every upstream car port. The pinned upstream version lists 335 car models in docs/CARS.md, from cars and SUVs to minivans, pickups and light commercial vans. LionDriver is a multi-vehicle platform, not a single-vehicle retrofit.
Vehicle compatibility does not imply independent safety assurance.
| Classification | Meaning |
|---|---|
| Upstream Compatible | Supported by the inherited openpilot integration |
| LionDriver Evaluated | Undergoing or completed documented engineering evaluation |
| Assurance Supported | Defined configuration with accepted evidence for specific safety claims |
The first evaluated configuration is the Toyota Corolla, 12th generation (E210), with Toyota Safety Sense 2.0, the reference vehicle for the assurance work. It is a starting point, not a limit: further vehicles join through a documented impact analysis against the assumptions the analysis makes about the car. No configuration is assurance-supported yet. See vehicle compatibility.
LionDriver follows standards-informed development: its work products are structured after these standards and cite their clauses, but no compliance is claimed, because no assessment has been performed. The assurance strategy explains how each one is tailored to an open-source, supervised Level 2 system.
| Supporting practice | Where it is applied |
|---|---|
| Automotive SPICE | Capability baseline |
| Systems engineering and requirements management | System requirements · traceability procedure · trace data |
| Safety analysis | ASIL decomposition · freedom from interference · dependent failures · FTA/FMEA |
| Simulation, SIL and HIL | Embedded software testing · SOTIF verification and validation strategy · simulation track · ASIL C hazardous events in the plant loop · harness box faults, interactive in Falstad |
| Fault injection | Fault injection specification |
| Independent review | Confirmation measures plan · verification review procedure |
| IEC 61508 | Referenced for supplier safety documentation of the safety microcontroller (component qualification) |
Status is taken from what exists in the repository. "Draft" means the work product is written but not reviewed; nothing is marked complete before its review.
| Phase | Work | Status |
|---|---|---|
| 1 · Foundation | Project governance and safety management plan | Draft |
| Upstream baseline assessment | Draft | |
| Assurance data model and traceability data | Draft; hazards, goals, assumptions and safety case recorded, requirements not yet | |
| 2 · Safety Engineering | Hazard analysis and functional safety concept | Draft |
| SOTIF analysis, cybersecurity analysis, AI safety requirements | Draft | |
| Architecture analysis | Draft | |
| Field monitoring, safety anomaly and root cause analysis process, first case FI-2026-001 (NHTSA PE26007) | Draft | |
| 3 · Implementation and Verification | Safety mechanisms from the technical safety requirements | Planned |
| ISO 26262-6 software lifecycle (Clauses 5–11) | Specified; starts after the Part 2–4 work products and supporting processes are approved | |
| Automated verification of the inherited safety code (unit tests, coverage gate, MISRA, mutation) | Running in CI; not yet reviewed as evidence | |
| Regression testing, simulation, fault injection, evidence generation | Specified, not executed | |
| 4 · Expanded Assurance | More evaluated configurations, independent review, living safety-case maturity, continuous assurance, community contributions | Planned |
For development, LionDriver uses openpilot's toolchain unchanged (Ubuntu 24.04 or macOS; see tools/README.md):
git clone https://github.com/jherrodthomas/LionDriver.git
cd LionDriver
tools/op.sh setup
source .venv/bin/activate
scons -uFor the assurance records, only Python 3 is needed:
python3 assurance/case-records/tools/validate.py
python3 assurance/case-records/tools/generate_dashboard.py --checkIn a car: LionDriver publishes no release build. Development builds must not be used on public roads outside the controlled test regime in WP-V-07. How openpilot itself is installed and used is described in the upstream project.
Contributions are welcome in software, functional safety, SOTIF, cybersecurity, AI safety, verification, documentation and vehicle integration. Safety-relevant changes need a rationale, an impact analysis and appropriate verification.
| Contributing to LionDriver | Rules for safety-relevant changes and assurance records |
| Issues · Pull requests | Questions, bugs, reviews of the analyses; pull requests target liondriver-dev |
| Documentation | Architecture, compatibility, assurance and the inherited openpilot docs |
| Wiki | Orientation: roadmap, glossary, how decisions are made, reading the safety case. Kept in wiki/ and mirrored on merge |
| Upstream openpilot | The driving platform LionDriver is derived from |
Jherrod Thomas maintains LionDriver as an open engineering initiative: a public demonstration of safety-lifecycle development, systems engineering and assurance practice on a real automotive software platform.
LionDriver is derived from openpilot by comma.ai and its contributors, and builds on their work. LionDriver is distributed under the MIT license, which keeps comma.ai's copyright notice alongside LionDriver's; third-party components keep their own licences. LionDriver is an independent project and is not affiliated with or endorsed by comma.ai.
Open-source licensing does not establish automotive safety certification, regulatory approval, or suitability for unsupervised vehicle operation.