JP2014102673A - 車載機及びセキュリティシステム - Google Patents

Abstract

【課題】不正なアプリケーションからミドルウェアへの不正アクセスを排除することができ、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる車載機を提供する。
【解決手段】アプリケーションからミドルウェアを経由してハードウェアを制御するソフトウェア構成の車載機であって、アプリケーションを記憶するアプリケーション記憶部１２と、アプリケーションを実行するアプリケーション実行部１３と、ドライバーの負荷状態を推定する負荷状態推定部１５と、ミドルウェアを保持するミドルウェア部１６と、負荷状態に応じたアクセスルールを記憶するアクセスルール記憶部１４２と、アプリケーションがミドルウェアにアクセスする際に、負荷状態推定部１５により推定されたドライバーの負荷状態及びアクセスルールを用いて、アプリケーションのミドルウェアへのアクセス可否を判定するアクセス許可判定部１４１とを備える。
【選択図】図３

Description

本発明は、車載機及びセキュリティシステムに関する。

従来のセキュリティの考え方は悪意を持った不正プログラムがシステム内に侵入しないようにするいわゆる未然防止が主である。このため、何らかの理由でチェックを通過してしまった不正プログラムは、有効に除去できないという問題がある。上記の問題に関し、一旦侵入した不正プログラムを検出及び駆除する方法が提案されている（例えば、特許文献１参照。）。

特許文献１では、ネットワーク上の各コンピュータがログを記録し、各コンピュータはログをネットワーク上の他のコンピュータに通知することで、ログを受信した他のコンピュータ各々が不正行為の有無を検査する。検査の結果、各コンピュータのうちの特定のコンピュータで不正行為があったと判断した場合、そのコンピュータにおいて不正行為のあった旨を表すメッセージを他のコンピュータに送信する。そのメッセージを受信した各コンピュータも個々に不正の有無を検査する。所定の期間内に所定のしきい値を超える台数のコンピュータが該当コンピュータに対して不正行為ありと判断した場合、以後、ネットワーク上の全コンピュータが不正行為ありと判断されたコンピュータとの通信を絶つ。これにより、不正プログラムによる被害を最小限にとどめる。

特開平０９−１２８３３６号公報

しかしながら、特許文献１に記載の不正プログラムを検出及び駆除する方法は、ログデータの解析が必須であることから、不正と判定できるログを取得し、解析が終了するまで不正プログラムからの悪影響を受けることになる。

本発明の目的は、不正なアプリケーションからミドルウェアへの不正アクセスを排除することができ、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる車載機及びセキュリティシステムを提供することである。

本発明の一態様によれば、アプリケーションがミドルウェアを経由してハードウェアを制御する車載機及びセキュリティシステムにおいて、ドライバーの負荷状態及びアクセスルールを用いてアプリケーションからミドルウェアへのアクセスを許可するか否かを判定する。

本発明によれば、不正なアプリケーションからミドルウェアへの不正アクセスを排除することができ、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる車載機及びセキュリティシステムを提供することができる。

本発明の第１の実施の形態に係るセキュリティシステムの一例を示す概略図である。 本発明の第１の実施の形態に係る車載機のソフトウェアの構成を示す概略図である。 本発明の第１の実施の形態に係るセキュリティシステムの一例を示すブロック図である。 本発明の第１の実施の形態に係るアプリケーション記憶部の詳細を示す概略図である。 本発明の第１の実施の形態に係る負荷状態推定部の詳細を示す概略図である。 本発明の第１の実施の形態に係るアクセスルール記憶部の詳細を示す概略図である。 図７（ａ）〜図７（ｄ）は、本発明の第１の実施の形態に係るレイアウトマネジメントにより画面に提示される情報提示領域を説明するための概略図である。 本発明の第１の実施の形態に係る車載機のアプリケーション実行時のフローチャートである。 本発明の第１の実施の形態に係るエラー時の処理のフローチャートである。 本発明の第２の実施の形態に係るセキュリティシステムの一例を示す概略図である。 本発明の第２の実施の形態に係るセキュリティシステムの一例を示すブロック図である。 本発明の第２の実施の形態に係るエラー時の処理のフローチャートである。 本発明の第２の実施の形態に係るデータセンターが不正アプリに関する情報を受信した際のフローチャートである。 本発明の第２の実施の形態に係る他車両に搭載された車載機がデータセンターから不正アプリに関する情報を受信した際のフローチャートである。

