ファームウェア保護装置、そのプログラム
【課題】二重化したファームウェアの両方が破損してしまった場合でもリカバリすることができる。
【解決手段】二重化したファームウェアそれぞれについて、そのプログラム本体であるプログラム部５０を、複数のプログラムブロック１〜ｎ（５１）に分割して記憶する。また、ヘッダ部４０には各プログラムブロック５１毎に対応するＳＵＭ４５を記憶し、このＳＵＭ４５を用いて各プログラムブロック５１毎に破損したか否かをチェックする。二重化したファームウェアの両方が破損してしまった場合でも、一方において破損したプログラムブロック５１が、他方においては破損していない場合には、他方のプログラムブロック５１を用いてリカバリすることができる。
【解決手段】二重化したファームウェアそれぞれについて、そのプログラム本体であるプログラム部５０を、複数のプログラムブロック１〜ｎ（５１）に分割して記憶する。また、ヘッダ部４０には各プログラムブロック５１毎に対応するＳＵＭ４５を記憶し、このＳＵＭ４５を用いて各プログラムブロック５１毎に破損したか否かをチェックする。二重化したファームウェアの両方が破損してしまった場合でも、一方において破損したプログラムブロック５１が、他方においては破損していない場合には、他方のプログラムブロック５１を用いてリカバリすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組込み機器に搭載するファームウェアを保護する技術に関する。
【背景技術】
【０００２】
従来、組込み機器に搭載するファームウェアの保護方法として、ファームウェアを記憶する領域を二重化する方法が広く行われている。これは、不揮発性メモリの経年劣化やダウンロード中の電源断等により、一方のプログラム（ファームウェア）が破損してしまった場合でも、必ず機器を起動できるようにするためのものである。
【０００３】
特許文献１に記載の発明では、ファームウェアを記憶する領域を二重化して、一方の領域はダウンロード時に書換え、もう一方の領域は起動したファームウェアが自分自身を書換えることで、二重化を行っている。また、記憶したファームウェアの一方が破損した場合は、上記と同様に、起動したファームウェアが自分自身を複製して、ファームウェアを常に二重化した状態にしている。
【０００４】
また、特許文献２には、データ数の増減に関わらずチェックサムデータ量を減少させることができるデータ保護装置が提案されている。すなわち、従来では二重化されたメモリに記憶される各データ毎に、そのデータに対するチェックサムデータを生成・記憶しており、このチェックサムデータを用いて各データ毎の異常の有無をチェックしていた。この為、データ数の増大に伴って多量のチェックサムデータが必要となるという問題があった。
【０００５】
この問題を解決する為、特許文献２の発明では、各データが１つのブロックにまとめられた実データ群と、この実データ群について、個々の実データの総和をとった１つのチェックサムデータとから構成されるようにしている。これによりチェックサムデータ量を大幅に削減することができる。また、チェックサムデータを用いたチェック処理によって異常が検出された場合には、ブロック内の実データ群全てについて修正を行う。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平４−３３６６４２号公報
【特許文献２】特開２０００−１４８６０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来、不揮発性メモリに記憶したファームウェアが破損しているかどうかの判定は、ファームウェアに付加したＳＵＭ（チェックサム）等を用いて行われている。しかし、ＳＵＭはプログラム全体に対して計算したものであり、プログラムの全体ではなく一部が破損した場合においても不整合となってしまう。そのため、二重化したファームウェアの両方が同時に破損した場合、従来の方法では、ファームウェアの破損状態に関わらず、装置を起動することができなかった。但し、人手を介して、ファームウェアを再度ダウンロードすれば、装置を起動（リカバリ）することは可能である。しかしながら、この様な人手を介在する方法は、組込み機器としては望ましくなく、また人間に余計な手間を掛けさせることになる。
【０００８】
上記特許文献１の発明では、ファームウェアを常に二重化する方法が提案されているが、二重化したファームウェアが同時に破損するケースに関しては何等言及していない。
また、記憶したファームウェアの一方が破損した場合、ファームウェアの破損状態に関わらず（一部のみが破損した場合でも）、起動したファームウェアの全領域を複製しているため、装置の起動時間が大幅に遅くなるという課題がある。
【０００９】
本発明の課題は、二重化したファームウェアの一部が破損した場合に、破損した部分のみをリカバリすることでリカバリに要する時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消でき、更に二重化したファームウェアの両方が破損してしまった場合でもファームウェアをリカバリすることができ、装置を起動することを可能とするファームウェア保護装置、そのプログラム等を提供することである。
【課題を解決するための手段】
【００１０】
本発明のファームウェア保護装置は、ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置であって、前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段とを有する。
【００１１】
上記ファームウェア保護装置では、ファームウェアを分割記憶し、各分割プログラム毎にチェックサムを保持している。これより、各分割プログラム毎に、それが破損しているか否かをチェックできる。ファームウェアの全体が破損しているのではなく、その一部のみが破損している場合には、破損している分割プログラムのみをリカバリすればよく、リカバリ処理に掛かる時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消できる。
【００１２】
上記ファームウェア保護装置において、例えば、前記二重化されたファームウェアが両方とも破損した場合、前記リカバリ手段は、まず一方のファームウェアをリカバリ対象として、該リカバリ対象のファームウェアに関する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムが、破損しているか否かをチェックし、他方のファームウェアにおいても破損している場合にはリカバリ不能とするが、破損していない場合には該他方のファームウェアにおける分割プログラムを用いて前記破損した分割プログラムをリカバリする。
【００１３】
本発明のファームウェア保護装置では、上記の通り、分割プログラム単位で破損の有無のチェック、リカバリを行えるので、たとえ二重化されたファームウェアが両方とも破損した場合でも、両方で同じ分割プログラムが破損していない限りは、リカバリを行える。
【発明の効果】
【００１４】
本発明のファームウェア保護装置、そのプログラム等によれば、二重化したファームウェアの一部が破損した場合に、破損した部分のみをリカバリすることでリカバリに要する時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消できる。更に二重化したファームウェアの両方が破損してしまった場合でもファームウェアをリカバリするこ
とができ、装置を起動することを可能とする。
【図面の簡単な説明】
【００１５】
【図１】本例のファームウェア保護装置の一例である組込み機器の構成例である。
【図２】（ａ）、（ｂ）、（ｃ）は、外部フラッシュＲＯＭのデータブロック構成例を示す図である。
【図３】ＳＤＲＡＭのデータ構成図である。
【図４】ブートファームウェアによるメイン処理のフローチャート図である。
【図５】ブートファームウェアの起動処理のフローチャート図である。
【図６】ブートファームウェアのリカバリ処理のフローチャート図（その１）である。
【図７】ブートファームウェアのリカバリ処理のフローチャート図（その２）である。
【図８】オペレーションファームウェアの処理フローチャート図（その１）である。
【図９】オペレーションファームウェアの処理フローチャート図（その２）である。
【図１０】ダウンロード処理のフローチャート図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例のファームウェア保護装置の一例である組込み機器の構成例である。尚、本例のファームウェア保護装置は、組込み機器に限らない。但し、特に組込み機器である場合には、上述した装置の起動ができない（もしくは起動が大幅に遅くなる）ことは、重大な問題となり、避けなければならないものである。
【００１７】
図示の例の組込み機器１０は、ＣＰＵ１１、外部フラッシュＲＯＭ１４、ＳＤＲＡＭ１５を有し、ＣＰＵ１１は、ＲＡＭ１２、内蔵フラッシュＲＯＭ１３を有する。また、組込み機器１０は、上位機１に接続している。
【００１８】
上位機１は、オペレーションファームウェアを組込み機器１０内のＳＤＲＡＭ１５に転送して記憶する処理機能と、このＳＤＲＡＭ１５に記憶されたオペレーションファームウェアを外部フラッシュＲＯＭ１４にダウンロードさせるための指示を組込み機器１０に対して行う処理機能等を備える、ＰＣ（パソコン）等の上位装置である。尚、このダウンロード指示を受けた組込み機器１０側では、後述する図１０に示すダウンロード処理を実行する。
【００１９】
内蔵フラッシュＲＯＭ１３は、ブートファームウェアを記憶する。
外部フラッシュＲＯＭ１４は、オペレーションファームウェアを記憶する。これは、オペレーションファームウェアを二重化して記憶・管理している。そして、本手法では、後に図２で説明するように、オペレーションファームウェアを複数ブロックに分割して管理している。
【００２０】
ＳＤＲＡＭ１５は、外部フラッシュＲＯＭ１４に記憶したオペレーションファームウェ
アの実行領域を有する（ワークメモリである）。
尚、上記オペレーションファームウェアが、組込み機器に搭載させて何らかの処理を実行させる為のファームウェアであり、二重化により保護する対象となるファームウェアである。一方、上記ブートファームウェアは、ブート処理（詳しくは後述する）を実行するファームウェアである。
【００２１】
図２に、外部フラッシュＲＯＭ１４のデータブロック構成を示す。
図２（ａ）に示すように、外部フラッシュＲＯＭ１４の記憶領域は、管理情報格納領域２１と、複数のＦＷ格納領域２２（図示の例では、ＦＷ格納領域ａ、ｂ等；ＦＷはファームウェアの略号とする）等から成る。
【００２２】
各ＦＷ格納領域２２は、それぞれオペレーションファームウェアを記憶する領域である。そして、上記の通り、オペレーションファームウェアは二重化されて記憶されており、例えばＦＷ格納領域ａとｂには基本的には同じオペレーションファームウェアが記憶されている。但し、上位機１から新バージョンのオペレーションファームウェアが転送されて、これをダウンロードした際には、一時的に、ＦＷ格納領域ａ、ｂのどちらか一方には新バージョン、他方には旧バージョンが格納された状態になる場合もある。また、何かの間違いで別のプログラムが格納される可能性もある。
【００２３】
管理情報格納領域２１は、上記ＦＷ格納領域２２に格納されているオペレーションファームウェアに関する各種管理情報が記憶される。これは詳細には図２（ｂ）に示すように、管理情報格納領域２１には、動作ステータス３１、バックアップステータス３２、カレントＦＷ格納領域番号３３、破損ブロック番号３４等の各種管理情報が記憶される。
【００２４】
尚、本説明では、管理情報格納領域２１には、ＦＷ格納領域ａとｂとに二重化されて格納される１つのオペレーションファームウェアに関する管理情報が記憶されるものとする。尚、オペレーションファームウェアが複数種類ある場合には、各オペレーションファームウェア毎に対応付けて上記管理情報が記憶される。
【００２５】
また尚、特に図示しないが、管理情報格納領域２１には、対応するオペレーションファームウェアの各格納領域（上記の例ではＦＷ格納領域ａとＦＷ格納領域ｂ）のアドレス等の情報も格納されている。例えば、後述する格納領域番号（１，２）にそれぞれ対応付けて、そのオペレーションファームウェアの各格納領域のアドレス等の情報も格納される。このアドレス等は、例えば、ヘッダ部４０の各種情報のアドレスや、プログラム部５０の各プログラムブロック５１のアドレス等である。また、ヘッダ部４０における各プログラムブロックＳＵＭ４５が、プログラム部５０におけるどのプログラムブロック５１に対応するものであるのかを示す情報等も、例えば管理情報格納領域２１に格納されていてもよい。
【００２６】
動作ステータス３１は、上記オペレーションファームウェアの動作状態を示すものであり、その値と意味は本例では下記の通りとする。
・0 ：運用中
・1 ：リカバリ中
・2 ：停止中（リカバリが不可能なため、再ダウンロードが必要な状態）
バックアップステータス３２は、オペレーションファームウェアがバックアップされているか否かを示すものであり、その値と意味は本例では下記の通りとする。
・0 ：バックアップなし
・1 ：バックアップあり
尚、“バックアップあり”とは、オペレーションファームウェアが正常に二重化されている状態であることを示す。よって、例えば、ＦＷ格納領域ａとｂとに格納されているオ
ペレーションファームウェアが、バージョンが同じではない場合や、破損が生じている場合には、“バックアップなし（０）”となる。
【００２７】
カレントＦＷ格納領域番号３３は、ブートファームウェアがブートするオペレーションファームウェアの格納領域番号であり、その値と意味は本例では下記の通りとする。
・1 ：ＦＷ格納領域ａ
・2 ：ＦＷ格納領域ｂ
つまり、カレントＦＷ格納領域番号３３＝‘１’の場合には、ＦＷ格納領域ａがカレント側であり、ＦＷ格納領域ｂはカレント側ではない（非カレント側というものとする）ことを意味する。同様に、カレントＦＷ格納領域番号３３＝‘２’の場合にはＦＷ格納領域ｂがカレント側であり、ＦＷ格納領域ａは非カレント側であることを意味する。
【００２８】
ブートファームウェアは、オペレーションファームウェアの処理を実行させる際には、カレント側のオペレーションファームウェアを、ＳＤＲＡＭ１５に転送して起動する。但し、カレント側のオペレーションファームウェアが正常に動作しない場合（破損がある等）には、非カレント側のオペレーションファームウェアをカレント側として、ＳＤＲＡＭ１５に転送して起動する。つまり、非カレント側とは、通常、バックアップ側を意味する。
【００２９】
破損ブロック番号３４は、カレントＦＷ格納領域番号３３が示す領域（上記カレント側の領域）における破損したプログラムブロックのブロック番号を、ビットに割当てて記憶するものであり、その意味は本例では以下の通りとする。
【００３０】
・ビットＯＮ ：破損あり
・ビットＯＦＦ：破損なし
尚、上記ブロック番号とは、後述する各プログラムブロック５１に割り当てられた識別番号である。例えばブロック番号が‘１’〜‘８’であったとしたならば、破損ブロック番号３４は８ビットから成り、ブロック番号‘１’は１ビット目に割り当て、ブロック番号‘８’は８ビット目に割り当てる。
【００３１】
各ＦＷ格納領域２２のデータ構成は同一であり、その一例を図２（ｃ）に示す。
図２（ｃ）に示す例では、ＦＷ格納領域２２に格納されるオペレーションファームウェアは、ヘッダ部４０とプログラム部５０とから成る。
【００３２】
プログラム部５０がオペレーションファームウェア本体である。プログラム部５０には、図示の通り、オペレーションファームウェア本体（プログラム本体）が、固定長ブロック（各プログラムブロック５１）に分割されて格納されている。
【００３３】
また、ヘッダ部４０には、名称４１、バージョン４２、ヘッダサイズ４３、プログラムサイズ４４、プログラムブロックＳＵＭ４５、ヘッダＳＵＭ４６等の、上記プログラム部５０のプログラム本体に関する各種データが格納される。
【００３４】
名称４１は、プログラム部５０に格納されているオペレーションファームウェアの名称等である。バージョン４２は、このオペレーションファームウェアのバージョンである。ヘッダサイズ４３は上記ヘッダ部４０のデータサイズである。
【００３５】
プログラムサイズ４４は、上記オペレーションファームウェアのプログラム部５０の実サイズである。尚、これは、各プログラムブロック５１の合計サイズを意味するものではない(プログラムブロック５１は固定長なので、プログラムサイズがこのブロックサイズで割り切れない場合には一致しない；最終ブロックの一部は空白等となる)。
【００３６】
各プログラムブロックＳＵＭ４５は、上記各プログラムブロック５１毎に対応したそのプログラムブロックのＳＵＭ（チェックサム）である。つまり、上記各プログラムブロック５１は、上記各プログラムブロックＳＵＭ４５と1対1で対応する。
【００３７】
ヘッダＳＵＭ４６は、ヘッダ部４０のＳＵＭ（チェックサム）である。これは、上記名称４１、バージョン４２、ヘッダサイズ４３、プログラムサイズ４４、のＳＵＭを計算したものに、プログラムブロックＳＵＭ４５の各ＳＵＭ値を加算した値（合計）である。
【００３８】
尚、よく知られているように、チェックサムは、データの信頼性を検査する為に、予め検査対象のデータに基づいて所定の計算方法により算出しておくものである。この所定の計算方法は、様々な方法があってよく、簡単な方法としては、全データをバイト単位で（桁あふれは無視して）加算する計算方法等がよく知られているが、この例に限るものではない。尚、ハッシュ値等もチェックサムの一例として扱われることがある。
【００３９】
この様に、本例では、オペレーションファームウェアを固定長ブロックに分割して格納すると共に、各プログラムブロック毎にＳＵＭを生成・格納している。つまり、各プログラムブロック毎にＳＵＭによる異常チェック（破損の有無のチェック）を行えるようにしている。上記の通り、二重化されたオペレーションファームウェアの両方とも、この様なデータ構成となっている。
【００４０】
この様な構成を用いることで、本手法では、（詳しくは後にフローチャート図を参照して説明するが）、ファームウェア保護装置（組込み機器等）において例えば以下の１）、２）の処理機能を提供することができる。
【００４１】
１）二重化したオペレーションファームウェアが両方とも破損した場合でも、リカバリ可能となる。つまり、当然、どちらか一方でもプログラム全体が破損した場合にはリカバリ不能であるが、両方とも一部のみが破損した状態であれば、リカバリできる場合がある。リカバリできる場合とは、どちらか一方において破損したプログラムブロックが、他方においては破損していない場合である。
【００４２】
二重化したオペレーションファームウェアが両方とも破損した場合のリカバリの為の処理に関しては、その具体的な一例については詳しくは後にフローチャート図を参照して説明するが、概略的には以下の通りである（但し、これは具体的な処理の一例を示すものであり、この例に限るものではない）。
【００４３】
まず、オペレーションファームウェアを起動するファームウェア(上記ブートファームウェア)による起動処理において、オペレーションファームウェアに破損があった場合には、破損したプログラムブロック５１の情報を管理情報格納領域２１の破損ブロック番号３４に記憶する。尚、上記の通り、破損ブロック番号３４には、カレント側に関する破損情報が記憶され、非カレント側に関しては記憶されないが、これは一例であり、非カレント側に関してもその破損したプログラムブロック５１の情報を記憶するようにしてもよい。
【００４４】
後述する図５に示す処理例では、二重化したオペレーションファームウェアが両方とも破損している場合には、上記起動処理後、自動でリブートする。この場合には、これによって、ブートファームウェアによるリカバリ処理が実行されることになる。このリカバリ処理において、ヘッダ部４０と管理情報格納領域２１を参照して、破損したオペレーションファームウェアの該当ブロック（破損したプログラムブロック５１）のみを、二重化したもう一方のオペレーションファームウェアから複製してリカバリする。
【００４５】
但し、上記の通り、もう一方のオペレーションファームウェアにおいても同じプログラムブロック５１が破損していた場合には、リカバリ不能となる。この場合には、再度、オペレーションファームウェアをダウンロードすることになる（但し、従来では人手を介したが、本手法では自動的にダウンロードする）。
【００４６】
この様に、二重化したファームウェアが両方とも破損した場合でも、破損状態によっては、ファームウェアをリカバリすることができる。
尚、後述する処理例では、リカバリ処理においてはカレント側のオペレーションファームウェアのみをリカバリする。非カレント側のオペレーションファームウェアに関しては、その後にカレント側のオペレーションファームウェアを実行することで（後述する図８、図９に示す“オペレーション”処理）、リカバリされる。但し、これは一例であり、この例に限らず、リカバリ処理においてカレント側、非カレント側（バックアップ側）の両方ともリカバリしてもよい。
【００４７】
２）二重化したオペレーションファームウェアの一部が破損した場合、破損した部分のみを（プログラムブロック単位で）リカバリすることで、オペレーションファームウェアのリカバリに要する時間を大幅に減少させることができる。これより、装置の起動時間が大幅に遅くなる問題を解消できる。尚、本例では二重化したオペレーションファームウェアのどちらか一方のみが破損した場合を主に想定しているが、両方とも異なった箇所が破損した場合でも同様にして得られる効果である。
【００４８】
これに関しても、その具体的な一例については詳しくは後にフローチャート図を参照して説明するが、概略的には以下の通りである（但し、これは具体的な処理の一例を示すものであり、この例に限るものではない）。
【００４９】
まず、上記ブートファームウェアの起動処理において、どちらか一方のオペレーションファームウェアに破損があった場合には、破損したプログラムブロック５１の情報を管理情報格納領域２１の破損ブロック番号３４に記憶する。そして、他方の（破損していない）オペレーションファームウェアを起動する。
【００５０】
これより、起動したオペレーションファームウェアの処理において、ヘッダ部４０と管理情報格納領域２１を参照して、破損したオペレーションファームウェアの該当ブロック（破損したプログラムブロック５１）のみを、当該起動したオペレーションファームウェアにおける該当ブロック（上記破損したプログラムブロック５１と同じプログラムブロック５１）を用いてリカバリする。
【００５１】
これにより、上記従来のように起動したファームウェアの全領域を複製する手法に比べて、複製するデータ量が少なくて済むので、ファームウェアのバックアップに要する時間が大幅に減少させることができ、以って装置の起動時間への影響を微小にすることができる。
【００５２】
図３に、ＳＤＲＡＭ１５のデータ構成図を示す。
図示の例では、ＳＤＲＡＭ１５は、ＦＷブート領域６１、ＦＷダウンロード領域６２の各記憶領域を有する。
【００５３】
ＦＷブート領域６１は、上記オペレーションファームウェアを外部フラッシュＲＯＭ１４から転送して、実行する領域である。
ＦＷダウンロード領域６２は、新たなオペレーションファームウェアをダウンロードする際に、これを一時的に記憶する領域である。これは、上位機1から新たなオペレーショ
ンファームウェアが転送されてＦＷダウンロード領域６２に記憶される。新たなオペレーションファームウェアは、ＦＷダウンロード領域６２に一時的に記憶された後、外部フラッシュＲＯＭ１４にダウンロードして格納される（図１０に処理の一例を示す）。その後、オペレーションファームウェアを実行する際には、上記ＦＷブート領域６１に転送・格納して実行することになる。
【００５４】
図４は、ブートファームウェアによるメイン処理のフローチャート図である。
ブートファームウェアは、予め内蔵フラッシュＲＯＭ１３に記憶されているプログラムであり、ＣＰＵ１１がこのブートファームウェアを内蔵フラッシュＲＯＭ１３から読出・実行することで、図４の処理が実現される。
【００５５】
ブートファームウェアは、様々な処理を行うが、基本的には図４に示すメイン処理を経て、図示のブート本体処理、起動処理、リカバリ処理の何れかを実行するものである。ブート本体処理とは、ここではダウンロード処理であり、例えば後述する図１０の処理を実行する。
【００５６】
尚、ブート本体処理は、無限ループでイベントを待ち、イベント発生したら、発生したイベントに応じた処理を行うものであり、例えばデータ収集や通信等の処理や、ダウンロード処理を行うものである。
【００５７】
ブート本体処理の一例であるダウンロード処理は、以下の（ａ）、（ｂ）の何れかの場合に実行される。
（ａ）一度もオペレーションファームウェアをダウンロードしていない場合において、上記上位機１からのダウンロード指示を受けた場合
（ｂ）二重化したオペレーションファームウェアが両方とも壊れている場合
ここで、図４に示す“ブート本体処理”は図示のステップＳ１２がＹＥＳの場合に実行されるものであり、これは上記（ｂ）の場合に相当するものであり、よって上記の通り図４に示す“ブート本体処理”はダウンロード処理を意味することになる。尚、同様の理由により、図７に示すステップＳ６０の後の“ブート本体処理”も、ダウンロード処理を意味することになる。そして、上記の通り、本例におけるダウンロード処理は例えば後述する図１０に示す処理となる。
【００５８】
また、起動処理とは、基本的にはカレント側のオペレーションファームウェアを起動して処理実行させるものである。これは、外部フラッシュＲＯＭ１４に記憶したオペレーションファームウェアを、ＳＤＲＡＭ１５に転送した後、処理実行させるものである。起動したオペレーションファームウェアの処理については、図８、図９に示し、後に説明する。
【００５９】
但し、カレント側のオペレーションファームウェアに破損等がある場合には、破損情報を破損ブロック番号３４に記憶すると共に、カレント側ではない（上記の通り非カレント側と呼ぶ）オペレーションファームウェアをカレント側に切り替えて処理実行させる。また、オペレーションファームウェアが両方とも破損している場合には、破損情報を破損ブロック番号３４に記憶すると共に、リブートして、上記リカバリ処理を実行して、破損箇所のリカバリを行う。上記起動処理の詳細は図５、リカバリ処理の詳細は図６、図７に示し、後に説明する。
【００６０】
以下、まず、図４のメイン処理について説明する。
図４の処理では、まず、ハードウェア及びブートファームウェアの各種初期化を行う（ステップＳ１１）。
【００６１】
そして、動作ステータス３１を参照して、その内容に応じて、上記ブート本体処理、起動処理、リカバリ処理の何れかを実行する。
すなわち、動作ステータス３１が“停止中(2)”の場合は（ステップＳ１２，ＹＥＳ）、二重化したオペレーションファームウェアが共に破損し、且つ、リカバリ不可能な状態であることを示しているため、オペレーションファームウェアの起動は行わず、ブート本体処理に遷移する。
【００６２】
尚、既に述べた通り、ブート本体処理とは、ダウンロード処理を含むブートファームウェアが本来行う処理であるが、本説明ではダウンロード処理のみ規定するものとする。上記の通り、ダウンロード処理については詳細は図１０に示し、後に説明する。
【００６３】
また、動作ステータス３１が“リカバリ中(1)”の場合は（ステップＳ１３，ＹＥＳ）、リカバリ処理へ遷移する。このリカバリ処理の詳細は図６、図７に示し、後に説明する。
【００６４】
また、動作ステータス３１が“運用中(0)”の場合は（ステップＳ１４，ＹＥＳ）、起動処理へ遷移する。この起動処理の詳細は図５に示し、後に説明する。
動作ステータス３１が“0〜2以外”の場合は（ステップＳ１２，Ｓ１３，Ｓ１４が何れもＮＯ）、管理情報格納領域２１が破損していると見なして、管理情報格納領域２１をゼロクリア（対象領域のビット値を“０”で全て埋めることを意味し、後述の説明の“ビットＯＦＦ”と“０”とは同値を指す）すると共に（ステップＳ１５）、各ＦＷ格納領域２２それぞれのヘッダ部４０を参照することで、二重化したオペレーションファームウェアのうち、バージョン４２が新しい方をカレント(ブート対象)として、その格納領域番号をＦＷ格納領域番号３３に設定して（上記の通り本例では１：ＦＷ格納領域ａ、２：ＦＷ格納領域ｂであり、‘１’‘２’のどちらかを設定する）（ステップＳ１６）、起動処理へ遷移する。
【００６５】
図５に、ブートファームウェアの上記起動処理のフローチャート図を示す。
図示の例では、まず、管理情報格納領域２１におけるカレントＦＷ格納領域番号３３を参照して現在のカレント側のオペレーションファームウェアを認識し、このカレント側のオペレーションファームウェアのＦＷ格納領域２２のヘッダ部４０が破損しているか否かをチェックする。これは、このヘッダ部４０のＳＵＭを計算し、算出したＳＵＭがヘッダＳＵＭ４６と一致するかをチェックする（ステップＳ２１）。
【００６６】
上記ＳＵＭが一致する場合は（ステップＳ２２，ＹＥＳ）、ヘッダ部４０は破損等していないことになり（正常であり）、ステップＳ２３以降の処理に遷移する。一方、上記ＳＵＭが一致しない場合には（ステップＳ２２，ＮＯ）、ヘッダ部４０が破損していることを示しているため、ステップＳ２９以降の処理に遷移する。
【００６７】
ステップＳ２３〜Ｓ２７の処理は、概略的には、オペレーションファームウェア本体（プログラム部５０）をブロック単位で、ＳＤＲＡＭ１５のＦＷブート領域６１に順次転送し、転送する毎に対応するプログラムブロックＳＵＭ４５を用いた破損（異常）チェックを行う処理である。上記転送とＳＵＭチェックを全ブロックについて完了するまで繰り返し行う。
【００６８】
すなわち、まず、プログラム部５０における１つのプログラムブロック５１をＦＷブート領域６１に転送し、このプログラムブロック５１のＳＵＭを計算する（ステップＳ２３）。そして、算出したＳＵＭがこのプログラムブロック５１に対応するプログラムブロックＳＵＭ４５と一致するか否かを判定し、一致する場合には（ステップＳ２４，ＹＥＳ）このプログラムブロック５１は破損していないことになるので、そのままステップＳ２７
の処理へ移行する。そして、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ２７，ＮＯ）、ステップＳ２３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【００６９】
一方、算出したＳＵＭと対応するプログラムブロックＳＵＭ４５とが不一致の場合には（ステップＳ２４,ＮＯ）、つまりこのプログラムブロック５１が破損している場合には、処理対象がカレント側の場合のみ（ステップＳ２５，ＹＥＳ）、当該破損したプログラムブロック５１の番号を内部変数Ａのビットに割当てて記憶する（ステップＳ２６）。
【００７０】
尚、上記ステップＳ２５の判定を行うのは、本説明で用いる一例では破損ブロック番号３４はカレント側にのみ対応する情報だからである。非カレント側についてはその一部に破損があっても破損ブロック情報は残さない。カレント側については破損ブロック番号３４に基づいて、破損したプログラムブロック５１のみリカバリを行う。よって、プログラム全体をリカバリする場合に比べて、リカバリ処理時間が短くて済む。一方、非カレント側に破損があった場合、後に説明する“オペレーション”の処理により（このときカレント側は破損があっても既にリカバリ済み）、カレント側のプログラム本体全体を非カレント側にコピーすることで、非カレント側もリカバリできる。
【００７１】
但し、既に述べた通り、これは一例であり、この例に限らない。例えば、破損ブロック番号３４を、カレント側対応と非カレント側対応との２種類用意し、これに応じて内部変数に関しても上記内部変数Ａに加えて更に非カレント側に対応する内部変数（仮に、内部変数Ｂとする）も用意するようにしてもよい。この例では、上記ステップＳ２５の判定がＮＯの場合には、内部変数Ｂを用いてステップＳ２６と同様の処理を行うことになる。また、後述するステップＳ３２、Ｓ３５の処理では、内部変数Ａ，Ｂの値をそれぞれ上記２種類の破損ブロック番号３４のどちらかにコピーすることになる。また、この例の場合、後述する各種処理のうち破損ブロック番号３４を用いる処理が、本例とは多少異なることになるが、これについては特に説明しない。
【００７２】
尚、内部変数Ａ、Ｂとは、破損ブロック番号３４と同じデータ構造の内部変数であり、上記の通り、“ビットＯＮ：破損あり”、“ビットＯＦＦ：破損なし”を意味しており、全てのビットは領域確保時に初期化（ビットＯＦＦ）しておく。そして、ステップＳ２６において、破損したプログラムブロック５１に対応するビットをビットＯＮする。尚、後述するように後にこの内部変数Ａにより破損ブロック番号３４を更新する。勿論、この例に限らず、例えば内部変数を用いることなく直接、破損ブロック番号３４を更新するようにしてもよい。
【００７３】
そして、上記ステップＳ２７の処理を行う。
全てのプログラムブロック５１について上記の処理を行ったら（ステップＳ２７，ＹＥＳ）、プログラムブロックＳＵＭ４５が全て正常であったか（破損していないか）否かを判定し（ステップＳ２８）、全て正常であった場合には、すなわち破損しているプログラムブロック５１が１つも無い場合には（ステップＳ２８，ＹＥＳ）、ステップＳ３２〜Ｓ３４の処理を実行し、ＦＷブート領域６１に転送済みのオペレーションファームウェアを起動する。
【００７４】
一方、破損しているプログラムブロック５１が１つでもある場合（ステップＳ２８，ＮＯ）、またはヘッダ部４０が破損している場合には（ステップＳ２２，ＮＯ）、二重化したオペレーションファームウェアの内、少なくとも1つが破損していること(バックアップなし)を示しているため、管理情報格納領域２１のバックアップステータス３２をバックアップなし(0)に設定する（ステップＳ２９）。
【００７５】
次に、非カレント(バックアップ)領域のチェックも実施済みか否かを判定し（ステップＳ３０）、未実施の場合には（ステップＳ３０，ＮＯ）、非カレント側のオペレーションファームウェアに関して、上記カレント側と同様のチェック処理を行う。すなわち、非カレント側（バックアップ側）のオペレーションファームウェアのＦＷ格納領域２２のヘッダ部４０、プログラム部５０が破損しているか否かを、上記ステップＳ２２〜Ｓ２８の処理によりチェックする。尚、ステップＳ３１の処理の前に、ＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送したプログラムブロック５１は全て削除する。
【００７６】
ステップＳ３１以降の処理では、非カレント側のオペレーションファームウェアのＦＷ格納領域２２を参照して、そのヘッダ部４０、プログラム本体（各プログラムブロック５１）に関するチェックを行うことになる。この際、チェック実行の有無を、例えばビット値で記憶しておき、ステップ３Ｓ０の処理では、この値に基いてチェックの有無を判定する。
【００７７】
すなわち、まず、上記非カレント側のオペレーションファームウェアのＦＷ格納領域２２におけるヘッダ部４０のＳＵＭを計算する（ステップＳ３１）。そして、ステップＳ２２の処理に戻り、まず、上記ステップＳ３１で算出したＳＵＭがヘッダＳＵＭ４６と一致するか否かによりヘッダ部４０が破損しているか否かを判定する（ステップＳ２２）。そして、ヘッダ部４０が破損していない場合には（ステップＳ２２，ＹＥＳ）、今度はプログラム５０について上記カレント側の場合と同様にして各プログラムブロック５１毎に破損しているか否かを判定する（ステップＳ２３〜Ｓ２７）。尚、既に述べた通り、もし破損しているプログラムブロック５１が存在しても、今度は上記ステップＳ２５の判定はＮＯとなるので、ステップＳ２６の処理（内部変数Ａに反映させる処理）は行われない。
【００７８】
そして、非カレント側のオペレーションファームウェアに関して、ヘッダ部４０及びプログラム部５０に破損が無かった場合には（ステップＳ２８，ＹＥＳ）、ステップＳ３２〜Ｓ３４の処理を行う。
【００７９】
一方、非カレント側のオペレーションファームウェアに関しても、ヘッダ部４０またはプログラム部５０に破損がある場合には（ステップＳ２２，ＮＯ；またはステップＳ２８，ＮＯ）、再び上記ステップＳ３０の判定を行うことになり、今度は判定ＹＥＳとなり、ステップＳ３５，Ｓ３６の処理を実行し、その後リブートを行う。つまり二重化されたオペレーションファームウェアの両方とも破損がある場合には、ステップＳ３５，Ｓ３６の処理を実行し、その後、後述するリカバリ処理を実行することになる。
【００８０】
上記ステップＳ３２〜Ｓ３４の処理について説明する。
これらの処理は、カレント側についてステップＳ２８の判定がＹＥＳの場合、またはカレント側に破損があり且つ非カレント側についてステップＳ２８の判定がＹＥＳの場合に、実行させることになる。また、これらの処理が実行される場合には、二重化したオペレーションファームウェアのうち、少なくともどちらか一方は正常な状態（破損していない）であり、正常なものがＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送されている状態である。
【００８１】
この状態において、まず、上記内部変数Ａを破損ブロック番号３４にコピーすることで、破損ブロック番号３４を更新する（ステップＳ３２）。カレント側についてステップＳ２８の判定がＹＥＳの場合については、内部変数Ａは初期状態のまま（全てのビットがＯＦＦ）であるので、更新後の破損ブロック番号３４の内容も、全てのビットがＯＦＦとなる。つまり、カレント側のプログラム本体については破損無しを示す内容となる。
【００８２】
一方、非カレント側についてステップＳ２８の判定がＹＥＳの場合については、もしカ
レント側の破損がヘッダ部４０の破損では無かったならば、更新後の破損ブロック番号３４の内容は、カレント側における破損したプログラムブロックを示すものとなる。
【００８３】
次に、カレントＦＷ格納領域番号３３に、上記ＳＤＲＡＭ１５（そのＦＷブート領域６１）に正常転送されたオペレーションファームウェアの番号を設定する（ステップＳ３３）。カレント側についてステップＳ２８の判定がＹＥＳの場合には、カレント側のオペレーションファームウェアの番号が設定されることになる。一方、非カレント側についてステップＳ２８の判定がＹＥＳの場合には、非カレント側のオペレーションファームウェアの番号が設定されることになる。これは、非カレント側がカレント側（ブート対象）に切り替わることを意味する。
【００８４】
そして、ＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送済みのオペレーションファームウェアを起動する（ステップＳ３４）。これによって“オペレーション”が実行される。“オペレーション”の処理内容については、後に図８、図９を参照して説明する。
【００８５】
次に、上記ステップＳ３５〜Ｓ３６の処理について説明する。
この場合、二重化したオペレーションファームウェアの両方が破損しているため、破損ブロック番号３４と動作ステータス３１を設定して、装置をリブートする。
【００８６】
すなわち、まず、上記ステップＳ３２と同様の処理を行う。すなわち上記内部変数Ａの内容を破損ブロック番号３４にコピーすることで、破損ブロック番号３４を更新する（ステップＳ３５）。次に、動作ステータス３１をリカバリ中（１）に設定する。そして、リブートする。これにより、上記ブートファームウェアのメイン処理に遷移する。動作ステータス３１をリカバリ中（１）に設定してあることから、このメイン処理において上記ステップＳ１３の判定がＹＥＳとなるので、リカバリ処理を実行することになる。
【００８７】
図６、図７は、ブートファームウェアのリカバリ処理のフローチャート図である。
尚、これは、リカバリ処理を２つの図面に渡って示しているものである。
上記の通り、本処理は、二重化したオペレーションファームウェアが両方共破損している状態で行われる。但し、オペレーションファームウェア全体が破損しているとは限らず、むしろ一部のみ破損している可能性が高い。
【００８８】
まず、上記ステップＳ２１，２２と同様の処理を、二重化したオペレーションファームウェア両方に対して行う（ステップＳ４１）。すなわち、二重化したオペレーションファームウェア各々のヘッダ部４０に関して、そのヘッダＳＵＭ４６を用いたチェックをそれぞれ行い、ヘッダ部４０の整合性を確認する。すなわち、ヘッダ部４０のＳＵＭを算出し、算出したＳＵＭ値がヘッダＳＵＭ４６と一致するか否かにより、ヘッダ部４０の正常／異常を判定する。
【００８９】
そして、二重化したオペレーションファームウェアの両方でヘッダ部４０が正常（破損なし）の場合には（ステップＳ４２，ＹＥＳ）、プログラムブロック５１に異常（破損）があることになるので、ステップＳ４７の処理へ移行する。
【００９０】
また、どちらか一方は正常であるが他方は異常である場合には（ステップＳ４２，ＮＯ且つステップＳ４３，ＹＥＳ）、ステップＳ４４の処理へ移行する。
両方ともヘッダ部４０が異常な場合は（ステップＳ４２，ＮＯ且つステップＳ４３，ＮＯ）、リカバリするための情報が得られないため、リカバリ不能とする。すなわち、動作ステータス３１を停止中（２）に設定し（ステップＳ６０）、本処理を終了する。そして、ブート本体処理（図１０のダウンロード指示を待つ状態）に遷移する。
【００９１】
尚、既に述べた通り、ブート本体処理は、ダウンロード処理を含むブートファームウェアが本来行う処理であるが、本説明では、ダウンロード処理のみ規定する。
以下、まず、ステップＳ４４以降の処理について説明する。
【００９２】
すなわち、上記のチェック処理により何れか一方のヘッダ部４０が正常（破損していない）で他方が異常（破損している）と判定された場合は、二重化したオペレーションファームウェアのプログラム部５０同士を比較する（ステップＳ４４）。その結果、同一のプログラムであることが確認された場合は（ステップＳ４５，ＹＥＳ）、破損していないヘッダ部４０を用いて破損しているヘッダ部４０をリカバリする。すなわち、破損していない領域のヘッダ部４０の情報を、破損しているヘッダ部４０の領域にコピーする（ステップＳ４６）。そして、ステップＳ５３の処理へ移行する。
【００９３】
一方、上記ステップＳ４４の比較の結果、プログラム部５０が不一致の場合には（ステップＳ４５，ＮＯ）、相互に異なるオペレーションファームウェアが記憶されていることを示している。例えば一方が新バージョンで他方が旧バージョンの場合等である。よって、この場合、ヘッダ部４０の情報も異なるものであり、破損していないヘッダ部４０を用いて破損しているヘッダ部４０をリカバリすることは出来ないので、リカバリ不能とする。つまり、上記ステップＳ６０の処理を実行し、本処理は終了する。
【００９４】
尚、上記ステップＳ４５や後述するステップＳ４８の処理の主旨は、相互に異なるオペレーションファームウェアが記憶されているか否かを判定するものであるので、例えば「名称４１及びバージョン４２が一致するか？」という判定処理に置き換えてもよい。
【００９５】
また、本例ではステップＳ４６の処理からステップＳ５３の処理に移行したが、これは一例であり、例えばステップＳ４６の処理からステップＳ４７の処理に移行するようにしてもよい。あるいは、ステップＳ４６の処理後に例えば「破損ブロック番号３４有り？(破損しているプログラムブロック５１があるか否かを判定するもの)」を追加し、この判定がＮＯの場合にはステップＳ５３の処理に移行し、判定ＹＥＳの場合にはステップＳ４７の処理に移行するようにしてもよい。何れにしても、図示のフローチャートは一つの例を示しているのであり、この例に限るものではない。
【００９６】
次に、以下、ステップＳ４７以降の処理について説明する。
上記の通り、二重化したオペレーションファームウェアの両方ともヘッダ部４０が正常な場合（破損していない）、ステップＳ４７へ移行し、ステップＳ４７〜Ｓ５２の処理を実行する。
【００９７】
まず、二重化したオペレーションファームウェアのヘッダ部４０同士を比較して（ステップＳ４７）、一致するか否かを判定する（ステップＳ４８）。
ヘッダ部４０が不一致の場合は（ステップＳ４８，ＮＯ）、相互に異なるオペレーションファームウェアが記憶されていることを示している。この場合、リカバリに必要なプログラムブロック５１が存在しないため、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【００９８】
一方、ヘッダ部４０が同じ場合には（ステップＳ４８，ＹＥＳ）、まず、カレントＦＷ格納領域番号３３と破損ブロック番号３４を参照する。これより、二重化したオペレーションファームウェアのどちらがカレント側でどちらが非カレント側であるかを認識でき、またカレント側においてどのプログラムブロック５１が破損しているかを認識できる。尚、破損ブロック番号３４は、上記図５の処理（起動処理）のステップＳ３５で設定した内容となっている。
【００９９】
そして、上記カレント側のリカバリを試みる。つまり、カレント側において破損しているプログラムブロック５１について、１つずつ、ステップＳ４９〜Ｓ５１の処理を実行し、全ての破損プログラムブロック５１についてリカバリ処理完了したら（ステップＳ５２，ＹＥＳ）、ステップＳ５３以降の処理に移る。但し、１つでもリカバリ不能な破損プログラムブロック５１があった場合（ステップＳ５０，ＮＯ）、上記ステップＳ６０の処理を実行することになる。
【０１００】
ステップＳ４９〜Ｓ５１の処理では、まず、処理対象の破損プログラムブロック５１について、非カレント側において同じプログラムブロック５１が破損していないか否かをチェックする（ステップＳ４９、Ｓ５０）。すなわち、非カレント側における上記処理対象の破損プログラムブロック５１と同じプログラムブロック５１のＳＵＭを計算し（ステップＳ４９）、このプログラムブロック５１に対応するプログラムブロックＳＵＭ４５と計算したＳＵＭとが一致するか否かを判定する（ステップＳ５０）。
【０１０１】
そして、ＳＵＭ不一致の場合、すなわち処理対象のプログラムブロック５１に関しては二重化したオペレーションファームウェアの両方とも破損している場合には（ステップＳ５０，ＮＯ）、リカバリ不能となる。よって、上記ステップＳ６０の処理を実行し、本処理は終了する（ダウンロード処理を行うことになる）。
【０１０２】
一方、ＳＵＭ一致の場合、すなわち処理対象のプログラムブロック５１に関して非カレント側のオペレーションファームウェアでは破損していない場合には（ステップＳ５０，ＹＥＳ）、非カレント側のオペレーションファームウェアの当該プログラムブロック５１を、カレント側のプログラムブロック５１の領域にコピーすることで、カレント側のプログラムブロック５１をリカバリする（ステップＳ５１）。
【０１０３】
例えば、図２（ｃ）の例において、カレント側のプログラムブロックｎが破損しており、非カレント側のプログラムブロックｎは破損していない場合には、非カレント側のプログラムブロックｎを、カレント側のプログラムブロックｎの領域にコピーすることになる。
【０１０４】
そして、カレント領域において破損している全てのプログラムブロック５１について上記処理を実行したか否かを判定し（ステップＳ５２）、未だ未処理のものがある場合には（ステップＳ５２，ＮＯ）、上記ステップＳ４９に戻り、次の処理対象の破損プログラムブロックについて、上記と同様の処理を行う。
【０１０５】
そして、カレント領域において破損している全てのプログラムブロック５１について上記処理を実行した場合（ステップＳ５２，ＹＥＳ）、これは途中でステップＳ５０の判定がＮＯとなることなく全ての破損プログラムブロック５１のリカバリを行えたことになり、ステップＳ５３の処理へ移行する。
【０１０６】
以上の処理により、ステップＳ５３以降の処理を行う場合には、少なくともカレント側のオペレーションファームウェアに関してはリカバリ完了していることになる。
以下、ステップＳ５３以降の処理について説明する。
【０１０７】
ステップＳ５３以降の処理は、上記リカバリが成功した場合の処理であり、よって基本的には、カレント領域のオペレーションファームウェアをＳＤＲＡＭ１５のＦＷブート領域６１に転送して起動し、オペレーション実行開始させるものであるが、念の為に再度ＳＵＭチェックを行っている。
【０１０８】
まず、カレント側のオペレーションファームウェアのプログラム部５０をブロック単位
でＳＤＲＡＭ１５のＦＷブート領域６１に転送する毎に、そのＳＵＭチェックを行う。すなわち、カレント側のオペレーションファームウェアのプログラム部５０の任意のプログラムブロック５１を、ＳＤＲＡＭ１５のＦＷブート領域６１に転送し、この転送したプログラムブロック５１のＳＵＭを算出する（ステップＳ５３）。そして、この転送したプログラムブロック５１に対応するプログラムブロックＳＵＭ４５が、ステップＳ５３で算出したＳＵＭと一致するか否か、すなわちこの転送したプログラムブロック５１が破損していないかをチェックする（ステップＳ５４）。これを、プログラム部５０の全てのプログラムブロック５１について実行し、全ブロックが処理完了したら（ステップＳ５５，ＹＥＳ）、ステップＳ５６の処理に移行する。一方、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ５５，ＮＯ）、ステップＳ５３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【０１０９】
但し、（通常起こりえないが）もし１つでも破損しているプログラムブロック５１があった場合には（ステップＳ５４，ＮＯ）、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【０１１０】
また、ステップＳ５６でも、最後に確認的に、全てのプログラムブロック５１が正常であったかを確認し（ステップＳ５６）、もし１つでも破損しているプログラムブロック５１があった場合には（ステップＳ５６，ＮＯ）、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【０１１１】
ステップＳ５６の判定がＹＥＳであれば、バックアップステータス３２をバックアップあり（１）に設定すると共に（ステップＳ５７）、動作ステータス３１を運用中（０）に設定する（ステップＳ５８）。そして、ＦＷブート領域６１に転送済みの（正常な）オペレーションファームウェアを起動する（ステップＳ５９）。
【０１１２】
図８、図９に、“オペレーション”の処理、すなわち起動されたオペレーションファームウェアの処理フローチャートを示す。
尚、これは、オペレーションファームウェアの処理を２つの図面に分けて示しているものである。
【０１１３】
また、上記の通り、この処理が実行されるのは、ステップＳ３４で起動されるケースと、ステップＳ５９で起動されるケースとがある。
図示の処理では、まず、必要に応じて、ハードウェア及びオペレーションファームウェアの各種初期化を行う（ステップＳ７１）。
【０１１４】
そして、バックアップステータス３２を参照して、“バックアップあり（１）”の場合には（ステップＳ７２、ＮＯ）、ステップＳ７３以降の処理を行うことなく、オペレーション本体処理（オペレーションファームウェアの本来の処理）へ移行する。すなわち、この場合には、非カレント側も正常な状態となっているはずであるので、非カレント側のリカバリ処理は必要ないので、そのまま本来の処理を実行開始すればよい。
【０１１５】
ここで、上記オペレーション本体処理とは、組込み機器として必要な機能を実行するものであり、通常、無限ループでイベントを待ち、発生したイベントに応じた処理を行うものである。具体的には、例えば、データ収集処理、通信処理、制御対象機器の制御処理（例えばファンの速度を制御する等）であり、更にダウンロード処理等も含まれる。ダウンロード処理は、上記イベントとして上述した上位機１からのダウンロード指示があった場合に実行されるものであり、本例では図１０に示すダウンロード処理を実行するものである。上記オペレーション本体処理の１つとして実行されるダウンロード処理は、オペレーションファームウェアを更新する場合に実行するものである。
【０１１６】
一方、“バックアップなし（０）”の場合は（ステップＳ７２，ＹＥＳ）、本来の処理を行う前に、ステップＳ７３以降の処理を実行するものとし、まず、カレントＦＷ格納領域番号３３を参照して非カレント側を認識し、非カレント側のオペレーションファームウェアのヘッダ部４０のＳＵＭを計算し（ステップＳ７３）、そのヘッダＳＵＭ４６によりヘッダ部４０の正常／異常（破損有無）チェックする（ステップＳ７４）。つまり、算出したＳＵＭがヘッダＳＵＭ４６と一致するか否かをチェックする。
【０１１７】
一致する場合には（ステップＳ７４，ＹＥＳ）ステップＳ７８の処理へ移行する。
一方、算出したＳＵＭがヘッダＳＵＭ４６と不一致の場合には、非カレント側のヘッダ部４０が破損していることを示しており（ステップＳ７４，ＮＯ）、リカバリを試みる。但し、その前に、ヘッダ部４０のみが破損しているかどうかを調べるために、二重化したオペレーションファームウェアのプログラム部５０同士を比較し（ステップＳ７５）、プログラム部５０が一致するか否かをチェックする（ステップＳ７６）。一致する場合には（ステップＳ７６，ＹＥＳ）、カレント領域のヘッダ部４０を、非カレント側のヘッダ部４０の領域にコピーすることで（ステップＳ７７）、非カレント領域のヘッダ部４０をリカバリする。
【０１１８】
これによって、非カレント側のリカバリは完了するので、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
ステップＳ８３では、バックアップステータス３２を“バックアップあり（１）”に設定する。ステップＳ８４では破損ブロック番号３４をゼロクリアする。
【０１１９】
一方、一致しない場合には（ステップＳ７６，ＮＯ）、カレント領域のオペレーションファームウェア全体を、非カレント側の領域にコピーする（ステップＳ８２）。これによって、非カレント側のリカバリは完了するので、上記と同様、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
【０１２０】
また、上記ステップＳ７４の判定がＹＥＳの場合には、まず、二重化したオペレーションファームウェアのヘッダ部４０同士を比較して（ステップＳ７８）、ヘッダ部４０が一致するか否かを判定する（ステップＳ７９）。ヘッダ部不一致の場合には（ステップＳ７９，ＮＯ）、非カレント領域に、カレント側とは異なるファームウェア（例えば旧バージョン等）が記憶されていることになるので、オペレーションファームウェア全体をバックアップする。すなわち、上記ステップＳ８２の処理を実行する。
【０１２１】
一方、ヘッダ部一致の場合は（ステップＳ７９，ＹＥＳ）、二重化したオペレーションファームウェアは同一（同じバージョン等）であり、破損ブロック番号３４が記憶されている場合には（ステップＳ８０，ＹＥＳ）、破損ブロック番号３４を参照して、非カレント側において破損しているプログラムブロック５１のみを、カレント側の該当するプログラムブロック５１を用いてリカバリする。
【０１２２】
すなわち、破損ブロック番号３４を参照することで、非カレント領域において破損しているプログラムブロック５１の番号を認識し、カレント領域における当該番号のプログラムブロック５１を、非カレント側における同じ番号のプログラムブロック５１の領域にコピーする（ステップＳ８１）。
【０１２３】
尚、上記ステップＳ８０の“破損ブロック番号３４が記憶されている場合”とは、破損ブロック番号３４において全てのビットがＯＦＦとなっている状態以外の場合、すなわち１つでもビットがＯＮになっている場合を意味する。これは、例えば、図５においてステップＳ２６の処理が実行され（よってそのときのカレント側についてはステップＳ２８の
判定はＮＯとなる）、且つそのときの非カレント側についてはステップＳ２８の判定がＹＥＳとなった場合等である。
【０１２４】
尚、“そのときの”と言っているのは、この場合、ステップＳ３３の処理によって、“そのときの”非カレント側がカレント側に設定されているからである。つまり、例えば仮に図５の処理の際にはＦＷ格納領域ａがカレント側、ＦＷ格納領域ｂが非カレント側であったとした場合、上記のケースではステップＳ３３によりＦＷ格納領域ｂがカレント側に設定されるので、本処理においては上記ステップＳ７３においてＦＷ格納領域ａが非カレント側として認識されることになる。よって、この場合には、破損ブロック番号３４は、“そのときの”カレント側であるＦＷ格納領域ａに関する破損情報であるが、本処理においてはＦＷ格納領域ａは非カレント側と認識されることになる。よって、この例では上記ステップＳ８１の処理は、ＦＷ格納領域ｂのプログラムブロック５１を用いて、ＦＷ格納領域ａの破損プログラムブロック５１をリカバリすることになる。
【０１２５】
上記ステップＳ８１の処理により、非カレント側のリカバリは完了するので、上記と同様、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
【０１２６】
一方、破損ブロック番号３４が記憶されていない場合には(ステップＳ８０，ＮＯ)、上記ヘッダ部不一致の場合と同様に、ステップＳ８２の処理を実行し、オペレーションファームウェア全体をバックアップする。尚、ステップＳ８０がＮＯとなる場合とは、例えば上記ステップＳ２６の処理が行われなかった場合等であり、すなわち破損ブロック番号３４において全てのビットがＯＦＦとなっている状態（初期状態）である。
【０１２７】
図１０に、ダウンロード処理のフローチャート図を示す。
ダウンロード処理は、例えばブートファームウェアやオペレーションファームウェアの本体処理中に含まれる処理であり（本体処理としての様々な処理のうちの１つであり；既に説明済みであるので、ここでの説明は省略する）、上位機１からダウンロード指示を受けると処理を開始する。尚、上位機１はＦＷダウンロード領域６２にオペレーションファームウェアを転送・格納した後、上記ダウンロード指示を出す。本手法では、再度のダウンロードが必要な状況において（二重化されたオペレーションファームウェアの両方が破損し且つリカバリ不能の場合）、従来のように人手を介することなく自動的に、ダウンロードが行われる。
【０１２８】
尚、ステップＳ１２がＹＥＳの場合またはステップＳ６０の後における“ブート本体処理”としてのダウンロード処理は、上位機１からのダウンロード指示が無くても直ちに、当該図１０のダウンロード処理を実行するようにしてもよい。
【０１２９】
あるいは、ステップＳ１２がＹＥＳの場合またはステップＳ６０の後における“ブート本体処理”としてのダウンロード処理は、まず最初に、上位機１に対してＦＷダウンロード領域６２にオペレーションファームウェアを転送・格納する処理を要求するようにしてもよい。この場合、上位機１は、オペレーションファームウェアを転送後、上記ダウンロード指示を出すことになり、これによって図１０のダウンロード処理を開始することになる。
【０１３０】
図１０の処理は、概略的には、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に転送・格納されたオペレーションファームウェアについて、所定のチェック処理を実行し、チェックＯＫであれば、このオペレーションファームウェアを外部フラッシュＲＯＭ１４にダウンロードすると共に、これを新たなカレント側のオペレーションファームウェアとするものである。
【０１３１】
図１０の処理では、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されたオペレーションファームウェアについて、ステップＳ９１〜Ｓ９５の所定のチェック処理を行う。このステップＳ９１，Ｓ９２，Ｓ９３，Ｓ９４，Ｓ９５の処理におけるチェックに関する処理自体は、上記ステップＳ２１，Ｓ２２，Ｓ２３，Ｓ２４，Ｓ２７と略同様の処理である。
【０１３２】
すなわち、まず、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されたオペレーションファームウェアのヘッダ部４０が正常か否か（破損していないか）を判定する為、このヘッダ部４０のＳＵＭを算出し（ステップＳ９１）、算出したＳＵＭが当該ヘッダ部４０のヘッダＳＵＭ４６と一致するか否かを判定する（ステップＳ９２）。不一致の場合には（ステップＳ９２，ＮＯ）、転送・格納されたオペレーションファームウェアを外部フラッシュＲＯＭ１４に書込むことはなく（ダウンロードすることなく）、そのヘッダ部４０が破損している旨を、上位機１へ通知する（ステップＳ１００）。
【０１３３】
一方、一致する場合、すなわちヘッダ部４０に異常がない場合には（ステップＳ９２，ＹＥＳ）、続いて、プログラム部５０についても正常か否か（破損していないか）を判定する。これは、プログラム部５０の各プログラムブロック５１毎に行う。すなわち、各プログラムブロック５１毎に、そのプログラムブロック５１のＳＵＭを算出し（ステップＳ９３）、算出したＳＵＭ値がそのプログラムブロック５１に対応するプログラムブロックＳＵＭ４５の値と一致するか否かを判定する（ステップＳ９４）。一致する場合はそのプログラムブロック５１は正常である（破損していない）ことになる（ステップＳ９４，ＹＥＳ）。そして、全てのプログラムブロック５１について上記チェックを完了したら（ステップＳ９５，ＹＥＳ）、ステップＳ９６の処理へ移行する。
【０１３４】
もし、１つでも破損しているプログラムブロック５１があった場合には（ステップＳ９４，ＮＯ）、ダウンロードされたオペレーションファームウェアを外部フラッシュＲＯＭ１４に書込むことはなく、そのプログラム部５０が破損している旨を、上位機１へ通知する（ステップＳ１００）。
【０１３５】
一方、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ９５，ＮＯ）、ステップＳ９３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【０１３６】
ステップＳ９６以降の処理では、まずバックアップステータス３２を“バックアップなし（0）”に設定してから（ステップＳ９６）、カレントＦＷ格納領域番号３３を参照して上記外部フラッシュＲＯＭ１４における非カレント領域を認識し、この非カレント領域に、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されているオペレーションファームウェア全体をダウンロードする（ステップＳ９７）。
【０１３７】
ダウンロード完了したら、カレントＦＷ格納領域番号３３にダウンロードした領域の番号を設定する（ステップＳ９８）。つまり、上記非カレント領域をカレント領域とする。そして、動作ステータス３１を“運用中（0）”に設定する（ステップＳ９９）。
【０１３８】
そして、ダウンロード処理の結果を上位機１に通知する（ステップＳ１００）。
その後、図４の処理が実行されると、上記起動処理が実行され、上記ダウンロードされたオペレーションファームウェアがカレント側としてチェック処理を受けて、正常であれば（上記の通り、ダウンロード時にチェックを行っているので正常のはずであるが）、非カレント側が異常であるか否かに関わらず、非カレント領域にも上記ダウンロードされたオペレーションファームウェアが記憶されることになり、バックアップステータス３２を“バックアップあり（１）”の状態になることになる。
【０１３９】
なお、ブートファームウェアでオペレーションファームウェアをバックアップ(二重化)しない理由は、正当なＳＵＭを持っているものの、起動後、直ちにシステムダウンしてしまうような誤ったプログラムがダウンロードされた場合を考慮しているからである。つまり、この様な場合、ブートファームウェアが上記ダウンロード処理の際にオペレーションファームウェアをバックアップ(二重化)すると、上記誤ったプログラムが二重化されることになり、機器が起動しなくなってしまうからである。
【０１４０】
本手法では、この様な事態を回避するために、ダウンロードされ正常動作したオペレーションファームウェアが、自身の二重化の為の処理を行うようにしている（特許文献１の作用等に記載あり）。もし、これが上記誤ったプログラムであった場合には、正常動作しないので、二重化が行われないことになり、機器が起動しなくなる事態を回避できる。
【０１４１】
以上説明したように、本手法によれば、以下の効果が得られる。
不揮発性メモリに二重化して記憶したファームウェアが両方とも破損した場合、従来の方法では、ファームウェアの破損状態に関わらず、装置を起動できない事態が発生してしまっていたが、本手法によりこの様な状態に陥る可能性を大幅に低減すことができる。
【０１４２】
組込み機器は必ず装置を起動することが重要であるが、リソースとの兼ね合いもあり、二重化を三重化にするといった対策は現実的には難しいため、二重化において、装置が起動しない状態になる可能性を低減する効果は大きい。
【０１４３】
また、従来、二重化したファームウェアの一部が破損した場合でも、起動したファームウェアの全領域を複製するようにしていたが、本発明は、必要な領域(破損ブロック)のみを複製するため、リカバリに要する時間を短縮することができ、装置の起動時間への影響を微小にすることができる。
【０１４４】
尚、本手法と上記特許文献２の発明とを比較すると、両者は発想が全く逆である。つまり、まず、本手法ではプログラム（ファームウェア）を対象にしているのに対して、上記特許文献２ではデータを対象にしているという違いがあるが、ここでは特許文献２の実データは本手法のプログラム（ファームウェア）に相当するものと考えてもよいものとする。この場合、特許文献２における図７のメモリ構成は、本手法における従来技術のメモリ構成と似ていると考えることもできる。つまり、特許文献２における図７に示す例えばデータ１１Ａ１ｄが、本手法のプログラム（ファームウェア）に相当することになる。特許文献２における図７ではデータ１１Ａ１ｄ〜データ１１Ａｎｄのｎ個のデータが格納されているので、これはｎ個のプログラム（ファームウェア）が格納されていることに相当することになる。
【０１４５】
そして、特許文献２における図７に示すメモリ構成では、各データ毎にチェックサムデータが格納されており（例えばデータ１１Ａ１ｄに対してチェックサムデータ１１Ａ１ｃ）、チェックサムデータを用いてデータの異常チェックを行うが、この点も本手法における従来技術と似ている。
【０１４６】
しかしながら、特許文献２においてはデータは数バイト程度である為、データの一部に破損が生じた場合でも、そのデータ全体についてリカバリを行うことに特に問題はない（処理時間が掛かるものではない）。むしろ、上記従来技術で説明した通り、特許文献２の発明は、１つのブロックに複数のデータをまとめて、一部のデータに異常が生じた場合でもブロック内の全データについて修正を行うようにしている。これは、上記の通り各データのデータ量が非常に少ないので、この様にしても特に問題はない（処理時間が掛かるものではない）ものと考えられる。
【０１４７】
一方、本手法では、プログラム（ファームウェア）が対象であり、そのデータ量が大きい為、例えば上記数バイトから成るデータを例えば１バイト単位で分割・管理すること（１バイト単位で異常の有無の判定やリカバリを行うこと）に相当する事を行っている。この様な発想は特許文献２には無い（上記の通り、むしろ逆の発想となっている）。よって、当然、特許文献２に基づいて本手法を想到することはできないし、特許文献２の発明やその従来技術では本手法の効果は得られない。
【符号の説明】
【０１４８】
１ 上位機
１０ 組込み機器
１１ ＣＰＵ
１２ ＲＡＭ
１３ 内蔵フラッシュＲＯＭ
１４ 外部フラッシュＲＯＭ
１５ ＳＤＲＡＭ
２１ 管理情報格納領域
２２ ＦＷ格納領域
３１ 動作ステータス
３２ バックアップステータス
３３ カレントＦＷ格納領域番号
３４ 破損ブロック番号
４０ ヘッダ部
４１ 名称
４２ バージョン
４３ ヘッダサイズ
４４ プログラムサイズ
４５ プログラムブロックＳＵＭ
４６ ヘッダＳＵＭ
５０ プログラム部
５１ プログラムブロック
６１ ＦＷブート領域
６２ ＦＷダウンロード領域
【技術分野】
【０００１】
本発明は、組込み機器に搭載するファームウェアを保護する技術に関する。
【背景技術】
【０００２】
従来、組込み機器に搭載するファームウェアの保護方法として、ファームウェアを記憶する領域を二重化する方法が広く行われている。これは、不揮発性メモリの経年劣化やダウンロード中の電源断等により、一方のプログラム（ファームウェア）が破損してしまった場合でも、必ず機器を起動できるようにするためのものである。
【０００３】
特許文献１に記載の発明では、ファームウェアを記憶する領域を二重化して、一方の領域はダウンロード時に書換え、もう一方の領域は起動したファームウェアが自分自身を書換えることで、二重化を行っている。また、記憶したファームウェアの一方が破損した場合は、上記と同様に、起動したファームウェアが自分自身を複製して、ファームウェアを常に二重化した状態にしている。
【０００４】
また、特許文献２には、データ数の増減に関わらずチェックサムデータ量を減少させることができるデータ保護装置が提案されている。すなわち、従来では二重化されたメモリに記憶される各データ毎に、そのデータに対するチェックサムデータを生成・記憶しており、このチェックサムデータを用いて各データ毎の異常の有無をチェックしていた。この為、データ数の増大に伴って多量のチェックサムデータが必要となるという問題があった。
【０００５】
この問題を解決する為、特許文献２の発明では、各データが１つのブロックにまとめられた実データ群と、この実データ群について、個々の実データの総和をとった１つのチェックサムデータとから構成されるようにしている。これによりチェックサムデータ量を大幅に削減することができる。また、チェックサムデータを用いたチェック処理によって異常が検出された場合には、ブロック内の実データ群全てについて修正を行う。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平４−３３６６４２号公報
【特許文献２】特開２０００−１４８６０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来、不揮発性メモリに記憶したファームウェアが破損しているかどうかの判定は、ファームウェアに付加したＳＵＭ（チェックサム）等を用いて行われている。しかし、ＳＵＭはプログラム全体に対して計算したものであり、プログラムの全体ではなく一部が破損した場合においても不整合となってしまう。そのため、二重化したファームウェアの両方が同時に破損した場合、従来の方法では、ファームウェアの破損状態に関わらず、装置を起動することができなかった。但し、人手を介して、ファームウェアを再度ダウンロードすれば、装置を起動（リカバリ）することは可能である。しかしながら、この様な人手を介在する方法は、組込み機器としては望ましくなく、また人間に余計な手間を掛けさせることになる。
【０００８】
上記特許文献１の発明では、ファームウェアを常に二重化する方法が提案されているが、二重化したファームウェアが同時に破損するケースに関しては何等言及していない。
また、記憶したファームウェアの一方が破損した場合、ファームウェアの破損状態に関わらず（一部のみが破損した場合でも）、起動したファームウェアの全領域を複製しているため、装置の起動時間が大幅に遅くなるという課題がある。
【０００９】
本発明の課題は、二重化したファームウェアの一部が破損した場合に、破損した部分のみをリカバリすることでリカバリに要する時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消でき、更に二重化したファームウェアの両方が破損してしまった場合でもファームウェアをリカバリすることができ、装置を起動することを可能とするファームウェア保護装置、そのプログラム等を提供することである。
【課題を解決するための手段】
【００１０】
本発明のファームウェア保護装置は、ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置であって、前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段とを有する。
【００１１】
上記ファームウェア保護装置では、ファームウェアを分割記憶し、各分割プログラム毎にチェックサムを保持している。これより、各分割プログラム毎に、それが破損しているか否かをチェックできる。ファームウェアの全体が破損しているのではなく、その一部のみが破損している場合には、破損している分割プログラムのみをリカバリすればよく、リカバリ処理に掛かる時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消できる。
【００１２】
上記ファームウェア保護装置において、例えば、前記二重化されたファームウェアが両方とも破損した場合、前記リカバリ手段は、まず一方のファームウェアをリカバリ対象として、該リカバリ対象のファームウェアに関する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムが、破損しているか否かをチェックし、他方のファームウェアにおいても破損している場合にはリカバリ不能とするが、破損していない場合には該他方のファームウェアにおける分割プログラムを用いて前記破損した分割プログラムをリカバリする。
【００１３】
本発明のファームウェア保護装置では、上記の通り、分割プログラム単位で破損の有無のチェック、リカバリを行えるので、たとえ二重化されたファームウェアが両方とも破損した場合でも、両方で同じ分割プログラムが破損していない限りは、リカバリを行える。
【発明の効果】
【００１４】
本発明のファームウェア保護装置、そのプログラム等によれば、二重化したファームウェアの一部が破損した場合に、破損した部分のみをリカバリすることでリカバリに要する時間を短縮でき、以って装置の起動時間が大幅に遅くなる問題を解消できる。更に二重化したファームウェアの両方が破損してしまった場合でもファームウェアをリカバリするこ
とができ、装置を起動することを可能とする。
【図面の簡単な説明】
【００１５】
【図１】本例のファームウェア保護装置の一例である組込み機器の構成例である。
【図２】（ａ）、（ｂ）、（ｃ）は、外部フラッシュＲＯＭのデータブロック構成例を示す図である。
【図３】ＳＤＲＡＭのデータ構成図である。
【図４】ブートファームウェアによるメイン処理のフローチャート図である。
【図５】ブートファームウェアの起動処理のフローチャート図である。
【図６】ブートファームウェアのリカバリ処理のフローチャート図（その１）である。
【図７】ブートファームウェアのリカバリ処理のフローチャート図（その２）である。
【図８】オペレーションファームウェアの処理フローチャート図（その１）である。
【図９】オペレーションファームウェアの処理フローチャート図（その２）である。
【図１０】ダウンロード処理のフローチャート図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例のファームウェア保護装置の一例である組込み機器の構成例である。尚、本例のファームウェア保護装置は、組込み機器に限らない。但し、特に組込み機器である場合には、上述した装置の起動ができない（もしくは起動が大幅に遅くなる）ことは、重大な問題となり、避けなければならないものである。
【００１７】
図示の例の組込み機器１０は、ＣＰＵ１１、外部フラッシュＲＯＭ１４、ＳＤＲＡＭ１５を有し、ＣＰＵ１１は、ＲＡＭ１２、内蔵フラッシュＲＯＭ１３を有する。また、組込み機器１０は、上位機１に接続している。
【００１８】
上位機１は、オペレーションファームウェアを組込み機器１０内のＳＤＲＡＭ１５に転送して記憶する処理機能と、このＳＤＲＡＭ１５に記憶されたオペレーションファームウェアを外部フラッシュＲＯＭ１４にダウンロードさせるための指示を組込み機器１０に対して行う処理機能等を備える、ＰＣ（パソコン）等の上位装置である。尚、このダウンロード指示を受けた組込み機器１０側では、後述する図１０に示すダウンロード処理を実行する。
【００１９】
内蔵フラッシュＲＯＭ１３は、ブートファームウェアを記憶する。
外部フラッシュＲＯＭ１４は、オペレーションファームウェアを記憶する。これは、オペレーションファームウェアを二重化して記憶・管理している。そして、本手法では、後に図２で説明するように、オペレーションファームウェアを複数ブロックに分割して管理している。
【００２０】
ＳＤＲＡＭ１５は、外部フラッシュＲＯＭ１４に記憶したオペレーションファームウェ
アの実行領域を有する（ワークメモリである）。
尚、上記オペレーションファームウェアが、組込み機器に搭載させて何らかの処理を実行させる為のファームウェアであり、二重化により保護する対象となるファームウェアである。一方、上記ブートファームウェアは、ブート処理（詳しくは後述する）を実行するファームウェアである。
【００２１】
図２に、外部フラッシュＲＯＭ１４のデータブロック構成を示す。
図２（ａ）に示すように、外部フラッシュＲＯＭ１４の記憶領域は、管理情報格納領域２１と、複数のＦＷ格納領域２２（図示の例では、ＦＷ格納領域ａ、ｂ等；ＦＷはファームウェアの略号とする）等から成る。
【００２２】
各ＦＷ格納領域２２は、それぞれオペレーションファームウェアを記憶する領域である。そして、上記の通り、オペレーションファームウェアは二重化されて記憶されており、例えばＦＷ格納領域ａとｂには基本的には同じオペレーションファームウェアが記憶されている。但し、上位機１から新バージョンのオペレーションファームウェアが転送されて、これをダウンロードした際には、一時的に、ＦＷ格納領域ａ、ｂのどちらか一方には新バージョン、他方には旧バージョンが格納された状態になる場合もある。また、何かの間違いで別のプログラムが格納される可能性もある。
【００２３】
管理情報格納領域２１は、上記ＦＷ格納領域２２に格納されているオペレーションファームウェアに関する各種管理情報が記憶される。これは詳細には図２（ｂ）に示すように、管理情報格納領域２１には、動作ステータス３１、バックアップステータス３２、カレントＦＷ格納領域番号３３、破損ブロック番号３４等の各種管理情報が記憶される。
【００２４】
尚、本説明では、管理情報格納領域２１には、ＦＷ格納領域ａとｂとに二重化されて格納される１つのオペレーションファームウェアに関する管理情報が記憶されるものとする。尚、オペレーションファームウェアが複数種類ある場合には、各オペレーションファームウェア毎に対応付けて上記管理情報が記憶される。
【００２５】
また尚、特に図示しないが、管理情報格納領域２１には、対応するオペレーションファームウェアの各格納領域（上記の例ではＦＷ格納領域ａとＦＷ格納領域ｂ）のアドレス等の情報も格納されている。例えば、後述する格納領域番号（１，２）にそれぞれ対応付けて、そのオペレーションファームウェアの各格納領域のアドレス等の情報も格納される。このアドレス等は、例えば、ヘッダ部４０の各種情報のアドレスや、プログラム部５０の各プログラムブロック５１のアドレス等である。また、ヘッダ部４０における各プログラムブロックＳＵＭ４５が、プログラム部５０におけるどのプログラムブロック５１に対応するものであるのかを示す情報等も、例えば管理情報格納領域２１に格納されていてもよい。
【００２６】
動作ステータス３１は、上記オペレーションファームウェアの動作状態を示すものであり、その値と意味は本例では下記の通りとする。
・0 ：運用中
・1 ：リカバリ中
・2 ：停止中（リカバリが不可能なため、再ダウンロードが必要な状態）
バックアップステータス３２は、オペレーションファームウェアがバックアップされているか否かを示すものであり、その値と意味は本例では下記の通りとする。
・0 ：バックアップなし
・1 ：バックアップあり
尚、“バックアップあり”とは、オペレーションファームウェアが正常に二重化されている状態であることを示す。よって、例えば、ＦＷ格納領域ａとｂとに格納されているオ
ペレーションファームウェアが、バージョンが同じではない場合や、破損が生じている場合には、“バックアップなし（０）”となる。
【００２７】
カレントＦＷ格納領域番号３３は、ブートファームウェアがブートするオペレーションファームウェアの格納領域番号であり、その値と意味は本例では下記の通りとする。
・1 ：ＦＷ格納領域ａ
・2 ：ＦＷ格納領域ｂ
つまり、カレントＦＷ格納領域番号３３＝‘１’の場合には、ＦＷ格納領域ａがカレント側であり、ＦＷ格納領域ｂはカレント側ではない（非カレント側というものとする）ことを意味する。同様に、カレントＦＷ格納領域番号３３＝‘２’の場合にはＦＷ格納領域ｂがカレント側であり、ＦＷ格納領域ａは非カレント側であることを意味する。
【００２８】
ブートファームウェアは、オペレーションファームウェアの処理を実行させる際には、カレント側のオペレーションファームウェアを、ＳＤＲＡＭ１５に転送して起動する。但し、カレント側のオペレーションファームウェアが正常に動作しない場合（破損がある等）には、非カレント側のオペレーションファームウェアをカレント側として、ＳＤＲＡＭ１５に転送して起動する。つまり、非カレント側とは、通常、バックアップ側を意味する。
【００２９】
破損ブロック番号３４は、カレントＦＷ格納領域番号３３が示す領域（上記カレント側の領域）における破損したプログラムブロックのブロック番号を、ビットに割当てて記憶するものであり、その意味は本例では以下の通りとする。
【００３０】
・ビットＯＮ ：破損あり
・ビットＯＦＦ：破損なし
尚、上記ブロック番号とは、後述する各プログラムブロック５１に割り当てられた識別番号である。例えばブロック番号が‘１’〜‘８’であったとしたならば、破損ブロック番号３４は８ビットから成り、ブロック番号‘１’は１ビット目に割り当て、ブロック番号‘８’は８ビット目に割り当てる。
【００３１】
各ＦＷ格納領域２２のデータ構成は同一であり、その一例を図２（ｃ）に示す。
図２（ｃ）に示す例では、ＦＷ格納領域２２に格納されるオペレーションファームウェアは、ヘッダ部４０とプログラム部５０とから成る。
【００３２】
プログラム部５０がオペレーションファームウェア本体である。プログラム部５０には、図示の通り、オペレーションファームウェア本体（プログラム本体）が、固定長ブロック（各プログラムブロック５１）に分割されて格納されている。
【００３３】
また、ヘッダ部４０には、名称４１、バージョン４２、ヘッダサイズ４３、プログラムサイズ４４、プログラムブロックＳＵＭ４５、ヘッダＳＵＭ４６等の、上記プログラム部５０のプログラム本体に関する各種データが格納される。
【００３４】
名称４１は、プログラム部５０に格納されているオペレーションファームウェアの名称等である。バージョン４２は、このオペレーションファームウェアのバージョンである。ヘッダサイズ４３は上記ヘッダ部４０のデータサイズである。
【００３５】
プログラムサイズ４４は、上記オペレーションファームウェアのプログラム部５０の実サイズである。尚、これは、各プログラムブロック５１の合計サイズを意味するものではない(プログラムブロック５１は固定長なので、プログラムサイズがこのブロックサイズで割り切れない場合には一致しない；最終ブロックの一部は空白等となる)。
【００３６】
各プログラムブロックＳＵＭ４５は、上記各プログラムブロック５１毎に対応したそのプログラムブロックのＳＵＭ（チェックサム）である。つまり、上記各プログラムブロック５１は、上記各プログラムブロックＳＵＭ４５と1対1で対応する。
【００３７】
ヘッダＳＵＭ４６は、ヘッダ部４０のＳＵＭ（チェックサム）である。これは、上記名称４１、バージョン４２、ヘッダサイズ４３、プログラムサイズ４４、のＳＵＭを計算したものに、プログラムブロックＳＵＭ４５の各ＳＵＭ値を加算した値（合計）である。
【００３８】
尚、よく知られているように、チェックサムは、データの信頼性を検査する為に、予め検査対象のデータに基づいて所定の計算方法により算出しておくものである。この所定の計算方法は、様々な方法があってよく、簡単な方法としては、全データをバイト単位で（桁あふれは無視して）加算する計算方法等がよく知られているが、この例に限るものではない。尚、ハッシュ値等もチェックサムの一例として扱われることがある。
【００３９】
この様に、本例では、オペレーションファームウェアを固定長ブロックに分割して格納すると共に、各プログラムブロック毎にＳＵＭを生成・格納している。つまり、各プログラムブロック毎にＳＵＭによる異常チェック（破損の有無のチェック）を行えるようにしている。上記の通り、二重化されたオペレーションファームウェアの両方とも、この様なデータ構成となっている。
【００４０】
この様な構成を用いることで、本手法では、（詳しくは後にフローチャート図を参照して説明するが）、ファームウェア保護装置（組込み機器等）において例えば以下の１）、２）の処理機能を提供することができる。
【００４１】
１）二重化したオペレーションファームウェアが両方とも破損した場合でも、リカバリ可能となる。つまり、当然、どちらか一方でもプログラム全体が破損した場合にはリカバリ不能であるが、両方とも一部のみが破損した状態であれば、リカバリできる場合がある。リカバリできる場合とは、どちらか一方において破損したプログラムブロックが、他方においては破損していない場合である。
【００４２】
二重化したオペレーションファームウェアが両方とも破損した場合のリカバリの為の処理に関しては、その具体的な一例については詳しくは後にフローチャート図を参照して説明するが、概略的には以下の通りである（但し、これは具体的な処理の一例を示すものであり、この例に限るものではない）。
【００４３】
まず、オペレーションファームウェアを起動するファームウェア(上記ブートファームウェア)による起動処理において、オペレーションファームウェアに破損があった場合には、破損したプログラムブロック５１の情報を管理情報格納領域２１の破損ブロック番号３４に記憶する。尚、上記の通り、破損ブロック番号３４には、カレント側に関する破損情報が記憶され、非カレント側に関しては記憶されないが、これは一例であり、非カレント側に関してもその破損したプログラムブロック５１の情報を記憶するようにしてもよい。
【００４４】
後述する図５に示す処理例では、二重化したオペレーションファームウェアが両方とも破損している場合には、上記起動処理後、自動でリブートする。この場合には、これによって、ブートファームウェアによるリカバリ処理が実行されることになる。このリカバリ処理において、ヘッダ部４０と管理情報格納領域２１を参照して、破損したオペレーションファームウェアの該当ブロック（破損したプログラムブロック５１）のみを、二重化したもう一方のオペレーションファームウェアから複製してリカバリする。
【００４５】
但し、上記の通り、もう一方のオペレーションファームウェアにおいても同じプログラムブロック５１が破損していた場合には、リカバリ不能となる。この場合には、再度、オペレーションファームウェアをダウンロードすることになる（但し、従来では人手を介したが、本手法では自動的にダウンロードする）。
【００４６】
この様に、二重化したファームウェアが両方とも破損した場合でも、破損状態によっては、ファームウェアをリカバリすることができる。
尚、後述する処理例では、リカバリ処理においてはカレント側のオペレーションファームウェアのみをリカバリする。非カレント側のオペレーションファームウェアに関しては、その後にカレント側のオペレーションファームウェアを実行することで（後述する図８、図９に示す“オペレーション”処理）、リカバリされる。但し、これは一例であり、この例に限らず、リカバリ処理においてカレント側、非カレント側（バックアップ側）の両方ともリカバリしてもよい。
【００４７】
２）二重化したオペレーションファームウェアの一部が破損した場合、破損した部分のみを（プログラムブロック単位で）リカバリすることで、オペレーションファームウェアのリカバリに要する時間を大幅に減少させることができる。これより、装置の起動時間が大幅に遅くなる問題を解消できる。尚、本例では二重化したオペレーションファームウェアのどちらか一方のみが破損した場合を主に想定しているが、両方とも異なった箇所が破損した場合でも同様にして得られる効果である。
【００４８】
これに関しても、その具体的な一例については詳しくは後にフローチャート図を参照して説明するが、概略的には以下の通りである（但し、これは具体的な処理の一例を示すものであり、この例に限るものではない）。
【００４９】
まず、上記ブートファームウェアの起動処理において、どちらか一方のオペレーションファームウェアに破損があった場合には、破損したプログラムブロック５１の情報を管理情報格納領域２１の破損ブロック番号３４に記憶する。そして、他方の（破損していない）オペレーションファームウェアを起動する。
【００５０】
これより、起動したオペレーションファームウェアの処理において、ヘッダ部４０と管理情報格納領域２１を参照して、破損したオペレーションファームウェアの該当ブロック（破損したプログラムブロック５１）のみを、当該起動したオペレーションファームウェアにおける該当ブロック（上記破損したプログラムブロック５１と同じプログラムブロック５１）を用いてリカバリする。
【００５１】
これにより、上記従来のように起動したファームウェアの全領域を複製する手法に比べて、複製するデータ量が少なくて済むので、ファームウェアのバックアップに要する時間が大幅に減少させることができ、以って装置の起動時間への影響を微小にすることができる。
【００５２】
図３に、ＳＤＲＡＭ１５のデータ構成図を示す。
図示の例では、ＳＤＲＡＭ１５は、ＦＷブート領域６１、ＦＷダウンロード領域６２の各記憶領域を有する。
【００５３】
ＦＷブート領域６１は、上記オペレーションファームウェアを外部フラッシュＲＯＭ１４から転送して、実行する領域である。
ＦＷダウンロード領域６２は、新たなオペレーションファームウェアをダウンロードする際に、これを一時的に記憶する領域である。これは、上位機1から新たなオペレーショ
ンファームウェアが転送されてＦＷダウンロード領域６２に記憶される。新たなオペレーションファームウェアは、ＦＷダウンロード領域６２に一時的に記憶された後、外部フラッシュＲＯＭ１４にダウンロードして格納される（図１０に処理の一例を示す）。その後、オペレーションファームウェアを実行する際には、上記ＦＷブート領域６１に転送・格納して実行することになる。
【００５４】
図４は、ブートファームウェアによるメイン処理のフローチャート図である。
ブートファームウェアは、予め内蔵フラッシュＲＯＭ１３に記憶されているプログラムであり、ＣＰＵ１１がこのブートファームウェアを内蔵フラッシュＲＯＭ１３から読出・実行することで、図４の処理が実現される。
【００５５】
ブートファームウェアは、様々な処理を行うが、基本的には図４に示すメイン処理を経て、図示のブート本体処理、起動処理、リカバリ処理の何れかを実行するものである。ブート本体処理とは、ここではダウンロード処理であり、例えば後述する図１０の処理を実行する。
【００５６】
尚、ブート本体処理は、無限ループでイベントを待ち、イベント発生したら、発生したイベントに応じた処理を行うものであり、例えばデータ収集や通信等の処理や、ダウンロード処理を行うものである。
【００５７】
ブート本体処理の一例であるダウンロード処理は、以下の（ａ）、（ｂ）の何れかの場合に実行される。
（ａ）一度もオペレーションファームウェアをダウンロードしていない場合において、上記上位機１からのダウンロード指示を受けた場合
（ｂ）二重化したオペレーションファームウェアが両方とも壊れている場合
ここで、図４に示す“ブート本体処理”は図示のステップＳ１２がＹＥＳの場合に実行されるものであり、これは上記（ｂ）の場合に相当するものであり、よって上記の通り図４に示す“ブート本体処理”はダウンロード処理を意味することになる。尚、同様の理由により、図７に示すステップＳ６０の後の“ブート本体処理”も、ダウンロード処理を意味することになる。そして、上記の通り、本例におけるダウンロード処理は例えば後述する図１０に示す処理となる。
【００５８】
また、起動処理とは、基本的にはカレント側のオペレーションファームウェアを起動して処理実行させるものである。これは、外部フラッシュＲＯＭ１４に記憶したオペレーションファームウェアを、ＳＤＲＡＭ１５に転送した後、処理実行させるものである。起動したオペレーションファームウェアの処理については、図８、図９に示し、後に説明する。
【００５９】
但し、カレント側のオペレーションファームウェアに破損等がある場合には、破損情報を破損ブロック番号３４に記憶すると共に、カレント側ではない（上記の通り非カレント側と呼ぶ）オペレーションファームウェアをカレント側に切り替えて処理実行させる。また、オペレーションファームウェアが両方とも破損している場合には、破損情報を破損ブロック番号３４に記憶すると共に、リブートして、上記リカバリ処理を実行して、破損箇所のリカバリを行う。上記起動処理の詳細は図５、リカバリ処理の詳細は図６、図７に示し、後に説明する。
【００６０】
以下、まず、図４のメイン処理について説明する。
図４の処理では、まず、ハードウェア及びブートファームウェアの各種初期化を行う（ステップＳ１１）。
【００６１】
そして、動作ステータス３１を参照して、その内容に応じて、上記ブート本体処理、起動処理、リカバリ処理の何れかを実行する。
すなわち、動作ステータス３１が“停止中(2)”の場合は（ステップＳ１２，ＹＥＳ）、二重化したオペレーションファームウェアが共に破損し、且つ、リカバリ不可能な状態であることを示しているため、オペレーションファームウェアの起動は行わず、ブート本体処理に遷移する。
【００６２】
尚、既に述べた通り、ブート本体処理とは、ダウンロード処理を含むブートファームウェアが本来行う処理であるが、本説明ではダウンロード処理のみ規定するものとする。上記の通り、ダウンロード処理については詳細は図１０に示し、後に説明する。
【００６３】
また、動作ステータス３１が“リカバリ中(1)”の場合は（ステップＳ１３，ＹＥＳ）、リカバリ処理へ遷移する。このリカバリ処理の詳細は図６、図７に示し、後に説明する。
【００６４】
また、動作ステータス３１が“運用中(0)”の場合は（ステップＳ１４，ＹＥＳ）、起動処理へ遷移する。この起動処理の詳細は図５に示し、後に説明する。
動作ステータス３１が“0〜2以外”の場合は（ステップＳ１２，Ｓ１３，Ｓ１４が何れもＮＯ）、管理情報格納領域２１が破損していると見なして、管理情報格納領域２１をゼロクリア（対象領域のビット値を“０”で全て埋めることを意味し、後述の説明の“ビットＯＦＦ”と“０”とは同値を指す）すると共に（ステップＳ１５）、各ＦＷ格納領域２２それぞれのヘッダ部４０を参照することで、二重化したオペレーションファームウェアのうち、バージョン４２が新しい方をカレント(ブート対象)として、その格納領域番号をＦＷ格納領域番号３３に設定して（上記の通り本例では１：ＦＷ格納領域ａ、２：ＦＷ格納領域ｂであり、‘１’‘２’のどちらかを設定する）（ステップＳ１６）、起動処理へ遷移する。
【００６５】
図５に、ブートファームウェアの上記起動処理のフローチャート図を示す。
図示の例では、まず、管理情報格納領域２１におけるカレントＦＷ格納領域番号３３を参照して現在のカレント側のオペレーションファームウェアを認識し、このカレント側のオペレーションファームウェアのＦＷ格納領域２２のヘッダ部４０が破損しているか否かをチェックする。これは、このヘッダ部４０のＳＵＭを計算し、算出したＳＵＭがヘッダＳＵＭ４６と一致するかをチェックする（ステップＳ２１）。
【００６６】
上記ＳＵＭが一致する場合は（ステップＳ２２，ＹＥＳ）、ヘッダ部４０は破損等していないことになり（正常であり）、ステップＳ２３以降の処理に遷移する。一方、上記ＳＵＭが一致しない場合には（ステップＳ２２，ＮＯ）、ヘッダ部４０が破損していることを示しているため、ステップＳ２９以降の処理に遷移する。
【００６７】
ステップＳ２３〜Ｓ２７の処理は、概略的には、オペレーションファームウェア本体（プログラム部５０）をブロック単位で、ＳＤＲＡＭ１５のＦＷブート領域６１に順次転送し、転送する毎に対応するプログラムブロックＳＵＭ４５を用いた破損（異常）チェックを行う処理である。上記転送とＳＵＭチェックを全ブロックについて完了するまで繰り返し行う。
【００６８】
すなわち、まず、プログラム部５０における１つのプログラムブロック５１をＦＷブート領域６１に転送し、このプログラムブロック５１のＳＵＭを計算する（ステップＳ２３）。そして、算出したＳＵＭがこのプログラムブロック５１に対応するプログラムブロックＳＵＭ４５と一致するか否かを判定し、一致する場合には（ステップＳ２４，ＹＥＳ）このプログラムブロック５１は破損していないことになるので、そのままステップＳ２７
の処理へ移行する。そして、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ２７，ＮＯ）、ステップＳ２３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【００６９】
一方、算出したＳＵＭと対応するプログラムブロックＳＵＭ４５とが不一致の場合には（ステップＳ２４,ＮＯ）、つまりこのプログラムブロック５１が破損している場合には、処理対象がカレント側の場合のみ（ステップＳ２５，ＹＥＳ）、当該破損したプログラムブロック５１の番号を内部変数Ａのビットに割当てて記憶する（ステップＳ２６）。
【００７０】
尚、上記ステップＳ２５の判定を行うのは、本説明で用いる一例では破損ブロック番号３４はカレント側にのみ対応する情報だからである。非カレント側についてはその一部に破損があっても破損ブロック情報は残さない。カレント側については破損ブロック番号３４に基づいて、破損したプログラムブロック５１のみリカバリを行う。よって、プログラム全体をリカバリする場合に比べて、リカバリ処理時間が短くて済む。一方、非カレント側に破損があった場合、後に説明する“オペレーション”の処理により（このときカレント側は破損があっても既にリカバリ済み）、カレント側のプログラム本体全体を非カレント側にコピーすることで、非カレント側もリカバリできる。
【００７１】
但し、既に述べた通り、これは一例であり、この例に限らない。例えば、破損ブロック番号３４を、カレント側対応と非カレント側対応との２種類用意し、これに応じて内部変数に関しても上記内部変数Ａに加えて更に非カレント側に対応する内部変数（仮に、内部変数Ｂとする）も用意するようにしてもよい。この例では、上記ステップＳ２５の判定がＮＯの場合には、内部変数Ｂを用いてステップＳ２６と同様の処理を行うことになる。また、後述するステップＳ３２、Ｓ３５の処理では、内部変数Ａ，Ｂの値をそれぞれ上記２種類の破損ブロック番号３４のどちらかにコピーすることになる。また、この例の場合、後述する各種処理のうち破損ブロック番号３４を用いる処理が、本例とは多少異なることになるが、これについては特に説明しない。
【００７２】
尚、内部変数Ａ、Ｂとは、破損ブロック番号３４と同じデータ構造の内部変数であり、上記の通り、“ビットＯＮ：破損あり”、“ビットＯＦＦ：破損なし”を意味しており、全てのビットは領域確保時に初期化（ビットＯＦＦ）しておく。そして、ステップＳ２６において、破損したプログラムブロック５１に対応するビットをビットＯＮする。尚、後述するように後にこの内部変数Ａにより破損ブロック番号３４を更新する。勿論、この例に限らず、例えば内部変数を用いることなく直接、破損ブロック番号３４を更新するようにしてもよい。
【００７３】
そして、上記ステップＳ２７の処理を行う。
全てのプログラムブロック５１について上記の処理を行ったら（ステップＳ２７，ＹＥＳ）、プログラムブロックＳＵＭ４５が全て正常であったか（破損していないか）否かを判定し（ステップＳ２８）、全て正常であった場合には、すなわち破損しているプログラムブロック５１が１つも無い場合には（ステップＳ２８，ＹＥＳ）、ステップＳ３２〜Ｓ３４の処理を実行し、ＦＷブート領域６１に転送済みのオペレーションファームウェアを起動する。
【００７４】
一方、破損しているプログラムブロック５１が１つでもある場合（ステップＳ２８，ＮＯ）、またはヘッダ部４０が破損している場合には（ステップＳ２２，ＮＯ）、二重化したオペレーションファームウェアの内、少なくとも1つが破損していること(バックアップなし)を示しているため、管理情報格納領域２１のバックアップステータス３２をバックアップなし(0)に設定する（ステップＳ２９）。
【００７５】
次に、非カレント(バックアップ)領域のチェックも実施済みか否かを判定し（ステップＳ３０）、未実施の場合には（ステップＳ３０，ＮＯ）、非カレント側のオペレーションファームウェアに関して、上記カレント側と同様のチェック処理を行う。すなわち、非カレント側（バックアップ側）のオペレーションファームウェアのＦＷ格納領域２２のヘッダ部４０、プログラム部５０が破損しているか否かを、上記ステップＳ２２〜Ｓ２８の処理によりチェックする。尚、ステップＳ３１の処理の前に、ＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送したプログラムブロック５１は全て削除する。
【００７６】
ステップＳ３１以降の処理では、非カレント側のオペレーションファームウェアのＦＷ格納領域２２を参照して、そのヘッダ部４０、プログラム本体（各プログラムブロック５１）に関するチェックを行うことになる。この際、チェック実行の有無を、例えばビット値で記憶しておき、ステップ３Ｓ０の処理では、この値に基いてチェックの有無を判定する。
【００７７】
すなわち、まず、上記非カレント側のオペレーションファームウェアのＦＷ格納領域２２におけるヘッダ部４０のＳＵＭを計算する（ステップＳ３１）。そして、ステップＳ２２の処理に戻り、まず、上記ステップＳ３１で算出したＳＵＭがヘッダＳＵＭ４６と一致するか否かによりヘッダ部４０が破損しているか否かを判定する（ステップＳ２２）。そして、ヘッダ部４０が破損していない場合には（ステップＳ２２，ＹＥＳ）、今度はプログラム５０について上記カレント側の場合と同様にして各プログラムブロック５１毎に破損しているか否かを判定する（ステップＳ２３〜Ｓ２７）。尚、既に述べた通り、もし破損しているプログラムブロック５１が存在しても、今度は上記ステップＳ２５の判定はＮＯとなるので、ステップＳ２６の処理（内部変数Ａに反映させる処理）は行われない。
【００７８】
そして、非カレント側のオペレーションファームウェアに関して、ヘッダ部４０及びプログラム部５０に破損が無かった場合には（ステップＳ２８，ＹＥＳ）、ステップＳ３２〜Ｓ３４の処理を行う。
【００７９】
一方、非カレント側のオペレーションファームウェアに関しても、ヘッダ部４０またはプログラム部５０に破損がある場合には（ステップＳ２２，ＮＯ；またはステップＳ２８，ＮＯ）、再び上記ステップＳ３０の判定を行うことになり、今度は判定ＹＥＳとなり、ステップＳ３５，Ｓ３６の処理を実行し、その後リブートを行う。つまり二重化されたオペレーションファームウェアの両方とも破損がある場合には、ステップＳ３５，Ｓ３６の処理を実行し、その後、後述するリカバリ処理を実行することになる。
【００８０】
上記ステップＳ３２〜Ｓ３４の処理について説明する。
これらの処理は、カレント側についてステップＳ２８の判定がＹＥＳの場合、またはカレント側に破損があり且つ非カレント側についてステップＳ２８の判定がＹＥＳの場合に、実行させることになる。また、これらの処理が実行される場合には、二重化したオペレーションファームウェアのうち、少なくともどちらか一方は正常な状態（破損していない）であり、正常なものがＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送されている状態である。
【００８１】
この状態において、まず、上記内部変数Ａを破損ブロック番号３４にコピーすることで、破損ブロック番号３４を更新する（ステップＳ３２）。カレント側についてステップＳ２８の判定がＹＥＳの場合については、内部変数Ａは初期状態のまま（全てのビットがＯＦＦ）であるので、更新後の破損ブロック番号３４の内容も、全てのビットがＯＦＦとなる。つまり、カレント側のプログラム本体については破損無しを示す内容となる。
【００８２】
一方、非カレント側についてステップＳ２８の判定がＹＥＳの場合については、もしカ
レント側の破損がヘッダ部４０の破損では無かったならば、更新後の破損ブロック番号３４の内容は、カレント側における破損したプログラムブロックを示すものとなる。
【００８３】
次に、カレントＦＷ格納領域番号３３に、上記ＳＤＲＡＭ１５（そのＦＷブート領域６１）に正常転送されたオペレーションファームウェアの番号を設定する（ステップＳ３３）。カレント側についてステップＳ２８の判定がＹＥＳの場合には、カレント側のオペレーションファームウェアの番号が設定されることになる。一方、非カレント側についてステップＳ２８の判定がＹＥＳの場合には、非カレント側のオペレーションファームウェアの番号が設定されることになる。これは、非カレント側がカレント側（ブート対象）に切り替わることを意味する。
【００８４】
そして、ＳＤＲＡＭ１５（そのＦＷブート領域６１）に転送済みのオペレーションファームウェアを起動する（ステップＳ３４）。これによって“オペレーション”が実行される。“オペレーション”の処理内容については、後に図８、図９を参照して説明する。
【００８５】
次に、上記ステップＳ３５〜Ｓ３６の処理について説明する。
この場合、二重化したオペレーションファームウェアの両方が破損しているため、破損ブロック番号３４と動作ステータス３１を設定して、装置をリブートする。
【００８６】
すなわち、まず、上記ステップＳ３２と同様の処理を行う。すなわち上記内部変数Ａの内容を破損ブロック番号３４にコピーすることで、破損ブロック番号３４を更新する（ステップＳ３５）。次に、動作ステータス３１をリカバリ中（１）に設定する。そして、リブートする。これにより、上記ブートファームウェアのメイン処理に遷移する。動作ステータス３１をリカバリ中（１）に設定してあることから、このメイン処理において上記ステップＳ１３の判定がＹＥＳとなるので、リカバリ処理を実行することになる。
【００８７】
図６、図７は、ブートファームウェアのリカバリ処理のフローチャート図である。
尚、これは、リカバリ処理を２つの図面に渡って示しているものである。
上記の通り、本処理は、二重化したオペレーションファームウェアが両方共破損している状態で行われる。但し、オペレーションファームウェア全体が破損しているとは限らず、むしろ一部のみ破損している可能性が高い。
【００８８】
まず、上記ステップＳ２１，２２と同様の処理を、二重化したオペレーションファームウェア両方に対して行う（ステップＳ４１）。すなわち、二重化したオペレーションファームウェア各々のヘッダ部４０に関して、そのヘッダＳＵＭ４６を用いたチェックをそれぞれ行い、ヘッダ部４０の整合性を確認する。すなわち、ヘッダ部４０のＳＵＭを算出し、算出したＳＵＭ値がヘッダＳＵＭ４６と一致するか否かにより、ヘッダ部４０の正常／異常を判定する。
【００８９】
そして、二重化したオペレーションファームウェアの両方でヘッダ部４０が正常（破損なし）の場合には（ステップＳ４２，ＹＥＳ）、プログラムブロック５１に異常（破損）があることになるので、ステップＳ４７の処理へ移行する。
【００９０】
また、どちらか一方は正常であるが他方は異常である場合には（ステップＳ４２，ＮＯ且つステップＳ４３，ＹＥＳ）、ステップＳ４４の処理へ移行する。
両方ともヘッダ部４０が異常な場合は（ステップＳ４２，ＮＯ且つステップＳ４３，ＮＯ）、リカバリするための情報が得られないため、リカバリ不能とする。すなわち、動作ステータス３１を停止中（２）に設定し（ステップＳ６０）、本処理を終了する。そして、ブート本体処理（図１０のダウンロード指示を待つ状態）に遷移する。
【００９１】
尚、既に述べた通り、ブート本体処理は、ダウンロード処理を含むブートファームウェアが本来行う処理であるが、本説明では、ダウンロード処理のみ規定する。
以下、まず、ステップＳ４４以降の処理について説明する。
【００９２】
すなわち、上記のチェック処理により何れか一方のヘッダ部４０が正常（破損していない）で他方が異常（破損している）と判定された場合は、二重化したオペレーションファームウェアのプログラム部５０同士を比較する（ステップＳ４４）。その結果、同一のプログラムであることが確認された場合は（ステップＳ４５，ＹＥＳ）、破損していないヘッダ部４０を用いて破損しているヘッダ部４０をリカバリする。すなわち、破損していない領域のヘッダ部４０の情報を、破損しているヘッダ部４０の領域にコピーする（ステップＳ４６）。そして、ステップＳ５３の処理へ移行する。
【００９３】
一方、上記ステップＳ４４の比較の結果、プログラム部５０が不一致の場合には（ステップＳ４５，ＮＯ）、相互に異なるオペレーションファームウェアが記憶されていることを示している。例えば一方が新バージョンで他方が旧バージョンの場合等である。よって、この場合、ヘッダ部４０の情報も異なるものであり、破損していないヘッダ部４０を用いて破損しているヘッダ部４０をリカバリすることは出来ないので、リカバリ不能とする。つまり、上記ステップＳ６０の処理を実行し、本処理は終了する。
【００９４】
尚、上記ステップＳ４５や後述するステップＳ４８の処理の主旨は、相互に異なるオペレーションファームウェアが記憶されているか否かを判定するものであるので、例えば「名称４１及びバージョン４２が一致するか？」という判定処理に置き換えてもよい。
【００９５】
また、本例ではステップＳ４６の処理からステップＳ５３の処理に移行したが、これは一例であり、例えばステップＳ４６の処理からステップＳ４７の処理に移行するようにしてもよい。あるいは、ステップＳ４６の処理後に例えば「破損ブロック番号３４有り？(破損しているプログラムブロック５１があるか否かを判定するもの)」を追加し、この判定がＮＯの場合にはステップＳ５３の処理に移行し、判定ＹＥＳの場合にはステップＳ４７の処理に移行するようにしてもよい。何れにしても、図示のフローチャートは一つの例を示しているのであり、この例に限るものではない。
【００９６】
次に、以下、ステップＳ４７以降の処理について説明する。
上記の通り、二重化したオペレーションファームウェアの両方ともヘッダ部４０が正常な場合（破損していない）、ステップＳ４７へ移行し、ステップＳ４７〜Ｓ５２の処理を実行する。
【００９７】
まず、二重化したオペレーションファームウェアのヘッダ部４０同士を比較して（ステップＳ４７）、一致するか否かを判定する（ステップＳ４８）。
ヘッダ部４０が不一致の場合は（ステップＳ４８，ＮＯ）、相互に異なるオペレーションファームウェアが記憶されていることを示している。この場合、リカバリに必要なプログラムブロック５１が存在しないため、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【００９８】
一方、ヘッダ部４０が同じ場合には（ステップＳ４８，ＹＥＳ）、まず、カレントＦＷ格納領域番号３３と破損ブロック番号３４を参照する。これより、二重化したオペレーションファームウェアのどちらがカレント側でどちらが非カレント側であるかを認識でき、またカレント側においてどのプログラムブロック５１が破損しているかを認識できる。尚、破損ブロック番号３４は、上記図５の処理（起動処理）のステップＳ３５で設定した内容となっている。
【００９９】
そして、上記カレント側のリカバリを試みる。つまり、カレント側において破損しているプログラムブロック５１について、１つずつ、ステップＳ４９〜Ｓ５１の処理を実行し、全ての破損プログラムブロック５１についてリカバリ処理完了したら（ステップＳ５２，ＹＥＳ）、ステップＳ５３以降の処理に移る。但し、１つでもリカバリ不能な破損プログラムブロック５１があった場合（ステップＳ５０，ＮＯ）、上記ステップＳ６０の処理を実行することになる。
【０１００】
ステップＳ４９〜Ｓ５１の処理では、まず、処理対象の破損プログラムブロック５１について、非カレント側において同じプログラムブロック５１が破損していないか否かをチェックする（ステップＳ４９、Ｓ５０）。すなわち、非カレント側における上記処理対象の破損プログラムブロック５１と同じプログラムブロック５１のＳＵＭを計算し（ステップＳ４９）、このプログラムブロック５１に対応するプログラムブロックＳＵＭ４５と計算したＳＵＭとが一致するか否かを判定する（ステップＳ５０）。
【０１０１】
そして、ＳＵＭ不一致の場合、すなわち処理対象のプログラムブロック５１に関しては二重化したオペレーションファームウェアの両方とも破損している場合には（ステップＳ５０，ＮＯ）、リカバリ不能となる。よって、上記ステップＳ６０の処理を実行し、本処理は終了する（ダウンロード処理を行うことになる）。
【０１０２】
一方、ＳＵＭ一致の場合、すなわち処理対象のプログラムブロック５１に関して非カレント側のオペレーションファームウェアでは破損していない場合には（ステップＳ５０，ＹＥＳ）、非カレント側のオペレーションファームウェアの当該プログラムブロック５１を、カレント側のプログラムブロック５１の領域にコピーすることで、カレント側のプログラムブロック５１をリカバリする（ステップＳ５１）。
【０１０３】
例えば、図２（ｃ）の例において、カレント側のプログラムブロックｎが破損しており、非カレント側のプログラムブロックｎは破損していない場合には、非カレント側のプログラムブロックｎを、カレント側のプログラムブロックｎの領域にコピーすることになる。
【０１０４】
そして、カレント領域において破損している全てのプログラムブロック５１について上記処理を実行したか否かを判定し（ステップＳ５２）、未だ未処理のものがある場合には（ステップＳ５２，ＮＯ）、上記ステップＳ４９に戻り、次の処理対象の破損プログラムブロックについて、上記と同様の処理を行う。
【０１０５】
そして、カレント領域において破損している全てのプログラムブロック５１について上記処理を実行した場合（ステップＳ５２，ＹＥＳ）、これは途中でステップＳ５０の判定がＮＯとなることなく全ての破損プログラムブロック５１のリカバリを行えたことになり、ステップＳ５３の処理へ移行する。
【０１０６】
以上の処理により、ステップＳ５３以降の処理を行う場合には、少なくともカレント側のオペレーションファームウェアに関してはリカバリ完了していることになる。
以下、ステップＳ５３以降の処理について説明する。
【０１０７】
ステップＳ５３以降の処理は、上記リカバリが成功した場合の処理であり、よって基本的には、カレント領域のオペレーションファームウェアをＳＤＲＡＭ１５のＦＷブート領域６１に転送して起動し、オペレーション実行開始させるものであるが、念の為に再度ＳＵＭチェックを行っている。
【０１０８】
まず、カレント側のオペレーションファームウェアのプログラム部５０をブロック単位
でＳＤＲＡＭ１５のＦＷブート領域６１に転送する毎に、そのＳＵＭチェックを行う。すなわち、カレント側のオペレーションファームウェアのプログラム部５０の任意のプログラムブロック５１を、ＳＤＲＡＭ１５のＦＷブート領域６１に転送し、この転送したプログラムブロック５１のＳＵＭを算出する（ステップＳ５３）。そして、この転送したプログラムブロック５１に対応するプログラムブロックＳＵＭ４５が、ステップＳ５３で算出したＳＵＭと一致するか否か、すなわちこの転送したプログラムブロック５１が破損していないかをチェックする（ステップＳ５４）。これを、プログラム部５０の全てのプログラムブロック５１について実行し、全ブロックが処理完了したら（ステップＳ５５，ＹＥＳ）、ステップＳ５６の処理に移行する。一方、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ５５，ＮＯ）、ステップＳ５３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【０１０９】
但し、（通常起こりえないが）もし１つでも破損しているプログラムブロック５１があった場合には（ステップＳ５４，ＮＯ）、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【０１１０】
また、ステップＳ５６でも、最後に確認的に、全てのプログラムブロック５１が正常であったかを確認し（ステップＳ５６）、もし１つでも破損しているプログラムブロック５１があった場合には（ステップＳ５６，ＮＯ）、リカバリ不能とする。すなわち、上記ステップＳ６０の処理を実行し、本処理は終了する。
【０１１１】
ステップＳ５６の判定がＹＥＳであれば、バックアップステータス３２をバックアップあり（１）に設定すると共に（ステップＳ５７）、動作ステータス３１を運用中（０）に設定する（ステップＳ５８）。そして、ＦＷブート領域６１に転送済みの（正常な）オペレーションファームウェアを起動する（ステップＳ５９）。
【０１１２】
図８、図９に、“オペレーション”の処理、すなわち起動されたオペレーションファームウェアの処理フローチャートを示す。
尚、これは、オペレーションファームウェアの処理を２つの図面に分けて示しているものである。
【０１１３】
また、上記の通り、この処理が実行されるのは、ステップＳ３４で起動されるケースと、ステップＳ５９で起動されるケースとがある。
図示の処理では、まず、必要に応じて、ハードウェア及びオペレーションファームウェアの各種初期化を行う（ステップＳ７１）。
【０１１４】
そして、バックアップステータス３２を参照して、“バックアップあり（１）”の場合には（ステップＳ７２、ＮＯ）、ステップＳ７３以降の処理を行うことなく、オペレーション本体処理（オペレーションファームウェアの本来の処理）へ移行する。すなわち、この場合には、非カレント側も正常な状態となっているはずであるので、非カレント側のリカバリ処理は必要ないので、そのまま本来の処理を実行開始すればよい。
【０１１５】
ここで、上記オペレーション本体処理とは、組込み機器として必要な機能を実行するものであり、通常、無限ループでイベントを待ち、発生したイベントに応じた処理を行うものである。具体的には、例えば、データ収集処理、通信処理、制御対象機器の制御処理（例えばファンの速度を制御する等）であり、更にダウンロード処理等も含まれる。ダウンロード処理は、上記イベントとして上述した上位機１からのダウンロード指示があった場合に実行されるものであり、本例では図１０に示すダウンロード処理を実行するものである。上記オペレーション本体処理の１つとして実行されるダウンロード処理は、オペレーションファームウェアを更新する場合に実行するものである。
【０１１６】
一方、“バックアップなし（０）”の場合は（ステップＳ７２，ＹＥＳ）、本来の処理を行う前に、ステップＳ７３以降の処理を実行するものとし、まず、カレントＦＷ格納領域番号３３を参照して非カレント側を認識し、非カレント側のオペレーションファームウェアのヘッダ部４０のＳＵＭを計算し（ステップＳ７３）、そのヘッダＳＵＭ４６によりヘッダ部４０の正常／異常（破損有無）チェックする（ステップＳ７４）。つまり、算出したＳＵＭがヘッダＳＵＭ４６と一致するか否かをチェックする。
【０１１７】
一致する場合には（ステップＳ７４，ＹＥＳ）ステップＳ７８の処理へ移行する。
一方、算出したＳＵＭがヘッダＳＵＭ４６と不一致の場合には、非カレント側のヘッダ部４０が破損していることを示しており（ステップＳ７４，ＮＯ）、リカバリを試みる。但し、その前に、ヘッダ部４０のみが破損しているかどうかを調べるために、二重化したオペレーションファームウェアのプログラム部５０同士を比較し（ステップＳ７５）、プログラム部５０が一致するか否かをチェックする（ステップＳ７６）。一致する場合には（ステップＳ７６，ＹＥＳ）、カレント領域のヘッダ部４０を、非カレント側のヘッダ部４０の領域にコピーすることで（ステップＳ７７）、非カレント領域のヘッダ部４０をリカバリする。
【０１１８】
これによって、非カレント側のリカバリは完了するので、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
ステップＳ８３では、バックアップステータス３２を“バックアップあり（１）”に設定する。ステップＳ８４では破損ブロック番号３４をゼロクリアする。
【０１１９】
一方、一致しない場合には（ステップＳ７６，ＮＯ）、カレント領域のオペレーションファームウェア全体を、非カレント側の領域にコピーする（ステップＳ８２）。これによって、非カレント側のリカバリは完了するので、上記と同様、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
【０１２０】
また、上記ステップＳ７４の判定がＹＥＳの場合には、まず、二重化したオペレーションファームウェアのヘッダ部４０同士を比較して（ステップＳ７８）、ヘッダ部４０が一致するか否かを判定する（ステップＳ７９）。ヘッダ部不一致の場合には（ステップＳ７９，ＮＯ）、非カレント領域に、カレント側とは異なるファームウェア（例えば旧バージョン等）が記憶されていることになるので、オペレーションファームウェア全体をバックアップする。すなわち、上記ステップＳ８２の処理を実行する。
【０１２１】
一方、ヘッダ部一致の場合は（ステップＳ７９，ＹＥＳ）、二重化したオペレーションファームウェアは同一（同じバージョン等）であり、破損ブロック番号３４が記憶されている場合には（ステップＳ８０，ＹＥＳ）、破損ブロック番号３４を参照して、非カレント側において破損しているプログラムブロック５１のみを、カレント側の該当するプログラムブロック５１を用いてリカバリする。
【０１２２】
すなわち、破損ブロック番号３４を参照することで、非カレント領域において破損しているプログラムブロック５１の番号を認識し、カレント領域における当該番号のプログラムブロック５１を、非カレント側における同じ番号のプログラムブロック５１の領域にコピーする（ステップＳ８１）。
【０１２３】
尚、上記ステップＳ８０の“破損ブロック番号３４が記憶されている場合”とは、破損ブロック番号３４において全てのビットがＯＦＦとなっている状態以外の場合、すなわち１つでもビットがＯＮになっている場合を意味する。これは、例えば、図５においてステップＳ２６の処理が実行され（よってそのときのカレント側についてはステップＳ２８の
判定はＮＯとなる）、且つそのときの非カレント側についてはステップＳ２８の判定がＹＥＳとなった場合等である。
【０１２４】
尚、“そのときの”と言っているのは、この場合、ステップＳ３３の処理によって、“そのときの”非カレント側がカレント側に設定されているからである。つまり、例えば仮に図５の処理の際にはＦＷ格納領域ａがカレント側、ＦＷ格納領域ｂが非カレント側であったとした場合、上記のケースではステップＳ３３によりＦＷ格納領域ｂがカレント側に設定されるので、本処理においては上記ステップＳ７３においてＦＷ格納領域ａが非カレント側として認識されることになる。よって、この場合には、破損ブロック番号３４は、“そのときの”カレント側であるＦＷ格納領域ａに関する破損情報であるが、本処理においてはＦＷ格納領域ａは非カレント側と認識されることになる。よって、この例では上記ステップＳ８１の処理は、ＦＷ格納領域ｂのプログラムブロック５１を用いて、ＦＷ格納領域ａの破損プログラムブロック５１をリカバリすることになる。
【０１２５】
上記ステップＳ８１の処理により、非カレント側のリカバリは完了するので、上記と同様、ステップＳ８３、Ｓ８４の処理を実行して、上記オペレーションファームウェア本来の処理を開始する。
【０１２６】
一方、破損ブロック番号３４が記憶されていない場合には(ステップＳ８０，ＮＯ)、上記ヘッダ部不一致の場合と同様に、ステップＳ８２の処理を実行し、オペレーションファームウェア全体をバックアップする。尚、ステップＳ８０がＮＯとなる場合とは、例えば上記ステップＳ２６の処理が行われなかった場合等であり、すなわち破損ブロック番号３４において全てのビットがＯＦＦとなっている状態（初期状態）である。
【０１２７】
図１０に、ダウンロード処理のフローチャート図を示す。
ダウンロード処理は、例えばブートファームウェアやオペレーションファームウェアの本体処理中に含まれる処理であり（本体処理としての様々な処理のうちの１つであり；既に説明済みであるので、ここでの説明は省略する）、上位機１からダウンロード指示を受けると処理を開始する。尚、上位機１はＦＷダウンロード領域６２にオペレーションファームウェアを転送・格納した後、上記ダウンロード指示を出す。本手法では、再度のダウンロードが必要な状況において（二重化されたオペレーションファームウェアの両方が破損し且つリカバリ不能の場合）、従来のように人手を介することなく自動的に、ダウンロードが行われる。
【０１２８】
尚、ステップＳ１２がＹＥＳの場合またはステップＳ６０の後における“ブート本体処理”としてのダウンロード処理は、上位機１からのダウンロード指示が無くても直ちに、当該図１０のダウンロード処理を実行するようにしてもよい。
【０１２９】
あるいは、ステップＳ１２がＹＥＳの場合またはステップＳ６０の後における“ブート本体処理”としてのダウンロード処理は、まず最初に、上位機１に対してＦＷダウンロード領域６２にオペレーションファームウェアを転送・格納する処理を要求するようにしてもよい。この場合、上位機１は、オペレーションファームウェアを転送後、上記ダウンロード指示を出すことになり、これによって図１０のダウンロード処理を開始することになる。
【０１３０】
図１０の処理は、概略的には、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に転送・格納されたオペレーションファームウェアについて、所定のチェック処理を実行し、チェックＯＫであれば、このオペレーションファームウェアを外部フラッシュＲＯＭ１４にダウンロードすると共に、これを新たなカレント側のオペレーションファームウェアとするものである。
【０１３１】
図１０の処理では、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されたオペレーションファームウェアについて、ステップＳ９１〜Ｓ９５の所定のチェック処理を行う。このステップＳ９１，Ｓ９２，Ｓ９３，Ｓ９４，Ｓ９５の処理におけるチェックに関する処理自体は、上記ステップＳ２１，Ｓ２２，Ｓ２３，Ｓ２４，Ｓ２７と略同様の処理である。
【０１３２】
すなわち、まず、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されたオペレーションファームウェアのヘッダ部４０が正常か否か（破損していないか）を判定する為、このヘッダ部４０のＳＵＭを算出し（ステップＳ９１）、算出したＳＵＭが当該ヘッダ部４０のヘッダＳＵＭ４６と一致するか否かを判定する（ステップＳ９２）。不一致の場合には（ステップＳ９２，ＮＯ）、転送・格納されたオペレーションファームウェアを外部フラッシュＲＯＭ１４に書込むことはなく（ダウンロードすることなく）、そのヘッダ部４０が破損している旨を、上位機１へ通知する（ステップＳ１００）。
【０１３３】
一方、一致する場合、すなわちヘッダ部４０に異常がない場合には（ステップＳ９２，ＹＥＳ）、続いて、プログラム部５０についても正常か否か（破損していないか）を判定する。これは、プログラム部５０の各プログラムブロック５１毎に行う。すなわち、各プログラムブロック５１毎に、そのプログラムブロック５１のＳＵＭを算出し（ステップＳ９３）、算出したＳＵＭ値がそのプログラムブロック５１に対応するプログラムブロックＳＵＭ４５の値と一致するか否かを判定する（ステップＳ９４）。一致する場合はそのプログラムブロック５１は正常である（破損していない）ことになる（ステップＳ９４，ＹＥＳ）。そして、全てのプログラムブロック５１について上記チェックを完了したら（ステップＳ９５，ＹＥＳ）、ステップＳ９６の処理へ移行する。
【０１３４】
もし、１つでも破損しているプログラムブロック５１があった場合には（ステップＳ９４，ＮＯ）、ダウンロードされたオペレーションファームウェアを外部フラッシュＲＯＭ１４に書込むことはなく、そのプログラム部５０が破損している旨を、上位機１へ通知する（ステップＳ１００）。
【０１３５】
一方、未だ全てのプログラムブロック５１について処理完了していなければ（ステップＳ９５，ＮＯ）、ステップＳ９３に戻り、次のプログラムブロック５１について同様の処理を実行する。
【０１３６】
ステップＳ９６以降の処理では、まずバックアップステータス３２を“バックアップなし（0）”に設定してから（ステップＳ９６）、カレントＦＷ格納領域番号３３を参照して上記外部フラッシュＲＯＭ１４における非カレント領域を認識し、この非カレント領域に、ＳＤＲＡＭ１５のＦＷダウンロード領域６２に格納されているオペレーションファームウェア全体をダウンロードする（ステップＳ９７）。
【０１３７】
ダウンロード完了したら、カレントＦＷ格納領域番号３３にダウンロードした領域の番号を設定する（ステップＳ９８）。つまり、上記非カレント領域をカレント領域とする。そして、動作ステータス３１を“運用中（0）”に設定する（ステップＳ９９）。
【０１３８】
そして、ダウンロード処理の結果を上位機１に通知する（ステップＳ１００）。
その後、図４の処理が実行されると、上記起動処理が実行され、上記ダウンロードされたオペレーションファームウェアがカレント側としてチェック処理を受けて、正常であれば（上記の通り、ダウンロード時にチェックを行っているので正常のはずであるが）、非カレント側が異常であるか否かに関わらず、非カレント領域にも上記ダウンロードされたオペレーションファームウェアが記憶されることになり、バックアップステータス３２を“バックアップあり（１）”の状態になることになる。
【０１３９】
なお、ブートファームウェアでオペレーションファームウェアをバックアップ(二重化)しない理由は、正当なＳＵＭを持っているものの、起動後、直ちにシステムダウンしてしまうような誤ったプログラムがダウンロードされた場合を考慮しているからである。つまり、この様な場合、ブートファームウェアが上記ダウンロード処理の際にオペレーションファームウェアをバックアップ(二重化)すると、上記誤ったプログラムが二重化されることになり、機器が起動しなくなってしまうからである。
【０１４０】
本手法では、この様な事態を回避するために、ダウンロードされ正常動作したオペレーションファームウェアが、自身の二重化の為の処理を行うようにしている（特許文献１の作用等に記載あり）。もし、これが上記誤ったプログラムであった場合には、正常動作しないので、二重化が行われないことになり、機器が起動しなくなる事態を回避できる。
【０１４１】
以上説明したように、本手法によれば、以下の効果が得られる。
不揮発性メモリに二重化して記憶したファームウェアが両方とも破損した場合、従来の方法では、ファームウェアの破損状態に関わらず、装置を起動できない事態が発生してしまっていたが、本手法によりこの様な状態に陥る可能性を大幅に低減すことができる。
【０１４２】
組込み機器は必ず装置を起動することが重要であるが、リソースとの兼ね合いもあり、二重化を三重化にするといった対策は現実的には難しいため、二重化において、装置が起動しない状態になる可能性を低減する効果は大きい。
【０１４３】
また、従来、二重化したファームウェアの一部が破損した場合でも、起動したファームウェアの全領域を複製するようにしていたが、本発明は、必要な領域(破損ブロック)のみを複製するため、リカバリに要する時間を短縮することができ、装置の起動時間への影響を微小にすることができる。
【０１４４】
尚、本手法と上記特許文献２の発明とを比較すると、両者は発想が全く逆である。つまり、まず、本手法ではプログラム（ファームウェア）を対象にしているのに対して、上記特許文献２ではデータを対象にしているという違いがあるが、ここでは特許文献２の実データは本手法のプログラム（ファームウェア）に相当するものと考えてもよいものとする。この場合、特許文献２における図７のメモリ構成は、本手法における従来技術のメモリ構成と似ていると考えることもできる。つまり、特許文献２における図７に示す例えばデータ１１Ａ１ｄが、本手法のプログラム（ファームウェア）に相当することになる。特許文献２における図７ではデータ１１Ａ１ｄ〜データ１１Ａｎｄのｎ個のデータが格納されているので、これはｎ個のプログラム（ファームウェア）が格納されていることに相当することになる。
【０１４５】
そして、特許文献２における図７に示すメモリ構成では、各データ毎にチェックサムデータが格納されており（例えばデータ１１Ａ１ｄに対してチェックサムデータ１１Ａ１ｃ）、チェックサムデータを用いてデータの異常チェックを行うが、この点も本手法における従来技術と似ている。
【０１４６】
しかしながら、特許文献２においてはデータは数バイト程度である為、データの一部に破損が生じた場合でも、そのデータ全体についてリカバリを行うことに特に問題はない（処理時間が掛かるものではない）。むしろ、上記従来技術で説明した通り、特許文献２の発明は、１つのブロックに複数のデータをまとめて、一部のデータに異常が生じた場合でもブロック内の全データについて修正を行うようにしている。これは、上記の通り各データのデータ量が非常に少ないので、この様にしても特に問題はない（処理時間が掛かるものではない）ものと考えられる。
【０１４７】
一方、本手法では、プログラム（ファームウェア）が対象であり、そのデータ量が大きい為、例えば上記数バイトから成るデータを例えば１バイト単位で分割・管理すること（１バイト単位で異常の有無の判定やリカバリを行うこと）に相当する事を行っている。この様な発想は特許文献２には無い（上記の通り、むしろ逆の発想となっている）。よって、当然、特許文献２に基づいて本手法を想到することはできないし、特許文献２の発明やその従来技術では本手法の効果は得られない。
【符号の説明】
【０１４８】
１ 上位機
１０ 組込み機器
１１ ＣＰＵ
１２ ＲＡＭ
１３ 内蔵フラッシュＲＯＭ
１４ 外部フラッシュＲＯＭ
１５ ＳＤＲＡＭ
２１ 管理情報格納領域
２２ ＦＷ格納領域
３１ 動作ステータス
３２ バックアップステータス
３３ カレントＦＷ格納領域番号
３４ 破損ブロック番号
４０ ヘッダ部
４１ 名称
４２ バージョン
４３ ヘッダサイズ
４４ プログラムサイズ
４５ プログラムブロックＳＵＭ
４６ ヘッダＳＵＭ
５０ プログラム部
５１ プログラムブロック
６１ ＦＷブート領域
６２ ＦＷダウンロード領域
【特許請求の範囲】
【請求項１】
ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置であって、
前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、
前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、
前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、
前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、
前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段と、
を有することを特徴とするファームウェア保護装置。
【請求項２】
前記二重化されたファームウェアが両方とも破損した場合、
前記リカバリ手段は、一方のファームウェアをリカバリ対象として、該リカバリ対象のファームウェアに関する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムが、破損しているか否かをチェックし、他方のファームウェアにおいても破損している場合にはリカバリ不能とし、破損していない場合には該他方のファームウェアにおける分割プログラムを用いて前記破損した分割プログラムをリカバリすることを特徴とする請求項１記載のファームウェア保護装置。
【請求項３】
ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置のコンピュータを、
前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、
前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、
前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、
前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、
前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段、
として機能させる為のプログラム。
【請求項１】
ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置であって、
前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、
前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、
前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、
前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、
前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段と、
を有することを特徴とするファームウェア保護装置。
【請求項２】
前記二重化されたファームウェアが両方とも破損した場合、
前記リカバリ手段は、一方のファームウェアをリカバリ対象として、該リカバリ対象のファームウェアに関する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムが、破損しているか否かをチェックし、他方のファームウェアにおいても破損している場合にはリカバリ不能とし、破損していない場合には該他方のファームウェアにおける分割プログラムを用いて前記破損した分割プログラムをリカバリすることを特徴とする請求項１記載のファームウェア保護装置。
【請求項３】
ファームウェアを二重化して記憶して、該ファームウェアの何れか一方を起動して実行させる装置のコンピュータを、
前記二重化された各ファームウェアを、それぞれ、固定長ブロックに分割して成る分割プログラム群として記憶するプログラム記憶手段と、
前記各分割プログラム毎に対応して、その分割プログラムのチェックサムを記憶するチェックサム記憶手段と、
前記各分割プログラム毎に対応して破損しているか否かを示す管理情報を記憶する管理情報記憶手段と、
前記各ファームウェア毎に、それが破損しているか否かをその各分割プログラム毎に前記チェックサムを用いてチェックして、該チェック結果により前記管理情報を更新するチェック手段と、
前記ファームウェアが破損した場合、該破損したファームウェアに対応する前記管理情報を参照して破損した分割プログラムを認識し、他方のファームウェアにおける該破損した分割プログラムに対応する分割プログラムを用いて、該破損した分割プログラムをリカバリするリカバリ手段、
として機能させる為のプログラム。
【図１】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【公開番号】特開２０１１−５３９８４（Ｐ２０１１−５３９８４Ａ）
【公開日】平成２３年３月１７日（２０１１．３．１７）
【国際特許分類】
【出願番号】特願２００９−２０３１２６（Ｐ２００９−２０３１２６）
【出願日】平成２１年９月２日（２００９．９．２）
【出願人】（０００００５２３４）富士電機ホールディングス株式会社 (3,146)
【Ｆターム（参考）】
【公開日】平成２３年３月１７日（２０１１．３．１７）
【国際特許分類】
【出願日】平成２１年９月２日（２００９．９．２）
【出願人】（０００００５２３４）富士電機ホールディングス株式会社 (3,146)
【Ｆターム（参考）】
[ Back to top ]