JP7426640B1 - 監視装置及び監視方法 - Google Patents

Abstract

２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、監視装置は、２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、監視装置は、第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部（ＶＭ４１１）と、第２仮想マシンの構成情報を取得する構成情報取得部と、コマンドに含まれる識別子からコマンドの特性を参照し、構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定する監視プログラム制御部（ＶＭ４１２）と、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する異常対応部（ＶＭ４１５）と、を備える。

Description

本開示は、例えばコマンドなどを監視する監視装置および監視方法に関する。

特許文献１の監視装置は、仮想ソフトウェア上の監視用の仮想マシンを用いて、仮想ソフトウェア上の監視対象の仮想マシンを監視する。例えば、監視装置は、所定の時間間隔ごとに、監視用の仮想マシンから監視対象の仮想マシンおよびハイパーバイザを検証し、その検証結果を取得する。

特開２０１９－１４４７８５号公報

本開示は、検知漏れがないようにコマンドを監視することができる監視装置などを提供する。

本開示の一態様に係る監視装置は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、前記監視装置は、前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、前記第２仮想マシンの構成情報を取得する構成情報取得部と、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。また、記録媒体は、非一時的な記録媒体であってもよい。

本開示の監視装置は、検知漏れがないようにコマンドを監視することができる。

本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施の形態並びに明細書および図面に記載された構成によってそれぞれ提供されるが、その利点および効果を得るために必ずしも全ての構成が提供される必要はない。

図１は、実施の形態における監視システムの全体構成図である。 図２は、実施の形態における車載システムの構成図を示す図である。 図３は、実施の形態における統合ＥＣＵの構成図である。 図４は、実施の形態における統合ＥＣＵの一部の構成を詳細に示すブロック図である。 図５は、実施の形態における仮想コマンドの一例を示す図である。 図６は、実施の形態における仮想マシンの構成情報の一例を示す図である。 図７は、実施の形態における仮想マシンのシステム状態の一例を示す図である。 図８は、実施の形態における監視仮想マシンの処理シーケンスの一例を示す図である。 図９は、実施の形態における監視プログラムの決定処理のフローチャートの一例を示す図である。 図１０は、実施の形態における監視プログラムの呼び出し処理のフローチャートの一例を示す図である。 図１１は、実施の形態における監視プログラムのタイムアウト時間の決定処理のフローチャートの一例を示す図である。 図１２は、実施の形態における監視プログラムの決定処理のフローチャートの他の一例を示す図である。 図１３は、実施の形態における監視プログラムの順序の決定及び監視プログラムの実行処理のフローチャートの一例を示す図である。 図１４は、実施の形態における異常対応処理のフローチャートの一例を示す図である。 図１５は、実施の形態におけるグルーピングログの一例を示す図である。 図１６は、実施の形態におけるグルーピングログの一例を示す図である。 図１７は、実施の形態における監視結果表示の一例を示す図である。 図１８は、実施の形態における監視結果表示の一例を示す図である。 図１９は、変形例における統合ＥＣＵの一部の構成を詳細に示すブロック図である。 図２０は、変形例における監視仮想マシンの処理シーケンスの一例を示す図である。 図２１は、変形例における監視プログラムの分担処理のフローチャートの一例を示す図である。 図２２は、変形例における分担の決定テーブルの一例を示す図である。

（本開示の基礎となった知見）
上記特許文献１の監視装置では、監視用の仮想マシンが乗っ取られない限り、他の仮想マシンの異常を検知できるが、定期的な検証であるため、検証のインターバル期間における不正なファイル操作またはネットワーク通信に対応することが難しく、検知の漏れが生じる。

このような課題を解決するために、本開示の一態様に係る監視装置は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、前記監視装置は、前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、前記第２仮想マシンの構成情報を取得する構成情報取得部と、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える。

これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。

また、さらに、前記第２仮想マシンのシステム状態を取得するシステム状態取得部を備え、前記監視プログラム制御部は、さらに前記システム状態に応じて、前記１以上の監視プログラムの実行方法を決定してもよい。

これによれば、さらに、第２仮想マシンのシステム状態に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの状態に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。

また、前記コマンドの特性は、前記コマンドの送信元または送信先の仮想マシン、前記コマンドの送信元または送信先の電子制御装置、前記コマンドの送信方向、前記コマンドに含まれるファイル操作のアクセス先、前記コマンドに含まれるファイル操作の種類、前記送信元または前記送信先の仮想マシンのＯＳ（Operating System）種別、前記送信元または前記送信先の仮想マシンの外部接続機能の有無、前記コマンドのＡＳＩＬ、及び、前記コマンドの車両制御への影響の少なくとも１つであってもよい。

このため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。

また、前記システム状態は、前記監視装置を備える車両の走行状態、前記車両の走行モード、前記仮想マシンのシステム負荷、前記コマンドの処理におけるシステム負荷、前記仮想マシンのネットワーク接続状態、前記仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである。

また、前記監視プログラムの実行方法は、前記監視プログラムが有効であるか否か、前記監視プログラムの呼び出し方法、前記監視プログラムに設定されているタイムアウト時間、及び、前記監視プログラムの実行順序の少なくとも１つであってもよい。

これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができる。

また、前記異常対応部は、さらに、前記コマンドの特性に応じて前記コマンドの異常を示すログを集約または集計してもよい。

このため、集約または集計した異常を分析に利用することができる。

また、前記監視プログラム制御部は、前記１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、前記簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出してもよい。

また、さらに、２以上の前記監視プログラム制御部を備え、前記コマンドに対する前記１以上の監視プログラムは、前記コマンドの送信先が前記仮想化プラットフォーム上の仮想マシンであると判定された場合に、前記２以上の監視プログラム制御部のうち、前記コマンドに含まれる識別子及び前記構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定されてもよい。

このため、コマンドに含まれる識別子及び構成情報に基づいて、監視処理を２以上の監視プログラム制御部で分担することができる。よって、遅延を抑えることができる。

また、前記２以上の前記監視プログラム制御部は、前記第２仮想マシンのシステム状態に応じて前記１以上の監視プログラムの実行方法を決定してもよい。

また、前記２以上の前記監視プログラム制御部のうち、第１監視プログラム制御部は、前記コマンドに第１識別子を付与し、第２監視プログラム制御部は、前記コマンドに第１識別子が付与されているか否かに応じて、前記１以上の監視プログラムの実行方法を決定してもよい。

本開示の一態様に係る監視方法は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置による監視方法であって、前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する一の仮想マシンにて動作し、前記監視方法は、前記一の仮想マシンと異なる仮想マシンにて動作するプロセスが送信または受信するコマンドを取得し、前記仮想マシンの構成情報を取得し、前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記１以上の監視プログラムの実行方法を決定し、前記監視プログラムの監視結果を取得して、異常を通知する。

これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置および接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

また、各図は、模式図であり、必ずしも厳密に図示されたものではない。また、各図において、同じ構成部材については同じ符号を付している。

（実施の形態）
［監視システムの全体構成図］
図１は、実施の形態における監視システムの全体構成図である。

監視システムは、監視サーバー１０と、車載システム２０とを備える。監視サーバー１０と車載システム２０とは、外部ネットワーク３０を介して接続される。

外部ネットワーク３０は、例えば、インターネットである。外部ネットワーク３０の通信方法は、有線であっても無線であってもよい。また、無線通信方式は既存技術であるＷｉ－Ｆｉ（登録商標）や、３Ｇ／ＬＴＥ（Long Term Evolution）やＢｌｕｅｔｏｏｔｈ（登録商標）、Ｖ２Ｘ通信方式であってもよい。

監視サーバー１０は、車載システム２０から車載システム２０のセキュリティ状態に関する情報である監視結果を取得して、グラフィカルユーザーインターフェースを用いて監視結果を表示する装置である。監視サーバー１０は、例えば、セキュリティオペレーションセンターにて、セキュリティ分析官が監視結果を確認して、車載システム２０において異常が発生した場合にソフトウェア更新などの対策を検討する際に利用される。

車載システム２０は、通信の制御、車両の制御、及び、映像の出力などを実施し、車載システム２０のセキュリティ状態を監視し、監視サーバー１０へセキュリティ状態の監視結果を通知する装置である。図１では、車載システム２０は１台のみ記載しているが、１以上の車載システム２０それぞれが、監視サーバー１０へセキュリティ状態の監視結果を送信する。車載システム２０の詳細は後述する。

［車載システム２０の全体構成図］
図２は、実施の形態における車載システムの構成図を示す図である。

車載システム２０は、統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂと、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとを備える。

統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００とは、ネットワークプロトコルの一種のＣＡＮ（Control Area Network）であるＣＡＮ４０を介して接続される。ここで利用されるネットワークプロトコルは、ＣＡＮに限らずに、ＣＡＮ－ＦＤや、ＦｌｅｘＲａｙプロトコルなどの車載システムで利用されるネットワークプロトコルであってもよい。

また、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂとは、ＣＡＮ４１を介して接続される。

また、統合ＥＣＵ２００と、ＺｏｎｅＥＣＵ５００とは、ネットワークプロトコルの一種のＥｔｈｅｒｎｅｔ（商標登録）のプロトコルであるイーサネット５０を介して接続される。イーサネット５０は、例えば、ＳＯＭＥ／ＩＰ（Scalable Service-Oriented MiddlewarE over IP）プロトコルである。ここで利用されるネットワークプロトコルは、ＳＯＭＥ／ＩＰでなくとも、ＳＯＭＥ／ＩＰ－ＳＤや、ＣＡＮ－ＸＬなど車載システムで利用されるネットワークプロトコルであってもよい。

また、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂとは、イーサネット５１を介して接続される。イーサネット５１は、イーサネット５０と同じネットワークプロトコルであってもよいし、異なるネットワークプロトコルであってもよい。

