JP2005219247A - 画像形成装置および自動リブート方法 - Google Patents

Abstract

【課題】 電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し、ユーザの操作を要することなく、自動かつ適切にリブートを行うことのできる画像形成装置および自動リブート方法を提供することを目的とする。
【解決手段】 画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、上記ハードウェア資源および上記プログラムをリブートする手段とを備える。
【選択図】 図５

Description

本発明は画像形成装置および自動リブート方法に関する。

コピー機等の画像形成装置にあっては、ハードウェアもしくはプログラム（ソフトウェア）の種々の原因に基づく故障が発生する場合があり、これらの故障への対応は円滑な機器の利用を担保する上で重要なテーマである。

従来、故障は例えば次のようなＡ〜Ｄの４つのタイプに分類されていた。

タイプＡ・・緊急性を要し、サービスマンによる修理が必要な故障
タイプＢ・・特定のユニットの故障で、基本機能に影響のない故障
タイプＣ・・ログ機能の故障
タイプＤ・・電源のオフ（ＯＦＦ）／オン（ＯＮ）により復旧可能なその他の故障
なお、上記のタイプ分けは便宜的なものであって、必ずしも故障の重大性の序列を意味しているものではない。

図１０は従来における故障発生時の動作を示す操作フロー図であり、上記のタイプＡおよびタイプＤの故障に対する動作である。なお、タイプＢについては別途のアラートが表示され、タイプＣについては特段の表示は行われない。

図１０において、タイプＡもしくはタイプＤの故障が発生すると（ステップＳ６０１）、タイプＡの故障の場合もしくはタイプＤの故障が所定の頻度で発生した場合には、画像形成装置にＣＳＳ（Customer Satisfaction Service）と呼ばれる自動通報機能があってその機能が有効である場合は故障時自動通報画面を表示してサービスセンタに自動通報を行う（ステップＳ６０２）。そして、通報が成功した場合はサービスマンによる修理を待つ旨が表示され（ステップＳ６０３）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ６０４）。また、通報が失敗した場合はユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ６０５）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ６０６）。

また、タイプＤの故障が単発（所定の頻度に達しない発生）で発生した場合には、画像形成装置の自動通報機能が有効である場合であっても自動通報は行われず、ユーザに電源のＯＦＦ／ＯＮを促す旨が表示され（ステップＳ６０７）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ６０８）。

一方、画像形成装置の自動通報機能が無効であるか自動通報機能自体が存在しない機種である場合、タイプＡの故障の場合もしくはタイプＤの故障が所定の頻度で発生した場合には、ユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ６１１）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ６１２）。また、タイプＤの故障が単発で発生した場合には、ユーザに電源のＯＦＦ／ＯＮを行い、それでも再び故障が発生した場合にはサービスセンタへ連絡すべき旨が表示され（ステップＳ６０９）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ６１０）。

従来の故障発生時における対応は上述したように行われていたが、次のような問題点があった。

すなわち、タイプＤの故障が単発で発生した場合には自動通報機能の有無にかかわらずユーザによる電源のＯＦＦ／ＯＮが促されるため、ユーザに負担が発生するという問題点があった。この際、通常のコピー操作等においては電源スイッチを使用することはほとんどないので、操作に慣れていない者には電源スイッチの場所がわからずに困惑する場合もあった。

また、タイプＤの故障が所定の頻度で発生した場合には自動通報が行われるかサービスセンタへの連絡が促されるが、それ以前に発生したタイプＤの故障の際に適切に電源のＯＦＦ／ＯＮを行っていれば解消されたかもしれない故障が、ユーザによる不適切な電源のＯＦＦ／ＯＮによって再発する場合もあり、その場合には本来はサービスマンを呼ぶまでもない故障であっても自動通報もしくはユーザによる連絡が行われてしまうという問題点があった。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し、ユーザの操作を要することなく、自動かつ適切にリブート（リセット、再起動）を行うことのできる画像形成装置および自動リブート方法を提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、上記ハードウェア資源および上記プログラムをリブートする手段とを備えるようにしている。

また、請求項２に記載されるように、リブート対象となる故障は、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障が所定の枚数の印刷を行う間に所定の回数に達しない範囲で発生した場合とすることができる。

