星核火花赛车科技

标签： 车型档案

  • Tesla 分总线 DBC 档案：同一 CAN ID 的两种报文

    结论：这份档案的对象是随某类商业诊断工具发布的一套 Tesla 平台 DBC，按「一条总线一份 DBC」拆分，另有一份 _shared 文件承载确实跨多总线的报文。它的数据特征不是某个信号的值，而是「同一个 CAN ID 在不同总线上是不同的报文」：例如 0x3D8 在动力总线上可能是 3 字节的 DC-DC 变换器状态，在底盘总线上却是 8 字节的 GPS 位置——一个编号、两条无关报文。正因如此，源文档给出的定位原则是用发送者（transmitter）字段标注报文属于哪条总线。源文档明确这套 DBC 「仅供参考、不受支持」，且其发布方不逆向信号，因此本文只记录结构与少数示例，不构成完整信号地图。

    车辆与适用范围

    源文档是一份 DBC 仓库说明加许可证。它描述的是数据组织方式与使用约定，而非某一台车的采集记录。

    项 内容
    车型 Tesla 各平台（源文档按「每个平台若干份 DBC」组织，未逐一点名具体车型）
    年款 / 市场版本 源文档未确认；并提示 Tesla 可能在不通知的情况下更新信号
    ECU / 改装状态 无改装；表现为可导入诊断工具的 DBC 定义文件
    采集跨度 源文档未提供日志数或帧数（其致谢提及来自社区提供的总线日志）
    适用范围 仅作参考、不受支持；发布方不逆向信号，用户须自行编辑与维护解码信息

    总线与寻址

    源文档的组织原则是「一个总线一个 DBC」，核心动因就是 ID 复用问题。

    项 内容
    物理层 / 比特率 源文档未给出
    寻址方式 源文档未给出；示例 ID 为 11 位量级（0x102、0x399）
    组织方式 按总线拆分：动力、底盘等各一份，另加一份 _shared 承载真正跨总线的报文
    跨总线识别 约定用发送者字段标识报文所在总线；_shared 内报文不带总线标签，在每个通道上都解码
    CAN FD 源文档未提供
    ID 复用示例 0x3D8：动力总线为 3 字节 DC-DC 状态；底盘总线为 8 字节 GPS 位置

    已解码信号

    源文档是 DBC 的说明文档，只举了少量示例。下表登记源文档实际给出的条目（含两个示例信号、一个 ID 复用示例与两类属性约定），并逐条标注出处；源文档没有提供逐信号清单，这一点在表格之后另有说明。

    条目 位置（ID / 属性） 含义 / 解码 证据
    BMS_packCurrent ID 258（0x102） 高压电池电流；被赋显示名「HV Battery Current」 显示名属性示例
    DAS_autopilotState2 ID 921（0x399） 枚举含 DISABLED/UNAVAILABLE/AVAILABLE/ACTIVE_NOMINAL/ACTIVE_RESTRICTED/ACTIVE_NAV/ACTIVE_FSD/ABORTING/ABORTED/FAULT/SNA 取值配色属性示例
    DC-DC 变换器状态 0x3D8（动力总线） 3 字节报文 ID 复用说明
    GPS 位置 0x3D8（底盘总线） 8 字节报文；与上面同编号但无关 ID 复用说明
    显示名属性 属性名（源文档用到具体属性键） 为信号指定在界面上显示的名称 属性说明
    取值配色属性 属性名（源文档用到具体属性键） 为枚举值指定颜色；合法值含 NONE、BLUE、GREEN、INDIGO、ORANGE、PINK、PURPLE、RED、TEAL、YELLOW、WHITE、BLACK、GRAY，也接受 3 字节十六进制色 属性说明
    _shared 报文 _shared 文件 不带总线标签，在每个通道上都解码 组织说明
    发送者字段 报文属性 按约定标明报文所在总线，导入时须开启「按发送者分配总线」 导入说明
    车辆无关定位 项目说明 工具定位为车无关，授权用户自行编辑并维护解码信息 项目说明

    读取方法与注意事项

    导入流程有一条关键约束：源文档说明在某版本的工具中，要把多份 DBC 导入同一个预设，须使用信号列表上的导入功能，因为主菜单的「打开文件」一次只能打开一份。同时有三个开关需要留意——保留不在该 DBC 内的信号/报文（以保住此前手工创建的内容）、按发送者名称尝试分配总线（必须开启）、以及保留计算信号（避免导入时删除默认预设里的计算信号）。这三项决定了导入结果是否与预期一致。

    由于 ID 复用，解析时不能只按编号索引。正确做法是：先确定当前监听的是哪条总线，再用「总线 + ID」的组合去查报文；对 _shared 中的报文才允许跨通道解码。若只有编号没有总线归属，0x3D8 这类报文会被错误地解码成另一条总线的含义。

    数据性质的提醒同样重要：源文档明确发布方不逆向 CAN 信号，并把它描述为一场「猫鼠游戏」——Tesla 可能不通知就更新信号，也不提供总线报文与信号说明。因此这套 DBC 只应作为起点，任何用于关键判断的信号都应在本车日志上复核；改进与修正通过提交合并请求汇集，可能随工具后续版本一起发布。

    证据等级与边界

    本文的证据等级是「项目说明级」：组织原则、ID 复用示例、两类属性与导入约定都能在源文档逐条核对，属直接证据；但源文档没有逐信号清单、没有比特率，也没有实车日志，因此本文只记录结构与少数示例，不提供完整信号地图。这一点与源文档「仅供参考、不受支持」的定位一致。

    两点不能外推。第一，Tesla 各平台之间的报文与信号可能不同，源文档按平台分别组织 DBC，把某一平台的条目外推到另一平台属于超范围。第二，信号可能随 Tesla 的更新而变化，源文档对此已明确提示；任何跨时间、跨软件版本的外推都缺乏依据。此外须注意许可：设备与设计文件采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布，商用前应先核对条款。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理 DBC 的组织与示例。

    常见问题

    为什么这些 DBC 要按总线拆成好几份？

    因为 Tesla 可能在不同总线上复用同一个 CAN 编号。源文档举 0x3D8 为例：动力总线上是 3 字节的 DC-DC 状态，底盘总线上是 8 字节的 GPS 位置，两者无关。按总线拆分并用发送者字段标注归属，才能避免解码串线。

    导入多份 DBC 时要注意什么？

    源文档提示：要在同一预设里导入多份 DBC，须用信号列表上的导入功能（主菜单「打开文件」一次只能开一份）；并按需处理三个开关，其中「按发送者名称尝试分配总线」必须开启，否则总线归属会错。

    这套 DBC 能直接用于关键判断吗？

    不建议。源文档明确发布方不逆向信号，把维护描述为「猫鼠游戏」，Tesla 可能不通知就更新信号，且这套 DBC「仅供参考、不受支持」。用于关键判断的信号应在本车日志上复核，也可通过提交修正参与维护。

    许可上有什么限制？

    该数据集采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布；商用或打包分发前应先核对条款。原文中出现的第三方贡献者名单与本档案无关，未予引用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/README.md（本项目车型档案主来源：按总线拆分 DBC 的原则、ID 复用示例、两类属性与导入约定）。
    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/LICENSE.md（CC BY-SA 4.0 许可条款）。

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

    更新记录

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

  • Mercedes-Benz W212 仪表台：CAN E 状态图与唤醒帧

    结论：2010 款 Mercedes-Benz E350（W212）的组合仪表是一个可以单独上台架的 CAN 节点：20 针连接器里只有 7 针有关，接上 500 kbit/s 的 CAN E 就能点亮。源文档用「试验法」（逐位扫描观察仪表反应）找出了 0x001 的状态编码与唤醒帧，并把 CAN E 的上电状态整理成一张状态图。以下所有结论仅限源文档记录的这一个仪表台。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 W212 E350 组合仪表的台架逆向记录。项目的目标是把这个仪表台用于模拟赛车，因此在台架上重建了它的供电与 CAN 环境，再逐条找出让它显示、点亮的报文。

    项 内容
    车型 Mercedes-Benz E350（W212），2010 年
    对象部件 组合仪表（cluster）；20 针 A1 连接器，其中只有 7 针有关：1 / 4 / 6 为供电，12 / 13 为 CAN E，17 / 18 为 CAN B
    台架硬件 Arduino Mega 2560 加 Seeed CAN-BUS Shield V2.0（MCP2515 控制器）；两个 120 Ω 终端电阻
    台架参数 500 kbit/s；MCP2515 晶振 16 MHz；串口 115200 baud
    适用范围 仅限源文档记录的这个仪表台；不适用于其他年款或其他配置的 W212

    总线与寻址

    因为是「只把一个仪表台搬上台架」，环境被大大简化：没有整车、没有网关，只有仪表自身与台架控制器之间的两条总线。

    项 内容
    总线 CAN E（引脚 12 / 13）、CAN B（引脚 17 / 18）
    速率 500 kbit/s
    终端 两个 120 Ω 电阻
    控制器 MCP2515（经 Arduino Mega 2560 驱动）
    ID 约定 源文档的 DBC 中消息 ID 记为十进制，使用前必须转成十六进制
    状态可读性 仪表上电后自身会发出若干帧（0x015、0x39D），可作为机器可读的状态指示

    已解码信号

    下表从源文档的记录中抽取。项目把已确认的编码与仅来自 DBC 命名、尚未在台架上触发的条目分开，本文原样保留标注。

    信号 位置（ID / DID / 字节） 解码 证据
    CAN E 状态 0x001 B0 枚举：00=OFF、04=Minimal full ON、C2=Limited/ACC-like、CC=Alternate full ON、CF=Delayed OFF、07=过渡候选 已确认（试验法逐位扫描）
    唤醒 0x045 载荷 00 00 00 00 FF 00 00 00 已确认
    OK 按钮 0x045 载荷 00 00 00 00 FF 02 00 00 已确认
    车门状态 0x283 55 = 全关；56 = 左前门开 已确认
    状态指示 A 0x015 3D FE 00 00 与 00 FE 00 00 两种 标定记录
    状态指示 B 0x39D B0 及末字节 B0：80 或 FF；末字节为存活计数器（07, 0F, …, 7F） 标定记录
    驱动控制（DRIVER_CONTROLS） 0x045（DBC 十进制 69） — 标定记录
    点火（IGNITION） 0x245（DBC 十进制 581） — 未确认（静态搜索无响应）
    轮速（WHEEL_SPEEDS） 0x203（DBC 十进制 515） — 标定记录
    安全带（SEATBELT_SENSORS） 0x375（DBC 十进制 885） — 标定记录
    油门（GAS_PEDAL） 0x105（DBC 十进制 261） — 标定记录
    挡杆（GEAR_LEVER） 0x06D（DBC 十进制 109） — 标定记录
    挡位包（GEAR_PACKET） 0x073（DBC 十进制 115） — 标定记录

    读取方法与注意事项

    第一条是接线与终端。20 针连接器里真正有用的是 7 针：1 / 4 / 6 是供电，12 / 13 是 CAN E，17 / 18 是 CAN B。台架上需要接两个 120 Ω 终端电阻，否则总线反射会让通信不稳定。

    第二条是 ID 进制。源文档的 DBC 把消息 ID 记成十进制（如 69、581、515），而 CANID 是十六进制的——所以 DRIVER_CONTROLS 十进制 69 对应 0x045，IGNITION 十进制 581 对应 0x245。解析前必须先做这个换算，否则会对着错误的 ID 收发。

    第三条是「试验法」。项目找编码的方式是逐位扫描 0x001 的字节并观察仪表反应，从而归纳出 ON/OFF 的取值（如 00 表示 OFF、04 表示最小开启、C2 表示受限/类似 ACC、CC 表示另一种全开）。源文档还记录了一个细节：让保持开启成立的是约 450 毫秒的 07 脉冲。

    证据等级与边界

    项目有一条很好的「机器可读验证」手段：仪表上电后自身会发回 0x015（其值在 3D FE 00 00 与 00 FE 00 00 之间变化）和 0x39D（首字节 80 或 FF，末字节是存活计数器），因此台架可以用这些回发帧判断仪表当前处于什么状态，而不必靠肉眼观察。这比单纯看背光亮不亮更可靠。

    但也存在明确未解项。0x245（IGNITION）在静态搜索下没有任何响应，源文档把它归入未解与下一步清单。此外，若干信号（轮速、安全带、油门、挡杆、挡位包）只是按 DBC 命名列出，尚未在台架上逐一触发验证，本文按「标定记录」而非「已确认」标注。

    边界上必须强调：以上编码、载荷与状态图都限定在源文档记录的这个仪表台（2010 款 W212 E350）上。台架环境与整车环境不同——整车上有网关与其它节点参与，仪表台在整车上的行为未必与台架一致；不同年款或配置的仪表也可能使用不同的编码。

    常见问题

    为什么只接 7 根线就能点亮这个仪表？

    因为源文档确认 20 针连接器里只有 7 针有关：1 / 4 / 6 供电，12 / 13 为 CAN E，17 / 18 为 CAN B。其余针脚在该用途下不需要。台架上再接两个 120 Ω 终端即可组成可通信的最小系统。

    0x001 的状态值是怎么找出来的？

    用试验法：逐位扫描 0x001 的字节并观察仪表反应，归纳出各取值的含义（00=OFF、04=最小开启、C2=受限/类似 ACC、CC=另一种全开、CF=延时关闭、07=过渡候选）。源文档还指出让「保持开启」成立的是约 450 毫秒的 07 脉冲。

    怎么判断仪表当前处于什么状态？

    用仪表自己发回的帧作为机器可读指示：0x015 的值在 3D FE 00 00 与 00 FE 00 00 之间切换，0x39D 的首字节为 80 或 FF、末字节是存活计数器（07, 0F, …, 7F）。据此判断状态比看背光是否点亮更可靠。

    台架上找出来的结论能直接用到整车上吗？

    不能直接套用。台架是把这个仪表台从整车中独立出来，缺少网关与其它节点。同一仪表台在整车上的行为可能与台架不同，不同年款或配置的仪表也可能使用不同编码。实车使用前必须重新验证。

    延伸阅读

    参考资料

    • 项目 10 —— public-can-dbc-datasets/additional/izakulus-w212-cluster-notes/README.md（本项目车型档案主来源：接线、台架参数、状态图与未解清单）

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

    更新记录

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

  • 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

  • Ford Fiesta MK5 影音 CAN 档案：125 kbps 车身信号

    结论：这份档案的对象是2006 年以后的 Ford Fiesta MK5（改款，配 2-DIN 与 6000CD 收音机）的影音 CAN（MS-CAN）。它的数据特征是「低速、易接入、以车身与影音信号为主」：总线速率 125 kbps，从收音机 QuadLock 连接器的 CANH/CANL 即可旁听，不需要 120 欧姆终端电阻；可见内容包括仪表显示屏文字（经 ISO-TP）、电台名、音量、CD 状态、时间、车门/车灯/挡位/踏板等。源文档只覆盖这一台改款 Fiesta 与这台 6000CD 收音机，且其定义文件不完整，部分报文只做到部分解码；下述结论不外推到其他年款或配置。

    车辆与适用范围

    源文档是一份逆向记录：作者以「截取收音机送给仪表 LCD 的文字」为起点，顺带解出若干其他报文。以下范围仅对应这一台车与这台收音机。

    项 内容
    车型 Ford Fiesta MK5，2006 年以后（MK5 改款），配 2-DIN 与 6000CD 收音机
    年款 / 市场版本 源文档以「>2006 改款」界定；其他年款与市场版本未确认
    ECU / 改装状态 无改装；在收音机 QuadLock 连接器的 CANH/CANL 上旁接一块 CAN 扩展板
    采集跨度 源文档未提供日志时长或帧数
    适用范围 仅这一台改款 Fiesta 与 6000CD 收音机的影音 CAN；定义文件不完整，部分报文仅部分解码

    总线与寻址

    源文档对物理层描述简练而具体：接入选定在收音机端，且对终端条件有明确说明。

    项 内容
    物理层 / 比特率 MS-CAN，125 kbps
    寻址 / 帧格式 源文档列出的 ID 均为 11 位标准帧（0x080–0x4F3）
    接入点 收音机 QuadLock 连接器的 CANH/CANL
    终端 不需要 120 欧姆终端电阻（源文档明示）
    CAN FD 源文档未提供（该年代与总线类型指向经典 CAN）
    传输层 仪表文字使用 ISO-TP（ISO 15765-2）分帧，含单帧与首帧/连续帧/流控

    已解码信号

    下表抽取源文档中最有代表性的条目（车身状态、影音与仪表文字）。位置列保留原文 ID 与字节序号，解码列保留其换算公式；证据列注明源文档对该条目的完成度或限定。

    信号 位置（ID / 字节） 解码 证据
    日期时间 0x080 / 字节 1–6 年（两位）、月、日、时、分、秒；1 秒分辨率 车载 RTC 独立于收音机时钟
    电台名 0x1E9 / 8 字节 ASCII 文本 完全解码
    转速 / 车速 / 油门 0x201 / 字节 1–2、5–6、7–8 km_h = speed/100；gas_percent = gas*100/50944 部分字段未标注
    转向灯箭头 0x265 / 字节 1 位掩码：左 0x20、右 0x40 位掩码按需相加
    前灯 / 手刹 0x286 / 字节 1 位掩码：手刹 0x10、示宽/近光 0x80、远光 0x40 示宽与近光共用同一 LED，无法区分
    音量 0x2D8 / 字节 2 volume = volume_raw/8 完全解码
    CD 状态 0x2DA / 字节 2、4 模式 0x2A/0x4A/0x6A；驱动器 0x23/0x21/0x22/0x26 枚举表完整
    CD 曲目 / 时间 0x2DB / 字节 3–4、6 曲目时间 track_seconds = track_time - 64；另含 track_id 非播放时为全 FF
    方向盘模式/选台键 0x2D5 / 字节 2 位掩码：模式 0x10、上选 0x40、下选 0x80 音量键不经此报文
    制动状态（一） 0x360 / 字节 6 未踩 0x60、轻搭 0x68、踩下 0x78 同一状态在两报文重复
    冷却液 + 制动（二） 0x420 / 字节 1、6 coolant_degrees = coolant - 40；制动 0x00/0x10/0x30 两处制动编码不同
    蓄电池电压 0x428 / 字节 2 battery_v = battery/10（十分之一伏） 完全解码
    车门 / 倒挡 / 锁止 0x433 / 字节 1、4、6 门位掩码：左前 0x80、右前 0x40、后备箱 0x08；倒挡 0x02；锁 0x10/解锁 0x20 位掩码完整
    仪表文字 0x4C0 / 短格式与扩展格式 短格式：0x07 0x34 + ASCII；扩展格式：首帧 0x10 + 长度 + 0x34，连续帧 0x21 + ASCII 为 ISO-TP；配套 0x4C8 流控
    车辆识别（VIN 低位） 0x4F3 / 8 字节 周期性广播的车辆 ID（VIN 低位，含生产日期信息） 完全解码

    读取方法与注意事项

    接入非常直接：源文档说明只需把 CAN 接口接到收音机 QuadLock 连接器的 CANH/CANL，无需 120 欧姆终端电阻。这一条与多数两节点试验台的接线习惯相反，源文档把它作为结论明确写出，实际接线时不要凭经验加终端。

    仪表文字那一类是ISO-TP（ISO 15765-2）传输：短格式只在收音机切到 AUX 模式时可见，形如「首字节标志 + 0x34 + ASCII」；扩展格式由一条含文本长度的首帧加若干条提供后续文本的连续帧组成。响应里随后出现的 ACK 报文提供流控：字节 1 为 0x30 表示「可继续发送」，字节 2 为 0x00 表示不做分帧流控，字节 3 为 0x00 表示按发送方最快速度。解析这类文本时，必须按 ISO-TP 的帧类型分别处理，而不能把每条 ID 当独立报文读。

    还有一处容易混淆：制动状态在两条报文里重复出现但编码不同——0x360 用 0x60/0x68/0x78，0x420 用 0x00/0x10/0x30。同一物理状态的多套编码要求解析方选定一个来源并保持口径一致。此外，音量键并不经方向盘那条报文（0x2D5 只覆盖模式与选台键），源文档对此如实标注为「似乎如此」。

    证据等级与边界

    本文属于单台实车逆向观测：ID、字节与换算公式均可在源文档逐条核对，属于直接证据；但源文档没有给出采集时长、帧数或时序，也未声明校验与计数器机制（除 ISO-TP 流控外）。随文档提供的定义文件（某类商业诊断工具的 .kcd 格式）源文档明确标注为不完整，因此不能把它当作完整协议描述。

    两点不能外推。第一，全部内容来自一台「2006 年以后改款」的 Fiesta 与一台 6000CD 收音机；换成其他年款、其他市场版本或其他音响配置，ID 与编码都可能不同。第二，多个报文只做到部分解码，源文档用「unspecified」标记了未解析字节；把这些字节当作已知信号会超出源文档证据。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理只读旁听所能看到的内容。

    常见问题

    接入这条总线要不要加 120 欧姆终端？

    不需要。源文档明确：把 CAN 接口接到收音机 QuadLock 的 CANH/CANL 即可，不用终端电阻。这与多数两节点试验台的接线习惯相反，接线时按源文档结论来，不要凭经验加终端。

    仪表屏的文字是怎么传的？

    走 ISO-TP（ISO 15765-2）。短格式如同「0x07 0x34 + ASCII」，只在 AUX 模式可见；扩展格式由带文本长度的首帧（0x10 + 长度 + 0x34）加若干连续帧（0x21 + ASCII）组成，随后有 0x4C8 流控 ACK。解析时必须按 ISO-TP 帧类型分别处理。

    为什么同一制动状态有两种编码？

    因为在源文档里它被两条报文重复承载：0x360 用 0x60/0x68/0x78，0x420 用 0x00/0x10/0x30。这是源文档记录的实际状态，解析时应选定一个来源并保持口径一致，不要混用两套编码。

    随文档提供的定义文件能当完整协议看吗？

    不能。源文档明确标注该文件（某类商业诊断工具的 .kcd 格式）不完整，多处字节以「unspecified」标记为未解析。把它当作完整协议描述会引入未经证实的字段。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/roncapat-ford-fiesta-mk5/README.md（本项目车型档案主来源：总线速率、接入方式、全部已解码 ID 与换算公式）。

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

    更新记录

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

  • CarCluster 仪表注入：13 个 Simhub 字段与 13 款仪表盘

    结论：这份档案记录的是一个反方向的 CAN 项目：不是从车上读信号，而是用 ESP32 + MCP2515 把 PC/游戏数据注入真实仪表盘，让一台退役的原车仪表在桌面上工作。源文档最可直接引用的是它的输入字段表——Simhub 集成示例把 13 个字段（车速、挡位、转速、最大转速、左右转向、机油温度、暂停、运行、油量百分比、手刹、ABS、TC）映射进这套固件。硬件与支持的仪表清单同样值得记录，但要注意：多款较新仪表（如 T-Cross）存在组件保护，一旦触发无已知解法。

    车辆与适用范围

    源文档是一个开源桌面项目，目标是驱动真实仪表盘，主要用于游戏，也可作时钟等用途。硬件极简：一块 ESP32、一个 MCP2515 CAN 模块、一个 12V 电源。

    项 内容
    车型 面向多种车型仪表盘（VW PQ35/MQB/PQ46、BMW F/E 系、Mercedes W204/W221、Mini F55/F56/F57、Opel Corsa E 等）
    年款 / 市场版本 随平台不同；源文档未统一给出年款，示例为 VW Polo 5、Golf 7、Škoda Superb 2、BMW F10/F30 6WA、E60、E46、W204/W221 等
    ECU / 改装状态 退役仪表盘 + 自制电源/线束；部分平台需逻辑电平转换（如 E46）、数字电位器模拟油位
    采集跨度 源文档未给出；无整车采集，数据来自游戏或网页界面
    适用范围 仅限源文档明确「已完整测试并支持」的仪表型号；相近平台「可能可用但需按具体车型修改」

    总线与寻址

    物理连接对普通爱好者很友好：ESP32 Devkit 板 + 通用 MCP2515 CAN 模块，另可用项目自制的转接 PCB 或跳线/面包板两种接法。仪表侧接线按平台各有专门文档。

    项 内容
    物理层 ESP32 板 + MCP2515 CAN 模块 + 12V 电源；E46 需逻辑电平转换
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出
    CAN FD 源文档未提及
    仪表侧接线 按平台各有一份接线文档（PQ/MQB/BMW F/E60/E46/MB W204/W221/Opel Corsa E）

    已解码信号

    这份主素材不是从整车抓包的信号表，而是注入端的数据字段映射。下表逐条来自源文档给出的 Simhub 集成更新消息格式，是文档中唯一逐字段列出的信号清单，括号内为默认值（若有）。

    字段 键名 含义 / 默认值 证据
    车速 spe 车速（km/h），取整 Simhub 更新消息示例
    挡位 gea 挡位字符串，空值默认 P Simhub 更新消息示例
    转速 rpm 当前转速，空值默认 0 Simhub 更新消息示例
    最大转速 mrp 红线转速，空值默认 8000 Simhub 更新消息示例
    左转向灯 lft 左转向指示，默认 0 Simhub 更新消息示例
    右转向灯 rit 右转向指示，默认 0 Simhub 更新消息示例
    机油温度 oit 机油温度，默认 0 Simhub 更新消息示例
    游戏暂停 pau 是否暂停，默认 0 Simhub 更新消息示例
    游戏运行 run 是否运行，默认 0 Simhub 更新消息示例
    油量百分比 fue 计算得到的燃油百分比，默认 0 Simhub 更新消息示例
    手刹 hnb 手刹状态，默认 0 Simhub 更新消息示例
    ABS abs ABS 是否激活，默认 0 Simhub 更新消息示例
    TC tra 牵引力控制是否激活，默认 0 Simhub 更新消息示例

    读取方法与注意事项

    初始化流程在源文档里很明确：下载项目后用 Arduino IDE 打开 Carcluster.ino，在 BEGIN USER CONFIGURATION 段选择目标仪表盘（例如把 #define CLUSTER 1 改成 3 使用 Golf 7 仪表），其余参数按具体仪表配置；项目已内置所需库，无需额外安装。烧录后 ESP32 会开一个名为 CarCluster 的 Wi-Fi 热点（密码 carcluster），连上后跳转 192.168.4.1 选择要接入的网络；若 3 分钟内未配置，则进入串口模式，可配合 Simhub 使用。

    两个易踩的坑：一是接上 CAN 模块时可能无法烧录，需先断开再上传；二是部分 ESP 板的串口不支持全速，会出现「板子无响应」之类错误，此时把 SERIAL_BAUD_RATE 改成 460800，并同步修改串口监视器、Simhub 与 Arduino 的上传速度。仪表侧的功能自测可以用网页界面（可设转速、车速等）来验证。Simhub 目前只支持 USB 连接、不支持 Wi-Fi。

    证据等级与边界

    本档案属于项目登记 + 集成示例。字段表本身是源文档写死的键名，可核对；「某款仪表盘被完整支持」是作者自测结论；至于实车报文，本项目并不产生——它是把游戏/PC 数据注入仪表，信号方向与整车抓包相反。

    三处不能外推。第一，字段表是注入协议，不是任何一辆车的 CAN 信号定义，不能当成车型档案使用。第二，平台相近不等于可用：源文档明说「相近平台可能可用，但需按具体车型修改」。第三，组件保护是硬边界：较新的 MQB 仪表（如 T-Cross）在未知时间后会进入组件保护模式，闪屏且多数指示灯失效，目前无已知解法，应避免使用。

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

    常见问题

    CarCluster 是从车上读信号吗？

    不是，方向相反。它把 PC/游戏的数据注入真实仪表盘，让仪表显示外部数据；项目目的是在桌面使用退役仪表，而非从整车抓包。

    为什么有些仪表盘不能用？

    以 VW T-Cross 为代表的新款 MQB 仪表会在未知时间后进入组件保护模式，闪屏且多数指示灯失效，源文档明说目前无已知解法，建议改用较老的 Golf 7 等。

    哪些仪表盘支持得最好？

    源文档给出的入门推荐顺序是：Mercedes 某几款仪表、BMW F 系仪表、VW MQB 系仪表；并列出已完整测试支持的具体型号，其中 W204/W221、BMW F10/F30 6WA、E46 等标为完整支持，E60 标为「部分支持、开发中」。

    注入的信号都有哪些？

    源文档的 Simhub 集成示例列出 13 个字段：车速、挡位、转速、最大转速、左右转向灯、机油温度、暂停、运行、油量百分比、手刹、ABS、TC。它们都有默认值，缺省时按默认显示。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/r00li-carcluster/README.md（本项目车型档案主来源：硬件、支持的仪表清单、Simhub 字段映射与安装说明；本快照仅含此文件）。

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

    更新记录

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

  • Chevrolet Impala 2008：怠速采集的 50 个 ID

    结论：Chevrolet Impala（2008 款）是一辆典型的「HS-CAN 直读」车：500 kbps、11 位标准帧，源文档在 6 次采集中识别出 50 个唯一 ID，并把解码整理成 22 条消息、71 个信号的 DBC。但它有一个必须说清的限制：所有采集都在静止怠速下完成，因此车速与轮速的换算公式从未被运动数据验证过。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 2008 款 Chevrolet Impala 的 HS-CAN 采集与解码。项目用多次定向采集诱发特定开关动作，再结合公开的 GM 数据库做交叉对照。

    项 内容
    车型 Chevrolet Impala，2008 款
    年款 / 市场版本 2008 款；具体市场版本源文档未确认
    采集构成 5 次约 15 秒的定向采集（用于诱发特定开关），加 1 次约 90 秒的基线采集
    采集状态 全部为静止怠速；源文档明确此时没有轮速与车速数据
    适用范围 仅限源文档记录的这一台车；结论不适用于其他年款或平台

    总线与寻址

    这辆车没有复杂的多总线结构或隐藏网关，接入相对直接。它的问题不在「能不能抓到」，而在「抓到后能证明到哪一步」。

    项 内容
    总线 HS-CAN；OBD-II 引脚 6 / 14
    速率 / 帧格式 500 kbps；11 位标准帧
    唯一 ID 数 50 个（6 次采集合计）
    DBC 22 条消息、71 个信号
    外部交叉引用 与公开的现代 GM Global A 数据库比对，50 个 ID 中有 20 个能匹配
    网关 源文档未记录网关行为；按同年款 GM 车的一般结构为单一 HS-CAN

    已解码信号

    下表从源文档的 Quick-Reference 解码表中抽取。项目对已被运动数据验证过的条目与仅靠怠速数据推出的条目做了区分，本文原样保留「未验证」标注。

    信号 位置（ID / DID / 字节） 解码 证据
    发动机转速 0x0C9 源文档更正：byte 0 是高半字节滚动计数器，不参与 RPM 计算 已确认
    制动开关 0x0C9 位标志 已确认
    制动压力 0x0F1 — 已确认
    挡位 PRNDL 0x1F5 枚举 已确认
    喷油脉宽 0x191 — 已确认
    冷却液温度 / 进气温度 0x4C1 — 已确认
    机油温度 0x4D1 — 已确认
    燃油轨压 0x4F1 — 已确认
    VIN 0x514 / 0x4E1 / 0x52A 多帧拼接为文本 已确认
    方向盘转角 / 角速度 0x1E5 — 已确认
    横加速度 / 横摆率 0x1E9 — 已确认
    电源模式 0x1F1 枚举 已确认
    车门 / 安全带 0x12A 位标志 已确认
    车速 0x3E9 公式存在，但未由运动数据验证 未验证
    轮速 0x348 / 0x34A 公式存在，但未由运动数据验证 未验证

    读取方法与注意事项

    第一条是采集设计。由于全部采集都在静止怠速下完成，任何与「车在动」相关的量都无法闭环：车速与轮速的换算公式虽然在文档里给出了，但没有运动数据能证明它对。若要把这些公式当作可用结论，必须补做一次实际行驶的采集。

    第二条是数据字段的坑。转速信号的 byte 0 曾被当成数据参与计算，源文档更正指出它其实是高半字节滚动计数器——这类「带头字节」的报文在很多车上都存在，把计数器当数据会引入周期性误差。处理多字节数值前，应先确认前导字节是否为计数器或状态位。

    第三条是外部对照的限度。项目把本车的 50 个 ID 与公开的现代 GM Global A 数据库比对，有 20 个能匹配。但这是跨世代的对照，只能作为线索，不能代替在本车上的实测——匹配上了不代表字节位置与刻度在本车上也一致。

    证据等级与边界

    源文档区分了「已确认」与「未验证」两类。已确认的多为怠速下就能观测的开关量、温度与静态值；未验证的集中在与运动强相关的车速与轮速。此外源文档指出，转向灯信号在这辆车的 HS-CAN 上并没有被找到——这是一个负向结论，说明该信号可能在别的总线或不经 CAN 传输。

    还有三处必须如实交代的边界。第一，源文档的 DBC 中，加速踏板位置字段从 bit 48 开始，但该消息被声明为 3 字节，两者不一致，说明这一条布局尚未定稿；第二，声称的原始采集文件并不在项目快照中，因此无法用原始数据复现结论；第三，上游 DBC 文件缺少仓库许可证信息，使用时需自行确认授权。

    适用范围上必须强调：以上 ID、字段与公式都限定在这一台 2008 款 Impala 上，且以怠速数据为主。不同年款、不同平台的车辆，ID 布局与刻度都可能变化；跨车使用前必须重新采集验证。

    常见问题

    为什么车速与轮速被标为「未验证」？

    因为全部 6 次采集都在静止怠速下完成，源文档明确此时没有轮速与车速数据。虽然文档给出了换算公式，但没有任何运动数据能证明它对。要确认这些公式，必须补做一次实际行驶的采集。

    转速信号里为什么要排除 byte 0？

    因为源文档更正指出 byte 0 是高半字节滚动计数器，不参与转速计算。早期把 byte 0 当数据会引入周期性误差。这类「带头字节」在车上很常见，解析多字节数值前应先确认前导字节是否为计数器或状态位。

    和公开 GM 数据库匹配上就代表正确吗？

    不代表。项目只做到 50 个 ID 里有 20 个能匹配现代 GM Global A 数据库，但这是跨世代对照，只能作为线索。匹配成功不等于字节位置与刻度在本车上也一致，仍需在本车实测确认。

    这份 DBC 可以直接拿来做产品吗？

    需谨慎。源文档已指出三处问题：加速踏板字段位置与消息长度声明不一致、原始采集文件不在快照中（无法复现）、上游文件缺少许可证信息。使用前应自行确认授权并补做缺失的验证。

    延伸阅读

    参考资料

    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/analysis/gm/chevy_impala_2008.md（本项目车型档案主来源：解码表、ID 清单与置信度）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/README.md（车辆覆盖与 DBC 文件清单）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/SOURCE.md（采集状态、DBC 规模与已知问题）

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

    更新记录

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

  • Western Formula Racing 的 PECAN 遥测链

    结论：这份档案记录的是 Western Formula Racing（学生方程式车队）的整车遥测链：车辆 CAN 报文由车上的树莓派 + CAN HAT 采集，打包成 UDP/TCP 经无线电发到基站，再经 Redis 广播到 WebSocket，最终在浏览器仪表板（PECAN）上实时显示，并落库到 TimescaleDB 供历史查询。它的价值是一条从总线到仪表盘的完整数据通路，而不是逐条信号解码：CAN 报文的分类由一份可配置清单管理（VCU、BMS、INV、TEST MSG 等），逐条定义放在 DBC 里。需要说明的是，本快照只包含项目 README，DBC 与逐条信号未包含在内。

    车辆与适用范围

    源文档是车队开源的数据采集系统仓库，覆盖车辆侧与基站侧两端软件，以及一台用于无实车测试的仿真器。

    项 内容
    车型 Western Formula Racing 方程式赛车（车队项目 PECAN）
    年款 / 市场版本 源文档未给出具体赛季，仅出现运行数据标识 ECU_25
    ECU / 改装状态 车队自研 VCU、BMS、逆变器等部件，构成车辆 CAN 报文来源
    采集跨度 源文档未给出日志数或帧数；提供 CSV 回放样例与仿真器
    适用范围 仅限该队的这套软硬件；逐条信号定义见其 DBC（公开样例在仿真器内，私有部分在受限子模块）

    总线与寻址

    数据流在源文档里以流程图给出：车辆 CAN → 树莓派 CAN HAT（SPI/CAN）→ 车上树莓派（原生 systemd 服务）→ 射频 UDP/TCP → 基站 → Redis → WebSocket → PECAN 仪表板；基站还可把解码后的 CAN 帧直接写入服务器的 TimescaleDB，由 Grafana 做历史可视化。

    项 内容
    物理层 车辆侧树莓派 CAN HAT（经 SPI 接口）读取 CAN 总线
    链路层 / 比特率 源文档未给出
    寻址方式 支持标准 CAN ID 与扩展 CAN ID 两类
    CAN FD 源文档未提及
    传输端口 UDP 5005、TCP 重传 5006、本地 PECAN WebSocket 9080、基站地址 10.71.1.20

    已解码信号

    本快照只含项目 README，DBC 本体与逐条信号未包含在内。为守住「只抄源文档里有证据的条目」这条线，下表登记 README 明确写出的报文类别与数据资产，并逐条注明证据；任何具体报文 ID、字节与缩放系数，源文档均未提供。

    条目 归属 / 位置 说明 证据
    VCU 报文 车辆 CAN 类别 整车控制单元报文类别 README「CAN Message Categories」
    BMS 报文 车辆 CAN 类别 电池管理系统报文类别 README「CAN Message Categories」
    INV 报文 车辆 CAN 类别 逆变器报文类别 README「CAN Message Categories」
    TEST MSG 车辆 CAN 类别 测试报文类别 README「CAN Message Categories」
    类别配置清单 pecan/src/assets/categories.txt 文本配置即可改分组与配色，无需改代码 README「CAN Message Categories」
    标准 / 扩展 CAN ID WS 后端 广播服务支持两类 ID README「WebSocket Backend」
    蓄能器仿真 WS 后端 内置 accumulator 仿真 README「WebSocket Backend」
    样例 CAN 数据 car-simulate/（CSV） 可回放的录制数据 README「Car Simulator」
    样例 DBC car-simulate/ 报文定义示例文件 README「Car Simulator」
    私有 DBC secret-dbc/ 子模块 受限的私有 DBC 文件 README「Project Structure」
    运行数据标识 ECU_25 Flight Recorder 记录的上传标识 README「Flight Recorder」
    实时遥测包 UDP 5005 车上→基站的实时流 README「Car RPi Deployment」
    重传包 TCP 5006 丢包重传通道 README「Car RPi Deployment」
    本地广播 WebSocket 9080 车载 Pi 上的本地 PECAN 数据源 README「Car RPi Deployment」

    读取方法与注意事项

    车辆侧不用容器：遥测栈以原生 systemd 服务 car-telemetry.service 运行，配置为 ROLE=car、基站地址、UDP 5005、TCP 重传 5006、本地 WebSocket 9080。部署步骤是 uv sync 后在服务文件里填入 git 短哈希，再 systemctl enable/start。这一点值得注意：车上运行时依赖与基站不同，车上没有 Docker 与 Redis。

    基站侧则用 Docker Compose 起整套栈（Redis、WebSocket、状态页、视频中继，可选 TimescaleDB 日志）。在笔记本上有一份现成的 .env.macbook 默认配置可直接拉起；在 Windows 上还需要保留一个 PowerShell UDP 中继窗口，因为 Docker Desktop 不会把局域网 UDP 转发进容器。

    没有实车时，可用仿真器回放 CSV 数据来做开发与自检：car-simulate 提供 CSV 回放、常驻 WebSocket 广播与示例 DBC。另有一条「Flight Recorder」路径，用手机在车辆热点上记录数据到浏览器 IndexedDB，等有网时再通过 POST /api/can-frames/batch 同步到服务器。

    证据等级与边界

    本档案属于项目登记，可核对的是系统架构、端口、部署方式与配置文件名；不能据此推出车辆具体有哪些信号，因为逐条定义在未被本快照收录的 DBC 里。

    三处不能外推。第一，报文类别（VCU/BMS/INV/TEST MSG）是可配置的分组名，不是信号清单——它由 categories.txt 决定，改配置即可变。第二，公开样例 DBC 与私有 DBC 是两回事：公开的仅用于仿真器开发，实际车辆定义在受限子模块 secret-dbc/，本快照未包含。第三，端口（5005/5006/9080）与基站地址是这套部署的默认值，换环境即需调整。

    关于「安全访问」类问题：本文只整理公开文档登记的数据通路，未涉及诊断写入或安全访问；源文档未提供绕过方法，且不建议尝试。

    常见问题

    PECAN 能读到哪些信号？

    源文档未给出逐条信号。它说明报文按可配置清单分组（示例为 VCU、BMS、INV、TEST MSG），逐条定义放在 DBC 里；本快照未包含该 DBC。

    车辆侧是怎么读 CAN 的？

    车辆侧树莓派接 CAN HAT，遥测软件以原生 systemd 服务运行，把报文打包成 UDP 5005 发送，另有 TCP 5006 用于重传；车载 Pi 上还有本地 WebSocket 9080。

    没有实车怎么测试？

    用 car-simulate 仿真器：回放 CSV 录制数据、常驻 WebSocket 广播，并附带一份示例 DBC；开发时无需连接真车。

    DBC 在哪里？

    公开样例在仿真器目录内；实际车辆定义位于受限子模块 secret-dbc/。本快照只包含项目 README，未包含任何 DBC 文件。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/western-formula-racing/README.md（本项目车型档案主来源：系统架构、数据流、部署与配置；本快照仅含此文件）。

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

    更新记录

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

  • BYD Atto 3 档案：Chassis 与 Private 双总线分工

    结论：这份档案的对象是一台 2024 年款、右舵出口版的 BYD Atto 3（元 PLUS EV）。它的数据特征是双总线分工：在 P13 摄像头连接器处接入后，Chassis CAN（引脚 4/8）为 500 kbit/s 经典 CAN、8 字节帧，承载转向、车速、踏板、挡位等整车状态，读与写都在这里；Private CAN（引脚 3/7）为 CAN-FD、数据段近 2 Mbit/s，承载摄像头、前向雷达与约 72 个来源未确认的经典格式 ID。整车消息在发送前需补一个字节校验，纵向与横向命令只允许三条报文。以下所有结论仅来自这一台车，中国国内版本与其他年款可能不同。

    车辆与适用范围

    源文档明确：全部数据来自一辆车——2024 年款右舵出口版 Atto 3；并把「换车前的检查项」单列一节。以下范围只对应这一辆。

    项 内容
    车型 BYD Atto 3 / 元 PLUS EV，2024 年款，右舵出口版（VIN 世界厂商标识 LGX）
    年款 / 市场版本 2024 右舵出口版；中国国内版本与其他年款可能不同（源文档明示）
    ECU / 改装状态 P13 摄像头连接器处旁接；以红熊猫板作 CAN 接口；无原厂设备，因此无 IMU，改用 CAN 桥接
    采集跨度 源文档未给出日志时长或帧数；给出整车质量 1750 kg、轴距 2.72 m、转向比 19.8
    适用范围 仅这一台 2024 右舵出口车；换车须重新测量连接器（BYD 用过两个摄像头供应商，连接器不同）

    总线与寻址

    数据来自 P13 摄像头连接器，共 8 个腔位、6 个接线。两条 CAN_H 同为粉色、两条 CAN_L 同为紫色，源文档要求按引脚位置而非颜色识别总线。

    项 内容
    Chassis CAN 引脚 4/8；经典 CAN，500 kbit/s，8 字节帧；本系统的读与写都在此
    Private CAN 引脚 3/7；CAN-FD，数据段近 2 Mbit/s；承载摄像头、雷达与约 72 个来源未确认的经典格式 ID
    寻址 / 帧格式 整车消息为经典 11 位 ID 格式；私有总线为 FD 帧，含 32 字节与 64 字节两类
    终端 在旁接点处为 Chassis CAN 增加终端，因为接入设备会在摄像头连接器处断开总线
    供电 引脚 1 = 摄像头地，引脚 2 = IG1（受控 12V）；点火状态也可从 CAN 推断

    已解码信号

    下表抽取源文档中带明确报文、缩放或位域的信号。位置与解码保留原文写法；证据一列注明来源，凡源文档标注为「未确认」的均原样保留。

    信号 位置（报文 ID / 字段） 解码 证据
    转向角 STEER_MODULE_2 0x11F / STEER_ANGLE_2 0.1 度 / LSB 源文档状态解码表
    驾驶员力矩 STEERING_TORQUE 0x1FC / DRIVER_TORQUE 0.1 Nm / LSB；用于人工接管判定，阈值 18 Nm 源文档；符号正值为左
    EPS 电机力度 0x1FC / MAIN_TORQUE 电机输出，非驾驶员输入 源文档
    EPS 状态 0x1FC 低半字节（位而非枚举） bit0 LKS_PREPARED、bit1 CRUISE_ACTIVATED、bit3 恒 1；0x318 恒 0xFF 源文档；状态 11 需 0.5 s 去抖
    车速 WHEELSPEED_CLEAN 0x1F0 16 位原始计数，0.0713 km/h 每计数 源文档
    单轮转速 WHEEL_SPEED 0x122 / WHEELSPEED_BR 14 位；bit 62 为有效位 源文档
    挡位 / 点火 DRIVE_STATE 0x242 任意有效挡位即视为点火接通 源文档
    制动状态 DRIVE_STATE 0x242 / BRAKE_PRESSED 已去抖；须与安全模块读同一信号 源文档
    油门 PEDAL 0x342 / GAS_PEDAL 不采用 DRIVE_STATE.RAW_THROTTLE 源文档
    转向灯 STALKS 0x133 — 源文档
    方向盘按钮 PCM_BUTTONS 0x3B0 SET / RES / LKAS / 车距 / ACC 开 源文档
    巡航状态 ACC_HUD_ADAS 0x32D / ACC_STATE 2 可用、3 与 5 已启用、7 错误（摄像头总线） 源文档
    偏航角速度 YAW_RATE 0x222 / YawRate 0|12@1+ × 0.002133 − 2.094 rad/s；另含偏置字段需相减 源文档 IMU 桥接节
    平面加速度 AXAY 0x223 / Ax、Ay 0|12@1+ 与 24|12@1+，× 0.027167 与 × 0.027127 m/s² 源文档；Ay 需反号
    雷达目标 私有总线 0x280–0x289 轨道含 TRACK_ID、LONG_DIST、LAT_DIST、VLEAD 等 源文档；COUNTER12_1/2 字段已修正

    读取方法与注意事项

    接入前先做识别。源文档指出：查询固件版本要用 0xF195（SUPPLIER_SOFTWARE_VERSION），因为 BYD 的 ECU 拒绝本平台默认的 0xF188；总线 0 上有 24 个 ECU 应答 0xF195，其中六个返回固件版本（摄像头、制动/IPB、EPS、前向雷达、驱动单元、安全气囊），版本载荷是 6 个原始字节而非 ASCII。摄像头 ECU 不应答固件查询，须设为非必需。

    发送前必须补校验：Chassis CAN 上被签名的 12 条消息，其校验是最后一字节，data[7] = (~sum(data[0:7])) & 0xFF；本系统只发送三条——转向角命令 0x1E2、HUD 帧 0x316、纵向命令 0x32E。0x1E2 按 50 Hz 发送（每两帧中的一帧为 100 Hz），而原车摄像头是 33 Hz。转向命令须在启用期间持续发送，包括静止时也要发请求位为 0 的空闲帧——出现间隙会让 EPS 进入状态 11 并闭锁，单靠随后发 STEER_REQ = 1 无法解除。

    私有总线的完整性另有一套：每条帧的第 0 字节是校验，形式为 CRC8(poly=0x1D, init=0x00, data[1:32]) XOR K[id]；64 字节 ID 的两半各自独立保护，K 是逐报文常量、并入 init/xorout/DataID，不是 CAN ID 的函数，需从本车日志逐 ID 采集。另需注意：源文档修正了雷达 DBC 中两个字段的解读——COUNTER12_1/COUNTER12_2 并非 12 位计数器，第 0 与第 32 字节是帧校验、计数器是第 1 与第 33 字节的低半字节。

    还有一处几何修正：雷达 LONG_DIST 以后轴中心（ISO 8855 车体坐标系）为原点，而非传感器面，需减去 3.60 m（前悬 885 mm + 轴距 2720 mm）后才是相对车头距离；不修正会让每个前车读数偏远 3.6 m，修正后雷达与视觉在 12 m 内一致到 0.5 m 以内。

    证据等级与边界

    本文属于单台实车观测：报文、缩放与位域都在源文档里按车辆实测列出，并标注了去抖时间、保活与几何修正等工程条件。但证据范围的边界同样清楚：源文档在末尾单列一节强调，全部数据来自一辆 2024 右舵出口版；中国国内版本与其他年款可能不同，BYD 还使用过两个摄像头供应商、连接器不同，换车必须重新测量连接器。此外，若用不带继电器直通的旁接线束，本系统运行时没有硬件回退；源文档建议使用带直通继电器的线束盒。

    一处不确定性必须原样保留：EPS 掉线前的状态字段被某份未合并的草稿 DBC 命名为 TORQUE_TEMP_FAILED（取值 1 "TooLarge"、2 "TooFast"），但源文档明确——没有 BYD 官方文档、没有 EPS 诊断码、也没有其他分支能确认该命名，应视为未确认；文档给出的转角上限结论并不依赖该命名。另据源文档，ABS/ESP 侧的转向限值表现为一个恒定的偏航率：EPS 在乘积约 3155 及以上放弃车道保持，故取 3000 留余量，不要抬高到 3155 或观测均值 3578。

    关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理源文档记录的可读信号与发送约束。

    常见问题

    为什么查询固件版本要用 0xF195 而不是 0xF188？

    因为源文档记录 BYD 的 ECU 会拒绝 0xF188（本平台默认的那个）。改用 0xF195 后，总线 0 上有 24 个 ECU 应答，其中六个返回固件版本；版本载荷是 6 个原始字节而非 ASCII，摄像头的 MPC ECU 不应答、须设为非必需。

    Chassis CAN 上发送报文要注意什么？

    两条硬约束。其一，被签名的 12 条消息必须补末字节校验 data[7] = (~sum(data[0:7])) & 0xFF；其二，本系统只允许发送 0x1E2、0x316、0x32E 三条。转向命令还要 50 Hz 连续发送、静止时发请求位为 0 的空闲帧，避免 EPS 进入状态 11 并闭锁。

    雷达距离为什么要减 3.6 m？

    因为 LONG_DIST 的原点是后轴中心（ISO 8855 车体坐标系），不是传感器面。需减去前悬 885 mm 加轴距 2720 mm 共 3.60 m 才得到相对车头距离；不修正每个前车会偏远 3.6 m，修正后在 12 m 内与视觉一致到 0.5 m 以内。

    TORQUE_TEMP_FAILED 这个信号名可信吗？

    不可信。源文档明确：该命名来自一份未合并的草稿 DBC，没有 BYD 文档、没有 EPS 诊断码、也没有其他分支能确认，应视为未确认。文档给出的转角上限（约 3000 / 车速）并不依赖这个命名。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/shemps-byd-atto3/README.md（本项目车型档案主来源：线束与总线拓扑、指纹、状态解码、校验、横向与纵向控制、雷达与 IMU 桥接、适用性边界）。

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

    更新记录

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

  • Nissan Leaf ZE0：LBC 块数据与只读遥测

    结论：Nissan Leaf（ZE0，2011–2012）最反直觉的一点是：它不实现标准 OBD-II PID——连发送 `0100` 都返回 NO DATA。要读电池，必须用 UDS 服务 0x21 向 LBC（锂电池控制器）索取整块数据（如 39 字节一组的电流、电压、SOC、容量）。同时 Car-CAN 上还有一批被动广播帧（档位、转向灯、里程、车门等）可直接监听。源文档的架构默认只读，从不发送会改变车辆状态的指令。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目为 Nissan Leaf 开发的只读遥测仪表盘。项目通过 ELM327 适配器读取标准与非标准数据，并用离线回放、模拟与 MQTT 等多种无车模式做测试，源码中带有大量离线测试用例。

    项 内容
    车型 Nissan Leaf（ZE0 世代）
    年款 2011–2012
    接入方式 ELM327（BLE 或 USB）；源文档另记录自 2026-10-03 起用 CANable 2 接入 Car-CAN
    采集跨度 两个车辆 profile：Leaf 版 18 项 / 61 个信号 / 33 条历史列；另一台对照车为纯标准 Mode 01（19 项 / 20 个信号）
    适用范围 仅限源文档记录的这台 Leaf；年份、电池版本与固件差异都可能改变可用数据块

    总线与寻址

    这辆车的读取要分两条路走：一条是主动的 UDS 块数据读取，另一条是被动的广播帧监听。两者的传输参数完全不同。

    项 内容
    Car-CAN 500 kbit/s；11 位标准帧；引脚 6 / 14
    EV-CAN 引脚 13 / 12；源文档要求强制只监听
    适配器参数 `ATSP6`（ISO 15765-4，11 位 500 kbit/s）
    UDS 寻址 向 LBC 请求用 `ATSH 79B`，接收用 `ATCRA 7BB`；读取服务为 0x21
    被动监听 必须关闭自动格式化（`ATCAF0`）才能拿到原始帧
    标准 OBD-II 本车不实现标准 PID，发送 `0100` 返回 NO DATA
    实测吞吐 CANable 2 在 Car-CAN 上约 1,692 帧/秒、49 个 ID、0 错误帧

    已解码信号

    下表从源文档的信号清单中抽取。项目的置信度分三档：verified（已确认）、static（静态常量）、tentative（暂定），本文按源文档标注保留。

    信号 位置（ID / DID / 字节） 解码 证据
    高压电流 LBC 数据块 01 s32 ÷ 1024 A verified
    电池包电压 LBC 数据块 01 u16 ÷ 100 V verified
    12 V 电压 LBC 数据块 01 u16 ÷ 1024 V verified
    绝缘电阻 LBC 数据块 01 kΩ verified
    SOC（荷电状态） LBC 数据块 01 u24 ÷ 10000 % verified
    可用容量 LBC 数据块 01 u24 ÷ 10000 Ah verified
    单体电压 LBC 数据块 02 96 × u16，单位 mV，量程 3000–4200 mV verified
    电流（第二通道） LBC 数据块 05 16 位回绕：±32 A 之外按 64 A 折叠 verified（2026-09-03 定案）
    档位 Car-CAN 0x421 枚举 verified
    转向灯 Car-CAN 0x358 位标志 verified
    整车里程 Car-CAN 0x5C5 — verified
    车门 / 锁 / 灯 Car-CAN 0x60D 位标志 verified
    车速 Car-CAN 0x284 — verified
    续航 Car-CAN 0x5A9 — verified

    读取方法与注意事项

    第一条是「不按标准 OBD 走」。多数车用 Mode 01 就能读到车速、转速等，但本车不实现标准 PID：`0100`（查询支持哪些 PID）返回 NO DATA。因此不能指望通用的 OBD 诊断 App 直接读出电池信息，必须走 UDS 服务 0x21 向 LBC 请求数据块。

    第二条是块数据的规模与时序。LBC 的第一个数据块约 39 字节，包含电流、电压、SOC、容量等多个字段；单体电压块则是 96 个 16 位值（对应电池单体），量程约 3000–4200 mV。源文档实测在 CANable 2 上，Car-CAN 约 1,692 帧/秒、49 个 ID、零错误帧，一次完整的 96 节电芯读取约 351 毫秒——这给出了「块读取能不能满足刷新需求」的量化参考。

    第三条是回绕陷阱。数据块 05 的电流是 16 位字段：当真实电流超出 ±32 A 时，读数会按 64 A 折叠回绕。也就是说，读到一个看似很低的电流，可能其实是对应的大电流。源文档在 2026-09-03 把这一行为定案。

    证据等级与边界

    源文档的置信度分三档：verified 表示已在实车或离线回放中确认；static 表示该字段在该车上恒为常量；tentative 表示暂定。表中所列以 verified 为主，原样保留标注。此外项目还保留一台对照车的纯标准 Mode 01 profile，用来区分「Leaf 特有的非标准读取」与「通用 OBD 路径」。

    安全边界方面，源文档明确记录了这套工具会发送与不会发送的内容：只发送 UDS 服务 0x21（只读）、标准 Mode 01/03/07，以及适配器自身的监听模式；从不发送会清除或改写 ECU 的指令。EV-CAN 上强制只监听。这一设计把「读车」与「改车」彻底分开。

    适用范围上必须强调：以上数据块布局、字段刻度与广播 ID 都限定在这一台 2011–2012 年的 ZE0 上。不同年份、不同电池容量版本（如 24/30/40 kWh）的 Leaf，其数据块与可用 PID 都可能不同，跨车使用前必须重新核对。

    常见问题

    为什么普通的 OBD 诊断 App 读不到这辆车的电池？

    因为本车不实现标准 OBD-II PID，发送 `0100` 会返回 NO DATA。通用 App 依赖标准 PID，自然读不到。要读电池必须用 UDS 服务 0x21 向 LBC（用 `ATSH 79B`、`ATCRA 7BB`）索取数据块。

    为什么读到的电流有时明显偏小？

    因为数据块 05 的电流是 16 位字段，真实值超出 ±32 A 时会按 64 A 折叠回绕。看到的低值可能对应实际的大电流，需要按回绕规则还原。源文档在 2026-09-03 确认了这一行为。

    被动监听需要什么特殊设置？

    源文档要求关闭自动格式化（`ATCAF0`），否则适配器会把原始帧「翻译」成标准格式，丢失块数据所需的信息。EV-CAN 上则强制只监听。整轮循环在实测硬件上约 0.58 秒完成。

    这套读取方式安全吗？

    源文档的设计是只读：只发送服务 0x21、标准 Mode 01/03/07 与监听模式，从不发送清除或改写指令，EV-CAN 强制只监听。即便如此，任何实车操作仍应自行复核并遵守当地法规。

    延伸阅读

    参考资料

    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/README.md（本项目车型档案主来源：只读架构、profile 与安全边界）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/SIGNALS.md（数据块字段、置信度分级与广播帧表）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/CAN_TRANSPORT.md（适配器参数与实测吞吐）

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

    更新记录

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

  • GM Global-A 档案：Chevrolet Express 广播数据

    结论：这份档案的对象是一台 2007 年款 Chevrolet Express 的 GMLAN High Speed 广播数据，源文档并主张同一份 DBC 可用于多数 2000 年代中期、使用该总线且采用 11 位帧头的通用（GM）车辆。它的数据特征是「只有范围声明，没有信号清单」：主素材是许可证文本，连同项目说明在内，源文档只交代了平台、总线与帧头宽度，未提供任何逐信号解码表、比特率或字节定义。因此本文能确认的只是「这份 DBC 面向哪一类车、哪条总线、哪种帧头、读到的是哪类数据」，具体信号必须回到 DBC 文件本身（本快照未包含）。

    车辆与适用范围

    源文档是一份随公开数据集发布的项目说明与许可证。它描述的是数据的适用范围与许可，而非某一台车的信号地图。

    项 内容
    车型 2007 年款 Chevrolet Express（作为创建该 DBC 的取样车）
    年款 / 市场版本 取样车为 2007 年款；源文档主张适用于「多数使用 GMLAN High Speed 总线的 2000 年代中期 GM 车」——该主张未经独立验证
    ECU / 改装状态 源文档未提供；DBC 的定位是只读读取广播数据
    采集跨度 源文档未提供（无日志数、事务数或时长）
    适用范围 限定于 GM Global-A 平台、采用 GMLAN High Speed 与 11 位帧头的车辆；同平台其他年款是否一致，源文档未给证据

    总线与寻址

    源文档对总线的描述只有寥寥数语，足以定位类别，但不足以直接解析。

    项 内容
    物理层 / 比特率 源文档未给出（仅指明为 GMLAN High Speed 总线）
    寻址 / 帧头 11 位帧头（源文档明确以「11-bit headers」描述）
    总线类型 GMLAN High Speed（GMLAN 高速总线）
    CAN FD 源文档未提供；年代与总线类型均指向经典 CAN
    数据方向 读取车辆广播数据，源文档未提及任何写入用途

    已解码信号

    源文档未提供任何逐信号解码表。为保持「只写源文档里有的事实」这一原则，下表登记的是源文档实际给出的全部可确认条目（平台、总线、帧头、数据性质、许可等），并逐条标注出处；任何涉及 ID、字节与缩放的内容，源文档均未包含。

    字段 出处 取值 / 含义 证据
    取样车型 项目说明 2007 年款 Chevrolet Express 源文档直接陈述
    平台 项目说明 GM Global-A 源文档直接陈述
    总线类型 项目说明 GMLAN High Speed 源文档直接陈述
    帧头宽度 项目说明 11 位 源文档直接陈述
    数据性质 项目说明 车辆广播数据（只读） 源文档直接陈述
    文件形式 项目说明 DBC（CAN 报文定义文件） 源文档直接陈述
    更广适用性主张 项目说明 「多数 2000 年代中期使用该总线的 GM 车」——源文档以「should work」措辞给出 未验证主张，原样保留
    许可证 许可证文件 CC BY-NC-SA 4.0（署名—非商业—相同方式共享） 许可证文本
    格式说明入口 项目说明 源文档另附一个第三方 DBC 格式介绍入口，未在本档案展开 源文档直接陈述

    读取方法与注意事项

    源文档对读取条件没有展开，能确认的只有两点：其一，这份文件的用途是读取广播数据，不涉及写入或诊断会话；其二，它是一份 DBC 定义，需配合能够加载 DBC 的工具使用。至于时序、流控、填充与超时预算等工程细节，源文档均未提供，本档案不臆测。

    需要提示的一点是取证路径：源文档给出的更广适用性来自「在 2007 Express 上创建、应当可用于同期 GM 车」的推断，而不是逐车核验。若要在具体车辆上使用，正确做法是先在该车上确认总线类型与帧头宽度（11 位），再核对 DBC 中的报文是否真的出现，并且逐条检查信号是否落在合理范围——而不是因为平台相同就默认直接可用。

    此外须留意许可证的非商业（NC）限制：这份 DBC 以署名—非商业—相同方式共享 4.0 发布，任何商业用途、或与商业产品打包分发，都需先确认许可是否允许；相同方式共享还要求衍生作品以相同许可发布。这一点对量产或商用项目是硬约束。

    证据等级与边界

    本文的证据等级是「项目说明级」：全部条目都能在项目说明或许可证里逐字核对，属直接证据；但源文档既无逐信号解码，也无实车日志，因此本文不提供任何 ID、字节位置或缩放公式。对比同批其他车型档案，本项目属于素材缺失较明显的一类——主素材是许可证文本，项目说明只有一段话。

    两点不能外推。第一，「多数 2000 年代中期 GM 车可用」是源文档的未验证主张，本文原样保留该不确定性，不做加强；具体车辆是否可用必须实测。第二，取样车为 2007 年款 Chevrolet Express，其 DBC 是否与同年款同平台的其他配置一致，源文档亦未给出证据。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文仅整理只读广播数据的适用范围。

    常见问题

    为什么这份档案没有信号清单？

    因为源文档（项目说明加许可证）只交代平台、总线、帧头与数据性质，没有提供任何逐信号解码表。逐信号定义应当在 DBC 文件本身里，但本快照未包含该文件；本文不臆造 ID 与缩放。

    「适用于多数同期 GM 车」这句话能直接采信吗？

    不能直接采信。源文档用的是「should work」这类推断措辞，属于未验证主张。正确做法是在目标车上先确认总线类型与 11 位帧头，再核对 DBC 报文是否真的出现、信号是否落在合理范围。

    这份 DBC 能商用吗？

    需先确认许可。它采用 CC BY-NC-SA 4.0，其中非商业（NC）限制了商业用途，相同方式共享（SA）要求衍生作品以相同许可发布。任何商用或与商业产品打包分发都应先核对许可条款。

    它能不能用来向车辆写数据？

    源文档的定位是读取广播数据，未提及任何写入用途；本档案也不提供写操作。CAN 与诊断操作存在风险，任何实车操作前请自行复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/pddenhar-gm-express/LICENSE.md（本项目车型档案主来源：CC BY-NC-SA 4.0 许可条款）。
    • 项目 01 —— public-can-dbc-datasets/additional/pddenhar-gm-express/README.md（平台、总线类型、11 位帧头与广播数据用途的唯一文字说明）。

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

    更新记录

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