openpilot 安全机制设计深入解析：两大核心安全要求与驾驶员监控、过度执行检查的源码实现

openpilot 是一个集自适应巡航控制（ACC）与自动车道居中（ALC）于一体的 L2 级驾驶辅助系统，其安全哲学可以用一句话概括：驾驶员注意力是必要条件，但并非充分条件。官方安全文档 明确了 openpilot 的安全设计目标与实现约束，而本文则在此基础上，结合 驾驶员监控策略、过度执行检查 等真实源码，拆解这套"故障安全被动系统"是如何把文档中承诺的两项核心安全要求落地到代码层面的。读完本文，你将理解 openpilot 从标准合规、实时监控到事后兜底的完整安全分层，以及每个安全约束对应的具体实现位置与关键参数。

安全定位：故障安全（Failsafe）被动系统

docs/SAFETY.md 开篇即给出了 openpilot 的安全定位：

openpilot is an Adaptive Cruise Control (ACC) and Automated Lane Centering (ALC) system. Like other ACC and ALC systems, openpilot is a failsafe passive system and it requires the driver to be alert and to pay attention at all times.

这里有两个关键定性：

1. failsafe passive（故障安全被动式）：系统的职责不是独立承担全部驾驶责任，而是作为辅助存在。一旦检测到驾驶员分心等异常，系统的首要动作是提醒和逐步退出，而不是"硬扛"。
2. 驾驶员注意力必要但不充分：文档特别强调 "driver alertness is necessary, but not sufficient, for openpilot to be used safely"，并声明系统不提供任何适用性保证（no warranty of fitness for any purpose）。

标准合规与工程实践

文档进一步说明了 openpilot 在工程层面如何逼近 L2 辅助驾驶的安全水位：

• 法规与标准：善意地（in good faith）遵循 FMVSS（美国联邦机动车安全法规）要求，并参照 ISO 26262 功能安全指南，其中也包括 NHTSA 发布的 ALCS（自动车道保持系统）相关文档；
• 编码规范：对安全相关（safety relevant）的代码部分执行严格的编码指南，例如 MISRA C : 2012（适用于其中的 C/C++ 组件）；
• 测试流程：每次软件发布前，执行软件在环（SIL）、硬件在环（HIL）和实车（in-vehicle）测试。

这些声明共同构成了后文源码级安全机制的"上层设计依据"：先经过危害与风险分析（Hazard and Risk Analysis）和 FMEA 推演，再提炼出两项可执行、可验证的核心安全要求。

核心安全要求一：驾驶员必须能随时立即接管

第一条要求是：

The driver must always be capable to immediately retake manual control of the vehicle, by stepping on the brake pedal or by pressing the cancel button.

即：踩刹车或按取消按钮，驾驶员必须能够立即收回车辆控制权。这一要求在 openpilot 中主要靠底层的 CAN 安全模型保证：panda 微控制器在硬件层面校验所有下行的转向/加速/刹车控制报文，任何非法或不合理的命令都会被拦截。官方文档指向两个实现位置：

• panda safety model：即 panda 子模块（本仓库根目录下的 panda/ 目录）中定义的分车型安全状态机；
• opendbc/safety/safety：即 opendbc 子模块（本仓库根目录下的 opendbc_repo/ 目录）中按车型实现的 safety 概念代码，以及配套的完整安全测试套件（opendbc/safety/tests）。

这两个子模块在当前仓库中为外部 checkout 依赖，具体各车型的安全实现细节需进入子模块仓库查阅；本文关注的重点是它们在 openpilot 主仓中的"上边界"——即上层软件如何配合这些底层约束工作。

核心安全要求二：轨迹不能突变，执行器必须被限幅

第二条要求是：

The vehicle must not alter its trajectory too quickly for the driver to safely react. This means that while the system is engaged, the actuators are constrained to operate within reasonable limits.

翻译过来就是：系统接合期间，车辆轨迹的变化速度必须在驾驶员可安全反应的范围之内，转向、加减速等执行器（actuators）被强制约束在合理极限之内。文档脚注给出了量化依据：

• 执行器极限参照 ISO 11270 和 ISO 15622 两项标准；
• 其中横向极限的换算结果是：最大 0.9 秒的执行动作才能产生 1 米的横向偏移（0.9 seconds of maximum actuation to achieve a 1m lateral deviation）。这是一个非常直观的驾驶员友好性指标——即使系统完全失控，横向偏移率也被限制在人类可以及时反应的量级。

这个"限幅 + 突变监控"的思路在 openpilot 主仓中有一个直接对应的实现，就是下一节要详细剖析的过度执行检查（Excessive Actuation Check）。

驾驶员监控（Driver Monitoring）：保持注意力的主动防线

