Honda 车型接口:能力参数、雷达静默与恢复边界

作者:

在

结论:Honda 车型接口把「能力参数」和「能力兑现」分得很清楚:openpilotLongitudinalControl、ControlsReady 与 tester-present 候选都只是软件侧的请求或标记,不是 ECU 行为的回执。雷达静默依赖 disable_ecu(),而它对通信控制请求传入空预期响应前缀、随后无条件打印「ecu disabled」并返回 True,因此至多证明会话得到匹配应答且后续查询没抛异常,不能证明 ECU 已停止发送。没有闭环证据时应保持 noOutput 或只读。

关键函数与组件

基线是本地 source/ 归档提交 c8fb906,只分析 Honda interface.py、通用诊断函数及 card/pandad 交接;不代表任何具体年款的线束、ECU 响应或原车 AEB 行为已验证。

入口 职责
CarInterfaceBase.get_params() 从平台规格建立基础 CarParams,再交给 Honda _get_params() 补齐能力与参数。
CarInterface._get_params() 选择 Bosch/Nidec 安全模式、纵向策略、指纹能力、调校和安全参数。
get_pid_accel_limits() Bosch 给定静态加速度范围;Nidec 的最大值靠近巡航设定速度时下降。
init() / deinit() 有雷达 Bosch 自控纵向的 UDS 通信控制请求与恢复请求。
disable_ecu() 扩展会话重试、通信控制发送及布尔结果;注释明确警告禁用原车 AEB。
IsoTpParallelQuery.get_data() 按预期响应前缀收集结果;空前缀不会验证通信控制的具体正响应码。

能力与安全配置

get_params() 先装载车型平台的质量、轴距、转向比和静态 flags,再调用 Honda _get_params()。Bosch 设置 hondaBosch、radarUnavailable=True;alphaLongitudinalAvailable 对 Bosch CAN FD 为假,openpilotLongitudinalControl 还取决于启动时传入的 alpha_long。它们是软件能力/选择位,不等于雷达实际静默。Bosch CAN FD 且 PT 总线编号至少 4 时,安全配置列表前插 noOutput,但并非所有 CAN FD 都无输出。

Nidec 选择 hondaNidec,同时设置 openpilotLongitudinalControl=True 和 pcmCruise=True,因此不能用 pcmCruise 单独推断执行权由原车 ACC 完全负责。指纹分支检测特定 CR-V BSM 标志、扩展 HUD、混动标志、自动/CVT/手动变速箱以及备用制动帧;EPS 固件版本含逗号时设 dashcamOnly。若 card 判定控制器不可用、用户关闭开关或 dashcamOnly,它会把整组安全配置替换为 noOutput 并标记 passive。

能力位/标记 含义与边界
openpilotLongitudinalControl 取决于启动时 alpha_long,是软件选择位,不等于雷达已静默。
pcmCruise Nidec 同时置真,不能单独推断执行权归属。
safetyParam 对备用制动、Nidec SCM 变体、Bosch 自控纵向、radarless 和 CAN FD 按位编码;固件还需依自身编译门与白名单解释这些位。
ControlsReady card 在初始化门满足时立即写,不验证雷达静默结果。

特别地,Bosch 自控纵向在固件里受 ALLOW_DEBUG 条件编译约束,Python 参数置位本身不足以证明固件允许该模式。此外,多数车型设置 PID 横向参数,部分车型走通用扭矩调校;三处分支直接改写 CarControllerParams.BOSCH_GAS_LOOKUP_V 类属性,不是写入本次 ret 或控制器实例,且函数内没有恢复默认值——同一进程先构建某一车型参数、再构建另一车型时,后者可能继承前者的查表值。

禁用、保活与恢复链

只有 BOSCH、非 BOSCH_RADARLESS 且 openpilotLongitudinalControl 时,CarInterface.init() 才调用 disable_ecu(),目标是固定的诊断目标地址与 PT 总线。它先尝试 UDS 扩展会话并要求匹配应答;随后发通信控制请求,子功能带 suppress-response 位。disable_ecu() 对后一步传入空的预期响应前缀并调用 get_data(0),然后无条件打印「ecu disabled」并返回 True。所以它至多证明前一步会话得到匹配应答且后一步查询没有抛出异常,不能证明 ECU 已停止发送;Honda init() 又没有返回该布尔值。

