画像処理装置及び障害解析プログラム
【課題】履歴情報に基づく障害等の解析精度を向上する。
【解決手段】監視部６８Ａにより副制御部６４の異常状態を検知した場合等、又はユーザーから解析指示がなされた場合に、キャプチャ指示部７６の指示によりＧＵＩ２６に表示されている画面イメージをキャプチャし、画面イメージを取得した時刻と共に、ログデータとしてログ格納部７２へ記録する。
【解決手段】監視部６８Ａにより副制御部６４の異常状態を検知した場合等、又はユーザーから解析指示がなされた場合に、キャプチャ指示部７６の指示によりＧＵＩ２６に表示されている画面イメージをキャプチャし、画面イメージを取得した時刻と共に、ログデータとしてログ格納部７２へ記録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置及び障害解析プログラムに関する。
【背景技術】
【０００２】
最近の画像処理装置は、高度なグラフィカル・ユーザ・インターフェース（ＧＵＩ）を装備している。ユーザーは、このＧＵＩを見ながら所定の操作を行うことにより、各種の処理設定をすることができる。これにより、ユーザーは簡単な操作で多くの機能を利用可能になっている。
【０００３】
このＧＵＩに様々な機能を搭載するとソフトウエアは大規模になり、不具合発生時の現象確認や再現が容易ではない。不具合の解析のためには障害発生のタイミングで情報収集するのが望ましい。特に、基幹系プリンターでは高信頼性が求められ、正確な解析情報の収集が重要となる。
【０００４】
そこで、多くのプリンターにはジョブ記録やシステム状態などを解析情報として収集する機能を搭載している（特許文献１参照）。
【特許文献１】特開２００２−１４９３８０公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述のように、不具合の解析はプリンター上で収集した解析情報に基づいて行うが、しかしＧＵＩソフトウエアの画面表示や操作に関する不具合の場合、文字情報であるログデータのみでは解析情報として不十分なことも多い。これは画面表示される情報が常に変化する上に、グラフィカルな情報を文字のみで表現することが極めて難しいためである。特に再現性に乏しい不具合事例では調査が困難となる可能性が高い。
【０００６】
本発明は、本構成を有しない場合に比べて、履歴情報に基づく障害等の解析精度を向上することができる画像処理装置及び障害解析プログラムを得ることが目的である。
【課題を解決するための手段】
【０００７】
請求項１に記載の発明は、画像処理に関する情報を送受信して視覚的に報知するモニタ画面を備えたユーザーインターフェースモジュールと、画像処理中に発生する特定事象の発生の有無を監視する監視手段と、前記監視手段の監視により、前記特定事象の発生を認識した場合に、前記モニタ画面に表示されているイメージデータを取り込むイメージデータ取込手段と、を有している。
【０００８】
請求項２に記載の発明は、前記請求項１に記載の発明において、画像処理の実行に則して、適宜当該画像処理に関する履歴情報を格納する履歴情報格納手段を更に有し、前記イメージデータ取込手段で取り込んだイメージデータを前記履歴情報格納手段に格納された履歴情報に関連付けて格納する。
【０００９】
請求項３に記載の発明は、前記請求項１又は請求項２に記載の発明において、前記イメージデータ取込手段が、少なくとも時間的制限を含む取込条件の不成立により、イメージデータの取り込みに失敗したとき当該取込処理を中止する。
【００１０】
請求項４に記載の発明は、請求項１〜請求項３の何れか１項記載の発明において、前記特定事象が、画像処理制御系に定常稼働能力負荷以上の負荷が一定期間継続又は累積したときである。
【００１１】
請求項５に記載の発明は、前記請求項１〜請求項３の何れか１項記載の発明において、前記特定事象が、画像処理実行以外の待機中において、画像処理制御系に非稼働能力負荷以上の負荷が継続又は累積したときである。
【００１２】
請求項６に記載の発明は、前記請求項１〜請求項５の何れか１項記載の発明において、前記特定事象が、前記ユーザーインターフェースモジュールの不具合の発生である。
【００１３】
請求項７に記載の発明は、前記請求項６記載の発明において、前記ユーザーインターフェースモジュールの不具合であるが、画像処理を中断又は中止するまでもない事象を、予め特定事象から排除する。
【００１４】
請求項８に記載の発明は、前記請求項１〜請求項７の何れか１項記載の発明において、前記特定事象が、前記ユーザーインターフェースモジュールを用いた画像処理に関する動作が、無反応なときである。
【００１５】
請求項９に記載の発明は、前記請求項１〜請求項８の何れか１項記載の発明において、前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた許容量を超えたときである。
【００１６】
請求項１０に記載の発明は、前記請求項１〜請求項９の何れか１項記載の発明において、前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた変化率を超えたときである。
【００１７】
請求項１１に記載の発明は、前記請求項１〜請求項１０の何れか１項記載の発明において、前記履歴情報格納手段により格納されたイメージデータのデータ量が一定量を超えたとき、前記イメージデータを格納時期が古い順に削除する。
【００１８】
請求項１２に記載の発明は、コンピュータを、請求項１〜請求項１１のいずれか１項記載の画像処理装置として機能させるための障害解析プログラムである。
【発明の効果】
【００１９】
請求項１又は請求項２記載の発明によれば、本構成を有しない場合に比べて、履歴情報に基づく障害等の解析精度を向上することができる
請求項３に記載の発明によれば、本構成を有しない場合に比べて、無駄な処理を省くことができる。
【００２０】
請求項４〜請求項１０に記載の発明によれば、本構成を有しない場合に比べて、適正なタイミングでモニタ画面に表示されているイメージデータを取り込むことができる。
【００２１】
請求項１１に記載の発明によれば、本構成を有しない場合に比べて、記憶容量を有効利用することができる。
【発明を実施するための最良の形態】
【００２２】
（画像処理装置１０の概略構成）
図１には、本実施の形態に係る画像処理装置１０が示されている。画像処理装置１０は、大きく分類して、図１の左側から画像形成部１２、用紙収容部１４、後処理部１６としている。
【００２３】
画像形成部１２は、その筐体１８の上面に当該画像処理装置１０の全体を制御する主制御部２０が設けられている。主制御部２０は、制御部本体２２と、キーボード２４と、マウス２５と、モニタ２７とを備えている。なお、上記キーボード２４、マウス２５の入力系と、モニタ２７の出力系とを総称して「ＧＵＩ２６」という。
【００２４】
また、主制御部２０の図１の右側（画像形成部１２の上面）には、矩形の開口部が設けられている。この開口部には、開閉蓋３２が取り付けられている。
【００２５】
画像形成部１２の筐体１８によって覆われており、前記主制御部２０からの画像データに応じて発光する光ビームを走査する光走査部と、光走査部によって走査された光ビームを受けて所謂静電潜像が形成される感光体ドラムと、感光体ドラム上の静電潜像へトナー等の現像剤を供給することで現像する現像部と、この現像によって顕像化された画像を記録用紙へ転写する転写部と、転写した記録用紙上の画像を定着させる定着部とを備えている。以下、上記一連の工程を、「画像形成処理全般」という。
【００２６】
上記画像形成部１２が収容された筐体１８の図１の前面は、ほぼ全域に亘って開口されており、所謂観音開き型の一対の開閉扉３４が取り付けられている。
【００２７】
このため、画像形成部１２のメンテナンス時には、この一対の開閉扉３４を開放することで、筐体１８の全面とほぼ同一の面積のメンテナンス作業空間が設けられることになる。
【００２８】
この画像形成部１２の転写部へ送られる記録用紙は、前記開閉蓋３２の下部に設けられたトレイ３６、或いは用紙収容部１４に設けられた複数のトレイ３８から選択的に持ち出されるようになっている。すなわち、トレイ３６、３８には、それぞれサイズの異なる記録用紙を収容可能（同一サイズの場合もある）となっており、主制御部２０からの指示に基づく、画像形成部１２からの指示で何れかのトレイ３６、３８が選択され、例えば、最上層の記録用紙から順番に持ち出すようになっている。
【００２９】
用紙収容部１４の上部は、画像形成された記録用紙の搬送部４０となっている。すなわち、画像形成部１２で画像形成された記録用紙は、後処理が必要な場合に、この搬送部４０を経て、後処理部１６へ搬送されるようになっている。なお、後処理が不要な記録用紙は、前記開閉蓋３２の下部に配置された排出トレイユニット４２へ排出されるようになっている。
【００３０】
後処理部１６は、例えば、フィニッシャー部とも称され、製本、綴じ、穴あけ、折り等の加工、並びにジョブ単位、部数単位での仕分け処理を実行する。
【００３１】
（画像処理装置１０の制御系）
図２に示される如く、本実施に形態に係る画像処理装置１０は主制御部２０によって制御されるようになっている。主制御部２０は、制御部本体２２と、入出力装置としてのＧＵＩ２６とを有している。
【００３２】
制御部本体２２は、全ての処理を総括管理する。また、制御部本体２２は、ＣＰＵ４４、ＲＡＭ４６、ＲＯＭ４８、画像データ蓄積メモリ６２、Ｉ／Ｏ（入出力部）５０、及びこれらを接続するデータバスやコントロールバス等のバス５２を有している。Ｉ／Ｏ５０には、ＧＵＩ２６が接続されている。
【００３３】
ＧＵＩ２６には、メニュー選択等の操作画面、各種設定画面や、実行中の画像処理の処理状況を報知する画面を表示するようになっている。ユーザーは、このＧＵＩ２６の表示内容を見ながら、各種指示等を行う。
【００３４】
画像データ蓄積メモリ６２は、ハードディスク等により構成されている。なお、画像データ蓄積メモリ６２はハードディスクに限られるものではなく、外部記憶装置等を用いてもよい。
【００３５】
また、制御部本体２２には、画像形成制御部５６と、搬送制御部５８と、後処理制御部６０とが、それぞれ通信インターフェース（Ｉ／Ｆ）５１を介して接続されている。以下、画像形成制御部５６、搬送制御部５８、後処理制御部６０を総称して「副制御部６４」という。
【００３６】
ユーザーがＧＵＩ２６を用いて入力した指示等は、制御部本体２２へ出力される。一方、制御部本体２２から出力された情報がＧＵＩ２６へ入力され、ＧＵＩ２６に表示されるようになっている。
【００３７】
制御部本体２２は、各種指示を副制御部６４へ適宜出力する。指示が入力された副制御部６４は、指示に基づいて各種画像処理を実行するよう制御する。副制御部６４は、処理状況や処理結果、画像データ等を制御部本体２２へ出力する。
【００３８】
また、制御部本体２２では、副制御部６４からの入力に基づいて、次の画像処理を行う副制御部６４へ指示を出力するようになっている。
【００３９】
さらに、制御部本体２２において、副制御部６４から入力された画像データは、画像データ蓄積メモリ６２へ蓄積される。画像データ蓄積メモリ６２には、画像処理実行中の画像データが蓄積されるようになっている。画像処理の完了と共に、画像データは削除される。
【００４０】
（ログデータ生成、並びにイメージデータ取得制御）
画像処理装置１０は、以上のような構成に基づき、複数の機能を組み合わせることで画像処理を実行している。ここで、画像処理装置１０は、画像処理が完了するまでの生じる事象等、画像処理装置１０で発生する事象について履歴情報（ログ）を記録している。さらに、本実施の形態に係る画像処理装置１０では、ログデータとしてＧＵＩ２６に表示されている画面のイメージデータを記録している。
【００４１】
図３には、本実施の形態に係る画像処理装置１０の機能ブロック図が示されている。なお、この機能ブロック図は、ハード構成を限定するものではなく、あくまでも、機能別に分類したものである。
【００４２】
ユーザーはＧＵＩ２６を用いて、画像形成処理全般等、所望の画像処理指示を入力する。ＧＵＩ２６は、解析部６６に接続されている。解析部６６は、ＧＵＩ２６を介して入力されたユーザーの指示内容を解析する。ユーザーの指示に基づき、指示を実行する各部へ実行命令を出力する。
【００４３】
解析部６６では、例えば、ユーザーによって入力された画像処理指示を解析する。なお、ユーザーの指示の一例として、前記画像処理指示を挙げたにすぎず、その他の各種指示等も含まれ、これに限られるものではない。
【００４４】
解析部６６は、画像処理制御部６８に接続されている。入力された指示が画像処理指示のとき、解析部６６は画像処理制御部６８へ画像処理指示を出力すると共に、画像データ蓄積メモリ６２から画像データを読み出して画像形成制御部５６へ出力する。画像処理制御部６８は、画像形成制御部５６、搬送制御部５８、後処理制御部６０のそれぞれと接続している。画像処理制御部６８は、入力された画像処理指示に基づき、画像形成制御部５６、搬送制御部５８、後処理制御部６０へ選択的に画像処理命令を出力する。
【００４５】
ここで、画像処理制御部６８は、監視部６８Ａを備えている。副制御部６４は、各処理状況や処理結果等の情報を逐次監視部６８Ａへ出力する。具体的には、各処理実行の開始又は終了のような制御情報や、エラー発生時のエラー情報等がある。
【００４６】
監視部６８Ａは、ログ生成部７０に接続されている。監視部６８Ａは、副制御部６４から入力された処理情報を、ログ生成部７０へ出力する。
【００４７】
ログ生成部７０は、監視部６８Ａから処理情報が入力されると、ログデータを生成する。ログデータは、例えば、図４（Ａ）に示す如く、前記制御情報やエラー情報や、発生した時刻の時刻情報等である。
【００４８】
ログ生成部７０はログ格納部７２に接続されている。ログ生成部７０は、生成したログデータをログ格納部７２へ出力する。ログ格納部７２では、ログデータが格納される。なお、ログデータとして記録される情報はこれに限らない。
【００４９】
また、ユーザーは前記ログ格納部７２に格納されたログデータを確認することができる。ＧＵＩ２６から解析部６６を介してログデータ表示指示が入力されると、解析部６６からはログ格納部７２へ当該表示指示が送られる。
【００５０】
ログ格納部７２はＧＵＩ表示制御部７４に接続されている。ログ格納部７２は、入力された表示指示に基づき、ＧＵＩ表示制御部７４へログデータを出力する。ＧＵＩ表示制御部７４は、ＧＵＩ２６を制御してログデータを表示する。多くの場合、ログ格納部７２に保存されたログデータをＭＯやＣＤ−ＲＷなどの外部媒体にコピーして、それを画像形成装置の保守を担当するサポートセンター等に持ち込んで、発生した不具合の原因調査や対策検討を行う。
【００５１】
ところで、ログデータにはエラー情報も含まれているため、エラー発生後におけるエラー解析の情報の一つとしてログデータが用いられる。エラー解析には、エラー発生のタイミングで情報収集することが有効である。また、特に、ＧＵＩモジュールのエラーの場合には、エラー発生時のＧＵＩの表示情報が解析に有効となる。これは、エラー発生時に何がどのように画面表示されていたか、装置を利用していたユーザーの記憶が必ずしも正しいとは限らないためである。解析のためにエラー発生時の状況を後日確認しても、忘却によって必要な情報が得られないか、またはユーザーの誤った記憶によって不正確な情報が伝わり、結果としてむしろ解析に手間取る場合がある。たとえばあるエラーメッセージが画面表示されたときでも、ユーザーや現場担当者などを介した結果、実際とは異なるメッセージが表示されたという情報が伝わってしまうことがある。さらに、ＧＵＩモジュールの障害においては、画面の正確な状態を言葉のみで表現することは、一般的に困難である。そこで、本実施の形態では、図４（Ｂ）、図４（Ｃ）に示される如く、ログデータとしてＧＵＩ２６の表示画面の画面イメージを記録している。エラー発生時の画面イメージがログデータとして記録されているので、エラー解析情報としてログデータが有効な情報となる。
【００５２】
また、エラー発生のタイミングを外さないために、本実施の形態では、監視部６８Ａが副制御部６４の状態を監視するようにしている。副制御部６４の一部の異常であっても、エラーの原因となる可能性がある。そこで、異常状態を検知したタイミングで表示画面をキャプチャしログデータとして記録する。なお、画面キャプチャとは、ＧＵＩ２６に表示されているイメージデータを取り込むことをいう。
【００５３】
図３に示される如く、監視部６８Ａは、副制御部６４からの制御情報やエラー情報等の入力を受け付けながら、副制御部６４に障害を発生させる原因となる「異常」が発生していないかを監視する。
【００５４】
具体的には、副制御部６４のいずれかが長期間高負荷に陥っているときは、何らかのソフトウエア障害が発生している可能性がある。そこで、監視部６８Ａは副制御部６４のいずれかの負荷情報を取得する。
【００５５】
なお、画像処理を実行しているときには、通常、高負荷となるため、高負荷であること自体が障害の発生を示唆している可能性は少ない。そこで、監視部６８Ａは、負荷情報の取得と同時に、副制御部６４から入力された制御情報に基づいて、副制御部６４が画像処理実行中であるか待機中であるかを判断するようにしてもよい。すなわち、副制御部６４が画像処理実行中には、監視部６８Ａは当該副制御部６４の負荷状態の監視を中止する。その結果、監視部６８Ａが、副制御部６４が一定時間高負荷であって、かつ待機中であることを確認したときに、異常状態であると判断する。
【００５６】
また、監視部６８Ａは、ＧＵＩ２６を含むＧＵＩモジュールの不具合を監視する。ＧＵＩモジュールとは、ＧＵＩ２６に情報を表示するＧＵＩ表示制御部７４、このＧＵＩ表示制御部７４に情報を送出するセンサ系等を含む。監視部６８Ａは、ＧＵＩモジュールの不具合の発生を異常状態であると判断する。
【００５７】
なお、ここでいう異常状態とは、ＧＵＩモジュール内部でデータの論理矛盾を検出するなど、システムの不具合に起因する不整合を検出した場合のことを指す。たとえば、ジョブ状態が印刷待ち、印刷中、印刷完了の順に変化するのが正しいのにも関わらず、印刷開始する前のジョブデータに対して印刷完了を意味するイベントを受信した場合などがある。
【００５８】
また、他の異常状態として、あるタイミングでは押せないはずのボタンが、実際には押されたことを検出した場合なども考えられる。たとえば装置を一時停止させるボタンは、既に一時停止中のときには無効な状態にあるのが正しいとする。しかし一時停止中であるにもかかわらずボタンが押されたことを検出した場合、ボタン表示の画面制御に不具合がある可能性がある。ＧＵＩの画面イメージを含むログデータが記録されていると、どのような画面表示が行われていたかを後から正確に知ることができるため、特にＧＵＩモジュールの不具合発生の解析に有効となる。
【００５９】
しかし、システムに実害を及ぼすエラーとなる可能性のない軽微な不具合が既に判明している場合はログデータとして記録しておかなくてもよいため、監視部６８Ａはそのようなエラーを検出して軽微な不具合は異常状態と判断しないようにしてもよい。上記の例でいえば、一時停止中に一時停止ボタンが押されたとしても実害がないことが予め判明しているのであれば、その不具合を検出しても無視するようにできる。
【００６０】
さらに、監視部６８Ａは、画像データ蓄積メモリ６２の画像データ量を監視する。画像データ蓄積メモリ６２には、画像処理実行中の画像データしか蓄積されておらず、画像処理が完了すると削除されるようになっている。すなわち、通常時、画像データ蓄積メモリ６２の画像データは処理の完了と共に削除されるため、蓄積されている画像データ量はある程度の量に収まる。また、副制御部６４が順に画像処理を実行するため、蓄積されている画像データ量の急激な増減はない。
【００６１】
しかし、画像処理は完了したのにデータが削除されなかったり、副制御部６４のひとつが正常に機能しなく画像処理が滞っていたり等のような動作不具合が考えられる。そこで、監視部６８Ａは、画像データ蓄積メモリ６２の画像データ量を監視し、予め定めた許容量を超えたことや、予め定めた所定の変化率を超えたことを確認したときに、異常状態であると判断する。
【００６２】
なお、副制御部６４の異常状態として以上のものを挙げたが、これに限定されるものではなく、後にエラーとなる可能性のある事項を、監視部６８Ａに監視させるようにすることができる。
【００６３】
監視部６８Ａは、副制御部６４の異常状態を検知すると、ログ生成部７０へ警告情報を出力する。ログ生成部７０は、警告情報に基づいてその時の時刻情報と共にログデータを記録する。
【００６４】
（監視部６８Ａの判定による画面キャプチャの場合）
図３に示される如く、監視部６８Ａはキャプチャ指示部７６に接続されている。監視部６８Ａが副制御部６４の異常状態を検知する（ここでは、ＣＰＵの高負荷を検出（図４（Ｂ）参照））。監視部６８Ａは、前記ログ生成部７０への警告情報の出力と共に、キャプチャ指示部７６へキャプチャ指示を出力する。
【００６５】
キャプチャ指示部７６は、ＧＵＩ表示制御部７４と取込実行部７８とに接続されている。キャプチャ指示部７６は、監視部６８Ａからの入力に基づいて、ＧＵＩ表示制御部７４と取込実行部７８とにキャプチャ指示を出力する。
【００６６】
ＧＵＩ表示制御部７４は、ＧＵＩ２６と取込実行部７８とに接続されている。ＧＵＩ表示制御部７４は、キャプチャ指示部７６からのキャプチャ指示に基づき、ＧＵＩ２６に現在表示されている画面イメージを取得する。ＧＵＩ表示制御部７４は、取得した画面イメージを取込実行部７８へ出力する。
【００６７】
取込実行部７８は、ログ生成部７０に接続されている。取込実行部７８は、キャプチャ指示部７６からのキャプチャ指示に基づいて、取得した画面イメージをログ生成部７０へ出力する。ログ生成部７０では、取得した画面イメージと、画面イメージを取得した時刻とを関連付けて、ログデータとして生成する。
【００６８】
ログ生成部７０は、画面イメージが付いたログデータをログ格納部７２へ出力する。ログ格納部７２では、通常のログデータと共に、前記画面イメージが付いたログデータが格納されることとなる（図４（Ｂ）参照）。
【００６９】
なお、ログ格納部７２に格納することができる画面イメージデータの容量を予め定めておき、規定の容量を超えたときに、画面イメージデータの格納時期の古いものから削除するように設定してもよい。設定することで、ログデータの容量が膨大になることなく、ログ格納部７２に格納できる画面イメージデータを一定に保つ。
【００７０】
（ユーザーの指示による画面キャプチャの場合）
監視部６８Ａによる副制御部６４等の監視による場合だけでなく、画像処理装置１０上で何らかの動作不具合が発生したことにユーザーが気付いたとき等、ユーザーの指示に基づいて画面キャプチャを含む解析情報を収集するようになっている。
【００７１】
ユーザーは、ＧＵＩ２６を用いて解析情報収集指示を入力する。指示は解析部６６へ入力され、指示内容を解析される。解析部６６は、キャプチャ指示部７６に接続されている。解析部６６は、指示内容に基づいてキャプチャ指示部７６へキャプチャ指示命令を出力する。
【００７２】
キャプチャ指示部７６へキャプチャ指示が入力されると、前記監視部６８Ａによる画面キャプチャの場合と同様に、画面イメージが取得され、ログデータとしてログ格納部７２へ格納される（図４（Ｃ）参照）。
【００７３】
なお、このときログデータには、ユーザーから解析情報収集指示がなされたことも記録される（図４（Ｃ）参照）。
【００７４】
（画面キャプチャ中止）
監視部６８Ａ又はユーザーからの指示により、キャプチャ指示部７６へキャプチャ指示がなされた場合において、何らかの原因により画面キャプチャが不可能となることがある。例えば、画面を司るＯＳソフトウエア、デバイスドライバやハードウエアが何らかの原因で停止していることが挙げられる。これらの原因により、画面キャプチャ自体が不可能となることが多い。
【００７５】
図３に示される如く、キャプチャ指示部７６のキャプチャ指示に基づき、ＧＵＩ表示制御部７４から取込実行部７８が画面イメージを取得する。
【００７６】
この場合において、取込実行部７８が画面イメージの取得に失敗したとき、監視部６８Ａは画面キャプチャの中止指示をキャプチャ指示部７６へ出力する。キャプチャ指示部７６は、中止指示を取込実行部７８へ出力し、画面キャプチャは中止される。
【００７７】
監視部６８Ａによる画面キャプチャの中止判断条件としては、例えば、キャプチャ指示部７６がＧＵＩ表示制御部７４へキャプチャ指示を出力した回数をカウントし、所定回数を超えたことや、キャプチャ指示部７６が最初にキャプチャ指示を出力してから所定時間経過したこと等がある。
【００７８】
なお、画面キャプチャの中止についても、ログデータとして記録される。
【００７９】
以下に本実施の形態の作用を図５の画面キャプチャの実行を示すフローチャートに従い説明する。
【００８０】
ステップ１００において、キャプチャ条件監視制御を行い、ステップ１０２へ移行する。なお、ステップ１００のキャプチャ条件監視制御については、図６を用いて後述する。
【００８１】
ステップ１０２では、フラグＦ＝１であるか否かを判定する。このフラグＦは、図６の処理によって決まるものである。ステップ１０２において肯定判定の場合（Ｆ＝１）、キャプチャ条件が成立しているため、ステップ１０４へ移行する。一方、ステップ１０２で否定判定の場合（Ｆ＝０）、キャプチャ条件が不成立であり、画面キャプチャの時期ではないのでこのルーチンは終了する。
【００８２】
次のステップ１０４では、キャプチャ指示部７６により画面キャプチャが指示され、ステップ１０６へ移行する。
【００８３】
ステップ１０６では、取込実行部７８が画面イメージを取得したか否かが判定される。ステップ１０６において、肯定判定されると（画面イメージ取得）ステップ１０８へ移行し、否定判定されると（画面イメージ未取得）ステップ１１０へ移行する。
【００８４】
次のステップ１０８では、画面イメージの取得が完了しているので、ログ生成部７０には取得した画面イメージを取得時刻と共にログデータとしてログ格納部７２へ格納する。
【００８５】
一方、ステップ１１０では、画面イメージを取得していないので、キャプチャ指示部７６が最初に指示を出力してから所定時間経過したか否かを判定する。ステップ１１０で肯定判定されると（所定時間経過）ステップ１１２へ移行する。一方、ステップ１１０で否定判定されると（所定時間未経過）ステップ１０６へ戻る。
【００８６】
ステップ１１２では、画面キャプチャが不可能な場合であるので、監視部６８Ａにより画面キャプチャの中止指示がなされる。
【００８７】
図６は、前述の図５のフローチャートで説明したキャプチャ条件監視制御（ステップ１００）を示すフローチャートである。
【００８８】
ステップ２００では、初期状態としてフラグＦ＝０が設定される。
【００８９】
ステップ２０２では、ユーザーからキャプチャ指示が入力されたか否かが判定される。ステップ２０２で肯定判定の場合（ユーザーによるキャプチャ指示）、ステップ２１４へ移行する。
【００９０】
一方、ステップ２０２で否定判定の場合（ユーザーから未指示）、ステップ２０４へ移行する。以後、画面キャプチャをすべき異常状態であるか否かの判定へと進む。
【００９１】
次のステップ２０４では、監視部６８Ａにより、副制御部６４のいずれかが高負荷であるか否かが判定される。ステップ２０４で肯定判定されると（高負荷）、副制御部６４のいずれかが異常状態である可能性があるとしてステップ２０６へ移行する。
【００９２】
一方、ステップ２０４で否定判定されると（高負荷ではない）、副制御部６４の異常状態ではないためステップ２０８へ移行する。
【００９３】
次のステップ２０６では、高負荷である副制御部６４が待機中であるか否かが判定される。ステップ２０６で肯定判定されると（待機中）、副制御部６４の異常状態と判断できステップ２１４へ移行する。
【００９４】
一方、ステップ２０６で否定判定されると（画像処理中）、画像処理実行による通常の高負荷状態であるので副制御部６４の異常状態ではない。このため、ステップ２０８へ移行する。
【００９５】
ステップ２０８では、ＧＵＩモジュールに不具合が発生しているか否かが判定される。ステップ２０８で肯定判定の場合（不具合発生）、ステップ２１４へ移行する。なお、ＧＵＩモジュールの不具合として軽微な不具合は除かれる。
【００９６】
一方、ステップ２０８で否定判定の場合（不具合の不発生又は軽微な不具合の発生）、ステップ２１０へ移行する。
【００９７】
ステップ２１０では、画像データ蓄積メモリ６２のデータ量が許容量を超えたか否かが判定される。ステップ２１０で肯定判定されると（許容量を超えた）、画像処理が正常に行われていないため、ステップ２１４へ移行する。一方、ステップ２１０で否定判定されると（許容量以下）、ステップ２１２へ移行する。
【００９８】
ステップ２１２では、画像データ蓄積メモリ６２のデータ量の変化率が所定の変化率を超えたか否かが判定される。ステップ２１２で肯定判定されると（所定の変化率を超えた）、前記ステップ２１０での肯定判定と同様に、画像処理の異常なので、ステップ２１４へ移行する。
【００９９】
一方、ステップ２１２で否定判定されると（所定の変化率以内）、キャプチャ条件が成立しなかったこととなり、画面キャプチャすべき場合ではないのでこのルーチンは終了する。
【０１００】
ステップ２１４では、キャプチャ条件が成立したこととなる。従って、Ｆ＝１に設定され、このルーチンは終了する。
【０１０１】
なお、本実施の形態では、取得した画面イメージと取得時刻とを一つのログデータとしてログ格納部７２に格納したが、画面イメージと取得時刻とからなるログデータは、通常のログデータとは別途格納するようにしてもよい。
【図面の簡単な説明】
【０１０２】
【図１】本実施の形態に係る画像処理装置を示す全体概要図である。
【図２】本実施に形態に係る画像処理装置のハード構成を示す図である。
【図３】本実施の形態に係る画像処理装置の機能ブロック図である。
【図４】本実施の形態に係るログデータの一例を示す図である。
【図５】本実施の形態に係る画面キャプチャの実行を示すフローチャートである。
【図６】本実施の形態に係るキャプチャ条件成立を判定するフローチャートである。
【符号の説明】
【０１０３】
１０ 画像処理装置
１２ 画像形成部
１４ 用紙収容部
１６ 後処理部
１８ 筐体
２０ 主制御部
２２ 制御部本体
２４ キーボード（ユーザーインターフェースモジュール）
２５ マウス（ユーザーインターフェースモジュール）
２６ ＧＵＩ（ユーザーインターフェースモジュール）
２７ モニタ（ユーザーインターフェースモジュール）
３２ 開閉蓋
３４ 開閉扉
３６ トレイ
３８ 複数のトレイ
４０ 搬送部
４２ 排出トレイユニット
４４ ＣＰＵ
４６ ＲＡＭ
４８ ＲＯＭ
５０ Ｉ／Ｏ
５１ Ｉ／Ｆ
５２ バス
５６ 画像形成制御部
５８ 搬送制御部
６０ 後処理制御部
６２ 画像データ蓄積メモリ
６４ 副制御部
６６ 解析部（監視手段）
６８ 画像処理制御部
６８Ａ 監視部（監視手段）
７０ ログ生成部（履歴情報格納手段）
７２ ログ格納部（履歴情報格納手段）
７４ ＧＵＩ表示制御部（ユーザーインターフェースモジュール、イメージデータ取込手段）
７６ キャプチャ指示部（イメージデータ取込手段）
７８ 取込実行部（イメージデータ取込手段）
【技術分野】
【０００１】
本発明は、画像処理装置及び障害解析プログラムに関する。
【背景技術】
【０００２】
最近の画像処理装置は、高度なグラフィカル・ユーザ・インターフェース（ＧＵＩ）を装備している。ユーザーは、このＧＵＩを見ながら所定の操作を行うことにより、各種の処理設定をすることができる。これにより、ユーザーは簡単な操作で多くの機能を利用可能になっている。
【０００３】
このＧＵＩに様々な機能を搭載するとソフトウエアは大規模になり、不具合発生時の現象確認や再現が容易ではない。不具合の解析のためには障害発生のタイミングで情報収集するのが望ましい。特に、基幹系プリンターでは高信頼性が求められ、正確な解析情報の収集が重要となる。
【０００４】
そこで、多くのプリンターにはジョブ記録やシステム状態などを解析情報として収集する機能を搭載している（特許文献１参照）。
【特許文献１】特開２００２−１４９３８０公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述のように、不具合の解析はプリンター上で収集した解析情報に基づいて行うが、しかしＧＵＩソフトウエアの画面表示や操作に関する不具合の場合、文字情報であるログデータのみでは解析情報として不十分なことも多い。これは画面表示される情報が常に変化する上に、グラフィカルな情報を文字のみで表現することが極めて難しいためである。特に再現性に乏しい不具合事例では調査が困難となる可能性が高い。
【０００６】
本発明は、本構成を有しない場合に比べて、履歴情報に基づく障害等の解析精度を向上することができる画像処理装置及び障害解析プログラムを得ることが目的である。
【課題を解決するための手段】
【０００７】
請求項１に記載の発明は、画像処理に関する情報を送受信して視覚的に報知するモニタ画面を備えたユーザーインターフェースモジュールと、画像処理中に発生する特定事象の発生の有無を監視する監視手段と、前記監視手段の監視により、前記特定事象の発生を認識した場合に、前記モニタ画面に表示されているイメージデータを取り込むイメージデータ取込手段と、を有している。
【０００８】
請求項２に記載の発明は、前記請求項１に記載の発明において、画像処理の実行に則して、適宜当該画像処理に関する履歴情報を格納する履歴情報格納手段を更に有し、前記イメージデータ取込手段で取り込んだイメージデータを前記履歴情報格納手段に格納された履歴情報に関連付けて格納する。
【０００９】
請求項３に記載の発明は、前記請求項１又は請求項２に記載の発明において、前記イメージデータ取込手段が、少なくとも時間的制限を含む取込条件の不成立により、イメージデータの取り込みに失敗したとき当該取込処理を中止する。
【００１０】
請求項４に記載の発明は、請求項１〜請求項３の何れか１項記載の発明において、前記特定事象が、画像処理制御系に定常稼働能力負荷以上の負荷が一定期間継続又は累積したときである。
【００１１】
請求項５に記載の発明は、前記請求項１〜請求項３の何れか１項記載の発明において、前記特定事象が、画像処理実行以外の待機中において、画像処理制御系に非稼働能力負荷以上の負荷が継続又は累積したときである。
【００１２】
請求項６に記載の発明は、前記請求項１〜請求項５の何れか１項記載の発明において、前記特定事象が、前記ユーザーインターフェースモジュールの不具合の発生である。
【００１３】
請求項７に記載の発明は、前記請求項６記載の発明において、前記ユーザーインターフェースモジュールの不具合であるが、画像処理を中断又は中止するまでもない事象を、予め特定事象から排除する。
【００１４】
請求項８に記載の発明は、前記請求項１〜請求項７の何れか１項記載の発明において、前記特定事象が、前記ユーザーインターフェースモジュールを用いた画像処理に関する動作が、無反応なときである。
【００１５】
請求項９に記載の発明は、前記請求項１〜請求項８の何れか１項記載の発明において、前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた許容量を超えたときである。
【００１６】
請求項１０に記載の発明は、前記請求項１〜請求項９の何れか１項記載の発明において、前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた変化率を超えたときである。
【００１７】
請求項１１に記載の発明は、前記請求項１〜請求項１０の何れか１項記載の発明において、前記履歴情報格納手段により格納されたイメージデータのデータ量が一定量を超えたとき、前記イメージデータを格納時期が古い順に削除する。
【００１８】
請求項１２に記載の発明は、コンピュータを、請求項１〜請求項１１のいずれか１項記載の画像処理装置として機能させるための障害解析プログラムである。
【発明の効果】
【００１９】
請求項１又は請求項２記載の発明によれば、本構成を有しない場合に比べて、履歴情報に基づく障害等の解析精度を向上することができる
請求項３に記載の発明によれば、本構成を有しない場合に比べて、無駄な処理を省くことができる。
【００２０】
請求項４〜請求項１０に記載の発明によれば、本構成を有しない場合に比べて、適正なタイミングでモニタ画面に表示されているイメージデータを取り込むことができる。
【００２１】
請求項１１に記載の発明によれば、本構成を有しない場合に比べて、記憶容量を有効利用することができる。
【発明を実施するための最良の形態】
【００２２】
（画像処理装置１０の概略構成）
図１には、本実施の形態に係る画像処理装置１０が示されている。画像処理装置１０は、大きく分類して、図１の左側から画像形成部１２、用紙収容部１４、後処理部１６としている。
【００２３】
画像形成部１２は、その筐体１８の上面に当該画像処理装置１０の全体を制御する主制御部２０が設けられている。主制御部２０は、制御部本体２２と、キーボード２４と、マウス２５と、モニタ２７とを備えている。なお、上記キーボード２４、マウス２５の入力系と、モニタ２７の出力系とを総称して「ＧＵＩ２６」という。
【００２４】
また、主制御部２０の図１の右側（画像形成部１２の上面）には、矩形の開口部が設けられている。この開口部には、開閉蓋３２が取り付けられている。
【００２５】
画像形成部１２の筐体１８によって覆われており、前記主制御部２０からの画像データに応じて発光する光ビームを走査する光走査部と、光走査部によって走査された光ビームを受けて所謂静電潜像が形成される感光体ドラムと、感光体ドラム上の静電潜像へトナー等の現像剤を供給することで現像する現像部と、この現像によって顕像化された画像を記録用紙へ転写する転写部と、転写した記録用紙上の画像を定着させる定着部とを備えている。以下、上記一連の工程を、「画像形成処理全般」という。
【００２６】
上記画像形成部１２が収容された筐体１８の図１の前面は、ほぼ全域に亘って開口されており、所謂観音開き型の一対の開閉扉３４が取り付けられている。
【００２７】
このため、画像形成部１２のメンテナンス時には、この一対の開閉扉３４を開放することで、筐体１８の全面とほぼ同一の面積のメンテナンス作業空間が設けられることになる。
【００２８】
この画像形成部１２の転写部へ送られる記録用紙は、前記開閉蓋３２の下部に設けられたトレイ３６、或いは用紙収容部１４に設けられた複数のトレイ３８から選択的に持ち出されるようになっている。すなわち、トレイ３６、３８には、それぞれサイズの異なる記録用紙を収容可能（同一サイズの場合もある）となっており、主制御部２０からの指示に基づく、画像形成部１２からの指示で何れかのトレイ３６、３８が選択され、例えば、最上層の記録用紙から順番に持ち出すようになっている。
【００２９】
用紙収容部１４の上部は、画像形成された記録用紙の搬送部４０となっている。すなわち、画像形成部１２で画像形成された記録用紙は、後処理が必要な場合に、この搬送部４０を経て、後処理部１６へ搬送されるようになっている。なお、後処理が不要な記録用紙は、前記開閉蓋３２の下部に配置された排出トレイユニット４２へ排出されるようになっている。
【００３０】
後処理部１６は、例えば、フィニッシャー部とも称され、製本、綴じ、穴あけ、折り等の加工、並びにジョブ単位、部数単位での仕分け処理を実行する。
【００３１】
（画像処理装置１０の制御系）
図２に示される如く、本実施に形態に係る画像処理装置１０は主制御部２０によって制御されるようになっている。主制御部２０は、制御部本体２２と、入出力装置としてのＧＵＩ２６とを有している。
【００３２】
制御部本体２２は、全ての処理を総括管理する。また、制御部本体２２は、ＣＰＵ４４、ＲＡＭ４６、ＲＯＭ４８、画像データ蓄積メモリ６２、Ｉ／Ｏ（入出力部）５０、及びこれらを接続するデータバスやコントロールバス等のバス５２を有している。Ｉ／Ｏ５０には、ＧＵＩ２６が接続されている。
【００３３】
ＧＵＩ２６には、メニュー選択等の操作画面、各種設定画面や、実行中の画像処理の処理状況を報知する画面を表示するようになっている。ユーザーは、このＧＵＩ２６の表示内容を見ながら、各種指示等を行う。
【００３４】
画像データ蓄積メモリ６２は、ハードディスク等により構成されている。なお、画像データ蓄積メモリ６２はハードディスクに限られるものではなく、外部記憶装置等を用いてもよい。
【００３５】
また、制御部本体２２には、画像形成制御部５６と、搬送制御部５８と、後処理制御部６０とが、それぞれ通信インターフェース（Ｉ／Ｆ）５１を介して接続されている。以下、画像形成制御部５６、搬送制御部５８、後処理制御部６０を総称して「副制御部６４」という。
【００３６】
ユーザーがＧＵＩ２６を用いて入力した指示等は、制御部本体２２へ出力される。一方、制御部本体２２から出力された情報がＧＵＩ２６へ入力され、ＧＵＩ２６に表示されるようになっている。
【００３７】
制御部本体２２は、各種指示を副制御部６４へ適宜出力する。指示が入力された副制御部６４は、指示に基づいて各種画像処理を実行するよう制御する。副制御部６４は、処理状況や処理結果、画像データ等を制御部本体２２へ出力する。
【００３８】
また、制御部本体２２では、副制御部６４からの入力に基づいて、次の画像処理を行う副制御部６４へ指示を出力するようになっている。
【００３９】
さらに、制御部本体２２において、副制御部６４から入力された画像データは、画像データ蓄積メモリ６２へ蓄積される。画像データ蓄積メモリ６２には、画像処理実行中の画像データが蓄積されるようになっている。画像処理の完了と共に、画像データは削除される。
【００４０】
（ログデータ生成、並びにイメージデータ取得制御）
画像処理装置１０は、以上のような構成に基づき、複数の機能を組み合わせることで画像処理を実行している。ここで、画像処理装置１０は、画像処理が完了するまでの生じる事象等、画像処理装置１０で発生する事象について履歴情報（ログ）を記録している。さらに、本実施の形態に係る画像処理装置１０では、ログデータとしてＧＵＩ２６に表示されている画面のイメージデータを記録している。
【００４１】
図３には、本実施の形態に係る画像処理装置１０の機能ブロック図が示されている。なお、この機能ブロック図は、ハード構成を限定するものではなく、あくまでも、機能別に分類したものである。
【００４２】
ユーザーはＧＵＩ２６を用いて、画像形成処理全般等、所望の画像処理指示を入力する。ＧＵＩ２６は、解析部６６に接続されている。解析部６６は、ＧＵＩ２６を介して入力されたユーザーの指示内容を解析する。ユーザーの指示に基づき、指示を実行する各部へ実行命令を出力する。
【００４３】
解析部６６では、例えば、ユーザーによって入力された画像処理指示を解析する。なお、ユーザーの指示の一例として、前記画像処理指示を挙げたにすぎず、その他の各種指示等も含まれ、これに限られるものではない。
【００４４】
解析部６６は、画像処理制御部６８に接続されている。入力された指示が画像処理指示のとき、解析部６６は画像処理制御部６８へ画像処理指示を出力すると共に、画像データ蓄積メモリ６２から画像データを読み出して画像形成制御部５６へ出力する。画像処理制御部６８は、画像形成制御部５６、搬送制御部５８、後処理制御部６０のそれぞれと接続している。画像処理制御部６８は、入力された画像処理指示に基づき、画像形成制御部５６、搬送制御部５８、後処理制御部６０へ選択的に画像処理命令を出力する。
【００４５】
ここで、画像処理制御部６８は、監視部６８Ａを備えている。副制御部６４は、各処理状況や処理結果等の情報を逐次監視部６８Ａへ出力する。具体的には、各処理実行の開始又は終了のような制御情報や、エラー発生時のエラー情報等がある。
【００４６】
監視部６８Ａは、ログ生成部７０に接続されている。監視部６８Ａは、副制御部６４から入力された処理情報を、ログ生成部７０へ出力する。
【００４７】
ログ生成部７０は、監視部６８Ａから処理情報が入力されると、ログデータを生成する。ログデータは、例えば、図４（Ａ）に示す如く、前記制御情報やエラー情報や、発生した時刻の時刻情報等である。
【００４８】
ログ生成部７０はログ格納部７２に接続されている。ログ生成部７０は、生成したログデータをログ格納部７２へ出力する。ログ格納部７２では、ログデータが格納される。なお、ログデータとして記録される情報はこれに限らない。
【００４９】
また、ユーザーは前記ログ格納部７２に格納されたログデータを確認することができる。ＧＵＩ２６から解析部６６を介してログデータ表示指示が入力されると、解析部６６からはログ格納部７２へ当該表示指示が送られる。
【００５０】
ログ格納部７２はＧＵＩ表示制御部７４に接続されている。ログ格納部７２は、入力された表示指示に基づき、ＧＵＩ表示制御部７４へログデータを出力する。ＧＵＩ表示制御部７４は、ＧＵＩ２６を制御してログデータを表示する。多くの場合、ログ格納部７２に保存されたログデータをＭＯやＣＤ−ＲＷなどの外部媒体にコピーして、それを画像形成装置の保守を担当するサポートセンター等に持ち込んで、発生した不具合の原因調査や対策検討を行う。
【００５１】
ところで、ログデータにはエラー情報も含まれているため、エラー発生後におけるエラー解析の情報の一つとしてログデータが用いられる。エラー解析には、エラー発生のタイミングで情報収集することが有効である。また、特に、ＧＵＩモジュールのエラーの場合には、エラー発生時のＧＵＩの表示情報が解析に有効となる。これは、エラー発生時に何がどのように画面表示されていたか、装置を利用していたユーザーの記憶が必ずしも正しいとは限らないためである。解析のためにエラー発生時の状況を後日確認しても、忘却によって必要な情報が得られないか、またはユーザーの誤った記憶によって不正確な情報が伝わり、結果としてむしろ解析に手間取る場合がある。たとえばあるエラーメッセージが画面表示されたときでも、ユーザーや現場担当者などを介した結果、実際とは異なるメッセージが表示されたという情報が伝わってしまうことがある。さらに、ＧＵＩモジュールの障害においては、画面の正確な状態を言葉のみで表現することは、一般的に困難である。そこで、本実施の形態では、図４（Ｂ）、図４（Ｃ）に示される如く、ログデータとしてＧＵＩ２６の表示画面の画面イメージを記録している。エラー発生時の画面イメージがログデータとして記録されているので、エラー解析情報としてログデータが有効な情報となる。
【００５２】
また、エラー発生のタイミングを外さないために、本実施の形態では、監視部６８Ａが副制御部６４の状態を監視するようにしている。副制御部６４の一部の異常であっても、エラーの原因となる可能性がある。そこで、異常状態を検知したタイミングで表示画面をキャプチャしログデータとして記録する。なお、画面キャプチャとは、ＧＵＩ２６に表示されているイメージデータを取り込むことをいう。
【００５３】
図３に示される如く、監視部６８Ａは、副制御部６４からの制御情報やエラー情報等の入力を受け付けながら、副制御部６４に障害を発生させる原因となる「異常」が発生していないかを監視する。
【００５４】
具体的には、副制御部６４のいずれかが長期間高負荷に陥っているときは、何らかのソフトウエア障害が発生している可能性がある。そこで、監視部６８Ａは副制御部６４のいずれかの負荷情報を取得する。
【００５５】
なお、画像処理を実行しているときには、通常、高負荷となるため、高負荷であること自体が障害の発生を示唆している可能性は少ない。そこで、監視部６８Ａは、負荷情報の取得と同時に、副制御部６４から入力された制御情報に基づいて、副制御部６４が画像処理実行中であるか待機中であるかを判断するようにしてもよい。すなわち、副制御部６４が画像処理実行中には、監視部６８Ａは当該副制御部６４の負荷状態の監視を中止する。その結果、監視部６８Ａが、副制御部６４が一定時間高負荷であって、かつ待機中であることを確認したときに、異常状態であると判断する。
【００５６】
また、監視部６８Ａは、ＧＵＩ２６を含むＧＵＩモジュールの不具合を監視する。ＧＵＩモジュールとは、ＧＵＩ２６に情報を表示するＧＵＩ表示制御部７４、このＧＵＩ表示制御部７４に情報を送出するセンサ系等を含む。監視部６８Ａは、ＧＵＩモジュールの不具合の発生を異常状態であると判断する。
【００５７】
なお、ここでいう異常状態とは、ＧＵＩモジュール内部でデータの論理矛盾を検出するなど、システムの不具合に起因する不整合を検出した場合のことを指す。たとえば、ジョブ状態が印刷待ち、印刷中、印刷完了の順に変化するのが正しいのにも関わらず、印刷開始する前のジョブデータに対して印刷完了を意味するイベントを受信した場合などがある。
【００５８】
また、他の異常状態として、あるタイミングでは押せないはずのボタンが、実際には押されたことを検出した場合なども考えられる。たとえば装置を一時停止させるボタンは、既に一時停止中のときには無効な状態にあるのが正しいとする。しかし一時停止中であるにもかかわらずボタンが押されたことを検出した場合、ボタン表示の画面制御に不具合がある可能性がある。ＧＵＩの画面イメージを含むログデータが記録されていると、どのような画面表示が行われていたかを後から正確に知ることができるため、特にＧＵＩモジュールの不具合発生の解析に有効となる。
【００５９】
しかし、システムに実害を及ぼすエラーとなる可能性のない軽微な不具合が既に判明している場合はログデータとして記録しておかなくてもよいため、監視部６８Ａはそのようなエラーを検出して軽微な不具合は異常状態と判断しないようにしてもよい。上記の例でいえば、一時停止中に一時停止ボタンが押されたとしても実害がないことが予め判明しているのであれば、その不具合を検出しても無視するようにできる。
【００６０】
さらに、監視部６８Ａは、画像データ蓄積メモリ６２の画像データ量を監視する。画像データ蓄積メモリ６２には、画像処理実行中の画像データしか蓄積されておらず、画像処理が完了すると削除されるようになっている。すなわち、通常時、画像データ蓄積メモリ６２の画像データは処理の完了と共に削除されるため、蓄積されている画像データ量はある程度の量に収まる。また、副制御部６４が順に画像処理を実行するため、蓄積されている画像データ量の急激な増減はない。
【００６１】
しかし、画像処理は完了したのにデータが削除されなかったり、副制御部６４のひとつが正常に機能しなく画像処理が滞っていたり等のような動作不具合が考えられる。そこで、監視部６８Ａは、画像データ蓄積メモリ６２の画像データ量を監視し、予め定めた許容量を超えたことや、予め定めた所定の変化率を超えたことを確認したときに、異常状態であると判断する。
【００６２】
なお、副制御部６４の異常状態として以上のものを挙げたが、これに限定されるものではなく、後にエラーとなる可能性のある事項を、監視部６８Ａに監視させるようにすることができる。
【００６３】
監視部６８Ａは、副制御部６４の異常状態を検知すると、ログ生成部７０へ警告情報を出力する。ログ生成部７０は、警告情報に基づいてその時の時刻情報と共にログデータを記録する。
【００６４】
（監視部６８Ａの判定による画面キャプチャの場合）
図３に示される如く、監視部６８Ａはキャプチャ指示部７６に接続されている。監視部６８Ａが副制御部６４の異常状態を検知する（ここでは、ＣＰＵの高負荷を検出（図４（Ｂ）参照））。監視部６８Ａは、前記ログ生成部７０への警告情報の出力と共に、キャプチャ指示部７６へキャプチャ指示を出力する。
【００６５】
キャプチャ指示部７６は、ＧＵＩ表示制御部７４と取込実行部７８とに接続されている。キャプチャ指示部７６は、監視部６８Ａからの入力に基づいて、ＧＵＩ表示制御部７４と取込実行部７８とにキャプチャ指示を出力する。
【００６６】
ＧＵＩ表示制御部７４は、ＧＵＩ２６と取込実行部７８とに接続されている。ＧＵＩ表示制御部７４は、キャプチャ指示部７６からのキャプチャ指示に基づき、ＧＵＩ２６に現在表示されている画面イメージを取得する。ＧＵＩ表示制御部７４は、取得した画面イメージを取込実行部７８へ出力する。
【００６７】
取込実行部７８は、ログ生成部７０に接続されている。取込実行部７８は、キャプチャ指示部７６からのキャプチャ指示に基づいて、取得した画面イメージをログ生成部７０へ出力する。ログ生成部７０では、取得した画面イメージと、画面イメージを取得した時刻とを関連付けて、ログデータとして生成する。
【００６８】
ログ生成部７０は、画面イメージが付いたログデータをログ格納部７２へ出力する。ログ格納部７２では、通常のログデータと共に、前記画面イメージが付いたログデータが格納されることとなる（図４（Ｂ）参照）。
【００６９】
なお、ログ格納部７２に格納することができる画面イメージデータの容量を予め定めておき、規定の容量を超えたときに、画面イメージデータの格納時期の古いものから削除するように設定してもよい。設定することで、ログデータの容量が膨大になることなく、ログ格納部７２に格納できる画面イメージデータを一定に保つ。
【００７０】
（ユーザーの指示による画面キャプチャの場合）
監視部６８Ａによる副制御部６４等の監視による場合だけでなく、画像処理装置１０上で何らかの動作不具合が発生したことにユーザーが気付いたとき等、ユーザーの指示に基づいて画面キャプチャを含む解析情報を収集するようになっている。
【００７１】
ユーザーは、ＧＵＩ２６を用いて解析情報収集指示を入力する。指示は解析部６６へ入力され、指示内容を解析される。解析部６６は、キャプチャ指示部７６に接続されている。解析部６６は、指示内容に基づいてキャプチャ指示部７６へキャプチャ指示命令を出力する。
【００７２】
キャプチャ指示部７６へキャプチャ指示が入力されると、前記監視部６８Ａによる画面キャプチャの場合と同様に、画面イメージが取得され、ログデータとしてログ格納部７２へ格納される（図４（Ｃ）参照）。
【００７３】
なお、このときログデータには、ユーザーから解析情報収集指示がなされたことも記録される（図４（Ｃ）参照）。
【００７４】
（画面キャプチャ中止）
監視部６８Ａ又はユーザーからの指示により、キャプチャ指示部７６へキャプチャ指示がなされた場合において、何らかの原因により画面キャプチャが不可能となることがある。例えば、画面を司るＯＳソフトウエア、デバイスドライバやハードウエアが何らかの原因で停止していることが挙げられる。これらの原因により、画面キャプチャ自体が不可能となることが多い。
【００７５】
図３に示される如く、キャプチャ指示部７６のキャプチャ指示に基づき、ＧＵＩ表示制御部７４から取込実行部７８が画面イメージを取得する。
【００７６】
この場合において、取込実行部７８が画面イメージの取得に失敗したとき、監視部６８Ａは画面キャプチャの中止指示をキャプチャ指示部７６へ出力する。キャプチャ指示部７６は、中止指示を取込実行部７８へ出力し、画面キャプチャは中止される。
【００７７】
監視部６８Ａによる画面キャプチャの中止判断条件としては、例えば、キャプチャ指示部７６がＧＵＩ表示制御部７４へキャプチャ指示を出力した回数をカウントし、所定回数を超えたことや、キャプチャ指示部７６が最初にキャプチャ指示を出力してから所定時間経過したこと等がある。
【００７８】
なお、画面キャプチャの中止についても、ログデータとして記録される。
【００７９】
以下に本実施の形態の作用を図５の画面キャプチャの実行を示すフローチャートに従い説明する。
【００８０】
ステップ１００において、キャプチャ条件監視制御を行い、ステップ１０２へ移行する。なお、ステップ１００のキャプチャ条件監視制御については、図６を用いて後述する。
【００８１】
ステップ１０２では、フラグＦ＝１であるか否かを判定する。このフラグＦは、図６の処理によって決まるものである。ステップ１０２において肯定判定の場合（Ｆ＝１）、キャプチャ条件が成立しているため、ステップ１０４へ移行する。一方、ステップ１０２で否定判定の場合（Ｆ＝０）、キャプチャ条件が不成立であり、画面キャプチャの時期ではないのでこのルーチンは終了する。
【００８２】
次のステップ１０４では、キャプチャ指示部７６により画面キャプチャが指示され、ステップ１０６へ移行する。
【００８３】
ステップ１０６では、取込実行部７８が画面イメージを取得したか否かが判定される。ステップ１０６において、肯定判定されると（画面イメージ取得）ステップ１０８へ移行し、否定判定されると（画面イメージ未取得）ステップ１１０へ移行する。
【００８４】
次のステップ１０８では、画面イメージの取得が完了しているので、ログ生成部７０には取得した画面イメージを取得時刻と共にログデータとしてログ格納部７２へ格納する。
【００８５】
一方、ステップ１１０では、画面イメージを取得していないので、キャプチャ指示部７６が最初に指示を出力してから所定時間経過したか否かを判定する。ステップ１１０で肯定判定されると（所定時間経過）ステップ１１２へ移行する。一方、ステップ１１０で否定判定されると（所定時間未経過）ステップ１０６へ戻る。
【００８６】
ステップ１１２では、画面キャプチャが不可能な場合であるので、監視部６８Ａにより画面キャプチャの中止指示がなされる。
【００８７】
図６は、前述の図５のフローチャートで説明したキャプチャ条件監視制御（ステップ１００）を示すフローチャートである。
【００８８】
ステップ２００では、初期状態としてフラグＦ＝０が設定される。
【００８９】
ステップ２０２では、ユーザーからキャプチャ指示が入力されたか否かが判定される。ステップ２０２で肯定判定の場合（ユーザーによるキャプチャ指示）、ステップ２１４へ移行する。
【００９０】
一方、ステップ２０２で否定判定の場合（ユーザーから未指示）、ステップ２０４へ移行する。以後、画面キャプチャをすべき異常状態であるか否かの判定へと進む。
【００９１】
次のステップ２０４では、監視部６８Ａにより、副制御部６４のいずれかが高負荷であるか否かが判定される。ステップ２０４で肯定判定されると（高負荷）、副制御部６４のいずれかが異常状態である可能性があるとしてステップ２０６へ移行する。
【００９２】
一方、ステップ２０４で否定判定されると（高負荷ではない）、副制御部６４の異常状態ではないためステップ２０８へ移行する。
【００９３】
次のステップ２０６では、高負荷である副制御部６４が待機中であるか否かが判定される。ステップ２０６で肯定判定されると（待機中）、副制御部６４の異常状態と判断できステップ２１４へ移行する。
【００９４】
一方、ステップ２０６で否定判定されると（画像処理中）、画像処理実行による通常の高負荷状態であるので副制御部６４の異常状態ではない。このため、ステップ２０８へ移行する。
【００９５】
ステップ２０８では、ＧＵＩモジュールに不具合が発生しているか否かが判定される。ステップ２０８で肯定判定の場合（不具合発生）、ステップ２１４へ移行する。なお、ＧＵＩモジュールの不具合として軽微な不具合は除かれる。
【００９６】
一方、ステップ２０８で否定判定の場合（不具合の不発生又は軽微な不具合の発生）、ステップ２１０へ移行する。
【００９７】
ステップ２１０では、画像データ蓄積メモリ６２のデータ量が許容量を超えたか否かが判定される。ステップ２１０で肯定判定されると（許容量を超えた）、画像処理が正常に行われていないため、ステップ２１４へ移行する。一方、ステップ２１０で否定判定されると（許容量以下）、ステップ２１２へ移行する。
【００９８】
ステップ２１２では、画像データ蓄積メモリ６２のデータ量の変化率が所定の変化率を超えたか否かが判定される。ステップ２１２で肯定判定されると（所定の変化率を超えた）、前記ステップ２１０での肯定判定と同様に、画像処理の異常なので、ステップ２１４へ移行する。
【００９９】
一方、ステップ２１２で否定判定されると（所定の変化率以内）、キャプチャ条件が成立しなかったこととなり、画面キャプチャすべき場合ではないのでこのルーチンは終了する。
【０１００】
ステップ２１４では、キャプチャ条件が成立したこととなる。従って、Ｆ＝１に設定され、このルーチンは終了する。
【０１０１】
なお、本実施の形態では、取得した画面イメージと取得時刻とを一つのログデータとしてログ格納部７２に格納したが、画面イメージと取得時刻とからなるログデータは、通常のログデータとは別途格納するようにしてもよい。
【図面の簡単な説明】
【０１０２】
【図１】本実施の形態に係る画像処理装置を示す全体概要図である。
【図２】本実施に形態に係る画像処理装置のハード構成を示す図である。
【図３】本実施の形態に係る画像処理装置の機能ブロック図である。
【図４】本実施の形態に係るログデータの一例を示す図である。
【図５】本実施の形態に係る画面キャプチャの実行を示すフローチャートである。
【図６】本実施の形態に係るキャプチャ条件成立を判定するフローチャートである。
【符号の説明】
【０１０３】
１０ 画像処理装置
１２ 画像形成部
１４ 用紙収容部
１６ 後処理部
１８ 筐体
２０ 主制御部
２２ 制御部本体
２４ キーボード（ユーザーインターフェースモジュール）
２５ マウス（ユーザーインターフェースモジュール）
２６ ＧＵＩ（ユーザーインターフェースモジュール）
２７ モニタ（ユーザーインターフェースモジュール）
３２ 開閉蓋
３４ 開閉扉
３６ トレイ
３８ 複数のトレイ
４０ 搬送部
４２ 排出トレイユニット
４４ ＣＰＵ
４６ ＲＡＭ
４８ ＲＯＭ
５０ Ｉ／Ｏ
５１ Ｉ／Ｆ
５２ バス
５６ 画像形成制御部
５８ 搬送制御部
６０ 後処理制御部
６２ 画像データ蓄積メモリ
６４ 副制御部
６６ 解析部（監視手段）
６８ 画像処理制御部
６８Ａ 監視部（監視手段）
７０ ログ生成部（履歴情報格納手段）
７２ ログ格納部（履歴情報格納手段）
７４ ＧＵＩ表示制御部（ユーザーインターフェースモジュール、イメージデータ取込手段）
７６ キャプチャ指示部（イメージデータ取込手段）
７８ 取込実行部（イメージデータ取込手段）
【特許請求の範囲】
【請求項１】
画像処理に関する情報を送受信して視覚的に報知するモニタ画面を備えたユーザーインターフェースモジュールと、
画像処理中に発生する特定事象の発生の有無を監視する監視手段と、
前記監視手段の監視により、前記特定事象の発生を認識した場合に、前記モニタ画面に表示されているイメージデータを取り込むイメージデータ取込手段と、
を有する画像処理装置。
【請求項２】
画像処理の実行に則して、適宜当該画像処理に関する履歴情報を格納する履歴情報格納手段を更に有し、
前記イメージデータ取込手段で取り込んだイメージデータを前記履歴情報格納手段に格納された履歴情報に関連付けて格納する請求項１記載の画像処理装置。
【請求項３】
前記イメージデータ取込手段が、少なくとも時間的制限を含む取込条件の不成立により、イメージデータの取り込みに失敗したとき当該取込処理を中止する請求項１又は請求項２記載の画像処理装置。
【請求項４】
前記特定事象が、画像処理制御系に定常稼働能力負荷以上の負荷が一定期間継続又は累積したときである請求項１〜請求項３の何れか１項記載の画像処理装置。
【請求項５】
前記特定事象が、画像処理実行以外の待機中において、画像処理制御系に非稼働能力負荷以上の負荷が継続又は累積したときである請求項１〜請求項３記載の画像処理装置。
【請求項６】
前記特定事象が、前記ユーザーインターフェースモジュールの不具合の発生である請求項１〜請求項５の何れか１項記載の画像処理装置。
【請求項７】
前記ユーザーインターフェースモジュールの不具合であるが、画像処理を中断又は中止するまでもない事象を、予め特定事象から排除する請求項６記載の画像処理装置。
【請求項８】
前記特定事象が、前記ユーザーインターフェースモジュールを用いた画像処理に関する動作が、無反応なときである請求項１〜請求項７の何れか１項記載の画像処理装置。
【請求項９】
前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた許容量を超えたときである請求項１〜請求項８の何れか１項記載の画像処理装置。
【請求項１０】
前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた変化率を超えたときである請求項１〜請求項９の何れか１項記載の画像処理装置。
【請求項１１】
前記履歴情報格納手段により格納されたイメージデータのデータ量が一定量を超えたとき、前記イメージデータを格納時期が古い順に削除する請求項１〜請求項１０の何れか１項記載の画像処理装置。
【請求項１２】
コンピュータを、請求項１〜請求項１１のいずれか１項記載の画像処理装置として機能させるための障害解析プログラム。
【請求項１】
画像処理に関する情報を送受信して視覚的に報知するモニタ画面を備えたユーザーインターフェースモジュールと、
画像処理中に発生する特定事象の発生の有無を監視する監視手段と、
前記監視手段の監視により、前記特定事象の発生を認識した場合に、前記モニタ画面に表示されているイメージデータを取り込むイメージデータ取込手段と、
を有する画像処理装置。
【請求項２】
画像処理の実行に則して、適宜当該画像処理に関する履歴情報を格納する履歴情報格納手段を更に有し、
前記イメージデータ取込手段で取り込んだイメージデータを前記履歴情報格納手段に格納された履歴情報に関連付けて格納する請求項１記載の画像処理装置。
【請求項３】
前記イメージデータ取込手段が、少なくとも時間的制限を含む取込条件の不成立により、イメージデータの取り込みに失敗したとき当該取込処理を中止する請求項１又は請求項２記載の画像処理装置。
【請求項４】
前記特定事象が、画像処理制御系に定常稼働能力負荷以上の負荷が一定期間継続又は累積したときである請求項１〜請求項３の何れか１項記載の画像処理装置。
【請求項５】
前記特定事象が、画像処理実行以外の待機中において、画像処理制御系に非稼働能力負荷以上の負荷が継続又は累積したときである請求項１〜請求項３記載の画像処理装置。
【請求項６】
前記特定事象が、前記ユーザーインターフェースモジュールの不具合の発生である請求項１〜請求項５の何れか１項記載の画像処理装置。
【請求項７】
前記ユーザーインターフェースモジュールの不具合であるが、画像処理を中断又は中止するまでもない事象を、予め特定事象から排除する請求項６記載の画像処理装置。
【請求項８】
前記特定事象が、前記ユーザーインターフェースモジュールを用いた画像処理に関する動作が、無反応なときである請求項１〜請求項７の何れか１項記載の画像処理装置。
【請求項９】
前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた許容量を超えたときである請求項１〜請求項８の何れか１項記載の画像処理装置。
【請求項１０】
前記特定事象が、画像処理における蓄積された画像データ量が、予め定めた変化率を超えたときである請求項１〜請求項９の何れか１項記載の画像処理装置。
【請求項１１】
前記履歴情報格納手段により格納されたイメージデータのデータ量が一定量を超えたとき、前記イメージデータを格納時期が古い順に削除する請求項１〜請求項１０の何れか１項記載の画像処理装置。
【請求項１２】
コンピュータを、請求項１〜請求項１１のいずれか１項記載の画像処理装置として機能させるための障害解析プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１０−４９３８８（Ｐ２０１０−４９３８８Ａ）
【公開日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願番号】特願２００８−２１１５８７（Ｐ２００８−２１１５８７）
【出願日】平成２０年８月２０日（２００８．８．２０）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願日】平成２０年８月２０日（２００８．８．２０）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]