JP2017507398A - 複数のユーザインターフェース動作ドメインを有する車両 - Google Patents

Abstract

車両インターフェースシステムは、グラフィックス処理装置及び複数の処理ドメインを含む。処理ドメインは、車両アプリケーションを実行して、グラフィックス処理装置に対するタスクを生成する。システムは、処理ドメインにより生成されたタスクを受信して、グラフィックス処理装置にタスクを送信する順番を決定するように構成されるタスクスケジューラを更に含む。グラフィックス処理装置は、タスクスケジューラにより決定された順番でタスクを処理し、タスクに基づいて表示データを生成する。システムは、グラフィックス処理装置により生成された表示データを受信して、表示データをユーザに提示するように構成される電子ディスプレイを更に含む。

Description

本発明は、一般的には、車載用のコンピュータ化ユーザインターフェースに関する。

（関連特許出願への相互参照）
本出願は、２０１４年１月６日に提出された米国特許仮出願第６１／９２４，２２６号の利益及び優先権を主張し、その全体は参照により本明細書に組み込まれる。

車両ユーザインターフェースディスプレイ（例えば、ダイヤル、ラジオディスプレイ等）は、従来は車内の特定の場所に固定されている。また、これらは、従来は全く異なる回路又はシステムによって制御されている。例えば、ラジオシステム及びそのユーザインターフェースは、従来は第１のシステムによって制御され、速度計ダイヤルは、従来は完全に異なるシステムによって制御されている。

高い信頼性、構成可能性及びユーザビリティを有する車両ユーザインターフェースシステムを開発することは非常に困難である。

本開示の１つの実装は車両インターフェースシステムである。車両インターフェースシステムは、グラフィックス処理装置、及び車両アプリケーションを実行して、グラフィックス処理装置に対するタスクを生成するように構成される複数の処理ドメインを含む。システムは、処理ドメインにより生成されたタスクを受信して、グラフィックス処理装置にタスクを送信する順番を決定するように構成されるタスクスケジューラを含むレンダリングコアを更に含む。グラフィックス処理装置は、タスクスケジューラにより決定された順番でタスクを処理し、タスクに基づいて表示データを生成する。システムは、グラフィックス処理装置により生成された表示データを受信して、表示データをユーザに提示するように構成される電子ディスプレイを更に含む。

タスクスケジューラは、タスクの各々に関係付けられる優先度レベルを識別し、識別された優先度レベルに基づいてグラフィックス処理装置にタスクを送信する順番を決定する。タスクに関係付けられる優先度レベルを識別することは、複数の処理ドメインの中のどれがタスクを生成したかを識別すること、識別された処理ドメインに関係付けられる優先度レベルを識別すること、及び識別された処理ドメインに関係付けられる優先度レベルに従ってタスクに優先度レベルを割り当てることを含む。

一部の実施形態では、複数の処理ドメインは、車両クリティカルアプリケーションを実行して、グラフィックス処理装置に対する高優先度タスクを生成するように構成される高信頼性ドメインを含む。複数の処理ドメインは、低優先度車両アプリケーションを実行して、グラフィックス処理装置に対する低優先度タスクを生成するように構成される低信頼性ドメインを更に含んでもよい。

一部の実施形態では、レンダリングコアは、第１のセットの処理ドメインにより生成される第１のセットのタスクを受信及び管理して、第１のセットのタスクをスケジューラに提供するように構成される第１のアプリケーションプログラムインターフェースを含む。一部の実施形態では、車両インターフェースシステムは、第２のセットの処理ドメインにより生成される第２のセットのタスクを受信及び管理するように構成される第２のアプリケーションプログラムインターフェースを含む。第２のセットの処理ドメインは、第１のセットの処理ドメインには無い１つ以上の処理ドメインを含んでもよい。

一部の実施形態では、タスクスケジューラは、アプリケーションプログラムインターフェースにおいて受信されたタスクの各々に関係付けられる優先度レベルを識別する。タスクスケジューラは、タスクを処理するように要求する割り込みをグラフィックス処理装置から受信し、割り込みの受信に応じて、グラフィックス処理装置に最高の識別された優先度レベルを有するタスクを送信する。

一部の実施形態では、レンダリングコアは、複数のリモートプロシージャコールエンドポイントを含む。リモートプロシージャコールエンドポイントの各々は、複数の処理ドメインの１つに対して指定され、且つ指定された処理ドメインにより生成されるタスクを管理するように構成されてもよい。

一部の実施形態では、グラフィックス処理装置は、表示される各タスクの部品を識別し、識別された部品をフレームバッファに記憶するように構成される。一部の実施形態では、レンダリングコアは複数のフレームバッファを含む。フレームバッファの各々は、前記複数の処理ドメインの１つに対して指定され、表示されるタスクの部品としてグラフィックス処理装置により識別される各タスクの部品を記憶するように構成されてもよい。

一部の実施形態では、レンダリングコアは、複数のフレームバッファからタスクの識別された部品を受信し、識別された部品を組み立てることにより表示タスクを生成するように構成されるコンポジタを含む。グラフィックス処理装置は、タスクスケジューラから組み立て済みタスクを受信し、組み立て済みタスクに基づいて表示データを生成してもよい。

本開示の別の実装は車両インターフェースシステムである。車両インターフェースシステムは、グラフィックス処理装置及びマルチコアプロセッサを含む。マルチコアプロセッサは、高優先度車両アプリケーションを実行して、グラフィックス処理装置に対する高優先度タスクを生成するように構成される第１の処理コア、及び低優先度車両アプリケーションを実行して、グラフィックス処理装置に対する低優先度タスクを生成するように構成される第２の処理コアを含む。システムは、処理コアの各々により生成されるタスクを受信および管理するように構成されるグラフィックス処理装置ドライバを更に含む。システムは、グラフィックス処理装置ドライバで受信されたタスクの各々に関係付けられる優先度レベルを識別して、識別された優先度レベルに基づいてグラフィックス処理装置にタスクを送信する順番を決定するように構成されるタスクスケジューラを更に含む。グラフィックス処理装置は、タスクスケジューラにより決定された順番でタスクを処理し、タスクに基づいて表示データを生成する。システムは、グラフィックス処理装置により生成された表示データを受信して、表示データをユーザに提示するように構成される電子ディスプレイを更に含む。

本明細書で使用される用語「第１の処理コア」、「第２の処理コア」は、マルチコアプロセッサの１つのコアをマルチコアプロセッサの別のコアから区別することを意図している。記述子「第１の」及び「第２の」は、「第１の処理コア」がプロセッサの第１の論理コアであること又は「第２の処理コア」がプロセッサの第２の論理コアであることを必要としない。むしろ、「第１の処理コア」はプロセッサの任意のコアであり、「第２の処理コア」は第１のコアではない任意のコアであり得る。別段の記載がなければ、記述子「第１の」及び「第２の」は本明細書を通じて様々なアイテムを互いから区別するために使用されているのであって（例えば、複数のプロセッサコア、ドメイン、オペレーティングシステム等）、何らかの特定の順番又は順序を示唆するものではない。

一部の実施形態では、タスクスケジューラは、タスクを処理するように要求する割り込みをグラフィックス処理装置から受信するように構成される。タスクスケジューラは、グラフィックス処理装置ドライバで受信されたタスクのどれが最高の識別された優先度レベルを有するかを決定し、且つ割り込みの受信に応じて、グラフィックス処理装置に最高の識別された優先度レベルを有するタスクを送信してもよい。一部の実施形態では、タスクに関係付けられる優先度レベルを識別することは、複数の処理コアの中のどれが前記タスクを生成したかを識別すること、識別された処理コアに関係付けられる優先度レベルを識別すること、及び識別された処理コアに関係付けられる優先度レベルに従ってタスクに優先度レベルを割り当てることを含む。

一部の実施形態では、高優先度タスクは、車両のセーフティ及びクリティカル車両動作の少なくとも１つに関連する車両アプリケーションにより生成される。低優先度タスクは、車両インフォテイメントアプリケーション、クラウドアプリケーション、及び自立ドライバ支援システムアプリケーションの少なくとも１つにより生成されてもよい。

本開示の別の実装は、車両インターフェースシステムにおいてユーザインターフェースを生成するための方法である。方法は、マルチコアプロセッサの第１のコアにより、第１の処理ドメインにおいて高優先度車両アプリケーションを実行するステップを含む。高優先度車両アプリケーションは高優先度タスクを生成する。方法は、マルチコアプロセッサの第２のコアにより、第２の処理ドメインにおいて低優先度車両アプリケーションを実行するステップを更に含む。低優先度車両アプリケーションは低優先度タスクを生成する。方法は、タスクスケジューラにより、生成されたタスクの各々に関係付けられる優先度レベルを識別するステップ、及びタスクスケジューラにより、識別された優先度レベルに基づいてグラフィックス処理装置にタスクを送信する順番を決定するステップを更に含む。方法は、グラフィックス処理装置により、タスクスケジューラにより決定された順番でタスクを処理するステップを更に含む。グラフィックス処理装置はタスクに基づいて表示データを生成する。方法は、車両インターフェースシステムの電子ディスプレイを介してグラフィックス処理装置により生成された表示データを提示するステップを更に含む。

一部の実施形態では、タスクに関係付けられる優先度レベルを識別するステップは、複数の処理ドメインの中のどれがタスクを生成したかを識別すること、識別された処理ドメインに関係付けられる優先度レベルを識別すること、及び識別された処理ドメインに関係付けられる優先度レベルに従ってタスクに優先度レベルを割り当てることを含む。

一部の実施形態では、グラフィックス処理装置にタスクを送信する順番を決定するステップは、タスクを処理するように要求する割り込みをグラフィックス処理装置から受信すること、生成されたタスクのどれが最高の識別された優先度レベルを有するかを決定すること、及び割り込みの受信に応じて、グラフィックス処理装置に最高の識別された優先度レベルを有するタスクを送信することを含む。

当業者は、上記の概要は単なる例示であって、限定することを全く意図していないことを理解するであろう。単に請求項に定義された本明細書に記載の装置及び／又は処理の他の態様、新規な特徴、及び利点は、本明細書に記載された詳細な説明と共に添付の図面を合わせて考慮すれば明らかになるであろう。

例示的な実施形態による、本開示のシステム及び方法が実装可能な車両（例えば、自動車）の例示である。 例示的な実施形態による、本明細書に記載のシステム及び方法を使用して図１の車両に提供され得る車両ユーザインターフェースシステムの例示である。 例示的な実施形態による、本開示のシステム及び方法による、図２の車両ユーザインターフェースシステムを介して提供され得る車両計器クラスタディスプレイの例示である。 例示的な実施形態による、図２の車両ユーザインターフェースシステム及び／又は図３Ａの車両計器クラスタディスプレイ等の車両ユーザインターフェースを介してディスプレイに提供するように構成されるマルチコア処理環境を含む車両インターフェースシステムのブロック図である。 例示的な実施形態による、マルチコア処理環境がハイパーバイザ及び複数の別のドメインを含むように示されるより詳細な図３Ｂのマルチコア処理環境を示すブロック図である。 例示的な実施形態による、スタートアップ時に図４のハイパーバイザによって行われるメモリマッピング処理を示すブロック図である。 例示的な実施形態による、図４のハイパーバイザの様々な特徴を示すブロック図である。 例示的な実施形態による、共通ディスプレイシステムにおける表示出力を容易にするために使用され得る図３Ｂのマルチコア処理環境の様々なコンポーネントを示すブロック図である。 例示的な実施形態による、車両インターフェースシステムに表示されるアプリケーション画像（例えば、グラフィックス出力）を生成するために図４のマルチコア処理環境内で動作し得る様々な動作モジュールを示すブロック図である。 例示的な実施形態による、図１の車両に実装され得るＧＰＵ処理及び共有のためのシステム及び方法を示すフロー図である。 例示的な実施形態による、図９Ａのシステムをより詳細に示すブロック図である。 例示的な実施形態による、車両ディスプレイにおいてグラフィックスをレンダリングするための従来のグラフィックス処理システムによって行われ得るＧＰＵスケジューリング処理を示す。 例示的な実施形態による、図９Ａのシステムによって行われ得るタイルベース型ＧＰＵスケジューリング処理を示す。 例示的な実施形態による、図９Ａのシステムによって行われ得るイベント駆動型ＧＰＵスケジューリング処理を示す。 例示的な実施形態による、図９Ａのシステムによって行われ得るイベント駆動型ＧＰＵスケジューリング処理を示す。 例示的な実施形態による、図９Ａのシステムと共に使用され得るグラフィックスセーフティ及びセキュリティシステムのブロック図である。

概略的に図面を参照すると、様々な例示的な実施形態によって、車両内にユーザインターフェースを提示するためのシステム及び方法が示されている。本明細書に記載のシステム及び方法は、車両内に複数のユーザインターフェースを提示し、統合型システムにおける多様なアプリケーション要件をサポートするために使用されてもよい。様々な車両アプリケーションが異なる程度のセキュリティ、セーフティ、及び開放性（例えば、インターネットから新しいアプリケーションを受信する機能）を要求する場合がある。本開示のシステム及び方法は、１つのオペレーティングシステムの動作が他のオペレーティングシステムの動作と干渉することを防ぐように、実質的に独立して動作する複数の異なるオペレーティングシステム（例えば、高信頼性のオペレーティングシステム、クラウドアプリケーションオペレーティングシステム、娯楽オペレーティングシステム等）を提供する。

本明細書に記載の車両システムは、単一のプラットフォームにおいて異なるドメインを有利にカプセル化する。このカプセル化は、異なるアプリケーションをサポートするために高度のセキュリティ、セーフティ、及び開放性をサポートし、更に高度のユーザカスタム化及びユーザ相互作用を可能にする。車両システムは、セキュリティ及びセーフティを確保するためにドメイン間のある程度の分離を維持しつつ、単一のプラットフォームにおける複数の異なるドメインの動作を統合するように構成される仮想化コンポーネントを含む。例示的な実施形態では、車両システムを実装するためにマルチコアシステム・オン・チップ（ＳｏＣ）が使用される。

例示的な実施形態では、システムは、少なくとも以下の４つのドメイン、即ち、（１）高信頼性ドライバ情報クラスタドメイン、（２）クラウドドメイン、（３）娯楽ドメイン、及び（４）自立ドライバ支援システム（ＡＤＡＳ；ａｕｔｏｎｏｍｏｕｓ ｄｒｉｖｅｒ ａｓｓｉｓｔａｎｃｅ ｓｙｓｔｅｍ）ドメイン、を含み且つサポートする。高信頼性ドライバ情報クラスタドメインは、車両のセーフティ及び／又はクリティカル車両動作に関するクリティカル車両アプリケーションをサポートしてもよい。クラウドドメインは、インターネット、接続された携帯型電子装置又は別のソースからの新しいユーザ又は車両「アプリ」のダウンロードをサポートしてもよい。娯楽ドメインは、例えば、音楽プレーヤ、ナビゲーション、電話及び／又は接続アプリケーションを含むアプリケーション及びユーザインターフェースコンポーネントに高品質ユーザ体験を提供してもよい。ＡＤＡＳドメインは、自立ドライバ支援システムのサポートを提供してもよい。様々な実施形態では、任意の数及び／又はタイプのドメインが、ここで列挙された４つのドメインに加えて又は代わりにサポートされてもよい（例えば、２つのドメイン、３つのドメイン、４つのドメイン、８つのドメイン等）。

例示的な実施形態では、少なくとも４つの異なるオペレーティングシステム環境が提供される（例えば、各ドメインに対して１つ）。高信頼性ドメイン用の第１のオペレーティングシステム環境は、クラスタ情報を有するディスプレイを確実に駆動してもよい。クラウドドメイン用の第２のオペレーティングシステム環境は、新しいユーザ又は車両アプリをサポートしてもよい。娯楽ドメイン用の第３のオペレーティングシステム環境は、様々な娯楽アプリケーション及びユーザインターフェースコンポーネントをサポートしてもよい。ＡＤＡＳドメイン用の第４のオペレーティングシステム環境は、ＡＤＡＳアプリケーションを実行するための環境の提供をサポートしてもよい。一部の実施形態では、第５の動作環境は、グラフィックスヒューマンマシンインターフェース（ＨＭＩ）を制御すると共にユーザ入力を処理してもよい。オペレーティングシステム環境の各々は、マルチコアシステム・オン・チップ（ＳｏＣ）の異なるコア（又は複数のコア）に専用であってもよい。様々な実施形態では、任意の数及び／又はタイプの動作環境が、ここで記載された動作環境に加えて又は代わりに提供されてもよい。