また、請求項３に記載されるように、上記所定の枚数は１０とし、上記所定の回数は２とすることができる。

また、請求項４に記載されるように、上記各手段は、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行うシステムコントロールサービスの一機能として構成することができる。

また、請求項５に記載されるように、リブート対象となる故障の検出からリブートの実行までの間に他の故障が発生した場合、当該他の故障が自動通報の対象であっても自動通報を行わずにリブートを継続実行するようにすることができる。

また、請求項６に記載されるように、リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作抑制を行うようにすることができる。

また、請求項７に記載されるように、上記動作抑制に対して上記ハードウェア資源および上記プログラムから応答があってからリブートの実行まで所定の時間待機するようにすることができる。

また、請求項８に記載されるように、上記ハードウェア資源および上記プログラムのリブートは、エンジンのリセット、ハードディスクドライブのアクセス停止、エンジン電源のＯＦＦ、エンジン電源のＯＮ、アプリのリブートを順次に行うようにすることができる。

また、請求項９に記載されるように、上記ハードウェア資源および上記プログラムのリブートは、省エネ移行中であることを検出した場合は、後処理後にエンジン電源のＯＮを最初に実行するようにすることができる。

また、請求項１０に記載されるように、上記エンジン電源のＯＮに続き、ハードディスクドライブのアクセス停止、アプリのリブートを順次に行うようにすることができる。

また、請求項１１に記載されるように、上記リブート対象となる故障を検出した場合に自動リブートの実行開始を知らせる画面を表示するようにすることができる。

また、請求項１２に記載されるように、上記自動リブートの実行開始を知らせる画面は、上記ハードウェア資源および上記プログラムの後処理の進行状況を示す表示を含むようにすることができる。

また、請求項１３に記載されるように、上記自動リブートの実行開始を知らせる画面は、リブート実行までの時間を示す表示を含むようにすることができる。

また、請求項１４に記載されるように、上記自動リブートの実行開始を知らせる画面は、即座にリブートの開始を指示するボタンを含むようにすることができる。

また、請求項１５に記載されるように、上記リブートの実行後にユーザに確認を求める画面を表示するようにすることができる。

また、請求項１６〜１９に記載されるように、画像形成に使用されるハードウェア資源と画像形成にかかる処理を行うプログラムとを有する画像形成装置における電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する工程と、上記ハードウェア資源および上記プログラムをリブートする工程とを備える等の自動リブート方法として構成することができる。

本発明にあっては、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し、ユーザの操作を要することなく、自動かつ適切にリブートを行うことができるという効果がある。

以下、本発明の好適な実施形態につき図面を参照して説明する。

図１は本発明の一実施形態にかかる画像形成装置の構成図である。

図１において、画像形成装置１は、ソフトウェア群２と、画像形成装置起動部３と、ハードウェア資源４とを含むように構成される。

画像形成装置起動部３は画像形成装置１の電源投入時に最初に実行され、アプリケーション層５およびプラットホーム層６を起動する。例えば画像形成装置起動部３は、アプリケーション層５およびプラットホーム層６のプログラムを、ハードディスク装置（以下、ＨＤＤという）などから読み出し、読み出した各プログラムをメモリ領域に転送して起動する。ハードウェア資源４は、スキャナ２５と、プロッタ２６と、ＡＤＦ（Auto Document Feeder）などのハードウェアリソース２４とを含む。

また、ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットホーム層６とを含む。アプリケーション層５は、プリンタ、コピー、ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。

アプリケーション層５は、プリンタ用のアプリケーションであるプリンタアプリ９と、コピー用アプリケーションであるコピーアプリ１０と、ファックス用アプリケーションであるファックスアプリ１１と、スキャナ用アプリケーションであるスキャナアプリ１２とを含む。

また、プラットホーム層６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層７と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層７からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）２１と、ＳＲＭ２１からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層８とを含む。

コントロールサービス層７は、ネットワークコントロールサービス（以下、ＮＣＳという）１３、デリバリーコントロールサービス（以下、ＤＣＳという）１４、オペレーションパネルコントロールサービス（以下、ＯＣＳという）１５、ファックスコントロールサービス（以下、ＦＣＳという）１６、エンジンコントロールサービス（以下、ＥＣＳという）１７、メモリコントロールサービス（以下、ＭＣＳという）１８、ユーザインフォメーションコントロールサービス（以下、ＵＣＳという）１９、システムコントロールサービス（以下、ＳＣＳという）２０など、一つ以上のサービスモジュールを含むように構成されている。

