JP5709713B2

JP5709713B2 - アプリケーション監視装置

Info

Publication number: JP5709713B2
Application number: JP2011212629A
Authority: JP
Inventors: 清原　良三; 良三清原
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2011-09-28
Filing date: 2011-09-28
Publication date: 2015-04-30
Anticipated expiration: 2031-09-28
Also published as: JP2013073456A

Description

本発明は、アプリケーションプログラム（以下、単にアプリケーションという）同士で正常に動作しているかどうかをお互いに監視するアプリケーション監視装置に関する。

従来、例えば特許文献１に示されるように、マルチコンピュータにおいて相互監視を行い、また、異常が起こった場合に再起動を行う装置があった。
また、例えば特許文献２に示されるように、監視アプリケーションによって他のアプリケーションの異常を検出し、再起動を行うようにしたものがあった。

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

最近のコンシューマ向け組込み機器などでは、機能が豊富になり、様々な無線ネットワーク機器と連動している。そのためあらゆるタイミングで様々なイベントが起こり、それらに対応してソフトウェアは動作しなければならないが、これらのタイミングをすべての組合せで試験することは容易ではなく、なかなか障害のないまま出荷することは困難である。
そこで、ソフトウェアの異常を検出することが必要となるが、ソフトウェアの異常をより早く発見するには監視の頻度を上げなければならず、監視のために本来の機能が正常に動作しないほどリソースが使われると本末転倒となってしまう問題があった。

また、特許文献１の装置はコンピュータ間の監視であり、単独のコンピュータシステムでは実施することができないという問題点があった。さらに、特許文献２に記載されたような異常監視では、監視アプリケーションそのものが異常となった場合はアプリケーションの監視ができないという問題があった。

この発明は上記のような課題を解決するためになされたもので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することのできるアプリケーション監視装置を得ることを目的とする。

この発明に係るアプリケーション監視装置は、オペレーティングシステム上で実行される複数のアプリケーションプログラムの実行を監視するアプリケーション監視装置であって、複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部とを備え、心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、正規の呼び出し元から呼ばれていることが確認できた場合に処理を実行するようにしたものである。
また、この発明に係るアプリケーション監視装置は、オペレーティングシステム上で実行される複数のアプリケーションプログラムの実行を監視するアプリケーション監視装置であって、複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、心音発生部における心音の発生タイミングを変更する心音変更部とを備えたものである。

この発明のアプリケーション監視装置は、複数のアプリケーションプログラムのそれぞれに、心音を発生する心音発生部と、心音を監視する監視部とを備え、心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、正規の呼び出し元から呼ばれていることが確認できた場合に処理を実行するようにしたので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することができる。
また、この発明のアプリケーション監視装置は、心音発生部における心音の発生タイミングを変更する心音変更部とを備えたので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することができる。

この発明の実施の形態１によるアプリケーション監視最適化装置を適用するコンピュータシステムの階層構造を示す説明図である。この発明の実施の形態１によるアプリケーション監視最適化装置の構成図である。この発明の実施の形態１によるアプリケーション監視最適化装置のアプリケーション本体部の動作を示すフローチャートである。この発明の実施の形態１によるアプリケーション監視最適化装置の心音発生部の処理を示すフローチャートである。この発明の実施の形態１によるアプリケーション監視最適化装置の監視部の動作を示すフローチャートである。この発明の実施の形態１によるアプリケーション監視最適化装置の心音タイミングと監視タイミングの変更動作を示すフローチャートである。この発明の実施の形態１によるアプリケーション監視最適化装置の心音発生部が正規の呼び出し元から呼ばれた場合にのみ動作を行う場合のフローチャートである。この発明の実施の形態１によるアプリケーション監視最適化装置のＣＰＵ使用率に基づくレベル変更動作の具体的な動作を示すフローチャートである。

