结论：Chrysler 的构帧不是一套模板，而是四套并存的布局：Pacifica/常规 Jeep、Ram DT、Ram HD 与 Cherokee CUSW，三帧消息的地址、字节长度和所在总线都不同，不能互相套用。几个最容易踩的点是：Ram 的按钮帧走 bus 2 而其他走 bus 0；Ram HD 与 CUSW 的 TX/RX 只在 ALLOW_DEBUG 构建中注册且参数层标 dashcamOnly；Pacifica、Ram DT、Ram HD 的转向扭矩上限分别是 261、261、361，CUSW 为 250。字段名相同并不代表可共用原始载荷。以下为固定快照 c8fb906 的静态分析，未向车辆发送 CAN。
四套发帧布局
主机侧三类输出分别是 LKAS 转向命令、DAS_6 图标/车系码/警示，以及巡航按钮。CANPacker.pack() 会在未显式提供时按地址递增 COUNTER，并调用 DBC 对应的 CHECKSUM 函数；chrysler_ 系列 DBC 使用 chrysler_checksum()，即最后一字节之外的 CRC-8 J1850，初值与尾异或都是 0xff。
| 平台族 | LKAS / DAS_6 / 按钮（地址/长度） | 主机 bus | panda 限制 |
|---|---|---|---|
| Pacifica / 常规 Jeep | 0x292/6 B、0x2a6/8 B、0x23b/3 B |
三种都在 bus 0 | 扭矩最大值 261，速率上/下限每次 3。 |
| Ram DT | 0xa6/8 B、0xfa/8 B、0xb1/3 B |
LKAS/HUD bus 0，按钮 bus 2 | 主机扭矩上限 261，固件白名单 350，实际受主机更紧约束。 |
| Ram HD | 0x276/8 B、0x275/8 B、0x23a/3 B |
LKAS/HUD bus 0，按钮 bus 2 | 主机/固件扭矩上限均 361，速率 14；TX/RX 仅 ALLOW_DEBUG 注册。 |
| Cherokee CUSW | 0x1f6/4 B、0x5dc/4 B、0x2fa/3 B |
三种都在 bus 0 | 独立 safety model，扭矩 250，速率 4；参数层标 dashcamOnly。 |
控制周期与按钮时序
CarController.update() 以 DT_CTRL = 0.01 s 的帧计数运行。按钮只在距上次发送严格超过 0.05 s 时生成，优先取消、其次恢复；计数用 CS.button_counter + 1，再由 create_cruise_buttons() 截成 4 位。这里有一个平台差异：CUSW 的 update_cusw() 没有像常规分支那样刷新 button_counter，若生成按钮帧会反复使用初始化值加一，是否触发原车计数拒收仍需台架确认。
DAS_6 的字段由 create_lkas_hud() 生成：它把激活态、车系码和告警转成图标与车道线字段；Ram 额外带原车自动远光状态，而 CUSW 的告警字段固定为零。也就是说，同一个「车道保持已激活」在四套布局里落在不同字段上，跨平台复用图标语义需要分别核对。
HUD 每 25 帧尝试一次，且只有 CS.lkas_car_model != -1 才发送。hud_count 小于 4 的启动告警只覆盖最初四个实际发送的 HUD 帧，源码注释里的「first 3 seconds」不能当作精确时长。转向周期由 CarControllerParams 设为普通/Ram 50 Hz、CUSW 100 Hz；控制位则依 minSteerSpeed、平台迟滞和最近下降沿约 200 个控制帧的等待决定。由于 lkas_active 在本次控制位更新前读取上一状态，控制位首次置位的周期不会产生非零扭矩。
| 时序项 | 取值 | 备注 |
|---|---|---|
| 控制步长 | DT_CTRL = 0.01 s |
按钮与 HUD 都按帧计数节流。 |
| 按钮最小间隔 | 严格大于 0.05 s | 优先取消，其次恢复。 |
| HUD 周期 | 每 25 帧 | 仅当 lkas_car_model != -1。 |
| 转向速率 | 普通/Ram 50 Hz、CUSW 100 Hz | 由 CarControllerParams 决定。 |
| 控制位迟滞 | 约 200 个控制帧 | 自最近下降沿起等待。 |
控制字段与原始载荷不能共用
create_lkas_command() 对 Ram 的控制字段编码为 2，其他为 1。这对应固件里的不同检查：常规固件在 Pacifica 上检查 bit 4、在 Ram 上检查字段值 2，而 CUSW 独立检查 bit 12。字段名相同并不代表可以共用原始载荷，这也是四套布局必须分别验证的原因之一。
panda 是最后一道独立门
主机发出的三类帧仍要经过 panda 安全钩子。常规模式仅允许表中的地址、总线与长度；转向再做扭矩与请求位检查；按钮只接受纯取消，或在 controls_allowed 下的纯恢复，CUSW 的取消/恢复位解析则不同。这套白名单与按钮限制应被视为独立于应用插件的最后一道门。生成式 Ram DBC 的地址映射（DAS_6 与按钮来自 Stellantis 共用 DBC 的地址替换）也应纳入构建一致性检查。
硬件与插件验收边界
把 DBC、总线、帧长、安全模式与固件构建作为同一车型插件的版本化契约；Ram 的按钮 bus 2 与普通平台的 bus 0 不可互换。台架应分别验证编码后的计数、CRC、控制位与 panda TX 的接受/拒绝矩阵，尤其覆盖 Pacifica、Ram DT、Ram HD、CUSW 四套布局——软件里有构帧函数，并不意味 HD/CUSW 的 release 固件允许发送。
实车验证前应先只读记录原车的 DAS_6、按钮计数与测得 EPS 扭矩以及 LKAS 故障时序，确认线束与转发路径。本文没有 DBC 动态编码回放、目标板或车辆响应证据，不构成上路控制许可。
常见问题
四套 Chrysler 布局能共用同一套构帧代码吗？
不能。Pacifica/常规 Jeep、Ram DT、Ram HD、Cherokee CUSW 的地址、长度和总线都不同：例如 Ram 的按钮帧走 bus 2，其他走 bus 0；Ram HD 与 CUSW 的 TX/RX 还只在 ALLOW_DEBUG 构建中注册。
为什么控制字段取值在 Ram 和其他平台上不同？
create_lkas_command() 对 Ram 的控制字段编码为 2、其他为 1，对应固件的不同检查：常规固件在 Pacifica 检查 bit 4、在 Ram 检查字段值 2，CUSW 则独立检查 bit 12。字段名相同不等于原始载荷可共用。
按钮计数在 CUSW 上有什么特殊之处？
CUSW 的 update_cusw() 没有像常规分支那样刷新 button_counter，若生成按钮帧会反复使用初始化值加一；这是否触发原车计数拒收仍需台架确认。
软件里有构帧函数就说明 HD/CUSW 可发送吗？
不能这样推断。Ram HD 与 CUSW 的参数层标 dashcamOnly，HD 的 TX/RX 只在 ALLOW_DEBUG 构建中注册；台架应分别验证四套布局的 panda 接受/拒绝矩阵，构帧函数存在不代表 release 固件允许发送。
延伸阅读
- Chrysler panda safety 模式 —— 承接地址白名单、扭矩速率与按钮掩码的固件侧约束。
- Chrysler 固件查询与转向能力身份 —— 车型身份与能力来源的对照。
- Ford CAN 构帧契约 —— 另一车系同类的 DBC/计数/校验构帧流程。
- VW MLB/PQ CAN 构帧契约 —— 对照多平台构帧映射与总线选择。
- CAN 报文解析的「健康位」在说什么 —— 承接计数与校验和之外的总线健康语义。
参考资料
- 项目 02 ——
openpilot-research/CHRYSLER_CAN_FRAME_CONTROL_CONTRACT_DEEP_DIVE.md（取用了四平台发帧矩阵、控制周期与按钮/HUD 时序、控制字段编码差异与 panda 安全门边界）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复