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