特開 2024-45942 リソース監視装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024045942

(43)【公開日】2024-04-03

(54)【発明の名称】リソース監視装置

(51)【国際特許分類】

   G06F 11/34 20060101AFI20240327BHJP

   G06F 11/30 20060101ALI20240327BHJP

【ＦＩ】

G06F11/34 152

G06F11/30 140A

【審査請求】未請求

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2022151050

(22)【出願日】2022-09-22

(71)【出願人】

【識別番号】000001122

【氏名又は名称】株式会社日立国際電気

(74)【代理人】

【識別番号】100097113

【弁理士】

【氏名又は名称】堀 城之

(74)【代理人】

【識別番号】100162363

【弁理士】

【氏名又は名称】前島 幸彦

(72)【発明者】

【氏名】田中 滉人

(72)【発明者】

【氏名】秋濃 智宣

(72)【発明者】

【氏名】阿部 健太郎

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042JJ29

5B042KK13

5B042MA08

5B042MA14

5B042MB03

5B042MC22

(57)【要約】

【課題】より適切に算定されたリソース使用量の代表値を用いてアプリケーションが動作する装置全体の監視を行う。
【解決手段】解析部は、例えばＣＰＵ使用率について、ある時点のＣＰＵ使用率のみに基づいて警告を発するのではなく、一定の時間間隔で一定の期間だけＣＰＵ使用率を取得し、このデータの中央値をこの期間内のＣＰＵ使用率の代表値として認識し、この代表値に基づいて上記と同様の警告を発する。図３（ａ）（ｂ）においては、このようにサンプリングされた測定点が丸印（Ｄ０～Ｄ９）で示されている。中央値を代表値として用いたことにより、一時的に他の時点とは大きく乖離した値となった図３（ａ）におけるＤ９、図３（ｂ）におけるＤ５は中央値の値には影響せず、図３（ａ）の場合にはこの中央値は９％程度となり警告は発せられず、図３（ｂ）の場合にはこの中央値は９１％程度となり警告が発せられる。このため、適正に警告が発せられる。
【選択図】図３

【特許請求の範囲】

【請求項1】

アプリケーションを実行させる際において用いられるリソースの使用状況を監視するリソース監視装置であって、
前記リソースの最大使用限界に対する現在の使用量であるリソース使用量を、予め定められた時間間隔で繰り返し取得するデータ取得部と、
前記リソース使用量が複数回取得される期間として予め測定期間が定められ、一つ以上の前記測定期間の間において得られた複数の前記リソース使用量の中央値を算出し、当該中央値が、予め定められた警告閾値以上となった場合に、警告を発する解析部と、
を具備することを特徴とするリソース監視装置。

【請求項2】

前記時間間隔、前記測定期間、前記中央値の算出に用いられる前記測定期間の数、及び前記警告閾値の値は、前記リソースの種類、又は前記アプリケーションに応じて定められたことを特徴とする請求項１に記載のリソース監視装置。

【請求項3】

前記解析部は、前記中央値の算出に用いる複数の前記リソース使用量のうち、他の全ての前記リソース使用量との間の差分が、予め定められた差分閾値以上となった一つの前記リソース使用量があった場合に、当該リソース使用量を、前記中央値の算出の際に除外することを特徴とする請求項１又は２に記載のリソース監視装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動無線通信システム等において用いられるリソースにおける異常の有無を監視するリソース監視装置に関する。

【背景技術】

【0002】

例えば移動無線通信システムにおけるアプリケーションの実行時には、多くのリソース（ＣＰＵ、メモリ、ネットワーク等）が使用される。多くのリソースが同時に使用される場合、このうち一つにおいて異常がある場合でも、アプリケーションの実行が中断する場合もあるため、リソースの状況をリアルタイムで認識し、異常が認められた場合には、その対応策を実行することが有効である。

【0003】

特許文献１には、無線基地局において、使用されている複数のリソースのうち空きリソースを認識し、この空きリソースを用いて他のリソースに対して確認用疑似信号を送信し、他のリソースからのこの信号に対する折り返し信号を受信することによって、他のリソースの状態を確認する技術が記載されている。これによって、異常が発生したリソースを認識することができると共に、対応策を無線基地局側で実行することができる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００６－２０１４３号公報

【発明の開示】

【発明が解決しようとする課題】

【0005】

