JP5113699B2 - ファームウェア更新システム、及び更新イメージ生成・配布サーバ装置 - Google Patents

Description

本発明は、ファームウェア更新システム、及び更新イメージ生成・配布サーバ装置に関する。

組込み機器をリリース後、ソフトウェアに不具合が見つかった場合、従来のファームウェアを、不具合を解決したファームウェアに書き換えることで、問題を解決するという方法が一般に行われている。このようなファームウェア更新に関する文献として、例えば次の特許文献１や特許文献２がある。なお、ここでファームウェアとは、組み込み機器の不揮発性記憶領域にあらかじめ記憶されているデータすべてを指すものとする。

特許文献１には、ファームウェアを全て交換するファームウェア更新方式が記載されている。また、非特許文献１には、Ｌｉｎｕｘでよく使われているソフトウェア更新プログラムであって、パッケージ単位でソフトウェアを管理し、更新のあったソフトウェアパッケージを配布することが開示されている。

特開平１１−１１０２１８号公報 Yum: Yellow dog Updater, Modified：http://linux.duke.edu/projects/yum/

しかしながら、特許文献１のような方式では、ファームウェアを全て交換するため、ファームウェア交換には時間がかかってしまう。また、非特許文献１のような方式では、ファームウェア全ての交換は発生しないものの、ファームウェアの開発者がパッケージ単位でソフトウェアを管理しなければならないという手間が生じてしまう。

本発明はこのような状況に鑑みてなされたものであり、ファームウェアを交換する時間が短く、かつファームウェア開発者の負担が少ない、ファームウェア交換を実現するものである。

上記課題を解決するために、新しいバージョンのファームウェアのイメージ（新ファームイメージ）を受け取り、古いバージョンのファームウェアのイメージ（旧ファームイメージ）と比較し、更新があったファイルだけを取り出し、旧ファームイメージから新ファームイメージに更新するための手順および更新データから構成される更新イメージを作成する機能を備えたサーバを設置する。上記機能で必要になる更新イメージ数を減らすために、頻繁にアクセスされる更新イメージのみをキャッシュする手段を備える。組込み機器には、更新イメージ中の更新手順に従って機器上の旧ファームイメージを新ファームイメージにバージョンアップする機能を設ける。また、旧ファームイメージから新ファームイメージへの更新後にサービスの再起動が必要になることがある。どんなファイルに更新があった場合にどんなサービスの再起動が必要かというＤＢ（再起動ＤＢ）を用意し、更新イメージ中の更新手順に、サービスの再起動指示を挿入可能にする。さらに、再起動ＤＢの作成を自動化する手段も備え、ファームウェア開発者の負担を少なくする。

即ち、本発明によるファームウェア更新システムは、機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムであって、ファームウェアで動作する機器と、ファームウェアを更新するための更新イメージを生成し、機器に送信する更新イメージ生成・配布サーバと、を備える。ここで、更新イメージ生成・配布サーバは、機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、更新イメージを前記機器に送信するデータ通信部と、を有し、機器は、更新イメージに基づいて、古いバージョンのファームウェアイメージを更新する。

更新イメージ生成・配布サーバは、さらに、最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部を備え、更新イメージ生成部は、第１のファームウェアイメージから第２のファームウェアイメージに更新するために必要なデータを更新イメージ格納部から取得し、更新イメージを生成する。第１のファームウェアイメージから第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが更新イメージ格納部に存在する場合、更新イメージ生成部は、当該隣接バージョン更新イメージを更新イメージとする。一方、第１のファームウェアイメージから第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが更新イメージ格納部に無い場合、更新イメージ生成部は、第１のファームウェアイメージを第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、更新イメージを生成する。

更新イメージ生成・配布サーバは、さらに、使用頻度の多い前記更新イメージを所定数個格納する更新イメージキャッシュ部を備える。このとき、更新イメージ生成部は、最新の更新イメージを生成した場合、更新イメージキャッシュ部の最下位の更新イメージと最新の更新イメージとを入れ替える。

