# 汽车电子架构完整知识体系
> 从 AUTOSAR、MCU、SoC 到 Android，一次讲透
---
## 一、基础概念：一辆车里面有多少"电脑"
一辆现代汽车内部有 **70~150 个 ECU**（Electronic Control Unit，电子控制单元），每个 ECU 就是一个独立的小电脑：
| ECU 名称 | 管什么事 |
|---|---|
| 发动机 ECU | 控制喷油量、点火时机 |
| 变速箱 ECU | 控制换挡逻辑 |
| ESP ECU | 防抱死刹车、车身稳定 |
| EPS ECU | 电动助力转向 |
| 安全气囊 ECU | 碰撞检测、气囊弹出 |
| BCM | 车身控制（车灯、车窗、门锁） |
| BMS | 电池管理（电动车电池监控） |
| 空调 ECU | 温度控制、风量、座椅加热 |
| 仪表 ECU | 车速表、转速表显示 |
| 娱乐主机 | 导航、音乐、蓝牙 |
| T-Box | 远程通信（手机控车、OTA） |
| ADAS ECU | 辅助驾驶（摄像头、雷达处理） |
这些 ECU 各自独立，线束复杂（一辆车线束总长超过 **5 公里**），成本高，难以协同。
---
## 二、两类处理器：MCU 与 SoC
汽车内部只有两类处理器在同时工作：
### MCU（微控制器）
- **代表芯片**：英飞凌 AURIX、NXP S32K / S32G、瑞萨 RH850、TI TMS570
- **CPU**：单核或少核，几十~几百 MHz
- **内存**：KB ~ MB 级
- **存储**：几 MB Flash
- **功耗**：几百 mW ~ 几 W
- **价格**：几十元
- **特点**：有 CAN 控制器，没有 GPU，硬实时，高可靠
- **运行软件**：AUTOSAR Classic Platform (CP)
- **用在哪**：动力域、底盘域、车身域
### SoC（片上系统）
- **代表芯片**：高通 SA8155 / SA8295、英伟达 Orin、瑞萨 R-Car H3、地平线征程 5
- **CPU**：多核（4~12 核），1~3 GHz
- **内存**：GB 级
- **存储**：几十~几百 GB
- **功耗**：几 W ~ 几十 W
- **价格**：几百~几千元
- **特点**：有 GPU / NPU / ISP，部分有 CAN 控制器
- **运行软件**：Android (AAOS)、Linux、AUTOSAR Adaptive Platform (AP)
- **用在哪**：座舱域、智驾域
### MCU vs SoC 一句话区分
> MCU = 单片机，像 Arduino 的工业级大哥，管"生死攸关"的事
> SoC = 手机芯片，像手机里的骁龙，管"用户体验"的事
---
## 三、五大域架构
### 3.1 为什么需要域
旧架构是分布式的，每增加一个功能就加一个 ECU。新架构把功能相近的 ECU 合并，由一个**域控制器**统一管理。
### 3.2 五大域总览
| 域 | 域控芯片 | 运行软件 | 具体职责 | 安全等级 |
|---|---|---|---|---|
| **动力域** | MCU（英飞凌 AURIX） | AUTOSAR CP | 发动机喷油/点火、变速箱换挡、电机控制、电池管理 BMS | ASIL-D（最高） |
| **底盘域** | MCU（英飞凌 AURIX） | AUTOSAR CP | ESP 防抱死刹车、EPS 电动助力转向、悬架调节 | ASIL-D |
| **车身域** | MCU（NXP S32K / 瑞萨） | AUTOSAR CP | 车灯控制、车窗/门锁、空调控制、雨刮/座椅 | ASIL-B ~ QM |
| **座舱域** | SoC（高通 SA8155 / SA8295） | Android AAOS | 中控大屏、仪表盘、语音助手、导航/音乐、OTA | QM（无安全要求） |
| **智驾域** | SoC（英伟达 Orin / 地平线征程5） | Linux / AUTOSAR AP | 摄像头/雷达感知、多传感器融合、路径规划、转向/刹车控制 | ASIL-B ~ D |
五个域之间通过**车载以太网 + CAN 总线**互相通信。
---
## 四、AUTOSAR 是什么
**AUTOSAR** = AUTomotive Open System ARchitecture（汽车开放系统架构）
> 它不是操作系统，而是一套**软件架构标准/规范**，规定了汽车芯片上的软件应该怎么分层、怎么写、怎么通信。
### 4.1 AUTOSAR Classic Platform（CP）
**跑在 MCU 上**，用于动力域、底盘域、车身域。
**分层结构（自上而下）：**
| 层级 | 名称 | 说明 |
|---|---|---|
| 第1层 | 应用层 SWC | 车企写的业务逻辑（如发动机喷油算法、电池均衡算法） |
| 第2层 | RTE 运行时环境 | 组件间通信桥梁 |
| 第3层 | BSW 服务层 | 诊断/存储/通信管理/OS |
| 第4层 | BSW ECU 抽象层 | I/O 接口、通信接口抽象 |
| 第5层 | BSW MCAL 微控制器抽象层 | CAN 驱动/SPI 驱动/ADC 驱动，直接操作芯片硬件 |
| 第6层 | MCU 芯片硬件 | 英飞凌 AURIX / NXP S32K 等 |
**MCAL 层的核心价值**：AUTOSAR MCAL 定义标准接口，各芯片厂商负责实现。车企的上层代码完全不用改，换芯片只换 MCAL 实现——这就是**可移植性**。
**CP 的特点**：
- OS：OSEK/VDX 固定优先级抢占式 RTOS
- 编译时静态配置，不支持运行时变更
- 硬实时（微秒级响应）
- 安全等级最高（ASIL-D）
- 不允许动态内存分配
### 4.2 AUTOSAR Adaptive Platform（AP）
**跑在 SoC 上**，用于智驾域。
**分层结构（自上而下）：**
| 层级 | 名称 | 说明 |
|---|---|---|
| 第1层 | 应用层 | 智驾算法服务（感知/融合/预测/规划/控制） |
| 第2层 | ARA 运行时环境 | 执行管理、通信管理、服务发现、诊断、OTA、日志、加密 |
| 第3层 | POSIX OS | 安全 Linux / QNX |
| 第4层 | SoC 芯片硬件 | 英伟达 Orin / 地平线征程5 等 |
**AP 解决什么问题**：
| CP 的局限 | AP 的解决 |
|---|---|
| 静态配置，无法运行时变更 | 支持动态部署，像手机更新 App 一样 |
| 不支持 SOA | 支持面向服务架构（服务发现、发布/订阅） |
| 不支持 OTA | 支持软件热更新 |
| MCU 资源太小，跑不了 AI | 在 SoC 上跑，有 GPU/NPU 加速 |
| 确定性不够（Linux 不确定） | 在 Linux 上层加确定性调度，保证时间槽 |
**AP 的核心功能**：
| 功能 | 说明 |
|---|---|
| 执行管理 (EM) | 按依赖顺序启动应用、监控进程健康、崩溃自动重启、连续崩溃则降级 |
| 通信管理 (CM) | SOME/IP 协议通信、发布/订阅模式 |
| 服务发现 | 服务上线自动注册、下线自动感知 |
| OTA 更新 (UCM) | 下载更新包→校验签名→热安装→重启服务 |
| 确定性调度 | 时间槽分配，保证从"看到障碍物"到"踩刹车"延迟确定 |
| 安全隔离 | 各进程独立内存空间，感知崩溃不影响控制 |
### 4.3 CP vs AP vs Android 对比
| 维度 | CP (MCU) | AP (SoC) | Android (SoC) |
|---|---|---|---|
| 全称 | Classic Platform | Adaptive Platform | Android Automotive OS |
| 跑在哪 | MCU 芯片 | 智驾/网关 SoC | 座舱 SoC |
| OS | OSEK RTOS | Linux (POSIX) | Linux |
| 实时性 | 硬实时（微秒） | 确定性（毫秒） | 不确定 |
| 动态部署 | 不支持 | 支持（OTA） | 支持（App） |
| 通信协议 | CAN / LIN | SOME/IP 以太网 | 互联网 + CAN |
| 架构风格 | 信号驱动 | 面向服务 SOA | App / Service |
| 安全等级 | ASIL-D | ASIL-B ~ D | QM（无安全） |
| 典型场景 | 发动机/刹车/转向 | 自动驾驶感知/规划 | 导航/音乐/语音 |
| 市场状态 | 大量使用 | 逐步落地中 | 大量使用 |
---
## 五、通信体系
### 5.1 三种通信协议
| 协议 | 带宽 | 数据量 | 线缆 | 用途 |
|---|---|---|---|---|
| **CAN 总线** | 1 Mbps（CAN FD 8 Mbps） | 最大 8 字节 | 两根铜线 | MCU 域内部，车速/温度/开关等小信号 |
| **LIN 总线** | 20 kbps | 极小 | 一根线 | 车窗电机、雨刮、后视镜等简单执行器 |
| **车载以太网** | 100 Mbps ~ 1 Gbps | 无限制 | 双绞线/光纤 | SoC 域内部 + 跨域，传感器数据/算法结果 |
### 5.2 CAN 通信硬件链路
任何 CAN 通信都必须经过**四层硬件**，缺一不可：
| 层级 | 硬件 | 说明 | 类比 |
|---|---|---|---|
| 第1层 | **CPU** | 处理器核心，产生/消费数据 | 你的电脑 |
| 第2层 | **CAN 控制器** | 芯片内部模块，把数据打包成 CAN 报文格式 | 网卡 |
| 第3层 | **CAN 收发器** | 外部独立小芯片，数字信号 ↔ 差分电信号转换 | 网口/水晶头 |
| 第4层 | **CAN 总线** | 两根物理铜线（CAN_H + CAN_L），所有节点共享 | 网线 |
> **关键认知**：没有任何东西能直接连 CAN 总线，中间一定有收发器。CAN 控制器输出的是芯片内部数字信号，CAN 总线上传输的是差分电信号，两者完全不同，必须由 CAN 收发器做转换。
### 5.3 谁有 CAN 控制器
| 设备 | 有 CAN 控制器？ | 说明 |
|---|---|---|
| MCU（域控制器） | 有 | MCU 芯片内部自带 |
| ECU（末端控制器） | 有 | ECU 内部有 MCU 芯片 |
| 座舱 SoC | 大多有 | 如高通 SA8155 内置 CAN 控制器 |
| 智驾 SoC | 通常没有 | 专注计算，不接 CAN |
### 5.4 两条通信链路
**链路 A：有 CAN 控制器 → 直接上总线 → 到 ECU**
适用：座舱 SoC → 车身 ECU
> 座舱 SoC CPU → SoC 内部 CAN 控制器 → CAN 收发器 → CAN 总线 → ECU 的 CAN 收发器 → ECU 的 CAN 控制器 → ECU 的 CPU
**链路 B：没有 CAN 控制器 → 以太网 → 网关 MCU → CAN 总线 → ECU**
适用：智驾 SoC → 底盘 ECU
> 智驾 SoC CPU → 以太网接口 → 车载以太网 → 网关 MCU 的以太网接口 → 网关 MCU CPU → 网关 MCU 内部 CAN 控制器 → CAN 收发器 → CAN 总线 → ECU
### 5.5 网关 MCU 的三种角色
| 角色 | 说明 | 示例 |
|---|---|---|
| 协议转换 | 不同协议之间转换 | 智驾 SoC 以太网包 → CAN 报文 → ECU |
| CAN 路由 | 不同 CAN 总线之间转发 | 动力域 CAN 报文 → 转发到车身域 CAN → 仪表显示 |
| CAN ↔ LIN 转换 | CAN 和 LIN 之间转换 | CAN 指令 → LIN → 车窗 ECU |
### 5.6 SOME/IP 通信承载的功能
SOME/IP = Scalable service-Oriented MiddlewarE over IP（基于 IP 的可扩展面向服务中间件），是车载以太网上的服务通信协议。
| 功能类别 | 具体功能 | 数据量 |
|---|---|---|
| **传感器数据** | 8 路摄像头（每路 30fps）、5 路毫米波雷达、激光雷达点云、12 路超声波、GPS/IMU | 最大（GB 级/秒） |
| **智驾算法链** | 感知→融合→预测→规划→控制，每步结果推送给下一步 | 中等 |
| **智驾功能** | 自动泊车、高速领航 NOA、城市领航 NOA、自动紧急制动 AEB、车道保持 LKA、自适应巡航 ACC | 小 |
| **跨域通信** | 智驾状态→仪表显示、障碍物警告→中控弹窗、环视画面→中控、DMS 驾驶员状态→座舱、用户操作→智驾、语音指令→智驾 | 中~大 |
| **系统服务** | 时间同步 gPTP（< 1 微秒精度）、服务发现、OTA 更新、诊断服务、日志收集、健康监控/心跳 | 小 |
### 5.7 CAN vs SOME/IP 分工
**CAN 负责（MCU 域内部通信）：**
- 车速、转速、温度、压力（几个字节的小信号）
- 开关状态（车门开/关、灯亮/灭）
- 简单控制指令（开空调、开车窗）
- 安全关键的快速信号（气囊触发、ESP 介入）
**SOME/IP 负责（SoC 域内部 + 跨域通信）：**
- 摄像头/雷达/激光雷达的海量数据
- 感知/融合/预测/规划的算法链结果
- 高精地图数据
- 智驾 ↔ 座舱的跨域消息
- OTA 更新、诊断、日志
**两者共存，各管各的：**
| 起点 | 通信方式 | 终点 |
|---|---|---|
| 座舱 SoC | CAN（直接） | MCU 域 → ECU |
| 智驾 SoC | 以太网 SOME/IP → 网关 MCU 转 CAN | ECU |
| 智驾 SoC | 以太网 SOME/IP | 座舱 SoC |
---
## 六、Android (AAOS) 在座舱中的角色
### 6.1 AAOS 软件栈
| 层级 | 组件 | 说明 |
|---|---|---|
| 第1层 | 车载应用 | 导航、音乐、电话、设置、第三方 App |
| 第2层 | CarService | CarPropertyService、CarAudioService、CarHVACService |
| 第3层 | **VHAL（Vehicle HAL）** | 桥梁：把 Android 语言翻译成车辆语言 |
| 第4层 | Linux Kernel | CAN 驱动、以太网驱动 |
| 第5层 | SoC 硬件 | 高通 SA8155 / SA8295 |
### 6.2 VHAL 的桥梁作用
VHAL（Vehicle HAL）是连接 Android 与车辆硬件的核心桥梁：
| 方向 | 数据流 |
|---|---|
| App → 硬件 | Android App 调用 CarPropertyManager.setProperty() → CarService → VHAL → SoC CAN 控制器 → CAN 总线 → MCU/ECU |
| 硬件 → App | MCU/ECU 通过 CAN 回报数据 → SoC CAN 控制器 → VHAL 回调 → CarService 通知 App → UI 更新 |
### 6.3 一次用户操作的完整链路
**场景：用户在车机大屏上把空调从 24°C 调到 26°C**
| 步骤 | 层级 | 操作 |
|---|---|---|
| 1 | 用户 | 点击屏幕 + 按钮 |
| 2 | Android App | 调用 CarPropertyManager.setProperty(HVAC_TEMPERATURE, 26) |
| 3 | CarService | 接收请求，验证权限，转换数据格式 |
| 4 | VHAL | 构造 CAN 报文 |
| 5 | SoC CAN 控制器 | 打包成 CAN 报文格式 |
| 6 | SoC CAN 收发器 | 数字信号转差分信号 |
| 7 | CAN 总线 | 物理传输 |
| 8 | 网关 MCU | 路由转发到车身域 CAN 总线 |
| 9 | 车身域 MCU (AUTOSAR CP) | COM 模块解析信号，空调 SWC 处理 |
| 10 | 空调 ECU | 驱动压缩机/风门 |
| 11 | 硬件 | 车内温度变化 |
| 12 | MCU | 通过 CAN 回报"当前温度=26°C" |
| 13 | VHAL | 收到回调 |
| 14 | Android UI | 更新显示 "26°C" |
---
## 七、智驾域 AP 架构
### 7.1 AP 在 SoC 上的位置
AP **不跑在座舱 SoC 上**，跑在智驾域控或中央网关的 SoC 上。
| SoC 用途 | 运行什么 | 说明 |
|---|---|---|
| 座舱 SoC | Android AAOS | 不是 AUTOSAR AP |
| 智驾 SoC | Linux + AUTOSAR AP | 或纯 Linux（不用 AP） |
| 单颗 SoC（未来） | Hypervisor 隔离，一个核跑 AP，另一个核跑 Android | 互不干扰 |
### 7.2 AP 智驾算法链
| 阶段 | 服务 | 输入 | 输出 | 时间 |
|---|---|---|---|---|
| 1 | 感知服务 | 摄像头图像 + 雷达数据 | 目标列表（类型/位置/速度/置信度） | 0~20ms |
| 2 | 融合服务 | 多传感器感知结果 | 融合后的跟踪目标列表 | 20~25ms |
| 3 | 预测服务 | 跟踪目标状态 | 目标未来轨迹 + 意图判断 | 25~30ms |
| 4 | 规划服务 | 预测结果 + 当前车速 | 目标路径 + 目标速度 + 行为决策 | 30~35ms |
| 5 | 控制服务 | 规划结果 | 转向角 + 油门开度 + 刹车压力 | 35~38ms |
| 6 | 输出 | 控制指令 | 通过以太网→网关MCU→CAN→底盘ECU | 38~40ms |
> 全程 40ms 以内完成（人眨一次眼约 300ms）
### 7.3 AP 与 Android 的部署关系
**方式一：两颗独立 SoC（当前主流）**
| SoC | 运行软件 | 通信方式 |
|---|---|---|
| 智驾 SoC | AP + Linux | 以太网 SOME/IP |
| 座舱 SoC | Android | CAN（直接上总线） |
两者通过**车载以太网**交互（智驾→座舱：状态推送、告警、环视画面；座舱→智驾：用户操作、语音指令）。
**方式二：单颗 SoC 跑两套系统（未来趋势）**
通过 Hypervisor（虚拟化层）隔离：
- 安全分区：AP + Linux（智驾，CPU 核心 1~4，GPU 分区 A，NPU 全部）
- 普通分区：Android（座舱，CPU 核心 5~8，GPU 分区 B）
- 两者互不干扰，AP 崩溃不影响 Android，Android 崩溃不影响 AP
---
## 八、整车架构全景
### 8.1 全局架构总图
| 层级 | 组件 | 职责 |
|---|---|---|
| 用户层 | 屏幕触控、语音指令、手机 App、钥匙、按钮 | 用户输入 |
| 座舱 SoC | Android AAOS + VHAL | 显示、AI、多媒体、网络、与 MCU 通信 |
| 智驾 SoC | AUTOSAR AP / Linux | 自动驾驶感知/融合/预测/规划/控制 |
| 网关 MCU | AUTOSAR CP | 以太网↔CAN 协议转换、CAN 路由转发、CAN↔LIN 转换 |
| 动力域 MCU | AUTOSAR CP | 发动机、变速箱、电池管理 |
| 底盘域 MCU | AUTOSAR CP | 制动、转向、悬架 |
| 车身域 MCU | AUTOSAR CP | 车灯、车窗、门锁、空调 |
| 末端 ECU | 独立硬件 | 具体执行器控制 |
| 物理执行器 | 无软件 | 发动机、电机、刹车、转向、空调、灯、窗 |
### 8.2 完整概念关系
| 概念 | 本质 | 一句话 |
|---|---|---|
| AUTOSAR Classic (CP) | MCU 上的软件标准 | 规定 MCU 上的软件怎么写，跑安全关键控制 |
| AUTOSAR Adaptive (AP) | SoC 上的软件标准 | 规定 SoC 上的软件怎么写，跑自动驾驶计算 |
| Android (AAOS) | 座舱 SoC 上的操作系统 | 跑在座舱 SoC 上，管人机交互层 |
| MCU 芯片 | 低功耗微控制器 | 管动力/底盘/车身域的安全控制 |
| SoC 芯片 | 高性能片上系统 | 管座舱用户体验或智驾计算 |
| ECU | 末端执行控制器 | 独立硬件，直接驱动执行器 |
| VHAL | Android 与车辆的桥梁 | 把 App 指令翻译成 CAN 报文 |
| CAN 总线 | 物理铜线 | MCU 域的通信线路，传小信号 |
| 车载以太网 | 高速物理线缆 | SoC 域的通信线路，传大数据 |
| SOME/IP | 以太网上的通信协议 | 智驾算法链内部通信 + 跨域通信 |
### 8.3 数据流总结
**场景 1：用户开空调（座舱 → MCU → ECU）**
> App → CarService → VHAL → SoC CAN 控制器 → CAN 收发器 → CAN 总线 → 网关 MCU 路由 → 车身域 CAN → 车身域 MCU (CP) → 空调 ECU → 压缩机动作
**场景 2：自动泊车（座舱 → 智驾 → MCU → ECU）**
> App → SOME/IP 以太网 → 智驾 SoC (AP) → 感知/规划/控制 → SOME/IP 以太网 → 网关 MCU（以太网→CAN 协议转换）→ CAN 总线 → 底盘域 MCU (CP) → ESP/EPS ECU → 刹车/转向动作
**场景 3：智驾告警 → 仪表显示（智驾 → 座舱）**
> 智驾 SoC (AP) → SOME/IP 以太网 → 座舱 SoC (Android) → CarService → 仪表 App 显示红色警告
---
以上就是汽车电子架构的完整知识体系。**AUTOSAR 是标准，芯片是硬件，Android 是 SoC 上跑的操作系统。AUTOSAR Classic 管安全关键的 MCU，Android 管用户可见的 SoC 座舱，两者通过 CAN / 以太网通信。**
