JP2017507401A - 複数のユーザインターフェース動作ドメインを有する車両 - 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