JP2023543957A - 車両の仮想化構造に基づくシステムの制御方法および装置｛ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｃｏｎｔｒｏｌｌｉｎｇ ｖｉｒｔｕａｌｉｚｅｄ ｖｅｈｉｃｌｅ ｓｔｒｕｃｔｕｒｅ－ｂａｓｅｄ ｓｙｓｔｅｍ｝ - Google Patents

Abstract

実施例は、複数のコンテナを起動するステップ；前記複数のコンテナのアップグレードの必要性を確認するステップ；および前記アップグレードの必要性に応じて前記複数のコンテナに対するアップグレードを行うステップ；を含み、前記複数のコンテナは、システムの初期化および管理を共有する、車両の仮想化構造に基づく制御方法を開示する。

Description

本発明は、車両の仮想化構造に基づくシステムの制御方法および装置に関する。

車両は、より高いレベルのコンピューター化に向かって徐々に進んでいる。
ほとんどの車両に対するタスク、機能および作業は、現在コンピューター制御下にあるか、コンピュータデバイスでモニタリングすることができる。
言い換えると、デジタル時代の到来により、消費者は、携帯電話とタブレットコンピュータとの間のようなタスクを車両内でも行うことができる。
例えば、タッチおよび触覚フィードバック、自然言語音声対話、近接感知およびボタンやコントロールを備えたインテリジェントなユーザインターフェースを有する車両用インフォテインメントシステムが、現在脚光を浴びている。
これによって、車両内の情報、通信ナビゲーション、およびエンターテイメントを簡素化し、ドライブユースに合わせて調整している。

このような技術状況に応じて、車両内には、複数の表示装置が存在し、表示装置を実行するソフトウェアも複数存在する。
また、車両内におけるユーザまたは搭乗者の複数の表示装置に対する使用の自由度が向上している。

ただし、車両内でオペレーティングシステム間のアップデートが困難であり、ウェブプラットフォームコンテナの使用がユーザ毎に独立していないという限界がある。

さらに、車両内でユーザらの音が混じり合い、走行の危険度が増加するという問題点がある。

実施例は、ディスクリソースの節約が可能な車両の仮想化構造に基づくシステムの制御方法および装置を提供することができる。

また、駆動速度が向上した車両の仮想化構造に基づくシステムの制御方法および装置を提供することができる。

また、車両内のユーザにカスタマイズされた車両の仮想化構造に基づくシステムの制御方法および装置を提供することができる。

また、車両内のユーザ毎にウェブアプリケーションを容易に使用可能な車両の仮想化構造に基づくシステムの制御方法および装置を提供することができる。

また、走行妨害が除去された車両内音響処理が行われる車両の仮想化構造に基づくシステムの制御方法および装置を提供することができる。

実施例で解決しようとする課題はこれらに限定されるのではなく、下記で説明する課題の解決手段または実施形態から把握できる目的および効果も含まれると言える。

実施例による車両の仮想化構造に基づく制御方法は、複数のコンテナを起動するステップ；前記複数のコンテナのアップグレードの必要性を確認するステップ；および前記アップグレードの必要性に応じて前記複数のコンテナに対するアップグレードを行うステップ；を含み、前記複数のコンテナは、システムの初期化および管理を共有する。

前記複数のコンテナのアップグレードの必要性を確認するステップは、アップグレード情報を受信するステップ；前記アップグレード情報と前記複数のコンテナのアップグレードとを比較するステップ；および前記アップグレードの必要性を決定するステップ；を含んでもよい。

前記アップグレードの必要性がない場合に前記複数のコンテナを駆動するステップ；をさらに含んでもよい。

前記アップグレードの必要性が存在する場合に、システムディレクトリに対するアップグレードであるか、またはユーザデータ（ｐｅｒｓｏｎａｌ ｄａｔａ）に対するアップグレードであるかを判断するステップ；をさらに含んでもよい。

前記システムディレクトリに対するアップグレードの場合、アップグレードであるかを判断するステップの後にユーザ認証を行うステップ；および前記システムディレクトリを受信するステップ；をさらに含んでもよい。

前記複数のコンテナを再起動するステップ；をさらに含み、前記アップグレードの必要性を確認するステップに戻ってもい。

前記ユーザデータに対するアップグレードの場合、アップグレードであるかを判断するステップの後に、最新のユーザデータを受信するステップ；および前記複数のコンテナを駆動するステップ；をさらに含んでもよい。

前記複数のコンテナを駆動するステップの後に、前記コンテナに接続されたディスプレイでアプリケーションを実行するステップ；をさらに含んでもよい。

前記複数のコンテナを駆動するステップで、前記ユーザデータのうち変更ディレクトリコピーして前記複数のコンテナを駆動してもよい。

前記共有されたシステムの初期化および管理は、カーネル（ｋｅｒｎｅｌ）、ディストロ（ｄｉｓｔｒｏ）、およびライブラリ（ｌｉｂｒａｒｙ）を含んでもよい。

さらに、実施例による車両の仮想化構造に基づく制御方法は、上述のアップデートなどの後にコンテナを駆動するにあたって、ユーザを認識するステップ；認識されたユーザが登録済みのユーザであるかを確認するステップ；を含む。

認識されたユーザが前記登録済みのユーザではない場合に登録を進行するステップ；をさらに含んでもよい。

認識されたユーザが前記登録済みのユーザである場合に車両の環境を設定するステップ；ウェブアカウントの登録有無を確認するステップ；をさらに含んでもよい。

前記ウェブアカウントの登録がない場合にウェブアカウントを登録するステップ；をさらに含んでもよい。

前記ウェブアカウントの登録がある場合に、前記ウェブアカウントが他のウェブプラットフォームコンテナにログインされた状況であるかを判断するステップ；をさらに含んでもよい。

前記ウェブアカウントが他のウェブプラットフォームコンテナにログインされた場合に終了または再ログインを出力するステップ；をさらに含んでもよい。

前記ウェブアカウントが他のウェブプラットフォームコンテナにログインされていない場合に優先アプリケーションを抽出するステップ；；をさらに含んでもよい。

ナビゲーションを駆動してお気に入りの目的地を表示するステップ；をさらに含んでもよい。

実施例による車両の仮想化構造に基づくサウンド制御方法は、第１サウンドクライアントからの第１サウンド出力情報、および第２サウンドクライアントからの第２サウンド出力情報のうち少なくとも１つを受信するステップ；受信された前記第１サウンド出力情報および前記第２サウンド出力情報に対する優先順位を比較するステップ；および比較結果に応じて第１サウンド出力情報および第２サウンド出力情報のうち少なくとも１つをハードウェアに送信するステップ；を含み、前記第１サウンドクライアントおよび前記第２サウンドクライアントは、互いに異なる仮想エンジン上に搭載される。

前記第１サウンドクライアントは、クラスタオペレーティングシステムに搭載され、前記第２サウンドクライアントは、ＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）オペレーティングシステム、コ－ドライバー（Ｃｏ－Ｄｒｉｖｅｒ）オペレーティングシステム、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）オペレーティングシステムに搭載されてもよい。

前記第１サウンド出力情報の優先順位は、前記第２サウンド出力情報の優先順位より高くてもよい。

前記優先順位を比較するステップの後に、前記第１サウンド出力情報の発生時点が車両の走行中であるか否かを確認するステップ；をさらに含んでもよい。

前記第１サウンド出力情報の発生時点が車両の走行中ではない場合、前記第１サウンド出力情報を出力した後に前記第２サウンド出力情報を出力するステップ；をさらに含んでもよい。

前記第１サウンド出力情報の発生時点が車両の走行中である場合、前記第１サウンド出力情報のレベルによって、前記第１サウンド出力情報および第２サウンド出力情報の出力有無および出力時間を調節して出力するステップ；を含んでもよい。

前記出力情報のレベルは、第１レベル、および前記第１レベルより低い第２レベルを含み、前記第１サウンド出力情報のレベルが第１レベルである場合は前記第１サウンド出力情報のみ出力し、前記第２サウンド出力情報の出力を遮断するステップ；をさらに含んでもよい。

前記第１サウンド出力情報のレベルが第２レベルである場合は、前記第１サウンド出力情報および前記第２サウンド出力情報を第１時間の間出力するステップ；および前記第２サウンド出力情報を第１時間に連続する第２時間の間出力するステップ；を含み、前記第１時間の間における前記第１サウンド出力情報の大きさは、前記第２サウンド出力情報の大きさより大きくてもよい。

前記第２サウンド出力情報のみを受信する場合、前記送信するステップで前記第２サウンド出力情報を前記ハードウェアに送信してもよい。

実施例による車両の仮想化構造に基づくサウンド制御装置は、第１サウンドクライアントからの第１サウンド出力情報および第２サウンドクライアントからの第２サウンド出力情報のうち少なくとも１つを受信する受信部；受信された前記第１サウンド出力情報および前記第２サウンド出力情報に対する優先順位を比較する比較部；および比較結果に応じて第１サウンド出力情報および第２サウンド出力情報のうち少なくとも１つをハードウェアに送信部；を含み、前記第１サウンドクライアントおよび前記第２サウンドクライアントは、互いに異なる仮想エンジン上に搭載される。