次に、図面を参照して、本発明の第１及び第２の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。ただし、図面は模式的なものであり、厚みと平面寸法との関係、各層の厚みの比率等は現実のものとは異なることに留意すべきである。したがって、具体的な厚みや寸法は以下の説明を参酌して判定すべきものである。又、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることはもちろんである。

また、以下に示す第１及び第２の実施の形態は、この発明の技術的思想を具体化するための装置や方法を例示するものであって、この発明の技術的思想は、構成部品の材質、形状、構造、配置等を下記のものに特定するものでない。この発明の技術的思想は、特許請求の範囲において、種々の変更を加えることができる。

（第１の実施の形態）
＜セキュリティシステムの構成＞
本発明の第１の実施の形態に係るセキュリティシステムとして、図１に示すように、車両１に搭載された車載機が、データセンター２からアプリケーションをダウンロードする場合を説明する。

ここで、一般的な車載機のソフトウェア構成を説明する。一般的な車載機のソフトウェア構成は、図２に示すように、アプリケーションＡＰ１，ＡＰ２，ＡＰ３，…、ミドルウェアＭＷ１，ＭＷ２，ＭＷ３，ＭＷ４，…、オペレーションシステム（ＯＳ）、ドライバの４つで構成される。アプリケーションは文字通りアプリケーションを実行し実際にドライバー（ユーザー）にサービスを提供するソフトウェアである。ミドルウェアは、複数のアプリケーションが利用する高度な機能をモジュール化したもので、ＯＳが提供する機能を特定の使い方に限定して組み合わせることで高度な機能をアプリケーションが容易に提供できるためのソフトウェアである。ＯＳは、ドライバを統率し、基本的な機能を提供するためのソフトウェアである。ドライバは、実際にハードウェアを制御するためのソフトウェアである。本発明の第１の実施の形態に係る車載機も、図２と同様のソフトウェア構成を有する。

本発明の第１の実施の形態に係るセキュリティシステムは、図３に示すように、車両１に搭載された車載機（車載ＩＴユニット）１０と、データセンター２とを備える。

データセンター２は、様々なアプリケーションを記憶するアプリケーション記憶部２１と、どのアプリケーションがどの車載機１０にダウンロードされているか等のアプリケーションに関する情報を管理するアプリケーション管理部２２と、車載機１０にアプリケーションをダウンロードする等の通信を行う通信部２３を備える。

アプリケーション記憶部１２は、図４に示すように、アプリケーションそのものの他、アプリケーション毎に、アプリケーションＩＤ（ＡＩＤ）、アプリケーション名、車載機１０にダウンロードされた日時、アプリケーションの作成者情報等を記憶する。アプリケーションＩＤとは、データセンター２にある全アプリケーションにそれぞれ割り当てられている固有のＩＤである。このアプリケーションの中に、ユーザーが意図しない動作を不正に行うアプリケーション（以下、「不正アプリ」ともいう。）が混入する可能性がある。

図３に示した車載機１０は、通信部１１、アプリケーション記憶部１２、アプリケーション実行部１３、アクセス許可部１４、負荷状態推定部１５、ミドルウェア部１６、ハードウェア制御部１７、ハードウェア１８及びセンサ部１９を備える。ハードウェア１８は、ハードウェア制御部１７にそれぞれ接続された表示操作部１８０、音声出力部１８１、音声入力部１８２、外部映像入力部１８３を備える。センサ部１９は、負荷状態推定部１５にそれぞれ接続されたステアリングセンサ１９１、車速センサ１９２、車内カメラ１９３、車外カメラ１９４及び生体信号センサ１９５を備える。

通信部１１は、データセンター２からアプリケーションをダウンロードするため等にデータセンター２との通信を行う。アプリケーション記憶部１２は、データセンター２から通信部１１を介してダウンロードされたアプリケーションを記憶する。アプリケーション実行部１３は、ドライバー（ユーザー）の指示に従い、アプリケーション記憶部１２に記憶されているアプリケーションを実行する。

