(57)【要約】【課題】画像形成システムの障害の診断を的確に行うとともに、診断アプリケーションの開発等を画像形成システムのハードウェアを制御する制御プログラムから切り離すことで開発等を容易にする。【解決手段】画像データに基づいて画像を形成し、前記画像を用紙に出力するプリンター部と、第１のオペレーティングシステムと、前記第１のオペレーティングシステム上で起動して前記プリンター部を含む自機のハードウェア資源の制御を行う制御プログラムと、少なくとも一つのアプリケーションが動作可能な第２のオペレーティングシステムと、が少なくとも動作する制御部と、を備え、制御部は、第２のオペレーティングシステム上で起動し、自機の画像形成システムの診断を行う診断アプリケーションを動作可能とする。【選択図】図３
2014219915.tif 000002
【特許請求の範囲】
【請求項１】
画像データに基づいて画像を形成し、前記画像を用紙に出力するプリンター部と、
第１のオペレーティングシステムと、前記第１のオペレーティングシステム上で起動して前記プリンター部を含む自機のハードウェア資源の制御を行う制御プログラムと、少なくとも一つのアプリケーションが動作可能な第２のオペレーティングシステムと、が少なくとも動作する制御部と、を備え、
前記制御部は、前記第２のオペレーティングシステム上で起動し、自機の画像形成システムの診断を行う診断アプリケーションが動作可能であることを特徴とする画像形成システム。
【請求項２】
前記制御プログラムは、前記診断アプリケーションに対し、自機の画像形成システムの診断に必要な情報を取得して提供する機能と、自機の画像形成システムで障害が発生している際に復旧に必要な作業要求を受け付けて自機の画像形成システムを動作させて前記作業を実行する機能とを有することを特徴とする請求項１記載の画像形成システム。
【請求項３】
前記診断アプリケーションは、前記制御プログラムに対し、自機の画像形成システムの診断に必要な情報を要求する機能と、前記情報に基づいて自機の画像形成システムで障害が発生している際に復旧に必要な作業の実行を要求する機能とを有することを特徴とする請求項２記載の画像形成システム。
【請求項４】
前記診断アプリケーションは、自機の画像形成システムの診断に必要な情報を取得し、前記情報に基づいて自機の画像形成システムで障害が発生している際に自機の画像形成システムを動作させて復旧に必要な作業を実行する機能を有することを特徴とする請求項１〜３のいずれかに記載の画像形成システム。
【請求項５】
前記診断アプリケーションは、復旧に必要な作業の一つとして制御プログラムに対し再起動要求を行うことを特徴とする請求項１〜４のいずれか１項に記載の画像形成システム。
【請求項６】
前記制御プログラムは、前記診断アプリケーションから自機の画像形成システムの再起動要求を受け付けると、再起動前に第２のオペレーティングシステムに関するスナップショットを記憶部に退避させることを特徴とする請求項５に記載の画像形成システム。
【請求項７】
前記制御プログラムは、自機の画像形成システムの再起動要求を受け付けると、第２のオペレーティングシステムのスナップショットが記憶部に保存されていれば、該スナップショットを取得して自機の画像形成システムの再起動を行うことを特徴とする請求項１〜６のいずれか１項に記載の画像形成システム。
【請求項８】
前記制御プログラムは、通常時には自機の画像形成装置の動作を通常時のモードにし、前記診断に際しては、前記診断アプリケーションの要求に基づいて自機の画像形成装置の動作を診断に適したモードに切り替えることを特徴とする請求項１〜７のいずれか１項に記載の画像形成システム。
【請求項９】
前記診断アプリケーションは、前記再起動後の画像形成システムの状態に応じて、必要であれば前記制御プログラムに対して、診断に適した前記モードへの切り替えを要求することを特徴とする請求項８に記載の画像形成システム。
【請求項１０】
前記診断アプリケーションが、外部記憶装置に格納されていることを特徴とする請求項１〜９のいずれか１項に記載の画像形成システム。
【請求項１１】
前記診断アプリケーションと前記制御プログラムとの間で通信を行う通信部を有することを特徴とする請求項１〜１０のいずれか１項に記載の画像形成システム。
【請求項１２】
第１のオペレーティングシステムと、前記第１のオペレーティングシステム上で起動してプリンター部を含む自機のハードウェア資源の制御を行う制御プログラムと、少なくとも一つのアプリケーションが動作可能な第２のオペレーティングシステムと、が少なくとも動作する画像形成システムの診断方法であって、
前記制御プログラムによって前記第２のオペレーティングシステム上で診断アプリケーションを起動させる起動ステップと、前記診断アプリケーションによって自機の画像形成装置の診断を行う診断ステップとを有することを特徴とする画像形成システムの診断方法。
【請求項１３】
前記診断に基づいて、自機の画像形成システムで障害が発生している際に前記制御プログラムまたは前記診断アプリケーションによって自機の画像形成システムを動作させて復旧に必要な作業を実行する復旧ステップを有することを特徴とする請求項１２記載の画像形成システムの診断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、画像データに基づいて形成した画像を用紙に出力する画像形成システムおよび該画像形成システムの診断方法に関するものである。
【背景技術】
【０００２】
プリンター、ファクシミリ、複写機および、これら機能を複数有する複合機などの画像形成システムでは、画像データに基づいて画像を形成し、前記画像を用紙に出力する機能を有しており、前記機能は、通常は、ＯＳ（オペレーティングシステム）上で動作するファームウェアによって当該画像形成システムのハードウェアを制御することで実現されている。
このような画像形成システムで障害が発生した場合、例えば、第１ＯＳで障害が発生すると第２ＯＳを起動して、第２ＯＳの管理下で第１ＯＳの障害対応処理を実行するものが提案されている（特許文献１参照）。
また、ＯＳの再起動を高速化するための方法も提案されている。例えば特許文献２では、第２のＯＳを起動する前に、第１のＯＳをメモリの予約領域に退避している。特許文献２では、ＯＳの評価を行う際に、前に行った試験の影響を避けるためにＯＳ再起動をしてから試験を行うと、ＯＳ再起動が頻繁に必要で効率が悪いという観点から、試験前の状態のスナップショットを取得しておき、再起動の代わりにスナップショットから復元を行う。
特許文献３では、ＯＳ終了時にＯＳ初期化データを退避しておき、ＯＳ起動時は退避していた初期化データからＯＳ状態の復元を行う。これにより、ＯＳが高速に再起動できるが、ＯＳ終了時に、アプリケーションが終了されてしまう。そこで、ＯＳ再起動時に、アプリケーション領域のデータを退避しておき、ＯＳ再起動後にアプリケーションを退避しておいたデータから状態を復元する。ＯＳのメモリ領域は触れないことで、ＯＳ自体は再起動でき、ＯＳ再起動後もアプリケーションを継続利用できるようにしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３０１６３９号公報
【特許文献２】特開２０１２−１８１７３７号公報
【特許文献３】国際公開２００５−７１５２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のように、マルチＯＳ構成を用いることで、第１ＯＳ自身の障害対応を行う例は存在する。
しかし、上記した障害の対応処理では、ＯＳに障害が発生した場合を前提としており、装置としての障害を診断することができない。また、ＯＳ自身がハードウェアや装置にアクセスする構成のため、ＯＳとの切り離しが困難であり、診断機能と画像形成に拘わる機能とを分離することができず、診断機能の開発や更新を容易に行うことができないという問題がある。
【０００５】
本発明は、上記事情を背景としてなされてものであり、診断機能の開発と更新が容易であり、また、装置に障害が発生した場合の診断と復旧が容易な画像形成システムおよび画像形成システムの診断方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
すなわち、本発明の画像形成システムは、画像データに基づいて画像を形成し、前記画像を用紙に出力するプリンター部と、第１のオペレーティングシステムと、前記第１のオペレーティングシステム上で起動して前記プリンター部を含む自機のハードウェア資源の制御を行う制御プログラムと、少なくとも一つのアプリケーションが動作可能な第２のオペレーティングシステムと、が少なくとも動作する制御部と、を備え、
前記制御部は、前記第２のオペレーティングシステム上で起動し、自機の画像形成システムの診断を行う診断アプリケーションが動作可能であることを特徴とする。
【０００７】
第２の本発明の画像形成システムは、前記第１の本発明において、前記制御プログラムは、前記診断アプリケーションに対し、自機の画像形成システムの診断に必要な情報を取得して提供する機能と、自機の画像形成システムで障害が発生している際に復旧に必要な作業要求を受け付けて自機の画像形成システムを動作させて前記作業を実行する機能とを有することを特徴とする。
【０００８】
第３の本発明の画像形成システムは、前記第２の本発明において、前記診断アプリケーションは、前記制御プログラムに対し、自機の画像形成システムの診断に必要な情報を要求する機能と、前記情報に基づいて自機の画像形成システムで障害が発生している際に復旧に必要な作業の実行を要求する機能とを有することを特徴とする。
【０００９】
第４の本発明の画像形成システムは、前記第１〜第３の本発明のいずれかにおいて、前記診断アプリケーションは、自機の画像形成システムの診断に必要な情報を取得し、前記情報に基づいて自機の画像形成システムで障害が発生している際に自機の画像形成システムを動作させて復旧に必要な作業を実行する機能を有することを特徴とする。
【００１０】
第５の本発明の画像形成システムは、前記第１〜第４の本発明のいずれかにおいて、前記診断アプリケーションは、復旧に必要な作業の一つとして制御プログラムに対し再起動要求を行うことを特徴とする。
【００１１】
第６の本発明の画像形成システムは、前記第５の本発明において、前記制御プログラムは、前記診断アプリケーションから自機の画像形成システムの再起動要求を受け付けると、再起動前に第２のオペレーティングシステムに関するスナップショットを記憶部に退避させることを特徴とする。
【００１２】
第７の本発明の画像形成システムは、前記第１〜第６の本発明のいずれかにおいて、前記制御プログラムは、自機の画像形成システムの再起動要求を受け付けると、第２のオペレーティングシステムのスナップショットが記憶部に保存されていれば、該スナップショットを取得して自機の画像形成システムの再起動を行うことを特徴とする。
【００１３】
第８の本発明の画像形成システムは、前記第１〜第７の本発明のいずれかにおいて、前記制御プログラムは、通常時には自機の画像形成装置の動作を通常時のモードにし、前記診断に際しては、前記診断アプリケーションの要求に基づいて自機の画像形成装置の動作を診断に適したモードに切り替えることを特徴とする。
【００１４】
第９の本発明の画像形成システムは、前記第８の本発明において、前記診断アプリケーションは、前記再起動後の画像形成システムの状態に応じて、必要であれば前記制御プログラムに対して、診断に適した前記モードへの切り替えを要求することを特徴とする。
【００１５】
第１０の本発明の画像形成システムは、前記第１〜第９の本発明のいずれかにおいて、前記診断アプリケーションが、外部記憶装置に格納されていることを特徴とする。
【００１６】
第１１の本発明の画像形成システムは、前記第１〜第１０の本発明のいずれかにおいて、前記診断アプリケーションと前記制御プログラムとの間で通信を行う通信部を有することを特徴とする。
【００１７】
第１２の本発明の画像形成システムの診断方法は、第１のオペレーティングシステムと、前記第１のオペレーティングシステム上で起動してプリンター部を含む自機のハードウェア資源の制御を行う制御プログラムと、少なくとも一つのアプリケーションが動作可能な第２のオペレーティングシステムと、が少なくとも動作する画像形成システムの診断方法であって、
制御プログラムによって前記第２のオペレーティングシステム上で診断アプリケーションを起動させる起動ステップと、前記診断アプリケーションによって自機の画像形成装置の診断を行う診断ステップとを有することを特徴とする。
【００１８】
第１３の本発明の画像形成システムの診断方法は、前記第１２の本発明において、前記診断に基づいて、自機の画像形成システムで障害が発生している際に前記制御プログラムまたは前記診断アプリケーションによって自機の画像形成システムを動作させて復旧に必要な作業を実行する復旧ステップを有することを特徴とする。
【発明の効果】
【００１９】
以上説明したように、本願発明によれば、第１ＯＳとは異なる第２ＯＳで診断アプリケーションを起動させて画像形成システムの診断を行うことができ、診断を容易に行うことができるとともに、診断機能の開発と更新が容易になる効果がある。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態の画像形成システムにおける画像形成装置のアプリケーションソフトを含むソフトウェア構成とハードウェア資源の概略を示す図である。
【図２】同じく、制御ブロック図である。
【図３】同じく、診断アプリケーションと装置制御ＦＷ間で通信を行う際のソフトウェア構成とハードウェア資源の概略を示す図である。
【図４】同じく、障害が発生した際の復旧の手順を示すフローチャートである。
【図５】同じく、障害が発生した際の復旧の一環である画像形成装置の再起動の手順を示すフローチャートである。
【図６】同じく、障害が発生した際の復旧の一環である画像形成装置の再起動に際しての第２ＯＳ起動の手順を示すフローチャートである。
【図７】従来の画像形成システムにおける画像形成装置のアプリケーションソフトを含むソフトウェア構成とハードウェア資源の概略を示す図である。
【図８】本発明以外の形態における診断を行うシステムを示す概略図である。
【発明を実施するための形態】
【００２１】
以下に、本発明の一実施形態を添付図面に基づいて説明する。
図７に示すように、従来の画像形成装置の構成はハードウェア上に装置制御用ファームウェアを起動させるＯＳ（例えばＬｉｎｕｘ（商標、以下同じ））が搭載され、そのＯＳ上で装置制御用ファームウェアを起動することにより装置が制御されている。装置の制御とはスキャン処理、プリント処理をはじめ画像データをＨＤＤへ保存、熱定着の温度管理、トレイやドアの開閉を検知するセンサなど多岐に亘る。
【００２２】
図１は、本実施形態の画像形成システムにおけるソフトウェア構成とハードウェア資源の概略を示す図である。なお、本願発明の画像形成システムは画像形成装置のみで構成されているものであってもよく、画像形成装置に外部装置が接続されたものや、複数の画像形成装置がネットワークなどによって接続されたもので画像形成システムが構成されるものであってもよい。外部装置としては、大容量給紙装置や後処理装置、端末などが挙げられる。
この図では、第１のオペレーティングシステム（以下第１ＯＳという）で、本発明の制御プログラムに相当する装置制御ファームウェア（以下装置制御ＦＷという）と、エミュレータが動作する。第１ＯＳは、装置制御ＦＷおよびエミュレータを動作させる組み込み向けＯＳであり、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ（いずれも商標、以下同じ）などにより構成される。装置制御ＦＷは、画像形成装置を動作させるソフトウェアである。装置制御ＦＷは、本発明の制御プログラムに相当する。
【００２３】
エミュレータ上では、第１ＯＳ上で動作する第２〜第Ｎ（Ｎは２以上の整数）のオペレーティングシステムとして第２のオペレーティングシステム（以下第２ＯＳという）が動作する。エミュレータは、第１ＯＳ上の一つのアプリケーションとして動作し、装置のＨＷ資源を利用することも可能であり、ハードウェアをエミュレーションして第２ＯＳに提供するソフトウェアであり、例えばＱｅｍｕ（商標、以下同じ）などを用いることができ、本願発明としては特定のものに限定されるものではない。
装置制御ＦＷを起動させる第１ＯＳとは別に、エミュレータを通すなどして第２〜第ＮＯＳを装置上で動作させることをマルチＯＳという。
また、この実施形態では、第１ＯＳ上でエミュレータを介して第２ＯＳが動作するものとして説明しているが、ハイパーバイザー上で、第１ＯＳと第２ＯＳとが並行して動作するものであってもよく、第１ＯＳと第２ＯＳとは並行して動作可能であれば、その構成関係は特に限定されるものではない。
【００２４】
ここで、第１ＯＳは画像形成装置の制御には適した組み込み向けＯＳであり、画像形成に直接関わらないアプリケーションや機能を搭載し実行するには向いていない。そこで、第２ＯＳとしてＷｉｎｄｏｗｓやＡｎｄｒｏｉｄ（商標、以下同じ）などのアプリケーション開発及び実行が容易なＯＳを動作させれば、画像形成装置を補助するための様々なアプリケーションを容易に開発、搭載できるようになる。
以上のように、第２ＯＳは、画像データ編集のアプリケーションなどの汎用的なアプリケーションを動作させるのに適したＯＳであり、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ、ＭａｃＯＳ（商標、以下同じ）などで構成される。
【００２５】
なお、この実施形態では、第１ＯＳ上で動作する第２ＯＳとして、１つのＯＳを有するものを示しているが、本発明としてはその数が特に限定されるものではなく、２つ以上のオペレーティングシステムが動作するものであってもよい。
また、この実施形態では、第２ＯＳが第１ＯＳ上で動作するものとして説明しているが、ハイパーバイザー上で、第１ＯＳと第２ＯＳとが並行して動作するようなものであってもよく、第１ＯＳと第２ＯＳとが並行して動作可能であれば、その構成関係は特に限定されるものではない。
【００２６】
また、第２ＯＳ上では、アプリケーションとして診断アプリケーションが動作可能になっている。
第２ＯＳ上では第２ＯＳ用に作成されたアプリケーションに手を加えること無く動作させることができる。そのため、第２ＯＳ用に存在するライブラリなどの豊富な資産を活用することで、装置制御ＦＷ内に機能を組み込むよりも容易にアプリケーションを作成することができる。この特徴を活かし、第２ＯＳ上で画像形成装置の障害復旧をサポートする診断アプリケーションを動作させることで、画像形成装置に障害が発生した際の復旧作業を効率化することができる。
【００２７】
従来の画像形成システムでは、障害を検知するとエラーコードを操作パネル上などに表示するのみであり、復旧のために必要な作業手順はサービスマニュアルなどを調べなければならない。また、作業に必要な各機能を動作させるには頻繁な画面遷移が必要であり、該当する機能を探すのに多大な手間を必要としている。この問題に対し、制御プログラム内に復旧作業をサポートする機能を追加することで時間短縮を図ることができるが、復旧作業の手順や内容を変更するには制御プログラムの更新が必要になってしまう。また、先に述べたように第１ＯＳは画像形成に関わらないアプリケーションを作成するには手間がかかる。そこで、復旧作業をサポートするための診断アプリケーションを、上記のように第２ＯＳ上で実行するようにすれば、診断アプリケーションと制御プログラムが切り離されるため、アプリケーション更新作業が容易になる。
【００２８】
すなわち、診断アプリケーションを第２ＯＳで動作させることのメリットとして、診断機能と装置制御ＦＷが切り離されるという点が挙げられる。診断機能を装置制御ＦＷの一部として実現した場合、画像形成には直接関わらない診断機能をアップデートするためには装置制御ＦＷ全体の更新が必要であり、装置制御ＦＷの本来機能である画像形成機能への影響を、画像形成機能自体は変更していないにも関わらず確認する必要がある。一方、診断機能を第２ＯＳ上の診断アプリケーションとして分離すれば、診断アプリケーションの更新は単なる第２ＯＳ上のアプリケーション更新になるため、第２ＯＳの動作が装置制御ＦＷへ影響しないように設計してあれば、装置制御ＦＷの更新は不要になる。
【００２９】
上記した第１ＯＳ、第２ＯＳは、画像形成装置に備えられ、本発明のハードウェア資源（以下Ｈ／Ｗという）の一部を使用し、また制御することができる。Ｈ／Ｗには、ＣＰＵ、メモリー、操作部、画像形成装置の主となる機能を果たすスキャナー、ドラム、定着器、給紙トレイ、各種センサ、補助記憶装置であるＨＤＤ、外付けメディア（例えばＵＳＢメモリー）などがある。これらのＨ／Ｗは、第１ＯＳによって全て直接アクセス可能である。一方、第２ＯＳは通常のＰＣなどで動作させるＯＳであり、画像形成装置特有のＨ／Ｗには直接アクセスしない。ただし、通常のＰＣでも使用されるＨＤＤやメモリーといったＨ／Ｗには、第２ＯＳでも、直接アクセスが可能であり、第１ＯＳと共通して使用することができる。
【００３０】
また、上記ＨＤＤでは、装置制御ＦＷ、第１ＯＳ、第２ＯＳ、アプリケーション、プリンタドライバやデータ、各アプリケーションで扱うデータなどを格納することができる。この際に、ＨＤＤは例えば第１ＯＳ用、装置制御ＦＷ用、第２ＯＳのアプリケーション用というように、パーティションを区切っておくことで各アプリケーションによる読み書き領域を制御することができ、また、複数のＨＤＤを用意して第１ＯＳ側と、第２ＯＳ側とで専用のＨＤＤを使用するようにしてもよい。また、アプリケーションは、ＵＳＢ−ＨＤＤなどの外部記憶部などに格納されているものであってもよい。上記ＨＤＤやＵＳＢ−ＨＤＤなどは、本願発明の記憶部に相当する。
【００３１】
次に、本実施形態の画像形成システムにおける制御ブロックを図２に基づいて説明する。
画像形成装置１は、主要な構成として、全体制御ブロック部１００とスキャナー部１３０と操作部１４０とプリンター部１５０とを有している。また、この実施形態では、後処理装置であるＦＮＳ１６０が画像形成システムの一部として画像形成装置に接続されて画像形成システムが構成されている。なお、本発明としては後処理装置の有無は特に限定されるものではない。
【００３２】
画像形成装置１は、ネットワークであるＬＡＮ２を通して外部装置であるＰＣ３などに接続されている。これらＬＡＮ２や、ＰＣ３を含めて画像形成システムとするものであってもよい。画像形成装置１に接続する装置の種別や数は特に限定されるものではない。全体制御ブロック部１００では、制御ＣＰＵ１１０を備えており、制御ＣＰＵ１１０にＤＲＡＭ制御ＩＣ１１１が接続されている。
制御ＣＰＵ１１０には、ＲＡＭ１１２、ＶＲＡＭ１１３が接続されている。
制御ＣＰＵ１１０は、前記装置制御ＦＷなどのソフトウェアの実行により画像形成装置１の全体を制御し、画像形成装置１全体の状態把握を行うものであり、本発明の制御部として機能する。
【００３３】
スキャナー部１３０は、光学読み取りを行うＣＣＤ１３１と、スキャナー部１３０全体の制御を行うスキャナー制御部１３２とを備えている。スキャナー制御部１３２は、制御ＣＰＵ１１０に接続されており、制御ＣＰＵ１１０による制御を受ける。なお、スキャナー制御部１３２は、ＣＰＵやこれを動作させるプログラムなどによって構成することができる。前記ＣＣＤ１３１で読み取った画像情報は、読み取り処理部１１６でデータ処理がなされる。読み取り処理部１１６には、ＤＲＡＭ制御ＩＣ１１１に接続されており、読み取り処理部１１６でデータ処理された画像データはＤＲＡＭ制御ＩＣ１１１に送信される。
【００３４】
ＲＡＭ１１２は、装置制御ＦＷ、第１ＯＳ、第２ＯＳ、アプリケーションプログラム、プリンタドライバ等のプログラムがロードされて、その実行に利用されるとともに、その実行に伴う作業エリアとして利用される。
【００３５】
操作部１４０は、タッチパネル式のＬＣＤ１４１と、操作部制御部１４２とを備えており、上記ＬＣＤ１４１と操作部制御部１４２とが接続され、該操作部制御部１４２と前記制御ＣＰＵ１１０と、がシリアル通信可能に接続されている。該構成によって操作部１４０の制御が制御ＣＰＵ１１０によって行われ、ＶＲＡＭ１１３に描かれた画面画像がＬＣＤ１４１に表示されるとともに、操作部１４０の入力情報が制御ＣＰＵ１１０に送られる。なお、操作部制御部１４２は、ＣＰＵやこれを動作させるプログラムなどによって構成することができる。操作部１４０には、表示切替部１４３を備えており、表示切替部１４３によって、操作部１４０で表示される画面の所定領域に対応するＶＲＡＭ１１３の記憶領域に、装置制御ＦＷが生成した画面、第２ＯＳの画面を選択的に描画することにより、これらの画面を切り替えて表示することを可能にしている。また、ＬＣＤ１４１の第２ＯＳの画面領域への操作は、第２ＯＳに伝えられて第２ＯＳに対する操作を行うこともできるようになっている。
【００３６】
次に、上記画像形成装置１の基本的動作について説明する。
先ず、画像形成装置１において画像情報を蓄積する手順について説明する。
第１に画像形成装置１において、スキャナー部１３０で原稿の画像を読み取り画像情報を生成する場合、スキャナー部１３０において原稿からＣＣＤ１３１により原稿の画像を光学的に読み取る。この際には、制御ＣＰＵ１１０から指令を受けるスキャナー制御部１３２によってＣＣＤ１３１の動作制御を行う。
ＣＣＤ１３１で読み取られた画像は、読み取り処理部１１６でデータ処理がなされ、データ処理された画像情報は、ＤＲＡＭ制御ＩＣ１１１を介して画像メモリー１１４やＨＤＤ１１５に格納される。画像メモリー１１４やＨＤＤ１１５に格納された画像情報や印刷情報は、制御ＣＰＵ１１０によってジョブとして管理することができる。
【００３７】
画像情報を外部から取得する場合、例えば、ＰＣ３からＬＡＮ２を通して送信されるジョブ情報は、ＮＩＣ１２２、制御ＣＰＵ１１０を介してＤＲＡＭ制御ＩＣ１１１により画像メモリー１１４やＨＤＤ１１５に格納される。
また、画像形成装置１でアプリケーションによって画像情報を生成する場合、プリンタドライバ、エミュレータ、装置制御ＦＷを介して得られる画像情報が上記と同様に画像メモリー１１４やＨＤＤ１１５に格納される。この際に、プリンタドライバから送られるプリントデータを画像形成装置のジョブとして受け付け、該ジョブの保存、実行等することができる。
外部からの取得や画像形成装置１で動作するアプリケーションによって取得される画像情報がベクターデータである場合、適宜の時期に、図示しないコントローラーによりＲＩＰ処理（Raster Image Processing）が行われる。
【００３８】
画像形成装置１で画像出力を行う場合、すなわち複写機やプリンターとして使用する場合、画像メモリー１１４やＨＤＤ１１５に格納された画像情報を含むジョブ情報を、ＤＲＡＭ制御ＩＣ１１１を介して書き込み処理部１１７にデータを送出し、書き込み処理部１１７からプリンター部１５０へ書き込みデータが送出される。
【００３９】
プリンター部１５０では、図示しない帯電部によって感光体の表面に一様に帯電を行った後に、ＬＤ１５１のレーザビームによって、書き込みデータに基づく露光走査を行って潜像を形成し、該潜像を現像部により反転現像して感光体の表面にトナー像を形成する。そして給紙トレイから給紙された用紙は、搬送装置によって転写位置へと送られ、該転写位置において転写部によりトナー像が転写される。その後、画像形成がされた用紙は、定着器により加熱定着され、ＦＮＳ１６０へと搬送される。画像形成がなされた用紙が搬送されるＦＮＳ１６０は、用紙にパンチを行うパンチユニットや、用紙にステイプルを行うステイプラーなどを備えており、所望により用紙への後処理を行う。
【００４０】
外部のＰＣ３のデータに基づいて出力するときは、ＰＣに搭載されているプリンタドライバを使用して装置制御ＦＷへデータを送り、出力を行うことができる。
第２ＯＳにあるデータを出力する場合も、第２ＯＳは通常のＰＣで使用されるＯＳなので前述の外部ＰＣに搭載されているものと同じプリンタドライバを利用して出力先プリンターを本体装置に指定することで本体装置の装置制御ＦＷへ出力することが可能である。つまり、専用のプリンタドライバを作成する必要なく出力することが出来る。この際には、出力データを装置制御ＦＷでジョブとして受け付け、出力処理を行うことができる。
以上により、画像形成装置１上で専用のプリンタドライバを必要とすることなく、出力まで行うことが可能である。但し、本実施形態としては、専用のプリンタドライバを用意するものであってもよく、プリンタドライバの種別が汎用、専用で限定されるものではない。
【００４１】
また、画像形成装置特有のＨ／Ｗは、通常のＰＣで使用される第２ＯＳでは制御することができない（例えば、熱定着の温度管理等）。しかしながら、第２ＯＳは装置を制御する装置制御ＦＷを起動する第１ＯＳ上で動作しているので、装置制御ＦＷを介してであれば制御することが可能である。第２ＯＳで起動するアプリケーションと装置制御ＦＷとでコマンドを定義しておくことで例えばアプリケーションが「定着温度を〜度に設定」というコマンドを装置制御ＦＷへ送信し、それを受けた装置制御ＦＷがコマンド内容を解釈し、Ｈ／Ｗを制御することで第２ＯＳ上から装置制御ＦＷを介して本体装置を制御することができる。上記により第２ＯＳからでも本体装置を制御可能となる。すなわち、装置制御ＦＷにコマンド受信機能を持たせ、第２ＯＳにそれぞれコマンド送信機能を持たせることで、異なるＯＳ間でコマンドを指令して、実行させることができる。
なお、本願発明としては、第２ＯＳで画像形成装置特有のＨ／Ｗの制御を直接行えるようにしたものであってもよい。
【００４２】
なお、画像出力に際しては、制御ＣＰＵ１１０ではジョブ情報に基づいて出力を行う。
ジョブ情報は、前記画像情報の他に、出力条件情報を含んでいる。出力条件は、プリントモード、用紙情報、給紙トレイ、排紙先、後処理条件などの情報からなり、具体的には、出力画像の画素数、カラー・モノクロの別、片面・両面の別、色調調整、用紙サイズ、用紙の向き、用紙の種類（紙種、斤量、用紙の色など）、給紙トレイの選択、後処理の有無、後処理条件などが挙げられる。出力条件は、印刷条件に相当する。
【００４３】
出力条件は、予め初期設定として標準的な設定（デフォルト設定）が定められている。また、出力条件は、操作部１４０において設定することができる。画像情報を取得するような場合には、制御ＣＰＵ１１０によって操作部制御部１４２が制御され、ＬＣＤ１４１に出力設定入力が可能な画面が表示される。
操作者によって適宜の操作入力がなされると、操作部制御部１４２から制御ＣＰＵ１１０に対し、操作部１４０上で設定された出力条件（プリントモード、給紙トレイ、排紙先、後処理条件など）等の情報が通知される。該情報を受けた制御ＣＰＵ１１０では、出力条件情報を作成し、一旦は制御ＣＰＵ１１０に備えるメモリーに格納する。画像情報を取得すると、画像情報とともにジョブ情報として画像メモリー１１４やＨＤＤ１１５に格納される。
また、第２ＯＳのプリンタドライバを介して出力が行われる場合には、プリンタドライバを介して出力条件が設定されているジョブとして扱うことができ、このジョブに対し、さらに装置制御ＦＷ上で出力条件の設定を行うことも可能である。
【００４４】
上記画像形成装置１で装置の診断を行う場合、図３に示すように第２ＯＳ上で診断アプリケーションを起動させる。診断アプリケーションは、制御ＣＰＵ１１０で動作し、装置制御ＦＷとの間内で装置内のネットワークを通した通信やシリアルバスを通したシリアル通信（ＲＳ２３２）などによる通信が可能になっている。上記ネットワークやＲＳ２３２、シリアルバスなどは本願発明の通信部を構成する。これらの通信部では、物理的な信号のやりとりをする必要がなく、コネクタなどの障害を調査、復旧させることも可能になる。
装置内のネットワークでは、通信先にＩＰアドレスを設定して通信することができる。一方、シリアル通信では、１対１対応をしているのでＩＰアドレスの設定が必要でなく、利便性が高い。その際に、第２ＯＳ上のシリアルポートと、第１ＯＳ上のデバイスファイルを関連付けることで装置制御ＦＷと診断アプリケーションとの間で通信が行われる。本実施形態では、ＴＣＰ／ＩＰを用いた通信が一般に用いられていることから診断アプリケーションの開発容易性を考慮して装置内ネットワークを用いている。
【００４５】
図３では、診断アプリケーションから装置制御ＦＷに対し通信により処理要求がなされ、処理が行われた装置制御ＦＷから診断アプリケーションに対し通信により処理結果通知がなされている状態を示している。
処理要求としては、診断に必要な情報を取得するための要求や、復旧に必要な動作を求める要求が挙げられる。処理結果通知としては、診断に必要な情報を通知するものや、復旧に必要な動作を行った結果を通知するものが挙げられる。
【００４６】
図８は、本実施形態と異なり、画像形成装置と外部のネットワークやケーブル、コネクタなどで物理的に接続された外部装置の診断アプリケーションを起動し、前記外部ネットワークを介して画像形成装置の装置制御ＦＷと通信を行って当該画像形成装置の診断を行う形態を示すものである。
この形態では、外部装置の通信インターフェースとネットワークを通し、さらに画像形成装置の通信インターフェースを通して画像形成装置の装置制御ＦＷと通信を行う。
図８(Ａ)では、上記経路を通して外部装置の診断アプリケーションから画像形成装置の装置制御ＦＷに処理要求がなされ、画像形成装置の装置制御ＦＷから外部装置の診断アプリケーションに処理結果の通知がなされている。しかし、上記形態では、それぞれの通信インターフェースやケーブル、コネクタ、外部ネットワークなどを介して装置制御ＦＷと診断アプリケーションとの間で通信を行うものであり、障害が発生した場合に、これらのケーブルや外部ネットワークなどの障害を診断することができない。例えば、ネットワーク設定に問題があるのか、ネットワークコネクタに物理的な問題があるのかなどを特定することができず、画像形成装置の診断を的確に行うことができない。
これに対し、本実施形態では、画像形成装置内部のネットワークを通して診断アプリケーションと装置制御ＦＷとで通信を行って診断を行うので、画像形成装置に起因した障害の診断を的確におこなうことができる。
【００４７】
次に、画像形成装置の診断に際し、制御ＣＰＵ１１０で実行される手順を図４のフローチャートに基づいて説明する。図４はＨＤＤエラー時の手順を示す診断フローチャートである。該手順は、装置制御ＦＷおよび診断アプリケーションの動作によって実行される。
ＨＤＤエラーが発生すると、ＨＤＤを制御する装置制御ＦＷによって、第２ＯＳが起動していなければ第２ＯＳを起動させて第２ＯＳを起動状態にする（ステップｓ１）。次いで診断アプリケーションを起動させる（ステップｓ２）。起動した診断アプルケーションは、装置制御ＦＷに対しエラー情報の要求を行い、装置制御ＦＷでは、該要求に従って取得したエラー情報の結果を診断アプリケーションに対し通知する（ステップｓ３）。エラー情報は、要求が行われることなく、装置制御ＦＷから診断アプリケーションに通知されるものであってもよい。
エラー情報を取得した診断アプリケーションでは、エラー情報に基づいてエラーの種別や復旧に必要な処理内容の決定などを行う（ステップｓ４）。この形態では、ＨＤＤエラーに対応した処理内容が決定され、モード切り替えの指令とともに処理内容が診断アプリケーションから装置制御ＦＷに通知される（ステップｓ５）。なお、モードとしては、通常プリンタモードと、診断に適した診断モードとを有しており、上記モード切り替えでは、通常プリンタモードから診断モードに切り替えられる。診断モードでは、センサによる検知が優先され、また、必要に応じてセンサがオンされる。
【００４８】
装置制御ＦＷでは、診断アプリケーションからの指令と通知を受けてエラーが発生したＨＤＤに対しｆｓｃｋ（ファイルシステムチェック）を実行し、ｆｓｃｋ結果を診断アプリケーションに通知する（ステップｓ６）。モードは診断モードであり、結果を容易に取得することができる。ｆｓｃｋ結果を受けた診断アプリケーションでは、結果の内容からｆｓｃｋが成功か失敗かを判断し（ステップｓ７）、成功であれば、診断アプリケーションから装置制御ＦＷに対し、画像形成装置の再起動を指令する（ステップｓ８）。装置制御ＦＷでは、指令に従って画像形成装置を再起動させる。このとき、装置制御ＦＷのモードは再起動によって初期化され、通常プリンタモードとして再起動される。
【００４９】
上記のように、障害内容によっては第１ＯＳを再起動させる必要が発生することが考えられる。ただし、通常、第１ＯＳを再起動させると、第１ＯＳ上のアプリケーションであるエミュレータも終了するため第２ＯＳが強制終了される。本実施形態では、装置制御ＦＷが第２ＯＳのスナップショットを記憶部であるＨＤＤに保存しておき、次回の第２ＯＳ起動時にはスナップショットから復元することで対処する。
【００５０】
再起動後、装置制御ＦＷから診断アプリケーションに通知される結果に基づいて診断アプリケーションでエラーがあるか否かを判定し（ステップｓ９）、エラーがなければ復旧を完了する（ステップｓ９、無し）。エラーがあれば（ステップｓ９、有り）、装置制御ＦＷに対し、モードを診断モードに切り替える要求と、復旧に必要な処理としてＨＤＤフォーマットを要求する。装置制御ＦＷでは、指令と要求に応じてモードを切り替え（ステップｓ１０）、ＨＤＤフォーマットを実行する（ステップｓ１１）。また、ステップｓ７で、ｆｓｃｋ結果が失敗であると判定する場合、診断アプリケーションでは、装置制御ＦＷに復旧を処理する内容としてＨＤＤフォーマットを要求する。この際は、装置制御ＦＷのモードは診断モードを継続している、装置制御ＦＷではＨＤＤフォーマットを実行する（ステップｓ１１）。
【００５１】
その後、装置制御ＦＷでは、ＨＤＤフォーマット結果を診断アプリケーションに通知し、診断アプリケーションでは、ＨＤＤフォーマット結果に基づいて成功か、失敗かを判定する（ステップｓ１２）。成功であると判定する場合（ステップｓ１２、成功）、診断アプリケーションでは装置制御ＦＷに対し画像形成装置の再起動を要求する。装置制御ＦＷでは、この要求を受けて画像形成装置を再起動する（ステップｓ１３）。このとき、ｆｓｃｋ成功時の再起動（ステップｓ８）と同様に、装置制御ＦＷは通常プリンタモードとして再起動される。再起動後、装置制御ＦＷから診断アプリケーションに通知される結果に基づいて診断アプリケーションでエラーがあるか否かを判定し（ステップｓ１４）、エラーがなければ復旧を完了し（ステップｓ１４、無し）、エラーがあれば（ステップｓ１４、有り）、装置制御ＦＷに対し、モードを診断モードに切り替える要求と、復旧に必要な処理としてＨＤＤ交換を要求しＨＤＤ交換を待機する（ステップ１６）。装置制御ＦＷでは、指令と要求に応じてモードを切り替え（ステップｓ１５）、ＨＤＤ交換がされると（ステップｓ１６）、復旧完了をする。ＨＤＤ交換は、装置制御ＦＷによって交換を検知することができる。
復旧が完了すると、装置制御ＦＷでは、診断アプリケーションを終了させ、第２ＯＳを終了させることができる。
【００５２】
また、上記手順で、画像形成装置の再起動が要求された場合の装置制御ＦＷによる手順を図５のフローチャートに基づいて説明する。
装置制御ＦＷで、再起動要求を受信すると、第２ＯＳ〜第ＮＯＳ（Ｎは、２以上の整数）をＨＤＤに退避する（ステップｓ２０）。
マルチＯＳ構成特有の課題である、第１ＯＳ再起動時の第２ＯＳの強制再起動については、ＯＳの状態を保持したまま再起動させる手段として、スナップショットを用いている。従来のスナップショットの技術ではマルチＯＳ構成ではないため、単にＯＳを高速に再起動したり、アプリケーションを停止することなくＯＳを再起動するためにスナップショットを取る、という内容である。本実施形態では、マルチＯＳ構成において、第２ＯＳ上のアプリケーションの要求により第１ＯＳを再起動するときに、再起動を要求したアプリケーション自身も含めた第２ＯＳ全体および、第３〜第ＮＯＳ全体の情報を失わないようにするためにスナップショットを用いるという点が従来例とは異なる。
【００５３】
ＨＤＤエラー時は、ファイルシステムチェック（ｆｓｃｋ）、ＨＤＤフォーマット、ＨＤＤ交換の順に対処を行うが、ファイルシステムチェックやＨＤＤフォーマット完了時は第１ＯＳを再起動する必要がある。このとき、第１ＯＳを単純に再起動すると、第１ＯＳ上のアプリケーションであるエミュレータを介して動作している第２ＯＳは強制終了されてしまい、診断アプリケーションも同時に強制終了される。第１ＯＳ再起動後に装置制御ＦＷが第２ＯＳを起動させたとき、診断アプリケーションは強制終了されているため、診断フローチャートをどこまで進んだのか判断ができなくなる。
この問題については、診断アプリケーション側で進捗状況をＨＤＤなどの不揮発性記憶装置へ退避しておき、次回診断アプリケーション起動時に記憶装置から診断処理の進捗状態を復元する。この方法では診断アプリケーションについては第２ＯＳの強制終了に備えることができるが、診断アプリケーション以外の第２ＯＳ上のアプリケーションや、第２ＯＳ自身、第３ＯＳ以降は強制終了に備えることができない。
そこで、装置制御ＦＷが第１ＯＳの再起動要求を受信すると、画像形成装置上で動作している第２〜第ＮＯＳについて、メモリやＣＰＵレジスタなどの全内容をＨＤＤへ退避し、画像形成装置再起動後にＨＤＤへ退避しておいた内容から第２〜第ＮＯＳの状態を復元する。
【００５４】
この方法の特徴として、診断アプリケーションの状態も復元されるため、診断アプリケーションは第１ＯＳの再起動に備えた特別の処理を必要としない。また、診断アプリケーションが第２〜第ＮＯＳの状態を考慮する必要がなく、第２〜第ＮＯＳの起動と終了については装置制御ＦＷ上で管理および制御することができる。
なお、この方法では装置制御ＦＷの状態が再起動前後で変化するため、診断アプリケーションは装置制御ＦＷの状態が初期化されることを考慮し、必要に応じて装置制御ＦＷの状態を制御する必要がある。
【００５５】
上記のように本実施形態では、再起動の要求に対し、装置制御ＦＷは、第２ＯＳに対するスナップショットを行う。次いで全エミュレータを終了する。なお、この手順では、複数の第２ＯＳ以降が起動しているものとして説明をしているが、第２ＯＳが動作するもの、または第２ＯＳのみが起動しているものであってもよい。
次いで、第１ＯＳを起動する（ステップｓ２２）。その後、第２ＯＳを起動し（ステップｓ２３）、再起動を完了する。
【００５６】
さらに、再起動における第２ＯＳ起動の詳細な手順を図６に基づいて説明する。
第２ＯＳの起動では、第２ＯＳの退避データがＨＤＤにあるか、すなわちスナップショットが行われているかの判定がなされる（ステップｓ３０）。第２ＯＳの待避データがＨＤＤにあれば（ステップｓ３０、Ｙ）、第２ＯＳを復元する（ステップｓ３１）。この際に、再起動を要求した診断アプリケーション自身も復元される。さらに、第３〜第ＮＯＳ全体もスナップショットに含まれていれば、これらの同様に復元される。上記第２ＯＳの復元によって第２ＯＳ起動が完了する。
また、第２ＯＳの退避データがＨＤＤにない場合（ステップｓ３０、Ｎ）、第２ＯＳを通常起動し（ステップｓ３２）、処理を完了する。
【００５７】
上記実施形態は、第１ＯＳ上の装置制御ＦＷが検知した画像形成装置の障害から復旧させるための診断アプリケーションを第２ＯＳ上で動作させるものであり、画像形成装置において障害が発生した場合の障害復旧作業をサポートする診断機能を、画像形成装置上で動作させる際に、装置制御ＦＷではなく、第２ＯＳ上のアプリケーションとして実行することができる。
これにより、診断アプリケーションを装置制御ＦＷから切り離し、診断アプリケーションの開発、更新と装置制御ＦＷの開発、更新を分離することができる。例えば、診断アプリケーション更新のために装置制御ＦＷを更新する作業が不要になる。
また、画像形成装置の再起動時において、上記のように第２ＯＳの状態を退避、復元するようにすることで第２ＯＳの状態によらず、画像形成装置の再起動を可能とする。すなわち、マルチＯＳ構成特有の課題である画像形成装置再起動時の第２ＯＳの強制再起動については、第２ＯＳの状態を退避、復元する作業を装置制御ＦＷが行うことで、画像形成装置の再起動により第２ＯＳの情報が失われることがなくなる。
【００５８】
また、この実施形態では、診断アプリケーション自身が直接ハードウェアを確認して障害の原因を調べるのではなく、画像形成装置が既に搭載している各種情報や機能テストモードを装置制御ＦＷの情報や機能を用いて診断を行うことができ、診断機能と画像形成に関わる機能の分離をより容易にし、診断機能の開発、更新を装置制御ＦＷから確実に切り離して実施できる。また、画像形成装置の仕組みに詳しくなくても診断アプリケーションを開発することができる。
ただし、本願発明としては、前記したように第２ＯＳが直接ハードウェアを確認するものであってもよい。
【００５９】
また、マルチＯＳ構成特有の課題である、第１ＯＳ再起動時の第２ＯＳの強制再起動については、ＯＳの状態を保持したまま再起動させる手段として、スナップショットを用いている。しかし、従来技術ではマルチＯＳ構成ではないため、単にＯＳを高速に再起動したり、アプリケーションを停止することなくＯＳを再起動するためにスナップショットを取る、という内容である。本件では、マルチＯＳ構成において、第２ＯＳ上のアプリケーションの要求により第１ＯＳを再起動するときに、再起動を要求したアプリケーション自身も含めた第２ＯＳ全体および、第３〜第ＮＯＳ全体の情報を失わないようにするためにスナップショットを用いるという点が異なっている。
【００６０】
以上、本発明について上記実施形態に基づいて本願発明の説明を行ったが、本願発明の内容は上記に限定されるものではなく、本願発明の範囲を逸脱しない限りは適宜の変更が可能である。
【符号の説明】
【００６１】
１  画像形成装置
２  ＬＡＮ
３、ＰＣ
１１０  制御ＣＰＵ
１１３  ＶＲＡＭ
１１４  画像メモリー
１１５  ＨＤＤ
１２０  通信部
１２２  ＮＩＣ
１３０  スキャナー部
１４０  操作部
１５０  プリンター部
【図１】
2014219915.tif 000003
【図２】
2014219915.tif 000004
【図３】
2014219915.tif 000005
【図４】
2014219915.tif 000006
【図５】
2014219915.tif 000007
【図６】
2014219915.tif 000008
【図７】
2014219915.tif 000009
【図８】
2014219915.tif 000010