実施例によると、ディスクリソースの節約が可能な車両の仮想化構造に基づくシステムの制御方法および装置を具現することができる。

また、駆動速度が向上した車両の仮想化構造に基づくシステムの制御方法および装置を具現することができる。

また、車両内のユーザにカスタマイズされた車両の仮想化構造に基づくシステムの制御方法および装置を具現することができる。

また、車両内のユーザ毎にウェブアプリケーションを容易に使用可能な車両の仮想化構造に基づくシステムの制御方法および装置を具現することができる。

また、走行妨害が除去された車両内音響処理が行われる車両の仮想化構造に基づくシステムの制御方法および装置を具現することができる。

本発明の多様かつ有益な長所および効果は上述の内容に限定されず、本発明の具体的な実施形態を説明する過程でより容易に理解することができるであろう。

図１は、実施例による車両の仮想化構造に基づくシステムの概念図であり、
図２は、実施例による車両の仮想化構造に基づくシステムの具体的なブロック図であり、
図３は、実施例による車両の仮想化構造に基づくシステムの制御方法に対する手順図であり、
図４は、実施例による車両の仮想化構造に基づくシステムの制御方法におけるアップグレードの必要性確認に対する具体的な手順図であり、
図５は、実施例による車両の仮想化構造に基づくシステムの制御方法に対する具体的な手順図であり、
図６は、実施例による車両の仮想化構造に基づくシステムにおける複数のコンテナの構造に対する概念図であり、
図７および図８は、実施例による車両の仮想化構造に基づくシステムにおける複数のコンテナを駆動することを説明する図であり、
図９は、図２におけるＫ部分の拡大図であり、
図１０は、実施例による車両の仮想化構造に基づくシステムにおけるウェブプラットフォーム制御方法に対する手順図であり、
図１１は、実施例による車両の仮想化構造に基づくシステムにおけるウェブプラットフォーム制御方法でウェブアプリケーションの駆動を示す図であり、
図１２は、他の実施例による車両の仮想化構造に基づくシステムの概念図であり、
図１３は、実施例による車両の仮想化構造に基づくシステムにおける表示装置を説明する図であり、
図１４は、実施例による車両の仮想化構造に基づくサウンド制御装置のブロック図であり、
図１５は、実施例による車両の仮想化構造に基づくサウンド制御方法の手順図であり、
図１６は、実施例による車両の仮想化構造に基づくサウンド制御方法の具体化された手順図であり、
図１７は、一例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図であり、
図１８は、他の例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図であり、
図１９は、また他の例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図であり、
図２０は、変形例による車両の仮想化構造に基づくシステムの概念図である。

発明の実施のための形態

本発明は、多様な変更を加えることができ、様々な実施例を有することができるところ、特定の実施例を図面に例示して説明する。
しかし、これは、本発明を特定の実施形態に対して限定しようとするのではなく、本発明の思想および技術範囲に含まれるすべての変更、均等物ないし代替物を含むものであると理解されたい。

第２、第１などのように序数を含む用語は多様な構成要素を説明するために使用できるが、構成要素は、用語によって限定されない。
用語は、ある構成要素を他の構成要素から区別する目的でのみ使用される。
例えば、本発明の権利範囲から逸脱することなく、第２構成要素は第１構成要素と命名されてもよく、同様に第１構成要素も第２構成要素と命名されてもよい。
および／またはという用語は、複数の関連する記載項目の組み合わせ、または、複数の関連する記載項目のうちいずれかを含む。

ある構成要素が他の構成要素に「連結されて」いるか「接続されて」ていると言及された場合は、他の構成要素に直接的に連結または接続されていてもよいが、それらの間にまた他の構成要素が存在してもよいと理解されるべきである。
一方、ある構成要素が他の構成要素に「直接連結されて」いるか「直接接続されて」ていると言及された場合は、それらの間にまた他の構成要素が存在しないものであると理解されるべきである。

本出願で使用した用語は、単に特定の実施例を説明するために使用されたものであり、本発明を限定することを意図していない。
単数の表現は、文脈上明らかに他に意味がない限り、複数の表現を含む。
本出願で、「含む」または「有する」などの用語は、明細書上に記載の特徴、数字、ステップ、動作、構成要素、部品またはこれらを組み合わせたものが存在することを指定しようとするものであり、１つまたはそれ以上の他の特徴や数字、ステップ、動作、構成要素、部品またはこれらを組み合わせたものなどの存在または付加の可能性を予め排除しないものであると理解されたい。

他に定義されない限り、技術的または科学的な用語を含んで本明細書で使用するすべての用語は、本発明が属する技術分野における通常の知識を有する者によって一般に理解されるのと同じ意味を有する。
一般に使用される辞書で定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有すると解釈されるべきであり、本出願で明らかに定義しない限り、理想的または過度に形式的な意味として解釈されない。

以下、添付の図面を参照して実施例を詳しく説明するが、図面符号にかかわらず同一または対応する構成要素には、同一の参照番号を付し、これに対する重複する説明は、省略する。

本開示の実施例は、車両、車両のインフォテインメントなどのための車両ストリーミング制御装置および制御方法に関し、アプリケーション（同じ意味で「アプリ」、「アプリケーション」、ａｐｐｌｉｃａｔｉｏｎ）などを車両で利用するにあたり、車両のインフォテインメントと組み合わせたシステム環境を提供することを内容とする。
ただし、このような内容が本特許の権利を限定するのではない。

より詳しく説明すると、車両用システムの場合、車両用インフォテインメント機能を提供すると共に車両の制御に関連する重要な機能を行っている。
ここで、車両の制御に関連する機能とは、ユーザの車両操作に影響を与えるナビゲーションシステムなどを含むアプリケーションから、車両の速度やＲＰＭなどを表示する計器盤を意味するクラスタシステム、自律制御車両の自律制御システムのように搭乗者の生命に関連する重要な機能までも含む。
また、このようなアプリケーションの表示は、自由に行われるが、車両制御など走行に妨害になってはならない。
すなわち、車両走行に対する保護は、必須に守られなければならない。
このような保護が行われない場合、事故が発生するおそれもある。
よって、本発明の好ましい実施例では、走行を妨害しない範囲内で車両内のストリーミングが行われ、オーディオ再生、ビデオ再生、ゲーム実行などのようなエンターテイメントに関連するサービス、アプリケーションが運転手を含む車両の搭乗者に対する接近および操作が容易に行われ得る。

図１は、実施例による車両の仮想化構造に基づくシステムの概念図であり、図２は、実施例による車両の仮想化構造に基づくシステムの具体的なブロック図である。

図１および図２を参照すると、実施例による車両の仮想化構造に基づくシステムは、ハードウェア（図示せず）、ハードウェア（図示せず）上に搭載されたベースオペレーティングシステム（１０）、ベースオペレーティングシステム（１０）上に搭載された第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）、各仮想エンジン上に搭載される少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）、少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）、オペレーティングシステムプラットフォーム（４０ａないし４０ｆ）で駆動される複数のアプリケーション（５０ａないし５０ｄ）、複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）または複数のアプリケーションなどを出力する複数のディスプレイ（６０ａないし６０ｆ）および仮想エンジン（２０ａないし２０ｂ）上で複数のオペレーティングシステム（３０ａないし３０ｄ）に対する環境を管理するコンテナ管理部（ＣＭ）を含んでもよい。
少なくとも１つのオペレーティングシステムは、以下「コンテナ（ｃｏｎｔａｉｎｅｒ）」として説明する。

ここで、ハードウェア（図示せず）とは、プロセッサ、表示部、保存部、メモリ部、コントロール部、Ｉ／Ｏ装置を含む概念であってもよい。

実施例において、走行部（ＣＰ）は、第１仮想エンジン（２０ａ）上で搭載または駆動されるシステム領域であり、インフォテインメント部（ＩＰ、Ｉｎｆｏｔａｉｎｍｅｎｔ Ｐｌａｔｆｏｒｍ）は、第１仮想エンジン（２０ａ）とは異種の仮想エンジンである第２仮想エンジン（２０ｂ）上で搭載または駆動されるシステム領域であってもよい。
このような構成によって、インフォテインメント部（ＩＰ）内でアップグレードまたはその他誤作動が発生しても、走行部（ＣＰ）がこれに対する影響を受けない。
すなわち、走行中の影響を最小化することができる。
さらに、インフォテインメント部（ＩＰ）以外にウェブプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）がベースオペレーティングシステム（１０）および追加の仮想エンジン（２０）上で搭載または駆動されてもよい。
インフォテインメント部（ＩＰ）と同様にプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、コンテナ管理者をインフォテインメント部（ＩＰ）と共有することができる。
またはプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）の一部で構成されてもよい。
以下では個別の構成として説明する。

プラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）のようにコンテナ管理部に搭載された１つのオペレーティングシステム（例えば、コンテナ、３０）、オペレーティングシステム上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（例えば、ＡＧＬ、４０）、オペレーティングシステムプラットフォーム（４０）で駆動される複数のアプリケーション（例えば、ウェブアプリケーション、５０）を含んでもよい。

まず、ベースオペレーティングシステム（１０）は、多様なオペレーティングシステムであってもよい。
例えば、ベースオペレーティングシステム（１０）は、リナックス（ｌｉｎｕｘ）、ハイパーバイザ（ｈｙｐｅｒｖｉｓｏｒ）、ＱＮＸ、ＧＥＮＩＶＩなどを含んでもよい。

例えば、第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、ミドルウェアソリューションまたは多様なプラットフォームであり、モバイルＣ言語で開発することができる。
第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、複数の内蔵ライブラリを提供でき、多様な移動端末機などで同じ動作を行うこともできる。
例えば、第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、リナックスベースのアンドロイドカーネルであってもよく、メモリ保護、仮想メモリモジュールおよびスケジュールキャッシングを初期化することもできる。

また、少なくとも１つのコンテナ（３０ａないし３０ｄ）は、第２仮想エンジン（２０ａ）上に搭載され、第１仮想エンジン（１０ａ）上に搭載されなくてもよい。
これによって、走行部（ＣＰ）に対するセキュリティ性が向上するので、走行安全性も向上させることができる。

少なくとも１つのコンテナ（３０ａないし３０ｄ）は、実施例で仮想化方式の一形態としてプロセス仮想化の日程であってもよい。
例えば、コンテナを用いた仮想化技術は、ホストＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）の内部を物理的リソースを管理するカーネル空間と、ユーザプロセス、すなわち、応用プログラム（アプリケーション、ａｐｐｌｉｃａｔｉｏｎ、ＡＰＰ）を実行するユーザ空間とに区分し、ユーザ空間を複数に分けてそれぞれのユーザプロセスで使用されるハードウェアリソースを割り当てて共有する技術を意味し得る。
例えば、コンテナ（３０ａないし３０ｄ）は、呼び出されたライブラリをシステムライブラリとインターフェースされるように変換して、ベースオペレーティングシステムと複数のオペレーティングシステムプラットフォームとの間の接続または互換を行ってもよい。

複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）は、コンテナ上に搭載されていてもよい。
複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）は、アンドロイド、ＡＧＬ（Ａｕｔｏｍｏｔｉｖｅ Ｇｒａｄｅ Ｌｉｎｕｘ）、ウェブ（ｗｅｂ）プラットフォーム、クラスタ（ｃｌｕｓｔｅｒ）プラットフォーム、ヘッドアップディスプレイ（ＨＵＤ）プラットフォームなどを含んでもよい。

少なくとも１つのアプリケーション（５０ａないし５０ｄ）は、システムプログラムを除いた応用プログラムとして、車両内ではＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）、コ－ドライバー（Ｃｏ－Ｄｒｉｖｅｒ）、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）などを含んでもよい。

複数のディスプレイ（６０ａないし６０ｆ）は、オペレーティングシステムプラットフォーム（４０ａないし４０ｆ）またはプラットフォーム上の応用プログラムなどをユーザ（例えば、搭乗者）に表示することができる。
例えば、複数のディスプレイ（６０ａないし６０ｆ）は、多様な表示装置（例えば、ＯＬＥＤ）を含んでもよい。

コンテナ管理部（ＣＭ）は、仮想エンジン（２０ａないし２０ｂ）上で複数のオペレーティングシステム（３０ａないし３０ｄ）に対する環境を管理することができる。
すなわち、コンテナ管理部（ＣＭ）は、複数のオペレーティングシステム（３０ａないし３０ｄ）の例として、コンテナに対するリソースの割り当て、ストリーミング接続、アップデート、ディスプレイ出力担当、出力部との接続などを行うことができる。
これについての詳しい説明は、後述する。

具体的に、コンテナ管理部（ＣＭ）は、コンテナ制御部（ＣＭ１）、コンテナアップグレード部（ＣＭ２）、コンテナ状態管理部（ＣＭ３）、ウェブプラットフォームコンテナ管理部（ＣＭ４）、コンテナブリッジ部（ＣＭ５）を含んでもよい。

コンテナ制御部（ＣＭ１）は、コンテナに割り当てられるシステムリソース、リソースポリシー、ストリーミング制御関連、ディスプレイへの出力関連、ファイルシステム管理などを行うことができる。

このようなコンテナ制御部（ＣＭ１）は、コンテナリソース管理部（Ｍ１－１）、ディスプレイ制御部（Ｍ１－２）、コンテナポリシー管理部（Ｍ１－３）、コンテナファイルシステム管理部（Ｍ１－４）、コンテナストリーミング管理部（Ｍ１－５）およびオーディオポリシーおよび制御管理部（Ｍ１－６）を含んでもよい。

コンテナリソース管理部（Ｍ１－１）は、コンテナに割り当てられるシステムリソースを動的に割り当てることができる。
例えば、コンテナリソース管理部（Ｍ１－１）は、リソース使用量を収集することにより、リソース不足によるＱｏＳ性能の低下を予防することができる。
例えば、コンテナリソース管理部（Ｍ１－１）は、予め設定されたコンテナの優先順位、リソース使用量の閾値、およびモニタリング監視周期を用いて専用コアに割り当てられるコンテナを設定することができる。

コンテナポリシー管理部（Ｍ１－３）は、上述のコンテナのうち専用コアに割り当てられる優先順位に対する情報を含んでもよい。

ディスプレイ制御部（Ｍ１－２）は、複数のディスプレイそれぞれの動作を担当するコンテナが車両内の各ディスプレイに画面を出力するように管理することができる。

コンテナファイルシステム管理部（Ｍ１－４）は、複数のコンテナ環境で各コンテナの動作に必要なファイルを体系的かつ効率的に管理することができる。
例えば、コンテナファイルシステム管理部（Ｍ１－４）は、後述のように、いずれかのファイルシステム、例としてコンテナのファイルシステムをまた他のコンテナファイルシステムにオーバーレイすることができる。
これによって、ユーザ（複数の搭乗者）は、コンテナのようなファイルシステムを他のユーザまたは他の位置（例えば、座席）で容易に共有することができる。

すなわち、実施例による車両の仮想化構造に基づくシステムにおいて複数のコンテナは、システムの初期化および管理を共有することができる。
例えば、実施例による車両の仮想化構造に基づくシステムにおいて複数のコンテナは、ｒｏｏｔｆｓを共有することができる。
また、各オペレーティングシステム、すなわち、コンテナは、別に変更ディレクトリを保存またはコピーすることでディスクなどのリソースを効率的に利用することができる。
さらに、各コンテナ毎のアップグレードも変更ディレクトリのみを用いて行うことができる。
例えば、各表示装置を効果的にアップグレードすることができる。

コンテナストリーミング管理部（Ｍ１－５）は、各ディスプレイから出力される画像の移動などを管理することができる。
すなわち、コンテナストリーミング管理部（Ｍ１０５）は、走行部とインフォテインメント部、さらにディスプレイそれぞれのポリシーによってストリーミングが可能であるかどうかを判断してもよい。

オーディオポリシーおよび制御管理部（Ｍ１－６）は、少なくとも１つのコンテナ間のオーディオ出力に対するポリシーを反映してオーディオ出力を制御することができる。
これについての詳しい説明は後述する。

コンテナアップグレード部（ＣＭ２）は、複数のオペレーティングシステムからなるインフォテインメント部の各オペレーティングシステム毎にアップグレードを行うことができる。
例えば、コンテナアップグレード部（ＣＭ２）は、コンテナで構成されたインフォテインメント部の各コンテナを容易にアップグレードすることができる。

コンテナアップグレード部（ＣＭ２）は、アップデートおよび確認管理部（Ｍ２－１）と、認証管理部（Ｍ２－２）とを含んでもよい。

アップデートおよび確認管理部（Ｍ２－１）は、複数のコンテナのうちアップデートが必要なコンテナのためのコンテナ毎の識別子、およびアップデート後における正常動作の確認を行うことができる。

認証管理部（Ｍ２－２）は、アップデートを行うために、車両およびコンテナ毎の認証、バージョン比較を行うことができる。

コンテナ状態管理部（ＣＭ３）は、コンテナが正常動作するか否かに対する確認など複数のコンテナ状態を管理することができる。

コンテナ状態管理部（ＣＭ３）は、状態管理部（Ｍ３－１）、ログ管理部（Ｍ３－２）を含んでもよい。

状態管理部（Ｍ３－１）は、周期的なモニタリングを通じてコンテナおよびコンテナ管理部の機能が正常動作しているかを確認することができる。

ログ管理部（Ｍ３－２）は、コンテナ状態管理部によって確認された内容をログを保管することができる。
さらに、ログ管理部（Ｍ３－２）は、所定時間後にログを削除またはバックアップ処理することができる。
さらに、コンテナが異常動作している場合、ログ管理部（Ｍ３－２）によって状態管理部（Ｍ３－１）が該当問題を容易に解決することができる。

