JP2021026754A - 情報処理装置、その制御方法、およびプログラム - Google Patents

Abstract

【課題】所定機種の情報処理装置で想定されていないエラーが発生した場合に、そのエラーの種類や対処方法を容易に特定することができるようにする。【解決手段】ログ・データ５１０−５１３は、エラーの解析に使用する複数の機器内情報を保存する。取得機器内情報推定部５０７は、発生したエラーの解析に必要な機器内情報を推定する。取得機器内情報抽出部５０８は、取得機器内情報推定部５０７の推定結果に対応する機器内情報を、ログ・データ５１０−５１３に保存された機器内情報から抽出する。エラー送信部５０４は、取得機器内情報抽出部５０８が抽出した機器内情報と、エラーの発生を通知するエラーイベントとを、ネットワーク通信部５０５へ送る。【選択図】 図５

Description

本発明は、情報処理装置、その制御方法、およびプログラムに関し、より詳細には、情報処理装置でのエラー発生を通知する技術に関する。

従来より、情報処理装置の機能として、動作不良や故障等のエラーが発生した際に、そのエラーの種類を示すエラーコードを添えて、クラウドなどの管理サーバへ通知する機能が知られている。エラーコードとは、発生した現象の種類を示す数字であり、情報処理装置の開発者によって割り振られる。

修理作業員は、エラーが発生した情報処理装置の設置現場に向かう前に、予め、管理サーバからエラーコードを受け取って、発生した現象の種類や対処方法等を特定することができる。そのため、修理作業員は、修理に必要な道具や交換部品等を事前に準備して設置現場へ向かうことができるため、修理作業に要する時間や労力を低減できる。

ここで、発生し得るエラーの種類は、情報処理装置の機種やシステム構成等に応じて異なる。そのため、ある機種では想定されているエラーが、他のある機種では想定されていない場合がある。

一方、従来より、情報処理装置の開発コストを削減するために、異なる機種間でプログラムモジュールを共通化したり、他機種用に開発したプログラムを流用したりするといった、工夫が行われている。これらの工夫は、エラー通知機能を実現するプログラムにおいても、同じである。このため、情報処理装置が、その機種では想定されていないエラーのエラーコードを通知できるように構成されている場合があり、何らかの原因により、そのエラーコードを管理サーバへ通知してしまう場合がある。

これに対して、下記特許文献１のシステムでは、メッセージのフィルタリングを行うことで、未登録メッセージの出力を監視している。そして、特許文献１のシステムでは、未登録メッセージが所定回数以上出力されると、未登録メッセージが出力されていることと、そのメッセージとを、管理者に通知する。この通知により、修理作業員は、未登録メッセージが通知されたことを、正しく把握することができる。

特開２００９−０６４０９８号公報

しかしながら、特許文献１のシステムでは、誤った通知が行われたとの警告を行うことができるものの、正しい通知を修理作業員へ行うことはできない。そのため、特許文献１のシステムでは、誤った通知が行われた場合には、修理作業員は、発生した現象の種類や対処方法等を特定することができず、このため、設置現場での修理時間や労力を低減するという、上述のような利便性を得ることができなかった。

本発明は、想定外のエラーが発生した場合に、そのエラーの種類や対処方法を容易に特定することができる情報処理装置を提供する。

上記の問題を解決するために、本発明の１実施形態に係る情報処理装置は、エラーの解析に使用する複数の機器内情報を保存する保存手段と、発生したエラーの解析に必要な機器内情報を推定する情報推定手段と、前記情報推定手段による推定結果に対応する機器内情報を、前記保存手段により保存された前記複数の機器内情報から抽出する情報抽出手段と、前記情報抽出手段が抽出した機器内情報と、エラーの発生を通知するエラーイベントとを、管理サーバへ送信する送信手段と、を備えることを特徴とする。

本発明によれば、想定されていないエラーのエラーコードが通知された場合でも、そのエラーの種類や対処方法等を容易に特定することができ、これにより、情報処理装置の修理時間や労力を低減できる。

本発明の各実施形態に係るシステムの全体構成を示すシステム構成図である。 本発明の各実施形態に係る管理サーバの構成を示すブロック図である。 本発明の各実施形態に係るクライアント端末の全体構成を示すブロック図である。 本発明の各実施形態に係る情報処理コントローラユニットの構成を示すブロック図である。 本発明の各実施形態に係るクライアント機のソフトウエア構成を示すブロック図である。 本発明の各実施形態に係るクライアント機のエラー送信動作を説明するためのフローチャートである。 （ａ）、（ｂ）、（ｃ）は実施形態１、２、３に係るクライアント機のエラー送信動作を説明するためのフローチャートである。 本発明の各実施形態に係るクライアント機のエラー送信動作を説明するためのフローチャートである。 本発明の実施形態４に係るクライアント機のエラー送信動作を説明するためのフローチャートである。