なお、プラットホーム層６は予め定義されている関数により、アプリケーション層５からの処理要求を受信可能とするＡＰＩ２８を有するように構成されている。ＯＳは、アプリケーション層５およびプラットホーム層６の各ソフトウェアをプロセスとして並列実行する。

ＮＣＳ１３のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。

例えばＮＣＳ１３は、ネットワークを介して接続されるネットワーク機器とのデータ通信をｈｔｔｐｄ（HyperText Transfer Protocol Daemon）により、ＨＴＴＰ（HyperText Transfer Protocol）で制御する。

ＤＣＳ１４のプロセスは、蓄積文書の配信などの制御を行う。ＯＣＳ１５のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。ＦＣＳ１６のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックス送受信、バックアップ用のメモリで管理されている各種ファックスデータの登録／引用、ファックス読み取り、ファックス受信印刷などを行うためのＡＰＩを提供する。

ＥＣＳ１７のプロセスは、スキャナ２５、プロッタ２６、その他のハードウェアリソース２４などのエンジン部の制御を行う。ＭＣＳ１８のプロセスは、メモリの取得および解放、ＨＤＤの利用などのメモリ制御を行う。ＵＣＳ１９は、ユーザ情報の管理を行うものである。

ＳＣＳ２０のプロセスは、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行う。

ＳＲＭ２１のプロセスは、ＳＣＳ２０と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ２１のプロセスは、スキャナ２５やプロッタ２６などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、実行制御する。

具体的に、ＳＲＭ２１のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないかどうか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。また、ＳＲＭ２１のプロセスは上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（例えば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。

また、ハンドラ層８は後述するファックスコントロールユニット（以下、ＦＣＵという）の管理を行うファックスコントロールユニットハンドラ（以下、ＦＣＵＨという）２２と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（以下、ＩＭＨという）２３とを含む。ＳＲＭ２１およびＦＣＵＨ２２は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信可能とするエンジンＩ／Ｆ２７を利用して、ハードウェア資源４に対する処理要求を行う。

画像形成装置１は、各アプリケーションで共通的に必要な処理をプラットホーム層６で一元的に処理することができる。次に、画像形成装置１のハードウェア構成について説明する。

図２は本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。

図２において、画像形成装置１は、コントローラボード３０と、オペレーションパネル４３と、ＦＣＵ４４と、エンジン４７とを含む。また、ＦＣＵ４４は、Ｇ３規格対応ユニット４５と、Ｇ４規格対応ユニット４６とを有する。

また、コントローラボード３０は、ＣＰＵ３１と、ＡＳＩＣ４０と、ＨＤＤ４２と、システムメモリ（ＭＥＭ−Ｐ）３２と、ローカルメモリ（ＭＥＭ−Ｃ）４１と、ノースブリッジ（以下、ＮＢと記す）３３と、サウスブリッジ（以下、ＳＢと記す）３４と、ＮＩＣ３５（Network Interface Card）と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とを含む。

オペレーションパネル４３は、コントローラボード３０のＡＳＩＣ４０に接続されている。また、ＳＢ３４と、ＮＩＣ３５と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とは、ＮＢ３３にＰＣＩバスで接続されている。

また、ＦＣＵ４４と、エンジン４７は、コントローラボード３０のＡＳＩＣ４０にＰＣＩバスで接続されている。

なお、コントローラボード３０は、ＡＳＩＣ４０にＭＥＭ−Ｃ４１、ＨＤＤ４２などが接続されると共に、ＣＰＵ３１とＡＳＩＣ４０とがＣＰＵチップセットのＮＢ３３を介して接続されている。このように、ＮＢ３３を介してＣＰＵ３１とＡＳＩＣ４０とを接続すれば、ＣＰＵ３１のインタフェースが公開されていない場合に対応できる。

また、ＡＳＩＣ４０とＮＢ３３とはＰＣＩバスを介して接続されているのでなく、ＡＧＰ（Accelerated Graphics Port）３９を介して接続されている。このように、図１のアプリケーション層５やプラットホーム層６を形成する一つ以上のプロセスを実行制御するため、ＡＳＩＣ４０とＮＢ３３とを低速のＰＣＩバスでなくＡＧＰ３９を介して接続し、パフォーマンスの低下を防いでいる。

