2. 商用车电子电气架构基础
商用车电子电气架构（E/E Architecture）是整车功能实现、信号交互与算力分配的基础。理解传统分布式架构与域集中架构的差异，以及CAN总线在其中的角色与边界，是评估CAN FD升级必要性的前提。本节从架构演进、总线应用、局限与升级动因四个层面展开。
一、传统分布式架构：功能与ECU一一对应
传统商用车普遍采用分布式架构，其核心特征是“一个功能对应一个或多个独立ECU”，各ECU通过CAN、LIN等总线互联。典型场景中，发动机控制、ABS、仪表、车身控制、空调、车门等模块各自独立，线束呈点对点或总线分支状铺开。
这种架构的优点是开发解耦、供应商成熟、单点故障影响范围有限。但随着商用车智能化需求增加，其问题逐渐暴露：
- ECU数量多，线束长度与重量大，装配复杂度高；
- 跨ECU功能需要多节点协同，信号转发层级多，时延不可控；
- 算力分散，难以支撑ADAS、OTA、大数据回传等新功能；
- 软件升级需逐ECU刷写，版本管理与一致性维护成本高。
二、域集中架构：按域整合算力与接口
域集中架构（Domain Centralized Architecture）按功能域划分，将原本分散的ECU功能收敛到域控制器（Domain Controller）中。商用车常见域划分包括：动力域、底盘域、车身域、座舱域、智驾域等。域控制器通过高速骨干网连接，域内则通过CAN FD、LIN、以太网等子网连接传感器与执行器。
与分布式架构相比，域集中架构的关键变化在于：
- 算力集中：域控制器承担域内主要计算与决策，ECU退化为执行器或传感器节点；
- 接口标准化：域内通信协议统一，减少网关转发层级；
- 软件集中：支持域内OTA与统一版本管理，降低刷写复杂度；
- 骨干网升级：域间通信带宽需求提升，推动CAN FD与车载以太网部署。
下表对比两种架构在商用车场景下的关键差异：
| 对比维度 | 传统分布式架构 | 域集中架构 |
|---|---|---|
| ECU数量 | 多，功能独立 | 少，功能整合 |
| 通信骨干 | CAN/LIN为主 | CAN FD/以太网骨干 |
| 算力分布 | 分散在各ECU | 集中在域控制器 |
| OTA能力 | 逐ECU刷写，效率低 | 域级刷写，效率高 |
| 线束复杂度 | 高 | 降低 |
| 典型带宽需求 | 500 kbps | 2 Mbps～5 Mbps |
三、CAN总线在商用车中的应用
CAN总线自20世纪80年代起成为商用车主流车载网络，其多主仲裁、差分传输、错误检测与重发机制，使其在电磁环境复杂的商用车场景中具备较高可靠性。典型应用包括：
- 动力CAN：发动机、变速箱、缓速器、排气后处理等；
- 底盘CAN：ABS、EBS、ESC、转向、悬架等；
- 车身CAN：车门、灯光、雨刮、空调、座椅等；
- 诊断CAN：OBD诊断、UDS服务、故障码读取与刷写。
以J1939协议为例，商用车CAN网络使用29位扩展帧，通过PGN（参数组编号）和SPN（可疑参数编号）组织信号。典型报文周期从10 ms到1 s不等，关键动力信号周期较短，车身信号周期较长。
// J1939典型报文示例（伪代码）
CAN_ID = 0x18FEF100 // PGN 65265，车速相关
DLC = 8
Data[0] = 车速低字节
Data[1] = 车速高字节
周期 = 100 ms
CAN总线的优势在于成本低、生态成熟、抗干扰强。但在域集中架构下，其局限性逐渐成为瓶颈。
四、CAN总线的局限与CAN FD升级动因
传统CAN（Classical CAN）的物理层与数据链路层限制，使其难以满足域集中架构下的新需求，主要局限包括：
- 带宽不足：经典CAN最大有效速率1 Mbps，实际商用车多运行在250 kbps或500 kbps，难以承载域间大量信号与诊断数据。
- 单帧载荷小：每帧最多8字节，长数据需分帧传输，协议开销大，传输效率低。
- 仲裁机制限制：基于ID优先级的非破坏性仲裁，低优先级报文在高负载下时延显著增加，影响实时性。
- 刷写效率低：OTA或诊断刷写时，8字节载荷导致传输时间长，产线节拍与售后效率受限。
- 安全能力弱：经典CAN缺乏内建加密与认证机制，难以满足日益增长的网络安全要求。
CAN FD（Flexible Data-rate）在保持CAN仲裁机制与拓扑兼容性的基础上，将单帧载荷扩展至64字节，并支持数据段可变速率（最高可达5 Mbps以上）。其核心改进包括：
- 数据段速率提升，仲裁段仍保持兼容；
- 单帧载荷64字节，减少分帧开销；
- CRC校验增强，提升数据完整性；
- 与经典CAN共存于同一物理总线，便于渐进升级。
下图展示传统分布式架构与域集中架构的对比，以及CAN与CAN FD在其中的位置关系：
从工程实践看，商用车CAN FD升级并非简单替换收发器，而是涉及网络拓扑、网关路由、信号矩阵、诊断协议与刷写流程的系统性变更。理解架构演进与总线局限，是后续制定升级方案、评估兼容性与设计测试用例的基础。