JP2015225478A - 情報処理装置のファームアップデートにおけるバックアップ方法 - Google Patents

Abstract

【課題】従来技術においては、ファームウェアをアップデートする場合、アップデートに失敗したときのリカバリのために、すべてのファームウェアをバックアップしている。しかし、アップデートするモジュールが少ない場合でも、必ずすべてのファームをバックアップしているため、時間を非常に要していた。よって、ファームウェアの差分アップデートの効果を活かした早くて安全な、バックアップを含むアップデートの仕組みを提供することを目的とする。
【解決手段】アップデート対象となるモジュールを特定するアップデート対象ファーム特定手段と、前記アップデート対象ファーム特定手段において特定されたモジュール内に含まれる、モジュール展開情報を参照する展開情報参照手段と、前記展開情報参照手段においてモジュールの展開先を特定する展開先特定手段と、前記展開先部分のみをバックアップする差分バックアップ手段と、アップデートを実施するアップデート実施手段と、を備える情報処理装置。
【選択図】図６

Description

本発明は、情報処理装置におけるファームアップデートを行う際に、現在動作しているファームをバックアップする、そのバックアップ方法に関する。

従来の情報処理装置のファームアップデートにおいては、アップデートが失敗するケースがありうる。そのため、失敗したときに前の状態に戻すため、現在動作中のファームウェアをバックアップしておく技術があり、それを利用して失敗時のリカバリを実施するケースがある。特にバックアップ方法においては、ファームウェアをネットワーク上のサーバに転送しておき、アップデートが正常に完了しなかった場合に転送しておいた古いファームウェアを書き戻す、といった技術が知られている（特許文献１参照）。また、ファームウェアのうち、必要な部分のみをアップデートする差分アップデートという技術が公知である。

特開２００４−３５６７６７号公報

しかし、特許文献１に記載された技術においては、ファームウェアを必ずすべてバックアップしておく必要がある。アップデートに失敗したときのリカバリのために、バックアップは必要だが、その一方で、アップデートはファームウェアを搭載した情報処理装置のダウンタイムにも繋がるため、短時間で終わらせる必要がある。今回、課題とするのは、このバックアップ対象となるファームについてである。先行技術である特許文献１においては、ファームウェアを必ずすべてバックアップするため、ファームウェアのうち、不要なバックアップをしている可能性もある。つまり、前述した差分アップデートが公知技術である今、バックアップ処理としても差分アップデートされる部分のみのファームをバックアップすべきである。

本発明は、上記の問題点を鑑み成されたものであり、ファームアップデートを実施する際に実施するバックアップを、差分アップデート対象となるファームウェアの一部分のみバックアップする、差分バックアップという仕組みを提供することを目的とする。

上記の目的を達成するために本発明に係る情報処理装置の構成は、ソフトウェアが複数モジュールに分割され、ある特定のモジュールのみをアップデートする差分アップデートが可能な情報処理装置において、アップデート対象となるモジュールを特定するアップデート対象ファーム特定手段と、前記アップデート対象ファーム特定手段において特定されたモジュール内に含まれる、モジュール展開情報を参照する展開情報参照手段と、前記展開情報参照手段においてモジュールの展開先を特定する展開先特定手段と、前記展開先部分のみをバックアップする差分バックアップ手段と、アップデートを実施するアップデート実施手段と、を備えることを特徴とする。

本発明によれば、ファームアップデート実施対象の数や大きさに応じて、必要な部分のみバックアップし、異常時のリカバリ処理の準備をすることができる。必要な部分のみバックアップすることにより、通常のファームアップデートの時間短縮に大幅に寄与する。また、リカバリ時の処理も差分部分のみ使用するため時間短縮に寄与することができる。

情報処理装置１００の構成を示すブロック図の一例である。 ＦｌａｓｈＲＯＭ２１１の構成図の一例である。 ＦｌａｓｈＲＯＭ２１１に含まれたファームウェアを構成するモジュールに含まれる設定ファイルの一例である。 ファームウェア内のディレクトリ構成の一例である。 バックアップを含むアップデート処理のフローチャートの一例である。 バックアップを含むアップデート処理のフローチャートの一例である。 バックアップを含むアップデート処理のフローチャートの一例である。 バックアップを含むアップデート処理のフローチャートの一例である。 ファームアップデートの一連の流れについてフローチャートである。 図７で説明したアップデートが失敗したとき流れについてフローチャートである。

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、情報処理装置１００の構成を示すブロック図の一例である。ＣＰＵ２１０を含む制御部２００は、情報処理装置１００全体の動作を制御する。ＣＰＵ２１０は、ＦｌａｓｈＲＯＭ２１１に記憶された制御プログラムを読み出して読取制御や印刷制御、ファームアップデート制御などの各種制御処理を実行する。また、ファームアップデート用のファイル格納領域、ワークエリア、またユーザデータ領域としても用いられる。ＲＡＭ２１２は、ＣＰＵ２１０の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２１３は、画像データやユーザデータ等を記憶する。ＨＤＤ２１３が接続されないケースもある。

