JP2010198155A - プログラム更新装置、プログラム更新方法、及び情報処理装置 - Google Patents

Abstract

【課題】プログラムの更新処理に失敗した場合でも、正常時の動作に復帰することができるプログラム更新方法を提供する。
【解決手段】プログラム更新装置は、第１のバージョンのプログラムを格納する第１格納部と、第１のバージョンと同じ又は第１のバージョンよりも新しいバージョンである第２のバージョンのプログラムを格納する第２格納部と、第２のバージョンのプログラムと第２のバージョンのプログラムよりもバージョンが新しい第３のバージョンのプログラムとの差分を取得する取得部と、第２格納部に格納される第２のバージョンのプログラムと取得部によって取得した差分とから第３のバージョンのプログラムを生成し、生成した第３のバージョンのプログラムを第１格納部に格納する更新部とを備える。
【選択図】図２

Description

本発明は、プログラムの更新処理に関する。

カーナビゲーションシステムを搭載する車載器等は、例えば、道路の新設等に合わせて、地図情報等のアプリケーションプログラムを更新する必要がある。例えば、車載器のオペレーティングシステム及びアプリケーションプログラム等を含むプログラム（以下、まとめてプログラムと称する）を更新する方法として以下の２つが挙げられる。

（１）専門家による更新処理の実施
車載器を保有するユーザがメーカへハードディスク（以下、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ））又は車載器そのものを送り、メーカがプログラムの更新処理を実施する方法である。若しくは、自動車の販売業者に自動車を預けて、販売員がプログラムの更新処理を実施する方法である。

この方法では、専門家がプログラムの更新処理を実施するので、プログラムの更新処理の手順、手段等がある程度自由に実施可能である。専門家による更新処理の実施における利点は、例えば、以下の点が挙げられる。

（１）プログラムの個別の更新から、全プログラムの更新まで更新するプログラムの選択が自由に実施可能である。（２）プログラムの更新処理に使用する治具等の専用の接続機器を使用できる。また、機器を分解して記憶媒体を取り出すことも可能である。プログラムの更新に失敗してもやり直すことが可能である。（３）データのバックアップを取ることが可能である。（４）リカバリによって工場出荷時に戻すことも可能である。

専門家によるプログラムの更新処理の実施の以上のような利点に対して、例えば、以下に示す欠点もある。

（１）車載器、又はＨＤＤをメーカに送らなければならない、もしくは、ディーラーへ出向いて自動車を預ける必要があるなどの、ユーザの手間がかかる。（２）車載器、ＨＤＤ、又は自動車を預けている間は、ユーザはカーナビゲーションシステムの使用ができない。（３）専用の治具の使用、機器の分解等、プロでしかできない作業内容である。

（２）ユーザによる更新処理の実施
ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＤＶＤ−ＲＯＭ（ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ ｄｉｓｃ）及びその他の記憶媒体に記憶された更新プログラムを利用して、ユーザ自身がプログラムの更新処理を実施する方法である。若しくは、携帯電話や車載器の通信機能等を使用して、外部との通信により更新プログラムをダウンロードして、ユーザ自身がプログラムの更新処理を実施する方法である。ユーザによる更新処理の実施における利点は、例えば、以下の点が挙げられる。

（１）ユーザ自身で実施できるため、メーカへＨＤＤを送ったり、販売店へ自動車を預けたりする必要がない。

ユーザによるプログラムの更新処理の実施の以上のような利点に対して、例えば、以下に示す欠点もある。

（２）車載器は復帰手段を持たないため、プログラムの更新処理に失敗した場合に、最悪の場合、起動が不可能になる事態に陥る可能性がある。（２）ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等を用いる場合、それらを入手する手間がかかる。（３）携帯電話や車載器の通信機能を用いて更新プログラムのデータをダウンロードする場合、パケット料金などの通信量が発生する。ダウンロードするデータが大きければ、通信料も高額になり、時間もかかる。

ユーザによるプログラムの更新処理の方法において、重大な欠点は、プログラムの更新処理に失敗した場合に復帰できない可能性があるという点である。プログラムの更新処理が失敗する原因としては、例えば、プログラムの更新処理中の電源断（自動車のアクセサリ電源の切断等）などが考えられる。

従って、ユーザによってプログラムの更新処理ができ、且つ、更新に失敗した場合に復帰手段を持つプログラム更新方法が望まれていた。

特開２００６−３０１９６０号公報

本発明は、プログラムの更新処理に失敗した場合でも、正常時の動作に復帰することができるプログラム更新方法を提供することを課題とする。

本発明は前記課題を解決するために、以下の手段を採用した。すなわち、プログラム更新装置は、第１のバージョンのプログラムを格納する第１格納部と、
前記第１のバージョンと同じ又は前記第１のバージョンよりも新しいバージョンである第２のバージョンの前記プログラムを格納する第２格納部と、
前記第２のバージョンのプログラムと前記第２のバージョンのプログラムよりもバージョンが新しい第３のバージョンの前記プログラムとの差分を取得する取得部と、
前記第２格納部に格納される前記第２のバージョンのプログラムと前記取得部によって取得した差分とから前記第３のバージョンのプログラムを生成し、前記生成した第３のバージョンのプログラムを前記第１格納部に格納する更新部とを備える。

本発明によれば、第１格納部に格納される第１のバージョンのプログラムが第３のバージョンのプログラムに更新される一方で、第２格納部には、第２のバージョンのプログラムが保持され続ける。例えば、第３のバージョンのプログラムを生成するステップ、又は、第３のバージョンのプログラムを第１格納部に格納するステップにおいて、コンピュータの電源が断絶する場合でも、第２のバージョンのプログラムが保持され続けているので、第２のバージョンのプログラムを使用して、復帰することができる。