例示的な実施形態では、専用オペレーティングシステムごとにメモリが分離される。主要オペレーティングシステムの各々が、非対称型マルチプロセッシング（ＡＭＰ；ａｓｙｍｍｅｔｒｉｃ ｍｕｌｔｉ−ｐｒｏｃｅｓｓｉｎｇ）を行うように構成され得るプロセッサの１つ（又は複数の）コアに結合されてもよい。有利に、各オペレーティングシステムをプロセッサの特定のコア（又は複数のコア）に結合することは、多数のハードウェア実行セキュリティ制御を提供する。例えば、ゲストに割り当てられる各コアは、物理メモリの既定の領域及び／又は周辺装置の既定のサブセットにのみアクセス可能であってもよい。車両装置（例えば、ＤＭＡ装置）は、ＳｏＣのハードウェアを介してメモリ保護を受けてもよい。この強い結合は、第１のゲストＯＳが異なるコアで実行されている他のゲストＯＳの動作と干渉できないように、第１のゲストオペレーティングシステム（ＯＳ）がマルチコアプロセッサの特定のコア（又は複数のコア）で実行できる環境をもたらす。ゲストＯＳは、ハイパーバイザレイヤを参照せずに実行されるように構成されてもよいが、基礎シリコン上で直接実行されてもよい。これは、各ゲストＯＳが変更又は修正される必要がない完全なハードウェア仮想化を提供する。

次に図１を参照すると、例示的な実施形態による自動車１が示されている。本明細書に記載の実施形態の特徴は、自動車１等の車両又は任意の他のタイプの車両用に実装されてもよい。本明細書に記載の実施形態は、自動車１の運転者又は乗客に改善された表示及び制御機能を有利に提供する。本明細書に記載の実施形態は、自動車１の様々な電子及び機械システム上で自動車１の運転者又は乗客に改善された制御を提供してもよい。

自動車１等の車両は、ユーザインターフェースシステムを含んでもよい。このようなユーザインターフェースシステムは、セーフティ関連情報（例えば、シートベルト情報、速度情報、タイヤ圧情報、エンジン警告情報、燃料レベル情報等）と共にインフォテイメント関連情報（例えば、音楽プレーヤ情報、ラジオ情報、ナビゲーション情報、電話情報等）をユーザに提供し得る。従来は、このようなシステムは、１つの車両サブシステムが自身のディスプレイにセーフティ関連情報を提供し、別の車両サブシステムが自身のディスプレイにインフォテイメント関連情報を提供するように相対的に分離されている。

本明細書に記載の様々な実施形態によれば、ドライバ情報（例えば、様々な車両安全性要求レベル、ＡＳＩＬによる）が、インフォテイメントアプリケーション及び／又はサードパーティ（例えば、「アプリ」又は「クラウド」）アプリケーションによってもたらされる。情報は、マルチコア処理環境により処理されて、表示環境にグラフィカルに統合される。この統合にもかかわらず、少なくとも高信頼性（即ち、セーフティ関連）処理が、ハードウェア及びソフトウェアによってセーフティ関連事項の無い処理及び情報から分離される。

例示的な実施形態によれば、自動車１は、車両ユーザインターフェース（例えば、１つ又は複数のディスプレイ及びユーザ入力装置）と統合されるコンピュータシステムを含み、且つ処理システムを含む。処理システムは、マルチコアプロセッサを含んでもよい。処理システムは、マルチコアプロセッサの１つ又は複数の第１のコアにおいて第１のゲストオペレーティングシステムに仮想化を提供するように構成されてもよい。また、処理システムは、マルチコアプロセッサの１つ又は複数の第２の異なるコア（即ち、第１のゲストオペレーティングシステムに割り当てられない任意のコア）において第２のゲストオペレーティングシステムに仮想化を提供するように構成されてもよい。第１のゲストオペレーティングシステムは、高信頼性動作用に構成されてもよい。仮想化は、第２のゲストオペレーティングシステムの動作が第１のゲストオペレーティングシステムの高信頼性動作を中断することを防ぐ。

次に図２を参照すると、例示的な実施形態による自動車用のユーザインターフェースシステムが示されている。ユーザインターフェースシステムは、計器クラスタディスプレイ（ＩＣＤ）２２０、ヘッドアップディスプレイ（ＨＵＤ）２３０、及び中央情報ディスプレイ（ＣＩＤ）２１０を含むように示されている。例示的な実施形態では、ディスプレイ２１０、２２０及び２３０の各々は単一の電子ディスプレイである。一部の実施形態では、ディスプレイ２１０、２２０及び２３０は、複数のドメインからの３つの別個のディスプレイドライバである。様々な車両サブシステムからの表示コンテンツが、ディスプレイ２１０、２２０及び２３０の各々に同時に表示されてもよい。例えば、図示の計器クラスタディスプレイ２２０はエンジン制御装置（ＥＣＵ）情報（例えば、速さ、ギヤ、ＲＰＭ等）を表示する。また、図示のディスプレイ２２０は、音楽アプリケーションからの音楽プレーヤ情報及びナビゲーションアプリケーションからのナビゲーション情報も表示する。また、ナビゲーション情報及び音楽プレーヤ情報は、ディスプレイ２３０にも出力されるように示される。電話アプリケーションからの電話情報が、（例えば、インターネットソースからの）天気情報及び（ディスプレイ２２０、２３０に情報を提供する同じナビゲーションアプリケーションからの）ナビゲーション情報と並行してディスプレイ２１０を介して提示されてもよい。

図２に示されているように、ＩＣＤ２２０、ＣＩＤ２１０及び／又はＨＵＤ２３０は、アプリケーション情報を表示するための異なる及び／又は複数の表示領域を有してもよい。こうした表示領域は、マルチコア処理環境及び／又は関連するハードウェア及びソフトウェアによって構成可能である仮想動作フィールドとして実装されてもよい。例えば、ＣＩＤ２１０は、３つの表示領域（例えば、仮想動作フィールド）を有するように示されている。携帯電話アプリケーション、天気アプリケーション、及びナビゲーションアプリケーション用のアプリケーションデータ情報が、それぞれ３つの表示領域に表示されてもよい。

マルチコア処理環境は、システムイベント、ユーザ入力、プログラム命令等に応答して表示領域を再構成してもよい。例えば、ユーザが天気アプリケーションを終了すると、電話アプリケーション及びナビゲーションアプリケーションはＣＩＤ２１０を満たすようにサイズ変更されてもよい。表示されるアプリケーションの数、表示されるアプリケーションのサイズ、表示されるアプリケーション情報、アプリケーションが高信頼性アプリケーションであるかどうか等の要因を考慮して、表示領域の多くの構成が可能である。異なる構成は、ポートレートとして表示されるアプリケーション、ランドスケープとして表示されるアプリケーション、複数列のアプリケーション、複数行のアプリケーション、異なるサイズの表示領域を有するアプリケーション等の異なる特徴を有してもよい。

例示的な実施形態では、ＩＣＤ２２０、ＣＩＤ２１０及びＨＵＤ２３０を提供する処理システムは、マルチコアプロセッサを含む。処理システムは、マルチコアプロセッサの１つ又は複数の第１のコアにおいて第１のゲストオペレーティングシステムに仮想化を提供するように構成されてもよい。また、処理システムは、マルチコアプロセッサの１つ又は複数の第２の異なるコア（即ち、第１のゲストオペレーティングシステムに割り当てられない１つ以上のコア）において第２のゲストオペレーティングシステムに仮想化を提供するようにも構成されてもよい。第１のゲストオペレーティングシステムは、高信頼性動作（例えば、ＥＣＵからセーフティ関連情報を受信し、受信した情報を使用してグラフィックス情報を生成すること）用に構成されてもよい。仮想化は、（例えば、サードパーティ開発者から又はクラウドからの「アプリ」を実行し得る）第２のゲストオペレーティングシステムの動作が第１のゲストオペレーティングシステムの高信頼性動作を中断することを防ぐ。

次に図３Ａを参照すると、例示的な実施形態による計器クラスタディスプレイ（ＩＣＤ）３００が示されている。ＩＣＤ３００は、ディスプレイスクリーンが共有される場合に可能な高度の統合を示す。ＩＣＤ３００において、ＥＣＵからの情報は、ナビゲーション情報に対してスクリーン領域の上に部分的にオーバレイされる。ナビゲーション情報用のスクリーン領域は、メディアプレーヤ、電話、又は他の情報に関係付けられる情報を表示するように変更され得る。先に説明されたように多くの構成が可能である。一部の実施形態では、ＩＣＤ３００又は別のディスプレイが、再構成されなくてもよい高信頼性情報を表示するための専用領域を有してもよい。例えば、ＩＣＤ３００に表示されるＥＣＵ情報は固定されてもよいが、残りの表示領域はマルチコア処理環境によって構成されてもよい。ナビゲーションアプリケーション及び天気アプリケーションは、高信頼性情報のために専用ではないＩＣＤ３００の１つ又は複数の表示領域に表示されてもよい。

一部の実施形態では、車両インターフェースシステムは、ＩＣＤ、ＣＩＤ、ＨＵＤ用のディスプレイ装置と他のディスプレイ（例えば、後部座席乗客ディスプレイ、乗客ダッシュボードディスプレイ等）との間の接続を管理する。車両インターフェースシステムは、ディスプレイ等の出力装置、入力装置、及びマルチコア処理環境に関連するハードウェアの間の接続を含んでもよい。このような車両インターフェースシステムは、図３Ｂを参照してより詳細に記載される。

次に図３Ｂを参照すると、例示的な実施形態による車両インターフェースシステム３０１が示されている。車両インターフェースシステム３０１は、マルチコア処理環境４００及び入出力装置、接続、及び／又は要素の間の接続を含む。マルチコア処理環境４００は、先に記載された車載オーディオビジュアルシステム用のシステムアーキテクチャを提供してもよい。マルチコア処理環境４００は、様々なコンピュータハードウェアコンポーネント（例えば、プロセッサ、集積回路、印刷回路基板、ランダムアクセスメモリ、ハードディスク記憶装置、ソリッドステートメモリ記憶装置、通信装置等）を含んでもよい。一部の実施形態では、マルチコア処理環境４００は、システムアーキテクチャによって、マルチコア処理環境４００内で実行中のアプリケーション及び／又は様々な周辺装置（例えば、装置３０３‐４４５）の間で交換される様々な入力及び出力を管理する。マルチコア処理環境４００は、例えば、計算を行い、アプリケーションを実行し、車両インターフェースシステム３０１を管理し、汎用処理タスクを行い、オペレーティングシステムを実行してもよい。

マルチコア処理環境４００は、マルチコア処理環境４００が他の装置又はソースから情報を受信し及び／又は他の装置又はソースに情報を送信することを可能にするコネクタハードウェアに接続されてもよい。例えば、マルチコア処理環境４００は、コネクタハードウェアを介してマルチコア処理環境４００に接続される携帯型メディア装置、データ記憶装置、サーバ、携帯電話等にデータを送信し又はこれらからデータを受信してもよい。一部の実施形態では、マルチコア処理環境４００は、アップル認定コネクタ３０３に接続される。アップル認定コネクタ３０３は、ＡＰＰＬＥ(R)製品に接続するための任意のコネクタであってもよい。例えば、アップル認定コネクタ３０３は、ファイアワイアコネクタ、３０ピンＡＰＰＬＥ(R)装置互換コネクタ、ライトニングコネクタ等であってもよい。

一部の実施形態では、マルチコア処理環境４００は、「ＵＳＢ２．０」（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ ｖｅｒｓｉｏｎ ２．０）コネクタ３０５に接続される。ＵＳＢ２．０コネクタ３０５は、１つ以上の装置又はデータソースの接続を可能にしてもよい。例えば、ＵＳＢ２．０コネクタ３０５は、４つのメスコネクタを含んでもよい。他の実施形態では、ＵＳＢ２．０コネクタ３０５は、１つ以上のオスコネクタを含む。一部の実施形態では、マルチコア処理環境４００は、「ＵＳＢ３．０」（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ ｖｅｒｓｉｏｎ ３．０）コネクタ３０７に接続される。ＵＳＢ２．０コネクタ３０５を参照して記載されたように、ＵＳＢ３．０コネクタ３０７は、互換装置が接続することを可能にする１つ以上のオス又はメス接続を含んでもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上の無線通信接続３０９に接続される。無線通信接続３０９は、追加の無線通信装置（例えば、プロセッサ、アンテナ等）と共に実装されてもよい。無線通信接続３０９は、マルチコア処理環境４００と他の装置又はソースとの間のデータ転送を可能にする。例えば、無線通信接続３０９は、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）３．０等のＢｌｕｅｔｏｏｔｈ（登録商標）通信、ＺｉｇＢｅｅ通信、Ｗｉ−Ｆｉ通信、ローカルエリアネットワーク及び／又は無線ローカルエリアネットワークを介する通信等を使用してデータ転送を可能にしてもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のビデオコネクタ３１１に接続される。ビデオコネクタ３１１は装置／ソース間のビデオデータの送信を可能にし、マルチコア処理環境４００が接続される。例えば、ビデオコネクタ３１１は、ＨＤＭＩ（登録商標）（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）等の標準に準拠するコネクタ又は接続であってもよい。一部の実施形態では、ビデオコネクタ３１１は、データ転送を促進する及び／又は標準に準拠するハードウェアコンポーネントを含む。例えば、ビデオコネクタ３１１は、補助プロセッサ、集積回路、メモリ、ＭＩＰＩ（ｍｏｂｉｌｅ Ｉｎｄｕｓｔｒｙ Ｐｒｏｃｅｓｓｏｒ Ｉｎｔｅｒｆａｃｅ）等を使用する標準を実装してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上の有線通信接続３１３に接続される。有線通信接続３１３は、ハードウェア及び／又はネットワーク装置間の接続を含んでもよい。例えば、有線通信接続３１３は、Ｅｔｈｅｒｎｅｔ（登録商標）スイッチ、ルータ、ハブ、ネットワークブリッジ等であってもよい。

マルチコア処理環境４００は、車両コントロール３１５に接続されてもよい。一部の実施形態では、車両コントロール３１５は、マルチコア処理環境４００が車両によって使用されるプロセッサ、メモリ、センサ等の車両制御設備と接続することを可能にする。例えば、車両コントロール３１５は、マルチコア処理環境４００をエンジン制御装置、エアバッグモジュール、身体制御器、走行制御モジュール、トランスミッション制御器等に接続してもよい。他の実施形態では、マルチコア処理環境４００は、列挙されているようなコンピュータシステムに直接接続される。このような場合、車両コントロール３１５は、エンジン制御装置、搭載プロセッサ、搭載メモリ等の要素を含む車両制御システムである。車両コントロール３１５は、車両コントロール３１５に接続される追加のソースからの情報をルーティングしてもよい。情報は、追加のソースからマルチコア処理環境４００へ及び／又はマルチコア処理環境４００から追加のソースへルーティングされてもよい。

一部の実施形態では、車両コントロール３１５は、１つ以上のＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋｓ）３１７、車両センサ３１９、及び／又はＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）３２１に接続される。ＬＩＮ３１７は、ＬＩＮプロトコルに準拠し、車両コンポーネント間の通信を可能にしてもよい。車両センサ３１９は、車両テレメトリを決定するためのセンサを含んでもよい。例えば、車両センサ３１９は、ジャイロスコープ、加速度計、３次元加速度計、傾斜計等の１つ以上であってもよい。ＣＡＮ３２１は、ＣＡＮバスによって車両コントロール３１５に接続されてもよい。ＣＡＮ３２１は、車内のセンサからのフィードバックを制御又は受信してもよい。また、ＣＡＮ３２１は、車両の電子制御装置と通信してもよい。他の実施形態では、車両コントロール３１５の機能は、マルチコア処理環境４００によって実装されてもよい。例えば、車両コントロール３１５は省略されてもよく、マルチコア処理環境４００はＬＩＮ３１７、車両センサ３１９、ＣＡＮ３２１又は車両の他のコンポーネントと直接接続してもよい。

