结论：Hyundai 的控制输出不是一条「转向命令」链路，而是同一份车型控制器代码按经典 CAN / CAN FD、原车纵向 / 自控纵向、LKA / LFA 架构分支，形成不同候选帧，再交给 panda 固件的 hyundai_tx_hook 或 hyundai_canfd_tx_hook 独立复核。主机侧 CANPacker 编码成功、CarOutput.accel 回报正确、tester-present 发出，都不等于 ECU 接受。下述节拍以 card 目标 100 Hz 且每轮调用一次控制器为前提，是代码名义节拍，不是实测总线频率。
公共控制周期：力矩、加速度与请求位
每一控制轮，CarController.update() 先把 actuators.torque 乘以车型 STEER_MAX，再以最近一次软件输出和 CS.out.steeringTorque 调用驾驶员力矩/变化率限制。横向未活动时力矩清零；经典 CAN 分支在横向活动但请求位被切断时还会设置 torque_fault，CAN FD 分支没有这个额外字段。这是两条分支在同一控制器里的第一处实现差异。
common_fault_avoidance() 在转角绝对值达到 85 度时管理请求位，目的在于避免 EPS 长时间大角度带扭矩故障。加速度只做 [-3.5, 2.0] m/s² 夹限，再传给具体纵向报文；CarOutput 回报的 accel 就是这一软件夹限值，不是 CAN FD 内部 aReqValue、MCU 发送回执或车辆实测加速度。
诊断保活方面，若启用 openpilot 纵向且非 CANFD_CAMERA_SCC，每 100 帧向经典 CAN 雷达 0x7d0、CAN FD E-CAN 雷达 0x7d0 或 LKA 架构 ADAS ECU 0x730 形成一条 tester-present 候选。它的目的是维持此前请求的 ECU 静默，不能证明 ECU 已静默；CarInterface.init() 使用通用 disable_ecu()，其成功/失败返回值没有被 card.ControlsReady 闭环消费。取消请求持续时 cancel_counter 逐轮加一，解除请求即归零——源码注释指出部分车辆的取消键也可能是暂停/恢复键，因此原车纵向的按钮取消被延迟。
经典 CAN 输出：LKAS11 与 SCC 家族
LKAS11 每控制轮形成候选：继承 CS.lkas11 中一批原车相机字段，覆盖转向力矩、请求位、HUD 警告、车道线和计数，再按车型选择 CRC8、前 6 字节和、或前 6+末字节和三种校验之一。它不是泛用的「转向命令」结构，不同车型的显示字段也有例外，process_hud_alert() 对部分 Genesis 警告采用不同编码。原车纵向下，持续取消超过 10 帧后发送一条 CLU11 取消候选；恢复请求则在距上次按钮帧大于 0.1 秒时一次追加 25 个相同恢复候选，而 last_button_frame 只在间隔至少 0.15 秒时更新。
自控纵向每偶数帧形成 SCC11、SCC12、SCC14；USE_FCA 且非 CAMERA_SCC 时还生成 FCA11。SCC12 的 aReqRaw / aReqValue 都取软件加速度，计数器及 nibble checksum 由构帧函数处理；SCC14 传入 jerk 上限和 HUD 前车状态。非 FCA 路径在 SCC12 设置 AEB disabled 字段，FCA 路径在 FCA11 设置相应禁用状态。
| 经典 CAN 报文 | 触发条件与节拍 | 关键边界 |
|---|---|---|
| LKAS11 | 每控制轮 | 覆盖力矩/请求位/HUD；校验方式按车型三分支 |
| CLU11 取消 | 原车纵向且持续取消超过 10 帧 | 「最多 10 Hz」注释不等于严格上限 |
| 恢复候选 ×25 | 距上次按钮帧 > 0.1 秒 | 不构成 25 条 ECU 接受证明 |
| SCC11 / SCC12 / SCC14 | 自控纵向每偶数帧 | SCC12 双加速度字段；SCC14 传 jerk 与前车状态 |
| FCA11 | USE_FCA 且非 CAMERA_SCC | 设置制动执行禁用状态 |
| SCC13 / FCA12 | 5 Hz 选项帧 | 额外选项帧，非原车 AEB 保留保证 |
| FRT_RADAR11 | 2 Hz 选项帧 | 同上，单独验证 |
| LFA 图标 | SEND_LFA 平台每 5 帧 | 仅图标候选 |
经典 panda hook 对 LKAS11 限扭矩/请求位，对 SCC12 检查两路加速度并禁止 AEB 执行字段，对 FCA11 阻止制动执行位；诊断地址只允许固定 tester-present 载荷。不同 hyundai、hyundaiLegacy、相机 SCC 和纵向模式选择不同 RX 检查与 TX 白名单，软件字段编码正确仍可能被 MCU 拒绝。
CAN FD 输出：LKA/LFA 路由与 SCC_CONTROL
CanBus 按 LKA/LFA 转向架构决定 A-CAN 或 E-CAN。LKA 平台生成 LKAS / LKAS_ALT，仅在自控纵向时同时补 LFA，其他平台直接生成 LFA。LKA 平台每 5 帧还用最近缓存的 CAM_0x2a4 / CAM_0x362 字段构造「无车道线」报文来抑制原车 LFA——这属于 ADAS 能力修改，应单独验证缓存年龄与原车功能影响。图标候选按 LKA/纵向组合每 5 帧输出；若 flag 开启，LKA 平台可生成 SPAS1 / SPAS2 转向灯候选。
自控纵向每偶数帧生成一条 SCC_CONTROL：aReqRaw 用夹限后的目标，aReqValue 用与上次记录 accel_last 相差不超过 5/50 的值；accel_last 随后记录当前原始目标，而不是编码出的 aReqValue。所以这个运算不能简单称为持续的输出速率限制，阶跃目标须回放核对两个字段和 ECU 响应。LKA 架构另发 ADRV 系列报文以配合禁用 ADAS ECU，LFA 架构按偶数帧生成 AEB disabled 图标报文。
| CAN FD 路径 | 生成条件 | 需单独验证的点 |
|---|---|---|
| LKAS / LKAS_ALT | LKA 架构每轮 | 总线归属（A-CAN/E-CAN） |
| LFA | 自控纵向补发，或非 LKA 平台直接生成 | 架构判定是否正确 |
| 无车道线抑制报文 | LKA 平台每 5 帧 | 缓存 CAM 报文年龄、原车功能影响 |
| SCC_CONTROL | 自控纵向每偶数帧 | aReqRaw 与 aReqValue 的 5/50 差值语义 |
| ADRV 系列 | LKA 架构 | 与禁用 ADAS ECU 的配合 |
| AEB disabled 图标 | LFA 架构每偶数帧 | 仅图标，不等于 AEB 状态 |
| SPAS1 / SPAS2 | flag 开启且 LKA 平台 | 本快照未见设置该 flag 的车型 |
原车纵向 CAN FD 用按钮或 SCC_CONTROL 取消：备用按钮平台直接复用最近 CS.cruise_info 的计数/校验及状态字段，把 ACCMode 改为 4、加速度置零；标准按钮平台须取消持续超过 10 帧、距上次按钮超过 0.25 秒，才一次追加 20 个相同的取消按钮候选。标准按钮的恢复也可一次追加 20 个候选；备用按钮平台的恢复分支只是 pass，本快照未实现。MCU safety 仍要求原车纵向 SCC_CONTROL 为取消模式且加速度为零。
插件化与硬件验收边界
把转向、纵向、巡航按钮、HUD、ADAS 抑制和诊断保活声明为不同能力，各自绑定平台、DBC、线束、节拍及安全模式，是这套实现的自然结论。车型控制插件只提交结构化候选；唯一受信任网关验证 CAN 地址、物理总线、长度、年龄、限幅和 ECU 静默状态，并由独立 MCU 保留不可绕过的 TX safety。禁止把 CANPacker 成功、CarOutput 回报或 tester-present 发送等同于 ECU 接受。
无车验证应覆盖经典 CAN/CAN FD、LKA/LFA、原车/自控纵向、相机 SCC、备用按钮、AEB 图标、缓存断流、大转角请求位、加速度阶跃和诊断失效，再逐帧与 DBC、panda hook 对照。CANFD_ENABLE_BLINKERS 还存在对 0x7b1 的保活及 SPAS 构帧代码，但本快照静态平台表未见设置该 flag 的车型，不能把代码分支当成已启用的实车能力。
常见问题
为什么 CAN FD 里的 aReqValue 不能当作真实加速度限幅？
因为 SCC_CONTROL 的 aReqValue 取的是与上次记录 accel_last 相差不超过 5/50 的值，而 accel_last 记录的是当前原始目标而非编码结果。这个运算在阶跃目标下不是持续速率限制，须回放核对两字段与 ECU 响应；CarOutput 回报的 accel 也只是软件夹限值，不是车辆实测加速度。
tester-present 发出去，是否说明雷达 ECU 已被静默？
不代表。每 100 帧形成的 tester-present 候选只用于维持此前请求的 ECU 静默状态，本身不能证明 ECU 已进入静默；CarInterface.init() 使用的 disable_ecu() 返回值也没有被 card.ControlsReady 闭环消费，因此不能由「帧已构造」推断「ECU 已接受」。
经典 CAN 与 CAN FD 的转向输出差在哪？
经典 CAN 每控制轮形成 LKAS11，并在横向活动但请求位被切断时设置 torque_fault；CAN FD 按 LKA/LFA 架构生成 LKAS/LKAS_ALT 或 LFA，没有这个额外字段。此外 CAN FD 的 LKA 平台还会每 5 帧构造「无车道线」报文抑制原车 LFA，属于 ADAS 能力修改。
备用按钮平台的恢复功能是否已实现？
未实现。源文档明确：原车纵向 CAN FD 中，标准按钮平台的恢复可一次追加 20 个候选，而备用按钮平台的恢复分支只是 pass，本快照未实现。取消分支则复用最近 CS.cruise_info 的字段并把 ACCMode 改为 4、加速度置零。
延伸阅读
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 与本文 LKAS11 三种校验、SCC12 nibble checksum 的语义衔接。
- 从使能到车轮：执行链上的八道门，以及它们各自不保证什么 —— 解释主机编码之后为何仍由 panda 固件独立许可。
- openpilot 的 100 Hz 控制回路：开源 ADAS 能给车载设备什么 —— 本文的「100 Hz 名义节拍」边界来源。
- Hyundai 经典 CAN 的 panda 侧安全模式 —— 承接
hyundai_tx_hook对 LKAS11/SCC12/FCA11 的复核细节。 - Hyundai 经典 CAN 与 CAN FD 的 CarState 输入契约 —— 与控制输出的分支判定互为对照。
参考资料
- 项目 02 ——
openpilot-research/HYUNDAI_CONTROLLER_CAN_OUTPUT_DEEP_DIVE.md（取用了公共控制周期、经典 CAN 与 CAN FD 构帧节拍、panda hook 复核点与插件化边界）。 - 项目 02 ——
openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（仅用于确认 Hyundai 品牌目录与 CAN/CAN FD 链路的总体位置）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复