JP2015103129A - 車載情報装置 - Google Patents

Abstract

【課題】ポリシーを利用してゲストＯＳ間の通信を許可することでゲストＯＳ間のセキュリティを制御する。【解決手段】本発明の車載情報装置１は、ホストＯＳ３を介して行われる複数のゲストＯＳ間の通信を制御する通信制御部２１を備え、セキュリティ制御部２５が、通信制御部２１を経由したゲストＯＳ間の通信内容を取得し、車両状態管理部３１から車両の状態を取得して、ポリシー管理部２７で管理されているポリシーに基づいてゲストＯＳ間の通信を許可するか否かを判定する。【選択図】図１

Description

本発明は、車両に搭載され、ホストＯＳが提供する仮想環境上で複数のゲストＯＳが動作する車載情報装置に関する。

従来では、ホストＯＳがポリシーに基づいてＡＰＩ(Application Programing Interface)やＣＰＵ等のハードウェア資源をゲストＯＳに提供あるいは制限することが行われていた。具体的に特許文献１では、仮想モバイル機器において、セキュリティ・ポリシーに応じて仮想マシンによるハードウェアへのアクセスを制限している。

特表２０１２−５３１６７８号公報

しかしながら、上述した従来の仮想モバイル機器では、ホストＯＳがポリシーに応じて個々のゲストＯＳのセキュリティを制御しているが、ゲストＯＳ間のセキュリティを制御することはできないという問題点があった。

そこで、本発明は、上述した実情に鑑みて提案されたものであり、ポリシーを利用してゲストＯＳ間のセキュリティを制御することのできる車載情報装置を提供することを目的とする。

上述した課題を解決するために、本発明は、ホストＯＳを介して行われる複数のゲストＯＳ間の通信を通信制御部が制御し、車両の状態を車両状態管理部が管理し、通信条件を規定したポリシーをポリシー管理部が管理する。そして、セキュリティ制御部が、通信制御部を経由したゲストＯＳ間の通信内容を取得し、車両状態管理部から車両の状態を取得して、ポリシー管理部で管理されているポリシーに基づいてゲストＯＳ間の通信を許可するか否かを判定する。

本発明によれば、ポリシーを利用することによって特定の場合に限定してゲストＯＳ間の通信を許可するので、ゲストＯＳ間のセキュリティを制御することができる。

図１は、本発明の第１実施形態に係る車載情報装置の構成を示すブロック図である。 図２は、本発明の第１実施形態に係る車載情報装置のポリシー管理部で管理されているポリシーの一例を示す図である。 図３は、本発明の第１実施形態に係る車載情報装置によるゲストＯＳ間の通信制御処理の処理手順を示すフローチャートである。 図４は、本発明の第２実施形態に係る車載情報装置の構成を示すブロック図である。 図５は、本発明の第２実施形態に係る車載情報装置のポリシー管理部で管理されているポリシーの一例を示す図である。 図６は、本発明の第２実施形態に係る車載情報装置によるゲストＯＳ間の通信制御処理の処理手順を示すフローチャートである。

以下、本発明を適用した第１及び第２実施形態について図面を参照して説明する。

［第１実施形態］
［車載情報装置の構成］
図１は本実施形態に係る車載情報装置の構成を示すブロック図である。図１に示すように、本実施形態に係る車載情報装置１は、ホストＯＳ３が搭載され、このホストＯＳ３には、カーネル５と、仮想化ソフトウェア７が導入されている。そして、仮想化ソフトウェア７によって提供された仮想環境上で第１及び第２ゲストＯＳ９ａ、９ｂが動作している。また、車載情報装置１は、ＧＰＳ１１と、ＣＡＮ１３と、ＡＢＳモジュール１５に接続されている。

ここで、車載情報装置１は車両に搭載された移動端末であり、仮想環境上で動作する複数のゲストＯＳ間の通信を制御する機能を備えている。特に、本実施形態では、ポリシーを利用して第１ゲストＯＳ９ａと第２ゲストＯＳ９ｂとの間の通信を制御する。

ホストＯＳ３は、車載情報装置１に搭載されたメインＯＳ（Operating System）であり、仮想化ソフトウェア７を動作させるのに必要な機能を提供し、必要となるハードウェアに直接接続されている。