一部の実施形態では、車両インターフェースシステム３０１は、システムモジュール３２３を含む。システムモジュール３２３は、電源を含み、及び／又は他のやり方で車両インターフェースシステム３０１に電力を供給してもよい。システムモジュール３２３は、プラットフォーム温度を監視又は制御するコンポーネントを含んでもよい。また、システムモジュール３２３は、起動及び／又はスリープ機能を実行してもよい。

図３Ｂを更に参照すると、マルチコア処理環境４００は、チューナコントロール３２５に接続されてもよい。一部の実施形態では、チューナコントロール３２５は、マルチコア処理環境４００が無線信号受信機と接続することを可能にする。チューナコントロール３２５は、マルチコア処理環境４００とＦＭアンテナ、ＡＭアンテナ等の無線伝送受信機との間のインターフェースであってもよい。チューナコントロール３２５は、マルチコア処理環境４００が信号を受信し、及び／又は受信機を制御することを可能にしてもよい。他の実施形態では、チューナコントロール３２５は、無線信号受信機及び／又はアンテナを含む。チューナコントロール３２５は、マルチコア処理環境４００によって制御される無線信号を受信してもよい。例えば、マルチコア処理環境４００は、チューナコントロール３２５に特定の周波数に同調するように命令してもよい。

一部の実施形態では、チューナコントロール３２５は、１つ以上のＦＭ及びＡＭソース３２７、ＤＡＢ（Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｂｒｏａｄｃａｓｔｉｎｇ）ソース３２９、及び／又は１つ以上のＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）ラジオソース３３１に接続されるＦＭ及びＡＭソース３２７は無線信号であってもよい。一部の実施形態では、ＦＭ及びＡＭソース３２７は、受信機、アンテナ等のハードウェアを含んでもよい。ＤＡＢソース３２９は、ＤＡＢ技術及び／又はプロトコルを利用する無線信号であってもよい。他の実施形態では、ＤＡＢソース３２９は、アンテナ、受信機、プロセッサ等のハードウェアを含んでもよい。ＨＤラジオソース３３１は、ＨＤラジオ技術及び／又はプロトコルを利用する無線信号であってもよい。他の実施形態では、ＨＤラジオソース３３１は、アンテナ、受信機、プロセッサ等のハードウェアを含んでもよい。

一部の実施形態では、チューナコントロール３２５は、１つ以上のアンプ３３３に接続される。アンプ３３３は、チューナコントロール３２５からオーディオ信号を受信してもよい。アンプ３３３は、信号を増幅して、それを１つ以上のスピーカに出力する。例えば、アンプ３３３は、１つ以上のスピーカ（例えば、４つのスピーカ）に接続される４チャネルパワーアンプであってもよい。一部の実施形態では、マルチコア処理環境４００は、（例えば、マルチコア処理環境４００内のアプリケーションによって生成される）オーディオ信号を、今度はアンプ３３３に信号を送信するチューナコントロール３２５に送信してもよい。

図３Ｂを更に参照すると、マルチコア処理環境４００は、マルチコア処理環境４００がメディアソースから情報を受信し及び／又はメディアソースに情報を送信することを可能にするコネクタハードウェア３３５−４４５に接続されてもよい。他の実施形態では、マルチコア処理環境４００は、メディアソースに直接接続され、マルチコア処理環境４００内に組み込まれるメディアソースを有し、及び／又は他のやり方でメディア情報を送受信してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＤＶＤドライブ３３５に接続される。ＤＶＤドライブ３３５は、ＤＶＤドライブ３３５に挿入されたＤＶＤディスクからマルチコア処理環境４００にＤＶＤ情報を提供する。マルチコア処理環境４００は、接続を介してＤＶＤドライブ３３５を制御してもよい（例えば、ＤＶＤディスクを読み込み、ＤＶＤディスクを排出し、情報を再生し、情報を停止する等）。更なる実施形態では、マルチコア処理環境４００は、ＤＶＤディスクにデータを書き込むためにＤＶＤドライブ３３５を使用する。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅｓ）３３７に接続される。一部の実施形態では、マルチコア処理環境４００は、ＳＳＤ３３７に直接接続される。他の実施形態では、マルチコア処理環境４００は、ＳＳＤ３３７の取り外しを可能にする接続ハードウェアに接続される。ＳＳＤ３３７はデジタルデータを含んでもよい。例えば、ＳＳＤ３３７は、デジタル的に記憶された画像、ビデオ、テキスト、オーディオ、アプリケーション等を含んでもよい。更なる実施形態では、マルチコア処理環境４００は、ＳＳＤ３３７に情報を記憶するためにＳＳＤ３３７との接続を使用する。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カードスロット３３９に接続される。ＳＤカードスロット３３９は、ＳＤカードを受け入れるように構成される。一部の実施形態では、異なるサイズのＳＤカード（例えば、マイクロ、フルサイズ等）を受け入れる複数のＳＤカードスロット３３９がマルチコア処理環境４００に接続される。ＳＤカードスロット３３９は、マルチコア処理環境４００がＳＤカードから情報を取得し、及び／又はＳＤカードに情報を書き込むことを可能にする。例えば、マルチコア処理環境４００は、上記のソースからアプリケーションデータを取得し、及び／又は上記のソースにアプリケーションデータを書き込んでもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のビデオデコーダ４４１に接続される。ビデオデコーダ４４１は、マルチコア処理環境４００にビデオ情報を提供してもよい。一部の実施形態では、マルチコア処理環境４００は、情報を復号して、マルチコア処理環境４００にそれを送信するビデオデコーダ４４１に情報を提供してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のコーデック４４３に接続される。コーデック４４３は、デジタルデータストリーム又は信号を符号化又は復号することを可能にする情報をマルチコア処理環境４００に提供してもよい。コーデック４４３は、追加のハードウェア（例えば、プロセッサ、メモリ等）で実行されるコンピュータプログラムであってもよい。他の実施形態では、コーデック４４３は、マルチコア処理環境４００のハードウェアで実行されるプログラムであってもよい。更なる実施形態では、コーデック４４３は、マルチコア処理環境４００によって使用される情報を含む。一部の実施形態では、マルチコア処理環境４００は、コーデック４４３から情報を取得し、及び／又はコーデック４４３に情報（例えば、追加のコーデック）を提供してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上の衛星ソース４４５に接続される。衛星ソース４４５は、衛星から受信した信号及び／又はデータであってもよい。例えば、衛星ソース４４５は、衛星ラジオ及び／又は衛星テレビ信号であってもよい。一部の実施形態では、衛星ソース４４５は信号又はデータである。他の実施形態では、衛星ソース４４５は、アンテナ、受信機、プロセッサ等のハードウェアコンポーネントを含んでもよい。

図３Ｂを更に参照すると、マルチコア処理環境４００は、入出力装置４４１−４５３に接続されてもよい。入出力装置４４１−４５３は、マルチコア処理環境４００がユーザに情報を表示することを可能にしてもよい。また、入出力装置４４１−４５３は、ユーザがマルチコア処理環境４００に制御入力を提供することを可能にしてもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＣＩＤディスプレイ４４７に接続される。マルチコア処理環境４００は、ＣＩＤディスプレイ４４７に画像、データ、ビデオ等を出力してもよい。例えば、マルチコア処理環境４００内で実行中のアプリケーションがＣＩＤディスプレイ４４７に出力されてもよい。一部の実施形態では、ＣＩＤディスプレイ４４７は、マルチコア処理環境４００に入力情報を送信してもよい。例えば、ＣＩＤディスプレイ４４７は、タッチ対応であり、マルチコア処理環境４００に入力情報を送信してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＩＣＤディスプレイ４４９に接続される。マルチコア処理環境４００は、ＩＣＤディスプレイ４４９に画像、データ、ビデオ等を出力してもよい。例えば、マルチコア処理環境４００内で実行中のアプリケーションがＩＣＤディスプレイ４４９に出力されてもよい。一部の実施形態では、ＩＣＤディスプレイ４４９は、マルチコア処理環境４００に入力情報を送信してもよい。例えば、ＩＣＤディスプレイ４４９は、タッチ対応であり、マルチコア処理環境４００に入力情報を送信してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のＨＵＤディスプレイ４５１に接続される。マルチコア処理環境４００は、ＨＵＤディスプレイ４５１に画像、データ、ビデオ等を出力してもよい。例えば、マルチコア処理環境４００内で実行中のアプリケーションがＨＵＤディスプレイ４５１に出力されてもよい。一部の実施形態では、ＨＵＤディスプレイ４５１は、マルチコア処理環境４００に入力情報を送信してもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上の後部座席ディスプレイ４５３に接続される。マルチコア処理環境４００は、後部座席ディスプレイ４５３に画像、データ、ビデオ等を出力してもよい。例えば、マルチコア処理環境４００内で実行中のアプリケーションが後部座席ディスプレイ４５３に出力されてもよい。一部の実施形態では、後部座席ディスプレイ４５３は、マルチコア処理環境４００に入力情報を送信してもよい。例えば、後部座席ディスプレイ４５３は、タッチ対応であり、マルチコア処理環境４００に入力情報を送信してもよい。

更なる実施形態では、マルチコア処理環境４００は、他のソースから入力を受信してもよい。例えば、マルチコア処理環境４００は、ハードキーコントロール（例えば、ボタン、ノブ、スイッチ等）から入力を受信してもよい。一部の実施形態では、マルチコア処理環境４００は、パーソナルメディア装置、携帯電話等の接続装置からも入力を受信してもよい。追加の実施形態では、マルチコア処理環境４００は、こうした装置に出力してもよい。

次に図４を参照すると、例示的な実施形態によるマルチコア処理環境４００をより詳細に示すブロック図が示されている。一部の実施形態では、マルチコア処理環境４００は、システム・オン・チップ、ＡＲＭｖ７−Ａアーキテクチャ、ＡＲＭｖ８アーキテクチャ又は任意の他のアーキテクチャを使用して実装される。他の実施形態では、マルチコア処理環境４００は、同じ又は類似の環境を提供するためにシステム・オン・チップではないマルチコアプロセッサを含んでもよい。例えば、マルチコアプロセッサは、複数の処理コアをサポートするマザーボード上の汎用コンピュータマルチコアプロセッサであってもよい。更なる実施形態では、マルチコア処理環境４００は、複数のネットワーク化された処理コアを使用して実装されてもよい。一実施形態では、マルチコア処理環境４００は、クラウドコンピュータアーキテクチャ又は他の分散コンピュータアーキテクチャを使用して実装されてもよい。

マルチコア処理環境４００は、ハイパーバイザ４０２を含むように示されている。ハイパーバイザ４０２は、ブート中にマルチコア処理環境４００を生成するのを支援するために、ブートローダと統合され又はブートローダと連動して動作してもよい。システムファームウェア（図示せず）が、第１のＣＰＵコア（コア０）を使用してブートローダ（例えば、Ｕ−Ｂｏｏｔ）を開始し得る。ブートローダは、ゲストＯＳ用のブートパーティションからカーネルイメージ及びデバイスツリーをロードし得る。次に、ハイパーバイザ４０２は、コア１で実行されるゲストＯＳ用に使用されるデータ構造を初期化し得る。次に、ハイパーバイザ４０２は、コア１用のゲストＯＳをブートし得る。次に、ハイパーバイザ４０２は、ハイパーバイザモードに切り替え、ハイパーバイザレジスタを初期化し、ゲストカーネルに制御を引き渡し得る。次に、コア０上で、ハイパーバイザ４０２は、コア０上で実行されるゲスト用に同じことをし得る（即ち、ゲスト用のデータ構造を初期化し、ハイパーバイザモードに切り替え、ハイパーバイザレジスタを初期化し、コア０用のゲストカーネルに制御を引き渡す）。ブートアップ後、プライマリコアとセカンダリコアとの区別は無視されてもよく、ハイパーバイザ４０２は２つのコアを等しく取り扱ってもよい。トラップは同じコアでそれらをトリガしたゲストとして処理されてもよい。

図４では、マルチコア処理環境４００は、ハイパーバイザ４０２によってセットアップが行われた後で、且つドメイン４０８−４１４を提供するためにゲストＯＳがブートアップされた後の状態のマルチコア処理環境４００が示されている。ドメイン４０８−４１４の各々は、インフォテイメントディスプレイ４２５、クラスタディスプレイ４２６、及び／又はヘッドアップディスプレイ４２７等のディスプレイシステムの所定の領域又はウィンドウを出力することに関与し得る。一部の実施形態では、クラスタディスプレイ４２６はＩＣＤであってもよい。クラスタディスプレイ４２６は、表示領域Ａ及びＢを有するように示されている。高信頼性ドメイン４０８は、表示領域Ａに関係付けられてもよい。表示領域Ａは、車両速度、エンジン状態、車両警報、タイヤ状態、又はＥＣＵからの他の情報等のセーフティクリティカル情報を表示するために使用されてもよい。表示領域Ａ用の情報は、完全にドメイン４０８によって提供されてもよい。表示領域Ｂは、インフォテイメントコア４１０によって生成される表示出力により提供される音楽プレーヤアプリケーションのユーザインターフェースを表してもよい。クラウドドメイン４１４は、表示領域Ｂにおいてインターネットベースの天気アプリケーションのユーザインターフェースを提供してもよい。有利に、クラウドドメイン４１４に又はインフォテイメントコア４１０で実行中の音楽プレーヤに存在し得るシステム不安定性、クラッシュ又は他の予想外の問題は、表示領域Ａの動作又は高信頼性ドメイン４０８により提供される任意の他の処理に影響を与える又は中断することが完全に防がれてもよい。

各ゲストＯＳは、そのオペレーティングシステムにおいて処理を実行するための自身のアドレス空間を有してもよい。２ステージメモリ管理装置（ＭＭＵ）４０４の第１ステージは、ゲストＯＳにより使用される論理アドレス及びそのアプリケーションを物理アドレスに変換してもよい。ゲストＯＳ用のＭＭＵ４０４により生成されるこのアドレスは、中間アドレスであってもよい。２ステージＭＭＵ４０４の第２ステージは、各ゲストからのこうした中間アドレスを実際の物理アドレスに変換してもよい。メモリの領域を特定のゲストＯＳ（従って、特定のドメイン及びコア）にマッピングするために使用されることに加えてＭＭＵ４０４の第２ステージは、図４に示されているように、メモリマップド周辺装置を特定のドメイン（従って、ゲストＯＳ及びコア）に専用にすることができる。

ハイパーバイザ４０２は、ＭＭＵ４０４の第２ステージを構成するのに使用されてもよい。ハイパーバイザ４０２は、物理メモリ領域を異なるゲストに割り当ててもよい。構成時間中にこうしたマッピングを静的に定義することは、全てのゲストに対する中間・物理メモリマッピングが互いのメモリ空間を侵害することができないように定義されることを確実にするのに役立つ。ゲストＯＳは、論理から中間メモリ空間への第１ステージのメモリマッピングを提供する。２ステージＭＭＵ４０４は、ゲストＯＳが通常通りに動作する（即ち、ゲストＯＳがメモリマッピングの所有権を有しているように動作する）ことを可能にしつつ、マッピングの基礎レイヤが異なるゲストＯＳ（即ち、ドメイン）が互いから分離されたままであることを確実にすることができる。