以下、本発明を実施するための形態について、図面を用いて説明する。
［実施形態１］
図１は、本実施形態に係るシステムの全体構成を示すシステム構成図である。
図１に示したように、ネットワーク１００は、管理サーバ１１０と、複数台のクライアント機１２０（図１では２台のクライアント機１２０ａ、１２０ｂを示す）と、操作端末１３０とに接続されている。

管理サーバ１１０は、クライアント機１２０から通知されたイベントを、内部のストレージ（図示せず）に保存する機能を有する。このストレージに蓄積された情報は、稼働監視情報の分析などに利用される。

また、管理サーバ１１０には、ウェブアプリケーション（図示せず）がインストールされている。このウェブアプリケーションは、ネットワーク１００を介して、操作端末１３０のウェブブラウザ等へ、閲覧データを提供する。

管理サーバ１１０としては、例えば、データストレージ機能と、情報処理計算機能と、ネットワーク通信機能とを具備する、コンピュータ等の汎用情報処理装置を使用できる。また、管理サーバ１１０を、汎用情報処理装置と同等の機能を有するクラウドサービスで実現してもよい。

クライアント機１２０は、本発明の「情報処理装置」に相当し、装置内で発生した事象を履歴イベントとして管理サーバ１１０へ通知する通信機能を有する。以下、クライアント機１２０として、複数種類の機能（例えばコピー機能やＦＡＸ機能等）を有する複合機を例に採って説明する。

操作端末１３０は、クライアント機１２０の開発担当者や修理作業員が使用する端末であり、ネットワーク１００を介して管理サーバ１１０へアクセスして、保存データを閲覧するため等に使用される。操作端末１３０としては、例えば、パーソナルコンピュータ等を使用できる。

図２は、管理サーバ１１０のハードウエア構成を示すブロック図である。図２は、管理サーバ１１０として一般的なコンピュータ等を使用する場合の、構成例である。
図２に示したように、管理サーバ１１０は、コントローラユニット２００、操作部２０９および表示部２１０を含んでいる。

コントローラユニット２００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１を有する。ＣＰＵ２０１は、システムバス２０８を介して、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、操作部Ｉ／Ｆ２０５、表示部Ｉ／Ｆ２０６およびネットワークＩ／Ｆ２０７へ接続されている。このＣＰＵ２０１は、ブートプログラムを用いてＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を起動したのち、このＯＳ上で各種アプリケーションプログラム等を実行する。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２は、ＣＰＵ２０１に実行されるブートプログラム等を保存する。
ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０１の作業領域として使用される。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４は、ＣＰＵ２０１に実行されるＯＳや各種アプリケーションプログラム等を保存する。さらに、ＨＤＤ２０４は、アプリケーションプログラムの、設定や履歴等のデータを保存する。

操作部Ｉ／Ｆ２０５は、ＣＰＵ２０１と操作部２０９とを接続するインタフェースであり、操作部２０９を用いてユーザが入力した情報をＣＰＵ２０１に送る。操作部２０９は、例えばマウスやキーボード等である。

表示部Ｉ／Ｆ２０６は、ＣＰＵ２０１と表示部２１０とを接続するインタフェースであり、表示部２１０に表示すべき画像のデータをＣＰＵ２０１から受け取って表示部２１０へ出力する。表示部２１０は、例えばディスプレイ等である。

ネットワークＩ／Ｆ２０７は、管理サーバ１１０を、ネットワーク１００上の各装置へ接続して、情報の入出力を行うためのインタフェースである。
図３は、クライアント機１２０のハードウエア構成を示すブロック図である。上述したように、本実施形態のクライアント機１２０は、複合機である。

情報処理コントローラユニット３０１は、クライアント機１２０の動作に係る情報処理制御を統括するコントローラである。
プリンタコントローラユニット３０２は、情報処理コントローラユニット３０１の制御に基づいて、プリンタ３０４を制御する。プリンタ３０４は、通常の画像出力デバイスである。

スキャナコントローラユニット３０３は、情報処理コントローラユニット３０１の制御に基づいて、スキャナ３０５を制御する。スキャナ３０５は、通常の画像入力デバイスである。

図４は、クライアント機１２０（図３参照）に設けた情報処理コントローラユニット３０１のハードウエア構成を示すブロック図である。
図４に示したように、情報処理コントローラユニット３０１は、ＣＰＵ４０１を有する。ＣＰＵ４０１は、システムバス４１０を介して、ＲＯＭ４０２、ＲＡＭ４０３、ネットワークＩ／Ｆ４０５、操作部Ｉ／Ｆ４０６、画像処理部４０７、デバイスコントローラＩ／Ｆ４０８、および電源制御部４０９へ接続されている。このＣＰＵ４０１は、ブートプログラムを用いてＯＳを起動したのち、このＯＳ上で各種アプリケーションプログラム等を実行する。

