The panda is a USB CAN gateway that sits between the comma device and the car’s CAN bus. All CAN messages from openpilot’s host software pass through panda before reaching the vehicle’s ADAS ECUs. This makes panda the physical enforcement layer of openpilot’s safety model — it can independently block or limit any message, regardless of what the host software sends.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/commaai/openpilot/llms.txt
Use this file to discover all available pages before exploring further.
Two core safety requirements
Following Hazard and Risk Analysis (HARA) and Failure Mode and Effects Analysis (FMEA), openpilot is designed around two fundamental safety requirements:1. The driver can always retake control
1. The driver can always retake control
The driver must be able to immediately retake manual control of the vehicle at any time. openpilot disengages when the driver steps on the brake pedal or presses the cancel button. Panda enforces this at the hardware level — it monitors driver inputs on the CAN bus and cuts actuation commands when an override is detected, independent of the host software state.This requirement covers both lateral (steering) and longitudinal (throttle and braking) control. The driver retaking control via the brake pedal or cancel button is always sufficient to disengage openpilot completely.
2. The vehicle cannot change trajectory too quickly
2. The vehicle cannot change trajectory too quickly
While openpilot is engaged, all actuators are constrained to operate within limits that give the driver sufficient time to react. The vehicle must not alter its trajectory so quickly that a normally attentive driver could not safely respond.Per ISO 11270 and ISO 15622, the lateral actuation limits translate to a maximum of 0.9 seconds of continuous actuation to achieve a 1-meter lateral deviation. Panda enforces per-brand actuator limits defined in the C safety mode files, and openpilot’s host software performs an independent excessive actuation check in
selfdrive/selfdrived/helpers.py.Compliance and standards
openpilot is developed in good faith to be compliant with applicable regulations and industry safety standards for Level 2 driver assistance systems:| Standard | Application |
|---|---|
| ISO 26262 | Functional safety guidelines for road vehicles; informs the hazard analysis and safety architecture |
| FMVSS | US Federal Motor Vehicle Safety Standards; openpilot’s behavior is designed to be consistent with FMVSS requirements for ADAS systems |
| ISO 11270 | Defines lane keeping assist system requirements, including lateral deviation limits |
| ISO 15622 | Defines adaptive cruise control requirements, including longitudinal actuation limits |
| MISRA C:2012 | Coding guidelines applied to all safety-critical C code in panda firmware to minimize undefined behavior |
Panda safety modes
Each supported car brand has a dedicated safety mode implemented in C in the opendbc repository:- Steering torque limits — Maximum allowable torque per CAN cycle, enforced per brand
- Torque rate limits — Maximum change in torque per cycle (
STEER_DELTA_UP/STEER_DELTA_DOWN) - Longitudinal limits — Gas and brake signal range validation
- Driver override detection — Monitoring driver steering torque and pedal inputs to detect manual intervention
- Heartbeat timeout — If the host software stops sending valid messages, panda stops forwarding actuation commands to the car
Vehicle-specific safety implementations are at github.com/commaai/opendbc/tree/master/opendbc/safety. The panda safety model overview is at github.com/commaai/panda#safety-model.
Testing
comma.ai runs three levels of safety testing before each software release:Software-in-the-loop (SIL) tests
Software-in-the-loop (SIL) tests
Safety mode logic is compiled and tested in a simulated environment. Each brand’s safety test suite (
opendbc/safety/tests/test_[brand].py) runs in CI on every pull request. Tests verify that:- Valid messages are forwarded correctly
- Out-of-range actuator values are blocked or clipped
- Driver override signals trigger immediate disengagement
- Heartbeat timeouts stop actuation as expected
Hardware-in-the-loop (HIL) tests
Hardware-in-the-loop (HIL) tests
The compiled panda firmware is flashed to physical panda hardware and tested with simulated CAN traffic. HIL tests catch timing-dependent behavior and hardware-specific issues that SIL tests cannot detect.
In-vehicle tests
In-vehicle tests
Before release, new safety logic and software changes are tested in vehicles on public roads. comma employees validate engagement, disengagement, driver override, and edge-case behavior in real driving conditions.
Driver monitoring
openpilot includes a driver monitoring feature that alerts the driver when distraction or drowsiness is detected using the cabin-facing camera. Driver alertness is a necessary condition for safe openpilot use, but not sufficient on its own — panda’s hardware safety layer operates independently of the driver’s attentiveness. Driver monitoring cannot be disabled. Forks that nerf or disable driver monitoring (selfdrive/monitoring/) violate openpilot’s safety requirements.
Fork requirements
Forks of openpilot that modify safety-critical code must follow these requirements to maintain an acceptable level of safety:- Do not disable or weaken driver monitoring (
selfdrive/monitoring/) - Do not disable or weaken excessive actuation checks (
selfdrive/selfdrived/helpers.py) - If your fork modifies any code in
opendbc/safety/:- Your fork cannot use the openpilot trademark
- Your fork must preserve the full safety test suite (
opendbc/safety/tests/) and all tests must pass, including any new coverage required by your fork’s changes