特許文献１においては、リソースにおける動作の異常の有無のみが判定された。これに対して、例えばリソースにおける単純な動作の異常の有無ではなく、リソースの使用状況（例えばＣＰＵ、メモリ、ネットワークの使用量）を認識することも有効である。この場合においては、例えばこの使用量（リソース使用量）として、その最大使用限界に対する現在の使用量の割合を表したリソース使用量が１００％となった場合には、もはやこのリソースを使用することが不可能である。このため、このリソース使用量が例えば９０％以上となった場合には、このリソースの使用がその後に困難となる可能性が高く、上記のようにリソースに異常が発生する可能性が高いと認識することができる。このため、リソース使用量を監視することは、アプリケーションを安定して実行させる上で有効である。

【0006】

しかしながら、使用状況によっては短時間の間にこのリソース使用量は大きく変動することがあり、この場合、このリソース使用量の値はサンプリングのタイミングによって大きく影響を受ける。このため、例えばリソースには実際はまだ余裕があるのに警告が発せられる、あるいは逆に実際には余裕がないのに警告が発せられない場合があった。

【0007】

このため、より適切に算定されたリソース使用量の代表値を用いてシステム全体の監視を行うことが望まれた。

【0008】

本発明は、このような状況に鑑みなされたもので、上記課題を解決することを目的とする。

【課題を解決するための手段】

【0009】

本発明のリソース監視装置は、アプリケーションを実行させる際において用いられるリソースの使用状況を監視するリソース監視装置であって、前記リソースの最大使用限界に対する現在の使用量であるリソース使用量を、予め定められた時間間隔で繰り返し取得するデータ取得部と、前記リソース使用量が複数回取得される期間として予め測定期間が定められ、一つ以上の前記測定期間の間において得られた複数の前記リソース使用量の中央値を算出し、当該中央値が、予め定められた警告閾値以上となった場合に、警告を発する解析部と、を具備する。
前記時間間隔、前記測定期間、前記中央値の算出に用いられる前記測定期間の数、及び前記警告閾値の値は、前記リソースの種類、又は前記アプリケーションに応じて定められていてもよい。
前記解析部は、前記中央値の算出に用いる複数の前記リソース使用量のうち、他の全ての前記リソース使用量との間の差分が、予め定められた差分閾値以上となった一つの前記リソース使用量があった場合に、当該リソース使用量を、前記中央値の算出の際に除外してもよい。

【発明の効果】

【0010】

本発明によると、より適切に算定されたリソース使用量の代表値を用いて機器全体の監視を行うことができる。

【図面の簡単な説明】

【0011】

【図1】実施の形態に係るリソース監視装置の構成を示す図である。

【図2】実施の形態に係るリソース監視装置における、リソース使用量の時間経過の例である。

【図3】実施の形態に係るリソース監視装置における、リソース使用量の時間経過の、サンプリングされた測定点が丸印（Ｄ０～Ｄ９）で示されている例である。

【図4】実施の形態に係るリソース監視装置における、動作を示すフローチャートである。

【図5】実施の形態に係るリソース監視装置において、周期的にリソース使用量を取得する場合において得られるデータの例である。

【図6】実施の形態に係るリソース監視装置が用いられる無線通信システムの構成の例である。

【図7】実施の形態に係るリソース監視装置における、警告の表示の例である。

【0012】

次に、本発明を実施するための形態となるリソース監視装置について説明する。このリソース監視装置は、アプリケーションの実行に際して使用されるリソース（ＣＰＵ、メモリ、ネットワーク等）のある時点での使用量をモニターし、その結果に応じてユーザに警告を発する。ここで、ある時点におけるリソース使用量の厳格な定義はリソースの種類毎に異なるが、これは周知であるためにその説明は省略する。

【0013】

図１は、このリソース監視装置の構成を示す図であり、ここでは、各構成要素は単純化して示されている。ここでは、前記のように各リソースの個々の時点での使用量のデータを収集するデータ収集部１０が設けられる。収集されたデータは、メモリまたはハードディスク等で構成された記憶部３０に蓄積される。解析部４０は、このデータを解析することによって、各リソースの使用状況を認識し、使用量に余裕がないと判断された場合には、表示部５０において警告を発する。あるいは、その旨を、アプリケーションを実行する機器に伝える。この監視動作は一定の期間内において一定の時間間隔で行われ、この時間管理のために監視動作用タイマー６０も設けられる。

【0014】

ここで、リソースの使用量は使用限界（全容量）を１００％とした場合に対する現在の使用率（％）（例えばメモリにおいては「使用中容量」／「全容量」）で表され、例えば一定周期（５秒）で認識される。解析部４０は、単にこのような各時点における使用率に基づいて警告を発するのではなく、多数の時点における使用率に基づいた代表値によって警告を発する。

