汽車產業正從多個分散式運算單元的架構，轉向將多項功能整合至少數集中式運算單元的架構，進而實現無線更新等新功能。
AAOS SDV 運用現有的 Android 系統和基礎架構提供解決方案。此外，原始設備製造商也希望解決方案能在雲端執行，以便提早開發並進行新的測試。
設計
圖 1. SDV 核心架構。
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 裝置的管理程序。此外，管理程序必須實作乙太網路或 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 的更新策略和分區版面配置。這項產品的安全性需求與 GWS 相似，但沒有 GUI。
GKI、驅動程式和 HAL
SDV Core 使用 Android 的 GKI 核心和 Android 6.1 核心。使用 GKI 的優點是，上游的變更最終會套用至 Android。此外，Android 在整個機群中使用一個核心。舉例來說，修補程式會集中套用，而不是套用至多個供應商核心。
這也讓 SDV 擁有穩定的核心介面。舉例來說，您可以將驅動程式編譯為與 GKI 搭配使用的模組，即使部署了含有安全性修正的新核心，也能正常運作。
GKI 核心有固定的時間表，應納入下一個 GKI 核心的供應商變更，應在年底前上游至 Linux 核心。
有了 GKI，裝置驅動程式和非啟動必要模組會編譯為核心模組，並包含在提早啟動期間載入的 RAM 磁碟中，而無法等待核心模組介面 (例如隨機初始化) 的極早期裝置設定，則必須在裝置樹狀架構中完成。核心模組不一定要上游，但必須針對 GKI 介面進行編譯。
由於 SDV Core 假設其建構在與 Virtio 相容的 Hypervisor 之上，因此如果支援該功能，驅動程式會以 Virtio 核心模組的形式提供，或以其他開放標準 (例如 DICE 的 Open Profile 和信任的 open-dice 核心驅動程式) 提供。
Virtio (和開放標準) 與 Hypervisor 的組合可實現硬體抽象化。因此，SDV 對 HAL 的需求極低，但由於缺少 Virtio 支援，仍需要一些 HAL。例如，用於硬體支援密碼編譯的 KeyMint HAL，以及用於 SDV VM 認證的密切相關 IRemotelyPrivisionedComponent HAL。
網路和通訊堆疊
圖 3. SDV 核心網路和通訊堆疊。
在網路方面，SDV Core 假設 vsock 或乙太網路可用於 VM 之間的通訊，VM 內部通訊也可以使用繫結器等 IPC 機制。
SDV 支援序列通訊，但僅限偵錯用途。
圖 4. SDV Core 序列支援偵錯。
在單一訪客中，SDV 會根據通訊模型和效能需求提供多個選項。
Vsock
Vsock 是多個 VM 之間或主機與 VM 之間本機通訊的首選管道。VM 應使用直接 vsock 通訊，讓實作項目最佳化副本數量。
共用記憶體
共用記憶體僅用於與 VM 進行 IPC (程序間通訊) 通訊，不提供做為多個 VM 之間通訊的一般管道。主機可能會使用共用記憶體與訪客共用資訊，但這並非針對高頻率網路流量所設計。
乙太網路
乙太網路用於多個 SoC 之間的通訊，也就是車內通訊。這可以是虛擬化系統，也可以是原生系統或舊版 ECU。
車輛網路規模較小，因此 IPv4 位址空間足以識別所有可用系統。不過，為確保系統與潛在上行連結和未來開發相容，必須支援 IPv4 和 IPv6。
VLAN
VLAN 是建立虛擬網路架構的機制，可隔離不同的子網路並形成區域網路。這項功能可用於建立不同的安全區域，在車輛中也是用於這個目的。必須支援 VLAN。
通訊協定
TCP 和 UDP
視用途而定，系統需要可靠或不可靠但快速的通訊協定。因此，系統會支援 TCP 和 UDP。
資料通道
Data Tunnel 是 SDV 新開發的通訊機制，可依據 pubsub 模型提供快速通訊管道，例如一個應用程式發布主題，而一或多個應用程式可以監聽該主題。在內部，它會利用 VM 內的共用記憶體和 FMQ (快速訊息佇列)，或使用 vsock 或乙太網路在 VM 之間通訊。
(SDV) RPC
SDV RPC 會使用繫結器，為 SDV 實作遠端程序呼叫。它會使用預先定義的 API 呼叫遠端程序。與 Data Tunnel 類似，它會使用共用記憶體在 VM 內通訊，或使用 vsock 或乙太網路進行跨 VM 通訊。
架構
SOMEIP
SOMEIP 用於與非 SDV 系統通訊。這項通訊協定以 TCP 和 UDP 為基礎，不需要特殊硬體或驅動程式。Google 會導入參考資料。
服務探索代理程式 (SD 代理程式)
可為 SDV 提供服務探索、驗證和授權功能。通訊時，可能會使用上述任何方法。為了進行驗證和授權，SD 代理程式需要存取安全性硬體，以及運作中的信任鏈。
中介軟體
SDV 開發了一個名為「中介軟體」的架構，可簡化所有不同通訊協定的使用方式。此外，它也使用新語言 VSIDL，為所有車輛信號實作可靠資料來源。
中立區
為了隔離系統部分，防止攻擊來自系統中較不信任的部分 (例如安裝安裝版應用程式的 IVI)，網路可能會導入不同的區域，包括非軍事區。在實務上，這代表子網路在實體或邏輯上是分開的，只有許可清單中的流量才能通過這些邊界。
Connectivity Manager
在 Android 中，通常會限制可自行開啟通訊端連線的應用程式和服務數量。而是由中央執行個體負責開啟及管理連線。由於 Android 在 Java 服務中實作這項功能，SDV 會建構自己的連線管理工具。
可更新性
SDV 的主要特色是可更新性。在 SDV 的生命週期內，可透過 Android 系統更新和 APEX 套件安裝新功能。
Android 系統更新
Android 已提供安裝更新的機制。在近期版本中，Android 使用 A/B 和虛擬 A/B 更新，SDV Core 將運用這項機制。A/B 更新會建立每個分區兩次，這有兩個優點：系統可以在背景更新，如果更新失敗，系統可以復原到最後一個已知可運作的版本。
APEX 套件
除了將系統分割成多個分區並使其可更新外，Android 還提供 APEX 套件，這是一種將應用程式和程式庫放入小型套件的機制，可獨立於系統更新進行安裝和更新。
SDV Core 會使用 APEX 容器在 SDV 執行個體上動態安裝服務，並管理多項服務部署至單一程序：只有在相同 APEX 中組合並使用相同憑證的服務，才能部署在相同的二進位檔中，以降低安全性風險。
Android 安裝 APEX 套件的機制會利用一些 Java 程式碼進行 APK 管理，以驗證套件。SDV Core 必須實作原生替代方案，才能動態安裝 APEX 套件。
更新管理
SDV 執行個體並非車輛中的完全獨立單位，需要與其他 SDV 執行個體和車輛服務進行協調。例如安裝服務依附元件，或確保只在安全的系統狀態下安裝更新。
SDV 考慮在多個 VM 中使用分區。這需要這些 VM 之間的協調，因為它們彼此之間有資料依賴關係：必須有一個主要 VM 來更新這些分區，以及一個機制來通知其他 VM 有關更新的分區，並同步更新所有 VM，以確保先前的已知工作狀態不會中斷。
開始使用
我們的入門指南提供原始碼、建構和啟動 Cuttlefish 的詳細資訊。