(57)【特許請求の範囲】
【請求項１】
ユーザ操作によって処理を行う情報機器管理方法であって、
機器管理サーバでは無応答状態に至った情報機器上のイベントシーケンスをキーとし、そのイベントシーケンスによりもたらされた状態の結果履歴を値とするレコードを蓄積する履歴データベースを構築し、
無応答状態発生時にユーザ要求によって前記機器管理サーバにおいて無応答状態をもたらしたイベントシーケンスをキーとして前記履歴データベースを検索し、同様のイベントシーケンスによって至った前記結果履歴の統計情報を元に当該無応答状態の終わる時間またはフリーズの可能性を予測し、ユーザに提示する情報機器管理方法。
【請求項２】
請求項１の情報機器管理方法であって、
前記ユーザ要求に際し、前記機器管理サーバにおける検索時に前記履歴データベースのレコード数が十分でなかった場合に、前記機器管理サーバの管理する情報機器に対し前記イベントシーケンス発生時にそれによって至った状態の情報収集依頼をブロードキャストし履歴データベースの情報を補充する情報機器管理方法。
【請求項３】
請求項１の情報機器管理方法であって、
前記機器管理サーバによって前記履歴データベースの検索結果から予測された結果を、無応答状態にある要求元の情報機器にのみ通知するのではなく、要求ユーザが参照可能な他の端末にも通達することで要求ユーザへの伝達を行う情報機器管理方法。
【請求項４】
請求項１の情報機器管理方法であって、
前記機器管理サーバにおいて前記結果履歴の統計情報を元に各結果履歴をもたらした情報機器のハードウェアスペックおよびCPU使用率・空きメモリ等の動的パラメータを加味し、結果予測を行う情報機器管理方法。
【請求項５】
請求項１から４のいずれかの情報機器管理方法であって、
前記履歴データベースに蓄えられた前記イベントシーケンス毎の前記結果履歴においてユーザによって強制終了された履歴のうち、正常に復帰した待ち状態の履歴の統計情報から予測できる範囲外の時間で発生した強制終了についてフリーズ状態の可能性があると判断し、開発元ならびに要求ユーザに通知する情報機器管理方法。
【請求項６】
請求項２から５のいずれかの情報機器管理方法であって、
前記機器管理サーバから管理対象の情報機器に情報収集依頼のブロードキャストを行う際に、その対象となるイベントシーケンスの結果履歴からフリーズ状態の可能性があると判断された場合に、より詳細な情報収集を行うために情報機器上のプロファイラを有効にし、フリーズ状態解決のための情報を収集する情報機器管理方法。
【請求項７】
請求項６の情報機器管理方法であって、
情報機器上のプロファイラを有効にする条件として、フリーズ状態を起こした結果履歴をもたらした情報機器のハードウェアスペックおよびCPU使用率・空きメモリ等の動的パラメータをもって、より近い条件の情報機器でのみプロファイラを有効にすることで、プロファイルの負荷を与える情報機器を限定する情報機器管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ操作によって処理を行う情報機器の管理に関する。
【背景技術】
【０００２】
情報機器は年々高度化をとげ、より高速な計算機環境が、家電や携帯デバイスを始め多くの機器に搭載されつつある。それに合わせソフトウェアの規模は増大の一途をたどり、複雑化に伴い出荷時点のソフトウェア実装の信頼性の完全な保証は難しくなってきている。
【０００３】
製品出荷後のソフトウェアアップデートの仕組みも多くの分野で標準的に取り入れられており、同時に製品出荷後に起きた不具合についてその原因を解析すべく、実機上で情報収集する手段も検討が進みPC等では搭載されつつある。特許文献１の例は、製品として出荷した後のソフトウェア障害の収集を行う事例であり、ソフトウェア処理が障害により動作を異常終了した場合の情報収集手段を課題としている。
【０００４】
【特許文献１】特開２００３−１７９５４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、ソフトウェアの異常状態としては、異常状態を検知し終了するような場合だけでなく、完全に無応答状態に陥ってしまうフリーズがあり、上記特許文献１の様な異常終了をハンドリングする手段ではこれを検知することが出来ない。
【０００６】
ユーザにとって無応答状態になったときに、アプリケーション/システムの正常な待ち時間であるのか、フリーズ状態に陥ったのかを区別することは非常に困難であり、特にユーザインタフェイスを持った情報機器では、ユーザストレスの一因になっている。
【０００７】
フリーズ状態であれば強制終了させることで中断させるしかないが、上述の通り区別が付かないことから、ユーザの気短な操作により、アプリケーション/システムとして正常な待ち時間であっても強制終了してしまう危険がある。その際データの喪失の危険があり、特に強制終了の手段として電源断やハードウェアリセットなどしか持たない機器構成では機器の破損の危険をも伴う。
【０００８】
ユーザによる強制終了を特許文献１の例における異常終了として捉えることも場合により可能だが、そうした場合にもユーザがフリーズと待ち時間とを区別せずに強制終了を行えば、収集できる情報も混然としてしまい、フリーズ状態の解析に利用しにくくなる。
【課題を解決するための手段】
【０００９】
そこで例えば、情報機器のユーザに対し通常無応答状態が待ち状態であるかフリーズ状態であるかの判断支援を要求する手段を設ける。情報機器ではその要求に際し、その状態に至るまでのイベントシーケンス情報を検索条件として機器管理サーバに問い合わせる。機器管理サーバによって管理される履歴データベースに同等のイベントシーケンスによって報告された、過去の無応答状態の結果履歴データを元に予想される待ち時間やフリーズの可能性を問い合わせのあったユーザに提供する。また、履歴データベース上に同様のイベントシーケンスでの記録がない場合や十分な蓄積がない場合には、機器管理サーバは管理するクライアント情報機器に対し、問い合わせのあったイベントシーケンスが起きた場合の無応答状態の監視および結果報告を要求する。これによって、無応答状態の起きやすいイベントシーケンスに対する結果履歴を収集し、今後同様の操作についてクライアントからの問い合わせにより正確な待ち情報を応答できるようにする。さらに、フリーズ状態を引き起こすイベントシーケンスを絞り込むことで、クライアントへの状態監視の際により詳細なプロファイル情報も合わせて取得し、不具合であるフリーズ状態の解決に役立てる。
【発明の効果】
【００１０】
上記手段によれば例えば、ユーザインタフェイスをもった情報機器において、待ち状態とフリーズ状態の判断を支援することで、ユーザストレスを緩和する。また、待ち状態でのユーザによる安易な強制終了を抑制することで、機器の破損やデータの喪失の危険を回避する。また、機器管理サーバによって管理対象の情報機器すべてで発生した機器待ち状態とフリーズ状態との判別を統計管理し、フリーズ状態についての収集情報の確度を向上させ、障害解析を促進する。
【発明を実施するための最良の形態】
【００１１】
ユーザインタフェイスを持った情報機器において、アプリケーション実行時の待ち時間と、異常時のフリーズ状態との区別がつかないことが、大きなユーザストレスとなる。また正常な待ち状態であっても、フリーズ状態と誤認しユーザが強制終了してしまう危険があった。ユーザに両者の判断を支援するための手段を提供することで、ユーザストレスの軽減ならびに、強制終了による機器破損やデータ喪失等の危険を回避する。機器管理サーバからの依頼で、フリーズ状態に至るイベントシーケンス発生時に管理対象となる情報機器でのプロファイル情報収集を強化させることで、フリーズ状態の原因解明に向け、より詳細な情報を集めることができる。
【００１２】
本発明の実施形態の例（実施例）を図面により詳細に説明する。
【００１３】
図１に本実施例を実現するシステムの構成例を示す。本実施例は機器管理サーバ101、機器管理サーバ101によって管理される情報機器110、120、130によって構成され、これらはネットワーク103を通じ接続される。なお実際は図面に示した3台に限らずより多くの管理対象情報機器によって構成される。なお、端末とサーバを含むシステムで説明するが、システムではなく端末単体やサーバ単体についての権利取得や権利行使を妨げるものではない。
【００１４】
管理サーバ101は接続された情報機器110、120、130を管理することを目的とし、履歴データベース102に接続される。情報機器110は、ユーザ操作によって情報処理を行う機器全般を想定し、図１に示されるようにCPU111、ネットワーク103に接続する通信部112、主記憶装置113、二次記憶装置114を備え、ユーザとのインタフェイスとして、出力を行うディスプレイ等の出力装置115、スイッチ/キーボート/マウス/タッチパネル等の入力装置116を有する。情報機器120、130、またその他の機器管理サーバ101の管理対象となる情報機器も情報機器110と同様の構成・機能を持つ。
【００１５】
図１のシステム構成における処理例を図２の処理フローを用いて説明する。図２のフローでは管理サーバ101上の処理をステップ20x、情報機器110上の処理をステップ22x、情報機器120、130他の管理対象情報機器上での処理をステップ24x、として表現する。各処理のフローは実線、各処理間の通信は破線によって示される。
【００１６】
前提として、情報機器110では、入力装置116による入力やアプリケーション/システムの状態遷移等のイベントシーケンスを常に一定数蓄積し、主記憶装置113または二次記憶装置114に保持している。保持されるイベントシーケンスのデータ形式を図３に例示する。この例に示されるようにイベントシーケンスとは、発生したアプリケーションAの起動、メニュBの選択、ボタンC押下といったイベントを時系列に並べたものであり、新たなイベントが発生する度に追加され、バッファ予定数をあふれたイベントから破棄していく。
【００１７】
情報機器110において、アプリケーションが動作しており、そのアプリケーションが、ユーザに対し無応答状態に陥った時点を本フローの開始とする。
【００１８】
(1)情報機器110において、ユーザは入力装置116によって、両状態の判別要求を発行する。この要求はCPU111/通信部112を経てネットワーク103を通じ管理サーバ101に送信される。この要求には合わせて、上記イベントシーケンスも管理サーバ101に向け送信される。(ステップ201)
この要求は入力装置116によってなされるが、マルチタスク環境で当該アプリケーションのみが無応答である場合は通常の入力イベントで実現できるが、OSを伴って無応答になった場合、NMI(Non-Maskable Interrupt)割り込みなどOSを介さない割り込みで本要求を実現することで、要求発行の確度を上げることができる。
【００１９】
(2)情報機器101では、送信後無応答状態に陥ったアプリケーションないしシステムの振る舞いを監視する。(ステップ202)
(3)機器管理サーバ101では、ステップ201のユーザによる要求をイベントシーケンスと合わせて受信する。ステップ201の要求に対し、履歴データベース102上の同様のイベントシーケンスによって起きた無応答状態の履歴を検索する。(ステップ221、222)
ステップ222における検索の手順を詳細化する。
【００２０】
履歴データベース102のレコード構成の例を図４に示す。履歴データベース102では、過去に起きた情報機器110、120、130等で起きたイベントシーケンス401、411と関連づける形で、同じイベントシーケンスから発生した無応答状態の結果と結果に至る時間を蓄積した結果履歴テーブル402、412を保持する。履歴データベース102ではイベントシーケンスと結果履歴テーブルのペアを図に示した2セットに限らず多数蓄積でき、後述するとおり本フローの過程によっても随時追加されていく。
【００２１】
ステップ201の要求に対する検索時には、要求とともに送信されるイベントシーケンスの要素を履歴データベース102上のレコードセットを順に比較し同一のイベントシーケンスを探し出す。
【００２２】
イベントシーケンスの比較に際しては完全一致ではなく、アプリケーション起動やルートメニュからの操作を一連のイベントの開始と見なし、その範囲での比較をしたり、キャンセル操作と直前のイベントを相殺した上で比較をするなどの検索手法により比較精度を向上させることができる。
より精度を上げるためにアプリケーションが明示的に自身がこれからする処理をアプリケーション情報とともに処理名や関数名といった形で直接的にイベントシーケンスに登録することもできる。
【００２３】
履歴検索の結果として、比較に成功したイベントシーケンスに関連づけられる結果履歴テーブルを元に待ち時間情報を返却する。図４で検索の結果イベントシーケンス401がヒットした場合、検索履歴テーブル402を用い、過去の履歴として10秒から45秒の間で検索対象となったイベントシーケンスによる処理が終了していることがわかる。
【００２４】
また待ち状態とフリーズ状態の区別という観点からは、履歴データベース102上の結果履歴テーブルにおいて、過去に正常に復帰した時間の範囲から、統計的に正常終了と見なせる時間内のユーザ強制終了は無視し、その範囲外で起きたユーザ強制終了のみをフリーズの可能性が高いと見なすことができる。
これらの情報を続くステップにおいてユーザに通知する。
【００２５】
(4)機器管理サーバ101では、検索したイベントシーケンスに対応する結果履歴が履歴データベース102に発見されたか場合その解析に基づく予測結果を、発見されない場合はその旨を、要求元である情報機器110に通知を行う。(ステップ223)
(5)情報機器101では、ステップ223の結果を受領し、ユーザに対し表示を行う。(ステップ203)
このとき、無応答状態の情報端末110では、この情報を出力装置115を通じて表示するのに遅延が生じたり、表示できない場合が考えられる。ステップ223の通知に際しては、通知元の情報機器110とは別のユーザ携帯端末などにもあわせて送信を行うことでステップ201の要求に対するより確実なユーザへの情報提供を行うことができる。
【００２６】
(6)機器管理サーバ101では、ステップ222の履歴検索として得られた図４の結果履歴テーブル402の履歴件数を確認し、統計データとして十分な数に至っていなければ、機器管理サーバ101の管理対象となる情報機器120、130等に対し検索のキーとなったイベントシーケンスによる処理の情報収集依頼を発行する。(ステップ224、225)
統計データとして十分な数の履歴があればなにもしない。十分な数であるかどうかは、機器管理サーバ101の設定値として与えられるしきい値によって判断する。ステップ225の情報収集依頼は機器管理サーバ101の管理対象のすべてのクライアント情報機器に要求し、分散して監視を行うことで、効率良く無応答状態に対する情報を収集することができる。
【００２７】
(7)ステップ225によって依頼を受けた情報機器120、130等も、情報機器110と同様に自身で起きたイベントシーケンスの蓄積を行っている。(ステップ241)
(8)情報機器120、130等は、新たなイベントを蓄積する際にステップ225で受領したイベントシーケンスと比較して、同等のイベントシーケンスが発生していないかを常にチェックする。(ステップ242、243)
(9)同等のイベントシーケンスが起きていると見なされた場合、情報機器120、130等でも情報機器110と同じく無応答状態になったものと見なし、アプリ処理の監視を開始する。(ステップ224)
(10)情報機器110および情報機器120、130等で、ステップ202、224でアプリ監視は同様に実施され、監視対象となる無応答状態がどのような結果で終わったのかを監視サーバに通知する。(ステップ204、245)
この結果情報は、対象となったイベントシーケンス情報とともにユーザ強制終了か、正常に復帰したのかのいずれかの結果と、その結果に至る経過時間によって構成され、情報機器自身の端末情報とともに報告される。各情報機器において監視要求のあったイベントシーケンスに対し、かならずしも無応答状態が発生するとは言えないが、その場合は待ち時間0の無応答状態であったものとして結果履歴に反映する。また情報機器における情報収集は一回の報告で終了せずに機器管理サーバ101に十分な情報が蓄積されるまで継続しても良い。
【００２８】
(11)機器管理サーバ101では、ステップ204、245の報告を受け、該当するイベントシーケンスに対応する結果検索テーブル402に、端末情報、時間、結果を追加する。
【００２９】
以上によって、ステップ201のユーザ要求に対し、無応答状態の判断支援情報を複数クライアント情報機器にまたがる統計情報によって、提示することが可能になり、ユーザストレスの軽減と、ストレスに伴う気短な強制終了を抑制することができる。
【００３０】
図２のフローのサイクルを繰り返すことで履歴データベース102には、多くのイベントシーケンスに対する無応答状態の履歴が蓄積される。その結果、ステップ222における検索の成功する確率が上がり、統計情報の充実により有意な情報が通知できるようになっていく。
【００３１】
多くの組込み機器では、同じ製品であればCPUや搭載メモリなどの機器構成は等しく、同じ処理にかかる時間も近くなることが想定される。機器管理サーバ101の管理対象がすべて同じ構成を持つ機器であるという前提が成り立てば、図２のステップ222の検索結果において、スペックの違いを考慮する必要はない。機器管理サーバの管理対象が、同じでない場合ステップ222の検索結果において、その違いを考慮することで、結果として得られる待ち時間/フリーズ状態の区別の精度を上げることができる。
【００３２】
図５に履歴データベース102に格納される結果履歴テーブルに端末のもつハードウェアのスペック情報を追加した例を示す。この例ではCPUのクロック性能501、メモリ搭載量502を合わせて結果履歴に残す。
【００３３】
図２のステップ201の要求に際して、情報機器101の持つスペック情報も同様に要求に合わせ、通知しステップ222の履歴検索に利用する。なお、各クライアントのスペック情報は管理サーバ101に事前に登録してあり、ステップ201の要求時には自身の登録IDを通知するといった仕組みも考えられる。この場合、履歴データベース上の結果履歴テーブルにも登録IDだけを残すことになる。
【００３４】
要求元である情報機器101のスペックによって、無応答状態の復帰予測時間を算出するのに、以下の様な補正が考えられる。
情報機器101のCPUクロックが図５の端末L、Nと同じ100MHzであった場合、時間予想にL,Nの結果を優先して利用することが考えられる。また、300MHzのMの結果を単純に数字上3分の1として換算することで、正常終了の事例として100MHzなら45秒から75秒で終わる事が予想できる。また、フリーズ状態がメモリ不足から起きることも考えられ、図５のようにメモリ搭載量と結果との間に相関が見られる場合には、情報機器101のメモリ搭載量が16MBよりも小さい場合に、フリーズ状態に陥っている危険が高いことをユーザや開発者に通知することができる。
【００３５】
こうしたハードウェアのスペック情報だけでなく、動的に変わる空きメモリ量やCPU使用率といった状態パラメータも同様に履歴データベース102上の結果履歴テーブルに蓄積し、より近い情報に重み付けを行って無応答状態の結果予想に交えていくことで、より正確な予想が得られる。
ステップ222の手順に詳細化したフリーズ状態の可能性の検出における、正常終了時間範囲の算出においても、上述と同様にハードウェアスペック/動的状態パラメータを加味し精度を向上させることができる。
【００３６】
機器管理サーバ101は、ステップ225によって管理対象である情報機器120、130等にイベントシーケンスに対する無応答状態の情報収集を依頼する。上記で図２のフローの説明では、情報機器120、130等ではこの情報として結果とその時間とした。情報機器120、130上に監視プロファイラを持たせることで、アプリケーション処理の監視開始と同時にこれを有効にし、より詳細なアプリの振る舞いを監視することができる。
【００３７】
一般に監視プロファイラは、通常処理に割り込んで、その振る舞いを監視するためパフォーマンスの面で、問題となることが多い。図２のフローのステップ242、243のように特定のイベントシーケンスが起きた時にのみ監視プロファイラを有効にすることで、通常処理に性能上の負荷をかけずに無応答状態の監視を行うことができる。
【００３８】
荷軽減の観点から、プロファイル有効化の条件をさらに絞り込むことができる。図６のフローを用い有効化の判断の例を示す。
【００３９】
(1)監視の目的をフリーズ状態の解決に限定することで、、監視プロファイルの開始条件とするイベントシーケンスを絞り込むことができる。ステップ222で述べた判断基準に則りフリーズ状態の可能性の低いイベントシーケンスでのプロファイルの有効化を抑制できる。(ステップ601)
(2)履歴データベース102での結果履歴上、フリーズ状態を起こした情報機器のハードウェアスペックと比較して、機器管理サーバ101によって管理される情報機器110、120、130等の内、類似するハードウェアスペックを持つ対象情報機器のみに対し、ステップ225の情報収集依頼に合わせてプロファイル有効化指示を行う。(ステップ602)
また、ハードウェアスペックのみを通知し、情報機器110、120、130等の各々で、自身のハードウェアスペックとの比較を行うことでプロファイル有効化の判断することもできる。
【００４０】
(3)同様にフリーズ状態が発生した時点での空きメモリ量やCPU使用率等の動的パラメータについてもステップ602同様にプロファイル有効化判断に利用できる。この場合、無応答状態が起きた時点での動的パラメータをステップ225情報収集依頼と合わせて送致する。各情報機器では、情報収集依頼のあったイベントシーケンスの発生判断ステップ242、243に合わせて、その時点での自身の動的パラメータが、送致されてきたものと比較し、類似すると判断された場合に限り、プロファイルの有効化を図る。
【００４１】
以上の手順によって、処理性能に影響を与えるプロファイルの有効化を、フリーズ状態の解析に必要な条件によって絞り込み、情報機器に対する監視プロファイルの負荷を抑制しつつ、必要な障害情報を収集することができる。
【産業上の利用可能性】
【００４２】
ユーザ操作を伴う情報機器における操作性の向上と、障害(フリーズ状態)解析に利用できる。
【図面の簡単な説明】
【００４３】
【図１】システムの構成例
【図２】システムにおける処理例
【図３】イベントを時系列に並べたイベントシーケンスのデータ構成例
【図４】履歴データベース102のデータ構成例
【図５】履歴データベース102に格納される結果履歴テーブルに端末のもつハードウェアのスペック情報を追加したデータ構成例
【図６】監視プロファイラを有効化するかの判断処理例
【符号の説明】
【００４４】
101  機器管理サーバ
102  履歴データベース
103  ネットワーク
110  情報機器
111  CPU
112  通信部
113  主記憶装置
114  二次記憶装置
115  出力装置
116  入力装置
120  情報機器
130  情報機器
【図１】
0005011174.tif 000002
【図２】
0005011174.tif 000003
【図３】
0005011174.tif 000004
【図４】
0005011174.tif 000005
【図５】
0005011174.tif 000006
【図６】
0005011174.tif 000007