文档指出 openpilot 内置了驾驶员监控功能，用于在检测到驾驶员分心时发出提醒。其完整实现位于 openpilot/selfdrive/monitoring/ 目录，核心文件是 dmonitoringd.py（监控进程）和 policy.py（监控策略状态机），参数测试见 test_monitoring.py。

双策略：视觉策略与方向盘触碰策略

policy.py 中的 DRIVER_MONITOR_SETTINGS 类集中定义了全部策略参数。从源码结构看，监控采用双策略并行、可回退的设计：

参数	取值	含义
_ALERT_MIN_SPEED	2.8 m/s（10 km/h）	低于此车速不触发告警
_VISION_POLICY_ALERT_1/2/3_TIMEOUT	5s / 8s / 13s	视觉策略下三级告警的触发时长
_WHEELTOUCH_POLICY_ALERT_1/2/3_TIMEOUT	5s / 15s / 25s	方向盘触碰策略下的三级告警时长
_NO_RESPONSE_TIMEOUT	5s	红色告警后无响应的判定窗口
_MAX_ALERT_3 / _MAX_NO_RESPONSE	2 / 1	触发锁定的累计次数上限
_LOCKOUT_TIMES	1 / 5 / 15 / 30 分钟	锁定时长随次数递增

两条策略的分工可以推断为：视觉策略依赖舱内相机模型（dmonitoringmodeld）输出的面部姿态、闭眼、看手机等概率，响应快（13 秒即达红色告警）；方向盘触碰策略作为视觉不可用时的兜底（例如光照不佳、模型不确定），只要求驾驶员在更长的 25 秒窗口内触碰方向盘。DriverMonitoring._set_policy 中可以看到策略切换逻辑：当面部检测稳定且模型置信度高时使用视觉策略，模型输出不确定（高方差）持续 10 秒以上（_HI_STD_FALLBACK_TIME）则回退到方向盘触碰策略。

注意力值（awareness）衰减与锁定机制

策略的核心状态是一个 0~1 的 awareness（注意力）值：

• 检测到分心（姿态偏离、闭眼、看手机三类之一，且模型置信度足够低噪）时，awareness 以固定步长 step_change = DT_DMON / 告警3时长 递减；其中 DT_DMON = 0.05s（见 common/realtime.py）；
• 分心解除后，awareness 以更快的恢复斜率回升（恢复系数在 _TIMEOUT_RECOVERY_FACTOR_MIN 到 _TIMEOUT_RECOVERY_FACTOR_MAX 之间，即 1.25~5 倍）；
• 跨过低速豁免（10 km/h 以下）后，awareness 触及阈值分别对应绿色（AlertLevel.one）、橙色（AlertLevel.two）、红色（AlertLevel.three）三级告警；红色告警持续 5 秒无响应即记一次 no-response；
• 累计 2 次红色告警或 1 次无响应后，触发递增锁定（1 → 5 → 15 → 30 分钟），锁定期间禁止接合，且计数持久化到 Params（DriverLockoutCount）。

值得特别注意的是，policy.py 的源码顶部直接写有一段致 fork 维护者的警告注释：

# NOTE: To fork maintainers.
# Disabling or nerfing safety features will get you and your users banned from our servers.
# We recommend that you do not change these numbers from the defaults.

这正是后文"fork 安全规范"在代码层面的原声表达——安全参数不建议从默认值修改。

过度执行检查（Excessive Actuation Check）：安全要求二的实时兜底

docs/SAFETY.md 在 fork 规范中明确点名了"过度执行检查"（excessive actuation checks），其实现位于 openpilot/selfdrive/selfdrived/helpers.py。这段代码是对"执行器必须工作在合理极限内"这一安全要求的运行时验证：即使底层限幅逻辑存在缺陷或异常，本检查也能在执行量超过极限约 2 倍时及时发现并处置。

判定逻辑与关键阈值

ExcessiveActuationCheck.update() 每一控制周期（DT_CTRL = 0.01s，见 common/realtime.py）执行如下判定：

MIN_EXCESSIVE_ACTUATION_COUNT = int(0.25 / DT_CTRL)   # 25 帧 = 0.25 秒
MIN_LATERAL_ENGAGE_BUFFER = int(1 / DT_CTRL)          # 100 帧 = 1 秒缓冲

纵向（Longitudinal）：

• 数据来源选用的是校准后的 IMU 加速度 calibrated_pose.acceleration.x，而非 CarState.aEgo——源码注释说明设备原始加速度在颠簸路面、起步、打滑等场景下噪声大；
• 触发条件：纵向接合中（longActive）且实际加速度超出 ACCEL_MAX * 2 或低于 ACCEL_MIN * 2（ACCEL_MIN/ACCEL_MAX 来自 opendbc 接口定义，即纵向规划允许极限的 2 倍）。