負荷状態推定部１５は、センサ部１９からのセンサ情報に基づいて、図５に示すようにドライバーの負荷状態Ａ，Ｂ，…を推定する。センサ情報としては、例えばステアリングセンサ１９１から取得されたステアリング操作情報や車速センサ１９２から取得された車速情報等の車両情報、車内カメラ１９３により撮影されたドライバーの顔画像や車外カメラ１９４により撮影された白線距離を利用した車両挙動等のカメラ映像、及び生体信号センサ１９５から取得されたドライバーの心拍や脈拍等の生体信号のいずれか、又はこれらの組み合わせが使用可能である。

例えば、負荷状態の推定方法として、車両１が走行中か停車中かでドライバーの負荷状態を推定する方法がある。即ち、車速情報やパーキングブレーキ情報等に基づいて、走行中であれば負荷状態を“高”と推定し、それ以外の停車中であれば負荷状態を“低”と推定する。なお、負荷状態は“高”又は“低”のように２値的に分類して推定しても良いし、“高”、“中”、“低”等と多段階（３段階以上）に分類して推定しても良い。

アクセス許可部１４は、アプリケーション実行部１３により実行されたアプリケーションがミドルウェア部１６に記憶されているアプリケーション用のミドルウェアを利用する際にアクセス許可を行う。アクセス許可部１４は、アクセス許可判定部１４１、アクセスルール記憶部１４２及びエラー処理実行部１４３を備える。

アクセスルール記憶部１４２は、図６に示すように、負荷状態推定部１５により推定されるドライバーの負荷状態毎に、アプリケーションからのアクセスを許可するミドルウェアと、アクセスを拒否するミドルウェアを規定するアクセスルールを記憶する。図６では、負荷状態Ａの場合には、ミドルウェアＭＷ１、ＭＷ２、ＭＷ３、ＭＷ６へのアクセスを許可し、ミドルウェアＭＷ４、ＭＷ５、ＭＷ７へのアクセスが拒否される。また、負荷状態Ｂの場合には、ミドルウェアＭＷ２、ＭＷ４、ＭＷ５、ＭＷ７へのアクセスが許可され、ミドルウェアＭＷ１、ＭＷ３、ＭＷ６へのアクセスが拒否されることを示している。

なお、図６では、判定ルールがアクセスを許可するミドルウェアとアクセスを拒否するミドルウェアを規定する場合を示すが、判定ルールはこれに限定されるものではない。判定ルールは、アクセスを許可するミドルウェアにおいてアクセスの一部を制限しても良い。

アクセスルールでは、例えば、走行中であり負荷状態が“高”の場合は、安全のために、表示操作部１８０等での動画再生用のミドルウェア、表示操作部１８０等にカメラ画像を表示するためのミドルウェア、表示操作部１８０等に文字入力のためのソフトウェアキーボードを表示するためのミドルウェア、表示操作部１８０等に表示モードを切り替えたりアプリケーションからの動的な情報表示を行うレイアウトマネジメント用のミドルウェアへのアクセスを全て拒否したり、アクセスの一部を制限したりする一方、音声入力部１８２等を用いた音声認識用のミドルウェアへのアクセスは許可する。また、停車中であり負荷状態が“低”の場合は、すべてのミドルウェアへのアクセスを許可するといったことが考えられる。

上述のレイアウトマネジメントについて補足説明を行う。レイアウトマネジメント用のミドルウェアにより、図７（ａ）に示すような表示操作部１８０等の画面３０にアプリケーションの情報提示を行う。図７（ａ）は情報提示なし、図７（ｂ）は情報提示領域３１を極小ウィンドウで表示する場合、図７（ｃ）は情報提示領域３１を１／４ウィンドウで表示する場合、図７（ｄ）は情報提示領域３１を１／２ウィンドウで表示する場合、図７（ｅ）は情報提示領域３１をフルウィンドウで表示する場合を示す。

このうち走行中に表示が許可されるのは、図７（ａ）及び図７（ｂ）に示した表示方法とする。この場合、走行中は図７（ａ）から図７（ｂ）への画面切り替え（アプリケーションからの極小ウィンドウを使った動的な情報提示）と、図７（ｂ）から図７（ａ）への画面切り替え（極小ウィンドウの消去）のみが許可される。一方、それ以外の図７（ｃ）〜図７（ｅ）の情報提示領域３１を使った表示は拒否（制限）される。合わせて拒否されるミドルウェアを利用しようとしたアプリケーションは不正アプリとしてエラー処理されることとなる。

