(57)【要約】【課題】ログデータが多い場合であってもログデータが落ちることなく採取され、かつログデータ採取用のコンピュータが接続されていないデバッグ・テスト環境であってもログデータを採取する。【解決手段】モバイル端末１が有するテンポラリのデータフォルダにログを格納し、そのログデータがある一定のサイズに達した時点で電子メールの添付ファイルとして予め決まった電子メールアドレス３１に対して電子メールを自動的に送信し、実際にログデータを入手する際は、別のコンピュータ２から当該電子メールアドレスに送信されている電子メールを受信し、添付ファイルを取り出す。【選択図】  図１
2004272810.tif 000002
【特許請求の範囲】
【請求項１】
モバイル端末ソフトウェアのログデータ採取方法において、取得したログデータを当該モバイル端末が備えるバッファに格納するステップと、
前記バッファに次のログデータを格納する余裕があるか否かを判定するステップと、
前記判定にて次のログデータを格納する余裕がないと判定されたとき、予め設定された電子メールアドレスに、前記バッファに格納されたログデータを電子メールによって送信するステップとを有することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【請求項２】
請求項１記載のモバイル端末ソフトウェアのログデータ採取方法において、前記バッファに格納されたログデータを電子メールの添付ファイルとして送信することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【請求項３】
請求項１又は２記載のモバイル端末ソフトウェアのログデータ採取方法において、複数のバッファを用い、前記判定にて現在使用中のバッファに次のログデータを格納する余裕がないと判定されたとき次のログデータを別のバッファに格納することで前記複数のバッファを循環的に使用することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【請求項４】
請求項１、２又は３記載のモバイル端末ソフトウェアのログデータ採取方法において、前記メールアドレスに送信された電子メールを前記モバイル端末とは別のコンピュータにおいて受信し前記ログデータを入手するステップを有することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【請求項５】
請求項４記載のモバイル端末ソフトウェアのログデータ採取方法において、前記電子メールを受信したコンピュータにおいて前記入手した複数のログデータを時系列順にソートして結合するステップを更に有することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【請求項６】
請求項５記載のモバイル端末ソフトウェアのログデータ採取方法において、前記複数のログデータを時系列順にソートして結合するステップは、前記ログデータを送信したモバイル端末が複数ある場合、ログデータを送信したモバイル端末毎に別々にログデータを結合することを特徴とするモバイル端末ソフトウェアのログデータ採取方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ログデータ採取方法に関し、特に通信機能を有するモバイル端末のソフトウェアのログデータを採取する方法に関する。
【０００２】
【従来の技術】
従来、モバイル端末ソフトウェアのデバッグ及びテスト作業では、そのモバイル端末が具備する外部接続インタフェースと、デバッガを動作させるコンピュータとを接続し、このデバッガを操作することでデバッグ及びテスト作業を行うのが一般的である。また、モバイル端末上のソフトウェアのコンポーネントを階層化し、モバイル端末に接続したコンピュータ上でデバッガを動作させ、階層化された各ソフトウェアコンポーネントのデータ移動や関数呼び出しを監視し、その結果を表示できる方法も開示されている（特許文献１参照）。
【０００３】
上記のデバッグ・テスト技法はテスト工程の前半、つまりモバイル端末ソフトウェアの品質がまだ十分確保されていない時点や、問題点の調査に難航した場合に有効な手法であり、デバッグ・テスト工程が進みモバイル端末ソフトウェアの品質がある程度確保された状態になると、モバイル端末ソフトウェアのログデータを採取し、そのログデータを解析する方法に移行していくのが一般的である。
このログデータを採取する場合、そのモバイル端末が具備する外部接続インタフェースと、ログデータ採取用のコンピュータとを接続し、ログデータ採取用のコンピュータ上でログデータを採取・表示するソフトウェアを起動する方法が一般的である。一方、ログデータを採取するバッファを予め用意しておき、ログデータを採取する際はこのバッファ上にコピーし、ログデータ採取バッファが満杯になった場合は古いログデータ採取バッファを上書きしていく方法や、そのログ採取バッファを複数面持たせる方法も存在する。またログ採取の方法を設定することで、ログ採取バッファを可変とする方法もある（特許文献２参照）。しかし、モバイル端末を始めとする組み込み系のソフトウェアでは、その動作環境となるハードウェアは必要最小限のメモリ構成で設計されることが多いため、ログデータ採取用として扱えるバッファは少量になる。
【０００４】
また、モバイル端末のアプリケーションの不具合のログデータを採取し、その不具合のログデータの状況からアプリケーションの起動を制限することで、システム全体の安定性を確保する方法も公開されている（特許文献３参照）。
【０００５】
【特許文献１】
特開２０００−３３０８２１号公報
【特許文献２】
特開平９−０６２５４３号公報
【特許文献３】
特開２００２−４９４９２号公報
【０００６】
【発明が解決しようとする課題】
モバイル端末が持つ外部接続インタフェースとしては、シリアルインタフェースを始めとする低速なインタフェースが多い。このため、モバイル端末ソフトウェアの各制御がログデータを取得する処理を大量に呼び出したり、あるいは一度しか呼び出さない場合でも採取対象となるログデータの量が多いと、ログデータが全て採取されず一部落ちてしまう場合があり、結果として十分な問題解析が実施できない場合がある。また、従来の方法ではログデータを採取するためにはログデータ採取用のコンピュータがモバイル端末に接続されていなければならず、仮にログデータ採取用のコンピュータが接続されていない状態でテストを実施し問題が発生したとしても、その問題を解析するためのログデータを入手する手段がない。また、既に述べた通り、モバイル端末はその性格上、装置内に多くのメモリを用意することが難しいため十分なログデータ採取バッファを提供できない場合も多い。
【０００７】
本発明の目的は、モバイル端末ソフトウェアのログデータが多い場合であってもログデータが落ちることなく採取され、かつログデータ採取用のコンピュータが接続されていないデバッグ・テスト環境であってもモバイル端末ソフトウェアのログデータが採取できる方法を提供することにある。
【０００８】
【課題を解決するための手段】
本発明では、ログデータをモバイル端末が具備する外部インタフェースに出力するのではなく、テンポラリのバッファ（データフォルダ）に格納し、そのログデータがある一定のサイズに達した時点で、例えば電子メールの添付ファイルとして予め決まった電子メールアドレスに対して自動的に送信することによって前記目的を達成する。ログデータの入手は、別のコンピュータから当該電子メールアドレスに送信されている電子メールを受信し、添付ファイルを取り出すことで行う。
【０００９】
すなわち、本発明によるモバイル端末ソフトウェアのログデータ採取方法は、取得したログデータを当該モバイル端末が備えるバッファに格納するステップと、前記バッファに次のログデータを格納する余裕があるか否かを判定するステップと、前記判定にて次のログデータを格納する余裕がないと判定されたとき、予め設定された電子メールアドレスに、前記バッファに格納されたログデータを電子メールによって送信するステップとを有することを特徴とする。バッファに格納されたログデータは、電子メールの添付ファイルとして送信することができる。また、複数のバッファを用い、前記判定にて現在使用中のバッファに次のログデータを格納する余裕がないと判定されたとき次のログデータを別のバッファに格納することで前記複数のバッファを循環的に使用するようにしてもよい。ログデータは、メールアドレスに送信された電子メールをモバイル端末とは別のコンピュータにおいて受信し、ログデータが添付ファイルとして送信されている場合にはそのファイルを取り出すことで入手できる。
【００１０】
電子メールを受信したコンピュータでは、入手した複数のログデータを時系列順にソートして結合することで連続したログデータを取得することができる。ログデータを送信したモバイル端末が複数ある場合には、ログデータを送信したモバイル端末毎に別々にログデータを結合すればよい。
【００１１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図１は、本発明の方法に必要なデバッグ・テスト環境の説明図であり、図２はモバイル端末ソフトウェアの内部構成例を示す機能ブロック図である。
【００１２】
デバッグ・テスト対象となるモバイル端末１は、通信機能を有し、電子メールを送受信することができるものとする。コンピュータ２はモバイル端末ソフトウェアのログデータを入手し解析するためのものであり、電子メールのクライアント機能を搭載している。電子メールは電子メールサーバ３を介して送受信される。モバイル端末１、コンピュータ２、及び電子メールサーバ３は、インターネット４に接続されている。電子メールアドレス３１は電子メールサーバ３で管理されており、モバイル端末１には電子メールアドレス３１と同じ電子メールアドレス１１が設定されている。モバイル端末１は、この電子メールアドレス１１の設定を変更する機能を具備してもよい。モバイル端末１は、電子メールサーバ３に対し電子メールを送信できる環境にあり、電子メールアドレス３１に届いた電子メールはコンピュータ２から読み取ることが可能な環境にある。
【００１３】
デバッグ・テスト対象のモバイル端末１は、図２に示すように、ハードウェアを制御するドライバ１２、リアルタイムＯＳ１３、通信制御機能１４、電子メール制御機能１５、ログデータ採取機能１６、各種データを格納するデータフォルダ１７、デバッグ・テスト対象の機能１８を備える。また、モバイル端末１は外部インタフェース１９を具備する。データフォルダ１７は、ログデータを格納するエリアとして、ログ採取用バッファＡ面１７Ａ、ログ採取用バッファＢ面１７Ｂの二面具備するものとする。
【００１４】
デバッグ・テスト対象機能１８に限らず、モバイル端末ソフトウェアの各機能は、ログデータを採取する場合、ログデータ採取機能１６を利用する。一般的にリアルタイムＯＳ１３上で動作するアプリケーションは、ある一つの小さな処理を行う制御を複数組み合わせてシステムを構成するという考え方で実装される。
このため、ログデータ採取機能１６も、リアルタイムＯＳ１３上で動作する一つの小さな制御として実装する。
【００１５】
図３及び図４のフローチャートを用いて、本発明によるログデータの採取方法を説明する。
ログデータ採取機能１６が他制御からログデータ採取要求を受けると、先ず二面あるログ採取用バッファのどちらがカレント面なのかをチェックする（Ｓ１）。Ａ面を使用している場合、ログ採取用バッファＡ面１７Ａの残バッファサイズと書込要求のあったログのサイズを比較する（Ｓ２）。ログ採取用バッファＡ面１７Ａの残バッファサイズの方が大きければ、ログ採取用バッファＡ面１７Ａの書込先頭アドレスを求め（Ｓ３）、書込要求のあったログをログ採取用バッファＡ面１７Ａの書込先頭アドレスから書込み（Ｓ４）、残バッファサイズを更新し（Ｓ５）、アイドル状態に戻る。なお、ログ採取用バッファＡ面１７Ａの書込先頭アドレスは、「ログ採取用バッファＡ１７Ａの先頭アドレス＋（ログ採取用バッファＡ面１７Ａのサイズ−残バッファサイズ）」で求めることができる。また、残バッファサイズを更新する際は、残バッファサイズから書込要求のあったログのサイズを引けばよい。
【００１６】
一方、ステップ２の判定で、書込要求のあったログのサイズが残バッファサイズより大きい場合には、電子メール制御機能１５に、ログ採取用バッファＡ１７Ａを添付ファイルとしてメール送信する様にリクエストを出す（Ｓ６）。リクエスト完了後、ログ採取用バッファのカレント面をＢ面に変更し（Ｓ７）、書込要求のあったログをログ採取バッファＢ面１７Ｂの先頭に書込み（Ｓ８）、残バッファサイズを求めて（Ｓ９）、アイドル状態に戻る。なお、残バッファサイズは、ログバッファＢ面のサイズから書込要求のあったログのサイズを引くことで求めればよい。
【００１７】
また、ステップ１の判定でカレント面がＢ面だった場合も考え方は上記と同様である。先ず、ログ採取用バッファＢ面１７Ｂの残バッファサイズと書込要求のあったログのサイズを比較する（Ｓ１０）。ログ採取用バッファＢ面１７Ｂの残バッファサイズの方が大きければ、ログ採取用バッファＢ面１７Ｂの書込先頭アドレスを求め（Ｓ１１）、書込要求のあったログをログ採取用バッファＢ面１７Ｂの書込先頭アドレスから書込み（Ｓ１２）、残バッファサイズを更新し（Ｓ１３）、アイドル状態に戻る。ステップ１０の判定で書込要求のあったログのサイズが残バッファサイズより大きい場合には、電子メール制御機能１５に、ログ採取用バッファＢ１７Ｂを添付ファイルとしてメール送信する様にリクエストを出す（Ｓ１４）。リクエスト完了後、ログ採取用バッファのカレント面をＡ面に変更し（Ｓ１５）、書込要求のあったログをログ採取バッファＡ面１７Ａの先頭に書込み（Ｓ１６）、残バッファサイズを求めて（Ｓ１７）、アイドル状態に戻る。
【００１８】
上記の説明では、ログデータを採取するデータフォルダはログバッファＡ面１７ＡとログバッファＢ面１７Ｂの２面用意してあるが、モバイル端末１の残メモリ容量に応じてその個数を変更可能としてもよい。また、上記の説明ではモバイル端末１の電源をＯＦＦにした場合に、最後に採取したログデータが電子メールサーバに送信されないが、電源ＯＦＦの場合にも、電子メール制御機能１５に対して現時点のログ採取バッファを添付ファイルとしてメール送信する様にリクエストを出す構成としてもよい。
【００１９】
次に、モバイル端末１の電子メール制御機能１５の動作について説明する。電子メール制御機能１５は、ログデータ採取機能１６からの受信したログ採取バッファの面情報（Ａ面かＢ面か）により、添付ファイルとするログ採取バッファ面を選択する。この時、添付ファイルのファイル名称をユニークにするため、例えば、モバイル端末１の「シリアルナンバー」と「現在時刻」を組み合わせた文字列を添付ファイルのファイル名称とする。送信先の電子メールアドレスをモバイル端末１の電子メールアドレス１１から取得し、電子メールを送信する。なお、ファイル名称に使用する情報として、「シリアルナンバー」ではなく「電話番号」を使う方式でもよい。
【００２０】
最後に、コンピュータ２からモバイル端末１のログデータを参照する場合の手順を説明する。コンピュータ２の電子メールクライアント機能により、電子メールサーバ３から電子メールを受信後、添付ファイルを参照する。ここで、本発明ではログデータはある一定のサイズに分割されて電子メールの添付ファイル化されているため、一つのファイルに纏めなければログデータの解析が行えない場合が多い。この場合、添付ファイル名称に含まれる「シリアルナンバー」によりテスト対象となったモバイル端末を判別後、添付ファイル名称に含まれる「現在時刻」によりログデータを時系列順にソートし結合することで、モバイル端末毎のログデータを生成することが可能である。
【００２１】
このように、ログデータ採取機能１６は、ログデータをモバイル端末１が具備する外部インタフェース１９に出力するのではなく、テンポラリのバッファ（データフォルダ）に格納し、そのログデータがある一定のサイズに達した時点で電子メールの添付ファイルとして予め決められた電子メールアドレスに対して電子メールを自動的に送信する。実際にログデータを入手する際は、別のコンピュータ２から当該電子メールアドレスに送信されている電子メールを受信し、添付ファイルを取り出せばよい。従って、モバイル端末が持つ外部接続インタフェースが低速なもので、外部インタフェースを介するとログデータを大量に採取した際に一部落ちてしまう場合があったとしても、この方法によるとログデータが紛失することはなく、問題解析を行うことができる。また、ログデータ採取用のコンピュータがモバイル端末に接続されている必要性がないため、モバイル端末のみ持ち歩けばよく、フィールドにおけるテスト作業が容易になる。更にログデータが残らないという状況も発生しないため、再現性の低い問題が発生した場合も確実にログデータを採取することができる。また、通信機能を持つモバイル端末には電子メール機能が具備される場合が殆どであるため、本発明を実現するにあたり電子メール機能を新規に作りこむ必要はない。
【００２２】
また、電子メールの添付ファイルの名称に規則性を持たせることにより、一度に複数台のモバイル端末のテストを実施した場合であってもログデータをモバイル端末毎に時系列に参照することができる。
【００２３】
【発明の効果】
本発明によると、ログデータが多い場合であってもログデータが落ちることなく、またログデータ採取用のコンピュータが接続されていないデバッグ・テスト環境であってもモバイル端末ソフトウェアのログデータを採取することが可能になる。
【図面の簡単な説明】
【図１】本発明の方法に必要なデバッグ・テスト環境の説明図。
【図２】モバイル端末ソフトウェアの内部構成例を示す機能ブロック図。
【図３】本発明によるログデータの採取方法を説明するフローチャート。
【図４】本発明によるログデータの採取方法を説明するフローチャート。
【符号の説明】
１…モバイル端末、２…コンピュータ、３…電子メールサーバ、４…インターネット、１１…電子メールアドレス、１２…ドライバ、１３…リアルタイムＯＳ、１４…通信制御機能、１５…電子メール制御機能、１６…ログデータ採取機能、１７…データフォルダ、１７Ａ…ログバッファＡ面、１７Ｂ…ログバッファＢ面、１８…デバッグ・テスト対象機能、１９…外部インタフェース、３１…電子メールアドレス
【図１】
2004272810.tif 000003
【図２】
2004272810.tif 000004
【図３】
2004272810.tif 000005
【図４】
2004272810.tif 000006