更新イメージ生成・配布サーバは、さらに、どんなファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、更新イメージ生成部は、再起動指示ＤＢを参照して、送信すべき更新イメージにサービスの再起動指示を挿入する。さらに、再起動指示ＤＢは、ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、更新イメージ生成部は、さらに、送信すべき更新イメージにライブラリに対応するサービスの再起動指示をする。

さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。

本発明によれば、ファームウェアを交換する時間を短くし、かつファームウェア開発者の負担が少ない、ファームウェア交換を実現することができるようになる。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

以下、本発明の一実施形態を図面を参照しながら説明する。
＜ファームウェア更新システムの構成＞
図１は、本発明の実施形態によるファームウェア更新システムの概略構成を示す図である。図１に示されるように、開発者１１０は、機器１６０のソフトウェアを開発し、開発したソフトウェアおよび構成ファイルをファームウェアイメージ１２０にまとめる。ファームウェアイメージ１２０は、開発者１１０が開発したソフトウェアと構成ファイルを一つのファイルとしてアーカイブしたものである（詳細な構成については図４参照）。そして、開発者１１０は、機器１６０のソフトウェア更新が必要になった時に、ファームウェアイメージ１２０を、自身のコンピュータ（図示せず）を用いて更新作成・配布サーバ１３０に送信する。

更新作成・配布サーバ１３０は、ネットワーク機能を備えたコンピュータとしてのハードウェアを備える。つまり、更新作成・配布サーバ１３０は、様々な制御処理を実行するＣＰＵ１３１と、ＲＡＭ１３２と、ネットワークインタフェース１３３と、各種データ・パラメータやプログラム等を格納するＨＤＤ１３４と、を備えている。

ＨＤＤ１３４の中には、旧版ファームウェアイメージ１３５が格納されている。そして、更新作成・配布サーバ１３０（ＣＰＵ１３１）は、開発者が開発した新しいファームウェアイメージ１２０と旧版ファームウェアイメージ１３５を比較し、更新された部分だけを取り出し、更新イメージ１４０を作成し、ネットワーク１５０を通じて機器１６０に送信する。更新イメージ１４０の詳細な構成は図２に示す通りであり、後述する。

機器１６０は、ネットワーク機能を備えたコンピュータとしてのハードウェアを備える。この機器１６０の例としては、ネット家電（ＴＶ）やブロードバンドルータ等が挙げられる。機器１６０が最低限備える構成は、ＣＰＵ１６１、ＲＡＭ１６２、ネットワークインタフェース１６３、フラッシュメモリ１６４である。ファームウェア更新の際には、機器１６０が、ソフトウェア更新リクエストを更新作成・配布サーバ１３０に送信し、更新イメージ１６０を受信し、フラッシュメモリ１６４に格納されたファームウェアを更新することになる。このように、プル型の構成にしてもよいし、更新作成・配布サーバ１３０から各機器１６０に対して更新イメージを適時送信するプッシュ型の構成にしてもよい。プッシュ型構成の場合には、予め機器１６０のアドレスが登録されている必要がある。

＜更新作成・配布サーバのＨＤＤ１３４の内部構成＞
図２は、本実施形態における更新作成・配布サーバ１３０のＨＤＤ１３４内部に格納されているデータやプログラムの構成を示す図である。ＨＤＤ１３４は、ファームウェアイメージ集１３５と、更新イメージ集２２０と、再起動指示ＤＢ２３０と、更新イメージキャッシュデータ２４０と、サービス名・ファイル対応データ２５０と、更新作成機能プログラム２６０と、再起動指示作成機能プログラム２７０と、更新配布機能プログラム２８０と、を含んでいる。

ファームウェアイメージ集１３５は旧版のファームウェアイメージであり、開発者１１０が過去に送信したファームウェアイメージのうち、最も古いバージョンのものと、最新のバージョンのものの２種類を保存されている。２１１の例では、バージョン１と最新のバージョン５０のファームウェアイメージが保存されていることが示されている。

