情報処理装置
【課題】多階層モデルでソフトウェアを構成した情報処理装置において、ソフトウェア動作に対する監視機能の独立性を高めるとともに、監視機能の層間の連携を高める。
【解決手段】多階層モデルでソフトウェアを構成した情報処理装置であって、各階層における動作を行なう複数のモジュールと、モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なう。
【解決手段】多階層モデルでソフトウェアを構成した情報処理装置であって、各階層における動作を行なう複数のモジュールと、モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なう。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関し、特に、多階層モデルでソフトウェアを構成した情報処理装置に関する。
【背景技術】
【０００２】
近年、組込み機器等の情報処理装置に対するディペンダビリティへの要求が高まっている。ディペンダビリティとは、情報処理装置の非機能要件を指し、例えば、リアルタイム性、信頼性、可用性、セキュリティ等を含む概念である。情報処理装置のディペンダビリティを確保するためには、情報処理装置の動作を監視し、異常発生時には、その対応処理を実施することが重要となる。このため、ソフトウェアに監視機能を組み込んでおくことが従来から行なわれている。
【０００３】
ところで、ソフトウェアが動作する情報処理装置では、オペレーティングシステム（以下「ＯＳ」と称す）上でアプリケーションを動作させたり、ＯＳ上にミドルウェアを搭載して、ミドルウェア上でアプリケーションを動作させたりするように、内部のソフトウェアを、多階層モデルで構成する場合が多い。以下では、各層のソフトウェア（ＯＳ、ミドルウェア、ソフトウェア）をモジュールと称する。
【０００４】
このような構成において、ソフトウェアに監視機能を設ける場合には、それぞれの層のモジュールにおいて独自の監視機能が組み込まれる。図１０は、内部のソフトウェアが多階層モデルで構成され、それぞれの層に監視機能を持たせた情報処理装置の構成例を示すブロック図である。
【０００５】
本図の例では、ハードウェア３００で動作するＯＳ３１０上にミドルウェア３２０を搭載し、ミドルウェア３２０上でアプリケーション３３０が動作するようになっている。ここで、ミドルウェア３２０は、ＯＳ３１０上で動作するアプリケーション実行環境であり、例えば、ＪａｖａＶＭ（登録商標）等が該当する。
【０００６】
そして、ＯＳ３１０は、ＯＳ監視機能部３１１を備え、ミドルウェア３２０は、ミドルウェア監視機能部３２１を備え、アプリケーション３３０は、アプリケーション監視機能部３３１を備えている。すなわち、各監視機能部は、ＯＳ３１０、ミドルウェア３２０、アプリケーション３３０に個別に組み込まれている。ただし、監視機能部が必要な層にのみ監視機能部を組み込む場合もある。
【０００７】
各監視機能部は、監視対象の状態、例えば、メモリ内容や動作履歴等を監視し、必要に応じて情報処理装置内部に記録したり、ネットワーク等を通じて情報処理装置外部に発信する等の処理を行なう。また、監視結果からモジュールに異常が発生したことが判明した場合は、異常対応の処理を実行する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平７−３０２２３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来のように、多階層モデルで構成されたソフトウェアの各層に個別に監視機能部を設けた場合には、情報処理装置全体の統括的な監視ができないという問題がある。
【００１０】
例えば、図１０において、アプリケーション３３０は、ミドルウェア３２０が提供する機能を用いて実現され、ミドルウェア３２０は、ＯＳ３１０が提供する機能を用いて実現される。このため、アプリケーション３３０の動作状態を詳細に知るためには、アプリケーション３３０の動作に関連したミドルウェア３２０の動作状態と、ＯＳ３１０の動作状態とを知る必要がある。このためには、各モジュールの監視機能部が連動して監視を行なわなければならないが、従来は、モジュール毎に独自の監視機能を設けているため、各モジュールの監視結果を関連付けることができない。
【００１１】
さらに、モジュール間で監視機能が連携していないために、いずれかの監視機能が監視対象モジュールの異常を検知した際の異常対象の処理内容が限られる場合が多い。これは、各モジュールで可能な異常対応処理は、通常、そのモジュールで処理可能なものと、その上層で動作するモジュールの制御に限定されるためである。例えば、アプリケーション３３０の異常により、情報処理装置の再起動が必要となった場合でも、アプリケーション３３０では、情報処理装置の再起動を行なえないことが多い。
【００１２】
また、多階層モデルで構成されたソフトウェアの各層に個別に監視機能部を組み込んだ場合には、監視機能が情報処理装置本来の機能に悪影響を与えるという問題もある。ここで、情報処理装置本来の機能とは、情報処理装置本来の使用目的を満たすための機能である。例えば、情報処理装置がプラント制御用コントローラであれば、情報処理装置本来の機能は、コントローラに接続されたプラントを構成する情報処理装置を制御する機能であり、コントローラの状態監視は、情報処理装置本来の機能には含まれない。
【００１３】
監視機能は、情報処理装置本来の機能には含まれないが、ＣＰＵ、メモリ、ネットワーク等の計算資源を、情報処理装置本来の機能と共有して動作する。このため、情報処理装置本来の機能の使用資源量は、監視機能の動作の影響を受ける。したがって、監視機能の動作によって、情報処理装置本来の機能の応答性やスループット等が悪化する場合がある。
【００１４】
さらに、多階層モデルで構成されたソフトウェアの各層に個別に監視機能を組み込んだ場合には、何らかの原因により情報処理装置本来の機能が暴走すると、監視機能も影響を受けるという問題がある。上述のように、監視機能と情報処理装置本来の機能とは、情報処理装置の計算資源を共有して動作する。このため、情報処理装置本来の機能が暴走して、情報処理装置の計算資源を占有してしまうと、監視機能は動作できず、監視を継続できなくなってしまう。
【００１５】
以上の問題は、監視機能が情報処理装置本来の機能に組み込まれており、従属性が高いのに加え、監視機能の層間の連携が十分でないことに起因すると考えられる。
【００１６】
そこで、本発明は、上述の問題を鑑みてなされたものであり、多階層モデルでソフトウェアを構成した情報処理装置において、ソフトウェア動作に対する監視機能の独立性を高めるとともに、監視機能の層間の連携を高めることを目的とする。
【課題を解決するための手段】
【００１７】
上記課題を解決するため、本発明の情報処理装置は、多階層モデルでソフトウェアを構成した情報処理装置であって、各階層における動作を行なう複数のモジュールと、前記モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、前記各監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なうことを特徴とする。
【００１８】
ここで、前記各監視部は、対応するモジュールの動作を監視した結果、異常を検出した場合は、当該監視部で対応可能であるかどうかを判定し、当該監視部で対応不可能と判定した際に、より下位の監視部に対して異常対応処理要求を行なうことができる。
【００１９】
また、前記各監視部は、対応するモジュールから、あらかじめ定められた形式の監視データを取得することで対応するモジュールの動作を監視することができる。
【００２０】
また、前記各モジュールは、上位のモジュールおよび当該モジュールに対応した監視部に対して、前記情報処理装置のリソースの割り当てを行なうことができる。このとき、前記各モジュールは、上位のモジュールと当該モジュールに対応した監視部とで、異なるリソースを割り当てることができる。
【００２１】
また、前記複数のモジュールとして、オペレーティングシステム、ミドルウェア、アプリケーションのうち、少なくとも２つを含むことができる。
【発明の効果】
【００２２】
本発明によれば、多階層モデルでソフトウェアを構成した情報処理装置において、ソフトウェア動作に対する監視機能の独立性を高めるとともに、監視機能の層間の連携を高めることができる。
【図面の簡単な説明】
【００２３】
【図１】本実施形態に係る情報処理装置の構成を示すブロック図である。
【図２】各資源管理部が行なう、情報処理装置の持つ資源の割り当ての例について説明する図である。
【図３】各監視部の状態監視の処理の流れを説明するフローチャートである。
【図４】アプリケーション監視部が、アプリケーションから監視要求を受けた場合、あるいは、アプリケーション監視部の任意の起動タイミングで実行する監視処理の流れを示すフローチャートである。
【図５】各監視部の異常判定処理の流れについて説明するフローチャートである。
【図６】アプリケーション監視部が、アプリケーションの異常対応処理を行なう場合の流れを示すフローチャートである。
【図７】応用例における情報処理装置の構成を示すブロック図である。
【図８】本応用例における情報処理装置による通信パケット受信処理の流れについて説明するフローチャートである。
【図９】異常判定処理の手順について説明するフローチャートである。
【図１０】多階層モデルで構成された従来の情報処理装置の構成を示すブロック図である。
【発明を実施するための形態】
【００２４】
本発明の実施の形態について図面を参照して説明する。図１は、本実施形態に係る情報処理装置の構成を示すブロック図である。本実施形態に係る情報処理装置は、内部のソフトウェアを、ＯＳ層、ミドルウェア層、アプリケーション層の多階層モデルで構成している。
【００２５】
そして、ＯＳ層は、ハードウェア資源管理部（Ｒ０）上で動作するＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）とを含み、ミドルウェア層は、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）とを含み、アプリケーション層は、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）と、アプリケーション監視部（Ｃ３）とを含んでいる。
【００２６】
本実施形態では、情報処理装置本来の機能を実現するＯＳ（Ｍ１）と、ミドルウェア（Ｍ２）と、アプリケーション（Ｍ３）とについて、それぞれの監視部、すなわち、ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）を独立させて設けおり、各監視部が互いに連携して、ＯＳ（Ｍ１）、ミドルウェア（Ｍ２）、アプリケーション（Ｍ３）の状態監視を行なう。
【００２７】
ここで、各監視部が監視するデータは、メモリ内容や動作履歴等の動作情報と、計算資源使用量等である。さらに、情報処理装置本来の機能に異常が発生した場合には、必要に応じて各監視部が連携して、異常対応処理を実行する。
【００２８】
以下に、本図における各ブロックについて説明する。
【００２９】
ハードウェア資源管理部（Ｒ０）は、ハードウェア１００のリソースを管理し、ハードウェア１００とソフトウェアとのやり取りを管理する。具体的には、情報処理装置が持つ計算資源を、ＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）に割り当て、それぞれの資源使用量を制限する。
【００３０】
ＯＳ資源管理部（Ｒ１）は、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）に資源を割り当て、それぞれの資源使用量を制限する。ＯＳ資源管理部（Ｒ１）が割り当て可能な資源の総量は、ハードウェア資源管理部（Ｒ０）により、ＯＳ（Ｍ１）に割り当てられた資源量から、ＯＳ（Ｍ１）自体の使用資源量を除いた量である。
【００３１】
ミドルウェア資源管理部（Ｒ２）は、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）とアプリケーション監視部（Ｃ３）に資源を割り当て、それぞれの資源使用量を制限する。ミドルウェア資源管理部（Ｒ２）が割り当て可能な資源の総量は、ＯＳ資源管理部（Ｒ１）により、ミドルウェア（Ｍ２）に割り当てられた資源量から、ミドルウェア（Ｍ２）自体の使用資源量を除いた量である。
【００３２】
ここで、ハードウェア資源管理部（Ｒ０）、ＯＳ資源管理部（Ｒ１）、ミドルウェア資源管理部（Ｒ２）の各資源管理部が行なう、情報処理装置の持つ資源の割り当ての例について、図２を参照して説明する。各資源管理部は、以下の処理を情報処理装置の起動時、すなわち、情報処理装置本来の機能と、後述する監視処理の実行前に実施する。
【００３３】
まず、ハードウェア資源管理部（Ｒ０）は、情報処理装置の持つ全資源を２つに分割し、ＯＳ層への割り当てとして、ＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）に資源を割り当てる。次に、ＯＳ資源管理部（Ｒ１）は、ＯＳ（Ｍ１）に割り当てられた資源の中から、ＯＳ（Ｍ１）自体の使用資源を除いた量を２つに分割し、ミドルウェア層への割り当てとして、ミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）に資源を割り当てる。そして、ミドルウェア資源管理部（Ｒ２）は、ミドルウェア（Ｍ２）に割り当てられた資源の中から、ミドルウェア（Ｍ２）自体の使用資源を除いた量を２つに分割し、アプリケーション層への割り当てとして、アプリケーション（Ｍ３）とアプリケーション監視部（Ｃ３）に資源を割り当てる。
【００３４】
図１のブロック図の説明に戻って、ＯＳ（Ｍ１）は、従来の一般的なＯＳ機能に加え、以下の特徴を有している。
１）ＯＳ資源管理部（Ｒ１）を有する。
２）ＯＳ監視部（Ｃ１）に対して、ＯＳ監視データを公開するインタフェースを有する。
３）必要に応じて、ＯＳ監視部（Ｃ１）に対して、ＯＳ監視要求を行なう。
【００３５】
ミドルウェア（Ｍ２）は、従来のミドルウェアの一般的な機能に加えて、以下の特徴を有している。
１）ミドルウェア資源管理部（Ｒ２）を有する。
２）ミドルウェア監視部（Ｃ２）に対して、ミドルウェア監視データを公開するインタフェースを有する。
３）必要に応じて、ミドルウェア監視部（Ｃ２）に対して、ミドルウェア監視要求を行なう。
【００３６】
アプリケーション（Ｍ３）は、従来のアプリケーションの一般的な機能に加えて、以下の特徴を有している。
１）アプリケーション監視部（Ｃ３）に対して、アプリケーション監視データを公開するインタフェースを有する。
２）必要に応じて、アプリケーション監視部（Ｃ３）に対して、アプリケーション監視要求を行なう。
【００３７】
ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）は、状態監視部（Ｃ０）を構成し、情報処理装置本来の機能の状態を監視する。
【００３８】
次に、各ブロック間でやり取りされるデータと要求について、再度図１を参照して説明する。
【００３９】
ＯＳ（Ｍ１）からＯＳ監視部（Ｃ１）に対しては、ＯＳ監視データ（Ｓ１）とＯＳ監視要求（Ｏ１）が送られる。ＯＳ監視データ（Ｓ１）は、ＯＳ（Ｍ１）の動作情報、例えば、メモリ内容や動作履歴等と、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）の資源使用量の情報を含むデータである。ＯＳ監視要求（Ｏ１）は、ＯＳ監視部（Ｃ１）に対するＯＳ監視の実行要求である。
【００４０】
ミドルウェア（Ｍ２）からミドルウェア監視部（Ｃ２）に対しては、ミドルウェア監視データ（Ｓ２）とミドルウェア監視要求（Ｏ２）が送られる。ミドルウェア監視データ（Ｓ２）は、ミドルウェア（Ｍ２）の動作情報、例えば、メモリ内容や動作履歴等と、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）の資源使用量の情報を含むデータである。ミドルウェア監視要求（Ｏ２）は、ミドルウェア監視部（Ｃ２）に対するミドルウェア監視の実行要求である。
【００４１】
アプリケーション（Ｍ３）からアプリケーション監視部（Ｃ３）に対しては、アプリケーション監視データ（Ｓ３）とアプリケーション監視要求（Ｏ３）が送られる。アプリケーション監視データ（Ｓ３）は、アプリケーション（Ｍ３）の動作情報、例えば、メモリ内容や動作履歴等を含むデータである。アプリケーション監視要求（Ｏ３）は、アプリケーション監視部（Ｃ３）に対するアプリケーション監視の実行要求である。
【００４２】
アプリケーション監視部（Ｃ３）からミドルウェア監視部（Ｃ２）に対しては、ミドルウェア監視要求（Ｏ２）と異常対応処理要求（Ｏ４）が送られる。異常対応処理要求（Ｏ４）は、異常対応処理の実行要求である。
【００４３】
ミドルウェア監視部（Ｃ２）からＯＳ監視部（Ｃ１）に対しては、ＯＳ監視要求（Ｏ１）と異常対応処理要求（Ｏ４）が送られる。
【００４４】
次に、ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）の各監視部が行なう処理について説明する。各監視部は、それぞれの監視対象の状態監視と、監視対象に異常が発生した際の異常対応処理を実行する。ここで、監視対象は、各監視部がそれぞれ監視するモジュールであり、ＯＳ監視部（Ｃ１）はＯＳ（Ｍ１）、ミドルウェア監視部（Ｃ２）はミドルウェア（Ｍ２）、アプリケーション監視部（Ｃ３）はアプリケーション（Ｍ３）である。
【００４５】
状態監視において、各監視部は、監視対象から監視データを取得し、この監視データを基に監視対象の異常を判定する。判定基準は、例えば、エラー発生の有無、メモリの値が特定の閾値を超過していなか等とすることができ、任意に定めることができる。
【００４６】
図３は、各監視部の状態監視の処理の流れを説明するフローチャートである。本図に示すように、本実施形態において監視データを取得するタイミングは３種類あり、以下のような判断が行なわれる。
【００４７】
すなわち、定周期や定時刻等の各監視部独自の起動タイミングであるかどうか（Ｓ１０１）、それぞれの監視対象から監視要求を受けたかどうか（Ｓ１０２）、上層の監視部から監視要求を受けたかどうか（Ｓ１０３）である。ただし、アプリケーション監視部（Ｃ３）は、上層がないため、（Ｓ１０３）の判断は行なわない。
【００４８】
これらの判断の結果、いずれかの条件を満たす場合には、監視対象から監視データを取得する（Ｓ１０４）。また、他層の監視部との連携した監視を実現するため、監視データ取得の際には、下層の監視部に対しても監視要求を行なう（Ｓ１０５）。これらの順序は、逆であってもよい。なお、ＯＳ監視部（Ｃ１）については、下層の監視部が存在しないため、下層への監視要求は行なわない。
【００４９】
そして、取得した監視データに基づいて、監視対象の異常判定を行なう（Ｓ１０６）。各監視部は、以上の監視処理を繰り返す（Ｓ１０７）。
【００５０】
図４は、監視部の状態監視処理のより具体的な例として、アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）から監視要求を受けた場合、あるいは、アプリケーション監視部（Ｃ３）の任意の起動タイミングで実行する監視処理の流れを示すフローチャートである。
【００５１】
アプリケーション監視部（Ｃ３）が、監視処理を開始すると、下位層であるミドルウェア監視部（Ｃ２）に、ミドルウェア監視要求を行なう（Ｓ２０１）。そして、アプリケーション（Ｍ３）からアプリケーション監視データを取得する（Ｓ２０２）。なお、ここでは、下位層に監視要求を行なってから、監視対象から監視データを取得するようにしている。そして、取得した監視データを基に、アプリケーション（Ｍ３）の異常判定を行なう（Ｓ２０３）。
【００５２】
また、アプリケーション監視部（Ｃ３）からミドルウェア監視要求を受けたミドルウェア監視部（Ｃ２）は、下位層であるＯＳ監視部（Ｃ１）に、ＯＳ監視要求を行なう（Ｓ２１１）。そして、ミドルウェア（Ｍ２）からミドルウェア監視データを取得し（Ｓ２１２）、取得した監視データを基に、ミドルウェア（Ｍ２）の異常判定を行なう（Ｓ２１３）。
【００５３】
また、ミドルウェア監視部（Ｃ２）からＯＳ監視要求を受けたＯＳ監視部（Ｃ２）は、ＯＳ（Ｍ１）からＯＳ監視データを取得する（Ｓ２３１）。ＯＳ監視部（Ｃ１）には、下位層がないため、監視要求は行なわない。そして、取得した監視データを基に、ＯＳ（Ｍ１）の異常判定を行なう（Ｓ２３２）。
【００５４】
状態監視の結果、監視対象に異常が発生したと判定した場合、各監視部は、あらかじめ定められた異常対応処理を実施する。ここで、各監視部が実行可能な異常対応処理は、属する層毎に異なる。例えば、情報処理装置の再起動は、通常、ＯＳ層でのみ可能であるため、ＯＳ監視部（Ｃ１）がＯＳ（Ｍ１）に指示することで実施する。また、ミドルウェアやアプリケーションの再起動は、通常、それぞれの動作環境であるＯＳ層とミドルウェア層でのみ可能であるため、ＯＳ監視部（Ｃ１）とミドルウェア監視部（Ｃ２）が各監視対象に指示することで実施する。
【００５５】
このように、監視部毎に可能な異常対応処理が異なるため、ある監視部が監視対象の異常を検知し、その監視部では対応処理を実行できない場合は、下層の監視部に異常対応処理要求を行なう。
【００５６】
図５は、各監視部の異常判定処理の流れについて説明するフローチャートである。各監視部は、取得した監視対象の監視データを基に異常判定を行ない、異常と判定した場合（Ｓ３０１：Ｙｅｓ）は、監視対象モジュールで対処可能かどうかを判定する（Ｓ３０２）。この判定は、例えば、異常内容と対処方法とを対応させたテーブル等をあらかじめ監視部内等に用意しておき、このテーブル等を参照することで行なうことができる。
【００５７】
その結果、監視対象のモジュールで対処可能な場合（Ｓ３０２：Ｙｅｓ）は、あらかじめ定められた異常対応処理を実行する（Ｓ３０３）。一方、監視対象のモジュールで対処可能でない場合（Ｓ３０２：Ｎｏ）は、下位層監視部に異常対応処理を要求する（Ｓ３０４）。
【００５８】
図６は、監視部の異常対応処理のより具体的な例として、アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）の異常対応処理を行なう場合の流れを示すフローチャートである。
【００５９】
アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）が異常であると判定すると、実行すべき異常対応処理がアプリケーション層で実行可能であるかどうかを判断する（Ｓ４０１）。
【００６０】
その結果、アプリケーション層で実行可能であると判定した場合（Ｓ４０１：Ｙｅｓ）は、アプリケーション層であらかじめ定められた異常対応処理を実行する（Ｓ４０２）。一方、アプリケーション層で実行可能ではないと判定した場合（Ｓ４０１：Ｎｏ）は、下位層であるミドルウェア監視部（Ｃ２）に異常対応処理を要求する（Ｓ４０３）。
【００６１】
異常対応処理要求を受けたミドルウェア監視部（Ｃ２）は、実行すべき異常対応処理がミドルウェア層で実行可能であるかどうかを判断する（Ｓ４１１）。その結果、ミドルウェア層で実行可能であると判定した場合（Ｓ４１１：Ｙｅｓ）は、ミドルウェア層であらかじめ定められた異常対応処理を実行する（Ｓ４１２）。一方、ミドルウェア層で実行可能ではないと判定した場合（Ｓ４１１：Ｎｏ）は、下位層であるＯＳ監視部（Ｃ１）に異常対応処理を要求する（Ｓ４１３）。
【００６２】
そして、異常対応処理要求を受けたＯＳ監視部（Ｃ１）は、ＯＳ層であらかじめ定められた異常対応処理を実行する（Ｓ４２１）。
【００６３】
以上説明したように、本実施形態の多階層モデル情報処理装置は、情報処理装置本来の機能を構成する各モジュールと、それぞれの監視部の使用資源とを分離して個別に管理することにより、監視処理が情報処理装置本来の機能に影響を与えないようにしている。この結果、以下に列挙するような効果を得ることができる。
１）情報処理装置本来の機能が定常動作している状態での情報処理装置の監視が可能となる。
２）監視処理内容の変更を情報処理装置の定常動作状態で行なうことが可能となる。例えば、情報処理装置内部への監視データの保存処理や、ネットワークを通じた情報処理装置外部への監視データ配信処理などを情報処理装置の定常動作中に各監視部に追加することが可能となる。
３）監視処理が暴走しても、情報処理装置本来の機能は影響を受けることなく動作を継続することが可能となる。
４）情報処理装置本来の機能のモジュールの動作タイミングで監視を実施する場合も、モジュールは監視部に対して監視要求を行なうだけでよく、実際の監視処理には各監視部に割り当てた資源が使用されるため、情報処理装置本来の機能への影響はほとんどない。
５）情報処理装置本来の機能がハングアップや暴走した場合も、監視処理を継続することができる。この結果、ハングアップや暴走の原因究明のために、ハングアップや暴走時の監視データを取得することが可能となる。また、異常対応処理として、情報処理装置本来の機能を構成するモジュールを置き換える処理を定義しておくことで、例えば、ハングアップが発生したアプリケーションを正常動作するアプリケーションに置き換えることが可能となる。
６）各層の監視部を連携させることで、情報処理装置全体の統括的な監視と、異常対応処理が可能となる。これにより、あるモジュールが下層のモジュールの機能を使用して動作する場合に、下層のモジュールを含めた統括的な監視を行なうことができるようになる。また、異常が発生したモジュールでは実行不可能な異常対応処理も実行可能となる。
【００６４】
次に、監視機能を情報処理装置本来の機能と分離した構成の別例として、本発明を受信パケット監視に適用した応用例について説明する。図７は、応用例における情報処理装置の構成を示すブロック図である。
【００６５】
応用例では、多階層モデルとしてネットワークのＴＣＰ／ＩＰスタックを用い、各層に監視部を設けることで、ネットワークセキュリティを向上させる場合について説明する。なお、ＴＣＰ／ＩＰスタックは、ＯＳＩ参照モデルのように、ＴＣＰ／ＩＰの機能を階層化構造の概念に基づいて分割管理するものである。
【００６６】
本図に示す応用例では、情報処理装置が受信したＴＣＰ／ＩＰパケットは、ＯＳＩ参照モデルにおけるＯＳ（Ｍ２１）内のデータリンク層（Ｍ２２）、ネットワーク層（Ｍ２３）、トランスポート層（Ｍ２４）の順に処理された後、ＯＳ（Ｍ２１）上で動作するアプリケーション（Ｍ２５）に通知されるものとする。ただし、上記の例のように、ミドルウェアを介在させるようにしてもよい。
【００６７】
また、情報処理装置には、ＯＳ（Ｍ２１）を監視するＯＳ監視部（Ｃ２１）が、ＯＳ（Ｍ２１）から独立して設けられている。ハードウェア１００、ハードウェア資源管理部（Ｒ０）は、図１に示したハードウェア１００、ハードウェア資源管理部（Ｒ０）と同様の構成である。
【００６８】
ＯＳ（Ｍ２１）内のそれぞれの層での処理内容は、カプセル化される。また、データリンク層（Ｍ２２）において、ＴＣＰ／ＩＰパケットに含まれる物理層フレームが処理され、ネットワーク層（Ｍ２３）において、ＴＣＰ／ＩＰパケットに含まれるＩＰデータグラムが処理され、トランスポート層（Ｍ２４）において、ＴＣＰ／ＩＰパケットに含まれるＴＣＰセグメントが処理される。
【００６９】
通常、情報処理装置のネットワークセキュリティを向上させるためには、層毎に処理するデータを解析し、異常がないことを確認する必要がある。しかし、この手法では、パケットの異常判定機能が、情報処理装置本来の機能と資源を共有するため、情報処理装置本来の機能のスループットが低下するなどの問題が生じる場合がある。この問題を解決するために、本発明を適用することが効果的である。以下では、外部機器からのデータ受信を例にして説明する。
【００７０】
応用例に係る情報処理装置において、ＯＳ（Ｍ２１）は、一般的なＯＳの機能に加えて、ＴＣＰ／ＩＰスタックの各層の処理時に、ＯＳ監視部（Ｃ２１）にデータ判定要求を行なうという特徴を有している。また、ＴＣＰ／ＩＰスタックの各層は、それぞれの処理データをＯＳ監視部（Ｃ２１）に公開する。
【００７１】
ＯＳ監視部（Ｃ２１）は、データリンク層監視部（Ｃ２２）、ネットワーク層監視部（Ｃ２３）、トランスポート層監視部（Ｃ２４）を備えている。各監視部は、ＯＳ（Ｍ２１）のＴＣＰ／ＩＰスタックの各層からデータ判定要求を受けると、層毎で処理されるデータを取得し、特定の判定基準にしたがって異常データでないかを判定する。そして、判定結果を要求元に通知する。
【００７２】
次に、各ブロック間でやり取りされるデータと要求について説明する。データリンク層（Ｍ２２）からデータリンク層監視部（Ｃ２２）に対しては、パケットに含まれる物理層フレーム（Ｓ２１）と、物理層フレームの異常判定要求である物理層フレーム判定要求（Ｏ２１）が送られる。
【００７３】
データリンク層監視部（Ｃ２２）からデータリンク層（Ｍ２２）に対しては、物理層フレーム異常判定結果（Ｓ２４）が送られる。
【００７４】
ネットワーク層（Ｍ２３）からネットワーク層監視部（Ｃ２３）に対しては、パケットに含まれるＩＰデータグラム（Ｓ２２）と、ＩＰデータグラムの異常判定要求であるＩＰデータグラム判定要求（Ｏ２２）が送られる。
【００７５】
ネットワーク層監視部（Ｃ２３）からネットワーク層（Ｍ２３）に対しては、ＩＰデータグラム判定結果（Ｓ２５）が送られる。
【００７６】
トランスポート層（Ｍ２４）からトランスポート層監視部（Ｃ２４）に対しては、パケットに含まれるＴＣＰセグメント（Ｓ２３）と、ＴＣＰセグメントの異常判定要求であるＴＣＰセグメント判定要求（Ｏ２３）が送られる。
【００７７】
トランスポート層監視部（Ｃ２４）からトランスポート層（Ｍ２４）に対しては、ＴＣＰセグメント判定結果（Ｓ２６）が送られる。
【００７８】
次に、本応用例における情報処理装置による通信パケット受信処理の流れについて図８のフローチャートを参照して説明する。
【００７９】
本応用例における情報処理装置は、外部機器から通信パケットを受信すると（Ｓ５０１）、まず、データリンク層（Ｍ２２）で物理層フレームを解析し、異常判定を実行する（Ｓ５０２）。この結果、物理層フレームが異常であれば（Ｓ５０３：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。
【００８０】
物理層フレームが異常でなければ（Ｓ５０３：Ｎｏ）、ネットワーク層（Ｍ２３）でＩＰデータグラムを解析し、異常判定を実行する（Ｓ５０４）。この結果、ＩＰデータグラムが異常であれば（Ｓ５０５：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。
【００８１】
ＩＰデータグラムが異常でなければ（Ｓ５０５：Ｎｏ）、トランスポート層（Ｍ２４）でＴＣＰセグメントを解析し、異常判定を実行する（Ｓ５０６）。この結果、ＴＣＰセグメントが異常であれば（Ｓ５０７：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。ＴＣＰセグメントが異常でなければ（Ｓ５０７：Ｎｏ）、アプリケーション（Ｍ２５）に受信データを通知し（Ｓ５０８）、パケット受信処理を終了する。
【００８２】
次に、異常判定処理のより具体的な手順について図９のフローチャートを参照して説明する。ここでは、データリンク層（Ｍ２２）における物理層フレームの異常判定を例に説明する。
【００８３】
まず、ＯＳ（Ｍ２１）のデータリンク層（Ｍ２２）で、通信パケットから物理層フレームを抽出する（Ｓ６０１）。そして、データリンク層監視部（Ｃ２２）に物理層フレーム判定処理要求を行なう（Ｓ６０２）。
【００８４】
これに対して、ＯＳ監視部（Ｃ２１）のデータリンク層監視部（Ｃ２２）は、物理層フレームをＯＳ（Ｍ２１）のデータリンク層（Ｍ２２）から取得する（Ｓ６１１）。そして、あらかじめ定められた基準にしたがって物理層フレームの異常判定を行ない（Ｓ６１２）、判定結果をＯＳ監視部（Ｃ２１）のデータリンク層監視部（Ｃ２２）に通知する（Ｓ６１３）。なお、他の層においても、同様の手順で異常判定処理が行なわれる。
【００８５】
このように、本変形例では、ＯＳ監視部（Ｃ２１）をＯＳ（Ｍ２１）から独立して設け、受信パケットの異常判定処理を、ＯＳ監視部（Ｃ２１）に割り当てた資源を使用して行なうことにより、情報処理装置本来の機能に影響を与えることなく受信パケットの監視を行なうことが可能となる。
【符号の説明】
【００８６】
１００…ハードウェア、３００…ハードウェア、３１０…ＯＳ、３１１…ＯＳ監視機能部、３２０…ミドルウェア、３２１…ミドルウェア監視機能部、３３０…アプリケーション、３３１…アプリケーション監視機能部、Ｍ１…ＯＳ、Ｍ２…ミドルウェア、Ｍ３…アプリケーション、Ｍ２１…ＯＳ、Ｍ２２…データリンク層、Ｍ２３…ネットワーク層、Ｍ２４…トランスポート層、Ｍ２５…アプリケーション、Ｒ０…ハードウェア資源管理部、Ｒ１…ＯＳ資源管理部、Ｒ２…ミドルウェア資源管理部、Ｒ３…アプリケーション資源管理部、Ｃ０…状態監視部、Ｃ１…ＯＳ監視部、Ｃ２…ミドルウェア監視部、Ｃ３…アプリケーション監視部、Ｃ２１…ＯＳ監視部、Ｃ２２…データリンク層監視部、Ｃ２３…ネットワーク層監視部、Ｃ２４…トランスポート層監視部
【技術分野】
【０００１】
本発明は、情報処理装置に関し、特に、多階層モデルでソフトウェアを構成した情報処理装置に関する。
【背景技術】
【０００２】
近年、組込み機器等の情報処理装置に対するディペンダビリティへの要求が高まっている。ディペンダビリティとは、情報処理装置の非機能要件を指し、例えば、リアルタイム性、信頼性、可用性、セキュリティ等を含む概念である。情報処理装置のディペンダビリティを確保するためには、情報処理装置の動作を監視し、異常発生時には、その対応処理を実施することが重要となる。このため、ソフトウェアに監視機能を組み込んでおくことが従来から行なわれている。
【０００３】
ところで、ソフトウェアが動作する情報処理装置では、オペレーティングシステム（以下「ＯＳ」と称す）上でアプリケーションを動作させたり、ＯＳ上にミドルウェアを搭載して、ミドルウェア上でアプリケーションを動作させたりするように、内部のソフトウェアを、多階層モデルで構成する場合が多い。以下では、各層のソフトウェア（ＯＳ、ミドルウェア、ソフトウェア）をモジュールと称する。
【０００４】
このような構成において、ソフトウェアに監視機能を設ける場合には、それぞれの層のモジュールにおいて独自の監視機能が組み込まれる。図１０は、内部のソフトウェアが多階層モデルで構成され、それぞれの層に監視機能を持たせた情報処理装置の構成例を示すブロック図である。
【０００５】
本図の例では、ハードウェア３００で動作するＯＳ３１０上にミドルウェア３２０を搭載し、ミドルウェア３２０上でアプリケーション３３０が動作するようになっている。ここで、ミドルウェア３２０は、ＯＳ３１０上で動作するアプリケーション実行環境であり、例えば、ＪａｖａＶＭ（登録商標）等が該当する。
【０００６】
そして、ＯＳ３１０は、ＯＳ監視機能部３１１を備え、ミドルウェア３２０は、ミドルウェア監視機能部３２１を備え、アプリケーション３３０は、アプリケーション監視機能部３３１を備えている。すなわち、各監視機能部は、ＯＳ３１０、ミドルウェア３２０、アプリケーション３３０に個別に組み込まれている。ただし、監視機能部が必要な層にのみ監視機能部を組み込む場合もある。
【０００７】
各監視機能部は、監視対象の状態、例えば、メモリ内容や動作履歴等を監視し、必要に応じて情報処理装置内部に記録したり、ネットワーク等を通じて情報処理装置外部に発信する等の処理を行なう。また、監視結果からモジュールに異常が発生したことが判明した場合は、異常対応の処理を実行する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平７−３０２２３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来のように、多階層モデルで構成されたソフトウェアの各層に個別に監視機能部を設けた場合には、情報処理装置全体の統括的な監視ができないという問題がある。
【００１０】
例えば、図１０において、アプリケーション３３０は、ミドルウェア３２０が提供する機能を用いて実現され、ミドルウェア３２０は、ＯＳ３１０が提供する機能を用いて実現される。このため、アプリケーション３３０の動作状態を詳細に知るためには、アプリケーション３３０の動作に関連したミドルウェア３２０の動作状態と、ＯＳ３１０の動作状態とを知る必要がある。このためには、各モジュールの監視機能部が連動して監視を行なわなければならないが、従来は、モジュール毎に独自の監視機能を設けているため、各モジュールの監視結果を関連付けることができない。
【００１１】
さらに、モジュール間で監視機能が連携していないために、いずれかの監視機能が監視対象モジュールの異常を検知した際の異常対象の処理内容が限られる場合が多い。これは、各モジュールで可能な異常対応処理は、通常、そのモジュールで処理可能なものと、その上層で動作するモジュールの制御に限定されるためである。例えば、アプリケーション３３０の異常により、情報処理装置の再起動が必要となった場合でも、アプリケーション３３０では、情報処理装置の再起動を行なえないことが多い。
【００１２】
また、多階層モデルで構成されたソフトウェアの各層に個別に監視機能部を組み込んだ場合には、監視機能が情報処理装置本来の機能に悪影響を与えるという問題もある。ここで、情報処理装置本来の機能とは、情報処理装置本来の使用目的を満たすための機能である。例えば、情報処理装置がプラント制御用コントローラであれば、情報処理装置本来の機能は、コントローラに接続されたプラントを構成する情報処理装置を制御する機能であり、コントローラの状態監視は、情報処理装置本来の機能には含まれない。
【００１３】
監視機能は、情報処理装置本来の機能には含まれないが、ＣＰＵ、メモリ、ネットワーク等の計算資源を、情報処理装置本来の機能と共有して動作する。このため、情報処理装置本来の機能の使用資源量は、監視機能の動作の影響を受ける。したがって、監視機能の動作によって、情報処理装置本来の機能の応答性やスループット等が悪化する場合がある。
【００１４】
さらに、多階層モデルで構成されたソフトウェアの各層に個別に監視機能を組み込んだ場合には、何らかの原因により情報処理装置本来の機能が暴走すると、監視機能も影響を受けるという問題がある。上述のように、監視機能と情報処理装置本来の機能とは、情報処理装置の計算資源を共有して動作する。このため、情報処理装置本来の機能が暴走して、情報処理装置の計算資源を占有してしまうと、監視機能は動作できず、監視を継続できなくなってしまう。
【００１５】
以上の問題は、監視機能が情報処理装置本来の機能に組み込まれており、従属性が高いのに加え、監視機能の層間の連携が十分でないことに起因すると考えられる。
【００１６】
そこで、本発明は、上述の問題を鑑みてなされたものであり、多階層モデルでソフトウェアを構成した情報処理装置において、ソフトウェア動作に対する監視機能の独立性を高めるとともに、監視機能の層間の連携を高めることを目的とする。
【課題を解決するための手段】
【００１７】
上記課題を解決するため、本発明の情報処理装置は、多階層モデルでソフトウェアを構成した情報処理装置であって、各階層における動作を行なう複数のモジュールと、前記モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、前記各監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なうことを特徴とする。
【００１８】
ここで、前記各監視部は、対応するモジュールの動作を監視した結果、異常を検出した場合は、当該監視部で対応可能であるかどうかを判定し、当該監視部で対応不可能と判定した際に、より下位の監視部に対して異常対応処理要求を行なうことができる。
【００１９】
また、前記各監視部は、対応するモジュールから、あらかじめ定められた形式の監視データを取得することで対応するモジュールの動作を監視することができる。
【００２０】
また、前記各モジュールは、上位のモジュールおよび当該モジュールに対応した監視部に対して、前記情報処理装置のリソースの割り当てを行なうことができる。このとき、前記各モジュールは、上位のモジュールと当該モジュールに対応した監視部とで、異なるリソースを割り当てることができる。
【００２１】
また、前記複数のモジュールとして、オペレーティングシステム、ミドルウェア、アプリケーションのうち、少なくとも２つを含むことができる。
【発明の効果】
【００２２】
本発明によれば、多階層モデルでソフトウェアを構成した情報処理装置において、ソフトウェア動作に対する監視機能の独立性を高めるとともに、監視機能の層間の連携を高めることができる。
【図面の簡単な説明】
【００２３】
【図１】本実施形態に係る情報処理装置の構成を示すブロック図である。
【図２】各資源管理部が行なう、情報処理装置の持つ資源の割り当ての例について説明する図である。
【図３】各監視部の状態監視の処理の流れを説明するフローチャートである。
【図４】アプリケーション監視部が、アプリケーションから監視要求を受けた場合、あるいは、アプリケーション監視部の任意の起動タイミングで実行する監視処理の流れを示すフローチャートである。
【図５】各監視部の異常判定処理の流れについて説明するフローチャートである。
【図６】アプリケーション監視部が、アプリケーションの異常対応処理を行なう場合の流れを示すフローチャートである。
【図７】応用例における情報処理装置の構成を示すブロック図である。
【図８】本応用例における情報処理装置による通信パケット受信処理の流れについて説明するフローチャートである。
【図９】異常判定処理の手順について説明するフローチャートである。
【図１０】多階層モデルで構成された従来の情報処理装置の構成を示すブロック図である。
【発明を実施するための形態】
【００２４】
本発明の実施の形態について図面を参照して説明する。図１は、本実施形態に係る情報処理装置の構成を示すブロック図である。本実施形態に係る情報処理装置は、内部のソフトウェアを、ＯＳ層、ミドルウェア層、アプリケーション層の多階層モデルで構成している。
【００２５】
そして、ＯＳ層は、ハードウェア資源管理部（Ｒ０）上で動作するＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）とを含み、ミドルウェア層は、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）とを含み、アプリケーション層は、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）と、アプリケーション監視部（Ｃ３）とを含んでいる。
【００２６】
本実施形態では、情報処理装置本来の機能を実現するＯＳ（Ｍ１）と、ミドルウェア（Ｍ２）と、アプリケーション（Ｍ３）とについて、それぞれの監視部、すなわち、ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）を独立させて設けおり、各監視部が互いに連携して、ＯＳ（Ｍ１）、ミドルウェア（Ｍ２）、アプリケーション（Ｍ３）の状態監視を行なう。
【００２７】
ここで、各監視部が監視するデータは、メモリ内容や動作履歴等の動作情報と、計算資源使用量等である。さらに、情報処理装置本来の機能に異常が発生した場合には、必要に応じて各監視部が連携して、異常対応処理を実行する。
【００２８】
以下に、本図における各ブロックについて説明する。
【００２９】
ハードウェア資源管理部（Ｒ０）は、ハードウェア１００のリソースを管理し、ハードウェア１００とソフトウェアとのやり取りを管理する。具体的には、情報処理装置が持つ計算資源を、ＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）に割り当て、それぞれの資源使用量を制限する。
【００３０】
ＯＳ資源管理部（Ｒ１）は、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）に資源を割り当て、それぞれの資源使用量を制限する。ＯＳ資源管理部（Ｒ１）が割り当て可能な資源の総量は、ハードウェア資源管理部（Ｒ０）により、ＯＳ（Ｍ１）に割り当てられた資源量から、ＯＳ（Ｍ１）自体の使用資源量を除いた量である。
【００３１】
ミドルウェア資源管理部（Ｒ２）は、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）とアプリケーション監視部（Ｃ３）に資源を割り当て、それぞれの資源使用量を制限する。ミドルウェア資源管理部（Ｒ２）が割り当て可能な資源の総量は、ＯＳ資源管理部（Ｒ１）により、ミドルウェア（Ｍ２）に割り当てられた資源量から、ミドルウェア（Ｍ２）自体の使用資源量を除いた量である。
【００３２】
ここで、ハードウェア資源管理部（Ｒ０）、ＯＳ資源管理部（Ｒ１）、ミドルウェア資源管理部（Ｒ２）の各資源管理部が行なう、情報処理装置の持つ資源の割り当ての例について、図２を参照して説明する。各資源管理部は、以下の処理を情報処理装置の起動時、すなわち、情報処理装置本来の機能と、後述する監視処理の実行前に実施する。
【００３３】
まず、ハードウェア資源管理部（Ｒ０）は、情報処理装置の持つ全資源を２つに分割し、ＯＳ層への割り当てとして、ＯＳ（Ｍ１）とＯＳ監視部（Ｃ１）に資源を割り当てる。次に、ＯＳ資源管理部（Ｒ１）は、ＯＳ（Ｍ１）に割り当てられた資源の中から、ＯＳ（Ｍ１）自体の使用資源を除いた量を２つに分割し、ミドルウェア層への割り当てとして、ミドルウェア（Ｍ２）とミドルウェア監視部（Ｃ２）に資源を割り当てる。そして、ミドルウェア資源管理部（Ｒ２）は、ミドルウェア（Ｍ２）に割り当てられた資源の中から、ミドルウェア（Ｍ２）自体の使用資源を除いた量を２つに分割し、アプリケーション層への割り当てとして、アプリケーション（Ｍ３）とアプリケーション監視部（Ｃ３）に資源を割り当てる。
【００３４】
図１のブロック図の説明に戻って、ＯＳ（Ｍ１）は、従来の一般的なＯＳ機能に加え、以下の特徴を有している。
１）ＯＳ資源管理部（Ｒ１）を有する。
２）ＯＳ監視部（Ｃ１）に対して、ＯＳ監視データを公開するインタフェースを有する。
３）必要に応じて、ＯＳ監視部（Ｃ１）に対して、ＯＳ監視要求を行なう。
【００３５】
ミドルウェア（Ｍ２）は、従来のミドルウェアの一般的な機能に加えて、以下の特徴を有している。
１）ミドルウェア資源管理部（Ｒ２）を有する。
２）ミドルウェア監視部（Ｃ２）に対して、ミドルウェア監視データを公開するインタフェースを有する。
３）必要に応じて、ミドルウェア監視部（Ｃ２）に対して、ミドルウェア監視要求を行なう。
【００３６】
アプリケーション（Ｍ３）は、従来のアプリケーションの一般的な機能に加えて、以下の特徴を有している。
１）アプリケーション監視部（Ｃ３）に対して、アプリケーション監視データを公開するインタフェースを有する。
２）必要に応じて、アプリケーション監視部（Ｃ３）に対して、アプリケーション監視要求を行なう。
【００３７】
ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）は、状態監視部（Ｃ０）を構成し、情報処理装置本来の機能の状態を監視する。
【００３８】
次に、各ブロック間でやり取りされるデータと要求について、再度図１を参照して説明する。
【００３９】
ＯＳ（Ｍ１）からＯＳ監視部（Ｃ１）に対しては、ＯＳ監視データ（Ｓ１）とＯＳ監視要求（Ｏ１）が送られる。ＯＳ監視データ（Ｓ１）は、ＯＳ（Ｍ１）の動作情報、例えば、メモリ内容や動作履歴等と、ＯＳ（Ｍ１）上で動作するミドルウェア（Ｍ２）の資源使用量の情報を含むデータである。ＯＳ監視要求（Ｏ１）は、ＯＳ監視部（Ｃ１）に対するＯＳ監視の実行要求である。
【００４０】
ミドルウェア（Ｍ２）からミドルウェア監視部（Ｃ２）に対しては、ミドルウェア監視データ（Ｓ２）とミドルウェア監視要求（Ｏ２）が送られる。ミドルウェア監視データ（Ｓ２）は、ミドルウェア（Ｍ２）の動作情報、例えば、メモリ内容や動作履歴等と、ミドルウェア（Ｍ２）上で動作するアプリケーション（Ｍ３）の資源使用量の情報を含むデータである。ミドルウェア監視要求（Ｏ２）は、ミドルウェア監視部（Ｃ２）に対するミドルウェア監視の実行要求である。
【００４１】
アプリケーション（Ｍ３）からアプリケーション監視部（Ｃ３）に対しては、アプリケーション監視データ（Ｓ３）とアプリケーション監視要求（Ｏ３）が送られる。アプリケーション監視データ（Ｓ３）は、アプリケーション（Ｍ３）の動作情報、例えば、メモリ内容や動作履歴等を含むデータである。アプリケーション監視要求（Ｏ３）は、アプリケーション監視部（Ｃ３）に対するアプリケーション監視の実行要求である。
【００４２】
アプリケーション監視部（Ｃ３）からミドルウェア監視部（Ｃ２）に対しては、ミドルウェア監視要求（Ｏ２）と異常対応処理要求（Ｏ４）が送られる。異常対応処理要求（Ｏ４）は、異常対応処理の実行要求である。
【００４３】
ミドルウェア監視部（Ｃ２）からＯＳ監視部（Ｃ１）に対しては、ＯＳ監視要求（Ｏ１）と異常対応処理要求（Ｏ４）が送られる。
【００４４】
次に、ＯＳ監視部（Ｃ１）、ミドルウェア監視部（Ｃ２）、アプリケーション監視部（Ｃ３）の各監視部が行なう処理について説明する。各監視部は、それぞれの監視対象の状態監視と、監視対象に異常が発生した際の異常対応処理を実行する。ここで、監視対象は、各監視部がそれぞれ監視するモジュールであり、ＯＳ監視部（Ｃ１）はＯＳ（Ｍ１）、ミドルウェア監視部（Ｃ２）はミドルウェア（Ｍ２）、アプリケーション監視部（Ｃ３）はアプリケーション（Ｍ３）である。
【００４５】
状態監視において、各監視部は、監視対象から監視データを取得し、この監視データを基に監視対象の異常を判定する。判定基準は、例えば、エラー発生の有無、メモリの値が特定の閾値を超過していなか等とすることができ、任意に定めることができる。
【００４６】
図３は、各監視部の状態監視の処理の流れを説明するフローチャートである。本図に示すように、本実施形態において監視データを取得するタイミングは３種類あり、以下のような判断が行なわれる。
【００４７】
すなわち、定周期や定時刻等の各監視部独自の起動タイミングであるかどうか（Ｓ１０１）、それぞれの監視対象から監視要求を受けたかどうか（Ｓ１０２）、上層の監視部から監視要求を受けたかどうか（Ｓ１０３）である。ただし、アプリケーション監視部（Ｃ３）は、上層がないため、（Ｓ１０３）の判断は行なわない。
【００４８】
これらの判断の結果、いずれかの条件を満たす場合には、監視対象から監視データを取得する（Ｓ１０４）。また、他層の監視部との連携した監視を実現するため、監視データ取得の際には、下層の監視部に対しても監視要求を行なう（Ｓ１０５）。これらの順序は、逆であってもよい。なお、ＯＳ監視部（Ｃ１）については、下層の監視部が存在しないため、下層への監視要求は行なわない。
【００４９】
そして、取得した監視データに基づいて、監視対象の異常判定を行なう（Ｓ１０６）。各監視部は、以上の監視処理を繰り返す（Ｓ１０７）。
【００５０】
図４は、監視部の状態監視処理のより具体的な例として、アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）から監視要求を受けた場合、あるいは、アプリケーション監視部（Ｃ３）の任意の起動タイミングで実行する監視処理の流れを示すフローチャートである。
【００５１】
アプリケーション監視部（Ｃ３）が、監視処理を開始すると、下位層であるミドルウェア監視部（Ｃ２）に、ミドルウェア監視要求を行なう（Ｓ２０１）。そして、アプリケーション（Ｍ３）からアプリケーション監視データを取得する（Ｓ２０２）。なお、ここでは、下位層に監視要求を行なってから、監視対象から監視データを取得するようにしている。そして、取得した監視データを基に、アプリケーション（Ｍ３）の異常判定を行なう（Ｓ２０３）。
【００５２】
また、アプリケーション監視部（Ｃ３）からミドルウェア監視要求を受けたミドルウェア監視部（Ｃ２）は、下位層であるＯＳ監視部（Ｃ１）に、ＯＳ監視要求を行なう（Ｓ２１１）。そして、ミドルウェア（Ｍ２）からミドルウェア監視データを取得し（Ｓ２１２）、取得した監視データを基に、ミドルウェア（Ｍ２）の異常判定を行なう（Ｓ２１３）。
【００５３】
また、ミドルウェア監視部（Ｃ２）からＯＳ監視要求を受けたＯＳ監視部（Ｃ２）は、ＯＳ（Ｍ１）からＯＳ監視データを取得する（Ｓ２３１）。ＯＳ監視部（Ｃ１）には、下位層がないため、監視要求は行なわない。そして、取得した監視データを基に、ＯＳ（Ｍ１）の異常判定を行なう（Ｓ２３２）。
【００５４】
状態監視の結果、監視対象に異常が発生したと判定した場合、各監視部は、あらかじめ定められた異常対応処理を実施する。ここで、各監視部が実行可能な異常対応処理は、属する層毎に異なる。例えば、情報処理装置の再起動は、通常、ＯＳ層でのみ可能であるため、ＯＳ監視部（Ｃ１）がＯＳ（Ｍ１）に指示することで実施する。また、ミドルウェアやアプリケーションの再起動は、通常、それぞれの動作環境であるＯＳ層とミドルウェア層でのみ可能であるため、ＯＳ監視部（Ｃ１）とミドルウェア監視部（Ｃ２）が各監視対象に指示することで実施する。
【００５５】
このように、監視部毎に可能な異常対応処理が異なるため、ある監視部が監視対象の異常を検知し、その監視部では対応処理を実行できない場合は、下層の監視部に異常対応処理要求を行なう。
【００５６】
図５は、各監視部の異常判定処理の流れについて説明するフローチャートである。各監視部は、取得した監視対象の監視データを基に異常判定を行ない、異常と判定した場合（Ｓ３０１：Ｙｅｓ）は、監視対象モジュールで対処可能かどうかを判定する（Ｓ３０２）。この判定は、例えば、異常内容と対処方法とを対応させたテーブル等をあらかじめ監視部内等に用意しておき、このテーブル等を参照することで行なうことができる。
【００５７】
その結果、監視対象のモジュールで対処可能な場合（Ｓ３０２：Ｙｅｓ）は、あらかじめ定められた異常対応処理を実行する（Ｓ３０３）。一方、監視対象のモジュールで対処可能でない場合（Ｓ３０２：Ｎｏ）は、下位層監視部に異常対応処理を要求する（Ｓ３０４）。
【００５８】
図６は、監視部の異常対応処理のより具体的な例として、アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）の異常対応処理を行なう場合の流れを示すフローチャートである。
【００５９】
アプリケーション監視部（Ｃ３）が、アプリケーション（Ｍ３）が異常であると判定すると、実行すべき異常対応処理がアプリケーション層で実行可能であるかどうかを判断する（Ｓ４０１）。
【００６０】
その結果、アプリケーション層で実行可能であると判定した場合（Ｓ４０１：Ｙｅｓ）は、アプリケーション層であらかじめ定められた異常対応処理を実行する（Ｓ４０２）。一方、アプリケーション層で実行可能ではないと判定した場合（Ｓ４０１：Ｎｏ）は、下位層であるミドルウェア監視部（Ｃ２）に異常対応処理を要求する（Ｓ４０３）。
【００６１】
異常対応処理要求を受けたミドルウェア監視部（Ｃ２）は、実行すべき異常対応処理がミドルウェア層で実行可能であるかどうかを判断する（Ｓ４１１）。その結果、ミドルウェア層で実行可能であると判定した場合（Ｓ４１１：Ｙｅｓ）は、ミドルウェア層であらかじめ定められた異常対応処理を実行する（Ｓ４１２）。一方、ミドルウェア層で実行可能ではないと判定した場合（Ｓ４１１：Ｎｏ）は、下位層であるＯＳ監視部（Ｃ１）に異常対応処理を要求する（Ｓ４１３）。
【００６２】
そして、異常対応処理要求を受けたＯＳ監視部（Ｃ１）は、ＯＳ層であらかじめ定められた異常対応処理を実行する（Ｓ４２１）。
【００６３】
以上説明したように、本実施形態の多階層モデル情報処理装置は、情報処理装置本来の機能を構成する各モジュールと、それぞれの監視部の使用資源とを分離して個別に管理することにより、監視処理が情報処理装置本来の機能に影響を与えないようにしている。この結果、以下に列挙するような効果を得ることができる。
１）情報処理装置本来の機能が定常動作している状態での情報処理装置の監視が可能となる。
２）監視処理内容の変更を情報処理装置の定常動作状態で行なうことが可能となる。例えば、情報処理装置内部への監視データの保存処理や、ネットワークを通じた情報処理装置外部への監視データ配信処理などを情報処理装置の定常動作中に各監視部に追加することが可能となる。
３）監視処理が暴走しても、情報処理装置本来の機能は影響を受けることなく動作を継続することが可能となる。
４）情報処理装置本来の機能のモジュールの動作タイミングで監視を実施する場合も、モジュールは監視部に対して監視要求を行なうだけでよく、実際の監視処理には各監視部に割り当てた資源が使用されるため、情報処理装置本来の機能への影響はほとんどない。
５）情報処理装置本来の機能がハングアップや暴走した場合も、監視処理を継続することができる。この結果、ハングアップや暴走の原因究明のために、ハングアップや暴走時の監視データを取得することが可能となる。また、異常対応処理として、情報処理装置本来の機能を構成するモジュールを置き換える処理を定義しておくことで、例えば、ハングアップが発生したアプリケーションを正常動作するアプリケーションに置き換えることが可能となる。
６）各層の監視部を連携させることで、情報処理装置全体の統括的な監視と、異常対応処理が可能となる。これにより、あるモジュールが下層のモジュールの機能を使用して動作する場合に、下層のモジュールを含めた統括的な監視を行なうことができるようになる。また、異常が発生したモジュールでは実行不可能な異常対応処理も実行可能となる。
【００６４】
次に、監視機能を情報処理装置本来の機能と分離した構成の別例として、本発明を受信パケット監視に適用した応用例について説明する。図７は、応用例における情報処理装置の構成を示すブロック図である。
【００６５】
応用例では、多階層モデルとしてネットワークのＴＣＰ／ＩＰスタックを用い、各層に監視部を設けることで、ネットワークセキュリティを向上させる場合について説明する。なお、ＴＣＰ／ＩＰスタックは、ＯＳＩ参照モデルのように、ＴＣＰ／ＩＰの機能を階層化構造の概念に基づいて分割管理するものである。
【００６６】
本図に示す応用例では、情報処理装置が受信したＴＣＰ／ＩＰパケットは、ＯＳＩ参照モデルにおけるＯＳ（Ｍ２１）内のデータリンク層（Ｍ２２）、ネットワーク層（Ｍ２３）、トランスポート層（Ｍ２４）の順に処理された後、ＯＳ（Ｍ２１）上で動作するアプリケーション（Ｍ２５）に通知されるものとする。ただし、上記の例のように、ミドルウェアを介在させるようにしてもよい。
【００６７】
また、情報処理装置には、ＯＳ（Ｍ２１）を監視するＯＳ監視部（Ｃ２１）が、ＯＳ（Ｍ２１）から独立して設けられている。ハードウェア１００、ハードウェア資源管理部（Ｒ０）は、図１に示したハードウェア１００、ハードウェア資源管理部（Ｒ０）と同様の構成である。
【００６８】
ＯＳ（Ｍ２１）内のそれぞれの層での処理内容は、カプセル化される。また、データリンク層（Ｍ２２）において、ＴＣＰ／ＩＰパケットに含まれる物理層フレームが処理され、ネットワーク層（Ｍ２３）において、ＴＣＰ／ＩＰパケットに含まれるＩＰデータグラムが処理され、トランスポート層（Ｍ２４）において、ＴＣＰ／ＩＰパケットに含まれるＴＣＰセグメントが処理される。
【００６９】
通常、情報処理装置のネットワークセキュリティを向上させるためには、層毎に処理するデータを解析し、異常がないことを確認する必要がある。しかし、この手法では、パケットの異常判定機能が、情報処理装置本来の機能と資源を共有するため、情報処理装置本来の機能のスループットが低下するなどの問題が生じる場合がある。この問題を解決するために、本発明を適用することが効果的である。以下では、外部機器からのデータ受信を例にして説明する。
【００７０】
応用例に係る情報処理装置において、ＯＳ（Ｍ２１）は、一般的なＯＳの機能に加えて、ＴＣＰ／ＩＰスタックの各層の処理時に、ＯＳ監視部（Ｃ２１）にデータ判定要求を行なうという特徴を有している。また、ＴＣＰ／ＩＰスタックの各層は、それぞれの処理データをＯＳ監視部（Ｃ２１）に公開する。
【００７１】
ＯＳ監視部（Ｃ２１）は、データリンク層監視部（Ｃ２２）、ネットワーク層監視部（Ｃ２３）、トランスポート層監視部（Ｃ２４）を備えている。各監視部は、ＯＳ（Ｍ２１）のＴＣＰ／ＩＰスタックの各層からデータ判定要求を受けると、層毎で処理されるデータを取得し、特定の判定基準にしたがって異常データでないかを判定する。そして、判定結果を要求元に通知する。
【００７２】
次に、各ブロック間でやり取りされるデータと要求について説明する。データリンク層（Ｍ２２）からデータリンク層監視部（Ｃ２２）に対しては、パケットに含まれる物理層フレーム（Ｓ２１）と、物理層フレームの異常判定要求である物理層フレーム判定要求（Ｏ２１）が送られる。
【００７３】
データリンク層監視部（Ｃ２２）からデータリンク層（Ｍ２２）に対しては、物理層フレーム異常判定結果（Ｓ２４）が送られる。
【００７４】
ネットワーク層（Ｍ２３）からネットワーク層監視部（Ｃ２３）に対しては、パケットに含まれるＩＰデータグラム（Ｓ２２）と、ＩＰデータグラムの異常判定要求であるＩＰデータグラム判定要求（Ｏ２２）が送られる。
【００７５】
ネットワーク層監視部（Ｃ２３）からネットワーク層（Ｍ２３）に対しては、ＩＰデータグラム判定結果（Ｓ２５）が送られる。
【００７６】
トランスポート層（Ｍ２４）からトランスポート層監視部（Ｃ２４）に対しては、パケットに含まれるＴＣＰセグメント（Ｓ２３）と、ＴＣＰセグメントの異常判定要求であるＴＣＰセグメント判定要求（Ｏ２３）が送られる。
【００７７】
トランスポート層監視部（Ｃ２４）からトランスポート層（Ｍ２４）に対しては、ＴＣＰセグメント判定結果（Ｓ２６）が送られる。
【００７８】
次に、本応用例における情報処理装置による通信パケット受信処理の流れについて図８のフローチャートを参照して説明する。
【００７９】
本応用例における情報処理装置は、外部機器から通信パケットを受信すると（Ｓ５０１）、まず、データリンク層（Ｍ２２）で物理層フレームを解析し、異常判定を実行する（Ｓ５０２）。この結果、物理層フレームが異常であれば（Ｓ５０３：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。
【００８０】
物理層フレームが異常でなければ（Ｓ５０３：Ｎｏ）、ネットワーク層（Ｍ２３）でＩＰデータグラムを解析し、異常判定を実行する（Ｓ５０４）。この結果、ＩＰデータグラムが異常であれば（Ｓ５０５：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。
【００８１】
ＩＰデータグラムが異常でなければ（Ｓ５０５：Ｎｏ）、トランスポート層（Ｍ２４）でＴＣＰセグメントを解析し、異常判定を実行する（Ｓ５０６）。この結果、ＴＣＰセグメントが異常であれば（Ｓ５０７：Ｙｅｓ）、通信パケットを破棄する（Ｓ５０９）。ＴＣＰセグメントが異常でなければ（Ｓ５０７：Ｎｏ）、アプリケーション（Ｍ２５）に受信データを通知し（Ｓ５０８）、パケット受信処理を終了する。
【００８２】
次に、異常判定処理のより具体的な手順について図９のフローチャートを参照して説明する。ここでは、データリンク層（Ｍ２２）における物理層フレームの異常判定を例に説明する。
【００８３】
まず、ＯＳ（Ｍ２１）のデータリンク層（Ｍ２２）で、通信パケットから物理層フレームを抽出する（Ｓ６０１）。そして、データリンク層監視部（Ｃ２２）に物理層フレーム判定処理要求を行なう（Ｓ６０２）。
【００８４】
これに対して、ＯＳ監視部（Ｃ２１）のデータリンク層監視部（Ｃ２２）は、物理層フレームをＯＳ（Ｍ２１）のデータリンク層（Ｍ２２）から取得する（Ｓ６１１）。そして、あらかじめ定められた基準にしたがって物理層フレームの異常判定を行ない（Ｓ６１２）、判定結果をＯＳ監視部（Ｃ２１）のデータリンク層監視部（Ｃ２２）に通知する（Ｓ６１３）。なお、他の層においても、同様の手順で異常判定処理が行なわれる。
【００８５】
このように、本変形例では、ＯＳ監視部（Ｃ２１）をＯＳ（Ｍ２１）から独立して設け、受信パケットの異常判定処理を、ＯＳ監視部（Ｃ２１）に割り当てた資源を使用して行なうことにより、情報処理装置本来の機能に影響を与えることなく受信パケットの監視を行なうことが可能となる。
【符号の説明】
【００８６】
１００…ハードウェア、３００…ハードウェア、３１０…ＯＳ、３１１…ＯＳ監視機能部、３２０…ミドルウェア、３２１…ミドルウェア監視機能部、３３０…アプリケーション、３３１…アプリケーション監視機能部、Ｍ１…ＯＳ、Ｍ２…ミドルウェア、Ｍ３…アプリケーション、Ｍ２１…ＯＳ、Ｍ２２…データリンク層、Ｍ２３…ネットワーク層、Ｍ２４…トランスポート層、Ｍ２５…アプリケーション、Ｒ０…ハードウェア資源管理部、Ｒ１…ＯＳ資源管理部、Ｒ２…ミドルウェア資源管理部、Ｒ３…アプリケーション資源管理部、Ｃ０…状態監視部、Ｃ１…ＯＳ監視部、Ｃ２…ミドルウェア監視部、Ｃ３…アプリケーション監視部、Ｃ２１…ＯＳ監視部、Ｃ２２…データリンク層監視部、Ｃ２３…ネットワーク層監視部、Ｃ２４…トランスポート層監視部
【特許請求の範囲】
【請求項１】
多階層モデルでソフトウェアを構成した情報処理装置であって、
各階層における動作を行なう複数のモジュールと、
前記モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、
前記各監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なうことを特徴とする情報処理装置。
【請求項２】
前記各監視部は、対応するモジュールの動作を監視した結果、異常を検出した場合は、当該監視部で対応可能であるかどうかを判定し、当該監視部で対応不可能と判定した際に、より下位の監視部に対して異常対応処理要求を行なうことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記各監視部は、対応するモジュールから、あらかじめ定められた形式の監視データを取得することで対応するモジュールの動作を監視することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記各モジュールは、上位のモジュールおよび当該モジュールに対応した監視部に対して、前記情報処理装置のリソースの割り当てを行なうことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記各モジュールは、上位のモジュールと当該モジュールに対応した監視部とで、異なるリソースを割り当てることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記複数のモジュールとして、オペレーティングシステム、ミドルウェア、アプリケーションのうち、少なくとも２つを含むことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項１】
多階層モデルでソフトウェアを構成した情報処理装置であって、
各階層における動作を行なう複数のモジュールと、
前記モジュールに対応して設けられ、対応するモジュールの動作を監視する複数の監視部とを備え、
前記各監視部は、対応するモジュールの動作とは独立して監視動作を行ない、対応するモジュールの監視の際に、より下位層の監視部に対して、監視要求を行なうことを特徴とする情報処理装置。
【請求項２】
前記各監視部は、対応するモジュールの動作を監視した結果、異常を検出した場合は、当該監視部で対応可能であるかどうかを判定し、当該監視部で対応不可能と判定した際に、より下位の監視部に対して異常対応処理要求を行なうことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記各監視部は、対応するモジュールから、あらかじめ定められた形式の監視データを取得することで対応するモジュールの動作を監視することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記各モジュールは、上位のモジュールおよび当該モジュールに対応した監視部に対して、前記情報処理装置のリソースの割り当てを行なうことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記各モジュールは、上位のモジュールと当該モジュールに対応した監視部とで、異なるリソースを割り当てることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記複数のモジュールとして、オペレーティングシステム、ミドルウェア、アプリケーションのうち、少なくとも２つを含むことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−７９２７４（Ｐ２０１２−７９２７４Ａ）
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願番号】特願２０１０−２２６７５８（Ｐ２０１０−２２６７５８）
【出願日】平成２２年１０月６日（２０１０．１０．６）
【出願人】（０００００６５０７）横河電機株式会社 (4,443)
【Ｆターム（参考）】
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願日】平成２２年１０月６日（２０１０．１０．６）
【出願人】（０００００６５０７）横河電機株式会社 (4,443)
【Ｆターム（参考）】
[ Back to top ]