また、統合ＥＣＵ２００と、監視サーバー１０とは、外部ネットワーク３０を介して接続される。

統合ＥＣＵ２００は、外部ネットワーク３０、ＣＡＮ４０及びイーサネット５０を介してメッセージを送受信する通信制御と、ＣＡＮ４０及びイーサネット５０を介してゲートウェイＥＣＵ３００及びＺｏｎｅＥＣＵ５００へ車両の制御を指示する車両制御と、インフォテイメントシステムやインストルメントパネルへの映像出力とを実施するＥＣＵである。また、統合ＥＣＵ２００は、統合ＥＣＵ２００のセキュリティ状態を監視し、監視サーバー１０へ監視結果を通知するＥＣＵである。なお、本実施の形態における統合ＥＣＵ２００は、監視装置の一例であって、その詳細は後述する。

ゲートウェイＥＣＵ３００は、統合ＥＣＵ２００と、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。

ステアリングＥＣＵ４００ａは、車両に搭載されるステアリングによる操舵を制御するＥＣＵである。

ブレーキＥＣＵ４００ｂは、車両に搭載されるブレーキを制御するＥＣＵである。

車載システム２０は、ステアリングＥＣＵ４００ａ及びブレーキＥＣＵ４００ｂの他に、車両のエンジンやボディを制御するＥＣＵを用いて車両の走る、曲がる、止まるといった制御を実現する。

ＺｏｎｅＥＣＵ５００は、統合ＥＣＵ２００と、フロントカメラＥＣＵ６００ａ及びリアカメラＥＣＵ６００ｂとの間で送受信されるメッセージを仲介するＥＣＵである。

フロントカメラＥＣＵ６００ａは、車両の前方に搭載され、車両の前方を撮影するカメラの映像を取得するＥＣＵである。

リアカメラＥＣＵ６００ｂは、車両の後方に搭載され、車両の後方を撮影するカメラの映像を取得するＥＣＵである。

図２では、フロントカメラＥＣＵとリアカメラＥＣＵのみが記載されているが、ＧＰＳなどの各種センサー情報を収集するＥＣＵを用いて、自動運転やアダプティブクルーズコントロール、自動駐車などの先進運転支援機能を実現してもよい。

［統合ＥＣＵの構成図］
図３は、実施の形態における統合ＥＣＵ２００の構成図である。統合ＥＣＵ２００は、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００と、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００と、仮想化プラットフォームＶＰ１００と、監視アプリＡ４００と、監視仮想マシンＶＭ４００とを備える。なお、以下では、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００を総称してアプリケーションと呼ぶことがある。また、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００と、監視仮想マシンＶＭ４００とを総称して仮想マシンと呼ぶことがある。

仮想化プラットフォームＶＰ１００は、ハイパーバイザ等の仮想ソフトウェア基盤であり、１以上の仮想マシンを実行及び管理するソフトウェアである。一般に、ハイパーバイザは、タイプ１と呼ばれるベアメタル型ハイパーバイザと、タイプ２と呼ばれるホスト型とに区別される。組み込みシステムでは、一般に、ハイパーバイザによる処理のオーバーヘッドを考慮して、タイプ１が用いられる。タイプ１のハイパーバイザは、コードサイズが小さいため、脆弱性を含む可能性が低く、アプリケーションや仮想マシンと比較して信頼できると想定できる。

実施の形態では、仮想化システムがタイプ１のハイパーバイザにより実現される例について説明するが、仮想化システムは、タイプ２のハイパーバイザにより実現されてもよい。

外部仮想マシンＶＭ１００は、外部アプリＡ１００を動作させるオペレーティングシステムである。外部アプリＡ１００は、外部ネットワーク３０を介して監視サーバー１０と通信するアプリケーションソフトウェアプログラムである。

制御仮想マシンＶＭ２００は、制御アプリＡ２００を動作させるオペレーティングシステムである。制御アプリＡ２００は、ＣＡＮ４０を介してゲートウェイＥＣＵ３００と通信し、車載システム２０を備える車両の走行に関する動作を制御するアプリケーションソフトウェアプログラムである。

映像仮想マシンＶＭ３００は、映像アプリＡ３００を動作させるオペレーティングシステムである。映像アプリＡ３００は、イーサネット５０を介してＺｏｎｅＥＣＵ５００と通信し、カメラの映像などを取得し、インフォテイメントシステムやインストルメントパネル、ヘッドアップディスプレイに映像を出力するアプリケーションソフトウェアプログラムである。また、カメラ映像は自動運転などの先進運転支援機能を実現するための情報としても利用される。

監視仮想マシンＶＭ４００は、仮想ドライバを用いて監視アプリＡ４００を動作させるオペレーティングシステムである。監視アプリＡ４００は、例えば、監視仮想マシンＶＭ４００以外の仮想マシン、仮想化プラットフォーム１００などを監視するアプリケーションソフトウェアプログラムである。

なお、本実施の形態における統合ＥＣＵ２００では、例えば、準仮想化技術(virtio)が用いられている。この準仮想化技術は、仮想化プラットフォーム１００上の仮想マシンへ標準的なインタフェースを提供する技術であり、仮想化プラットフォーム１００が接続する物理デバイス(ストレージ、ネットワークデバイスなど)と高速な通信を可能にする。

なお、図３では記載が省略されているが、燃料や給電状態、給油状態を管理する機能、事故などシステム異常が発生した場合に緊急アラートを発呼する機能、車両診断を制御する機能、外部デバイス接続を監視する機能が統合ＥＣＵ２００に搭載されてもよい。

なお、外部仮想マシンＶＭ１００はサードパーティアプリのダウンロードや、Ｗｉ－ＦｉやＢｌｕｅｔｏｏｔｈなど外部ネットワークとの接続があるため、攻撃者に乗っ取られる可能性が比較的高い。制御仮想マシンＶＭ２００は自動車の走る、止まる、曲がるなど走行に関する制御をおこなうコマンドを送受信するため、コマンドのリアルタイム性が必要とされる。映像仮想マシンＶＭ３００は、ディスプレイを制御するため、カメラや車速の表示など一定のリアルタイム性が必要であり、外部ネットワークとの接続がないため、乗っ取られる可能性は比較的低い。このため、映像仮想マシンＶＭ３００については、送信時のコマンドよりも受信時コマンドの監視が必要とされる。これらから、外部仮想マシンが送信元である通信は詳細な監視が必要であり、制御仮想マシンが送信元または送信先である場合は、リアルタイム性を達成するために、簡易な監視が望ましい。

［統合ＥＣＵの構成図の詳細］
図４は、実施の形態における統合ＥＣＵ２００の一部の構成を詳細に示すブロック図である。

外部仮想マシンＶＭ１００は、コマンドの送受信を実行するコマンド送受信部ＶＭ１０１を備える。コマンド送受信部ＶＭ１０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ１０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。

制御仮想マシンＶＭ２００は、コマンドの送受信を実行するコマンド送受信部ＶＭ２０１を備える。コマンド送受信部ＶＭ２０１は、制御仮想マシンＶＭ２００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ２０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。

映像仮想マシンＶＭ３００は、コマンドの送受信を実行するコマンド送受信部ＶＭ３０１を備える。コマンド送受信部ＶＭ３０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへコマンドを送信する。また、コマンド送受信部ＶＭ３０１は、外部仮想マシンＶＭ１００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。

監視仮想マシンＶＭ４００の監視アプリＡ４００は、コマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、コマンド送信部ＶＭ４１６、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８を備える。

コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信する。コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、つまり、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、及び、映像仮想マシンＶＭ３００のうちの少なくとも１つの対象仮想マシン（第２仮想マシン）において動作するプロセスが送信または受信するコマンドを取得する。

監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１により取得されたコマンドに含まれる識別子からコマンドの特性を参照して、コマンドの特性を特定する。そして、監視プログラム制御部ＶＭ４１２は、システム構成取得部ＶＭ４１８により取得された対象仮想マシンの構成を示す構成情報、及び、コマンドの特性に応じて、１以上の監視プログラムの実行方法を決定する。監視プログラム制御部ＶＭ４１２は、さらに、システム状態取得部ＶＭ４１７により取得された、対象仮想マシンのシステム状態に応じて、１以上の監視プログラムの実行方法を決定してもよい。なお、１以上の監視プログラムの実行方法の詳細については後述する。

簡易監視プログラムＶＭ４１３は、コマンド受信部ＶＭ４１１により取得されたコマンドの簡易的な監視を行うプログラムの一例である。簡易監視プログラムＶＭ４１３は、例えば、パケットのヘッダフィールドをチェックし、許可リストでフィルタリングするＦｉｒｅｗａｌｌを行うプログラムであってもよいし、パケットの統計情報のみを取得して、通信ペアごとの通信量から異常を判定するフロー検知を行うプログラムであってもよい。つまり、簡易的な監視は、例えば、Ｆｉｒｅｗａｌｌ、フロー検知などである。

詳細監視プログラムＶＭ４１４は、コマンド受信部ＶＭ４１１により取得されたコマンドの詳細な監視を行うプログラムの一例である。詳細監視プログラムＶＭ４１４は、例えば、コマンドのペイロードに異常が含まれているか否かを判定するDeep packet inspectionを行うプログラムであってもよい。つまり、詳細な監視は、例えば、Deep packet inspectionなどである。

なお、監視アプリＡ４００は、簡易監視プログラムＶＭ４１３及び詳細監視プログラムＶＭ４１４を備えるとしたが、これに限らずに、種類が異なる複数の監視プログラムを備えていればよい。例えば、監視アプリＡ４００は、ファイルアクセス監視プログラム及びネットワーク監視プログラムを備えてもよい。ファイルアクセス監視プログラムは、ファイルアクセスに関するコマンドを監視するプログラムである。ファイルアクセス監視プログラムは、例えば、特定の仮想マシンが読み書き可能なファイルパスを許可リストとして保持して、許可リストに保持されているファイルパス以外の読み出し及び書き込みを異常と判定する処理を行うプログラムであってもよい。この場合、ファイルアクセス監視プログラムとしては、コマンドの種別に応じて、具体的な検知ルールを用いた監視プログラムが利用できる。ネットワーク監視プログラムは、ネットワークを介して授受するデータに関するコマンドを監視するプログラムである。