図３に示したアクセス許可判定部１４１は、負荷状態推定部１５により推定された図５に示すようなドライバーの負荷状態と、アクセスルール記憶部１４２に記憶されているドライバーの負荷状態に対応した図６に示すようなアクセスルールを用いて、アプリケーションからのミドルウェアへのアクセス可否を判定する。このとき、アプリケーションがアクセスルールによりアクセスが許可されているミドルウェアにアクセスしようとしている場合はアクセス許可判定部１４１はアクセス許可と判定する。一方、アプリケーションがアクセスルールに従わずに、アクセスルールによりアクセスが拒否されているミドルウェアにアクセスしようとしている場合には、アクセス許可判定部１４１はアクセス不可と判定する。

エラー処理実行部１４３は、アクセス許可判定部１４１によりアクセス不可と判定された場合にエラー処理を実行する。エラー処理実行部１４３は、例えばアプリケーションからミドルウェアへのアクセスを拒否したり、不正なアクセスがあった旨をドライバーに通知したりする。更に、エラー処理実行部１４３は、アクセスが拒否されたアプリケーションを強制的に終了し、アプリケーションをアプリケーション記憶部１２から完全に削除しても良い。

更に、エラー処理実行部１４３は、アプリケーション記憶部１２内にアクセスが拒否されたアプリケーションの作成者と同一作成者が作成したアプリケーションが存在する場合、そのアプリケーションも不正アプリと特定し、アプリケーション記憶部１２から削除しても良い。

ミドルウェア部１６は、アプリケーションが利用する高度な機能をある程度モジュール化したアプリケーション用のミドルウェアを記憶する。ミドルウェア部１６が記憶しているミドルウェアは、アクセス許可判定部１４１によりアクセスが許可された場合に実行される。

ハードウェア制御部１７は、アプリケーションやミドルウェアにより制御されるドライバを記憶し、ハードウェア１８である表示操作部１８０、音声出力部１８１、音声入力部１８２又は外部映像入力部１８３等を制御する。

＜車載機の動作＞
次に、本発明の第１の実施の形態に係る車載機１０のアプリケーション実行時の動作の一例を、図８のフローチャートを参照しながら説明する。

（イ）ステップＳ１１において、車載機１０のアプリケーション記憶部１２に記憶されているアプリケーションについてドライバーが実行を指示すると、アプリケーション実行部１３は該当するアプリケーションを実行する。その後、起動されたアプリケーションは、アプリケーション作成者によって作成された所定の動作を開始する。そして起動されたアプリケーションからミドルウェアへのアクセスが発生すると、ステップＳ１２に進む。

（ロ）ステップＳ１２において、アクセス許可判定部１４１が、負荷状態推定部１５により推定されたドライバーの負荷状態を取得する。ステップＳ１３において、アクセス許可判定部１４１が、負荷状態推定部１５により推定されたドライバーの負荷状態に対応するアクセスルールをアクセスルール記憶部１４２から取得する。ステップＳ１４において、アクセス許可判定部１４１が、負荷状態推定部１５から取得したドライバーの負荷状態と、アクセスルール記憶部１４２から取得したアクセスルールを用いて、アプリケーションからミドルウェアへのアクセスの可否を判定する。

（ハ）ステップＳ１４においてアクセスが許可された場合、ステップＳ１５に進み、アプリケーションが指定した処理を実行し、ステップＳ１６においてアプリケーションが終了するまで処理を継続する。

（ニ）一方、ステップＳ１４でアクセスが許可されない（拒否された）場合は、ステップＳ１７に進み、エラー時の処理を実行し、終了する。

＜エラー処理実行部の動作＞
次に、図８のステップＳ１７のエラー時の処理の詳細を、図９のフローチャートを参照しながら説明する。