また、本発明の態様は、工場出荷時のバージョンのプログラムと前記工場出荷時のバージョンよりも新しいバージョンである第１のバージョンの前記プログラムとを格納した補助記憶装置と、
前記補助記憶装置からローディングされた前記第１のバージョンのプログラムを保持する主記憶装置と、
電源投入時に前記主記憶装置に保持される第１のバージョンのプログラムを起動するＣＰＵと、を備える装置であって、
前記ＣＰＵは、
前記主記憶装置に保持される第１のバージョンのプログラムにエラーがある場合、及び、前記主記憶装置に保持される第１のバージョンのプログラムが今回の電源投入時までの間に所定回数以上動作を中断させていた場合には、前記補助記憶装置に格納された前記第１のバージョンのプログラムを前記主記憶装置にローディングし、
前記主記憶装置に保持される第１のバージョンのプログラムが今回の電源投入時までの間に所定回数以上ローディングに失敗している場合には、前記補助記憶装置に格納された前記工場出荷時のバージョンのプログラムを前記主記憶装置にローディングする。

本発明によれば、主記憶装置にローディングされた第１のバージョンのプログラムデータに異常が発生している場合でも、補助記憶装置から再度第１のバージョンのプログラムのローディングを実行し正常な状態に復帰することができる。また、補助記憶装置からの第１のバージョンのプログラムのローディングが失敗した場合でも、工場出荷時のバージョンのプログラムを使用して装置を起動することができる。このようにして、段階的に処理を行うので、より効率的に復旧処理を行うことができる。また、最終的には、工場出荷時のバージョンのプログラムによって装置の起動が保証される。

本発明によれば、プログラムの更新処理に失敗した場合でも、正常時の動作に復帰することができるプログラム更新方法を提供することができる。

プログラム更新システムの構成例を示す図である。 プログラム更新システムのプログラム更新処理における動作例を示す図である。 プログラム更新処理中に電源断が発生した場合の復帰動作の例について示す図である。 プログラム更新処理中に電源断が発生した場合の復帰動作の例について示す図である。 ＦＲＯＭ内のブートフラグの値の例を示す図である。 車載器のリカバリデータの保持の例を示す図である。 正常時の起動動作の流れの例を示す図である。 起動シーケンスの例を示す図である。 異常時シーケンスＡで実行される処理の流れの例を示す図である。 異常時シーケンスＡの処理フローを示す図である。 異常時シーケンスＢで実行される処理を示す図である。 異常時シーケンスＢの処理フローを示す図である。

以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成には限定されない。

＜第１実施形態＞
本発明のプログラム更新方法は、機器の１つの記憶媒体に、同一のプログラム群を格納するフォルダ（以降、プログラムフォルダと称する）を２個保持する。プログラムの更新処理の際には、一方のプログラムフォルダ内のプログラム群を更新し、他方のプログラムフォルダ内のプログラム群はバックアップとしてそのまま保持する。

２個のプログラムフォルダについて交互にプログラム更新処理を実施することによって、一方のプログラムフォルダはプログラム群を更新して最新のバージョンのプログラム群
を保持することができる。また、他方のプログラムフォルダは更新処理の直前まで使用していたバージョンのプログラム群を保持することができる。プログラムの更新処理の後に、最新のバージョンのプログラム（更新済みのプログラム）が動作しない場合には、プログラム更新処理を実施しなかった（バックアップとしての）プログラムフォルダを選択して、当該プログラムを起動することが可能となる。

＜プログラム更新システムの構成例＞
図１は、プログラム更新システムの構成例を示す図である。プログラム更新システムは、車載器１と、更新プログラムを保持する、例えば、メーカのサーバであるセンタＣ１とを含む。

センタＣ１は、例えば、車載器１に搭載されているプログラムのメーカ等のサーバである。センタＣ１は、プログラムの更新情報を発信する。センタＣ１は、バージョン比較部Ｃ２を備える。バージョン比較部Ｃ２は、車載器１に搭載されているプログラムのバージョンとセンタＣ１が保持する最新のプログラムのバージョンを比較して差分データを生成する。

車載器１は、ユーザの自動車に搭載されているカーナビゲーションシステムを備える機器である。車載器１は、携帯電話／ＤＣＭ（Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍｏｄｕｌｅ）２と、マスタ機器と３と、スレーブ機器４と、デッキ５とを備える。

携帯電話/ＤＣＭ２は、外部のセンタＣ１と無線通信を行うインターフェイスである。
カーナビゲーションシステムを備える車載器では、携帯電話と（専用ケーブル等で）接続して、携帯電話の通信機能を用いてプログラムの差分データをダウンロードする機種もある。また、ＤＣＭと呼ばれる車載器専用の通信機を備える機種もある。図１では、センタＣ１との通信インターフェイスとして、携帯電話とのインターフェイスとＤＣＭとをまとめて携帯電話／ＤＣＭ２として表示している。

デッキ５は、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）、又は、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などの外部記憶媒体からプログラムの更新データを読み出す機器である。

マスタ機器３は、マイクロコンピュータ（以下、マイコンと称す）を少なくとも１つ備えており、スレーブ機器４を取りまとめる中心的役割を果たす、車載器１に１台のみ存在する機器である。マスタ機器３のような車載器専用の制御コンピュータをＥＣＵ（Ｅｌｅｃｔｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と呼ぶこともある。

マスタ機器３は、通信部３１と、ダウンロード選択部３２と、バージョン情報収集部３３と、プログラム更新部３４と、スレーブ通信部３５と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）３６と、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３７と、ＦＲＯＭ（Ｆｌａｓｈ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３８とを備える。

通信部３１（「取得部」に相当）は、携帯電話／ＤＣＭ２又はデッキ５と通信を行う。通信部３１は、携帯電話／ＤＣＭ２又はデッキ５を通じて更新データを受信し、ＨＤＤ３６に格納する。

