ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

DBC文件长啥样?一次拆透BO_和SG_

DBC文件长啥样?一次拆透BO_和SG_ DBC就是个文本文件别被后缀吓住。这篇拿一段真实DBC逐行注释BO_怎么读、SG_里起始位/长度/大小端三要素怎么定、factor和offset怎么换算再讲3个新手必踩的坑。想要DBC速查表评论DBC。我第一次拿到DBC文件是供应商邮件发来的附件Engine.dbc200多KB。我双击系统弹出来问用什么程序打开——我愣住了。搞测试的居然被一个文件后缀难住了。后来才知道这玩意儿用记事本就能打开里面全是纯文本。今天这篇就带你把DBC文件真正打开看一遍。看完你会发现DBC没那么玄核心就两行。DBC就是个文本文件别把它当黑盒先破除一个误区DBC不是二进制不是什么专用格式就是文本。用记事本、VS Code都能打开能进git做版本管理diff一下就知道供应商这次改了哪几个信号。一个DBC文件里90%的内容你这辈子都不用细看。真正天天打交道的就两行BO_定义一条报文Message报文的身份证SG_定义报文里的信号Signal信号的说明书剩下的BU_节点列表、VAL_值表、CM_注释都是打辅助的后面顺带提一句。BO_报文的身份证一行就四件事看这段真实的BO_ 100 WheelSpeed: 8 Vector__XXX逐个拆一个都别放过100报文ID。注意是十进制。0x64四个轮速信号的报文。WheelSpeed报文名见名知意就行。8DLC数据长度8字节。Vector__XXX发送节点。这里是占位写法实际项目里会写成EMS、BCM这种真实节点名。这里埋着第一个坑。DBC里的ID是十进制抄到代码里记得转十六进制。更坑的是扩展帧DBC里存的不是真实ID而是真实ID | 0x80000000。比如诊断常用的0x18DAF110在DBC里会写成25644853920x98DAF110。我第一次见到这种天文数字ID真以为文件坏了还给供应商打了电话——对方在电话那头笑了半天。SG_信号的说明书三要素加换算报文是信封信号才是信。继续看BO_ 100 WheelSpeed: 8 Vector__XXX SG_ WheelSpeedFL: 0|161 (0.1,0) [0|6553.5] km/h Vector__XXX SG_ WheelSpeedFR: 16|161 (0.1,0) [0|6553.5] km/h Vector__XXX拿左前轮速这一行开刀0|16起始位0长度16位。这是三要素的前两个。1字节序Intel小端。0是Motorola大端——三要素的第三个。无符号。-代表有符号。(0.1,0)factor0.1offset0。换算用的。[0|6553.5]物理值范围。65535×0.16553.5对上了。km/h单位。Vector__XXX接收节点。换算公式就一个刻在脑子里物理值 原始值 × factor offset来个实战的。Trace里抓到ID 0x64的报文前两个字节是2C 01。这个信号是Intel小端低字节在前拼出来raw0x012C300。300×0.130.0左前轮速30km/h。反过来呢想往总线上发45.5km/hraw(45.5-0)/0.14550x01C7小端低字节在前填C7 01。这里容易写反注意反推时先减offset再除factor别直接拿物理值去除。大小端DBC里最绕的一块单独拎出来说1是Intel0是Motorola死记硬背容易混理解了就忘不掉。Intel小端起始位指的是信号最低位LSB的位置。数据像搭积木从低字节往高字节直着拼上面那个轮速的例子就是0|16bit0到bit15一口气占满byte0和byte1顺得很。Motorola大端起始位指的是信号最高位MSB的位置。从MSB开始往低位排排到字节边界会拐弯——像锯齿一样折到下一个字节的高位继续。这是DBC里最反直觉的地方。我在这上面结结实实栽过一次。一个项目里供应商DBC把发动机转速写成7|160Motorola。我当时图省事按Intel去解了解出来的转速忽大忽小跟台架对不上。查了半天Trace最后发现起始位的含义搞反了Motorola的7指的是MSB在bit7不是从bit7往高处长。改过来数值瞬间正常。记住这句就行看到0先问自己MSB在哪别急着拼字节。新手3个常犯错误对着查第一个ID进制搞错。DBC里BO_ 100是十进制写CAPL或者脚本时要转成0x64。扩展帧那个天文数字ID真实ID|0x80000000更是重灾区第一次见的人十个有九个懵。第二个符号位没注意。有符号信号最高位是符号位raw0xFFFF对无符号是65535对有符号是-1。我见过有人把带符号的扭矩信号按无符号解析扭矩一变负就飙到六万多还以为是传感器坏了。第三个信号位重叠或者DBC版本对不上实车。8字节的帧里两个信号占了同一个bitCANdb打开直接报错这还算好的。最阴的是版本问题DBC是v1.2实车刷的是v1.1固件某个信号起始位差了8位解出来的值永远差一截怎么查Trace都查不出原因。记住一条铁律DBC解出来的值对不上先怀疑版本再怀疑人生。顺带认识几个配角VAL_是值表给枚举信号配文字的VAL_ 100 GearPos 0 P 1 R 2 N 3 D;BU_列出所有节点CM_是注释。BA_属性定义初期不用深究知道有这么个东西就行。收个尾DBC拆到底就是两句话BO_定报文SG_定信号。信号再往下就是三要素起始位、长度、大小端加换算factor、offset加符号。下次供应商甩给你一个DBC别再双击发愣了直接用文本编辑器打开先找BO_再看SG_骨架就有了。想要DBC速查表评论区扣DBC我整理一份BO_/SG_字段速查发你。你第一次打开DBC的时候最懵的是哪一行评论区聊聊。这里是车软学堂每天一篇汽车电子测试实战。关注我明天讲用Trace快速定位问题信号的3个方法ID过滤、触发条件、找特定值附一个真实排查场景。 往期推荐第一次打开CANoe先看懂这3个窗口汽车电子测试工程师每天到底在干啥五大质量工具之FMEA失效模式分析刚入行做汽车电子测试先搞懂这5个概念DoIP诊断实战——以太网时代的UDS怎么调视觉通用智能来了一篇论文重新思考AGI未来的AI可能首先要“看懂世界”啃完这本开源教材大模型的底层逻辑我算是理清了从零开始用ComfyUI跑MiniMaxH3本地安装、云端和视频工作流搞懂UDS诊断从这篇开始——测试应用层工程师实战指南
返回列表