横向（Lateral）：

• 由校准 yaw rate 与车速计算 roll 补偿后的横向加速度：vEgo * yaw_rate - sin(roll) * g；
• 触发条件：横向接合中（latActive）、驾驶员未干预方向盘（steeringPressed 为假），且 |横向加速度| 超过 ISO_LATERAL_ACCEL * 2——这里直接引用了文档脚注中 ISO 11270/15622 对应的横向极限常量（来自 opendbc.car.lateral），保持与文档所述标准的一致；
• 存在一个 MIN_LATERAL_ENGAGE_BUFFER（1 秒）的接合缓冲：横向刚接合的前 1 秒不判定，避免接合瞬间的初始转向动作造成误报。

防误报与确认计数：

• 设备加速度与校准加速度之差若超过 2 m/s²，视为 IMU 数据不可信（device_motion_valid = False），本周期不累计；
• 只有连续 0.25 秒（25 个控制帧）持续满足超限且数据可信，才最终判定为纵向或横向过度执行。

判定后的处置链路

检查的调用与处置位于 selfdrived.py：

1. 接合中处置：一旦判定成立且当前尚未记录过，添加 excessiveActuation 事件。该事件在 events.py 中映射为两级动作：ET.SOFT_DISABLE（软退出，提示 "Excessive Actuation"）与 ET.NO_ENTRY（禁止再次接合）——即系统立即解除接合，并阻止在本次驾驶中重新接合，把控制权交还给驾驶员；
2. 下路告警：同时通过 set_offroad_alert("Offroad_ExcessiveActuation", ...) 将该次事件持久化，下一次下路时以告警形式提醒用户联系支持团队，告警文案定义在 alerts_offroad.json。

这条"软退出 + 禁入 + 事后上报"的链路，恰好呼应了文档中"驾驶员必须能立即接管、系统突变必须可被察觉"的两条主线：它既保证超限瞬间控制权回到驾驶员手中，又保证这类异常不会无声地溜走。

Fork 安全规范：三条不可触碰的红线

docs/SAFETY.md 的最后一节对 openpilot 的 fork 项目提出了硬性安全要求，这也是全文最具约束性的部分，完整继承如下：

1. 禁止禁用或削弱驾驶员监控（driver monitoring），即上文分析的 openpilot/selfdrive/monitoring/ 目录；
2. 禁止禁用或削弱过度执行检查（excessive actuation checks），即上文分析的 openpilot/selfdrive/selfdrived/helpers.py；
3. 如果 fork 修改了 opendbc/safety/ 下的任何代码：
   • 该 fork 不得使用 openpilot 商标；
   • 该 fork 必须完整保留 opendbc 安全测试套件，且全部测试必须通过——包括 fork 自身变更所要求的新增测试覆盖。

文档给出的违规后果是明确的：不遵守上述标准的 fork 及其用户将被封禁出 comma.ai 服务器；comma.ai 同时强烈反对使用安全代码缺失或不满足上述要求的 openpilot fork。可以看到，前两条红线对应的正是本文剖析的两个核心模块——监控策略的源码注释（policy.py）与安全参数集中化设计，实际上是在代码层面预先降低了 fork 误改的可能：阈值统一收敛在 DRIVER_MONITOR_SETTINGS，执行检查统一收敛在 ExcessiveActuationCheck，改动面最小且容易被审计发现。

小结：文档要求到代码实现的对照

安全文档中的要求/声明	仓库中的落地位置
故障安全被动系统，驾驶员注意力必要但不充分	整体设计哲学，见 docs/SAFETY.md
FMVSS / ISO 26262 / MISRA C : 2012 / SIL·HIL·实车测试	工程实践声明（发布流程约束）
驾驶员可随时踩刹车/按取消立即接管	panda 安全模型（panda/ 子模块）、opendbc safety（opendbc_repo/ 子模块）
执行器限幅（ISO 11270 / ISO 15622，0.9s→1m 横向偏移）	底层限幅 + ExcessiveActuationCheck 的 2 倍超限兜底
驾驶员分心提醒与升级告警	monitoring/policy.py 双策略状态机与递增锁定
Fork 不得削弱安全代码	三条红线 + policy.py 源码注释 的代码级警示

openpilot 的安全架构呈现出清晰的三层结构：底层由 panda/opendbc 的安全状态机保证"命令合法性与执行器限幅"，中层由自车状态与驾驶员监控保证"人-车责任边界始终清晰"，上层由事件系统与告警链路保证"异常可感知、可追溯、可处置"。理解这三层的关系，是阅读 openpilot 安全相关代码的正确起点。