Functional safety
Vision Pilot is written to be safety-certifiable. This is what that means, what exists today, and what an integrator is responsible for.
Vision Pilot is not a certified system, and is not a finished product. It is designed to be productionizable and safety-certifiable, but any deployment on a real vehicle - and every consequence of that deployment - is the responsibility of the integrator. Read the disclaimer before going further.
The documents
All functional safety material lives in
Functional_Safety/ in the repository, and is
maintained alongside the code rather than as a separate deliverable.
Safety plan ↗
How safety work is organised across the project - activities, artefacts and responsibilities.
Scope · draftSEooC scope definition ↗
The ISO 26262 compliance boundary: what is inside the element, what is assumed of the system around it, and what is explicitly out of scope.
RequirementsSoftware requirements ↗
The requirements the implementation is written against, and traced to.
EvidenceSafety metrics ↗
The measures used to evaluate whether the system behaves safely, and how they are computed.
Safety Element out of Context
Vision Pilot is developed as a Safety Element out of Context (SEooC) under ISO 26262 - a component designed without a specific vehicle item in mind, shipped together with the assumptions it makes about the system it will be integrated into.
The SEooC document covers:
| Section | Why it matters to you |
|---|---|
| SEooC scope | What the element is, and is not |
| SEooC boundary | Where Vision Pilot’s responsibility ends and yours begins |
| External interfaces | What crosses that boundary, in both directions |
| Assumptions of use | Conditions that must hold for the safety argument to be valid |
| Known limitations | Where the system is known to be weak |
| Intended ISO 26262 compliance scope | What is being claimed, and at what level |
| Future safety roadmap | What is still to come |
The assumptions of use and known limitations sections are the two an integrator must read in full. An assumption that does not hold in your vehicle invalidates the argument built on it.
How safety shapes the architecture
The architecture is built around the safety case rather than bolted to it:
- Two independent AI paths. A perception path producing explicit, inspectable quantities, and an end-to-end path. Independence is what makes disagreement detectable.
- The Safety Guardian sits between AI and actuation. Nothing reaches the planner without passing through fusion. Where the paths disagree, the conservative interpretation is taken.
- Explicit intermediate quantities. Object boxes, CIPO distance, ego path and lane state are all inspectable, loggable and testable - which is what makes requirements traceable to behaviour.
- A stated sensor specification. 50–55° FoV, 2 MP, one RGB camera, specified mounting and a calibrated homography. These are safety-relevant constraints, not recommendations. See hardware and calibration.
Verification you can run today
- Open-loop replay against recorded sequences with ground-truth speed logs - getting started.
- Closed-loop simulation in CARLA, where the stack’s own commands move the vehicle - simulation.
- Frame-level logging to Rerun, so any run can be reconstructed and inspected after the fact - modules.
On the roadmap
Safety verification and standards compliance against ISO 26262 (functional safety) and ISO 8800 (safety and AI) are tracked on the roadmap. The SEooC scope definition is currently a draft and will be revised as that work progresses.
Contributions to the safety work are welcome - it is discussed in the weekly working group meetings.