また、簡易監視プログラムＶＭ４１３と詳細監視プログラムＶＭ４１４は、保持するルールが異なる同一の監視プログラムであってもよい。

異常対応部ＶＭ４１５は、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する。

コマンド送信部ＶＭ４１６は、コマンドの監視結果に応じて、当該コマンドを監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどへ送信する。コマンド送信部ＶＭ４１６は、コマンドの監視結果に異常が含まれていれば当該コマンドを当該コマンドの宛先へ送信せず、コマンドの監視結果に異常が含まれていなければ当該コマンドを当該コマンドの宛先へ送信する。

システム状態取得部ＶＭ４１７は、対象仮想マシンのシステム状態を取得する。システム状態の詳細は後述する。

システム構成取得部ＶＭ４１８は、対象仮想マシンの構成情報を取得する。システム構成取得部ＶＭ４１８は、構成情報取得部の一例である。構成情報の詳細は後述する。

仮想化プラットフォームＶＰ１００は、物理インタフェースＶＰ１０１を備える。物理インタフェースＶＰ１０１は、監視サーバー１０と、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、映像仮想マシンＶＭ３００、及び、監視仮想マシンＶＭ４００との間の通信を制御する。

［仮想コマンド］
図５は、実施の形態における仮想コマンドの一例を示す図である。

仮想コマンドは、例えば図５に示すように、シーケンス番号などの番号と、コマンド種別用のヘッダと、ヘッダｈ１、ヘッダｈ２、およびペイロードとを含む。コマンド種別用のヘッダは、コマンド種別として例えばファイル操作、パケット送信、パケット受信などを示す。ヘッダｈ１は、仮想コマンドの送信先を示す。ヘッダｈ２は、仮想コマンドの送信元を示す。送信先または送信元は、ストレージデバイスであってもよく、外部ＥＣＵであってもよい。ペイロードには、ファイルパス、データ、ステアリング制御のデータ、制御値、アップデート内容、バイナリデータなどが含まれる。なお、ファイル操作には、データの読み取り要求または書き込み要求の２種類があり、ファイル操作の種類を識別するための情報がヘッダｈ１に格納されてもよい。

［仮想マシンの構成情報］
図６は、実施の形態における仮想マシンの構成情報の一例を示す図である。構成情報は、コマンドに含まれる識別子毎に、関連するシステムの構成情報を取得するためのテーブルである。

仮想マシンの構成情報は、例えば図６に示すように、仮想マシンを識別する識別子と、仮想マシンのＯＳ（Operating System）種別と、ＡＳＩＬ（Automotive Safety Integrity Level）と、外部接続機能と、タイムアウト時間と、呼び出し方と、ディスプレイ表示機能とを含む。ＡＳＩＬは、自動車の安全レベルを示す。外部接続機能は、仮想マシンが外部デバイスとの間で通信接続可能か否かを示す。タイムアウト時間は、監視プログラムの処理に設定されるタイムアウト時間を示す。呼び出し方は、監視プログラムをコマンドの送受信処理に対して直列で処理するか、並列で処理するかを示す。つまり、直列で処理する場合、監視プログラムがコマンドに対して実行された後に、コマンドの送受信処理が実行される。並列で処理する場合、コマンドに対する監視プログラムの実行と、コマンド送受信処理とが並列で処理される。ディスプレイ表示機能は、仮想マシンが表示機能を有するか否かを示す。

構成情報のうち、ＯＳ種別及び外部接続機能は、攻撃者の乗っ取られやすさの判断に用いられてもよい。ＡＳＩＬは、リアルタイム性の判断に用いられてもよい。ＡＳＩＬは、Ｄ、Ｃ、Ｂ、Ａ、ＱＭの順に高いレベルに設定され、高いほどリアルタイム性が必要と判断されてもよい。タイムアウト時間は、監視プログラムのタイムアウト時間の設定に用いられる。呼び出し方は、監視プログラムの呼び出し方の決定に用いられる。タイムアウト時間及び呼び出し方は、識別子ごとではなくリアルタイム性に基づいて決定されてもよい。ディスプレイ表示機能は、異常検知時に表示するために用いられてもよい。異常発生が疑われ、かつ、表示機能を有する仮想マシンは、異常を表示する処理を実行してもよい。システムの更新にともなって、仮想マシンの構成情報には、追加、削除、及び、変更のいずれかが行われる可能性がある。この場合であっても、監視プログラム制御部は、更新された構成情報を示すテーブルを参照すればよい。

［仮想マシンのシステム状態］
図７は、実施の形態における仮想マシンのシステム状態の一例を示す図である。仮想マシンのシステム状態は、仮想マシン毎のシステム状態を取得して保持するデータベースである。システム状態は、各仮想マシンに問い合わせることで得られてもよいし、仮想化プラットフォームＶＰ１００に問い合わせることで得られてもよい。システム状態は、問い合わせて得られた情報に基づいて更新されてもよい。

仮想マシンのシステム状態は、例えば、図７に示すように、仮想マシンを識別する識別子と、仮想マシンの起動状態と、システム負荷と、仮想コマンド負荷と、ネットワーク状態と、走行状態と、走行モードと、セキュリティ異常とを含む。仮想マシンの起動状態は、仮想マシンが起動済み（つまり起動中）であるか、仮想マシンが停止中であるかを示す。起動状態は、異常対応部ＶＭ４１５で仮想マシンを再起動した場合に、再起動完了したか確認するために用いられてもよい。仮想マシンのシステム状態は、監視装置を備える車両の走行状態、車両の走行モード、仮想マシンのシステム負荷、コマンドの処理におけるシステム負荷、仮想マシンのネットワーク接続状態、仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである。

システム負荷は、ＣＰＵ及びメモリの少なくとも一方の使用率である。システム負荷は、低い場合に詳細な監視プログラムをＯＮにし、高い場合にＯＦＦにする判断で用いられてもよい。システム負荷は、例えば、低、中、及び、高のいずれかであるかを示す。中は、低よりも負荷が高いことを示し、高は、中よりも負荷が高いことを示す。システム負荷は、上記の３段階の場合に限らずに、低、高の２段階で示されてもよい。この場合、高は、低よりも負荷が高いことを示す。

仮想コマンド負荷は、仮想コマンドに関する処理の負荷である。仮想コマンド負荷が高いことは、監視プログラムを並列で呼び出す、または、複数の監視プログラムで処理を分担するという判断に用いられてもよい。また、仮想コマンド負荷が低いことは、監視プログラムを直列で呼び出しても、詳細監視プログラムを呼び出しても仮想コマンドの遅延等の影響が小さいと判断されてもよい。仮想コマンド負荷は、例えば、低、中、及び、高の何れであるかを示す。中は、低よりも負荷が高いことを示し、高は、中よりも負荷が高いことを示す。仮想コマンド負荷は、上記の３段階の場合に限らずに、低、高の２段階で示されてもよい。この場合、高は、低よりも負荷が高いことを示す。

ネットワーク状態は、外部機器への通信接続が、接続済み（つまり接続中）であるか未接続であるかを示す。ネットワーク状態は、外部機器への通信機能を有する仮想マシンのみで示される。ネットワーク状態は、接続済みの場合に、乗っ取られやすいと判断して詳細な監視プログラムをＯＮにするための判断で用いられてもよい。

走行状態は、車両が走行中であるか、停止中であるかを示す。走行状態が走行中を示す場合、制御仮想マシンＶＭ２００への通信は安全影響があるため、監視プログラムは、リアルタイム性に影響を与えないように並列で呼び出されてもよい。走行状態が停止中を示す場合、安全影響がないので監視プログラムは呼び出されなくてもよい。一方で、走行状態が停止中を示す場合はシステム負荷が低いため、全ての監視プログラムが呼び出されてもよい。

走行モードは、車両が自動運転中であるか手動運転中であるかを示す。走行モードが自動車運転中を示す場合、制御仮想マシンＶＭ２００への通信は安全影響があるため、監視プログラムは、リアルタイム性に影響を与えないように並列で呼び出されてもよい。走行モードが手動運転中を示す場合、安全影響がないので監視プログラムは呼び出されなくてもよい。

セキュリティ異常は、セキュリティに関する異常が発生しているか、異常が発生していないか（つまり、正常か）を示す。セキュリティ異常は、簡易プログラムで異常であると判定された場合に、異常対応部ＶＭ４１５が該当仮想マシンを異常状態に設定し、異常状態の場合に詳細な監視プログラムを実行するために用いられてもよい。なお、仮想マシンごとのセキュリティ異常は、簡易プログラムの異常判定結果でなく、他のプログラムによる異常判定結果に基づいて設定されてもよい。例えば、仮想マシン内のＳＥＬｉｎｕｘ（Ｓｅｃｕｒｉｔｙ－Ｅｎｈａｎｃｅｄ Ｌｉｎｕｘ）などのアクセスコントロール機構によって特定の処理が拒否された場合に該当仮想マシンがセキュリティ異常状態に設定されてもよい。

［監視仮想マシンの処理シーケンス］
図８は、実施の形態における監視仮想マシンの処理シーケンスの一例を示す図である。

図８に示すように、コマンド受信部ＶＭ４１１は、監視仮想マシンＶＭ４００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信し、受信したコマンドを識別する（Ｓ１０１）。これにより、システム構成取得部ＶＭ４１８は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンの構成情報を取得する。また、システム状態取得部ＶＭ４１７は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンのシステム状態を取得してもよい。ステップＳ１０１により得られた、コマンドの識別子、仮想マシンの構成情報、及び、仮想マシンのシステム状態は、監視プログラム制御部ＶＭ４１２へ通知される。

