(57)【要約】【課題】特別なハードウェアや、対象機器側の対応を必要とせずに、対象コンピュータ周辺機器の解析を実現できるようにする。【解決手段】解析対象となる周辺機器１４、１５が接続されたコンピュータシステムにおいて、このコンピュータシステムに解析用の専用ドライバ１１と専用アプリケーション１２とをインストールするステップと、専用アプリケーション１２にもとづき、専用ドライバ１１によって、解析対象周辺機器１４、１５に発行されている情報を監視するステップとを備える。【選択図】      図１
2004287630.tif 000002
【特許請求の範囲】
【請求項１】
解析対象となる周辺機器が接続されたコンピュータシステムにおいて、このコンピュータシステムに解析用の専用ドライバと専用アプリケーションとをインストールするステップと、前記専用アプリケーションにもとづき、前記専用ドライバによって、前記解析対象周辺機器に発行されている情報を監視するステップとを備えたコンピュータ周辺機器の状態解析方法。
【請求項２】
専用アプリケーションが、コンピュータシステムの周辺機器を対象としたデバイスドライバプログラムである、請求項１記載のコンピュータ周辺機器の状態解析方法。
【請求項３】
解析対象となる周辺機器が接続されるとともに、ネットワーク接続が施されているコンピュータシステムにおいて、このコンピュータシステムに前記ネットワークのための通信回線を経由して解析用の専用ドライバと専用アプリケーションとをインストールするステップと、前記通信回線を経由して専用アプリケーションを操作することで、前記専用ドライバによって、前記解析対象周辺機器に発行されている情報を監視するステップとを備えたコンピュータ周辺機器の状態解析方法。
【請求項４】
コンピュータシステムに検証用アプリケーションをインストールするステップと、解析用の専用アプリケーションから得られたデータをもとに、前記検証用アプリケーションを介して解析対象周辺機器にコマンドを発行するステップとを備えた請求項１から３までのいずれか１項記載のコンピュータ周辺機器の状態解析方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ周辺機器で不具合が発生した場合の解析・検証のためのコンピュータ周辺機器の状態解析方法に関し、たとえば通信回線を利用して遠隔操作にて解析・検証を行うためのコンピュータ周辺機器の状態解析方法に関する。
【０００２】
【従来の技術】
コンピュータ周辺機器の解析や検証には、対象機器に対してどのようなコマンドがどのような手順と時間間隔で発行されたかの情報を取得することが不可欠である。このようなコンピュータ周辺機器への発行コマンドを取得するには、２通りの方法がある。一つは、専用のハードウェアすなわちバスアナライザを、対象のコンピュータシステムに接続して取得する方法である。もう一つは、たとえば特許文献１に記載されているように、周辺機器自体に、自身に発行されたコマンドを自身のＲＡＭ上に履歴として残す機能を搭載し、データ取得用の特殊コマンドを対象機器で発行することで周辺機器内部の履歴データを吸い出す方法である。
【０００３】
【特許文献１】
特開平１１−６９４６７号公報
【０００４】
【発明が解決しようとする課題】
まず前述のバスアナライザ等の専用ハードウェアを使用する方法であるが、この方法は、信号線の状態も含め、もっとも詳細なデータが得られる方法である。しかし、これらバスアナライザは非常に高価であり、したがってユーザーにおける保有台数も限られるため、必然的に同時期に現場に投入できるケースが制限されてしまう。さらに決定的なことは、専用ハードウェアを必要とするために、その専用ハードウェアはもちろんのこと、解析作業現場においてそれを操作できる人間が必ず必要なことである。このため、遠隔地での問題発生の場合には、操作できる人員がハードウェアを携帯して現場に出向かなければならないという問題がある。
【０００５】
一方、もう一つの、周辺機器自身のＲＡＭに履歴を残す方法では、周辺機器自身がコマンド履歴を残すため、特殊なハードウェアは必要としない。しかし周辺機器自身のＲＡＭに履歴を残すことから、残せるデータ量はＲＡＭ容量に依存し、このため多くのデータを残すことは出来ない。もちろん、ＲＡＭ容量を増やせばその分だけ余分にデータを残すことは可能だが、ＲＡＭ容量の増加はそのまま製品のコストアップにもつながるため、製品としては現実的な対応ではない。また、開発する製品毎に、自身の制御ソフトウェア内に専用ルーチンを組み込まねばならず、設計段階における負担になりかねない。なにより、この方法は、その専用ルーチンが組み込まれている機器にのみ有効な方法であり、それ以外の機器に対しては適用できないという問題もある。
【０００６】
そこで本発明は、特別なハードウェアや、対象機器側の対応を必要とせずに、対象コンピュータ周辺機器の解析を実現できるようにすることを目的とする。
【０００７】
【課題を解決するための手段】
先ず、現在のパーソナルコンピュータ（以下、「ＰＣ」と称する）の構成と、現在のＰＣにて使用されているオペレーティングシステム（以下、「ＯＳ」と称する）内において各周辺機器への要求がどのように伝達されているのかの構造とについて説明する。
【０００８】
現在、ＰＣにはハードディスクドライブ、光ディスクドライブ他、様々な周辺機器が接続されている。Ｗｉｎｄｏｗｓ（登録商標）と呼ばれるＯＳを搭載したＰＣを例にとると、コンピュータ周辺機器などのハードウェアと、カーネルモードと呼ばれるモード上で動作するソフトウェアであるＯＳ（Ｗｉｎｄｏｗｓ（登録商標））と、ユーザーモードと呼ばれるモード上で動作するソフトウェア（アプリケーション）とによって構成され、各ハードウェアはＯＳのＩ／Ｏシステムにより管理されている。
【０００９】
次に、エンドユーザーが周辺機器に対してある要求を行った場合に、その要求がどのように処理されるかについて説明する。  まず、エンドユーザーは一般のアプリケーション等を操作することで、ＯＳに対して要求を発行する。これら要求はＩ／Ｏ要求としてＯＳのＩ／Ｏシステムにて受信され、パケット（Ｉ／Ｏ  Ｒｅｑｕｅｓｔ  Ｐａｃｋｅｔ、以下、「ＩＲＰ」と称する）にて表現される。Ｉ／Ｏシステム内のＩ／ＯマネージャがこのＩＲＰを生成し、そのＩＲＰへのポインタを適切なデバイスドライバに引き渡す。ここで、ＩＲＰは階層型のデバイスドライバのスタックによって処理されることが一般的である。最初に受け取った上位のドライバから順に、要求はより実際のハードウェアに近い表現に変換されて行き、最終的に最下位に位置するドライバが実際に対象のハードウェアとやりとりを行う。そして最終的に処理されたＩＲＰは、再びＩ／Ｏマネージャを通してデータと結果がユーザー側のアプリケーションに返される。すなわちＯＳからあるハードウェアに対して要求した命令やそのデータと結果は、Ｉ／Ｏマネージャとハードウェアとの間のドライバスタック内を通過しており、これをキャッチすることも可能ということである。
【００１０】
請求項１に記載の本発明は、解析対象となる周辺機器が接続されたコンピュータシステムにおいて、このコンピュータシステムに解析用の専用ドライバと専用アプリケーションとをインストールするステップと、前記専用アプリケーションにもとづき、前記専用ドライバによって、前記解析対象周辺機器に発行されている情報を監視するステップとを備えたものである。
【００１１】
より具体的には、本発明によれば、前述のようにドライバ階層構造を持つＯＳにて動作しているＰＣにおいて、ベンダーが配置することのできる階層構造の最下位、すなわちハードウェアに最も近い位置にて、上位および下位ドライバの動作に影響を及ぼすことなく対象機器へのパケットをキャッチすることを目的としたモニタ専用ドライバと、その専用ドライバと連動して対象機器のパケットデータを入手することを可能とした専用アプリケーションとを有し、専用アプリケーションは現在ＰＣに接続されている周辺機器の一覧からモニタ対象とする機器を選択することが可能であり、モニタ専用ドライバは、ドライバ階層構造内にて専用アプリケーションにより指定された機器に発行されているパケットをキャッチして、そのデータと結果を専用アプリケーションに通知することが可能である。これにより、専用アプリケーションで受信されたデータを解析作業者が解析することで、特別なハードウェアや対象機器側の対応を必要とせず、ソフトウェアのみの構成により、コンピュータ周辺機器の解析および検証作業を容易に実現することが可能となる。
【００１２】
請求項２に記載の本発明では、専用アプリケーションは、コンピュータシステムの周辺機器を対象としたデバイスドライバプログラムである。
請求項３に記載の本発明は、ネットワーク接続されているＰＣ環境において、接続されている通信回線を通して専用ドライバと専用アプリケーションとをインストールし、同じく通信回線経由で専用アプリケーションを操作し、専用アプリケーションが取得したデータを受信することで、解析作業現場にてアプリケーションを操作する人員を必要とせず、遠隔地からのコンピュータ周辺機器のモニタシステムを実現するものである。
【００１３】
請求項４に記載の本発明は、モニタ用アプリケーション以外に、対象機器に命令を発行する検証用アプリケーションもインストールし、モニタ用アプリケーションにて受信したデータをもとに、検証用アプリケーションを操作して対象機器にコマンドを発行して不具合現象の再現実験を行うことで、遠隔地からの解析のみならず不具合の解析のための検証実験をも実現するものである。
【００１４】
【発明の実施の形態】
以下に、本発明の実施の形態を、図面を参照して説明する。
（実施の形態１）
以下に、本発明の実施の形態１について、図１と図２を用いて説明する。
【００１５】
図１において、１はＰＣ２を操作するユーザーであり、解析作業者もこれにあてはまる。ＰＣ２は、ユーザーモードのアプリケーション３、モニタ専用アプリケーション１２、ＯＳ４、各周辺機器類１３等により構成されるものである。ＯＳ４において、５はＩ／Ｏシステムであり、Ｉ／Ｏマネージャ６を具備する。また７はドライバスタックで、上層から下層に向けて順に、上位ドライバ８と、中間ドライバ９と、下位ドライバ１０と、モニタ専用ドライバ１１とを有する。ハードウェアにて構成された周辺機器類１３は、この図１のものでは、モニタ対象１としての機器（Ａ）１４と、モニタ対象２としての機器（Ｂ）１５と、図外の機器とを備える。
【００１６】
このような構成において、周辺機器類１３の状態解析に際しては、まず、本発明の核となるモニタ専用ドライバ１１とそれに連動するモニタ専用アプリケーション１２とを、ＰＣ２内にインストールしておく。モニタ専用ドライバ１１はＯＳ２のドライバスタック７の最下層位置に配置されることが望ましい。なぜならば、下層にあるほど、実際にハードウェアに発行されているコマンドとその結果により近いデータが得られるからである。もし中間位置に配置したとすれば、コマンドや結果はそれより最下位にあるドライバによって変更される可能性があり、実際に発生している不具合状況と異なるデータを入手してしまうことが考えられ、解析対象としてのふさわしさに欠ける場合が起こり得る。
【００１７】
以下、ユーザー１がある操作をした場合に解析対象機器においてどのようなやりとりが行われているかを解析する場合を例にとり、説明する。まず、モニタ専用アプリケーション１２を起動させ、モニタすべき周辺機器を指定する。ここでは周辺機器類１３の中の機器（Ａ）１４と機器（Ｂ）１５とが指定されたとする。
【００１８】
ユーザー１は、アプリケーション３を操作することで、ファイルの読み書きなどのＩ／Ｏ要求をＯＳ４に対して発行する。アプリケーション３からのＩ／Ｏ要求はＯＳ４のＩ／Ｏシステム５にて受信され、Ｉ／Ｏシステム５内のＩ／Ｏマネージャ６により適切なＩＲＰが作成され、これが階層構造を持つドライバスタック７に引き渡される。ドライバスタック７内では、まず最上位ドライバ８にＩＲＰが渡され、中間ドライバ９、さらに下位に位置する下位ドライバ１０によりハードウェアに近い表現に変更されながら引き渡されて、最終的に最下位に位置するモニタ専用ドライバ１１を通過する。
【００１９】
モニタ専用ドライバ１１は、そのＩ／Ｏ要求がモニタ専用アプリケーション１２で指定された対象機器（Ａ）１４と対象機器（Ｂ）１５に対するものであればそれを確保し、そのＩ／Ｏ要求が終了した際に再びモニタ専用ドライバ１１に通知されるよう設定を行った後、ハードウェアとしての周辺機器類１３、もしくは下位にまだドライバが存在すればそのドライバにＩ／Ｏ要求を引き渡す。モニタ対象外機器に対するＩ／Ｏ要求であれば、ドライバ１１内では特別な設定をせずそのまま受け流す。そして機器（Ｂ）１５にてドライバへの完了通知設定したＩ／Ｏ要求が実行され終了した時点で、設定どおりモニタ専用ドライバ１１に通知され、ドライバ１１は、その結果とデータをコピーしてモニタ専用アプリケーション１２に通知する。
【００２０】
モニタ専用アプリケーション１２は、その結果を画面表示するかもしくはファイルに残すことでユーザー１に報告することが可能であり、これによりユーザー１は対象機器（Ａ）１４、対象機器（Ｂ）１５の通信状況を把握し解析することが可能となる。
【００２１】
上述の専用ドライバ１１と専用アプリケーション１２の動作を、以下において、図２に示すフローチャートに基づいて説明する。まず、アプリケーション側でモニタ対象機器を指定し（Ｓ１）、アプリケーション側でモニタ開始を実行し（Ｓ２）、対象機器の情報とモニタ開始の合図をドライバ側に通知する（Ｓ３）。モニタ開始した後はアプリケーション側はドライバ１１からのデータ通知待ち状態となる（Ｓ４）。
【００２２】
ドライバ１１は、モニタ開始した時点から、ＯＳ４からのＩ／Ｏ要求を監視する状態となる（Ｓ５）。ＯＳからのＩ／Ｏ要求が発生した場合（Ｓ６でＹＥＳ）、そのＩ／Ｏ要求がアプリケーション１２より指定された対象機器１４、１５に対してのものであれば（Ｓ７でＹＥＳ）、このＩ／Ｏ要求の発生時間を保存し、このＩ／Ｏ要求の実行が完了した際に処理関数（Ｓ１０）が呼び出されるよう設定して（Ｓ８）、モニタ停止要求がない限り（Ｓ１６でＮＯ）、要求Ｓ５からの監視ループに戻る。すなわち、ドライバ１１では、Ｓ６のＩ／Ｏ要求発生監視とＳ９のＩ／Ｏ要求完了通知監視との２つの監視ルーチンが同時に動作することとなる。
【００２３】
Ｓ８で設定したＩ／Ｏ要求が完了した場合（Ｓ９でＹＥＳ）は、そのＩ／Ｏ要求の内容と実行結果、またデータ転送を伴うものであればそのデータ等必要なＩ／Ｏ要求情報をコピーしてアプリケーション側に通知する（Ｓ１０）。
【００２４】
アプリケーション側は、このようにしてドライバ側からの通知を受け取ったなら（Ｓ１２でＹＥＳ）、そのデータを確保する（Ｓ１３）。Ｓ１３において、アプリケーション側は、データを受信する毎に表示デバイスへの表示を行ってもかまわないし、後述するモニタ終了時点で一括して表示してもかまわないし、一切表示せずに記憶装置へファイルの状態で保存してもかまわない。
【００２５】
このようなルーチンは、ユーザー１がモニタリングを停止するまで繰り返される。モニタリングを停止する場合は、ユーザー１がアプリケーション１２を操作してモニタリング終了命令を出す。ユーザー１からのモニタリング終了要求を受け取ったアプリケーションは（Ｓ１４でＹＥＳ）、モニタリング停止の通知をドライバ側に通知する（Ｓ１５）。アプリケーション側からのモニタ停止要求を受信したドライバ１１は（Ｓ１６でＹＥＳ）、上述の監視ルーチンを抜けてモニタリングを終了する。
【００２６】
このように本実施の形態１によれば、上述のようなソフトウェアのみの構成であることから、アプリケーション側で対応することで機能拡張なども容易である。例えば、常時発行されている不要なコマンド等をモニタ対象からはずすマスク機能や、特定のＩ／Ｏ要求もしくは結果が生じた際にモニタリングを開始するトリガ機能を設けることも可能である。
【００２７】
（実施の形態２）
つぎに、本発明の実施の形態２について、図３を用いて説明する。なお、前述した実施の形態１のものと同じ構成の部分については、その詳細な説明を省略する。
【００２８】
図３において、１６はＰＣ２のための通信回線で、有線、無線の形態を問わずネットーワークに接続されたものである。遠隔地に存在するＰＣ２での解析業務が生じた場合、解析作業者１７は、通信回線１６を通して操作することが可能なモニタ専用アプリケーション１２とモニタ専用ドライバ１１を、この通信回線１６を経由して転送し、対象ＰＣ２にインストールする。
【００２９】
その後、解析作業者１７側にあるＰＣ１８中の通信操作用アプリケーション１９を使用し、通信回線１６を通してモニタ専用アプリケーション１２を操作することとする。モニタ専用アプリケーション１２とモニタ専用ドライバ１１は、通信操作用アプリケーション１９の操作どおりに、実施の形態１と同様にしてモニタ対象１４のデータを取得し、取得したデータを、通信回線１６を通して解析作業者のＰＣ１８へ転送する。こうして解析作業者１７は、対象ＰＣ２での対象機器１４において、どのような現象が発生しているのかを、遠隔地にて確認することができる。
【００３０】
このように専用ソフトウェアのインストールから操作およびデータ取得まで全て通信回線１６を通すことで、遠隔地における解析作業が発生した場合でも、人員を派遣することなく、任意の対象機器１４のモニタリングおよび解析作業を実現することができる。
【００３１】
また、以下のような利用も可能である。すなわち、ＯＳ４の起動時に、モニタ条件を設定したモニタ専用アプリケーション１２を常駐型のアプリケーションとして起動することで、対象機器１４を常にモニタリング状態に置き、そのコマンド履歴をＰＣ２内の記憶装置にデータとして保存していく。そして特定のエラーが発生した場合に、通信回線１６を通してＰＣ１８へ通知し、これまでに取得した履歴データも転送する。このようにすれば、ＰＣ１８に、複数のモニタ対象ＰＣ２に接続された複数の対象機器１４の管理サーバー的な役割を持たせることも可能である。
【００３２】
（実施の形態３）
つぎに、本発明の実施の形態４について、図４を用いて説明する。なお、前述した実施の形態１、２のものと同じ構成の部分については、その詳細な説明を省略する。
【００３３】
上述の実施の形態２で構成されるようなネットワーク接続されたＰＣ環境において、再現実験などの検証作業も必要な場合は、通信回線経由１６を通して新たに検証用アプリケーション２０を対象ＰＣ２に転送しインストールする。解析作業者１７は、モニタ専用アプリケーション１２から得られたデータを実行用データとして検証用アプリケーション２０に転送し、それを実行するように操作する。そして検査用アプリケーション２０は、そのデータをもとにして、対象機器（Ａ）１４にコマンドを発行する。もちろんこの検査用アプリケーション２０が実行した命令もＯＳ４のドライバスタック７内を通っているため、この実行結果やデータもモニタ専用アプリケーション１２で取得することが可能であり、また実験結果を解析作業者１７にフィードバックすることも可能である。
【００３４】
このようにモニタ専用アプリケーション１２と検証用アプリケーション２０とを連携させることで、解析作業者１７は、シーケンスを変更したりする等、検証作業を重ねることが可能である。また、対象機器（Ａ）１４が自社の製品である場合は、そのファームウェアを通信回線１６を経由してアップデートすることも可能である。例えば、不具合が生じた際に、モニタ専用アプリケーション１２で得られたデータをもとに不具合の原因を特定し、不具合部分を修正したファームウェアを通信回線１６を経由して対象機器（Ａ）１４にダウンロードし、事前に得た不具合発生時のモニタデータを検証用アプリケーション２０に送り対象機器１４に対して繰り返し実行し確認実験を行うことで、不具合の解析から対象機器ファームウェアの検証まで行うことが可能である。
【００３５】
このように、本発明により、遠隔地で不具合が発生した場合でも、人員を派遣することなく対象機器の解析から検証まで一貫して行うことが可能となる。
【００３６】
【発明の効果】
以上のように、本発明の解析方法によれば、モニタ用の特殊なハードウェアを必要とせず、また対象機器側の対応も必要としないため、任意の対象機器の解析環境を構築することが可能であり、また特にそれら専用ソフトウェアを通信回線経由で操作することで、現場に人員を派遣することなく、遠隔地においても解析が可能であり、また検証用アプリケーションと連携させることで検証実験まで一貫して行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１にもとづくモニタシステムの構成図
【図２】本発明の実施の形態１における専用アプリケーションと専用ドライバとのやりとりを示すフローチャート
【図３】本発明の実施の形態２にもとづくモニタシステムの構成図
【図４】本発明の実施の形態３にもとづくモニタシステムの構成図
【符号の説明】
２  ＰＣ（パーソナルコンピュータ）
４  オペレーティングシステム（ＯＳ）
５  Ｉ／Ｏシステム
７  ドライバスタック
１１  モニタ専用ドライバ
１２  モニタ専用アプリケーション
１３  周辺機器類（ハードウェア）
１４  機器Ａ（モニタ対象１）
１５  機器Ｂ（モニタ対象２）
１６  通信回線
１９  通信操作用アプリケーション
２０  検証用アプリケーション
【図１】
2004287630.tif 000003
【図２】
2004287630.tif 000004
【図３】
2004287630.tif 000005
【図４】
2004287630.tif 000006