ＲＯＭ４０２は、ＣＰＵ４０１に実行されるブートプログラム等を保存する。
ＲＡＭ４０３は、ＣＰＵ４０１の作業領域として使用されるとともに、画像データを一時記憶するための画像メモリ領域としても使用される。

ＨＤＤ４０４は、ＣＰＵ４０１に実行されるＯＳや、各種アプリケーションプログラムや、画像データ等を保存する。さらに、ＨＤＤ４０４は、アプリケーションプログラムの、設定や履歴等のデータを保存する。

ネットワークＩ／Ｆ４０５は、クライアント機１２０を、ネットワーク１００を介して管理サーバ１１０へ接続し、情報の入出力を行うためのインタフェースである。
操作部Ｉ／Ｆ４０６は、ＣＰＵ４０１と操作部３０６とを接続するインタフェースであり、ユーザが操作部３０６で入力した情報をＣＰＵ４０１に送る。操作部３０６は、例えばマウスやキーボード等である。

画像処理部４０７は、プリンタ３０４へ出力する画像の変換処理や、スキャナ３０５から入力した画像の変換処理を行う。併せて、画像処理部４０７は、画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理を行う。

デバイスコントローラＩ／Ｆ４０８は、プリンタコントローラユニット３０２およびスキャナコントローラユニット３０３へ接続され、画像データの同期系や非同期系の変換を行う。

電源制御部４０９は、クライアント機１２０全体の電源制御を行う。具体的には、電源制御部４０９は、クライアント機１２０の電源オン／オフ制御や、通常通電状態と省電力状態との間の移行／復帰の制御等を行う。

情報処理コントローラユニット３０１には、エラー処理部５００が、ソフトウエアで構成される。すなわち、エラー処理部５００の各構成部は、ＨＤＤ４０４に記憶されているプログラムを、ＲＡＭ４０３にロードして、ＣＰＵ４０１で実行することにより実現される。図５は、エラー処理部５００の構成を示すブロック図である。

図５のエラー処理部５００において、エラー管理部５０１は、クライアント機１２０内の各モジュールでエラーが発生した際にエラーコードを受けとる機能と、発生したエラーのログをエラー発生履歴ログ５０６として記録する機能とを有する。また、エラー管理部５０１は、エラーが発生したことをエラー回収部５０２へ伝える機能を有する。

本実施形態では、発生したエラーが、そのクライアント機１２０が属する機種で発生するエラーとして予め想定されているエラーか否かに応じて、エラーコードの決定方法が異なる。想定されているエラーが発生した場合は、そのエラーが発生したモジュールからエラー管理部５０１へ、通常のエラーコード、すなわちエラーの分類に応じて開発者等が予め割り当てたエラーコード（以下、「個別エラーコード」と記す）が送られる。一方、想定外のエラーが発生した場合は、そのエラーが発生したモジュールからエラー管理部５０１へ、想定外のエラーが発生したことを示すエラーコード（以下、「包括想定外エラーコード」と記す）が送られる。

エラー回収部５０２は、発生したエラーを管理サーバ１１０へ通知するための処理を行う。具体的には、エラー回収部５０２は、発生したエラーを、エラーイベントとして正規化する処理を行う。また、エラー回収部５０２は、エラー管理部５０１から入力したエラーコードに基づいて、そのエラーが、クライアント機１２０が属する機種で発生するエラーとして想定されているエラーか否かを判断する。

メッセージバッファ５０３は、正規化したエラーイベントを、エラー回収部５０２から受け取って保存する。正規化されたエラーイベントは、不揮発性の記憶領域へ保存することが望ましく、本実施形態ではＨＤＤ４０４に保存される。エラーイベントの正規化には、ＪＳＯＮなどの汎用フォーマットを用いることができる。

エラー送信部５０４は、例えばメッセージバッファ５０３への書き込みを検知するなどして、エラーイベントが発行されたことを検知する。エラーイベントの発行を検知したとき、エラー送信部５０４は、そのエラーイベントの情報をメッセージバッファ５０３から読み出し、ネットワーク通信部５０５を介して管理サーバ１１０へ送信する。後述するように、本実施形態では、想定外のエラーが発生した場合、エラーイベントと共にファイルを送信する。エラー送信部５０４は、送信するファイルを、抽出データ５０９として、デバッグログ５１０、ジョブログ５１１、プリントデータ５１２、スキャンデータ５１３等から取得する。

