认识CAN矩阵
CAN矩阵是什么
CAN矩阵(CAN Matrix)是汽车电子和工业控制中,用于描述CAN总线网络里所有报文(Message)和信号(Signal)定义的文件或表格。简单说,它就像是 CAN 通信的“密码本”或“翻译字典”,告诉 ECU 和开发工具:总线上每一帧数据代表什么、怎么解析。工具(如 CANoe、CANalyzer、Vehicle Spy)可以导入 CAN 矩阵(常见格式如 DBC、ARXML、Excel),自动解析总线上原始数据。
报文层信息
报文名称:如
EngineData、VehicleSpeedCAN ID:报文的标识符,如
0x123报文类型:标准帧/扩展帧、事件型/周期型
发送节点:哪个 ECU 发送这个报文
接收节点:哪些 ECU 接收这个报文
周期:如 10ms、100ms
数据长度(DLC):一帧有几个字节
信号层信息
每个报文里可能包含多个信号,CAN矩阵会定义:
信号名称:如
EngineSpeed、CoolantTemp起始位、长度:信号在报文数据字节中的位置
字节序:Intel(小端)或 Motorola(大端)
精度/分辨率:如 0.01
偏移量:如 -40
物理值范围:如 -40~200
单位:如 rpm、km/h、℃
信号类型:布尔量、枚举量、数值量等
CAN矩阵常见格式有
DBC 文件:Vector 公司定义,行业事实标准,用于 CANdb++、CANoe 等工具。
Excel 表格:人工评审和发布常用。
ARXML:AUTOSAR 标准格式,用于现代汽车电子架构。
LDF:用于 LIN 总线,类似 CAN 矩阵。
CAN 矩阵常见字段对照表
| 字段名(你列出的) | 常见标准名 | 中文含义 | 说明 |
|---|---|---|---|
| Message ID | CAN ID / Message Identifier | 报文标识符 | 报文的唯一 ID,如0x123,用于仲裁和识别 |
| Message Name | Message Name | 报文名称 | 报文的名字,如EngineData,便于人阅读 |
| Message Type | Message Type | 报文类型 | 如标准帧、扩展帧;或应用层类型(周期、事件) |
| Message Length | DLC (Data Length Code) | 报文长度 | 报文数据字节数,通常 0~8(CAN FD 可达 64) |
| Message Send Type | Transmission Type | 发送类型 | 周期型、事件型、混合型等 |
| Cycle Time (ms) | Cycle Time / Period | 周期时间 | 报文周期发送的间隔,单位 ms |
| Signal Name | Signal Name | 信号名称 | 报文内某个信号的名字,如EngineSpeed |
| Byte Order | Byte Order | 字节序 | Motorola(大端)或Intel(小端) |
| Signal Size (bit) | Signal Length / Size | 信号长度 | 信号占用的位数,如 8、16、12 |
| Start Bit (LSB Or MSB) | Start Bit | 起始位 | 信号在报文数据中的起始位置,需注明是相对 LSB 还是 MSB |
| Factor | Factor / Resolution / Scale | 精度/分辨率 | 物理值 = 原始值 × Factor + Offset |
| Offset | Offset | 偏移量 | 物理值 = 原始值 × Factor + Offset |
| Init Value | Init Value | 初始值 | 信号上电或无效时的默认值 |
| Minimum | Minimum | 最小值 | 信号物理值的最小限值 |
| Maximum | Maximum | 最大值 | 信号物理值的最大限值 |
| Sender | Sender / Transmitter | 发送节点 | 发送该报文的 ECU 名称 |
| Receiver | Receiver | 接收节点 | 接收该报文的 ECU 名称(可能有多个) |
| Signal Group | Signal Group | 信号组 | 将多个信号打包成组,用于一起处理 |
| Comment | Comment | 注释 | 额外说明信息 |
| Unit | Unit | 单位 | 物理量的单位,如 rpm、km/h、℃ |
| Coding | Coding / Value Description | 编码/值描述 | 枚举或布尔信号的取值含义,如 0=OFF, 1=ON |
1. Message ID(报文标识符)
是什么?
报文的“身份证号”。CAN 总线上同时跑着很多报文,每个报文都有一个唯一的 ID,用来区分彼此。
举例:
我们给车速报文分配 ID =0x100。以后只要在总线上看到0x100,就知道这是车速报文。
常见值:
标准帧:11 位,范围
0x000~0x7FF扩展帧:29 位,范围更广
ID 还有一个作用:ID 越小,优先级越高(总线仲裁时)。
2. Message Name(报文名称)
是什么?
给人看的名字,方便记忆。计算机只认 ID,但人记不住0x100是什么意思,所以起个名字。
举例:
我们把这个报文命名为VehicleSpeed。看名字就知道是车速。
3. Message Type(报文类型)
是什么?
描述报文的帧格式或数据链路类型。
常见值:
Standard(标准帧):使用 11 位 ID。
Extended(扩展帧):使用 29 位 ID。
有些矩阵里还可能写CAN FD(可变数据速率,数据长度可达 64 字节)。
举例:
我们的车速报文使用标准帧,所以 Message Type = Standard。
4. Message Length(报文长度)
是什么?
报文里数据部分有多少个字节,也叫 DLC(Data Length Code)。
常见值:
传统 CAN:0 ~ 8 字节;CAN FD:0 ~ 64 字节。
举例:
车速信号我们设计为 16 位(2 个字节),所以报文长度 = 2。
也就是说这帧报文里只有 2 个字节的数据。
5. Message Send Type(发送类型)
是什么?
报文是怎么被发送的——是定时发,还是有事才发。
常见值:
Cyclic(周期型):每隔固定时间就发一次。
Event(事件型):当某个条件触发时才发(比如车门打开)。
Mixed(混合型):既周期发,事件发生时也发。
举例:
车速需要实时更新,所以我们让它周期型发送。
6. Cycle Time (ms)(周期时间)
是什么?
如果是周期型报文,这个字段就是每隔多少毫秒发送一次。
举例:
我们设置 Cycle Time = 20 ms。意思是仪表盘每 20 毫秒发送一次车速报文(1 秒发 50 次)。
注意:
如果 Message Send Type 是 Event,这个字段可能为空或填 0。
7. Signal Name(信号名称)
是什么?
报文里包含的具体数据项的名字。一个报文可以包含多个信号。
举例:
我们的车速报文里只有一个信号,命名为SpeedValue。
说明:
比如一个发动机报文可能包含EngineSpeed、CoolantTemp、ThrottlePosition等多个信号。
8. Byte Order(字节序)
是什么?
当一个信号需要多个字节才能表示时(比如 16 位要用 2 个字节),规定这些字节在报文里怎么排列。
两种格式:
Motorola(大端):高字节在前(先发高位)。
Intel(小端):低字节在前(先发低位)。
举例:
假设车速物理值 = 4660,原始值用十六进制表示是0x1234(2 字节)。
如果是Motorola:报文数据 =
[0x12, 0x34]如果是Intel:报文数据 =
[0x34, 0x12]
我们这里规定车速信号使用Intel格式(现代很多 ECU 用小端)。
9. Signal Size (bit)(信号长度)
是什么?
信号占用多少个二进制位。位数越多,能表示的范围越大。
常见值:
8 位(1 字节)、16 位(2 字节)、1 位(布尔量)等。
举例:
车速范围我们想设为 0 ~ 300 km/h,用 16 位足够了(16 位可表示 0 ~ 65535)。
所以 Signal Size = 16 bit。
10. Start Bit (LSB Or MSB)(起始位)
是什么?
信号在报文数据中从第几位开始。但这个“第几位”的计数方式取决于参考点是LSB(最低有效位)还是MSB(最高有效位)。
为什么要区分 LSB/MSB?
因为不同的工具或厂商定义位编号时,有的从最低位开始数,有的从最高位开始数。
这个字段就是告诉你:我写的起始位是相对于 LSB 还是 MSB 的。
举例:
我们的车速信号放在报文数据的最开始,如果工具用 LSB 参考,那么 Start Bit = 0(从最低位开始占用 16 位)。
如果工具用 MSB 参考,起始位可能写成 15(因为 16 位数据最高位是第 15 位)。
具体取决于你的矩阵格式。
初学者提示:
你只需要知道这个字段和 Byte Order 搭配使用,解析工具会自动计算,你照着填就行。
11. Factor(精度 / 分辨率)
是什么?
缩放因子。CAN 总线传输的是整数原始值,但实际物理量可能是小数,需要用 Factor 把原始值转成物理值。
公式:
物理值 = 原始值 × Factor + Offset
举例:
我们想让车速精确到 0.01 km/h(比如 60.00 km/h)。
原始值每增加 1,物理值增加 0.01,所以 Factor = 0.01。
如果原始值是 6000,物理值 = 6000 × 0.01 + 0 = 60.00 km/h。
12. Offset(偏移量)
是什么?
物理值公式里的常数项,用来平移数值。有的传感器原始值 0 不代表物理量 0。
举例:
温度传感器:原始值 0 对应 -40℃,那么 Offset = -40。
这样物理温度 = 原始值 × Factor + (-40)。
对于车速,我们假设原始值 0 就代表 0 km/h,所以 Offset = 0。
13. Init Value(初始值)
是什么?
信号在上电、复位或还没收到有效数据时的默认值。
举例:
车速信号初始值设为 0,表示车还没动时车速为 0。
作用:
防止接收方读到未定义的随机值导致误判。
14. Minimum(最小值)
是什么?
信号物理值的下限。用于校验数据是否合理。
举例:
车速不可能小于 0,所以 Minimum = 0 km/h。
作用:
如果接收到的信号计算出物理值 < 0,可能表示传感器故障或数据错误。
15. Maximum(最大值)
是什么?
信号物理值的上限。
举例:
这辆车的最高设计时速是 300 km/h,所以 Maximum = 300 km/h。
作用:
如果物理值 > 300,也可能表示数据异常。
16. Sender(发送节点)
是什么?
哪个 ECU 发送这个报文。
举例:
车速报文是由仪表盘 ECU发送的,所以 Sender = InstrumentCluster(或写具体名称如“仪表”)。
17. Receiver(接收节点)
是什么?
哪些 ECU 需要接收这个报文。可能是一个,也可能是多个。
举例:
发动机控制单元、车身稳定系统、导航主机都需要知道车速,所以 Receiver = EngineECU, ESP, HeadUnit。
18. Signal Group(信号组)
是什么?
把多个信号打包成一个组,便于一起处理或更新。
举例:
如果一个报文里包含 4 个车轮的转速信号,可以把它们放进一个叫WheelSpeeds的组里。
接收方可以一次性获取整组数据,保证一致性。
注意:
不是所有信号都有组,很多矩阵里这一列是空的。
19. Comment(注释)
是什么?
额外说明信息,给人看的备注。
举例:
可以写“车速信号来自 ABS 轮速传感器计算值,精度 0.01 km/h”。
方便工程师理解信号的来源或特殊条件。
20. Unit(单位)
是什么?
物理量的单位。
常见值:
km/h, rpm, ℃, %, V, A, Nm, kPa 等。
举例:
车速的单位是km/h。
21. Coding(编码描述)
是什么?
对于枚举型或布尔型信号,描述每个数值代表什么意思。
举例:
假设我们有一个挡位信号:
0 = P(驻车)
1 = R(倒挡)
2 = N(空挡)
3 = D(前进挡)
Coding 列就会写:0=P, 1=R, 2=N, 3=D。
注意:
对于连续数值(如车速),这一列通常为空。
CAN矩阵开发
| 步骤 | 核心任务 | 备注 |
|---|---|---|
| 1 | 读懂矩阵 | 知道要收/发哪些报文、信号怎么打包解析 |
| 2 | 配置底层 | 波特率、过滤器,让 CAN 硬件能工作 |
| 3 | 实现发送 | 把物理值转成原始值,按周期/事件发出 |
| 4 | 实现接收 | 从原始数据中提取信号,转成物理值 |
| 5 | 应用逻辑 | 用收发到的数据做实际功能(控制、显示等) |
| 6 | 测试验证 | 用工具确认报文正确,功能正常 |
实际项目中这些步骤会分配给从应用层到底层不同的工程师配合完成,例如
底层驱动工程师:重点做第 2 步,提供 CAN 收发接口。
应用软件工程师:重点做第 1、3、4、5 步,调用底层接口实现报文收发和逻辑。
测试工程师:重点做第 6 步。
CAN矩阵变更
CAN 矩阵变更就是通信定义发生变化。
变更类型很多:增删报文、修改信号、改周期、改节点等。
变更原因:功能变化、优化、纠错等。
开发人员需要根据新矩阵更新软件,并重新验证。
认识DBC
DBC是什么
DBC 是 CAN 通信矩阵的标准文件格式,用于描述报文和信号,让工具和代码能够自动理解 CAN 通信内容。
你在矩阵里看到的每一行,DBC 都有对应的语法来表达。
开发中,你可能会用 Excel 看矩阵,用 DBC 做实际开发和测试。
DBC的用途
1.用于应用层功能测试
应用层功能测试的重点是验证 ECU 的逻辑功能是否正确,而不是底层的位操作。
测试工程师需要:
实时查看总线上报文里的信号值(物理值,而不是原始十六进制)。
模拟其他 ECU 发送报文,来触发被测 ECU 的某项功能。
自动记录数据,判断功能是否满足要求。
① 实时解析与显示
测试工具(如 CANoe、CANalyzer)加载 DBC 后,会自动把总线上收到的原始数据解析成有意义的物理量,并显示在界面上。
② 模拟节点与报文
测试人员可以使用 CANoe 等工具,根据 DBC 定义模拟发送节点。
③ 自动化测试与判定
加载 DBC 后,测试工具可以编写脚本,自动检查信号值是否在期望范围内。
④ 故障诊断与问题定位
当功能测试发现异常时,测试人员可以通过 DBC 快速定位问题。
2.用于底层CAN通讯软件开发
底层 CAN 通讯软件负责让 ECU 的 CAN 控制器正确收发报文。
它需要知道:
要发送哪些报文?ID 是多少?
报文数据长度是多少?
数据字节里每个信号怎么放?(起始位、长度、字节序、精度)
报文发送周期是多少?
要接收哪些报文?如何过滤?
接收到的数据如何解析出物理值?
这些信息全部来自 CAN 矩阵,而 DBC 就是矩阵的机器可读形式。
① 配置硬件与驱动
底层工程师根据 DBC 中的报文 ID 列表,配置 CAN 控制器的接收过滤器,只让关心的报文进入中断,减轻 CPU 负担。
② 生成/编写信号打包解包代码
很多工具(如 Vector GENy、MATLAB、AUTOSAR 工具链)可以直接根据 DBC 生成信号打包(Pack)和解包(Unpack)函数。
③ 实现周期发送和事件触发
DBC 的属性(Attribute)中通常包含报文的发送类型和周期(例如GenMsgCycleTime)。
底层软件根据这些属性设置定时器,周期调用发送函数。
④ 保证多节点一致性
当一个项目中有多家供应商开发不同 ECU 时,每家都拿到同一份 DBC。
底层工程师按照 DBC 实现,就能确保不同 ECU 之间“说同一种语言”,不会出现字节序或精度不一致的问题。
DBC开发(根据CAN矩阵新建一个DBC)
新建一条发送/接收报文
配置接收报文的时候,节点配置Node,Mapped Rx Sig(映射接收信号)是站在应用层的角度,告诉工具或代码生成器:这个节点虽然接收了某条报文,但它只关心其中的哪几个信号,实际上底层仍然是接收整条报文。