画像形成装置制御方法および画像形成装置
【課題】安定した状態でファームウェアを更新するすることが可能な画像形成装置制御方法および画像形成装置を実現する。
【解決手段】単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置１００であって、ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステム＃１と、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステム＃２とを別個に動作可能に備える。
【解決手段】単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置１００であって、ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステム＃１と、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステム＃２とを別個に動作可能に備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置制御方法および画像形成装置に関し、特に、画像形成装置のファームウェアの更新を安定して行う技術に関する。
【背景技術】
【０００２】
画像形成装置において各種動作はＣＰＵ（Central Processing Unit）等の制御部により制御されている。そして、この制御部は、インストールされているＯＳ（Operating System）またはファームウェア等に基づいて、画像形成装置の制御プログラムに従って、画像形成装置を構成する各部を制御して、各種の演算処理を行うことによって、画像形成装置を統括的に制御する。
【０００３】
また、このファームウェアはフラッシュメモリ等の媒体に書き込まれており、新たなバージョンのファームウェアに書き換えることが可能に構成されたものがある。
【０００４】
ところで、画像形成中にファームウェア更新を行う場合、どちらかの処理が原因でＯＳがハングアップすることがある。この場合には、画像形成が中断して生産性が低下し、処理中の画像データを喪失することになる。
【０００５】
また、ファームウェアの更新が途中で中断されることで正常な更新ができなくなるため、ファームウェアの次回の起動ができなくなるという大きな問題が発生する。
【０００６】
なお、このような電子情報装置においてファームウェアの更新に関連する技術は、以下の特許文献に提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平８−１６４０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
以上の特許文献１では、リセットしたりしてシステムを落すことなくシステムを立ち上げたままの状態において、運用中に、随時新しいファームウェアを情報処理装置に書き込むものである。
【０００９】
しかし、この特許文献１記載の装置でも、通常処理とファームウェア更新処理とを並行して行う場合には、どちらかの処理が原因でＯＳがハングアップすることがあり、結果として通常処理もファームウェア更新処理も両方とも停止してしまう。
【００１０】
本発明はこのような課題に鑑みてなされたものであって、安定した状態でファームウェアを更新することが可能な画像形成装置制御方法および画像形成装置を実現することを目的とする。
【課題を解決するための手段】
【００１１】
すなわち、前記した課題を解決する本発明は、以下の通りである。
【００１２】
（１）第１の発明は、単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置における画像形成装置制御方法であって、ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作させる、ことを特徴とする。
【００１３】
（２）第２の発明は、以上の（１）において、前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、ことを特徴とする。
【００１４】
（３）第３の発明は、以上の（１）において、前記第１オペレーティングシステムにおいてファームウェア更新要求が受信されると前記第２オペレーティングシステムが起動される、ことを特徴とする。
【００１５】
また、ファームウェア更新が完了すると、第２オペレーティングシステムがシャットダウンされることが望ましい。
【００１６】
（４）第４の発明は、以上の（１）〜（３）において、前記第１オペレーティングシステムは、前記第２オペレーティングシステムの動作状況を監視し、前記第２オペレーティングシステムの停止を検知した場合には前記第２オペレーティングシステムを再起動し、前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視し、前記第１オペレーティングシステムの停止を検知した場合には前記第１オペレーティングシステムを再起動する、ことを特徴とする。
【００１７】
（５）第５の発明は、以上の（１）〜（４）において、第１オペレーティングシステムと第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、ことを特徴とする。
【発明の効果】
【００１８】
本発明によると、以下のような効果が得られる。
【００１９】
（１）第１の発明では、第１オペレーティングシステムと第２オペレーティングシステムとを別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしており、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがなく、安定した状態でファームウェアを更新することが可能になる。
【００２０】
（２）第２の発明では、以上の（１）において、第１オペレーティングシステム上でファームウェアが正常に起動された後に、ファームウェア更新のための第２オペレーティングシステムが起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００２１】
（３）第３の発明では、以上の（１）において、第１オペレーティングシステムにおいてファームウェア更新要求が受信されると第２オペレーティングシステムが起動されるため、装置の資源を無駄にすることなく、必要な状況においてファームウェアを更新することが可能になる。
【００２２】
また、ファームウェア更新が完了すると第２オペレーティングシステムがシャットダウンすることで、必要な状況においてのみ第２オペレーティングシステムを起動するため、装置の資源を無駄にすることがない。
【００２３】
（４）第４の発明では、以上の（１）〜（３）において、第１オペレーティングシステムは、第２オペレーティングシステムの動作状況を監視し、第２オペレーティングシステムの停止を検知した場合には第２オペレーティングシステムを再起動し、第２オペレーティングシステムは、第１オペレーティングシステムの動作状況を監視し、第１オペレーティングシステムの停止を検知した場合には第１オペレーティングシステムを再起動する、ことにより、不具合発生時にも再起動が可能になり、安定した動作を保つことが可能になる。
【００２４】
（５）第５の発明では、以上の（１）〜（４）において、第１オペレーティングシステムと第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムであるため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがなく、安定した状態で画像形成を実行すると共にファームウェアを更新することが可能になる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図２】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【図３】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図４】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【図５】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図６】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下、図面を参照して本発明を実施するための形態（以下、実施形態）を詳細に説明する。
【００２７】
〈画像形成装置の構成（１）〉
ここでは、ファームウェアの更新を行う機能を有する画像形成装置１００を具体例にして説明する。
【００２８】
図１に示される画像形成装置１００は、ＣＰＵ（Central Processing Unit）等により構成されて制御プログラムに基づいて画像形成装置１００内の各部を制御する制御部１０１と、各種ネットワークを介して他の装置と通信するための通信部１０２と、液晶表示部とタッチパネルとにより構成されて利用者による操作が入力される操作部１０５と、ＵＳＢメモリやＳＤメモリカード等の画像形成装置外から画像データが入力される入力部１２０と、画像形成装置１００で取り扱う画像データを不揮発性の記憶装置であるハードディスク装置（ＨＤＤ；Hard Disk Drive）等に蓄積するデータ蓄積部１３０と、画像データに対して圧縮伸長処理やＲＩＰ処理など各種画像処理を施す画像処理部１５０と、電子写真方式などにより画像形成出力を実行するプリントエンジンとしての画像形成部１６０と、を備えて構成されている。
【００２９】
また、更新ファームウェア保存部２００は、画像形成装置１００とネットワーク接続可能な外部装置、あるいは、画像形成装置１００に接続可能なＵＳＢメモリなどであり、更新ファームウェアとファームウェア更新要求とを保存している。
【００３０】
また、制御部１０１は、実行すべきファームウェアを不揮発性メモリ等に保存するファームウェア保存部１０１０と、電子機器部分であるハードウェア１０１１と、仮想マシン環境において仮想マシンのゲストＯＳやプログラムを動作させる際の基盤となるべくハードウェア１０１１上で動作するホストＯＳ（Operating System）１０１２と、コンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとで異なるゲストＯＳを並列に実行できるようにするソフトウェアである仮想マシンモニタ１０１３と、仮想ハードウェア１０１３Ａ上でゲストＯＳ１０１４ａ（図１においてゲストＯＳ＃１）を実行する仮想マシン１０１４Ａ（図１において仮想マシン＃１）と、仮想ハードウェア１０１３Ｂ上でゲストＯＳ１０１４ｂ（図１においてゲストＯＳ＃２）を実行する仮想マシン１０１４Ｂ（図１において仮想マシン＃２）と、ゲストＯＳ１０１４ａ上で動作するプログラム１０１５Ａと、ゲストＯＳ１０１４ｂ上で動作するプログラム１０１５Ｂと、を備えて構成されている。
【００３１】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。
【００３２】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａと、ゲストＯＳ１０１４ｂ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ｂｂと、を有する。
【００３３】
なお、この図１における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。
【００３４】
また、この図１における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。
【００３５】
また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００３６】
〈画像形成装置の動作（１）〉
ここで、本実施形態の構成（１）の画像形成装置における画像形成の動作（１）について、図２のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００３７】
画像形成装置１００の電源がオペレータによりオンされる（図２中のステップＳ１０１）と、ファームウェア保存部１０１０等に保存されているブートローダ（boot loader）がブート処理を行い、ホストＯＳ１０１２を起動する（図２中のステップＳ１０２）。
【００３８】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図２中のステップＳ１０３）。
【００３９】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図２中のステップＳ１０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００４０】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図２中のステップＳ１０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図２中のステップＳ１０６）。
【００４１】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図２中のステップＳ１０７）。
【００４２】
また、ゲストＯＳ１０１４ａ上でファームウェアを実行するファームウェア実行部１０１５Ａａは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを起動するよう要求する（図２中のステップＳ１０８）。
【００４３】
これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【００４４】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図２中のステップＳ１０８）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図２中のステップＳ２０１）。
【００４５】
このゲストＯＳ１０１４ｂ上ではファームウェア更新要求受付部１０１５Ｂｂが動作開始し、このファームウェア更新要求受付部１０１５Ｂｂがファームウェア更新要求を受け付け待ちをしている（図２中のステップＳ２０２）。
【００４６】
このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００４７】
この際に、ファームウェア更新要求受付部１０１５Ｂｂは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ｂｂは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００４８】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ｂｂが受信すると（図２中のステップＳ２０２でＹＥＳ）、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図２中のステップＳ２０３）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図２中のステップＳ２０４）。
【００４９】
この際に、更新ファームウェア保存部２００は、ファームウェア更新要求によって指示されたアドレスから更新ファームウェアを読み出す。なお、更新ファームウェア保存部２００がＵＳＢメモリ等であって入力部１２０に接続された場合には、このＵＳＢメモリ内のファームウェア更新要求がファームウェア更新要求受付部１０１５Ｂｂで受信され、ファームウェア更新部１０１５ＢａによってＵＳＢメモリ内の更新ファームウェアが読み出される。また、更新ファームウェア保存部２００がネットワーク接続されたサーバ等であって通信部部１０２に接続された場合には、このサーバ等の記憶部内のファームウェア更新要求がファームウェア更新要求受付部１０１５Ｂｂで受信され、ファームウェア更新部１０１５Ｂａによってサーバ等の記憶部内の更新ファームウェアが読み出される。
【００５０】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａからファームウェア更新完了通知を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図２中のエンド（ゲストＯＳ＃２））。
【００５１】
なお、ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【００５２】
以上の動作において、ファームウェア更新中や、ファームウェア更新完了について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【００５３】
以上の構成（１）と動作（１）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【００５４】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【００５５】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【００５６】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動された後に、ファームウェア更新のためのゲストＯＳ１０１４ｂが起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００５７】
〈画像形成装置の構成（２）〉
図３に示される画像形成装置１００は、図１で説明した画像形成装置１００と同様に、コンピュータを仮想化して、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａ（図３においてゲストＯＳ＃１）を実行し、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢでゲストＯＳ１０１４ｂ（図３においてゲストＯＳ＃２）を実行するものである。
【００５８】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、ゲストＯＳ１０１４ａ上で動作しつつゲストＯＳ１０１４ｂの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ａｃと、ゲストＯＳ１０１４ａ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ａｄと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。
【００５９】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａを有する。
【００６０】
なお、この図３における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。また、この図３における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００６１】
〈画像形成装置の動作（２）〉
ここで、本実施形態の構成（２）の画像形成装置における画像形成の動作（２）について、図４のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００６２】
画像形成装置１００の電源がオペレータによりオンされる（図４中のステップＳ４０１）と、ファームウェア保存部１０１０等に保存されているブートローダがブート処理を行い、ホストＯＳ１０１２を起動する（図４中のステップＳ４０２）。
【００６３】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図４中のステップＳ４０３）。
【００６４】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図４中のステップＳ４０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００６５】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図４中のステップＳ４０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図４中のステップＳ４０６）。
【００６６】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図４中のステップＳ４０７）。
【００６７】
また、ゲストＯＳ１０１４ａ上ではファームウェア更新要求受付部１０１５Ａｄがファームウェア更新要求を受け付け待ちをしている（図４中のステップＳ４０８）。このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００６８】
この際に、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００６９】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ａｄが受信すると（図４中のステップＳ４０８でＹＥＳ）、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを起動するよう要求する（図４中のステップＳ４０９）。
【００７０】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図４中のステップＳ４０９）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図４中のステップＳ５０１）。
【００７１】
この時点では、操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求がファームウェア更新要求受付部１０１５Ａｄで受信されている（図４中のステップＳ４０８でＹＥＳ）ため、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図４中のステップＳ５０２）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図４中のステップＳ５０３）。
【００７２】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａは、ファームウェア実行部１０１５Ａａに対してファームウェア更新完了通知を送信する（図４中のステップＳ５０４）。
【００７３】
ＯＳ状態変更部１０１５Ａｃはファームウェア更新完了通知を受信する（図４中のステップＳ４１０でＹＥＳ）と、ゲストＯＳ１０１４ｂに対して停止要求を発生する（図４中のステップＳ４１１）。
【００７４】
ＯＳ状態変更部１０１５Ａｃから停止要求を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図４中のステップＳ５０５、エンド（ゲストＯＳ＃２））。
【００７５】
ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【００７６】
なお、これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【００７７】
以上の動作において、ファームウェア更新中や、ファームウェア更新完了について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【００７８】
以上の構成（２）と動作（２）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【００７９】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【００８０】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【００８１】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動されてファームウェア更新要求を受信した後に、ファームウェア更新のためのゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによって起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００８２】
また、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａがファームウェア更新を完了した後に、ゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによってシャットダウンさせられるため、資源や電力の無駄使いが無く、ＣＰＵパワーが無駄に使用されることがなくなる。
【００８３】
〈画像形成装置の構成（３）〉
図５に示される画像形成装置１００は、図１や図３で説明した画像形成装置１００と同様に、コンピュータを仮想化して、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａ（図５においてゲストＯＳ＃１）を実行し、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢでゲストＯＳ１０１４ｂ（図５においてゲストＯＳ＃２）を実行するものである。
【００８４】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、動作時にハートビート信号を発生し続けることで自己の生存を知らしめると共に他のハートビート信号を受信することで他の生存を確認するＯＳ生存監視部１０１５Ａｂと、ゲストＯＳ１０１４ａ上で動作しつつゲストＯＳ１０１４ｂの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ａｃと、ゲストＯＳ１０１４ａ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ａｄと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。なお、ここで、ハートビート信号と言ったものは、定期的な信号により自己の生存を示す信号（生存確認信号）であれば良く、既知の各種の信号を用いることが可能である。
【００８５】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａと、動作時にハートビート信号を発生し続けることで自己の生存を知らしめると共に他のハートビート信号を受信することで他の生存を確認するＯＳ生存監視部１０１５Ｂｃと、ゲストＯＳ１０１４ｂ上で動作しつつゲストＯＳ１０１４ａの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ｂｄと、を有する。
【００８６】
なお、この図５における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。また、この図５における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００８７】
また、ここでは、ハートビート信号を生存確認に用いているが、これ以外であっても互いの生存確認を行うことが可能な各種の手法を採用することが可能である。
【００８８】
〈画像形成装置の動作（３）〉
ここで、本実施形態の構成（３）の画像形成装置における画像形成の動作（３）について、図６のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００８９】
画像形成装置１００の電源がオペレータによりオンされる（図６中のステップＳ６０１）と、ファームウェア保存部１０１０等に保存されているブートローダがブート処理を行い、ホストＯＳ１０１２を起動する（図６中のステップＳ６０２）。
【００９０】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図６中のステップＳ６０３）。
【００９１】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図６中のステップＳ６０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００９２】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図６中のステップＳ６０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図６中のステップＳ６０６）。
【００９３】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図６中のステップＳ６０７）。
【００９４】
また、ゲストＯＳ１０１４ａ上ではファームウェア更新要求受付部１０１５Ａｄがファームウェア更新要求を受け付け待ちをしている（図６中のステップＳ６０８）。このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００９５】
この際に、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００９６】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ａｄが受信すると（図６中のステップＳ６０８でＹＥＳ）、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを起動するよう要求する（図６中のステップＳ６０９）。
【００９７】
ここで、ＯＳ生存監視部１０１５Ａｂは、自己の生存を他のＯＳ生存監視部に対して知らしめるハートビート信号を定期的に生成する（図６中のステップＳ６１０）。このＯＳ生存監視部１０１５Ａｂからのハートビート信号は、後述するＯＳ生存監視部１０１５Ｂｃに対して送出される。
【００９８】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図６中のステップＳ６０９）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図６中のステップＳ７０１）。
【００９９】
ここで、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５Ｂｃは、自己の生存を他のＯＳ生存監視部に対して知らしめるハートビート信号を定期的に生成する（図７中のステップＳ７０２）。このＯＳ生存監視部１０１５Ｂｃからのハートビート信号は、ＯＳ生存監視部１０１５Ａｂに対して送出される。
【０１００】
ゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５ＡｂはゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５Ｂｃからのハートビート信号を受信している（図６中のステップＳ６１１）。ここで、ＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号が受信できなければ（図６中のステップＳ６１１でＮＯ）、何らかの理由でゲストＯＳ１０１４ｂそのもの又はゲストＯＳ１０１４ｂ上のプログラムがハングアップ（停止）していると考えられるため、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを再起動するよう要求する（図６中のステップＳ６１２）。これ以後、ＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号が受信できるまで、ＯＳ状態変更部１０１５ＡｃはゲストＯＳ１０１４ｂを再起動するよう要求する（図６中のステップＳ６１１でＮＯ、ステップＳ６１２）。
【０１０１】
一方、ゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号を受信できれば（図６中のステップＳ６１１でＹＥＳ）、次の処理に進む。
【０１０２】
また、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５ＢｃはゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５Ａｂからのハートビート信号を受信している（図６中のステップＳ７０３）。ここで、ＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号が受信できなければ（図６中のステップＳ７０３でＮＯ）、何らかの理由でゲストＯＳ１０１４ａそのもの又はゲストＯＳ１０１４ａ上のプログラムがハングアップ（停止）していると考えられるため、ゲストＯＳ１０１４ｂ上のＯＳ状態変更部１０１５Ｂｄは、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡにおいてゲストＯＳ１０１４ａを再起動するよう要求する（図６中のステップＳ７０４）。これ以後、ＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号が受信できるまで、ＯＳ状態変更部１０１５ＢｄはゲストＯＳ１０１４ａを再起動するよう要求する（図６中のステップＳ７０３でＮＯ、ステップＳ７０４）。
【０１０３】
一方、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号を受信できれば（図６中のステップＳ７０３でＹＥＳ）、次の処理に進む。
【０１０４】
この時点では、操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求がファームウェア更新要求受付部１０１５Ａｄで受信されている（図６中のステップＳ６０８でＹＥＳ）ため、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図６中のステップＳ７０５）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図６中のステップＳ７０６）。
【０１０５】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａは、ファームウェア実行部１０１５Ａａに対してファームウェア更新完了通知を送信する（図６中のステップＳ７０７）。
【０１０６】
ゲストＯＳ１０１４ａ側のＯＳ状態変更部１０１５Ａｃはファームウェア更新完了通知を受信する（図６中のステップＳ６１３でＹＥＳ）と、ゲストＯＳ１０１４ｂに対して停止要求を発生する（図６中のステップＳ６１４）。また、ゲストＯＳ１０１４ｂに停止要求を発生したことでゲストＯＳ１０１４ａ側からのハートビート信号が不要になるため、ＯＳ生存監視部１０１５Ａｂはハートビート信号の送出を停止する（図６中のステップＳ６１５）。
【０１０７】
このようにしてＯＳ状態変更部１０１５Ａｃから停止要求を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図６中のステップＳ７０８、エンド（ゲストＯＳ＃２））。
【０１０８】
ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【０１０９】
なお、これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【０１１０】
以上の動作において、ファームウェア更新中、ファームウェア更新完了、ＯＳの再起動について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【０１１１】
以上の構成（３）と動作（３）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【０１１２】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【０１１３】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【０１１４】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動されてファームウェア更新要求を受信した後に、ファームウェア更新のためのゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによって起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【０１１５】
また、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａがファームウェア更新を完了した後に、ゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによってシャットダウンさせられるため、資源や電力の無駄使いが無く、ＣＰＵパワーが無駄に使用されることがなくなる。
【０１１６】
また、ファームウェア更新のためにゲストＯＳ１０１４ｂが動作している期間は、ゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂとが互いの生存をハートビート信号により監視しており、相手方のハートビート信号が受信できない場合には相手方を再起動するようにしているため、不具合発生時にも再起動が可能になり、ファームウェア更新や画像形成について安定した動作を保つことが可能になる。
【符号の説明】
【０１１７】
１００ 画像形成装置
１０１ 制御部
１０２ 通信部
１０５ 操作部
１２０ 入力部
１３０ データ蓄積部
１５０ 画像処理部
１６０ 画像形成部
２００ 更新ファームウェア保存部
【技術分野】
【０００１】
本発明は、画像形成装置制御方法および画像形成装置に関し、特に、画像形成装置のファームウェアの更新を安定して行う技術に関する。
【背景技術】
【０００２】
画像形成装置において各種動作はＣＰＵ（Central Processing Unit）等の制御部により制御されている。そして、この制御部は、インストールされているＯＳ（Operating System）またはファームウェア等に基づいて、画像形成装置の制御プログラムに従って、画像形成装置を構成する各部を制御して、各種の演算処理を行うことによって、画像形成装置を統括的に制御する。
【０００３】
また、このファームウェアはフラッシュメモリ等の媒体に書き込まれており、新たなバージョンのファームウェアに書き換えることが可能に構成されたものがある。
【０００４】
ところで、画像形成中にファームウェア更新を行う場合、どちらかの処理が原因でＯＳがハングアップすることがある。この場合には、画像形成が中断して生産性が低下し、処理中の画像データを喪失することになる。
【０００５】
また、ファームウェアの更新が途中で中断されることで正常な更新ができなくなるため、ファームウェアの次回の起動ができなくなるという大きな問題が発生する。
【０００６】
なお、このような電子情報装置においてファームウェアの更新に関連する技術は、以下の特許文献に提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平８−１６４０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
以上の特許文献１では、リセットしたりしてシステムを落すことなくシステムを立ち上げたままの状態において、運用中に、随時新しいファームウェアを情報処理装置に書き込むものである。
【０００９】
しかし、この特許文献１記載の装置でも、通常処理とファームウェア更新処理とを並行して行う場合には、どちらかの処理が原因でＯＳがハングアップすることがあり、結果として通常処理もファームウェア更新処理も両方とも停止してしまう。
【００１０】
本発明はこのような課題に鑑みてなされたものであって、安定した状態でファームウェアを更新することが可能な画像形成装置制御方法および画像形成装置を実現することを目的とする。
【課題を解決するための手段】
【００１１】
すなわち、前記した課題を解決する本発明は、以下の通りである。
【００１２】
（１）第１の発明は、単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置における画像形成装置制御方法であって、ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作させる、ことを特徴とする。
【００１３】
（２）第２の発明は、以上の（１）において、前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、ことを特徴とする。
【００１４】
（３）第３の発明は、以上の（１）において、前記第１オペレーティングシステムにおいてファームウェア更新要求が受信されると前記第２オペレーティングシステムが起動される、ことを特徴とする。
【００１５】
また、ファームウェア更新が完了すると、第２オペレーティングシステムがシャットダウンされることが望ましい。
【００１６】
（４）第４の発明は、以上の（１）〜（３）において、前記第１オペレーティングシステムは、前記第２オペレーティングシステムの動作状況を監視し、前記第２オペレーティングシステムの停止を検知した場合には前記第２オペレーティングシステムを再起動し、前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視し、前記第１オペレーティングシステムの停止を検知した場合には前記第１オペレーティングシステムを再起動する、ことを特徴とする。
【００１７】
（５）第５の発明は、以上の（１）〜（４）において、第１オペレーティングシステムと第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、ことを特徴とする。
【発明の効果】
【００１８】
本発明によると、以下のような効果が得られる。
【００１９】
（１）第１の発明では、第１オペレーティングシステムと第２オペレーティングシステムとを別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしており、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがなく、安定した状態でファームウェアを更新することが可能になる。
【００２０】
（２）第２の発明では、以上の（１）において、第１オペレーティングシステム上でファームウェアが正常に起動された後に、ファームウェア更新のための第２オペレーティングシステムが起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００２１】
（３）第３の発明では、以上の（１）において、第１オペレーティングシステムにおいてファームウェア更新要求が受信されると第２オペレーティングシステムが起動されるため、装置の資源を無駄にすることなく、必要な状況においてファームウェアを更新することが可能になる。
【００２２】
また、ファームウェア更新が完了すると第２オペレーティングシステムがシャットダウンすることで、必要な状況においてのみ第２オペレーティングシステムを起動するため、装置の資源を無駄にすることがない。
【００２３】
（４）第４の発明では、以上の（１）〜（３）において、第１オペレーティングシステムは、第２オペレーティングシステムの動作状況を監視し、第２オペレーティングシステムの停止を検知した場合には第２オペレーティングシステムを再起動し、第２オペレーティングシステムは、第１オペレーティングシステムの動作状況を監視し、第１オペレーティングシステムの停止を検知した場合には第１オペレーティングシステムを再起動する、ことにより、不具合発生時にも再起動が可能になり、安定した動作を保つことが可能になる。
【００２４】
（５）第５の発明では、以上の（１）〜（４）において、第１オペレーティングシステムと第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムであるため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがなく、安定した状態で画像形成を実行すると共にファームウェアを更新することが可能になる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図２】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【図３】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図４】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【図５】本発明の実施形態の画像形成装置の構成を示すブロック図である。
【図６】本発明の実施形態の画像形成装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下、図面を参照して本発明を実施するための形態（以下、実施形態）を詳細に説明する。
【００２７】
〈画像形成装置の構成（１）〉
ここでは、ファームウェアの更新を行う機能を有する画像形成装置１００を具体例にして説明する。
【００２８】
図１に示される画像形成装置１００は、ＣＰＵ（Central Processing Unit）等により構成されて制御プログラムに基づいて画像形成装置１００内の各部を制御する制御部１０１と、各種ネットワークを介して他の装置と通信するための通信部１０２と、液晶表示部とタッチパネルとにより構成されて利用者による操作が入力される操作部１０５と、ＵＳＢメモリやＳＤメモリカード等の画像形成装置外から画像データが入力される入力部１２０と、画像形成装置１００で取り扱う画像データを不揮発性の記憶装置であるハードディスク装置（ＨＤＤ；Hard Disk Drive）等に蓄積するデータ蓄積部１３０と、画像データに対して圧縮伸長処理やＲＩＰ処理など各種画像処理を施す画像処理部１５０と、電子写真方式などにより画像形成出力を実行するプリントエンジンとしての画像形成部１６０と、を備えて構成されている。
【００２９】
また、更新ファームウェア保存部２００は、画像形成装置１００とネットワーク接続可能な外部装置、あるいは、画像形成装置１００に接続可能なＵＳＢメモリなどであり、更新ファームウェアとファームウェア更新要求とを保存している。
【００３０】
また、制御部１０１は、実行すべきファームウェアを不揮発性メモリ等に保存するファームウェア保存部１０１０と、電子機器部分であるハードウェア１０１１と、仮想マシン環境において仮想マシンのゲストＯＳやプログラムを動作させる際の基盤となるべくハードウェア１０１１上で動作するホストＯＳ（Operating System）１０１２と、コンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとで異なるゲストＯＳを並列に実行できるようにするソフトウェアである仮想マシンモニタ１０１３と、仮想ハードウェア１０１３Ａ上でゲストＯＳ１０１４ａ（図１においてゲストＯＳ＃１）を実行する仮想マシン１０１４Ａ（図１において仮想マシン＃１）と、仮想ハードウェア１０１３Ｂ上でゲストＯＳ１０１４ｂ（図１においてゲストＯＳ＃２）を実行する仮想マシン１０１４Ｂ（図１において仮想マシン＃２）と、ゲストＯＳ１０１４ａ上で動作するプログラム１０１５Ａと、ゲストＯＳ１０１４ｂ上で動作するプログラム１０１５Ｂと、を備えて構成されている。
【００３１】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。
【００３２】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａと、ゲストＯＳ１０１４ｂ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ｂｂと、を有する。
【００３３】
なお、この図１における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。
【００３４】
また、この図１における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。
【００３５】
また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００３６】
〈画像形成装置の動作（１）〉
ここで、本実施形態の構成（１）の画像形成装置における画像形成の動作（１）について、図２のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００３７】
画像形成装置１００の電源がオペレータによりオンされる（図２中のステップＳ１０１）と、ファームウェア保存部１０１０等に保存されているブートローダ（boot loader）がブート処理を行い、ホストＯＳ１０１２を起動する（図２中のステップＳ１０２）。
【００３８】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図２中のステップＳ１０３）。
【００３９】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図２中のステップＳ１０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００４０】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図２中のステップＳ１０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図２中のステップＳ１０６）。
【００４１】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図２中のステップＳ１０７）。
【００４２】
また、ゲストＯＳ１０１４ａ上でファームウェアを実行するファームウェア実行部１０１５Ａａは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを起動するよう要求する（図２中のステップＳ１０８）。
【００４３】
これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【００４４】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図２中のステップＳ１０８）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図２中のステップＳ２０１）。
【００４５】
このゲストＯＳ１０１４ｂ上ではファームウェア更新要求受付部１０１５Ｂｂが動作開始し、このファームウェア更新要求受付部１０１５Ｂｂがファームウェア更新要求を受け付け待ちをしている（図２中のステップＳ２０２）。
【００４６】
このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００４７】
この際に、ファームウェア更新要求受付部１０１５Ｂｂは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ｂｂは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００４８】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ｂｂが受信すると（図２中のステップＳ２０２でＹＥＳ）、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図２中のステップＳ２０３）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図２中のステップＳ２０４）。
【００４９】
この際に、更新ファームウェア保存部２００は、ファームウェア更新要求によって指示されたアドレスから更新ファームウェアを読み出す。なお、更新ファームウェア保存部２００がＵＳＢメモリ等であって入力部１２０に接続された場合には、このＵＳＢメモリ内のファームウェア更新要求がファームウェア更新要求受付部１０１５Ｂｂで受信され、ファームウェア更新部１０１５ＢａによってＵＳＢメモリ内の更新ファームウェアが読み出される。また、更新ファームウェア保存部２００がネットワーク接続されたサーバ等であって通信部部１０２に接続された場合には、このサーバ等の記憶部内のファームウェア更新要求がファームウェア更新要求受付部１０１５Ｂｂで受信され、ファームウェア更新部１０１５Ｂａによってサーバ等の記憶部内の更新ファームウェアが読み出される。
【００５０】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａからファームウェア更新完了通知を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図２中のエンド（ゲストＯＳ＃２））。
【００５１】
なお、ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【００５２】
以上の動作において、ファームウェア更新中や、ファームウェア更新完了について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【００５３】
以上の構成（１）と動作（１）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【００５４】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【００５５】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【００５６】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動された後に、ファームウェア更新のためのゲストＯＳ１０１４ｂが起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００５７】
〈画像形成装置の構成（２）〉
図３に示される画像形成装置１００は、図１で説明した画像形成装置１００と同様に、コンピュータを仮想化して、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａ（図３においてゲストＯＳ＃１）を実行し、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢでゲストＯＳ１０１４ｂ（図３においてゲストＯＳ＃２）を実行するものである。
【００５８】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、ゲストＯＳ１０１４ａ上で動作しつつゲストＯＳ１０１４ｂの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ａｃと、ゲストＯＳ１０１４ａ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ａｄと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。
【００５９】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａを有する。
【００６０】
なお、この図３における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。また、この図３における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００６１】
〈画像形成装置の動作（２）〉
ここで、本実施形態の構成（２）の画像形成装置における画像形成の動作（２）について、図４のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００６２】
画像形成装置１００の電源がオペレータによりオンされる（図４中のステップＳ４０１）と、ファームウェア保存部１０１０等に保存されているブートローダがブート処理を行い、ホストＯＳ１０１２を起動する（図４中のステップＳ４０２）。
【００６３】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図４中のステップＳ４０３）。
【００６４】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図４中のステップＳ４０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００６５】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図４中のステップＳ４０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図４中のステップＳ４０６）。
【００６６】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図４中のステップＳ４０７）。
【００６７】
また、ゲストＯＳ１０１４ａ上ではファームウェア更新要求受付部１０１５Ａｄがファームウェア更新要求を受け付け待ちをしている（図４中のステップＳ４０８）。このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００６８】
この際に、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００６９】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ａｄが受信すると（図４中のステップＳ４０８でＹＥＳ）、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを起動するよう要求する（図４中のステップＳ４０９）。
【００７０】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図４中のステップＳ４０９）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図４中のステップＳ５０１）。
【００７１】
この時点では、操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求がファームウェア更新要求受付部１０１５Ａｄで受信されている（図４中のステップＳ４０８でＹＥＳ）ため、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図４中のステップＳ５０２）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図４中のステップＳ５０３）。
【００７２】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａは、ファームウェア実行部１０１５Ａａに対してファームウェア更新完了通知を送信する（図４中のステップＳ５０４）。
【００７３】
ＯＳ状態変更部１０１５Ａｃはファームウェア更新完了通知を受信する（図４中のステップＳ４１０でＹＥＳ）と、ゲストＯＳ１０１４ｂに対して停止要求を発生する（図４中のステップＳ４１１）。
【００７４】
ＯＳ状態変更部１０１５Ａｃから停止要求を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図４中のステップＳ５０５、エンド（ゲストＯＳ＃２））。
【００７５】
ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【００７６】
なお、これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【００７７】
以上の動作において、ファームウェア更新中や、ファームウェア更新完了について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【００７８】
以上の構成（２）と動作（２）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【００７９】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【００８０】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【００８１】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動されてファームウェア更新要求を受信した後に、ファームウェア更新のためのゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによって起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【００８２】
また、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａがファームウェア更新を完了した後に、ゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによってシャットダウンさせられるため、資源や電力の無駄使いが無く、ＣＰＵパワーが無駄に使用されることがなくなる。
【００８３】
〈画像形成装置の構成（３）〉
図５に示される画像形成装置１００は、図１や図３で説明した画像形成装置１００と同様に、コンピュータを仮想化して、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａ（図５においてゲストＯＳ＃１）を実行し、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢでゲストＯＳ１０１４ｂ（図５においてゲストＯＳ＃２）を実行するものである。
【００８４】
ここで、ゲストＯＳ１０１４ａ側のプログラム１０１５Ａは、ゲストＯＳ１０１４ａ上で動作しつつファームウェア保存部１０１０からファームウェアをロードして実行させて画像形成装置を動作させるファームウェア実行部１０１５Ａａと、動作時にハートビート信号を発生し続けることで自己の生存を知らしめると共に他のハートビート信号を受信することで他の生存を確認するＯＳ生存監視部１０１５Ａｂと、ゲストＯＳ１０１４ａ上で動作しつつゲストＯＳ１０１４ｂの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ａｃと、ゲストＯＳ１０１４ａ上で動作しつつファームウェア更新要求を受け付けてファームウェア更新部１０１５Ｂａにファームウェア更新を実行させるファームウェア更新要求受付部１０１５Ａｄと、ゲストＯＳ１０１４ａ上で動作しつつ画像形成を制御する画像形成プログラム１０１５Ａｅと、を有する。なお、ここで、ハートビート信号と言ったものは、定期的な信号により自己の生存を示す信号（生存確認信号）であれば良く、既知の各種の信号を用いることが可能である。
【００８５】
また、ゲストＯＳ１０１４ｂ側のプログラム１０１５Ｂは、ゲストＯＳ１０１４ｂ上で動作しつつ更新ファームウェア保存部２００から更新ファームウェアを読み出してファームウェア保存部１０１０に書き込むファームウェア更新部１０１５Ｂａと、動作時にハートビート信号を発生し続けることで自己の生存を知らしめると共に他のハートビート信号を受信することで他の生存を確認するＯＳ生存監視部１０１５Ｂｃと、ゲストＯＳ１０１４ｂ上で動作しつつゲストＯＳ１０１４ａの起動あるいは停止といった状態を変更可能なＯＳ状態変更部１０１５Ｂｄと、を有する。
【００８６】
なお、この図５における制御部１０１は、ホストＯＳ１０１２上で実行されるゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂ、並びに各プログラムを模式的に表したものである。また、この図５における制御部１０１では仮想化数を２としてホストＯＳ１０１２上で２つのゲストＯＳを動作させるようにしているが、仮想化数は２に限定されるものではなく３以上であってもよい。また、この実施形態では、ゲストＯＳ１０１４ａ（ゲストＯＳ＃１）が第１オペレーティングシステムであり、ゲストＯＳ１０１４ｂ（ゲストＯＳ＃２）が第２オペレーティングシステムである。
【００８７】
また、ここでは、ハートビート信号を生存確認に用いているが、これ以外であっても互いの生存確認を行うことが可能な各種の手法を採用することが可能である。
【００８８】
〈画像形成装置の動作（３）〉
ここで、本実施形態の構成（３）の画像形成装置における画像形成の動作（３）について、図６のフローチャートを参照して説明する。なお、以下の説明では、プログラム，ソフトウェア，ファームウェアをメモリ上にロードして実行することを、単に実行すると言うことにする。
【００８９】
画像形成装置１００の電源がオペレータによりオンされる（図６中のステップＳ６０１）と、ファームウェア保存部１０１０等に保存されているブートローダがブート処理を行い、ホストＯＳ１０１２を起動する（図６中のステップＳ６０２）。
【００９０】
そして、ホストＯＳ１０１２上で仮想マシンモニタ１０１３がソフトウェアとして動作し、この仮想マシンモニタ１０１３はコンピュータを仮想化して仮想ハードウェア１０１３Ａと仮想ハードウェア１０１３Ｂとを２つの別個のハードウェアとして振る舞うようにする（図６中のステップＳ６０３）。
【００９１】
さらに、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡでゲストＯＳ１０１４ａを起動する（図６中のステップＳ６０４）。なお、この時点で、仮想マシンモニタ１０１３は、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂにおいて、ゲストＯＳ１０１４ｂを自動的には起動しない。
【００９２】
ここで、ゲストＯＳ１０１４ａ上で、ファームウェア実行部１０１５Ａａがファームウェア保存部１０１０からファームウェアをロードし（図６中のステップＳ６０５）、ロードしたファームウェアをファームウェア実行部１０１５Ａａが実行する（図６中のステップＳ６０６）。
【００９３】
そして、ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａによるファームウェア実行に伴い、画像形成プログラム１０１５Ａｅが実行され、画像形成装置１００としての画像形成動作を開始する（図６中のステップＳ６０７）。
【００９４】
また、ゲストＯＳ１０１４ａ上ではファームウェア更新要求受付部１０１５Ａｄがファームウェア更新要求を受け付け待ちをしている（図６中のステップＳ６０８）。このファームウェア更新要求の受付待ちとしては、通信部１０２を介した外部のコンピュータやサーバなどから送信される「ファームウェア更新要求」の受信であってもよいし、入力部１２０に接続されるＵＳＢメモリに含まれる「ファームウェア更新要求」の読み取りであってもよい。
【００９５】
この際に、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。最新のファームウェアを、入力部あるいは通信部から入力してください」などと操作部１０５にメッセージ表示をしてもよい。また、ファームウェア更新要求受付部１０１５Ａｄは、「ファームウェア更新可能です。ファームウェアを更新しますか（Ｙ／Ｎ）」などと操作部１０５にメッセージ表示をして、オペレータからのファームウェア更新要求の入力を受け付けてもよい。
【００９６】
操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求をファームウェア更新要求受付部１０１５Ａｄが受信すると（図６中のステップＳ６０８でＹＥＳ）、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを起動するよう要求する（図６中のステップＳ６０９）。
【００９７】
ここで、ＯＳ生存監視部１０１５Ａｂは、自己の生存を他のＯＳ生存監視部に対して知らしめるハートビート信号を定期的に生成する（図６中のステップＳ６１０）。このＯＳ生存監視部１０１５Ａｂからのハートビート信号は、後述するＯＳ生存監視部１０１５Ｂｃに対して送出される。
【００９８】
ゲストＯＳ１０１４ａ上のファームウェア実行部１０１５Ａａから仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂに対してゲストＯＳ１０１４ｂの起動要求が発生する（図６中のステップＳ６０９）と、仮想マシンモニタ１０１３はハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４Ｂでファームウェア更新用のゲストＯＳ１０１４ｂが起動される（図６中のステップＳ７０１）。
【００９９】
ここで、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５Ｂｃは、自己の生存を他のＯＳ生存監視部に対して知らしめるハートビート信号を定期的に生成する（図７中のステップＳ７０２）。このＯＳ生存監視部１０１５Ｂｃからのハートビート信号は、ＯＳ生存監視部１０１５Ａｂに対して送出される。
【０１００】
ゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５ＡｂはゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５Ｂｃからのハートビート信号を受信している（図６中のステップＳ６１１）。ここで、ＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号が受信できなければ（図６中のステップＳ６１１でＮＯ）、何らかの理由でゲストＯＳ１０１４ｂそのもの又はゲストＯＳ１０１４ｂ上のプログラムがハングアップ（停止）していると考えられるため、ゲストＯＳ１０１４ａ上のＯＳ状態変更部１０１５Ａｃは、仮想ハードウェア１０１３Ｂ上の仮想マシン１０１４ＢにおいてゲストＯＳ１０１４ｂを再起動するよう要求する（図６中のステップＳ６１２）。これ以後、ＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号が受信できるまで、ＯＳ状態変更部１０１５ＡｃはゲストＯＳ１０１４ｂを再起動するよう要求する（図６中のステップＳ６１１でＮＯ、ステップＳ６１２）。
【０１０１】
一方、ゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５ＡｂがＯＳ生存監視部１０１５Ｂｃからのハートビート信号を受信できれば（図６中のステップＳ６１１でＹＥＳ）、次の処理に進む。
【０１０２】
また、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５ＢｃはゲストＯＳ１０１４ａ側のＯＳ生存監視部１０１５Ａｂからのハートビート信号を受信している（図６中のステップＳ７０３）。ここで、ＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号が受信できなければ（図６中のステップＳ７０３でＮＯ）、何らかの理由でゲストＯＳ１０１４ａそのもの又はゲストＯＳ１０１４ａ上のプログラムがハングアップ（停止）していると考えられるため、ゲストＯＳ１０１４ｂ上のＯＳ状態変更部１０１５Ｂｄは、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４ＡにおいてゲストＯＳ１０１４ａを再起動するよう要求する（図６中のステップＳ７０４）。これ以後、ＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号が受信できるまで、ＯＳ状態変更部１０１５ＢｄはゲストＯＳ１０１４ａを再起動するよう要求する（図６中のステップＳ７０３でＮＯ、ステップＳ７０４）。
【０１０３】
一方、ゲストＯＳ１０１４ｂ側のＯＳ生存監視部１０１５ＢｃがＯＳ生存監視部１０１５Ａｂからのハートビート信号を受信できれば（図６中のステップＳ７０３でＹＥＳ）、次の処理に進む。
【０１０４】
この時点では、操作部１０５や更新ファームウェア保存部２００からのファームウェア更新要求がファームウェア更新要求受付部１０１５Ａｄで受信されている（図６中のステップＳ６０８でＹＥＳ）ため、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａが、更新ファームウェア保存部２００から更新ファームウェアを読み出して（図６中のステップＳ７０５）、読み出した更新ファームウェアをファームウェア保存部１０１０に書き込む（図６中のステップＳ７０６）。
【０１０５】
このようなファームウェア更新を実行した後、ファームウェア更新部１０１５Ｂａは、ファームウェア実行部１０１５Ａａに対してファームウェア更新完了通知を送信する（図６中のステップＳ７０７）。
【０１０６】
ゲストＯＳ１０１４ａ側のＯＳ状態変更部１０１５Ａｃはファームウェア更新完了通知を受信する（図６中のステップＳ６１３でＹＥＳ）と、ゲストＯＳ１０１４ｂに対して停止要求を発生する（図６中のステップＳ６１４）。また、ゲストＯＳ１０１４ｂに停止要求を発生したことでゲストＯＳ１０１４ａ側からのハートビート信号が不要になるため、ＯＳ生存監視部１０１５Ａｂはハートビート信号の送出を停止する（図６中のステップＳ６１５）。
【０１０７】
このようにしてＯＳ状態変更部１０１５Ａｃから停止要求を受けたゲストＯＳ１０１４ｂは、自らをシャットダウンして終了する（図６中のステップＳ７０８、エンド（ゲストＯＳ＃２））。
【０１０８】
ここで、仮想マシンモニタ１０１３は、ハードウェア資源（ＣＰＵやメモリ）の再分配を行い、仮想ハードウェア１０１３Ａ上の仮想マシン１０１４Ａに対して全てのハードウェア資源を割り当てるようにする。
【０１０９】
なお、これ以後、画像形成装置１００の電源が遮断されるまで、仮想マシン１０１４Ａ上のゲストＯＳ１０１４ａで、ファームウェア実行部１０１５Ａａと画像形成プログラム１０１５Ａｅとが画像形成装置１００を動作させる。
【０１１０】
以上の動作において、ファームウェア更新中、ファームウェア更新完了、ＯＳの再起動について、動作中の処理内容を操作部１０５に表示するようにしても良い。
【０１１１】
以上の構成（３）と動作（３）では、ゲストＯＳ１０１４ａ（第１オペレーティングシステム）とゲストＯＳ１０１４ｂ（第２オペレーティングシステム）とを仮想化して別個に動作させることで、ファームウェアの実行とファームウェアの更新とを異なるオペレーティングシステム上で行うようにしている。このため、それぞれのオペレーティングシステム上での処理が相手側のオペレーティングシステムに影響を与えることがない。
【０１１２】
すなわち、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行が、ゲストＯＳ１０１４ｂ上でのファームウェア更新に影響を与えることはない。また、ゲストＯＳ１０１４ｂ上でのファームウェア更新が、ゲストＯＳ１０１４ａ上でのファームウェア実行や画像形成プログラムの実行に影響を与えることもない。
【０１１３】
従って、安定した状態で画像形成とファームウェア更新とを実行することが可能になり、ファームウェア更新側ＯＳのハングアップ（停止）による画像データの喪失や、画像形成側ＯＳハングアップ（停止）によるファームウェア更新失敗といった事態を発生する可能性が極めて小さくなる。
【０１１４】
また、ゲストＯＳ１０１４ａ上でファームウェアが正常に起動されてファームウェア更新要求を受信した後に、ファームウェア更新のためのゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによって起動されるため、画像形成装置全体として正常動作した安定状態でファームウェアを更新することが可能になる。
【０１１５】
また、ゲストＯＳ１０１４ｂ上のファームウェア更新部１０１５Ｂａがファームウェア更新を完了した後に、ゲストＯＳ１０１４ｂがゲストＯＳ１０１４ａによってシャットダウンさせられるため、資源や電力の無駄使いが無く、ＣＰＵパワーが無駄に使用されることがなくなる。
【０１１６】
また、ファームウェア更新のためにゲストＯＳ１０１４ｂが動作している期間は、ゲストＯＳ１０１４ａとゲストＯＳ１０１４ｂとが互いの生存をハートビート信号により監視しており、相手方のハートビート信号が受信できない場合には相手方を再起動するようにしているため、不具合発生時にも再起動が可能になり、ファームウェア更新や画像形成について安定した動作を保つことが可能になる。
【符号の説明】
【０１１７】
１００ 画像形成装置
１０１ 制御部
１０２ 通信部
１０５ 操作部
１２０ 入力部
１３０ データ蓄積部
１５０ 画像処理部
１６０ 画像形成部
２００ 更新ファームウェア保存部
【特許請求の範囲】
【請求項１】
単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置における画像形成装置制御方法であって、
ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作させる、
ことを特徴とする画像形成装置制御方法。
【請求項２】
前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、
ことを特徴とする請求項１記載の画像形成装置制御方法。
【請求項３】
前記第１オペレーティングシステムにおいてファームウェア更新要求が受信されると前記第２オペレーティングシステムが起動される、
ことを特徴とする請求項１記載の画像形成装置制御方法。
【請求項４】
前記第１オペレーティングシステムは、前記第２オペレーティングシステムの動作状況を監視し、前記第２オペレーティングシステムの停止を検知した場合には前記第２オペレーティングシステムを再起動し、
前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視し、前記第１オペレーティングシステムの停止を検知した場合には前記第１オペレーティングシステムを再起動する、
ことを特徴とする請求項１−３のいずれか一項に記載の画像形成装置制御方法。
【請求項５】
前記第１オペレーティングシステムと前記第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、
ことを特徴とする請求項１−４のいずれか一項に記載の画像形成装置制御方法。
【請求項６】
単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置であって、
ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作可能に備える、
ことを特徴とする画像形成装置。
【請求項７】
前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、
ことを特徴とする請求項６記載の画像形成装置制御。
【請求項８】
前記第１オペレーティングシステムは、ファームウェア更新要求を受信すると前記第２オペレーティングシステムを起動する第１状態変更部を備える、
ことを特徴とする請求項６記載の画像形成装置。
【請求項９】
前記第１オペレーティングシステムは、
前記第２オペレーティングシステムの動作状況を監視する第１生存監視部と、
前記第２オペレーティングシステムの停止が前記第１生存監視部により検知された場合には前記第２オペレーティングシステムを再起動する第１状態変更部とを備え、
前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視する第２生存監視部と、前記第１オペレーティングシステムの停止が前記第２生存監視部により検知された場合には前記第１オペレーティングシステムを再起動する第２状態変更部と、
を備えることを特徴とする請求項６−８のいずれか一項に記載の画像形成装置。
【請求項１０】
前記第１オペレーティングシステムと前記第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、
ことを特徴とする請求項６−９のいずれか一項に記載の画像形成装置。
【請求項１】
単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置における画像形成装置制御方法であって、
ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作させる、
ことを特徴とする画像形成装置制御方法。
【請求項２】
前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、
ことを特徴とする請求項１記載の画像形成装置制御方法。
【請求項３】
前記第１オペレーティングシステムにおいてファームウェア更新要求が受信されると前記第２オペレーティングシステムが起動される、
ことを特徴とする請求項１記載の画像形成装置制御方法。
【請求項４】
前記第１オペレーティングシステムは、前記第２オペレーティングシステムの動作状況を監視し、前記第２オペレーティングシステムの停止を検知した場合には前記第２オペレーティングシステムを再起動し、
前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視し、前記第１オペレーティングシステムの停止を検知した場合には前記第１オペレーティングシステムを再起動する、
ことを特徴とする請求項１−３のいずれか一項に記載の画像形成装置制御方法。
【請求項５】
前記第１オペレーティングシステムと前記第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、
ことを特徴とする請求項１−４のいずれか一項に記載の画像形成装置制御方法。
【請求項６】
単一のハードウェア資源上で画像形成プログラムを実行することにより画像形成を行う画像形成装置であって、
ファームウェアおよび前記画像形成プログラムを動作させる第１オペレーティングシステムと、前記ファームウェアを更新する処理を実行させる第２オペレーティングシステムとを別個に動作可能に備える、
ことを特徴とする画像形成装置。
【請求項７】
前記第２オペレーティングシステムは、前記ファームウェアが実行された後に起動される、
ことを特徴とする請求項６記載の画像形成装置制御。
【請求項８】
前記第１オペレーティングシステムは、ファームウェア更新要求を受信すると前記第２オペレーティングシステムを起動する第１状態変更部を備える、
ことを特徴とする請求項６記載の画像形成装置。
【請求項９】
前記第１オペレーティングシステムは、
前記第２オペレーティングシステムの動作状況を監視する第１生存監視部と、
前記第２オペレーティングシステムの停止が前記第１生存監視部により検知された場合には前記第２オペレーティングシステムを再起動する第１状態変更部とを備え、
前記第２オペレーティングシステムは、前記第１オペレーティングシステムの動作状況を監視する第２生存監視部と、前記第１オペレーティングシステムの停止が前記第２生存監視部により検知された場合には前記第１オペレーティングシステムを再起動する第２状態変更部と、
を備えることを特徴とする請求項６−８のいずれか一項に記載の画像形成装置。
【請求項１０】
前記第１オペレーティングシステムと前記第２オペレーティングシステムとは、ホストオペレーティングシステム上で動作するゲストオペレーティングシステムである、
ことを特徴とする請求項６−９のいずれか一項に記載の画像形成装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１３−５４５８５（Ｐ２０１３−５４５８５Ａ）
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願番号】特願２０１１−１９３１２５（Ｐ２０１１−１９３１２５）
【出願日】平成２３年９月５日（２０１１．９．５）
【出願人】（３０３０００３７２）コニカミノルタビジネステクノロジーズ株式会社 (12,802)
【Ｆターム（参考）】
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願日】平成２３年９月５日（２０１１．９．５）
【出願人】（３０３０００３７２）コニカミノルタビジネステクノロジーズ株式会社 (12,802)
【Ｆターム（参考）】
[ Back to top ]