车载网络测试-DBC文件解读
目录
- 1 背景
- 2 DBC结构
- 2.1 Networks
- 2.2 ECUs(Electronic Control Units)
- 2.3 Network Nodes
- 2.4 Message(报文)
- 2.4.1 Message定义、作用、示例
- 2.4.2 报文Attribute(属性)
- 2.4.2.1 常见的报文Attributes
- 2.4.2.2 其他相关属性
- 2.5 Signal(信号)
- 3 总结
1 背景
DBC文件(Database CAN)是一种用于描述CAN(Controller Area Network)网络中消息和信号的数据库文件格式。它对工程师来说具有以下重要作用:
- 定义CAN网络通信协议
- DBC文件详细定义了CAN网络中消息(Message)和信号(Signal)的格式、内容及其相互关系。
- 它规定了消息的ID、长度、周期性和信号在消息中的位置、数据类型、缩放因子、偏移量等。
- 实现通信标准化
- DBC文件确保所有节点(ECU)在通信时使用统一的协议,避免因消息格式不一致导致的通信错误。
- 它为不同供应商或团队开发的ECU提供了通用的通信标准。
- 支持工具链集成
- DBC文件可以被多种工具(如CANalyzer、CANoe、MATLAB/Simulink等)解析和使用,用于仿真、测试和分析CAN网络。
- 它简化了工程师在开发、测试和调试过程中的工作。
- 信号解析与解码
- DBC文件提供了信号的物理值和原始值之间的转换规则(如缩放因子、偏移量),帮助工程师解析CAN总线上的原始数据。
- 这对于诊断、监控和数据分析非常重要。
- 支持自动化代码生成
- 许多开发工具可以根据DBC文件自动生成代码(如C代码),用于ECU的通信层实现。
- 这减少了手动编写代码的工作量,提高了开发效率和代码的可靠性。
- 诊断和测试
- DBC文件定义了诊断消息(如UDS或OBD-II)和信号,支持故障诊断和测试。
- 它帮助工程师快速定位和解决通信问题。
- 文档化和版本管理
- DBC文件作为CAN网络的通信协议文档,便于团队协作和版本管理。
- 它记录了网络中的所有消息和信号,方便后续维护和升级。
- 支持网络仿真和测试
- 使用DBC文件,工程师可以模拟CAN网络的行为,验证通信协议的正确性和鲁棒性。
- 这对于系统集成和验证至关重要。
DBC文件是CAN网络开发、测试和维护的核心工具,它为工程师提供了标准化的通信协议定义、信号解析、自动化代码生成和网络仿真支持,极大地提高了开发效率和系统的可靠性。因此,做为汽车测试工程师来说,解读DBC文件或编辑DBC文件是必须掌握的知识。
2 DBC结构
在DBC文件中,主要由Networks、ECUs(电子控制单元)、Network nodes(网络节点)、Messages(报文)、Signals(信号)几个层级组成;是描述CAN(控制器局域网)通信网络结构和组成部分的关键属性。如下图:
2.1 Networks
- 定义:
DBC文件中的Networks
属性表示整个CAN网络的全局配置,通常包含网络的名称、波特率(通信速率)、注释等信息。它定义了网络的物理层和通信参数。 - 作用:
- 描述网络的整体结构(如波特率、协议版本)。
- 可能包含多个子网络(例如在多通道CAN系统中)。
如上图,该车型的Networks属性定义了网络名称、网络协议、备注、网络类型、网络管理的参数(NmMessageCount、NM报文基地址)
Tips:
在DBC文件中,NmMessageCount
可能是一个信号或参数,用于描述某个节点的网络管理行为;具体定义可能因厂商或项目而异,但通常它会与网络管理消息的发送次数或条件相关。
如上图,描述了该网络下的俩个ECU(CCU、ZCU_L)以及它们的一些属性,比如所属网络、地址信息、节点层模块、是否为网络管理节点
2.2 ECUs(Electronic Control Units)
- 定义:
ECUs是CAN网络中的电子控制单元,即网络中的逻辑节点。每个ECU可以发送或接收特定的CAN报文。 - 作用:
- 定义网络中的参与者(如发动机控制模块、ABS控制器等)。
- 在DBC文件中通过
BU_
关键字声明所有ECU节点。
- 示例:
BU_: CCU ZCU_L // 声明了俩个ECU节点
- 每个ECU可能具有属性(如地址、诊断功能),但核心作用是关联到报文(
BO_
)和信号(SG_
)的发送/接收。
如下图,该网络定义了两个ECU,分别为CCU和ZCU_L;
- 每个ECU可能具有属性(如地址、诊断功能),但核心作用是关联到报文(
2.3 Network Nodes
- 定义:
Network nodes
通常与ECUs
同义,指网络中的物理或逻辑节点。在标准DBC中,BU_
定义的ECU列表即为网络节点。 - 潜在差异:
- 某些工具可能区分“逻辑节点”(ECUs)和“物理节点”(如网关、中继器),但标准DBC中通常统一用
BU_
表示。
- 某些工具可能区分“逻辑节点”(ECUs)和“物理节点”(如网关、中继器),但标准DBC中通常统一用
- 示例:
BU_: CCU ZCU_L // 俩个网络节点
如下图,该网络节点定义的CCU、ZCU_L俩个节点的属性(为网络管理节点):
Networks、ECUs、Network nodes关键区别
属性 | 作用 | DBC关键字/结构 | 示例 |
---|---|---|---|
Networks | 定义网络的全局配置(如波特率) | BS_ (波特率) | BS_: 500000 |
ECUs | 声明网络中的逻辑节点 | BU_ (节点列表) | BU_: CCU ZCU_L |
Network nodes | 同ECUs,指具体节点 | 同BU_ | 实际节点如“CCU”或“ZCU_L” |
总结
- Networks:描述网络的物理层和全局参数。
- ECUs:定义网络中的逻辑参与者(节点),通过
BU_
声明。 - Network nodes:通常与ECUs等价,指具体的网络节点。
2.4 Message(报文)
2.4.1 Message定义、作用、示例
- 定义:
Message 是 CAN 总线上的一个数据帧,包含一组相关的 Signal。每个 Message 通过一个唯一的 Message ID(标识符)来标识。 - 作用:
- 标识数据帧:Message 通过 Message ID 唯一标识,用于区分不同的数据帧。
- 定义数据长度:Message 定义了数据帧的长度(通常为 1 到 8 字节)。
- 组织信号:Message 包含一组 Signal,这些 Signal 是实际传输的数据。
- 描述发送者和接收者:Message 可以指定发送节点(Transmitter)和接收节点(Receivers)。
- 示例:
BO_ 100 MessageName: 8 NodeName
BO_ 100 MessageName: 8 NodeName
BO_ 表示 Message 的定义。
100 是 Message ID。
MessageName 是消息的名称。
8 是数据长度(字节数)。
NodeName 是发送该报文的节点名称。
2.4.2 报文Attribute(属性)
在 DBC文件(CAN数据库文件)中,报文的 Attributes(属性) 用于定义报文在通信中的行为特性、发送规则或其他扩展配置。这些属性直接影响CAN网络中的报文调度、发送逻辑及工具链(如CANoe、CANalyzer)的解析行为。以下是报文Attributes的详细分类和说明:
- DBC文件中的属性分为两类:
- 全局属性:适用于整个DBC文件(如协议版本、网络名称)。
- 局部属性:仅针对特定对象(如报文、信号、节点)。
报文的Attributes属于局部属性,需在报文定义中明确指定。
2.4.2.1 常见的报文Attributes
如下图:
- 1 关键属性:
以下是与报文直接相关的关键属性(具体名称可能因工具链不同略有差异):
属性名称 | 数据类型 | 作用 | 示例值 |
---|---|---|---|
GenMsgSendType | 枚举型 | 定义报文发送类型: - Cyclic (周期发送)- Event (事件触发)- CyclicAndEvent (混合模式) | Cyclic |
GenMsgCycleTime | 整数 | 报文周期发送的时间间隔(单位:ms)。仅对Cyclic 类型有效。 | 100 (表示100ms) |
GenMsgDelayTime | 整数 | 报文发送后的最小延迟时间(单位:ms),防止总线过载。 | 10 |
GenMsgStartDelayTime | 整数 | 系统启动后首次发送报文的延迟时间(单位:ms)。 | 500 |
GenMsgILSupport | 布尔型 | 是否支持交互层(Interaction Layer)功能(如UDS诊断)。 | TRUE |
GenMsgNmMessage | 布尔型 | 是否为网络管理(Network Management)报文。 | FALSE |
GenMsgCanId | 十六进制 | 报文的CAN ID(需与报文定义中的ID一致)。 | 0x100 |
-
1.1关键属性详解
-
(1) GenMsgSendType,作用:控制报文的触发方式。
-
Cyclic:周期性发送(如发动机转速报文每100ms发送一次)。
-
Event:事件触发(如车门开关状态变化时发送)。
-
CyclicAndEvent:周期发送,但事件触发时立即更新并发送。
-
配置建议: 实时性要求高的信号(如刹车状态)应使用
Event
或CyclicAndEvent
模式。
-
-
(2) GenMsgCycleTime,作用:定义周期性报文的发送间隔。
- 注意事项: 周期时间需综合考虑总线负载和信号更新需求。例如: 底盘控制报文可能需要
10ms
周期,温度监控报文可设为1000ms
。
- 注意事项: 周期时间需综合考虑总线负载和信号更新需求。例如: 底盘控制报文可能需要
-
(3) GenMsgDelayTime,作用:防止连续发送报文导致总线拥堵。例如,若报文A发送后需等待
5ms
才能发送报文B,可避免信号冲突。 -
(4) GenMsgStartDelayTime,作用:系统上电后,某些报文需等待其他模块初始化完成再开始发送。例如,仪表盘报文可能在启动
500ms
后开始发送,确保ECU就绪。
-
-
1.2在DBC文件中的定义格式
在DBC文件中,报文属性通过BA_
关键字定义,格式如下:
// 语法
BA_ "AttributeName" BO_ MessageID Value;
// 示例:设置报文0x100的周期为100ms
BA_ "GenMsgCycleTime" BO_ 256 100; // 256是0x100的十进制表示
(1) 周期报文配置
BO_ 256 EMS_EngineStatus: 8 EMS
BA_ "GenMsgSendType" BO_ 256 1; // 1表示Cyclic
BA_ "GenMsgCycleTime" BO_ 256 100; // 100ms周期
(2) 事件触发报文
BO_ 512 DOOR_Status: 1 BodyControl
BA_ "GenMsgSendType" BO_ 512 2; // 2表示Event
2.4.2.2 其他相关属性
主要还有Diagnostic相关和Net Management相关属性;
-
1 诊断相关属性:
Diagnostic
属性是其中一种特殊的属性,通常用于与诊断相关的配置。Diagnostic
属性在DBC文件中用于标识和配置与诊断相关的消息和参数。通过正确配置这些属性,可以确保CAN网络中的诊断功能正常工作。
Diagnostic
属性通常用于定义与诊断相关的参数,例如:- 诊断请求和响应的ID:定义诊断消息的标识符(ID)。
- 诊断数据的格式:定义诊断消息中数据的格式,如长度、字节顺序等。
- 诊断服务:定义支持的诊断服务(如UDS服务)。
- 诊断参数:定义诊断相关的参数,如超时时间、重试次数等。
-
1.1
Diagnostic
属性的常见配置:
在DBC文件中,Diagnostic
属性通常以以下方式定义:
BA_ "Diagnostic" BO_ 1234 1;
BA_
表示属性定义。"Diagnostic"
是属性的名称。BO_
表示该属性应用于消息(Message)。1234
是消息的ID。1
是属性的值,表示该消息是诊断消息。
- 1.2 示例
假设有一个诊断请求消息,ID为0x7DF
,可以这样定义其Diagnostic
属性:
BA_ "Diagnostic" BO_ 0x7DF 1;
这表示ID为 0x7DF
的消息是一个诊断消息。
除了 Diagnostic
属性外,DBC文件中还可能有其他与诊断相关的属性,例如:
Request
:定义诊断请求消息。Response
:定义诊断响应消息。Timeout
:定义诊断消息的超时时间。
-
2 Net Management 属性
Net Management
属性是用于描述CAN网络管理相关的属性。CAN网络管理(NM)是用于控制CAN网络中节点的睡眠和唤醒机制,以节省能源并提高网络效率。
主要定义如下:- NmMessage:
- 描述:指定用于网络管理的CAN消息。
- 示例:
NmMessage = 0x500;
- NmNodeId:
- 描述:指定节点的网络管理标识符。
- 示例:
NmNodeId = 0x01;
- NmTimeout:
- 描述:指定网络管理超时时间(以毫秒为单位)。
- 示例:
NmTimeout = 1000;
- NmCycleTime:
- 描述:指定网络管理周期时间(以毫秒为单位)。
- 示例:
NmCycleTime = 500;
- NmWaitBusSleepTime:
- 描述:指定节点在进入睡眠模式前等待总线睡眠的时间(以毫秒为单位)。
- 示例:
NmWaitBusSleepTime = 2000;
- NmImmediateRestart:
- 描述:指定节点是否在接收到网络管理消息后立即重启。
- 示例:
NmImmediateRestart = TRUE;
示例 DBC 文件片段
BO_ 500 NmMessage: 8 Vector__XXX
SG_ NmSignal : 0|8@1+ (1,0) [0|255] "Nm" Vector__XXX
BA_ "NmMessage" BO_ 500 0x500;
BA_ "NmNodeId" BO_ 500 0x01;
BA_ "NmTimeout" BO_ 500 1000;
BA_ "NmCycleTime" BO_ 500 500;
BA_ "NmWaitBusSleepTime" BO_ 500 2000;
BA_ "NmImmediateRestart" BO_ 500 TRUE;
解释:
BO_ 500 NmMessage: 8 Vector__XXX
定义了一个ID为500的CAN消息,用于网络管理。SG_ NmSignal : 0|8@1+ (1,0) [0|255] "Nm" Vector__XXX
定义了该消息中的一个信号。BA_ "NmMessage" BO_ 500 0x500;
将该消息的ID设置为0x500。BA_ "NmNodeId" BO_ 500 0x01;
将该节点的网络管理标识符设置为0x01。BA_ "NmTimeout" BO_ 500 1000;
将网络管理超时时间设置为1000毫秒。BA_ "NmCycleTime" BO_ 500 500;
将网络管理周期时间设置为500毫秒。BA_ "NmWaitBusSleepTime" BO_ 500 2000;
将等待总线睡眠时间设置为2000毫秒。BA_ "NmImmediateRestart" BO_ 500 TRUE;
设置节点在接收到网络管理消息后立即重启。
这些属性可以根据具体的网络管理需求进行调整和配置。
- 3 注意事项:
- 兼容性:不同工具链(如Vector CANdb++ vs Peak CANoe)可能对属性支持不同,需查阅工具文档。
- 冲突避免:
若多个报文共享相同ID,需通过GenMsgILSupport
或网关配置避免冲突。 - 工具验证:在CANoe/CANalyzer中加载DBC后,通过Trace窗口检查报文发送是否符合属性定义。
- 信号更新策略:事件触发报文需确保信号值变化时触发发送逻辑(依赖ECU软件实现)。
通过合理配置报文Attributes,可以优化CAN网络性能并满足功能安全要求。若需更具体的属性定义(如自定义属性),可结合工具链文档扩展。 - 小知识:总线负载计算:
周期时间直接影响总线负载率,需使用公式校验:
负载率 = (报文数量 × 报文长度 × 8) / (周期时间 × 总线速率) × 100%
2.5 Signal(信号)
- 定义:
Signal 是 Message 中的具体数据字段,表示实际传输的信息。每个 Signal 在 Message 中占据一定的位数,并通过特定的编码方式表示数据。 - 作用:
定义数据内容:Signal 是实际传输的数据,例如车速、温度、开关状态等。
描述数据属性:Signal 定义了数据的长度(位数)、起始位、字节顺序(大端或小端)、缩放因子、偏移量、单位等。
指定取值范围:Signal 可以定义最小值和最大值,以及无效值或错误值的表示方式。
描述信号接收者:Signal 可以指定接收该信号的节点。
示例:SG_ SignalName : 7|16@1+ (0.1,0) [0|1000] "Unit" NodeName
SG_ 表示 Signal 的定义。
SignalName 是信号的名称。
7 是起始位。
16 是信号的长度(位数)。
@1+ 表示字节顺序(1 表示大端,+ 表示无符号)。
(0.1,0) 是缩放因子和偏移量(信号值 = 原始值 * 0.1 + 0)。
[0|1000] 是信号的最小值和最大值。
“Unit” 是信号的单位。
NodeName 是接收该信号的节点名称。
- Value Table
Value Table 是用于定义信号值的含义的表格。它通常用于将信号的数值映射到人类可读的描述,例如状态、错误码或其他有意义的信息。
Value Table 的语法:
在 DBC 文件中,Value Table 的定义格式如下:
VAL_ <信号ID> <信号名称> <数值> "<描述>" <数值> "<描述>" ... ;
<信号ID>
:信号的标识符(通常是信号所属的报文ID)。<信号名称>
:信号的名称。<数值>
:信号的具体数值。<描述>
:与该数值对应的描述。
示例
假设有一个信号 EngineStatus
,其值可以表示发动机的不同状态。在 DBC 文件中,可以这样定义:
VAL_ 0x100 EngineStatus 0 "Off" 1 "Idle" 2 "Running" 3 "Error";
0x100
是信号所属的报文ID。EngineStatus
是信号的名称。0
表示发动机关闭,1
表示怠速,2
表示运行中,3
表示错误。
使用场景
- 状态指示:例如,信号值表示设备的运行状态(如开/关、正常/故障等)。
- 错误码:信号值表示特定的错误代码,便于调试和诊断。
- 模式选择:信号值表示设备的工作模式(如自动/手动、低速/高速等)。
注意事项
- Value Table 是可选的,不是所有信号都需要定义。
- 数值和描述必须一一对应。
- 描述通常用双引号括起来,且不能包含分号(
;
)。
通过 Value Table,DBC 文件可以更直观地表达信号的含义,便于开发人员理解和调试 CAN 通信数据。
- Message 和 Signal 的关系:
- 一个 Message 包含一个或多个 Signal。
- Signal 是 Message 的实际数据内容,而 Message 是 Signal 的载体。
- Message 通过 Message ID 唯一标识,而 Signal 通过其在 Message 中的起始位和长度来定位。
备注:
在解析DBC文件时,需注意不同工具可能对术语有细微调整,但核心逻辑遵循上述定义。
还有些信号的属性,比如信号长度、信号排布、起始位置等在之前专题有过介绍,详见:
车载网络测试-路由表解读-通信矩阵部分属性解读
3 总结
以上对DBC文件的Networks、ECUs(电子控制单元)、Network nodes(网络节点)、Messages(报文)、Signals(信号)几个层级进行了介绍。大家如有疑问,欢迎一起探讨!