更新イメージ集２２０には、最古のファームウェアイメージから、最新のファームウェアイメージに至るまでの更新が一バージョンごとに保存されている。つまり、最新のバージョンが５０ならば、「ファームウェアイメージバージョン１から、ファームウェアイメージバージョン２への更新を表す更新イメージ（更新イメージ１⇒２と表記する）」、「更新イメージ２⇒３」、「更新イメージ３⇒４」、「更新イメージ４⇒５」…＜中略＞…「更新イメージ４９⇒５０」が保存されている。例えば、更新イメージ２⇒５のように１つ飛び以外のケースは、そのイメージが頻繁に使用されるものである等の例外的な場合を除き、基本的に格納されていない。なお、更新イメージの構成は図５に示されるようなものである。

再起動指示ＤＢ２３０は、ＣＰＵ１３１が再起動指示作成機能（プログラム）２７０を実行する際に使うデータを保存している。詳細なデータ構成は図６に示されている。

更新イメージキャッシュデータ２４０は、更新イメージ２２１に対するアクセス頻度および更新イメージのデータ（例えば、アクセス頻度が多いトップ１０のデータ）が記録されている。詳細な構成は図７に示されているようなものである。

サービス名ファイル名対応データ２５０は、サービス名とそれに対応する実行ファイルの組を示す情報である。詳細な構成は図８に示されているようなものである。

更新作成機能プログラム２６０は、更新イメージ１４０を作成するためのプログラムである。機能の詳細については図９を用いて後述する。また、再起動指示作成機能プログラム２７０は、再起動指示ＤＢ２３０を作成するプログラムである。機能の詳細については図１０を用いて後述する。更新配布機能プログラム２８０は、機器１６０からのリクエストに応じて、更新イメージ集２２０に格納された更新イメージを配布するプログラムである。機能の詳細については図１１を用いて後述する。これらのプログラムは、ＣＰＵ１３１によって実行され、各機能が実現される。

＜機器のフラッシュメモリ１６４の内部構成＞
図３は本実施形態における機器１６０のフラッシュメモリ１６４に格納されているデータやプログラム等の構成を示す図である。フラッシュメモリ１６４は、機器１６０で使用中のファームウェアイメージ３１０と、バージョン番号３２０と、オペレーティングシステム３３０と、更新適用プログラム３４０と、を格納している。

ファームウェアイメージ３１０は、機器で動作するソフトウェアおよび構成ファイル一式が格納されたイメージデータである。バージョン番号３２０は、ファームウェアイメージ３１０のバージョンを表している。

オペレーティングシステム３３０は、ファームウェアイメージ３１０に格納されたソフトウェアを実行するための機能を備えている。更新適用プログラム３４０は、更新作成・配布サーバ１３０から、更新イメージ１４０を受信し、更新イメージ１４０に記述された更新をファームウェアイメージ３１０に適用する機能を備え、ＣＰＵ１６１によって実行されるプログラムである。当該機能の処理の詳細は図１２を用いて後述する。

＜ファームウェアイメージの構成＞
図４は、本実施形態によるファームウェアイメージ１２０の構成を示す図である。図４に示されるように、ファームウェアイメージ１２０は、バージョン番号４１０と、ファームウェアのデータ本体４２０で構成される。

バージョン番号４１０は、ファームウェアイメージ１２０のバージョンを表す。バージョン番号は、開発者１１０に管理されている、ファームウェアイメージ１２０のバージョン番号である。ファームウェアのデータ本体４２０は、例えば、ＵＮＩＸ系オペレーティングシステムで広く使われているｔａｒなどを使って、ファイルシステムの構造をアーカイブすることにより生成される。

＜更新イメージの構成＞
図５は、本実施形態における更新イメージ１４０の構成を示す図である。更新イメージ１４０において、５１０は更新前のイメージのバージョン番号を表す。５２０は更新後のイメージのバージョン番号を表す。例えば、５１０が「４９」、５２０が「５０」の場合は、ファームウェアイメージのバージョン４９から、バージョン５０への更新であることを表す。

５３０〜５６０には、更新手順が記されている。５３０は、更新操作を表す。５４０は、操作対象ファイルのフルパスを表す。５５０は、該当する更新をした場合の再起動指示が記されている。５６０には、フルパス５４０に対応するファイルのデータが記録されている。例えば、行５７１は、「ファイル名／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄに対して、５６０に格納されたデータで上書きを行い、ｈｔｔｐサービスの再起動を行う」という更新手順を表している。