ネットワーク通信部５０５は、ネットワークＩ／Ｆ４０５を利用して、通信を行う。
エラー発生履歴ログ５０６は、上述したように、発生したエラーのログであり、ＨＤＤ４０４に保持される。

取得機器内情報推定部５０７は、エラーコードが包括想定外エラーコードであるとエラー回収部５０２が判断した場合に、デバッグログ５１０やジョブログ５１１等の各種ログを取得する。そして、取得機器内情報推定部５０７は、取得したログに基づいて、発生したエラーの解析に必要な機器内情報を推定する（後述）。

取得機器内情報抽出部５０８は、取得機器内情報推定部５０７の推定結果に対応する機器内情報、すなわちエラー解析に必要であると推定された機器内情報のファイルパスを取得し、エラー回収部５０２へ通知する（後述）。

抽出データ５０９は、デバッグログ５１０、ジョブログ５１１、プリントデータ５１２、スキャンデータ５１３等の各種機器内情報の中から、エラー解析に必要な機器内情報として取得機器内情報推定部５０７で指定されて抽出されたデータである。
表１に、機器内情報の例を示す。

デバッグログ５１０は、クライアント機１２０内に設けられた各モジュールの動作情報の記録であり、主としてデバッグに使用される。
ジョブログ５１１は、例えばプリントやスキャンなど、クライアント機１２０が実行した処理の処理単位ごとの履歴である。ジョブログ５１１は、例えばジョブが開始された時刻や、実行結果、印刷枚数などの記録を含む。

プリントデータ５１２は、印刷用のデータであり、例えば、印刷する画像データそのものや、印刷のために画像データを変換したデータである。
スキャンデータ５１３は、例えばスキャナ３０５での読み取り処理で生成した画像データである。

次に、図６を用いて、本実施形態に係るエラー処理を説明する。図６は、エラー管理部５０１がエラーを検知してから、エラー送信部５０４がエラーを送信するまでの処理を説明するフローチャートである。

以下の説明は、エラー管理部５０１が、外部（クライアント機１２０内の他のモジュール）から、包括想定外エラーコードを受信する場合の例である。但し、外部から個別エラーコードをそのまま受信し、エラー管理部５０１あるいはエラー回収部５０２によって、受信した個別エラーコードに対応するエラーが想定されたエラーか否かを判断することとしてもよい。例えば、クライアント機１２０内に、想定されたエラーの個別エラーコードをリスト化して記憶しておき、受信した個別エラーコードがリストに含まれない場合に、その個別エラーコードを包括想定外エラーコードへ書き換えることにしてもよい。

情報処理コントローラユニット３０１の例えばＨＤＤ４０４は、クライアント機１２０内で発生すると想定されているエラーのエラーコードを、リスト化して保存している。クライアント機１２０内の各モジュールでエラーが発生したとき、情報処理コントローラユニット３０１は、発生したエラーのエラーコードを、リスト化された各エラーコードリストと比較する。

情報処理コントローラユニット３０１は、発生したエラーの個別エラーコードがリストに存在しない場合、想定外のエラーが発生したと判断する。この場合、情報処理コントローラユニット３０１は、発生したエラーの個別エラーコードを、想定外のエラーコードが発生したことを示すエラーコード、すなわち包括想定外エラーコードに書き換えて、エラー処理部５００へ送る。

一方、発生したエラーのエラーコードがリストに存在している場合、発生し得ると想定されているエラーが発生したと判断して、発生したエラーの個別エラーコードをそのままエラー処理部５００へ送る。

エラー処理部５００のエラー管理部５０１は、上述のように、受け取ったエラーコードのログをエラー発生履歴ログ５０６として記録するとともに、そのエラーコードをエラー回収部５０２へ伝える。

エラー回収部５０２は、受け取ったエラーコードが、想定外のエラーに対応するか否か、すなわち包括想定外エラーコードか否かを判定する（ステップＳ６０１）。包括想定外エラーコードではない場合、このエラーコード（すなわち個別エラーコード）を、メッセージバッファ５０３へ保存する。そして、エラー送信部５０４が、このエラーコードを用いてエラーイベントを生成し、ネットワーク通信部５０５を介して管理サーバ１１０へ送信して（ステップＳ６０５）、処理を終了する。

一方、ステップＳ６０１で包括想定外エラーコードであった場合、取得機器内情報推定部５０７が、発生したエラーの解析に必要な機器内情報を推定する（ステップＳ６０２）。ステップＳ６０２の推定処理の詳細については、図７（ａ）を用いて後述する。

続いて、取得機器内情報抽出部５０８が、取得機器内情報推定部５０７の推定結果に基づいて、エラーの解析に必要な関連する機器内情報を取得する（ステップＳ６０３）。ステップＳ６０３の取得処理の詳細については、図８を用いて後述する。