次に、監視プログラム制御部ＶＭ４１２は、コマンドの識別子からコマンドの特性を参照し、通知された構成情報及びシステム状態と、コマンドの特性とに応じて、当該コマンドに対して実行すべき１以上の監視プログラムを決定する（Ｓ１０２）。具体的には、監視プログラム制御部ＶＭ４１２は、受信したコマンドに対して実行すべき１以上の監視プログラムのそれぞれについて実行するか否か（つまり、各監視プログラムのＯＮ／ＯＦＦ）を決定してもよい。監視プログラム制御部ＶＭ４１２は、例えば、外部接続する外部仮想マシンＶＭ１００に対するコマンドであれば全ての監視プログラムを実行すると決定してもよい。また、監視プログラム制御部ＶＭ４１２は、例えば、外部接続しない映像仮想マシンＶＭ３００に対するコマンドであれば一部の監視プログラムのみを実行し、必須でない処理を削減してもよい。また、監視プログラム制御部ＶＭ４１２は、例えば、受信時ならFirewallのみの簡易監視プログラムを実行し、送信時は簡易監視プログラム及び詳細監視プログラム（つまりFirewall＋ペイロード監視）を実行すると決定してもよい。つまり、仮想マシン単位ではなく通信単位で監視プログラムを変更してもよい。例えば、監視プログラム制御部ＶＭ４１２は、車両の制御に影響するコマンドに対してのみ監視プログラムを実行し、制御に影響しないコマンドに対しては監視プログラムを実行しなくてもよい。また、監視プログラム制御部ＶＭ４１２は、コマンドの種別がファイル操作である場合は、システム影響が小さい読み取り要求やシステム影響が大きい書き込み要求などのファイル操作の種類に応じて監視プログラムを変更してもよい。このように、脅威の大きさに応じて処理を削減できる。なお、ステップＳ１０２の具体例は、後述する。ここで、コマンドの特性は、コマンドの送信元または送信先の仮想マシン、コマンドの送信先または送信先の電子制御装置、コマンドの送信方向、コマンドに含まれるファイル操作のアクセス先、送信元または送信先の仮想マシンのＯＳ（Operating System）種別、送信元または送信先の仮想マシンの外部接続機能の有無、コマンドのＡＳＩＬ、及び、コマンドの車両制御への影響の少なくとも１つである。コマンドの特性は、監視装置を備える車両の走行状態、車両の走行モード、及び、システム状態の少なくとも１つを含んでいてもよい。

次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方法（つまり、呼び出し方）を決定する（Ｓ１０３）。監視プログラム制御部ＶＭ４１２は、例えば、受信したコマンドが、制御仮想マシンＶＭ２００に対するコマンドであれば監視プログラムを並列で呼び出すと決定し、外部仮想マシンＶＭ１００に対するコマンドであれば監視プログラムを直列で呼び出すと決定してもよい。これにより、遅延影響がない通信の異常に即時対応できる。なお、ステップＳ１０３の具体例は、後述する。

次に、監視プログラム制御部ＶＭ４１２は、監視プログラムのタイムアウト時間を決定する（Ｓ１０４）。監視プログラム制御部ＶＭ４１２は、例えば、受信したコマンドが、制御仮想マシンＶＭ２００に対するコマンドであればタイムアウト時間を短時間に設定し、外部仮想マシンＶＭ１００に対するコマンドであればタイムアウト時間を長時間に設定してもよい。これにより、通信遅延を保証できる。なお、ステップＳ１０４の具体例は、後述する。

次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの実行の順序を決定する（Ｓ１０５）。監視プログラム制御部ＶＭ４１２は、例えば、簡易監視プログラム（Firewall）で異常と判定された場合のみ、詳細監視プログラム（ペイロード監視）の実行を決定してもよいし、詳細監視プログラムの実行のスキップを決定してもよい。これにより、処理負荷の高い監視の処理回数を削減できる。なお、ステップＳ１０５の具体例は後述する。

次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうち実行すると決定された簡易監視プログラムＶＭ４１３の呼び出しを行う（Ｓ１０６）。そして、簡易監視プログラムＶＭ４１３による監視処理が実行される（Ｓ１０７）。

次に、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうち実行すると決定された詳細監視プログラムＶＭ４１４の呼び出しを行う（Ｓ１０８）。そして、詳細監視プログラムＶＭ４１４による監視処理が実行される（Ｓ１０９）。

次に、監視プログラム制御部ＶＭ４１２は、対応アプリの呼び出しを行う（Ｓ１１０）。これにより、異常対応部ＶＭ４１５は、異常対応処理を実行する（Ｓ１１１）。異常対応処理では、監視処理の監視結果に応じて、コマンドのロギング、コマンドのドロップ、仮想マシンの再起動、システムの再起動などが実行される。なお、ステップＳ１１１の詳細は後述する。

次に、監視プログラム制御部ＶＭ４１２は、受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信する（Ｓ１１２）。監視プログラム制御部ＶＭ４１２は、例えば、監視処理において正常と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信する。監視プログラム制御部ＶＭ４１２は、例えば、監視処理において以上と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、コマンド送信部ＶＭ４１６へ送信しなくてもよい。そして、コマンド送信部ＶＭ４１６は、監視プログラム制御部ＶＭ４１２から受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信する（Ｓ１１３）。

［監視プログラムの決定］
図９は、実施の形態における監視プログラムの決定処理（Ｓ１０２）のフローチャートの一例を示す図である。監視プログラムの決定処理では、対象の仮想マシンが外部仮想マシンＶＭ１００である場合、外部と通信可能であり外部から乗っ取られる可能性が高いため、外部仮想マシンＶＭ１００からの通信の詳細をチェックするように監視プログラムが決定されてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００にはリアルタイム性が要求されるため、監視プログラムによる監視処理がスキップされてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが映像仮想マシンＶＭ３００である場合、映像仮想マシンＶＭ３００は直接乗っ取られる可能性は低いので、受信するコマンドに対して詳細監視プログラムが実行されてもよい。

図９に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１２１）。

次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１２２）。

監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１２２でＡｎｄｒｏｉｄ）、ステップＳ１２３を実行し、当該ＯＳ種別がＬｉｎｕｘ（登録商標）である場合（Ｓ１２２でＬｉｎｕｘ）、ステップＳ１２７を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１２２でＲＴＯＳ）、ステップＳ１３１を実行する。

ステップＳ１２３において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する（Ｓ１２４）。

監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１２４で送信）、ステップＳ１２５を実行し、コマンドが受信されたコマンドである場合（Ｓ１２４で受信）、ステップＳ１２６を実行する。

ステップＳ１２５において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。

ステップＳ１２６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。

ステップＳ１２７において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する（Ｓ１２８）。

監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１２８で送信）、ステップＳ１２９を実行し、コマンドが受信されたコマンドである場合（Ｓ１２８で受信）、ステップＳ１３０を実行する。

ステップＳ１２９において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。

ステップＳ１２６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。

ステップＳ１３１において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＦＦに設定する。つまり、簡易監視プログラムを実行しないことが設定される。

次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する（Ｓ１３２）。つまり、詳細監視プログラムを実行しないことが設定される。

このようにして、取得したコマンドに対する仮想マシンのＯＳ種別と、コマンドが送信されたか受信されたかを示す、コマンドの送受信状態とに応じて、コマンドに対して、簡易監視プログラムを実行するか否か、及び、詳細監視プログラムを実行するか否かが決定されてもよい。

なお、外部のネットワークへの接続状態、走行状態、及び、走行モードの少なくとも１つに応じて簡易監視プログラムのＯＮ／ＯＦＦ及び詳細監視プログラムのＯＮ／ＯＦＦが判断されてもよい。例えば、外部のネットワークへ接続中であれば、外部仮想マシンＶＭ１００からのコマンドは疑わしいので、詳細監視プログラムがＯＮに設定されてもよい。また、走行中または自動運転中であれば、映像仮想マシンからのコマンドは安全に影響がある可能性があるため、詳細監視プログラムがＯＮに設定されてもよい。

［監視プログラムの呼び出し］
図１０は、実施の形態における監視プログラムの呼び出し処理（Ｓ１０３）のフローチャートの一例を示す図である。監視プログラムの呼び出し処理では、対象の仮想マシンが外部仮想マシンＶＭ１００である場合、外部と通信可能であり外部から乗っ取られる可能性が高いため、外部仮想マシンＶＭ１００からの通信の詳細をチェックするように監視プログラムが決定されてもよい。また、監視プログラムの決定処理では、対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００は直接乗っ取られる可能性が低いため、外部仮想マシンＶＭ１００、外部ＥＣＵ、外部デバイスなどから受信したコマンドの詳細をチェックするように監視プログラムが決定されてもよい。

図１０に示すように、監視プログラム制御部ＶＭ４１２は、コマンドを取得する（Ｓ１４１）。なお、ステップＳ１４１は、ステップＳ１２１と同じ処理であるため、省略されてもよい。

次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１４２）。なお、ステップＳ１４２は、ステップＳ１２２と同じ処理であるため、省略されてもよい。

監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１４２でＡｎｄｒｏｉｄ）、ステップＳ１４３を実行し、当該ＯＳ種別がＬｉｎｕｘである場合（Ｓ１４２でＬｉｎｕｘ）、ステップＳ１４６を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１４２でＲＴＯＳ）、ステップＳ１４９を実行する。

ステップＳ１４３において、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する。

監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１４３で送信）、ステップＳ１４４を実行し、コマンドが受信されたコマンドである場合（Ｓ１４３で受信）、ステップＳ１４５を実行する。

ステップＳ１４４において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。