実施の形態１．
図１は、この発明の実施の形態１によるアプリケーション監視最適化装置を適用するコンピュータシステムの階層構造を示す説明図である。
図示のように、コンピュータシステムは、ハードウェアプラットフォーム（Ｈ／Ｗ）１０１上でオペレーティングシステム（ＯＳ）１０２が動作し、このオペレーティングシステム１０２上でアプリケーション１０３が動作するよう構成されている。ハードウェアプラットフォーム１０１は、オペレーティングシステム１０２やアプリケーション１０３を実行するためのＣＰＵやメモリといったハードウェアを示している。オペレーティングシステム１０２は、アプリケーション１０３の動作を管理するソフトウェアである。アプリケーション１０３は、各種の処理を行うアプリケーションプログラム（ソフトウェア）であり、それぞれのアプリケーション１０３は通信機能１０４を備えて、一つのアプリケーション１０３が他のアプリケーション１０３を監視するよう構成されている。このようにすることにより、すべてのアプリケーション１０３が同時に異常状態になる場合を除いて、アプリケーション１０３間で異常を判断し、アプリケーション１０３を再起動することが可能となる。

図２は、各アプリケーション１０３が有する機能構成を示す説明図であり、実施の形態１におけるアプリケーション監視最適化装置の構成を示すものである。
それぞれのアプリケーション１０３は、アプリケーション本体部２００、監視部２０１、心音発生部２０２、心音タイミング変更部２０３、監視変更部２０４を備えている。アプリケーション本体部２００は、アプリケーション１０３としての各種の処理を行う本体部分である。監視部２０１は、アプリケーション１０３の中でアプリケーション本体部２００とは独立に定期的に動作する機能であって、監視対象となる一つのアプリケーションが正常に動作しているか（生存しているか）の状態を監視する機能部である。即ち、監視部２０１は、自アプリケーション１０３以外の監視対象とする特定のアプリケーション１０３の心音を監視するものである。心音発生部２０２は、そのアプリケーション１０３において、アプリケーション本体部２００自身が正常に動作していることを示す心音機能である。この心音機能とは、ハードウェアなどで実装する所謂ウォッチドッグタイマと同様で、一定の動作の中で必ず心音を発生するという動作をするようにプログラムは作成される。即ち、心音動作を一定時間行わなかった場合に、そのアプリケーション１０３が異常であると判断するために利用する機能である。

心音タイミング変更部２０３は、心音の間隔を変更する機能である。例えば、心音発生部２０２が呼び出される度に心音を発生させると、処理のオーバヘッドが増える。十分高速なＣＰＵではその間隔は短い方が良いが、遅いＣＰＵでは間隔を短くするとその処理がオーバヘッドとなり本末転倒となる。従って、このようなＣＰＵの能力に合わせて心音タイミングを変更するために心音タイミング変更部２０３が設けられている。また、監視変更部２０４は、例えば心音の発生される間隔が変更になると監視の間隔もその心音の頻度に合わせて変更すべきものであるため、そのための変更機能である。

尚、これらアプリケーション本体部２００〜監視変更部２０４は、それぞれの機能に対応したプログラムをＣＰＵやメモリといったハードウェアで実行することにより実現される機能部である。

図３、図４を利用して心音発生部２０２の動作を説明する。
図３は、アプリケーション本体部２００が実行する処理の一例を示すフローチャートである。例えば、ステップＳＴ３０１で、処理を行うのに先立ち、心音発生部２０２への呼び出しを行う。その後、ステップＳＴ３０２で、本来のアプリケーション本体部２００の動作に戻る。また、特定のポイントで心音発生部２０２の呼び出しを行うのがステップＳＴ３０３である。ステップＳＴ３０３で心音発生部２０２の呼び出しを行った後に、ステップＳＴ３０４で再びアプリケーション本体部２００本来の処理に戻る。ステップＳＴ３０５では関数呼び出しが入り、呼び出し先のステップＳＴ３０６の入り口とステップＳＴ３０８の出口で再び心音発生部２０２の呼び出しを行う。ステップＳＴ３０７では関数本来の処理を行い、関数の処理が終わるとステップＳＴ３０９でアプリケーション本体部２００本来の処理に戻る。

尚、図３に示した一連の処理は一例であって、処理の中で一定の時間以内に心音を発生するように心音発生部２０２の呼び出し機能を挿入しておけば他の方法であってもよい。この挿入は遅いＣＰＵでも一定の時間以内に呼び出されるように配置しておく。