ダウンロード選択部３２は、携帯電話／ＤＣＭ２又はデッキ５のどちらから更新データをダウンロードするかを選択する。ダウンロード選択部３２は、例えば、デッキ５にＣＤ又はＤＶＤが挿入されたことを検知し、デッキ５から更新データのダウンロードを行うこ
とを選択する。

バージョン情報収集部３３は、現在のマスタ機器３に搭載されるプログラムのバージョンを管理する。

プログラム更新部３４（「更新部」に相当）は、ダウンロードされた更新データから実際にプログラムの更新処理を実施する。プログラム更新部３４の詳細については、後述する。

スレーブ通信部３５は、スレーブ機器４と接続し、通信を行う。マスタ機器３とスレーブ機器４とは、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）配線やバス接続によって接続されている。

ＨＤＤ３６は、車載器１上で実行されるプログラムや関連するデータ等を格納する補助記憶装置である。図１においては、マスタ機器３がＨＤＤ３６を備える図を示している。ＨＤＤ３６は、マスタ機器２及びスレーブ機器４とは独立に車載器１内に備えられてもよい。

ＤＲＡＭ３７は、主記憶装置である。ＤＲＡＭ３７は、ＨＤＤ３６に格納されているプログラムをローディングするローダプログラムを格納する。ローダプログラムは、あるプログラムを起動するときに、ＨＤＤ３６に格納されているプログラムデータをＤＲＡＭ３７上に展開する。

ＦＲＯＭ３８は、不揮発性の記憶装置である。ＦＲＯＭ３８は、ブートプログラムとブートフラグとを格納する。ブートプログラムは車載器１が電源投入等により起動する際の起動プロセスを格納したプログラムである。ブートフラグは、プログラムをローディングするプログラムフォルダを示すフラグを保持する。詳細は、後述する。

スレーブ機器４は、それぞれが独自の機能を果たす。スレーブ機器４には、例えば、デジタルテレビ装置、ＤＶＤ再生装置等がある。スレーブ機器４は、車載器１の仕様によって、備えられる個数が変わる。

スレーブ機器４の中でも、例えば、デジタルテレビ装置等のように扱うデータ量が多い場合には、１つのマイコンにかかる負荷が大きくなるため、マイコンを複数備えることがある。スレーブ機器４がマイコンを複数備える場合には、複数のマイコンの内の１つのマイコンを親マイコン、その他のマイコンを子マイコンというように分ける。子マイコンは親マイコンを通じてマスタ機器から更新データの受信等を行う。

スレーブ機器４は、共通して、機器通信部４１1、プログラム更新部４１２、バージョ
ン情報収集部４１３を有する。マイコンを複数備えるスレーブ機器４では、親マイコンが機器通信部４１１、プログラム更新部４１２、バージョン情報収集部４１３を有する。スレーブ機器４がマイコンを複数備える場合には、親マイコン、子マイコンそれぞれが互いに通信するための通信部を備える。子マイコンは、親マイコンとの通信インターフェイスである通信部４２１とプログラム更新部４２２とを備える。

機器通信部４１１は、マスタ機器３と接続するインターフェイスである。機器通信部４１１は、例えば、ＬＡＮ配線やバス接続等でマスタ機器３と接続する。

バージョン情報収集部４１３は、スレーブ機器４内の親マイコン及び子マイコンが使用するプログラムのバージョン情報を管理する。バージョン情報収集部４１３は、マスタ機
器３がダウンロードしたプログラムの更新データとスレーブ機器が実行するプログラムのバージョンとを比較する。

プログラム更新部４１２及びプログラム更新部４２２は、マスタ機器３によってダウンロードされた更新データから、スレーブ機器４の親マイコン及び子マイコンそれぞれのプログラム更新処理を行う。プログラム更新部４１２及びプログラム更新部４２２については、後述する。

マスタ機器３の通信部３１、ダウンロード選択部３２、バージョン情報収集部３３、プログラム更新部３４、及びスレーブ通信部３５は、マスタ機器３が備えるマイコンのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、及びそれぞれの機能部の専用の電子回路を含んだＩＣチップ等によって実現される。スレーブ機器４の機器通信部４１１、プログラム更新部４１２、４２２、バージョン情報収集部４１３、通信部４１４、４２２は、スレーブ機器４が備える親マイコン及び子マイコンのＣＰＵ、電子回路を含んだＩＣチップ等で実現される。

＜プログラムの更新システムの動作例＞
図２は、プログラム更新システムのプログラム更新処理における動作例を示す図である。図２では、代表してマスタ機器３がプログラム更新処理を実行する場合を例として説明する。ＨＤＤ３６には、アップデートフォルダとプログラムフォルダＡとプログラムフォルダＢとが設定されている。アップデートフォルダは、プログラム更新に関するファイルが格納される。プログラムフォルダＡ及びプログラムフォルダＢは、マスタ機器３が使用する全プログラム（以下、プログラム群と称す）が格納されている。図２では、プログラムフォルダＡには、バージョン２のプログラム群が格納されており、プログラムフォルダＢには、プログラムフォルダＡに格納されているプログラム群のバージョンよりも古いバージョン１のプログラム群が格納されているとして説明する。

マスタ機器３のプログラム更新部３４は、ＨＤＤ３６のアップデートフォルダ内に管理ファイルを作成する（ＯＰ１）。この時点では、管理ファイルは空である。

ダウンロード選択部３２は、携帯電話／ＤＣＭ２からダウンロードするか、デッキ５から更新データと読み出すかを選択し、通信部４１に指示を出す。通信部４１は、ダウンロード選択部３２から指示された方を選択し、差分データファイルをダウンロードする（ＯＰ２）。ダウンロードされた差分データファイルはＨＤＤ３６のアップデートフォルダに保存される。