ＣＰＵ３１は、画像形成装置１の全体制御を行うものである。ＣＰＵ３１は、図１のＮＣＳ１３、ＤＣＳ１４、ＯＣＳ１５、ＦＣＳ１６、ＥＣＳ１７、ＭＣＳ１８、ＵＣＳ１９、ＳＣＳ２０、ＳＲＭ２１、ＦＣＵＨ２２、ＩＭＨ２３をＯＳ上にそれぞれプロセスとして起動して実行させると共に、アプリケーション層５を形成するプリンタアプリ９、コピーアプリ１０、ファックスアプリ１１、スキャナアプリ１２を起動して実行させる。

ＮＢ３３は、ＣＰＵ３１、ＭＥＭ−Ｐ３２、ＳＢ３４およびＡＳＩＣ４０を接続するためのブリッジである。ＭＥＭ−Ｐ３２は、画像形成装置１の描画用メモリなどとして用いるメモリである。ＳＢ３４は、ＮＢ３３とＰＣＩバス、周辺デバイスとを接続するためのブリッジである。また、ＭＥＭ−Ｃ４１はコピー用画像バッファ、符号バッファとして用いるメモリである。

ＡＳＩＣ４０は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＨＤＤ４２は、画像の蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積などを行うためのストレージである。また、オペレーションパネル４３は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。

図３は本発明の故障対応のために図１のＳＣＳ２０内に設けられた機能部の構成例を示すブロック図である。なお、故障対応に関する部分のみを示している。

図３において、ＳＣＳ２０には、前述したタイプＡおよびタイプＤの故障を検出する故障検出部２０ａと、発生した故障をログに書き込むログ書込部２０ｂと、電源のＯＦＦ／ＯＮによって復旧する可能性の高いタイプＤの故障のうちリブート対象となる故障（例えば印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回に達しない範囲で発生する場合、すなわち１回目のタイプＤの故障）を検出するリブート対象故障検出部２０ｃとを含んでいる。

また、ＳＣＳ２０には、故障発生時に自動通報および自動リブートに関する画面を表示する画面表示制御部２０ｄと、タイプＡの故障もしくはタイプＤの故障が所定の頻度で発生した場合（例えば印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回発生した場合）に前述したＣＳＳあるいはネットワークを利用した診断サービスであるＮＲＳ（New Remote Service）を使用してサービスセンタに自動通報を行う自動通報制御部２０ｅとを含んでいる。

更に、ＳＣＳ２０には、リブート対象となる故障を検出した直後に、リブートに先立って、画像形成装置１のハードウェア資源４であるエンジンやプログラム（ソフトウェア群２）に対して動作抑制（新たな動作の抑制、プロセス間通信の抑制、ＨＤＤへのアクセスの抑制等を含む）を行う動作抑制制御部２０ｆと、画像形成装置１のエンジンやプログラムに対して一連のリブート（リセット）処理を行うリブート実行制御部２０ｇとを含んでいる。なお、省エネ移行検出部２０ｈは画像形成装置１が省エネ状態に入っていることを検出する部分である。

図４は故障発生時における画像形成装置の動作を示す操作フロー図である。

図４において、タイプＡもしくはタイプＤの故障が発生すると（ステップＳ１０１）、タイプＡの故障の場合もしくはタイプＤの故障であってリブート対象とならない場合（印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回発生した場合）には、画像形成装置１にＣＳＳもしくはＮＲＳによる自動通報機能があってその機能が有効である場合は、故障時自動通報画面を表示してサービスセンタに自動通報を行う（ステップＳ１０２）。そして、通報が成功した場合はサービスマンによる修理を待つ旨が表示され（ステップＳ１０３）、あるいは別パターンとして営業時間外であるため対応が次営業日になる旨が表示され（ステップＳ１０５）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１０４、Ｓ１０６）。また、通報が失敗した場合はユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ１０７）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１０８）。

