Repository navigation
How LionDriver works
The other pages explain how LionDriver is assured. This one explains the product they are about: how the device connects to the car, how one steering command travels from the camera to the steering motor, what the safety envelope on the panda checks on the way, who is in charge, what happens when something fails, what stays stock, and where the system is meant to be used. It explains and links. The engineering record is the architecture, WP-S-03, the technical safety requirements, WP-S-02 and the timing analysis, WP-S-04; the car is the reference vehicle, and the operating domain is in WP-C-02.
Important
LionDriver is a supervised driver-assistance system. The driver must stay attentive and in control at all times. The figures show how the system is designed to behave; nothing here is verified on the car yet.
Every figure is drawn at each wiki sync by tools/wiki/how_animations.py. The
envelope limits are read from the calibration record (WP-W-09
CD-02), the stall times, the forwarding rule and the driver-monitoring times from WP-S-02, the FTTI and the fault budgets
from WP-S-04 §3.7, the assumptions of use from WP-C-01 §7, the
operating domain and its exits from WP-C-02, and the status of each requirement from the
TSR list. Every other phrase is checked
against its record, and the limits against the panda code when it is checked out. When a record changes, the build
fails instead of showing old text.
On the reference car, the forward camera behind the mirror does Toyota's own lane keeping and pre-collision braking (PCS), and talks to the rest of the car over one connector. The harness plugs in at that connector and splits it: the camera on one side (bus 2), the car on the other (bus 0). The panda, the safety microcontroller in the comma device, sits between them. It forwards everything the camera says except its steering, lane-display and cruise commands, so the car's own PCS braking keeps working, and sends openpilot's steering in their place. If the device faults or is unplugged, a relay in the harness drops and the camera is connected straight to the car again.
The main computer (the SoC) runs openpilot: the driving model reads the camera, the planner picks a path, the controls turn it into a steering torque, and the car interface packs it into a CAN message. None of that is safety-rated (QM). The panda is: it checks every message before the car sees it. If the chain stalls, the panda does not wait for the SoC to notice. It counts the time since the last good message and takes authority back well before the FTTI, the time after which a fault could first lead to a hazardous drift.
Each steering frame must pass every check, every time. A blocked frame never reaches the steering motor. The limits are fixed numbers in the firmware; the figure also says which planned checks are not implemented yet, read from the TSR list. Hardware safety and interference explains why the panda can be trusted when the SoC cannot, and From hazard to test follows one of these limits from the hazard it answers to the test that checks it.
The driver hands control over by setting the car's own cruise, and takes it back by braking or cancelling cruise. The panda enforces both, from the car's messages, whatever the main computer says. A check the figure marks planned is required but not built yet. The driver-monitoring camera watches the driver's face; when they look away, alerts escalate, and if nothing brings them back the car slows to a stop in its lane rather than drive on unsupervised.
Each bar is the time budget to notice a fault (detect) and to make the steering safe (react), against the FTTI: the time after which the fault could first lead to a hazardous drift. These budgets are worked out from the code and cross-checked in simulation; none has been measured on the car yet. The panda sounds its own siren, so the warning does not depend on the computer that may have failed.
LionDriver adds to the car; it does not replace the car's own safety systems. The stock pre-collision braking keeps working with the harness fitted, the device is never allowed to send its messages, and the stock wiring comes back when the device fails. The analysis also assumes things about the car itself, the assumptions of use, and they still have to be checked on it.
The operating domain (ODD) is the set of roads and conditions the analysis covers: here, highways only. Outside it the system may still engage, which is why the figure ends with the ways out of the domain and how many the system notices on its own today. The rest the driver has to notice. SOTIF and ISO 26262 explains why the limits of the intended function are analysed at all.
- Reference vehicle: the car, the device and what the configuration fixes.
- CAN, CAN FD and end-to-end protection: the bus these messages travel on, and what protects them on the way.
- Integrated standards: what each standard asks of the same envelope.
- Glossary for the work product and ID codes.