尚、差分データとは、センタＣ１又はＣＤ、ＤＶＤなどの外部記憶媒体が保持するプログラムと、プログラムフォルダＡ又はプログラムフォルダＢが格納するプログラム群の内最も新しいバージョンのプログラム群との差分データである。バージョン情報収集部３３は、プログラムフォルダＡ及びプログラムフォルダＢに格納されているプログラム群のバージョンを管理している。携帯電話／ＤＣＭ２経由でセンタＣ１から差分データをダウンロードする場合には、バージョン情報収集部３３で管理している内で最も新しいバージョンをセンタＣ１に通知し、センタＣ１において最新のバージョンのプログラムとの差分データを生成する。デッキ５を経由して、ＣＤ−ＲＯＭ／ＤＶＤ−ＲＯＭ等の外部記憶媒体から差分データを取得する場合には、通信部３１は、バージョン情報収集部３３で管理している内で最も新しいバージョンのプログラムと、外部記憶媒体に格納されているバージョンのプログラムとの差分のみを読み出す。

差分データファイルのアップデートフォルダへの保存が完了すると、プログラム更新部３４は、管理ファイルに差分データのダウンロード済みを記録する（ＯＰ３）。管理ファ
イルへの記録方法は、例えば、管理ファイル内の差分データのダウンロード済みを示す「差分データダウンロードフラグ」を立てる。

次に、プログラム更新部３４は、ダウンロードされた差分データファイルをモジュール毎の差分データファイルに分割する（ＯＰ４）。プログラム更新部３４は、モジュール毎の差分データファイルを生成すると、管理ファイルにファイル分割済みであることを記録する（ＯＰ５）。管理ファイルへの記録方法は、例えば、管理ファイル内のファイル分割済みを示す「ファイル分割済みフラグ」を立てる。

プログラム更新部３４は、ＦＲＯＭ３８内のブートフラグを確認して、更新対象のプログラムフォルダを決定する（ＯＰ６）。ブートフラグは、プログラムフォルダＡ又はプログラムフォルダＢの何れが現在有効になっているかを示すフラグを保持する。例えば、プログラムフォルダＡが、現在有効になっているとする。現在プログラムフォルダＡが有効になっている場合には、プログラムフォルダＡに格納されているプログラム群が、マスタ機器３が搭載するプログラムの最新バージョンであることを示す。従って、ブートフラグでプログラムフォルダＡが現在有効なフォルダである場合には、プログラム更新部３４は、より古いバージョンのプログラム群を格納するプログラムフォルダＢを更新対象のフォルダに決定する。

プログラム更新部３４は、更新対象のプログラムフォルダＢ内に格納されるファイルを全て削除する（ＯＰ７）。プログラム更新部３４は、更新対象でないプログラムフォルダＡ内のファイルと差分データファイルとから新たにプログラムファイルをプログラムフォルダＢに生成する（ＯＰ８）。例えば、プログラムフォルダＡ内のファイルＡと、差分データファイルａとから新ファイルＡをプログラムフォルダＢ内に生成する。新ファイルＡの生成が完了すると、プログラム更新部３４は、管理ファイル内に新ファイルＡを生成済であることを記録する（ＯＰ９）。

プログラム更新部３４は、プログラムフォルダＡ格納されているファイル分だけＯＰ８からＯＰ９の処理を繰り返す（ＯＰ１０）。

プログラムフォルダＡに格納されている全ファイルについて新ファイルの生成が完了すると、プログラム更新部３４は、ＦＲＯＭ３８内のブートフラグの有効プログラムフォルダをプログラムフォルダＢに設定する（ＯＰ１１）。プログラム更新部３４は、管理ファイル内にブートフラグ更新済みを記録する（ＯＰ１２）。

プログラム群を格納するプログラムフォルダを２つ用意し、古いバージョンのプログラム群を格納するプログラムフォルダのみを更新することによって、その直前まで使用していた動作確認済みのプログラムフォルダをバックアップとして保持することができる。

図３Ａ及び図３Ｂは、図２で説明したＯＰ１からＯＰ１２の各処理中に電源断が発生した場合の復帰動作の例について示す図である。図３では、車載器１の電源（自動車のアクセサリ電源）が何らかの要因でオフとなり、プログラム更新処理が強制的に終了され、その後、車載器１が起動した場合のプログラム更新処理の復帰動作を示す。

車載器1が再起動した後、アップデートフォルダ内の管理ファイルの中が初期状態（空
）である場合には、プログラム更新部３４は、ＯＰ1から処理を開始する。管理ファイル
の中身が初期状態である場合には、電源断が発生した時の状態として、管理ファイルの生成処理中（ＯＰ１）、差分データのダウンロード中（ＯＰ２）、管理ファイルへ差分データのダウンロード済みを記録中（ＯＰ３）、であったと考えられる。若しくは、ＯＰ１からＯＰ３までの各処理の間であったと考えられる。そのため管理ファイルの中身が初期状
態である場合には、プログラム更新部３４は、ＯＰ１から処理を開始し、生成途中のファイル（管理ファイル、差分データファイル）が存在する場合には、一旦その生成途中のファイルを破棄して再生成する。

管理ファイルの中身が、差分データダウンロード済みを記録している場合には、すなわち、「差分データダウンロードフラグ」が立っている場合には、プログラム更新部３４は、ＯＰ４から処理を開始する。この場合には、電源断が発生した時の状態として、差分データファイルを分割してモジュール毎の差分データファイル生成中（ＯＰ４）、管理ファイルへモジュール毎に分割した差分データファイル生成済みを記録中（ＯＰ５）、の何れかであったと考えられる。若しくは、ＯＰ３からＯＰ５までの各処理の移行時であったと考えられる。そのため管理ファイルの中身が差分データダウンロード済みを記録している場合には、プログラム更新部３４は、ＯＰ４から処理を開始する。