また、タイプＤの故障であってリブート対象となる場合（１回目の発生の場合）には、画像形成装置１の自動通報機能が有効である場合であっても自動通報は行われず、本発明の特徴的な動作としての自動リブートの実行開始を知らせる画面が表示される（ステップＳ１０９）。この画面では、リブートにより処理内容が消去されるため再び作業をやり直す必要がある旨が表示されるほか、ハードウェア資源およびプログラムのリブートのための後処理の進行状況を示す表示と、リブート実行までの時間を示す表示と、即座にリブートの開始を指示するボタンとが含まれている。ここで、後処理は、エンジンに紙が残らないようにしたり、ＨＤＤの故障等を起こさないよう、適切なリブートが行えるようにするための処理である。また、リブート実行までの時間として、後処理が終了してリブートが行えるようになってから例えば３０秒の待機時間を設けている。これは、後処理が短時間に終了した場合には自動リブートの開始を伝える画面が短時間しか表示されず、ユーザに充分に認識させることができないからである。また、即座にリブートの開始を指示するボタンを設けているのは、作業を急いでいる場合に所定の待機時間を待つことなくリブートを実施し、早急な復旧を図るためである。

自動リブートの実行開始を知らせる画面が表示されてから所定の待機時間が経過した場合には自動リブートが実行され（ステップＳ１１０）、自動リブートを実行したことをユーザに伝えて確認を求める画面が表示される（ステップＳ１１１）。そして、ユーザが確認のボタンを押すことで、通常画面に移行する（ステップＳ１１２）。

また、自動リブートの実行開始を知らせる画面からユーザによって即座にリブートの開始を指示するボタンが押された場合には、所定の待機時間を経ることなしに自動リブートが実行され（ステップＳ１１３）、通常画面に移行する（ステップＳ１１２）。この場合は自動リブートを実行したことをユーザに伝えて確認を求める画面（ステップＳ１１１）は省略される。

一方、画像形成装置１の自動通報機能が無効であるか自動通報機能自体が存在しない機種である場合、タイプＡの故障の場合もしくはタイプＤの故障であってリブート対象とならない場合には、ユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ１１７）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１１８）。

また、タイプＤの故障であってリブート対象となる場合には、自動通報機能が有効な場合（ステップＳ１０９）と同様の自動リブートの実行開始を知らせる画面が表示され（ステップＳ１１４）、所定の待機時間が経過した場合には自動リブートが実行され（ステップＳ１１５）、自動リブートを実行したことをユーザに伝えて確認を求める画面が表示され（ステップＳ１１１）、ユーザが確認のボタンを押すことで通常画面に移行する（ステップＳ１１２）。また、自動リブートの実行開始を知らせる画面からユーザによって即座にリブートの開始を指示するボタンが押された場合には、所定の待機時間を経ることなしに自動リブートが実行され（ステップＳ１１６）、通常画面に移行する（ステップＳ１１２）。

以上の動作により、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障であって自動通報を行うまでもないと考えられる故障については、ユーザの手を煩わすことなく適切かつ自動的にリブートが行われることになる。

次に、図５はリブート対象故障発生時における画像形成装置の動作を示すシーケンス図である。

図５において、ＯＣＳ１５およびＳＣＳ２０は、図１に同符号を付して示したものに対応している。なお、ＳＣＳ２０として図１におけるＳＲＭ２１の機能も含めて示している。また、アプリ１０１、１０２は、図１におけるプリンタアプリ９、コピーアプリ１０、ファックスアプリ１１、スキャナアプリ１２に対応しており、エンジン１０３は図１におけるハードウェア資源４に対応している。ｘＣＳ１０４は図１におけるＮＣＳ１３、ＤＣＳ１４、ＦＣＳ１６、ＥＣＳ１７、ＭＣＳ１８、ＵＣＳ１９等のコントロールサービス層７のプロセスに対応している。なお、リブートにかかる処理は図３に示したＳＣＳ２０内の機能部によって主として行われる。