ウェブプラットフォームコンテナ管理部（ＣＭ４）は、ウェブプラットフォームコンテナに対する管理を行うことができ、ウェブプラットフォーム管理部（Ｍ４－１）、ウェブアカウント管理部（Ｍ４－２）を含んでもよい。

ウェブプラットフォーム管理部（Ｍ４－１）は、ウェブプラットフォームの多様な機能がオペレーティングシステム、すなわち、コンテナ上で正常動作しているかを管理することができる。
また、ウェブプラットフォーム管理部（Ｍ４－１）は、複数のウェブプラットフォームコンテナが動作している場合、各コンテナ毎にログインアカウントを管理することで、個人化されたウェブ利用環境を管理することができる。
これについての詳しい説明は、後述する。

さらに、コンテナブリッジ部（ＣＭ５）は、インターフェース、ハードウェアなどに接続され、ディスプレイ、オーディオ、アプリケーション、ネットワークなどに対する各オペレーティングシステムの間の相互接続を行うことができる。

図面に記載の各要素は、例示であり、以下ではこれを基準として説明する。

また、ユーザ（例えば、搭乗者）は、ユーザインターフェースなどを介して車両の仮想化構造に基づくシステムを操作することができる。
また、操作過程または結果がディスプレイ、オーディオなどの出力装置を介してユーザに提供され得る。
また、ユーザがディスプレイタッチを操作するなどの入力を通じて、これに対するフィードバックが行われ得る。

図３は、実施例による車両の仮想化構造に基づくシステムの制御方法に対する手順図であり、図４は、実施例による車両の仮想化構造に基づくシステムの制御方法におけるアップグレードの必要性確認に対する具体的な手順図であり、図５は、実施例による車両の仮想化構造に基づくシステムの制御方法に対する具体的な手順図であり、図６は、実施例による車両の仮想化構造に基づくシステムにおける複数のコンテナの構造に対する概念図であり、図７および図８は、実施例による車両の仮想化構造に基づくシステムにおける複数のコンテナを駆動を説明する図である。

実施例による車両の仮想化構造に基づくシステムの制御方法は、複数のコンテナを起動するステップ（Ｓ３１０）、複数のコンテナのアップグレードの必要性を確認するステップ（Ｓ３２０）、およびアップグレードの必要性に応じて複数のコンテナに対するアップグレードを行うステップ（Ｓ３３０）を含んでもよい。

このとき、実施例による車両の仮想化構造に基づくシステムにおいて複数のコンテナは、上述のように、システムの初期化および管理を共有することができる。

例えば、複数のコンテナ（Ｃｏｎｔａｉｎｅｒ１ないしＣｏｎｔａｉｎｅｒ３）は、共有されたシステムの初期化および管理であるｒｏｏｔｆｓを共有することができる。
すなわち、複数のコンテナ（Ｃｏｎｔａｉｎｅｒ１ないしＣｏｎｔａｉｎｅｒ３）は、カーネル（ｋｅｒｎｅｌ）、ディストロ（ｄｉｓｔｒｏ）、およびライブラリ（ｌｉｂｒａｒｙ）を互いに共有することができる。

このとき、車両の仮想化構造に基づくシステムの制御方法は、上述のコンテナ管理部（ＣＭ）で行われてもよい。
すなわち、車両の仮想化構造に基づくシステムの制御装置は、コンテナ管理部（ＣＭ）を含んでもよい。
さらに、車両の仮想化構造に基づくシステムの制御装置は、コンテナ制御部（ＣＭ１）、コンテナアップグレード部（ＣＭ２）を含んでもよく、後述の各制御ステップを行ってもよい。以下で各ステップが行われる装置に対して簡略に記載する。

実施例において、コンテナ制御部は、複数のコンテナを起動することができる（Ｓ３１０）。
また、コンテナアップグレード部（ＣＭ２）は、オペレーティングシステム、すなわち、起動された複数のコンテナに対するアップグレードの必要性を判断することができる（Ｓ３２０）

具体的に、複数のコンテナのアップグレードの必要性を確認するステップは、アップグレード情報を受信するステップ（Ｓ３２１）、アップグレード情報と複数のコンテナのアップグレードとを比較するステップ（Ｓ３２２）、アップグレードの必要性を決定するステップ（Ｓ３２３）を含んでもよい。

コンテナアップグレード部（ＣＭ２）は、サーバーなどからアップデート情報を受信することができる。
アップデート情報は、該当コンテナのバージョン情報を含んでもよい。

さらに、コンテナ管理部（ＣＭ）またはコンテナアップグレード部（ＣＭ２）は、受信したアップグレードと複数のコンテナのアップグレード、すなわち、アップグレード情報を比較してもよい。
これによって、受信したアップグレード情報と対応するコンテナのアップグレード情報とを比較することで、コンテナのアップグレード情報が、受信したアップグレード情報より最新であるかどうかを判断してもよい。

例えば、コンテナ管理部（ＣＭ）またはコンテナアップグレード部（ＣＭ２）は、受信したアップグレード情報とコンテナのアップグレード情報とが同じバージョンであるか、またはコンテナのアップグレード情報が最新の場合はアップグレードの必要性がないと判断してもよい。
また、受信したアップグレードの情報がコンテナのアップグレード情報より低いバージョンの場合はアップグレードの必要性があると判断してもよい。
すなわち、複数のコンテナのアップグレードが必要であるかどうかを判断することができる（Ｓ３３４）。

また、コンテナ管理部（ＣＭ）は、アップグレードの必要性に応じて複数のコンテナに対するアップグレードを行うことができる（Ｓ３３０）。
アップグレードの必要性が存在する場合にのみ、コンテナ管理部（ＣＭ）は、複数のコンテナに対するアップグレードを行うことができる。
また、アップグレードの必要性が存在しない場合は、コンテナ制御部（ＣＭ１）は複数のコンテナを駆動することができる（Ｓ３４０）。
すなわち、各ディスプレイ毎のユーザデータ（ｐｅｒｓｏｎａｌ Ｄａｔａ）をローディングしてコンテナを駆動することができる。
このとき、上述のように、コンテナ管理部（ＣＭ）またはコンテナ制御部（ＣＭ１）は、車両内の各ディスプレイ毎のコンテナでシステムの初期化および管理であるｒｏｏｔｆｓを共有し、各コンテナ（例えば、ディスプレイ毎）がユーザデータを共有されたｒｏｏｔｆｓにオーバーレイするため、ディスクリソースを節約することができる。
これによって、効率的なコンテナの運営または駆動を行うことができる。
さらに、コンテナは、ユーザデータをコピーして（ｃｏｐｉｅｄ）駆動されてもよい。
実施例において、ユーザデータのうち変更ディレクトリコピーして複数のコンテナを駆動または実行することができる。
すなわち、最新バージョンのユーザデータ（ｄｅｌｔａ０／）が新しいユーザデータ（ｄｅｌｔａ１／）でコピー（ｃｏｐｉｅｄ）されてもよい。
これによって、既存コンテナ（ｏｒｉｇｉｎａｌ）の駆動後における新しいコンテナ（ｓｎａｐ ｃｌｏｎｅ）の駆動を容易に行うことができる。
例えば、複数のＲＳＥディスプレイに対するコンテナの駆動をより容易に行うことができる。
また、既存の最新バージョンのユーザデータまたは駆動されたユーザデータ（ｎｅｗ ｆｉｌｅｓ）が上述のように共有されたｒｏｏｔｆｓ（ｒｏｏｔ ｆｉｌｅｓ）にオーバーレイされてもよい（ｍｏｕｎｔ）。
これによって、コンテナの駆動およびアップデート（システムファイルおよびユーザデータ）の両方を容易に行うことができる。

また、コンテナ管理部（ＣＭ）またはコンテナ制御部（ＣＭ１）は、コンテナに接続されたディスプレイでアプリケーションを実行することができる（Ｓ３５０）。
これによって、車両内の各搭乗者に位置するディスプレイ毎の各サービス（例えば、アプリケーション実行）を搭乗者に提供することができる。

また、コンテナ管理部（ＣＭ）またはコンテナ制御部（ＣＭ１）は、アップグレードの必要性が存在する場合、システムディレクトリに対するアップグレードであるか、または、ユーザデータ（ｐｅｒｓｏｎａｌ ｄａｔａ）に対するアップグレードであるかを判断することができる（Ｓ３６０）。
これは、上述のアップグレードの必要性に応じて複数のコンテナに対するアップグレードを行うステップ（Ｓ３３０）が具体化されるステップであってもよい。
すなわち、コンテナに対するアップグレードの遂行が、以下のように具体化して行われてもよい。

システムディレクトリに対するアップグレードの場合、コンテナ管理部（ＣＭ）は、アップグレードであるかを判断した（Ｓ３６０）後にユーザ認証を行い（Ｓ３７０）、システムディレクトリを受信することができる（Ｓ３８０）。

