Hyundai 接口的 CAN FD 判别、能力位与 ECU 静默恢复边界

结论：Hyundai 车型接口的能力位是软件决策，不等于目标 ECU 已按请求改变状态。接口按指纹与固件把平台分成 CAN FD 与经典 CAN 两条判别路径，再由相机总线上是否出现 0x50 或 0x110 决定 LKA 还是 LFA 转向，并据此交换 A-CAN / E-CAN；纵向 ECU 静默只在「自控纵向且非相机 SCC」路径发起，且通用 disable_ecu() 的返回布尔值没有在 Hyundai init() 中被汇总，card 在其返回后直接写 ControlsReady。固定快照基线为 c8fb906，未执行 UDS 请求或实车验证。

入口与函数链

CarInterfaceBase.get_params() 先装载平台规格和静态 flags，再调用 Hyundai _get_params()，最后计算车辆惯量与轮胎刚度。Hyundai _get_params() 负责分 CAN FD / 经典 CAN，由指纹与固件推导动态标志、纵向能力和 safety 配置。HyundaiFlags 记录车型 / 检测特征，HyundaiSafetyFlags 编码给 MCU 的控制策略，二者不可互换。

CAN FD：相机地址驱动的分支

_get_params() 先由 CanBus(None, fingerprint).CAM 找相机总线；该总线上出现 0x50 或 0x110 时判为 LKA 转向，否则判为 LFA。随后 CanBus(None, fingerprint, lka_steering) 重新计算 A-CAN / E-CAN：LKA 平台与 LFA 平台交换两条总线。

CanBusBase 在指纹阶段按非空 bus 最大编号推导四路偏移；运行阶段 CanBus(CP) 则按 safetyConfigs 数量算偏移。因此识别出的拓扑必须与实际 panda / 线束配置一致，不能由车型名称单独推断 E-CAN 号。CAN FD 的 0x1ba、0xFA、0x1cf、0x130、0x40 等地址参与 BSM、混动、备用按钮和档位报文推断。

LKA 平台若相机有 0x110，再加 ALT LKA 标志；非 LKA 平台在没有 CANFD_RADAR_SCC 静态标志时，推导相机 SCC。CANFD_NO_RADAR_DISABLE 会关掉实验纵向可用性；LKA 平台若 car_fw 未列出 ADAS ECU，也会关掉。这些是保守能力判据，但空固件列表与「已证明车辆无 ADAS ECU」不能画等号。CAN FD 默认以 hyundaiCanfd 作为执行 safety；若推导出的 E-CAN 编号至少为 4，则在安全配置列表前插入一个 noOutput，由后一个配置承载 Hyundai safety 参数。

经典 CAN、共同能力与雷达状态

经典 CAN 在动力总线 0 / 相机总线 2 上按地址判断 BSM、LFA 图标、FCA 报文及 LDA 按钮。LEGACY 平台选 hyundaiLegacy safety，因为旧报文缺计数 / 校验；其他经典平台选 hyundai，相机 SCC 再追加相应 safety 参数。LEGACY 或 UNSUPPORTED_LONGITUDINAL 会使实验纵向不可用。

两条路径共同设置 0.1 秒转向执行延迟、0.4 秒限制计时器、扭矩标定，以及 ALT_LIMITS / ALT_LIMITS_2 安全标志；后者还使车型 dashcamOnly。特定平台型号另改延迟或设 dashcamOnly。

车型参数里的 LONG 不是最终上路授权：card 仍可能把接口设为被动并把安全模式改为 noOutput。

ECU 静默与恢复的实际边界

CarInterface.init() 仅在自控纵向且非相机 SCC 路径静默纵向 ECU：经典 CAN 及普通 CAN FD 目标为 0x7d0，LKA 转向 CAN FD 改为 E-CAN 的 0x730。默认通信控制请求带 UDS 0x28 的 suppress-positive-response 位；它表示请求 ECU 不发送正响应，不是已经收到确认。若 CANFD_ENABLE_BLINKERS 置位，接口另对 0x7b1 发独立请求；该 flag 在本快照的静态平台项中未见设置。