つまり、図５は、バージョン番号４９のファームウェアイメージからバージョン番号５０のファームウェアに更新するにはどのような処理手順がなされたかを示しているのである。このような更新イメージが、隣同士のバージョンのファームウェアの全ての組み合せについて更新イメージ集２２０として更新作成・配布サーバ１３０のＨＤＤ１３４に格納されている。

＜再起動指示ＤＢの構成＞
図６は、本実施形態における再起動指示ＤＢ２３０の構成を示す図である。図６に示されるように、再起動指示ＤＢ２３０には、ファイル名６１０と再起動指示６２０の対応が格納されている。つまり、ファイル名６１０に示されるファイルに更新が発生した場合には、再起動指示６２０で示されるサービスの再起動が必要となるのである。

再起動指示ＤＢ２３０のデータは、後述のサービス名ファイル名対応データ２５０（図８）を基にして生成されるものである。

＜更新イメージキャッシュの構成＞
図７は、本実施形態における更新イメージキャッシュデータ２４０の構成を示す図である。更新イメージキャッシュデータは、更新種別７１０と、アクセス数７２０と、更新イメージデータ７３０と、によって構成される。

更新種別７１０は、リクエストされた更新のバージョンを示している。例えば、「４９⇒５０」は、バージョン４９から５０への更新リクエストを表す。アクセス数７２０は、更新種別７１０のリクエストされた頻度を示す。７３０は、更新イメージへのデータである。７３０のフォーマットは図５に示した通りである。更新イメージキャッシュデータは、７２０のアクセス数順に上位のデータ７３０のみが格納される。例えば、上位１０種類のデータ７３０のみが格納されるようにする。

＜サービス名ファイル名対応データ＞
図８は、本実施形態におけるサービス名ファイル名対応データ２５０の構成を示す図である。この対応データは、例えば機器メーカが予め用意する。

サービス名ファイル名対応データは、サービス名８１０とそれを構成する実行ファイル名８２０の組で構成されている。例えば、行８３１は、ｈｔｔｐサービスを構成する実行ファイル名は／ｓｂｉｎ／ｈｔｔｐｄであることを表している。機器のシステム構成によっては、これを自動的に用意することもできる。

多くのＬｉｎｕｘシステムではサービス名ごとに起動スクリプトが用意されている。例えば、／ｅｔｃ／ｉｎｉｔ．ｄ／ｈｔｔｐｄはｈｔｔｐｄサービスの起動スクリプトである。この起動スクリプトを解析し、中に含まれる実行ファイルをサービス名ファイル名対応２５０に登録する。例えば、／ｅｔｃ／ｉｎｉｔ．ｄ／ｈｔｔｐｄを解析し、／ｓｂｉｎ／ｈｔｔｐｄが含まれると分かったら、８１０にｈｔｔｐｄサービス、８２０に／ｓｂｉｎ／ｈｔｔｐｄが登録される。

＜更新作成機能＞
図９は、更新作成機能２６０における処理を説明するためのフローチャートである。図９によって作成されるデータは、図５に示される更新イメージである。なお、ここでは、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、更新作成機能プログラム２６０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。

開発者１１０から取得したファームウェアイメージ１２０を、ネットワークインタフェース１３３を介して受信する（ステップＳ９１０）と、ＣＰＵ１３１は、取得したばかりのファームウェアイメージ（新バージョン）と、１バージョン古いファームウェアイメージとを比較し、操作の種類、フルパス（ファイルパス）、ファイルのデータを抽出する（ステップＳ９２０）。より具体的には、ファームウェアイメージ集２１０には、ステップ９１０で受信したファームウェアイメージ（新ファームウェアイメージと呼ぶ）より１バージョン古いファームウェアイメージ（旧ファームウェアイメージと呼ぶ）が保存されている。例えば、ステップＳ９１０で、バージョン５０を受信したらならば、旧ファームウェアイメージのバージョンは４９である。そして、ＣＰＵ１３１は、更新イメージ（図５）の旧バージョン番号５１０、新バージョン番号５２０を埋める。例えば、ステップ９１０で受信したファームウェアイメージのバージョンが５０ならば、５１０は「４９」、５２０は「５０」となる。次に、ＣＰＵ１３１は、新ファームウェアイメージと旧ファームウェアイメージのファイルシステム構造を比較し、更新されているファイル、削除されているファイル、追加されているファイルを取り出す。そして、更新イメージの５３０、５４０、５６０を埋める（図５）。例えば、新ファームウェアイメージにて、／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄが更新されていた場合は、操作５３０には「更新」、フルパス５４０には「／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄ」、ファイルのデータ５６０には、新ファームウェアイメージに含まれる／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄのデータが格納される。