最後に、エラー送信部５０４が、この包括想定外エラーコードを含むエラーイベントを、エラー解析に必要な機器内情報とともに管理サーバ１１０へ送信して（ステップＳ６０４）、処理を終了する。

具体的には、エラー送信部５０４は、まず、メッセージバッファ５０３に保存されているエラーイベントを読み出す。次に、エラーイベントと共に送信するファイル、すなわちエラー解析に必要な機器内情報のファイルを取得する。ファイルを特定するファイルパスは、取得機器内情報抽出部５０８から読み出される。そして、取得されたファイルが、エラーイベントとともに、エラー送信部５０４から管理サーバ１１０へ送信される。

なお、本実施形態では、１種類の包括想定外エラーコードのみを使用したが、複数種類の包括想定外エラーコードを使用してもよい。

例えば、プリンタコントローラユニット３０２内で想定外のエラーが発生した場合と他の場合とで、異なる包括想定外エラーコードをエラー管理部５０１へ伝えることとしてもよい。この場合、取得機器内情報推定部５０７は、想定外のエラーの発生場所がプリンタコントローラユニット３０２内であることを把握できる。その結果、取得機器内情報推定部５０７は、例えば、エラーの解析に必要な機器内情報が、プリンタコントローラログであると推定することができる。

図７（ａ）は、ステップＳ６０２（図６参照）の処理を詳細に示すフローチャートである。この処理は、エラー処理部５００によって実行される。エラー処理部５００は、上述のように、情報処理コントローラユニット３０１のＣＰＵ４０１がプログラムを実行することによって実現される。

図７（ａ）の処理では、まず、取得機器内情報推定部５０７が、デバッグログ５１０から、直近システムログを取得する（ステップＳ７０１）。

次に、取得機器内情報推定部５０７は、直近システムログから、最も直近に発生したエラーを示すログを抽出する（ステップＳ７０２）。具体的には、取得機器内情報推定部５０７は、直近システムログからエラーが発生したことを示すログの行を抽出して、ログ記録時刻が最も新しい行のみ抽出する。

続いて、取得機器内情報推定部５０７は、抽出したログを用いて、エラーを発生させたプロセス（またはタスク）を特定する（ステップＳ７０３）。システムログには、ログを出力したプロセス、出力した時刻、ログの内容などが、記録されている。そのため、抽出した行から、エラーが発生したことを示すログを出力したプロセスを特定できる。

最後に、特定したプロセスから、エラー解析に必要な機器内情報を特定する（ステップＳ７０４）。
表２は、エラー解析に必要な機器内情報とプロセスとの関係の１例を示す。

図８は、ステップＳ６０３（図６参照）の処理を詳細に示すフローチャートである。ステップＳ６０３の処理は、エラー処理部５００の取得機器内情報抽出部５０８によって実行される。

まず、取得機器内情報抽出部５０８は、必要な機器内情報が保存されているファイルのパスを取得する（ステップＳ８０１）。具体的には、取得機器内情報抽出部５０８が、予め、各機器内情報と保存場所との対応情報を保存しておき、その対応情報を参照してファイルパスを取得する。但し、機器内情報と保存場所との対応情報は、取得機器内情報抽出部５０８以外の構成部に保存しておいてもよい。

次に、取得機器内情報抽出部５０８は、取得したファイルパスを用いて、エラー解析に必要な機器内情報を抽出する（ステップＳ８０２）。本実施形態では、抽出するファイルとしては、デバッグログ５１０、ジョブログ５１１、プリントデータ５１２、スキャンデータ５１３のいずれかが該当するが、これら以外の機器内情報を参照してもよい。

続いて、取得機器内情報抽出部５０８は、抽出した機器内情報を、ひとつのディレクトリにまとめて、圧縮する（ステップＳ８０３）。圧縮方法としては、ｚｉｐやｔａｒ．ｇｚなど、汎用のフォーマットを用いることができる。この圧縮により、送信時のネットワーク負荷を低減できる。

最後に、取得機器内情報抽出部５０８は、エラー送信時にエラーイベントとともに送信するファイルとして、この圧縮ファイルを指定する（ステップＳ８０４）。具体的には、取得機器内情報抽出部５０８が、圧縮したファイルのパスをエラー回収部５０２へ通知すると、エラー回収部５０２が、このファイルパスを、エラーイベントとともに、メッセージバッファ５０３へ保存する。

以上のようにして、クライアント機１２０は、管理サーバ１１０へ、包括想定外エラーコードと、想定外のエラーコードの発生原因を解析するために必要な機器内情報とを、送信する。修理作業員や開発担当者は、ネットワーク１００を介して、例えばパソコン等の操作端末１３０を管理サーバ１１０へ接続する。そして、修理作業員等は、操作端末１３０のウェブブラウザを操作して、管理サーバ１１０のウェブアプリケーションへアクセスし、管理サーバ１１０内の包括想定外エラーコードや機器内情報を閲覧する。