カーネル５は、ホストＯＳ３を構成するソフトウェア上の機能層であり、ＣＰＵリソースの管理やアプリケーションの起動、管理、ハードウェアへのアクセス等の基本的な機能を提供する。そして、通信制御部２１と、ドライバ２３とを備えている。

通信制御部２１は、アプリケーション間の通信を司る機能を備えており、ホストＯＳ３内での通信を効率良くするために提供されたものであり、ホストＯＳ３を介して行われる第１ゲストＯＳ９ａと第２ゲストＯＳ９ｂとの間の通信を制御している。例えば、ＩＰＣ（Inter Process Communication）等の通信機能を用いて通信経路を提供する。

ドライバ２３は、ＧＰＳ１１やＣＡＮ１３、ＡＢＳモジュール１５等の各種ハードウェアへのアクセスを提供するためのドライバソフトウェアである。

仮想化ソフトウェア７は、仮想環境を提供するための基本ソフトウェアであり、仮想的なハードウェアをエミュレーションすることによって仮想環境を提供し、提供された仮想環境ではゲストＯＳを複数動作させることが可能となる。また、仮想化ソフトウェア７は、セキュリティ制御部２５と、ポリシー管理部２７と、ゲストＯＳ管理部２９と、車両状態管理部３１とを備えている。

セキュリティ制御部２５は、車両状態管理部３１から車両の状態を取得し、第１及び第２ゲストＯＳ９ａ、９ｂが通信制御部２１を経由して他のゲストＯＳと通信する際に通信内容を取得する。そして、ポリシー管理部２７で管理されているポリシーに基づいて第１及び第２ゲストＯＳ９ａ、９ｂ間の通信を許可するか否かを判定することでセキュリティを制御する。また、第１及び第２ゲストＯＳ９ａ、９ｂ間の通信の接続、遮断を行うと共に、ゲストＯＳ管理部２９に対しては第１及び第２ゲストＯＳ９ａ、９ｂの起動、停止を指示したり、第１及び第２ゲストＯＳ９ａ、９ｂの機能を制限または解除する指示を出したりする。さらに、セキュリティ制御部２５は、ゲストＯＳ管理部２９から複数のゲストＯＳ９ａ、９ｂの状態を取得して第１及び第２ゲストＯＳ９ａ、９ｂ間の通信を許可するか否かを判定してもよい。

ポリシー管理部２７は、通信条件を規定したポリシーを管理しており、このポリシーは第１及び第２ゲストＯＳ９ａ、９ｂ間の通信内容及び車両の状態に応じて通信条件が規定されている。

ゲストＯＳ管理部２９は、第１及び第２ゲストＯＳ９ａ、９ｂの状態を管理しており、ゲストＯＳで実行されているプロセスやモード等のゲストＯＳ毎の状態とともに、ゲストＯＳ全体の起動数や組合せなどゲストＯＳ全体の状態を把握する。このとき、ゲストＯＳ管理部２９は、第１及び第２ゲストＯＳ９ａ、９ｂの状態としてゲストＯＳの起動の有無及びゲストＯＳの種別（汎用（通常）ＯＳ、リアルタイムＯＳ、ＨＭＩの有無等）を取得して管理する。さらに、ゲストＯＳの状態とともに第１及び第２ゲストＯＳ９ａ、９ｂで起動されているアプリケーションの状態を管理することも可能である。また、ゲストＯＳ管理部２９は、第１及び第２ゲストＯＳ９ａ、９ｂの起動、停止を行う機能も備えており、必要に応じて実行することが可能である。

車両状態管理部３１は、ホストＯＳ３に接続されたＧＰＳ１１、ＣＡＮ１３、ＡＢＳモジュール１５等のハードウェアの状態を把握することによって車両の状態を管理する。