操作部Ｉ／Ｆ２１４は、操作部２１９と制御部２００とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。プリンタＩ／Ｆ２１５は、プリンタエンジン２２０と制御部２００とを接続する。プリンタエンジン２２０内に含む図示しないＲＯＭにはプリンタエンジンファーム２５０が格納されている。プリンタエンジン２２０で印刷すべき画像データはプリンタＩ／Ｆ２１５を介して制御部２１０からプリンタエンジン２２０に転送され、プリンタ２２０において記録媒体上に印刷される。また、プリンタエンジン２２０はフィニッシャエンジン２２２とも接続するケースがある。フィニッシャエンジン２２２内に含む図示しないＲＯＭにはフィニッシャエンジンファーム２５２が格納されている。フィニッシャエンジン２２２は、プリンタエンジン２２０から送られた印刷済みの記録媒体をソートしたりステイプルしたりする機能を持つ。

スキャナＩ／Ｆ２１６は、スキャナエンジン２２１と制御部２００とを接続する。スキャナエンジン２２１内に含む図示しないＲＯＭにはスキャナエンジンファーム２５１が格納されている。また、スキャナエンジンファーム２５１をＦｌａｓｈＲＯＭ２１１に含むケースもある。スキャナエンジン２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２００に入力する。

ＵＳＢ−ＨｏｓｔＩ／Ｆ２１７は、ＵＳＢ−ＦＡＸエンジン２２３と制御部２００とを接続する。ＵＳＢ−ＦＡＸエンジン２２３内に含む図示しないＲＯＭにはＵＳＢ−ＦＡＸエンジンファーム２５３が格納されている。

ＵＳＢ−ＦＡＸエンジン２２３は、スキャナエンジン２２１により読み取った画像データをＦＡＸ回線１１５を介してＦＡＸ送信する機能を持つ。また、ＵＳＢ−ＨｏｓｔＩ／Ｆ２１７は、外部ＵＳＢデバイス２２４とも接続可能である。

外部ＵＳＢデバイス２２４は、ＵＳＢメモリやＵＳＢキーボードなどが例として挙げられる。ＵＳＢメモリにアップデートファームを格納し、ダウンロードしてＦｌａｓｈＲＯＭ２１１のファイル格納領域に置くケースもある。

ネットワークＩ／Ｆ２１８は、制御部２００（情報処理装置１００）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ２１８は、ＬＡＮ１１０上の外部装置（例えば、外部サーバ２２５やＰＣ２２６）に画像データや情報を送信したり、逆にアップデートファームや各種情報を受信したりする。外部サーバ２２５はインターネット上に存在するケースもある。

図２はＦｌａｓｈＲＯＭ２１１の構成図の一例である。３１０はファームウェアであり通常プログラムが格納された領域である。このファームウェア３１０は、図１で説明したような各種機能を動作させるプログラムである。３１１はアップデートファームウェアであり、ファームウェア３１０をアップデートする指示を出したり、旧ファームウェアをバックアップする指示をしたりするプログラムである。

３２０はアップデート対象ファームウェア置き場であり、図１で説明したＵＳＢ−ＨｏｓｔＩ／Ｆ２１７やネットワーク２１８経由でダウンロードしたファームウェアを置く場所である。このアップデート対象ファームウェア置き場３２０はファームウェア３１０、アップデートファームウェア３１１双方から参照できる場所となっている。

３２１は旧ファームウェアバックアップ場所であり、ファームウェア３１０をアップデートする際に、そのファームウェアをバックアップ（退避）しておくための場所である。この場所も、ファームウェア３１０、アップデートファームウェア３１１双方から参照できる場所となっている。

図３はＦｌａｓｈＲＯＭ２１１に含まれたファームウェア３１０の構成図の一例を表したものである。３５０が各モジュールを示している。たとえば、システム制御モジュール３６０では、メモリの管理や設定値の管理などを行っている。また、図２におけるアップデート対象ファームウェア置き場３２０に配置する、アップデート対象ファームウェアも同様に各モジュールに分割されている。アップデート対象ファームウェアのモジュールの内容は図４（ａ）（ｂ）にて、ＦｌａｓｈＲＯＭ２１１に含まれたファームウェア３１０のディレクトリ構成、ファイル構成については図５で説明する。