これにより、修理作業員は、包括的想定外エラーコードを確認して、想定外のエラーが発生したことを理解することができる。一方、開発担当者は、エラーイベントとあわせて送信された機器内情報を参照することで、エラーの原因や対処方法を検討することができる。本実施形態では、機器内の全ての情報ではなく、エラー解析に必要な情報のみを送信するため、データ送信時のネットワーク負荷の軽減や、開発担当者のエラー解析所要時間の短縮を図ることができる。

［実施形態２］
以下、実施形態２について、図７（ｂ）を用いて説明する。本実施形態に係るシステムや動作は、以下に説明する事項を除いて、上述の実施形態１と同じである。
上述の実施形態１では、エラーが発生したプロセス／タスクからエラーが発生した箇所を特定することで、エラー解析に必要な機器内情報を推定した（図６のステップＳ６０２、図７のステップＳ７０３参照）。

これに対して、本実施形態では、エラー発生時またはエラー発生直前に実行していたジョブから、エラー解析に必要な機器内情報を推定する。
図７（ｂ）は、ステップＳ６０２（図６参照）の処理を詳細に示すフローチャートである。この処理は、エラー処理部５００の取得機器内情報推定部５０７によって実行される。エラー処理部５００は、上述のように、情報処理コントローラユニット３０１のＣＰＵ４０１がプログラムを実行することによって実現される。

まず、取得機器内情報推定部５０７は、ジョブログ５１１を取得する（ステップＳ７１１）。
次に、取得機器内情報推定部５０７は、取得したジョブログ５１１から、エラー発生時またはエラー発生直前に実行していたジョブを特定する（ステップＳ７１２）。具体的には、取得機器内情報推定部５０７は、ジョブログ５１１から、実行したジョブのそれぞれについて、ジョブ開始時刻とジョブ終了時刻とを取得し、エラー発生時刻と比較することで、ジョブを特定する。

そして、取得機器内情報推定部５０７は、特定したジョブから、エラー解析に必要な機器内情報を指定する（ステップＳ７１３）。
表３は、エラー解析に必要な機器内情報とジョブとの関係の１例を示す。

上述の実施形態１では、開発担当者は、エラーが発生した箇所を特定することはできるが、どのような経緯でエラーが発生したかを特定することはできない。これに対して、本実施形態では、エラーが発生した際に実行していたジョブを特定するので、エラーが発生するまでの経緯を特定することができる。これにより、開発担当者がエラーを解析する時に、エラーのきっかけとなる要因を特定したり、エラーが起こる原因となり得る要素を限定したりすることができる。

本実施形態は、上述の実施形態１と併用することも可能である。すなわち、プロセス／タスクから推定した機器内情報とジョブから推定した機器内情報の両方を、管理サーバ１１０へ送信することにしてもよい。

［実施形態３］
以下、実施形態３について、図７（ｃ）を用いて説明する。本実施形態に係るシステムや動作は、以下に説明する事項を除いて、上述の実施形態１と同じである。
本実施形態では、個別エラーコードから、エラー解析に必要な機器内情報を推定する点で、上述の実施形態１、２と異なる。

図７（ｃ）は、図６のステップＳ６０２での処理を詳細に示すフローチャートである。この処理は、エラー処理部５００の取得機器内情報推定部５０７によって実行される。エラー処理部５００は、上述のように、情報処理コントローラユニット３０１のＣＰＵ４０１がプログラムを実行することによって実現される。

まず、取得機器内情報推定部５０７は、エラーが発生したとき、個別エラーコードから、メインコードを取得する（ステップＳ７２１）。ここで、メインコードとは、発生したエラーの主分類を示す。主分類が同じエラー群は、それぞれエラーの内容やエラー発生場所が同じである。本実施形態では、エラー発生時に、エラー管理部５０１は、包括的想定外エラーコードと共に、個別エラーコードを管理する。但し、個別エラーコードを取得する方法は、他の方法でもよい。

次に、取得機器内情報推定部５０７は、個別エラーコードから取得したメインコードが定義されているものか否かを判定する（ステップＳ７２２）。メインコードが定義されていなかった場合、発生したエラーのコード自体からは現象を理解することができないため、全ての機器内情報を指定して（ステップＳ７２４）、処理を終了する。

一方、ステップＳ７２２でメインコードが定義されていると判断した場合、エラー解析に必要な機器内情報うちメインコードに対応したものを指定して（ステップＳ７２３）、処理を終了する。これにより、エラーの詳細を特定することはできないとしても、概要を特定することは可能となる。
表４は、エラー解析に必要な機器内情報と、メインコードとの関係の１例を示す。

