2. 整车电子电气架构基础：四种架构对OTA的影响
做OTA升级，首先得搞清楚车上的电子电气架构长什么样。说白了，架构决定了你能怎么升级、升级多快、会不会出问题。我这些年踩过的坑，十有八九都跟架构设计脱不了干系。
咱们从最老的开始，一路讲到最新的SOA。每种架构我都会结合项目里的真实情况来讲。
2.1 分布式架构：ECU各自为政
这是十年前最常见的方案。每个功能一个ECU，门控、车窗、雨刮、座椅……各管各的。通信靠CAN/LIN总线，偶尔用FlexRay。
核心特征：每个ECU固件独立，升级得一个一个来。
我记得2018年做一个项目，车上42个ECU。客户要求OTA升级，我一看架构图就头疼。每个ECU的MCU型号不同，Flash大小不同，升级协议也不同。有的用UDS，有的用私有协议，还有几个压根不支持Bootloader跳转。
分布式架构对OTA的影响，我总结了几点：
- 升级效率低——每个ECU单独刷，42个节点全刷完，顺利的话也得40分钟。要是某个节点刷挂了，还得整车断电重来。
- 版本管理混乱——每个ECU有自己的版本号，组合起来就是天文数字。我见过一个项目，光版本兼容性矩阵就写了2000多行。
- 带宽瓶颈——CAN总线最高1Mbps，刷一个2MB的固件，理论传输就要16秒。实际加上协议开销，30秒都算快的。
- 升级安全性差——很多老ECU没有安全启动，刷写过程中断电就变砖。我曾经遇到过，升级到一半CAN总线被高优先级报文占满，刷写超时，三个ECU同时变砖。
避坑指南：分布式架构做OTA，一定要先做ECU能力普查。我曾经跳过这一步，结果发现有个门控ECU的Flash只有64KB，固件压缩后还放不下。最后只能换硬件，项目延期两个月。
2.2 域集中架构：按功能域整合
后来大家发现ECU太多管不过来，就开始搞域集中。把相近功能的ECU合并到一个域控制器里。常见的域有：动力域、底盘域、车身域、信息娱乐域、自动驾驶域。
域控制器一般用高性能SoC，跑Linux或QNX。域内ECU通过CAN/LIN连到域控，域控之间走以太网。
| 域类型 | 包含功能 | 典型SoC | OTA影响 |
|---|---|---|---|
| 动力域 | 发动机、变速箱、BMS | Infineon TC3xx | 升级需保证扭矩安全 |
| 底盘域 | ESP、EPS、空气悬架 | NXP S32G | 升级期间不能影响制动 |
| 车身域 | 门控、车窗、灯光 | Renesas RH850 | 可并行升级，影响小 |
| 信息娱乐域 | 仪表、中控、T-Box | Qualcomm SA8155 | 升级频繁，A/B分区常见 |
| 自动驾驶域 | 感知、规划、控制 | NVIDIA Orin | 升级需功能安全等级 |
域集中架构对OTA的好处很明显：
- 节点数减少——从42个ECU降到6-8个域控，升级时间大幅缩短。
- 以太网骨干——100Mbps/1Gbps带宽，刷写速度不再是瓶颈。
- 统一升级管理——域控作为升级代理，负责域内ECU的刷写协调。
但也不是没坑。我做过一个项目，车身域控同时管理12个ECU。升级时域控先升级自己，然后依次刷写子节点。结果域控升级后重启，子节点全部失联。查了半天，发现是域控的CAN路由表在升级后被清空了。
经验之谈：域控升级时，一定要保留子节点的路由信息和升级状态。我现在的做法是：域控升级前先把子节点状态快照存到备份分区，升级完成后自动恢复。
2.3 中央计算架构：一个大脑管所有
到了中央计算架构，车上就剩一个或两个中央计算机。所有传感器、执行器都通过区域网关（Zone Gateway）连到中央计算机。区域网关只做数据转发，不做决策。
这种架构对OTA来说，简直是福音。
- 单点升级——主要升级中央计算机就行，区域网关的固件基本不变。
- 算力充足——中央计算机用服务器级芯片，跑容器化应用，升级可以做到热更新。
- 统一安全策略——所有升级包签名验证都在中央计算机完成，安全策略一致。
但中央架构也有新问题。我记得一个项目，中央计算机负责所有ADAS功能。升级过程中，客户要求不能中断辅助驾驶。这就麻烦了——升级期间，感知算法要持续运行，控制指令要实时输出。
我们最后用了热升级+影子模式的方案：
// 热升级伪代码
1. 启动新版本容器（影子模式）
2. 新旧版本同时接收传感器数据
3. 比较新旧版本输出差异
4. 差异在安全阈值内 → 切换流量到新版本
5. 差异超出阈值 → 回滚旧版本
6. 确认新版本稳定 → 停止旧版本容器这个方案对内存和算力要求很高。中央计算机得同时跑两套算法，内存至少翻倍。我们当时用的NVIDIA Thor，256GB内存，勉强够用。
注意：中央架构下，区域网关的固件虽然不常升级，但一旦需要升级，就得整车所有网关一起刷。因为区域网关之间没有独立升级通道，必须通过中央计算机串行刷写。我建议区域网关的固件设计成向前兼容至少3个版本。
2.4 SOA架构：服务化才是终极形态
SOA（Service-Oriented Architecture）把车上的功能拆成一个个服务。每个服务独立部署、独立升级、独立运行。服务之间通过SOME/IP或DDS通信。
SOA对OTA的影响是革命性的：
- 细粒度升级——只升级有问题的服务，不用动整个系统。比如只升级泊车感知服务，不影响行车感知服务。
- 灰度发布——先升级10%的车，观察没问题再全量推送。SOA的服务发现机制天然支持灰度。
- 热替换——服务可以做到不停机升级。新版本服务启动后，旧版本服务优雅退出，连接无缝迁移。
- 版本兼容——每个服务有自己的接口版本号，服务注册中心负责版本匹配。不兼容的接口自动路由到旧版本服务。
我去年主导的一个SOA项目，升级体验是这样的：
# 升级一个微服务
1. 云端推送新版本服务镜像
2. 中央计算机下载并校验签名
3. 启动新版本服务（监听新端口）
4. 服务注册中心更新路由表
5. 新请求路由到新版本服务
6. 旧版本服务等待现有请求完成
7. 旧版本服务优雅退出
8. 升级完成，零停机整个过程用户无感知。导航服务升级时，用户正在用的导航会话不受影响。等用户下次重新规划路线，才会用到新版本。
SOA升级的核心优势：服务级升级粒度 + 灰度发布 + 热替换 + 零停机。这是传统架构完全做不到的。
但SOA也不是银弹。我踩过的坑包括：
- 服务间依赖复杂——A服务升级后，B服务调用A的接口返回格式变了，导致B服务崩溃。后来我们强制要求所有接口变更必须向后兼容。
- 状态同步问题——热替换时，旧服务的运行状态怎么迁移到新服务？我们用了Redis做状态缓存，但延迟敏感的服务还是有问题。
- 调试困难——几十个服务同时运行，出问题很难定位。我们上了分布式链路追踪（OpenTelemetry），才勉强能排查。
我的建议：SOA架构下，每个服务都要有健康检查接口和就绪检查接口。Kubernetes的liveness probe和readiness probe可以直接用。另外，服务启动时不要立即接受请求，等初始化完成后再注册到服务中心。
2.5 四种架构对比总结
我画了一张对比图，把四种架构对OTA的影响放在一起看：
从这张图能看出来，架构越先进，OTA升级体验越好。但要注意，架构升级不是一蹴而就的。我见过很多项目想一步到位上SOA，结果基础架构没准备好，服务拆得太细，反而把系统搞复杂了。
我个人建议：如果现在还是分布式架构，先往域集中走。域集中稳定了，再考虑中央计算。SOA可以提前规划，但不要强求一步到位。毕竟，车上的东西，稳定比先进更重要。