コンテナ管理部（ＣＭ）またはコンテナアップグレード部（ＣＭ２）は、ユーザ認証を行うことができる。
ユーザ認証は、車両およびコンテナに対する認証を含んでもよい。
すなわち、車両の種類とコンテナの種類を判断した後、該当車両に対応するコンテナに対する認証を行うことができる（Ｓ３７０）。

また、コンテナ管理部（ＣＭ）またはコンテナアップグレード部（ＣＭ２）は、サーバーから最新バージョンのファイルシステム（ｆｉｌｅ ｓｙｓｔｅｍ）を受信することができる。
例えば、ファイルシステムとしてカーネル、ＯＳ、ライブラリが存在する。
受信されたファイルシステムが共有されたｒｏｏｔｆｓに適用されてもよい。
すなわち、実施例による車両の仮想化構造に基づく制御方法および装置は、コンテナ管理部によって（またはコンテナ管理部を含んで）同一の仮想エンジン上に同一のコンテナ種類に対するシステムディレクトリアップグレードを容易に行うことができる。
すなわち、１回のシステムディレクトリの受信によって複数のコンテナに対するシステムディレクトリアップグレードを行うことができる。
その後、複数のコンテナを再起動することができる（Ｓ３９０）。

その後、アップグレードの必要性を確認するステップ（Ｓ３２０）に戻り、上述のステップまたは機能を行うことができる。

ユーザデータ（ｐｅｒｓｏｎａｌ ｄａｔａ）に対するアップグレードの場合、アップグレードであるかを判断するステップ（Ｓ３６０）の後に複数のコンテナを駆動することができる（Ｓ３４０）。
ただし、その前に最新のユーザデータを受信（Ｓ３６５）することができる。
ここで最新とは、保全が上位であるか、修正された日付が最も近い場合を意味する。

最新のユーザデータを各コンテナに適用することができる。
このとき、上述のように、共有されたｒｏｏｔｆｓにユーザデータをオーバーレイしてユーザデータをローディングし、個別コンテナを駆動することができる。
これによって、ディスクリソースに対する使用を最小化することができる。

さらに、コンテナ管理部（ＣＭ）は、コンテナに接続されたディスプレイでアプリケーションを実行することができる（Ｓ３５０）。
すなわち、アプリケーションが各コンテナ上に駆動されて各ディスプレイを介して出力され得る。
これによって、車両内の各搭乗者に位置するディスプレイ毎の各サービス（例えば、アプリケーション実行）を搭乗者に提供することができる。

図９は、図２におけるＫ部分の拡大図であり、図１０は、実施例による車両の仮想化構造に基づくシステムにおけるウェブプラットフォーム制御方法に対する手順図であり、図１１は、実施例による車両の仮想化構造に基づくシステムにおけるウェブプラットフォーム制御方法でウェブアプリケーションの駆動を示す図である。

図９ないし図１１を参照すると、上述のように実施例による車両の仮想化構造に基づくシステムは、ベースオペレーティングシステム（１０）および追加の仮想エンジン（２０）上で搭載または駆動されるウェブプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）を含んでもよい。
インフォテインメント部（ＩＰ）と同様にプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、コンテナ管理者をインフォテインメント部（ＩＰ）と共有することができる。
またはプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）の一部として構成されてもよい。
これについては、言及したように個別の構成として説明する。

また、プラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）のようにコンテナ管理部に搭載された１つのオペレーティングシステム（例えば、コンテナ、３０）、オペレーティングシステム上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（例えば、ＡＧＬ、４０）、オペレーティングシステムプラットフォーム（４０）で駆動される複数のアプリケーション（例えば、ウェブアプリケーション、５０）を含んでもよい。

さらに、仮想エンジン（２０）には、車両情報サービスサーバー（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｖｅｒ、ＶＩＳ ｓｅｒｖｅｒ）を含んでもよい。車両情報サービスサーバー（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｖｅｒ、ＶＩＳ ｓｅｒｖｅｒ）は、車両駆動部情報（速度、燃料量など）および車両設定情報（温度、シート位置など）を保存して、各ウェブプラットフォームコンテナ、すなわちオペレーティングシステムプラットフォーム（４０）に伝送することができる。
すなわち、車両情報サービスサーバー（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｖｅｒ、ＶＩＳ ｓｅｒｖｅｒ）は、各ウェブオペレーティングシステムプラットフォーム（４０）内の車両情報サービスクライアント（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｖｅｒ、ＶＩＳ Ｃｌｉｅｎｔ）に要請されたまたは搭乗者に対応した車両駆動部情報および車両設定情報を提供することができる。

また、コンテナ管理者（ＣＭ）は、上述のようにウェブプラットフォームコンテナ管理部（ＣＭ４）を含んでもよい。
また、ウェブプラットフォームコンテナ管理部（ＣＭ４）は、ウェブプラットフォームコンテナに対する管理を行うことができ、ウェブプラットフォーム管理部、ウェブアカウント管理部を含んでもよい。

ウェブプラットフォーム管理部は、ウェブプラットフォームの多様な機能がオペレーティングシステム、すなわち、コンテナ上で正常動作しているかを管理することができる。
また、ウェブプラットフォーム管理部は、複数のウェブプラットフォームコンテナが動作している場合、各コンテナ毎にログインアカウントを管理することで、個人化されたウェブ利用環境を管理することができる。

オペレーティングシステムプラットフォーム（４０）は、ＡＧＬであって、要請されたまたは搭乗者に対応した車両駆動部情報および車両設定情報を提供され、車両の環境を設定するサービスクライアント（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｓｅｖｅｒ、ＶＩＳ Ｃｌｉｅｎｔ）を含んでもよい。

さらに、オペレーティングシステムプラットフォーム（４０）は、ユーザの認識および登録のためのＡＰＩサービス部（Ｄｅｖｉｃｅ ＡＰＩ ｓｅｒｖｉｃｅ）、オペレーティングシステムプラットフォームに含まれたウェブアプリケーションを管理する機能を確張するために、複数のウェブプラットフォームコンテナ（オペレーティングシステム、３０）の駆動時にＧＰＳなどのハードウェアリソースを複数のウェブアプリケーションが利用できるかどうかをモニタリングして管理するアドオン部（ＷＡＭ ａｄｄ ｏｎ）、およびウェブアプリケーションの利用時にテキストの入力が必要な場合のための仮想キーボード部（Ｖｉｒｔｕａｌ Ｋｅｙｂｏａｒｄ）を含んでもよい。

より具体的に、実施例による車両の仮想化構造に基づく制御方法は、ウェブプラットフォームの制御に関連してユーザを認識するステップ（Ｓ４０５）、認識されたユーザが登録済みのユーザであるかを確認するステップ（Ｓ４１０）を含んでもよい。

すなわち、オペレーティングシステムプラットフォーム（４０）またはＡＰＩサービス部（Ｄｅｖｉｃｅ ＡＰＩ ｓｅｒｖｉｃｅ）は、ユーザを認識することができる（Ｓ４０５）。
言い換えると、車両内の各搭乗者に対する個別の認識が行われ得る。
これによって、多様な装置（センサー、モバイル、アプリケーションなど）を通じてユーザ認識が行われ得る。
また、ユーザを認識するステップ（Ｓ４０５）は、上述のアップデートおよびコンテナ駆動の後に行われてもよい。
例えば、ユーザを認識するステップ（Ｓ４０５）は、アプリケーションが各コンテナ上で駆動され、各ディスプレイに出力された（Ｓ３５０）後に行われてもよい。
このとき、車両内の搭乗者のユーザがウェブプラットフォームコンテナを駆動してユーザ認識が行われてもよい。

オペレーティングシステムプラットフォーム（４０）またはＡＰＩサービス部（Ｄｅｖｉｃｅ ＡＰＩ ｓｅｒｖｉｃｅ）は、認識されたユーザが登録済みのユーザであるかを確認することができる（Ｓ４１０）。
オペレーティングシステムプラットフォーム（４０）またはＡＰＩサービス部（Ｄｅｖｉｃｅ ＡＰＩ ｓｅｒｖｉｃｅ）は、登録済みのユーザではない場合はユーザ登録を進行し（Ｓ４１５）、登録済みのユーザの場合は車両の環境を設定してもよい（Ｓ４２０）。
環境は、シート位置、望ましい温度、照明光状態などを含んでもよい。

特に、ユーザ認識は、コンテナ管理部（ＣＭ）のうちウェブプラットフォームコンテナ管理部（ＣＭ４）と連携して行われてもよい。
ウェブプラットフォームコンテナ管理部（ＣＭ４）は、ウェブアカウントの登録、変更、削除などを管理し、ウェブアカウントが登録されたアカウントであるかを確認でき、ウェブアカウント毎にアプリケーションリストの実行および管理を行うか、ウェブアカウントログインが重複して生じないようにログイン状態を管理することができる。
すなわち、オペレーティングシステムプラットフォーム（４０）またはＡＰＩサービス部（Ｄｅｖｉｃｅ ＡＰＩ ｓｅｒｖｉｃｅ）から提供されたユーザ情報がコンテナ管理部（ＣＭ）で確認されることで、アカウント毎にアプリケーションリストの実行および管理や重複ログインの管理を行うことができる。