【0015】

以下に、この点について説明する。まず、従来のリソース監視装置におけるように、単純に各時点の使用率の値に基づいて警告を発する場合について説明する。図２（ａ）は、監視対象となるリソースであるＣＰＵの使用率の時間経過の第１の例である。ここで、この使用率が警告閾値である９０％を超えた場合に警告が発せられるものとする。

【0016】

ここで示されるように、ＣＰＵ使用率は短時間の間で激しく変動する。この際、例えば３０ｓｅｃ付近でこの判定を行った場合には、この時点でのＣＰＵ使用率は１０％程度であり余裕があるが、４５ｓｅｃ付近でこの判定を行った場合には、ＣＰＵ使用率は９０％を超えているため、警告が発せられる。しかしながら、図２（ａ）の場合には、大部分の領域でＣＰＵ使用率は警告閾値を大きく下回っている。更に、４５ｓｅｃ付近で警告が発せられても、実際にはその直後にＣＰＵ使用率は再び大きく低下するため、この場合には、このような大きなＣＰＵ使用率はアプリケーションの実行に際しては大きな影響を与えない、あるいはこのような警告は適切ではない。

【0017】

図２（ｂ）は、ＣＰＵ使用率の時間経過の第２の例である。この場合、２５ｓｅｃ付近でこの判定を行った場合にはＣＰＵ使用率は警告閾値を大きく下回っているために警告は発せられないが、この付近以外の大部分ではＣＰＵ使用率は警告閾値を上回っている。このため、サンプリングの時点が２５ｓｅｃ付近のみであった場合には、実際にはアプリケーションの実行に際して障害があるにも関わらず、警告が発せられない。

【0018】

このため、上記の解析部４０は、ある時点のＣＰＵ使用率のみに基づいて警告を発するのではなく、一定の時間間隔で一定の期間だけＣＰＵ使用率を取得し、このデータの中央値をこの期間内のＣＰＵ使用率の代表値として認識し、この代表値に基づいて上記と同様の警告を発する。ここで、中央値とは、例えばデータ数が奇数である場合には、データを大小の順に並べた場合において中央となったデータの値であり、データ数が偶数であった場合には、データを同様に並べた場合において、中央となった２つのデータの平均値である。

【0019】

図３（ａ）（ｂ）においては、図２（ａ）（ｂ）においてこのようにサンプリングされた測定点が丸印（Ｄ０～Ｄ９）で示されている。ここで、サンプリングは５ｓｅｃ間隔で０～４５ｓｅｃの間で１０回にわたり行われた。上記のように中央値を代表値として用いたことにより、一時的に他の時点とは大きく乖離した値となった図３（ａ）におけるＤ９、図３（ｂ）におけるＤ５は中央値の値には影響せず、図３（ａ）の場合にはこの中央値は９％程度となり警告は発せられず、図３（ｂ）の場合にはこの中央値は９１％程度となり警告が発せられる。このため、適正に警告が発せられる。

【0020】

上記の動作では、一時的に他の時点とは値が大きく乖離したためにデータとしては不適切である図３（ａ）におけるＤ９、図３（ｂ）におけるＤ５が、中央値を採用することによって代表値の算出の際には実質的に除外された。しかしながら、例えばサンプリング数がより少ない場合等には、このように明らかに不適切なデータが中央値に影響する場合もある。この場合には、このように不適切なデータを除外するために、他の手法を採用することもできる。例えば、Ｄ４のみの値がＤ０～Ｄ３、Ｄ５～Ｄ９のいずれとも大きく異なっていた場合に、この差分がある閾値（差分閾値）を上回っていた場合には、Ｄ４を上記の中央値の算出から除外することができる。

【0021】

図４は、上記のような解析部４０の動作を示すフローチャートである。ここでは、まず、このようなリソース監視動作を開始するにあたり、リソース監視用パラメータを記憶部３０から読み出す（Ｓ１）。このパラメータとしては、具体的には、サンプリング間隔（図３においては５ｓｅｃ）、１回の測定期間における最大サンプリング回数Ｎ０（図３においては１０回）、警告閾値、差分閾値、中央値算出のために必要となるデータ数、等があり、予め記憶部３０に記憶されている。中央値を算出するための一連のデータの取得期間（測定期間）は、図３においては、Ｄ０～Ｄ９にかけての１０回の測定に必要な４５（５×９）ｓｅｃとなる。これらのパラメータは、監視の対象となるリソース毎に設定され、各リソースにおける図２に示されたような特性に応じ、適性に警告が発せられるように設定される。