（イ）図７のステップＳ１４でアクセスが不可と判定された場合、図９のステップＳ２１において、エラー処理実行部１４３は、アクセスが不可と判定されたアプリケーションを不正アプリと特定し、不正アプリからミドルウェアへのアクセスを拒否する。更に、ステップＳ２２において、エラー処理実行部１４３は、不正なアクセスがあった旨をドライバーに通知する。

（ロ）ステップＳ２３において、エラー処理実行部１４３が、不正アプリを強制的に終了する。ステップＳ２４において、エラー処理実行部１４３が、不正アプリをアプリケーション記憶部１２から完全に削除する。

（ハ）ステップＳ２５において、アプリケーション記憶部１２内に不正アプリの作成者と同一作成者が作成したアプリケーションが存在しているか検索する。存在する場合には、ステップＳ２６においてそのアプリケーションについてもアプリケーション記憶部１２から削除する。

本発明の第１の実施の形態によれば、ミドルウェアを経由してハードウェアを制御するソフトウェア構成となっている車載機１０において、アプリケーションからミドルウェアへアクセスする際に、ドライバーの負荷状態を用いてミドルウェアへのアクセス可否を判定することにより、不正アプリからミドルウェアへの不正アクセスを排除することができ、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる。

更に、車両情報、カメラ映像、ドライバーの生体信号の少なくともいずれかに基づいてドライバーの負荷状態を推定することにより、ドライバーの負荷状態と矛盾するアプリケーション動作を検出することができる。

更に、アクセス許可判定部１４１によりアクセス不可と判定された場合、許可されないアクセスを行おうとした不正アプリからミドルウェアへのアクセスを拒否することにより、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる。

更に、不正アプリから不正なアクセスがあった旨をドライバーに通知し、不正アプリを強制的に終了し、不正アプリをアプリケーション記憶部１２から削除することにより、被害の拡大を防止することができる。

更に、車載機１０内から不正アプリの作成者と同一作成者が作成したアプリケーションを削除することにより、被害の拡大を防止することができる。

（第２の実施の形態）
＜セキュリティシステムの構成＞
本発明の第１の実施の形態では、不正アプリ検出後の対応として、不正アプリを検出した車載機で閉じる場合を説明したが、本発明の第２の実施の形態では、不正検出後のエラー処理として、サーバー経由で該当する全車載機に情報を伝え、不正アプリを完全に排除する場合を説明する。

本発明の第２の実施の形態では、図１０に示すように、車載機を搭載している車両１で検出された不正アプリに関する情報を、データセンター２を介して他車両１ａ，１ｂ，１ｃにも通知し、まだ被害の発生していない他車両１ａ，１ｂ，１ｃにおいても不正アプリを削除する。

本発明の第２の実施の形態に係るセキュリティシステムは、図１１に示すように、車両１の車載機１０と、データセンター２と、他車両１ａ，１ｂ，１ｃの車載機（図示省略）を備える。

車載機１０のエラー処理実行部１４３は、データセンター２に不正アプリに関するアプリケーションＩＤ等の情報を通信部１１を介して送信する。データセンター２のアプリケーション管理部２２は、不正アプリに関する情報を受けてアプリケーション記憶部１２内の不正アプリに該当するアプリケーションを削除する。更に、アプリケーション管理部２２は、不正アプリに該当するアプリケーションをダウンロードした他車両１ａ，１ｂ，１ｃへ不正アプリに関する情報を通信部２３を介して送信する。各車両１ａ，１ｂ，１ｃに搭載されている車載機は、データセンター２から不正アプリに関する情報を受信し、不正アプリに該当するアプリケーションを削除する。

他の構成は、本発明の第１の実施の形態に係るセキュリティシステムの構成と実質的に同様であるので、重複した説明を省略する。

＜エラー処理実行部の動作＞
本発明の第２の実施の形態に係るエラー時の処理動作を図１２のフローチャートに示す。ステップＳ３１〜Ｓ３６の手順は、図９に示したエラー処理のステップＳ２１〜Ｓ２６の手順と実質的に同様であるので、重複した説明を省略する。ステップＳ３７において、エラー処理実行部１４３が、不正アプリに関する情報を通信部１１を介してデータセンター２に送信する。

＜データセンターの動作＞
次に、本発明の第２の実施の形態に係るデータセンター２が不正アプリに関する情報を受信した際の動作を図１３のフローチャートを参照しながら説明する。

