汽车行业正从许多分散式计算单元的架构转向将多种功能组合到少数集中式计算单元中的架构，从而实现无线更新等新功能。
AAOS SDV 利用现有的 Android 系统和基础架构来提供解决方案。此外，原始设备制造商 (OEM) 也在寻找可在云端运行的解决方案，因为这有助于早期开发并带来新的测试可能性。
设计
图 1. SDV 核心架构。
适用于 SDV Core (SDV Core) 的 AAOS 是一种基于 Android 的操作系统。由于其嵌入式特性，它不实现 Android 的 JVM 堆栈，而是以原生方式开发所有系统功能。
SDV Core 主要针对虚拟化环境开发，并且一些设计决策假设了这种集成。不过，可以原生运行 SDV Core，但与其他 Android 版本相比，这需要进行更多集成工作。
SDV Core 专为本地分布式系统而设计，例如，它假定 SDV Core（或衍生版本）的多个实例在同一芯片上或多个系统上并排运行，并且可以通过网络连接进行通信。因此，系统架构的一个核心方面是将功能实现为可托管在任何实例上的服务。
SDV Core 是开发车载功能的最小功能集。典型服务会接收一些信号，处理这些信号，然后与其他服务分享结果。这种范围限制是有意为之，因为这样可以使 SDV Core 能够运行各种可能不包含高级引擎的 SoC（片上系统），从而节省成本。
详细设计
图 2. SDV 核心详细架构。
SDV Core 派生自 Android，因此其架构尽可能与 Android 保持一致。从本质上讲，这意味着 SDV Core 也使用来自 Android 的 GKI、驱动程序、HAL 和核心库，并添加了服务架构所需的组件。
以下部分将详细介绍系统组件。
宿主环境和虚拟化
SDV Core 的开发基于以下假设：它将在虚拟环境中运行，因此，我们对宿主环境做出了一些假设：
宿主环境运行支持 Virtio 设备的 Hypervisor。此外，虚拟机监控程序必须实现以太网或 vsock、电源状态和块设备。此外，Hypervisor 必须支持运行 Android/Linux。
在硬件方面，SDV Core 假设 CPU 和 MMU 支持硬件虚拟化，并且系统通过以太网连接。系统不需要具有 GPU、IPU、CSI、媒体引擎、显示屏或其他汽车通信总线（例如 CAN、LIN）。
Android Base
SDV Core 基于 Android，但将系统精简为基本系统功能，并添加了 SDV 运行时环境。这意味着 SDV 也使用 GKI、原生系统服务（例如 adbd 和 logd）和系统功能，但不包含 JVM 以及基于 JVM 的服务或系统应用，也不包含为 JVM 实现的功能。
这也意味着 SDV 将适应 Android 的更新策略和分区布局。它具有类似的安全要求，但没有 GUI。
GKI、驱动程序和 HAL
SDV 核心用户的 Android GKI 内核，采用 Android 6.1 内核。使用 GKI 的优势在于，上游的变更最终会落实到 Android 中。此外，Android 在整个设备群中仅使用一个内核。例如，补丁会集中应用，而不是应用于多个供应商内核。
这还允许 SDV 具有稳定的内核接口。例如，您可以将驱动程序编译为与 GKI 配合使用的模块，即使部署了包含安全修复的新内核，这些模块也能正常运行。
GKI 内核的时间表是固定的，应在上游将供应商变更提交到 Linux 内核，直到年底。这些变更应成为下一个 GKI 内核的一部分。
借助 GKI，设备驱动程序和非启动必需模块将编译为内核模块，并包含在前期启动期间加载的 ramdisk 中，无法等待内核模块接口（例如随机初始化）的前期设备配置必须在设备树中完成。内核模块不需要上游化，但必须针对 GKI 接口进行编译。
由于 SDV Core 假设其构建在与 Virtio 兼容的 Hypervisor 之上，因此如果支持该功能，驱动程序将作为 Virtio 内核模块交付，否则将作为其他开放标准（例如，用于信任的 DICE 开放配置文件和 open-dice 内核驱动程序）交付。
Virtio（和开放标准）与虚拟机监控器的这种组合可实现硬件抽象化。因此，SDV 中对 HAL 的需求极低，但由于缺少 Virtio 支持，仍需要一些 HAL。例如，用于硬件支持的加密的 KeyMint HAL，以及用于 SDV 虚拟机之间认证的密切相关的 IRemotelyPrivisionedComponent HAL。
网络和通信堆栈
图 3. SDV 核心网络和通信堆栈。
对于网络，SDV 核心假设 vsock 或以太网可用于跨虚拟机通信，虚拟机内部通信也可以使用 binder 等 IPC 机制。
SDV 仅支持用于调试的串行通信。
图 4. SDV 核心序列支持，用于调试。
在单个 guest 中，SDV 提供了多种选项，具体取决于通信模型和性能要求。
Vsock
Vsock 是多个虚拟机或宿主机与虚拟机之间本地通信的首选渠道。虚拟机应使用彼此之间的直接 vsock 通信，以允许实现优化副本数量。
共通记忆
共享内存仅用于与虚拟机进行 IPC（进程间通信），但不能作为多个虚拟机之间进行通信的常规渠道。主机可以使用共享内存与 guest 共享信息，但它并非为高频网络流量而设计。
以太网
以太网将用于多个 SoC 之间的通信，即用于车载通信。这可以是虚拟化系统，也可以是原生系统或旧版 ECU。
车辆网络足够小，IPv4 地址空间足以识别所有可用系统。不过，为了确保系统与潜在的上行链路和未来的发展兼容，必须支持 IPv4 和 IPv6。
VLAN
VLAN 是一种用于创建虚拟网络架构的机制，可用于隔离不同的子网并形成本地网络。这可用于创建不同的安全区，并且在汽车中用于此目的。需要支持 VLAN。
协议
TCP 和 UDP
根据使用情形，系统需要可靠或不可靠但快速的通信协议。因此，将支持 TCP 和 UDP。
数据隧道
数据隧道是 SDV 的一种新开发的通信机制，可提供遵循发布-订阅模型的快速通信渠道，例如一个应用发布一个主题，而一个或多个应用可以监听该主题。在内部，它要么利用虚拟机内的共享内存和 FMQ（快速消息队列），要么利用 vsock 或以太网在虚拟机之间进行通信。
(SDV) RPC
SDV RPC 利用 binder 为 SDV 实现远程过程调用。它使用预定义的 API 来调用远程过程。与数据隧道类似，它要么使用共享内存在虚拟机内进行通信，要么使用 vsock 或以太网进行跨虚拟机通信。
框架
SOMEIP
SOMEIP 用于与非 SDV 系统通信。它基于 TCP 和 UDP 构建，不需要特殊硬件或驱动程序。Google 将实现一个参考。
服务发现代理 (SD 代理)
它为 SDV 提供服务发现、身份验证和授权。对于通信，它可以使用上述任何方法。对于身份验证和授权，SD 代理需要访问安全硬件，并建立有效的信任链。
中间件
SDV 开发了一个名为中间件的框架，以简化对所有这些不同协议的使用。它还使用一种新语言 VSIDL 为所有车辆信号实现了一个可靠来源。
中性区
为了隔离系统的一部分，防止来自不太受信任的系统部分（例如，安装了自定义应用的 IVI）的攻击，网络可能会引入不同的区域，包括非军事区。实际上，这意味着子网在物理上或逻辑上是隔离的，只有列入许可名单的流量才能通过这些边界。
连接管理器
在 Android 中，一种常见的做法是限制可以自行打开套接字连接的应用和服务数量。而是由中央实例负责打开和管理连接。由于 Android 在 Java 服务中实现了此功能，因此 SDV 将构建自己的连接管理器。
可更新性
SDV 的一个关键特性是可更新性。在 SDV 的整个生命周期内，可以通过 Android 系统更新和 APEX 软件包安装新功能。
Android 系统更新
Android 已经提供了一种安装更新的机制。它在最新版本中使用 A/B 和虚拟 A/B 更新，而 SDV Core 将利用此机制。A/B 更新会创建每个分区的两个副本，这带来了两项优势：系统可以在后台更新；如果更新失败，系统可以回滚到上次已知的版本以继续运行。
APEX 软件包
除了将系统拆分为多个可更新的分区之外，Android 还提供 APEX 软件包，这是一种将应用和库放入小型软件包的机制，这些软件包可以独立于系统更新进行安装和更新。
SDV Core 将使用 APEX 容器在 SDV 实例上动态安装服务，同时还会管理将多个服务部署到单个进程中：只有捆绑在同一 APEX 中并使用同一证书的服务才能部署在同一二进制文件中，以降低安全风险。
Android 安装 APEX 软件包的机制利用了一些用于 APK 管理的 Java 代码来验证软件包。SDV Core 需要实现原生替代方案，以允许动态安装 APEX 软件包。
更新管理
SDV 实例不是汽车中完全独立的单元，需要与其他 SDV 实例和汽车服务进行编排。例如，安装服务依赖项或确保仅在安全的系统状态下安装更新。
SDV 会考虑跨多个虚拟机使用分区。这需要这些虚拟机之间进行协调，因为它们彼此之间存在数据依赖关系：必须有一个主虚拟机来更新这些分区，并且需要一种机制来通知其他虚拟机有关更新的分区和同步信息，以便同时更新所有虚拟机，从而确保不会破坏之前已知的正常运行状态。
使用入门
我们的入门指南详细介绍了源代码、构建和使用 Cuttlefish 启动。