【0022】

これらのパラメータの設定が一つでも不適切である場合には、アプリケーションを適性に動作させることができないおそれがあり、かつ人為的なミスやハッキング等によってこのように不適切な値となる場合もある。このため、解析部４０は、このパラメータが予め定められた初期値から一定の値以上相違しているか否かを判定し（Ｓ２）、相違していた場合（Ｓ２：Ｙｅｓ）には、このパラメータが不適切であると判定し、以降ではパラメータをこの初期値に変更する（Ｓ３）。

【0023】

これによって、実際の監視動作が開始される。この際、解析部４０は、監視動作用タイマー６０をリセットしてスタートさせる（Ｓ４）。次に、中央値を求める対象となる一連のデータ（リソース使用量）を取得するための測定回数のカウンタとなるＮをリセットし（Ｓ５）、解析部４０は、データ収集部１０が収集した対象となるリソースのこの時点でのリソース使用量（図３におけるＤ０～Ｄ９の各値）を入手する（Ｓ６）。このデータが正常に入手できた場合（Ｓ７：Ｙｅｓ）には、Ｎはインクリメントされ（Ｓ８）、正常に入手できなかった場合には、Ｎはインクリメントされない。入手できたリソース使用量の値は記憶部３０に記憶される。

【0024】

次に、解析部４０は、現在の時点が監視動作用タイマー６０のスタート時（Ｓ４）から測定期間内であり（Ｓ９：Ｙｅｓ）、かつＮ＜Ｎ０（最大サンプリング回数）である場合（Ｓ１０：Ｎｏ）には、再びリソース使用量の入手（Ｓ６）以降の工程が行われる。前のデータ取得（Ｓ６）から次のデータ取得（Ｓ６）の時間間隔（図３の場合には５ｓｅｃ）は、前記の通り、リソース監視用パラメータとして設定されている。

【0025】

現在の時点が監視動作用タイマー６０のスタート時（Ｓ４）から測定期間外である（Ｓ９：Ｎｏ）、又はＮ≧Ｎ０（最大サンプリング回数）である場合（Ｓ１０：Ｙｅｓ）には、中央値を定めるための一連のデータ取得が終了したと認識される。このため、解析部４０は、この一連のデータの中に、除外すべきデータがあるか否かを判定する（Ｓ１１）。前記の通り、この判定は、ある一つのデータに着目し、他のデータの中でこのデータとの間の差分の絶対値が差分閾値以上となったものがあるか否かによって行われる。差分閾値以上となったものがあった場合には、この一つのデータは、除外すべきであると判定される。このように、除外されるべきデータが存在した場合（Ｓ１１：Ｙｅｓ）、解析部４０は、このデータを中央値を算出する際に除外し（Ｓ１２）、存在しなかった場合（Ｓ１１：Ｎｏ）には、取得された一連のデータ全てをそのまま用いる。ただし、このような差分閾値を用いたデータの除外（Ｓ１１、Ｓ１２）は、必ずしも行う必要はなく、これを行うか否かの設定を、リソース監視用パラメータに含ませることができる。

【0026】

解析部４０は、このように取得あるいは選別された一連のデータにより中央値の算出が可能か（一連のデータが中央値を算出する対象として適正か否か）を判定する（Ｓ１３）。ここで、例えば一連のデータ取得の際に、データが正常に入手できなかった（Ｓ７：Ｎｏ）回数が多く、充分な数のデータが測定期間内（Ｓ９）に得られなかった場合には、これによっては中央値の算出は可能でない（Ｓ１３：Ｎｏ）と判定される。このように中央値の算出のために必要なデータ数はリソース監視用パラメータ（Ｓ１）で設定され、例えばこの数を５とすると、このデータの数が４つ以下の場合には、この算出が可能でない（Ｓ１３：Ｎｏ）と判定される。この数は、例えばＮ０を基準として定めることもでき、例えばＮ０／２とすることができる。また、中央値算出が可能でない状態が何回続いたら、算出不可との警告（Ｓ１７）を表示するかの設定を、リソース監視用パラメータ（Ｓ１）に含ませることができる。

【0027】