通用 disable_ecu() 先要求扩展会话的有效前缀响应，随后以空期望前缀调用通信控制查询并丢弃查询结果；只要后者没有抛异常，就可记录成功。因此其返回真也不等于已验证 0x28 正响应或实际 ECU 停发。Hyundai init() 又没有返回 / 汇总这个布尔值；card 在它返回后直接写 ControlsReady。这是一条源码确认的状态回执缺口，不是对特定车辆雷达或 ADAS ECU 实际行为的断言。

deinit() 构造启用收发请求并复用 init() 的条件与地址。在本快照的主运行链未检出 CI.deinit() 调用，所以不能说正常退出一定主动恢复 ECU。控制器每 100 帧的 tester-present 也仅在自控纵向、非 CAN FD 相机 SCC 时形成。禁用雷达可能使原车 AEB 不可用，必须逐硬件架构独立验证。

面向新硬件与插件化的接口建议

车型插件只应给出期望能力、指纹 / 固件证据、DBC 和拓扑；受信任 ECU 管理服务独占诊断写权限，并单独报告请求已发送、预期正响应或可观测行为、持续存活和恢复结果。不同车型的相机 SCC 与雷达 / ADAS ECU 静默对原车 AEB 的影响，不得合并为一个通用开关。非上车验证矩阵应覆盖 LKA / LFA、相机 / 雷达 SCC、双 panda 总线偏移、备用按钮 / 档位、缺失 ADAS 固件、CANFD_NO_RADAR_DISABLE、负 UDS 响应、超时、掉电恢复及 AEB / FCW。

常见问题

为什么不能用车型名直接推断 E-CAN 号？

因为 E-CAN 号由拓扑推导：指纹阶段 CanBusBase 按非空 bus 最大编号算四路偏移，运行阶段 CanBus(CP) 按 safetyConfigs 数量算偏移；而 LKA 与 LFA 平台会交换 A-CAN / E-CAN。识别出的拓扑必须与实际 panda / 线束配置一致。

车型参数里 LONG 为真就代表能上纵向控制吗？

不代表。只有 openpilotLongitudinalControl（即 alpha_long and alphaLongitudinalAvailable）真正启用时才给 MCU 设 LONG；card 还可能因开关关闭、无控制器或 dashcamOnly 把接口设为被动并把安全模式改为 noOutput。

接口静默雷达 ECU 成功了吗？

无法从返回值判断。默认请求带 UDS 0x28 suppress-positive-response 位，只是让 ECU 不回正响应；disable_ecu() 丢弃查询结果，返回真也不等于已验证 0x28 正响应或 ECU 实际停发。Hyundai init() 更没有汇总该布尔值。

退出时会自动恢复被静默的 ECU 吗？

不能这样假设。deinit() 会构造恢复请求并复用 init() 的条件与地址，但在本快照的主运行链未检出 CI.deinit() 调用。恢复是否发生需按具体运行路径与硬件架构单独验证。

延伸阅读

• Hyundai 车辆状态输入：经典 CAN 与 CAN FD 两条解析路径 —— 承接本文的指纹分支与总线偏移。
• Hyundai 经典 CAN 的 panda safety：报文校验与限幅 —— 说明 hyundaiLegacy 与 hyundai 的差异。
• Hyundai 控制器的 CAN 输出：能力位如何变成候选帧 —— 与本文 CarController.update() 的职责衔接。
• UDS 诊断工具为什么不能随手调：只读、会话与写 ECU 的分权设计 —— 解释 ECU 静默为何属于高危写操作。

参考资料

• 项目 02 —— openpilot-research/HYUNDAI_INTERFACE_CAPABILITY_ECU_LIFECYCLE_DEEP_DIVE.md（取用了 CAN FD / 经典 CAN 判别、能力位推导、ECU 静默与恢复边界分析）。

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

更新记录

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