図５において、リブート対象となる故障（タイプＤの故障であって１回目の発生の場合）が発生し、ＳＣＳ２０がこれを検出すると（ステップＳ２０１）、自動リブートの実行開始を知らせる画面を表示し（ステップＳ２０２）、ほぼ同時に、ｘＣＳ１０４、アプリ１０１、１０２、エンジン１０３に対して動作抑制の通知を行う（ステップＳ２０３〜Ｓ２０６）。動作抑制の通知を受けた各部は、後処理として、仕掛かり中の処理を区切りのよい、リブートが安全に行える状態で動作停止し、インタフェースの抑制を行うことで新たな動作を抑制し、ＳＣＳ２０に対して応答を通知する（ステップＳ２０７〜Ｓ２１０）。ＳＣＳ２０は応答の受付を例えば３分間でタイムアウトする。

次いで、ＳＣＳ２０は例えば３０秒間の待機を行い（ステップＳ２１１）、リブートの実行に入る。ここで、ＯＣＳ１５に対して操作部ドライバの通信停止要求を行うが、関数内でブロックされるため応答はない（ステップＳ２１２）。続いて、ＳＣＳ２０はエンジン１０３に対してリセット要求を行い（ステップＳ２１３）、エンジン１０３から応答を受け取る（ステップＳ２１４）。そして、ＨＤＤのアクセス停止処理（ステップＳ２１５）、エンジン電源のＯＦＦ（ステップＳ２１６）、エンジン電源のＯＮ（ステップＳ２１７）、アプリ１０１、１０２のリブート実行（ステップＳ２１８）を順次に行い、エンジン１０３に対してコントローラ起動を行い（ステップＳ２１９）、エンジン１０３からエンジンコンフィグを受け取る（ステップＳ２２０）。そして、自動リブートを実行したことをユーザに伝えて確認を求める画面を表示する（ステップＳ２２１）。

このように、各モジュールの動作抑制を行い、動作中の処理の後始末とインタフェースの抑制を行うことで、残紙やＨＤＤ故障やデータのゴミ等を生ずることなく、速やかにリブートを行うことができる。

ところで、自動リブートもしくは自動通報の処理中に更に別の故障が発生する場合がある。図６は自動リブートもしくは自動通報の処理中に故障が発生した場合の動作パターンを示す図であり、１回目および２回目の故障のタイプに応じてパターンを分けてある。

図６において、改善前とは、タイプＡの故障の場合もしくはタイプＤの故障であってリブート対象とならない場合（印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回発生した場合）に自動通報を行うという原則をそのまま適用した場合であり、改善後とは、その際の問題点を考慮して動作を修正したものである。なお、前述した図４および図５の動作フローは改善後のものに対応している。

特に問題となるのは、図６のパターン（１）とパターン（３）の場合である。すなわち、パターン（１）では、１回目のタイプＤの故障により自動リブート処理に入った後に、２回目としてタイプＤの故障が発生した場合、改善前は自動リブートを中断して自動通報処理に入ってしまうこととなる。しかし、この場合、リブート処理の初期に行われる各モジュールの動作抑制によりＮＲＳ等による自動通報機能が使えない状態となっており、自動通報処理は必ず失敗してしまうことになる。また、自動通報処理にいったん移行することで、タイプＤの故障の発生頻度を把握するカウント値がクリアされてしまうため、自動通報の失敗の後に再びタイプＤの故障が発生すると、本来は３度目のタイプＤの故障であって自動通報をすべきものであるが、１回目のタイプＤの故障と扱われてリブート処理に入ってしまい、リブート処理が繰り返されるという問題もある。

一方、パターン（３）は２回目がタイプＡの故障の場合であり、動作抑制によって自動通報処理が必ず失敗するという問題は同様であるが、更に、定着ＳＣ（定着部の故障）のようにサービスマンの解除が行われないと復旧できないようにするためのＳＰモード（特殊モード）に入ることができず、手動によるリブート後も同じタイプＡの故障が発生するという問題がある。

図７は上述したリブート処理中に故障が発生した場合の改善前の動作を示す図であり、自動リブートの対象となる故障が発生し（ステップＳ３０１）、自動リブートの実行開始を伝える画面が表示された後（ステップＳ３０２）、通常であればリブートが実施され（ステップＳ３０３）、確認画面が表示されて処理を終えるものであるが（ステップＳ３０４）、処理の途中でタイプＡもしくはタイプＤの故障が発生すると（ステップＳ３０５）、自動通報（自動通報機能が無効の場合はサービスコール画面の表示）が行われ（ステップＳ３０６）、電源のＯＦＦ／ＯＮを待つ状態で停止してしまうものである（ステップＳ３０７）。