中央値の算出が可能であった場合（Ｓ１３：Ｙｅｓ）には、解析部４０は、一連のデータから前記のように中央値を算出する（Ｓ１４）。この具体的な手法については後述する。その後、この中央値と警告閾値を比較し、中央値が警告閾値以上となった場合（Ｓ１５：Ｙｅｓ）には、解析部４０は、表示部５０等において警告を発する、あるいは更にこれに応じた他の動作を行わせる（Ｓ１６）。これらの動作についても後述する。一方、解析部４０は、中央値の算出が可能でなかった場合（Ｓ１３：Ｎｏ）には、リソース使用量が高い旨とは異なる、リソース使用量の適正な算出ができなかった旨の警告を表示部５０等で表示させる（Ｓ１７）。

【0028】

以上の動作によって、一定期間（測定期間）内で得られた一連のデータを用いて警告を発する動作は終了するが、その後においてもこの監視動作を継続する場合（Ｓ１８：Ｙｅｓ）には、記憶部３０に記憶された一連の古いデータを削除し（Ｓ１９）、Ｎをリセットした上で（Ｓ５）、データ使用量の取得（Ｓ６）以降の工程が新たに行われる。古いデータの削除（Ｓ１９）については後述する。監視動作を継続しない場合（Ｓ１８：Ｎｏ）には、監視動作用タイマーをリセットし（Ｓ２０）、動作は終了する。

【0029】

なお、この動作は、監視対象となるリソース（ＣＰＵ、メモリ等）毎に行われる。この際、リソース監視用パラメータはリソース（あるいはその種類）毎、あるいは実行中のアプリケーションに応じて設定される。

【0030】

上記の中央値の算出（Ｓ１４）について、具体的に説明する。図５は、上記の動作によって実測されたデータ（リソース使用量：ＣＰＵ使用率）の例である。ここでは、Ｎ０＝１０とし、このような前記の一連の１０個のデータを取得するサイクルが３つ設けられた（監視動作の継続（Ｓ１８：Ｙｅｓ）が２回行われた）後で得られた全てのデータが記載され、各サイクルは、「最新のサイクル」、「１つ前のサイクル」、「２つ前のサイクル」と記載されている。ここで、「１つ前のサイクル」においては、データ数が４つしか得られていないために、このサイクルのみから中央値の算出はできないものと認識される（Ｓ１３：Ｎｏ）。一方、「２つ前のサイクル」、「最新のサイクル」におけるデータ数は１０（全て）であるために、中央値は算出可とされ（Ｓ１３：Ｙｅｓ）、中央値はそれぞれ７４．５％（Ｎ＝４、９の平均）、４７％（Ｎ＝３、６の平均）となる。

【0031】

図２に示されたようなリソース使用量の時間経過の傾向の概要が予め判明している場合には、図５において中央値を算出するために用いるデータの範囲を適宜設定することができる。例えば、この範囲を１サイクルよりも長く設定し、「最新のサイクル」と「１つ前のサイクル」の２つを用いてもよく、この場合には中央値は４５％となる。前記のようにサイクル毎に判定を行う場合には「１つ前のサイクル」のデータは反映されなかったのに対し、この場合には「１つ前のサイクル」のデータも反映される。同様に、「２つ前のサイクル」も含めた３つのサイクルのデータを用いることも可能であり、この場合には中央値は５５％となる。

【0032】

このような、使用するデータの範囲（サイクル）は、リソース監視用パラメータ（Ｓ１）として、リソース毎、あるいはアプリケーション毎に設定することができる。この場合、使用するサイクル数に応じて、必要となるサイクルのデータは記憶部３０で記憶していることが必要となるが、新しいデータが得られる度に古いデータは削除することが好ましい。このため、図４において、監視動作を継続する場合（Ｓ１８：Ｙｅｓ）には、記憶部３０に記憶された、不必要となる一連の古いデータは削除される（Ｓ１９）。

【0033】

次に、中央値が警告閾値以上となった場合（Ｓ１５：Ｙｅｓ）に行われる動作（Ｓ１６）について説明する。この場合には、対象となったリソースにおいて異常が発生したと認識される。このため、解析部４０は、アプリケーションを実行する機器に対して、アプリケーションの動作を記録するログファイル、及び障害情報を記録するログファイルに、異常（対象となったリソースの使用量が警告閾値を超過したこと）を記録した上で、アプリケーションのメモリ情報を保存させる。その後、この旨の警告を、表示部５０、及びアプリケーションを実行する機器の表示部で表示させる。

【0034】