管理ファイルの中身が、差分データダウンロード済みとファイル分割済みとを記録している場合には、すなわち、「差分データダウンロードフラグ」と「ファイル分割済みフラグ」とが立っている場合には、プログラム更新部３４は、ＯＰ６から処理を開始する。この場合には、電源断が発生した時の状態として、ＦＲＯＭ３８内のブートフラグのチェック中（ＯＰ６）、更新対象プログラムフォルダ内の全ファイルの削除中（ＯＰ７）、更新対象プログラムフォルダ内に新ファイルの生成中（ＯＰ８）、管理ファイルへ新ファイルの生成済みを記録中（ＯＰ９）、の何れかであったと考えられる。若しくは、ＯＰ５からＯＰ９までの各処理の移行時であったと考えられる。そのため管理ファイルの中身が差分データダウンロード済みとファイル分割済みとを記録している場合には、プログラム更新部３４は、ＯＰ６から処理を開始する。

管理ファイルの中身が、差分データダウンロード済みと、ファイル分割済みと、新ファイルＸ生成済み（Ｘ：変数）とを記録している場合には、すなわち、「差分データダウンロードフラグ」と「ファイル分割済みフラグ」と「新ファイルＸ生成済みフラグ」とが立っている場合には、プログラム更新部３４は、ＯＰ１０から処理を開始する。即ち、プログラム更新部３４は、新ファイルＸの次のファイルの新ファイル生成から処理を開始する。この場合には、電源断が発生した時の状態として、更新対象プログラムフォルダ内に新ファイルの生成中、管理ファイルへ新ファイルの生成済みを記録中、の何れかであったと考えられる。そのため管理ファイルの中身が差分データダウンロード済みと、ファイル分割済みと、新ファイルＸ生成済みとを記録している場合には、プログラム更新部３４は、ファイルＸの次のファイルの新ファイルの生成から処理を開始する。

管理ファイルの中身が、差分データダウンロード済みと、ファイル分割済みと、全ファイル生成済みとを記録している場合には、すなわち、「差分データダウンロードフラグ」と、「ファイル分割済みフラグ」と、「新ファイルＸ生成済みフラグ」が全ファイルについて立っている場合には、プログラム更新部３４は、ＦＲＯＭ３８内のブートフラグを参照してプログラムのロードを開始する。この場合には、電源断が発生した時の状態として、ＦＲＯＭ３８内のブートフラグの有効フォルダを更新中（ＯＰ１１）、管理ファイルへブートフラグの更新済みを記録中、の何れかであったと考えられる。そのため管理ファイルの中身が差分データダウンロード済みと、ファイル分割済みと、全ファイル生成済みとを記録している場合には、プログラム更新部３４は、ブートフラグの内容を参照してプログラムをロードする。

管理ファイルにおいて、プログラム更新処理の進捗状況を管理することによって、プログラム更新処理が電源断等によって強制終了された場合でも、管理ファイルを参照することによって、強制終了された（と予想される）処理から再開することができる。

＜ブートフラグの値の例＞
図４は、ＦＲＯＭ３８内のブートフラグの値の例を示す図である。例えば、プログラムフォルダ毎に、ブートフラグを保持する。すなわち、ＦＲＯＭ３８内にブートフラグＡ及びブートフラグＢを保持し、これによって、ローディング時にロードすべきプログラムフォルダの選択を行う（有効なプログラムフォルダを示す）。

図４では、プログラムフォルダＡの状態を示すブートフラグＡと、プログラムフォルダＢの状態を示すブートフラグＢとが、それぞれ１６ビットで構成される例を示す。図４では、各ブートフラグの値を１６進数表記している。各ブートフラグは、「０ｘ００００」が無効、「０ｘ０００１」が有効を示す。ＦＲＯＭ３８の特性として、ブートフラグを書き換える（更新する）場合には、いったんブートフラグのデータを無効にする必要があるため、「０ｘＦＦＦＦ」としてデータをクリアする。また、図４では、ブートフラグの更新は、プログラムフォルダＡの更新がプログラムフォルダＢの更新に優先して行われる場合を示す。ブートフラグＡ及びブートフラグＢの状態遷移は、以下に示す状態１から状態２，３，４を経て状態５、若しくは、状態５から状態６，７，８を経て状態１に遷移するとする。

状態１は、ブートフラグＡが「０ｘ０００１」、ブートフラグＢが「０ｘ００００」である状態である。すなわち、プログラムフォルダＡが現在有効なプログラムファイルとして選択されている状態を示す。

状態２は、ブートフラグＡが「０ｘＦＦＦＦ」、ブートフラグＢが「０ｘ００００」である状態である。この場合には、ブートフラグＡは書き換えられている最中であることを示し、ブートフラグＢの値は無効を示すものの、ブートフラグＡが更新中であることを鑑みて、現在有効なプログラムフォルダはプログラムフォルダＢであると判断する。

状態３は、ブートフラグＡが「０ｘ００００」、ブートフラグＢが「０ｘ００００」である状態である。この場合には、ブートフラグＡおよびブートフラグＢの双方が更新中であることを示し、状態１から状態５への過渡期であることを鑑みて、プログラムフォルダＢが有効なプログラムフォルダであると判断する。

状態４は、ブートフラグＡが「０ｘ００００」、ブートフラグＢが「０ｘＦＦＦＦ」である状態である。ブートフラグＢは書き換えられている最中であることを示す。ブートフラグＡが優先的に更新されることを鑑みて、プログラムフォルダＢが現在有効なプログラムフォルダであることを判断する。

状態５は、ブートフラグＡが「０ｘ００００」、ブートフラグＢが「０ｘ０００１」である状態である。この場合、プログラムフォルダＡは無効で、プログラムフォルダＢが有効である。

状態６は、ブートフラグＡが「０ｘＦＦＦＦ」、ブートフラグＢが「０ｘ０００１」である状態である。ブートフラグＡは書き換えられている最中であり、状態５から遷移することを鑑みて、プログラムフォルダＡは有効で、プログラムフォルダＢは無効であると判断する。