このような問題があることから、改善後の動作として、自動リブート処理が開始された後に他の故障が発生した場合は、ログのみを残し、リブート処理を継続するようにしている。

図８はリブート処理中に故障が発生した場合の改善後の動作を示す図であり、自動リブートの対象となる故障が発生し（ステップＳ４０１）、自動リブートの実行開始を伝える画面が表示された後は（ステップＳ４０２）、別のタイプＡもしくはタイプＤの故障が発生しても（ステップＳ４０５）、ログを書き込むのみとし（ステップＳ４０６）、リブートを実施するものである（ステップＳ４０３）。そして、リブートの実施後は通常は確認画面が表示されて処理を終えるものであるが（ステップＳ４０４）、その前に更に自動通報の対象となる故障が発生すれば（定着ＳＣの場合はタイプＡの故障として必ず再発）（ステップＳ４０７）、自動通報もしくはサービスコールの画面に移行することになる（ステップＳ４０８）。こうすることで、故障内容に応じた適切な対応を行うことができる。

次に、図９は省エネ移行中における自動リブートの動作を示すシーケンス図である。すなわち、画像形成装置は電力消費量節減のために省エネモードに入るようになっているものが多いが、そのような省エネ移行中にリブートの対象となる故障が発生した場合の動作である。

図９において、リブート対象となる故障（タイプＤの故障であって１回目の発生の場合）が発生し、ＳＣＳ２０がこれを検出すると（ステップＳ５０１）、自動リブートの実行開始を知らせる画面を表示し（ステップＳ５０２）、ほぼ同時に、ｘＣＳ１０４、アプリ１０１、１０２に対して動作抑制の通知を行う（ステップＳ５０３〜Ｓ５０５）。なお、ＳＣＳ２０は省エネ状態に移行していることを認識しており、省エネ移行によりエンジン１０３は実質的に停止状態であるため、エンジン１０３に対しては動作抑制の通知を行わない。

動作抑制の通知を受けた各部は、後処理として、仕掛かり中の処理を区切りのよい、リブートが安全に行える状態で動作停止し、インタフェースの抑制を行うことで新たな動作を抑制し、ＳＣＳ２０に対して応答を通知する（ステップＳ５０６〜Ｓ５０８）。ＳＣＳ２０は応答の受付を例えば３分間でタイムアウトする。

次いで、ＳＣＳ２０は例えば３０秒間の待機を行った後（ステップＳ５０９）、最初にエンジンのＯＮを行い（ステップＳ５１０）、続いてＨＤＤのアクセス停止処理を行う（ステップＳ５１１）。その後、ＯＣＳ１５からレディーの通知が行われ（ステップＳ５１２）、ＯＣＳ１５に対して操作部ドライバの通信停止要求を行う（ステップＳ５１３）。なお、省エネ移行によりエンジン１０３は実質的に停止状態にあるため、エンジン１０３に対してはリセット要求を行わず、電源をいったんＯＦＦにすることもない。そして、アプリ１０１、１０２のリブート実行を行い（ステップＳ５１４）、エンジン１０３に対してコントローラ起動を行い（ステップＳ５１５）、エンジン１０３からエンジンコンフィグを受け取り（ステップＳ５１６）、自動リブートを実行したことをユーザに伝えて確認を求める画面を表示する（ステップＳ５１７）。

このようにすることで、画像形成装置１が省エネ移行中であっても適切にリブートを行うことができる。

本発明の一実施形態にかかる画像形成装置の構成図である。 本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。 ＳＣＳ内の故障対応のための機能部の構成例を示すブロック図である。 故障発生時における画像形成装置の動作を示す操作フロー図である。 リブート対象故障発生時における画像形成装置の動作を示すシーケンス図である。 自動リブートもしくは自動通報の処理中に故障が発生した場合の動作パターンを示す図である。 リブート処理中に故障が発生した場合の改善前の動作を示す図である。 リブート処理中に故障が発生した場合の改善後の動作を示す図である。 省エネ移行中における自動リブートの動作を示すシーケンス図である。 従来における故障発生時の動作を示す操作フロー図である。

符号の説明