第１ゲストＯＳ９ａは、ホストＯＳ３の仮想化ソフトウェア７によって提供された仮想環境上で動作するゲストＯＳである。第１ゲストＯＳ９ａの種別は汎用ＯＳであり、ＨＭＩ（Human Machine Interface）を備えている。これにより、主にディスプレイへの表示機能やＴＴＳ(Text To Speech)を用いた音声インターフェース等のアプリケーションが動作している。第１ゲストＯＳ９ａ上には仮想化サポートソフトウェアが導入されており、通信制御部２１へ通信することにより第２ゲストＯＳ９ｂの状態を把握することができる。本実施形態では、第１ゲストＯＳ９ａが、第２ゲストＯＳ９ｂから警告信号を受け取った際にディスプレイ出力やＴＴＳ出力などを用いて、不具合が発生したことを速やかにユーザへ通知する。また、不具合以外の緊急ではない情報については、車両走行中のようなユーザの集中力を削ぐタイミングを避け、停止時などに参考情報として通知する。

第２ゲストＯＳ９ｂは、第１ゲストＯＳ９ａと同様にホストＯＳ３の仮想化ソフトウェア７によって提供された仮想環境上で動作するゲストＯＳである。第２ゲストＯＳ９ｂの種別はリアルタイムＯＳであり、ＡＢＳモジュール１５を制御するためのＯＳが導入されている。本実施形態では、第２ゲストＯＳ９ｂはＨＭＩを備えておらず、ＡＢＳにリアルタイムの制御不具合が発生すると、ビープ音のみでユーザへ通知する。そのための仮想ビープインターフェース３３が第２ゲストＯＳ９ｂに導入されており、第２ゲストＯＳ９ｂのＡＢＳ制御アプリケーションはビープ出力のみを行う。

仮想ビープインターフェース３３は、第２ゲストＯＳ９ｂに導入されている仮想マシン上に存在する仮想ハードウェアである。したがって、実際のハードウェアは存在しない。そして、仮想ビープインターフェース３３は、ビープハードウェアの代わりにビープ出力を受け取ると、第２ゲストＯＳ９ｂがユーザに対して警告を行おうとしていることを、通信制御部２１を経由して第１ゲストＯＳ９ａに通知する。

ＧＰＳ（Global Positioning System）１１は、車両に搭載され、車両の位置情報や時刻等の時間情報を取得するためのデバイスである。

ＣＡＮ（Controller Area Network）１３は、車両に搭載された車載ネットワークであり、ＣＡＮバスに接続された各種機器やセンサー等から車両信号を取得するためのデバイスである。

ＡＢＳモジュール１５は、車両に搭載されたＡＢＳ（アンチロック・ブレーキ・システム）の制御モジュールであり、ＡＢＳにおけるブレーキのタイミング制御などを行う。

次に、図２を参照して、ポリシー管理部２７で管理されているポリシーの一例を示す。図２に示すように、２０１は、図２のポリシーが第２ゲストＯＳ９ｂから第１ゲストＯＳ９ａへの通信に関するポリシーであることを示している。

２０２は情報種別であり、緊急情報に該当する情報はすべて（＊：アスタリスク）を許可（ＯＫ）することを示している。

２０３は位置に関するポリシーであり、「Dealer」のＰＯＩ（Point Of Interest）属性を有する位置に自らの車両が位置する場合にのみ許可（ＯＫ）することを示している。

２０４も位置に関するポリシーであり、「Circuit」のＰＯＩ属性を有する位置に自らの車両が位置する場合にのみ許可（ＯＫ）することを示している。

２０５は車両の状態に関するポリシーであり、走行中(Running)に該当する場合は不許可(ＮＧ)にすることを示している。

このように２０２〜２０５の条件によって、特定の場合に限定してゲストＯＳ間の通信を許可するので、ゲストＯＳ間のセキュリティを制御することができる。

［ゲストＯＳ間の通信制御処理の手順］
次に、本実施形態に係る車載情報装置１の第１及び第２ゲストＯＳ９ａ、９ｂ間における通信制御処理の手順を、図３のフローチャートを参照して説明する。

図３に示すように、まずステップＳ１０１において車載情報装置１が起動すると、ステップＳ１０２においてゲストＯＳ管理部２９が、仮想環境上で動作しているゲストＯＳを認識する。本実施形態では、第１及び第２ゲストＯＳ９ａ、９ｂが認識され、これらのゲストＯＳの機能や状態を把握する。ゲストＯＳの状態としては、ゲストＯＳの起動の有無やゲストＯＳの種別（汎用ＯＳ、リアルタイムＯＳ等）、起動中のゲストＯＳの組み合わせなどがある。また、ゲストＯＳの状態とともにゲストＯＳで起動しているアプリケーションの状態を取得して管理してもよい。アプリケーションの状態としては、リアルタイム性が要求される処理やバックグラウンドで動作するような優先度の低い処理のようにアプリケーションの処理に関する優先度や実行中／待機中のようなアプリケーションの実行状況等がある。

