1 背景

DBC文件（Database CAN）是一种用于描述CAN（Controller Area Network）网络中消息和信号的数据库文件格式。它对工程师来说具有以下重要作用：

1. 定义CAN网络通信协议
   • DBC文件详细定义了CAN网络中消息（Message）和信号（Signal）的格式、内容及其相互关系。
   • 它规定了消息的ID、长度、周期性和信号在消息中的位置、数据类型、缩放因子、偏移量等。
2. 实现通信标准化
   • DBC文件确保所有节点（ECU）在通信时使用统一的协议，避免因消息格式不一致导致的通信错误。
   • 它为不同供应商或团队开发的ECU提供了通用的通信标准。
3. 支持工具链集成
   • DBC文件可以被多种工具（如CANalyzer、CANoe、MATLAB/Simulink等）解析和使用，用于仿真、测试和分析CAN网络。
   • 它简化了工程师在开发、测试和调试过程中的工作。
4. 信号解析与解码
   • DBC文件提供了信号的物理值和原始值之间的转换规则（如缩放因子、偏移量），帮助工程师解析CAN总线上的原始数据。
   • 这对于诊断、监控和数据分析非常重要。
5. 支持自动化代码生成
   • 许多开发工具可以根据DBC文件自动生成代码（如C代码），用于ECU的通信层实现。
   • 这减少了手动编写代码的工作量，提高了开发效率和代码的可靠性。
6. 诊断和测试
   • DBC文件定义了诊断消息（如UDS或OBD-II）和信号，支持故障诊断和测试。
   • 它帮助工程师快速定位和解决通信问题。
7. 文档化和版本管理
   • DBC文件作为CAN网络的通信协议文档，便于团队协作和版本管理。
   • 它记录了网络中的所有消息和信号，方便后续维护和升级。
8. 支持网络仿真和测试
   • 使用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；
    

2.3 Network Nodes

• 定义：
  Network nodes通常与ECUs同义，指网络中的物理或逻辑节点。在标准DBC中，BU_定义的ECU列表即为网络节点。
• 潜在差异：
  • 某些工具可能区分“逻辑节点”（ECUs）和“物理节点”（如网关、中继器），但标准DBC中通常统一用BU_表示。
• 示例：

  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 属性通常用于定义与诊断相关的参数，例如：

  1. 诊断请求和响应的ID：定义诊断消息的标识符（ID）。
  2. 诊断数据的格式：定义诊断消息中数据的格式，如长度、字节顺序等。
  3. 诊断服务：定义支持的诊断服务（如UDS服务）。
  4. 诊断参数：定义诊断相关的参数，如超时时间、重试次数等。

• 1.1 Diagnostic 属性的常见配置：
  在DBC文件中，Diagnostic 属性通常以以下方式定义：

BA_ "Diagnostic" BO_ 1234 1;

1. BA_ 表示属性定义。
2. "Diagnostic" 是属性的名称。
3. BO_ 表示该属性应用于消息（Message）。
4. 1234 是消息的ID。
5. 1 是属性的值，表示该消息是诊断消息。

• 1.2 示例
  假设有一个诊断请求消息，ID为 0x7DF，可以这样定义其 Diagnostic 属性：

BA_ "Diagnostic" BO_ 0x7DF 1;

这表示ID为 0x7DF 的消息是一个诊断消息。

除了 Diagnostic 属性外，DBC文件中还可能有其他与诊断相关的属性，例如：

1. Request：定义诊断请求消息。
2. Response：定义诊断响应消息。
3. Timeout：定义诊断消息的超时时间。

• 2 Net Management 属性
  Net Management 属性是用于描述CAN网络管理相关的属性。CAN网络管理（NM）是用于控制CAN网络中节点的睡眠和唤醒机制，以节省能源并提高网络效率。
  主要定义如下：

  1. NmMessage:
  • 描述：指定用于网络管理的CAN消息。
  • 示例：NmMessage = 0x500;
  2. NmNodeId:
  • 描述：指定节点的网络管理标识符。
  • 示例：NmNodeId = 0x01;
  3. NmTimeout:
  • 描述：指定网络管理超时时间（以毫秒为单位）。
  • 示例：NmTimeout = 1000;
  4. NmCycleTime:
  • 描述：指定网络管理周期时间（以毫秒为单位）。
  • 示例：NmCycleTime = 500;
  5. NmWaitBusSleepTime:
  • 描述：指定节点在进入睡眠模式前等待总线睡眠的时间（以毫秒为单位）。
  • 示例：NmWaitBusSleepTime = 2000;
  6. 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 表示错误。

使用场景

1. 状态指示：例如，信号值表示设备的运行状态（如开/关、正常/故障等）。
2. 错误码：信号值表示特定的错误代码，便于调试和诊断。
3. 模式选择：信号值表示设备的工作模式（如自动/手动、低速/高速等）。

注意事项

• Value Table 是可选的，不是所有信号都需要定义。
• 数值和描述必须一一对应。
• 描述通常用双引号括起来，且不能包含分号（;）。

通过 Value Table，DBC 文件可以更直观地表达信号的含义，便于开发人员理解和调试 CAN 通信数据。

• Message 和 Signal 的关系：

1. 一个 Message 包含一个或多个 Signal。
2. Signal 是 Message 的实际数据内容，而 Message 是 Signal 的载体。
3. Message 通过 Message ID 唯一标识，而 Signal 通过其在 Message 中的起始位和长度来定位。
   备注：
   在解析DBC文件时，需注意不同工具可能对术语有细微调整，但核心逻辑遵循上述定义。
   还有些信号的属性，比如信号长度、信号排布、起始位置等在之前专题有过介绍，详见：
   车载网络测试-路由表解读-通信矩阵部分属性解读

3 总结

以上对DBC文件的Networks、ECUs（电子控制单元）、Network nodes（网络节点）、Messages（报文）、Signals（信号）几个层级进行了介绍。大家如有疑问，欢迎一起探讨！