続いて、ＣＰＵ１３１は、ファームウェアイメージ集１３５の最新のバージョンのファームウェアイメージを削除し、代わりに、ステップＳ９１０で受信したファームウェアイメージ１２０を最新バージョンとして保存する（ステップＳ９３０）。

また、ＣＰＵ１３１は、再起動ＤＢ２３０を参照し、フルパス５４０に対応する再起動指示６２０を見出し、更新イメージの５５０の列を埋める（ステップＳ９４０）。例えば、フルパス５４０が「／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄ」となっていた場合は、ファイル名６１０が一致する行は６３１である。行６３１の再起動指示は「ｈｔｔｐｄサービス」となっているため、再起動指示５５０は、「ｈｔｔｐｄサービス」と記録する。なお、対応する再起動指示６２０が再起動指示ＤＢ２３０から見つからない場合は、５５０には「無し」が格納される。

さらに、ＣＰＵ１３１は、作成された更新イメージを、更新イメージ集２２０に保存する（ステップＳ９５０）。

＜再起動指示作成機能＞
図１０は、再起動指示作成機能２７０における処理を説明するためのフローチャートである。図１０によって作成されるデータは、図６に示されるデータである。ここでも、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、再起動指示作成機能プログラム２７０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。なお、サービス名ファイル名対応２５０の各行（図８参照）についてステップＳ１０２０からＳ１０４０の処理が実行される。

まず、ＣＰＵ１３１は、図８のサービス名ファイル名対応データ２５０を参照し、該当する行（８３１、８３２・・・等）のファイル名８２０及びサービス名８１０を再起動指示ＤＢ２３０のファイル名６１０及び再起動指示６２０にそれぞれ登録する（ステップＳ１０２０）。

次に、ＣＰＵ１３１は、ファイル名８２０が利用している共有ライブラリを解析する（ステップＳ１０３０）。ファイル名の中身（バイナリ）を見ると、どんなライブラリを使用しているかの依存関係が判明する。つまり、このステップでは、関連するライブラリをサーチしている。例えば、ファイル名が／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄの場合、ｈｔｔｐｄのバイナリを解析し、利用している共有ライブラリの名前を取り出す。例えば、ｈｔｔｐｄのバイナリから、共有ライブラリの名前がｌｉｂｈｔｔｐｄ．ｓｏが取り出されたとする。共有ライブラリの検索パスから、ｌｉｂｈｔｔｐｄ．ｓｏのフルパスを取り出す。共有ライブラリの検索パスが／ｌｉｂの場合は、フルパスは／ｌｉｂ／ｌｉｂｈｔｔｐｄ．ｓｏとなる。

続いて、ＣＰＵ１３１は、ステップＳ１０３０で得たライブラリのフルパスを再起動指示ＤＢ２３０のファイル名６１０に登録し、再起動指示６２０については、ステップＳ１０２０で登録したサービス名を登録する（ステップＳ１０４０）。このステップでは、ステップＳ１０３０で使用していると判明したライブラリもファイル名に対応してサービスに関係しているので、再起動の対象とするためにライブラリのファイル名及びサービス名を登録する。ステップＳ１０３０の例で言うと、ファイル名６１０には、「／ｌｉｂ／ｌｉｂｈｔｔｐｄ．ｓｏ」が登録され、再起動指示６２０には「ｈｔｔｐｄサービス」が登録される。

＜更新配布機能＞
図１１は、本実施形態における更新配布機能２８０の処理を説明するためのフローチャートである。ここでも、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、更新配布機能プログラム２８０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。なお、ファームウェアイメージ集１３５に格納されている最新のファームウェアイメージのバージョンは「５０」として、以下のステップを説明する。