１ 画像形成装置
１５ ＯＣＳ
２０ ＳＣＳ
２０ａ 故障検出部
２０ｂ ログ書込部
２０ｃ リブート対象故障検出部
２０ｄ 画面表示制御部
２０ｅ 自動通報制御部
２０ｆ 動作抑制制御部
２０ｇ リブート実行制御部
２０ｈ 省エネ移行検出部
２１ ＳＲＭ
１０１ アプリ
１０２ アプリ
１０３ エンジン
１０４ ｘＣＳ

Claims (19)

1. 画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、
   電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、
   上記ハードウェア資源および上記プログラムをリブートする手段とを備えたことを特徴とする画像形成装置。
2. リブート対象となる故障は、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障が所定の枚数の印刷を行う間に所定の回数に達しない範囲で発生した場合とすることを特徴とする請求項１に記載の画像形成装置。
3. 上記所定の枚数は１０とし、上記所定の回数は２としてなることを特徴とする請求項２に記載の画像形成装置。
4. 上記各手段は、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行うシステムコントロールサービスの一機能として構成されてなることを特徴とする請求項１乃至３のいずれか一項に記載の画像形成装置。
5. リブート対象となる故障の検出からリブートの実行までの間に他の故障が発生した場合、当該他の故障が自動通報の対象であっても自動通報を行わずにリブートを継続実行することを特徴とする請求項１乃至４のいずれか一項に記載の画像形成装置。
6. リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作抑制を行うことを特徴とする請求項１乃至５のいずれか一項に記載の画像形成装置。
7. 上記動作抑制に対して上記ハードウェア資源および上記プログラムから応答があってからリブートの実行まで所定の時間待機することを特徴とする請求項６に記載の画像形成装置。
8. 上記ハードウェア資源および上記プログラムのリブートは、エンジンのリセット、ハードディスクドライブのアクセス停止、エンジン電源のＯＦＦ、エンジン電源のＯＮ、アプリのリブートを順次に行うことを特徴とする請求項１乃至７のいずれか一項に記載の画像形成装置。
9. 上記ハードウェア資源および上記プログラムのリブートは、省エネ移行中であることを検出した場合は、後処理後にエンジン電源のＯＮを最初に実行することを特徴とする請求項１乃至７のいずれか一項に記載の画像形成装置。
10. 上記エンジン電源のＯＮに続き、ハードディスクドライブのアクセス停止、アプリのリブートを順次に行うことを特徴とする請求項９に記載の画像形成装置。
11. 上記リブート対象となる故障を検出した場合に自動リブートの実行開始を知らせる画面を表示することを特徴とする請求項１乃至１０のいずれか一項に記載の画像形成装置。
12. 上記自動リブートの実行開始を知らせる画面は、上記ハードウェア資源および上記プログラムの後処理の進行状況を示す表示を含むことを特徴とする請求項１１に記載の画像形成装置。
13. 上記自動リブートの実行開始を知らせる画面は、リブート実行までの時間を示す表示を含むことを特徴とする請求項１１または１２のいずれか一項に記載の画像形成装置。
14. 上記自動リブートの実行開始を知らせる画面は、即座にリブートの開始を指示するボタンを含むことを特徴とする請求項１１乃至１３のいずれか一項に記載の画像形成装置。
15. 上記リブートの実行後にユーザに確認を求める画面を表示することを特徴とする請求項１乃至１４のいずれか一項に記載の画像形成装置。
16. 画像形成に使用されるハードウェア資源と画像形成にかかる処理を行うプログラムとを有する画像形成装置における電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する工程と、
    上記ハードウェア資源および上記プログラムをリブートする工程とを備えたことを特徴とする自動リブート方法。
17. リブート対象となる故障の検出からリブートの実行までの間に他の故障が発生した場合、当該他の故障が自動通報の対象であっても自動通報を行わずにリブートを継続実行することを特徴とする請求項１６に記載の自動リブート方法。
18. リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作抑制を行うことを特徴とする請求項１６または１７に記載の自動リブート方法。
19. 上記ハードウェア資源および上記プログラムのリブートは、エンジンのリセット、ハードディスクドライブのアクセス停止、エンジン電源のＯＦＦ、エンジン電源のＯＮ、アプリのリブートを順次に行うことを特徴とする請求項１６乃至１８に記載の自動リブート方法。
    
    

Images