3、车载网络架构：CAN、CAN-FD、以太网、FlexRay等总线在OTA升级中的作用与特点
车载网络架构是OTA（Over-The-Air）升级的物理基础与数据传输通道。不同总线在带宽、实时性、可靠性、物理拓扑及协议栈上存在显著差异，直接决定了OTA升级的策略选择、刷写速度、安全机制及诊断交互方式。理解各总线的技术特性及其在OTA升级中的角色，是设计高效、安全、兼容性强的升级方案的前提。本章将深入剖析CAN、CAN-FD、以太网及FlexRay四种主流车载总线在OTA升级中的核心作用、技术特点、应用场景及工程实践中的关键考量。
3.1 核心原理：各总线在OTA升级中的定位与工作机制
OTA升级的本质是将新的固件镜像从云端下载至车端，再通过车载网络分发至目标ECU（电子控制单元）并完成Flash擦写。这一过程对网络的依赖体现在三个层面：数据通道（承载固件数据流）、诊断会话（UDS协议栈交互）和传输控制（流控、重传、超时管理）。不同总线因其物理层和协议栈的差异，在这三个层面表现出截然不同的能力边界。
- CAN 2.0：经典CAN总线带宽为500kbps，单帧数据场仅8字节。在OTA升级中，CAN通常用于小体积ECU（如车窗控制器、座椅模块）的固件更新，或作为诊断会话的兜底通道。其优势在于极高的可靠性和实时性，但传输效率低下——升级一个256KB的固件，理论耗时超过70秒，实际考虑协议开销和流控，往往需要3-5分钟。
- CAN-FD：CAN-FD（CAN with Flexible Data-rate）在仲裁段保持CAN协议兼容，但在数据段将速率提升至2-5Mbps，单帧数据场扩展至64字节。这使得CAN-FD成为当前OTA升级的主力通道。以4Mbps速率计算，传输同样256KB固件仅需约0.5秒（理论值），实际刷写时间可缩短至30-60秒，兼顾了实时性与吞吐量。
- 车载以太网：以太网提供100Mbps甚至1Gbps的带宽，帧长可达1500字节，支持TCP/IP协议栈。在OTA升级中，以太网通常作为骨干网络，连接网关、中央计算单元和域控制器。固件包先通过以太网高速传输至域控制器，再由域控制器通过CAN-FD或CAN分发至末端ECU。这种"以太网骨干+CAN-FD末端"的混合架构已成为新一代电子电气架构的主流。
- FlexRay：FlexRay采用时间触发机制，带宽10Mbps，具备双通道冗余和确定性通信能力。在OTA升级中，FlexRay主要用于安全关键系统（如线控转向、主动悬架）的固件更新。其确定性时隙分配保证了升级过程中不影响实时控制任务的执行，但协议复杂度高，工具链成本昂贵，应用范围相对有限。
核心理解：OTA升级的网络选型不是"越高速越好"，而是取决于目标ECU的算力、Flash大小、实时性约束以及整车网络拓扑。一个典型的OTA刷写路径是：云端 → 车机（T-Box）→ 以太网 → 域控制器 → CAN-FD/CAN → 目标ECU。每一段总线的选择都需匹配其负载能力和协议特性。
3.2 判断方法与操作流程：如何为OTA升级选择合适的总线策略
在实际工程中，确定某条总线是否适合承载OTA升级任务，需要从以下四个维度进行量化评估：
- 带宽与时间预算：计算固件大小与总线有效吞吐量的比值。有效吞吐量需扣除协议开销（帧头、CRC、填充位）、流控帧（如CAN的CF帧）和重传概率。例如，CAN-FD在4Mbps下有效数据率约为理论值的70%-80%。
- ECU存储与Flash驱动能力：目标ECU的Flash擦写时间（通常为每扇区20-100ms）往往比总线传输时间更长。若Flash擦写成为瓶颈，则提升总线带宽对整体升级时间影响有限。
- 实时性约束：对于动力总成或底盘域ECU，升级过程中必须保证控制报文（如扭矩请求、制动压力）的实时性不被刷写流量挤占。此时需采用优先级设计或时间片轮转策略。
- 诊断协议兼容性：OTA升级依赖UDS（ISO 14229）诊断服务，包括会话控制（0x10）、安全访问（0x27）、写入数据（0x2E）、例程控制（0x31）等。不同总线对UDS的传输层映射不同：CAN使用ISO-TP（15765-2）分段传输，以太网使用DoIP（Diagnostic over IP）。
| 评估维度 | CAN 2.0 | CAN-FD | 车载以太网 | FlexRay |
|---|---|---|---|---|
| 有效吞吐量（典型） | ~40 KB/s | ~350 KB/s | ~11 MB/s (100Mbps) | ~0.8 MB/s |
| 单帧最大数据场 | 8字节 | 64字节 | 1500字节 | 254字节 |
| UDS传输层 | ISO-TP (单帧/多帧) | ISO-TP (FD帧) | DoIP (TCP) | ISO-TP (FlexRay适配) |
| 典型升级对象 | 车身/舒适ECU | 域控制器/传感器 | 中央网关/信息娱乐 | 线控底盘ECU |
| 升级256KB固件耗时 | ~6.5分钟 | ~45秒 | ~2秒 | ~5分钟 |
操作流程建议：在项目早期，应建立"总线负载率-升级时间"仿真模型。将OTA刷写流量叠加到正常通信矩阵中，观察总线负载率是否超过设计上限（CAN通常不超过70%，CAN-FD不超过80%）。若超过，需调整刷写调度策略，例如将刷写任务拆分为多个小段，在车辆空闲时段（如夜间驻车）执行。
3.3 案例拆解：某车型OTA升级中CAN-FD与以太网协同的实战复盘
背景与约束：某中高端纯电动车型采用"中央网关+5个域控制器"的电子电气架构。OTA升级需求覆盖动力域（BMS、MCU）、底盘域（ESP、EPS）和车身域（BCM、门窗）。初始设计仅使用CAN-FD作为刷写通道，但在实车测试中发现两个问题：一是动力域BMS固件达1.2MB，通过CAN-FD刷写需耗时约8分钟，用户体验差；二是升级过程中CAN-FD总线负载率飙升至85%，导致部分实时控制报文延迟。
分析判断过程：团队对流量进行了抓包分析，发现CAN-FD的有效数据率仅为理论值的65%，主要瓶颈在于目标ECU的Flash擦写速度（每扇区40ms）和ISO-TP传输层的流控等待时间。同时，网关到动力域控制器之间已部署100Mbps以太网链路，但未用于OTA。
实际操作步骤：
- 将OTA升级策略调整为两级分发：第一级，通过DoIP协议将固件包从T-Box高速传输至动力域控制器（耗时约2秒）；第二级，由动力域控制器通过内部SPI接口直接刷写BMS Flash，绕过CAN-FD总线。
- 对于无法绕过总线的ECU（如ESP），保留CAN-FD刷写通道，但将刷写任务安排在车辆下电前，并降低刷写优先级，确保实时控制报文优先占用总线。
- 引入"刷写暂停/恢复"机制：当检测到总线负载率超过75%时，自动暂停刷写任务，待负载回落后再恢复。
结果对比：动力域升级时间从8分钟缩短至40秒（含Flash擦写时间）；CAN-FD总线负载率在升级过程中稳定在50%以下；ESP升级期间未出现任何控制报文丢失或延迟超标。
风险与代价：该方案要求域控制器具备足够的本地存储空间（用于暂存固件包）和Flash驱动能力；同时，DoIP协议的安全认证（TLS）增加了网关的CPU负载，需评估网关算力余量。
复盘经验：OTA升级的网络设计应遵循"数据就近分发"原则——尽可能将固件包传输至离目标ECU最近的智能节点，减少低速总线上的长距离传输。同时，必须为实时控制流量预留至少30%的总线带宽余量。
3.4 常见误区与总结复盘
在车载网络与OTA升级的工程实践中，以下误区值得特别注意：
- 误区一：认为CAN-FD可以完全替代CAN。实际上，CAN-FD节点无法与CAN 2.0节点直接通信（仅仲裁段兼容），在混合网络中必须通过网关进行协议转换。OTA升级策略需同时考虑两种总线的共存。
- 误区二：忽视以太网升级时的供电稳定性。高速刷写时ECU电流消耗增大，若车辆蓄电池电压波动超过9V-16V范围，可能导致Flash写入失败。建议在升级流程中增加电压监测步骤。
- 误区三：FlexRay节点升级时未考虑时隙预留。FlexRay的静态时隙是预先分配的，若OTA刷写占用静态时隙，会直接影响线控指令的周期性发送。正确做法是使用动态时隙或预留专用升级时隙。
- 误区四：忽略总线负载率的动态变化。OTA升级并非孤立事件，车辆在升级期间可能同时运行导航、娱乐、空调等应用，产生额外的网络流量。需在升级前进行全车网络负载评估。
风险提示：在OTA升级过程中，若CAN总线发生持续错误帧（Bus-off），可能导致ECU进入静默模式。务必在刷写程序中加入总线状态监测和自动恢复机制，并在升级失败后支持回滚至上一版本固件。