状態７は、ブートフラグＡが「０ｘ０００１」、ブートフラグＢが「０ｘ０００１」である状態である。この場合には、ブートフラグＡおよびブートフラグＢの双方が更新中であることを示し、状態５から状態１への過渡期であることを鑑みて、プログラムフォルダＡが有効なプログラムフォルダであると判断する。

状態８は、ブートフラグＡが「０ｘ０００１」、ブートフラグＢが「０ｘＦＦＦＦ」である状態である。ブートフラグＢは書き換えられている最中であることを示す。ブートフラグＡが優先的に更新されることを鑑みて、プログラムフォルダＡが現在有効なプログラムフォルダであることを判断する。

車載器１が起動したときに、ブートフラグの値が状態２から状態４の場合は状態５の値に、状態６から状態８の場合は状態１の値に書き換えてから起動する。

＜起動シーケンスの例＞
プログラム更新処理が完了すると、車載器１、マスタ機器３、もしくは各スレーブ機器４を再起動して、更新した最新バージョンのプログラムをローディングする処理を実行する。このとき、プログラム更新処理は成功したとしても、更新した最新バージョンのプログラムのローディング処理に異常が発生する等の可能性がある。このようなプログラムのローディングの異常の原因としては、更新プログラムにバグがある、更新プログラムをＤＲＡＭ３７上にローディングするときにビット化けが生じる等が考えられる。このような、更新後のプログラムが起動しない場合に、復帰する手段として、第１実施形態の車載機１では、ＨＤＤ３６にリカバリデータを保持する。

図５は、車載器１のリカバリデータの保持の例を示す図である。ＨＤＤ３６は、ローダフォルダとリカバリフォルダを保持している。ローダフォルダには、ローディング処理を実行するローダプログラムが格納されている。リカバリフォルダには、リカバリプログラムと各機器（マスタ機器、スレーブ機器）の工場出荷状態のプログラムが格納されている。リカバリプログラムは、リカバリ処理を実行するプログラムである。

＜＜正常時の起動動作の流れの例＞＞
図６は、正常時の起動動作の流れの例を示す図である。図６は、車載器１に電源が投入されて、マスタ機器３がスレーブ機器４を含む起動シーケンスを実行する場合について説明する。マスタ機器３は、車載器１又はマスタ機器３に電源が投入されると、ＦＲＯＭ３８内に格納されているブートプログラムが起動する（ＯＰ２１）。ブートプログラムを実行する機器のＣＰＵは、ＤＲＡＭ３７にロードされているアプリケーションプログラムのエラー検出を行う（ＯＰ２２）。

アプリケーションプログラムのエラーチェックは、チェックサムによるエラー検出、異常リセット発生回数のチェック、異常ローディングの発生回数のチェックが行われる。異常リセットは、アプリケーションプログラムにバグがあると自発的にリセットを行うことがある。異常リセット回数は、ログとして記録された、今回の起動までにアプリケーションプログラムがリセットされた回数である。異常ローディングとは、ＨＤＤ３６に格納されたアプリケーションプログラムをＤＲＡＭ３７にコピーする処理に失敗することである。異常ローディング回数とは、今回の起動までに異常ローディングが発生した回数である。

アプリケーションプログラムのエラーチェックにおいて、異常がない場合には、その後、ＤＲＡＭ３７にロードされているアプリケーションプログラムを実行する（ＯＰ２３）。

正常時には、ＣＰＵは、ＨＤＤ３６に格納されているプログラムフォルダを参照せず、ＤＲＡＭ３７にロードされているアプリケーションプログラムのデータを使用して起動する。

＜＜異常が発生した場合の起動時の動作の例＞＞
図７は、起動シーケンスの例を示す図である。図７も、図６と同様に、マスタ機器３が起動シーケンスを行う場合について説明する。

車載器１又はマスタ機器３に電源が投入される（又は、再起動される）と、ＦＲＯＭ３８に格納されたブートプログラムを起動する（ＯＰ３１）。

マスタ機器３のＣＰＵは、ログに記録されたアプリケーションプログラムの異常リセット回数Ｘをチェックする（ＯＰ３２）。アプリケーションプログラムの異常リセット回数Ｘが予め設定された所定回数以上の値か否かを確認する。アプリケーションの異常リセット回数Ｘが所定回数以上の値である場合には（ＯＰ３２：Ｙ）、異常時シーケンスＡに処理が移る（ＯＰ３８）。異常時シーケンスＡについては、後述する。

アプリケーションプログラムの異常リセット回数Ｘが所定値より小さい値である場合には（ＯＰ３２：Ｎ）、異常ローディング回数Ｙが予め設定された所定回数以上の値か否かを判定する（ＯＰ３３）。異常ローディング回数Ｙが所定回数以上の値である場合には（ＯＰ３３：Ｙ）、異常時シーケンスＢに処理が移る（ＯＰ３７）。異常時シーケンスＢについては、後述する。

アプリケーションプログラムの異常ローディング回数Ｙが所定回数よりも小さい場合には（ＯＰ３３：Ｎ）、チェックサムを確認する（ＯＰ３４）。チェックサムに異常がある場合には（ＯＰ３４：Ｙ）、異常時シーケンスＡに処理が移る（ＯＰ３８）。チェックサムに異常がない場合には（ＯＰ３４：Ｎ）、アプリケーションプログラムを起動する（ＯＰ３５）。

ＣＰＵは、アプリケーションプログラムの異常リセットの発生を監視しており、異常リセットが発生した場合には（ＯＰ３６）、異常リセット回数Ｘに１を加え、異常リセットの発生を記録する（ＯＰ３９）。

＜＜異常時シーケンスＡ＞＞
図８は、異常時シーケンスＡ、すなわち、異常リセット回数Ｘが所定回数以上の値である場合と、チェックサムに異常がある場合とに実行される処理の流れの例を示す図である。図９は、異常時シーケンスＡの処理フローを示す図である。図８と図９とは、同じ処理には同じ符号を付して示す。

