星核火花赛车科技

标签： CAN总线

  • 车型协议接入实践：从指纹识别到安全固件的最低契约

    结论：接入一个新车型，最低工作集是走完一条固定骨架：安全板接收 CAN → 主机车况网关 → 指纹与 ECU 固件匹配 → 生成车型参数与安全模式 → DBC 解析出车况 → 控制器生成候选发送帧 → 回包编码 → 主机到板传输 → 板端安全钩子放行。公开资料在固定快照中核对了 17 个车型实现目录，但「实现入口存在」并不等于已完成某品牌全部平台与年款的报文与安全审计。接入的关键判断有三条：未识别 / 模糊匹配默认被动；品牌目录不能代替平台差异验证；含 ALLOW_DEBUG 条件的模式不等于发布固件可启用执行。

    车型实现的共同骨架

    公开资料显示，车型实现的加载与运行是一条固定链路，可按下面顺序理解：

    1. 安全板接收 CAN 帧，交给主机车况网关；
    2. 网关做指纹识别与 ECU 固件匹配，形成车型参数与安全配置；
    3. DBC 解析器把原始帧解析为车型车况；
    4. 控制器消费车况，生成控制意图；
    5. 车型控制器把控制意图编码为候选发送帧；
    6. 候选帧经主机发送线程下发，最终由安全固件的发送钩子决定是否放行。

    两个结构性事实需要注意：其一，车型接口由一份品牌清单静态加载，不是运行时扫描任意插件目录；其二，每个品牌常规包含车型枚举与物理配置、车型参数与安全模式、接收帧到车况、控制意图到候选帧这几组模块，部分品牌另有雷达接口。这些模块的职责边界，就是后续插件化时「能力契约」的划分依据。

    十七个品牌目录与平台差异

    固定快照中核对到的车型实现入口如下。每类的接口、状态、控制器与配置模块均已在目录中确认存在，「雷达接口」表示另有雷达相关模块。此表是开发入口索引，不能替代平台差异验证：

    品牌目录 额外雷达接口 平台/安全差异 当前深度
    body 无 非汽车双轮平台 链路已追踪
    byd 无 仅调试安全模式 单车型转角链路已追踪
    chrysler 有 多车型链 主要链路已追踪
    ford 有 经典 CAN 与 CAN FD 主要链路已追踪
    gm 有 ASC M / 相机若干链路 主要链路已追踪
    honda 有 两套转向实现 主要链路已追踪
    hyundai 有 经典 CAN 与 CAN FD 主要链路已追踪
    mazda 无 扭矩/速度迟滞 主要链路已追踪
    mg 无 仅调试安全模式 扭矩链路已追踪
    mock 无 空发送回退 非实车回退已追踪
    nissan 无 转角 / 车型取消 主要链路已追踪
    psa 无 三总线，仅调试安全模式 转角链路已追踪
    rivian 有 两代硬件 主要链路已追踪
    subaru 无 含 preglobal 分支 主要链路已追踪
    tesla 有 转角 / 原车转发 主要链路已追踪
    toyota 有 逐层样本 已逐层追踪
    volkswagen 有 多平台安全模式 主要链路已追踪

    特别要注意：安全钩子注册表把若干模式（第三方品牌、部分平台）置于 ALLOW_DEBUG 条件下；实现目录与测试存在，并不表示发布固件可启用执行。目标车型还须以具体平台与固件版本逐一核对。

    启动阶段的五道控制门

    车型识别与启动阶段依次经过多道门，每道门都可能让系统停留在「被动」状态：

    入口 行为
    CAN 指纹 在总线上按 CAN 地址与数据长度逐步排除候选；超过限定帧数后停止，不保证未知车型能识别
    指纹确认 优先查询 VIN、ECU 存在性及固件版本，再收集 CAN 指纹；单一固件候选可覆盖结果，环境变量可强制指纹（仅用于受控开发）
    固件匹配 先精确固件匹配，失败再尝试模糊 / 品牌自定义匹配，返回是否精确及候选集
    车型获取 无候选时回退空模型；用候选接口生成车型参数并保留 VIN、固件、指纹来源及模糊匹配标记
    控制就绪 仅在进程初始化、非被动、控制请求存活的路径调用车型编码形成候选发送帧

    这里要分清几种状态：空模型、被动、仅仪表记录互不相等，但都不能作为未知车型开始执行的理由；用户配置或环境变量强制指纹也不构成车辆协议兼容性验证。

    DBC 编解码的函数级语义

    解析与编码是两个方向，公开资料给出的关键语义如下：

    入口 关键含义
    DBC 加载 加载消息、信号、枚举；按 DBC 系列选择校验算法
    取值 按大小端与位提取原始整数；符号、倍率和偏移另行处理
    解析 解码信号、计算校验和与计数器；失败返回失败，不把这一帧的部分值提交
    计数器 错误计数达阈值则拒绝，有效后逐步恢复
    整帧解析 仅接收指定总线与已注册地址，更新值与时间戳，返回成功解析的地址集
    健康位 检查最近成功时间、计数器与缺失次数；总线空窗单独观察
    编码 反向应用倍率/偏移，自动补计数器与校验和；未知信号仅记录错误并跳过
    组帧 返回地址、编码后数据与总线号；未命中消息名时返回空数据

    最常见误用是只看数值而忽略健康位：解析器保存的是最近一次成功值，若忽略有效位与总线健康，就可能把旧值当成当前观测；编码器只是协议编码，不是转向扭矩或加速度安全门。

    样本三层与插件化最低契约

    以样本车型看，三层结构最清楚：

    层 已核对决策
    车型能力 设定安全模式与助力比例；按平台/固件选择扭矩或角度控制、制动地址、加密、原车/自控纵向能力
    ECU 变更 特定实验纵向模式会执行 ECU 通信控制，退出时尝试恢复；属车型专属且需单独台架验证
    输入状态 区分动力、相机总线与平台标志，解析车门、安全带、制动/油门、轮速故障、转角与驾驶员扭矩
    控制器 按驾驶员扭矩与助力限制转向请求；按提醒、纵向能力、车速与加密分支生成候选帧
    固件接收 从指定报文维护扭矩、角度、巡航、油门、刹车及车速样本
    固件发送 检查转向扭矩/角度速率、纵向加速度、AEB 与诊断报文

    从这条样本链可以抽出面向插件化的五条最低契约：

    1. 车型插件声明平台、ECU 固件范围、DBC 版本、总线拓扑、能力位、车型参数与安全模式；未识别 / 模糊匹配默认被动；
    2. 解码插件输出值、时间戳、来源、校验 / 计数器 / 超时状态，不能把上次成功值伪装成当前有效观测；
    3. 控制插件只产生结构化控制请求或候选帧，不能自行改固件白名单、安全模式或绕过车况网关；
    4. 硬件安全控制器独立于应用 CPU 实现收发与转发限制、心跳失效回退与板级故障处理；
    5. 每个目标车型逐一建立解析、编码、固件安全和回放基线；品牌目录索引不是一套通用线束或固件配置规格。

    常见问题

    有了某个品牌的车型目录，就能接这个品牌的全部车型吗？

    不能。品牌目录只证明实现入口存在，不能代替平台差异验证。目标车型须以具体平台与固件版本逐一核对；同一品牌可能同时存在经典 CAN 与 CAN FD 等不同分支。

    未知车型会怎样处理？

    无候选时会回退到空模型；未识别或模糊匹配默认被动。被动、仅仪表记录与空模型互不相等，但都不能作为未知车型开始执行的理由。

    CAN 解析出的值可以直接用吗？

    不能只看数值。解析器保存的是最近一次成功值，必须同时检查有效位、时间戳与总线健康，否则会把旧值误当成当前观测。

    安全模式在调试条件下可用，是否代表能上车执行？

    不代表。若干模式被置于 ALLOW_DEBUG 条件下，实现目录与测试存在并不表示发布固件可启用执行；实际执行还需台架与受控场地验证。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（取用车型实现骨架、17 个品牌目录索引、启动控制门、DBC 编解码语义、样本三层结构与插件化最低契约）。

    说明：本文为对固定源码快照（主仓库提交 c8fb906 及固定的车型协议与安全固件归档）的静态阅读整理，未接入目标车型、线束或安全板，未运行完整测试套件。文中所有入口、状态与目录均出自源文档，样本车型仅为实现链路示例，不是对任何年款或配置的实车适用性声明。

    更新记录

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

  • 菲亚特 Fiorino 的 B-CAN：50 kbps 上的车速、转速与油量

    结论：菲亚特 Fiorino（Fiat Mini 平台）的 B-CAN 是 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层、50 kbps、大端（Motorola，MSB 在前）。文档记录了一个紧凑的帧矩阵：车速、转速、冷却液温度、喷油量、续航、油量等都能从几条固定 ID 上被动读到。这套解码背后有一个现实动机——Fiat Mini 平台的仪表存在一个出厂软件缺陷，总里程一到 399999 公里就永久冻结；作者因此让 ESP32 自行计算并存储里程，且系统随车通过了西班牙官方的 ITV 检验。边界：帧矩阵按平台记录，具体到某一辆车仍需核对，任何改动都应先在台架确认。

    本文整理自该项目的 CAN 矩阵文档与工程说明。文档把帧矩阵定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，本文保留这一来源限定。

    车辆与适用范围

    项目以一辆 Fiat Fiorino 为对象，用一块 ESP32 加自定义载板替换原厂中央单色液晶，读 B-CAN 实时遥测并渲染自定义界面。文档提到同类平台的车型（Fiorino、Grande Punto、Alfa Romeo MiTo）共享这套仪表缺陷，因此帧矩阵按 Fiat Mini 平台陈述。

    项 内容
    车型 菲亚特 Fiorino（Fiat Mini 平台；同平台另有 Grande Punto、Alfa Romeo MiTo）
    年款 / 市场版本 源文档未给出具体年款；项目语境为西班牙市场（需通过 ITV 检验）
    ECU / 改装状态 用 ESP32 + 自定义载板替换原厂中央单色液晶；原厂仪表仍作为被替换对象存在
    采集跨度 源文档未给出；随车通过了西班牙官方 ITV 检验
    适用范围 按 Fiat Mini 平台记录的帧矩阵；逐车细节仍需核对

    总线与寻址

    文档把 B-CAN 定义为 CAN 2.0B、29 位扩展标识符，物理层是低速容错 CAN（ISO 11898-3），50 kbps，字节序为大端（Motorola，MSB 先）。接入侧使用 TJA1055T（低速容错 B-CAN 收发器），配合电平转换芯片适配 3.3 V / 5 V。

    项 内容
    物理层 低速容错 CAN（ISO 11898-3），50 kbps
    链路层 CAN 2.0B，29 位扩展标识符
    字节序 大端（Motorola，MSB 在前）
    收发器 TJA1055T 低速容错 B-CAN 收发器 + 电平转换
    CAN FD 源文档未提及

    已解码信号

    下表逐条取自文档帧矩阵。解码式中 B_n 表示第 n 个字节，位移写法保留原文。

    信号 位置（ID / 字节） 解码 证据
    发动机转速 0x04214001 字节 6 Byte[6] × 32（32 转/分/位） 文档帧矩阵
    喷油量 0x04214001 字节 4、5 ((B4 左移 8) 或 B5) ÷ 100.0，单位 mm³/行程 文档帧矩阵
    发动机温度 0x04214001 字节 3 B3 − 40，摄氏度 文档帧矩阵
    燃油消耗（推导） 0x04214001 字节 3 至 6 (raw_iq × RPM × 1.2) ÷ 1e6，升/小时（按 4 缸 4 冲程推导） 文档帧矩阵（派生量）
    总里程 0x0C014003 字节 1 至 3 (B1 左移 16) 或 (B2 左移 8) 或 B3，公里 文档帧矩阵；不采用，见下（399999 公里后冻结）
    续航 0x0C014003 字节 4、5 ((B4 与 0x03) 左移 8) 或 B5（字节 4 需掩码） 文档帧矩阵
    车速 0x04394000 字节 0、1 ((B0 左移 8) 或 B1) × 0.0625，km/h 文档帧矩阵
    燃油液位 0x06214000 字节 5 Byte[5]，直接取百分比 文档帧矩阵

    读取方法与注意事项

    先查 DLC，再取载荷。文档把「提取载荷前必须检查 DLC」列为安全要求，用于防止缓冲区越界读。这一条对 0x04214001 这类大端多字节字段尤其重要。

    0x0C014003 是复用帧。文档说明这一帧同时承载「总里程」和「续航」两组信息（多路复用），解析时要按同一帧内的不同字节段分别取用，不能只当一种含义。

    里程为何要自己算。这是本项目的核心动机：Fiat Mini 平台的仪表存在出厂缺陷，总里程到达 399999 公里后永久冻结、不再记录。文档因此让单片机从 B-CAN 实时遥测独立计算并安全存储总里程，并把它写入外部的 AT24C32 EEPROM（经 I2C，配合 DS3231 实时时钟），以避免磨损 ESP32 内部闪存。文档记录：该车带着这套系统通过了西班牙官方的 ITV 检验，作为可靠性的一次实证。

    两条核对手段。固件提供「被动 CAN ASCII 流式输出」（用一个编译开关打开），按标准 LAWICEL/SLCAN 格式（如 t1238…）把原始 B-CAN 帧输出到串口，便于用任意串口终端或自写脚本记录；界面上还有硬件状态浮层，用于提示 EEPROM 状态、熄火保存与内存损坏错误。

    证据等级与边界

    文档给出的帧矩阵被明确定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，属于社区工程结果，而不是厂家规格。其中「燃油消耗」被文档自述为派生量（由喷油量与转速按 4 缸 4 冲程推导），而非总线上直接广播的字段；「总里程」虽可从帧中解出，但文档明确不采用该值，原因是它在 399999 公里后冻结。

    验证层面有两处相对硬的证据：其一，该车带着这套嵌入式方案通过了西班牙官方的 ITV 检验，文档把它作为「可靠且准确」的实证；其二，项目提供了原始 B-CAN 帧的被动流式输出，便于独立复核。但文档未给出逐信号置信度，也未绑定具体年款与配置。

    因此边界是：帧矩阵按 Fiat Mini 平台陈述，同平台车型（Fiorino、Grande Punto、MiTo）可能共享，但具体到某一辆车、某一年的配置仍需逐车核对；更换仪表属对车辆电气系统的改动，任何操作都应在台架或合规前提下进行。

    常见问题

    Fiorino 的 B-CAN 是什么协议和速率？

    文档定义为 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层，速率 50 kbps，字节序为大端（Motorola，MSB 在前）。收发器用的是低速容错型号 TJA1055T。

    为什么不用总线上读到的总里程？

    因为 Fiat Mini 平台的仪表存在出厂缺陷：总里程到达 399999 公里后永久冻结、不再记录。项目因此让 ESP32 从实时遥测独立计算总里程，并写入外部 EEPROM 保存，而不是直接采信被冻结的广播值。

    车速和转速的解码式分别是什么？

    车速在 0x04394000 字节 0、1：((B0 左移 8) 或 B1) × 0.0625 km/h。转速在 0x04214001 字节 6：Byte[6] × 32，分辨率 32 转/分。

    解析时有哪些必须注意的工程细节？

    三点：提取载荷前先检查 DLC，防止越界读；0x0C014003 是复用帧，同时承载总里程与续航，要分段取用；全程按大端解析多字节字段。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/docs/Can_Matrix.md（本项目车型档案主来源，取用了总线规格与帧矩阵）。
    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/README.md（取用了 399999 公里冻结背景、硬件选型与 ITV 检验结论）。

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

    更新记录

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

  • 比亚迪 BYD 全车系 DBC 档案：7 个候选文件的报文规模

    结论：这份档案记录的不是一台车，而是一组面向比亚迪（BYD）与吉利车型的候选 DBC 文件：来源快照保留 7 个字节互不相同的 DBC，报文数从 4 条到 124 条不等。它的价值在于给「国产新能源整车的报文规模」提供了一份可核对的清单，但来源说明明确指出——项目文档里那张宽泛的车型列表并不能确立每个 DBC 对每种车型的适配，很多字段还用了占位名，且仓库快照里找不到许可文件（README 只有 MIT 徽章）。因此本文只登记文件与规模，不做「某款车某信号」的断言。下述内容仅限源文档记录的这一批候选文件。

    车辆与适用范围

    源文档是一个开源辅助驾驶适配项目的说明。项目自述针对「比亚迪全系与吉利」做适配，并提供了实车 DBC 报文数据库；但来源说明的措辞更谨慎：这些是「候选的逆向定义」，上游 README 的宽泛车型列表不构成逐车型的已核验适配。车型代号在 README 里列得很细（汉 DM/EV、唐 DM-i/DM-p、宋 PLUS/Pro/L、秦 PLUS/L、元 PLUS、海豹、护卫舰、腾势 D9 等），但它们属于文档级声称。

    项 内容
    车型范围 项目自述覆盖比亚迪（汉 / 唐 / 宋 / 秦 / 元 / 海豹 / 驱逐舰 / 腾势）与吉利（缤越）多款车型
    年款 / 市场版本 README 按年款列出代号（如 2020 汉 DM、2022 汉 DM-i、2022 元 PLUS / ATTO 3）；来源说明未确立逐车型适配
    ECU / 改装状态 面向车机端开源辅助驾驶项目；包含 EPS、ADAS、RADAR、CAMERA、BCM、VCU、BMS 等节点的报文
    采集跨度 快照保留 7 个字节互不相同的 DBC；上游还以嵌套目录重复了其中几个，快照已省略重复项
    适用范围 仅限这一批候选文件；跨车型、跨年款适用性未验证，且部分文件用占位名

    总线与寻址

    来源说明没有给出比特率、寻址位数这类总线参数——它登记的对象是 DBC 文件本身，而非一次抓包。因此本文按「文档级」记录：能确定的只有 DBC 这一载体、报文数与文件来源位置；总线物理参数应视为源文档未提供。

    项 内容
    载体 DBC 文件（报文 + 信号的数据库描述），非原始抓包
    物理层 / 比特率 源文档未提供
    寻址方式 源文档未提供 11 位 / 29 位说明
    CAN FD 源文档未提供
    节点覆盖（README 声称） EPS 转向、ADAS 辅助驾驶、RADAR 雷达、CAMERA 前视相机、BCM 车身、VCU 整车控制、BMS 电池

    已解码信号与文件清单

    由于主素材给的是 DBC 文件而非成品信号表，下表按「文件 / 条目」登记规模与来源说明原样保留的注意事项，不代填任何信号名或缩放。

    条目 上游位置 规模 / 内容 证据 / 注意
    byd_han_dmev_2020.dbc BYD_Files/opendbc/dbc/ 16 条报文 与已归档的另一副本不同：改动两个踏板缩放、省去 4 条报文
    byd_generic_pt.dbc byd2/ 19 条报文 通用动力总成候选文件
    byd_tangdm_radar.dbc byd2/ 4 条报文 唐 DM 雷达相关
    byd_generic_pt_v2.dbc 嵌套目录内的 opendbc/dbc/ 19 条报文 与上一份布局大体重叠，但报文明/信号名被混淆成不同写法
    byd_all.dbc byd大全.dbc 124 条报文 头部注明由运行时/导出资源重建，许多字段为占位名
    byd_song.dbc 比亚迪3/Bydsong(1).dbc 89 条报文 同目录 generated(1).dbc 与其字节相同
    byd_tang_dmp_based_on_han.dbc 比亚迪3/唐DMP_based_on_han.dbc 88 条报文 文件名即说明「基于汉架构扩展」
    车型代号表 项目 README 数十个代号 README 声称的适配范围，非逐车型已核验
    横向力矩曲线参数 LAT_SIGLIN_TABLE 项目 README 调参节 示例 [4.867, 1.09, 0.243] 调参说明，非 DBC 内信号
    吉利缤越相关参数 项目 README 50 Hz 控制频次、最大转向力矩 598 README 自述规格

    读取方法与注意事项

    第一，先把「文件」和「已核验适配」分开。来源说明写得很清楚：上游 README 的宽泛车型列表不确立每个 DBC 对每种车型的适配，而 byd_all.dbc 的头部自述是「由运行时/导出资源重建」，因此其中的字段名多为占位名。把这样的文件直接当作某车某信号的权威定义，会混淆「存在」与「正确」。

    第二，同名不同内容要留意。快照里两份 byd_generic_pt 变体布局大体重叠，但报文明和信号名被改写成不同写法；byd_han_dmev_2020.dbc 也与之前归档的副本不同（改了两个踏板缩放、少了 4 条报文）。同名文件的差异本身就是证据链的一部分，不能互相替代。

    第三，权利层面要谨慎。来源说明指出：仓库快照里找不到许可文件，尽管 README 带 MIT 徽章。因此这些文件只适合作为私有研究副本，在对外分发或整合前应先确认原作者与再分发权利。

    第四，README 里的调参项（转向速率上限/回正速率、力矩模式表、离手维持参数）属于控制侧参数，不是 CAN 信号；它们与 DBC 里的报文定义分属两层。

    证据等级与边界

    可视为可核对的是「快照里实际存在这 7 个文件、各自多少条报文」——这来自来源说明的逐条登记。属于未确立的是各文件对应的具体车型适配：来源说明用「候选的逆向定义」来描述它们，并指出部分字段是占位名。

    不能外推的地方有三处。第一，DBC 里有报文不等于该车型在总线上真的以这个布局广播；需要实车抓包核对。第二，混淆/占位名使得信号语义不可靠，不能据此命名功能。第三，不同年款之间的报文集合可能有子集或超集关系，跨年款套用没有证据。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的文件与规模，不涉及对车辆安全机制的规避，也不涉及任何报文写入操作。

    常见问题

    这些 DBC 能直接说明某款比亚迪车的某个信号定义吗？

    不能。来源说明指出这些是候选的逆向定义，上游 README 的宽泛车型列表不确立逐车型适配，且 byd_all.dbc 的字段多为占位名；要确认某个信号，需要实车抓包核对。

    为什么有两个名字几乎一样的通用 DBC？

    来源说明登记了两份 byd_generic_pt 变体：布局大体重叠，但报文明与信号名被改写成不同写法；它们是同名不同内容，不能互相替代。

    这些文件有开源许可吗？

    来源说明称仓库快照里找不到许可文件，尽管 README 带 MIT 徽章；因此应先确认原作者与再分发权利，仅作私有研究副本使用。

    文件里的报文数加起来代表整车所有报文吗？

    不代表。各文件是不同来源与年份的候选集合，byd_all.dbc 有 124 条、byd_song.dbc 有 89 条、雷达到只有 4 条；它们不是同一辆车的完整报文表。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/README.md（主来源：项目自述、车型代号表与调参说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/SOURCE.md（快照范围、7 个 DBC 的报文数与许可提示）。

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

    更新记录

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

  • GM panda safety：三个参数位切换拓扑，白名单不等于字段认证

    结论：GM panda safety 按 HW_CAM、HW_CAM_LONG、EV 三个参数位切换硬件拓扑与 TX 表，三者的使能与转发策略互不相同：ASCM 分支 disable_forwarding=true 完全禁转发、由按钮沿使能；相机原车纵向跟随 PCM；相机自控纵向仅在调试构建且 HW_CAM_LONG 置位时才把 gm_pcm_cruise 改为假。白名单只控制 CAN 地址、总线、长度，不代表所有字段都经安全认证。

    本文基于固定源码快照逐函数静态解析 opendbc/safety/modes/gm.h，结合通用 safety 分发与本机原版 GM 测试。未编译目标固件或接入车辆；这里的总线号、编码和阈值仅适用于该源码快照及匹配车型，不能直接当作新硬件配置。

    RX：来源、使能与完整性缺口

    GM_COMMON_RX_CHECKS 监视总线 0 的 0x184 驾驶员扭矩、0x34A 后轮速度、0x1E1 按钮、0xBE 踏板、0x1C4 油门/巡航和 0xC9 制动状态；0xBE 允许三种长度以适配不同车型。各项暂以 10 Hz 标称检查，且显式忽略校验和、计数器、质量位——源码 TODO 指出这不是完整报文完整性校验。EV 参数位另把 0xBD 再生制动消息纳入 RX 表，频率配置为 40 Hz。

    报文 用途 完整性处理
    0x184 驾驶员扭矩（11 位有符号，进共享采样窗口） 忽略校验和/计数器/质量位
    0x34A 后轮双速；两轮原始速度均不超过 10 判静止 停车判据，不是完整车速估计
    0x1E1 按钮沿使能（ASCM 用 SET 松开沿或 RESUME 按下沿） 忽略完整性字段
    0xBE ASCM 刹车（字节阈值）；允许三种长度 与相机刹车帧 0xC9 不是同义来源
    0x1C4 相机原车纵向读取巡航接合状态 走 pcm_cruise_check()
    0xC9 相机刹车（bit 40） 与 0xBE 不能互换
    0xBD EV 再生制动，仅 EV 参数位置位时入 RX 表 配置为 40 Hz

    safety_rx_hook() 只在检查通过、命中表后调用 gm_rx_hook()，因此再生制动分支并非在非 EV 模式下无条件接收。ASCM 以 0x1E1 的 SET 松开沿或 RESUME 按下沿使能，CANCEL 按下退出；相机原车纵向则从 0x1C4 读取巡航接合状态。

    TX 与模式矩阵

    GM 自控纵向时 gm_pcm_cruise=false；相机原车纵向时为 true。相机自控纵向仅在调试构建且 HW_CAM_LONG 位置位时把它改为假。这决定使能来自按钮沿还是 PCM，影响告警与执行权限，不只是 TX 白名单的变化。

    模式 纵向 TX 转发与使能
    ASCM，HW_CAM=0 0x2CB 位于总线 0，0x315 位于总线 2；另有观测/keepalive 帧 disable_forwarding=true，由按钮沿使能
    相机，默认或 release 无 0x2CB/0x315；0x1E1 总线 2 仅允许取消 跟随 PCM 巡航接合，仍可发横向 0x180
    相机，ALLOW_DEBUG 且 HW_CAM_LONG=1 0x2CB/0x315 总线 0 改用按钮沿，禁原车 0x1E1 TX
    上述模式叠加 EV 不改变所选 TX 表 仅增加 0xBD 再生制动 RX

    gm_tx_hook() 对 0x180 调用共享扭矩安全检查，含 300 原始单位上限、变化率、驾驶员扭矩与实时增量限制。0x315 的 12 位原始编码先反转为非负制动量，再用 longitudinal_brake_checks() 限制到 max_brake=400 且未使能时必须为零。0x2CB 将油门/再生制动信号偏移到整数域后分别按 ASCM/相机限值检查，apply 位在 controls_allowed=false 时禁止。相机原车纵向的 0x1E1 只有原车巡航已接合且按钮编码为 CANCEL 时放行。

    白名单不等于字段认证

    并非所有 GM 白名单帧都有逐信号检查：例如 ASCM 的 keepalive/观测帧和相机的 0x184 状态帧，在 gm_tx_hook() 中没有对应载荷分支。白名单控制的是 CAN 地址、总线、长度。

    转发层面同样分层：相机模式中 0x184 总线 2 的 check_relay=true 会使共享转发逻辑阻断来自总线 0、目标为总线 2 的同地址帧；ASCM 则完全禁转发。应把「是否允许发」「是否阻断原车转发」「是否检测原车 ECU」分别建模。

    验证范围与插件边界

    test_gm.py 有 ASCM、相机、EV、相机自控纵向测试类，包含按钮、踏板、扭矩/纵向限值和点火用例。本机运行原版 GM 模块测试为 Ran 192 tests、OK (skipped=19)，即 173 项执行且通过，19 项未执行。跳过项来自无 _user_regen_msg 的通用再生制动用例、无第二车速消息的通用检查，以及四个抽象基类的 setUpClass，不能计入通过。

    测试调用 libsafety_py._build_libsafety() 默认加 ALLOW_DEBUG，因此相机自控纵向用例不能证明 release 固件接受 HW_CAM_LONG。本机另用严格警告把测试库 safety.c 分别编译为不含/含 ALLOW_DEBUG 的目标文件，只在后者找到 GM_CAM_LONG_TX_MSGS——这核对的是本机编译分支，不是 STM32 固件或运行时许可。实板转发、实际 CAN 来源和目标 ECU 响应仍未测试。

    • 自制硬件的 GM 插件契约应固定车型/DBC、ASCM 或相机接线、EV 位、总线号、固件构建类型和 safetyParam。
    • 只读采集和回放先验证 0xBE 长度变体、0xC9 刹车、0xBD 再生制动、按钮沿、PCM 巡航及 0x184 驾驶员扭矩。
    • 台架再做丢帧、重放、错总线、故障继电器和 release/debug 差异。
    • 普通插件只产生候选控制，不能设置安全钩子或绕过板端 TX/转发判定。

    常见问题

    GM 白名单里的帧都经过字段级安全检查吗？

    不是。白名单只控制 CAN 地址、总线、长度；ASCM 的 keepalive/观测帧和相机的 0x184 状态帧在 gm_tx_hook() 中没有对应载荷分支，不能据此声称所有字段都经过安全认证。

    相机自控纵向在 release 固件里能用吗？

    测试不能证明。相机自控纵向仅在调试构建且 HW_CAM_LONG 位置位时把 gm_pcm_cruise 改为假；而测试默认加 ALLOW_DEBUG，本机只在含该宏的目标文件里找到 GM_CAM_LONG_TX_MSGS，这核对的是编译分支而非运行时许可。

    ASCM 和相机的刹车帧可以互换吗？

    不能。ASCM 的刹车取 0xBE 字节阈值，相机刹车取 0xC9 的 bit 40，切换拓扑时不能把两种刹车帧视为同义来源；0xBE 还允许三种长度以适配不同车型。

    GM 的 RX 完整性与校验和有关系吗？

    没有做完整校验。各项暂以 10 Hz 标称检查，且显式忽略校验和、计数器、质量位；源码 TODO 指出这不是完整报文完整性校验。所以「命中 RX 表」不等于「报文完整可信」。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/GM_PANDA_SAFETY_MODE_DEEP_DIVE.md（取用了 GM 三参数位模式矩阵、RX/TX 与转发边界、白名单不等于字段认证，以及本机测试计数）。
    • 项目 02 —— openpilot-research/ACTUATION_GATE_CHAIN_DEEP_DIVE.md（仅用于确认执行链分层语义，未取用其未公开内容）。

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

    更新记录

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

  • 起亚 Soul EV（PS）DBC 档案：转向、制动与四轮速信号

    结论：这是一份以起亚 Soul EV（PS）命名的 DBC 数据档案，由两部分组成：一份「整车」文件记录可读的转向角、制动压力与四轮车速（每 20 毫秒更新，单位分别为度、Bar、KPH）；一份「DriveKit」文件记录可写的转向角、转向扭矩、油门踏板与制动踏板命令（同样 20 毫秒）。三条硬边界：其一，这不是厂家整网定义，而是研究与自动驾驶平台用的消息集合；其二，文档把底盘控制（雨刮、转向灯、喇叭、大灯、读 VIN）标为 Niro 专用，每条 DriveKit 消息是否适用于 Soul EV「未建立」；其三，所有声明的量程都是 [0|0]，不能当作真实范围。

    本文整理自该项目的 DBC 说明与其来源说明。来源说明本身就把适用范围、许可与验证状态标得很保守，本文原样保留这些限定。

    车辆与适用范围

    仓库说明该项目是一个起亚 Soul EV 的 CAN 记录与解码脚本，用于某实验室的自动驾驶平台采集；DBC 覆盖范围被描述为「有限」。来源说明进一步指出：这是记录集合而非出厂整网，本归档也未针对具体年款、配置或固件做过独立核对。

    项 内容
    车型 起亚 Soul EV（PS）
    年款 / 市场版本 源文档未确认（未绑定具体年款、配置或固件）
    ECU / 改装状态 面向自动驾驶平台的数据采集；DriveKit 为可写命令集
    采集跨度 源文档未给出；说明称用于 AV 平台数据采集，本归档未核对原始采集
    适用范围 仅该 DBC 快照；DriveKit 消息对 Soul EV 的适用性未建立

    总线与寻址

    来源说明没有给出该车的总线速率或 11 位 / 29 位寻址结论，也没有 CAN FD 的说明。文档给出的是消息与信号的名称、方向（读 / 写）与周期，属于应用层与数据层；物理层与链路层细节属源文档未覆盖项，本文不补。

    项 内容
    物理层 源文档未给出
    链路层 源文档未给出
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    消息周期 文档列出的信号多为 20 毫秒周期

    已解码信号

    下表分「整车文件（只读）」与「DriveKit 文件（可写）」两组。所有声明的物理量程均为 [0|0]，因此「单位」是文档给出的量纲，不是经验证的范围。表格中凡「Niro only」者不得套到 Soul EV。

    信号 / 命令 来源与方向 解码 / 取值 证据
    Steering Angle（整车） Vehicle DBC，只读 度，20 毫秒 源文档规格表
    Brake Pressure（整车） Vehicle DBC，只读 Bar，20 毫秒 源文档规格表
    Individual Wheel Speed（整车） Vehicle DBC，只读 KPH，20 毫秒（四个轮速） 源文档规格表
    steering_angle_cmd_flags DriveKit STEERING_ANGLE_COMMAND，写 Disable / Enable 源文档命令表
    steering_angle_cmd_angle 同命令消息 度 源文档命令表
    steering_angle_cmd_max_velocity 同命令消息 度（文档示例用 300） 源文档命令表与示例
    steering_angle_report_flags DriveKit STEERING_ANGLE_REPORT，读 Enable / Disable，每 20 毫秒发布 源文档报告表
    steering_angle_report_errors 同报告消息 Angle Missing / Angle Irrational / Module Disabled / Command Rejected 源文档报告表
    steering_enable_magic DriveKit STEERING_ENABLE 默认 magic number（用于先使能扭矩控制器） 源文档示例
    Steering Torque DriveKit，写 度，20 毫秒 源文档规格表
    Throttle Pedal Position DriveKit，写 百分比，20 毫秒 源文档规格表
    Brake Pedal Position DriveKit，写 百分比，20 毫秒 源文档规格表
    CHASSIS_CONTROL_COMMAND（Niro only） DriveKit，写 前雨刮（off / intermittent / slow / fast）、后雨刮（off / on）、左右转向灯、喇叭、读 VIN、大灯（off / low / high） 源文档命令表，标注 Niro 专用

    读取方法与注意事项

    转向角命令三步走。文档给出的顺序是：先发 STEERING_ENABLE（带默认 magic number）使能转向扭矩控制器；再发 STEERING_ANGLE_COMMAND，其中 flags 置 Enable、angle 设目标角、max_velocity 设最大角速度（示例用 300 度/秒）；最后应能在总线上看到 STEERING_ANGLE_REPORT 回报 flags 为 Enable、errors 为 None。

    命令互斥与越界拒绝。文档明确：转向角命令与转向扭矩命令不能同时使用，二者互斥。示例还演示越界：请求超过车辆能力的角度（9999 度）时回报变为 flags 为 Disable、errors 为 Command Rejected，控制器自我禁用。

    底盘控制是 Niro 专用。CHASSIS_CONTROL_COMMAND 可在一条消息里同时设置一个或多个底盘部件（雨刮、转向灯、喇叭、大灯，以及请求 VIN），但文档把这组功能标为 Niro only。是否适用于 Soul EV，来源说明写明「未建立」，因此不能照搬。

    写命令有实车风险。DriveKit 文件里转向、油门、制动等都是写入类命令，一旦发送就会作用在真实车辆上。本文只转述文档记录，不构成操作指引。

    证据等级与边界

    第一层是覆盖范围：来源说明写明整车文件只有 3 条消息、6 个信号，DriveKit 文件有 15 条消息、32 个信号，这是一套研究用的消息集合，不是厂家整网定义。

    第二层是数据质量：每个声明的物理范围都是 [0|0]，来源说明把它列为需要独立复核的信号准确性问题；DriveKit 说明文件还提到 Niro 专用的底盘控制，因此「每条 DriveKit 消息都适用于 Soul EV」并未成立。

    第三层是来源状态：项目自报做了 AV 平台采集，但本归档未将该副本与其采集数据、具体年款 / 配置 / 固件做独立核对；快照中也未发现仓库级许可证，仅作私有离线研究副本保留。据此，本文的信号与方向只能视为「这份 DBC 所声明的范围」，不能外推到其他 Soul EV 或其他起亚车型。

    常见问题

    这份 DBC 是起亚 Soul EV 的整车出厂网络吗？

    不是。来源说明写明整车文件只有 3 条消息、6 个信号，DriveKit 文件有 15 条消息、32 个信号，是一套研究 / AV 平台用的消息集合，而非厂家整网定义。

    为什么每个信号的物理范围都写成 [0|0]？

    因为源 DBC 就是这么声明的，来源说明也把它列为「信号准确性需要独立复核」的问题。所以 [0|0] 不能当作真实量程，表格里的「度 / Bar / KPH / 百分比」只是文档给出的量纲。

    转向角命令和转向扭矩命令能一起发吗？

    不能。文档明确二者互斥，不能同时使用。示例演示的顺序是先发使能消息，再发转向角命令，并通过报告消息确认 flags 为 Enable、errors 为 None。

    Niro 的底盘控制能不能套到 Soul EV？

    未确认。文档把这组底盘控制（雨刮、转向灯、喇叭、大灯、读 VIN）明确标注为 Niro only；来源说明也指出「每条 DriveKit 消息是否适用于 Soul EV 尚未建立」。因此不能照搬到 Soul EV。

    转向角报告里会出现哪些错误？

    文档列出的四种是：Angle Missing（角度缺失）、Angle Irrational（角度不合理）、Module Disabled（模块禁用）、Command Rejected（命令被拒）。越界请求（如示例中的 9999 度）会得到 Command Rejected，随后控制器自我禁用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/DBC/DBC-README.md（本项目车型档案主来源，取用了整车 / DriveKit 的信号与周期表）。
    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/SOURCE.md（取用了覆盖范围、[0|0] 量程与「未建立」等边界说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/README.md（取用了 AV 平台采集的项目背景）。

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

    更新记录

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

  • FT86 与 MX-5 的赛道 CAN 信号：RaceChrono 公式表

    结论：这是一组面向赛道数据记录的 CAN 信号表，覆盖四类车：2013-2020 Subaru BRZ / Toyota 86 / Scion FR-S、2022 BRZ / GR86、Mazda MX-5 的 NC 与 ND 两代。它们的共同点是——老一代 FT86 与 NC/ND 的主 CAN 就在 OBD 口引脚 6/14 上，用一款 OBD 读取器即可直接抓广播帧；而 2022 BRZ/GR86（以及 2018+ WRX、许多 Porsche）把 CAN 与 OBD 口隔离了，只能拿慢速有限的 OBD 数据，或另找接入点。下表登记的是各平台可用的通道与公式，其中若干系数源文档自述为「经验值」或「可能有误」。下述条目只适用于各表所记录的车型与年款。

    车辆与适用范围

    源文档是一个 DIY BLE CAN 记录设备的说明，作者用它给一款商业赛道计时 App 供数。信号表按车型分组保留，ND 表明确说明是在一台 2019 MX-5 RF 上测试的。

    项 内容
    车型 2013-2020 Subaru BRZ / Toyota 86 / Scion FR-S；2022 Subaru BRZ / Toyota GR86；Mazda MX-5 NC（2005-2015）、ND（2019 RF 实测）
    年款 / 市场版本 各表相互独立；ND 表按 2019 MX-5 RF 测试，其他 ND 年款「应可适用」但未独立确认
    ECU / 改装状态 原厂状态；接入走 OBD 口或隐藏连接器，作者自制 nRF52840 + MCP2515 记录设备
    采集跨度 源文档未给出统一日志数；MX-5 NC 表附有一份怠速时 10 秒内的 CAN ID 直方图
    适用范围 各车型表只适用其列出的年款/代际；跨代不可套用（同一功能在不同代的 ID 完全不同）

    总线与寻址

    源文档说明 FT86 与 Miata 的老一代主 CAN 在 OBD 引脚 6/14 上；较新的车把 CAN 与 OBD 口隔离。信号表以 11 位 ID 记录（如 0x140、0xD1、0x081、0x201），源文档未展开 29 位或 CAN FD 话题，按经典 CAN 处理。

    项 内容
    物理层 双绞线 CAN；FT86/Miata 老一代主 CAN 在 OBD 引脚 6/14
    链路层 / 比特率 源文档未统一给出比特率，按经典 CAN 处理
    寻址方式 11 位 ID
    CAN FD 源文档未涉及
    接入差异 2022 BRZ/GR86、2018+ WRX 等把 CAN 与 OBD 口隔离，需另找接入点

    已解码信号

    下表从四张源表中抽取代表性信号，逐条标注车型与证据/置信度。源文档标注为经验值、可能错误或请求独立核对的系数，按原样保留。

    信号 车型 / ID 解码 证据 / 置信度
    加速踏板位置 FT86 gen1 / 0x140 A / 2.55（%） 源表「Recommended」
    加速踏板位置 FT86 gen2 / 64 E / 2.55（%） 源表「Recommended」
    制动位置 FT86 gen1 / 0xD1 min(C / 0.7, 100)（%） 0.7 为经验除数；看到频繁 100% 可改用 0.8 / 0.9
    制动压力 FT86 gen1 / 0xD1 C × 128 源表「Recommended」
    制动压力 FT86 gen2 / 313 F × 128 系数取自 gen1，源文档称「似乎吻合」
    冷却液温度 FT86 gen1 / 0x360 D − 40 → °C 源表「Recommended」
    机油温度 FT86 gen1 / 0x360 C − 40 → °C 源表「Recommended」
    转速 FT86 gen1 / 0x140 bitsToUIntLe(raw, 16, 14) 源表「Recommended」
    车速 FT86 gen1 / 0xD1 bytesToIntLe(raw, 0, 2) × 0.015694 源文档建议对 GPS 核对乘数
    车速 FT86 gen2 / 313 bitsToUIntLe(raw, 16, 13) × 0.015694 乘数同样建议对 GPS 核对，换更大/更小直径轮胎时尤其
    转向角 FT86 gen1 / 0xD0 bytesToIntLe(raw, 0, 2) × −0.1（正值为左转） 源表「Recommended」
    四轮车速 FT86 gen1 / 0xD4 每 2 字节一个轮，× 0.015694 与「车速」同乘数
    横摆角速度 FT86 gen2 / 312 bytesToIntLe(raw, 4, 2) × −0.2725 对某款外部陀螺仪标定；gen1 用 0.286478897
    横/纵向加速度 FT86 gen1 / 0xD0 bytes(6,1) × 0.2；bytes(7,1) × −0.1 源文档标注「数据噪声大」
    离合器位置 FT86 gen1 / 0x140 (B & 0x80) / 1.28（只有 0% 和非 0%） 源文档标注仅能区分 0% 与「非 0%」
    转速 MX-5 NC / 0x201 bytesToUInt(raw, 0, 2) / 4.00 源表（WIP）
    车速 MX-5 NC / 0x201 ((bytesToInt(raw, 4, 2) / 100) − 100) / 3.6 原始值含 100 km/h 偏移；/3.6 转 m/s
    制动压力 MX-5 NC / 0x085 (3.4518689053 × raw − 327.27) / 1000 kPa 乘数取自他人数据，源文档标注「可能有误」
    车速 MX-5 ND / 514 bytesToInt(raw, 2, 2) / 360.0 源表「Recommended」（2019 RF 实测）
    转速 MX-5 ND / 514 bytesToUInt(raw, 0, 2) / 4 源文档提问：若有人记录到 > 8192 rpm 请告知
    转向角 MX-5 ND / 134 (16000 − bytesToUInt(raw, 0, 2)) × 0.1（正值为右转） 源表「Recommended」

    读取方法与注意事项

    第一是通道预算：源文档提醒，每增加一个基于新 CAN ID 的通道都会增加会话文件体积，并可能拖低其他通道的更新率，因为 BLE 带宽有限；但如果新通道与已有通道共用同一个 CAN ID（例如「节气门位置」和「加速踏板位置」都用 0x140），协议会自动优化，基本不影响更新率。

    第二是接入点：FT86 与 Miata 老一代可以直接用 OBD 引脚 6/14；作者也提到可以在信息娱乐主机后方找一个隐藏连接器做完全隐式的接入。2022 之后的部分车型把 CAN 与 OBD 口隔离，这时要么接受慢速 OBD 数据，要么另找物理接入点并自制连接。

    第三是公式单位：源表的车速公式末尾带「/3.6」，是把 km/h 换成 App 内部使用的 m/s，再由 App 换算成用户选择的单位；照着抄时不要重复换算。转向角公式前的负号只是朝向约定（正值为左转或右转随车型不同），可按喜好去掉。

    证据等级与边界

    可视为有证据的是 ND 表（在 2019 MX-5 RF 上实测）与各表标注为「Recommended」的基础信号。属于经验值/待核对的是：制动位置的 0.7 除数、gen2 制动压力沿用 gen1 系数、车速乘数（建议对 GPS 核对）、MX-5 NC 的制动压力乘数（源文档自述可能有误）、横/纵向加速度（噪声大）、离合器位置（只能区分 0%）。

    不能外推的地方有两处。第一，同一功能在不同代际是不同的 ID 与公式（例如加速踏板 gen1 是 0x140、gen2 是 64），跨代套用必然出错。第二，各表相互独立，ND 表虽称「应适用于其他 ND 年款」，但只有 2019 RF 一台被实测，其他年款与配置需自行确认。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；这些表都是监听广播帧得到的结果，不涉及对车辆安全机制的规避。

    常见问题

    哪些车能直接从 OBD 口抓到主 CAN？

    源文档说明 2013-2020 的 BRZ/86/FR-S，以及 NC 与 ND 代 Miata，主 CAN 就在 OBD 引脚 6/14 上，用一款 OBD 读取器即可直接抓。2022 BRZ/GR86、2018+ WRX 以及许多 Porsche 把 CAN 与 OBD 口隔离了，只能拿慢速有限的 OBD 数据或另找接入点。

    2022 BRZ 和 2013-2020 的公式能通用吗？

    不能。同一功能在不同代是不同的 ID 与公式，例如加速踏板 gen1 用 0x140、gen2 用 ID 64；两代表是独立维护的。

    车速公式里的乘数需要改吗？

    源文档建议对 GPS 核对，换更大或更小直径轮胎时尤其要核对；FT86 两代都用 0.015694，MX-5 NC 用含 100 km/h 偏移的分式。

    加更多通道会影响刷新率吗？

    会，若新通道基于新的 CAN ID。源文档说明同一 CAN ID 上的多个通道不影响更新率，而基于新 ID 的通道很可能拖低所有其他通道的更新率。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/README.md（主来源：设备与接入总说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/can_db/ft86.md 与 can_db/ft86_gen2.md（两代 FT86 信号表）。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/can_db/mazda_mx5_nc.md 与 can_db/mazda_mx5_nd.md（MX-5 NC/ND 信号表）。

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

    更新记录

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

  • pandad 硬件测试：DFU 恢复、SPI 注错与 loopback 边界

    结论：pandad 的三个设备测试给出三种不同强度的证据：恢复测试只证明设备可见性，CAN loopback 证明期望集合被逐条消耗，SPI 注错证明服务存活与粗时序。它们都会复位/刷写 panda、切换 allOutput safety 并发送随机 CAN，绝不可在连接车辆的环境运行。源文档明确，三者都不能证明永久 NACK、非法长度、短健康包、热插拔、多 Panda、心跳失效后的 MCU 静默或实际车型 RX/TX safety 钩子。本文为静态核对，未启动测试、未刷写、未发送 CAN、未连接任何设备。

    恢复测试：只证明设备可被看到

    TestPandad 要求 comma 硬件；每个测试的 setUp() 先执行测试基类的硬件初始化，再停止已有 pandad，如果当前枚举不到 Panda 就尝试启动包装器恢复。核心 _run_test() 启动 pandad，在 30 秒内订阅 pandaStates，看到至少一块且首块 pandaType != unknown 即停止并返回耗时。

    源文档强调它没有断言 CAN 能收发、固件签名值、心跳健康或目标安全模式。因此「看到 pandaStates」不等于整条安全链通过。

    场景 实际操作 静态覆盖范围
    test_in_dfu() 主机 GPIO 进入 ROM DFU，再让包装器恢复 验证可恢复到非 unknown 状态，不测刷写中断
    test_in_bootstub() 经 Panda API 进入 bootstub，确认标志，再让包装器恢复 验证 bootstub 起点的正常恢复
    test_in_reset() 操作 STM_RST_N，确认暂时枚举不到 Panda，再启动包装器 属于物理复位线测试，不是纯软件 mock
    test_release_to_devel_bootstub() _flash_bootstub() 选择 MCU 配套 bootstub 文件并通过 PandaDFU.program_bootstub() 写入 有真实固件修改；名称里的 release/devel 不能替代证书/签名核验
    test_recover_from_bad_bootstub() 进入 DFU 后向 bootstub 起始地址写入 100 个零字节，复位并确认普通/DFU 枚举为空，再靠包装器恢复 主动制造启动损坏，失败时可能需要外部救援

    公共台架夹具与 allOutput 的放开范围

    setup_pandad() 有三次重试：清除当前测试 Prefix 下的 Params，反复发布 deviceState.started=False 等待非 unknown pandaStates，再写 FirmwareQueryDone、ControlsReady 和仅含 allOutput 的 CarParams.safetyConfigs，发布 started=True。

    两处边界需要注意：测试基类的 OpenpilotPrefix 隔离的是软件路径，不隔离接在 panda 上的物理 CAN；allOutput 的 tx_hook 无帧内容限制，通用发送门也对该模式放开白名单，这不是车型量产 safety 策略。台架必须与车辆 CAN 物理断开，不能仅依靠软件设置「loopback」。

    loopback 与 SPI 注错的断言边界

    send_random_can_messages() 对 0～2 号总线生成随机 29 位以内地址和 1～8 字节载荷，用 sendcan 发布；没有 CAN FD 长帧。TestBoarddLoopback.test_loopback() 运行 200 轮，每轮除原总线集合外还期待 src+128 的发送回执集合；收到消息就从集合移除，最后要求所有期望集合清空。源文档指出这比只看「有 CAN 流量」强，但不测负载极限、重复帧保序、超时恢复或车辆控制的安全限幅；每轮接收循环最多 500 次 wait_for_one，没有外层总时间上限。

    TestBoarddSpi.setup_class() 设置 STARTED=1、SPI_ERR_PROB=0.001，默认还开启 BOARDD_LOOPBACK；SPI 层在配置概率下扰动传输长度、TX/RX 缓冲，然后继续真实 ioctl，故它是传输层随机注错而非确定性故障脚本。test_spi_corruption() 在默认约 20 秒循环中发送随机 CAN，检查状态消息有效与设备类型/点火/电压/风扇范围，并统计三种主题的平均/最大消息间隔和数量。

    测试 断言边界 不能证明
    test_loopback() 200 轮，期望集合（含 src+128 回执）全部清空 负载极限、重复帧保序、超时恢复、安全限幅
    test_spi_corruption() CAN Event 即使 valid=False 仍进入测试；只断言收到且 src<=4 的（地址，载荷）曾在对应发送集合中；最后只要求 total_recv_count > 20（集合移除被注释） 接收数等于发送数、每条只到达一次或全部发送帧均回传
    JUNGLE_SPAM 模式 校验地址、源总线和 0xff 载荷模式 不产生本测试自己的发送集合

    三种证据各自不证明什么

    源文档收束得很清楚：恢复测试的设备可见性、loopback 的期望集合消耗、SPI 注错时的服务存活/粗时序，三者都不能证明永久 NACK、非法长度、短健康包、热插拔、多 Panda、心跳失效后的 MCU 静默或实际车型 RX/TX safety 钩子。

    硬件插件验证的推荐顺序是：先用离线消息/协议测试，再在断开车辆的台架做可重复错误矩阵与固件恢复，最后另由独立 safety 层和受监督实车流程验收。已静态核对三个测试文件、公共 helper、SPI 注错点与 allOutput 安全钩子；未运行设备测试或执行任何刷写/CAN 操作。

    源文档也把恢复包装器列为待验证对象：真实包装器的复位、签名和重试边界需要另做专题核对，本节列出的是测试证据。分支和计数结论是源码可见的断言范围，目标硬件时序和异常恢复结果仍需专用台架验证；全项目其他组件仍待逐项审查。

    常见问题

    pandad 恢复测试通过是否代表固件与安全链正常？

    不代表。源文档明确 _run_test() 只要求在 30 秒内看到至少一块非 unknown 的 pandaStates，没有断言 CAN 能收发、固件签名值、心跳健康或目标安全模式。

    为什么 SPI 注错测试通过不能说明接收完整？

    因为它的断言很窄。源文档指出，test_spi_corruption() 只断言收到且 src<=4 的帧曾在对应发送集合中，集合移除被注释，最后只要求 total_recv_count > 20，并不要求接收数等于发送数或全部发送帧均回传。

    台架上把 safety 设成 allOutput 就安全吗？

    不安全。allOutput 的 tx_hook 无帧内容限制，通用发送门也放开白名单，它不是车型量产 safety 策略；且 OpenpilotPrefix 只隔离软件路径，不隔离物理 CAN，台架必须与车辆 CAN 物理断开。

    这些测试能在连接车辆的环境下跑吗？

    绝对不能。源文档在开头即警示：它们会复位/刷写 panda、切换 allOutput 并发送随机 CAN，绝不可在连接车辆的环境运行。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/PANDAD_HARDWARE_TEST_DFU_SPI_LOOPBACK_SAFETY_BOUNDARY_DEEP_DIVE.md（取用了恢复测试场景表、公共台架夹具、loopback 与 SPI 注错的断言范围、三类证据边界）。

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

    更新记录

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

  • Subaru Global safety：0x221 只允许取消，纵向不放行

    结论：Subaru Global safety 的 TX 权限极窄：转向帧 0x122 受扭矩与请求位门约束，而 0x221 ES_Distance 只允许取消——任何非 inactive_gas=1818 的 Cruise_Throttle 或未设置 Cruise_Cancel 都被拒，主动油门、制动或巡航 RPM 命令一律不放行。该快照下 alphaLongitudinalAvailable=False，不能因限值结构存在就向插件授予纵向执行权限。

    本文依据固定源码快照的 subaru.h、车型接口和相邻安全测试做静态分析，不证明目标固件、线束、ECU 或实车安全。本文覆盖 Global 模式；它与 Preglobal 是不同安全钩子，能力不能互相继承。

    模式与总线矩阵：Gen2 只搬了三组 RX

    Global 选择 subaru 安全模式，Gen2 额外设置 GEN2 参数。subaru_init() 按 Gen2 标志选择两组 RX/TX 总线表，没有纵向 TX 表分支。一个常见误解是「Gen2 把全部 RX 移到 bus 1」——实际只有轮速、制动、巡航三组从 bus 0 改到 bus 1，油门与驾驶员扭矩仍留在 bus 0。

    报文职责 Gen1 Gen2 钩子使用
    0x40 油门、0x119 驾驶员扭矩 RX bus 0 bus 0 两代相同
    0x13A 轮速、0x13C 制动、0x240 巡航 RX bus 0 bus 1 Gen2 的 alt bus 影响这三组，不能把全部 RX 一起移到 bus 1
    0x122 ES_LKAS TX bus 0 / 8 字节 bus 0 / 8 字节 两代均检查扭矩与请求位
    0x221 ES_Distance TX bus 0 / 8 字节 bus 1 / 8 字节 均只允许取消，Cruise_Throttle=1818
    0x321/0x322/0x323 HUD TX bus 0 / 8 字节 bus 0 / 8 字节 白名单与继电器检查；无本模式逐字段校验

    五组 RX 均要求 8 字节、8 位累加校验、四位计数器和存活检查；声明频率依次为油门 100 Hz、扭矩 50 Hz、轮速 50 Hz、制动 50 Hz、巡航 20 Hz。这些频率用于健康检查，不等于每帧独立实时截止时间。subaru_get_checksum()、subaru_get_counter()、subaru_compute_checksum() 定下字节 0 存校验和、字节 1 低四位为计数器；校验值为地址两字节加字节 1 起的数据之和并截断为 8 位。

    校验与计数器：一个已知的盲点

    一个值得写进契约盲点的现象来自离线探针：把已打包 0x221 帧的字节 4 异或 0xFF、保持原校验字节不变，两代仍能通过 TX 钩子。这说明该数据字节及由此产生的校验和失配不在本模式的 TX 专属检查内。需要强调边界：这不意味着 ECU 会接受畸形帧，只是固件这一层没有拦。

    项目 规则 边界
    校验和 字节 0 存校验和；地址两字节加字节 1 起数据求和截断为 8 位 8 位累加，非通用 CRC
    计数器 字节 1 低四位 四位回绕，配合存活检查
    TX 校验盲点 改字节 4 保持原校验字节仍可通过 TX 钩子 不在本模式 TX 专属检查内，不代表 ECU 接受

    转向、纵向与转发边界

    subaru_tx_hook() 对 0x122 解码 13 位有符号转向扭矩并反转符号，检查请求位。Gen1 最大扭矩 2047、上升/下降分别 50/70；Gen2 为 1000、40/40。两代共用实时差 940、驾驶员余量 60、倍数 50，以及至少 7 帧有效请求、最多 1 帧无效请求和 144 ms 最小间隔的容忍配置。这些是固件限值，不等于主机控制器一定按相同步长构帧。

    纵向一侧，源码定义了较多 SUBARU_LONG_LIMITS 字段，但当前 TX 钩子只在 0x221 读取其 inactive_gas=1818，没有放行主动油门、制动或巡航 RPM 命令。与之对应，接口显式关闭自控纵向能力。

    同时，两代的 0x122 与 HUD TX 均标 check_relay=true，若本机发送总线出现同地址原车帧，可触发共享继电器故障；0x221 为 check_relay=false。该模式无专属 fwd 钩子，通用转发只在 bus 0 与 bus 2 之间；Gen2 的 bus 1 不是该转发对。不能只看上层相机/网关接线位置就假定 0x221 已被正确转发或替代。

    状态侧，subaru_rx_hook() 对 0x119 读取 11 位驾驶员扭矩并反转符号；轮速解析四轮 13 位原始值，只要任一非零即认为移动，并以均值形成速度。通用 RX 门继续处理踏板退出。

    验证与插件准入

    三项原钩子离线探针用真实 DBC 打包 0x221 取消帧并调用编译版 safety_tx_hook()：Gen1 仅 bus 0、Gen2 仅 bus 1 可通过；取消位缺失或油门从 1818 变为 1819 都被拒。相邻 test_subaru.py 覆盖 Gen1/Gen2 扭矩、请求位及取消帧；本机运行该模块 64 项，12 项跳过，其余通过。

    • 身份插件需证明 Global Gen1/Gen2、DBC 和物理总线布局；Preglobal、Hybrid、角度 LKAS 的能力不能继承本模式推断。
    • 车辆输入插件保留五组 RX 的来源与时间戳；Gen2 特别区分 bus 0 的油门/扭矩与 bus 1 的轮速/制动/巡航。
    • 控制插件只提交转向意图和受限取消请求；安全模式读回、CRC/计数、继电器、失联降级仍由独立 MCU/网关裁决。
    • 验证需覆盖错总线、校验/计数故障、巡航边沿、驾驶员反扭矩、请求位切断、0x221 非活动油门和 HUD 载荷，再进入台架与受控场地。

    HUD 三帧仅做通用地址/总线/长度白名单及继电器检查，未在本模式限制载荷字段。自制硬件应把这些帧的构造权留给可信任网关，限制模板与发送节拍，避免普通插件直接写原始 CAN。当前无目标板或实车验证。

    常见问题

    Subaru Global 支持自控纵向吗？

    不支持。该快照下 alphaLongitudinalAvailable=False，普通参数路径不会启用自控纵向；subaru_init() 也没有纵向 TX 表分支。当前 TX 钩子只在 0x221 读取 inactive_gas=1818，任何非该值的 Cruise_Throttle 或未设置 Cruise_Cancel 都被拒。

    Gen2 是把所有 RX 都移到 bus 1 吗？

    不是。Gen2 只把轮速、制动、巡航三组从 bus 0 改到 bus 1，油门与驾驶员扭矩仍留在 bus 0。不能把全部 RX 一起移到 bus 1，否则会读错来源。

    改了 0x221 的数据字节还能通过 TX 钩子，是不是说明固件有漏洞？

    该数据字节及由此产生的校验和失配不在本模式的 TX 专属检查内，所以按探针做法仍能通过 TX 钩子；但这不等于 ECU 会接受畸形帧。这里应把它写成契约盲点，而不是定性为整车级缺陷。

    为什么不能只按接线位置判断 0x221 是否被转发？

    因为该模式没有专属 fwd 钩子，通用转发只在 bus 0 与 bus 2 之间，Gen2 的 bus 1 不是该转发对；而 0x221 的 check_relay=false。只看上层相机/网关接线位置，无法推断 0x221 已被正确转发或替代。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/SUBARU_GLOBAL_PANDA_SAFETY_DEEP_DIVE.md（取用了 Global Gen1/Gen2 总线矩阵、TX 取消帧约束、转向限值与三项离线探针结论）。
    • 项目 02 —— openpilot-research/SUBARU_PREGLOBAL_PANDA_SAFETY_DEEP_DIVE.md（仅用于确认 Preglobal 是不同安全钩子、能力不可继承）。

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

    更新记录

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

  • Fiat Ducato X250 车身 CAN 档案：50 kbit/s 上的 24 条信号

    结论：Fiat Ducato X250 的一个反直觉特征是OBD 口后面不是发动机 CAN，而是一张 50 kbit/s 的车身 CAN：引脚 6/14 承载 B-CAN，500 kbit/s 上什么都没有；发动机 ECU 走引脚 7 的 K 线（ISO 14230-4 KWP2000）。好消息是仪表需要的多数发动机量（转速、冷却液温度、车速、里程、续航）都被广播到这张车身网上，所以一个只监听、不发送的 CAN 记录器就能读到。源文档记录 18 个 ID、约 90 帧/秒，并逐条说明每个信号是怎么在实车上核对出来的。下述结论仅限源文档记录的那一台 2009 X250。

    车辆与适用范围

    源文档是一位车主的业余项目，属于单台车、单人实验。作者明确声明「只做监听、绝不发送」，并说明是配合一款支持 MQTT 的 OBD-CAN 记录适配器完成的；文档还提到另一台车（同平台另一辆 van）提供了油量数据。作者列出该平台同款车型（Citroën Jumper / Peugeot Boxer 2006–2014），但只有 Ducato X250 被测试过。

    项 内容
    车型 Fiat Ducato X250，2.3 MultiJet 柴油（车身改装为 Elnagh Prince 55L 房车，7.15 m）
    年款 / 市场版本 2009（第一代 X250，模拟仪表 + 橙色 LCD）；意大利（EU）市场
    ECU / 改装状态 原厂线束未改；OBD 口插一款 OBD-CAN 记录适配器（只监听模式）；发动机 ECU 走 K 线
    采集跨度 5 段真实抓包（怠速、门与灯、杂项动作、冷启动与轰油、约 20 分钟 7 km 行驶），约 90 帧/秒
    适用范围 仅限这一台 Ducato X250；同平台 Jumper/Boxer 未测试，车身电路（例如车门与柜锁共用一条回路）因改装而异

    总线与寻址

    源文档把物理层写在最前面：OBD 引脚 6/14 是车身 CAN（B-CAN），50 kbit/s、11 位 ID；引脚 7 是发动机 ECU 的 K 线。作者特别提醒：把记录器设成 500 kbit/s 时「什么都看不到」，因为这张网上没有 500 kbit/s 的流量。

    项 内容
    物理层 双绞线 CAN，B-CAN 高/低；OBD 引脚 6/14
    链路层 / 比特率 50 kbit/s（源文档明示；500 kbit/s 无流量）
    寻址方式 11 位 ID，文档记录 18 个 ID
    CAN FD 否；按经典 CAN 处理
    发动机 ECU 走 OBD 引脚 7 的 K 线（ISO 14230-4 KWP2000）
    模式 只监听（Silent / listen-only），记录器不在总线上发送

    已解码信号

    源文档对每个信号都写了「怎么验证」的一列，并明确保留未完成核对的条目。下表抽取代表性信号；油量与瞬时油耗两条按源文档原样保留其未完成核对的标注。

    信号 位置（ID / 字节 / 位） 解码 证据
    制动踏板 0x180，b0 位 7 位 踩踏板
    示宽灯 / 近光 / 远光 0x180，b1 位 5 / 3 / 4 各自为 1 位 灯光开关、拨杆
    左 / 右转向灯 0x180，b2 = 0x40 / 0x20 随闪光跳变 拨杆
    发动机是否运转 0x281 用「转速 > 300」判定（不用 b1 位 7） 3 次钥匙测试（仅通电、启动、运转后停机）
    冷却液温度 0x281，b3 b3 − 40 → °C 表针居中时 81 °C
    转速 0x281，b5 与 b6 (b6×256 + b5) / 8 → rpm 怠速约 830，轰油 1800 / 3000
    车速 0x286，b2 与 b3 (b2×256 + b3) / 16 → km/h 4 段稳态行驶与 GPS 差在 1% 内
    车速（副本） 0x2A0，b0 与 b1 (b0×256 + b1) / 16 → km/h 同 0x286
    驻车制动 0x380，b0 位 5 位 拉手刹
    任一车门开 0x380，b1 任一门开时为 0x0C，全关为 0x00 驾驶室门、房车门、储物柜共一条回路
    倒挡 0x380，b2 位 2 位 挂倒挡进出 3 次
    启动电池电压 0x380，b3 b3 × 0.16 → V 与启动电池上的分流计对比 20 分钟行驶
    低油量告警 0x380，b4 位 1 0x02 表示进入储备 与仪表储备灯同亮时 b5 = 11、续航 110 km
    油量 0x380，b5 b5 → 升 另一台满油 90 L 罐读 91；本文档尚未在本车下次加油时交叉核对
    驾驶员安全带 0x39A，b2 位 0 1 = 未系（副本见 0x3C3 b4 位 1） 系/解 3 次，跟随仪表告警灯
    里程 0x603，b1 低半字节 + b2 + b3 20 位 → km 61744 与仪表一致，行驶 7 km 后 +7
    续航 0x603，b4 位 2-0 + b5 11 位 → km 272 与仪表一致
    瞬时油耗 0x603，b0 + b1 高半字节，BCD BCD → L/100km（示例 11 6x = 11.6） 源文档标注「待行驶中验证」
    行程平均油耗 / 平均车速 / 时间 / 距离 0x643，b0-b7 油耗 BCD、车速 km/h、时间 BCD、距离 20 位×0.1 km 与仪表行程电脑一致
    仪表时钟 0x683，b0 / b1，BCD 时 / 分 BCD 与本车仪表钟一致（本车约慢 3 分钟）

    读取方法与注意事项

    第一是速率设置：把记录器设成 50K、静默（Silent）模式，并在协议上选 slcan 以便抓包；源文档提醒设成 500K 会完全看不到流量。第二是总线上没有的东西：增压压力、发动机负荷、进气温度与故障码都在 K 线上，CAN-only 的记录器看不到；源文档把这条写进「不在本总线」一节。

    第三是时间边界的陷阱。源文档给出三条：车钥匙拔出时整条总线静默，什么也读不到；熄火瞬间的最后一帧会「说谎」（油量 0、驻车制动释放、发动机仍报运转），不要基于该边沿做自动化；判断发动机是否运转要用「转速 > 300」，不要用 0x281 的 b1 位 7——它在仅通电、发动机未启动时就是 1，熄火最后一帧和行驶后 ECU 继续发送约 20 秒时也会误报。

    第四是数据回读的取舍：里程、续航与油量没有过期机制，停车时会保留最后值，但在重启或 MQTT 重载后会变成未知值，直到下次通电；需要的话要在自己一侧加保留（retain）。此外作者提到，同一 ID 上的多个按位条目在实践中不一定都能可靠发布，所以灯、刹车、转向被合成一个 24 位原始值再在上层拆分。

    证据等级与边界

    可视为实车证据的是绝大多数条目——源文档逐条写了验证方式（踩踏板、切灯、GPS 对比、与分流计/仪表比对）。属于明确未完成的是油量（本文档尚未在本车加油时交叉核对，数字来自另一台车）与瞬时油耗（标注为待行驶中验证）。

    不能外推的地方有两处。第一，这台是改装房车，车门、房车门与储物柜共用一条回路，所以 0x380 只能给「某个门开着」，不能分辨具体是哪扇门——同平台不同车身（van、底盘车、房车）的门路会不同。第二，源文档只测试了这一台 Ducato X250；同平台的 Jumper/Boxer 未测试，年款差异也可能改变 ID 与位定义。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；它是纯监听项目，明确「不要在总线上发送报文」。本文只整理公开文档登记的只读信号。

    常见问题

    Ducato X250 的 OBD 口能读到发动机数据吗？

    能读到一部分。源文档说明 OBD 引脚 6/14 是 50 kbit/s 的车身 CAN，引脚 7 是 K 线的发动机 ECU；转速、冷却液温度、车速、里程、续航这些被广播到车身网上的量，CAN-only 记录器可以只监听读到，而增压压力、负荷、进气温度与故障码在 K 线上读不到。

    为什么设成 500K 看不到任何报文？

    因为这张 OBD 口的车身 CAN 跑在 50 kbit/s，源文档说 500 kbit/s 上什么都没有。应设为 50K。

    怎么判断发动机是否在运转？

    用「转速 > 300」。源文档明确不要用 0x281 的 b1 位 7：它在仅通电、发动机未启动时就是 1，熄火最后一帧和行驶后 ECU 继续发送约 20 秒时也会误报。

    为什么熄火后油量显示为 0？

    因为源文档记录熄火瞬间的最后一帧会给出异常值（油量 0、驻车制动释放、发动机仍报运转）。作者建议不要基于这个边沿触发自动化，并让实时传感器用超时机制转为「不可用」而不是冻结。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/README.md（主来源：车辆、总线、取数路径与坑点）。
    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/docs/can-id-reference.md（逐 ID 的信号表与验证方式）。
    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/captures/README.md（5 段真实抓包的用途说明）。

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

    更新记录

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

  • Holley EFI 的 29 位 CAN ID：通道索引与参数解码档案

    结论：Holley EFI 系统（HP / Dominator V4+、Terminator X、Sniper V2+ 等）用的是29 位扩展 CAN 标识符，而且把「命令位 + 目标 + 通道索引 + 源 ID + 源序列号」编进 ID 本身。文档记录的结构是：位 28 为命令位（等于 1）、位 27:25 为目标（等于 111 表示广播）、位 24:14 承载通道索引 / 参数标识、位 13:11 为源 ID（等于 010 表示 ECU）、位 10:0 为 ECU 序列号低 11 位。读取侧的关键一步是用 ECU 序列号的低 11 位做过滤（例如序列号 19838 对应 0x57E，即 1406）。默认波特率是 1000000（1 Mbit/s）。边界：源文档是工具说明，参数含义来自官方 DBC，本文不为其数值或安全阈值背书。

    本文整理自该解析工具的 CAN 部分文档。它记录的是「怎么把 Holley 的 ID 与 DBC 对起来」，而不是某一台车的出厂网络定义。

    车辆与适用范围

    这里的「车型」应理解为被记录的 Holley EFI 平台，而非某一款整车：文档适用的产品线是 HP / Dominator（V4+）、Terminator X 与 Sniper（V2+），解码依据是官方 DBC 文件。文档没有绑定到某台具体车辆，也没有给出硬件型号随年款变化的说明。

    项 内容
    车型 / 平台 Holley EFI 系统：HP / Dominator（V4+）、Terminator X、Sniper（V2+）
    年款 / 市场版本 源文档未给出（按产品代次表述）
    ECU / 改装状态 面向后装电喷 ECU；示例 ECU 序列号 19838（CAN ID 中使用 0x57E）
    采集跨度 源文档未给出；示例为一段实时会话与一份 candump 日志
    适用范围 工具与 ID 结构说明；不含具体车辆的整网定义

    总线与寻址

    文档明确使用 29 位扩展标识符，并给出默认波特率 1000000（1 Mbit/s）。没有提到 CAN FD，也没有给出 11 位寻址的用法。ID 的位域划分本身就是寻址方式的一部分，见下表。

    项 内容
    物理层 CAN，默认波特率 1000000（1 Mbit/s，文档默认值）
    链路层 29 位扩展标识符
    寻址 ID 内置：命令位（位 28）、目标（位 27:25，111 为广播）、通道索引（位 24:14）、源 ID（位 13:11，010 为 ECU）、源序列号低 11 位（位 10:0）
    CAN FD 源文档未提及
    多 ECU 按 ECU 序列号低 11 位过滤，用于多 ECU 同总线场景

    已解码信号

    下表分两部分：ID 位域（用来定位是哪个 ECU、哪个通道）与参数（由官方 DBC 解码的量）。源文档是工具说明，未对单个参数标注置信度；参数含义来自官方 DBC，安全阈值则是「可配置的代码取值」，不是厂商规格。

    条目 位置 解码 / 含义 证据
    命令位 ID 位 28 等于 1 表示命令 源文档 ID 结构说明
    目标 ID ID 位 27:25 111 表示广播 源文档 ID 结构说明
    通道索引（参数标识） ID 位 24:14 标识具体参数通道 源文档 ID 结构说明
    源 ID ID 位 13:11 010 表示 ECU 源文档 ID 结构说明
    源序列号（低 11 位） ID 位 10:0 取 ECU 序列号低 11 位；例：19838 用 0x57E（1406） 源文档 ID 结构说明
    RPM 示例 0x9E005000，ECU 1406，通道 8 DBC 解码；示例值 6500 rpm 源文档示例输出
    FUEL_AFR_AVERAGE DBC 消息 由 DBC 解码 源文档配置示例
    OIL_PRESSURE DBC 消息 由 DBC 解码；文档阈值 警告 30 psi、危险 20 psi 源文档阈值表
    COOLANT_TEMP DBC 消息 由 DBC 解码；阈值 警告 210 华氏度、危险 230 华氏度 源文档阈值表
    机油温度 DBC 消息 阈值 警告 250 华氏度、危险 280 华氏度 源文档阈值表
    燃油压力 DBC 消息 阈值 警告 40 psi、危险 30 psi 源文档阈值表
    爆震退点火 DBC 消息 阈值 警告 2 度、危险 4 度 源文档阈值表
    增压 DBC 消息 阈值 警告 20 psi、危险 25 psi 源文档阈值表
    转速阈值 RPM 参数 警告 7000、危险 8000 源文档阈值表
    DL 日志参数 二进制日志列 Param_002 = RPM、Param_066 = TPS，共 516 个参数 源文档参数表

    读取方法与注意事项

    先按序列号过滤。解析器会自动提取 ECU 序列号的低 11 位用于匹配，因此多 ECU 同总线时，必须先填对序列号，否则会同时看到别的 ECU 的消息。

    DBC 决定字段含义。参数名与单位来自官方 DBC（文档列出的文件包括 HP Dominator & Terminator X DBC.dbc、Sniper V2 DBC.dbc、HARDWIRE HOLLEY DBC FILE.dbc）。DBC 放错或不匹配，字段会解不出或解错。文档建议把 DBC 放在同目录或用 --dbc 指定完整路径。

    实时与离线两条通道。实时侧可直接监听 can0 等接口（无需先跑 candump），也可把 candump 文本通过管道或文件喂给解析器；输出支持人类可读、JSON、CSV 与实时仪表盘四种格式，仪表盘可按 --minmax 跟踪最小 / 最大值并同时 --record 录制。

    二进制日志的格式差异。同一仓库还处理 .DL / .DLZ 日志：.DLZ 先做字节交换、RLE 解压、再字节交换；.DL 分 V3（魔数 0x0095365F）、V4 / V5（魔数 0x0085F41F）与 V6。文档说明 V5 为稀疏存储、无法直接解析，需要先在官方软件里打开转换成 V6；V6 可端到端解析。

    证据等级与边界

    源文档是工具说明，没有为单个参数标注置信度。表中「解码 / 含义」一列，凡属参数含义者都来自官方 DBC；凡属数值（如 RPM 6500）都是示例输出；凡属阈值（如 OIL_PRESSURE 20/30 psi）都是「代码里可配置的取值」，文档原文即写明可配置，因此不能当作厂商规格或安全红线。

    范围边界同样清楚：这套 ID 结构与 DBC 面向的是 Holley 的后装 EFI 平台，不是某一款整车的出厂网络；文档未绑定具体车辆、年款或整车网络，也未提供实车验证结论。任何字段值、阈值或「安全」判断，都应回到你自己的 ECU、DBC 与实车数据上复核，不能跨平台外推。

    常见问题

    Holley EFI 的 CAN ID 为什么用 29 位？

    因为它要在 ID 里同时编码「谁发的、发给谁、哪个通道、什么命令」。文档给出的划分是：位 28 命令、位 27:25 目标（111 广播）、位 24:14 通道索引、位 13:11 源 ID（010 为 ECU）、位 10:0 源序列号低 11 位。

    总线上有多个 ECU，怎么只看其中一个？

    按 ECU 序列号过滤。解析器自动取序列号的低 11 位做匹配，例如序列号 19838 对应 ID 中的 0x57E（1406）；填错序列号会解到别的 ECU 的消息。

    默认波特率是多少？

    文档默认值是 1000000，即 1 Mbit/s。可在命令行用 --bitrate 覆盖。

    .DLZ 和 .DL 是什么关系？

    .DLZ 是压缩日志，文档给出的解压步骤是字节交换、RLE 解压、再字节交换。解出的 .DL 分 V3 / V4 / V5 / V6；其中 V5 为稀疏存储、不能直接解析，需在官方软件里转成 V6 才能端到端解析。

    文档里的阈值能当安全结论用吗？

    不能。文档原文写明这些阈值是「代码里可配置」的取值，不是厂商规格或安全红线。它们只用于实时仪表盘的红 / 黄 / 绿显示，实际判断需回到你自己的标定与实车数据。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/hackinglz-holley-efi/can/README.md（本项目车型档案主来源，取用了 Holley CAN ID 结构与参数阈值表）。
    • 项目 01 —— public-can-dbc-datasets/additional/hackinglz-holley-efi/README.md（取用了 DL / DLZ 日志格式与参数列说明）。

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

    更新记录

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