DBC 文件是什么
DBC 是一个纯文本文件，用来描述 CAN 总线上跑的内容。针对每一条报文，它会写明：报文 ID、数据长度、发送节点，以及载荷里每一个信号的名字、起始位、位长、字节序、比例、偏置、单位和取值范围。CANoe、CANalyzer、Kvaser、python-can、cantools 读的都是同一种格式——所以它才是"厂家把胎压数据交给客户工程团队"最实际的方式。
但它不是固件，也不是行为规范。它只说"位在哪"，不说"什么时候报警"、不说"传感器丢了会怎样"、更不说"第 37 号位置对应车上哪个轮子"。后面这些属于另一份文档。只发一个 DBC 就算交付的供应商，其实只给了你一半接口。
在 TPMS 项目里这个区别尤其要紧：胎压数据不是"一帧一个含义"的固定结构，它是多个轮位 + 多种状态 + 一个会随传感器掉线而变化的状态机。
为什么 TPMS 的 DBC 和发动机的不一样
动力总线上，"转速"这个信号出现一次，位置固定。胎压数据是重复的，而且行业里没有统一约定。常见三种布局：
- 一个轮位一条报文：最好读，但报文数量随机台轮数增长。4~8 个轮子没问题，160 个轮位就很别扭。
- 一条报文装多个轮位：效率高，大机器上的常规做法。代价是一帧丢失就同时丢好几个轮位。
- 位置索引 / 多路复用报文：用一个选择字段说明本帧描述哪一组轮位。紧凑，但解码变成有状态的，粗心的集成往往就栽在这里。
不管给你的是哪一种，DBC 里都必须写清楚。如果实际上是多路复用，而 DBC 里没有建多路复用信号模型，你的解析程序会读出"看起来合理但其实错误"的压力值——这比读不出来更糟。
一份能用的 DBC 必须有什么
逐条对照，每一条都在真实项目里耽误过时间。
1. 报文 ID 以及扩展帧标志。CAN 2.0B 有 11 位和 29 位两种 ID；少了扩展属性，有些工具会安静地解错帧。
2. 每条报文的 DLC，标准帧应当为 8。
3. 周期时间必须写成属性，而不是邮件里的一句话。工具读的是属性；我们接收器默认 500 ms 数据周期，这个属性要与实际配置一致。
4. 发送节点名，一眼能看出接收器是发送方、你的控制器是接收方。
5. 每个信号的字节序。Intel（小端）和 Motorola（大端）都合法，而且在解码之前长得一模一样——这是"读出来全是乱码"的头号原因。
6. 比例与偏置，以及原始量程。压力用 kPa、温度用 °C，直接可读，而不是让你心算。
7. 状态信号的值表。一个状态字节，0 = 正常、1 = 压力过低、2 = 快速漏气、3 = 传感器缺失，比裸数值有用得多。
8. 每个物理信号都写单位，写在单位字段里，不要靠名字去猜。
这八条齐了，文件在机器层面就能用。至于好不好用，是另一个问题。
通常缺的是什么
缺的东西很可预测，也正是值得你花二十分钟审一遍的原因。
报警语义。 DBC 能带一个标志位，但说不出阈值是多少、怎么改。要一份书面的标志位／阈值／默认值对照表，并问清哪些是客户可以自己配置的。
位置映射。 DBC 里没有任何东西告诉你"第三个信号实例"对应二轴左前外侧轮。你需要一张映射表，把每个监测位置对应到物理轮位，调试之前就与客户定好，之后不再变动。
超时与传感器缺失行为。 传感器停止上报时，接收器是继续发上次的值、发 0、清一个有效位，还是干脆不再发这个轮位？这四种在现实中都存在，只有一种是你的控制器需要的——而从 DBC 里看不出来。
有效位与电量位。 传感器电量低不是轮胎故障，但它会变成故障。确保它作为一个独立信号存在。
版本绑定。 要求 DBC 修订号与固件版本绑定。对不上任何发布版本的文件，半年后就是一份不能信的文件。
二十分钟验收法
不需要台架，也能把一份 TPMS DBC 粗筛一遍。用 cantools 或任何一个 CAN 工具打开，做五件事：
1. 能不能解析？ 格式错的文件工具会直接报错，能干净打开就已经过掉了最便宜的一关。
2. 报文清单和文档对得上吗？ 数一下条数，和接口文档比。对不上，说明其中一份已经过期。
3. 解一帧真实数据。 让供应商给一帧已知数值的抓包，解出来和文档里的数对一遍。如果对方给不出这一帧，这本身就是一条结论。
4. 算一下量程边界。 原始最大值 × 比例 + 偏置，结果应该是物理上合理的压力，而不是大了十倍。
5. 找重叠。 两个信号从同一个比特位开始，解析器不会报错，但实际用起来是灾难。
想看看真实硬件上这些层怎么落地，可以看 CAN 总线 TPMS 集成页；接收器支持的协议和电气参数在 TR100 接收器产品页。
除了文件还要要什么
只给一个 DBC 不算交接。还要：人可读的报文对照表、报警与阈值表、位置映射模板、接插件针脚定义，以及一个能配轮位数量、传感器 ID 和阈值的配置工具。如果接收器还有串口输出，还要寄存器表——Modbus RTU 和 RS485 的集合同样需要它。
另外，问一句"固件是谁写的"也很合理。自己掌握固件的厂家，能在你的项目需要时改一个信号或加一个标志位；靠第三方模块拼装的厂家，只会把你的需求转发出去，再带回一个更慢也更不确定的答复。
我们怎么交付
GZVIA 在深圳自研传感器、接收器、中继器、显示器和云平台，所以报文对照表和 DBC 出自写固件的同一个团队。串口集成我们给寄存器表；CAN 集成我们给帧布局、报警语义和配置工具。我们交付过 160 轮运梁车：2 台接收器 + 12 台中继器 + 160 颗传感器；单台设备实测最大 224 轮（28 轴 × 8）——长车场景对我们是日常，不是理论。
把你的控制器型号、它讲的协议、以及轮位数量发给我们，我们可以在你正式下单之前先给一份 DBC 让你审。要一份示例 DBC。