図４は、心音発生部２０２の処理フローの一例である。
ステップＳＴ４０１で頻度確認処理を行う。これは、例えば頻度のレベル１であれば毎回この機能を呼び出された場合はステップＳＴ４０２でのデータのアップデート処理を行う。レベル２であれば２回に１回のみデータのアップデート処理を行い、自分の呼び出された回数だけは覚えておいて、偶数回目の呼び出しであれば何もしないで、自分の呼び出された回数の情報だけをアップデートして処理を終える。また、頻度のレベルは、心音タイミング変更部２０３で管理しており、この頻度のレベルによって心音発生タイミングを変更する。

この心音機能呼び出しの実装は、アプリケーション本体部２００が関数呼び出しの形で実装しても良いし、頻度の確認の処理に限りインライン展開する所謂マクロ機能として実装しても良い。また、一度実行して頻度を決めてしまえば、再度コンパイルする時点でこの処理を抜けるような条件付コンパイルにて実装してもかまわない。

ステップＳＴ４０２の共有メモリアップデートは、心音発生部２０２が心音を発生する度に他のアプリケーション１０３からもアクセス可能なメモリのカウントアップを行うもので、他のアプリケーション１０３の監視機能（監視部２０１）がそのメモリをアクセスして、前回見たものからカウントアップされていたらそのアプリケーション１０３は正常に動作していると判断するためのものである。あるいは、フラグを書き込むことによってそのアプリケーション１０３が正常に動作していることを示すようにしてもよい。

従って、アプリケーション１０３の生存が判断できるのであれば、共有メモリではなく、自己のメモリで他アプリの要求に対して答える形でも良いし、メモリ以外のデバイスに情報を書き込むのでもかまわない。

次に、図５のフローチャートを用いて監視部２０１の動作について説明する。
アプリケーション本体部２００から監視部２０１が呼び出されると、ステップＳＴ５０１で監視部２０１はアプリケーション本体部２００とは独立に別のプロセスまたはプログラムとして動作する。
呼び出された処理はステップＳＴ５０９で呼び出し元に戻る。一方、別に作られた監視プログラム（プロセス）はステップＳＴ５０２以下を実行する。

ステップＳＴ５０２では、予め決められているか、またはダイナミックに既にアプリケーション１０３として登録されている中から選んで監視する対象を決定する。つまり、監視先のアプリケーション１０３の共有メモリなど、どこを読めば状態がわかるかという情報を設定する。
ステップＳＴ５０３では監視間隔を設定する。これは心音の発生間隔に対応して適切な値を設定する。例えば、監視間隔としては、心音が発生する最小間隔のＮ倍以上で、かつ、最大間隔のＮ倍以下（Ｎは正の整数）の値とする。

例えば、心音の発生する最小間隔が６０ｍｓであり、最大間隔は２００ｍｓであるとする。ここで、監視間隔が大きいと、異常が起きたことをチェックするのが遅れてしまい、監視間隔が小さいとオーバヘッドが大きくなってしまう。最小間隔が６０ｍｓであるということはそれより小さい監視間隔では意味がないことになるため、６０ｍｓ以上とする。また、最大間隔が２００ｍｓでそれより大きくすることは、心音自体のオーバヘッドの方が無駄となってしまう。そこで、最大間隔は２００ｍｓ以下とする。また、ＣＰＵの負荷が大きい場合、心音の発生を１回飛ばす（行わない）という状態が生じる。この場合は、例えば、６０ｍｓの間隔であったのが１回心音発生がないと１２０ｍｓの間隔になり、２回心音発生が行われなかった場合は１８０ｍｓの間隔となってしまう。また、最大間隔も、４００ｍｓ，６００ｍｓ，…となる。そこで、このような心音発生がなかった間隔を考慮しＮ倍の値を設定する。なお、Ｎの値はＣＰＵの性能や負荷等に基づいて決定する。このような設定により、何回か監視する間に少なくとも１回は心音のあることを正常と判断することができる。

ステップＳＴ５０４で監視先の情報を取得する。最初は稼動しているのかどうかはわからないが稼動しているという情報を取得する。
ステップＳＴ５０５で監視の間隔時間のスリープ状態に入る。スリープ状態から抜けると、再度ステップＳＴ５０６で、ステップＳＴ５０４と同様に監視先の情報を取得する。ここで、ステップＳＴ５０４と違う状態になっていたら監視先のアプリケーション１０３が正常に動作していることを意味する。その場合は、ステップＳＴ５０７で正常と判断し、再びステップＳＴ５０５に戻り、次の間隔までスリープする。