（イ）ステップＳ４１において、データセンター２の通信部２３が、車載機１０から不正アプリに関する情報を受信すると、アプリケーション管理部２２が、アプリケーション記憶部２１に記憶されている該当するアプリケーションを削除する。

（ロ）ステップＳ４２において、アプリケーション管理部２２が、不正アプリの作成者と同一作成者のアプリケーションが存在するか否かを検索する。存在する場合には、ステップＳ４３に進み、アプリケーション管理部２２が該当するアプリケーションをアプリケーション記憶部２１から削除する。

（ハ）その後、ステップＳ４４において、アプリケーション管理部２２が、自ら記憶しているアプリケーションのダウンロード履歴から不正アプリをダウンロードした車載機を特定する。ステップＳ４５において、アプリケーション管理部２２が、特定された車載機に対し不正アプリに関する情報として不正アプリのアプリケーションＩＤを通信部２３を介して送信する。全車載機では不正アプリに関する情報を受けて該当するアプリケーションが存在する場合には削除される。なお、ステップＳ４５では、不正アプリに関する情報をデータセンター２からプッシュで送信したが、各車両１ａ，１ｂ，１ｃの車載機１０がダウンロードのため等でデータセンター２に接続した際に、不正アプリに関する情報を付加して送信するような形態であっても良い。

（ニ）ステップＳ４６において全車載機から削除結果を受信したか判定する。ステップＳ４７において反応の無い車載機については不正アプリに関する情報を再送信することにより、該当する全ての車載機から削除結果を受信するまで繰り返し不正アプリに関する情報を再送信する。該当する全ての車載機から削除結果を受信すれば終了する。

＜他車両の動作＞
次に、本発明の第２の実施の形態において、他車両１ａ，１ｂ，１ｃに搭載された車載機１０がデータセンター２から不正アプリに関する情報を受信した際の動作を、図１４のフローチャートを参照しながら説明する。

（イ）ステップＳ５１において、他車両１ａ，１ｂ，１ｃに搭載されている車載機１０は不正アプリに該当するアプリケーションがアプリケーション記憶部１２に存在するかアプリケーションＩＤを基に判定する。データセンター２は不正アプリのダウンロード履歴のある車載機１０に限定して不正アプリに関する情報を送っているが、ドライバーが何らかの理由で手動で不正アプリを削除した場合等には該当する不正アプリがアプリケーション記憶部１２に存在しない場合も考えられる。

（ロ）ステップＳ５１で不正アプリが存在すると判定された場合、ステップＳ５２に進み、車載機１０はアプリケーション記憶部１２に記憶されている不正アプリを全て削除する。なお、不正アプリの作成者と同一作成者が作成したアプリケーションを検索し、存在する場合は同一作成者が作成したアプリケーションも不正アプリとして削除しても良い。

（ハ）ステップＳ５３において、他車両１ａ，１ｂ，１ｃに搭載されている車載機１０から、「ＡＩＤ：○○削除、ＡＩＤ：××該当無し」といったように削除結果をデータセンター２へ通知する。一方、ステップＳ５１で不正アプリが存在しないと判定された場合でも、ステップＳ５３において全てのアプリケーションＩＤについて該当無しを示す情報をデータセンター２に通知する。

本発明の第２の実施の形態によれば、アプリケーションからミドルウェアを経由してハードウェアを制御するソフトウェア構成となっている車載機において、アプリケーションがミドルウェアへアクセスする際に、ドライバーの負荷状態を用いてミドルウェアへのアクセスを許可するか否かを判定することにより、不正アプリによるミドルウェアへの不正アクセスを排除することができ、ドライバーの負荷状態と矛盾するアプリケーション動作を未然に防止することができる。

更に、データセンター２内の不正アプリを削除することで、他の車載機が不正アプリに該当するアプリケーションを新たにダウンロードできなくなることで、被害の拡大を防止することができる。

更に、データセンター２から全ての車載機に対して不正アプリに関する情報を伝え、全ての車載機から不正アプリに該当するアプリケーションを削除できることで、被害の拡大を防止することができる。

（その他の実施の形態）
上記のように、本発明は第１及び第２の実施の形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