異常リセット回数Ｘが所定回数以上の値である場合、及び、チェックサムに異常がある場合には、ＤＲＡＭ３７にロードされているローダプログラムをＨＤＤ３６のローダフォルダから再度ローディングする（ＯＰ４１）。次に、ローディングされたローダプログラムを起動する（ＯＰ４２）。

起動されたローダプログラムに従って、ＣＰＵは、ＦＲＯＭ３８内のブートフラグをチェックして、現在有効なプログラムフォルダを取得する（ＯＰ４３）。ＣＰＵは、ＨＤＤ３６に格納されている現在有効なプログラムフォルダからアプリケーションプログラムを再度ローディングする（ＯＰ４４）。

アプリケーションプログラムのローディング時に異常が発生した場合には（ＯＰ４５：Ｙ）、異常ローディング回数Ｙに１を加え、異常ローディングの発生を記録する（ＯＰ４６）。その後、再起動して図７に示す処理を再度実行する（ＯＰ４７）。

アプリケーションプログラムのローディングに成功した場合にも（ＯＰ４５：Ｎ）、再起動をして、図７に示す処理を再度実行する（ＯＰ４７）。

＜＜異常時シーケンスＢ＞＞
図１０は、異常時シーケンスＢ、すなわち、異常ローディング回数Ｙが所定回数以上の値である場合に実行される処理を示す図である。図１１は、異常時シーケンスＢの処理フローを示す図である。図１０と図１１とは、同じ処理には同じ符号を付して示す。

異常ローディング回数Ｙが所定回数以上の値である場合には、まず、車載器１のユーザに対して、リカバリ処理を実行するか否かを問い合わせるコーションを表示する（ＯＰ５１）。表示されるコーションは、例えば、「プログラムファイル異常のため、起動できません。工場出荷状態に戻します。よろしいですか。（ＹＥＳ／ＮＯ）」など、ユーザにリカバリ処理の実行の確認を求める内容である。

ユーザは、コーション表示に対して、入力を行う（ＯＰ５２）。ユーザがリカバリ処理を実行することを選択すると（ＯＰ５３：Ｙ）、ＣＰＵはリカバリプログラムをＨＤＤ３６内のリカバリファイルからローディングする（ＯＰ５４）。ローディングされたリカバリファイルを起動し（ＯＰ５５）、ＨＤＤ３６のリカバリフォルダから工場出荷状態のアプリケーションプログラムをローディングする（ＯＰ５６）。その後、再起動して図７に示す処理を再度実行する（ＯＰ５７）。

ユーザがリカバリ処理の実行を選択しなかった場合には（ＯＰ５３：Ｎ）、再起動を行う旨のコーションを表示する（ＯＰ５８）。このとき表示されるコーションは、例えば、「システムを再起動します。」等、ユーザに再起動の確認を行う内容である。その後、再起動して図７に示す処理を再度実行する（ＯＰ５７）。

＜第１実施形態の作用効果＞
プログラムを格納するプログラムフォルダを２個保持し、プログラムの更新処理を行う場合には、どちらか一方のみを更新する。もう一方はバックアップとして保持する。これによって、プログラム更新処理中に電源断等で処理が強制終了された場合でも、元の動作保障されたプログラムのデータを失うことがない。

プログラム更新処理において、進捗状況を管理ファイルに記録することによって、プログラム更新処理が電源断等により強制終了された場合でも、管理ファイルに完了が記録された処理の次の処理から再開することができる。したがって、プログラム更新処理を最初からやり直す必要がなく、時間を省くことができる。

マスタ機器３がスレーブ機器４の更新プログラムのダウンロードも一括して行う。スレーブ機器４のプログラム更新処理を行う際には、専用の治具が必要となる場合があった。しかし、プログラム更新の窓口をマスタ機器３に一本化されることで、専用の治具がなくてもユーザがスレーブ機器４のプログラム更新処理を行うことができる。

更新プログラムをセンタＣ１からダウンロードする際には、車載器１が保持するプログラムと、センタＣ１が保持する新しいバージョンのプログラムとの差分データのみをダウンロードする。これによって、センタＣ１と車載器１との間の通信量を少なく抑えることができ、データをダウンロードする時間も短くすることができる。パケット通信等従量課金制の通信の場合には、通信量を抑えることができる。

起動時には、ＤＲＡＭ内のアプリケーションプログラムのチェックサム、異常リセット回数、異常ローディング回数といった、３種のパラメータをチェックすることによって、起動方法を判断する。これによって、段階的にリカバリを実行でき、効率がよい。また、リカバリフォルダ内には工場出荷状態の全プログラムが格納されているので、最終的には
、工場出荷状態にフルリカバリすることができ、起動が保証される。

第１実施形態によれば、ユーザ自身がプログラム更新処理を行うことができ、且つ、プログラム更新処理の中断や、プログラム更新処理の失敗により起動不可能な状態になった場合でも、正常な状態に復帰することができる。

＜変形例＞
管理ファイルを、プログラムファイルのように２個用意し、二重化してもよい。例えば、プログラム更新処理が開始されると、アップデートフォルダ内の管理ファイルＡのコピーを生成する。この管理ファイルＡのコピーファイルを管理ファイルＢとする。管理ファイルＡはそのまま保持し、プログラム更新処理では管理ファイルＢを更新する。プログラム更新処理が完了した時点で、管理ファイルＡを削除する。このようにすることによって、プログラム更新処理中に電源断が発生した場合でも、管理ファイルＡをバックアップとして保持できるため、管理ファイルの内容が失われることを防ぐことができる。