一方、ステップＳＴ５０６、ＳＴ５０７で、例えば監視先の情報が変わってないといった場合で、異常が発生していると判断されれば、ステップＳＴ５０８で対象アプリケーション１０３を強制終了し、同アプリケーション１０３を再起動する。

図６に、心音タイミング変更部２０３と監視変更部２０４による心音タイミングの変更と監視タイミングの変更の実施フローを示す。心音タイミングと監視タイミングの調整は、出荷前の機器や、利用者が指定して起動する場合や、機器が起動する時に必ず実行するなどどのタイミングで起動しても構わない。

ステップＳＴ６０１では、今まで動作していたものであれば、その設定を継続する。そうでなければ、初めての起動のときに使うことになっている設定を用いて、心音や監視の頻度の情報を設定する。これによって、心音機能が何回か呼ばれた場合に、その中でどの程度の回数は心音を発するかが決まり、監視のための動作間隔もここで決まる。

ステップ６０２でコンピュータシステムのアプリケーション１０３をすべて起動した状態にする。この起動状態では各アプリケーション１０３が通常の状態で動作するようにしておく。特に最初は初期化などＣＰＵの使用率が高い状態になるようにしておく。ステップＳＴ６０３で空きＣＰＵ時間を計測する。通常のアプリの状態でどうなるかは起動時のＣＰＵ占有率などからも推定できる。このＣＰＵ占有率には心音発生部２０２や監視部２０１の動作の部分も入るため、本来のアプリの占有率より高くなる。ステップＳＴ６０３でＣＰＵ占有率（空きＣＰＵ時間）を計測した後、ステップＳＴ６０４でアプリケーション１０３を終了し、ステップＳＴ６０５においてＣＰＵ使用率を判定する。

ステップＳＴ６０５の判定において、アプリケーション１０３のＣＰＵ使用率が一定の範囲より低ければ、より精度を上げるために１レベル心音の頻度の間隔を短くしたり、監視部２０１における監視間隔を短くするといったレベル変更処理をステップＳＴ６０６やステップＳＴ６０８で実行する。一定の範囲内に入っていればステップＳＴ６０７でその設定を保存して終了する。ステップＳＴ６０６，ＳＴ６０８実行後はステップＳＴ６０２に戻り、再びＣＰＵ使用率の確認をアプリケーション１０３の再起動から行い、適切な範囲に入るまでこの操作を繰り返す。なお、ステップＳＴ６０７で設定保存したものは、次に普通に起動された場合に生かされている場合もあるし、この保存したものを利用して再コンパイルリンクすれば有効になる場合もある。

次に、心音発生部２０２が正規の呼び出し元から呼ばれた場合にのみ動作を行う例を図７のフローチャートを用いて説明する。
図７のフローチャートにおいて、ステップＳＴ７０１，ＳＴ７０５は、図４に示した処理と同様である。このような心音機能であるステップＳＴ７０１、ＳＴ７０５にさらに、心音機能を実行する直前に、正規の呼び出し元から呼び出されたものかどうか、即ち暴走によって呼ばれたものであるのかどうかを判定する。

そのために、ステップＳＴ７０２でスタック上の呼び出し元または戻り先アドレスを確認し、これがプログラムのコンパイル、リンク時に確定したアドレスまたは自己のアドレスからの相対的な位置として正しいかどうかを、ステップＳＴ７０３において、一覧表を探すことによって確認する。
ステップＳＴ７０４において、正規のところから呼び出しを受けたかどうかを判定し、誤っていた場合には処理をせずに終了する。あるいは、心音機能を呼び出す際に、あるメモリのビットフラグをオンにしておいて、心音機能が呼び出されると、ステップＳＴ７０２でスタック上の呼び出し元の情報を見るのではなく、対象とするメモリのビットフラグのオンオフを確認したうえで、フラグをオフにする。