図４（ａ）は、アップデート対象ファームウェアのモジュールの内容の一例を示したもので、図３におけるシステム制御モジュール３６０の内部構造を示したものである。本例におけるシステム制御モジュールの名称にはバージョンが付随しており、例えばｓｙｓｔｅｍ−３．１．１．ｐｋｇといった名称になっている。このｓｙｓｔｅｍ−３．１．１．ｐｋｇは圧縮（例えばｚｉｐ圧縮）されており、中身のファイルは例えば以下のようになっている。実行モジュールｓｙｓｔｅｍ．ｂｉｎ、共有ライブラリｌｉｂｓｙｓｔｅｍ．ｓｏ．３．１．１、他の実行ファイル、ライブラリが参照先として指定するｌｉｂｓｙｓｔｅｍ．ｓｏ．３．１．１へのシンボリックリンクファイルｌｉｂｓｙｓｔｅｍ．ｓｏ．３、設定ファイルｓｙｓｔｅｍ−３．１．１．ｃｏｎｆ。特に設定ファイルｓｙｓｔｅｍ−３．１．１．ｃｏｎｆの中にはシステム制御モジュール３６０に含まれるファイル群の配置場所やパーミッション情報が含まれている。これについては図４（ｂ）にて説明する。

図４（ｂ）は、図４（ａ）における設定ファイルｓｙｓｔｅｍ−３．１．１．ｃｏｎｆの内容を示したものである。ｎａｍｅフィールドに名称、ｇｒｏｕｐフィールドに本モジュールのグループ、ｖｅｒｓｉｏｎフィールドにバージョン、ｐａｃｋａｇｅｒフィールドに作成者とメールアドレス、ｆｉｌｅｓフィールドにファイル名とパーミッションが記載されている。特にｆｉｌｅｓフィールドにおいては、システム制御モジュール３６０に含まれるファイル群の配置場所やパーミッション情報が含まれている。例えば、実行モジュールｓｙｓｔｅｍ．ｂｉｎは／ｂｉｎ／というディレクトリに展開されるように指定されていて、パーミッションは０７５５（自分自身はリード・ライト・実行可能、同一ｇｒｏｕｐ、他ｇｒｏｕｐはリード・実行可能）といった形になっている。

また、共有ライブラリｌｉｂｓｙｓｔｅｍ．ｓｏ．３．１．１は／ｌｉｂ／というディレクトリに展開されるように指定されていて、パーミッションは０６４４（自分自身はリード・ライト可能、同一ｇｒｏｕｐ、他ｇｒｏｕｐはリード・可能）といった形になっている。また、共有ライブラリへのシンボリックリンクｌｉｂｓｙｓｔｅｍ．ｓｏ．３は／ｌｉｂ／というディレクトリに展開されるように指定されていて、パーミッションは記載が省略されている。これは、シンボリックリンクは一般的に意味をもたないためであり、特に指定されていない。

図５は、ＦｌａｓｈＲＯＭ２１１に含まれたファームウェア３１０のディレクトリ情報を示したものである。この情報ファイルもモジュール化されており、図４（ａ）（ｂ）に近いフォーマットとなっている。ｎａｍｅフィールド、ｇｒｏｕｐフィールド、ｖｅｒｓｉｏｎフィールド、ｐａｃｋａｇｅｒフィールドは図４（ａ）（ｂ）と同様である。ｄｉｒｎａｍｅフィールドは、ディレクトリ名とそのディレクトリのオーナーとなるユーザ、グループ、パーミッションが記載されている。例えば図４（ａ）（ｂ）で記載された／ｂｉｎ／、／ｌｉｂ／については、オーナーがｒｏｏｔ、グループがｒｏｏｔ、パーミッションが０７５５となっている。図２においてアップデートファームウェア３１１によりアップデート指示が出された場合、図４（ａ）（ｂ）の情報を元に、ファームウェア３１０における図５で示されたディレクトリにファイルが展開される。

