星核火花赛车科技

标签： 安全模式

  • opendbc 车型档案：DBC 结构、指纹与安全模式

    结论：这份档案记录的是 opendbc——一个「用 Python 读写你的车」的开源库与 DBC 仓库集合，目标是让带 LKAS + ACC 的车（多为 2016 年后）都能被读状态、控油门刹车与转向。它最值得记录的不是某一辆车的信号，而是三件工程约定：DBC 预处理器把品牌级与车型级 DBC 合成 _generated 文件；指纹（fingerprinting）用 ECU 固件版本识别车型；安全模型让 panda 上电默认处于 SAFETY_SILENT（总线静默），必须先选安全模式才能发报文。逐条信号定义在各自的 DBC 里，本文只登记文档明确写出的示例与能力。

    车辆与适用范围

    源文档是 opendbc 项目的总说明与其 DBC 目录说明。它覆盖的车辆范围很宽，但支持清单放在被引用的 docs/CARS.md（本快照未包含）。

    项 内容
    车型 多品牌；指向「支持车型清单」与约 300 个车型的公开 CAN 数据集
    年款 / 市场版本 多为 2016 年后具备电子可执行转向、油门、刹车的车（因 LKAS/ACC 普及）
    ECU / 改装状态 通过 comma four 与车型线束接入两条 CAN 总线，其中一条被拆开用于注入本系统的执行报文
    采集跨度 源文档未给出统一跨度；提供约 300 车型的 CAN 片段数据集
    适用范围 仅限被登记支持并可被指纹识别的车型；自定义安全模式需自行编译烧录

    总线与寻址

    项目结构分为四层：opendbc/dbc/（DBC 仓库）、opendbc/can/（从 DBC 解析与构造报文的库）、opendbc/car/（与车辆交互的高层 Python 库）、opendbc/safety/（功能安全）。这些层共同决定「一辆车能被读到什么、能写什么」。

    项 内容
    物理层 由车型线束决定；线束接两条 CAN 总线并拆开其中一条用于注入
    链路层 / 比特率 源文档未给出（随车型 DBC 与适配器）
    寻址方式 源文档未给出；DBC 内以报文与信号为单位
    CAN FD 源文档未提及
    承载硬件 comma four + 车型线束 + panda；自定义安全模式需自行编译固件

    已解码信号

    源文档是项目总说明，不是逐车信号清单。下表登记文档中明确写出、可核对的示例与能力条目：信号示例来自 DBC 目录说明的书写范例，其余来自项目总说明的术语与结构。具体每辆车的完整信号以各自 DBC 为准。

    条目 位置 解码 / 含义 证据
    车速 DBC 信号示例 7|15@0+ (0.00278,0) [0|70] "m/s" dbc/README 书写范例
    加速踏板位置 DBC 信号示例 6|7@0+ (1,0) [0|100] "%"（留出首比特不分配） dbc/README 书写范例
    纵向加速度 报文 490 / LONG_ACCEL 注释原文：轮速导数，噪声大且会吸附到零 dbc/README 注释范例
    转向角 car 库读取 读出转向角等状态 README 首段
    油门 / 刹车 / 转向控制 执行器写入 控制油门、刹车、转向 README 首段
    EV 充电状态 读写目标 目标之一：读取并写入充电状态 README 首段
    门锁开 / 关 读写目标 目标之一：读写信门锁 README 首段
    雷达解析 radar_interface.py 解析（若车辆配备） README「Structure of a port」
    指纹 fingerprints.py ECU 固件版本数据库，用于识别车型 README「Structure of a port」
    安全模式状态 SAFETY_SILENT / SAFETY_ALLOUTPUT 上电默认静默；部分模式在发布固件中被禁用 README「Safety Model」
    DBC 预处理器产物 *_generated 由品牌 DBC + 车型 DBC 合成 dbc/README「DBC file preprocessor」
    公开 CAN 数据集 commaCarSegments 约 300 个车型的 CAN 数据 README「More resources」

    读取方法与注意事项

    接入第一步是硬件：拿到兼容车型的线束（若没有现成的，就从「开发者线束」起，再压接所需连接器），线束会把你接到两条 CAN 总线并暴露注入点。第二步是反向工程：先录一段包含丰富事件（开启 LKAS 与 ACC、把方向盘打到两端等）的 route，再用 cabana 打开分析。

    一个车型端口的代码结构很固定：carstate.py 解析状态、carcontroller.py 输出控制、<brand>can.py 是围绕 DBC 的构造辅助、fingerprints.py 存 ECU 固件版本、interface.py 是高层接口、radar_interface.py 解析雷达、values.py 枚举该品牌车型。

    DBC 层面有一个实用的约定：同一个品牌下不同车型的 DBC 大量重叠，因此项目提供预处理器，从「品牌 DBC + 车型 DBC」生成输出文件（_generated 后缀）。改动了源文件需重新运行生成脚本。文档还给出两条书写规范：注释直接写进 DBC（便于在 cabana 里查看/编辑），以及信号只用最少的比特——若不能确定某比特归属，就把它留空不分配，以避免误读。

    证据等级与边界

    本档案属于项目登记。可核对的是结构、命名、安全模型与文档示例；不支持据此列出任何一辆车的完整信号表，因为逐车定义在被引用但未包含在本快照内的 DBC 与 docs/CARS.md 里。

    三处不能外推。第一，「支持某品牌」不等于「支持某年款某配置」——支持清单以车型为单位，文档用术语明确区分 port（某车型的集成）与 brand（品牌）。第二，安全模式不是默认可用：panda 上电默认 SAFETY_SILENT，且 SAFETY_ALLOUTPUT 之类在发布固件中被禁用，需要自行编译烧录才能用。第三，DBC 示例里的数值（如 0.00278 的 m/s 系数）只是书写范例，不代表任何真实车型的标定。

    关于「安全访问」类问题：本文只整理公开文档登记的结构与安全模型，未涉及安全访问的绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    opendbc 支持哪些车？

    见被引用的支持车型清单：任何具备 LKAS 与 ACC 的车都可能被支持，多为 2016 年后的车型。本快照只含项目总说明与 DBC 目录说明，未包含完整支持清单。

    怎么给一辆新车加支持？

    按「车型端口」的结构来做：先连上硬件并录一段含丰富事件的 route，再用 cabana 反向工程；随后补齐状态解析、控制输出、指纹与车型枚举等文件。相似车型已有支持时，大部分工作可能已经完成。

    panda 上电后能直接发报文吗？

    不能。上电默认处于 SAFETY_SILENT，总线被强制静默；必须先选择一个安全模式才能发送报文。部分模式（如 SAFETY_ALLOUTPUT）在发布固件中被禁用，需要自行编译烧录。

    DBC 里的 _generated 文件是怎么来的？

    由预处理器从「品牌 DBC + 车型 DBC」合成。源文件改动后需重新运行生成脚本，产物放在仓库根目录并带 _generated 后缀。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/README.md（本项目车型档案主来源：项目结构、安全模型、端口结构与反向工程流程）。
    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/dbc/README.md（DBC 目录说明：书写规范、预处理器与示例）。

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

    更新记录

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

  • Tesla 与 Rivian 不能共用一套插件：转角控制 vs 动态扭矩的两条链路

    结论：Tesla 与 Rivian 都属于电动车，但不能共用一套「电动车插件」：Tesla 是转角控制加选择性原车报文转发，Rivian 是动态扭矩加原车 ACC 状态取消，两者在总线拓扑、原车辅助系统与安全策略上均不同。两品牌的纵向参数读取都受 ALLOW_DEBUG 限制，车型/固件识别是执行前提；未识别、无法确认固件或未接线时保持被动。本文为源码静态分析，没有实车、线束、固件构建或 HIL 验证。

    Tesla：转角控制与选择性转发

    CarInterface._get_params() 选择 tesla 安全模式和转角控制，并通过指纹识别缺失 DAS_settings、新 3-bit DAS_steeringControlType 固件；Model X 或旧固件条件可标为 dashcamOnly。雷达支持需要特定 Continental 雷达、DBC 与物理接入 bus 1，不能只凭车型名推断。alpha_long 可写纵向安全参数，但固件实际纵向启用受 ALLOW_DEBUG 限制。

    CarState.update() 与 update_autopark_state() 从 party 与 autopilot-party 两条总线解析车速、踏板、EPS 手握级别/接管、巡航、Autopark、原车 AEB/LKAS，并保留 DAS_control 副本用于取消报文；状态机只在未巡航的上升沿锁存 Autopark。输出侧，CarController.update() 在 hands_on_level >= 3 时停用横向，每 2 帧按速度和车辆模型限制目标转角并定期发送允许转向报文；纵向启用时发送加速度，否则仅构造符合取消语义的 DAS_control。get_safety_CP() 以 Model Y 参数匹配固件转角限制。

    雷达接口读取 40 对 A/B 目标消息，要求索引一致，按状态删除旧目标并报告 CAN、遮挡及传感器故障；无物理雷达/未接线时退回基础接口。tesla_checksum() 实现发送帧校验，但编码器不是发送许可。

    层 关键入口 已核对行为
    安全 RX tesla_rx_hook() 从 EPAS、DI、ESP 采样转角、双车速、油门/制动、巡航与手动接管，识别原车 AEB、LKAS 与 Autopark
    安全 TX tesla_tx_hook() Autopark 锁存时拒绝所有候选；转向检查角度/速率/控制类型；原车 LKAS 运行时禁止主机转向
    纵向限制 tesla_tx_hook() 禁止主机 AEB 事件；原车 AEB 运行时拒绝纵向/取消帧；非纵向模式只允许无执行量的取消
    原车转发 tesla_fwd_hook() 按 Autopark、原车 LKAS、原车 AEB 选择性屏蔽相机/Autopilot 总线的转向与纵向报文
    初始化 tesla_init() 构造不同纵向白名单；先假定 Autopark/Summon 激活，直到状态消息澄清

    需要强调的是，tesla_fwd_hook() 的转发是根据状态选择性屏蔽，不能把「拦截原车控制帧」写成一条恒定规则。tesla_init() 启动先假定 Autopark/Summon 激活，是为降低上电时与原车系统争用而设的保守起点。

    Rivian：动态扭矩与原车 ACC 状态取消

    CarInterface._get_params() 选择 rivian 模式，以 0x321 消息是否存在区分 Gen2，并配置扭矩控制。本快照设 radarUnavailable=True；Gen2 自控纵向默认不开放，docs 可影响能力字段。即使软件选择纵向，固件白名单也仅在 ALLOW_DEBUG 接受参数。输入侧 CarState.update() 从 PT、相机、ADAS 三路解析车速、踏板、转向、巡航、AEB 和故障；Gen2 缺部分车门/安全带 CAN 信号，源码说明依赖原车 ACC 处理，不能等同软件已观测到这些状态。另外 cruiseState.speed 的注释说明当前是检测到的限速替代值，不是已核对的目标巡航速度。

    Rivian 会复制 ACM_lkaHbaCmd、Gen1 触摸方向盘帧，并保留每次 VDM_AdasSts 更新；后者可能一轮收到两帧，所以控制器逐帧重发以保留时序。输出侧，CarController.update() 根据速度插值得到扭矩上限，再按驾驶员扭矩限幅；Gen1 可发送触摸方向盘消息。自控纵向生成加速度帧；原车纵向取消时先发送数帧 available 再发 unavailable 状态，让 ACM 接受切换。

    层 关键入口 已核对行为
    参数 _get_params() 以 0x321 区分 Gen2；本快照设雷达不可用
    编码 riviancan.py create_lka_steering()、create_wheel_touch()、create_longitudinal()、create_adas_status() 复用原车字段并重算校验
    雷达 RadarInterface.update() 有目标解析器，但参数层总设不可用，通常走基础接口；只保留 LRR 或 SRR+LRR 模式有效目标
    安全 RX rivian_rx_hook() 从 ESP 与 VDM 双车速检查失配；CRC/质量位函数对特定地址独立验证
    安全 TX rivian_tx_hook() 转向扭矩设速度相关上限、驾驶员抵消及变化率；纵向加速度另设限值
    模式选择 rivian_init() 原车 ACC 与自控纵向使用不同 TX 白名单；纵向选择仅在 ALLOW_DEBUG 编译块读取

    对硬件与插件化重构的四条约束

    1. 车型/固件识别是执行前提。Tesla 的 steering-control 字段代际、Rivian Gen1/Gen2、雷达物理接入和发布/调试固件选择必须进入受审计的能力清单；不能把 alphaLongitudinalAvailable 直接映射为「允许发送」。
    2. 原车系统仲裁不能外包给普通插件。Tesla 的 Autopark、原车 LKAS/AEB 转发优先级和 Rivian 的 ACC 状态取消时序应与板级安全门、主机状态机共同验证，在不明状态下不放行控制。
    3. 传感器数据必须携带来源与有效性。Tesla/Rivian 的双车速、CAN 质量位和雷达模式不是普通数值字段；新硬件要保留总线、时间戳、计数器/校验及故障标志，防止旧值伪装成实时观测。
    4. 发布固件单独验收。这两个模式本身可在注册表中找到，但纵向参数读取受 ALLOW_DEBUG；不能用调试固件跑通的纵向测试宣称发布版可用。

    把两条链路放在一起看，可以发现共性：软件层「能构造帧」与硬件层「允许发送」始终是两件事，而原车辅助系统（Autopark、LKAS、AEB、ACC）的在场状态会随时改变这条边界。跨品牌流程可参考车型协议总览，板级执行可参考 panda 专题。

    常见问题

    Tesla 与 Rivian 都是电动车，为什么不能共用一套插件？

    因为两者控制类型不同：Tesla 采用转角控制并选择性转发原车报文，Rivian 采用动态扭矩并依赖原车 ACC 状态取消。它们的总线拓扑、原车辅助系统与安全策略都不同，源文档明确「不能共用一套电动车插件」，必须按平台分别声明能力。

    为什么代码里有纵向控制，实车却不一定能启用？

    因为两品牌的纵向参数读取都受 ALLOW_DEBUG 限制：Tesla 的 tesla_longitudinal 仅在 ALLOW_DEBUG 读取安全参数，Rivian 的纵向选择也只在 ALLOW_DEBUG 编译块读取。因此不能用调试固件跑通的纵向测试宣称发布版可用。

    Tesla 雷达支持能否只凭车型名判断？

    不能。源文档指出雷达支持需要特定 Continental 雷达、DBC 与物理接入 bus 1，不能只凭车型名推断；Rivian 侧参数层在本快照总设 radarUnavailable=True，即使代码有目标解析器，也不会据此宣称实车雷达链已启用。

    Rivian 的原车纵向取消为什么要先发 available 再发 unavailable？

    源文档说明这是为了让 ACM 接受切换：取消时先发送数帧 available 再发 unavailable 状态。这属于原车系统仲裁时序，应与板级安全门、主机状态机共同验证，而不是当作普通的功能开关。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/TESLA_RIVIAN_DEEP_DIVE.md（取用了 Tesla/Rivian 的参数、输入、输出、安全 RX/TX、转发与初始化行为，以及四条插件化约束）。
    • 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（仅用于确认两品牌目录与跨品牌安全主链路的总体位置）。

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

    更新记录

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

  • 大众四平台加斯巴鲁两代：一套安全模式为什么不能按品牌复用

    结论：品牌名不是能力边界。同一家车厂的不同平台在安全模式、报文地址、校验方式和控制类型上差异很大：大众至少要分成 MQB、MEB、MLB、PQ 四套，斯巴鲁至少要分成 Global Gen1/Gen2 与 Preglobal；插件能力必须按平台 + 固件 + 接线位置 + 总线拓扑 + 控制类型声明，不能按品牌名继承。而且该快照把大众 MLB/PQ 与斯巴鲁 Preglobal 放在 ALLOW_DEBUG 条件下，不能因源码实现存在就认定发布固件支持执行。以下基于源码快照 c8fb906 与固定版本 opendbc_repo 的静态阅读，未接目标 ECU、未验证具体年款。

    大众：四套平台不能合并

    参数层 CarInterface._get_params() 会按 PQ、MLB、MEB、默认 MQB 选择安全模式；变速箱、网关/前相机接入、盲区监测等由指纹决定。MEB 使用曲率控制且配置自控纵向；非 MEB 的 alphaLongitudinalAvailable 与 alpha_long 路径须结合实际发布配置判断，不能只看能力字段放行。另外，若 PT bus 编号不在首组，还会前置 noOutput 安全配置。

    层 关键组件 源码行为
    输入 CarState.update() 分发到 update_mqb/pq/meb/mlb()；update_hca_state() 与 update_acc_fault() 是故障状态收敛点。
    控制 CarController.update() MEB 将目标曲率与测量曲率差补偿后限幅，控制转向功率逐步升降；其余平台按驾驶员扭矩限制目标扭矩。
    MEB 停车 MebLongStateMachine.update() 协调 ACC 状态、保持/起步/释放坡道与退出斜坡，避免停车保持直接切到无请求；它不是通用纵向 PID。
    雷达 RadarInterface.update() MEB 网关接法读取相机发布的过滤后轨迹，不是原始雷达点；校验消息、状态与重复 ID，维护目标生命周期。

    大众固件模式差异

    把四套平台的固件行为并排看，差异集中在校验、TX 白名单与纵向编译门上：

    模式 初始化、RX、TX 必须保留的区别
    MQB init()、rx()、tx() 原车 ACC 与自控纵向用不同 TX 白名单；纵向固件标志仅在 ALLOW_DEBUG 分支读取。RX 从 ESP、EPS、TSK、油门、刹车和按钮更新状态。
    MEB init()、rx()、tx() Gen2 的替代 CRC 与消息长度单独选择；TX 校验曲率、转向功率、ACC 加速度，并限制停车保持与起步请求。
    MLB init()、rx()、tx() TX 表只含转向、HUD 与原车 ACC 按钮，没有纵向加速/制动帧；六组 RX 全部显式忽略 checksum，但检查计数器。
    PQ init()、rx()、tx() 使用不同地址、XOR 校验和与计数器位置；纵向标志同样有 ALLOW_DEBUG 编译门。

    MLB 与 PQ 的细节很典型：MLB 的 TX 表根本不发纵向帧，且源码保留着校验 TODO，不能据「通用大众模式」推断它的校验能力；PQ 用 XOR 校验和与不同计数器位置，原车 ACC 与自控纵向的使能事件也不同。MEB 的停车保持即使 ACC 未激活仍可能影响车辆，因此必须维持独立固件门。

    斯巴鲁：Global 与 Preglobal

    参数层 CarInterface._get_params() 对 Preglobal 选 subaruPreglobal，其余选 subaru；Global Gen2 会写入安全参数。Preglobal、角度 LKAS、Hybrid 被标为 dashcamOnly，而此快照显式将 alphaLongitudinalAvailable=False，所以普通参数路径不会启用自控纵向——相关代码仍存在，不代表当前可用。

    层 关键组件 源码行为
    输入 CarState.update() 按 Gen2、Hybrid、Preglobal、角度 LKAS 改变刹车、轮速、巡航、转角来源；保留原车 EyeSight 报文副本供控制器改写。
    输出 CarController.update() 软件侧按驾驶员扭矩限幅；STEER_RATE_LIMITED 时在高转向速率下周期性切断请求以避免 EPS 故障。
    构帧 subarucan.py Global 与 Preglobal 的转向、EyeSight Distance、HUD 及校验和函数分开；不能把同名逻辑当作相同总线或相同编码。
    Global 固件 subaru_init()、subaru_rx_hook()、subaru_tx_hook() Gen2 的车速/制动/巡航来自 alt bus，Gen1 来自主总线；ES_Distance 仅准许取消且油门值必须为 inactive。
    Preglobal 固件 subaru_preglobal_init()、rx()、tx() 另一套报文地址与驾驶员扭矩符号，特定车型可反转扭矩方向；RX 对计数器/校验和的忽略有源码 TODO。

    Global 的纵向限值常量虽然存在，但当前 TX 路径没有放行纵向控制；Preglobal 的 TX 白名单也含 ES_Distance，按钮行为需按平台测试核对。ECU 生命周期上，只有 DISABLE_EYESIGHT 标志才会执行 EyeSight 通信控制，这条分支不能当作默认运行路径。

    对硬件与插件化的约束

    1. 插件能力必须按平台、固件、接线位置、总线拓扑与控制类型声明，不按品牌名继承。MEB 曲率控制、MQB/PQ/MLB 扭矩控制以及斯巴鲁 Global/Preglobal 不能共用一套执行器协议配置。
    2. 固件安全模式仍是独立硬件信任边界：插件可选择经审计的模式与参数，但不得改写 TX 白名单、CRC、转向/加速度限值，也不能以主机软件状态替代固件 RX 检查。
    3. 大众 MEB 的停车保持/起步是动作语义，不只是加速度数字；应在插件契约中显式建模，并用故障注入验证失联、错误 CRC、错误 bus、状态迁移及退出斜坡。
    4. 斯巴鲁 Hybrid、角度 LKAS、Preglobal 与大众 PQ/MLB 在源码中有待验证或发布限制，应保持被动，直到目标车的 DBC、帧重放、台架与封闭场地证据齐全。

    常见问题

    能不能写一套代码同时适配大众所有车型？

    不能。大众至少分 MQB、MEB、MLB、PQ 四套平台，安全模式、TX 白名单、校验方式与控制类型都不同。参数层必须按平台选择，MEB 用曲率控制，其余用扭矩控制，不能合并。

    源码里实现了某平台的纵向控制，就代表能用吗？

    不代表。此快照把大众 MLB/PQ 与斯巴鲁 Preglobal 放在 ALLOW_DEBUG 条件下，斯巴鲁还显式将 alphaLongitudinalAvailable=False。源码实现存在不等于发布固件支持执行。

    为什么 MLB 模式不能按「大众通用」假设校验能力？

    因为 MLB 的六组 RX 全部显式忽略 checksum、只检查计数器，源码还保留着校验 TODO。不能据通用大众模式推断它具备同样的完整性校验。

    斯巴鲁 Global 和 Preglobal 的报文可以复用吗？

    不可以。两者的转向、EyeSight Distance、HUD 以及校验和函数分开实现，Preglobal 还使用另一套报文地址与驾驶员扭矩符号、特定车型可反转扭矩方向。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/VW_SUBARU_DEEP_DIVE.md（大众与斯巴鲁车型实现专题，含源码行号索引）
    • 项目 02 —— openpilot-research/VOLKSWAGEN_MEB_PANDA_SAFETY_DEEP_DIVE.md（源文档指向的 MEB 安全钩子逐函数专题）
    • 项目 02 —— openpilot-research/SUBARU_GLOBAL_PANDA_SAFETY_DEEP_DIVE.md（源文档指向的斯巴鲁 Global 安全专题）

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

    更新记录

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

  • Mazda 52/45 迟滞与 Nissan 12 帧平均：三品牌横控差异

    结论：Chrysler、Nissan、Mazda 三家都保留了原车的纵向巡航控制，但横向控制、取消策略与安全模式差异显著，不能抽象成同一套报文插件。Nissan 用后轮速度做安全侧转角限制、驾驶员扭矩按 12 帧平均；Mazda 的最低价速度门用 52/45 km/h 上/下行迟滞并等待 LKAS_BLOCK 清除；Chrysler 的 Ram HD 与 CUSW 被标为 dashcamOnly，CUSW 还使用独立的 chryslerCusw 模式且固件注册仅在 ALLOW_DEBUG。本文为对本地 source/ 与固定版本 opendbc_repo 的静态阅读，未运行测试、未连接实板、未验证任何年款。

    Chrysler：多平台 EPS 电机扭矩

    CarInterface._get_params() 根据 Pacifica/Jeep、Ram DT、Ram HD、CUSW 选择安全模式与参数；Ram HD、CUSW 标为 dashcamOnly，CUSW 使用独立的 chryslerCusw 模式，其固件注册仅存在于 ALLOW_DEBUG 编译块。此快照中雷达解析接口虽存在，但始终 radarUnavailable=True。EPS 固件/车型还会影响最低转向速度。

    CarState.update() 与 update_cusw() 使用不同的状态映射，Ram 的 ACC 状态来自相机总线。CarController.update() 在软件侧按 EPS 测得扭矩限幅，按平台采用最低转向速度迟滞，并在 LKAS 控制位下降后等待一段帧数再重新使能，以避免 EPS 故障。chryslercan.py 里的构帧函数各自编码仪表、转向与巡航按钮，车型报文与 checksum 不能仅靠品牌名复用。

    层 关键入口 已核对行为
    参数 CarInterface._get_params() 按 Pacifica/Jeep、Ram DT、Ram HD、CUSW 选安全模式；Ram HD、CUSW 标 dashcamOnly；CUSW 注册仅 ALLOW_DEBUG
    输入 CarState.update() / update_cusw() 主流平台与 CUSW 用不同状态映射；Ram 的 ACC 状态来自相机总线
    输出 CarController.update() 按 EPS 测得扭矩限幅，采用最低转向速度迟滞，LKAS 位下降后等一段帧数再重新使能
    构帧 chryslercan.py create_lkas_hud()、create_lkas_command()、create_cruise_buttons() 分别编码
    固件 RX/TX chrysler_rx_hook() / chrysler_tx_hook() / chrysler_init() Pacifica/Jeep 与 Ram DT/HD 分别设扭矩、变化率与电机扭矩误差限值；按钮只允许取消或恢复
    CUSW 固件 chrysler_cusw_init() / rx() / tx() 另套地址、RX 表、扭矩限值与按钮位定义；注释仍记载转向故障待解决

    验证入口是 Chrysler 与 CUSW 的安全测试以及通用车型接口测试；这三品牌各自目录下尚无独立车型测试套件，本次也未运行。CUSW 即使源码可编译，其安全模式注册也仅存在于调试固件，注释仍记载转向故障待解决，不可视为量产可用。

    Nissan：转角控制与车型专属取消

    Nissan 侧选择 nissan 安全模式，采用转角控制与原车纵向；Altima 通过安全参数切换 EPS 及相关状态报文总线。此快照中雷达不可用，但不能据此认定原车 ADAS 的内部感知已被软件接管。

    CarState.update() 里，Altima 与其他车型的 PT/相机 bus 对调；后轮速度用于安全侧转角限制的原始速度，四轮均值用于平滑估计，驾驶员扭矩按 12 帧平均以避免误报。CarController.update() 先用一阶滤波平滑低速大转角指令，再按速度/实际角度限制目标，驾驶员施力时降低 EPS 可用扭矩上限。

    取消策略是 Nissan 最不能包装成通用插件的部分：Rogue/X-Trail/Altima 发送 CRUISE_THROTTLE 取消，Leaf 则用 create_cancel_msg() 把 CANCEL_SEATBELT 置位，让 ProPILOT 将其解释为安全带未系而退出，源码说明会伴随蜂鸣和警告——这是明确的 HMI/安全语义。

    层 关键入口 已核对行为
    参数 CarInterface._get_params() 选 nissan 安全模式、转角控制、原车纵向；Altima 切换 EPS 相关报文总线
    输入 CarState.update() / get_can_parsers() Altima 与其余车型 PT/相机 bus 对调；后轮速度用于安全侧转角限制；驾驶员扭矩按 12 帧平均
    输出 CarController.update() 低速大转角先一阶滤波，再按速度/实际角度限幅；驾驶员施力时降低 EPS 可用扭矩上限
    Leaf 取消 create_cancel_msg() 置 CANCEL_SEATBELT 使 ProPILOT 解释为安全带未系退出，源码说明伴随蜂鸣与警告
    固件 RX/TX nissan_rx_hook() / nissan_tx_hook() / nissan_init() 转角幅度与速度相关变化率由固件检查；0x20b 按钮帧只允许取消位；Leaf 0x280 在白名单但无逐位附加约束

    Nissan 的 RX 表显式忽略 checksum/counter，因此不能声称该路径有独立的报文完整性检验。此外，MCU 的 RX 变体锁定、Altima 总线、0x20B 按钮掩码与 Leaf 0x280 载荷边界都需按具体 DBC 与测试核对，不能只凭品牌推断。

    Mazda：扭矩控制与速度迟滞

    Mazda 选择 mazda 安全模式与扭矩调校；此快照仅 CX-5 2022、CX-9 2021 不标 dashcamOnly，部分车型有最低转向车速门。CarState.update() 解析四轮速度、原车巡航、踏板、驾驶员/EPS 扭矩及相机 LKAS 状态。

    最低速度门使用 52/45 km/h 上/下行迟滞，并等待 LKAS_BLOCK 清除；低速告警与临时转向故障由状态逻辑产生。CarController.update() 按驾驶员扭矩限幅 LKAS，踩刹车后延迟发取消以规避与原车巡航主开关的竞态，停车恢复按间隔发 Resume。mazdacan.py 的构帧函数使用不同来源与计数器，需要保持相机/主总线消息时序。

    层 关键入口 已核对行为
    参数 CarInterface._get_params() 选 mazda 安全模式与扭矩调校；仅 CX-5 2022、CX-9 2021 不标 dashcamOnly
    输入 CarState.update() 最低速度门用 52/45 km/h 上/下行迟滞，并等待 LKAS_BLOCK 清除
    输出 CarController.update() 按驾驶员扭矩限幅 LKAS；踩刹车后延迟发取消；停车恢复按间隔发 Resume
    构帧 mazdacan.py create_steering_control()、create_alert_command()、create_button_cmd() 来源与计数器各异
    固件 RX/TX mazda_rx_hook() / mazda_tx_hook() / mazda_init() LKAS 扭矩受最大值、速率、驾驶员反向扭矩约束；未使能时按钮帧只能是取消

    Mazda 的 RX 表忽略 checksum/counter/质量位，同样不能声称有独立报文完整性检验。

    三者共用同一套通用边界：指纹 DBC、CarState、CarController 与 panda 的 RX/TX 钩子，但具体报文与状态各自实现。验证入口包括 Chrysler、CUSW、Nissan、Mazda 各自的 panda 安全测试以及通用车型接口测试；这些测试覆盖按钮、平台扭矩与部分总线变体，本次均未运行。

    对硬件与插件化的含义

    1. 车型契约必须区分 Pacifica/Ram/CUSW、Altima/Leaf、CX-5/CX-9 的报文地址、总线、控制类型、计数器与发布状态，不能只给出 brand 和 canfd 两个字段。
    2. 调试固件的 Chrysler CUSW 与 Ram HD 路径、Nissan Leaf 的安全带模拟取消、Mazda 的刹车后取消延迟，都应列为需要人机交互与实车故障分析的高风险策略，不开放为通用插件选项。
    3. 软件限幅、倒车/低速/停用状态和原车辅助系统冲突，必须与 panda 的 TX 白名单和 RX 状态独立核对；缺少 checksum/counter 的 RX 路径还需额外评估错误帧、重放与总线时序失效。
    4. 目标车型应先做只读采集、DBC/总线回放、错误帧注入、台架与封闭场地验证；本篇不是上车许可。

    常见问题

    三个品牌能共用一套转向控制插件吗？

    不能。三者的报文地址、总线、控制类型（Chrysler 为 EPS 电机扭矩、Nissan 为转角、Mazda 为扭矩）与计数器都不同，且取消策略各异，因此不能抽象成同一套报文插件。

    Nissan Leaf 是怎么取消巡航的？

    它不用普通取消按钮，而是用 create_cancel_msg() 把 CANCEL_SEATBELT 置位，让 ProPILOT 将其解释为安全带未系而退出，源码说明会伴随蜂鸣和警告，具有明确 HMI/安全语义。

    Mazda 的最低转向速度门是多少？

    源文档给出的最低速度门使用 52/45 km/h 上/下行迟滞，并等待 LKAS_BLOCK 清除后才允许。该阈值出自源文档，本文未在实车验证。

    为什么说这些品牌的 RX 路径没有独立完整性校验？

    Nissan 与 Mazda 的 RX 表都显式忽略 checksum/counter（Mazda 还忽略质量位），Chrysler 的 CUSW 也是另套定义。缺少这些字段意味着错误帧、重放与总线时序失效需要额外评估。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CHRYSLER_NISSAN_MAZDA_DEEP_DIVE.md（三品牌参数、输入/输出、构帧与固件 RX/TX 对照）
    • 项目 02 —— openpilot-research/CHRYSLER_PANDA_SAFETY_MODE_DEEP_DIVE.md（源文档指向的 Chrysler panda 安全函数级专题）
    • 项目 02 —— openpilot-research/PANDA_BOARD_DEEP_DIVE.md（源文档指向的板级执行专题）

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

    更新记录

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