Repository navigation
From hazard to test
How LionDriver gets from "what could go wrong" to "here is the test that shows it doesn't", for someone who has never seen it done. One real chain is followed the whole way: the safety goal that the car must not steer unless the driver asked it to. This page explains and links. The records are the work products it points to; nothing here is a requirement, a test result or evidence.
Every figure is drawn at each wiki sync by tools/wiki/h2t_animations.py. Each
phrase it quotes or summarises is checked against its work product, the test statuses come from the case records,
and the code excerpts are checked against opendbc and panda. When a record changes, the build fails instead of
showing old text.
flowchart LR
I["Item<br/>WP-C-01"] --> H["Hazard and risk<br/>HE-01.4 → SG-01"]
H --> F["What<br/>FSR-01.04"]
F --> T["How<br/>TSR-105"]
T --> A["Software and hardware<br/>SWSR-105 · HWSR-501"]
A --> M["Safety mechanism<br/>SM-04"]
M --> V["Tests<br/>SIL · HIL · fault injection · car"]
V --> E["Evidence<br/>claim G1.1.3"]
Everything starts with a boundary. Inside it are the parts LionDriver is responsible for (WP-C-01). Outside are the car, the driver and the road, which the item relies on but does not control. What it relies on is written down as assumptions of use (AOU), and each one has to be verified, for example that the EPS lets a normal driver overpower the steering torque.
The hazard analysis (WP-C-03) takes each driving situation and asks what the item could do wrong in it. Each answer is rated for severity (how badly people could be hurt), exposure (how often the situation occurs) and controllability (how many drivers could still avoid harm). The three together give the ASIL, from A (lowest) to D (highest), or QM when no safety requirement is needed. The worst hazardous events become safety goals: what must never happen.
A functional safety requirement (FSR, WP-C-04) says what the item must do to keep the goal true, without design. A technical safety requirement (TSR, WP-S-02) says how this system does it: which element, which signal, how fast. Change the design and the TSRs change; the FSR stays. How to write either one is in Deriving and writing safety requirements.
Each TSR is allocated to an element of the architecture and broken down into software requirements (WP-W-02) and hardware requirements (WP-H-01). Here the software owns the check, and the hardware owns the guarantee that the check keeps running. How hardware failures are counted, and how the QM parts are kept from disturbing the safety parts, is in Hardware safety and interference.
Every line of code and every setting points back to the requirement it meets, and every requirement points forward to its code and its tests. A line with no requirement, or a requirement with no line, is a finding. Known gaps are recorded, not hidden: TSR-105 is marked partial because a steer-request bit with zero torque is still accepted.
A safety mechanism keeps a safety goal true when something else fails. The gate (SM-04, WP-S-03) catches a bad command from the openpilot computer; the watchdog catches the gate itself stopping. This figure is an illustration, not a test result.
Testing that the code does what the requirement says is only the start. LionDriver also tests on the real chip, injects faults to check that the mechanisms react in time (WP-V-05), and tests in the car with real drivers whether the controllability ratings hold (WP-C-08). The fault tree (Building a fault tree) says which faults are worth injecting. The results become evidence for the safety case, and count only once they are reviewed: What is a safety case?.
What keeps the item safe once it is installed and in use is on After release.
This chain follows a fault. What happens when nothing fails but the function still gets it wrong is on SOTIF and ISO 26262.