ステップＳＴ７０３、ＳＴ７０４の部分がオンであった場合（一覧表のアドレスが一致した場合）には正規のところから呼び出されたと判断し、心音を発生し、ステップＳＴ７０５でアップデートを行うが、オフであった場合（一覧表のアドレスに一致したアドレスがなかった場合）には何もせずに終了する。

次に、図８のフローチャートを用いて、ＣＰＵ使用率に基づくレベル変更動作の具体的な動作について説明する。
ステップＳＴ８０１でＣＰＵ使用率を取得する。これは、オペレーティングシステム１０２の基本機能を利用して取得すれば良い。オペレーティングシステム１０２にはアプリケーション１０３のＣＰＵ使用率を提供するインタフェースが備えられているものが多い。

ステップＳＴ８０２では例えば使用率が５０％を超えたとすると、心音機能や監視機能のオーバヘッドが大きいと考えて、その割合を減らす処理を行うためにステップＳＴ８０４に移行する。ステップＳＴ８０４では、心音発生部２０２が呼び出された際に毎回心音を発生するのではなく、例えば、心音タイミング変更部２０３における頻度レベルから、１０回に１回とか、１０回に２回というように心音を発生しないようにする。これは心音発生部２０２が呼び出された回数と心音タイミング変更部２０３におけるレベル設定、即ちどの程度の割合で実際の心音発生を行うべきかという数値から計算可能である。例えば１割減らすのであれば１０回に１回心音を発生しないことにすれば良い。また、連続して心音を発生させない、ということがないように、回数を割り算して割り切れたかどうかなどで判断すると均等に発生させない回を分散することが出来る。

次に、ステップＳＴ８０５で、ステップＳＴ８０４で設定した頻度に応じて、監視変更部２０４は、監視部２０１の監視間隔を伸ばすように変更する。例えば、一割頻度が変わったのであれば一割伸ばすというように変更する。

ステップＳＴ８０３では最低のＣＰＵ使用率割合と比較する。例えばＣＰＵ使用率が３０％より小さいようなケースには心音の頻度レベルを上げてよい。その方が正確に問題が発生したことがわかるからである。このような場合には、ステップＳＴ８０６で心音の頻度レベルをステップＳＴ８０４と逆の形で設定する。ステップＳＴ８０７ではステップＳＴ８０５同様に監視間隔を逆に縮める。例えば、一割頻度が上がったのであれば監視間隔は１割縮める。

上記のように構成することによりアプリケーション１０３間での異常の発見をそのハードウェアの性能に合わせて、素早く、正確に判断できるようになる。即ち、同じソフトウェアでも機種が変わったり、他の原因でクロックの供給速度が変わったりしても自動的に調整することができるなど開発効率を向上させることができるようになる。

以上説明したように、実施の形態１のアプリケーション監視最適化装置によれば、オペレーティングシステム上で複数のアプリケーションプログラムが実行されるコンピュータシステムにおいて、複数のアプリケーションプログラムの実行を監視するアプリケーション監視最適化装置であって、複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、心音発生部における心音の発生タイミングを変更する心音変更部と、監視部の監視タイミングを変更する監視変更部とを備えたので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、心音発生部は、自アプリケーションプログラムが所定の処理を行う毎に呼び出されるようにしたので、アプリケーションの異常発生を確実に判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、正規の呼び出し元から呼ばれていることが確認できた場合にのみ処理を実行するようにしたので、例えば、ＣＰＵの暴走によって呼ばれたものであるのかどうかを判定することができ、アプリケーションの異常発生を確実に判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、心音発生部は、他のアプリケーションプログラムからアクセスできる領域のメモリにフラグを書き込むか、または、領域の値を前回の値から変更することで正常動作を示すようにしたので、簡単な構成でアプリケーションの異常発生を判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、監視部は、一定の間隔で周期的に監視動作を行うようにしたので、アプリケーションの異常発生を容易に判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、監視部は、監視対象とする特定のアプリケーションプログラムが正常に動作していないと判断した場合は、アプリケーションプログラムを再起動するようにしたので、ユーザに対する使い勝手の向上を図ることができる。すなわち、アプリケーションによっては不具合といっても単に再起動すれば良いだけのものも多く、こういったアプリケーションは異常が起きたことを瞬時に判定し再起動できればユーザも気づかないことが多い。また、より安全性が要求されるような機器においては、例え異常ではなかったとしても異常かもしれない段階で安全に再起動できればユーザも気づかずにすむ場合も多いからである。