図４に示されているように、同じディスプレイ（クラスタディスプレイ４２６）を共有し且つ同じハードウェア（例えば、システム・オン・チップ）を共有する一方で、図４のアーキテクチャはドメイン間のパーティション化を提供する。図４に示されるアーキテクチャは、コンピュータシステムに車両ユーザインターフェース（例えば、入力装置、ディスプレイ４２６）との統合を提供する。一部の実施形態では、マルチコア処理環境４００は、マルチコアプロセッサを含む。マルチコア処理環境４００は、マルチコアプロセッサの１つ又は複数の第１のコア（例えば、コア０）において第１のゲストオペレーティングシステム（例えば、ＱＮＸ ＯＳ４１６）に仮想化を提供するように構成されてもよい。マルチコア処理環境４００は、マルチコアプロセッサの１つ又は複数の第２の異なるコア（例えば、コア１）において少なくとも第２のゲストオペレーティングシステム（例えば、Ｌｉｎｕｘ（登録商標） ＯＳ４１８）に仮想化を提供するように構成されてもよい。第１のゲストオペレーティングシステム（例えば、「リアルタイム」ＱＮＸ ＯＳ４１６）は、高信頼性動作用に構成されてもよい。仮想化を提供するために非対称型マルチプロセッシング（ＡＭＰ）を使用してオペレーティングシステムをそれ自身のコアに専用にすることは、第２のゲストオペレーティングシステム（例えば、Ｌｉｎｕｘ ＯＳ４１８）の動作が第１のゲストオペレーティングシステム（例えば、ＱＮＸ ＯＳ４１６）の高信頼性動作を中断することを防ぐのに有利に役立つ。

高信頼性ドメイン４０８は、１つ以上の割り当てられた周辺機器としてＥＣＵ入力を有し得る。例えば、ＥＣＵは、高信頼性ドメイン４０８に割り当てられる周辺機器１であってもよい。周辺機器２は、車両のコントローラエリアネットワーク（ＣＡＮ）等の別の車両ハードウェア装置であってもよい。ドメイン間のパーティション化を考慮すると、インフォテイメントドメイン４１０、ネイティブＨＭＩドメイン４１２、及びクラウドドメイン４１４は、ＥＣＵ又はＣＡＮに直接アクセスすることができなくてもよい。他のドメイン（例えば、４１０、４１４）によってＥＣＵ又はＣＡＮ情報が使用される場合、情報は、高信頼性ドメイン４０８により取得されて、共有メモリ４２４に配置され得る。

例示的な実施形態では、各スクリーンがドメイン４０８−４１４の１つ以上からのグラフィカル出力を保持するように、クラスタディスプレイ４２６等の複数の分離したスクリーンはシステムを提供され得る。一組のシステム周辺機器（例えば、ＥＣＵ、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ハードドライブ等）が、単一のマルチコアシステム・オン・チップを使用して１つ又は複数のスクリーンを提供するために使用されてもよい。本明細書に記載のドメインパーティション化は、インフォテイメントオペレーティングシステム（例えば、インフォテイメントドメイン４１０）、インターネット／アプリオペレーティングシステム、及び／又はクラウドオペレーティングシステム（例えば、クラウドドメイン４１４）からセーフティ関連ドライバ情報オペレーティングシステム（例えば、高信頼性ドメイン４０８）を効果的に分離することができる。

様々なオペレーティングシステムが、他の動作ドメインを有するスクリーン上に示されるアプリケーションのビューを生成することができる。異なるスクリーンは、異なるドメインにより制御されてもよい。例えば、クラスタディスプレイ４２６は高信頼性ドメイン４０８によって主に制御されてもよいが、インフォテイメントディスプレイ４２５はインフォテイメントドメイン４１０によって主に制御されてもよい。ドメイン４０８−４１４によって生成される様々なグラフィックス出力が、以下の図面においてより詳細に記載される。この制御にもかかわらず、ドメイン４１０、４１４からのビューがクラスタディスプレイ４２６に示され得る。共有メモリ４２４が、ドメイン４１０、４１４からドメイン４０８へグラフィックビューを提供するために使用されてもよい。特に、ピクセルバッファコンテンツが、ドメイン４０８によって使用するためにドメイン４１０、４１４から共有メモリ４２４に提供されてもよい。例示的な実施形態では、（例えば、ｌｉｎｕｘ ＯＳ４２０を有する）ネイティブＨＭＩドメイン４１２が、グラフィカル出力を調整するために使用され、ドメイン４０８−４１４、４１０及び４１４の各々からピクセルバッファコンテンツを使用して表示出力を構築する。

有利に、単一のシステムが複数のディスプレイを駆動するために使用され且つ複数のドメインをまとめるので、ユーザは、どのドメイン又はアプリケーションコンテンツがどこ（例えば、クラスタディスプレイ、インフォテイメントディスプレイ４２５、ヘッドアップディスプレイ４２７、後部座席ディスプレイ等）に示されるかを構成することが可能であってもよい。例えば、ユーザは、高信頼性ドメイン４０８、インフォテイメントドメイン４１０、ネイティブＨＭＩドメイン４１２、クラウドドメイン４１４、及び／又は表示コンテンツを生成する任意の他のドメインからの情報を表示するように情報クラスタディスプレイ４２６を構成し得る。例えば、ユーザは、高信頼性ドメイン４０８、インフォテイメントドメイン４１０、ネイティブＨＭＩドメイン４１２、クラウドドメイン４１４、及び／又は任意の他のドメインからの情報を表示するようにインフォテイメントディスプレイ４２５及び／又はヘッドアップディスプレイ４２７を構成し得る。異なるドメインからのコンテンツは、同じディスプレイの異なる部分に（例えば、異なる仮想動作フィールドに）又は異なるディスプレイに表示されてもよい。様々なアプリケーションからのコンテンツを表示するために使用される仮想動作フィールドは、異なるディスプレイに移動され、再配置され、位置を変えられ、サイズ変更され、又はユーザの好みに適合するように他のやり方で調節され得る。

一部の実施形態では、車載周辺機器が、特定のオペレーティングシステムに割り当てられる。車載周辺機器は、装置ポート（ＧＰＩＯ、Ｉ２Ｃ、ＳＰＩ、ＵＡＲＴ）、専用オーディオライン（ＴＤＭ、Ｉ２Ｓ）、又はより多くの他のコントローラ（Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ、ＭＯＳＴ）を含んでもよい。各ＯＳは、Ｉ／Ｏ装置に直接アクセスすることができる。従って、Ｉ／Ｏ装置は各ＯＳに割り当てられる。第２ステージのメモリ管理装置（ＭＭＵ）４０４は、異なるオペレーティングシステム／ドメインに割り当てられる中間アドレスを周辺機器にマッピングする。

図５を参照すると、例示的な実施形態による、特定のドメインにおける個々のゲストＯＳに装置を割り当てるための第２ステージＭＭＵ４２８の使用を例示するブロック図が示されている。第２ステージＭＭＵ４２８は、図４を参照して記載された２ステージＭＭＵ４２４のコンポーネントであってもよい。ブート中に第２ステージＭＭＵ４２８を構成するハイパーバイザ４０２が示されている。ハイパーバイザ４０２は、第２ステージＭＭＵ４２８用のページテーブルをセットアップして、中間アドレス（ＩＡ）を物理アドレス（ＰＡ）に変換してもよい。一部の実施形態では、第２ステージＭＭＵ４２８は、ＩＰＡ空間からの任意のページ（例えば、４ｋＢページ）をＰＡ空間からの任意のページにマッピングすることができる。マッピングは、読み出し／書き込み、読み出し専用、書き込み専用として、又は他の適切な許可を有するように指定され得る。ページテーブルをセットアップするために、ハイパーバイザ４０２は、ハイパーバイザ４０２のデバイスツリーで利用可能なメモリ範囲情報を使用することができる。この配置は、どの装置がゲストに割り当てられるかを設定するための単一の場所を有利に提供し、ハイパーバイザ４０２及びゲストカーネルの両方がデバイスツリーを使用することができる。

図５には、スタートアップ時にハイパーバイザ４０２により行われるマッピングの単純化された例が示されている。コア０が、メモリ領域０、メモリマップド周辺機器０、及びメモリマップ周辺機器１に割り当てられてもよい。コア１は、メモリ領域１及び周辺機器２に割り当てられる。構成は、各コアがそのＯＳのデバイスツリーで指定されたメモリマッピング領域を割り当てられるように継続するであろう。ゲストドメインが第２ステージＭＭＵ４２８により管理されるページテーブルに従ってマッピングされていないページへのアクセスを試みると、ゲスト用のプロセッサコアは例外を出し、それにより、ハイパーバイザ４０２をアクティブ化して、データ又は命令停止ハンドリングのためにハイパーバイザ４０２のトラップハンドラ４３０を呼び出す。例示的な実施形態では、オペレーティングシステムからＣＰＵへの１：１のマッピングが有り、ハイパーバイザによってスケジューリングが行われない。有利に、こうした実施形態は、仮想割り込み管理の必要性及び仮想ＣＰＵインターフェースの必要性を減らす。通常の割り込みが発生すると、各ＣＰＵはそのゲストＯＳでその割り込みを直接処理することができる。

ハイパーバイザ４０２は、異なるドメインで実行中の２つのゲストオペレーティングシステム間の通信をサポートしてもよい。上記のように、このような通信のために共有メモリが使用される。２つのゲストのデバイスツリーにおいて特定の物理メモリ範囲が指定されると、そのメモリ範囲は両方のコアにマッピングされ、共有メモリとしてアクセス可能になる。ゲストＯＳ間の割り込みに対して、割り込みラインをアサート及びクリアするために割り込みコントローラが使用される。例示的な実施形態によれば、カーネルにおける各仮想装置に対するデバイスツリーは、他のコアとの通信のためにどの割り込みをトリガすべきかを記述する「ドアベル」プロパティを有する。トラップされたメモリページを使用してドアベルがアクセスされ、そのアドレスはデバイスツリーにも記述されている。受信側では、トラップされたメモリページを使用して割り込みがクリアされる。これは、ロッキング無しで且つ、従来の装置割り込みと比較して比較的低いオーバヘッドで、割り込みアサーション及びハンドリングを可能にする。

例示的な実施形態では、ゲストオペレーティングシステムは、システム全体をリセットすることは許可されない。その代わり、システムは、（例えば、エラー状態から回復するために）個々のゲストのリセットをサポートするように構成される。ハイパーバイザ４０２は、ゲストオペレーティングシステムのカーネル及びデバイスツリーのバックアップコピーを作成して、ハイパーバイザ保護メモリ領域に情報を記憶することができる。ゲストがシステムの初期化を試みると、ハイパーバイザトラップがゲストリセットを開始するであろう。このゲストリセットはバックアップコピーからカーネル及びデバイスツリーを復元することにより行われ、割り当てられたコアのＣＰＵ状態を再初期化して、ゲストのブートアップのために制御をゲストに戻す。

次に図４−６を参照すると、ハイパーバイザ４０２がリソースの初期構成及び割り当てを行うと、ハイパーバイザ４０２は通常動作中に休眠状態になってもよい。ハイパーバイザ４０２は、予想外のトラップが発生したときにのみアクティブになってもよい。ハイパーバイザ４０２のこの態様は、図４、５及び６の各々に様々に示されている。図６に示されているように、構成時（図５を参照）におけるメモリの割り当てのために専用ハードウェア装置又はメモリ領域へのゲストＯＳの直接アクセスにハイパーバイザの関与は無い。ハイパーバイザアクセスモード（Ｃｏｒｔｅｘ Ａ１５等の一部のＡＲＭプロセッサにおける「ＨＹＰ」モード）は、任意の個々のゲストＯＳよりも高い特権レベルの下でハードウェアプラットフォームにアクセスすることができる。高特権ＨＹＰモードで実行するハイパーバイザは、受信したトラップを制御することができる。こうしたトラップは、フレームバッファ書き込み同期信号、音声同期信号、又は構成レジスタ（例えば、クロックレジスタ、コプロセッサレジスタ）へのアクセスを含み得る。

例示的な実施形態では、ハイパーバイザ４０２は、通常の割り込み分配には関与していない。むしろ、割り込みコントローラ（例えば、一部のＡＲＭチップの汎用割り込みコントローラ）は、適切なコアへの伝達を処理することができる。ハイパーバイザ４０２は、ブート中の割り込みコントローラを設定することができる。上記のように、ゲストＯＳ間の通信は、共有メモリ及び割り込みに基づく。トラップ及び書き込みハンドラは、コア間で割り込みを送信するように構成される。

図６に示されているように、装置割り込みは、ハイパーバイザ４０２による構成時に個々のゲストＯＳ又はコアに割り当てられてもよい。初期化中に、ハイパーバイザ４０２は、ブートアップ中に値を有用に設定し得る割り込みコントローラ（例えば、ＧＩＣ）セットアップを実行することができる。各ゲストがブートされると、ハイパーバイザ４０２は、ゲストのデバイスツリーから割り込み割り当てを読み込むことができる。ハイパーバイザ４０２は、適切なＣＰＵコアに関係付けられるようにＩＲＱマップに割り込み読み込み（ｉｎｔｅｒｒｕｐｔ ｒｅａｄ）を追加することができる。このマップは、ランタイム中にディストリビュータによって使用されてもよい。次に、ハイパーバイザ４０２は、適切なＣＰＵコアに対する割り込みを使用可能にすることができる。ゲストＯＳがディストリビュータへのアクセスを試みるといつも、トラップが登録されてもよい。ディストリビュータへの読み込みはトラップされなくてもよいが、任意のゲストＯＳから許可される。ディストリビュータへの書き込みアクセスはトラップされ、ディストリビュータはアクセスが許可されるべきかどうかを分析する。

例示的な実施形態では、システムは、完全なハードウェア仮想化を提供する。各ゲストがその専用周辺機器に直接アクセスできるのでＩ／Ｏアクセス用のパラ仮想化ドライバの必要性が無い。個々のドメインに割り当てられないメモリの一部が、ハイパーバイザコード及びカーネルイメージ用に保持され得る。このメモリ場所は、どのゲストＯＳによってもアクセスすることができない。カーネルイメージは、ボート処理中にバックアップイメージとしてこのメモリにロードされる。ハイパーバイザ４０２は、個々のＯＳをリブートするためにリセット時にトラップされてもよい。

個々のゲストＯＳのクラッシュの場合に、このプロパティはシステムの残りが機能することを有利に可能にしつつ、クラッシュしたＯＳが他のＯＳに影響を与えずにリブートできる。例示的な実施形態では、メタデータは非セキュアドメインからセキュアドメインへ許可されない。例えば、図４を参照すると、メタデータの転送は、クラウドドメイン４１４から高信頼性ドメイン４０８へ許可されない。セキュアゲスト（即ち、高信頼性ドメイン）のインターフェースアクセス（例えば、リモートプロシージャコール）は許可されない。

図７を次に参照すると、例示的な実施形態によって、共通ディスプレイシステムにおける表示出力を促進するためのシステムコンポーネントが例示されている。図７に示されているように、ネイティブＨＭＩドメイン４１２は、グラフィックス及びコンポジタコンポーネント４５０を含む。グラフィックス及びコンポジタコンポーネント４５０は、一般に、他のドメイン（例えば、４０８、４１０、４１４）によってそれに提供される及び／又はそれ自身によって（即ち、ネイティブＨＭＩドメイン４１２で）生成されるフレームバッファ情報（即ち、グラフィックスデータ）を結合するように機能する。このデータのフローは図７で強調されている。ネイティブＨＭＩドメイン４１２はフレームバッファ（「ＦＢ」）ビデオモジュール４５２を含むように示されているが、他のドメインは各々がフレームバッファクライアントモジュール（即ち、ＦＢクライアント４５４、４５６、４５８）を含んでいる。

例示的な実施形態では、ハイパーバイザ４０２は、共有メモリ及び割り込みの形態で異なる仮想マシン（ゲストＯＳ）間で効率的な通信を可能にする仮想装置を提供する。ＦＢクライアントモジュール４５４、４５６、４５８及びＦＢビデオモジュール４５２は、ハイパーバイザ４０２によって提供される仮想装置用のＬｉｎｕｘ（又はＱＮＸ）カーネルモジュールであってもよく、それによりゲストＯＳのユーザ空間に機能を露出させる。例示的な実施形態では、メモリ領域への生アクセスを提供する代わりに、モジュール４５２−４５８は、Ｌｉｎｕｘフレームバッファ、Ｖｉｄｅｏ ｆｏｒ Ｌｉｎｕｘ ２、ｅｖｄｅｖ、ＡＬＳＡ、及びネットワークインターフェース等の僅かに高いレベルのＡＰＩを実装する。これは、Ａｎｄｒｏｉｄのユーザ空間等の既存のユーザ空間ソフトウェアが修正無しで使用され得るという利点を有する。