そして、セキュリティ制御部２５は、このようなゲストＯＳやアプリケーションの状態を取得してゲストＯＳ間の通信を許可するか否かを判定してもよい。例えば、第１ゲストＯＳ９ａが起動していないときには、ステップＳ１０２において第２ゲストＯＳ９ｂからの通信を不許可としてもよい。

次に、ステップＳ１０３において、第２ゲストＯＳ９ｂに組み込まれているＥＣＵがＡＢＳモジュール１５で何らかのイベントが発生し、ユーザに対して通知が必要な状況であることを検知する。

ステップＳ１０４では、実際にユーザへ通知するために仮想ビープインターフェース３３でビープ音を出力するための処理が行われ、第２ゲストＯＳ９ｂから警告信号を出力する。

次に、ステップＳ１０５において、セキュリティ制御部２５は、予めポリシー管理部２７から図２に示した通信ポリシーを取得しており、第２ゲストＯＳ９ｂから出力された警告信号の種別に応じて緊急情報であるか否かを判定する。

ここで、警告信号が緊急情報である場合にはステップＳ１０６に進み、緊急情報でない場合にはステップＳ１０７に進む。

ステップＳ１０７では、セキュリティ制御部２５が、車両状態管理部３１からＧＰＳ１１で検出された車両の位置情報を取得し、車両が登録済みの場所に位置しているか否かを判定する。具体的に図２のポリシーでは、登録済みの場所として「ディーラー」と「サーキット」が設定されているので、ＧＰＳ１１の位置情報により自車両がディーラーまたはサーキットの場所に位置しているか否かを判定する。通常、緊急情報でない場合に走行中の運転者に何らかの情報を出力することは適当ではないが、ディーラーによる整備時やサーキット等の特殊走行時にはこの条件を緩和して、走行中であるか否かを問わず情報を出力する。そこで、登録済みの場所に車両が位置している場合にはステップＳ１０６に進み、登録済みの場所に位置していない場合にはステップＳ１０８に進む。

次に、ステップＳ１０８において、セキュリティ制御部２５は、車両が走行中であるか否かを判定する。セキュリティ制御部２５は、車両状態管理部３１からＣＡＮ１３で検出された車両情報やＧＰＳ１１による位置情報を取得し、自車両が走行中であるか否かを判定する。走行中の運転者に情報提示することを制限し、車両が停止したときに情報提示を行うためである。そこで、車両が走行中でない場合にはステップＳ１０６に進み、車両が走行中である場合にはステップＳ１０９に進む。

ステップＳ１０９では、セキュリティ制御部２５が、走行中である車両が停止するまで情報の提示を待機する。

こうしてステップＳ１０５、１０７、１０８において、ポリシーに規定された通信条件を満たしていると判定されると、ステップＳ１０６に進んで、セキュリティ制御部２５は、第２ゲストＯＳ９ｂからの警告信号を通信制御部２１へ送信する。

次に、ステップＳ１１０において、通信制御部２１は、第２ゲストＯＳ９ｂによって出力された警告信号をセキュリティ制御部２５から受信し、第１ゲストＯＳ９ａへ向けて出力する。

ここで、第１ゲストＯＳ９ａに向けて出力された信号は再びセキュリティ制御部２５を通過するので、ステップＳ１１１〜１１４において、ステップＳ１０５、１０７〜１０９と同一の処理がセキュリティ制御部２５によって行われる。そして、ポリシーに規定された通信条件を満たしていると判定されると、ステップＳ１１５に進んで、第１ゲストＯＳ９ａが、第２ゲストＯＳ９ｂから出力された警告信号を受信する。

ステップＳ１１６では、第１ゲストＯＳ９ａが保有するディスプレイやＴＴＳ等の高度なインターフェースを用いて、ユーザにＡＢＳで起きたイベントについて通知して本実施形態に係るゲストＯＳ間の通信制御処理を終了する。