本実施形態に係る方法により、想定外のエラーが発生したときに、エラーそのものが不明なのか、あるいはエラーの詳細のみが不明なのかを、判断することができる。そして、エラーの詳細のみが不明の場合は、開発担当者がエラーの解析を行うために必要な情報を特定することができる。

本実施形態は、上述の実施形態１、２の一方または両方と併用することも可能である。すなわち、プロセス／タスクから推定した機器内情報と、ジョブから推定した機器内情報との少なくとも一方を、メインコードから推定した機器内情報とともに、管理サーバ１１０へ送信してもよい。

［実施形態４］
以下、実施形態４について、図９を用いて説明する。本実施形態に係るシステムや動作は、以下に説明する事項を除いて、上述の実施形態１〜３と同じである。
上記実施形態１〜３では、クライアント機１２０のエラーコードが包括想定外コードである場合の対処を、自動的に行っている。しかし、包括想定外コードが何度も発生するケースでは、その発生原因が同一であるケースも多いため、機器内情報を毎回通知しなくても、最初の一回だけ通知すれば、包括想定外コードが発生した原因の詳細を解析することは可能である。

このため、本実施形態では、包括想定外コードとなるエラーが発生した場合に、予め定めた条件に応じて、同じ機器内情報の取得・送信の繰り返しを抑制する。なお、本実施形態では、「エラー」という用語を使用しているが、機器の動作を止めるエラーに限定するものではなく、動作を継続可能なアラームや、用紙の詰まりであるジャム等であっても良い。

図９は、エラー処理部５００のエラー管理部５０１がエラーを検知してから、エラー送信部５０４がエラーを示すコードを送信するまでの、処理の詳細を示すフローチャートである。
図９において、ステップＳ９０１、Ｓ９０４、Ｓ９０６、Ｓ９０７で示す処理は、それぞれ図６中のステップＳ６０１、Ｓ６０２、Ｓ６０４、Ｓ６０５の処理と同一である。

以下に説明するように、本実施形態では、エラー管理部５０１が、包括想定外エラーコードを管理するだけでなく、実際に発生した個別エラーコードを管理する（後述のステップＳ９０２参照）。更に、本実施形態では、エラー管理部５０１は、機器内情報のうち、情報処理コントローラユニット３０１を動作させるプログラムのバージョン（コントローラのバージョン）を、包括想定外エラーコードと共に管理する（後述のステップＳ９０３参照）。エラー管理部５０１は、これらの管理のために、実際に発生した個別エラーコードや、エラー発生時におけるコントローラのバージョンを、エラー発生履歴ログ５０６へ記録する（後述のステップＳ９０５参照）。

以下、図９のエラー処理について、詳細に説明する。
まず、ステップＳ９０１で、エラーコードが包括想定外エラーコードか否かを判断する。包括想定外エラーコードであった場合、エラー管理部５０１は、実際に発生した個別エラーコードと、エラー発生履歴ログ５０６中の個別エラーコードとを比較し、過去に同じ個別エラーコードが発生したか否かを確認する（ステップＳ９０２）。過去に同じ個別エラーコードが発生していなかった場合は、ステップＳ９０７の処理に移る。

一方、過去に同じ個別エラーコードが発生していた場合、エラー管理部５０１は、ステップS９０３にて、過去に個別エラーコードが発生していた際のコントローラのバージョン情報を、エラー発生履歴ログ５０６中から取得する。さらに、エラー管理部５０１は、取得したバージョン情報を、機器構成情報中のコントローラのバージョン情報と比較し、バージョンが同一ではなかった場合は、ステップＳ９０４の処理に移る。

ステップS９０３にてバージョンが同一だった場合は、ステップＳ９０７の処理を実行する。このステップＳ９０７では、エラー回収部５０２が、受け取ったエラーコードを、メッセージバッファ５０３に、エラーイベントとして保存する。そして、エラー送信部５０４が、このエラーコードを用いてエラーイベントを生成し、ネットワーク通信部５０５を介して管理サーバ１１０へ送信して、処理を終了する。

ステップＳ９０４では、取得機器内情報推定部５０７が、発生したエラーの解析に必要な機器内情報を推定する。この推定処理は、上記実施形態１〜３の何れかにおけるステップＳ６０２の処理と同じでよい（図７（ａ）〜（ｃ）参照）。また、上記実施形態１〜３おけるステップＳ６０２の処理を２つ以上併用してもよいことは、もちろんである。