まず、ＣＰＵ１３１は、ネットワークインタフェース１３３を介して、機器１６０よりアップデートリクエストを受け取る（ステップＳ１１１０）。アップデートリクエストの中には、ファームウェアイメージのバージョン番号３２０が含まれている。なお、ここではプル型を例に説明をするが、プッシュ型の更新配布であってもよい。

次に、ＣＰＵ１３１は、更新イメージキャッシュの更新種別７１０を参照し、リクエストされたアップデートが更新イメージキャッシュに含まれるか判別する（ステップＳ１１２０）。図７の例だと、ステップＳ１１１０で受け取ったバージョン番号が「４８」だったならば、機器のファームウェアイメージのバージョンは４８であり、最新のバージョンである５０へのアップデートは７４２にあるように、更新イメージキャッシュに含まれることになる。

ステップＳ１１２０で、リクエストされたアップデートが更新イメージキャッシュに含まれると判断した場合は、ＣＰＵ１３１は、更新イメージキャッシュ中の対応する更新イメージ７３０を機器１６０に配信する（ステップＳ１１３０）。ステップＳ１１１０で受け取ったバージョン番号が「４８」だったならば、行７４２の更新イメージ７３０を配信する。同時に更新イメージキャッシュの対応するアクセス数７２０をインクリメントする。

一方、ステップＳ１１２０で、リクエストされたバージョンの更新イメージが、更新イメージキャッシュに含まれない場合には、処理はステップＳ１１４０に移行する。例えば、図７の例で、ステップ１１１０で受け取ったバージョン番号が「４７」だったならば、更新イメージキャッシュに含まれない。そして、ＣＰＵ１３１は、更新イメージ集２２０に含まれる更新イメージのマージを行い、必要な更新イメージを生成する（ステップＳ１１４０）。

このマージ処理の手順を、ステップ１１１０で受け取ったバージョン番号が「４７」だったとして説明する。更新イメージ集２２０に含まれる「更新イメージ４７⇒４８」、「更新イメージ４８⇒４９」、「更新イメージ４９⇒５０」をマージし、「更新イメージ４７⇒５０」を作成する。具体的には、「更新イメージ４７⇒４８」の５３０、５４０、５５０、５６０の組からなる行に対して、「更新イメージ４８⇒４９」の５３０、５４０、５５０、５６０の組からなる行を追加、同様に「更新イメージ４９⇒５０」の５３０、５４０，５５０、５６０の組からなる行を追加する。そして、新バージョン番号５２０を「５０」に書き換える。

続いて、ＣＰＵ１３１は、更新イメージキャッシュデータを更新する（ステップＳ１１５０）。より詳細には、更新イメージキャッシュデータのうち、アクセス数７２０が最も少ない行を削除し、代わりにステップＳ１１４０で作成した更新イメージを追加する。例えば、更新種別７１０には「４７⇒５０」、アクセス数７２０には「１」、更新イメージデータ７３０には、作成した更新イメージが格納される。

そして、ＣＰＵ１３１は、ステップＳ１１４０で作成した更新イメージを、ネットワークインタフェース１３３を介して機器１６０に配信する。

＜更新適用処理＞
図１２は、機器１６０における更新適用プログラム３４０の処理を説明するためのフローチャートである。ここでは、特に断らない限り、各ステップの動作主体はＣＰＵ１６１である。つまり、ＣＰＵ１６１が、更新適用プログラム３４０をＲＡＭ１６２に展開して当該プログラム中の各ステップを実行していく。

まず、ＣＰＵ１６１は、アップデートリクエストを更新作成・配布サーバ１３０に送信する（ステップＳ１２１０）。アップデートリクエストには、バージョン番号３２０が含まれている。

そして、ＣＰＵ１６１は、更新イメージを更新作成・配布サーバ１３０より受信する（ステップ１２２０）。ここで受信する更新イメージは、更新配布機能２８０を実行することによって作成されたものである。