例示的な実施形態では、ハイパーバイザ４０２によって提供される仮想装置はメモリマッピングされるＩ／Ｏを使用する。ハイパーバイザ４０２は、デバイスツリーからの情報を使用してメモリ領域を初期化することができる。装置は、ＩＲＱ信号及び信号への確認を使用して、仮想マシン間割り込みをそれぞれ確認することができる。これは、ハイパーバイザ４０２によってトラップされるレジスタ領域に書き込むことにより達成され得る。１６Ｍの共有メモリ、割り込み及びドアベルを有する仮想装置用のデバイスツリーエントリの例が以下に示されている。一部の実施形態では、ドアベルレジスタへの書き込みはターゲット仮想マシンにおける割り込みをトリガする。
mosx-example@f1000000 {
compatible = “mosx-example”, “ivmc”;
reg = <0xf0100000 0x1000>,
<0xf1000000 0x1000000>;
interrupts = <0 145 4>;
doorbells = <144>;
};

各ドメインは、ディスプレイ及び入力装置を表す１つ又は複数のカーネルモジュールを利用してもよい。ドメイン４０８、４１０、４１４に対して、１つ又は複数のモジュールは、仮想フレームバッファ（例えば、ＦＢクライアント４５４、４５６、４５８）及び仮想入力装置（例えば、イベント入力４６０、４６２、４６４）を提供する。コンポジタドメイン（例えば、ドメイン４１２）に対して、仮想ビデオ入力４５２及び仮想イベント出力装置４６８を提供するために１つ又は複数のカーネルモジュールが存在する。メモリはドメインごとにイベントバッファ及びフレームバッファに専用である。フレームバッファ用のピクセルフォーマットは、任意の様々な異なるフォーマット（例えば、ＡＲＧＢ３２、ＲＧＢＡ、ＢＧＲＡ）であってもよい。例えば、入力イベントが共有メモリ領域のページに記憶されている信号に対してモジュール間で割り込みが使用されてもよい。割り込みを受信すると、受信ドメインで実行中の仮想装置は、共有メモリから入力イベントを取得して、それを処理するためにユーザ空間に提供してもよい。

ビデオ側では、ＦＢクライアントによってバッファページが投入されてもよく、ユーザ空間がページを満たすと、信号ＩＲＱがコンポジタに提供され得る。次に、コンポジタは、共有メモリからページを取得して、それを新しいフレームを待っている任意のユーザ空間処理に提供する。このようにして、ネイティブＨＭＩドメイン４１２は、グラフィックスのためのサーバとして、且つ入力処理のためのクライアントとして機能し得る。入力（例えば、タッチスクリーン入力、ボタン入力等）は、ネイティブＨＭＩドメイン４１２のイベント出力４６８によって適切な入力イベント４６０、４６２、４６４に提供される。フレームバッファはドメイン４０８、４１０、４１４によって満たされて、ＦＢクライアント４５４、４５６、４５８はフレームバッファビデオ４５２を使用してネイティブＨＭＩドメインにフレームバッファコンテンツを提供する。

イベント及びフレームバッファコンテンツの両方が、共有メモリを使用してドメインからドメインへと渡される。従って、各ゲストオペレーティングシステム又はドメインは、自身のグラフィカルコンテンツを作成し（例えば、音楽プレーヤアプリケーションはそのビデオ出力を作成する）、このグラフィカルコンテンツは、結合されたグラフィックス表示出力上の適切な位置において様々なドメインからの様々なグラフィックスコンテンツを配置するためにコンポジタに提供される。クラスタディスプレイ４２６を参照すると、例えば、高信頼性ドメイン４０８上のアプリケーションは、ディスプレイ４２６上の空間Ａにグラフィックスを生成してもよい。このようなグラフィックスコンテンツは、ＦＢクライアント４５４へ、そして共有メモリ４２４を介してＦＢビデオ４５２へと提供されてもよい。

インフォテイメントドメインからのグラフィックスコンテンツは、そのドメインで実行中のアプリケーションによって生成され得る。ドメインは、ＦＢクライアント４５６にこのような情報を投入して、共有メモリ４２４を介してＦＢビデオ４５２にフレームバッファコンテンツを提供し得る。ドメイン４０８及び４１０からのフレームバッファコンテンツによって、コンポジタは、クラスタディスプレイ４２６上に結合されたシーンの表示を引き起こすことができる。このようなグラフィカル表示は、ユーザ空間からユーザ空間へコード又はメタデータを渡さずに有利に発生する。グラフィックス及びイベント情報の伝達は、割り込みベースのＯＳ間通信を介して行われてもよい。有利に、各コア／ＯＳは、非対称マルチプロセッシングを使用して通常通りに動作してもよい。ハイパーバイザ４０２は、コア又はＯＳスケジューリングを行わなくてもよい。高レベルのセキュリティ、分離及び移植性を提供する非パラ仮想化が存在する。

また、各ドメインによって使用される仮想ネットワークインターフェースも提供され得る。ＯＳユーザ空間に対して、それは名前及びＭＡＣアドレス（デバイスツリーで構成可能である）を有する通常のネットワークインターフェースとして見える。共有メモリは、仮想ネットワークインターフェース用のヘッダページ及び２つのバッファを含んでもよい。第１のバッファは、第１のゲスト用の受信バッファとして、及び第２のゲスト用の送信バッファとして機能し得る。第２のバッファは、逆の役割で（第１のゲスト用の送信バッファとして、及び第２のゲスト用の受信バッファとして）使用される。ヘッダは、対応するバッファの内側の有効データ領域の開始及び終了オフセットを指定し得る。有効データ領域は、一連のパケットを含み得る。新しいパケットがバッファに書き込まれたことを受信側ゲストに示すために、単一の割り込みが使用されてもよい。より詳細には、送信ドメインがパケットサイズを書き込み、その後に共有メモリにおける送信バッファへのパケットデータが続く。着信側では、割り込みが着信パケットの存在を示す。システムによって受信されるパケットは読み取られて、受信側ドメインによりゲストＯＳのネットワークサブシステムに転送される。ドメインの１つが、実際のハードウェアコンポーネントによる受信を制御することができる。仮想サウンドカードがシステムに存在し得る。再生及びキャプチャバッファが、図７を参照して記載されたクライアント／サーバフレームバッファにより提供されたものと同様に動作し得る。

次に図８を参照すると、例示的な実施形態によるマルチコア処理環境４００内で実行される様々な動作モジュールが示されている。動作モジュールは、車両内のディスプレイ装置で表示するためのアプリケーション画像（例えば、グラフィックス出力）を生成するために使用される。アプリケーション画像はフレームバッファコンテンツを含んでもよい。動作モジュールは、メモリに記憶されて、マルチコア処理環境４００のコンピュータコンポーネント及び／又はハードウェアコンポーネントにより実行されるコンピュータコードであってもよい。動作モジュールは、ハードウェアコンポーネントであり又はハードウェアコンポーネントを含んでもよい。一部の実施形態では、図８に示された動作モジュールは、マルチコア処理環境４００の単一コアで実装される。例えば、図４に示されたネイティブＨＭＩドメイン４１２が、ここで検討される動作モジュールを含んでもよい。他の実施形態では、本明細書で検討される動作モジュールは、他のドメインで及び／又は複数のドメインで実行及び／又は記憶されてもよい。

一部の実施形態では、マルチコア処理環境４００は、システム構成モジュール３４１を含む。システム構成モジュール３４１は、システム構成に関連する情報を記憶してもよい。例えば、システム構成モジュール３４１は、接続ディスプレイの数、接続ディスプレイのタイプ、ユーザ設定（例えば、お気に入りのアプリケーション、好みのアプリケーション場所等）、デフォルト値（例えば、アプリケーションのデフォルト表示場所）等の情報を含んでもよい。

一部の実施形態では、マルチコア処理環境４００は、アプリケーションデータベースモジュール３４３を含む。アプリケーションデータベースモジュール３４３は、マルチコア処理環境４００にロードされる及び／又は実行される各アプリケーションに関連する情報を含んでもよい。例えば、アプリケーションデータベースモジュール３４３は、特定のアプリケーションに関連する表示情報（例えば、アイテム／ディスプレイ構成、色、相互作用可能要素、関連画像及び／又はビデオ等）、デフォルト又は設定情報（例えば、「ホワイトリスト」又は「ブラックリスト」情報、デフォルト表示場所、お気に入りの状態等）等を含んでもよい。

一部の実施形態では、マルチコア処理環境４００は、オペレーティングシステムモジュール３４５を含む。オペレーティングシステムモジュール３４５は、マルチコア処理環境４００で実行される１つ以上のオペレーティングシステムに関連する情報を含んでもよい。例えば、オペレーティングシステムモジュール３４５は、実行可能コード、カーネル、メモリ、モード情報、割り込み情報、プログラム実行命令、デバイスドライバ、ユーザインターフェースシェル等を含んでもよい。一部の実施形態では、オペレーティングシステムモジュール３４５は、マルチコア処理環境４００の他の全てのモジュールを管理するために使用されてもよい。

一部の実施形態では、マルチコア処理環境４００は、１つ以上のプレゼンテーションコントローラモジュール３４７を含む。プレゼンテーションコントローラモジュール３４７は、１つ以上のコンポーネントモジュール３４９と１つ以上のアプリケーションモジュール３５１との間の通信リンクを提供してもよい。プレゼンテーションコントローラモジュール３４７は、コンポーネントモジュール３４９とアプリケーションモジュール３５１との間の入力及び／又は出力を処理してもよい。例えば、プレゼンテーションコントローラ３４７は、コンポーネントモジュール３４９から適切なアプリケーションへと情報をルーティングしてもよい。同様に、プレゼンテーションコントローラ３４７は、アプリケーションモジュール３５１から適切なコンポーネントモジュール３４９へと出力命令をルーティングしてもよい。一部の実施形態では、プレゼンテーションコントローラモジュール３４７は、データをルーティングする前にマルチコア処理環境４００がデータを前処理することを許可してもよい。例えば、プレゼンテーションコントローラ３４７は、アプリケーションモジュール３５１又はコンポーネントモジュール３４９のどれかにより処理され得る形態に情報を変換してもよい。

一部の実施形態では、コンポーネントモジュール３４９は、マルチコア処理環境４００に接続されるコンポーネント（例えば、携帯電話、ＤＶＤドライブ等の娯楽装置、アンプ、信号チューナ等）に関連する入力及び／又は出力を処理する。例えば、コンポーネントモジュール３４９は、コンポーネントから入力を受信するための命令を提供してもよい。コンポーネントモジュール３４９は、コンポーネント及び／又は処理入力から入力を受信してもよい。例えば、コンポーネントモジュール３４９は、入力を命令に変換してもよい。同様に、コンポーネントモジュール３４９は、出力命令をコンポーネント用の出力又は出力コマンドに変換してもよい。他の実施形態では、コンポーネントモジュール３４９は、上記のタスクを行うために使用される情報を記憶する。コンポーネントモジュール３４９は、プレゼンテーションコントローラモジュール３４７によりアクセスされてもよい。次に、プレゼンテーションコントローラモジュール３４７は、アプリケーションモジュール３５１及び／又はコンポーネントとインターフェース接続してもよい。

アプリケーションモジュール３５１はアプリケーションを実行してもよい。アプリケーションモジュール３５１は、プレゼンテーションコントローラ３４７、ウィンドウマネージャ３５５、レイアウトマネージャ３５７、及び／又はユーザ入力マネージャ３５９から入力を受信してもよい。また、アプリケーションモジュール３５１は、プレゼンテーションコントローラ３４７、ウィンドウマネージャ３５５、レイアウトマネージャ３５７、及び／又はユーザ入力マネージャ３５９に情報を出力してもよい。アプリケーションモジュール３５１は、入力に基づいて計算を行って、出力を生成する。次に、出力は異なるモジュールに送信される。アプリケーションの例は、天気情報を取得してそれをユーザに表示する天気情報アプリケーション、携帯装置から通知を取得してユーザに表示する通知アプリケーション、他の入力装置を使用してユーザが携帯装置を制御することを可能にする携帯装置インターフェースアプリケーション、ゲーム、カレンダ、ビデオプレーヤ、音楽ストリーミングアプリケーションを含む。一部の実施形態では、アプリケーションモジュール３５１は、計算、処理、入力、及び／又は出力により引き起こされるイベントを処理する。アプリケーションモジュール３５１は、ユーザ入力を処理し、及び／又はそれに応じて表示される画像（例えば、レンダリング面３５３）を更新してもよい。アプリケーションモジュール３５１は、アプリケーションを終了する、アプリケーション等を立ち上げる等の他の動作を処理してもよい。

アプリケーションモジュール３５１は、１つ以上のレンダリング面３５３を生成してもよい。レンダリング面は、ユーザに表示される情報である。一部の実施形態では、レンダリング面３５３は、ディスプレイ上に位置する仮想動作フィールドを介してアプリケーションの表示を可能にする情報を含む。例えば、レンダリング面３５３は、表示される要素のレイアウト、表示される値、表示されるラベル、表示されるフィールド、色、形状等を含む。他の実施形態では、レンダリング面３５３は、ユーザに表示される画像内に含まれる情報のみを含んでもよい。例えば、レンダリング面３５３は、値、ラベル及び／又はフィールドを含み得るが、レイアウト（例えば、情報の位置、色、サイズ等）は、他のモジュール（例えば、レイアウトマネージャ３５７、ウィンドウマネージャ３５５等）によって決定されてもよい。

一部の実施形態では、アプリケーションモジュール３５１は異なるドメインに位置している。例えば、アプリケーションモジュール３５１はインフォテイメントドメイン４１０に位置し得るが、別のアプリケーションモジュールはクラウドドメイン４１４に位置してもよい。異なるドメイン上のアプリケーションモジュール３５１は、共有メモリ４２４を使用して他のドメイン上のモジュールに情報及び／又は命令を渡してもよい。レンダリング面３５３は、アプリケーションモジュール３５１からネイティブＨＭＩドメイン４１２にフレームバッファとして渡されてもよい。また、異なるドメイン上のアプリケーションモジュール３５１は、共有メモリ４２４を介して情報及び／又は命令を受信してもよい。例えば、ユーザ入力は、共有メモリ４２４にイベント出力としてネイティブＨＭＩドメイン４１２から渡されてもよく、異なるドメイン上のアプリケーションモジュール３５１は共有メモリ４２４からイベント入力としてユーザ入力を受信してもよい。

ウィンドウマネージャ３５５は、１つ以上のディスプレイ３４７における情報の表示を管理する。一部の実施形態では、ウィンドウマネージャ３５５は、他のモジュールから入力を受け取る。例えば、ウィンドウマネージャ３５５は、レイアウトマネージャ３５７及びアプリケーションモジュール３５１（例えば、レンダリング面３５３）からの入力を使用して、ディスプレイ３４７に表示するための画像を作成してもよい。ウィンドウマネージャ３５５は、表示情報を適切なディスプレイ３４７にルーティングしてもよい。レイアウトマネージャ３５７からの入力は、システム構成モジュール３４１、アプリケーションデータベースモジュール３４３からの情報、ユーザ入力マネージャ３５９からの表示レイアウトを変更するためのユーザ入力命令、レイアウトヒューリスティックによる単一ディスプレイ３４７上のアプリケーション表示のレイアウト、又はディスプレイ３４７に関係付けられる仮想動作フィールドを管理するためのルール等を含んでもよい。同様に、ウィンドウマネージャ３５５は、入力を処理して、他のモジュールにルーティングしてもよい（例えば、命令を出力する）。例えば、ウィンドウマネージャ３５５は、ユーザ入力を受信して、適切なクライアント又はアプリケーションモジュール３５１にリダイレクトしてもよい。一部の実施形態では、ウィンドウマネージャ３５５は、Ｘ、Ｙ、又はＺオーダーに基づいて異なるクライアント又はアプリケーション面（例えば、表示画像）を作成し得る。ウィンドウマネージャ３５５は、ユーザ入力を介してユーザにより制御されてもよい。ウィンドウマネージャ３５５は、シェル（例えば、Ｗａｙｌａｎｄ ｓｈｅｌｌ）を介してクライアント又はアプリケーションと通信してもよい。例えば、ウィンドウマネージャ３５５は、Ｘ−Ｓｅｒｖｅｒウィンドウマネージャ、Ｗｉｎｄｏｗｓウィンドウマネージャ、Ｗａｙｌａｎｄウィンドウマネージャ、Ｗａｙｌａｎｄサーバ等であってもよい。

