星核火花赛车科技

标签： Honda

  • 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

  • Honda 旧版 openpilot 子集：DBC 名与 ECU 固件指纹

    结论：这是一份旧版开源辅助驾驶项目的 Honda 子集档案，它记录的不是「某台车抓到了哪些帧」，而是「怎么认出一台 Honda 是哪款」：用 ISO 15765-4 的 29 位固定寻址（0x18DA<TA>F1）向一串 ECU 读固件版本号，再拿版本号前缀去匹配车型；同时按硬件族（Nidec 与 Bosch A / Bosch B）挑选对应的 DBC 与线束，并为每个车型设定最小转向速度。它覆盖 Civic、Accord、CR-V、Fit、Odyssey、Pilot、Insight、HR-V、Passport、Ridgeline 与 Acura ILX / RDX 等多款车。下述内容只适用源文档记录的这一份车型与固件表。

    车辆与适用范围

    源文档是一份旧版开源项目的静态快照：根文档是项目的通用说明，车型细节集中在 Honda 的车型常量文件里。文件同时保留了大量固件版本号样本，用于把「读到的一组版本号」映射回具体车型。

    项 内容
    车型 Honda：Civic（含 2016-18、2019-21、2022、Hatchback、1.6 柴油）、Accord / Accord Hybrid、CR-V（含 5G、EU、Hybrid）、Fit、Freed、HR-V、Odyssey、Pilot、Passport、Ridgeline、Insight、Honda e；Acura：ILX、RDX（含 3G）
    年款 / 市场版本 以车型常量里的年份区间为准（如 Civic 2016-18 / 2019-21 / 2022）；部分条目注明市场（如 Odyssey CHN、CR-V EU）
    ECU / 改装状态 原厂；按车型使用 Nidec 或 Bosch A / Bosch B 线束
    采集跨度 源文档未给出抓包数；车型常量登记了每个 ECU 的固件版本样本列表
    适用范围 仅限源文档所列车型与固件版本；未列入的版本需自行补录，不能假定兼容

    总线与寻址

    这份档案的寻址方式很规整：对每个 ECU 用 0x18DA<目标地址>F1 的 29 位物理请求（F1 是测试仪地址），读回的固件版本号再按车型分组。DBC 侧则按硬件族命名，并给个别车型挂了单独的 body DBC。

    项 内容
    物理层 双绞线 CAN；经车型线束接到相应总线
    链路层 / 比特率 源文档未在本文件给出比特率
    寻址方式 ISO 15765-4 29 位固定寻址：请求 0x18DA<TA>F1，测试仪地址 F1
    CAN FD 源文档未涉及；按经典 CAN 处理
    硬件族 Nidec 与 Bosch A / Bosch B 三套；DBC 名如 honda_civic_touring_2016_can_generated、honda_accord_2018_can_generated、honda_civic_ex_2022_can_generated

    已解码信号

    主素材的「信号级」内容集中在ECU 的请求地址与固件版本前缀上，因此下表登记每个 ECU 的寻址与版本号前缀形态，并给出代表性车型的版本样本。个别条目源文档标注为「修改版固件」，按原样保留。

    ECU 位置（请求地址） 固件版本前缀（样本） 证据
    发动机 PCM 0x18da10f1 37805-… 车型常量 FW_VERSIONS
    线控换挡 0x18da0bf1 54008-… 车型常量 FW_VERSIONS
    变速箱 TCM 0x18da1ef1 28101-… / 28102-… / 28103-… 车型常量 FW_VERSIONS
    电动制动助力 0x18da2bf1 46114-… / 39494-… 车型常量 FW_VERSIONS
    VSA 车身稳定 0x18da28f1 57114-… 车型常量 FW_VERSIONS
    EPS 电动转向 0x18da30f1 39990-… 车型常量 FW_VERSIONS；个别项标注「修改版固件」
    SRS 安全气囊 0x18da53f1 77959-… 车型常量 FW_VERSIONS
    组合仪表 0x18da60f1 78109-… / 78108-… 车型常量 FW_VERSIONS
    HUD 0x18da61f1 78209-… 车型常量 FW_VERSIONS
    前向毫米波雷达 0x18dab0f1 36802-… 车型常量 FW_VERSIONS
    前视摄像头 0x18dab5f1 36161-… 车型常量 FW_VERSIONS
    网关 0x18daeff1 38897-… 车型常量 FW_VERSIONS

    读取方法与注意事项

    第一，识别是「多 ECU 组合」而不是单点。源文档为每款车登记了若干 ECU 的版本号列表，匹配时是把读到的整组版本号与车型的列表比对；只读到某一个 ECU 的版本不足以定车。

    第二，硬件族决定用哪套 DBC 与线束。源文档把车型分成 Nidec 与 Bosch 两族，Bosch 又细分到需要 Bosch A 或 Bosch B 线束：Civic 2016-18 用 Nidec，Civic 2019-21 与 Hatchback 用 Bosch A，Civic 2022 用 Bosch B。CRC/识别出错时，往往是把车放错了族。

    第三，几个「例外集」是踩坑点。源文档列出：HONDA_NIDEC_ALT_SCM_MESSAGES（一批 Nidec 车用替代 SCM 报文）、HONDA_NIDEC_ALT_PCM_ACCEL（Odyssey）、HONDA_BOSCH_ALT_BRAKE_SIGNAL（Accord、CR-V 5G、Acura RDX 3G 用替代制动信号）、HONDA_BOSCH_RADARLESS（Civic 2022 无雷达）、以及 STEER_THRESHOLD 的两处覆盖（Acura RDX 与 CR-V EU 用 400，默认 1200）。

    第四是最小转向速度：车型信息里为每款车写了 min_steer_speed，从 0（如 Civic 2022、Odyssey）到 25 mph（Acura ILX）不等，且都按 mph 换算。它与硬件族、DBC 一样是车型识别后要一起取用的参数。

    证据等级与边界

    可视为文档级证据的是：每个 ECU 的请求地址、以及各车型登记的固件版本号列表。这些是源文档快照里的明确内容。属于「示例性」的是具体版本号——它们来自项目记录的样本，不代表该车型全部生产版本；未列入的版本不能被假定兼容。

    不能外推的地方有两处。第一，车型与年款是逐条列出的，同一车名不同年款可能属于不同硬件族、用不同 DBC（Civic 三代就是例子），跨年款套用没有依据。第二，源文档是旧版项目的静态快照，后续项目可能已增删车型或改动寻址；本文只反映快照当时的内容。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试。读固件版本属于常规诊断读取；本文不涉及任何写 ECU 或绕过安全机制的操作。

    常见问题

    这台 Honda 到底是哪款、用哪套硬件？

    源文档的做法是向一组 ECU（PCM、TCM、VSA、EPS、仪表、雷达、摄像头、网关等）读固件版本，用整组版本号匹配车型，并据车型决定用 Nidec 还是 Bosch A / Bosch B 线束与对应 DBC。

    Civic 2016-18、2019-21、2022 有什么区别？

    硬件族不同：2016-18 属 Nidec，2019-21 与 Hatchback 属 Bosch A，2022 属 Bosch B；Civic 2022 还被列入无雷达集合，且最小转向速度记为 0。

    为什么有些车要单独列出替代报文集合？

    源文档为若干车设了例外集，例如一批 Nidec 车用替代 SCM 报文、Odyssey 用替代 PCM 加速报文、Accord/CR-V 5G/Acura RDX 3G 用替代制动信号、Civic 2022 无雷达；这些车的报文布局与同族其它车不同。

    固件版本号能当唯一识别码吗？

    不能。源文档登记的是样本列表，用于组合匹配；未列入的版本不在表内，且同一车型不同年款可能落在不同族，不能只凭一个版本号定车。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/blueopenpilot-c3-legacy-subset/README.md（主来源：项目总说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/blueopenpilot-c3-legacy-subset/selfdrive/car/honda/values.py（车型常量、ECU 请求地址、固件版本表与硬件族）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • Honda 平台表：38 个条目里的 DBC、flags 与线束提示

    结论：Honda 的平台表把三类东西放在不同层：软件平台定义（固定快照里 38 个 Honda/Acura 条目）、DBC 与 flags、以及 HondaCarDocs 的线束提示。三者不能互相替代——同 DBC 不等于同线束，CAN FD DBC 不等于 CAN FD 平台，文档线束提示也不等于接线验证。任何车型插件都必须冻结精确平台 ID、DBC 哈希、静态与动态 flags、物理总线图与线束版本，不能只凭「Bosch/Nidec」或 DBC 文件名授予控制权。

    38 个平台条目：计数的是代码平台

    在固定快照 c8fb906 的 CAR 枚举里，Honda/Acura 有 38 个平台条目：26 个 Bosch 配置，其中 7 个为 HondaBoschCANFDPlatformConfig，另有 12 个 Nidec 配置。源文档强调，这里计数的是代码平台，不是市场车型、年款或可装车数量。

    HondaBoschCANFDPlatformConfig 继承 Bosch，构造时加 BOSCH_CANFD，并默认 PT DBC 为 honda_common_canfd_generated；HondaNidecPlatformConfig 加 NIDEC，各平台通过 radar_dbc_dict() 同时声明 PT DBC 与 acura_ilx_2016_nidec 雷达 DBC。

    软件类别 代表平台 DBC / flags 含义
    Bosch 有雷达 HONDA_ACCORD、HONDA_CRV_5G PT DBC 依车型而异；BOSCH_ALT_BRAKE 可为静态标志，也可由指纹条件补上。
    Bosch 无雷达 HONDA_CIVIC_2022、HONDA_HRV_3G、ACURA_ADX BOSCH_RADARLESS 使车端总线、按钮目标和纵向权限走不同分支；不能只按 DBC 名判断。
    Bosch CAN FD HONDA_ACCORD_11G、HONDA_CRV_6G、ACURA_MDX_4G_MMR BOSCH_CANFD 标志和默认 PT DBC 一起定义平台；本快照参数层不开放 CAN FD 实验纵向。
    Bosch 非 CAN FD 但复用 CAN FD DBC ACURA_MDX_4G PT DBC 仍是 honda_common_canfd_generated，源码注释明确「not CANFD car but shares same dbc」；安全模式和总线拓扑不能由 DBC 文件名反推。
    Nidec HONDA_CIVIC、HONDA_CRV、HONDA_ODYSSEY PT/雷达双 DBC；NIDEC_ALT_SCM_MESSAGES、NIDEC_ALT_PCM_ACCEL 和全车门字段标志决定输入/输出分支。

    CarSpecs 与参数复用不等于实车测定

    CarSpecs 给质量、轴距、转向比、质心前轴比、最低转向/使能速度和轮胎刚度因子；通用 get_params() 将其写入 CarParams，并加默认载荷后计算惯量/轮胎刚度。平台间存在显式参数复用：旧 HONDA_HRV 复用 HONDA_HRV_3G.specs，旧 HONDA_PILOT 复用四代 Pilot 的 specs。源文档提醒，这是代码共享，不是目标车辆物理参数已经测定的证据。

    CarInterface._get_params() 把静态平台资料与指纹、固件、用户选择合成为实际 CarParams 和 safetyParam；CarState.get_can_parsers() 按 PT/相机/车身路由建立解析器，RadarInterface 在 Nidec 平台另用 Bus.radar DBC 建立雷达解析器，CanBus/CarControllerParams 再把车型能力映射为物理总线与转向扭矩上限。源文档据此把「平台表」定位为软件声明，而不是可直接施工的线束图。

    静态 flags、指纹动态标志与总线映射

    平台表中的 BOSCH、NIDEC、BOSCH_RADARLESS、BOSCH_CANFD、BOSCH_ALT_RADAR 是构造时的静态能力。CarInterface._get_params() 还从指纹动态设置 BOSCH_EXT_HUD、HYBRID、条件性的 BOSCH_ALT_BRAKE 以及特定五代 CR-V 的 HAS_BSM；固件 EPS 版本含逗号则置 dashcamOnly。BOSCH_TJA_CONTROL 在控制器有分支，但本快照平台定义中未见设置，不能把 dormant 代码当作已开通能力。

    CanBus 把 Bosch 有雷达平台的 PT 映射到 offset+1、radar 到 offset，纵向模式影响 LKAS 发送总线；radarless/CAN FD/Nidec 使用另一组映射。CarState 的相机解析器使用同一 PT DBC，却绑定 CanBus.camera 物理输入；BSM parser 使用 Bus.body DBC 但读取 CanBus.radar，需要 panda 转发 B-CAN。源文档据此总结：DBC 语法共用、逻辑 Bus 名称和真实总线接线是三个不同层次。DBC 语法共用不代表物理总线相同。

    这些 flags 的取值分支会一路传到构帧与限幅：例如 BOSCH_RADARLESS 影响车端总线与按钮目标，纵向模式影响 LKAS 发送总线。因此只按 DBC 名或品牌判断输入/输出分支，会同时误判总线映射与限幅参数。

    线束提示只是文档族

    HondaCarDocs.init_make() 按 flags 选择文档线束族：Bosch CAN FD 为 bosch_c，radarless 为 bosch_b，其他 Bosch 为 bosch_a，Nidec 为 nidec。CarDocs 的年款、最低转向速度、套件和 AEB/FCW 脚注用于支持表呈现，不构成引脚、供电、继电器或 EMC 的工程验收。部分平台 car_docs=[] 只是不在支持表展示，不代表平台代码不存在。

    把这些层叠起来看：平台表决定「软件认为这是什么车」，flags 决定「走哪条分支」，DBC 决定「怎么解析字段」，线束文档决定「支持表怎么展示」，而物理接线与 ECU 固件证据是独立的一层。四者只有在插件描述符里逐项冻结，才谈得上可复现。

    插件描述符必须冻结什么

    必须冻结的字段 为什么不能省
    精确平台 ID、DBC 哈希 同 DBC 不等于同线束；ACURA_MDX_4G 复用 CAN FD DBC 却是非 CAN FD 平台。
    静态 flags（BOSCH / NIDEC / BOSCH_RADARLESS / BOSCH_CANFD） BOSCH_RADARLESS 会使总线、按钮目标和纵向权限走不同分支。
    动态 flags（EXT_HUD / HYBRID / ALT_BRAKE / HAS_BSM / dashcamOnly） 由指纹与固件条件设置，不能只按 DBC 名或品牌判断。
    物理总线图、线束版本 逻辑 Bus 名称与真实接线是不同层次，DBC 名不能反推拓扑。
    ECU 固件证据、panda safety 模式 决定控制权授予与失联回退，不能只靠「Bosch/Nidec」授予控制权。

    源文档给出的顺序是：先建立目标车型的只读 CAN/电源/接线记录，再验证 PT、camera、radar、body 路由、原车 ADAS 保留和失联回退；没有原厂资料和台架证据，不把文档线束类型当作可照抄的接线表。此处仅完成静态结构分析，未验证 38 个平台的实际车辆参数或装配兼容性。

    常见问题

    38 个 Honda 平台条目等于 38 款可装车型吗？

    不等于。源文档明确，这 38 个是代码里的平台条目（26 个 Bosch 配置含 7 个 CAN FD 配置，加 12 个 Nidec 配置），计数的是代码平台，不是市场车型、年款或可装车数量。

    用了同一个 CAN FD DBC，是否说明这平台就是 CAN FD 车？

    不是。ACURA_MDX_4G 的 PT DBC 仍是 honda_common_canfd_generated，但源码注释明确它「not CANFD car but shares same dbc」，说明安全模式和总线拓扑不能由 DBC 文件名反推。

    文档线束提示（bosch_a/b/c、nidec）可以直接照抄接线吗？

    不可以。这些是 HondaCarDocs.init_make() 按 flags 选择的文档线束族，用于支持表呈现，源文档明确它们不构成引脚、供电、继电器或 EMC 的工程验收。接线仍需原厂资料与台架证据。

    BOSCH_TJA_CONTROL 出现分支，是否代表该能力已开通？

    不代表。源文档指出它在控制器里有分支，但本快照的平台定义中未见设置，属于 dormant 代码，不能当作已开通能力。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_PLATFORM_DBC_HARNESS_MATRIX_DEEP_DIVE.md（取用了平台类别计数、静态与动态 flags 分层、总线映射与线束文档族选择逻辑）。

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

    更新记录

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

  • Honda panda safety：RX/TX 白名单与 AEB 转发

    结论：Honda panda safety 的规则分四段：RX 检查表（地址/总线/长度/频率 + nibble checksum 与二位计数器）、使能状态（主开关、PCM/SET-RESUME 使能沿）、TX 白名单与内容钩子、以及转发钩子。honda_tx_hook() 的 Honda 内容钩子在 controls_allowed=False 时拒绝非零转向，但源码并未在该钩子内对使能时的转向幅度或变化率作额外限制，那部分由主机 CarController 承担。拒帧还可能产生状态副作用：本地 C 探针显示，一帧被拒的主机 0x1FA 仍会先写入全局 honda_brake，从而影响下一次原车 AEB 转发决策。以下为固定源码快照 c8fb906 与本地 C 探针的静态分析，不证明目标板固件编译选项、实际 CAN 总线或整车安全性。

    关键函数与组件

    入口 源码 作用
    honda_nidec_init() / honda_bosch_init() honda.h 按参数选择 RX 期望、TX 地址/总线/长度白名单和平台状态。
    honda_get_checksum() / honda_compute_checksum() / honda_get_counter() honda.h 解码 Honda checksum/计数器，供通用接收检查使用。
    safety_rx_hook() / honda_rx_hook() safety.h、honda.h 通用验证通过且属于 RX 检查表后，才更新 Honda 使能、踏板与 AEB 状态。
    generic_rx_checks() / safety_tick() safety.h 踩刹车等通用退出，以及每秒检查关键 RX 消息是否超时/失效。
    safety_tx_hook() / honda_tx_hook() safety.h、honda.h 通用白名单加 Honda 内容检查；最终还需无继电器故障。
    safety_fwd_hook() / honda_nidec_fwd_hook() safety.h、honda.h 通用阻断冲突帧后，Nidec 对相机原车制动执行动态转发决策。

    RX 与使能状态

    Honda RX 检查表把 SCM_BUTTONS 两种地址、ENGINE_DATA、POWERTRAIN_DATA 纳入核心检查；多数模式还检查 SCM_FEEDBACK，备用刹车模式加 BRAKE_MODULE，Nidec 还检查相机总线 BRAKE_COMMAND。每项声明地址、总线、长度和频率，部分声明最大计数器。Honda 钩子提供 nibble checksum 和二位计数器解码；通用 safety_rx_hook() 仅在消息匹配、校验有效且属于 RX 表时才调用 honda_rx_hook()。safety_tick() 每秒检查迟到/无效关键消息并清除 controls_allowed，不能把 25/100 Hz 配置频率误读为毫秒级 fail-safe deadline。

    honda_rx_hook() 从 ENGINE_DATA 更新是否行驶，从 SCM 更新 ACC 主开关，主开关关闭直接禁止控制。Bosch 原车巡航和 Nidec 使用 PCM 巡航上升沿允许控制；Bosch 巡航退出会撤销许可，但 Nidec 允许在 PCM 退出后继续制动至零。Bosch 自控纵向改用 SET/RESUME 的释放沿使能，MAIN/CANCEL 则退出。用户制动有普通 POWERTRAIN_DATA 的连续开关样本判据或备用 BRAKE_MODULE 来源；随后通用 generic_rx_checks() 再按制动上升沿/车辆运动状态撤销控制。主机侧 CarState 字段不替代 MCU 的这一路独立采样。

    TX 白名单与内容规则

    通用 safety_tx_hook() 先核对当前模式 TX 表中的地址、总线和长度，再调用 Honda 内容钩子，最终还受 relay_malfunction 阻断。Nidec 允许指定转向、BRAKE_COMMAND、ACC_HUD 和 LKAS_HUD；Bosch 普通、纵向、radarless、CAN FD 各有不同表。Bosch 纵向 safetyParam 只在 ALLOW_DEBUG 编译条件下转成纵向模式能力，不能由 Python CarParams 位推断实板支持。

    内容钩子在 controls_allowed=False 时拒绝非零转向；源码未在该钩子内对使能时的转向扭矩幅度、变化率或驾驶员反向扭矩作额外限制。主机 CarController 自身会做变化率和车型 STEER_MAX 处理，但这是与 MCU TX 规则不同的层。当前 Honda 安全测试的转向专项只断言未使能零值可发、非零值被拒，不能把通用车型的转向扭矩安全测试结果自动套给 Honda。Nidec 对 ACC_HUD 的 PCM 速度/gas 和 BRAKE_COMMAND 的制动量做纵向许可检查，并阻止主机设置 AEB 执行位；Bosch 有雷达的 ACC_CONTROL 检查加速度、gas 和 AEB 位，radarless 的加速报文走另一地址与编码。所有这些规则只约束通过当前 TX 表的候选，不能保证 ECU 实际接受。

    Nidec AEB 转发及状态顺序

    相机总线 0x1FA 通过 RX 检查后，如果未设置「禁用原车 AEB」的替代体验位，Honda 钩子比较原车制动力与最近记录的主机制动力：原车 AEB 不活动时清掉转发锁存；AEB 活动且原车制动力不小于主机记录值时置位；较小时保持之前状态。通用转发层先按继电器故障和静态冲突表阻断，Nidec 专属钩子再决定是否允许相机 0x1FA 走向另一总线。

    honda_tx_hook() 读取 Nidec 主机 0x1FA 时，先写全局 honda_brake，后检查制动上限、是否正在转发原车 AEB 和 AEB 位。本地拒帧探针直接编译仓库的 libsafety/safety.c：在 Nidec 模式下，相机 AEB 0x1FA 请求制动 100，基线转发；重新初始化后，先送主机 0x1FA 请求制动 200 且带 AEB 执行位，该帧被 TX 钩子拒绝，再送相同的相机帧，RX 有效但转发被阻断。严格编译和 UBSan 运行输出：

    场景 相机帧 RX 转发 说明
    基线 有效（rx=1） 允许（forward=1） 无先前主机帧干扰。
    先送被拒主机帧 — 候选未被接受（accepted=0） 主机制动 200 且带 AEB 位，被 TX 钩子拒绝。
    随后相机帧 有效（rx=1） 被阻断（forward=0） RX 有效但转发被阻断，证明拒帧有状态副作用。

    这证明当前测试库实现中拒帧可影响下一次 AEB 转发决策，尚不证明目标实板的编译配置、真实消息时序或车辆制动后果。

    自制硬件与插件验收

    车型插件只能提交受限候选，MCU 必须独立持有模式、RX 有效性、TX 白名单、超时与转发规则。Honda 的不同模式要分别验证 PT/camera 总线、备用刹车、Nidec 原车 AEB、Bosch ALLOW_DEBUG 门、诊断固定载荷和失联默认状态。探针应扩展为正式回归测试：对越界、带 AEB 位、因原车 AEB 锁存而被拒的主机 0x1FA，都断言下一帧的转发状态只依据已准许发送的主机制动记录。还需检查使能时转向幅度由哪些独立物理/软件约束承担，不能把 Python 限幅写成 MCU 的保证。本文未运行完整 safety 测试或实板故障注入。

    常见问题

    Honda 的转向扭矩在 MCU 侧会被限幅吗？

    Honda 内容钩子只在 controls_allowed=False 时拒绝非零转向，源码未在该钩子内对使能时的幅度、变化率或驾驶员反向扭矩作额外限制。变化率与车型 STEER_MAX 由主机 CarController 处理，属于不同层次。

    Nidec 用哪种沿使能，Bosch 自控纵向呢？

    Nidec 与 Bosch 原车巡航用 PCM 巡航上升沿允许控制；Bosch 自控纵向改用 SET/RESUME 的释放沿使能，MAIN/CANCEL 退出。Nidec 还允许在 PCM 退出后继续制动至零。

    一帧被拒的主机 0x1FA 会影响后续转发吗？

    会。主机 0x1FA 被 TX 钩子读取时先写全局 honda_brake 再检查，探针显示被拒帧仍能改变下一次相机 AEB 0x1FA 的转发决策，输出为 baseline rx=1 forward=1; rejected candidate accepted=0; stock rx=1 forward=0。

    safety_tick() 是毫秒级 fail-safe 吗？

    不是。它每秒才检查迟到/无效关键消息并清除 controls_allowed，不能把 25/100 Hz 配置频率误读为毫秒级安全时限。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_PANDA_SAFETY_RX_TX_FORWARD_DEEP_DIVE.md（RX/TX 白名单、使能状态、Nidec AEB 转发与拒帧探针）。
    • 项目 02 —— openpilot-research/ 同目录 Honda 接口与输出专题（模式参数与控制构帧作为相邻边界参考）。

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

    更新记录

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

  • Honda 控制输出：Bosch/Nidec 构帧与 50/10 Hz 节拍

    结论：Honda 控制输出分 Bosch 与 Nidec 两条构帧路径，并叠加三层节拍：转向每轮一条候选、纵向 50 Hz、仪表 10 Hz。Nidec 的正加速并不在 50 Hz 制动帧里，而由 10 Hz ACC_HUD 携带 PCM_SPEED/PCM_GAS，所以仪表链本身就是纵向执行链的一部分。Python 侧的限幅不等于 MCU 的安全保证：CarController 的 STEER_MAX 与变化率处理、panda honda_tx_hook() 的独立检查、继电器故障阻断是不同层次。下述 100/50/10 Hz 均以目标 100 Hz、每轮调用控制器一次且无丢周期为前提，只表示软件名义节拍；未做 DBC 回放、台架或实车验证。

    关键函数与组件

    入口 源码 作用
    CarController.update() carcontroller.py 读取控制目标与车况缓存，限幅、调度并返回候选 CAN 帧和软件回报值。
    compute_gas_brake() carcontroller.py Nidec 把加速度转换成 gas/brake；Bosch 分支当前返回两个零，实际纵向另由 ACC 帧表示。
    actuator_hysteresis() / brake_pump_hysteresis() carcontroller.py Nidec 制动去抖与泵请求；泵计时基于 frame * DT_CTRL。
    CarControllerParams / CanBus values.py、hondacan.py 车型扭矩上限、变化率及 PT/radar/camera/LKAS 路由。
    create_steering_control() / create_acc_commands() hondacan.py 转向和 Bosch 纵向字段编码。
    create_brake_command() / create_acc_hud() hondacan.py Nidec 制动、PCM 加速及仪表字段编码。
    honda_tx_hook() / honda_nidec_fwd_hook() honda.h MCU 独立检查候选帧并决定相机制动帧转发。

    公共转向与回报语义

    每轮先对归一化 actuators.torque 以 STEER_DELTA_UP/DOWN * DT_CTRL 限变化率，再取负号、夹到 [-1, 1] 并乘车型 STEER_MAX 构造 CAN 扭矩。create_steering_control() 始终生成一条 STEERING_CONTROL 候选；CC.latActive 为假时其扭矩和请求位都为零，BOSCH_TJA_CONTROL 还设置 STEER_DOWN_TO_ZERO。这段 Python 限制不替代 MCU 的未使能零转向规则，也不能从 latActive 为真推定车辆接受转向。

    new_actuators 中的 torque 是软件限速后的归一化值，torqueOutputCan 是编码前的整数；accel/gas/brake/speed 有部分字段只在对应分支更新，可能保持上轮值。它们是软件目标回报，不是 panda 发送回执或车辆执行测量。控制器仅在车控存活检查通过时才被调用并发布 sendcan；消息的 valid 使用 CS.canValid，具体总线发送仍需再经过 pandad/panda。

    纵向与按钮分支

    分支 触发条件 生成的候选帧
    原车纵向 未启用自控纵向 偶数轮 BOSCH_SUPPLEMENTAL_1；取消或恢复请求时 SCM_BUTTONS（radarless 发相机总线，其余用 PT 总线）
    自控纵向 Bosch 启用自控纵向 偶数轮 ACC_CONTROL；有雷达版再加 ACC_CONTROL_ON
    自控纵向 Nidec 启用自控纵向 50 Hz BRAKE_COMMAND + 10 Hz ACC_HUD 携带 PCM_SPEED/PCM_GAS

    若未启用自控纵向，偶数轮对非 radarless/CAN FD 平台尝试生成 BOSCH_SUPPLEMENTAL_1，取消或恢复请求则生成 SCM_BUTTONS；radarless 把按钮发到相机总线，其他平台用 PT 总线。源码的 supplemental 条件没有显式限定 Bosch，不能据此推定所有进入该分支的车型都获安全白名单许可。spam_buttons_command() 只生成一条候选，调用处没有独立按钮节流，实际发送还受当前模式的 TX 白名单和按钮安全门制约。

    启用自控纵向时偶数轮生成纵向候选。Bosch 把加速度夹在 BOSCH_ACCEL_MIN/MAX，用独立查表得到 gas；有雷达版同时生成 ACC_CONTROL_ON 与 ACC_CONTROL，无雷达版只生成 ACC_CONTROL。gas_command 在不活动或低于阈值时为 -30000，ACCEL_COMMAND 在不活动时为零；STANDSTILL 由 LongControlState.stopping 连续计数而来，无雷达版 IDLESTOP_ALLOW 要计数超过 200 个 50 Hz 周期。enabled、longActive、stopping 是不同条件，不能合并成单一「已启用」位。

    Nidec 的 compute_gb_honda_nidec() 在低于 2.3 m/s 时引入蠕行制动，再经刹车迟滞、每轮变化率限制、风阻扣减和 NIDEC_BRAKE_MAX - 1 上界量化为 BRAKE_COMMAND。泵请求在制动增大或超过 20 秒后重置计时，正制动下保持至少 0.2 秒。编码器把 AEB 执行相关字段显式置零，FCW 只映射警告和原车 chime。Nidec 正加速不是每个 50 Hz 制动周期的独立油门帧，而是在 10 Hz ACC_HUD 中携带 PCM_SPEED/PCM_GAS，因此 HUD 链也是其纵向执行链的一部分，应分别回放替代与普通分支。

    HUD、总线与 MCU 边界

    每 10 轮：自控纵向才生成 ACC_HUD，所有模式生成一个或两个 LKAS_HUD 候选；有雷达 Bosch 自控纵向还生成 RADAR_HUD，特定 Civic Bosch 补 LEGACY_BRAKE_COMMAND。原车纵向且 BOSCH_EXT_HUD 时 LKAS_HUD_A/B 分开发送。hud_v_cruise 在不可见时取 255，可见时除以 CS.v_cruise_factor，此值依赖 CarState 所选单位。create_acc_hud() 对 Bosch/Nidec 使用不同字段，Nidec 还复制原车 acc_hud 的若干 FCM/图标位；无新鲜度检查时不应将复制成功当作原车功能健康。

    CanBus 不能假定 PT 永远是 bus 0：有雷达 Bosch 的 PT 为 offset+1、radar 为 offset，LKAS 依据自控纵向决定去 PT 还是 radar；radarless/CAN FD 与 Nidec 的 PT 为 offset。panda honda_nidec_init() / honda_bosch_init() 选择地址、总线、长度白名单及 RX 检查；Bosch 自控纵向的 safetyParam 分支仍受 ALLOW_DEBUG 编译门约束，不能因 Python 能构帧就推定量产固件可发。

    honda_tx_hook() 对 Nidec BRAKE_COMMAND 的制动幅度、AEB 位和 ACC_HUD 的速度/gas 作检查；对 Bosch ACC_CONTROL 的加速度、gas 和 AEB 位作检查；未允许控制时转向输出必须为零。诊断地址只允许固定 tester-present 载荷，Bosch 原车纵向的按钮在控制不允许时只能取消。Nidec honda_nidec_fwd_hook() 还按相机原车 AEB 制动力与自控制动请求比较动态转发 0x1FA，不是简单的「总是屏蔽原车制动」。

    插件与硬件验收

    车型输出插件应分别声明转向、纵向、按钮、HUD、诊断保活和原车 ADAS 影响权限；每项绑定 DBC、车型指纹、物理总线、消息周期、数据年龄和 panda safety 模式。只允许插件产生候选控制帧，最终 TX 白名单、力矩/加速度/AEB 约束与超时失效仍在独立 MCU。对 Nidec 要单测 10 Hz ACC_HUD 与 50 Hz 制动的耦合、泵保持和原车 AEB 转发；对 Bosch 要单测雷达/无雷达、原车/自控纵向、ALLOW_DEBUG 配置和 ECU 静默失败。当前没有可用实板、目标车型回放或车辆执行证据，本文不能作为上车许可。

    常见问题

    Nidec 的加速信号在哪条帧里？

    不在 50 Hz 制动帧里。Nidec 正加速是在 10 Hz ACC_HUD 中携带 PCM_SPEED/PCM_GAS，因此 HUD 链也是其纵向执行链的一部分，不能只看 BRAKE_COMMAND。

    Bosch 的 gas 是怎么算出来的？

    自控纵向时 Bosch 把加速度夹在 BOSCH_ACCEL_MIN/MAX，再用独立查表得到 gas；gas_command 在不活动或低于阈值时为 -30000。compute_gas_brake() 的 Bosch 分支当前返回两个零，实际纵向另由 ACC 帧表示。

    PT 总线一定是 bus 0 吗？

    不是。有雷达 Bosch 的 PT 为 offset+1、radar 为 offset，LKAS 依据自控纵向决定去 PT 还是 radar；radarless/CAN FD 与 Nidec 的 PT 为 offset，因此不能假定固定编号。

    Python 的转向限幅算安全保证吗？

    不算。CarController 的 STEER_MAX 与变化率处理只是软件层；MCU 的 honda_tx_hook() 独立检查候选帧，未允许控制时转向输出必须为零，最终还受继电器故障阻断。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_CONTROLLER_CAN_OUTPUT_DEEP_DIVE.md（Bosch/Nidec 构帧、50/10 Hz 节拍、HUD 与 MCU 边界）。
    • 项目 02 —— openpilot-research/ 同目录 Honda CarState 与接口专题（输入侧与雷达通信控制作为相邻边界参考）。

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

    更新记录

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