结论：这份档案记录的是 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 后缀。
延伸阅读
- 车型协议的 DBC 指纹：靠什么把一辆车认成它自己 —— 与本档案的
fingerprints.py与「指纹」约定直接对应。 - 公开 DBC 数据集的整理：来源、版本与可信度分层 —— 对照 DBC 预处理器与
_generated的版本管理。 - 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 解释为何要按品牌拆 DBC 再合成。
- openpilot 的 100 Hz 控制回路：开源 ADAS 能给车载设备什么 —— 承接本档案的横向/纵向控制能力。
- Western Formula Racing 遥测链：PECAN 的 CAN 采集到仪表 —— 同批车型档案，对照「DBC 定义」与「遥测管线」两种用途。
参考资料
- 项目 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
发表回复