レイアウトマネージャ３５７は、１つ以上のディスプレイ３４７上に表示されるアプリケーションのレイアウトを生成する。レイアウトマネージャ３５７は、アプリケーションデータのレイアウトを生成するのに使用されるシステム構成情報を取得してもよい。例えば、レイアウトマネージャ３５７は、ディスプレイ３４７の解像度及び場所を含むディスプレイ３４７の数、システム内のウィンドウマネージャの数、モニタのスクリーンレイアウトスキーム（ｂｉｎｉｎｇ）、車両状態等のシステム構成情報を取得してもよい。一部の実施形態では、システム構成情報は、システム構成モジュール３４１からレイアウトマネージャ３５７によって取得されてもよい。

また、レイアウトマネージャ３５７は、アプリケーションデータのレイアウトを生成するのに使用されるアプリケーション情報を取得してもよい。例えば、レイアウトマネージャ３５７は、どのアプリケーションがどのディスプレイ３４７（例えば、ＨＵＤ、ＣＩＤ、ＩＣＤ等）に表示されることができるか、各アプリケーションによってサポートされるディスプレイ解像度、アプリケーション状態（例えば、どのアプリケーションが実行中であり又はアクティブであるか）、トラックシステム及び／又は非システムアプリケーション（例えば、タスクバー、設定メニュー、エンジニアリングスクリーン等）等のアプリケーション情報を取得してもよい。

一部の実施形態では、レイアウトマネージャ３５７は、アプリケーションデータベースモジュール３４３からアプリケーション情報を取得してもよい。更なる実施形態では、レイアウトマネージャ３５７は、アプリケーションモジュール３５１からアプリケーション情報を取得してもよい。また、レイアウトマネージャ３５７は、ユーザ入力情報を受信してもよい。例えば、ユーザ入力から生じる情報及び／又は命令は、ユーザ入力マネージャ３５９からレイアウトマネージャ３５７に送信されてもよい。例えば、ユーザ入力は、あるディスプレイ３４７から別のディスプレイ３４７へアプリケーションを移動させ、アプリケーション画像をサイズ変更し、追加のアプリケーションアイテムを表示し、アプリケーションを終了する命令等を生じてもよい。レイアウトマネージャ３５７は、ユーザ入力に完全に又は部分的に基づいて新しい表示レイアウトを生成するように命令を実行し及び／又は情報を処理してもよい。

レイアウトマネージャ３５７は、１つ以上のディスプレイに表示されるアプリケーションデータ（例えば、レンダリング面３５３）用のレイアウトを決定するために上記の情報又は他の情報を使用してもよい。多くのレイアウトが可能である。レイアウトマネージャ３５７は、本明細書に記載のレイアウトを生成するために様々な技術を使用してもよい。こうした技術は、例えば、サイズ最適化、アプリケーションの優先順位付け、ユーザ入力への応答、ルール、ヒューリスティック、レイアウトデータベース等を含んでもよい。

レイアウトマネージャ３５７は、他のモジュールに情報を出力してもよい。一部の実施形態では、レイアウトマネージャ３５７は、アプリケーション情報及び／又はアイテムを所定の設定（例えば、所定のサイズ、所定のディスプレイ３４７、所定の表示場所（例えば、仮想動作フィールド）等でレンダリングするためにアプリケーションモジュール３５１に命令及び／又はデータを送信する。例えば、レイアウトマネージャ３５７は、レイアウトマネージャ３５７によって取得された情報及び／又は命令に基づいてレンダリング面３５３を生成するようにアプリケーションモジュール３５１に命令してもよい。

一部の実施形態では、レンダリング面３５３又は他のアプリケーションデータは、レイアウトマネージャ３５７に戻されてもよく、これは次にウィンドウマネージャ３５５にそれを転送してもよい。例えば、アプリケーション及び／又は仮想動作フィールドの方向、アプリケーション及び／又は仮想動作フィールドのサイズ、アプリケーション及び／又は仮想動作フィールドをどのディスプレイ３４７に表示すべきか等の情報が、レイアウトマネージャ３５７によってウィンドウマネージャ３５５に渡されてもよい。他の実施形態では、レイアウトマネージャ３５７からの命令に応答してアプリケーションモジュール３５１によって生成されるレンダリング面３５３又は他のアプリケーションデータが、ウィンドウマネージャ３５５に直接送信されてもよい。更なる実施形態では、レイアウトマネージャ３５７は、ユーザ入力マネージャ３５９に情報を伝達してもよい。例えば、レイアウトマネージャ３５７は、所定のユーザ入力を防ぐためにインターロック情報を提供してもよい。

マルチコア処理環境４００は、ユーザ入力３６１を受信してもよい。ユーザ入力３６１は、タッチスクリーン入力（例えば、プレス、スワイプ、ジェスチャ等）、ハードキー入力（例えば、ボタンを押すこと、ノブを回すこと、スイッチをアクティブ化すること等）、音声コマンド等のユーザ入力に応じたものであってもよい。一部の実施形態では、ユーザ入力３６１は入力信号又は命令であってもよい。例えば、入力ハードウェア及び／又は中間制御ハードウェア及び／又はソフトウェアがユーザ入力を処理して、マルチコア処理環境４００に情報を送信してもよい。他の実施形態では、マルチコア処理環境４００は、車両インターフェースシステム３０１からユーザ入力３６１を受信する。更なる実施形態では、マルチコア処理環境４００は、直接ユーザ入力（例えば、電圧の変化、測定キャパシタンス、測定抵抗等）を受信する。マルチコア処理環境４００は、直接ユーザ入力を処理し又は他のやり方で取り扱ってもよい。例えば、ユーザ入力マネージャ３５９及び／又は追加のモジュールが直接ユーザ入力を処理してもよい。

ユーザ入力マネージャ３５９はユーザ入力３６１を受信する。ユーザ入力マネージャ３５９はユーザ入力３６１を処理してもよい。例えば、ユーザ入力マネージャ３５９は、ユーザ入力３６１を受信して、ユーザ入力３６１に基づいて命令を生成してもよい。例えば、ユーザ入力マネージャ３５９は、ＣＩＤディスプレイ上のキャパシタンスの変化から成るユーザ入力３６１を処理し、ＣＩＤディスプレイ上の左から右のスワイプに対応する入力命令を生成してもよい。また、ユーザ入力マネージャは、ユーザ入力３６１に対応する情報を決定してもよい。例えば、ユーザ入力マネージャ３５９は、どのアプリケーションモジュール３５１がユーザ入力３６１に対応するかを決定してもよい。ユーザ入力マネージャ３５９は、レイアウトマネージャ３５７から受信したアプリケーションレイアウト情報及びユーザ入力３６１、ウィンドウマネージャ３５５からのウィンドウ情報、及び／又はアプリケーションモジュール３５１から受信したアプリケーション情報に基づいてこの決定を行ってもよい。

ユーザ入力マネージャ３５９は、ユーザ入力３６１に対応する情報及び／又は命令を出力してもよい。情報及び／又は命令は、レイアウトマネージャ３５７に出力されてもよい。例えば、あるディスプレイ３４７から別のディスプレイ３４７へとアプリケーションを移動させるための命令が、対応するディスプレイ３４７に対して更新されたレンダリング面３５３を生成するようにアプリケーションモジュール３５１を命令するレイアウトマネージャ３５７に送信されてもよい。他の実施形態では、情報及び／又は命令は、ウィンドウマネージャ３５５に出力されてもよい。例えば、情報及び／又は命令はウィンドウマネージャ３５５に出力されてもよく、これは次に情報及び／又は命令を１つ以上のアプリケーションモジュール３５１に転送してもよい。更なる実施形態では、ユーザ入力マネージャ３５９は、情報及び／又は命令をアプリケーションモジュール３５１に直接出力する。

一部の実施形態では、システム構成モジュール３４１、アプリケーションデータベースモジュール３４３、レイアウトマネージャ３５７、ウィンドウマネージャ３５５、及びユーザ入力マネージャ３５９が、ネイティブＨＭＩドメイン４１２に位置してもよい。上記の機能は、異なるドメインに位置するモジュールと通信するために共有メモリ４２４を使用して実行されてもよい。例えば、ユーザ入力は、ネイティブＨＭＩドメイン４１２に位置するユーザ入力マネージャ３５９によって受信されてもよい。入力は、イベントとして共有メモリ４２４を介して別のドメイン（例えば、インフォテイメントドメイン４１０）に位置するアプリケーションに渡されてもよい。入力を受信するアプリケーションモジュール３５１は、新しいレンダリング面３５３を生成してもよい。レンダリング面３５３は、共有メモリ４２４を使用してフレームバッファクライアントとしてネイティブＨＭＩドメイン４１２に位置するレイアウトマネージャ２３７及び／又はウィンドウマネージャ３５５に渡されてもよい。レイアウトマネージャ３５７及び／又はウィンドウマネージャ３５５は、次に、ディスプレイ３４７を使用して情報を表示してもよい。上記は単なる例示である。ドメイン間で命令及び／又は情報を渡すために共有メモリ４２４を使用してモジュール及びドメインの多数の構成が可能である。

レンダリング面３５３及び／又はアプリケーション情報は、１つ以上のディスプレイ３４７に表示されてもよい。ディスプレイ３４７は、ＩＣＤ、ＣＩＤ、ＨＵＤ、後部座席ディスプレイ等であってもよい。一部の実施形態では、ディスプレイ３４７は、統合型入力装置を含んでもよい。例えば、ＣＩＤディスプレイ３４７は容量性タッチスクリーンであってもよい。１つ以上のディスプレイ３４７がディスプレイシステム（例えば、拡張デスクトップ）を形成してもよい。ディスプレイシステムのディスプレイ３４７は、マルチコア処理環境４００の１つ又は複数のモジュールにより調整されてもよい。例えば、レイアウトマネージャ３５７及び／又はウィンドウマネージャ３５５は、どのアプリケーションがディスプレイシステムのどのディスプレイ３４７に表示されるかを決定してもよい。同様に、１つ以上のモジュールが、複数のディスプレイ３４７間での相互作用を調整してもよい。例えば、マルチコア処理環境４００は、あるディスプレイ３４７から別のディスプレイ３４７へのアプリケーションの移動を調整してもよい。

次に図９Ａを参照すると、例示的な実施形態による、ＧＰＵ共有のための例示的な実施形態による９００及び方法を示すフロー図が示されている。システム９００は、複数のドメイン９０１−９１１（即ち、インフォテイメントドメイン９０１、ドライバ情報ドメイン９０３、アンドロイドドメイン９０５、ＡＤＡＳドメイン９０７、クラウドドメイン９０９、及びＨＵＤドメイン９１１）を含むように示されている。様々な実施形態では、システム９００は、例示のドメイン９０１−９１１又は上記の任意の他のタイプのドメインの任意の組み合わせを含んでもよい。各ドメイン９０１−９１１は、ＧＰＵによって実行されるタスクを有する様々なアプリケーション（例えば、インフォテイメント、ナビゲーション、ＦＢビュー、ＨＵＤソフトウェア等）を含んでもよい。有利に、様々なアプリケーションによって提供されるタスクを実行するために単一のＧＰＵ９１３が使用されてもよい。他の実施形態では、様々なアプリケーションによって提供されるタスクを実行するために複数のＧＰＵが使用されてもよい。

一部の実施形態では、アプリケーションは、タスクをプロキシ（例えば、図示のＯｐｅｎＧＬプロキシ）に渡す（ステップ１）。例えば、インフォテイメントドメイン９０１、アンドロイドドメイン９０３、ドライバ情報ドメイン９０５、ＡＤＡＳドメイン９０７、及びクラウドドメイン９０９は、各々がドメインに関係付けられるＯｐｅｎＧＬプロキシにタスクを渡すように示されている。タスクがＨＵＤ関連ソフトウェアによって生成されるとき、ＨＵＤドメイン９１１はソフトウェアＯｐｅｎＧＬドライバにタスクを渡してもよい。

図９Ａを更に参照すると、システム９００は、高信頼性レンダリングコア９１５（例えば、Ｌｉｎｕｘレンダリングコア）及びクラウドソフトウェアレンダリングコア９１７を含むように示されている。レンダリングコア９１５−９１７は、複数のリモートプロシージャコール（ＲＰＣ）エンドポイント（例えば、インフォテイメントＲＰＣエンドポイント、ドライバ情報ＲＰＣエンドポイント、アンドロイドＲＰＣエンドポイント、ＡＤＡＳ ＲＰＣエンドポイント等）を含んでもよい。各ＲＰＣエンドポイントは、特定のドメインに対するタスクを管理するように構成されてもよい。

一部の実施形態では、各ＲＰＣエンドポイントは、対応するドメイン９０１−９０９のプロキシからタスクを受信する（ステップ２）。例えば、各ＲＰＣエンドポイントは、特定のドメイン又はその特定のアプリケーション用に指定されてもよい。タスクは、ドメイン９０１−９０９から受信されて、ＲＰＣエンドポイントにより検索されるように共有メモリに記憶されてもよい。例示的な実施形態では、クラウドドメイン９０９のアプリケーションは車両により直接的に関係付けられる他のアプリケーションとは異なって構成され得るので、クラウドドメイン９０９は異なるソフトウェアレンダリングコア９１７を有してもよい。

ＲＰＣエンドポイントは、様々なアプリケーションからＯｐｅｎＧＬドライバにタスクを伝達してもよい（ステップ３）。一部のＲＰＣエンドポイントは高信頼性レンダリングコア９１５のＯｐｅｎＧＬドライバ９１９ドライバにタスクを伝達するように示されているが、他のＲＰＣエンドポイントはクラウドソフトウェアレンダリングコア９１７内のソフトウェアＯｐｅｎＧＬドライバ９２１にタスクを伝達するように示されている。ＯｐｅｎＧＬドライバ９１９は、処理のためＧＰＵ９１３に提供されるタスクを管理するように構成されてもよい。図９Ａに示されているように、ソフトウェアＯｐｅｎＧＬドライバ９２１で受信されたタスクは、クラウドドメイン９０９からのタスクであってもよい。クラウドドメイン９０９から受信されたタスクは、このようなタスクがＧＰＵ９１３による更なる処理無しでディスプレイ上にレンダリングされ得るので、処理のためにＧＰＵに提供される必要が無くてもよい。

図９Ａを更に参照すると、ＯｐｅｎＧＬドライバ９１９からのタスクは、カーネルドライバのスケジューラ（例えば、ＴｉｍｅＧｒａｐｈスケジューラ）に提供されてもよい（ステップ４）。スケジューラは、ＯｐｅｎＧＬドライバ９１９からのどのタスクをＧＰＵ９１３に送信すべきか及び／又はタスクを送信する順番を決定するように構成されてもよい。一部の実施形態では、スケジューラは、車両セーフティ及び／又はクリティカル車両動作に関するタスクを優先順位付けする。タスクスケジューリング処理は、後続の図面により詳細に記載されている。スケジューラは処理のためにＧＰＵ９１３にタスクを提供し（ステップ５）、ＧＰＵ９１３はタスクを処理する（例えば、タスクに関する車両のディスプレイ用の表示構成を決定すること）。

ＧＰＵ９１３がタスクを処理した後で、タスクは、タスクに関係付けられるドメインに対するフレームバッファ９２３に提供される（ステップ６）。一部の実施形態では、一連のタスクが組み合わされて同時にフレームバッファ９２３に提供される。個別の単一のタスクはＧＰＵ９１３内の状態を変化させてもよく、十分な数のタスクがフレームバッファを生成するために処理されている場合にフレームバッファに提供されてもよい。ＧＰＵ９１３は、表示されるドメイン又はタスクの、様々なコンポーネント、及びその構成を識別することによりタスクを処理してもよい。言い換えれば、フレームバッファ９２３は、表示される各ドメイン又はタスクの「部品」を記憶するように構成されてもよい。例えば、ナビゲーションタスクについて、インフォテイメントドメインに関してフレームバッファ９２３に記憶される様々なコンポーネントは、マップ表示及び構成、アイコン、テキスト等に関してもよい。天気タスクは、雲り及び晴れ等の天気のグラフィカルシンボル及びテキスト等の様々なコンポーネントを含んでもよい。またステップ６では、高信頼性レンダリングコア９１５から離れて既に処理されているソフトウェアベースタスクが、特定のドメインに対して指定される共有メモリフレームバッファ９２５に送信されてもよい。フレームバッファ９２３と同様に、共有メモリフレームバッファ９２５は、タスクの様々なコンポーネント（例えば、「部品」）を受信してもよい。