［第１実施形態の効果］
以上詳細に説明したように、本実施形態に係る車載情報装置１では、ゲストＯＳ間の通信内容と車両の状態を取得し、ポリシーに基づいてゲストＯＳ間の通信を許可するか否かを判定する。これにより、ポリシーを利用して特定の場合に限定してゲストＯＳ間の通信を許可するので、ゲストＯＳ間のセキュリティを制御することができる。

また、本実施形態に係る車載情報装置１では、ホストＯＳ３が仮想化ソフトウェア７を導入することによって仮想環境を提供するので、複数のゲストＯＳを動作させることが可能となる。

さらに、本実施形態に係る車載情報装置１では、仮想化ソフトウェア７が仮想的なハードウェアをエミュレーションすることによって仮想環境を提供する。これにより、異なるハードウェア環境やＯＳ環境で動作しているソフトウェアを実行することが可能となる。

また、本実施形態に係る車載情報装置１では、複数のゲストＯＳの状態を管理するゲストＯＳ管理部２９をさらに備え、セキュリティ制御部２５がゲストＯＳ管理部２９から複数のゲストＯＳの状態を取得してゲストＯＳ間の通信を許可するか否かを判定する。これにより、セキュリティ制御部２５がゲストＯＳの状態を把握することができ、それに応じてゲストＯＳ間の通信の可否を判定することができる。

さらに、本実施形態に係る車載情報装置１では、ゲストＯＳ管理部２９がゲストＯＳの状態とともにゲストＯＳで起動されているアプリケーションの状態を管理する。これにより、ゲストＯＳの状態だけではなく、アプリケーションの状態を把握してゲストＯＳ間の通信の可否を判定することができる。

また、本実施形態に係る車載情報装置１では、ゲストＯＳ管理部２９がゲストＯＳの状態としてゲストＯＳの起動の有無及びゲストＯＳの種別を取得して管理する。これにより、セキュリティ制御部２５がゲストＯＳの起動の有無や種別に応じてゲストＯＳ間の通信の可否を判定することができる。

さらに、本実施形態に係る車載情報装置１では、複数のゲストＯＳに、ＨＭＩを備えたゲストＯＳとＨＭＩを備えていないゲストＯＳが含まれている。これにより、ＨＭＩを備えていないゲストＯＳからの情報をＨＭＩを備えたゲストＯＳによってユーザに通知することができるので、ユーザに対して常に高度なサービスを提供することができる。

また、本実施形態に係る車載情報装置１では、ポリシーに規定された通信条件として、ゲストＯＳ間の通信内容が緊急情報であるか否か、車両の位置が予め設定された所定の位置であるか否か、車両が走行中であるか否かのうちの少なくとも１つとしている。これにより、通信内容や車両の位置、状態に応じてゲストＯＳ間の通信の可否を判定することができる。

［第２実施形態］
次に、本発明の第２実施形態に係る車載情報装置について図面を参照して説明する。尚、第１実施形態と同一の構成要素には同一の番号を付して詳細な説明は省略する。

［車載情報装置の構成］
図４は本実施形態に係る車載情報装置の構成を示すブロック図である。図４に示すように、本実施形態に係る車載情報装置５１は、第３ゲストＯＳ９ｃと、仮想ネットワーク５３をさらに備え、ネットワークインターフェース５５に接続されていることが、第１実施形態と相違している。また、第１ゲストＯＳ９ａと第３ゲストＯＳ９ｃには仮想ネットワークインターフェース５７ａ、５７ｃがそれぞれ備えられている。

本実施形態の車載情報装置５１は、仮想ネットワーク５３を介して第１ゲストＯＳ９ａと第３ゲストＯＳ９ｃとの間で通信を行うことを可能としている。

第３ゲストＯＳ９ｃは、ホストＯＳ３の仮想化ソフトウェア７によって提供された仮想環境上で動作するゲストＯＳである。第３ゲストＯＳ９ｃの種別は第１ゲストＯＳ９ａと同様に汎用ＯＳであり、ＨＭＩを備えている。第３ゲストＯＳ９ｃは、第１ゲストＯＳ９ａとは異なるＯＳで作られたアプリケーションを動作させたり、再開発が困難なアプリケーションを再利用したりしている。第３ゲストＯＳ９ｃで処理した結果は、第１ゲストＯＳ９ａに送信され、ユーザインタフェースのみを第１ゲストＯＳ９ａが行う。

