自動車業界は、多くの分散型コンピューティング ユニットのアーキテクチャから、複数の機能を少数の集中型コンピューティング ユニットに統合するアーキテクチャに移行しています。これにより、無線アップデートなどの新機能が実現します。
AAOS SDV は、既存の Android システムとインフラストラクチャを活用してソリューションを提供します。また、OEM はクラウドでも実行できるソリューションを求めています。これにより、早期の開発が容易になり、新しいテストの可能性が広がります。
デザイン
図 1. SDV Core アーキテクチャ。
SDV Core 向け AAOS（SDV Core）は、Android をベースとしたオペレーティング システムです。組み込み型であるため、Android の JVM スタックは実装されていませんが、すべてのシステム機能はネイティブに開発されています。
SDV Core は主に仮想化環境向けに開発されており、一部の設計上の決定ではこの統合を前提としています。ただし、SDV Core をネイティブに実行することは可能ですが、他の Android リリースと比較して、より多くの統合作業が必要になります。
SDV Core はローカル分散システム向けに設計されています。たとえば、SDV Core（または派生）の複数のインスタンスが同じチップ上または複数のシステムに隣接して実行され、ネットワーク接続を介して通信できることを前提としています。したがって、システム アーキテクチャの重要な側面は、任意のインスタンスでホストできるサービスとして機能を実装することです。
SDV Core は、車載機能を開発するための最小限の機能セットです。一般的なサービスは、いくつかのシグナルを受信して処理し、結果を他のサービスと共有します。このスコープの制限は、高度なエンジンを含まない可能性のあるさまざまな SoC（システム オン チップ）を SDV Core で実行してコストを削減できるようにするために、意図的に設けられています。
詳細設計
図 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 のアップデート戦略とパーティション レイアウトを適応させることも意味します。セキュリティ要件は似ていますが、GUI はありません。
GKI、ドライバ、HAL
SDV Core ユーザーは、Android 6.1 カーネルを備えた Android の GKI カーネルを使用します。GKI を使用するメリットは、アップストリームの変更が最終的に Android に反映されることです。また、Android はフリート全体で 1 つのカーネルを使用します。たとえば、パッチは複数のベンダー カーネルではなく、中央に適用されます。
これにより、SDV は安定したカーネル インターフェースを持つことができます。たとえば、セキュリティ修正を含む新しいカーネルがデプロイされた場合でも、GKI で動作するモジュールとしてドライバをコンパイルできます。
GKI カーネルのタイムラインは固定されているため、次の GKI カーネルの一部となるベンダーの変更は、年末まで Linux カーネルにアップストリームする必要があります。
GKI では、デバイス ドライバと起動に必要のないモジュールはカーネル モジュールとしてコンパイルされ、アーリーブート時に読み込まれる RAM ディスクに含まれます。カーネル モジュール インターフェースを待機できない非常に早いデバイス構成（ランダム初期化など）は、デバイスツリーで行う必要があります。カーネル モジュールをアップストリームに送信する必要はありませんが、GKI インターフェースに対してコンパイルする必要があります。
SDV Core は Virtio 互換のハイパーバイザ上に構築されることを前提としているため、機能がサポートされている場合はドライバが Virtio カーネル モジュールとして提供され、サポートされていない場合は別のオープン標準（DICE のオープン プロファイルや信頼のための open-dice カーネル ドライバなど）として提供されます。
Virtio（およびオープン標準）とハイパーバイザの組み合わせにより、ハードウェアの抽象化が実現します。そのため、SDV での HAL の必要性は最小限ですが、Virtio のサポートがないため、一部は依然として必要です。たとえば、ハードウェア格納型暗号の KeyMint HAL や、SDV VM 間の証明書取得のための IRemotelyPrivisionedComponent HAL などです。
ネットワーキングと通信スタック
図 3. SDV コア ネットワーキングおよび通信スタック。
ネットワーキングの場合、SDV Core は、VM 間で通信するために vsock または Ethernet のいずれかが使用可能であることを前提としています。VM 内部の通信では、バインダなどの IPC メカニズムも使用できます。
SDV は、デバッグ目的でのみシリアル通信をサポートします。
図 4. デバッグ用の SDV Core シリアル サポート。
単一のゲスト内で、SDV は通信モデルとパフォーマンス要件に応じて複数のオプションを提供します。
Vsock
Vsock は、複数の VM 間またはホストと VM 間のローカル通信に推奨されるチャネルです。VM は、実装でコピー数を最適化できるように、相互に直接 vsock 通信を使用する必要があります。
共有メモリ
共有メモリは、IPC（プロセス間通信）のために VM との通信にのみ使用されますが、複数の VM 間の通信用の通常のチャネルとしては提供されません。ホストは共有メモリを使用してゲストと情報を共有できますが、高頻度のネットワーキング トラフィックは想定されていません。
イーサネット
イーサネットは、複数の SoC 間の通信、つまり車内通信に使用されます。仮想化システムだけでなく、ネイティブ システムやレガシー ECU も対象となります。
車両ネットワークが十分に小さく、IPv4 アドレス空間で利用可能なすべてのシステムを識別できる。ただし、システムが潜在的なアップリンクや将来の開発と互換性があることを保証するため、IPv4 と IPv6 はサポートされなければなりません。
VLAN
VLAN は、異なるサブネットワークを分離してローカル ネットワークを形成できる仮想ネットワーク アーキテクチャを作成するメカニズムです。これは、さまざまなセキュリティ ゾーンを作成するために使用でき、自動車内ではその目的で使用されます。VLAN のサポートが必要です。
プロトコル
TCP と UDP
ユースケースに応じて、システムには信頼性の高い通信プロトコルまたは信頼性の低い高速通信プロトコルのいずれかが必要です。したがって、TCP と UDP がサポートされます。
データ トンネル
Data Tunnel は、SDV 向けに新たに開発された通信メカニズムです。pubsub モデルに沿った高速通信チャネルを提供します。たとえば、1 つのアプリケーションがトピックをパブリッシュし、1 つ以上のアプリケーションがそれをリッスンできます。内部的には、VM 内の共有メモリと FMQ（高速メッセージ キュー）を使用するか、vsock または Ethernet を使用して VM 間で通信します。
（SDV）RPC
SDV RPC は、バインダを活用して SDV のリモート プロシージャ コールを実装します。これは、事前定義された API を使用してリモート プロシージャを呼び出します。Data Tunnel と同様に、VM 内の通信には共有メモリを使用し、VM 間の通信には vsock または Ethernet を使用します。
フレームワーク
SOMEIP
SOMEIP は、SDV 以外のシステムとの通信に使用されます。TCP と UDP を基盤として構築されており、特別なハードウェアやドライバは必要ありません。Google はリファレンスを実装します。
サービス ディスカバリ エージェント（SD エージェント）
SDV にサービス ディスカバリ、認証、認可を提供します。通信には、前述のいずれかの方法を使用できます。認証と認可を行うには、SD エージェントがセキュリティ ハードウェアと信頼のチェーンにアクセスする必要があります。
ミドルウェア
SDV は、ミドルウェアと呼ばれるさまざまなプロトコルの使用を簡素化するフレームワークを開発しています。また、新しい言語 VSIDL を使用して、すべての車両シグナルの信頼できる情報源を実装します。
ニュートラル ゾーン
システムの信頼性の低い部分（カスタム インストールされたアプリを含む IVI など）からの攻撃を防ぐために、ネットワークで非武装地帯を含むさまざまなゾーンが導入されることがあります。実際には、サブネットワークが物理的または論理的に分離され、許可リストに登録されたトラフィックのみが境界を通過できることを意味します。
接続マネージャー
Android では、ソケット接続を自分で開くことができるアプリケーションとサービスの数を制限するのが一般的です。代わりに、中央インスタンスが接続のオープンと管理を行います。Android はこの機能を Java サービスに実装しているため、SDV は独自の接続マネージャーを構築します。
更新可能性
SDV の主な機能は、更新可能性です。新機能は、Android システム アップデートと APEX パッケージを通じて、SDV のライフサイクル全体にわたってインストールできます。
Android のシステム アップデート
Android には、アップデートをインストールするメカニズムがすでに用意されています。最近のバージョンでは A/B アップデートと仮想 A/B アップデートが使用されており、SDV Core はこのメカニズムを活用します。A/B アップデートでは、各パーティションが 2 回作成されます。これにより、システムをバックグラウンドでアップデートできる、アップデートが失敗した場合にシステムを最後に確認されたバージョンにロールバックして動作させることができる、という 2 つのメリットがあります。
APEX パッケージ
Android では、システムを複数のパーティションに分割して更新可能にするだけでなく、APEX パッケージも提供しています。これは、システム アップデートとは別にインストールおよび更新できる小さなパッケージにアプリとライブラリを格納するメカニズムです。
SDV Core は、APEX コンテナを使用して SDV インスタンスにサービスを動的にインストールしますが、複数のサービスを単一のプロセスにデプロイすることも管理します。同じ APEX にバンドルされ、同じ証明書を使用するサービスのみを同じバイナリにデプロイして、セキュリティ リスクを軽減できます。
Android の APEX パッケージのインストール メカニズムは、APK 管理用の Java コードの一部を活用してパッケージを検証します。SDV Core は、APEX パッケージを動的にインストールできるように、ネイティブの代替手段を実装する必要があります。
更新の管理
SDV インスタンスは車内の完全に独立したユニットではなく、他の SDV インスタンスやカーサービスとのオーケストレーションが必要です。たとえば、サービスの依存関係をインストールしたり、安全なシステム状態でのみ更新がインストールされるようにしたりする場合です。
SDV は、複数の VM でパーティションを使用することを検討します。これらの VM は相互にデータ依存性があるため、連携が必要です。これらのパーティションを更新するプライマリ VM と、更新されたパーティションと同期について他の VM に通知するメカニズムが必要です。これにより、すべての VM を同時に更新して、以前の既知の動作状態が壊れないようにします。
スタートガイド
スタートガイドでは、ソースコード、Cuttlefish でのビルドと起動について詳しく説明しています。