また、コンテナ管理部（ＣＭ）のうちウェブプラットフォームコンテナ管理部（ＣＭ４）は、認識されたユーザ、すなわち、ユーザ情報に対するウェブアカウントの登録有無を確認することができる（Ｓ４２５）。

これによって、コンテナ管理部（ＣＭ）のうちウェブプラットフォームコンテナ管理部（ＣＭ４）は、該当ユーザに対するウェブアカウントが登録されていないか、または、ない場合はウェブアカウントを登録して（Ｓ４３０）保存し、ウェブアカウントが登録された場合は、ウェブアカウントが他のウェブプラットフォームコンテナにログインされたのかを確認することができる（Ｓ４３５）。

これによって、コンテナ管理部（ＣＭ）のうちウェブプラットフォームコンテナ管理部（ＣＭ４）は、ウェブアカウントが他のウェブプラットフォームコンテナにログインされた場合は終了または再ログインを出力し（Ｓ４４０）、該当ウェブアカウントがログインされた状態ではない場合は、ウェブアカウント毎にアプリケーションを抽出（Ｓ４４５）できる。
また、抽出されたウェブアカウント毎の優先アプリケーションがユーザに提供され得る（図１１を参照）。
これによって、ユーザは、ウェブアカウント毎に優先またはリアルタイムのウェブアプリケーションの駆動に対して容易に認識することができる。

また、コンテナ管理部（ＣＭ）のうちウェブプラットフォームコンテナ管理部（ＣＭ４）は、ナビゲーションアプリケーションを駆動して目的地をディスプレイに表示することができる（Ｓ４５０）。
また、ユーザは、仮想キーボード部（Ｖｉｒｔｕａｌ Ｋｅｙｂｏａｒｄ）により目的地を入力することができる（Ｓ４５５）。
このように、実施例による車両の仮想化構造に基づく制御方法および装置でウェブプラットフォーム制御により（方法または装置）、ユーザ認識によってウェブプラットフォームアプリケーションを容易に使用し、各オペレーティングシステム（ウェブプラットフォームコンテナ）に同一のアプリケーションを異なるユーザまたは搭乗者ウェブアカウントで駆動することができる。
これによって、車両内の搭乗者間の個別アカウントを用いて同一のアプリケーションを駆動および実行することができる。

図１２は、他の実施例による車両の仮想化構造に基づくシステムの概念図であり、図１３は、実施例による車両の仮想化構造に基づくシステムにおける表示装置を説明する図である。

図１２および図１３を参照すると、上述のように実施例による車両の仮想化構造に基づくシステムは、ハードウェア（図示せず）、ハードウェア（図示せず）上に搭載されたベースオペレーティングシステム（１０）、ベースオペレーティングシステム（１０）上に搭載された第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）、各仮想エンジン上に搭載される少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）、少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）、オペレーティングシステムプラットフォーム（４０ａないし４０ｆ）で駆動される複数のアプリケーション（５０ａないし５０ｄ）、複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）または複数のアプリケーションなどを出力する複数のディスプレイ（６０ａないし６０ｆ）および仮想エンジン（２０ａないし２０ｂ）上で複数のオペレーティングシステム（３０ａないし３０ｄ）に対する環境を管理するコンテナ管理部（ＣＭ）を含んでもよい。
少なくとも１つのオペレーティングシステムは、以下「コンテナ（ｃｏｎｔａｉｎｅｒ）」として説明する。

ここで、ハードウェア（図示せず）は、プロセッサ、表示部、保存部、メモリ部、コントロール部、Ｉ／Ｏ装置を含む概念であってもよい。

実施例において、走行部（ＣＰ）は、第１仮想エンジン（２０ａ）上で搭載または駆動されるシステム領域であり、インフォテインメント部（ＩＰ、Ｉｎｆｏｔａｉｎｍｅｎｔ Ｐｌａｔｆｏｒｍ）は、第１仮想エンジン（２０ａ）とは異種の仮想エンジンである第２仮想エンジン（２０ｂ）上で搭載または駆動されるシステム領域であってもよい。
このような構成によって、インフォテインメント部（ＩＰ）内でアップグレードまたはその他誤作動が発生しても、走行部（ＣＰ）がこれに対する影響を受けない。
すなわち、走行中の影響を最小化することができる。
さらに、インフォテインメント部（ＩＰ）以外にウェブプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）が、ベースオペレーティングシステム（１０）および追加の仮想エンジン（２０）上で搭載または駆動されてもよい。
インフォテインメント部（ＩＰ）と同様にプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、コンテナ管理者をインフォテインメント部（ＩＰ）と共有することができる。
またはプラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）の一部で構成されてもよい。以下では個別の構成として説明する。

プラットフォーム部（Ｗｅｂ Ｐｌａｔｆｏｒｍ）は、インフォテインメント部（ＩＰ）のようにコンテナ管理部に搭載された１つのオペレーティングシステム（例えば、コンテナ、３０）、オペレーティングシステム上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（例えば、ＡＧＬ、４０）、オペレーティングシステムプラットフォーム（４０）で駆動される複数のアプリケーション（例えば、ウェブアプリケーション、５０）を含んでもよい。

まず、ベースオペレーティングシステム（１０）は、例えば、多様なオペレーティングシステムであってもよい。
例えば、ベースオペレーティングシステム（１０）は、リナックス（ｌｉｎｕｘ）、ハイパーバイザ（ｈｙｐｅｒｖｉｓｏｒ）、ＱＮＸ、ＧＥＮＩＶＩなどを含んでもよい。

例えば、第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、ミドルウェアソリューションまたは多様なプラットフォームであり、モバイルＣ言語で開発することができる。
第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、複数の内蔵ライブラリを提供でき、多様な移動端末機などで同じ動作を行うこともできる。
例えば、第１仮想エンジン（２０ａ）と第２仮想エンジン（２０ｂ）は、リナックスベースのアンドロイドカーネルであってもよく、メモリ保護、仮想メモリモジュールおよびスケジュールキャッシングを初期化することもできる。

また、少なくとも１つのコンテナ（３０ａないし３０ｄ）は、第２仮想エンジン（２０ａ）上に搭載され、第１仮想エンジン（１０ａ）上に搭載されなくてもよい。
これによって、走行部（ＣＰ）に対するセキュリティ性が向上するので、走行安全性も向上させることができる。

少なくとも１つのコンテナ（３０ａないし３０ｄ）は実施例で仮想化方式の一形態としてプロセス仮想化の日程であってもよい。
例えば、コンテナを用いた仮想化技術は、ホストＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）の内部を、物理的リソースを管理するカーネル空間と、ユーザプロセス、すなわち応用プログラム（アプリケーション、ａｐｐｌｉｃａｔｉｏｎ、ＡＰＰ）を実行するユーザ空間とに区分し、ユーザ空間を複数に分けてそれぞれのユーザプロセスで使用されるハードウェアリソースを割り当てて共有する技術を意味し得る。
例えば、コンテナ（３０ａないし３０ｄ）は、呼び出されたライブラリをシステムライブラリとインターフェースされるように変換して、ベースオペレーティングシステムと複数のオペレーティングシステムプラットフォームとの間の接続または互換を行うことができる。

複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）は、コンテナ上に搭載されていてもよい。
複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）は、アンドロイド、ＡＧＬ（Ａｕｔｏｍｏｔｉｖｅ Ｇｒａｄｅ Ｌｉｎｕｘ）、ウェブ（ｗｅｂ）プラットフォーム、クラスタ（ｃｌｕｓｔｅｒ）プラットフォーム、ヘッドアップディスプレイ（ＨＵＤ）プラットフォームなどを含んでもよい。
さらに、オペレーティングシステムプラットフォーム（４０）内に複数のサウンドクライアントが配置されてもよい。
複数のサウンドクライアントは、第１サウンドクライアントおよび第２サウンドクライアントを含んでもよい。
このとき、第１サウンドクライアントは、第１仮想エンジン（２０ａ）上のオペレーティングシステムプラットフォーム（４０ａ、４０ｂ）に搭載されていてもよい。
第２サウンドクライアントは、第２仮想エンジン（２０ｂ）上のオペレーティングシステムプラットフォーム（４０ｃなど）に搭載されていてもよい。
すなわち、第１サウンドクライアントおよび第２サウンドクライアントは、互いに異なる仮想エンジン上に搭載されていてもよい。
また、第１サウンドクライアントは、クラスタオペレーティングシステムに搭載（４０ａ）またはＨＵＤオペレーティングシステム（４０ｂ）に搭載されていてもよい。
また、第２サウントクライアントは、ＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）オペレーティングシステム、コ－ドライバー（Ｃｏ－Ｄｒｉｖｅｒ）オペレーティングシステム、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）オペレーティングシステムに搭載されていてもよい。