ステップＳ１４５において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を直列に設定する。

ステップＳ１４６において、監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドであるか受信されたコマンドであるかを判定する。

監視プログラム制御部ＶＭ４１２は、コマンドが送信されたコマンドである場合（Ｓ１４６で送信）、ステップＳ１４７を実行し、コマンドが受信されたコマンドである場合（Ｓ１４６で受信）、ステップＳ１４８を実行する。

ステップＳ１４７において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。

ステップＳ１４８において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を直列に設定する。

ステップＳ１４９において、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムの呼び出し方を並列に設定する。

監視プログラムの呼び出し方が直列に設定される場合、コマンドを送信先に送信する前に監視処理を実行するため、異常検知した場合に即座にコマンドを停止できる。つまり、直列で監視プログラムを呼び出す場合、監視処理が終了するまでコマンドの送信が停止してしまう。一方で、監視プログラムの呼び出し方が並列に設定される場合、コマンドの監視処理を待たずにコマンドを送信先に送信することができる。

［監視プログラムのタイムアウト時間の決定］
図１１は、実施の形態における監視プログラムのタイムアウト時間の決定処理（Ｓ１０４）のフローチャートの一例を示す図である。監視プログラムのタイムアウト時間の決定処理では、監視対象の仮想マシンが制御仮想マシンＶＭ２００である場合、制御仮想マシンＶＭ２００にはリアルタイム性が要求されるため、監視プログラムによる監視処理のタイムアウト時間が短時間に設定されてもよい。

図１１に示すように、監視プログラム制御部ＶＭ４１２は、コマンドを取得する（Ｓ１５１）。なお、ステップＳ１５１は、ステップＳ１２１、ステップＳ１４１と同じ処理であるため、省略されてもよい。

次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元または送信先の仮想マシンのＯＳ種別を判定する（Ｓ１５２）。なお、ステップＳ１５２は、ステップＳ１２２及びステップＳ１４２と同じ処理であるため、省略されてもよい。

監視プログラム制御部ＶＭ４１２は、コマンドの送信元または送信先の仮想マシンのＯＳ種別がＡｎｄｒｏｉｄである場合（Ｓ１５２でＡｎｄｒｏｉｄ）、ステップＳ１５３を実行し、当該ＯＳ種別がＬｉｎｕｘである場合（Ｓ１５２でＬｉｎｕｘ）、ステップＳ１５４を実行し、当該ＯＳ種別がＲＴＯＳである場合（Ｓ１５２でＲＴＯＳ）、ステップＳ１５５を実行する。

ステップＳ１５３において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を長時間に設定する。

ステップＳ１５４において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を長時間に設定する。

ステップＳ１５５において、監視プログラム制御部ＶＭ４１２は、監視処理のタイムアウト時間を短時間に設定する。

タイムアウト時間は、短時間に設定されることで、最大遅延を短くできるため低遅延を保証できるが、監視処理が終わらない可能性もある。一方で、タイムアウト時間は、長時間に設定されることで、監視処理に時間を多く使えるが、コマンド送信に時間がかかるため遅延が大きくなる可能性がある。

［監視プログラムの決定（別の例）］
図１２は、実施の形態における監視プログラムの決定処理（Ｓ１０２）のフローチャートの他の一例を示す図である。

図１２に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１６１）。

次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのセキュリティ異常があるか否かを判定する（Ｓ１６２）。

監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのセキュリティ異常があると判定した場合（Ｓ１６２でＹｅｓ）、ステップＳ１６３を実行し、取得したコマンドの送信元の仮想マシンのセキュリティ異常がないと判定した場合（Ｓ１６２でＮｏ）、ステップＳ１６５を実行する。

ステップＳ１６３において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する（Ｓ１６４）。つまり、詳細監視プログラムを実行することが設定される。

ステップＳ１６５において、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのシステム処理負荷が高いか低いかを判定する。

監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンのシステム処理負荷が低いと判定した場合（Ｓ１６５で低）、ステップＳ１６６を実行し、取得したコマンドの送信元の仮想マシンのシステム処理負荷が高いと判定した場合（Ｓ１６５で高）、ステップＳ１６８を実行する。

ステップＳ１６６において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＮに設定する。つまり、簡易監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する（Ｓ１６７）。つまり、詳細監視プログラムを実行することが設定される。

ステップＳ１６８において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムをＯＦＦに設定する。つまり、簡易監視プログラムを実行しないことが設定される。

次に、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みであるか否かを判定する（Ｓ１６９）。

監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みでないと判定した場合（Ｓ１６９でＮｏ）、ステップＳ１７０を実行し、取得したコマンドの送信元の仮想マシンが外部ネットワークに接続済みであると判定した場合（Ｓ１６９でＹｅｓ）、ステップＳ１７１を実行する。

ステップＳ１７０において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＦＦに設定する。つまり、詳細監視プログラムを実行しないことが設定される。

ステップＳ１７１において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムをＯＮに設定する。つまり、詳細監視プログラムを実行することが設定される。

ステップＳ１７０またはステップＳ１７１が終了すると、監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳか否かを判定する（Ｓ１７２）。

監視プログラム制御部ＶＭ４１２は、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳである場合（Ｓ１７２でＹｅｓ）、ステップＳ１７３を実行し、取得したコマンドの送信元の仮想マシンまたは送信先の仮想マシンのＯＳ種別がＲＴＯＳでない場合（Ｓ１７２でＮｏ）、監視プログラムの決定処理を終了する。

ステップＳ１７３において、監視プログラム制御部ＶＭ４１２は、車両の走行状態が走行中であるか停止中であるかを判定する。

監視プログラム制御部ＶＭ４１２は、車両の走行状態が走行中であると判定した場合（Ｓ１７３で走行中）、ステップＳ１７４を実行し、車両の走行状態が停止中であると判定した場合（Ｓ１７３で停止中）、ステップＳ１７６を実行する。

ステップＳ１７４において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラム及び詳細監視プログラムをＯＮに設定する。つまり、簡易監視プログラム及び詳細監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方を並列に決定する（Ｓ１７５）。ステップＳ１７５が終了するとステップＳ１７６が実行される。

ステップＳ１７６において、監視プログラム制御部ＶＭ４１２は、車両の走行モードが自動運転であるか手動運転であるかを判定する。

監視プログラム制御部ＶＭ４１２は、車両の走行モードが自動運転であると判定した場合（Ｓ１７６で自動運転）、ステップＳ１７７を実行し、車両の走行モードが手動運転であると判定した場合（Ｓ１７６で手動運転）、監視プログラムの決定処理を終了する。

ステップＳ１７７において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラム及び詳細監視プログラムをＯＮに設定する。つまり、簡易監視プログラム及び詳細監視プログラムを実行することが設定される。

次に、監視プログラム制御部ＶＭ４１２は、監視プログラムの呼び出し方を並列に決定する（Ｓ１７８）。ステップＳ１７８が終了すると監視プログラムの決定処理を終了する。

［監視プログラムの順序の決定］
図１３は、実施の形態における監視プログラムの順序の決定及び監視プログラムの実行処理（Ｓ１０５～Ｓ１０９）のフローチャートの一例を示す図である。

図１３に示すように、監視プログラム制御部ＶＭ４１２は、コマンド受信部ＶＭ４１１からコマンドを取得する（Ｓ１８１）。なお、ステップＳ１８１は、ステップＳ１２１、ステップＳ１４１、及び、ステップＳ１５１と同じ処理であるため、省略されてもよい。

次に、監視プログラム制御部ＶＭ４１２は、複数の監視プログラムが直列で呼び出されるか否かを判定する（Ｓ１８２）。

監視プログラム制御部ＶＭ４１２は、複数の監視プログラムが直列で呼び出されないと判定した場合（Ｓ１８２でＮｏ）、ステップＳ１８３を実行し、複数の監視プログラムが直列で呼び出されると判定した場合（Ｓ１８２でＹｅｓ）、ステップＳ１８４を実行する。なお、複数の監視プログラムが直列で呼び出されない場合とは、１つの監視プログラムが呼び出される場合と、複数の監視プログラムが並列で呼び出される場合とを含む。

ステップＳ１８３において、監視プログラム制御部ＶＭ４１２は、ＯＮに設定された監視プログラム（簡易監視プログラム及び詳細監視プログラムの少なくとも一方）を実行する。

ステップＳ１８４において、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムを実行する。

次に、監視プログラム制御部ＶＭ４１２は、簡易監視プログラムによる監視処理の監視結果が異常であるか否かを判定する（Ｓ１８５）。

監視プログラム制御部ＶＭ４１２は、簡易監視プログラムによる監視処理の監視結果が異常であると判定した場合（Ｓ１８５でＹｅｓ）、ステップＳ１８６を実行し、簡易監視プログラムによる監視処理の監視結果が異常でない（つまり正常である）と判定した場合（Ｓ１８５でＮｏ）、監視プログラムの順序の決定処理を終了する。

ステップＳ１８６において、監視プログラム制御部ＶＭ４１２は、詳細監視プログラムを実行する。

このように、監視プログラムの順序の決定処理を実行することで、例えば、簡易監視プログラムによる監視結果が異常の場合のみ詳細監視プログラムを実行するため、より詳細な異常を検出することができる。

なお、簡易監視プログラムによる監視結果が異常の場合には異常を確定させることで、詳細監視プログラムの実行をスキップしてもよい。これにより、異常が発生したことを通知するまでに要する時間を削減することができる。

［異常対応処理］
図１４は、実施の形態における異常対応処理（Ｓ１１１）のフローチャートの一例を示す図である。

図１４に示すように、異常対応部ＶＭ４１５は、監視処理における監視結果を取得する（Ｓ１９１）。

次に、異常対応部ＶＭ４１５は、監視結果が１以上異常であるか否かを判定する（Ｓ１９２）。

