汽車產業正從多個分散式運算單元的架構，轉向將多項功能整合到少數集中式運算單元的架構，以啟用無線更新等新功能。
AAOS SDV 採用現有的 Android 系統和基礎架構，提供解決方案。此外，原始設備製造商也希望解決方案能在雲端執行，以利早期開發並實現新的測試可能性。
設計
圖 1. SDV Core 架構。
SDV Core 適用的 AAOS (SDV Core) 是以 Android 為基礎的作業系統。由於是嵌入式，因此不會實作 Android 的 JVM 堆疊，而是以原生方式開發所有系統功能。
SDV Core 主要為虛擬化環境開發，部分設計決策會假設這項整合。不過，您還是可以原生執行 SDV Core，但與其他 Android 版本相比，這需要更多整合工作。
SDV Core 專為本機分散式系統設計，例如，假設 SDV Core (或衍生項目) 的多個執行個體彼此相鄰，無論是在同一晶片上或跨多個系統，都能透過網路連線通訊。因此，系統架構的核心要點是將功能實作為服務，並可託管在任何執行個體上。
SDV Core 是開發車內功能所需的最低功能集。一般服務會接收幾個信號、處理這些信號，然後與其他服務分享結果。這項範圍限制是刻意為之，因為這樣 SDV Core 就能在各種 SoC (系統單晶片) 上執行，這些 SoC 可能不含進階引擎，因此可節省成本。
精細設計
圖 2. SDV Core 詳細架構。
SDV Core 衍生自 Android，因此其架構盡可能與 Android 保持一致。這表示 SDV Core 也會使用 Android 的 GKI、驅動程式、HAL 和核心程式庫，並新增服務架構所需的元件。
以下各節將詳細說明系統元件。
主機環境和虛擬化
SDV Core 的開發前提是會在虛擬環境中執行，因此我們對主機環境做出一些假設：
主機環境會執行支援 Virtio 裝置的管理程序。此外，管理程序必須實作乙太網路或 vsock、電源狀態和區塊裝置。此外，管理程序必須支援執行 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 的更新策略和磁碟分割區配置。這項產品的安全需求與 ChromeOS 類似，但沒有 GUI。
GKI、驅動程式和 HAL
SDV Core 使用者Android 的 GKI 核心搭配 Android 6.1 核心。使用 GKI 的優點是，上游的變更最終會進入 Android。此外，Android 在整個機群中都使用同一個核心。舉例來說，修補程式會集中套用，而非套用至多個供應商核心。
這也讓 SDV 擁有穩定的核心介面。舉例來說，您可以將驅動程式編譯為與 GKI 搭配使用的模組，即使部署了含有安全性修正檔的新核心，也能正常運作。
GKI 核心的時程固定，供應商變更應在年底前上傳至 Linux 核心，成為下一個 GKI 核心的一部分。
使用 GKI 時，裝置驅動程式和非開機必要模組會編譯為核心模組，並包含在早期開機期間載入的 ramdisk 中。無法等待核心模組介面的極早期裝置設定 (例如隨機初始化) 必須在裝置樹狀結構中完成。核心模組不一定要上傳至上游，但必須根據 GKI 介面編譯。
由於 SDV Core 假設是建構在與 Virtio 相容的 Hypervisor 之上，因此如果支援這項功能，驅動程式會以 Virtio 核心模組的形式提供，否則會以其他開放標準的形式提供 (例如 DICE 的 Open Profile 和信任的 open-dice 核心驅動程式)。
Virtio (和開放式標準) 與管理程序的組合會導致硬體抽象化。因此，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。
資料通道
資料通道是 SDV 新開發的通訊機制，可提供遵循發布/訂閱模型的快速通訊管道，例如一個應用程式發布主題，而一或多個應用程式可以監聽該主題。在內部，這項功能會使用 VM 內的共用記憶體和 FMQ (快速訊息佇列)，或使用 vsock 或乙太網路在 VM 之間通訊。
(SDV) RPC
SDV RPC 會利用繫結器實作 SDV 的遠端程序呼叫。它會使用預先定義的 API 呼叫遠端程序。與資料通道類似，它會使用共用記憶體進行 VM 內通訊，或使用 vsock 或乙太網路進行跨 VM 通訊。
架構
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 套件的機制會利用部分 Java 程式碼進行 APK 管理，以驗證套件。SDV Core 必須實作原生替代方案，才能動態安裝 APEX 套件。
更新管理
SDV 執行個體並非車輛中的完全獨立單元，需要與其他 SDV 執行個體和車輛服務協調運作。例如安裝服務依附元件，或確保更新只會在安全的系統狀態下安裝。
SDV 會考慮在多個 VM 中使用分割區。這需要這些 VM 之間的協調作業，因為彼此之間有資料依附元件：必須有主要 VM 來更新這些分割區，並有通知其他 VM 更新分割區的機制，以及同時更新所有 VM 的同步作業，確保先前的已知工作狀態不會中斷。
開始使用
如要瞭解原始碼、建構及使用 Cuttlefish 啟動的詳細資訊，請參閱入門指南。