さらに、サウンドサーバーは、第１サウンドクライアント（ＳＣ１）および第２サウンドクライアント（ＳＣ２）からそれぞれ第１サウンド出力情報および第２サウンド出力情報を受信することができる。
サウンドサーバーは、仮想エンジン（２０ａ、２０ｂ）またはベースオペレーティングシステム（１０）内に搭載されていてもよい。
以下でサウンドサーバーは、第１サウンドサーバー（ＳＳ１）、第２サウンドサーバー（ＳＳ２）を含み、第１サウンドサーバー（ＳＳ１）および第２サウンドサーバー（ＳＳ２）は、異種の仮想エンジンに搭載されることを基準として説明する。

少なくとも１つのアプリケーション（５０ａないし５０ｄ）は、システムプログラムを除いた応用プログラムとして、車両内ではＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）、コ－ドライバー（Ｃｏ－Ｄｒｉｖｅｒ）、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）などを含んでもよい。

複数のディスプレイ（６０ａないし６０ｆ）は、オペレーティングシステムプラットフォーム（４０ａないし４０ｆ）またはプラットフォーム上の応用プログラムなどをユーザ（例えば、搭乗者）に表示することができる。
例えば、複数のディスプレイ（６０ａないし６０ｆ）は、多様な表示装置（例えば、ＯＬＥＤ）を含んでもよい。

以下の説明は、上述のオーディオポリシーおよび制御管理部に対する内容であり得る。

また、ユーザ（例えば、搭乗者）は、ユーザインターフェースなどを介して車両の仮想化構造に基づくシステムを操作することができる。
また、操作過程または結果がディスプレイ、オーディオなどの出力装置を介してユーザに提供されてもよい。

図１４は、実施例による車両の仮想化構造に基づくサウンド制御装置のブロック図であり、図１５は、実施例による車両の仮想化構造に基づくサウンド制御方法の手順図であり、図１６は、実施例による車両の仮想化構造に基づくサウンド制御方法の具体化された手順図であり、図１７は、一例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図であり、図１８は、他の例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図であり、図１９は、また他の例に対する第１サウンド出力情報および第２サウンド出力情報の出力を説明する図である。

図１４を参照すると、実施例による車両の仮想化構造に基づくサウンド制御装置（１００）は、受信部（１１０）、比較部（１２０）、判断部（１３０）、および送信部（１４０）を含んでもよい。
このとき、車両の仮想化構造に基づくサウンド制御装置（１００）は、オーディオポリシーおよび制御管理部を含み、オーディオポリシーおよび制御管理部は、受信部（１１０）、比較部（１２０）、判断部（１３０）、および送信部（１４０）に対応することができる。

まず、受信部（１１０）は、各サウンドクライアントからサウンド出力情報を受信することができる。
例えば、受信部（１１０）は、第１サウンドクライアントからの第１サウンド出力情報および第２サウンドクライアントからの第２サウンド出力情報のうち少なくとも１つを受信することができる。
また、サウンド出力情報は、ユーザの入力などによって生じ得る。
すなわち、サウンド出力情報は、ユーザ入力によってアプリケーションが実行されて出力されるサウンド情報を含んでもよい。

比較部（１２０）は、受信された前記第１サウンド出力情報および前記第２サウンド出力情報に対する優先順位を比較できる。
第１サウンド出力情報の優先順位は、前記第２サウンド出力情報の優先順位より高くてもよい。
これによって、走行部から受信したサウンド出力情報が、インフォテインメント部から受信したサウンド出力情報より優先順位が高いので、走行に対する安定性を向上させることができる。

判断部（１３０）は、前記第１サウンド出力情報の発生時点が車両の走行中であるか否かを判断してもよい。
このとき、判断部（１３０）は、第１サウンド出力情報を出力した後に第２サウンド出力情報を出力するように判断してもよい。

また、判断部（１３０）は、第１サウンド出力情報の発生時点が車両の走行中である場合、第１サウンド出力情報のレベルによって第１サウンド出力情報および第２サウンド出力情報の出力有無および出力時間を調節して出力するように判断してもよい。

具体的に、判断部（１３０）は、第１サウンド出力情報のレベルが第１レベルである場合は前記第１サウンド出力情報のみ出力し、前記第２サウンド出力情報の出力を遮断するように判断してもよい。
このとき、出力情報のレベルは、第１レベル、および前記第１レベルより低い第２レベルを含んでもよい。

また、判断部（１３０）は、第１サウンド出力情報のレベルが第２レベルである場合は、前記第１サウンド出力情報および前記第２サウンド出力情報を第１時間の間出力してもよい。
また、判断部（１３０）は、第２サウンド出力情報を第１時間に連続する第２時間の間出力するように判断してもよい。
このとき、第１時間の間における前記第１サウンド出力情報の大きさは、前記第２サウンド出力情報の大きさより大きくてもよい。
このような構成によって、車両の走行中における安定性を向上させることができる。

また、仮想エンジン（仮想化環境）またはホストオペレーティングシステムに搭載された（または埋め込まれた）オペレーティングシステム（例えば、ゲストオペレーティングシステムなど）内のサウンドクライアントは、各オペレーティングシステムなどと接続された表示装置などにサウンド出力情報を受信または要請することができる。
サウンド出力情報の受信および要請は、出力が要求されるサウンドデータを意味し得る。

また、仮想エンジンまたはコンテナまたはベースオペレーティングシステム内に搭載されたサウンドサーバーは、データすなわちサウンド出力情報を受信して出力インターフェースであるスピーカーなどを介してサウンドを出力するように、ハードウェアにサウンド出力情報を送信することができる。
このとき、サウンド出力情報すなわちデータは、仮想エンジンまたはホストオペレーティングシステムに搭載された（または埋め込まれた）オペレーティングシステム（例えば、ゲストオペレーティングシステムなど）内のサウンドクライアントを介して表示装置に伝達されることでユーザに提供されてもよい。

また、送信部（１４０）は、最終判断された第１サウンド出力情報および第２サウンド出力情報のうち少なくとも１つをハードウェアなどに送信してもよい。
これによって、車両の前面または後面のサウンド出力装置（例えば、スピーカー）を介してサウンドを出力することができる。

図１５ないし図１９を参照すると、実施例による車両の仮想化構造に基づくサウンド制御方法は、第１サウンドクライアントからの第１サウンド出力情報および第２サウンドクライアントからの第２サウンド出力情報のうち少なくとも１つを受信するステップ（Ｓ５１０）、受信された前記第１サウンド出力情報および前記第２サウンド出力情報に対する優先順位を比較するステップ（Ｓ５２０）、および、比較結果に応じて第１サウンド出力情報および第２サウンド出力情報のうち少なくとも１つをハードウェアに送信するステップ（Ｓ５３０）を含んでもよい。
以下で各ステップは、上述の車両の仮想化構造に基づくサウンド制御装置によって行われてもよい。

また、第１サウンドクライアントおよび前記第２サウンドクライアントは、互いに異なる仮想エンジン上に搭載され、第１サウンドクライアントは、クラスタオペレーティングシステムに搭載され、前記第２サウンドクライアントは、ＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）オペレーティングシステム、コ－ドライバー（Ｃｏ－Ｄｒｉｖｅｒ）オペレーティングシステム、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）オペレーティングシステムに搭載されていてもよい。

また、第１サウンド出力情報の優先順位は、前記第２サウンド出力情報の優先順位より高くてもよい。

また、優先順位を比較した（Ｓ５２０）後、第１サウンド出力情報の発生時点が車両の走行中であるか否かを確認することができる（Ｓ５４０）。

実施例において、第１サウンド出力情報の発生時点が車両の走行中ではない場合、第１サウンド出力情報を出力した後に第２サウンド出力情報を出力してもよい（Ｓ５５０）。
例えば、走行が始まる前に、インフォテインメント部のオーディオ再生前に駆動部の通知音の再生が必要なことがある。
この場合、図１７のように、駆動部のアラーム（第１サウンド出力情報）を特定時間（ｔａ）まで先に出力し、インフォテインメント部のオーディオ（第２サウンド出力情報）が特定時間（ｔａ）以降に出力されてもよい。
すなわち、エンジン始動後に、ＡＶＮのラジオなどメディアの再生前に燃料不足アラーム、消耗品交換アラームなどの通知音が優先して出力（再生）されてもよい。
言い換えると、比較結果に応じて、第１サウンド出力情報および第２サウンド出力情報（車両走行中には第１サウンド出力情報の送信後に第２サウンド出力情報を送信）のうち少なくとも１つを送信してもよい。

また、第１サウンド出力情報の発生時点が車両の走行中である場合、前記第１サウンド出力情報のレベルによって、前記第１サウンド出力情報および第２サウンド出力情報の出力有無および出力時間を調節して出力してもよい（Ｓ５７０）。
ここで、出力情報のレベルは、第１レベル、および前記第１レベルより低い第２レベルを含んでもよい。

また、第１サウンド出力情報のレベルが第１レベルであるかを判断してもよい。
第１サウンド出力情報のレベルが第１レベルである場合は、第１サウンド出力情報のみ出力し、第２サウンド出力情報の出力を遮断してもよい（Ｓ５８０）。

