(57)【要約】【課題】  電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し自動リブートを行う場合に、課金やその他の管理上の必要性から設けられる各種カウンタの値に不整合が生じない画像形成装置および自動リブート方法を提供することを目的とする。【解決手段】  画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、上記リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作停止を行う手段と、上記ハードウェア資源および上記プログラムをリブートする手段とを備える。【選択図】  図５
2005229210.tif 000002
【特許請求の範囲】
【請求項１】
画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、
電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、
上記リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作停止を行う手段と、
上記ハードウェア資源および上記プログラムをリブートする手段とを備えたことを特徴とする画像形成装置。
【請求項２】
上記プログラムのコントローラ側に設けられるトータルカウンタと、
上記コントローラ側に設けられる課金装置のカウンタと、
ハードウェア資源のエンジン側に設けられるメカカウンタと、
上記エンジン側に設けられる課金装置のカウンタとを備えたことを特徴とする請求項１に記載の画像形成装置。
【請求項３】
上記動作停止は、ジョブの停止および新たなプロセス制御の発生停止を含むことを特徴とする請求項１または２のいずれか一項に記載の画像形成装置。
【請求項４】
上記ジョブの停止により、上記プログラムのアプリは未完了のジョブのキャンセルを行うことを特徴とする請求項３に記載の画像形成装置。
【請求項５】
上記動作停止の完了の後であって上記リブートの前に上記ハードウェア資源および上記プログラムの動作抑制を行うことを特徴とする請求項１乃至４のいずれか一項に記載の画像形成装置。
【請求項６】
上記動作抑制に対して上記ハードウェア資源および上記プログラムから応答があってからリブートの実行まで所定の時間待機することを特徴とする請求項５に記載の画像形成装置。
【請求項７】
リブート対象となる故障は、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障が所定の枚数の印刷を行う間に所定の回数に達しない範囲で発生した場合とすることを特徴とする請求項１乃至６のいずれか一項に記載の画像形成装置。
【請求項８】
上記所定の枚数は１０とし、上記所定の回数は２としてなることを特徴とする請求項７に記載の画像形成装置。
【請求項９】
上記各手段は、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行うシステムコントロールサービスの一機能として構成されてなることを特徴とする請求項１乃至８のいずれか一項に記載の画像形成装置。
【請求項１０】
上記ハードウェア資源および上記プログラムのリブートは、エンジンのリセット、ハードディスクドライブのアクセス停止、エンジン電源のＯＦＦ、エンジン電源のＯＮ、アプリのリブートを順次に行うことを特徴とする請求項１乃至９のいずれか一項に記載の画像形成装置。
【請求項１１】
上記リブート対象となる故障を検出した場合に自動リブートの実行開始を知らせる画面を表示することを特徴とする請求項１乃至１０のいずれか一項に記載の画像形成装置。
【請求項１２】
上記自動リブートの実行開始を知らせる画面は、上記ハードウェア資源および上記プログラムの後処理の進行状況を示す表示を含むことを特徴とする請求項１１に記載の画像形成装置。
【請求項１３】
上記自動リブートの実行開始を知らせる画面は、リブート実行までの時間を示す表示を含むことを特徴とする請求項１１または１２のいずれか一項に記載の画像形成装置。
【請求項１４】
上記自動リブートの実行開始を知らせる画面は、即座にリブートの開始を指示するボタンを含むことを特徴とする請求項１１乃至１３のいずれか一項に記載の画像形成装置。
【請求項１５】
上記リブートの実行後にユーザに確認を求める画面を表示することを特徴とする請求項１乃至１４のいずれか一項に記載の画像形成装置。
【請求項１６】
画像形成に使用されるハードウェア資源と画像形成にかかる処理を行うプログラムとを有する画像形成装置における電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する工程と、
上記リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作停止を行う工程と、
上記ハードウェア資源および上記プログラムをリブートする工程とを備えたことを特徴とする自動リブート方法。
【請求項１７】
上記動作停止は、ジョブの停止および新たなプロセス制御の発生停止を含むことを特徴とする請求項１６に記載の自動リブート方法。
【請求項１８】
上記ジョブの停止により、上記プログラムのアプリは未完了のジョブのキャンセルを行うことを特徴とする請求項１６または１７のいずれか一項に記載の自動リブート方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像形成装置および自動リブート方法に関する。
【背景技術】
【０００２】
コピー機等の画像形成装置にあっては、課金やその他の管理上の必要性から、プリントを行う毎にカウント値がアップ（ＵＰ）するハードウェアもしくはソフトウェアによる各種のカウンタが設けられている。例えば、次のようなカウンタが設けられている。
【０００３】
・コントローラ側のトータルカウンタ
・コントローラ側の課金装置のカウンタ
・エンジン側のメカカウンタ
・エンジン側の課金装置のカウンタ
これらのカウンタはプリントを行う毎に正確にカウント値がアップすることが要求され、その値に不整合が発生する場合には課金やその他の管理に影響を与えることになる。
【０００４】
図８は画像形成装置における通常時のカウンタ関連動作を示すシーケンス図である。なお、ここでは連続して２枚のプリントを行う場合を想定している。
【０００５】
図８において、コピー等の実行を制御するアプリ２０１からＥＣＳ（エンジンコントロールサービス）等のｘＣＳ２０４にプリントのジョブスタートが通知されると（ステップＳ５０１）、ｘＣＳ２０４はＳＣＳ（システムコントロールサービス）２０３に対して１枚目のプリントのプロセススタートを通知し（ステップＳ５０２）、ＳＣＳ２０３はエンジン２０６に対して１枚目のプリントのプロセススタートを通知する（ステップＳ５０３）。これを受けてエンジン２０６が１枚目の給紙を開始し、その旨をＳＣＳ２０３に通知すると（ステップＳ５０４）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝える（ステップＳ５０５）。これを受けてｘＣＳ２０４はＳＣＳ２０３に対して２枚目のプリントのプロセススタートを通知し（ステップＳ５０６）、ＳＣＳ２０３はエンジン２０６に対して２枚目のプリントのプロセススタートを通知し（ステップＳ５０７）、エンジン２０６は２枚目の給紙を開始するとその旨をＳＣＳ２０３に伝える（ステップＳ５０８）。なお、１枚目の給紙の段階で２枚目のプロセススタートを通知しているのは、プリントのパフォーマンスを上げるためである。
【０００６】
エンジン２０６は１枚目のプリントを実行し、定着が終わった段階でエンジン側のメカカウンタをアップし（ステップＳ５０９）、１枚目の定着完了をＳＣＳ２０３に通知する（ステップＳ５１０）。これを受けてＳＣＳ２０３はコントローラ側のトータルカウンタをアップし（ステップＳ５１１）、エンジン２０６に対してカウント要求を行う（ステップＳ５１２）。これを受けてエンジン２０６はエンジン側の課金装置のカウンタをアップする（ステップＳ５１３）。
【０００７】
その後、エンジン２０６は１枚目を正常に排紙した段階でＳＣＳ２０３に対してその旨を通知し（ステップＳ５１４）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝え（ステップＳ５１５）、ｘＣＳ２０４はそれを更にアプリ２０１に伝える（ステップＳ５１６）。これを受けてアプリ２０１はＳＣＳ２０３に対してカウント要求を行い（ステップＳ５１７）、ＳＣＳ２０３はコントローラ側の課金装置のカウンタをアップする（ステップＳ５１８）。
【０００８】
同様に、エンジン２０６は２枚目の定着が終わった段階でエンジン側のメカカウンタをアップし（ステップＳ５１９）、２枚目の定着完了をＳＣＳ２０３に通知する（ステップＳ５２０）。これを受けてＳＣＳ２０３はコントローラ側のトータルカウンタをアップし（ステップＳ５２１）、エンジン２０６に対してカウント要求を行う（ステップＳ５２２）。これを受けてエンジン２０６はエンジン側の課金装置のカウンタをアップする（ステップＳ５２３）。
【０００９】
その後、エンジン２０６は２枚目を正常に排紙した段階でＳＣＳ２０３に対してその旨を通知し（ステップＳ５２４）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝え（ステップＳ５２５）、ｘＣＳ２０４はそれを更にアプリ２０１に伝える（ステップＳ５２６）。これを受けてアプリ２０１はＳＣＳ２０３に対してカウント要求を行い（ステップＳ５２７）、ＳＣＳ２０３はコントローラ側の課金装置のカウンタをアップする（ステップＳ５２８）。
【００１０】
以上の動作においては、１枚目および２枚目とも、コントローラ側のトータルカウンタ、コントローラ側の課金装置のカウンタ、エンジン側のメカカウンタ、エンジン側の課金装置のカウンタの値は整合性が保たれている。
【００１１】
ところで、画像形成装置にあってはハードウェアもしくはプログラム（ソフトウェア）の種々の原因に基づく故障が発生する場合がある。故障は例えば次のようなＡ〜Ｄの４つのタイプに分類されている。なお、これらのタイプ分けは便宜的なものであって、必ずしも故障の重大性の序列を意味しているものではない。
【００１２】
タイプＡ・・緊急性を要し、サービスマンによる修理が必要な故障
タイプＢ・・特定のユニットの故障で、基本機能に影響のない故障
タイプＣ・・ログのみのＳＣ
タイプＤ・・電源のオフ（ＯＦＦ）／オン（ＯＮ）により復旧可能なその他の故障
従来、上記の故障のうち、タイプＤに該当するものについては、それが所定の回数に満たない場合には、ユーザの手を煩わすことなくシステム側で自動的にリブートを実行するようにしていた。
【００１３】
図９はリブート対象故障発生時の従来の動作を示すシーケンス図であり、リブート対象の故障が発生した場合（ステップＳ６０１）、ＳＣＳ２０３からｘＣＳ２０４へ、ＳＲＭ（システムリソースマネージャ）２０５を介してエンジン２０６へ、そしてアプリ２０１、２０２へ、ほぼ同時に動作抑制の通知を行い（ステップＳ６０２〜Ｓ６０６）、各部に動作抑制処理（仕掛かり中の処理を区切りのよいリブートが安全に行える状態で動作停止するための後処理、インタフェースの抑制を行うことによる新たな動作の抑制等）を行わせ（ステップＳ６０７）、各部から動作抑制の応答があった後（ステップＳ６０８〜Ｓ６１２）、リブートを実行するようにしていた（ステップＳ６１３）。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
従来の故障発生時におけるリブート処理は上述したように行われていたが、課金やその他の管理上の必要性から設けられる各種のカウンタの値に不整合が生ずるという問題点があった。
【００１５】
図１０はリブート対象故障発生時の従来のカウンタ関連動作を示すシーケンス図であり、連続して２枚のプリントを行う場合を想定している。
【００１６】
図１０において、アプリ２０１からｘＣＳ２０４にプリントのジョブスタートが通知されると（ステップＳ７０１）、ｘＣＳ２０４はＳＣＳ２０３に対して１枚目のプリントのプロセススタートを通知し（ステップＳ７０２）、ＳＣＳ２０３はエンジン２０６に対して１枚目のプリントのプロセススタートを通知する（ステップＳ７０３）。これを受けてエンジン２０６が１枚目の給紙を開始し、その旨をＳＣＳ２０３に通知すると（ステップＳ７０４）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝える（ステップＳ７０５）。これを受けてｘＣＳ２０４はＳＣＳ２０３に対して２枚目のプリントのプロセススタートを通知し（ステップＳ７０６）、ＳＣＳ２０３はエンジン２０６に対して２枚目のプリントのプロセススタートを通知し（ステップＳ７０７）、エンジン２０６は２枚目の給紙を開始するとその旨をＳＣＳ２０３に伝える（ステップＳ７０８）。
【００１７】
この後、リブート対象の故障が発生すると（ステップＳ７０９）、ＳＣＳ２０３からエンジン２０６に対して動作抑制およびプロセスキャンセルの通知が行われ（ステップＳ７１０〜Ｓ７１２）、ほぼ同時にｘＣＳ２０４およびアプリ２０１に対しても動作抑制の通知が行われる（ステップＳ７１３、Ｓ７１４）。
【００１８】
エンジン２０６は可能な範囲でプロセスのキャンセルを試みるが、既に処理に入ってしまった１枚目のプリントのキャンセルが間に合わなかったものとすると、そのプリントを実行し、定着が終わった段階でエンジン側のメカカウンタをアップし（ステップＳ７１５）、１枚目の定着完了をＳＣＳ２０３に通知する（ステップＳ７１６）。これを受けてＳＣＳ２０３はコントローラ側のトータルカウンタをアップし（ステップＳ７１７）、エンジン２０６に対してカウント要求を行い（ステップＳ７１８）、これを受けてエンジン２０６はエンジン側の課金装置のカウンタをアップする（ステップＳ７１９）。
【００１９】
その後、エンジン２０６は１枚目を正常に排紙した段階でＳＣＳ２０３に対してその旨を通知し（ステップＳ７２０）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝え（ステップＳ７２１）、ｘＣＳ２０４はそれを更にアプリ２０１に伝えようとする（ステップＳ７２２）。しかしながら、この時点では既にｘＣＳ２０４は動作抑制に入っているため、インタフェースの抑制によりアプリ２０１に対する通知は行えない状態になっている。従って、続くアプリ２０１からＳＣＳ２０３に対して行われるはずのカウント要求（ステップＳ７２３）も行えず、ＳＣＳ２０３はコントローラ側の課金装置のカウンタをアップすることができない（ステップＳ７２４）。
【００２０】
その後、エンジン２０６は２枚目のプリントをキャンセルしたことにより、異常排紙（白紙のままの排紙）を行い、その旨をＳＣＳ２０３に伝え（ステップＳ７２５）、ＳＣＳ２０３はそれを更にｘＣＳ２０４に伝える（ステップＳ７２６）。
【００２１】
以上の動作から明らかなように、１枚目のプリントは正常に行われ、エンジン側のメカカウンタ、エンジン側の課金装置のカウンタ、コントローラ側のトータルカウンタについてはアップが行われるが、コントローラ側の課金装置のカウンタについてはアップが行われず、カウンタの値の不整合が生ずるものである。
【００２２】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し自動リブートを行う場合に、課金やその他の管理上の必要性から設けられる各種カウンタの値に不整合が生じない画像形成装置および自動リブート方法を提供することにある。
【課題を解決するための手段】
【００２３】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、画像形成に使用されるハードウェア資源と、画像形成にかかる処理を行うプログラムとを有する画像形成装置において、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する手段と、上記リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作停止を行う手段と、上記ハードウェア資源および上記プログラムをリブートする手段とを備えるようにしている。
【００２４】
また、請求項２に記載されるように、上記プログラムのコントローラ側に設けられるトータルカウンタと、上記コントローラ側に設けられる課金装置のカウンタと、ハードウェア資源のエンジン側に設けられるメカカウンタと、上記エンジン側に設けられる課金装置のカウンタとを備えるようにすることができる。
【００２５】
また、請求項３に記載されるように、上記動作停止は、ジョブの停止および新たなプロセス制御の発生停止を含むようにすることができる。
【００２６】
また、請求項４に記載されるように、上記ジョブの停止により、上記プログラムのアプリは未完了のジョブのキャンセルを行うようにすることができる。
【００２７】
また、請求項５に記載されるように、上記動作停止の完了の後であって上記リブートの前に上記ハードウェア資源および上記プログラムの動作抑制を行うようにすることができる。
【００２８】
また、請求項６に記載されるように、上記動作抑制に対して上記ハードウェア資源および上記プログラムから応答があってからリブートの実行まで所定の時間待機するようにすることができる。
【００２９】
また、請求項７に記載されるように、リブート対象となる故障は、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障が所定の枚数の印刷を行う間に所定の回数に達しない範囲で発生した場合とすることができる。
【００３０】
また、請求項８に記載されるように、上記所定の枚数は１０とし、上記所定の回数は２とすることができる。
【００３１】
また、請求項９に記載されるように、上記各手段は、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行うシステムコントロールサービスの一機能として構成することができる。
【００３２】
また、請求項１０に記載されるように、上記ハードウェア資源および上記プログラムのリブートは、エンジンのリセット、ハードディスクドライブのアクセス停止、エンジン電源のＯＦＦ、エンジン電源のＯＮ、アプリのリブートを順次に行うようにすることができる。
【００３３】
また、請求項１１に記載されるように、上記リブート対象となる故障を検出した場合に自動リブートの実行開始を知らせる画面を表示するようにすることができる。
【００３４】
また、請求項１２に記載されるように、上記自動リブートの実行開始を知らせる画面は、上記ハードウェア資源および上記プログラムの後処理の進行状況を示す表示を含むようにすることができる。
【００３５】
また、請求項１３に記載されるように、上記自動リブートの実行開始を知らせる画面は、リブート実行までの時間を示す表示を含むようにすることができる。
【００３６】
また、請求項１４に記載されるように、上記自動リブートの実行開始を知らせる画面は、即座にリブートの開始を指示するボタンを含むようにすることができる。
【００３７】
また、請求項１５に記載されるように、上記リブートの実行後にユーザに確認を求める画面を表示するようにすることができる。
【００３８】
また、請求項１６〜１８に記載されるように、画像形成に使用されるハードウェア資源と画像形成にかかる処理を行うプログラムとを有する画像形成装置における電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障のうちリブート対象となる故障を検出する工程と、上記リブート対象となる故障を検出した直後に上記ハードウェア資源および上記プログラムの動作停止を行う工程と、上記ハードウェア資源および上記プログラムをリブートする工程とを備える自動リブート方法として構成することができる。
【発明の効果】
【００３９】
本発明にあっては、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障に対し自動リブートを行う場合に、課金やその他の管理上の必要性から設けられる各種カウンタの値に不整合が生じないという効果がある。
【発明を実施するための最良の形態】
【００４０】
以下、本発明の好適な実施形態につき図面を参照して説明する。
【００４１】
図１は本発明の一実施形態にかかる画像形成装置の構成図である。
【００４２】
図１において、画像形成装置１は、ソフトウェア群２と、画像形成装置起動部３と、ハードウェア資源４とを含むように構成される。
【００４３】
画像形成装置起動部３は画像形成装置１の電源投入時に最初に実行され、アプリケーション層５およびプラットホーム層６を起動する。例えば画像形成装置起動部３は、アプリケーション層５およびプラットホーム層６のプログラムを、ハードディスク装置（以下、ＨＤＤという）などから読み出し、読み出した各プログラムをメモリ領域に転送して起動する。ハードウェア資源４は、スキャナ２５と、プロッタ２６と、ＡＤＦ（Auto Document Feeder）などのハードウェアリソース２４とを含む。
【００４４】
また、ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットホーム層６とを含む。アプリケーション層５は、プリンタ、コピー、ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。
【００４５】
アプリケーション層５は、プリンタ用のアプリケーションであるプリンタアプリ９と、コピー用アプリケーションであるコピーアプリ１０と、ファックス用アプリケーションであるファックスアプリ１１と、スキャナ用アプリケーションであるスキャナアプリ１２とを含む。
【００４６】
また、プラットホーム層６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層７と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層７からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）２１と、ＳＲＭ２１からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層８とを含む。
【００４７】
コントロールサービス層７は、ネットワークコントロールサービス（以下、ＮＣＳという）１３、デリバリーコントロールサービス（以下、ＤＣＳという）１４、オペレーションパネルコントロールサービス（以下、ＯＣＳという）１５、ファックスコントロールサービス（以下、ＦＣＳという）１６、エンジンコントロールサービス（以下、ＥＣＳという）１７、メモリコントロールサービス（以下、ＭＣＳという）１８、ユーザインフォメーションコントロールサービス（以下、ＵＣＳという）１９、システムコントロールサービス（以下、ＳＣＳという）２０など、一つ以上のサービスモジュールを含むように構成されている。
【００４８】
なお、プラットホーム層６は予め定義されている関数により、アプリケーション層５からの処理要求を受信可能とするＡＰＩ２８を有するように構成されている。ＯＳは、アプリケーション層５およびプラットホーム層６の各ソフトウェアをプロセスとして並列実行する。
【００４９】
ＮＣＳ１３のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。
【００５０】
例えばＮＣＳ１３は、ネットワークを介して接続されるネットワーク機器とのデータ通信をｈｔｔｐｄ（HyperText Transfer Protocol Daemon）により、ＨＴＴＰ（HyperText Transfer Protocol）で制御する。
【００５１】
ＤＣＳ１４のプロセスは、蓄積文書の配信などの制御を行う。ＯＣＳ１５のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。ＦＣＳ１６のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックス送受信、バックアップ用のメモリで管理されている各種ファックスデータの登録／引用、ファックス読み取り、ファックス受信印刷などを行うためのＡＰＩを提供する。
【００５２】
ＥＣＳ１７のプロセスは、スキャナ２５、プロッタ２６、その他のハードウェアリソース２４などのエンジン部の制御を行う。ＭＣＳ１８のプロセスは、メモリの取得および解放、ＨＤＤの利用などのメモリ制御を行う。ＵＣＳ１９は、ユーザ情報の管理を行うものである。
【００５３】
ＳＣＳ２０のプロセスは、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行う。
【００５４】
ＳＲＭ２１のプロセスは、ＳＣＳ２０と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ２１のプロセスは、スキャナ２５やプロッタ２６などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、実行制御する。
【００５５】
具体的に、ＳＲＭ２１のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないかどうか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。また、ＳＲＭ２１のプロセスは上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（例えば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００５６】
また、ハンドラ層８は後述するファックスコントロールユニット（以下、ＦＣＵという）の管理を行うファックスコントロールユニットハンドラ（以下、ＦＣＵＨという）２２と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（以下、ＩＭＨという）２３とを含む。ＳＲＭ２１およびＦＣＵＨ２２は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信可能とするエンジンＩ／Ｆ２７を利用して、ハードウェア資源４に対する処理要求を行う。
【００５７】
画像形成装置１は、各アプリケーションで共通的に必要な処理をプラットホーム層６で一元的に処理することができる。次に、画像形成装置１のハードウェア構成について説明する。
【００５８】
図２は本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。
【００５９】
図２において、画像形成装置１は、コントローラボード３０と、オペレーションパネル４３と、ＦＣＵ４４と、エンジン４７とを含む。また、ＦＣＵ４４は、Ｇ３規格対応ユニット４５と、Ｇ４規格対応ユニット４６とを有する。
【００６０】
また、コントローラボード３０は、ＣＰＵ３１と、ＡＳＩＣ４０と、ＨＤＤ４２と、システムメモリ（ＭＥＭ−Ｐ）３２と、ローカルメモリ（ＭＥＭ−Ｃ）４１と、ノースブリッジ（以下、ＮＢと記す）３３と、サウスブリッジ（以下、ＳＢと記す）３４と、ＮＩＣ３５（Network Interface Card）と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とを含む。
【００６１】
オペレーションパネル４３は、コントローラボード３０のＡＳＩＣ４０に接続されている。また、ＳＢ３４と、ＮＩＣ３５と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とは、ＮＢ３３にＰＣＩバスで接続されている。
【００６２】
また、ＦＣＵ４４と、エンジン４７は、コントローラボード３０のＡＳＩＣ４０にＰＣＩバスで接続されている。
【００６３】
なお、コントローラボード３０は、ＡＳＩＣ４０にＭＥＭ−Ｃ４１、ＨＤＤ４２などが接続されると共に、ＣＰＵ３１とＡＳＩＣ４０とがＣＰＵチップセットのＮＢ３３を介して接続されている。このように、ＮＢ３３を介してＣＰＵ３１とＡＳＩＣ４０とを接続すれば、ＣＰＵ３１のインタフェースが公開されていない場合に対応できる。
【００６４】
また、ＡＳＩＣ４０とＮＢ３３とはＰＣＩバスを介して接続されているのでなく、ＡＧＰ（Accelerated Graphics Port）３９を介して接続されている。このように、図１のアプリケーション層５やプラットホーム層６を形成する一つ以上のプロセスを実行制御するため、ＡＳＩＣ４０とＮＢ３３とを低速のＰＣＩバスでなくＡＧＰ３９を介して接続し、パフォーマンスの低下を防いでいる。
【００６５】
ＣＰＵ３１は、画像形成装置１の全体制御を行うものである。ＣＰＵ３１は、図１のＮＣＳ１３、ＤＣＳ１４、ＯＣＳ１５、ＦＣＳ１６、ＥＣＳ１７、ＭＣＳ１８、ＵＣＳ１９、ＳＣＳ２０、ＳＲＭ２１、ＦＣＵＨ２２、ＩＭＨ２３をＯＳ上にそれぞれプロセスとして起動して実行させると共に、アプリケーション層５を形成するプリンタアプリ９、コピーアプリ１０、ファックスアプリ１１、スキャナアプリ１２を起動して実行させる。
【００６６】
ＮＢ３３は、ＣＰＵ３１、ＭＥＭ−Ｐ３２、ＳＢ３４およびＡＳＩＣ４０を接続するためのブリッジである。ＭＥＭ−Ｐ３２は、画像形成装置１の描画用メモリなどとして用いるメモリである。ＳＢ３４は、ＮＢ３３とＰＣＩバス、周辺デバイスとを接続するためのブリッジである。また、ＭＥＭ−Ｃ４１はコピー用画像バッファ、符号バッファとして用いるメモリである。
【００６７】
ＡＳＩＣ４０は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＨＤＤ４２は、画像の蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積などを行うためのストレージである。また、オペレーションパネル４３は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。
【００６８】
図３は故障対応のために図１のＳＣＳ２０内に設けられた機能部の構成例を示すブロック図である。なお、故障対応に関する部分のみを示している。
【００６９】
図３において、ＳＣＳ２０には、前述したタイプＡおよびタイプＤの故障を検出する故障検出部２０ａと、発生した故障をログに書き込むログ書込部２０ｂと、電源のＯＦＦ／ＯＮによって復旧する可能性の高いタイプＤの故障のうちリブート対象となる故障（例えば印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回に達しない範囲で発生する場合、すなわち１回目のタイプＤの故障）を検出するリブート対象故障検出部２０ｃとを含んでいる。
【００７０】
また、ＳＣＳ２０には、故障発生時に自動通報および自動リブートに関する画面を表示する画面表示制御部２０ｄと、タイプＡの故障もしくはタイプＤの故障が所定の頻度で発生した場合（例えば印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回発生した場合）にＣＳＳ（Customer Satisfaction Service）と呼ばれる自動通報機能あるいはネットワークを利用した診断サービスであるＮＲＳ（New Remote Service）を使用してサービスセンタに自動通報を行う自動通報制御部２０ｅとを含んでいる。
【００７１】
更に、ＳＣＳ２０には、リブート対象となる故障を検出した直後に、リブートに先立って、画像形成装置１のハードウェア資源４であるエンジンやプログラム（ソフトウェア群２）に対して動作停止（ジョブの停止、新たなプロセス制御の発生停止等を含む）を行う動作停止制御部２０ｆと、動作停止の応答を待ってエンジンやプログラムに対して動作抑制（新たな動作の抑制、プロセス間通信の抑制、ＨＤＤへのアクセスの抑制等を含む）を行う動作抑制制御部２０ｇと、画像形成装置１のエンジンやプログラムに対して一連のリブート（リセット）処理を行うリブート実行制御部２０ｈとを含んでいる。
【００７２】
図４は故障発生時における画像形成装置の動作を示す操作フロー図である。
【００７３】
図４において、タイプＡもしくはタイプＤの故障が発生すると（ステップＳ１０１）、タイプＡの故障の場合もしくはタイプＤの故障であってリブート対象とならない場合（印刷枚数をカウントするトータルカウンタが１０カウントアップする間にタイプＤの故障が２回発生した場合）には、画像形成装置１にＣＳＳもしくはＮＲＳによる自動通報機能があってその機能が有効である場合は、故障時自動通報画面を表示してサービスセンタに自動通報を行う（ステップＳ１０２）。そして、通報が成功した場合はサービスマンによる修理を待つ旨が表示され（ステップＳ１０３）、あるいは別パターンとして営業時間外であるため対応が次営業日になる旨が表示され（ステップＳ１０５）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１０４、Ｓ１０６）。また、通報が失敗した場合はユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ１０７）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１０８）。
【００７４】
また、タイプＤの故障であってリブート対象となる場合（１回目の発生の場合）には、画像形成装置１の自動通報機能が有効である場合であっても自動通報は行われず、自動リブートの実行開始を知らせる画面が表示される（ステップＳ１０９）。この画面では、リブートにより処理内容が消去されるため再び作業をやり直す必要がある旨が表示されるほか、ハードウェア資源およびプログラムのリブートのための後処理の進行状況を示す表示と、リブート実行までの時間を示す表示と、即座にリブートの開始を指示するボタンとが含まれている。ここで、後処理は、動作停止および動作抑制による処理であり、各種カウンタの不整合を起こさないようにジョブの停止や新たなプロセス制御の発生停止を行うとともに、エンジンに紙が残らないようにしたり、ＨＤＤの故障等を起こさないよう、適切なリブートが行えるようにするための処理である。また、リブート実行までの時間として、後処理が終了してリブートが行えるようになってから例えば３０秒の待機時間を設けている。これは、後処理が短時間に終了した場合には自動リブートの開始を伝える画面が短時間しか表示されず、ユーザに充分に認識させることができないからである。また、即座にリブートの開始を指示するボタンを設けているのは、作業を急いでいる場合に所定の待機時間を待つことなくリブートを実施し、早急な復旧を図るためである。
【００７５】
自動リブートの実行開始を知らせる画面が表示されてから所定の待機時間が経過した場合には自動リブートが実行され（ステップＳ１１０）、自動リブートを実行したことをユーザに伝えて確認を求める画面が表示される（ステップＳ１１１）。そして、ユーザが確認のボタンを押すことで、通常画面に移行する（ステップＳ１１２）。
【００７６】
また、自動リブートの実行開始を知らせる画面からユーザによって即座にリブートの開始を指示するボタンが押された場合には、所定の待機時間を経ることなしに自動リブートが実行され（ステップＳ１１３）、通常画面に移行する（ステップＳ１１２）。この場合は自動リブートを実行したことをユーザに伝えて確認を求める画面（ステップＳ１１１）は省略される。
【００７７】
一方、画像形成装置１の自動通報機能が無効であるか自動通報機能自体が存在しない機種である場合、タイプＡの故障の場合もしくはタイプＤの故障であってリブート対象とならない場合には、ユーザにサービスセンタへ連絡すべき旨が表示され（ステップＳ１１７）、電源のＯＦＦ／ＯＮを待つ状態になる（ステップＳ１１８）。
【００７８】
また、タイプＤの故障であってリブート対象となる場合には、自動通報機能が有効な場合（ステップＳ１０９）と同様の自動リブートの実行開始を知らせる画面が表示され（ステップＳ１１４）、所定の待機時間が経過した場合には自動リブートが実行され（ステップＳ１１５）、自動リブートを実行したことをユーザに伝えて確認を求める画面が表示され（ステップＳ１１１）、ユーザが確認のボタンを押すことで通常画面に移行する（ステップＳ１１２）。また、自動リブートの実行開始を知らせる画面からユーザによって即座にリブートの開始を指示するボタンが押された場合には、所定の待機時間を経ることなしに自動リブートが実行され（ステップＳ１１６）、通常画面に移行する（ステップＳ１１２）。
【００７９】
以上の動作により、電源のＯＦＦ／ＯＮによって復旧する可能性の高い故障であって自動通報を行うまでもないと考えられる故障については、ユーザの手を煩わすことなく適切かつ自動的にリブートが行われることになる。
【００８０】
次に、図５はリブート対象故障発生時における画像形成装置の動作を示すシーケンス図である。
【００８１】
図５において、ＳＣＳ２０およびＳＲＭ２１は図１に同符号を付して示したものに対応している。また、アプリ１０１、１０２は、図１におけるプリンタアプリ９、コピーアプリ１０、ファックスアプリ１１、スキャナアプリ１２に対応しており、エンジン１０３は図１におけるハードウェア資源４に対応している。ｘＣＳ１０４は図１におけるＮＣＳ１３、ＤＣＳ１４、ＦＣＳ１６、ＥＣＳ１７、ＭＣＳ１８、ＵＣＳ１９等のコントロールサービス層７のプロセスに対応している。なお、リブートにかかる処理は図３に示したＳＣＳ２０内の機能部によって主として行われる。
【００８２】
図５において、リブート対象となる故障（タイプＤの故障であって１回目の発生の場合）が発生し、ＳＣＳ２０がこれを検出すると（ステップＳ２０１）、自動リブートの実行開始を知らせる画面を表示し（ステップＳ２０２）、ほぼ同時に、アプリ１０１、１０２に対して動作停止を通知するとともに（ステップＳ２０３、Ｓ２０４）、ＳＲＭ２１を介してエンジン１０３に対して動作停止を通知する（ステップＳ２０５、Ｓ２０６）。これにより、アプリ１０１、１０２は動作停止処理に入り、ジョブの停止等を行い（ステップＳ２０７）、動作停止処理が完了した段階で動作停止の応答をＳＣＳ２０に通知する（ステップＳ２１０、Ｓ２１１）。また、エンジン１０３も新たなプロセス制御を行わない状態となり、動作停止の応答をＳＣＳ２０に通知する（ステップＳ２０８、Ｓ２０９）。
【００８３】
次いで、ＳＣＳ２０は各部からの応答を確認した上で（ステップＳ２１２）、ｘＣＳ１０４へ、ＳＲＭ２１を介してエンジン１０３へ、そしてアプリ１０１、１０２へ、ほぼ同時に動作抑制の通知を行い（ステップＳ２１３〜Ｓ２１７）、各部に動作抑制処理（仕掛かり中の処理を区切りのよいリブートが安全に行える状態で動作停止するための後処理、インタフェースの抑制を行うことによる新たな動作の抑制等）を行わせ、各部から動作抑制の応答があった後（ステップＳ２１８〜Ｓ２２２）、リブートを実行する（ステップＳ２２３）。そして、自動リブートを実行したことをユーザに伝えて確認を求める画面を表示する（ステップＳ２２４）。
【００８４】
次に、図６はリブート対象故障発生時におけるカウンタ関連動作を示すシーケンス図である。なお、図６は、プリントの途中で図５におけるリブート対象となる故障が発生（ステップＳ２０１）してから動作抑制通知（ステップＳ２１６、Ｓ２１７）が行われるまでを示している。また、図６では連続して２枚のプリントを行う場合を想定している。
【００８５】
図６において、アプリ１０１からｘＣＳ１０４にプリントのジョブスタートが通知されると（ステップＳ３０１）、ｘＣＳ１０４はＳＣＳ２０に対して１枚目のプリントのプロセススタートを通知し（ステップＳ３０２）、ＳＣＳ２０はエンジン１０３に対して１枚目のプリントのプロセススタートを通知する（ステップＳ３０３）。これを受けてエンジン１０３が１枚目の給紙を開始し、その旨をＳＣＳ２０に通知すると（ステップＳ３０４）、ＳＣＳ２０はそれを更にｘＣＳ１０４に伝える（ステップＳ３０５）。これを受けてｘＣＳ１０４はＳＣＳ２０に対して２枚目のプリントのプロセススタートを通知し（ステップＳ３０６）、ＳＣＳ２０はエンジン１０３に対して２枚目のプリントのプロセススタートを通知し（ステップＳ３０７）、エンジン１０３は２枚目の給紙を開始するとその旨をＳＣＳ２０に伝える（ステップＳ３０８）。
【００８６】
この後、リブート対象の故障が発生すると（ステップＳ３０９）、ＳＣＳ２０はアプリ１０１に対して動作停止要求を行う（ステップＳ３１０）。これを受けてアプリ１０１はｘＣＳ１０４に対してジョブキャンセルを通知し（ステップＳ３１１）、ｘＣＳ１０４はＳＣＳ２０に対して１枚目のプロセスキャンセルを通知し（ステップＳ３１２）、ＳＣＳ２０はそれをエンジン１０３に伝える（ステップＳ３１３）。続いて、同様に、ｘＣＳ１０４はＳＣＳ２０に対して２枚目のプロセスキャンセルを通知し（ステップＳ３１４）、ＳＣＳ２０はそれをエンジン１０３に伝える（ステップＳ３１５）。
【００８７】
エンジン１０３は可能な範囲でプロセスのキャンセルを試みるが、既に処理に入ってしまった１枚目のプリントのキャンセルが間に合わなかったものとすると、そのプリントを実行し、定着が終わった段階でエンジン側のメカカウンタをアップし（ステップＳ３１６）、１枚目の定着完了をＳＣＳ２０に通知する（ステップＳ３１７）。これを受けてＳＣＳ２０はコントローラ側のトータルカウンタをアップし（ステップＳ３１８）、エンジン１０３に対してカウント要求を行い（ステップＳ３１９）、これを受けてエンジン１０３はエンジン側の課金装置のカウンタをアップする（ステップＳ３２０）。
【００８８】
その後、エンジン１０３は１枚目を正常に排紙した段階でＳＣＳ２０に対してその旨を通知し（ステップＳ３２１）、ＳＣＳ２０はそれを更にｘＣＳ１０４に伝え（ステップＳ３２２）、ｘＣＳ１０４はそれを更にアプリ１０１に伝える（ステップＳ３２３）。この場合、動作抑制とは異なり動作停止ではインタフェース等の抑制は行われないので、正常に伝わる。従って、これを受けてアプリ１０１はＳＣＳ２０に対してカウント要求を行い（ステップＳ３２４）、ＳＣＳ２０はコントローラ側の課金装置のカウンタをアップする（ステップＳ３２５）。
【００８９】
その後、エンジン１０３は２枚目のプリントをキャンセルしたことにより、異常排紙（白紙のままの排紙）を行い、その旨をＳＣＳ２０に伝え（ステップＳ３２６）、ＳＣＳ２０はそれを更にｘＣＳ１０４に伝え（ステップＳ３２７）、ｘＣＳ１０４は更にそれをアプリ１０１に伝える（ステップＳ３２８）。これによって継続していたプリントのジョブに関するプロセスの動作停止が完了したため、ｘＣＳ１０４はアプリ１０１に対してジョブ終了を通知し（ステップＳ３２９）、アプリ１０１はＳＣＳ２０に対して動作停止の応答を通知する（ステップＳ３３０）。
【００９０】
その後、ＳＣＳ２０は他の部分からの動作停止応答を待ち（所定のタイムアップが設けられている）、動作抑制の処理に入る（ステップＳ３３１、Ｓ３３２）。
【００９１】
以上の動作から明らかなように、正常に行われた１枚目のプリントにつき、エンジン側のメカカウンタ、エンジン側の課金装置のカウンタ、コントローラ側のトータルカウンタ、コントローラ側の課金装置のカウンタのそれぞれが正常にアップすることとなり、不整合が生ずることはない。
【００９２】
次に、図７は図５における動作抑制からリブート実行（ステップＳ２１３〜Ｓ２２３）までの動作を示すシーケンス図である。
【００９３】
図７において、ＳＣＳ２０はｘＣＳ１０４、アプリ１０１、１０２、エンジン１０３に対して動作抑制の通知を行う（ステップＳ４０１〜Ｓ４０４）。動作抑制の通知を受けた各部は、後処理として、仕掛かり中の処理を区切りのよい、リブートが安全に行える状態で動作停止し、インタフェースの抑制を行うことで新たな動作を抑制し、ＳＣＳ２０に対して応答を通知する（ステップＳ４０５〜Ｓ４０８）。ＳＣＳ２０は応答の受付を例えば３分間でタイムアウトする。
【００９４】
次いで、ＳＣＳ２０は例えば３０秒間の待機を行い（ステップＳ４０９）、リブートの実行に入る。ここで、ＯＣＳ１５に対して操作部ドライバの通信停止要求を行うが、関数内でブロックされるため応答はない（ステップＳ４１０）。続いて、ＳＣＳ２０はエンジン１０３に対してリセット要求を行い（ステップＳ４１１）、エンジン１０３から応答を受け取る（ステップＳ４１２）。そして、ＨＤＤのアクセス停止処理（ステップＳ４１３）、エンジン電源のＯＦＦ（ステップＳ４１４）、エンジン電源のＯＮ（ステップＳ４１５）、アプリ１０１、１０２のリブート実行（ステップＳ４１６）を順次に行い、エンジン１０３に対してコントローラ起動を行い（ステップＳ４１７）、エンジン１０３からエンジンコンフィグを受け取る（ステップＳ４１８）。
【００９５】
このように、各モジュールの動作抑制を行い、動作中の処理の後始末とインタフェースの抑制を行うことで、残紙やＨＤＤ故障やデータのゴミ等を生ずることなく、速やかにリブートを行うことができる。
【図面の簡単な説明】
【００９６】
【図１】本発明の一実施形態にかかる画像形成装置の構成図である。
【図２】本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。
【図３】ＳＣＳ内の故障対応のための機能部の構成例を示すブロック図である。
【図４】故障発生時における画像形成装置の動作を示す操作フロー図である。
【図５】リブート対象故障発生時における画像形成装置の動作を示すシーケンス図である。
【図６】リブート対象故障発生時におけるカウンタ関連動作を示すシーケンス図である。
【図７】動作抑制からリブート実行までの動作を示すシーケンス図である。
【図８】通常時のカウンタ関連動作を示すシーケンス図である。
【図９】リブート対象故障発生時の従来の動作を示すシーケンス図である。
【図１０】リブート対象故障発生時の従来のカウンタ関連動作を示すシーケンス図である。
【符号の説明】
【００９７】
１        画像形成装置
１５      ＯＣＳ
２０      ＳＣＳ
２０ａ    故障検出部
２０ｂ    ログ書込部
２０ｃ    リブート対象故障検出部
２０ｄ    画面表示制御部
２０ｅ    自動通報制御部
２０ｆ    動作停止制御部
２０ｇ    動作抑制制御部
２０ｈ    リブート実行制御部
２１      ＳＲＭ
１０１    アプリ
１０２    アプリ
１０３    エンジン
１０４    ｘＣＳ
【図１】
2005229210.tif 000003
【図２】
2005229210.tif 000004
【図３】
2005229210.tif 000005
【図４】
2005229210.tif 000006
【図５】
2005229210.tif 000007
【図６】
2005229210.tif 000008
【図７】
2005229210.tif 000009
【図８】
2005229210.tif 000010
【図９】
2005229210.tif 000011
【図１０】
2005229210.tif 000012