一、汽车电子电气架构演进与Android Automotive OS概述
大家好，我是你们这门课的主讲。今天咱们聊聊汽车电子电气架构的演进，以及Android Automotive OS是怎么诞生的。
说实话，我入行那会儿，汽车电子还是个相对“封闭”的领域。一辆车上有几十个甚至上百个ECU（电子控制单元），各管各的。你想想看，一个车窗升降，可能就得过三四个ECU的“审批”。这种架构，我们叫它分布式ECU架构。
1.1 分布式ECU架构：各自为战的“小作坊”
分布式架构长什么样？简单说，就是每个功能都有自己独立的“大脑”。
- 发动机：一个ECU管喷油点火
- 变速箱：另一个ECU管换挡逻辑
- 车窗：再来一个ECU管升降
- 车灯：还得有一个
这种设计的好处是，各模块独立开发，互不干扰。但坏处也很明显——线束多得像蜘蛛网，整车线束长度动不动就几公里。而且，你想升级一个功能？对不起，得把整个ECU拆下来刷写。
核心痛点：算力分散、通信延迟高、OTA升级困难、线束成本爆炸。
我记得2015年那会儿，我参与过一个项目，光是解决CAN总线上的信号冲突，就花了整整两周。说白了，这种架构已经跟不上智能汽车的需求了。
1.2 域集中架构：从“小作坊”到“区域中心”
后来，行业开始往域集中架构迁移。什么意思？就是把功能相近的ECU，合并到一个“域控制器”里。
典型的域划分包括：
| 域名称 | 负责功能 | 典型芯片 |
|---|---|---|
| 动力域 | 发动机、变速箱、电池管理 | Infineon TC3xx |
| 底盘域 | 制动、转向、悬架 | NXP S32K |
| 车身域 | 车窗、门锁、灯光、空调 | TI TDA4 |
| 智能座舱域 | 仪表、中控、HUD、语音 | 高通SA8155/SA8295 |
| 自动驾驶域 | 感知、规划、决策 | 英伟达Orin/Thor |
这种架构的好处很明显：
- 线束减少了30%-50%
- 算力可以集中调度
- 域内通信延迟大幅降低
- 支持部分OTA升级
但问题也来了——域与域之间怎么通信？尤其是智能座舱域和自动驾驶域，它们需要大量数据交换。我曾在项目中遇到过，座舱域和智驾域之间用以太网通信，结果因为QoS配置不当，导致视频流卡顿。嗯，这里要注意，域间通信的实时性和带宽，是架构设计的关键。
1.3 中央计算平台：真正的“大脑”
到了中央计算平台阶段，架构进一步简化。整车只有一个或两个超级计算中心，所有功能都跑在上面。
这种架构的特点：
- 硬件：高性能SoC（如高通Snapdragon Ride、英伟达Thor），算力可达1000+ TOPS
- 软件：虚拟化技术，一个芯片上同时跑多个操作系统（Linux、QNX、Android）
- 通信：全车以太网，带宽可达10Gbps
我个人习惯：在做中央计算平台架构时，一定要提前规划好虚拟化层的资源隔离。否则，一个APP崩溃，可能把整个仪表盘都带黑屏。我曾经吃过这个亏，后来再也不敢轻视Hypervisor的配置了。
1.4 Android Automotive OS的诞生背景
好，聊完了硬件架构，咱们说说软件。为什么汽车需要Android Automotive OS？
你想想看，传统的车载系统（比如QNX、Linux）虽然稳定，但生态太弱了。用户想要装个导航、听个音乐、看个视频，都得等车厂OTA。而Android呢？它有海量的APP生态，有成熟的开发者社区，有完善的权限管理机制。
但直接把手机Android搬上车，行不行？不行。为什么？
- 安全性：手机死机了重启就行，车机死机了可能影响驾驶安全
- 稳定性：车机要7x24小时运行，不能像手机一样每天重启
- 权限管控：车辆数据（车速、刹车、转向）不能随便让APP访问
- 生命周期：汽车要开10年，系统得支持长期维护
所以，Google在2017年推出了Android Automotive OS。它不是Android Auto（那个只是手机投屏），而是一个完整的、原生运行在车机上的操作系统。
核心定位：Android Automotive OS = Android开放生态 + 汽车级安全与稳定性要求。
1.5 Android Automotive OS的核心架构
Android Automotive OS在标准Android基础上，增加了几个关键模块：
| 模块 | 作用 | 说明 |
|---|---|---|
| Vehicle HAL | 车辆硬件抽象层 | 统一接口，访问车速、车门、空调等车辆信号 |
| Car Service | 车辆服务管理 | 管理车辆状态、驾驶模式、车辆属性 |
| Car App | 车载应用框架 | 提供仪表、导航、媒体等系统级应用 |
| Permission Manager | 权限管理 | 车辆专属权限（如访问车速、控制空调） |
举个例子，一个导航APP想获取当前车速，它不能直接读CAN总线（那太危险了）。它得通过Car Service，调用Vehicle HAL，再经过权限检查，才能拿到数据。这个流程，就是我们后面要重点讲的权限管控机制。
避坑指南：我曾经见过一个团队，为了省事，直接给导航APP开放了“读取所有车辆信号”的权限。结果APP里有个广告SDK，偷偷把车速数据上传到了云端。嗯，这不仅是隐私问题，更是安全漏洞。所以，权限管控一定要做到“最小化授权”。
1.6 为什么选择Android Automotive OS？
说白了，车厂选择Android Automotive OS，无非三个原因：
- 生态成熟：全球有300万+ Android开发者，APP移植成本低
- 迭代快：Google每年发布大版本更新，安全补丁每月推送
- 成本低：相比自研系统，Android的研发和维护成本低得多
但代价也有：系统复杂度高、安全攻击面大、需要深度定制。这恰恰是我们这门课要解决的问题——如何在享受Android生态的同时，保证汽车级的安全与稳定。
1.7 本章小结
咱们回顾一下：
- 从分布式ECU到域集中，再到中央计算平台，架构越来越集中，算力越来越强
- Android Automotive OS是Google为汽车量身定制的操作系统
- 它的核心挑战是：开放生态 vs 汽车级安全
下一章，我会带大家深入Android Automotive OS的权限模型，看看它和手机Android到底有什么不同。到时候，我会分享一个我亲手踩过的坑——关于“车辆控制权限”的误配置，差点导致测试车在路试时失控。嗯，那故事挺刺激的，咱们下回分解。