ディスプレイの安全はコックピット ドメイン コントローラをターゲットとし、安全性と可用性の要件を満たすディスプレイを含め、自動車内のすべてのディスプレイを Android で制御できるようにします。
図 1.クラスタの概要。
関連情報
GitHub の詳細については、Compose 用の自動車設計をご覧ください。
用語
- platform
- ハードウェア、ハイパーバイザ、オペレーティング システム、関連ライブラリの組み合わせ。
- safety monitor
- 車両の状態をモニタリングし、対応するビジュアル情報がユーザーに意図したとおりに表示されることを検証するアプリ。
ディスプレイの安全のコンポーネント
ディスプレイの安全ソフトウェアは、次の 3 つの主要なコンポーネントで構成されています。
DriverUI: HAR によってレンダリングされる安全または規制に関する要素を除く、インストルメント クラスタのディスプレイ全体をレンダリングする Android システムアプリ。
高可用性レンダラ(HAR): コールドブート直後に表示する必要があるディスプレイ要素と、Android が使用できない場合のプレースホルダ要素をレンダリングする品質管理プロセス。HAR は移植可能で、運転に不可欠な情報に重点を置いています。
安全設計ツールチェーン: 設計ソースから安全モニタの実装の構成を生成し、関連する ASIL-B の安全目標を達成するための一連のツール。
すべてのコンポーネントは、設計ツールチェーンである Compose 用の自動車設計 を使用して、 同じ OEM 設計定義から作成されていることを確認します。
図 2.ディスプレイの安全のコンポーネント。
高可用性レンダラ
HAR は Rust で記述されており、次のコンポーネントで構成されています。
プラットフォーム抽象化レイヤ(PAL)。グラフィック、カメラ、音声、ユーザー入力(ハンドル操作など)、車両データ(シグナルまたはプロパティとも呼ばれます)、車両構成(ガソリン車または電気自動車、左ハンドルまたは右ハンドルなど)、ユーザー設定(km/h と mph など)を含む複数の サブシステムとやり取りするための抽象化。
ターゲット プラットフォームの PAL の実装。
PAL で開発された HAR アプリ。
Google は PAL を定義し、PAL と HAR アプリのリファレンス実装を提供します。リファレンス HAR アプリはすべてのビルディング ブロックを提供し、リファレンス メインループを含みます。OEM は、要件に合わせて PAL 実装と HAR アプリをカスタマイズする必要があります。HAR はレンダリングに Impeller を使用します。
詳しくは、次をご覧ください。
DriverUI
クラスタ UI は通常、ハンドルの背後にある別のディスプレイに配置されます。OEM は、クラスタと IVI を徐々に統合します。この統合された UI が DriverUI です。
DriverUI は、HAR によってレンダリングされる安全関連または規制に関する要素を除く、インストルメント クラスタのディスプレイ全体をレンダリングする Android システムアプリです。 DriverUI は、メディア再生、通話、地図、ナビゲーションなどに関する情報を表示し、Compose 用の自動車設計を使用して実装されます。
AAOS には、インストルメント クラスタを構築するための 2 つの API があります。インストルメント クラスタ API (クラスタ 1とも呼ばれます)はメンテナンス モードであり、OEM は ClusterHomeManager API(クラスタ 2とも呼ばれます)に移行することをおすすめします。
Google は、クラスタ 1 API とクラスタ 2 API のリファレンス実装を提供しています。
詳細については、DriverUI をご覧ください。
HAR と DriverUI の出力をブレンドする
HAR と DriverUI は、別々のディスプレイを使用して UI をレンダリングします。両方の出力が合成され、1 つの画像として DriverUI に表示されます。
これを実現するため、HAR は DriverUI から定期的なハートビート メッセージを受信し、実行中であることを示すことで、Android 出力が表示される領域の透明度を制御します。
DriverUI が実行されていない場合、HAR はハートビートがないことを検出し、DriverUI 領域を不透明にしてプレースホルダを表示します。ハートビートを受信すると、HAR はプレースホルダを削除し、DriverUI 領域を透明に設定します。
DriverUI と HAR は、リモート プロシージャ コール(RPC)を使用して相互に通信します。ハートビート メッセージは、RPC チャネルで送信されるデータの例であり、フィールドの 1 つとしてタイムスタンプで構成されます。
RPC には gRPC が使用されます。SDV では、SDV 通信スタックが SDV ゲートウェイ クライアントを提供し、DriverUI から HAR へのチャネルを検出して確立します。
図 3. HAR と DriverUI の構成。
安全設計ツールチェーン
安全設計ツールチェーンは、OEM が Figma 設計ドキュメントから生成された安全モニタ ソリューションを順番に提供するために使用する一連のツールです。
安全設計コンパイラは、安全モニタを構築するための後続のコード生成を駆動する安全アーティファクトを生成します。設計コンパイルとコード生成を分離することで、使用されるコード生成ツールは ISO-26262 TCL-3 評価を取得できます。
図 4. 安全設計ツールチェーンを使用する。
コンパイラのアーティファクトが生成されると、ツールチェーンは人間が読めるレポートを生成できます。このレポートは、OEM の安全エンジニアが Figma 設計から生成されたアーティファクトを検証するために検査できるファイルです。
Google は、ASIL 認定を受けていない安全モニタのリファレンス実装を提供しています。OEM は、要件に合わせて安全モニタをカスタマイズし、実装の認定を取得する必要があります。
詳細については、安全設計ツールチェーンをご覧ください。
SDV でディスプレイの安全を使用する
SDV でディスプレイの安全をビルドして実行できます。SDV は機能が完成しており、2 つのゲスト VM を使用して完全なディスプレイの安全クラスタを実行します。
ソフトウェア定義型自動車
Android Automotive OS(AAOS)ソフトウェア定義型自動車(SDV):
- クラスタ全体を表示するには、2 つのゲスト VM が必要です。
- ゲスト VM の SDV メディア(高速ブート VM とも呼ばれます)で HAR を実行します。
- SDV-IVI VM を実行する別のゲスト VM で DriverUI を実行します。