(57)【要約】      （修正有）【課題】ワイヤレスデバイスにおいて、デッドロックの回避を図り、デッドロックの回避ができない場合には、発生したデッドロックを検出してシステムの復旧を行ってシステム全体のフリーズを回避する。【解決手段】ワイヤレスデバイスに診断エンジンを常駐して、常にプロセスの動作状態とシステムリソースの利用状態を観察し、プロセスが起動するときとシステムリソースを要求するときにデッドロックの回避を図り、プロセス間にデッドロックが起きたときに直ちに診断してデットロックの場所（プロセス）と原因を特定して、即時に直せるのであれば、対応処置を取り、システムを復旧する。ソフトウェア上のバグであれば、詳細な診断データを記録した診断報告書を診断サーバに送る。【選択図】  図１
2007048247.tif 000002
【特許請求の範囲】
【請求項１】
少なくともひとつのプロセッサとひとつのソフトウェア・アプリケーションをもち、中に搭載するプロセッサによって自動的にプロセス間に起きるデッドロックを回避し、発生したデッドロックを診断してフリーズになるシステムを復旧するワイヤレスデバイスと、ワイヤレスネットワークを通してワイヤレスデバイスと接続できる遠隔地に置かれる診断サーバから構成するシステムフリーズの診断・復旧システム。
【請求項２】
請求項１に記載するワイヤレスデバイス上で起きるプロセス間のデッドロックの回避メソッド。本メソッドは、プロセス間のデッドロックを回避するためにワイヤレスデバイス上でシステムのプロセスとリソースに関する情報を収集する。収集した情報の中には、プロセスの間において起きるデッドロックを回避するために利用できる情報として少なくともひとつを含む。
【請求項３】
請求項１に記載するワイヤレスデバイス上で起きるシステム全体に広がるシステムフリーズの診断メソッド。本メソッドは、ワイヤレスデバイス上でシステムに走るプロセスの動作状態とシステムリソースの利用状態を観察し、複数のプロセス間において起きたデッドロックの診断を行うために情報を収集する。収集した情報の中には、プロセス間のデッドロックを検出するために利用できる情報として少なくともひとつを含む。この情報に基づいて、ワイヤレスデバイス上で発生したシステムフリーズの場所（プロセス）を特定し、システムフリーズが発生した原因を診断する。
【請求項４】
請求項１に記載するワイヤレスデバイスのシステムフリーズの復旧メソッド。本復旧メソッドは、診断結果に基づいて発生したシステムフリーズに対応する処置をとり、システムを復旧する。
【請求項５】
請求項１に記載するワイヤレスデバイスのシステムフリーズの診断結果報告メソッド。本診断結果報告メソッドは、ＯＴＡ（Ｏｖｅｒ−ｔｈｅ−ａｉｒ：ワイヤレスネットワーク）を通して診断結果を診断サーバに報告してデータベースに登録する。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、ワイヤレスデバイスのシステムフリーズの診断と復旧方法、システムフリーズ診断機能を持つワイヤレスデバイスおよびワイヤレスデバイスのシステムフリーズ診断と復旧を実施するシステムに関する。
【背景技術】
【０００２】  近年、携帯電話の高機能化によって、数多くのアプリケーションが高負荷の状態で走り、システムリソースの競合が発生してシステムがフリーズするリスクが高くなり、フリーズしたシステムを復旧させるには強制的に再起動する方法しかなく、作成途中のデータがなくなってしまい、利用者の満足度が低下する傾向にある。デッドロックとは、マルチタスクの環境で走る二つ以上のプロセスがシステムリソース又は相互通信の競合によって永遠にブロックされてしまうことである。システムフリーズとは、プロセス間のデッドロックがシステム全体へ広がり、システムがフリーズとなる状態である。【０００３】  システムフリーズが発生した場合は、利用者が携帯電話事業者のカスタマサポートセンタに電話してサポートを受ける。しかし、担当者が電話に出てくるまで長く待たされることが多い。担当者が出てきても、問題が解決できない場合も大いにある。事業者は、必要な情報が不十分であるために、問題の原因を究明しないままで製造メーカにまわしてしまう場合が多い。【０００４】  製造メーカは多くの人員を投入し、時間をかけてシステムフリーズのバグを再現させ、バグの発生原因を調べる。時間を費やしてもバグが見つからない場合もある。バグが見つからなければ、バグを修正することができない。バグを速やかに修正できなければ、顧客（事業者と利用者）との関係が悪くなる恐れがある。【０００５】  一方、ソフトウェアのバグでなくても、携帯電話を使えなくなることもある。たとえば、利用者の操作順番によってシステムリソースの競合が起きてシステムがおかしくなり、動作しなくなる。また、利用者の勘違いで、フリーズの問題ではなくても利用者から事業者のカスタマサポートに連絡するケースも少なくない。さらに、利用者がサポートへ連絡した際に新しい携帯電話機交換を要求するケースが多くある。修理受付窓口または小売店では、システムフリーズの有力な検査方法が無いことにより、多くの故障等の問題が無い携帯電話機を回収して新しい携帯電話に交換してしまう。この場合は、膨大な交換費用をメーカが負担することになる。【０００６】  携帯電話機が故障してユーザが携帯電話機を修理受付窓口や小売店に持ち込んだときに、持ち込まれた携帯電話機の状態を窓口担当者が即座に的確に判断することができ、修理の迅速化を図ることができる携帯電話機の修理サービス支援方法として、特許文献１に記載された方法がある。その方法では、保守情報を保存する保守情報記憶領域が記憶部に確保され、保守情報を保守情報記憶領域に書き込むとともに保守情報記憶領域から保守情報を読み出して表示部に表示させる。
【特許文献１】    特開２００４−１９４２４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】  しかし、特許文献１に記載された方法では、保守情報しか記録していないので、一定のハードウェアに関する故障や不具合しか判定することができない。上述のように、携帯電話機は様々な機能を実現できるようになっているので、システムフリーズの問題がソフトウェアが原因となって発生するために、ハードウェアに関する故障や不具合しか判定できないのでは、ユーザに対するカスタマサポート・サービスとして不十分である。また、特許文献１に記載された方法では、修理受付窓口への持込みが必要とされている。しかし、そのようなやり方では、数百万台の携帯電話で一斉に発生したシステムフリーズの問題に対応することが不可能である。【０００８】  そこで、本発明は、特別な機能に限定することなく、ワイヤレスデバイスにおいてあらゆるアプリケーションがあらゆるタイミングで起動することが原因でシステムフリーズが発生した場合に、修理受付窓口へ持ち込む必要もなく、リアルタイムで診断してシステムを復旧することができる方法、この方法を実現したソフトウェアおよびこのソフトウェアを実装したワイヤレスデバイスを提供することを目的とする。
【課題を解決するための手段】
【０００９】  本発明によるワイヤレスデバイスは、システムフリーズの診断エンジンを備えた携帯電話機であって、診断エンジンがシステムの健康を観察し、システムフリーズを回避する手段と、システムフリーズを認識する手段と、フリーズが認識されたときに必要な情報を収集し、診断を行ってシステムを復旧する診断・復旧手段とを有することを特徴とする。【００１０】  システム健康の観察手段は、診断エンジンがシステムに常駐して、システムリソースの利用状況を監視し、アプリケーションが起動するときや起動したアプリケーションから再びシステムリソースを要求するときに、アプリケーションのリソース要求に対して利用可能なリソースを基に審査し、システムリソースの競合が発生しないのであれば、必要なリソースを割り付ける。【００１１】  システムリソースは、プロセッサ、Ｉ／Ｏチャンネル、メモリ、デバイス、データ（例えばファイル）、データベース、セマフォがある。これらのシステムリソースにアクセスするときに制限があり、例えばメモリの割付要求に対して、メモリが不足したときに、プロセスの間にシステムリソースの競合（デッドロック）が起きる。【００１２】  デッドロックは、一つのプロセスが一つのシステムリソースを持ったまま、次のシステムリソースを要求する際（Ｈｏｌｄ−ａｎｄ−ｗａｉｔ）に起きる。例えば、２００ＫＢのメモリは、二つのプロセスからそれぞれ７０ＫＢと８０ＫＢの割付要求があったときに、１５０ＫＢのメモリが割り当てられ、残りのメモリが５０ＫＢとなる。二つのプロセスが割り当てられたメモリを持ったまま、次にまたそれぞれ６０ＫＢと７０ＫＢの割付要求があった際に、要求されるメモリがないため割り当てられなく、二つのプロセスが互いにブロックされてしまう。高負荷のシステムには、メモリのリークなどによるプロセスのデッドロックがよく起き、悪循環が起き、すべてのプロセスが動かなくなり、システム全体がフリーズしてしまい、システムを再起動する以外に復旧方法がなくなってしまう。【００１３】  本発明は、まず、デッドロックの回避を図り、デッドロックの回避ができない場合には、部分的に発生したデッドロックを検出して、システムの復旧を行って最悪のシステム全体フリーズを回避する。【００１４】  システムフリーズの回避手段は、システムリソースとプロセスの動きを監視して、デッドロックになる可能性のあるリソース割付をしない。リソース割付の判断基準として、常に利用可能なシステムリソースを１０％以上確保するという手段をとる。例えば、３２ＭＢメモリのシステムにおいて、常に３ＭＢのフリーメモリを残す。また、ループになるシステムリソース割付が行わない。例えば、プロセスＡがリソースＡを利用しているときにプロセスＢが利用しているリソースＢの割付を要求する同時に、プロセスＢがリソースＡの割付を要求する。プロセスＡとプロセスＢが互いに持っているリソースＢとリソースＡの開放を待ち、デッドロックになってしまう。これをリソースのループ割付と言う。【００１５】  デッドロックの検出手段は、長くスリープしているプロセスを探し、そのプロセスの履歴を調べて、デッドロックになっているかを判断する。長いスリープ・プロセスの判断���準として、一定の時間内（例えば５分）に起きていない、若しくは起きてもすぐにスリープになるプロセスを判断する。デッドロックになったプロセスの判断基準として、長いスリープ・プロセスであり、スリープの間に活動（例えばリソースの割付、Ｉ／Ｏ入出力）の履歴がないプロセスを判断する。【００１６】  システムの復旧手段は、デッドロックにあったプロセスに対して、すべてのプロセス又は一部のプロセスを強制的に終了させ、これらのプロセスに占用されたすべてのシステムリソースを開放する。一部のプロセスを終了させる場合は、デッドロックを解除するまでプロセスを一つずつ終了する作業を繰り返す。終了させたプロセスは、デッドロックにならないように順番に再起動して実行する。【００１７】  デッドロックを診断した結果は、ＯＴＡ（Ｏｖｅｒ−ｔｈｅ−ａｉｒ）を通して診断サーバに報告する。報告内容は、デッドロック発生した場所、原因および関連診断データが含まれる。これらの情報は、携帯電話事業者がカスタマをサポートするときに利用でき、また携帯電話メーカがバグをフィックスするときに利用することができる。
【発明の効果】
【００１８】  以上のように、本発明によれば、ワイヤレスデバイスにおいてシステムフリーズの回避、診断と復旧方法およびデッドロック診断実施のためのシステムとして、デバイスに診断エンジンが常駐し、プロセスの間にシステムリソースの競合が起きてデッドロックになることを回避し、回避できない場合に一部のプロセスの間においてデッドロックが発生した後に直ちにデッドロックを検出して、デッドロックになったプロセスを終了させ、システム全体のフリーズを回避させるので、ほとんどの場合に事業者のカスタマサポートに連絡する必要がなく、修理受付窓口に持ち込まれる必要もない。たとえ、事業者のカスタマサポートに連絡されたときでも、サポートに必要な情報が既に診断サーバに報告されてあり、すぐにカスタマへ対応ができる。また、ソフトウェア上でバグが見つかった場合に、バグに関する詳細な診断情報が収集されており、メーカが即座に的確にバグを判断することができ、バグを直ちに直すことができる。従って、利用者は、本発明によるデッドロック診断機能をセルフケアとして利用でき、ワイヤレスデバイスに発生するほとんどの最も複雑なシステムフリーズ又はリセットの問題が自動的に回避される。回避できなかった場合に、発生したデッドロックが自動的に診断されてシステムが自動的に復旧される。また、事業者のカスタマサポート担当者は、カスタマに対して的確に、かつ、迅速に問題を特定できるとともに、カスタマ対応の迅速化を図ることができ、顧客サービスの向上を図ることができる。さらに、メーカは、診断報告書に含まれる詳細な診断データを用いて、ソフトウェア上のデッドロックに関わるバグが発生した場所と原因がわかり、直ちにそのバグを修正することができる。事業者とメーカにとって、カスタマとプロダクトのサポートコストを著しく削減することができる。
【発明を実施するための最良の形態】
【００１９】  以下、本発明の実施の形態を図面を参照して説明する。図１は、本発明によるワイヤレスデバイスのデッドロック診断と復旧方法を実現することができるシステムの構成を示すブロック図である。【００２０】  図１に示す診断システムにおいて、ワイヤレスデバイス０１にデッドロック診断・復旧機能を実装して、システムリソースとプロセスの状態を観察し、プロセス間のデッドロックの回避を図り、デッドロックになったときに診断して、必要な処置を行い、システムを正常に復旧する。診断する際に、診断サーバ０２に対して、診断データベース０３からワイヤレスネットワーク０４経由で必要な診断情報を取り寄せることもできる。診断結果は、ワイヤレスネットワーク０４を通して、診断サーバ０２に報告し、診断レポートとして診断データベース０３に登録する。【００２１】  事業者のカスタマサポートから、この診断レポートを見ることができる。事業者のカスタマサポートは、この診断レポートをチェックして、ワイヤレスデバイス側で解決しなかったケースに対して、診断レポートに記載する情報に基づいて、解決方法を見つける。ソフトウェア上のバグであれば、メーカに対してバグ報告を行い、バグ修正を依頼する。メーカが、バグ修正依頼を受けた後に、ネットワーク経由で診断データベースから詳細な診断情報データを取り寄せて、バグの原因を調べ、バグの場所を特定し、ソフトウェア上のバグを修正する。【００２２】  図２は、システムフリーズの診断・復旧手順を示す説明図である。診断エンジンはシステムが正常時にプロセスとシステムリソースの状態の観察１０を行い、デッドロックを起こす可能性のあるプロセス間のシステムリソース割付をしないようにしてデッドロックの回避１１を図る。発生したデッドロックに対して、観察１０によって収集されたプロセスとシステムリソースの情報を用いて診断１２を行い、デッドロックを検出して、デッドロックになったプロセスをすべて又は一つずつ終了させてシステムリソースを開放し、システムの復旧１３を行う。部分的にプロセスを終了させる場合は、プロセスの終了手順が基準として利用者データ（例えば入力したメール）に関わりのないプロセスから終了させて、利用者の作成中データ（例えば送信メールを作成する途中）を優先的に保護する。【００２３】  図３は、上記の診断・復旧機能を実装するワイヤレスデバイスを示すブロック図である。図３に示している例では、本発明の診断・復旧を機能するワイヤレスデバイスに、診断エンジン２０、マルチタスクの環境において走るプロセス群２１、診断情報（システムリソース）２２と通信部２３を実装する。診断エンジン２０は、ワイヤレスデバイス上のシステムに常駐し、発生する可能性のあるデッドロックの回避、発生したデッドロックの診断とシステムフリーズの復旧を行う。プロセス群２１は、ワイヤレスデバイス上で高負荷の環境において起動しているマルチプロセスであり、診断エンジン２０の診断対象である。診断情報（システムリソース）２２は、各プロセスからアクセスするシステムリソースであり、プロセス間において起きうるデッドロックのソースとなる。通信部２３は、システムフリーズ診断の結果を診断サーバに報告するときに��断サーバとの通信に通信プロトコル（例えばＯＭＡ−ＤＭ：Ｏｐｅｎ  ｍｏｂｉｌｅ  ａｐｐｌｉａｎｃｅ−ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）を提供して診断データを伝送する手段である。
【実施例】
【００２４】  図４は、メモリの競合によって発生するデッドロックの一例を示す説明図である。図２に示す例では、利用可能なメモリが１００ＫＢになったときに、システムがプロセスＡ３０とプロセスＢ３１からそれぞれ５０ＫＢと３０ＫＢのメモリ要求に対してメモリの割付を許可する。次に、プロセスＡ３０とプロセスＢ３１が割り付けたメモリを握ったまま、さらにそれぞれ３０ＫＢと３０ＫＢのメモリ要求に対して、割り付けられるメモリがないので、プロセスＡとプロセスＢが互いに待つことになり、強制的に必要なメモリを開放しない限り、デッドロックとなる。【００２５】  デッドロックが上記のように限られたシステムリソースを共用するときに起きるだけでなく、プロセス間のメッセージ通信にも起きる。図５は、プロセス間においてメッセージの通信競合によって発生するデッドロックの一例を示す説明図である。プロセスＣ３２がプロセスＤ３３と同時に相手からのメッセージを待つことになると、メッセージの送信ができなくなり、プロセスＣとプロセスＤの間においてメッセージ受信がブロックされ、双方がデッドロックになってしまう。【００２６】  システムリソースの競合によるデッドロックは、リソース割付の基準を設け、デッドロックの発生を回避することができる。プロセス間のメッセージ通信競合によるデッドロックは、簡単に回避することができないが、診断してシステム設計上の問題（デッドロックになるパス）を究明することができる。【００２７】  図６は、ワイヤレスデバイス上にあるシステムリソースの一例を示す説明図である。デッドロック診断に必要となる情報は、メモリ４０、データ４１とセマファ４２がある。システムリソース４３は、これらの情報データから構成される。メモリ４０は、プロセスが共用するリソースであり、使用すると利用可能な領域が少なくなるので、高負荷の環境中に競合が起きやすいリソースである。データ４１は、ファイルやデータベースであり、同じデータに対して複数のプロセスからアクセスされるときに、競合が起きる可能性があるリソースである。セマファ４２は、共用されるデータに対して複数のプロセスからのアクセスを制御するためのシグナルであり、複数のプロセスがこのシグナルを永遠に待ち続けるとデッドロックになる。【００２８】  図７は、これまでの実施例の中に記載してあったデッドロックの回避実施例を示す説明図である。デッドロックを回避するために、システムのプロセス管理モジュールとリソース管理モジュールの中に新たにＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  ｉｎｔｅｒｆａｃｅ）を組み込み、プロセスの起動要求とプロセスからのリソース要求があるときに、要求に答える審査を行う。図７に示す例では、プロセス管理モジュールがプロセスの起動要求を受けたときに、直ちにはそのプロセス２１を起動しない。プロセス管理モジュール５０に組み込まれているＡＰＩ５１が診断エンジン２０にシステムリソースをチェックするリクエストを送る。診断エンジン２０がシステムリソースを調べ、利用可能なシステムリソース情報をＡＰＩ５１に送り返す。ＡＰＩ５１がこのシステムリソース情報を基にプロセス２１の必要なシステムリソースを割り付けることによってデッドロックにならないのであれば、プロセス２１の起動を許可する。許可しない場合は、プロセス２１の起動をデッドロックになる可能性がなくなるまで保留する。プロセス起動許可の判断基準として、前に述べたように、利用可能なシステムリソースが１０％以下になるプロセスの起動を許可しない。【００２９】  また、リソース管理モジュールが実行中のプロセスからのリソース割付要求に対して直ちにその要求を許可するのでなく、そのリソースを割り付けることによってデッドロックになるかどうかの審査を行う。図７に示す例では、リソース管理５２がプロセス２１からリソース割付の要求があったときに、リソース管理モジュールに組み込まれているＡＰＩ５３を呼び出して、診断エンジン２０にいままでプロセス２１のリソース要求履歴を調べるリクエストを送る。診断エンジン２０がプロセス２１のリソース割付履歴を調べ、もしこのプロセス２１が連続して増大する要求であれば、デッドロックを起こす恐れがあるので、引き続きのリソース割付を許可しない。判断基準として、前に述べたように、利用可能なシステムリソースが１０％以下になるリソース割付を許可しない。履歴調査の結果が診断エンジン２０からＡＰＩ５３に返される。リソース管理モジュールがこの結果に基づいて、プロセス２１に新たにリソースの割付を許可するかどうかを判断する。許可しない場合は、デッドロックの可能性がなくなるまで、プロセス２１へのリソース割付を保留する。【００３０】  図８は、システムフリーズの診断・復旧実施の一例を示す説明図である。プロセス間のデッドロックを回避できなかった場合は、システムフリーズになり、システムを再起動しなければならない状況になる。本発明は、システム全体がフリーズになる前に、部分的にデットロックになったプロセスを終了させ、システムリソースを開放し、システムをフリーズから復旧することを図る。図８で示す例では、プロセスＥ６０とプロセスＦ６１の間において例えば図４に示したようなデッドロック（Ｈｏｌｄ−ａｎｄ−ｗａｉｔ）が起きた場合に、診断エンジン２０がシステムリソース２２とスリープになっているプロセスに対して診断を行い、デッドロックが起きたプロセスＥ７０とプロセスＦ７１を検出する。デッドロックを検出する基準として、前に述べたように、長い間にスリープし、活動のないプロセスがデッドロックにある。診断エンジン２０がデッドロックになったプロセスＥ７０とプロセスＦ７１に対して一つずつ又はすべてのプロセスを終了させてシステムリソースを開放する処置を取って、システム全体へ広げるデットロックを抑え、システムフリーズを回避する。【００３１】  図９は、ネットワークを通した診断結果報告実施の一例を示す説明図である。図９に示す例では、診断エンジン２０が診断結果をリクエスト７０に載せてＯＴＡ（ワイヤレスネットワーク）を通して診断サーバ０２に送り、診断サーバがその診断レポートを受信した後に診断レポートを処理し、データベースに登録して、診断エンジン２０にその処理結果をレスポンスとして診断エンジン２０に送る。
【図面の簡単な説明】
【００３２】
【図１】本発明によるワイヤレスデバイスのデッドロック診断と復旧方法を実現することができる診断システムの構成を示すブロック図である。
【図２】デッドロックの回避とシステムフリーズ診断・復旧を実施する手順の一例を示す説明図である。
【図３】ワイヤレスデバイスにデッドロック診断・復旧機能を実装する一例を示すブロック図である。
【図４】ワイヤレスデバイス上でメモリの競合によって発生するデッドロックの一例を示す説明図である。
【図５】ワイヤレスデバイス上でシグナルの競合によって発生するデッドロックの一例を示す説明図である。
【図６】ワイヤレスデバイスの記憶領域に保存される診断情報（システムリソース）の一例を示す説明図である。
【図７】デッドロックの回避実施の一例を示す説明図である。
【図８】デッドロックの診断・復旧実施の一例を示す説明図である。
【図９】診断結果の報告実施の一例を示す説明図である。
【符号の説明】
【００３３】０１  ワイヤレスデバイス（携帯電話、携帯端末）
０２  診断サーバ
０３  診断データベース
０４  ワイヤレスネットワーク
２０  診断エンジン
２１  プロセス群
２２  診断情報（システムリソース）
２３  通信部
３０  プロセスＡ
３１  プロセスＢ
３２  プロセスＣ
３３  プロセスＤ
４０  システムリソースであるメモリ
４１  システムリソースであるデータ
４２  システムリソースであるセマファ
４３  診断用データ保存部
５０  プロセス管理部
５１  プロセスからのシステムリソース要求をチェックするＡＰＩ
５２  システムリソース管理部
５３  プロセスに割り付けたシステムリソースの履歴をチェックするＡＰＩ
６０  プロセスＥ
６１  プロセスＦ
７０  リクエスト・メッセージ
７１  レスポンス・メッセージ
【図１】
2007048247.tif 000003
【図２】
2007048247.tif 000004
【図３】
2007048247.tif 000005
【図４】
2007048247.tif 000006
【図５】
2007048247.tif 000007
【図６】
2007048247.tif 000008
【図７】
2007048247.tif 000009
【図８】
2007048247.tif 000010
【図９】
2007048247.tif 000011