结论：这份档案的对象是随某类商业诊断工具发布的一套 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（署名—相同方式共享），衍生作品需以相同许可发布；商用或打包分发前应先核对条款。原文中出现的第三方贡献者名单与本档案无关，未予引用。
延伸阅读
- 车型协议的 DBC 指纹：靠什么把一辆车认成它自己 —— 解释本文为何要「先定总线、再查 ID」。
- 公开 DBC 数据集的整理：来源、版本与可信度分层 —— 与本文「仅供参考、不受支持」的定位同题。
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 判读本文示例报文时的通用参照。
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 对应本文「信号可能随更新变化」的时效性提醒。
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 与 ID 复用同属「同名不等于同物」的问题。
参考资料
- 项目 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
发表回复