また、実施の形態１のアプリケーション監視最適化装置によれば、心音タイミング変更部は、心音発生部が呼び出された場合に、所定回数に一回の割合で心音を発生させるよう制御することで心音発生タイミングを変更するようにしたので、簡単な構成で心音発生タイミングを変更することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、心音発生タイミングは、予め設定された心音発生頻度レベルに応じて決定されているようにしたので、簡単な構成で心音発生タイミングを制御することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、監視変更部は、監視タイミングの変更として監視周期を変更するようにしたので、アプリケーションの異常発生を確実に判断することができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、監視部は、心音発生部の心音発生間隔に応じた監視間隔で監視を行うようにしたので、心音発生と心音監視を効率よく行うことができる。

また、実施の形態１のアプリケーション監視最適化装置によれば、監視間隔は、心音発生間隔における最小間隔のＮ倍以上で、かつ、最大間隔のＮ倍以下（Ｎは正の整数）の値とするようにしたので、何回か監視する間に少なくとも１回は心音のあることを正常と判断することができ、確実に心音監視を行うことができる。

なお、本願発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、もしくは実施の形態の任意の構成要素の省略が可能である。

１０１ハードウェアプラットフォーム（Ｈ／Ｗ）、１０２オペレーティングシステム（ＯＳ）、１０３アプリケーション、１０４通信機能、２００アプリケーション本体部、２０１監視部、２０２心音発生部、２０３心音タイミング変更部、２０４監視変更部。

Claims

オペレーティングシステム上で実行される複数のアプリケーションプログラムの前記実行を監視するアプリケーション監視装置であって、
前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、
自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、
自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部とを備え、
前記心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、当該正規の呼び出し元から呼ばれていることが確認できた場合に処理を実行することを特徴とするアプリケーション監視装置。
オペレーティングシステム上で実行される複数のアプリケーションプログラムの前記実行を監視するアプリケーション監視装置であって、
前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、
自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、
自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、
前記心音発生部における心音の発生タイミングを変更する心音変更部とを備えたことを特徴とするアプリケーション監視装置。
前記心音変更部は、前記心音発生部が呼び出された場合に、所定回数に一回の割合で心音を発生させるよう制御することで心音発生タイミングを変更することを特徴とする請求項２記載のアプリケーション監視装置。
前記心音発生タイミングは、予め設定された心音発生頻度レベルに応じて決定されていることを特徴とする請求項３記載のアプリケーション監視装置。
前記心音発生部は、前記自アプリケーションプログラムが所定の処理を行う毎に呼び出されることを特徴とする請求項１から請求項４のうちのいずれか一項記載のアプリケーション監視装置。
前記心音発生部は、他のアプリケーションプログラムからアクセスできる領域のメモリにフラグを書き込むか、または、前記領域の値を前回の値から変更することで正常動作を示すことを特徴とする請求項１から請求項５のうちのいずれか一項記載のアプリケーション監視装置。
前記監視部は、一定の間隔で周期的に監視動作を行うことを特徴とする請求項１から請求項６のうちのいずれか一項記載のアプリケーション監視装置。
前記監視部は、前記監視対象とする特定のアプリケーションプログラムが正常に動作していないと判断した場合は、当該アプリケーションプログラムを再起動することを特徴とする請求項１から請求項７のうちのいずれか一項記載のアプリケーション監視装置。
前記監視部の監視タイミングを変更する監視変更部を備え、
前記監視変更部は、監視タイミングの変更として監視周期を変更することを特徴とする請求項１から請求項８のうちのいずれか一項記載のアプリケーション監視装置。
前記監視部は、前記監視対象とする特定のアプリケーションプログラムの心音発生間隔に応じた監視間隔で監視を行うことを特徴とする請求項１から請求項９のうちのいずれか一項記載のアプリケーション監視装置。
前記監視間隔は、前記心音発生間隔における最小間隔のＮ倍以上で、かつ、最大間隔のＮ倍以下（Ｎは正の整数）の値とすることを特徴とする請求項１０記載のアプリケーション監視装置。