異常対応部ＶＭ４１５は、監視結果が１以上異常であると判定した場合（Ｓ１９２でＹｅｓ）、ステップＳ１９３を実行し、監視結果が１以上異常でない、つまり、異常がなかった場合（Ｓ１９２でＮｏ）、異常対応処理を終了する。なお、異常応答処理の要否はこのように閾値（１以上）によって判断してもよいし、多数決で判断してもよいし、統計処理アルゴリズムによって判断をしてもよい。さらに、仮想マシンのシステム状態に含まれる、仮想マシンの起動状態と、システム負荷と、仮想コマンド負荷と、ネットワーク状態と、走行状態と、走行モードと、セキュリティ異常のうち少なくとも１つを考慮して判断してもよい。これにより、信頼性と確実性の高い異常対応処理を実現できる。

ステップＳ１９３において、異常対応部ＶＭ４１５は、異常を含む監視結果のログをグルーピングして記憶する。つまり、グルーピングログを記憶する。グルーピングログの詳細は後述する。

次に、異常対応部ＶＭ４１５は、監視結果による異常が詳細監視プログラムの監視処理により検出された異常であるか否かを判定する（Ｓ１９４）。

異常対応部ＶＭ４１５は、監視結果による異常が詳細監視プログラムの監視処理により検出された異常であると判定した場合（Ｓ１９４でＹｅｓ）、ステップＳ１９５を実行し、監視結果による異常が詳細監視プログラムの監視処理により検出された異常でない（つまり簡易監視プログラムの監視処理により検出された異常である）と判定した場合（Ｓ１９４でＮｏ）、異常対応処理を終了する。

ステップＳ１９５において、異常対応部ＶＭ４１５は、取得したコマンドをドロップさせる（つまり、コマンドを利用しないように処理する）。例えば、コマンドを破棄してもよいし、コマンドが利用できないことを示す情報（フラグ）を付与してもよい。コマンドが利用できないことを示す情報（フラグ）が付与されたコマンドは、仮想マシン、他の機器などに利用されない。

次に、異常対応部ＶＭ４１５は、異常を通知して、例えば、表示機能を有する仮想マシン（映像仮想マシンＶＭ３００）に発生した異常を含むＵＩを表示させる（Ｓ１９６）。

なお、異常対応部ＶＭ４１５は、簡易監視及び詳細監視の両方において異常であり、確実に異常と判定できた場合のみコマンドをドロップしてもよい。

また、異常対応部ＶＭ４１５は、監視プログラムのフィルタリングルールを変更してもよい。これにより、次回から異常を検出されたコマンドをドロップできる。

また、異常対応部ＶＭ４１５は、異常なコマンドの送信元である仮想マシンを再起動または停止してもよい。これにより、攻撃プロセスを止めることができる。

また、異常対応部ＶＭ４１５は、異常な仮想マシンが一定数以上ある場合、システム全体を再起動してもよい。これにより、セキュアブートによりセーフティ起動が可能になる。

また、異常対応部ＶＭ４１５は、異常を通知して表示してもよい。異常対応部ＶＭ４１５は、仮想マシンが担当する車内のディスプレイに異常を表示させてもよいし、または、監視サーバー１０へ通知して監視サーバーにて異常を表示させてもよい。

また、異常対応部ＶＭ４１５は、前回の監視結果に基づいて、監視プログラムのＯＮ／ＯＦＦを決定してもよい。この場合、仮想マシンのシステム状態をセキュリティ状態が異常であると設定し、システム状態に応じて、監視プログラムのＯＮ／ＯＦＦを設定してもよい。

［グルーピングログ］
図１５及び図１６は、実施の形態におけるグルーピングログの一例を示す図である。

グルーピングログは、仮想マシン毎に当該仮想マシンに対するコマンドに異常があったことを記録したログである。図１５及び図１６に示すように、グルーピングログは、異常ＩＤと、異常名と、異常識別子と、仮想マシン識別子と、回数と、最終時刻とを含む。異常ＩＤは、異常名及び監視対象の仮想マシンが同じ異常であることを示す。異常名は、異常の種類の名称である。異常識別子は、異常を識別する情報である。仮想マシン識別子は、仮想マシンを識別する情報である。回数は、同じ異常識別子の異常が発生した回数を示す。最終時刻は、最後に該当する異常が発生した時刻を示す。

このように、グルーピングログによって、監視プログラム制御部ＶＭ４１２が検出した異常に関連するログ情報を抽出できるため、異常対応部ＶＭ４１５が監視サーバー１０へグルーピングログを送信し、監視サーバー１０のグラフィカルユーザーインターフェース上にグルーピングログを表示することで、分析官の分析を効率的に実現できる。

また、グルーピングログは監視プログラムで利用されてもよく、例えば、監視プログラムがグルーピングログを定期的に取得し、特定の仮想マシンの異常の発生回数が閾値を超えた場合に異常であると判定してもよい。

図１５は、仮想マシン識別子が１である仮想マシンにおいて発生した異常のグルーピングログの一例である。図１６は、仮想マシン識別子が２である仮想マシンにおいて発生した異常のグルーピングログの一例である。

［監視サーバーにおける異常の表示例］
図１７は、実施の形態における監視結果表示の一例を示す図である。

監視結果表示は、セキュリティ分析官へ監視情報を伝達するために利用されてもよい。監視結果表示は、監視サーバー１０が車載システム２０から監視結果を受信することで監視サーバーにより生成されてもよい。監視結果表示は、監視結果がグラフィカルユーザーインターフェースにおいて表現された表示である。

監視結果は、コマンドが正常であった場合には、コマンドに対応する仮想マシンを特定する識別子と、当該仮想マシンに対応するアプリの識別子と、正常判定した時刻とを含む。監視結果は、コマンドが異常であった場合には、コマンドに対応する仮想マシンを特定する識別子と、当該仮想マシンに対応するアプリの識別子と、異常判定した時刻とを含む。

なお、図１７において、太枠のブロックは異常であると判定された監視対象のソフトウェアを示し、細枠のブロックは正常であると判定された監視対象のソフトウェアを示す。

図１７において、統合ＥＣＵ２００の抽象化されたシステムアーキテクチャが表示されており、異常及び正常の一方（ここでは異常）の構成要素が強調されて区別できるように表現されており、構成要素の下部に対応する監視結果が表示されている。これにより、セキュリティ分析官は直感的に異常が発生した構成要素を理解することができるため、セキュリティ異常の解析を迅速に実施できる。

図１７に示される車両識別子は車両ごとに付与されるユニークな識別子である。ＥＣＵ識別子はＥＣＵごとに付与される識別子である。この場合、異常が検出された車両の車両識別子と、仮想化プラットフォームが搭載されたＥＣＵの識別子とが表示される。異常なコマンドの送信元は、システムアーキテクチャが表示された画面の上に強調表示されてもよい。また、異常検出時刻と検出した監視プログラムの名称が表示されてもよい。異常検知時刻は、異常通知のログに含まれ、監視プログラムの名称は、異常通知のログに含まれる識別子から参照される。これにより、監視サーバーのＧＵＩを用いて異常を分析するセキュリティ分析官が、異常が発生している箇所の特定と異常の内容を容易に把握できる。

［統合ＥＣＵにおける異常の表示例］
図１８は、実施の形態における監視結果表示の一例を示す図である。

図１８に示されるように、車両内のディスプレイ上に、異常な通信の送信元が制御するディスプレイの枠が強調表示されてもよい。これにより、ドライバが容易に異常と危険性を判断でき、車両を路肩に停止することができる。例えば、映像仮想マシンが異常な場合に、映像仮想マシンが制御するクラスターディスプレイと電子ミラーディスプレイとの外枠に赤枠を表示することで異常を通知してもよい。

［効果など］
本実施の形態に係る監視装置（統合ＥＣＵ２００）は、２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、監視装置は、２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、監視装置は、第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部ＶＭ４１１と、第２仮想マシンの構成情報を取得するシステム構成取得部ＶＭ４１８と、コマンドに含まれる識別子からコマンドの特性を参照し、構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定する監視プログラム制御部ＶＭ４１２と、監視プログラムの監視結果を取得して、監視結果に異常が含まれる場合に異常を通知する異常対応部ＶＭ４１５と、を備える。

これによれば、第２仮想マシンの構成情報及びコマンドの特性に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。

通常、コマンドには送受信のＬ２ 物理アドレスしか記載がないため、監視プログラム制御部では、アドレスの他の情報の取得はできない。統合ＥＣＵ２００において実現される複数の仮想マシンを監視する監視仮想マシンＶＭ４００は、仮想化環境上の監視プログラムであるため、監視対象の仮想マシンの構成情報とシステム状態とを取得できる。これらの情報によって、コマンドの送受信のアドレスから、どの仮想マシン（どのＯＳ）からの通信であるかを判定できる。さらに、仮想マシンの状態に応じて、処理を切り替えることができる。

従来技術では、監視結果のログを全て蓄積するが、どの仮想マシンからのログであるか識別ができないため、インシデントレスポンスの際の分析に時間を要する。本実施の形態にかかる異常対応部ＶＭ４１５は、仮想マシンの構成情報を用いることで、異常ログを仮想マシンごとに蓄積することができる。このため、インシデントレスポンスの際の分析に要する時間を削減することができる。また、異常なコマンドの送信元からどの仮想マシンが異常かわかるため、該当仮想マシンでの異常表示、再起動、停止などの異常に対処するための処理を実行できる。

例えば、監視装置（統合ＥＣＵ２００）は、さらに、第２仮想マシンのシステム状態を取得するシステム状態取得部ＶＭ４１７を備える。監視プログラム制御部ＶＭ４１２は、さらにシステム状態に応じて、１以上の監視プログラムの実行方法を決定する。

