"オペレーティングシステム上で複数のアプリケーションプログラムが実行されるコンピュータシステムにおいて、当該複数のアプリケーションプログラムの実行を監視するアプリケーション監視最適化装置であって、前記複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、前記心音発生部における心音の発生タイミングを変更する心音変更部と、前記監視部の監視タイミングを変更する監視変更部とを備えたことを特徴とするアプリケーション監視最適化装置。心音発生部は、自アプリケーションプログラムが所定の処理を行う毎に呼び出されることを特徴とする請求項1記載のアプリケーション監視最適化装置。心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、当該正規の呼び出し元から呼ばれていることが確認できた場合にのみ処理を実行することを特徴とする請求項2記載のアプリケーション監視最適化装置。心音発生部は、他のアプリケーションプログラムからアクセスできる領域のメモリにフラグを書き込むか、または、前記領域の値を前回の値から変更することで正常動作を示すことを特徴とする請求項2記載のアプリケーション監視最適化装置。監視部は、一定の間隔で周期的に監視動作を行うことを特徴とする請求項1記載のアプリケーション監視最適化装置。監視部は、監視対象とする特定のアプリケーションプログラムが正常に動作していないと判断した場合は、当該アプリケーションプログラムを再起動することを特徴とする請求項1記載のアプリケーション監視最適化装置。心音タイミング変更部は、心音発生部が呼び出された場合に、所定回数に一回の割合で心音を発生させるよう制御することで心音発生タイミングを変更することを特徴とする請求項1記載のアプリケーション監視最適化装置。心音発生タイミングは、予め設定された心音発生頻度レベルに応じて決定されていることを特徴とする請求項7記載のアプリケーション監視最適化装置。監視変更部は、監視タイミングの変更として監視周期を変更することを特徴とする請求項1記載のアプリケーション監視最適化装置。監視部は、心音発生部の心音発生間隔に応じた監視間隔で監視を行うことを特徴とする請求項1記載のアプリケーション監視最適化装置。監視間隔は、心音発生間隔における最小間隔のN倍以上で、かつ、最大間隔のN倍以下Nは正の整数の値とすることを特徴とする請求項10記載のアプリケーション監視最適化装置。最近のコンシューマ向け組込み機器などでは、機能が豊富になり、様々な無線ネットワーク機器と連動している。そのためあらゆるタイミングで様々なイベントが起こり、それらに対応してソフトウェアは動作しなければならないが、これらのタイミングをすべての組合せで試験することは容易ではなく、なかなか障害のないまま出荷することは困難である。そこで、ソフトウェアの異常を検出することが必要となるが、ソフトウェアの異常をより早く発見するには監視の頻度を上げなければならず、監視のために本来の機能が正常に動作しないほどリソースが使われると本末転倒となってしまう問題があった。また、特許文献1の装置はコンピュータ間の監視であり、単独のコンピュータシステムでは実施することができないという問題点があった。さらに、特許文献2に記載されたような異常監視では、監視アプリケーションそのものが異常となった場合はアプリケーションの監視ができないという問題があった。この発明は上記のような課題を解決するためになされたもので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することのできるアプリケーション監視最適化装置を得ることを目的とする。この発明に係るアプリケーション監視最適化装置は、オペレーティングシステム上で複数のアプリケーションプログラムが実行されるコンピュータシステムにおいて、複数のアプリケーションプログラムの実行を監視するアプリケーション監視最適化装置であって、複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、心音発生部における心音の発生タイミングを変更する心音変更部と、監視部の監視タイミングを変更する監視変更部とを備えたものである。この発明のアプリケーション監視最適化装置は、複数のアプリケーションプログラムのそれぞれに、心音を発生する心音発生部と、心音を監視する監視部と、心音の発生タイミングを変更する心音変更部と、監視タイミングを変更する監視変更部とを備えたので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することができる。実施の形態1.図1は、この発明の実施の形態1によるアプリケーション監視最適化装置を適用するコンピュータシステムの階層構造を示す説明図である。図示のように、コンピュータシステムは、ハードウェアプラットフォームH/W101上でオペレーティングシステムOS102が動作し、このオペレーティングシステム102上でアプリケーション103が動作するよう構成されている。ハードウェアプラットフォーム101は、オペレーティングシステム102やアプリケーション103を実行するためのCPUやメモリといったハードウェアを示している。オペレーティングシステム102は、アプリケーション103の動作を管理するソフトウェアである。アプリケーション103は、各種の処理を行うアプリケーションプログラムソフトウェアであり、それぞれのアプリケーション103は通信機能104を備えて、一つのアプリケーション103が他のアプリケーション103を監視するよう構成されている。このようにすることにより、すべてのアプリケーション103が同時に異常状態になる場合を除いて、アプリケーション103間で異常を判断し、アプリケーション103を再起動することが可能となる。図2は、各アプリケーション103が有する機能構成を示す説明図であり、実施の形態1におけるアプリケーション監視最適化装置の構成を示すものである。それぞれのアプリケーション103は、アプリケーション本体部200、監視部201、心音発生部202、心音タイミング変更部203、監視変更部204を備えている。アプリケーション本体部200は、アプリケーション103としての各種の処理を行う本体部分である。監視部201は、アプリケーション103の中でアプリケーション本体部200とは独立に定期的に動作する機能であって、監視対象となる一つのアプリケーションが正常に動作しているか生存しているかの状態を監視する機能部である。即ち、監視部201は、自アプリケーション103以外の監視対象とする特定のアプリケーション103の心音を監視するものである。心音発生部202は、そのアプリケーション103において、アプリケーション本体部200自身が正常に動作していることを示す心音機能である。この心音機能とは、ハードウェアなどで実装する所謂ウォッチドッグタイマと同様で、一定の動作の中で必ず心音を発生するという動作をするようにプログラムは作成される。即ち、心音動作を一定時間行わなかった場合に、そのアプリケーション103が異常であると判断するために利用する機能である。心音タイミング変更部203は、心音の間隔を変更する機能である。例えば、心音発生部202が呼び出される度に心音を発生させると、処理のオーバヘッドが増える。十分高速なCPUではその間隔は短い方が良いが、遅いCPUでは間隔を短くするとその処理がオーバヘッドとなり本末転倒となる。従って、このようなCPUの能力に合わせて心音タイミングを変更するために心音タイミング変更部203が設けられている。また、監視変更部204は、例えば心音の発生される間隔が変更になると監視の間隔もその心音の頻度に合わせて変更すべきものであるため、そのための変更機能である。尚、これらアプリケーション本体部200~監視変更部204は、それぞれの機能に対応したプログラムをCPUやメモリといったハードウェアで実行することにより実現される機能部である。図3、図4を利用して心音発生部202の動作を説明する。図3は、アプリケーション本体部200が実行する処理の一例を示すフローチャートである。例えば、ステップST301で、処理を行うのに先立ち、心音発生部202への呼び出しを行う。その後、ステップST302で、本来のアプリケーション本体部200の動作に戻る。また、特定のポイントで心音発生部202の呼び出しを行うのがステップST303である。ステップST303で心音発生部202の呼び出しを行った後に、ステップST304で再びアプリケーション本体部200本来の処理に戻る。ステップST305では関数呼び出しが入り、呼び出し先のステップST306の入り口とステップST308の出口で再び心音発生部202の呼び出しを行う。ステップST307では関数本来の処理を行い、関数の処理が終わるとステップST309でアプリケーション本体部200本来の処理に戻る。尚、図3に示した一連の処理は一例であって、処理の中で一定の時間以内に心音を発生するように心音発生部202の呼び出し機能を挿入しておけば他の方法であってもよい。この挿入は遅いCPUでも一定の時間以内に呼び出されるように配置しておく。図4は、心音発生部202の処理フローの一例である。ステップST401で頻度確認処理を行う。これは、例えば頻度のレベル1であれば毎回この機能を呼び出された場合はステップST402でのデータのアップデート処理を行う。レベル2であれば2回に1回のみデータのアップデート処理を行い、自分の呼び出された回数だけは覚えておいて、偶数回目の呼び出しであれば何もしないで、自分の呼び出された回数の情報だけをアップデートして処理を終える。また、頻度のレベルは、心音タイミング変更部203で管理しており、この頻度のレベルによって心音発生タイミングを変更する。この心音機能呼び出しの実装は、アプリケーション本体部200が関数呼び出しの形で実装しても良いし、頻度の確認の処理に限りインライン展開する所謂マクロ機能として実装しても良い。また、一度実行して頻度を決めてしまえば、再度コンパイルする時点でこの処理を抜けるような条件付コンパイルにて実装してもかまわない。ステップST402の共有メモリアップデートは、心音発生部202が心音を発生する度に他のアプリケーション103からもアクセス可能なメモリのカウントアップを行うもので、他のアプリケーション103の監視機能監視部201がそのメモリをアクセスして、前回見たものからカウントアップされていたらそのアプリケーション103は正常に動作していると判断するためのものである。あるいは、フラグを書き込むことによってそのアプリケーション103が正常に動作していることを示すようにしてもよい。従って、アプリケーション103の生存が判断できるのであれば、共有メモリではなく、自己のメモリで他アプリの要求に対して答える形でも良いし、メモリ以外のデバイスに情報を書き込むのでもかまわない。次に、図5のフローチャートを用いて監視部201の動作について説明する。アプリケーション本体部200から監視部201が呼び出されると、ステップST501で監視部201はアプリケーション本体部200とは独立に別のプロセスまたはプログラムとして動作する。呼び出された処理はステップST509で呼び出し元に戻る。一方、別に作られた監視プログラムプロセスはステップST502以下を実行する。ステップST502では、予め決められているか、またはダイナミックに既にアプリケーション103として登録されている中から選んで監視する対象を決定する。つまり、監視先のアプリケーション103の共有メモリなど、どこを読めば状態がわかるかという情報を設定する。ステップST503では監視間隔を設定する。これは心音の発生間隔に対応して適切な値を設定する。例えば、監視間隔としては、心音が発生する最小間隔のN倍以上で、かつ、最大間隔のN倍以下Nは正の整数の値とする。例えば、心音の発生する最小間隔が60msであり、最大間隔は200msであるとする。ここで、監視間隔が大きいと、異常が起きたことをチェックするのが遅れてしまい、監視間隔が小さいとオーバヘッドが大きくなってしまう。最小間隔が60msであるということはそれより小さい監視間隔では意味がないことになるため、60ms以上とする。また、最大間隔が200msでそれより大きくすることは、心音自体のオーバヘッドの方が無駄となってしまう。そこで、最大間隔は200ms以下とする。また、CPUの負荷が大きい場合、心音の発生を1回飛ばす行わないという状態が生じる。この場合は、例えば、60msの間隔であったのが1回心音発生がないと120msの間隔になり、2回心音発生が行われなかった場合は180msの間隔となってしまう。また、最大間隔も、400ms,600ms,...となる。そこで、このような心音発生がなかった間隔を考慮しN倍の値を設定する。なお、Nの値はCPUの性能や負荷等に基づいて決定する。このような設定により、何回か監視する間に少なくとも1回は心音のあることを正常と判断することができる。ステップST504で監視先の情報を取得する。最初は稼動しているのかどうかはわからないが稼動しているという情報を取得する。ステップST505で監視の間隔時間のスリープ状態に入る。スリープ状態から抜けると、再度ステップST506で、ステップST504と同様に監視先の情報を取得する。ここで、ステップST504と違う状態になっていたら監視先のアプリケーション103が正常に動作していることを意味する。その場合は、ステップST507で正常と判断し、再びステップST505に戻り、次の間隔までスリープする。一方、ステップST506、ST507で、例えば監視先の情報が変わってないといった場合で、異常が発生していると判断されれば、ステップST508で対象アプリケーション103を強制終了し、同アプリケーション103を再起動する。図6に、心音タイミング変更部203と監視変更部204による心音タイミングの変更と監視タイミングの変更の実施フローを示す。心音タイミングと監視タイミングの調整は、出荷前の機器や、利用者が指定して起動する場合や、機器が起動する時に必ず実行するなどどのタイミングで起動しても構わない。ステップST601では、今まで動作していたものであれば、その設定を継続する。そうでなければ、初めての起動のときに使うことになっている設定を用いて、心音や監視の頻度の情報を設定する。これによって、心音機能が何回か呼ばれた場合に、その中でどの程度の回数は心音を発するかが決まり、監視のための動作間隔もここで決まる。ステップ602でコンピュータシステムのアプリケーション103をすべて起動した状態にする。この起動状態では各アプリケーション103が通常の状態で動作するようにしておく。特に最初は初期化などCPUの使用率が高い状態になるようにしておく。ステップST603で空きCPU時間を計測する。通常のアプリの状態でどうなるかは起動時のCPU占有率などからも推定できる。このCPU占有率には心音発生部202や監視部201の動作の部分も入るため、本来のアプリの占有率より高くなる。ステップST603でCPU占有率空きCPU時間を計測した後、ステップST604でアプリケーション103を終了し、ステップST605においてCPU使用率を判定する。ステップST605の判定において、アプリケーション103のCPU使用率が一定の範囲より低ければ、より精度を上げるために1レベル心音の頻度の間隔を短くしたり、監視部201における監視間隔を短くするといったレベル変更処理をステップST606やステップST608で実行する。一定の範囲内に入っていればステップST607でその設定を保存して終了する。ステップST606,ST608実行後はステップST602に戻り、再びCPU使用率の確認をアプリケーション103の再起動から行い、適切な範囲に入るまでこの操作を繰り返す。なお、ステップST607で設定保存したものは、次に普通に起動された場合に生かされている場合もあるし、この保存したものを利用して再コンパイルリンクすれば有効になる場合もある。次に、心音発生部202が正規の呼び出し元から呼ばれた場合にのみ動作を行う例を図7のフローチャートを用いて説明する。図7のフローチャートにおいて、ステップST701,ST705は、図4に示した処理と同様である。このような心音機能であるステップST701、ST705にさらに、心音機能を実行する直前に、正規の呼び出し元から呼び出されたものかどうか、即ち暴走によって呼ばれたものであるのかどうかを判定する。そのために、ステップST702でスタック上の呼び出し元または戻り先アドレスを確認し、これがプログラムのコンパイル、リンク時に確定したアドレスまたは自己のアドレスからの相対的な位置として正しいかどうかを、ステップST703において、一覧表を探すことによって確認する。ステップST704において、正規のところから呼び出しを受けたかどうかを判定し、誤っていた場合には処理をせずに終了する。あるいは、心音機能を呼び出す際に、あるメモリのビットフラグをオンにしておいて、心音機能が呼び出されると、ステップST702でスタック上の呼び出し元の情報を見るのではなく、対象とするメモリのビットフラグのオンオフを確認したうえで、フラグをオフにする。ステップST703、ST704の部分がオンであった場合一覧表のアドレスが一致した場合には正規のところから呼び出されたと判断し、心音を発生し、ステップST705でアップデートを行うが、オフであった場合一覧表のアドレスに一致したアドレスがなかった場合には何もせずに終了する。次に、図8のフローチャートを用いて、CPU使用率に基づくレベル変更動作の具体的な動作について説明する。ステップST801でCPU使用率を取得する。これは、オペレーティングシステム102の基本機能を利用して取得すれば良い。オペレーティングシステム102にはアプリケーション103のCPU使用率を提供するインタフェースが備えられているものが多い。ステップST802では例えば使用率が50を超えたとすると、心音機能や監視機能のオーバヘッドが大きいと考えて、その割合を減らす処理を行うためにステップST804に移行する。ステップST804では、心音発生部202が呼び出された際に毎回心音を発生するのではなく、例えば、心音タイミング変更部203における頻度レベルから、10回に1回とか、10回に2回というように心音を発生しないようにする。これは心音発生部202が呼び出された回数と心音タイミング変更部203におけるレベル設定、即ちどの程度の割合で実際の心音発生を行うべきかという数値から計算可能である。例えば1割減らすのであれば10回に1回心音を発生しないことにすれば良い。また、連続して心音を発生させない、ということがないように、回数を割り算して割り切れたかどうかなどで判断すると均等に発生させない回を分散することが出来る。次に、ステップST805で、ステップST804で設定した頻度に応じて、監視変更部204は、監視部201の監視間隔を伸ばすように変更する。例えば、一割頻度が変わったのであれば一割伸ばすというように変更する。ステップST803では最低のCPU使用率割合と比較する。例えばCPU使用率が30より小さいようなケースには心音の頻度レベルを上げてよい。その方が正確に問題が発生したことがわかるからである。このような場合には、ステップST806で心音の頻度レベルをステップST804と逆の形で設定する。ステップST807ではステップST805同様に監視間隔を逆に縮める。例えば、一割頻度が上がったのであれば監視間隔は1割縮める。上記のように構成することによりアプリケーション103間での異常の発見をそのハードウェアの性能に合わせて、素早く、正確に判断できるようになる。即ち、同じソフトウェアでも機種が変わったり、他の原因でクロックの供給速度が変わったりしても自動的に調整することができるなど開発効率を向上させることができるようになる。以上説明したように、実施の形態1のアプリケーション監視最適化装置によれば、オペレーティングシステム上で複数のアプリケーションプログラムが実行されるコンピュータシステムにおいて、複数のアプリケーションプログラムの実行を監視するアプリケーション監視最適化装置であって、複数のアプリケーションプログラムのそれぞれに対応して設けられ、自アプリケーションプログラムが正常に動作していることを示す心音を発生する心音発生部と、自アプリケーションプログラム以外の監視対象とする特定のアプリケーションプログラムの心音を監視する監視部と、心音発生部における心音の発生タイミングを変更する心音変更部と、監視部の監視タイミングを変更する監視変更部とを備えたので、適切なオーバヘッドで動作し、アプリケーションの異常発生を容易に判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、心音発生部は、自アプリケーションプログラムが所定の処理を行う毎に呼び出されるようにしたので、アプリケーションの異常発生を確実に判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、心音発生部は、アプリケーションプログラムが正常に動作している場合の呼び出し元を正規の呼び出し元として管理し、正規の呼び出し元から呼ばれていることが確認できた場合にのみ処理を実行するようにしたので、例えば、CPUの暴走によって呼ばれたものであるのかどうかを判定することができ、アプリケーションの異常発生を確実に判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、心音発生部は、他のアプリケーションプログラムからアクセスできる領域のメモリにフラグを書き込むか、または、領域の値を前回の値から変更することで正常動作を示すようにしたので、簡単な構成でアプリケーションの異常発生を判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、監視部は、一定の間隔で周期的に監視動作を行うようにしたので、アプリケーションの異常発生を容易に判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、監視部は、監視対象とする特定のアプリケーションプログラムが正常に動作していないと判断した場合は、アプリケーションプログラムを再起動するようにしたので、ユーザに対する使い勝手の向上を図ることができる。すなわち、アプリケーションによっては不具合といっても単に再起動すれば良いだけのものも多く、こういったアプリケーションは異常が起きたことを瞬時に判定し再起動できればユーザも気づかないことが多い。また、より安全性が要求されるような機器においては、例え異常ではなかったとしても異常かもしれない段階で安全に再起動できればユーザも気づかずにすむ場合も多いからである。また、実施の形態1のアプリケーション監視最適化装置によれば、心音タイミング変更部は、心音発生部が呼び出された場合に、所定回数に一回の割合で心音を発生させるよう制御することで心音発生タイミングを変更するようにしたので、簡単な構成で心音発生タイミングを変更することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、心音発生タイミングは、予め設定された心音発生頻度レベルに応じて決定されているようにしたので、簡単な構成で心音発生タイミングを制御することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、監視変更部は、監視タイミングの変更として監視周期を変更するようにしたので、アプリケーションの異常発生を確実に判断することができる。また、実施の形態1のアプリケーション監視最適化装置によれば、監視部は、心音発生部の心音発生間隔に応じた監視間隔で監視を行うようにしたので、心音発生と心音監視を効率よく行うことができる。また、実施の形態1のアプリケーション監視最適化装置によれば、監視間隔は、心音発生間隔における最小間隔のN倍以上で、かつ、最大間隔のN倍以下Nは正の整数の値とするようにしたので、何回か監視する間に少なくとも1回は心音のあることを正常と判断することができ、確実に心音監視を行うことができる。なお、本願発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、もしくは実施の形態の任意の構成要素の省略が可能である。"