仮想ネットワーク５３は、論理的なネットワークであり、ソフトウェアによって構築された物理的には存在しない仮のネットワークである。第１及び第３ゲストＯＳ９ａ、９ｃは仮想ネットワークインターフェース５７ａ、５７ｃを介して仮想ネットワーク５３にアクセスし、この仮想ネットワーク５３を経由してゲストＯＳ間の通信やインターネット等の外部のネットワークへの接続を行う。

ネットワークインターフェース５５は、車両に搭載され、ホストＯＳ３が外部と通信を行うためのインターフェースである。ホストＯＳ３では、仮想ネットワーク５３からネットワークインターフェース５５を経由して外部のネットワークへの接続を提供する。

仮想ネットワークインターフェース５７ａ、５７ｃは、第１及び第３ゲストＯＳ９ａ、９ｃ上に存在する仮想的なネットワークインターフェースである。第１及び第３ゲストＯＳ９ａ、９ｃ上で動作しているアプリケーションが外部へ通信を行う場合に、仮想ネットワーク５３を介して外部へ通信する。また、第３ゲストＯＳ９ｃ上のアプリケーションによる処理結果を送信する場合には、仮想ネットワークインターフェース５７ａ、５７ｃにより仮想ネットワーク５３を介して通信することができる。

次に、図５を参照して、ポリシー管理部２７で管理されているポリシーの一例を示す。図５に示すように、５０１は、以下に示す項目（５０２）が第３ゲストＯＳ９ｃから第１ゲストＯＳ９ａへの通信に関するポリシーであることを示している。

５０２は、アプリケーション情報に関するデータ通信のすべて（＊：アスタリスク）を許可（ＯＫ）することを示している。

５０３は、以下に示す項目（５０４〜５０７）が第２ゲストＯＳ９ｂ、第３ゲストＯＳ９ｃから第１ゲストＯＳ９ａへの通信に関するポリシーであることを示している。

５０４は情報種別であり、緊急情報に該当する情報はすべて（＊：アスタリスク）を許可（ＯＫ）することを示している。

５０５は位置に関するポリシーであり、「Dealer」のＰＯＩ（Point Of Interest）属性を有する位置に自らの車両が位置する場合にのみ許可（ＯＫ）することを示している。

５０６も位置に関するポリシーであり、「Circuit」のＰＯＩ属性を有する位置に自らの車両が位置する場合にのみ許可（ＯＫ）することを示している。

５０７は車両の状態に関するポリシーであり、走行中(Running)に該当する場合は不許可(ＮＧ)にすることを示している。

５０８は、以下に示す項目（５０９、５１０）が第１ゲストＯＳ９ａから他のゲストＯＳすべて（＊：アスタリスク）への通信に関するポリシーであることを示している。

５０９は車両の状態に関するポリシーであり、走行中(Running)に該当する場合は不許可(ＮＧ)にすることを示している。

５１０は車両の状態に関するポリシーであり、ＡＢＳモジュール１５が動作中(Running)に該当する場合は不許可(ＮＧ)にすることを示している。

これら５０９、５１０の条件によって、第１ゲストＯＳ９ａに何者かが侵入して不正な通信を実行しようとした場合でも、走行中やＡＢＳの動作時には通信を不許可にすることができる。これにより車両の走行に影響を与える場面での不正な通信を防止してセキュリティを制御することができる。

［ゲストＯＳ間の通信制御処理の手順］
次に、本実施形態に係る車載情報装置５１の第１〜第３ゲストＯＳ９ａ、９ｂ、９ｃ間における通信制御処理の手順を、図６のフローチャートを参照して説明する。

図６に示すように、まずステップＳ２０１において車載情報装置５１が起動すると、ステップＳ２０２においてゲストＯＳ管理部２９が、仮想環境上で動作しているゲストＯＳを認識する。本実施形態では、第１〜第３ゲストＯＳ９ａ、９ｂ、９ｃが認識され、これらのゲストＯＳの機能や状態を把握する。