これによれば、さらに、第２仮想マシンのシステム状態に応じて１以上の監視プログラムの実行方法を決定するため、第２仮想マシンの状態に応じた適切な監視処理を実行することができる。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができ、コマンドへの監視処理を効率よく効果的に実行することができる。

例えば、コマンドの特性は、コマンドの送信元の仮想マシン、コマンドの送信先の仮想マシン、コマンドの送信方向、ファイルアクセス、送信元または送信先の仮想マシンのＯＳ（Operating System）種別、コマンドのＡＳＩＬ、監視装置を備える車両の走行状態、車両の走行モード、及び、システム状態の少なくとも１つである。このため、第２仮想マシンの特性及びコマンドの特性に応じた適切な監視処理を実行することができる。

また、監視プログラムの実行方法は、監視プログラムが有効であるか否か、監視プログラムの呼び出し方法、監視プログラムに設定されているタイムアウト時間、及び、監視プログラムの実行順序の少なくとも１つである。これにより、監視処理の処理負荷を調整でき、また、コマンドのリアルタイム性が考慮された監視処理を実現することができる。

また、異常対応部ＶＭ４１５は、さらに、コマンドの種別に応じてコマンドの異常を示すログを集約または集計することでグルーピングログを生成する。このため、集約または集計した異常を分析に利用することができる。

また、監視プログラム制御部ＶＭ４１２は、１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出す。例えば、簡易監視プログラムで異常が検知された場合に詳細監視プログラムを実行することで、異常についてより詳細な結果が得られるように処理されてもよいし、簡易監視プログラムで異常が検知された場合に詳細監視プログラムの実行をスキップすることで処理負荷を低減し、異常の通知までに要する時間を削減してもよい。

（変形例）
［統合ＥＣＵの構成の詳細］
図１９は、変形例における統合ＥＣＵ２００の一部の構成を詳細に示すブロック図である。

実施の形態と比較して監視仮想マシンＶＭ５００の構成が異なるため、監視仮想マシンＶＭ５００について説明する。

監視仮想マシンＶＭ５００は、第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、第１コマンド送信部ＶＭ５０３、第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、第２コマンド送信部ＶＭ５１３、簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８を備える。簡易監視プログラムＶＭ４１３、詳細監視プログラムＶＭ４１４、異常対応部ＶＭ４１５、システム状態取得部ＶＭ４１７、及び、システム構成取得部ＶＭ４１８の構成は、実施の形態の監視仮想マシンＶＭ４００が備える構成と同様であるため、同じ符号を付し説明を省略する。

監視仮想マシンＶＭ５００は、２つのコマンド受信部と、２つの監視プログラム制御部と、２つのコマンド送信部とを有する点が実施の形態の監視仮想マシンＶＭ４００と異なる。つまり、監視仮想マシンＶＭ５００は、コマンド受信部、監視プログラム制御部、及び、コマンド送信部を２組有する点が監視仮想マシンＶＭ４００と異なる。コマンド受信部、監視プログラム制御部、及び、コマンド送信部を２組有するため、２組に監視処理の役割分担をさせることでコマンドが遅延することを抑制できる。

第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、映像仮想マシンＶＭ３００用の処理を実行する。つまり、第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、映像仮想マシンＶＭ３００のプロセスで送信または受信されるコマンドに対する処理を実行する。第１コマンド受信部ＶＭ５０１、第１監視プログラム制御部ＶＭ５０２、及び、第１コマンド送信部ＶＭ５０３は、それぞれ、実施の形態のコマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、及び、コマンド送信部ＶＭ４１６と同様の機能を有する。

第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、外部仮想マシンＶＭ１００用の処理を実行する。つまり、第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、外部仮想マシンＶＭ１００のプロセスで送信または受信されるコマンドに対する処理を実行する。第２コマンド受信部ＶＭ５１１、第２監視プログラム制御部ＶＭ５１２、及び、第２コマンド送信部ＶＭ５１３は、それぞれ、実施の形態のコマンド受信部ＶＭ４１１、監視プログラム制御部ＶＭ４１２、及び、コマンド送信部ＶＭ４１６と同様の機能を有する。

映像仮想マシンＶＭ３００から外部仮想マシンＶＭ１００への仮想マシン間の内部通信である場合に、映像仮想マシンＶＭ３００からの送信時の監視プログラムの設定に基づいて、第１監視プログラム制御部ＶＭ５０２によって簡易監視プログラムと詳細監視プログラムが実行されてもよい。また、外部仮想マシンＶＭ１００の受信時の監視プログラム設定に基づいて、第１監視プログラム制御部ＶＭ５０２によって簡易監視プログラムと詳細監視プログラムが実行されてもよい。

この場合、同じコマンドに対して、同じ監視プログラムを実行することは非効率であるため、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２のうちの一方の監視プログラム制御部で監視処理を実行したり、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２の両方で処理を分担したりする。処理の分担は分担テーブルを用いて決定され、簡易監視プログラムはコマンドの送信側の仮想マシンに対応する監視プログラム制御部において実行され、詳細監視プログラムはコマンドの受信側の仮想マシンに対応する監視プログラム制御部において実行されるように分担処理することで、遅延を抑えられる。

［監視仮想マシンの処理シーケンス］
図２０は、変形例における監視仮想マシンの処理シーケンスの一例を示す図である。

図２０に示すように、第１コマンド受信部ＶＭ５０１または第２コマンド受信部ＶＭ５１１は、監視仮想マシンＶＭ５００以外の仮想マシン、外部ＥＣＵ、外部デバイスなどからコマンドを受信し、受信したコマンドを識別する（Ｓ１０１）。これにより、システム構成取得部ＶＭ４１８は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンの構成情報を取得する。また、システム状態取得部ＶＭ４１７は、コマンドに含まれる識別子に基づいて、コマンドを送信した仮想マシン、または、コマンドを受信した仮想マシンのシステム状態を取得してもよい。ステップＳ１０１により得られた、コマンドの識別子、仮想マシンの構成情報、及び、仮想マシンのシステム状態は、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２へ通知される。

次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、コマンドの識別子からコマンドの特性を参照し、通知された構成情報及びシステム状態と、コマンドの特性とに応じて、監視プログラムの分担を決定する（Ｓ２１１）。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、システム負荷の低いインタフェース側で、監視処理を実行するように監視処理を分担することで、負荷を軽減できる。

次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、１以上の監視プログラムのうち実行すると決定された簡易監視プログラムＶＭ４１３の呼び出しを行う（Ｓ１０６）。そして、簡易監視プログラムＶＭ４１３による監視処理が実行される（Ｓ１０７）。

次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、１以上の監視プログラムのうち実行すると決定された詳細監視プログラムＶＭ４１４の呼び出しを行う（Ｓ１０８）。そして、詳細監視プログラムＶＭ４１４による監視処理が実行される（Ｓ１０９）。

次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、対応アプリの呼び出しを行う（Ｓ１１０）。これにより、異常対応部ＶＭ４１５は、異常対応処理を実行する（Ｓ１１１）。異常対応処理では、監視処理の監視結果に応じて、コマンドのロギング、コマンドのドロップ、仮想マシンの再起動、システムの再起動などが実行される。なお、ステップＳ１１１の詳細は後述する。

次に、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、第１コマンド送信部ＶＭ５０３または第２コマンド送信部ＶＭ５１３へ送信する（Ｓ１１２）。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、監視処理において正常と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、送信先に対応するコマンド送信部へ送信する。第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２は、例えば、監視処理において以上と判定されたコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信するために、送信先に対応するコマンド送信部へ送信しなくてもよい。そして、送信先に対応するコマンド送信部は、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２から受信したコマンドを指定の宛先の仮想マシン、外部ＥＣＵ、外部デバイスなどに送信する（Ｓ１１３）。

なお、上記では、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２がステップＳ２１１、Ｓ１０６、Ｓ１０８、Ｓ１１０、及びＳ１１２の処理を行うとしたが、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２の少なくとも一方においてこれらの処理が行われればよい。

［監視プログラムの分担］
図２１は、変形例における監視プログラムの分担処理（Ｓ２１１）のフローチャートの一例を示す図である。

図２１に示すように、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、第１コマンド受信部ＶＭ５０１または第２コマンド受信部ＶＭ５１１において受信されたコマンドを取得する（Ｓ２２１）。

次に、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、取得したコマンドに基づいて、仮想マシン間の内部通信であるか否かを判定する（Ｓ２２２）。つまり第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、取得したコマンドの送信元及び送信先の両方が仮想マシンであるか否かを判定する。

第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、仮想マシン間の内部通信であると判定した場合（Ｓ２２２でＹｅｓ）、ステップＳ２２３を実行し、仮想マシン間の内部通信でないと判定した場合（Ｓ２２２でＮｏ）、監視プログラムの分担処理を終了する。

ステップＳ２２３において、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、仮想コマンドの負荷に応じて分担の決定テーブルを参照し、分担識別子を付与する。

次に、第１監視プログラム制御部ＶＭ５０２または第２監視プログラム制御部ＶＭ５１２は、分担識別子に従って決定した監視プログラムを実行する（Ｓ２２４）。

［分担の決定テーブル］
図２２は、変形例における分担の決定テーブルの一例を示す図である。

図２２に示すように、分担の決定テーブルは、分担識別子と、条件と、簡易監視プログラムを実行する監視プログラム制御部と、詳細監視プログラムを実行する監視プログラム制御部と、異常対応部とを含む。分担識別子は、４つの分担方法を特定する識別子である。条件は、仮想コマンド負荷に基づいて４つの分担方法のうちの１つを決定するための条件である。例えば、送信側の仮想コマンド負荷が閾値１より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、異常対応処理は第１監視プログラム制御部ＶＭ５０２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値１以上閾値２より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値２以上閾値３より低い場合、簡易監視プログラムは第１監視プログラム制御部ＶＭ５０２により実行され、詳細監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。また、例えば、送信側の仮想コマンド負荷が閾値３以上である場合、簡易監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、詳細監視プログラムは第２監視プログラム制御部ＶＭ５１２により実行され、異常対応処理は第２監視プログラム制御部ＶＭ５１２により実行される。

