JP2004165734A

JP2004165734A - 画像形成装置及びファームウェアプログラム

Info

Publication number: JP2004165734A
Application number: JP2002325927A
Authority: JP
Inventors: Takeshi Morikawa; 武森川
Original assignee: Minolta Co Ltd
Current assignee: Minolta Co Ltd
Priority date: 2002-11-08
Filing date: 2002-11-08
Publication date: 2004-06-10

Abstract

【課題】トラブルが発生した場合など、緊急にファームウェアの更新処理を行う必要がある場合において、生産性の低下を抑制することができる画像形成装置、及びファームウェアプログラムを提供する。
【解決手段】ファームウェアに起因するトラブルの発生が検知された場合に、新たなファームウェアに更新する画像形成装置において、新たなファームウェアが、例えば画像読取部の制御モジュール４２３や画像形成部の制御モジュール４２４などの各制御モジュールのうち、どのモジュールを制御するファームウェアかを判定し、新たなファームウェアにより制御される部分の動作を停止し、他の部分の動作は継続させる。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
本発明は、画像形成装置及び画像形成装置の動作を制御するファームウェアプログラムに関する。
【０００２】
【従来の技術】
近年の画像形成装置の動作は、ファームウェアと称されるプログラムにより制御されることが多い。従来、ファームウェアはマスクＲＯＭに格納されており、バージョンアップ等の理由によりファームウェアを更新する必要が生じた場合には、マスクＲＯＭを交換することにより更新を行なっていた。しかし、マスクＲＯＭの交換のためにはサービスマンが画像形成装置の設置場所まで赴く必要があり、ファームウェア更新のためのコストが高いものとなっていた。そこで最近では、ファームウェアをフラッシュＲＯＭなどの書き換え可能な記憶装置に格納するようにして、電子メール等の手段を利用してインターネットを介してファームウェアを送信することにより、ファームウェアの更新を行う技術が考案されている。
【０００３】
一方、画像形成装置で問題が発生した場合にサービスセンタにエラーコード等の情報を送信し、サービスセンタ側でエラーコード等を解析、診断して、可能であれば通信回線を通じて対処を行うようなシステムにおいて、画像形成装置で発生した問題が、例えばファームウェアが想定していないような条件で動作したことによるものであると診断された場合などには、緊急にファームウェアの更新を行うことが好ましい。上記のようにインターネットを介して送信されてきたファームウェアに更新するためには、通常、画像形成装置の動作を停止する必要がある。
【０００４】
【特許文献１】
特開２０００−１１５３９３号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、ファームウェアの更新のために画像形成装置全体の動作を停止したのでは、画像形成装置の生産性が低下するという問題点があった。
本発明は、係る問題点に鑑みてなされたものであって、トラブルが発生した場合など、緊急にファームウェアの更新処理を行う必要がある場合において、生産性の低下を抑制することができる画像形成装置、及びファームウェアプログラムを提供することを目的としている。
【０００６】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る画像形成装置は、各部の動作が、当該各部のそれぞれに対応する複数のファームウェアによりそれぞれ制御される画像形成装置において、トラブルの発生を検知する検知手段と、前記トラブルに関連するファームウェアについて、バージョンの異なる別のファームウェアが存在する場合に、当該別のファームウェアを取得する取得手段と、前記取得手段が別のファームウェアを取得した場合に、当該別のファームウェアが、前記各部のうち、どの部分を制御するかを判定する判定手段と、前記判定手段による判定結果に基づき、前記各部のうち、前記別のファームウェアにより制御される部分の動作を停止する停止手段と、前記停止手段により動作が停止した後、前記別のファームウェアを、前記各部のそれぞれが備える記憶装置のうち、前記別のファームウェアにより制御される部分に備えられる記憶装置に格納する格納手段とを含むことを特徴としている。
【０００７】
この構成によると、停止手段が、ファームウェアの更新が行われる部分のみ動作を停止させる。そのため、例えば画像読取部と画像形成部とが別のファームウェアで制御されるような画像形成装置において、画像読取部のファームウェアに起因してトラブルが発生した場合でも、画像読取部だけ動作を停止させ、画像形成部の動作を継続させることができるため、画像形成装置全体の生産性の劣化を抑制することができる。なお、「別のファームウェア」には、トラブル解決のために用意された新しいバージョンのファームウェアだけでなく、バージョンアップ時のトラブルに対応するための旧バージョンのファームウェアも含まれる。
【０００８】
また、記憶装置としては、例えばフラッシュＲＯＭを用いることができるが、これに限定されず、ＭＲＡＭ（マグネチックＲＡＭ）、ＦｅＲＡＭ（強誘電体メモリ）やＯＵＭ（オボニクス・ユニファイド・メモリ）などの各種メモリを用いることもできる。
なお、前記画像形成装置はさらに、前記検知手段によりトラブルの発生が検知された場合に、前記トラブルに関する情報をネットワークを介して外部に送信する送信手段を備え、前記取得手段は、前記トラブルに関する情報に基づいて外部から送信されてくる別のファームウェアを、ネットワークを介して取得するとすることができるが、本発明はインターネット等のネットワークを介して新たなファームウェアを取得する場合に限定されず、トラブル発生時にＣＤ−ＲＯＭなどの記録媒体を介して新たなファームウェアを供給する場合にも適用することができる。
【０００９】
さらに、前記画像形成装置は、発生したトラブルが緊急に対応すべきものであるか否かを判定する緊急度判定手段と、前記緊急度判定手段により緊急に対応すべきと判定された場合に、前記各部のうち、前記格納手段による記憶装置への格納が行われた部分の再起動を指示する再起動手段とを含むことが好ましい。この場合も、再起動される部分以外は動作を継続させることができるので、生産性の劣化は抑制される。また、前記画像形成装置は、発生したトラブルが緊急に対応すべきものであるか否かを判定する緊急度判定手段と、電源がオフ状態とされたことを検知する電源検知手段を備え、前記取得手段は、前記緊急度判定手段により、緊急に対応すべきものではないと判断された場合には、前記電源検知手段により、電源がオフ状態とされたことが検知された場合に別のファームウェアを取得するとすることが好ましい。利用者により画像形成装置が使用されないタイミングでファームウェアの更新処理を行うことができるからである。
【００１０】
また、本発明に係るファームウェアプログラムは、各部の動作が、当該各部のそれぞれに対応する複数のファームウェアプログラムによりそれぞれ制御される画像形成装置において、動作を制御するファームウェアプログラムであって、トラブルの発生を検知する検知処理と、前記トラブルに関連するファームウェアについて、バージョンの異なる別のファームウェアが存在する場合に、当該別のファームウェアを取得する取得処理と、前記取得処理において別のファームウェアを取得した場合に、当該別のファームウェアが、前記各部のうち、どの部分を制御するかを判定する判定処理と、前記判定処理における判定結果に基づき、前記各部のうち、前記別のファームウェアにより制御される部分の動作を停止させる停止処理とを含む処理を前記画像形成装置にて実行させることを特徴としている。
【００１１】
【発明の実施の形態】
以下、本発明に係る画像形成装置等の実施の形態について、図面を参照しながら説明する。
（１）画像形成装置の管理システムの全体構成
図１は、本実施の形態における画像形成装置の管理システム（以下、単に「管理システム」という。）の構成を示す図である。同図の管理システム１０は、サービスセンタ２０とユーザサイト４０とをインターネット３０にて接続した構成となっている。
【００１２】
サービスセンタ２０は、ユーザサイト４０に対して新たなファームウェアを送信し、ユーザサイト４０では、それまでのファームウェアを、送信されてきた新たなファームウェアで書き換える更新処理を行う。本実施の形態では、新たなファームウェアの送信を、インターネット３０を介した電子メール・メッセージにより行う。送信されてきたファームウェアは、ユーザサイト４０の画像形成装置４２内において、一旦フラッシュＲＯＭ等の書き換え可能な記憶装置に格納され、ファームウェアが動作するＣＰＵの再起動の際にＳＲＡＭ等の記憶手段にロードされて実際の動作を行う。なお、サービスセンタ２０から送信されるファームウェアは、バージョンアップした新しいファームウェアだけでなく、バージョンアップしたファームウェアに起因してトラブルが発生した場合などは、旧バージョンのファームウェアが送信されることもある。
【００１３】
本実施の形態では、サービスセンタ２０は、各ユーザサイトに設けられた画像形成装置にトラブルが発生した場合に、当該画像形成装置から送信されてきた、例えばエラーコードなどの情報を受け付け、トラブルの原因の解析等の処理を行う。解析の結果、当該トラブルがファームウェアに起因するものであった場合に、別のファームウェアを当該ユーザサイトに送信する。即ち、サービスセンタ２０は複数のユーザサイトに対して各種画像形成装置の管理サービスを提供することができる。もっとも、いずれのユーザサイトに対して提供するサービスもトラブル解析やファームウェアの送信に関しては同様であるので、本実施の形態においてはユーザサイト４０を例として説明する。
【００１４】
サービスセンタ２０は、ルータ２５を介してインターネット３０に接続されているが、さらにセキュリティの保護のためファイアウォール２４が設けられている。サービスセンタ２０のホストコンピュータ２１は、ＬＡＮ２２を介してファイアウォール２４に接続されており、メールサーバ２３を介して各ユーザサイトと電子メールの送受信を行う。
【００１５】
ユーザサイト４０はルータ４５を介してインターネット３０に接続されており、サービスセンタ２０と同様にセキュリティ保護のためのファイアウォール４４が設けられている。ファイアウォール４４とルータ４５とを介してインターネット３０に接続されているＬＡＮ４７には、画像形成装置４２、クライアントＰＣ４３等が接続されている。ＬＡＮ４７には複数の画像形成装置を接続することが可能である。もっともこれらはユーザサイト４０の構成の一例であり、クライアントＰＣを備えていないユーザサイトもあり得る。
【００１６】
ユーザサイト４０に備えられているメールサーバ４６は、ファイアウォール４４に接続されており、クライアントＰＣ４３や画像形成装置４２等に対して電子メールの送受信サービスを提供する。なお、メールサーバを備えていないユーザサイトのクライアントＰＣや画像形成装置は外部のメールサーバ、例えばインターネットサービスプロバイダ（以下、「ＩＳＰ」と表記する。）が保有するメールサーバを利用することもできる。
【００１７】
本実施の形態での電子メールを利用したファイルの送受信には、例えばＳＭＴＰ（シンプル・メール・トランスファー・プロトコル：ＲＦＣ８２１等）、ＭＩＭＥ（マルチプル・インターネット・メール・エクステンション：ＲＦＣ１５２１等）やＰＯＰ３（ポスト・オフィス・プロトコル・バージョン３：ＲＦＣ１７２５、ＲＦＣ１９３９等）などのプロトコルを利用することができる。
【００１８】
（２）画像形成装置の構成
次に画像形成装置４２内のハードウェア構成について説明する。なお本実施の形態の画像形成装置４２は、複写機やプリンタとしての機能を兼ね備えた、いわゆるＭＦＰ（マルチ・ファンクション・ペリフェラル：デジタル複合機）であるが、本実施の形態の管理システム１０は、ＭＦＰの他にファクシミリ、複写機、プリンタ等、各種の画像形成装置を管理することが可能である。
【００１９】
図２は、画像形成装置４２のうち、特にファームウェアを実行して画像形成装置４２の動作を制御する３つの制御モジュールのハードウェア構成と各制御モジュールの接続状態を示す図である。
３つの制御モジュールはそれぞれ固有の役割を果たしているが、ハードウェア構成はほぼ同様であって、ＣＰＵやメモリ等が内部バスにて接続され、さらに内部バスに接続されたシリアルＩ／Ｆ（インターフェース）等により他の制御モジュールとシリアル通信する他、個別の機能に対応するＧＡ（ゲートアレイ）等が内部バスに接続されて構成されている。
【００２０】
さらに、制御モジュールごとのファームウェアを格納するフラッシュＲＯＭ、作業用メモリとして用いられるＳＲＡＭ（スタティックＲＡＭ）、動作設定等のパラメータを格納したＮＶＲＡＭ（不揮発性ＲＡＭ）が内部バスにそれぞれ接続されている。前記したようにファームウェアは一旦フラッシュＲＯＭに格納された後、再起動の際にＳＲＡＭにロードされるため、ＣＰＵはＳＲＡＭからファームウェアを読み出し、これに従って処理を実行する。
【００２１】
制御モジュール４２１は、画像形成装置４２のメインの制御モジュールであり、ＣＰＵ４２１１、フラッシュＲＯＭ４２１２、ＳＲＡＭ４２１３、ＮＶＲＡＭ４２１４を備えている。また、他の制御モジュール４２３、４２４とシリアル通信するためのシリアルＩ／Ｆ４２１５、４２１６やＬＡＮ４７を介して外部と通信するためのＮＩＣ（ネットワーク・インターフェース・カード）４２１７も内部バスに接続されており、さらに操作パネル４２１８も制御モジュール４２１の制御下にある。
【００２２】
制御モジュール４２１は、操作パネル４２１８等を介して、プリントジョブやコピージョブ、或いはファームウェア更新ジョブを受け付け、ジョブの実行に必要な処理を他の制御モジュール４２３、４２４に振り分けたり、各処理の順序やタイミングを指示する等の全体制御の機能を有する。なお、本実施の形態では、外部から送信された画像データやＩＲ部で原稿画像を読み取って得た画像データの圧縮等を行う画像処理部４２２１、圧縮された画像が格納される揮発性メモリである符号メモリ４２２２を備えている。この符号メモリ４２２２は、ＳＲＡＭ４２１３と物理的に同一であってもよく、例えば、いわゆる電子ソート機能により、複数部の印刷がなされるような場合、圧縮された画像データを格納することができる。
【００２３】
さらに制御モジュール４２１は、ＨＤＤ（ハード・ディスク・ドライブ）４２１９を備えている。ＨＤＤ４２１９は、不図示のＨＤＤ接続Ｉ／Ｆを介して内部バスに接続されており、ＣＰＵ４２１１は当該ＨＤＤ接続Ｉ／Ｆに指示することにより、ＨＤＤ４２１９にアクセスする。
ＮＶＲＡＭ４２１４に格納される各種設定値としては、メールサーバ４６のＩＰアドレス、メールサーバ４６から電子メールをダウンロードする際に必要となるアカウント名、パスワード、及び画像形成装置４２にトラブルが発生した場合に記録されるエラーコードなどを含むトラブル履歴情報等がある。前記したように制御モジュール４２１にはＮＩＣ４２１７が接続されており、ＬＡＮ４７等を介してインターネット３０に接続し、電子メールの送受信を行うことができる。
【００２４】
さらに制御モジュール４２１はタイマ４２２０を備えており、例えば、電子メールの受信の有無を確認してダウンロードするためにメールサーバ４６にアクセスするタイミングを取得したり、電子メールの送受信に用いるＳＭＴＰ、ＰＯＰ３等の下位層プロトコルであるＴＣＰ（トランスミッション・コントロール・プロトコル）によるパケット再送制御に必要なタイムアウトを検出するために用いられる。
【００２５】
本実施の形態のリセット部４２２３は、電源ユニット４２５からの電源を各制御モジュールに供給する電源制御Ｉ／Ｏを含んでいる。なお、当該電源制御Ｉ／Ｏは、各制御モジュールのＣＰＵ４２１１、４２３１、４２４１のリセット端子と接続されており、各制御モジュールに対して再起動を指示する機能を備える。本実施の形態では、トラブル発生時、他の制御モジュールのファームウェアのみが更新される場合には、当該制御モジュールのみに再起動を指示する。即ち、例えば画像読取部を制御するファームウェアの更新のための再起動を行いながら、画像形成動作を継続して実行することができ、画像形成装置全体の生産性の低下を抑制することができる。各制御モジュールが再起動された場合に、フラッシュＲＯＭに格納された新たなファームウェアがＳＲＡＭにロードされて、実際に動作するようになる。
【００２６】
制御モジュール４２３は、ＣＰＵ４２３１等を内部バスに接続した構成を有しており、さらに原稿画像を読み取るためのイメージリーダ（ＩＲ）の動作を制御するためのＩＲ負荷制御部Ｉ／ＯＧＡ４２３５を備えている。また、制御モジュール４２１と通信するためのシリアルＩ／Ｆ４２３６が内部バスに接続されている。
【００２７】
制御モジュール４２３は、ＩＲ負荷制御部Ｉ／ＯＧＡ４２３５を介して、原稿の紙送りをする搬送モータを制御したり、イメージリーダを駆動する駆動モータや原稿面を照射するランプの点灯を制御したりする。そして、この制御は、操作パネル４２１８にて入力された指示に基づいて制御モジュール４２１が発行する制御命令に従って実行される。
【００２８】
制御モジュール４２４もＣＰＵ４２４１、フラッシュＲＯＭ４２４２、ＳＲＡＭ４２４３、及びＮＶＲＡＭ４２４４を内部バスに接続したハードウェア構成を有しており、さらに制御モジュール４２１とシリアル通信するためのシリアルＩ／Ｆ４２４５を備えている。また、プリント負荷を制御するためのプリント負荷制御部Ｉ／ＯＧＡ４２４６を備えている。
【００２９】
制御モジュール４２４は、画像形成部を制御するモジュールであり、感光体ドラム上に潜像を形成し、これを現像して記録シートに転写し、転写したトナー像を定着して記録シートを排出するまでの一連のプリント動作にかかわるレーザダイオードの点灯制御、ポリゴンミラーや搬送ローラの駆動等の制御を、制御モジュール４２１からの指示に基づいて実行する。
【００３０】
（３）ホストコンピュータ２１の構成
次に、サービスセンタ２０に配備され、ユーザサイト４０等に設置された画像形成装置を管理するホストコンピュータ２１の構成について説明する。なお、本実施の形態では、シングルプロセッサ構成の場合について説明するが、管理する画像形成装置が多数である等の場合にはマルチプロセッサ構成としてもよい。
【００３１】
図３は、ホストコンピュータ２１の構成を示す図である。同図に示されるようにホストコンピュータ２１は、本体部２１４と、これに接続された周辺機器であるディスプレイ２１１、キーボード２１２、マウス２１３からなっている。本体部２１４は、ＣＰＵ２１４４、ＲＯＭ２１４５、ＲＡＭ２１４６等を内部バスにて接続した構成を有している。
【００３２】
本体部２１４は、周辺機器との接続インターフェースとして、ディスプレイ２１１に画像出力するための表示制御部２１４１、キーボード２１２やマウス２１３からの入力を受け付けるための入力制御部２１４２、ＬＡＮ２２に接続するためのＮＩＣ２１４３を備え、これらも内部バスに接続されている。
不図示のインターフェース部を介して内部バスに接続された固定記憶装置２１４７には、本実施の形態においてファームウェアを添付した電子メールが送信される、ホストコンピュータ２１の管理下にある各画像形成装置の電子メールアドレスを含む情報を、画像形成装置ごとに記憶する送信先データベースを格納している他、実際に送信されるファームウェアが格納される。
【００３３】
ホストコンピュータ２１には、例えばＤＢＭＳ（データベース管理システム）がインストールされており、オペレータは当該ＤＢＭＳを介して前記送信先データベースにアクセスすることができるが、ＤＢＭＳを介さず他の手段でアクセスするようにしても構わない。また、ＤＢＭＳの種類として、本実施の形態ではＲＤＢＭＳ（リレーショナルＤＢＭＳ）を用いるものとするが、他の種類のＤＢＭＳを用いてもよい。
【００３４】
なお、前記ＤＢＭＳでは、各ユーザサイトでのトラブル発生時にインターネットを介して送信されてくるエラーコードも管理されている。即ち、ホストコンピュータ２１では、送信されてきたエラーコードをキーとしてＤＢＭＳにアクセスすることで、発生したトラブルがファームウェアに起因するものであるか否かを判定することができる。
【００３５】
（４）ホストコンピュータ２１の処理内容
以上のような構成を有する管理システム１０に関し、以下、具体的な処理内容について説明するが、まず、サービスセンタ２０に設置されているホストコンピュータ２１の処理内容について、特にファームウェア更新のための電子メール送信処理に関する部分について簡単に説明する。図４は、ホストコンピュータ２１の処理内容を示すフローチャートである。
【００３６】
ホストコンピュータ２１は電源の投入により処理を開始し、まず初期化処理を行なう（Ｓ１）。初期化処理の内容としては、ＲＯＭ２１４５から読み出したブートプログラムによるＲＡＭ２１４６の初期化などのハードウェアの初期化、ＯＳ（オペレーティング・システム）や必要なアプリケーションプログラムの起動、ディスプレイ２１１への初期画面の表示などが含まれる。
【００３７】
初期化処理を終了すると、ホストコンピュータ２１は入力待ち状態となる。本実施の形態では、まず、ユーザサイトからエラーコードを受信したか否かが判断される（Ｓ２）。エラーコードを受信した場合の処理内容については後に詳細に説明する。
エラーコードが送信されていない場合（Ｓ２：Ｎｏ）、ホストコンピュータ２１は、ファームウェアの更新に関する入力、即ち「通信設定処理」、「画像形成装置登録処理」、「ファームウェア送信処理」の各指示を、キーボード２１２上に配列されたファンクションキーＦ１〜Ｆ３により受け付ける。
【００３８】
ホストコンピュータ２１は、Ｆ１キーが押下されたのを検出すると（Ｓ３：Ｙｅｓ）、通信設定処理を行う（Ｓ４）。具体的には、キーボード２１２などを介して、電子メールの送信に必要なパラメータの設定、例えば、サービスセンタ２０側のＬＡＮ２２に接続されたメールサーバ２３のＩＰアドレス、ホストコンピュータ２１の電子メールアドレス等の入力を受け付け、固定記憶装置２１４７に格納する。
【００３９】
Ｆ１キーが押下されていない場合（Ｓ３：Ｎｏ）に、Ｆ２キーが押下されたことを検出すると（Ｓ５：Ｙｅｓ）、画像形成装置登録処理を行う（Ｓ６）。具体的には、ファームウェアを送信すべき画像形成装置の電子メールアドレスや、画像形成装置内の各制御モジュールの識別子、送信すべきファームウェアのファイル名、その画像形成装置のユーザの名称、住所、電話番号等の情報の入力を受け付け、それらの情報を固定記憶装置２１４７の送信先データベースに格納する。
【００４０】
前記の通り、本実施の形態でホストコンピュータ２１が固定記憶装置２１４７に保持しているデータベースはいわゆるリレーショナルデータベースであって、情報がテーブルの形式で記憶されている。図５は、上記送信先データベースの内容の一例を示す図である。同図に示されるように、送信先データベースでは、管理システム１０による管理の対象である画像形成装置のそれぞれに固有の識別子（以下、「装置ＩＤ」という。）を付与し、さらに画像形成装置が複数の制御モジュールを有している場合には、それぞれに制御モジュールの識別子を付与して、これらをキーとし、各画像形成装置、制御モジュールごとにデータを管理している。データの項目としては、送信先の「電子メールアドレス」、「ファームウェアファイル名」、及びその他の情報を含んでいる。
【００４１】
「制御モジュール識別子」は、画像形成装置４２の如く、一の画像形成装置が複数の制御モジュールを有する場合に、ファームウェアファイル名により指定されるファイルに含まれるファームウェアが、どの制御モジュールを制御するものであるかを識別するための識別子である。ファームウェアは通常バイナリデータの形式で作成される。電子メールにファームウェアを添付すべくテキストに変換する前に、いわゆる圧縮ソフトウェアを用いて、複数のファームウェアをまとめて圧縮するようにしてもよい。
【００４２】
ファイルの圧縮には、各種の圧縮ソフトウェアを用いることができ、圧縮後のファイルの拡張子は特に限定されず、電子メールを受信した画像形成装置の側での解凍が可能である限り、ｌｚｈ、ｌｈａ、ｚｉｐ、ｇｚ、ｓｉｔ、ｃｐｔ等、圧縮方式に対応して任意のものを用いることができる。以下、図５の例に示した場合において、装置ＩＤ「１」、制御モジュール識別子「１」の場合を例としてより具体的に説明する。
【００４３】
この場合の例では、バイナリデータのファームウェアがファイル名「Ｆｉｒｍｗｒ０１．ｄａｔ」のファイルに格納されている。ファームウェアを圧縮ソフトウェアにより圧縮した場合には、圧縮方式に応じて、圧縮ファイル名（例えば「Ｆｉｒｍｗｒ０１．ｌｚｈ」）を決定することができる。複数のファームウェアをまとめて圧縮した場合には、例えば「Ｆｉｒｍｗｒ．ｌｚｈ」というようなファイル名とすることができる。生成された圧縮ファイルはバイナリデータの形式であるから、これを、例えばｂａｓｅ６４などの方法でテキストに変換した後、電子メールに添付することができる。
【００４４】
なお、「その他の情報」としては、画像形成装置のユーザの名称、住所、電話番号等の情報がテキストデータとして格納されている。もっとも、これら「ユーザの名称」、「住所」等をそれぞれ別項目としてもよいことは勿論である。
図４のフローチャートに戻って、Ｆ２キーも押下されていない場合（Ｓ５：Ｎｏ）、Ｆ３キーが押下されたのを検出すると（Ｓ７：Ｙｅｓ）、ファームウェア送信処理を行う（Ｓ８）。具体的には、ファームウェアを電子メールに添付して画像形成装置に対して送信し、ファームウェアの更新を促す。
【００４５】
さて、このファームウェア送信処理は、エラーコードを受信した場合にも行われる可能性のある処理であるから、ここで、エラーコードを受信した場合（Ｓ２：Ｙｅｓ）の処理について説明を行う。図６は、エラーコードを受信した場合の処理内容について説明するためのフローチャートである。同図に示されるように、まず、エラーコードを受信した場合には、当該エラーコードにより示されるトラブルの内容が、ファームウェアに起因するものであるか否かの判定を行う（Ｓ９１）。
【００４６】
この判定は、エラーコードのデータベースを参照することによって行うことができる。本実施の形態では、各ユーザサイトは、トラブル発生時にエラーコード、装置ＩＤ、及び当該装置で用いているファームウェアのファイル名、当該ファームウェアのバージョンを示す番号（動作しているファームウェアが複数ある場合においては、その全てについて）を送信する。
【００４７】
そして、エラーコードのデータベースを、図７に一例を示すような内容としておき、ファームウェアに起因するトラブルであるか否かを判定するためのフラグ（図７では「起因フラグ」としているが名称がこれに限定されないことは勿論である。）を参照して判定すればよい。もっとも、判定の方法はこれに限定されず、エラーコード自体、例えば下二桁の値の範囲などによって判定することもできる。
【００４８】
なお、「符号メモリの領域外アクセス」とは、例えば画像データを圧縮して符号メモリ４２２２に格納する場合に、ファームウェアが想定していないような特殊な原稿であって圧縮率が十分に上がらない場合など、符号メモリ４２２２において本来アクセスするべきでない領域にアクセスした場合が考えられ、「定着装置の温度が上昇しない」とは、定着装置自体の故障や配線異常などにより定着装置の温度が十分に上昇しない場合（ファームウェアに起因するものではない）などが考えられる。
【００４９】
ファームウェアに起因するトラブルでないと判定された場合には（Ｓ９１：Ｎｏ）、通常のトラブル診断、対応処理を行う（Ｓ９２）。ここでの処理内容の詳細については説明を省略する。ファームウェアに起因するトラブルであると判定された場合には（Ｓ９１：Ｙｅｓ）、さらに、画像形成装置４２からエラーコードと同時に送信されるファームウェアのバージョンを、データベースに格納されている最新のバージョン番号と比較する（Ｓ９３）。
【００５０】
バージョン比較の結果、サービスセンタに新たなバージョンのファームウェアが存在した場合に（Ｓ９４：Ｙｅｓ）、図４のフローチャートへ戻ってファームウェア送信処理（Ｓ８）を行う。なお、新たなバージョンのファームウェアが存在しない場合（Ｓ９４：Ｎｏ）には、バージョンアップに起因するトラブルであることを想定して旧バージョンのファームウェアメッセージを取得し（Ｓ９５）、サービスセンタ２０内のトラブル対策関係者にその旨のメッセージを送信する（Ｓ９６）。
【００５１】
その後、図４のフローチャートへと戻って入力待ち状態に戻る。また、トラブルがファームウェアに起因するものでなかった場合（Ｓ９１：Ｎｏ）にも、前記した通常のトラブル対応処理（Ｓ９２）の後、メッセージを送信して（Ｓ９６）、図４のフローチャートへと戻って入力待ち状態となる。次に、ファームウェア送信処理（Ｓ８）の内容について説明する。図８は、ファームウェア送信処理の詳細な内容を示すフローチャートである。
【００５２】
ファームウェア送信処理では、まずホストコンピュータ２１が、ファームウェア送信の対象となる画像形成装置の装置ＩＤ及び制御モジュール識別子の指定を受け付ける（Ｓ１０）。Ｆ３キーが押下された場合には、ホストコンピュータ２１は、キーボード２１２等を介して、ファームウェアの送信対象を特定する情報として、装置ＩＤ、制御モジュール識別子等の入力を受け付ける。エラーコードが送信された場合には、装置ＩＤはエラーコードとともに送信されるし、装置モジュール識別子は、エラーコードをキーとしてエラーコードテーブルから読み出すことができる。
【００５３】
ホストコンピュータ２１は、入力されたデータをキーとして送信先データベースを読み出し、当該データに対応する登録情報を含むレコードを読み出す（Ｓ１１）。次にホストコンピュータ２１は、登録情報に従い、固定記憶装置２１４７からファームウェアのファイルを読み出す（Ｓ１２）。本実施の形態では読み出されたファイルを圧縮ソフトウェアにより圧縮する（Ｓ１３）。圧縮ファイルのファイル名は、ファームウェアのファイル名や圧縮方式等により決定される。
【００５４】
圧縮ファイルはバイナリデータの形式で作成されるため、ホストコンピュータ２１は、得られた圧縮ファイルをＢａｓｅ６４等の方式によりテキストデータに変換する（Ｓ１４）。また、ホストコンピュータ２１は、得られた登録情報のレコードから電子メールアドレスを読み出し、当該電子メールアドレスを宛先とする電子メール・メッセージを作成する（Ｓ１５）。この電子メール・メッセージには、圧縮されたファームウェアの内容が添付される。なお、本実施の形態において、電子メール・メッセージのフォーマットはＲＦＣ８２２に準拠する。
【００５５】
次にホストコンピュータ２１は、作成された電子メール・メッセージをメールサーバ２３に送信する（Ｓ１６）。即ち、図４のステップＳ３にて設定されるメールサーバ２３のＩＰアドレス等を参照して、メールサーバ２３との間にＴＣＰコネクションを確立し、ＳＭＴＰに従ってメールサーバ２３に電子メール・メッセージを送付する。
【００５６】
以後、図４のフローチャートに戻り、ステップＳ６にてＦ３キーが押下されていない場合（Ｓ６：Ｎｏ）、若しくはファームウェア送信処理の終了後には、ステップＳ２へと戻り、繰返しエラーコードの受信及びファンクションキーＦ１〜Ｆ３の押下をチェックする。
（５）画像形成装置４２の処理内容
次に、画像形成装置４２において行われるファームウェア書き換え処理等の具体的な内容について説明する。図９は、画像形成装置４２、特に制御モジュール４２１１において実行される処理の内容を示すフローチャートである。この処理は本発明に係るファームウェアプログラムが例えばメイン制御モジュール４２１のＣＰＵ４２１１において動作することにより実現される。なお、本発明に係る部分以外の処理については詳細な記載を省略している。
【００５７】
このファームウェアプログラムは、電源投入時にフラッシュＲＯＭからＳＲＡＭにロードされて動作を開始し、まず、各メモリの作業領域の内容の初期化や標準モードの設定等の初期化処理を行う（Ｓ２０）。なお、このような初期化処理は、制御モジュール４２１、４２３、４２４のそれぞれにおいて個別に実行される。
【００５８】
初期化処理が終了すると、通常の処理を行う（Ｓ２１）。通常の処理とは、画像形成装置４２が通常に動作する場合に実行されるべき各種の処理である。例えば、各種入力の受付、プリントジョブ実行のためにシリアルＩ／Ｆ４２１５、４２３６を介して画像読取部の制御モジュール４２３に指示を出す処理、シリアルＩ／Ｆ４２１６、４２４５を介して画像形成部の制御モジュール４２４に指示を出す処理、操作パネル４２１８への表示、ＮＩＣ４２１７を介してプリントデータを受信する処理などがある。
【００５９】
その後、画像形成装置４２の状態監視処理を行う（Ｓ２２）。具体的には、メインの制御モジュール４２１での受信ジョブ等のトラブル発生状況、画像読取部の制御モジュール４２３からシリアルＩ／Ｆを介して送信される画像読取部のトラブル発生状況、画像形成部の制御モジュール４２４からシリアルＩ／Ｆを介して送信される画像形成部のトラブル発生状況を監視する。トラブルが発生している場合にはトラブル履歴として、エラーコードを含むトラブルに関する情報をＮＶＲＡＭ４２１４に格納する。なお、ここではリセット部４２２３に含まれる電源制御Ｉ／Ｏの状態も監視しており、利用者による電源スイッチのＯＮ／ＯＦＦも検出できるようになっている。
【００６０】
本実施の形態では、状態監視処理で検出された状態に関する情報を随時サービスセンタ２０に送信している（Ｓ２３）。サービスセンタ２０の側では、送信されてきた情報に、エラーコードが含まれていた場合に、図４のステップＳ２においてエラーコードを受信したものとして取り扱う。画像形成装置４２では、次にトラブル履歴があるか否かを判定する（Ｓ２４）。
【００６１】
トラブルが発生していない場合には（Ｓ２４：Ｎｏ）、再度通常処理へと進む（Ｓ２１）。トラブル履歴が存在した場合、即ちトラブルが発生していた場合には（Ｓ２４：Ｙｅｓ）、発生したトラブルが緊急に対処を要するトラブル（例えば、前記した符号メモリの領域外アクセスが考えられる。このトラブルの対処のためにファームウェア中の圧縮パラメータを修正する場合があり、また、読み取られた特殊な原稿の処理を行うためには、緊急で対処を行う必要がある。）であるか否かを判定する（Ｓ２５）。
【００６２】
緊急のトラブルの場合には（Ｓ２５：Ｙｅｓ）、ファームウェアが添付された電子メールの読み取り処理に移行する（Ｓ２７）。図１０は電子メール読み取り処理の詳細な内容を示すフローチャートである。電子メール読み取り処理において、制御モジュール４２１は、まずメールサーバ４６との間でＴＣＰコネクションを確立する（Ｓ３１）。ＴＣＰコネクションを確立したら、ＰＯＰ３に従い、メールサーバ４６に新着メッセージ、即ち新たな電子メール・メッセージが入着したか否かを問い合わせる。新着メッセージがある場合には（Ｓ３２：Ｙｅｓ）、当該メッセージを制御モジュール４２１にダウンロードするようにメールサーバ４６に要求する（Ｓ３３）。
【００６３】
制御モジュール４２１は新着メッセージを受け取ると、現時刻を計時してＮＶＲＡＭ４２１４の所定アドレスに格納する。本実施の形態では、制御モジュール４２１は受け取った新着メッセージのメッセージ・ヘッダ部の「Ｃｏｎｔｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」フィールドを参照して、そのフィールド・ボディに「Ｆｉｒｍｗａｒｅ」と記載されているか否かをチェックする。
【００６４】
前記フィールド・ボディに「Ｆｉｒｍｗａｒｅ」と表示されていたら、制御モジュール４２１は前記メッセージにファームウェアの内容が添付されていると判定し（Ｓ３４：Ｙｅｓ）、ファームウェアに相当するテキスト部分を取り出す（Ｓ３５）。なお、本実施の形態では、「Ｃｏｎｔｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」フィールドのフィールド・ボディに「Ｆｉｒｍｗａｒｅ」と記載されているか否かにより、ファームウェアが含まれているか否かを判定したが、判定手法はこれに限定されず、「Ｓｕｂｊｅｃｔ」フィールドの内容、添付されているファイル名等を参照して判定するようにしてもよい。また、判定ミスの防止のため、上記の判定手法を組合せて（例えば、「Ｃｏｎｔｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」フィールドの内容とファイル名の両方を参照する。）判定するようにしてもよい。
【００６５】
取り出されたＵＳ−ＡＳＣＩＩデータはＢａｓｅ６４方式に基づいて復号化され（逆Ｂａｓｅ６４変換）、ファームウェアを含む圧縮ファイル（本実施の形態では、ファイル名＝「Ｆｉｒｍｗｒ０１．ｌｚｈ」）に戻される（Ｓ３６）。この圧縮ファイルを解凍することによりファームウェアが得られる。複数のファームウェアがまとめて圧縮されている場合には、解凍により得られた複数のファイルのそれぞれのファイル名から、各ファイルがどの制御モジュールに対応するファームウェアかを判定することができる。制御モジュール４２１は、バイナリデータのチェックサムを計算して、ＮＶＲＡＭ４２１４の所定アドレスに格納する（Ｓ３７）。
【００６６】
以上のようにファームウェアのダウンロードを行なった後、制御モジュール４２１は、ＰＯＰ３に従い、メールサーバ４６からダウンロード済みの電子メール・メッセージを削除する（Ｓ３８）。そして、メールサーバ４６との間のＴＣＰコネクションを切断して（Ｓ３９）、電子メール読み取り処理を終了する。新着メッセージがない場合（Ｓ３２：Ｎｏ）、若しくは新着メッセージがあってもファームウェアが添付されていない場合には（Ｓ３４：Ｎｏ）、直接ステップＳ３９へと進み、メールサーバ４６との間のＴＣＰコネクションを切断して、電子メール読み取り処理を終了する。
【００６７】
なお、メールサーバ４６からダウンロード済みの電子メール・メッセージを削除する処理については、画像形成装置４２におけるファームウェアの更新等の処理が終了した後に実行するようにしてもよい。ファームウェアの更新の失敗は、チェックサムにて判断可能な場合（例えばデータ化け）だけでなく、更新途中で画像形成装置４２の電源がオフ状態とされた場合等にも生じ得るので、そのような場合にメールサーバ４６に電子メール・メッセージを残しておき、再度電源がオン状態となった場合に電子メール・メッセージを取得するようにすることなども考えられる。
【００６８】
また、電子メール・メッセージの削除は、必ずしもダウンロードの際に行う必要はなく、ダウンロードの際には電子メール・メッセージを残しておき、所定時間ごとに削除の処理を行うようにしたり、電源投入時に処理済みの電子メール・メッセージを削除するようにすることもできる。
電子メール読み取り処理を終了すると、制御モジュール４２１は、ファームウェアを受信したか否かを判定する（Ｓ２８）。ファームウェアを受信していない場合には（Ｓ２８：Ｎｏ）、本実施の形態では、再度電子メールの読み取り処理を行うようにしているが（Ｓ２７）、これに限らず、例えば通常処理（Ｓ２２）に戻るようにしてもよい。
【００６９】
ファームウェアを受信した場合（Ｓ２８：Ｙｅｓ）には、ファームウェア書き換え処理を実行する（Ｓ２９）。以下、本実施の形態におけるファームウェア書き換え処理の詳細な内容について説明する。
図１１は、ファームウェア書き換え処理の詳細な内容を示すフローチャートである。本実施の形態のファームウェア書き換え処理では、まず、送信されてきたファームウェアがどの制御モジュールに対応するものかを判定する（Ｓ５１）。本実施の形態では、解凍されたファームウェアのファイル名から判定することができる。ファームウェアがメインの制御モジュール４２１に対応するものである場合、ファームウェアの更新の際には、プリントデータの受信ジョブ、プリントジョブ、画像読取ジョブの全てが実行不可能な状態となる。従って全てのジョブの実行を停止し（Ｓ５２）、メイン制御モジュールのフラッシュＲＯＭ４２１２の書き換えを行う（Ｓ５３）。そしてトラブル履歴を消去する（Ｓ５４）。これは次にトラブルが発生しない限り、ファームウェアの更新を行う必要がないからである。最後にメイン制御モジュール４２１の再起動処理を行う（Ｓ５５）。本実施の形態では、リセット部４２２３に含まれる電源制御Ｉ／Ｏを介してソフトウェアリセット処理を行う。もっとも再起動の方法はこれに限定されず、電源スイッチのオン・オフを制御する等の方法を用いてもよい。この再起動処理により新たなファームウェアがＳＲＡＭにロードされて動作が開始する。
【００７０】
更新すべきファームウェアが画像形成部の制御モジュール４２４に対応するようなものである場合には、更新の際にプリントジョブが実行不可能となるが、プリントデータの受信ジョブや画像読取ジョブはそのまま実行することが可能である。従って、本実施の形態ではプリントジョブのみ実行停止処理を行う（Ｓ５６）。その後、シリアルＩ／Ｆ４２１６、４２４５を介して、受信したファームウェアを制御モジュール４２４に送信する処理を行う（Ｓ５７）。これを受信した制御モジュール４２４は、フラッシュＲＯＭ４２４２の更新処理を行う。その後、トラブル履歴を消去し（Ｓ５８）、制御モジュール４２４にて更新後のファームウェアを動作させるため、リセット部４２２３を介してリセット信号を出力し、画像形成部の制御モジュール４２４を再起動させる（Ｓ５９）。
【００７１】
更新すべきファームウェアが画像読取部の制御モジュール４２３に対応するようなものである場合には、更新の際に画像読取ジョブが実行不可能となるが、プリントデータの受信ジョブやプリントジョブはそのまま実行することが可能である。従って、本実施の形態では画像読取ジョブのみ実行停止処理を行う（Ｓ６０）。その後、シリアルＩ／Ｆ４２１５、４２３６を介して、受信したファームウェアを制御モジュール４２３に送信する処理を行う（Ｓ６１）。これを受信した制御モジュール４２３は、フラッシュＲＯＭ４２３２の更新処理を行う。その後、トラブル履歴を消去して（Ｓ６２）、制御モジュール４２３にて更新後のファームウェアを動作させるため、リセット部４２２３を介してリセット信号を出力し、画像読取部の制御モジュール４２３を再起動させる（Ｓ６３）。
【００７２】
以上の処理を終了すると、図９のフローチャートに戻って、再度通常処理に移行する（Ｓ２１）。なお、メインの制御モジュール４２１で動作していたファームウェアが更新される場合には、それまで動作していたファームウェアの動作は終了する。
＜変形例＞
以上、本発明を実施の形態に基づいて説明してきたが、本発明の内容が、上記実施の形態に示された具体例に限定されないことは勿論であり、例えば、以下のような変形例を考えることができる。
【００７３】
（１）本実施の形態では、エラーコードのテーブルをサービスセンタ２０側に用意し、当該テーブルの内容に基づいて、発生したトラブルがファームウェアに起因するものであるか否かを判定したが、エラーコードに関する詳細情報は、画像形成装置内部に保持し、ファームウェアに起因するものか否かの情報をサービスセンタに送信するようにしてもよい。
【００７４】
（２）本実施の形態では、制御モジュールが三つの画像形成装置４２に本発明を適用した場合の例について説明したが、制御モジュールの数に制限はない。また、画像読取部や画像形成部に限ることなく、モジュールごとに動作の停止や再起動が可能な部分であれば（例えばフィニッシャなどの付属装置を別のファームウェアで制御する場合など）、本発明を適用することは可能である。
【００７５】
【発明の効果】
以上のように、本発明に係る画像形成装置等によれば、ファームウェアに起因するトラブルの発生に対応してファームウェアの更新をする場合に、更新される部分のみ動作の停止を行うようにしているため、他の部分の動作を停止させる必要がなく、生産性の低下を抑制することができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る画像形成装置の管理システムの構成を示す図である。
【図２】画像形成装置４２のうち、特にファームウェアを実行して画像形成装置４２の動作を制御する３つの制御モジュールのハードウェア構成と各制御モジュールの接続状態を示す図である。
【図３】ホストコンピュータ２１の構成を示す図である。
【図４】ホストコンピュータ２１の処理内容を示すフローチャートである。
【図５】送信先データベースの内容の一例を示す図である。
【図６】サービスセンタ側で、エラーコードを受信した場合の処理内容について説明するためのフローチャートである。
【図７】エラーコードのデータベースの内容の一例を示す図である。
【図８】ファームウェア送信処理の詳細な内容を示すフローチャートである。
【図９】画像形成装置４２側で実行される処理の内容を示すフローチャートである。
【図１０】電子メール読み取り処理の詳細な内容を示すフローチャートである。
【図１１】ファームウェア書き換え処理の詳細な内容を示すフローチャートである。
【符号の説明】
１０管理システム
２０サービスセンタ
２１ホストコンピュータ
３０インターネット
４０ユーザサイト
４２画像形成装置
４２１メイン制御モジュール
４２１４ＮＶＲＡＭ
４２２３リセット部
４２３画像読取部の制御モジュール
４２４画像形成部の制御モジュール
４６メールサーバ