次に、ＣＰＵ１６１は、受信した更新イメージを使い、ファームウェアイメージ３１０を更新する（ステップＳ１２３０）。例えば、図５のような更新イメージを受信した場合、行５７１〜５７３の操作５３０に従い、ファームウェアイメージを更新する。つまり、／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄを５６０のデータで上書きし、／ｌｉｂ／ｌｉｂｆｏｏ．ｓｏ．１を削除し、／ｕｓｒ／ｓｂｉｎ／ｎａｍｅｄを５６０の内容で作成する。また、バージョン番号３２０が、５２０に書かれたバージョン番号に更新される。

続いて、ＣＰＵ１６１は、再起動指示５５０に従い、再起動処理を行う（ステップＳ１２４０）。図５の例では、ｈｔｔｐｄサービスの再起動を行う。

＜まとめ＞
以上により、ファームウェア更新を実現できる。システム全体の処理をまとめると、まず開発者１１０は、最新のファームウェアイメージ１２０を更新作成・配布サーバ１３０に送信する。機器１６０は、更新適用プログラム３４０を使い、ファームウェア更新リクエストを更新作成・配布サーバ１３０に対して送信する。更新作成・配布サーバ１３０は、更新作成機能２６０を使い、更新イメージ１４０を作成し、更新イメージ１４０を機器１６０に送信する。機器１６０は、更新イメージ１４０を受け取り、更新適用プログラム３４０を使って、ファームウェアを最新のものに更新する。

以上説明した本発明の実施形態を適用することにより、ファームウェアを更新する際、更新イメージ１４０に含まれるファイルのみが更新されるため、ファームウェア全てを交換するよりも、ファームウェアを更新するための時間は短くて済む。さらに、ファームウェア開発者１１０が、ファームウェアイメージ１２０を更新作成・配布サーバ１３０に送付するだけで、更新イメージ１４０が自動的に作成されるため、ファームウェア開発者１１０の負担は少ない。

副次的な効果として、更新イメージを格納するための領域も少なくなっている。例えば、ファームウェアの最新版のバージョンが５０ならば、更新１⇒５０、更新２⇒５０、更新３⇒５０、更新４⇒５０……更新４９⇒５０の４９種類の更新イメージが必要になるだけで、全ての組合せを格納しておく必要はない。更新１⇒５０は、４９バージョン分の差分、更新２⇒５０は４８バージョン分の差分であるため、サイズが大きい。これらを保管する代わりに、２２１のように、１バージョンずつの差分を４９個保管するようにしているため、更新イメージを格納する領域は少なくて済むようになる。

なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

本発明の実施形態によるファームウェア更新システムの全体概略構成を示す図である。 更新作成・配布サーバのＨＤＤの内部データ構成を示す図である。 機器のメモリの内部データ構成を示す図である。 ファームウェアイメージの構成例を示す図である。 更新イメージの構成例を示す図である。 再起動指示ＤＢの構成例を示す図である。 更新イメージキャッシュの構成例を示す図である。 サービスファイル名対応の構成例を示す図である。 更新作成機能の処理動作を説明するためのフローチャートである。 再起動指示作成機能の処理動作を説明するためのフローチャートである。 更新配布機能の処理動作を説明するためのフローチャートである。 更新適用プログラムの処理動作を説明するためのフローチャートである。

符号の説明

１１０・・・開発者
１２０・・・ファームウェアイメージ
１３０・・・更新作成・配布サーバ
１４０・・・更新イメージ
１５０・・・ネットワーク
１６０・・・機器
１３１・・・ＣＰＵ
１３２・・・ＲＡＭ
１３３・・・ネットワークインタフェース
１３４・・・ＨＤＤ
１３５・・・旧版ファームウェアイメージ
１６１・・・ＣＰＵ
１６２・・・ＲＡＭ
１６３・・・ネットワークインタフェース
１６４・・・フラッシュメモリ

Claims (8)