図６は、ファームアップデートの一連の流れについてフローチャートにて説明した図である。Ｓ１０１では、アップデート対象ファームウェア置き場３２０に対し、ＵＳＢ−ＨｏｓｔＩ／Ｆ２１７やネットワーク２１８経由でダウンロードしたファームウェアを、アップデートファームウェア３１１がアップデート対象のものと特定する。Ｓ１０２では、そのアップデート対象の各モジュール３５０から展開先情報を参照する。参照する情報は図４（ａ）（ｂ）で示したとおりである。Ｓ１０３では、図４（ｂ）に記載されている情報から、各ファイルの展開先ディレクトリを特定する。次に、Ｓ１０４で、Ｓ１０３で特定したディレクトリ、例えば／ｌｉｂ以下を、アップデートファームウェア３１１が旧ファームウェアバックアップ場所３２１にバックアップする。そして、Ｓ１０５では、アップデートファームウェア３１１が、ファームウェア３１０をアップデートして終了する。

図７は、アップデートが失敗したときの動作について説明した図である。アップデートファームウェア３１１が旧ファームウェアバックアップ場所３２１から、図６のＳ１０４でバックアップしたファームウェアをファームウェア３１０にリカバリする（書き戻す）。

図８は、図６とほぼ同様であるが、図７で説明した、アップデートが失敗したときの流れについてフローチャートで示した図である。Ｓ２０１からＳ２０５までは、Ｓ１０１からＳ１０５までと同様である。Ｓ２０５でファームウェアのアップデートを実施した際に、Ｓ２０６でアップデートが成功したかどうかを判断し、成功ならそのまま終了する。アップデートが失敗した場合には、Ｓ２０７で、図７で説明したように、旧ファームウェアをリカバリする（書き戻す）。

実施例１との差分は、バックアップ対象を、ディレクトリではなくファイルそのものにする点である。図１から図５、図７については同様である。フローチャートのみの差分説明となる。

図９はファームアップデートの一連の流れについてフローチャートにて説明した図である。Ｓ３０１では、アップデート対象ファームウェア置き場３２０に対し、ＵＳＢ−ＨｏｓｔＩ／Ｆ２１７やネットワーク２１８経由でダウンロードしたファームウェアを、アップデートファームウェア３１１がアップデート対象のものと特定する。Ｓ３０２では、そのアップデート対象の各モジュール３５０から展開先情報を参照する。参照する情報は図４（ａ）（ｂ）で示したとおりである。Ｓ３０３では、図４（ｂ）に記載されている情報から、各ファイルを特定する。次に、Ｓ３０４で、Ｓ３０３で特定したファイル、例えば／ｂｉｎ／ｓｙｓｔｅｍ．ｂｉｎ，／ｌｉｂ／ｌｉｂｓｙｓｔｅｍ．ｓｏ．３．１．１，／ｌｉｂ／ｌｉｂｓｙｓｔｅｍ．ｓｏ．３を、アップデートファームウェア３１１が旧ファームウェアバックアップ場所３２１にバックアップする。そして、Ｓ１０５では、アップデートファームウェア３１１が、ファームウェア３１０をアップデートして終了する。

図１０は、図９とほぼ同様であるが、図７で説明した、アップデートが失敗したとき流れについてフローチャートで示した図である。Ｓ４０１からＳ４０５までは、Ｓ３０１からＳ３０５までと同様である。Ｓ４０５でファームウェアのアップデートを実施した際に、Ｓ４０６でアップデートが成功したかどうかを判断し、成功ならそのまま終了する。アップデートが失敗した場合には、Ｓ４０７で、図７で説明したように、旧ファームウェアをリカバリする（書き戻す）。

２１１ ＦｌａｓｈＲＯＭ、２２０ プリンタエンジン、２２１ スキャナエンジン、
２２２ フィニッシャエンジン、２２３ ＵＳＢ−ＦＡＸエンジン

Claims (4)

1. ソフトウェアが複数モジュールに分割され、ある特定のモジュールのみをアップデートする差分アップデートが可能な情報処理装置において、アップデート対象となるモジュールを特定するアップデート対象ファーム特定手段と、前記アップデート対象ファーム特定手段において特定されたモジュール内に含まれる、モジュール展開情報を参照する展開情報参照手段と、前記展開情報参照手段においてモジュールの展開先を特定する展開先特定手段と、前記展開先部分のみをバックアップする差分バックアップ手段と、アップデートを実施するアップデート実施手段と、を備えることを特徴とする情報処理装置。
2. アップデートに失敗した際に、前記差分バックアップ手段によってバックアップされた部分のみを書き戻すリカバリ手段を備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記展開先特定手段によって特定される展開先は、ディレクトリであることを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記展開先特定手段によって特定される展開先は、ディレクトリ兼ファイルであることを特徴とする請求項１又は請求項２に記載の情報処理装置。