自動車業界は、多くの分散型コンピューティング ユニットのアーキテクチャから、複数の機能を少数の集中型コンピューティング ユニットに統合するアーキテクチャに移行しています。これにより、無線アップデートなどの新機能が実現します。
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 は、車載機能を開発するための最小限の機能セットです。一般的なサービスは、いくつかのシグナルを受信して処理し、その結果を他のサービスと共有します。このスコープ制限は、SDV Core が高度なエンジンを搭載していない可能性のあるさまざまな SoC（System-on-a-chip）を実行できるようにし、コストを削減することを目的としています。
詳細設計
図 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 のサポートがないため、一部の HAL は依然として必要です。たとえば、ハードウェア格納型暗号用の KeyMint HAL や、SDV VM 間の構成証明用の密接に関連する IRemotelyPrivisionedComponent HAL などです。
ネットワーキングと通信スタック
図 3. SDV コア ネットワーキングおよび通信スタック。
ネットワーキングの場合、SDV Core は、VM 間で通信するために vsock またはイーサネットのいずれかを使用できることを前提としています。VM 内部通信では、バインダなどの IPC メカニズムも使用できます。
SDV は、デバッグ目的でのみシリアル通信をサポートしています。
図 4. デバッグ用の SDV Core シリアル サポート。
1 つのゲスト内で、SDV は通信モデルとパフォーマンス要件に応じた複数のオプションを提供します。
Vsock
Vsock は、複数の VM 間またはホストと VM 間のローカル通信に推奨されるチャネルです。VM は、実装でコピー数を最適化できるように、相互に直接 vsock 通信を使用する必要があります。
共有メモリ
共有メモリは、IPC（プロセス間通信）のために VM と通信する場合にのみ使用され、複数の VM 間の通信用の Regular チャンネルとしては提供されません。ホストは共有メモリを使用してゲストと情報を共有できますが、高頻度のネットワーク トラフィックは想定されていません。
イーサネット
イーサネットは、複数の SoC 間の通信、つまり車載通信に使用されます。これは、仮想化システムだけでなく、ネイティブ システムやレガシー ECU にも該当します。
車両ネットワークは十分に小さいため、IPv4 アドレス空間ですべての利用可能なシステムを識別できます。ただし、システムが潜在的なアップリンクや将来の開発に対応できるように、IPv4 と IPv6 をサポートする必要があります。
VLAN
VLAN は、異なるサブネットワークを分離してローカル ネットワークを形成できる仮想ネットワーク アーキテクチャを作成するメカニズムです。これは、さまざまなセキュリティ ゾーンを作成するために使用でき、車内でもその目的で使用されます。VLAN のサポートが必要です。
プロトコル
TCP と UDP
ユースケースに応じて、システムには信頼性の高い通信プロトコル、または信頼性は低いものの高速な通信プロトコルが必要です。したがって、TCP と UDP がサポートされます。
データトンネル
Data Tunnel は、SDV 用に新たに開発された通信メカニズムです。pubsub モデルに沿った高速通信チャネルを提供します。たとえば、1 つのアプリケーションがトピックをパブリッシュし、1 つ以上のアプリケーションがそれをリッスンできます。内部的には、VM 内の共有メモリと FMQ（高速メッセージ キュー）を使用するか、vsock またはイーサネットを使用して 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 パッケージも提供しています。APEX パッケージは、アプリケーションとライブラリを小さなパッケージに格納するメカニズムであり、システム アップデートとは別にインストールして更新できます。
SDV Core は、APEX コンテナを使用して SDV インスタンスにサービスを動的にインストールしますが、複数のサービスを単一のプロセスにデプロイする管理も行います。同じ APEX にバンドルされ、同じ証明書を使用するサービスのみを同じバイナリにデプロイして、セキュリティ リスクを軽減できます。
APEX パッケージをインストールする Android のメカニズムは、APK 管理用の Java コードを利用してパッケージを検証します。SDV Core は、APEX パッケージを動的にインストールできるように、ネイティブの代替手段を実装する必要があります。
更新の管理
SDV インスタンスは、車内で完全に独立したユニットではなく、他の SDV インスタンスや車載サービスとのオーケストレーションが必要です。たとえば、サービスの依存関係をインストールする場合や、安全なシステム状態でのみアップデートがインストールされるようにする場合です。
SDV では、複数の VM にまたがるパーティションの使用を検討します。これらの VM は互いにデータの依存関係があるため、VM 間の調整が必要です。これらのパーティションを更新するプライマリ VM と、更新されたパーティションについて他の VM に通知するメカニズム、およびすべての VM を同時に更新して同期し、以前の既知の動作状態が破損しないようにするメカニズムが必要です。
スタートガイド
スタートガイドでは、Cuttlefish でのソースコード、ビルド、起動について詳しく説明しています。