続いて、ステップＳ９０５で、エラー管理部５０１は、ステップＳ６０３と同様、機器内情報を取得するための処理を行う。この処理では、エラー管理部５０１が、包括想定外エラーコードと共に、実際に発生した個別エラーコードと、情報処理コントローラユニット３０１のプログラムのバージョン(コントローラのバージョン)とを、エラー発生履歴ログ５０６に記録する。
その後、ステップＳ９０６で、エラー送信部５０４が、この包括想定外エラーコードを含むエラーイベントを、エラー解析に必要な機器内情報とともに管理サーバ１１０へ送信して、処理を終了する。

本実施形態に示す方法によれば、クライアント機１２０は、過去に同一の個別エラーコードが発生していた場合に、機器内情報の送信を抑制することができる（ステップＳ９０２参照）。
さらに、本実施形態では、コントローラの現状バージョンを、過去の個別エラーコード発生時のバージョンを比較し、これらのバージョンが異なっている場合に限り、機器内情報の送信を行う（ステップＳ９０３，Ｓ９０７参照）。これにより、個別エラーコードが発生した場合に、情報処理コントローラユニット３０１のプログラム・バージョンが同一であれば、同一のエラーであると判断して、機器内情報の送信が抑制される。

１００ ネットワーク
１１０ 管理サーバ
１２０ａ、１２０ｂ クライアント機
１３０ 操作端末
５００ エラー処理部
５０１ エラー管理部
５０２ エラー回収部
５０３ メッセージバッファ
５０４エラー送信部
５０５ ネットワーク通信部
５０６ エラー発生履歴ログ
５０７ 取得機器内情報推定部
５０８ 取得機器内情報抽出部
５０９ 抽出データ
５１０ デバッグログ
５１１ ジョブログ
５１２ プリントデータ
５１３ スキャンデータ

Claims (10)

1. エラーの解析に使用する複数の機器内情報を保存する保存手段と、
   発生したエラーの解析に必要な機器内情報を推定する情報推定手段と、
   前記情報推定手段による推定結果に対応する機器内情報を、前記保存手段により保存された前記複数の機器内情報から抽出する情報抽出手段と、
   前記情報抽出手段が抽出した機器内情報と、エラーの発生を示すエラーイベントとを、管理サーバへ送信する送信手段と
   を備えることを特徴とする情報処理装置。
2. 発生したエラーが、予め想定されたエラーであるか否かを判定するエラー判定手段をさらに備え、
   前記送信手段は、
   想定されたエラーである場合、前記エラーイベントのみを送信し、
   想定外のエラーである場合、前記情報抽出手段に抽出された前記機器内情報を、前記エラーイベントとともに送信する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記送信手段は、
   想定されたエラーである場合、前記エラーイベントに、エラーの分類に応じて個別に定めた個別エラーコードを格納して送信し、
   想定外のエラーである場合、前記エラーイベントに、複数の前記個別エラーコードを包括するように定めた包括想定外エラーコードを格納して送信する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記情報推定手段は、
   発生したエラーを示す前記個別エラーコードを特定し、
   特定された前記個別エラーコードの主分類を示すメインコードを特定し、
   特定された前記メインコードから、エラーの解析に必要な前記機器内情報を特定する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記送信手段は、想定外のエラーの発生原因に応じて、予め定めた複数種類の前記包括想定外エラーコードの何れか一つを送信することを特徴とする請求項３に記載の情報処理装置。
6. 前記送信手段は、
   発生した想定外のエラーが、過去に発生したエラーと同一の分類に属する場合には、前記エラーイベントのみを送信し、
   発生した想定外のエラーが、過去に発生したエラーと異なる分類に属する場合には、前記機器内情報を、前記エラーイベントとともに送信する、
   ことを特徴とする請求項２乃至５の何れか１項に記載の情報処理装置。
7. 前記情報推定手段は、
   最も直近に発生したエラーを特定し、
   特定された前記エラーに対応するプロセスまたはタスクを特定し、
   特定された前記プロセスまたはタスクから、エラーの解析に必要な前記機器内情報を特定する
   ことを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
8. 前記情報推定手段は、
   エラーの発生時刻を特定し、
   特定された前記エラー発生時刻またはその直前に実行していたジョブを特定し、
   特定された前記ジョブに応じて、エラーの解析に必要な前記機器内情報を特定する
   ことを特徴とする請求項１乃至７の何れか１項に記載の情報処理装置。
9. 情報処理装置における制御方法であって、
   エラーの解析に使用する複数の機器内情報を保存する保存工程と、
   発生したエラーの解析に必要な機器内情報を推定する情報推定工程と、
   前記情報推定工程での推定結果に対応する機器内情報を、前記保存工程で保存された前記複数の機器内情報から抽出する情報抽出工程と、
   前記情報抽出工程で抽出された機器内情報と、エラーの発生を示すエラーイベントとを、管理サーバへ送信する送信工程と
   を有することを特徴とする制御方法。
10. 請求項１乃至８のいずれか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。
    
    

Images