(57)【要約】      （修正有）【課題】ファームウェアの更新が不完全になることを回避する。又、ＲＯＭの空き容量が不足する場合のファームウェア更新を行う。【解決手段】ファームウェアの更新を、ファイルシステムを経由してフラッシュメモリなどＲＯＭの空き領域に更新すべきファイルを別ファイルとして書き込み、正常に書き込みが終了した後、更新すべきファイルが本来の名称になるようファイルシステムを操作することで、ファームウェアの更新が不完全になることを回避する。またファームウェアの更新を複数のファイルの組み合わせで行う必要がある場合やＲＯＭの空き容量が足りない場合など、更新用モジュールを用いることにより、安全確実なファームウェア更新を行う。【選択図】図４
2006202086.tif 000002
【特許請求の範囲】
【請求項１】
ファイルシステムを経由してフラッシュメモリなどＲＯＭの空き領域に更新すべきファイルを別ファイルとして書き込み、正常に書き込みが終了した後、更新すべきファイルが本来の名称になるようファイルシステムを操作し、更新が不完全になることを回避することを特徴とするファームウェア更新方法。
【請求項２】
総ファイルサイズが空き領域をこえるような複数のファイルの組み合わせでファームウェアの更新を行う必要がある場合など、必要なファイルを更新する機能を有する更新用モジュールを用いて、不正なファイルの組み合わせとなることを回避し、複数回の差分更新をくりかえすことにより更新が可能なことを特徴とするファームウェア更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファームウェア更新中の障害に対して、特別な自動復旧機能などを必要としない安全確実なファームウェア更新方法に関するものである。
【背景技術】
【０００２】
ファームウェアの更新中に電源断など不慮の障害が発生すると、ＲＯＭ内のファームウェアが不完全に書き換えられて破損してしまうことにより、システムが起動しない状態になってしまう可能性がある。ファームウェア復旧のためにはＲＯＭを交換するなどの手作業が必要であった。
【０００３】
ファームウェア復旧の自動化に関しては、様々な方法が提案されている。たとえば、特開平１０−３０７７２６「起動エラー時におけるファームウェア リカバリ方式」では、更新前のファームウェアをあらかじめ別の記憶装置にバックアップを行う方法が、また特開２００４−３８７１６「障害発生時の自動復旧機能を備えたファームウェア更新方法」では、正常に更新が行うことができたかどうかのフラグと復旧プログラムを備えた方法が提案されている。
【特許文献１】特開平１０−３０７７２６号公報
【特許文献２】特開２００４−３８７１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、これらの方法では、通常使用するＲＯＭ以外のファームウェア記憶装置や復旧プログラムを用意することによる製品のコストアップや製品試験工数増大への影響が避けられない。
【課題を解決するための手段】
【０００５】
本発明は、前述のファームウェアが不完全に書き換えられて破損した場合に復旧させるのではなく、ＲＯＭのファイルシステムを経由してファームウェアを更新することにより、障害によるファームウェアが破損することを完全に回避するものである。
【発明の効果】
【０００６】
本発明を用いることで、従来のシステムに対しても、特別なハードウェアを追加することなく、低コストで安全確実なファームウェア更新方法を提供することができる。
【実施例１】
【０００７】
請求項１に記載の本発明は、ファームウェアをＲＯＭのファイルシステムを経由してファイル単位で更新することが第一の特徴である。従来、ファームウェアの更新はファームウェアの全体あるいは複数に分けられたモジュール群をブロック単位で書き換えるものであったが、本発明ではファイルシステムを経由して、ファイル単位での更新を行う。
【０００８】
さらに、ＲＯＭの空き領域に更新すべきファイルを別ファイルとして書き込み、正常に書き込みが終了した後、更新すべきファイルが本来の名称になるようファイルシステムを操作することで、ファームウェアの更新が不完全になることを回避することが第二の特徴である。
【０００９】
書き換えが必要なファイルをネットワークや他の機器より送られてきた新しいデータで直接置き換える場合、この最中に障害が発生するとファームウェアが破損してしまう。これは従来のブロック単位での更新の場合でもファイルシステムを経由した更新の場合でも同様である。
【００１０】
そこで、以下の方法を用いて、ファームウェアが破損することを回避する。更新すべきファイル名をabcd.efgとする。まず、ＲＯＭの空き領域に更新用の新しいファイルを本来とは違った名前で格納する。空き領域はファイルシステム自体が管理しているため、ファームウェア更新プログラムに対して特別な仕掛けは必要なく、変更した名前でファイルを保存するだけの操作で十分である。仮にこの名前を~abcd.efgとする。この保存時に万が一、障害が発生したとしても、システムの実行には関係のない名前のファイルが存在しているだけであるため特に問題は生じない。正常に~abcd.efgが作成されたことを確認した後、ファイルシステムを操作して、更新された新しいファイルデータ~abcd.efgが示す領域をファイル名abcd.efgにマッピングし直す。この操作はファイルシステムにおいてアトミック操作（不可分操作）のため、ファイル更新時において不正なファイルが作成される可能性はない。
【００１１】
ＵＮＩＸ（登録商標）のファイルシステムを利用した場合の例をあげて説明する。ＵＮＩＸ（登録商標）以外のファイルシステムでも各部の名称以外は基本的に同様と考えてもよい。図１は、ＵＮＩＸ（登録商標）のファイルシステムの概略を表したものである。ファイルシステムはディレクトリ１０内の抽象的なファイル名Ａを抽象的なファイルセグメントであるインデックスノード（以下ｉノードと称する）にマッピングする。抽象的なファイルセグメントであるｉノード１１は、ＲＯＭ１６内の当該セグメントを記憶する物理的なデータブロック１３〜１４、あるいは、さらにｉノード１２を経由して（複数のｉノードを経由する場合もあり得る）、物理的なデータブロック１５へとマッピングされる。このようにしてＵＮＩＸ（登録商標）のファイルシステムは抽象的なファイル名と物理的なデータブロックをｉノード経由でマッピングしている。
【００１２】
図２はファームウェア更新前のファイルシステムの状態である。更新対象のファイル名をabcd.efgとする。このファイルはｉノード２１を経由して物理データブロック２２とマッピングされている。この図では、abcd.efg以外のファイルのｉノード記述は省略している。
【００１３】
図３は更新ファイルを~abcd.efgというファイル名で書き込んだ状態を示している。ファイルシステムにより、ＲＯＭの空き領域にデータブロックが確保され、ｉノード３４を経由して更新ファイルが~abcd.efgというファイル名で物理データブロック３５へマッピングされている。
【００１４】
図４は、更新すべきabcd.efgに対応するｉノードポインタ４６をもともとの値ｎから更新ファイル~abcd.efgに対応するｚにマッピングし直した後の状態を表している。この操作はＵＮＩＸ（登録商標）のシステムコールを用いて行われるアトミック操作であるため、障害により不正な状態に陥ることはあり得ない。元のｉノード４１はファイル名とのマッピング状態から解放され、ｉノード４１にマッピングされていた物理データブロック４２は以後空き領域として扱われる。
【００１５】
以上は一つのファイルに対する更新の説明であるが、複数のファイルの更新が必要な場合も、上記の手順を繰り返すことにより不正な状態に陥ることなくファームウェア更新が可能である。
【実施例２】
【００１６】
請求項２に記載の本発明は、必ず複数のファイルの組み合わせで行う必要がある場合かつ更新すべきファイルの総ファイルサイズがＲＯＭの空き容量を超えている場合のファームウェア更新方法を提供する。アプリケーションソフトとそれが利用するドライバソフトなどはバージョンに不整合が生じることのないよう同時に更新する必要がある。ドライバソフトだけ更新が成功した時点で障害が発生するとアプリケーションソフトとドライバソフト間に不整合が生じ、システムが起動しない場合がありえる。
【００１７】
これらの問題を以下の方法を用いて回避する。まず更新用モジュールを作成する。またモジュールが有する機能は、基本的に図５に示す単純なものであり、その他、必要に応じて更新状態を表示するなどの機能を有する。また、同時に更新するファイルとの整合性を持ち、更新対象でシステムの実行時には必ず起動されるモジュール名とする。
【００１８】
更新用モジュールを更新対象のファイルと請求項１の方法を用いて置換する。更新用モジュールは、更新が必要なファイルをネットワークや他の機器より請求項１の更新方法を用いて更新を行う。この作業を繰り返し、すべてのファイルが正常でかつ更新済みであることを確認できれば、自分自身を本来の更新ファイルに更新する処理を行い、更新された本来のシステムが起動する状態になる。
【００１９】
更新の途中で障害が発生したとしても、更新用モジュールがＲＯＭ上に残っているため、次回起動時に更新の継続が可能であり、最終的には必ず全てのファイルが更新された状態になることが保証される。
【図面の簡単な説明】
【００２０】
【図１】ＵＮＩＸ（登録商標）ファイルシステム概略
【図２】ファイル更新前のｉノード状態
【図３】更新ファイル保存後のｉノード状態
【図４】ファイル更新後のｉノード状態
【図５】更新用モジュール機能フローチャート
【符号の説明】
【００２１】
１０  ディレクトリ
１１  ｉノード
１２  ｉノード
１３  物理データブロック
１４  物理データブロック
１５  物理データブロック
１６  ＲＯＭ
２０  ディレクトリ
２１  ｉノード
２２  物理データブロック
２３  ＲＯＭ
３０  ディレクトリ
３１  ｉノード
３２  物理データブロック
３３  ＲＯＭ
３４  ｉノード
３５  物理データブロック
４０  ディレクトリ
４１  ｉノード
４２  物理データブロック
４３  ＲＯＭ
４４  ｉノード
４５  物理データブロック
４６  変更されたｉノードポインタ
【図１】
2006202086.tif 000003
【図２】
2006202086.tif 000004
【図３】
2006202086.tif 000005
【図４】
2006202086.tif 000006
【図５】
2006202086.tif 000007