例えば、図１１に示した車載機１０のエラー処理実行部１４３が、データセンター２に不正アプリに関する情報を送信する際、アクセス許可部１４によりアクセス不可と判定されたときのセンサ情報及びドライバーの負荷状態等を併せて送信しても良い。データセンター２は、不正アプリに関する情報とセンサ情報及びドライバーの負荷状態等とを用いてアクセス許可部１４と同様な手順等でシミュレーションを行い、アクセス許可部１４により不正アプリと判定されたアプリケーションが本当に不正アプリか、即ち不正アプリと同一のアプリケーションからミドルウェアへのアクセス可否を再度判定しても良い。これにより、アプリケーションが不正か否かをより正確に判定することができる。

このように、本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。したがって、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

１，１ａ，１ｂ，１ｃ…車両
２…データセンター
１０…車載機
１１，２３…通信部
１２，２１…アプリケーション記憶部
１３…アプリケーション実行部
１４…アクセス許可部
１５…負荷状態推定部
１６…ミドルウェア部
１７…ハードウェア制御部
１８…ハードウェア
１９…センサ部
２２…アプリケーション管理部
１４１…アクセス許可判定部
１４２…アクセスルール記憶部
１４３…エラー処理実行部

Claims (8)

1. アプリケーションがミドルウェアを経由してハードウェアを制御するソフトウェア構成の車載機であって、
   前記アプリケーションを記憶するアプリケーション記憶部と、
   前記アプリケーションを実行するアプリケーション実行部と、
   ドライバーの負荷状態を推定する負荷状態推定部と、
   前記ミドルウェアを記憶するミドルウェア部と、
   前記ドライバーの負荷状態に応じたアクセスルールを記憶するアクセスルール記憶部と、
   前記アプリケーションが前記ミドルウェアにアクセスする際に、前記負荷状態推定部により推定されたドライバーの負荷状態及び前記アクセスルールを用いて、前記アプリケーションの前記ミドルウェアへのアクセス可否を判定するアクセス許可判定部
   とを備えることを特徴とする車載機。
2. 前記負荷状態推定部は、車両情報、カメラ映像、前記ドライバーの生体信号の少なくともいずれかに基づいて前記ドライバーの負荷状態を推定することを特徴とする請求項１に記載の車載機。
3. 前記アクセス許可判定部によりアクセス不可と判定された場合、前記許可されないアクセスを行おうとした不正アプリからミドルウェアへのアクセスを拒否するエラー処理実行部を更に備えることを特徴とする請求項１又は２に記載の車載機。
4. 前記エラー処理実行部は、前記不正アプリから不正なアクセスがあった旨をドライバーに通知し、前記不正アプリを強制的に終了し、前記不正アプリを前記アプリケーション記憶部から削除することを特徴とする請求項３に記載の車載機。
5. 前記エラー処理実行部は、前記不正アプリの作成者と同一作成者が作成したアプリケーションを削除することを特徴とする請求項３又は４に記載の車載機。
6. 請求項１〜４のいずれか１項に記載の車載機と、
   前記車載機がダウンロード可能な複数のアプリケーションを管理するデータセンター
   とを備え、
   前記アクセス許可判定部によりアクセス不可と判定された場合、前記車載機が、前記許可されないアクセスを行おうとした不正アプリに関する情報を前記データセンターに送信し、
   前記データセンターが、前記不正アプリに関する情報に基づいて前記データセンターが保持している不正アプリに該当するアプリケーションを削除することを特徴とするセキュリティシステム。
7. 前記車載機が、前記データセンターから前記不正アプリに関する情報を受信した場合、前記不正アプリに該当するアプリケーションを前記アプリケーション記憶部から削除し、削除結果を前記データセンターに送信することを特徴とする請求項６に記載のセキュリティシステム。
8. 前記車載機が、前記データセンターに前記不正アプリに関する情報、及び前記アクセス許可判定部によりアクセス不可と判定されたときの前記ドライバーの負荷状態を送信し、
   前記データセンターが、前記不正アプリに関する情報及び前記ドライバーの負荷状態を用いて前記不正アプリから前記ミドルウェアへのアクセス可否を判定することを特徴とする請求項６又は７に記載のセキュリティシステム。

Images