図９Ａを更に参照すると、フレームバッファ９２３及び共有メモリフレームバッファ９２５は、処理されたタスク及び情報をコンポジタ９２７に提供してもよい（ステップ７）。コンポジタ９２７は、フレームバッファ９２３及び９２５から受信された様々なコンポーネントを組み立ててもよい。コンポジタ９２７は、ディスプレイに関する適切な構成を決定するように構成されてもよい。例えば、コンポジタ９２７は、どのディスプレイにタスクが示されるべきか、ディスプレイの寸法、ディスプレイ内の様々なアイコン及びテキストの構成、特定のコンポーネントを表示するべきかどうか等を決定してもよい。コンポジタ９２７は、高い重要度を有するタスクがＨＵＤディスプレイに表示されるべきであり、低い重要度を有するタスクがＣＩＤディスプレイに表示されるべきであること等を決定してもよい。別の例として、コンポジタ９２７は、コンポーネント（例えば、ビデオ）が表示されるべき又は表示されるべきではないかどうかを決定してもよい。コンポジタ９２７は、アイコン、テキスト、又はディスプレイの他のコンポーネントをサイズ変更し、（例えば、複数のディスプレイで、同じディスプレイで）タスクを再配置してもよい。コンポジタ９２７は、様々なコンポーネントを組み立てて、組み立て済みタスクにしてもよい。

コンポジタ９２７は、ＯｐｅｎＧＬドライバ９１９に組み立て済みタスクを提供してもよい（ステップ８）。タスクに関する構成を決定した後で、コンポジタ９２７は、ＧＰＵ及びディスプレイによる後続の処理のためにタスクをＯｐｅｎＧＬドライバ９１９に提供してもよい。組み立て済みタスクはスケジューラに渡されてもよく（ステップ９）、スケジューラは処理のために組み立て済みタスクをＧＰＵ９１３に渡してもよい（ステップ１０）。ＧＰＵ９１３は、タスクに関する表示を生成するために組み立て済みタスクを処理してもよい。例えば、複数のフレームバッファが結合されて単一のフレームバッファにされてもよい。組み立て済みタスクがＧＰＵ９１３により処理された後で、ＧＰＵ９１３は、タスクが表示される特定のディスプレイに関するフレームバッファ（例えば、ディスプレイフレームバッファ１、ディスプレイフレームバッファ２等）にタスクを渡してもよい（ステップ１１）。フレームバッファは、車両での表示のために選択されたディスプレイのディスプレイ装置にタスクを渡してもよい（ステップ１２）。

図９Ｂを次に参照すると、例示的な実施形態による、ＧＰＵ共有システム９００をより詳細に示すブロック図が示されている。システム９００は、様々なＣＰＵコンポーネント９０２−９１６及びＧＰＵコンポーネント９１８−９４２を含むように示されている。

ＣＰＵコンポーネント９０２−９１６は、複数のアプリケーション９０２を含むように示されている。アプリケーション９０２は、上記のドメインからもたらされてもよい。ＣＰＵコンポーネントは、ＯｐｅｎＧＬプロキシ９０４及びＥＧＬプロキシ９０６を更に含んでもよい。プロキシ９０４、９０６は、アプリケーション９０２とＧＰＵとの間で様々なタスクに関する中間体として機能するように構成されてもよい。ＣＰＵコンポーネントは、クライアント認証ブロック９０８、ランタイムＡＰＩセキュリティ９１０、及びＧＰＵリセットリカバリプロキシ９１２を更に含んでもよい。クライアント認証ブロック９０８は、ドメインの様々なアプリケーション９０２により提供されるタスクを認証するように構成されてもよい。ランタイムＡＰＩセキュリティ９１０は、（図１４で詳細に記載される）車両のディスプレイと様々なドメインとの間の互換性を確実にするように構成されてもよい。一部の実施形態では、ランタイムＡＰＩセキュリティ９１０は、ＯｐｅｎＧＬコマンド及びシェーダーのセーフティを確認するために使用される。ＧＰＵリセットリカバリプロキシ９１２は、ＧＰＵがリセットされ又は問題に遭遇する場合にアプリケーション９０２とＧＰＵとの間の中間体として機能するように構成されてもよい。

ＣＰＵコンポーネント９０２−９１６は通信レイヤ９１４を含むように示され、ＧＰＵコンポーネント９１８−９４２は通信レイヤ９１８を含むように示されている。通信レイヤ９１４及び９１８は、ＴＣＰ／ＩＰ又はＵＤＰ等のインターネットプロトコルを使用して及び／又は共有メモリと通信するように構成されてもよい。通信レイヤ９１４、９１８は、メモリ９１６に記憶されたタスクを送信及び受信するために共有メモリ９１６と通信するように構成されてもよい。

ＧＰＵコンポーネント９１８−９４２は、認証マネージャ９２０を含むように示されている。認証マネージャ９２０は、クライアント認証９０８により決定される認証情報を受信して、処理されるタスクを検証するために情報を使用してもよい。ＧＰＵコンポーネント９１８−９４２は、ＲＰＣエンドポイント９２２を更に含むように示されている。ＲＰＣエンドポイント９２２は、図８を参照して記載されるように、特定のドメインに関するタスクを管理するように構成されてもよい。

ＧＰＵコンポーネント９１８−９４２は、ＧＰＵリソースを管理するように構成されるリソースマネージャ９２４を含むように示されている。リソースマネージャ９２４は、ＧＰＵドメインにおけるアプリケーションによるメモリの割り当てを追跡及び許可してもよい。リソースマネージャ９２４は、図１１−１３により詳細に記載されている。ＧＰＵコンポーネント９１８−９４２は、ＧＰＵがリセットされる場合に、ＧＰＵ、ＯｐｅｎＧＬドライバ、及びアプリケーションの挙動を管理するように構成されるリセットリカバリマネージャ９２６を更に含んでもよい。

ＧＰＵコンポーネント９１８−９４２は、ＯｐｅｎＧＬドライバ９２８及びＥＧＬドライバ９３０を更に含んでもよい。ドライバ９２８、９３０は、ＧＰＵに関するバッファ管理活動（例えば、タスクを受信すること）を管理してもよい。言い換えれば、ドライバ９２８、９３０は、様々なドメインとＧＰＵとの間の通信を管理する。一部の実施形態では、ＯｐｅｎＧＬプロキシ９０４及びＯｐｅｎＧＬドライバ９２８は、Ｗａｙｌａｎｄプロキシ及びＷａｙｌａｎｄエンドポイントを実装する。ＥＧＬドライバ９３０は、例えば、Ｗａｙｌａｎｄ ＥＧＬドライバであってもよい。

ＧＰＵコンポーネント９１８−９４２は、ＧＰＵスケジューラ９３２を更に含んでもよい。ＧＰＵスケジューラ９３２は、ＧＰＵのためのスケジュールを管理する（例えば、どのタスクを次に処理するかを決定する）ように構成されてもよい。ＧＰＵスケジューラ９３２は、図１２により詳細に記載されている。ＧＰＵコンポーネント９１８−９４２は、ＧＰＵ性能（例えば、図１４により詳細に記載されるＧＰＵストール）を監視するように構成されるＧＰＵウォッチドッグを更に含んでもよい。ＧＰＵコンポーネント９１８−９４２は、（図１２でより詳細に記載される）処理されるタスクを保持するため及び処理される次のタスクを選択するためのキューを記憶するように構成されるカーネルドライバ９３６を含むように更に示されている。ＧＰＵコンポーネント９１８−９４２は、図８に記載されたコンポジタ９３８、ロガー９４０及び構成マネージャ９４２を更に含んでもよい。ロガー９４０は、一般に、レンダリングコアにより使用されるＧＰＵ活動をログするように構成されてもよい。

次に図１０を参照すると、例示的な実施形態による、車両ディスプレイ上でグラフィックスをレンダリングするためのＧＰＵスケジューリング処理１０００が示されている。処理１０００は、高優先度タスク及び低優先度タスクを含むように示されている。こうしたタスクは、一般的には、車両ディスプレイにおいてレンダリングする表示を表す。例えば、高優先度タスクは、リアルタイム又は近リアルタイムで更新しなければならないナビゲーションディスプレイ、警告ディスプレイ、車両の現在速度を表示するディスプレイ等に関してもよい。低優先度タスクは、娯楽関連ディスプレイ（例えば、ラジオディスプレイ、ビデオ再生ディスプレイ、電話ディスプレイ、天気ディスプレイ等）に関してもよい。高優先度タスクは、一般に、車両の運転者にクリティカルである又は必要不可欠であると考えられるアプリケーションに関連し、低優先度タスクは、一般に、車内の娯楽機能を提供するアプリケーションに関連してもよい。

処理１０００において、ＣＰＵ１０１０は、レンダリングのための複数の高優先度タスク１００２、１００４、１００７及び低優先度タスク１００３、１００５、１００６を有してもよい。ＣＰＵ１０１０は、ＧＰＵドライバ（例えば、ドライバ１００９）からのＧＰＵコマンド（例えば、コマンド１００８）を介して、タスクが生成されるとレンダリングのためのタスクをＧＰＵ１０１２に提供してもよい。ＧＰＵドライバ１００９は、一実施形態では、ＯｐｅｎＧＬドライバであってもよい。処理１０００では、ＧＰＵ１０１２は、タスクが到着する順番で各タスクを実行する。結果として、第２の高優先度タスク１００４は、第１の低優先度タスク１００３が処理される間、処理されるのを待たなければならないように示されている。高優先度タスクは、一般に、実行されて車両ディスプレイにレンダリングされることを所定期間の間ブロックされる。これは、高優先度タスクが時間内にレンダリングされない可能性があるという問題を引きおこし得る（例えば、リアルタイムでナビゲーションマップを更新しない、車両警告を時間内に更新しない等）。

次に図１１を参照すると、例示的な実施形態による、別のＧＰＵスケジューラ処理１１００が示されている。処理１１００は、タイルベース型ＧＰＵスケジューリング処理を示す。処理１１００では、ＧＰＵは、ＣＰＵからタスクを受信してもよく、ディスプレイでレンダリングするための各タスクの各タイルを処理してもよい。ＧＰＵは、複数のＧＰＵコアを介して（例えば、先の図面に示された４つのコアの間で）タイルを並列に処理し且つレンダリングしてもよい。

処理１１００は、複数の生成されたタスクを有するＣＰＵ１１０２を含む。例えば、ＣＰＵ１１０２は、低優先度タスク（例えば、天気表示１１１０）及び高優先度タスク（例えば、ナビゲーション表示１１１２）を実行していてもよい。ＣＰＵ１１０２は、最初に低優先度タスクを生成して、天気表示１１１０の一部をＧＰＵドライバを介してＧＰＵ１１０４に渡すように示されている。簡潔のため、図１１は、レンダリングのためにＧＰＵ１１０４に渡される表示１１１０、１１１２の一部のみを示している。しかしながら、処理１１００は２つの表示の全体及び／又は追加の表示のために実行されてもよいことが理解されるべきである。様々な実施形態では、ＣＰＵ１１０２及び／又はＧＰＵ１１０４は、ＧＰＵ１１０４が各タイルを個別に処理及びレンダリングし得るように各タスクを複数のタイルに分割してもよい。

ＧＰＵ１１０４は、天気表示１１００の各タイルの処理及びレンダリングを開始する。その間に、ＣＰＵ１１０２は、高優先度タスクの生成を開始し、終了すると、ナビゲーション表示１１１２の一部をＧＰＵ１１０４に渡してもよい。ナビゲーション表示１１１２は、表示が天気表示１１１０に対して優先されるべきであることをＧＰＵ１１０４に示す優先度レベルとともに渡される。優先度レベルは、各タスクがディスプレイにどのように表示されるかに関連してもよい。例えば、あるタスクはリアルタイムで更新しなければならない一方で、他のタスクは断続的な更新を要求するのみであり、又はあるタスクのコンテンツは別のタスクのコンテンツよりも重要であってもよい。優先度レベル割り当ては、例えば、ＥＧＬ＿ＩＭＧ＿Ｃｏｎｔｅｘｔ＿ｐｒｉｏｒｉｔｙ等のＥＧＬ拡張により行われてもよい。

ＧＰＵ１１０４は、低優先度タスクの第４のタイルを処理している間、高優先度タスクを受信するように示されている。ＧＰＵ１１０４は低優先度タスクの第４のタイルの処理を終了すると、高優先度タスクの処理を開始するために低優先度タスクの処理を中断してもよい。高優先度タスクの処理が終了すると、ＧＰＵ１１０４は低優先度タスクの処理を再開してもよい。図示のように、ＧＰＵ１１０４は、タイルベース型スケジューリング処理を実行することにより、タイルを個別に処理する。ＧＰＵ１１０４は、その当然の結果として低優先度タスクからのタイルに対して高優先度タスクからのタイルを優先する。ＧＰＵ１１０４は、各受信タスクに対して各タイルの優先度を管理するための組み込みスケジューラを有してもよい。

次に図１２−１３を参照すると、別の例示的なＧＰＵスケジューラ処理１２００が示されている。処理１２００では、イベント駆動型スケジューリング処理が、ＧＰＵをＣＰＵと同期させる。ＧＰＵがアイドル状態にある場合、最も高い優先度を有するタスクがＧＰＵに送られてもよい。ＧＰＵがタスクをアクティブに処理している場合、将来のタスクのキューが、ＧＰＵに送信するために形成されてもよい。ＧＰＵがタスクの処理を終了すると、割り込みがキューに送られてもよく、これは処理のためにキューからタスクをＧＰＵスケジューラに検索させる。

図１２に示されているように、複数のアプリケーション１２０１−１２０３が、処理のためにＧＰＵに提供する１つ以上のタスクを有してもよい。アプリケーション１２０１は低優先度アプリケーションとして示され、アプリケーション１２０２は通常優先度アプリケーションとして示され、アプリケーション１２０３は高優先度アプリケーションとして示されている。アプリケーション１２０１−１２０３により生成されるタスクは、高優先度タスク１２０４及び低優先度タスク１２０６の組み合わせとして示されている。図１２の実施形態は２つのタスクの優先度レベルのみを示しているが、任意の数の優先度レベルが処理１２００に組み込まれてもよいことが理解されるべきである（例えば、クリティカル、高、並、通常、低、超低等）。

処理１２００では、コマンドキュー１２１０が、カーネル空間ドライバ１２０８に形成されてもよい。キュー１２１０は、将来ＧＰＵ１２２０によって処理されるタスクを含む。ＧＰＵ１２２０がタスクの処理を終了すると、ＧＰＵは、ＧＰＵ１２２０が次のタスクの準備が整っていることを示す割り込み１２１２をＧＰＵスケジューラ１２２２に送信してもよい。ＧＰＵスケジューラ１２２２は、コマンドキュー１２１０にアクセスして、どのタスクがＧＰＵ１２２０に提供されるべきかを決定してもよい。決定は、各タスクの優先度レベル、各タスクのキューにおける場所、又は他の関連情報を使用して行われてもよい。ＧＰＵスケジューラ１２２２は、ＧＰＵ１２２０に提供するために選択されたタスクをＧＰＵインターフェース１２２４に提供する。ＧＰＵインターフェース１２２４は、例えば、円形又はリングバッファであってもよい。