なお、図２２では仮想コマンド負荷に応じて分担方法を特定する方法を示したが、仮想コマンドの通信方向または送信先、送信元に応じて分担方法を特定してもよい。例えば、仮想コマンドを受信する第１監視プログラム制御部ＶＭ５０２にて簡易監視プログラムと詳細監視プログラムを実行し、仮想コマンドを送信する第２監視プログラム制御部ＶＭ５１２にて、異常対応処理を実行する。この場合、仮想コマンド負荷を参照することなく分担方法を決定できる。

また、第１監視プログラム制御部ＶＭ５０２にて仮想コマンドに分担識別子を付与することで、第２監視プログラム制御部ＶＭ５１２が仮想コマンドに付与された分担識別子を参照して分担方法を特定してもよい。この場合、第１監視プログラム制御部ＶＭ５０２が分担方法を任意に決定できる。なお、仮想コマンドに分担識別子を付与する方法以外にも第１監視プログラム制御部ＶＭ５０２と第２監視プログラム制御部ＶＭ５１２との間のデータ通信やデータ共有によって監視プログラムの分担方法を特定してもよく、監視プログラム間のデータ通信やデータ共有によって監視プログラムの分担方法を特定してもよい。この場合、仮想コマンドの特性と監視プログラムの特性とに応じて動的に分担方法を決定できる。

また、監視プログラムが複数の監視ルールを保持する場合、第１監視プログラム制御部ＶＭ５０２が実行する監視プログラムに第１のルールを適用し、第２監視プログラム制御部ＶＭ５１２が実行する監視プログラムが第２のルールを適用するという分担を実施してもよい。この場合、監視プログラムが一つであっても処理を分担できる。

［効果など］
変形例に係る監視装置（統合ＥＣＵ２００）は、２以上の監視プログラム制御部（例えば、第１監視プログラム制御部ＶＭ５０２及び第２監視プログラム制御部ＶＭ５１２）を備え、コマンドに対する１以上の監視プログラムは、コマンドの送信先が仮想化プラットフォーム上の仮想マシンであると判定された場合に、２以上の監視プログラム制御部のうち、コマンドに含まれる識別子及び構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定される。

例えば、２以上の監視プログラム制御部は、システム状態に応じて１以上の監視プログラムの実行方法を決定する。

例えば、２以上の監視プログラム制御部のうち、第１監視プログラム制御部は、コマンドに第１識別子を付与し、第２監視プログラム制御部は、コマンドに第１識別子が付与されているか否かに応じて、１以上の監視プログラムの実行方法を決定する。

このため、コマンドに含まれる識別子及び構成情報に基づいて、監視処理を２以上の監視プログラム制御部で分担することができる。よって、遅延を抑えることができる。

以上、本開示の監視装置について、上記実施の形態およびその変形例に基づいて説明したが、本開示は、その実施の形態および変形例に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を上記実施の形態および変形例に施したものも本開示に含まれてもよい。

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ（Central Processing Unit）またはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の監視装置などを実現するソフトウェアは、図８～図１４、図２０及び図２１のそれぞれに示すフローチャートまたはシーケンス図の各ステップをコンピュータに実行させるコンピュータプログラムである。

なお、以下のような場合も本開示に含まれる。

（１）上記の少なくとも１つの装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。そのＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、上記の少なくとも１つの装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（２）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

（３）上記の少なくとも１つの装置を構成する構成要素の一部または全部は、その装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（４）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ（Compact Disc）－ＲＯＭ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。

また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

本開示の監視装置は、例えば車両に搭載された電子機器などに適用することができる。

１０ 監視サーバー
２０ 車載システム
３０ 外部ネットワーク
４０、４１ ＣＡＮ
５０、５１ イーサネット
２００ 統合ＥＣＵ
３００ ゲートウェイＥＣＵ
４００ａ ステアリングＥＣＵ
４００ｂ ブレーキＥＣＵ
５００ ＺｏｎｅＥＣＵ
６００ａ フロントカメラＥＣＵ
６００ｂ リアカメラＥＣＵ
Ａ１００ 外部アプリ
Ａ２００ 制御アプリ
Ａ３００ 映像アプリ
Ａ４００ 監視アプリ
ＶＭ１００ 外部仮想マシン
ＶＭ１０１、ＶＭ２０１、ＶＭ３０１ コマンド送受信部
ＶＭ２００ 制御仮想マシン
ＶＭ３００ 映像仮想マシン
ＶＭ４００、ＶＭ５００ 監視仮想マシン
ＶＭ４１１ コマンド受信部
ＶＭ４１２ 監視プログラム制御部
ＶＭ４１３ 簡易監視プログラム
ＶＭ４１４ 詳細監視プログラム
ＶＭ４１５ 異常対応部
ＶＭ４１６ コマンド送信部
ＶＭ４１７ システム状態取得部
ＶＭ４１８ システム構成取得部
ＶＭ５０１ 第１コマンド受信部
ＶＭ５０２ 第１監視プログラム制御部
ＶＭ５０３ 第１コマンド送信部
ＶＭ５１１ 第２コマンド受信部
ＶＭ５１２ 第２監視プログラム制御部
ＶＭ５１３ 第２コマンド送信部
ＶＰ１００ 仮想化プラットフォーム
ＶＰ１０１ 物理インタフェース

Claims (11)

1. ２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置であって、
   前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する第１仮想マシンにて動作し、
   前記監視装置は、
   前記第１仮想マシンと異なる第２仮想マシンにて動作するプロセスが送信または受信するコマンドを受信するコマンド受信部と、
   前記第２仮想マシンの構成情報を取得する構成情報取得部と、
   前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記構成情報及び前記コマンドの特性に応じて前記１以上の監視プログラムの実行方法を決定する監視プログラム制御部と、
   前記監視プログラムの監視結果を取得して、前記監視結果に異常が含まれる場合に前記異常を通知する異常対応部と、を備える、
   監視装置。
2. さらに、
   前記第２仮想マシンのシステム状態を取得するシステム状態取得部を備え、
   前記監視プログラム制御部は、さらに前記システム状態に応じて、前記１以上の監視プログラムの実行方法を決定する
   請求項１に記載の監視装置。
3. 前記コマンドの特性は、前記コマンドの送信元または送信先の仮想マシン、前記コマンドの送信元または送信先の電子制御装置、前記コマンドの送信方向、前記コマンドに含まれるファイル操作のアクセス先、前記コマンドに含まれるファイル操作の種類、前記送信元または前記送信先の仮想マシンのＯＳ（Operating System）種別、前記送信元または前記送信先の仮想マシンの外部接続機能の有無、前記コマンドのＡＳＩＬ、及び、前記コマンドの車両制御への影響の少なくとも１つである
   請求項１に記載の監視装置。
4. 前記システム状態は、前記監視装置を備える車両の走行状態、前記車両の走行モード、前記仮想マシンのシステム負荷、前記コマンドの処理におけるシステム負荷、前記仮想マシンのネットワーク接続状態、前記仮想マシン内のセキュリティ異常の有無、及び、仮想コマンドのセキュリティ異常の有無の少なくとも１つである
   請求項２に記載の監視装置。
5. 前記監視プログラムの実行方法は、前記監視プログラムが有効であるか否か、前記監視プログラムの呼び出し方法、前記監視プログラムに設定されているタイムアウト時間、及び、前記監視プログラムの実行順序の少なくとも１つである
   請求項１から４のいずれか１項記載の監視装置。
6. 前記異常対応部は、さらに、前記コマンドの特性に応じて前記コマンドの異常を示すログを集約または集計する
   請求項１から４のいずれか１項に記載の監視装置。
7. 前記監視プログラム制御部は、前記１以上の監視プログラムのうちの簡易監視プログラムの監視結果に応じて、前記簡易監視プログラムよりも処理負荷が高い詳細監視プログラムを呼び出す
   請求項１から４のいずれか１項に記載の監視装置。
8. さらに、
   ２以上の前記監視プログラム制御部を備え、
   前記コマンドに対する前記１以上の監視プログラムは、前記コマンドの送信先が前記仮想化プラットフォーム上の仮想マシンであると判定された場合に、前記２以上の監視プログラム制御部のうち、前記コマンドに含まれる識別子及び前記構成情報に基づいて決定された１以上の監視プログラム制御部によって実行方法が決定される
   請求項１から４のいずれか１項に記載の監視装置。
9. 前記２以上の前記監視プログラム制御部は、前記第２仮想マシンのシステム状態に応じて前記１以上の監視プログラムの実行方法を決定する
   請求項８に記載の監視装置。
10. 前記２以上の前記監視プログラム制御部のうち、第１監視プログラム制御部は、前記コマンドに第１識別子を付与し、第２監視プログラム制御部は、前記コマンドに第１識別子が付与されているか否かに応じて、前記１以上の監視プログラムの実行方法を決定する
    請求項８に記載の監視装置。
11. ２以上の仮想マシンを動作させる仮想化プラットフォームにおける監視装置による監視方法であって、
    前記監視装置は、前記２以上の仮想マシンのうち、プロセスが送信または受信するコマンドを監視する１以上の監視プログラムが動作する一の仮想マシンにて動作し、
    前記監視方法は、
    前記一の仮想マシンと異なる仮想マシンにて動作するプロセスが送信または受信するコマンドを取得し、
    前記仮想マシンの構成情報を取得し、
    前記コマンドに含まれる識別子から前記コマンドの特性を参照し、前記１以上の監視プログラムの実行方法を決定し、
    前記監視プログラムの監視結果を取得して、異常を通知する
    監視方法。

Images