次に、ステップＳ２０３において、セキュリティ制御部２５は、ポリシー管理部２７からポリシーを取得して読み込む。

ステップＳ２０４において、セキュリティ制御部２５は、第１〜第３ゲストＯＳ９ａ〜９ｃからの通信を検出したか否かを判定し、検出していない場合には継続してゲストＯＳからの通信を監視する。一方、ゲストＯＳからの通信を検出すると、ステップＳ２０５に進んで、セキュリティ制御部２５は、まず検出した通信が第２ゲストＯＳ９ｂからの通信であるか否かを判定する。ここで、第２ゲストＯＳ９ｂからの通信でない場合にはステップＳ２０６に進み、第２ゲストＯＳ９ｂからの通信である場合にはステップＳ２０８に進む。

ステップＳ２０６では、セキュリティ制御部２５は、ステップＳ２０４で検出した通信が第３ゲストＯＳ９ｃからの通信であるか否かを判定する。ここで、第３ゲストＯＳ９ｃからの通信である場合にはステップＳ２０７に進み、第３ゲストＯＳ９ｃからの通信でない場合には第１ゲストＯＳ９ａからの通信であると判定してステップＳ２１１に進む。

このようにしてセキュリティ制御部２５は、第１〜第３ゲストＯＳ９ａ〜９ｃのどこからの通信であるかを判定する。そして、第３ゲストＯＳ９ｃからの通信である場合には、ステップＳ２０７において、セキュリティ制御部２５は、図５に示したポリシーに基づいて第３ゲストＯＳ９ｃからの通信がアプリ情報であるか否かを判定する。ここで、アプリ情報でない場合にはステップＳ２０８に進み、アプリ情報である場合にはステップＳ２１３に進む。

次に、ステップＳ２０８では、セキュリティ制御部２５が、図５のポリシーに基づいて第２及び第３ゲストＯＳ９ｂ、９ｃからの通信が緊急情報であるか否かを判定する。ここで、緊急情報でない場合にはステップＳ２０９に進み、緊急情報である場合にはステップＳ２１３に進む。

ステップＳ２０９では、セキュリティ制御部２５が、車両状態管理部３１からＧＰＳ１１で検出された車両の位置情報を取得し、車両が登録済みの場所に位置しているか否かを判定する。具体的に図５のポリシーでは、登録済みの場所として「ディーラー」と「サーキット」が設定されているので、ＧＰＳ１１の位置情報により自車両がディーラーまたはサーキットの場所に位置しているか否かを判定する。通常、緊急情報でない場合に走行中の運転者に何らかの情報を出力することは適当ではないが、ディーラーによる整備時やサーキット等の特殊走行時にはこの条件を緩和して情報を出力する。そして、登録済みの場所に位置していない場合にはステップＳ２１０に進み、登録済みの場所に車両が位置している場合にはステップＳ２１３に進む。

ステップＳ２１０では、セキュリティ制御部２５が、車両が走行中であるか否かを判定する。セキュリティ制御部２５は、車両状態管理部３１からＣＡＮ１３で検出された車両情報やＧＰＳ１１による位置情報を取得し、自車両が走行中であるか否かを判定する。走行中の運転者に情報提示することを制限し、車両が停止したときに情報提示を行うためである。そこで、車両が走行中でない場合にはステップＳ２１３に進み、車両が走行中である場合にはステップＳ２１４に進む。

また、ステップＳ２１１では、セキュリティ制御部２５が、ステップＳ２１０と同様に車両が走行中であるか否かを判定する。そして、車両が走行中でない場合にはステップＳ２１２に進み、車両が走行中である場合にはステップＳ２１４に進む。

ステップＳ２１２では、セキュリティ制御部２５が、ＡＢＳモジュール１５が動作中であるか否かを判定する。セキュリティ制御部２５は、車両状態管理部３１からＡＢＳモジュール１５の動作状態を取得し、ＡＢＳモジュール１５が動作中であるか否かを判定する。ＡＢＳが動作しているような重要な状況で運転者に情報提示することを制限するためである。そこで、ＡＢＳモジュール１５が動作中でない場合にはステップＳ２１３に進み、ＡＢＳモジュール１５が動作中である場合にはステップＳ２１４に進む。

