第2章：整车电子电气架构基础

各位同学好，我是老张。今天咱们聊聊整车电子电气架构的基础。说实话，这个题目看着大，但它是整个OTA系统的地基。地基不牢，后面盖什么楼都得塌。

我入行那会儿，车上的ECU还不到10个。现在呢？随便一辆智能电动车，ECU数量轻松破百。这么多脑子，怎么协调工作？这就引出了我们今天要讲的四种架构。

2.1 分布式架构

分布式架构，说白了就是“各扫门前雪”。每个功能模块都有自己的ECU，各干各的。

特点：

• 每个ECU负责单一功能（比如车窗、门锁、雨刮）
• ECU之间通过CAN/LIN总线通信
• 软件和硬件强耦合，换一个功能就得换硬件

我在2015年参与过一个项目，那车上有60多个ECU。每次做OTA升级，光梳理ECU之间的依赖关系就够头疼的。你想想看，升级一个门控模块，还得考虑它和BCM、PEPS之间的握手协议。稍有不慎，车就趴窝了。

典型拓扑：

ECU1(BCM) ←→ ECU2(PEPS) ←→ ECU3(GW)
   ↓              ↓
ECU4(门窗)    ECU5(座椅)

嗯，这里要注意。分布式架构虽然灵活，但线束成本高、升级困难。我记得有一次，客户要求增加一个远程启动功能。结果呢？得换BCM硬件，重新走线，前后折腾了三个月。

2.2 域集中架构

域集中架构，就是把功能相近的ECU合并到一个“域控制器”里。比如车身域、动力域、底盘域、信息娱乐域。

为什么会出现？ 说白了，分布式架构太乱了。我见过一辆豪华车，光CAN网络就有5条，网关配置表比字典还厚。域集中架构就是给这些“散兵游勇”找个领导。

域控制器的作用：

• 整合多个ECU的功能
• 提供更强的算力（通常用多核SoC）
• 支持以太网通信，带宽更大

典型架构：

+------------------+
|  中央网关        |
+--------+---------+
         |
+--------+---------+  +------------------+
| 车身域控制器     |  | 信息娱乐域控制器 |
| - 门窗           |  | - 导航           |
| - 灯光           |  | - 语音           |
| - 座椅           |  | - 仪表           |
+------------------+  +------------------+

你想想看，域集中架构对OTA的好处是什么？升级对象从几十个ECU变成了几个域控制器。升级路径清晰了，刷写效率也高了。

2.3 中央计算架构

中央计算架构，就是“一个大脑管所有”。整车只有一个或两个高性能计算平台，所有功能都跑在上面。

核心思想： 硬件标准化，软件定义功能。说白了，就是像手机一样，硬件平台统一，功能靠软件升级。

技术特点：

• 采用高性能SoC（如NVIDIA Orin、高通SA8295）
• 支持硬件虚拟化，多个操作系统并行运行
• 所有传感器数据汇聚到中央处理器

典型拓扑：

+------------------+
| 中央计算平台     |
| - 自动驾驶       |
| - 座舱           |
| - 车身控制       |
| - 网关           |
+--------+---------+
         |
+--------+---------+
| 区域控制器       |
| (负责IO采集)     |
+------------------+

我记得有个项目，客户要求实现“软件定义汽车”。我们用了中央计算架构，把原来需要5个ECU的功能全部整合到一个平台上。OTA升级从原来的2小时缩短到15分钟。效果立竿见影。

2.4 SOA架构

SOA，全称Service-Oriented Architecture，面向服务的架构。它不是硬件架构，而是软件架构思想。

核心概念： 把功能拆成独立的“服务”，服务之间通过标准接口通信。就像乐高积木，每个服务是一个积木块，可以自由组合。

SOA的关键要素：

• 服务发现： 服务提供者注册，消费者查找
• 服务接口： 标准化API（通常用SOME/IP或DDS）
• 服务编排： 组合多个服务实现复杂功能

代码示例： 一个简单的SOA服务定义

// 车窗服务接口
service WindowService {
  version 1.0
  
  // 方法
  method openWindow(windowId: uint8, position: uint8) -> bool
  method closeWindow(windowId: uint8) -> bool
  
  // 事件
  event windowPositionChanged(windowId: uint8, position: uint8)
  
  // 属性
  property windowStatus: array<uint8, 4>
}

嗯，这里要注意。SOA不是银弹。我见过一些团队，为了SOA而SOA，把简单的功能拆成十几个服务，结果通信开销比功能本身还大。说白了，服务粒度要适中。

四种架构对比：

架构类型	ECU数量	OTA复杂度	软件灵活性	典型代表
分布式	50-100+	高	低	传统燃油车
域集中	5-10个域控	中	中	早期智能车
中央计算	1-2个中央平台	低	高	特斯拉、蔚来
SOA	取决于硬件	极低	极高	最新架构

我个人习惯，做架构选型时先问三个问题：

1. 这辆车需要支持多少功能？
2. 未来3年，功能会增加多少？
3. OTA升级频率是多久一次？

答案不同，架构选择就不同。分布式架构虽然老，但成本低、可靠性高。中央计算架构虽然新，但对散热、供电要求高。没有最好的架构，只有最合适的。

好了，这一章就到这里。下一章我们聊聊OTA系统的核心——升级包管理。到时候我会分享一些实际项目中的踩坑经验。