また、管理ファイルＢの更新中に電源断等が発生した場合には、例えば、以下のように判断することで、処理を再開した場合に適切な管理ファイルを選択することができる。
（１）管理ファイルＡが存在し、且つ管理ファイルＢが存在しない場合には、管理ファイルＡを参照する。
（２）管理ファイルＡ及び管理ファイルＢが存在する場合には、管理ファイルＡを参照し、管理ファイルＢは削除する。
（３）管理ファイルＡが存在せず、且つ、管理ファイルＢが存在する場合には、管理ファイルＢを参照する。

第１実施形態では、プログラムフォルダ内に格納されているプログラム群を一括して更新する処理について説明した。これに代えて、個々のプログラムを更新することも可能である。個々のプログラムを指定して更新する場合は、ブートフラグで示される有効なプログラムフォルダに格納されている方のプログラムを更新する。更新が完了したら、更新されたプログラムについて、更新済みであることを管理ファイルに記録しておく。

第１実施形態では、異常時シーケンスＢにおいて、リカバリフォルダから工場出荷状態のプログラムをローディングした。これに代えて、異常時シーケンスＢにおいて、ブートフラグをチェックし、現在有効ではないプログラムフォルダ、すなわち、更新前の動作実績のある旧バージョンのプログラムをローディングしてもよい。

また、第１実施形態では、マスタ機器３が各スレーブ機器４のプログラム更新処理、及び、リカバリ処理を行う場合について説明した。本発明は、これに限られるものではなく、自己が使用するアプリケーションプログラムについて、各スレーブ機器４でプログラム更新処理、及び、リカバリ処理を行ってもよい。

１ 車載器
２ 携帯電話／ＤＣＭ
３ マスタ機器
４ スレーブ機器
５ デッキ
３１ 通信部
３２ ダウンロード選択部
３３ バージョン情報収集部
３４ プログラム更新部
３５ スレーブ通信部
３６ ＨＤＤ
３７ ＤＲＡＭ
３８ ＦＲＯＭ
４１ 親マイコン
４２ 子マイコン
４１１ 機器通信部
４１２ プログラム更新部
４１３ バージョン情報収集部
４１４ 通信部
４２１ 通信部
４２２ プログラム更新部

Claims (5)

1. 第１のバージョンのプログラムを格納する第１格納部と、
   前記第１のバージョンと同じ又は前記第１のバージョンよりも新しいバージョンである第２のバージョンのプログラムを格納する第２格納部と、
   前記第２のバージョンのプログラムと前記第２のバージョンのプログラムよりもバージョンが新しい第３のバージョンのプログラムとの差分を取得する取得部と、
   前記第２格納部に格納される前記第２のバージョンのプログラムと前記取得部によって取得した差分とから前記第３のバージョンのプログラムを生成し、前記生成した第３のバージョンのプログラムを前記第１格納部に格納する更新部と
   を備えるプログラム更新装置。
2. 前記第１格納部と前記第２格納部とのどちらに格納されているプログラムを使用するかを示す情報を保持する記憶部をさらに備え、
   前記更新部は、前記取得した差分と、前記第２格納部に格納される前記第２のバージョンのプログラムと、から前記第３のバージョンのプログラムを生成し、前記生成した第３のバージョンのプログラムを前記第１格納部に格納した場合に、前記記憶部によって保持される前記情報を前記第１格納部に格納されているプログラムを使用することを示す情報に更新する
   請求項１に記載のプログラム更新装置。
3. 前記差分を取得する処理、前記第３のバージョンのプログラムを生成する処理、及び、前記生成した第３のプログラムを第１格納部に格納する処理のそれぞれについて処理の完了を示す管理情報を格納する管理情報格納部を
   さらに備え、
   前記更新部は、前記差分を取得する処理、前記第３のバージョンのプログラムを生成する処理、及び、前記生成した第３のプログラムを第１格納部に格納する処理の各処理が完了した場合に、該処理の完了を示す管理情報を前記管理情報格納部に格納し、前一連の処理が中断された場合に、前記管理情報格納部に格納されている管理情報に基づいて、処理の完了が示されていない処理を実行する
   請求項１に記載のプログラム更新装置。
4. 第１のバージョンのプログラムを格納する第１格納部と、
   前記第１のバージョンと同じ又は前記第１のバージョンよりもバージョンが新しい第２のバージョンのプログラムを格納する第２格納部と、を備えるコンピュータが、
   前記第２のバージョンのプログラムと前記第２のバージョンよりもバージョンが新しい第３のバージョンのプログラムとの差分を取得するステップと、
   前記第２格納部に格納される前記第２のバージョンのプログラムと前記取得した差分とから前記第３のバージョンのプログラムを生成するステップと、
   前記第１格納部に格納される前記第１のバージョンのプログラムを削除して、前記生成した第３のバージョンのプログラムを前記第１格納部に格納するステップと、を実行するプログラム更新方法。
5. 工場出荷時のバージョンのプログラムと前記工場出荷時のバージョンよりも新しいバージョンである第１のバージョンのプログラムとを格納した補助記憶装置と、
   前記補助記憶装置からローディングされた前記第１のバージョンのプログラムを保持する主記憶装置と、
   電源投入時に前記主記憶装置に保持される第１のバージョンのプログラムを起動するＣＰＵと、を備える装置であって、
   前記ＣＰＵは、
   前記主記憶装置に保持される第１のバージョンのプログラムにエラーがある場合、及び、前記主記憶装置に保持される第１のバージョンのプログラムが今回の電源投入時までの間に所定回数以上動作を中断させていた場合には、前記補助記憶装置に格納された前記第１のバージョンのプログラムを前記主記憶装置にローディングし、
   前記主記憶装置に保持される第１のバージョンのプログラムが今回の電源投入時までの間に所定回数以上ローディングに失敗している場合には、前記補助記憶装置に格納された前記工場出荷時のバージョンのプログラムを前記主記憶装置にローディングする
   情報処理装置。

Images