card 首次满足初始化门时调用 CI.init(),紧接着写 ControlsReady=True,没有验证雷达静默结果。pandad 在 FirmwareQueryDone 和 ControlsReady 都为真后读取参数、设置安全模式;这两项参数并非 ECU 行为回执。保持发送候选、MCU 接受、ECU 收到以及 ECU 持续静默是四个不同事实。

CarInterface.deinit() 用通信控制「启用 RX/TX」请求复用 init() 路径,仍不检查恢复应答。当前主 card 运行链只见 init() 调用,未见对 Honda deinit() 的调用;进程退出或异常时不能由这个函数的存在推断原车雷达/AEB 已恢复。恢复行为是否由 ECU 会话超时、断电或其他机制完成,必须在目标车型台架和受控场地验证。

插件与硬件验收

将「雷达静默」设计成受信任诊断服务持有的事务能力:记录目标 ECU、物理总线、请求、正/负响应、发送持续性、实际雷达报文消失与恢复证据,并把原车 AEB/FCW 影响作为显式安全决策。没有闭环证据时保持 noOutput 或只读,不能让车型插件以 openpilotLongitudinalControl、ControlsReady 或 tester-present 候选代替验收。多车型参数生成必须隔离/冻结 BOSCH_GAS_LOOKUP_V 等调校状态;至少测试 Civic Bosch、Odyssey MMR、RDX MMR 与普通 Bosch 的不同构建顺序。

常见问题

disable_ecu() 返回 True 就代表雷达被禁用了吗?

不代表。disable_ecu() 对通信控制请求传入空的预期响应前缀并调用 get_data(0),然后无条件打印「ecu disabled」并返回 True。源码说明它至多证明前一步扩展会话得到匹配应答且后一步查询没有抛出异常,不能证明 ECU 已停止发送;Honda init() 也没有返回该布尔值。

pcmCruise 为真表示减速完全由原车负责吗?

不能这样推断。Nidec 选择 hondaNidec 时同时设置 openpilotLongitudinalControl=True 和 pcmCruise=True,源码因此明确指出不能用 pcmCruise 单独推断执行权由原车 ACC 完全负责。

BOSCH_GAS_LOOKUP_V 为什么会有跨车型风险?

因为部分调校分支直接改写 CarControllerParams.BOSCH_GAS_LOOKUP_V 类属性,不是写入本次 ret 或控制器实例,且函数内没有恢复默认值。源码可推断:同一 Python 进程先构建某一车型参数、再构建另一车型时,后者可能继承前者的查表值。这需用 Civic Bosch、Odyssey MMR、RDX MMR 等不同构建顺序验证。

进程退出后原车雷达/AEB 会自动恢复吗?

不能由源码推断。deinit() 用通信控制「启用 RX/TX」请求复用 init() 路径、仍不检查恢复应答,而当前主 card 运行链只见 init() 调用、未见 Honda deinit() 调用。恢复行为是否由 ECU 会话超时、断电或其他机制完成,必须在目标车型台架和受控场地验证。

延伸阅读

参考资料

  • 项目 02 —— openpilot-research/HONDA_INTERFACE_CAPABILITY_RADAR_LIFECYCLE_DEEP_DIVE.md(取用了 Honda 接口函数表、能力与安全配置、禁用/保活/恢复链、插件与硬件验收要求)。
  • 项目 02 —— openpilot-research/HONDA_CARSTATE_SPEED_BRAKE_CRUISE_INPUT_DEEP_DIVE.md(仅用于确认 Honda 输入状态专题的接续关系,未取用其未公开内容)。

说明:本文为对固定源码快照的静态结构分析,未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档,标注为未验证的结论保留其原有边界。

更新记录

首次发布 2026-10-11 最近核对:2026-10-11

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注