Claims

各部の動作が、当該各部のそれぞれに対応する複数のファームウェアによりそれぞれ制御される画像形成装置において、
トラブルの発生を検知する検知手段と、
前記トラブルに関連するファームウェアについて、バージョンの異なる別のファームウェアが存在する場合に、当該別のファームウェアを取得する取得手段と、
前記取得手段が別のファームウェアを取得した場合に、当該別のファームウェアが、前記各部のうち、どの部分を制御するかを判定する判定手段と、
前記判定手段による判定結果に基づき、前記各部のうち、前記別のファームウェアにより制御される部分の動作を停止する停止手段と、
前記停止手段により動作が停止した後、前記別のファームウェアを、前記各部のそれぞれが備える記憶装置のうち、前記別のファームウェアにより制御される部分に備えられる記憶装置に格納する格納手段とを含む
ことを特徴とする画像形成装置。
前記画像形成装置はさらに、
前記検知手段によりトラブルの発生が検知された場合に、前記トラブルに関する情報をネットワークを介して外部に送信する送信手段を備え、
前記取得手段は、
前記トラブルに関する情報に基づいて外部から送信されてくる別のファームウェアを、ネットワークを介して取得する
ことを特徴とする請求項１に記載の画像形成装置。
前記画像形成装置は、
発生したトラブルが緊急に対応すべきものであるか否かを判定する緊急度判定手段と、
前記緊急度判定手段により緊急に対応すべきと判定された場合に、前記各部のうち、前記格納手段による記憶装置への格納が行われた部分の再起動を指示する再起動手段とを含む
ことを特徴とする請求項１又は２に記載の画像形成装置。
前記画像形成装置は、
発生したトラブルが緊急に対応すべきものであるか否かを判定する緊急度判定手段と、
電源がオフ状態とされたことを検知する電源検知手段を備え、
前記取得手段は、
前記緊急度判定手段により、緊急に対応すべきものではないと判断された場合には、前記電源検知手段により、電源がオフ状態とされたことが検知された場合に別のファームウェアを取得する
ことを特徴とする請求項１又は２に記載の画像形成装置。
各部の動作が、当該各部のそれぞれに対応する複数のファームウェアプログラムによりそれぞれ制御される画像形成装置において、動作を制御するファームウェアプログラムであって、
トラブルの発生を検知する検知処理と、
前記トラブルに関連するファームウェアについて、バージョンの異なる別のファームウェアが存在する場合に、当該別のファームウェアを取得する取得処理と、
前記取得処理において別のファームウェアを取得した場合に、当該別のファームウェアが、前記各部のうち、どの部分を制御するかを判定する判定処理と、
前記判定処理における判定結果に基づき、前記各部のうち、前記別のファームウェアにより制御される部分の動作を停止させる停止処理とを含む処理を前記画像形成装置にて実行させる
ことを特徴とするファームウェアプログラム。