この場合に対象となったリソースが特にメモリ（ＤＲＡＭ等）であり、ガベージコレクション（ＧＣ）機能が実装されている場合には、以下の動作を行わせる。ＧＣ機能とは、メモリにおいてアプリケーションソフトウェアが動的に確保したメモリ領域のうち、不要となった領域を自動的に開放する機能である。このため、メモリ使用量が１００％に近くなった場合には、ＧＣ機能によって使用量を低下させる（空き容量を増やす）ことができ、これによってその後にアプリケーションを正常に実行させることができる。この場合には、前記の警告閾値とは別に、ＧＣ機能を実行させるためのＧＣ実行閾値をこのメモリ使用量に対して設定することができる。このＧＣ実行閾値も、リソース監視用パラメータ（Ｓ１）に含ませることができる。

【0035】

この場合、メモリ使用量がこのＧＣ実行閾値以上となったら、解析部４０は、前記のアプリケーション、障害情報のログファイルに、この旨を記録し、更にＧＣ機能を実行させる。これによって、このメモリの使用量を低下させ、その後にアプリケーションを正常に実行させる、あるいは異常終了する前での期間を長くすることができる。

【0036】

次に、このリソース監視装置１が実装される無線通信システムの例について説明する。図６は、この無線通信システム１００の構成を簡略化して示す。この無線通信システム１００は、作業指示者Ｈ０と現場担当者（例えば工事担当者）Ｈ１との間で指示や情報のやりとりをするために用いられる。作業指示者Ｈ０、現場担当者Ｈ１はそれぞれ複数存在し、作業指示者Ｈ０は手元にあるコンピュータである通信卓１１０、あるいは電話機１２０を用いてこの作業を行い、現場担当者Ｈ１は、各自が携帯する携帯端末１３０を用いてこの作業を行う。この際の情報はサーバ１４０を介してやりとりされ、通信卓１１０とサーバ１４０はネットワークＮで、電話機１２０とサーバ１４０は電話回線Ｔで接続される。現場担当者Ｈ１（携帯端末１３０）の位置は様々であるため、サーバ１４０と携帯端末１３０との間の通信は、地上における複数の箇所に設置された基地局１５０を介して、無線通信回線Ｒを介して行われる。各基地局１５０とサーバ１４０はネットワークＮで接続される。

【0037】

この場合、通信卓１１０において、業務用のアプリケーションを実行させることによって、上記のような作業の指示や情報のやりとりが行われる。このアプリケーションの実行の際には、通信卓１１０で設けられたディスプレイである表示部１１１が用いられる。また、この作業においては、通信卓１１０におけるＣＰＵやメモリが用いられ、これらが前記の監視対象のリソースとなる。

【0038】

この場合には、例えば図１の解析部４０の動作は通信卓１１０において、上記のような解析部４０の動作を行う装置を動作させることによって実現でき、上記のリソース監視装置１は通信卓１１０を構成するコンピュータの構成要素で実現できる。この場合には、通信卓１１０にリソース監視装置１が実装される。この場合には、前記の表示部５０と通信卓１１０の表示部１１１は共通となる。

【0039】

この場合における、表示部１１１の画面表示の例を図７に示す。この場合においては、大部分を占める下側の主表示Ｄ０が、実際に作業で用いるアプリケーションの画面となる。その上側のポップアップ表示Ｄ１は、前記の警告（Ｓ１６）の動作の際においてのみ表示される。ここでは、異常が認められたリソースが特定され、例えばこれがメモリであった場合には前記のＧＣ処理が行われた旨が表示される。このような表示は、リソースの種類やアプリケーションに応じて適宜設定され、このような警告の表示のフォーマットも、前記のリソース監視用パラメータ中で設定が可能とされる。

【0040】

なお、図６の例では、上記のリソース監視装置が無線通信システム内の通信卓１１０に実装された。しかしながら、このように各種のリソースが多く使用されるアプリケーションが実行される装置上であれば、同様にこのリソース監視装置を実装して、リソースの監視を行うことができる。

【0041】

以上、本発明を実施形態をもとに説明した。この実施形態は例示であり、それらの各構成要素の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【符号の説明】

【0042】

１ リソース監視装置
１０ データ収集部
３０ 記憶部
４０ 解析部
５０、１１１ 表示部
６０ 監視動作用タイマー
１００ 無線通信システム
１１０ 通信卓
１２０ 電話機
１３０ 携帯端末
１４０ サーバ
１５０ 基地局
Ｄ０ 主表示
Ｄ１ ポップアップ表示
Ｈ０ 作業指示者
Ｈ１ 現場担当者
Ｎ ネットワーク
Ｔ 電話回線
Ｒ 無線通信回線

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】