1. 機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムであって、
   前記ファームウェアで動作する機器と、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバと、を備え、
   前記更新イメージ生成・配布サーバは、前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、前記更新イメージを前記機器に送信するデータ通信部と、最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部と、隣接したバージョン及び離間したバージョンのファームウェアイメージ間の更新イメージである離間バージョン更新イメージのうちで、使用頻度数が多い所定数の更新イメージを格納する高使用頻度更新イメージ格納部と、を有し、
   前記更新イメージ格納部が、前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージを保持する場合、前記更新イメージ生成部は、当該隣接バージョン更新イメージを前記更新イメージとし、
   前記更新イメージ格納部が、前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージを保持せず、かつ、前記高使用頻度更新イメージ格納部が、前記第１のファームイメージから前記第２のファームイメージの更新に直接対応する離間バージョン更新イメージを保持しない場合、前記更新イメージ生成部は、前記第１のファームウェアイメージを前記第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、前記更新イメージを生成し、
   前記高使用頻度更新イメージ格納部が、前記第１のファームイメージから前記第２のファームイメージの更新に直接対応する離間バージョン更新イメージを保持する場合、前記更新イメージ生成部は、前記離間バージョン更新イメージを前記更新イメージとし、
   前記機器は、前記更新イメージに基づいて、前記古いバージョンのファームウェアイメージを更新する、
   ことを特徴とするファームウェア更新システム。
2. 前記ファームウェアは、複数の構成ファイルを含み、
   前記更新イメージ生成・配布サーバは、さらに、どんな構成ファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、
   前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入することを特徴とする請求項１に記載のファームウェア更新システム。
3. 前記再起動指示ＤＢは、前記ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、
   前記更新イメージ生成部は、さらに、前記送信すべき更新イメージに前記ライブラリに対応するサービスの再起動指示をすることを特徴とする請求項２に記載のファームウェア更新システム。
4. 機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムにおいて動作し、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバ装置であって、
   前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、
   最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部と、
   隣接したバージョン及び離間したバージョンのファームウェアイメージ間の更新イメージである離間バージョン更新イメージのうちで、アクセス数が多い所定数の更新イメージを格納する高使用頻度更新イメージ格納部と、
   前記更新イメージを、前記ファームウェアを使用する機器に送信するデータ通信部と、
   を備え、
   前記更新イメージ格納部が、前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージを保持する場合、前記更新イメージ生成部は、当該隣接バージョン更新イメージを前記更新イメージとし、
   前記更新イメージ格納部が、前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージを保持せず、かつ、前記高使用頻度更新イメージ格納部が、前記第１のファームイメージから前記第２のファームイメージの更新に直接対応する離間バージョン更新イメージを保持しない場合、前記更新イメージ生成部は、前記第１のファームウェアイメージを前記第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、前記更新イメージを生成し、
   前記高使用頻度更新イメージ格納部が、前記第１のファームイメージから前記第２のファームイメージの更新に直接対応する離間バージョン更新イメージを保持する場合、前記更新イメージ生成部は、前記離間バージョン更新イメージを前記更新イメージとすることを特徴とする更新イメージ生成・配布サーバ装置。
5. 前記ファームウェアは、複数の構成ファイルを含み、
   さらに、どんな構成ファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、
   前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入することを特徴とする請求項４に記載の更新イメージ生成・配布サーバ装置。
6. 前記再起動指示ＤＢは、前記ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、
   前記更新イメージ生成部は、さらに、前記送信すべき更新イメージに前記ライブラリに対応するサービスの再起動指示をすることを特徴とする請求項５に記載の更新イメージ生成・配布サーバ装置。
7. 機器のソフトウェアと複数の構成ファイルを含むファームウェアのイメージを更新するファームウェア更新システムであって、
   前記ファームウェアで動作する機器と、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバと、を備え、
   前記更新イメージ生成・配布サーバは、前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、どんな構成ファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢと、前記更新イメージを前記機器に送信するデータ通信部と、を有し、
   前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入し、
   前記機器は、前記更新イメージに基づいて、前記古いバージョンのファームウェアイメージを更新する、
   ことを特徴とするファームウェア更新システム。
8. 機器のソフトウェアと複数の構成ファイルを含むファームウェアのイメージを更新するファームウェア更新システムにおいて動作し、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバ装置であって、
   前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、
   どんな構成ファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢと、
   前記更新イメージを、前記ファームウェアを使用する機器に送信するデータ通信部と、を備え、
   前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入することを特徴とする更新イメージ生成・配布サーバ装置。

Images