例えば、車両の走行中に駆動部のオーディオ（またはサウンド）を出力し、インフォテインメント部のオーディオをミュート（ｍｕｔｅ）してもよい。
これによって、運転手が危険状態を完全に認知することになり、事故の発生を抑制することができる。
すなわち、図１８のように、第１サウンド出力情報のみ出力され、第２サウンド出力情報の出力が遮断されてもよい。

例えば、走行中の車両駆動部の故障、居眠り防止アラームなど（第１サウンド出力情報）が、インフォテインメント部のオーディオ（第２サウンド出力情報）が遮断された状態で出力されなければならないので、第１サウンド出力情報のみがハードウェアに送信され得る。

また、第１サウンド出力情報のレベルが第２レベルである場合は、第１サウンド出力情報および前記第２サウンド出力情報を第１時間の間出力し（Ｓ５９０）、第２サウンド出力情報を第１時間に連続する第２時間の間出力してもよい（Ｓ５９５）。

図１９を参照すると、第１時間（ｔ１）まで第１サウンド出力情報および第２サウンド出力情報を出力してもよい。
このとき、第１時間（ｔ１）の間における前記第１サウンド出力情報の大きさ（ＡＭ１）は、前記第２サウンド出力情報の大きさ（ＡＭ２）より大きくてもよい。
これによって、運転手は、第１サウンド出力情報のオーディオを容易に認知することができる。

これによって、走行中の車線逸脱アラーム、消耗品交換アラームなどの瞬間的な注意を必要とする第１サウンド出力情報を運転手に容易に提供することができる。

さらに、第２サウンド出力情報のみを受信する場合、前記送信するステップで前記第２サウンド出力情報を前記ハードウェアに送信することができる。

このとき、表示装置がオーディオデータを出力する場合、これらの装置間で優先順位が存在し得る。
例えば、ＡＶＮ、ＲＳＥ、Ｃｏ－ｄｒｉｖｅの順に優先順位が設定されてもよい。

例えば、ＡＶＮのみオーディオ出力が行われる場合、車両のすべてのサウンド装置（以下、スピーカー）が該当オーディオを出力することができる。
また、ＡＶＮとＲＳＥが同時にオーディオ出力を行う場合、車両の前面部上にオーディオが出力される場合、車両の前面部のスピーカーはＡＶＮのオーディオ出力を出力し、車両の後面部のスピーカーはＲＳＥのオーディオ出力を出力することができる。
また、ＡＶＮとＣｏ－ｄｒｉｖｅが同時にオーディオ出力を行う場合、ＡＶＮとＣｏ－ｄｒｉｖｅのうち最近出力されたオーディオ出力を車両のすべてのスピーカーに出力することができる。

図２０は、変形例による車両の仮想化構造に基づくシステムの概念図である。

上述のように、実施例による車両の仮想化構造に基づくシステムは、ハードウェア（図示せず）、ハードウェア（図示せず）上に搭載されたベースオペレーティングシステム（１０）、ベースオペレーティングシステム（１０）上に搭載された少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）、少なくとも１つのオペレーティングシステム（３０ａないし３０ｆ）上に搭載され、ミドルウェアおよび重要アプリケーションが含まれた一連のソフトウェアとして複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）、オペレーティングシステムプラットフォーム（４０ａないし４０ｆ）で駆動される複数のアプリケーション（５０ａないし５０ｄ）、複数のオペレーティングシステムプラットフォーム（４０ａないし４０ｆ）または複数のアプリケーションなどを出力する複数のディスプレイ（６０ａないし６０ｆ）および仮想エンジン（２０ａないし２０ｂ）上で複数のオペレーティングシステム（３０ａないし３０ｄ）に対する環境を管理するコンテナ管理部（ＣＭ）を含んでもよい。
少なくとも１つのオペレーティングシステムは、以下「コンテナ（ｃｏｎｔａｉｎｅｒ）」として説明する。
すなわち、上述の仮想エンジンを用いることなく、図２０に示す車両の仮想化構造に基づくシステムで上述のサウンド制御を行うことができる。

上述の本発明の実施例は、コンピューターによって実行されるプログラムモジュールのようなコンピューターによって実行可能な命令語を含む記録媒体の形態にも具現することができる。
コンピューター可読媒体は、コンピューターによってアクセス可能な任意の可用媒体であってもよく、揮発性および非揮発性の媒体、分離型および非分離型の媒体をいずれも含む。
また、コンピューター可読媒体は、コンピューター記憶媒体を含んでもよい。
コンピューター記憶媒体は、コンピューター可読命令語、データ構造、プログラムモジュールまたはその他データのような情報の保存のための任意の方法または技術で具現された揮発性および非揮発性、分離型および非分離型の媒体をいずれも含んでもよい。

また、本実施例で説明した車両用ソフトウェア制御装置は、コンピューター具現可能な記憶媒体に格納されたコンピュータープログラムとして具現することができる。
また、本実施例で使用される「～部」という用語は、ソフトウェアまたはＦＰＧＡ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）またはＡＳＩＣなどのハードウェア構成要素を意味し、「～部」は任意の役割を行うことができる。
ただし、「～部」は、ソフトウェアまたはハードウェアに限定される意味ではない。
「～部」は、アドレス可能な記憶媒体に存在するように構成されてもよく、１つまたはそれ以上のプロセッサを再生させるように構成されてもよい。
よって、一例として「～部」は、ソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素などの構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、および変数を含んでもよい。
構成要素および「～部」より提供される機能は、より小さい数の構成要素および「～部」に結合するか、または、追加の構成要素と「～部」にさらに分離できる。
さらに、構成要素および「～部」は、デバイスまたはセキュリティマルチメディアカード内の１つまたはそれ以上のＣＰＵを再生させるように具現されてもよい。

以上、実施例を中心に説明してきたが、これは例示に過ぎず、本発明を限定するものではなく、本発明が属する分野における通常の知識を有する者であれば、本実施例の本質的な特性を逸脱しない範囲で、以上に例示されていない様々の変形と応用が可能であることが分かるであろう。
例えば、実施例に具体的に示された各構成要素は変形して実施できるものである。
また、このような変形と応用に関する差異点は、添付の特許請求の範囲で規定する本発明の範囲に含まれるものであると解釈されるべきである。

Claims (10)

1. 複数のコンテナを起動するステップ；
   前記複数のコンテナのアップグレードの必要性を確認するステップ；および
   前記アップグレードの必要性に応じて前記複数のコンテナに対するアップグレードを行うステップ；を含み、
   前記複数のコンテナは、システムの初期化および管理を共有する、車両の仮想化構造に基づく制御方法。
2. 前記複数のコンテナのアップグレードの必要性を確認するステップは、
   アップグレード情報を受信するステップ；
   前記アップグレード情報と前記複数のコンテナのアップグレードとを比較するステップ；および
   前記アップグレードの必要性を決定するステップ；を含む、請求項１に記載の車両の仮想化構造に基づく制御方法。
3. 前記アップグレードの必要性がない場合に前記複数のコンテナを駆動するステップ；をさらに含む、請求項２に記載の車両の仮想化構造に基づく制御方法。
4. 前記アップグレードの必要性が存在する場合に、システムディレクトリに対するアップグレードであるか、またはユーザデータ（ｐｅｒｓｏｎａｌ ｄａｔａ）に対するアップグレードであるかを判断するステップ；をさらに含む、請求項２に記載の車両の仮想化構造に基づく制御方法。
5. 前記システムディレクトリに対するアップグレードの場合、アップグレードであるかを判断するステップの後に、
   ユーザ認証を行うステップ；および
   前記システムディレクトリを受信するステップ；をさらに含む、請求項４に記載の車両の仮想化構造に基づく制御方法。
6. 前記複数のコンテナを再起動するステップ；をさらに含み、
   前記アップグレードの必要性を確認するステップに戻る、請求項５に記載の車両の仮想化構造に基づく制御方法。
7. 前記ユーザデータに対するアップグレードの場合、アップグレードであるかを判断するステップの後に、
   最新のユーザデータを受信するステップ；および
   前記複数のコンテナを駆動するステップ；をさらに含む、請求項４に記載の車両の仮想化構造に基づく制御方法。
8. 前記複数のコンテナを駆動するステップの後に、
   前記コンテナに接続されたディスプレイでアプリケーションを実行するステップ；をさらに含む、請求項３または請求項７に記載の車両の仮想化構造に基づく制御方法。
9. 前記複数のコンテナを駆動するステップで、
   前記ユーザデータのうち変更ディレクトリコピーして前記複数のコンテナを駆動する、請求項７に記載の車両の仮想化構造に基づく制御方法。
10. 前記共有されたシステムの初期化および管理は、カーネル（ｋｅｒｎｅｌ）、ディストロ（ｄｉｓｔｒｏ）およびライブラリ（ｌｉｂｒａｒｙ）を含む、請求項７に記載の車両の仮想化構造に基づく制御方法。