MatrixFusion多源矩阵融合：高密度多目标混行场景下的跨镜精准分离与零断点接续算法技术白皮书
2026/7/27 0:36:50
CAN (Controller Area Network) 通信
CAN 是一种串行通信协议，是一个现场总线。
总线状态
CAN 总线存在两种稳态电平状态：隐性电平、显性电平
隐性电平（Recessive）CAN-H ≈ 2.5V，CAN-L ≈ 2.5V，差分电压≈0V，逻辑
1。 总线空闲时，所有节点输出隐性电平；多个节点同时发送隐性电平，总线依旧保持隐性。显性电平（Dominant）CAN-H ≈ 3.5V，CAN-L ≈ 1.5V，差分电压≈2V，逻辑
0。 显性优先级高于隐性：只要任意一个节点发出显性电平，整条总线都会被拉为显性电平，这也是 CAN 位仲裁机制的物理基础。
总线故障补充（车载调试常用）
- CAN_H 断路：总线只能维持部分隐性，通信极易报错；
- CAN_L 对地短路：总线持续显性，全网通信瘫痪；
- 缺少终端电阻：高速通信出现波形畸变、丢帧。
数据类型
CAN 报文数据段分为Byte0 ~ Byte7，字节地址从前往后递增。当一个信号占用多个字节时，两种格式填充方向完全相反：
| 名称 | 长度 | 用途 | 示例 |
|---|---|---|---|
| 信号 (Signal) | 1-64位（通常1-32位） | 车载电子控制单元（ECU）之间传递的最小信息单元，如车速、转速、温度等物理量 | 车速信号：16位，范围0-655.35 km/h，精度0.01 km/h |
| 报文 (Message/Frame) | 标准CAN：0-8字节 CAN FD：0-64字节 | 包含一个或多个信号的完整数据包，带有ID、控制位、数据段和校验信息 | 发动机转速报文：ID=0x100，数据=0x12 0x34 0x56 0x78（包含转速、水温等信号） |
| 协议数据单元 (PDU) | 可变（通常对应一个报文） | AUTOSAR架构中的通信抽象层，封装信号到报文的映射关系，实现软硬件解耦 | ComSignal → ComIPdu → CanIPdu → CanFrame，实现应用层信号到物理报文的转换 |
| 信号组 (Signal Group) | 多个信号组合 | 逻辑上相关的多个信号集合，通常一起传输，提高通信效率 | 车门状态组：包含门锁状态、车窗位置、儿童锁状态等多个信号 |
| 多路复用信号 (Multiplexed Signal) | 可变（根据复用器值选择） | 同一报文位置在不同时间传输不同信号，通过复用器值区分 | 诊断报文：复用器=0x01传输故障码，复用器=0x02传输实时数据 |
表：CAN通信中常见数据类型对比
Intel 格式（小端序，从前往后延伸）
信号最低有效位 LSB 放在StartBit，向高地址字节（地址增大方向）依次填充信号高位。
延伸方向：Byte0 → Byte1 → Byte2（顺着字节地址向后）
特点：低字节存放数据低位，典型小端模式。
Motorola 格式（大端序，从后往前延伸）
- 信号最高有效位 MSB 放在
StartBit，向低地址字节（地址减小方向）依次填充信号低位。
- 延伸方向：
Byte2 → Byte1 → Byte0（逆着字节地址向前） - 特点：高字节存放数据高位，典型大端模式。
数据帧
CAN 通信依靠数据帧完成信息交互，标准 CAN 2.0 规范分为两种帧格式：标准帧、扩展帧。 两者最核心区别：ID 长度不同，直接决定总线上节点寻址数量。
标准帧（CAN2.0A）
- 仲裁段 ID：11 位
- ID 范围：0 ~ 0x7FF
- 特点：报文结构短，解析简单，早期车身控制、低速网络大量使用
扩展帧（CAN2.0B）
- 仲裁段 ID：29 位（基础 ID11 位 + 扩展 ID18 位）
- ID 范围：0 ~ 0x1FFFFFFF
- 特点：可供分配的报文 ID 数量巨大；现在新能源整车、底盘动力网络普遍采用扩展帧
重要知识点：CAN FD 属于 CAN 的升级版本，支持更长数据长度（最大 64 字节），兼容传统 CAN 硬件底层，是当下新能源车型主流升级方案。
仲裁优先级
CAN 总线采用非破坏性位仲裁机制，依靠仲裁段（CAN ID）逐位竞争总线使用权：
- 所有想要发送报文的节点同步从 SOF 位开始逐位向外发送电平；
- 节点每发送 1bit，同时监听总线实际电平；
- 规则：显性电平 (0) 优先级 > 隐性电平 (1)；
- 一旦发现「自己发出的电平」和「总线上监听到的电平不一致」，节点立刻停止发送，切换为只听模式，退出本次竞争。
💡关键结论：CAN ID 数值越小，优先级越高。ID 二进制中越早出现 0 的报文，更容易抢占总线。
AUTOSAR 架构
AUTOSAR 标准将车载软件分层，把 CAN 通信从硬件驱动到应用信号进行标准化封装，自上而下分层简要梳理：
Application 层（应用层）开发者调用 RTE 接口读写信号，不直接操作 CAN 报文。
RTE（运行时环境）应用层与底层通信栈的桥梁，完成信号打包、解包，实现软硬件解耦。
COM 通信模块负责信号 <-> 报文之间的组包、解包，信号初值、超时监测、信号网关转发。
CAN Interface（CanIf）适配层，统一接口，隔离上层 COM 与底层 CAN 驱动，支持多路 CAN 控制器。
CAN Driver（CanDrv）MCU 寄存器驱动层，直接操作 CAN 外设硬件，收发原始 CAN 帧。
MCU 硬件 + CAN 收发器物理层，完成差分信号驱动，对应拓扑图中 CAN_H/CAN_L 硬件电路。
AUTOSAR 带来的优势
- 软硬件解耦，更换 ECU 芯片、更换 CAN 收发器无需大规模修改应用逻辑；
- 标准化报文管理、诊断、通信超时、报文周期配置；
- 支持 CAN、CAN FD、LIN 等多种总线统一管理，便于整车项目移植。