図１３をより詳細に参照すると、処理１３００が示されている。処理１３００は、処理１２００のより詳細なバージョンであってもよい。処理１３００は、高優先度タスク１３０２、１３０３のペア、及び低優先度タスク１３０４を示している。ＣＰＵ１３１０は、ＧＰＵドライバ１３０６を介して第１の高優先度タスク１３０２を提供し、ＧＰＵ１３１２がタスクを処理する。ＧＰＵ１３１２がタスク１３０２を処理するのにビジーである間、ＣＰＵ１３１０は将来の処理のためにタスク１３０３、１３０４を生成し続けてもよい。ＧＰＵドライバ１３０６によってタスク１３０３、１３０４がキュー１３１４に提供される。ＧＰＵ１３１２がタスク１３０２の処理を終了すると、ＧＰＵ１３１２は割り込み１３１６をＣＰＵ１３１０に送信する。割り込みに応答して、ＣＰＵ１３１０は、キュー１３１４において最高優先度のタスクをＧＰＵ１３１２に提供してもよい。ＧＰＵ１３１２は、次に、キュー１３１４から最大優先度を有するタスク（例えば、タスク１３０４）を受信して、このタスクを最初に処理してもよい。次に、ＧＰＵ１３１２は、高優先度タスク（例えば、タスク１３０４）を処理して、低優先度タスク（例えば、タスク１３０３）が後に続く。タスクの処理の間、ＧＰＵ１３１２は、どのタスクが次に処理されるべきかをＧＰＵスケジューラ（例えば、ＧＰＵスケジューラ１２２２）が決定する「オーバヘッド」時間を有するように示されている。

ＧＰＵスケジューラ１２２２は、どのタスクが次に処理されるべきかを決定するために、タスク優先度レベルに追加して様々な情報を組み込んでもよい。例えば、ＧＰＵスケジューラ１２２２は、スケジュールが車内の各アプリケーションに対して所定量のＧＰＵ時間及びリソースを予約することを可能にする予約機能を含んでもよい。別の例として、ＧＰＵスケジューラ１２２２は、ＧＰＵ実行時間を更に推定及びログしてもよく、タスクの推定実行時間に基づいてＧＰＵにタスクを分配してもよい。

図１４を次に参照すると、例示的な実施形態による、グラフィックスセーフティ及びセキュリティシステム１４００のブロック図が示されている。システム１４００の特徴は、図１１−１３に記載されたようにグラフィックススケジューリングの処理にセキュリティ機能を提供してもよい。システム１４００は、ＧＰＵ１４０１、ＧＰＵ１４０１にタスクを提供する複数のアプリケーション１４０２、ＧＰＵドライバ１４０４（図１４ではＯｐｅｎＧＬとして示されている）、及び上記のＧＰＵスケジューラ１４１０を含む。システム１４００は、（図１４でＧＬ＿ＥＸＴ＿ｒｏｂｕｓｔｎｅｓｓと示されている）ロバスト性拡張１４０６を含むように示されている。拡張１４０６は、ＧＰＵによる各タスクの処理における異常を確認するために使用されてもよい。例えば、拡張１４０６は、セーフメモリコピー動作を確認し、ＧＰＵがリセットされたこと、又はそうではないことを検出してもよい。

システム１４００は、ランタイムＡＰＩセキュリティチェック１４０８を含むように更に示されている。ランタイムＡＰＩセキュリティチェック１４０８は、ＧＰＵドライバ１４０４出力を確認するように構成されてもよい。例えば、チェック１４０８はシェーダーを有効にし、又はバグ若しくは事故を回避するためにシェーダーを修正してもよく、タイミングを制限し、又はタスクがＧＰＵ１４００に送信される前にＧＰＵドライバ１４０４により出力されるタスクを確認及び修正してもよい。ランタイムＡＰＩセキュリティチェックの１つの例示の実装は、ＡＮＧＬＥ（Ａｌｍｏｓｔ Ｎａｔｉｖｅ Ｇｒａｐｈｉｃｓ Ｌａｙｅｒ Ｅｎｇｉｎｅ）である。ＡＮＧＬＥは、ＯｐｅｎＧＬ ＥＳ ２．０ ＡＰＩコールをＤｉｒｅｃｔＸ９又はＤｉｒｅｃｔＸ１１のＡＰＩコールに変換するように構成されてもよい。言い換えれば、ＡＮＧＬＥは、様々なユーザインターフェース（例えば、本開示のディスプレイ）がＯｐｅｎＧＬドライバに依存しなくてもコンテンツを実行できるようにする。ＡＮＧＬＥの使用は、ＯｐｅｎＧＬドライバ用のグラフィックスコマンドが他のグラフィックスコマンド（例えば、本開示のディスプレイで実装され得るＷｅｂＧＬグラフィックスコマンド）と互換性を有していない実装において有利であってもよい。しかしながら、他の実装では様々な他のランタイムＡＰＩセキュリティチェックが使用され得ることを理解されたい。

システム１４００は、ＧＰＵ実行時間を監視するためにＧＰＵウォッチドッグ１４１２を更に含むように示されている。ＧＰＵウォッチドッグ１４１２は、ＧＰＵがスタック又はブロックされた場合にＧＰＵリセット１４１４をトリガしてもよい。ＧＰＵウォッチドッグ１４１２は、ＧＰＵ実行時間及び処理される将来のタスクをスケジューリングするのに使用される他のＧＰＵ情報をＧＰＵスケジューラ１４１０に提供してもよい。

様々な例示的な実施形態に示されたシステム及び方法の構造及び配置は単なる例示である。本開示には少数の実施形態のみが詳細に記載されているが、多くの修正（例えば、サイズ、寸法、構造、形状及び様々な要素の比率、パラメータの値、取り付け配置、材料の使用、色、方向の変更）が可能である。例えば、要素の配置は反転され又は他のやり方で変更されてもよく、個々の要素の性質又は数又は位置が変更又は変形されてもよい。従って、このような全ての修正が、本開示の範囲内に含まれることが意図される。任意の処理又は方法のステップの順番又は順序が、代替的な実施形態に従って変更され又は再順序付けされてもよい。他の置換、修正、変更及び省略が、本開示の範囲から逸脱することなく、例示的な実施形態の設計、動作条件及び配置で行われてもよい。

本開示は、様々な動作を遂行するための任意の機械可読媒体上のプログラム製品、システム及び方法を考慮している。本開示の実施形態は、既存のコンピュータプロセッサを使用して、又はこの若しくは別の目的で組み込まれる、適切なシステムのための専用コンピュータプロセッサによって、又は配線システムによって実装されてもよい。本開示の範囲内の実施形態は、機械実行可能命令又はそれに記憶されるデータ構造を伝送する又は有する機械可読媒体を含むプログラム製品を含む。このような機械可読媒体は、汎用又は専用コンピュータ又はプロセッサを有する他の機械によりアクセスされ得る任意の利用可能な媒体であってもよい。例えば、このような機械可読媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光学ディスク記憶装置、磁気ディスク記憶装置又は他の磁気記憶装置、又は機械実行可能命令又はデータ構造の形態で所望のプログラムコードを伝送又は記憶するために使用され得る且つ汎用又は専用コンピュータ又はプロセッサを有する他の機械によりアクセスされ得る任意の他の媒体を含んでもよい。情報が機械とのネットワーク又は別の通信接続（有線、無線、又は有線若しくは無線の組み合わせ）を介して伝送又は提供される場合、機械は適切に接続を機械可読媒体と見なす。従って、任意のこのような接続は、適切に機械可読媒体と呼ばれる。上記の組み合わせも、機械可読媒体の範囲内に含まれる。例えば、機械実行可能命令は、汎用コンピュータ、専用コンピュータ、又は専用処理機械に所定の機能若しくは機能グループを実行させる命令及びデータを含む。

図面は方法ステップの特定の順番を示しているが、ステップの順番は描かれたものと異なっていてもよい。また、２つ以上のステップが同時に又は部分的に同時に行われてもよい。このような変形は、選択されたソフトウェア及びハードウェアシステムに及び設計者の選択に依存するであろう。このような全ての変形は、本開示の範囲内である。同様に、ソフトウェアの実装は、様々な接続ステップ、処理ステップ、比較ステップ及び決定ステップを遂行するためのルールベース論理及び他の論理を有する標準プログラミング技術によって達成され得る。

Claims (20)

1. グラフィックス処理装置と、
   車両アプリケーションを実行して、前記グラフィックス処理装置に対するタスクを生成するように構成される複数の処理ドメインと、
   前記処理ドメインにより生成された前記タスクを受信して、前記グラフィックス処理装置に前記タスクを送信する順番を決定するように構成されるタスクスケジューラを含むレンダリングコアであって、前記グラフィックス処理装置は前記タスクスケジューラにより決定された前記順番で前記タスクを処理し且つ前記タスクに基づいて表示データを生成するレンダリングコアと、
   前記グラフィックス処理装置により生成された前記表示データを受信して、前記表示データをユーザに提示するように構成される電子ディスプレイと
   を備える、車両インターフェースシステム。
2. 前記タスクスケジューラは、前記タスクの各々に関係付けられる優先度レベルを識別し、識別された優先度レベルに基づいて前記グラフィックス処理装置に前記タスクを送信する順番を決定する、請求項１に記載の車両インターフェースシステム。
3. タスクに関係付けられる優先度レベルを識別することは、
   前記複数の処理ドメインの中のどれが前記タスクを生成したかを識別すること、
   識別された処理ドメインに関係付けられる優先度レベルを識別すること、及び
   前記識別された処理ドメインに関係付けられる前記優先度レベルに従って前記タスクに優先度レベルを割り当てること
   を含む、請求項２に記載の車両インターフェースシステム。
4. 前記複数の処理ドメインは、
   車両クリティカルアプリケーションを実行して、前記グラフィックス処理装置に対する高優先度タスクを生成するように構成される高信頼性ドメイン、及び
   低優先度車両アプリケーションを実行して、前記グラフィックス処理装置に対する低優先度タスクを生成するように構成される低信頼性ドメイン
   を含む、請求項１に記載の車両インターフェースシステム。
5. 前記レンダリングコアは、第１のセットの処理ドメインにより生成される第１のセットのタスクを受信及び管理して、前記第１のセットのタスクを前記スケジューラに提供するように構成される第１のアプリケーションプログラムインターフェースを含む、請求項１に記載の車両インターフェースシステム。
6. 前記タスクスケジューラは、
   前記アプリケーションプログラムインターフェースにおいて受信された前記タスクの各々に関係付けられる優先度レベルを識別し、
   タスクを処理するように要求する割り込みを前記グラフィックス処理装置から受信し、且つ
   前記割り込みの受信に応じて、前記グラフィックス処理装置に最高の識別された優先度レベルを有するタスクを送信する
   ように構成される、請求項５に記載の車両インターフェースシステム。
7. 第２のセットの処理ドメインにより生成される第２のセットのタスクを受信および管理するように構成される第２のアプリケーションプログラムインターフェースを更に備え、前記第２のセットの処理ドメインは前記第１のセットの処理ドメインには無い１つ以上の処理ドメインを含む、請求項５に記載の車両インターフェースシステム。
8. 前記レンダリングコアは複数のリモートプロシージャコールエンドポイントを含み、前記リモートプロシージャコールエンドポイントの各々は、前記複数の処理ドメインの１つに対して指定され、且つ指定された処理ドメインにより生成されるタスクを管理するように構成される、請求項１に記載の車両インターフェースシステム。
9. 前記グラフィックス処理装置は、表示される各タスクの部品を識別して、識別された部品をフレームバッファに記憶するように構成される、請求項１に記載の車両インターフェースシステム。
10. 前記レンダリングコアは複数のフレームバッファを含み、前記フレームバッファの各々は、前記複数の処理ドメインの１つに対して指定され、且つ表示されるタスクの部品として前記グラフィックス処理装置により識別される各タスクの部品を記憶するように構成される、請求項１に記載の車両インターフェースシステム。
11. 前記レンダリングコアは、前記複数のフレームバッファから前記タスクの識別された部品を受信して、前記識別された部品を組み立てることにより表示タスクを生成するように構成されるコンポジタを含む、請求項１０に記載の車両インターフェースシステム。
12. 前記グラフィックス処理装置は、前記タスクスケジューラから組み立て済みタスクを受信して、前記組み立て済みタスクに基づいて前記表示データを生成する、請求項１１に記載の車両インターフェースシステム。
13. グラフィックス処理装置と、
    高優先度車両アプリケーションを実行して、前記グラフィックス処理装置に対する高優先度タスクを生成するように構成される第１の処理コア、及び低優先度車両アプリケーションを実行して、前記グラフィックス処理装置に対する低優先度タスクを生成するように構成される第２の処理コアを備えるマルチコアプロセッサと、
    前記処理コアの各々により生成されるタスクを受信および管理するように構成されるグラフィックス処理装置ドライバと、
    前記グラフィックス処理装置ドライバで受信された前記タスクの各々に関係付けられる優先度レベルを識別して、識別された優先度レベルに基づいて前記グラフィックス処理装置に前記タスクを送信する順番を決定するように構成されるタスクスケジューラであって、前記グラフィックス処理装置は前記タスクスケジューラにより決定された前記順番で前記タスクを処理し且つ前記タスクに基づいて表示データを生成するタスクスケジューラと、
    前記グラフィックス処理装置により生成された前記表示データを受信して、前記表示データをユーザに提示するように構成される電子ディスプレイと
    を備える、車両インターフェースシステム。
14. 前記タスクスケジューラは、
    タスクを処理するように要求する割り込みを前記グラフィックス処理装置から受信し、
    前記グラフィックス処理装置ドライバで受信された前記タスクのどれが最高の識別された優先度レベルを有するかを決定し、且つ
    前記割り込みの受信に応じて、前記グラフィックス処理装置に前記最高の識別された優先度レベルを有するタスクを送信する
    ように構成される、請求項１３に記載の車両インターフェースシステム。
15. タスクに関係付けられる優先度レベルを識別することは、
    前記複数の処理コアの中のどれが前記タスクを生成したかを識別すること、
    識別された処理コアに関係付けられる優先度レベルを識別すること、及び
    前記識別された処理コアに関係付けられる前記優先度レベルに従って前記タスクに優先度レベルを割り当てること
    を含む、請求項１３に記載の車両インターフェースシステム。
16. 前記高優先度タスクは、前記車両のセーフティ及びクリティカル車両動作の少なくとも１つに関連する車両アプリケーションにより生成される、請求項１３に記載の車両インターフェースシステム。
17. 前記低優先度タスクは、車両インフォテイメントアプリケーション、クラウドアプリケーション、及び自立ドライバ支援システムアプリケーションの少なくとも１つにより生成される、請求項１３に記載の車両インターフェースシステム。
18. 車両インターフェースシステムにおいてユーザインターフェースを生成するための方法であって、
    マルチコアプロセッサの第１のコアにより、第１の処理ドメインにおいて高優先度車両アプリケーションを実行するステップであって、前記高優先度車両アプリケーションは高優先度タスクを生成するステップと、
    前記マルチコアプロセッサの第２のコアにより、第２の処理ドメインにおいて低優先度車両アプリケーションを実行するステップであって、前記低優先度車両アプリケーションは低優先度タスクを生成するステップと、
    タスクスケジューラにより、生成されたタスクの各々に関係付けられる優先度レベルを識別するステップと、
    前記タスクスケジューラにより、識別された優先度レベルに基づいてグラフィックス処理装置に前記タスクを送信する順番を決定するステップと、
    前記グラフィックス処理装置により、前記タスクスケジューラにより決定された前記順番で前記タスクを処理するステップであって、前記グラフィックス処理装置は前記タスクに基づいて表示データを生成するステップと、
    前記車両インターフェースシステムの電子ディスプレイを介して前記グラフィックス処理装置により生成された前記表示データを提示するステップと
    を含む、方法。
19. タスクに関係付けられる優先度レベルを識別するステップは、
    前記複数の処理ドメインの中のどれが前記タスクを生成したかを識別すること、
    識別された処理ドメインに関係付けられる優先度レベルを識別すること、及び
    前記識別された処理ドメインに関係付けられる前記優先度レベルに従って前記タスクに優先度レベルを割り当てること
    を含む、請求項１８に記載の方法。
20. 前記グラフィックス処理装置に前記タスクを送信する前記順番を決定するステップは、
    タスクを処理するように要求する割り込みを前記グラフィックス処理装置から受信すること、
    生成されたタスクの中のどれが最高の識別された優先度レベルを有するかを決定すること、及び
    前記割り込みの受信に応じて、前記グラフィックス処理装置に前記最高の識別された優先度レベルを有するタスクを送信すること
    を含む、請求項１８に記載の方法。
    

Images