こうしてポリシーに基づいて判定してステップＳ２１３に進むと、セキュリティ制御部２５はゲストＯＳ間の通信を許可し、ステップＳ２１４に進んだ場合にはゲストＯＳ間の通信を不許可として本実施形態に係るゲストＯＳ間の通信処理を終了する。

［第２実施形態の効果］
以上詳細に説明したように、本実施形態に係る車載情報装置５１では、仮想ネットワーク５３を介してゲストＯＳ９ａ、９ｃが外部のネットワークと通信することができる。これにより、ゲストＯＳが外部のネットワークと通信できる環境においても、ポリシーを利用して特定の場合に限定してゲストＯＳ間の通信を許可するので、ゲストＯＳ間のセキュリティを制御することができる。

なお、上述の実施形態は本発明の一例である。このため、本発明は、上述の実施形態に限定されることはなく、この実施形態以外の形態であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることは勿論である。

１、５１ 車載情報装置
３ ホストＯＳ
５ カーネル
７ 仮想化ソフトウェア
９ａ 第１ゲストＯＳ
９ｂ 第２ゲストＯＳ
９ｃ 第３ゲストＯＳ
１１ ＧＰＳ
１３ ＣＡＮ
１５ ＡＢＳモジュール
２１ 通信制御部
２３ ドライバ
２５ セキュリティ制御部
２７ ポリシー管理部
２９ ゲストＯＳ管理部
３１ 車両状態管理部
３３ 仮想ビープインターフェース
５３ 仮想ネットワーク
５５ ネットワークインターフェース
５７ａ、５７ｃ 仮想ネットワークインターフェース

Claims (8)

1. 車両に搭載され、ホストＯＳ（Operating System）が提供する仮想環境上で動作する複数のゲストＯＳ間の通信を制御する車載情報装置であって、
   前記ホストＯＳを介して行われる前記複数のゲストＯＳ間の通信を制御する通信制御部と、
   前記車両の状態を管理する車両状態管理部と、
   前記複数のゲストＯＳ間の通信内容及び前記車両の状態に応じて通信条件を規定したポリシーを管理するポリシー管理部と、
   前記ゲストＯＳが前記通信制御部を経由して他のゲストＯＳと通信する際に通信内容を取得し、前記車両状態管理部から車両の状態を取得して、前記ポリシー管理部で管理されているポリシーに基づいて前記ゲストＯＳ間の通信を許可するか否かを判定するセキュリティ制御部と
   を備えたことを特徴とする車載情報装置。
2. 前記ホストＯＳは、仮想化ソフトウェアを導入することによって前記仮想環境を提供することを特徴とする請求項１に記載の車載情報装置。
3. 前記仮想化ソフトウェアは、仮想的なハードウェアをエミュレーションすることによって前記仮想環境を提供することを特徴とする請求項２に記載の車載情報装置。
4. 前記複数のゲストＯＳの状態を管理するゲストＯＳ管理部をさらに備え、
   前記セキュリティ制御部は、前記ゲストＯＳ管理部から前記複数のゲストＯＳの状態を取得して前記ゲストＯＳ間の通信を許可するか否かを判定することを特徴とする請求項１〜３のいずれか１項に記載の車載情報装置。
5. 前記ゲストＯＳ管理部は、前記ゲストＯＳの状態とともに前記ゲストＯＳで起動されているアプリケーションの状態を管理することを特徴とする請求項４に記載の車載情報装置。
6. 前記ゲストＯＳ管理部は、前記ゲストＯＳの状態として前記ゲストＯＳの起動の有無及び前記ゲストＯＳの種別を取得して管理することを特徴とする請求項４または５に記載の車載情報装置。
7. 前記複数のゲストＯＳには、ＨＭＩ（Human Machine Interface）を備えたゲストＯＳとＨＭＩを備えていないゲストＯＳが含まれていることを特徴とする請求項１〜６のいずれか１項に記載の車載情報装置。
8. 前記ポリシーに規定された通信条件は、前記ゲストＯＳ間の通信内容が緊急情報であるか否か、前記車両の位置が予め登録された所定の位置であるか否か、前記車両が走行中であるか否かのうちの少なくとも１つであることを特徴とする請求項１〜７のいずれか１項に記載の車載情報装置。

Images