JP2004102893A

JP2004102893A - Remote downloader and remote download method

Info

Publication number: JP2004102893A
Application number: JP2002266793A
Authority: JP
Inventors: Kenjiro Morihisa; 森久　謙二郎
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2002-09-12
Filing date: 2002-09-12
Publication date: 2004-04-02

Abstract

<P>PROBLEM TO BE SOLVED: To start a target system after reset and to constantly secure a remote download function even when a failure due to a channel trouble, power interruption and a malfunction of a starting remote downloader itself, etc. is caused. <P>SOLUTION: Two surfaces of FDP storage areas are prepared on a flash ROM 102, pieces of starting surface judgment information are prepared on each surface and an FDP appropriately controls pieces of the starting surface judgment information on each surface. Thus, the target system after the reset can be started even when the failure due to the channel trouble, the power interruption and the malfunction of the starting FDP itself, etc., is caused during remote download processing, especially of the FDP itself and a remote download function is constantly secured basically without requiring a special memory except the flash ROM. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば移動体通信システムにおける基地局に適用され、上位装置が保持するプログラムをターゲットシステムに通信路を介してダウンロードし、プログラムのバージョンアップを遠隔操作により実現するリモートダウンローダ及びリモートダウンロード方法に関する。
【０００２】
【従来の技術】
従来、この種のリモートダウンローダ及びリモートダウンロード方法としては、特開平１１―４５１８２号公報で開示されたものが知られている。この公報で開示された従来の技術では、リモートダウンローダがリセット時に自分自身をフラッシュＲＯＭ上からＲＡＭ上に展開し動作する。ＲＡＭ上で動作しているリモートダウンローダは、バージョンアップが必要な時に上位装置から新しいバージョンのリモートダウンローダをダウンロードし、フラッシュＲＯＭ上の古いバージョンのリモートダウンローダに対して上書きすることにより、バージョンアップを実現する。
【０００３】
また、フラッシュＲＯＭ上に２面リモートダウンローダ格納領域を確保しているリモートダウンローダ及びリモートダウンロード方法としては、特開２０００―１６３２６８号公報で開示されたものが知られている。この公報で開示された従来の技術では、フラッシュＲＯＭとは別に読み書き可能な不揮発性メモリであるＮＶＲＡＭを用意し、このＮＶＲＡＭ上に起動するリモートダウンローダの面に関する情報を格納し制御することにより、リモートダウンローダの２面管理を実現している。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記特開平１１―４５１８２号公報に記載された従来のリモートダウンローダ及びリモートダウンロード方法においては、現在起動しているリモートダウンローダが格納されていたフラッシュＲＯＭ上のリモートダウンローダ格納エリアに直接新しいバージョンのリモートダウンローダが上書きされるので、新しいバージョンのリモートダウンローダに問題が有る場合、これ以降のリセットに対してターゲットシステムが起動できないという問題がある。
【０００５】
ターゲットシステムが移動体通信システムにおける基地局である場合を考えると、ターゲットシステムが起動しないということは、基地局の存在する現地に技術者が実際に赴く必要があることを意味する。しかし、基地局は全国各地に膨大な数存在し、中には山間部等現地に技術者が実際に赴くことが困難である場合も少なくない。バージョンアップ作業を含め、リモートメンテナンスを基本とする移動体通信システムにとっては、ターゲットシステムが起動できないという事態は絶対に避けなければならなく、いかなるケースにおいても、ターゲットシステムが起動可能であり、リモートダウンロード機能が確保されていることが重要である。
【０００６】
新しいバージョンのリモートダウンロードプログラムに問題が生じるケースとしては、下記３つのケースが考えられる。
１つ目のケースとしては、上位装置１０１とターゲットシステム１００の間の通信路２００に通信路障害等が発生し、新しいバージョンのリモートダウンローダのプログラムの一部にビット化けが生じている。
【０００７】
２つ目のケースとしては、リモートダウンロード中に、上位装置１０１またはターゲットシステム１００で停電等の理由による電源断が発生し、リモートダウンロード処理が途中で中断し、新しいバージョンのリモートダウンローダの一部分が存在しない。
３つ目のケースとしては、そもそも新しいバージョンのリモートダウンローダに不具合が存在し、プログラムの暴走等の障害が発生する。３つ目のケースについては、本来、運用で解決しなければならない課題であり、本来起こってはいけないケースである。
【０００８】
しかし、近年の開発サイクルの短縮化に伴い、開発のスピードアップは必須で、開発工程とテスト工程が並行に行われ、膨大な数のプログラムバージョンが存在するのも事実であり、間違えて不具合のあるリモートダウンローダを新しいバージョンとして上位装置に設定してしまった等の上位装置運用者の運用（人為）ミスが絶対に起こらないとは言い切れない。また、プログラムリリース後に、ターゲットシステムが起動できなくなる等の致命的な不具合がリモートダウンローダに絶対に存在しないとも言い切れない。更に、３つ目のケースが発生した場合、ターゲットシステムが起動できないという問題は、上位装置配下の全てのターゲットシステムに及ぶ。以上より、３つ目のケースについても、ターゲットシステムの１機能として実装することが望まれる。
【０００９】
また、特開２０００―１６３２６８号公報で開示された従来のリモートダウンローダ及びリモートダウンロード方法においては、上記２つ目のケースが発生した場合については、ターゲットシステムが起動できないという問題を回避できるが、上記１つ目及び３つ目のケースが発生した場合は、ターゲットシステムを起動できないという問題が発生する。また、フラッシュＲＯＭの他に、高価なＮＶＲＡＭを必要とし、ターゲットシステムの複雑化及びコストアップにつながることがあげられる。
【００１０】
本発明は、上記従来の問題を解決するもので、新しいバージョンのリモートダウンロードプログラムに不具合が生じた際のターゲットシステムの起動を可能にする２面管理管理方式を簡易に実現することができるリモートダウンローダ及びリモートダウンロード方法を提供することを目的とする。また、新しいバージョンのリモードダウンロードプログラムに対して上記３つのケースのいずれが発生しても、特に３つ目のケースが発生してもリセット後ターゲットシステムが起動可能であり、リモートダウンロード機能を常に確保することができるリモートダウンローダ及びリモートダウンロード方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
請求項１に係る発明のリモートダウンローダは、自身をリモートダウンロードする機能を有する電子機器を制御するプログラムを、リモートダウンロードを実施するリモートダウンロードプログラムと前記電子機器を制御するメインとなる制御プログラムの２つに分割し、それぞれ独立してリモートダウンロードすることを特徴とする。
【００１２】
この構成によれば、フラッシュＲＯＭ上に２面管理するのはリモートダウンローダのみで、制御ソフトについては１面管理となるので、フラッシュＲＯＭ容量を必要最小限に抑えて２面管理方式を実現することができる。
【００１３】
請求項２に係る発明のリモートダウンローダは、請求項１に係る発明のリモートダウンローダにおいて、フラッシュＲＯＭに前記リモートダウンロードプログラムを格納するＡ面及びＢ面の２つのリモートダウンローダ格納領域が設定されるとともに、それぞれの面のリモートダウンローダ格納領域内に、起動するリモートダウンローダの起動面に関する情報を格納する起動面判定情報が設定され、それぞれのリモートダウンローダ格納領域内の起動面判定情報のみにより起動面を判定することを特徴とする。
【００１４】
この構成によれば、フラッシュＲＯＭ以外の特別な装置（メモリ等）を必要とせず、容易に２面管理方式を実現することができる。
【００１５】
請求項３に係る発明のリモートダウンローダは、請求項２に係る発明のリモートダウンローダにおいて、ＲＡＭにバージョンアップ判定に関する情報を格納するバージョンアップ判定情報が設定され、前記２つのリモートダウンローダ格納領域内の起動面判定情報に加えて、前記バージョンアップ判定情報により起動面を判定することを特徴とする。
【００１６】
この構成によれば、起動処理の短縮を目的としたフラッシュＲＯＭへのファームウェア遅延書き込みや、リモートダウンローダの自律再起動といった、よりきめ細かな２面管理方式を実現することができる。
【００１７】
請求項４に係る発明のリモートダウンローダは、請求項３に係る発明のリモートダウンローダにおいて、前記リモートダウンロードプログラムを前記フラッシュＲＯＭから前記ＲＡＭへ展開するために最低限必要なブート処理とその他残りのブート処理を実施するブート手段と、起動面判定情報よりリモートダウンローダの起動面を判定するリモートダウンローダ起動面判定手段と、前記リモートダウンローダ起動面判定手段からの要求により、リセットされるのを待ち続けるリセット待ち手段と、リモートダウンローダ起動面からリモートダウンローダを展開し、展開したリモートダウンローダのエントリポイントに分岐するリモートダウンローダ展開手段と、起動面判定情報の報告及びバージョンアップに伴う起動面判定情報の更新を行う起動面判定情報管理手段と、バージョン情報の報告及びバージョン情報の更新を行うバージョン情報管理手段と、ダウンロードされたファームウェアを前記フラッシュＲＯＭに格納し、前記起動面判定情報管理手段にバージョンアップに伴う起動面判定情報の更新を指示し、前記バージョン情報管理手段にバージョンアップに伴うバージョン情報の更新を指示するファームウェアバージョンアップ手段と、ファームウェアのバージョンアップを管理するファームウェアバージョンアップ管理手段と、前記ファームウェアバージョンアップ管理手段からの指示により上位装置からファームウェアをダウンロードするファームウェアダウンロード手段と、前記ファームウェアバージョンアップ管理手段からの指示により、指示された制御ソフト起動面から制御プログラムを前記ＲＡＭ上に展開し、制御プログラムのエントリポイントに分岐する制御ソフト展開手段とを具備し、前記リモートダウンローダ起動面判定手段は、前記ブート手段にて最低限必要なブート処理が行われた後、前記起動面判定情報管理手段からの起動面判定情報の報告よりリモートダウンローダの起動面を判定し、正常に判定できた場合は判定結果を前記リモートダウンローダ展開手段に報告し、正常に判定できなかった場合は前記リセット待ち手段にリセット待ちを要求し、前記起動面情報判定管理手段は、前記リモートダウンローダ起動面判定手段からの要求により起動面判定情報を報告し、前記ファームウェアバージョンアップ手段からの指示により、バージョンアップに伴う起動面判定情報の更新を実施し、前記バージョン情報管理手段は、前記ファームウェアバージョンアップ管理手段からのバージョン情報報告要求によりバージョン情報を報告するとともに前記ファームウェアバージョンアップ手段からの要求によりバージョン情報を更新し、前記ファームウェアバージョンアップ管理手段は、前記バージョン情報管理手段から報告されたファームウェアのファームウェアバージョン情報を前記上位装置に報告し、前記上位装置に対してファームウェアバージョンアップの必要性を問い合わせ、前記上位装置より必要との指示を受けた場合はファームウェアダウンロード手段を経由してファームウェアダウンロードを実施し、ファームウェアダウンロード直後にファームウェアダウンロード処理の合否を判断し、失敗と判断した場合はバージョンアップ処理を中止して前記制御ソフト展開手段に制御プログラムの展開を要求し、ファームウェア内リモートダウンローダのバージョンアップの必要性については前記バージョン情報管理手段から報告されたリモートダウンローダのリモートダウンローダ個別バージョン情報とダウンロードしたファームウェア内のリモートダウンローダ個別バージョン情報より判定し、必要と判定した場合は前記ファームウェアバージョンアップ手段にリモートダウンローダのバージョンアップを要求し、同様にファームウェア内の制御プログラムのバージョンアップの必要性をリモートダウンローダと同様の方法で判定し、必要と判定した場合は前記ファームウェアバージョンアップ手段に制御プログラムのバージョンアップを要求し、前記上位装置にバージョンアップ結果を報告し、前記制御ソフト展開手段に制御ソフトの展開を要求し、前記ファームウェアバージョンアップ手段は、前記ファームウェアバージョンアップ管理手段からの指示により、ダウンロードしたファームウェアを前記フラッシュＲＯＭに格納し、前記起動面判定情報管理手段にバージョンアップに伴う起動面判定情報の更新を指示し、前記バージョン情報管理手段にバージョンアップに伴うバージョン情報の更新を指示することを特徴とする。
【００１８】
この構成によれば、特にリモートダウンローダ自身のリモートダウンロード処理中に、リモートダウンローダが起動面判定情報を適切に制御し、通信路障害、電源断の障害が発生しても、リセット後ターゲットシステムは起動可能であり、常にリモートダウンロード機能を確保することができる。
【００１９】
請求項５に係る発明のリモートダウンローダは、請求項４に係る発明のリモートダウンローダにおいて、前記起動面判定情報管理手段は、リモートダウンローダのバージョンアップを実施するフラッシュＲＯＭ上のリモートダウンローダ格納領域のバージョンアップ対象面を起動面の次の面であるＡ面に対してはＢ面又はＢ面に対してはＡ面として管理し、リモートダウンローダのバージョンアップに伴うバージョンアップ対象面のイレーズ及びリモートダウンローダの書込を完了した際に現在の起動面の起動面判定情報を参照し、現在のバージョンアップ対象面が次回起動時の起動面と判定されるように現在のバージョンアップ対象面の起動面判定情報を書き換えることを特徴とする。
【００２０】
この構成によれば、起動面の判定を、フラッシュＲＯＭ上の起動面判定情報のみで実施するので、フラッシュＲＯＭ以外の特別な装置（メモリ）を必要とせず、容易に２面管理方式を実現することができる。
【００２１】
請求項６に係る発明のリモートダウンローダは、請求項５に係る発明のリモートダウンローダにおいて、現在の起動面の起動面判定情報を参照し、現在のバージョンアップ対象面が次回起動時の起動面と判定されるように現在のバージョンアップ対象面の起動面判定情報を書き換える方法として「じゃんけん」論理を適用し、起動時の起動面判定においては「じゃんけん」に「勝った」方が起動面と判定されることとして、現在の起動面の起動面判定情報を「先出し」、現在のバージョンアップ対象面の起動面判定情報を「後出し」と例え、「先出し」の論理に対して「勝つ」ように「後出し」の論理を決定し、前記起動面判定情報管理手段は、現在のバージョンアップ対象面の起動面判定情報を書き換えることを特徴とする。
【００２２】
この構成によれば、「じゃんけん」という非常に簡単なロジックを使用して、容易に起動面の判定処理を実現することができる。
【００２３】
請求項７に係る発明のリモートダウンローダは、請求項４から請求項６のいずれかに係る発明のリモートダウンローダにおいて、前記起動面判定情報管理手段は、リモートダウンローダのバージョンアップに伴うバージョンアップ対象面のイレーズを実施する直前に、バージョンアップ対象面の起動面判定情報の全ビットを“０”に設定するを具備することを特徴とする。
【００２４】
この構成によれば、フラッシュＲＯＭの特性を利用することにより、容易にフラッシュＲＯＭのイレーズ処理及び書き込み処理完了状況を判定することができる。
【００２５】
請求項８に係る発明のリモートダウンローダは、請求項４から請求項７のいずれかに係る発明のリモートダウンローダにおいて、モートダウンロード処理におけるソフトウェア不具合等の処理異常を検出し、前記起動面判定情報管理手段に起動面判定情報の制御を要求し、前記リセット待ち手段にリセット待ちを要求するリモートダウンローダプログラム障害検出手段を具備し、前記起動面判定情報管理手段は、前記リモートダウンローダプログラム障害検出手段からの起動面判定情報の制御要求により、現起動面が次起動面と判定されないように現起動面の起動面判定情報を書き換え、前記リモートダウンローダ起動面判定手段は、前記起動面判定情報管理手段から報告される、書き換えられた起動面判定情報より、前回起動した起動面を現在の起動面と判定しないことを特徴とする。
【００２６】
この構成によれば、特にリモートダウンローダ自身のリモートダウンロード処理中に、リモートダウンローダが起動面判定情報を適切に制御し、通信路障害、電源断の障害に加えて、起動しているリモートダウンローダ自身の不具合等によるプログラム暴走等の障害が発生しても、リセット後ターゲットシステムは起動可能であり、常にリモートダウンロード手段を確保することができる。
【００２７】
請求項９に係る発明のリモートダウンローダは、請求項４から請求項８のいずれかに係る発明のリモートダウンローダにおいて、前記リモートダウンローダ起動面判定手段は、システム初期立ち上げ時、Ａ面であるリモートダウンローダ格納領域にリモートダウンローダが格納されていれば、当該リモートダウンローダ格納領域の起動面判定情報及びＢ面のリモートダウンローダ格納領域全体の全ビットが“１”であるフラッシュＲＯＭにおけるイレーズ完了状態であっても、その後のシステム運用における起動面の判定処理を正常に実施することを特徴とする。
【００２８】
この構成によれば、システム初期立ち上げ時にフラッシュＲＯＭ全体をイレーズ後、Ａ面のみにリモートダウンロードプログラムを書き込めばシステム初期立ち上げ可能であり、両面の起動面判定情報に正常な値を書き込むといった作業や、Ｂ面にリモートダウンロードプログラムを書き込むといった作業は不要となる。
【００２９】
請求項１０に係る発明のリモートダウンローダは、請求項４から請求項９のいずれかに係る発明のリモートダウンローダにおいて、前記ブート手段及び前記リモートダウンローダ起動面判定手段及び前記ファームウェアバージョン管理手段からのバージョンアップ判定情報の制御要求によりバージョンアップ判定情報を制御し、前記ファームウェアバージョン管理手段からのバージョンアップ判定情報の報告要求に対してバージョンアップ判定情報を報告するバージョンアップ判定情報管理手段を具備し、前記ブート手段は、リモートダウンロードプログラムを前記フラッシュＲＯＭから前記ＲＡＭへ展開するために最低限必要なブート処理と、その他残りのブート処理を実施し、バージョンアップ判定情報の初期化を前記バージョンアップ判定情報管理手段に要求し、前記リモートダウンローダ起動面判定手段は、前記ブート手段による最低限必要なブート処理後、前記起動面判定情報管理手段からの起動面判定情報の報告よりリモートダウンローダの起動面を判定し、正常に判定できた場合はその判定結果を前記リモートダウンローダ展開手段と前記バージョンアップ判定情報管理手段に報告し、正常に判定できなかった場合は前記リセット待ち手段にリセット待ちを要求し、前記ファームウェアバージョンアップ管理手段は、前記バージョン情報管理手段から報告されたファームウェアバージョン情報を前記上位装置に報告し、前記上位装置に対してファームウェアバージョンアップの必要性を問い合わせ、前記上位装置より必要との指示を受けた場合は前記ファームウェアダウンロード手段を経由してファームウェアダウンロードを実施し、ファームウェアダウンロード処理の合否を確認し、失敗と判断された場合はバージョンアップ処理を中止し、前記制御ソフト展開手段に制御プログラムの展開を要求し、ファームウェア内リモートダウンローダのバージョンアップの必要性については前記バージョン情報管理手段から報告されたリモートダウンローダ個別バージョン情報とダウンロードしたファームウェア内のリモートダウンローダ個別バージョン情報より判定しその判定結果を前記バージョンアップ判定情報管理手段に報告し、同様にファームウェア内制御プログラムのバージョンアップの必要性をリモートダウンローダと同様の方法で判定しその判定結果を前記バージョンアップ判定情報管理手段に報告し、必要と判定された場合は前記制御ソフト展開手段にダウンロードしたファームウェアを一時的に格納しているＲＡＭ上の領域であるファームウェア一次格納領域からの制御プログラムの展開を要求し、不要と判定された場合は前記制御ソフト展開手段にフラッシュＲＯＭ上の制御ソフト面からの制御プログラムの展開を要求し、制御ソフト起動後前記バージョンアップ判定情報管理手段からの報告により、リモートダウンローダ処理においてリモートダウンローダのバージョンアップ必要と判定されていた場合は前記ファームウェアバージョンアップ手段にリモートダウンローダのバージョンアップを要求し、同様にリモートダウンローダ処理において制御プログラムのバージョンアップ必要と判定されていた場合は前記ファームウェアバージョンアップ手段に制御プログラムのバージョンアップを要求し、正常にリモートダウンローダ又は制御プログラムのバージョンアップの必要性が判定されていなかった場合は前記リセット待ち手段にリセット待ちを要求し、前記上位装置にバージョンアップ結果を報告することを特徴とする。
【００３０】
この構成によれば、起動時にファームウェアのフラッシュＲＯＭへの書き込み処理を実施する必要が無くなり、起動後、メインとなる制御処理に影響を与えないような低優先度の処理としてファームウェアのフラッシュＲＯＭへの書き込み処理を実施することにより、メインとなる制御処理開始までの起動時間を大幅に短縮することができる。
【００３１】
請求項１１に係る発明のリモートダウンローダは、請求項４から請求項１０のいずれかに係る発明のリモートダウンローダにおいて、前記ファームウェアバージョンアップ管理手段からの報告によりファームウェア内リモートダウンローダのバージョンアップ必要と判定された場合、リモートダウンローダの自律再起動処理を行う自律再起動手段を具備し、前記リモートダウンローダ起動面判定手段は、前記ブート手段による最低限必要なブート処理後、前記起動面判定情報管理手段からの起動面判定情報の報告と前記バージョンアップ判定情報管理手段からのバージョンアップ判定情報の報告よりリモートダウンローダの起動面を判定し、正常に判定できた場合はその判定結果を前記リモートダウンローダ展開手段と前記バージョンアップ判定情報管理手段に報告し、正常に判定できなかった場合は前記リセット待ち手段にリセット待ちを要求し、前記リモートダウンローダ展開手段は、前記リモートダウンローダ起動面判定手段からのリモートダウンローダ起動面の報告よりファームウェア一次格納領域からの展開を報告された場合はファームウェア一次格納領域上のリモートダウンロードプログラムを展開し、フラッシュＲＯＭ上のリモートダウンローダ格納領域からの展開を報告された場合は報告されたリモートダウンローダ格納領域の起動面からリモートダウンロードプログラムを展開し、展開したリモートダウンロードプログラムのエントリポイントに分岐し、前記ファームウェアバージョンアップ管理手段は、前記バージョンアップ判定情報管理手段からのバージョンアップ判定情報よりファームウェアバージョンアップ判定実施不要と判定された場合は、前記上位装置からのファームウェアダウンロード処理及びファームウェアバージョンアップの必要性判定を実施せず、ファームウェアバージョンアップ判定実施必要と判定された場合は、前記バージョン情報管理手段から報告されたファームウェアのバージョン情報を前記上位装置に報告し、前記上位装置に対してファームウェアバージョンアップの必要性を問い合わせ、前記上位装置より必要との指示を受けた場合は、前記ファームウェアダウンロード手段を経由してファームウェアダウンロードを実施し、ファームウェアダウンロード処理の合否を確認し、失敗と判断した場合はバージョンアップ処理を中止し、前記制御ソフト展開手段に制御プログラムの展開を要求し、ファームウェア内リモートダウンローダのバージョンアップの必要性については、前記バージョン情報管理手段から報告されたリモートダウンローダ個別バージョン情報とダウンロードしたファームウェア内のリモートダウンローダ個別バージョン情報より判定し、その判定結果を前記バージョンアップ判定情報管理手段に報告し、必要と判定された場合は前記自律再起動手段にリモートダウンローダの自律再起動を要求し、同様にファームウェア内制御ソフトのバージョンアップの必要性をリモートダウンローダと同様の方法で判定し、その判定結果を前記バージョンアップ判定情報管理手段に報告し、必要と判定された場合は前記制御ソフト展開手段に前記ＲＡＭ上の一次格納面からの制御プログラムの展開を要求し、不要と判定された場合は、前記制御ソフト展開手段に前記フラッシュＲＯＭ上の制御ソフト面からの制御プログラムの展開を要求し、制御ソフト起動後、前記バージョンアップ判定情報管理手段からの報告によりリモートダウンローダ処理においてリモートダウンローダのバージョンアップ必要と判定されていた場合は、前記ファームウェアバージョンアップ手段にリモートダウンローダのバージョンアップを要求し、同様にリモートダウンローダ処理において制御プログラムのバージョンアップ必要と判定されていた場合は、前記ファームウェアバージョンアップ手段に制御プログラムのバージョンアップを要求し、正常にリモートダウンローダ又は制御プログラムのバージョンアップの必要性が判定されていなかった場合は、前記リセット待ち手段にリセット待ちを要求し、前記上位装置にバージョンアップ結果を報告することを特徴とする。
【００３２】
この構成によれば、リモートダウンロードプログラムをバージョンアップ後、リセット処理を実施することなく、バージョンアップしたリモートダウンロードプログラムを自律的に再起動することが可能となる。
【００３３】
請求項１２に係る発明のリモートダウンローダは、請求項４から請求項１１のいずれかに係る発明のリモートダウンローダにおいて、前記起動面判定情報管理手段は、起動面判定情報の各情報要素を、冗長ビットを持った複数ビット構成で管理することを特徴とする。
【００３４】
この構成によれば、メモリ装置の劣化等のハードウェア故障や、リモートダウンロードプログラムの不具合等のソフトウェア故障を、簡単な手段によって実現することができる。
【００３５】
請求項１３に係る発明のリモートダウンローダは、請求項４から請求項１１のいずれかに係る発明のリモートダウンローダにおいて、前記バージョンアップ判定情報管理手段は、バージョンアップ判定情報の各情報要素を、冗長ビットを持った複数ビット構成で管理することを特徴とする。
【００３６】
この構成によれば、メモリ装置の劣化等のハードウェア故障や、リモートダウンロードプログラムの不具合等のソフトウェア故障を、簡単な手段によって実現することができる。
【００３７】
請求項１４に係る発明の基地局装置は、請求項１から請求項１３のいずれかに係る発明のリモートダウンローダを具備することを特徴とする。
【００３８】
この構成によれば、無線通信装置において、上記いずれかと同様の作用効果を得ることができる。
【００３９】
請求項１５に係る発明のリモートダウンロード方法は、リモートダウンローダをフラッシュＲＯＭからＲＡＭへ展開するために最低限必要なブート処理を実施し、起動面判定情報よりリモートダウンローダの起動面を判定し、正常に判定できなかった場合はリセット待ちを行い、正常に判定できた場合は判定結果が示す起動面からリモートダウンローダを展開し、展開したリモートダウンローダのエントリポイントに分岐し、その他残りのブート処理を実施し、ファームウェアバージョン情報を上位装置に報告し、上位装置に対してファームウェアバージョンアップの必要性を問い合わせ、上位装置より必要との指示を受けた場合はファームウェアダウンロードを実施し、ファームウェアダウンロード処理の合否を確認し、失敗と判断された場合はバージョンアップ処理を中止して制御プログラムを展開し、ファームウェア内リモートダウンローダのバージョンアップの必要性については、リモートダウンローダ個別バージョン情報とダウンロードしたファームウェア内のリモートダウンローダ個別バージョン情報とより判定し、必要と判定された場合はリモートダウンローダのバージョンアップを実施し、バージョンアップに伴い起動面判定情報の更新及びバージョン情報の更新を行い、同様にファームウェア内制御プログラムのバージョンアップの必要性をリモートダウンローダと同様の方法で判定し、必要と判定された場合は制御プログラムのバージョンアップを実施し、バージョンアップに伴いバージョン情報の更新を行い、上位装置にファームウェアバージョンアップ結果を報告し、フラッシュＲＯＭから制御プログラムをＲＡＭ上に展開し、制御プログラムのエントリポイントに分岐することを特徴とする。
【００４０】
この方法によれば、特にリモートダウンローダ自身のリモートダウンロード処理中に、リモートダウンローダが起動面判定情報を適切に制御し、通信路障害、電源断の障害が発生しても、リセット後ターゲットシステムは起動可能であり、常にリモートダウンロード機能を確保することができる。
【００４１】
請求項１６に係る発明のリモートダウンロード方法は、請求項１５に係る発明のリモートダウンロード方法において、バージョンアップ対象面を起動面の次面として管理し、リモートダウンローダのバージョンアップに伴うバージョンアップ対象面のイレーズ及びリモートダウンローダの書込を完了した際に現起動面の起動面判定情報を参照し、現バージョンアップ対象面が次起動面と判定されるように現バージョンアップ対象面の起動面判定情報を書き換えることを特徴とする。
【００４２】
この方法によれば、起動面の判定を、フラッシュＲＯＭ上の起動面判定情報のみで実施するので、フラッシュＲＯＭ以外の特別な装置（メモリ）を必要とせず、容易に２面管理方式を実現することができる。
【００４３】
請求項１７に係る発明のリモートダウンロード方法は、請求項１５に係る発明のリモートダウンロード方法において、現起動面の起動面判定情報を参照し、現バージョンアップ対象面が次起動面と判定されるように現バージョンアップ対象面の起動面判定情報を書き換える方法として「じゃんけん」論理を適用し、起動時の起動面判定においては「じゃんけん」に「勝った」方が起動面と判定されることとして、現起動面の起動面判定情報を「先出し」、現バージョンアップ対象面の起動面判定情報を「後出し」と例え、「先出し」の論理に対して「勝つ」ように「後出し」の論理を決定し、現バージョンアップ対象面の起動面判定情報を書き換えることを特徴とする。
【００４４】
この方法によれば、「じゃんけん」という非常に簡単なロジックを使用して、容易に起動面の判定処理を実現することができる。
【００４５】
請求項１８に係る発明のリモートダウンロード方法は、請求項１５から請求項１７のいずれかに係る発明のリモートダウンロード方法において、モートダウンローダのバージョンアップに伴うバージョンアップ対象面のイレーズを実施する直前に、バージョンアップ対象面の起動面判定情報の全ビットを“０”に設定することを特徴とする。
【００４６】
この方法によれば、フラッシュＲＯＭの特性を利用することにより、容易にフラッシュＲＯＭのイレーズ処理及び書き込み処理完了状況を判定することができる。
【００４７】
請求項１９に係る発明のリモートダウンロード方法は、請求項１５から請求項１８のいずれかに係る発明のリモートダウンロード方法において、リモートダウンローダによるリモートダウンロード処理においてソフトウェア不具合等の処理異常を検出した際、現起動面が次起動面と判定されないように現起動面の起動面判定情報を書き換え、リセット待ちを行い、リセットされ次回起動時には、前起動面で前回起動時に異常が検出された面を現起動面と判定しないことを特徴とする。
【００４８】
この方法によれば、特にリモートダウンローダ自身のリモートダウンロード処理中に、リモートダウンローダが起動面判定情報を適切に制御し、通信路障害、電源断の障害に加えて、起動しているリモートダウンローダ自身の不具合等によるプログラム暴走等の障害が発生しても、リセット後ターゲットシステムは起動可能であり、常にリモートダウンロード機能を確保することができる。
【００４９】
請求項２０に係る発明のリモートダウンロード方法は、請求項１５から請求項１９のいずれかに係る発明のリモートダウンロード方法において、システム初期立ち上げ時、一方の面であるリモートダウンローダ格納領域にリモートダウンローダが格納されていれば、当該リモートダウンローダ格納領域の起動面判定情報及び他方の面であるリモートダウンローダ格納領域全体の全ビットがフラッシュＲＯＭにおけるイレーズ完了状態を示す“１”であっても、その後のシステム運用における起動面の判定処理を正常に実施することができることを特徴とする。
【００５０】
この方法によれば、システム初期立ち上げ時にフラッシュＲＯＭ全体をイレーズ後、Ａ面のみにリモートダウンロードプログラムを書き込めばシステム初期立ち上げ可能であり、両面の起動面判定情報に正常な値を書き込むといった作業や、Ｂ面にリモートダウンロードプログラムを書き込むといった作業は不要となる。
【００５１】
請求項２１に係る発明のリモートダウンロード方法は、請求項１５から請求項２０のいずれかに係る発明のリモートダウンロード方法において、リモートダウンローダをフラッシュＲＯＭからＲＡＭへ展開するために最低限必要なブート処理後、バージョンアップ判定情報の初期化を実施し、起動面判定情報よりリモートダウンローダの起動面を判定し、正常に判定できた場合は判定結果が示す起動面からリモートダウンローダを展開し、展開したリモートダウンローダのエントリポイントに分岐すると共に、判定結果を先程初期化したバージョンアップ判定情報に格納し、ファームウェア内リモートダウンローダのバージョンアップの必要性については、リモートダウンローダ個別バージョン情報と、ダウンロードしたファームウェア内のリモートダウンローダ個別バージョン情報より判定し、判定結果をバージョンアップ判定情報に格納し、同様にファームウェア内制御ソフトのバージョンアップの必要性をリモートダウンローダと同様の方法で判定し、その判定結果をバージョンアップ判定情報に格納し、バージョンアップ判定情報より制御プログラムのバージョンアップが必要と判定された場合は、ＲＡＭ上の一次格納面からの制御プログラムを展開し、不要と判定された場合は、フラッシュＲＯＭ上の制御ソフト面からの制御プログラムを展開し、制御ソフト起動後、バージョンアップ判定情報を参照し、リモートダウンローダ処理においてリモートダウンローダのバージョンアップ必要と判定されていた場合は、リモートダウンローダのバージョンアップを実施し、バージョンアップに伴い起動面判定情報の更新及びバージョン情報の更新を行い、同様に、バージョンアップ判定情報を参照し、リモートダウンローダ処理において制御プログラムのバージョンアップ必要と判定されていた場合は、制御プログラムのバージョンアップを実施し、バージョンアップに伴いバージョン情報の更新を行い、更にバージョンアップ情報を参照し、正常にリモートダウンローダまたは制御プログラムのバージョンアップの必要性が判定されていなかった場合は、リセット待ちを行うことを特徴とする。
【００５２】
この方法によれば、起動時にファームウェアのフラッシュＲＯＭへの書き込み処理を実施する必要が無くなり、起動後、メインとなる制御処理に影響を与えないような低優先度の処理としてファームウェアのフラッシュＲＯＭへの書き込み処理を実施することにより、メインとなる制御処理開始までの起動時間を大幅に短縮することができる。
【００５３】
請求項２２に係る発明のリモートダウンロード方法は、請求項１５から請求項２１のいずれかに係る発明のリモートダウンロード方法において、最低限必要なブート処理後、起動面判定情報とバージョンアップ判定情報よりリモートダウンローダの起動面を判定し、正常に判定でき且つファームウェア一次格納領域からの起動と判定された場合はファームウェア一次格納領域上のリモートダウンローダを展開し、バージョンアップ判定情報より、ファームウェアバージョンアップ判定実施不要と判定された場合は上位装置からのファームウェアダウンロード処理及びファームウェアバージョンアップの必要性判定を実施せず、ファームウェアバージョンアップ判定実施必要と判定された場合のみ上位装置からのファームウェアダウンロード処理及びファームウェアバージョンアップの必要性判定を実施し、上位装置からのファームウェアダウンロード処理及びファームウェアバージョンアップの必要性判定を実施した場合でリモートダウンローダ個別バージョンアップが必要と判定された場合はリモートダウンローダの自律再起動を実施し、リモートダウンローダ個別バージョンアップが不要と判定された場合は引き続きリモートダウンローダと同様の方法でファームウェア内制御ソフトのバージョンアップの必要性判定を実施することを特徴とする。
【００５４】
この方法によれば、リモートダウンロードプログラムをバージョンアップ後、リセット処理を実施することなく、バージョンアップしたリモートダウンロードプログラムを自律的に再起動することが可能となる。
【００５５】
請求項２３に係る発明のリモートダウンロード方法は、請求項１５から請求項２２のいずれかに係る発明のリモートダウンロード方法において、起動面判定情報の各情報要素を、冗長ビットを持った複数ビット構成で管理し、同様にバージョンアップ判定情報の各情報要素を、冗長ビットを持った複数ビット構成で管理する、の両方またはいずれかを実施することを特徴とする。
【００５６】
この方法によれば、メモリ装置の劣化等のハードウェア故障や、リモートダウンローダプログラムの不具合等のソフトウェア故障を簡単な手段によって実現することができる。
【００５７】
以下、本発明の実施の形態を説明する前に、図４８を用いてリモートダウンローダを実施するシステム概要を説明する。
【００５８】
リモートダウンロードは、プログラムバージョンアップを遠隔操作により実現することを目的として実施されるものであり、上位装置１０１とターゲットシステム１００との間で実施され、上位装置１０１が保持するプログラムをターゲットシステム１００にリモートダウンロードする。上位装置１０１とターゲットシステム１００は通信路を介して接続され、ターゲットシステム１００は少なくともＣＰＵ２０１、フラッシュＲＯＭ（不揮発性メモリ）１０２、ＲＡＭ（揮発性メモリ）１０３、上位装置通信コントローラ２０２を具備する。
【００５９】
続いて、図４９を用いて、上位装置１０１とターゲットシステム１００との間で実施されるリモートダウンロードの通信プロトコルの例を説明する。
ステップ（ＳＴ）３１１おいて、ターゲットシステム１００は、現在保持しているプログラムバージョン確認する。そして、ステップ３１２において、先のステップで確認したプログラムバージョンを上位装置１０１に報告する。
【００６０】
次いで、ステップ３２１において、上位装置１０１は、自己が保持しているプログラムバージョンとターゲットシステム１００より報告を受けたプログラムバージョンとを比較してバージョンアップの有無を判定する。そして、ステップ３２２において、上位装置１０１はターゲットシステム１００にバージョンアップの有無を指示する。その後、ステップ３３０において、上位装置１０１とターゲットシステム１００との間でリモートダウンロードを実施する。
【００６１】
リモートダウンロード完了後、ターゲットシステム１００は、ダウンロード処理の合否をサム値チェック等の方法で確認する。ステップ３４１において、ターゲットシステム１００は、バージョンアップ処理を実施する。そして、ステップ３４２において、バージョンアップの結果を上位装置１０１に報告する。次いで、ステップ３５０において、上位装置１０１はバージョンアップ結果の報告より、ターゲットシステム１００のプログラムバージョン情報を更新し、ターゲットシステム１００のプログラムバージョンを把握しておく。
【００６２】
なお、以後前記通信プロトコルを前提として話を進めるが、その他の通信プロトコルを適用しても同様である。
【００６３】
最後に、図５０を用いて、ファームウェアのバージョン体系について説明する。
ファームウェアは、ＦＤＰ（リモートダウンロードプログラム）と制御ソフトから構成され、ファームウェア全体のバージョン４２００の他、ＦＤＰの個別バージョン４２０１及び制御ソフトの個別バージョン４２０２から構成される。
【００６４】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。
（実施の形態１）
図１は、本発明の実施の形態１に係るリモートダウンローダの構成を示すブロック図である。なお、本実施の形態のリモートダウンローダは、例えば移動動体通信システムの基地局装置に設けられる。
【００６５】
図１において、リモートダウンローダ１００Ａ上には、フラッシュＲＯＭ１０２とＲＡＭ１０３が実装されており、上位装置１０１と通信路２００（図４９参照）を介して接続されている。フラッシュＲＯＭ１０２上にはＦＤＰ１１３を格納する領域として、ＦＤＰ格納領域（Ａ面）１１０と、ＦＤＰ格納領域（Ｂ面）１１１が存在し、それぞれの領域内に起動面判定情報１１２＿Ａ、１１２＿Ｂが格納されている。また、フラッシュＲＯＭ１０２上にはファームウェア等のバージョン情報１１４も格納されている。
【００６６】
リモートダウンローダ１００Ａは、ブート手段１２０と、ＦＤＰ起動面判定手段１２１と、ＦＤＰ展開手段１２３と、起動面判定情報管理手段１３０と、バージョン情報管理手段１３１と、ファームウェアバージョンアップ管理手段１４０と、ファームウェアバージョンアップ手段１５０と、ファームウェアダウンロード手段１６０と、上位装置通信手段１６１と、制御ソフト展開手段１７０と、リセット待ち手段１８０とを備えている。
【００６７】
ブート手段１２０は、ＦＤＰ１１３をフラッシュＲＯＭ１０２からＲＡＭ１０３へ展開するために最低限必要なブート処理と、その他残りのブート処理を実施する。ＦＤＰ起動面判定手段１２１は、最低限必要なブート処理後、起動面判定情報管理手段１３０からの起動面判定情報１１２の報告よりＦＤＰ１１３の起動面を判定し、正常に判定できた場合は判定結果をＦＤＰ展開手段１２３に報告し、正常に判定できなかった場合は、リセット待ち手段１８０にリセット待ちを要求する。ＦＤＰ展開手段１２３は、ＦＤＰ起動面判定手段１２１からのＦＤＰ起動面の報告より、報告された起動面からＦＤＰ１１３を展開し、展開したＦＤＰ１１３のエントリポイントに分岐する。
【００６８】
ファームウェアバージョンアップ管理手段１４０は、バージョン情報管理手段１３１から報告されたファームウェアバージョン情報１１４を、上位装置通信手段１６１を経由して上位装置１０１に報告し、上位装置１０１に対してファームウェアバージョンアップの必要性を問い合わせ、上位装置１０１より必要との指示を受けた場合は、ファームウェアダウンロード手段１６０を経由してファームウェアダウンロードを実施する。そして、ファームウェアダウンロード処理の合否をサム値チェック等の方法で確認し、失敗と判断された場合はバージョンアップ処理を中止し、制御ソフト展開手段１７に制御ソフトの展開を要求する。
【００６９】
また、ファームウェア内ＦＤＰのバージョンアップの必要性については、バージョン情報管理手段１３１から報告されたＦＤＰ個別バージョン情報４２０１と、ダウンロードしたファームウェア内のＦＤＰ個別バージョン情報４２０１より本手段で判定する。必要と判定された場合は、ファームウェアバージョンアップ手段１５０にＦＤＰ１１３のバージョンアップを要求し、同様にファームウェア内制御ソフトのバージョンアップの必要性をＦＤＰと同様の方法で判定する。必要と判定された場合は、ファームウェアバージョンアップ手段１５０に制御ソフトのバージョンアップを要求し、上位装置通信手段１６１を経由して上位装置１０１にバージョンアップ結果を報告し、制御ソフト展開手段１７０に制御ソフトの展開を要求する。
【００７０】
バージョン情報管理手段１３１は、ファームウェアバージョンアップ管理手段１４０からの要求により、バージョン情報１１４を報告し、ファームウェアバージョンアップ手段１５０からの要求により、バージョン情報１１４を更新する。上位装置通信手段１６１は、ファームウェアバージョンアップ管理手段１４０からの要求により、上位装置１０１にバージョン情報１１４を報告し、上位装置１０１からのバージョンアップの必要性に関する指示をファームウェアバージョンアップ管理手段１４０に報告し、ファームウェアダウンロード手段１６０からの指示により上位装置１０１とダウンロード処理のための通信を実施し、上位装置１０１にバージョンアップ結果情報を報告する。
【００７１】
ファームウェアダウンロード手段１６０は、ファームウェアバージョンアップ管理手段１４０からの指示により、上位装置通信手段１６１を経由して上位装置１０１からファームウェアをダウンロードする。ファームウェアバージョンアップ手段１５０は、ファームウェアバージョンアップ管理手段１４０からの指示により、ダウンロードしたファームウェアをフラッシュＲＯＭ１０２に格納する。そして、起動面判定情報管理手段１３０にバージョンアップに伴う起動面判定情報１１２の更新を指示し、バージョン情報管理手段１３１にバージョンアップに伴うバージョン情報１１４の更新を指示する。
【００７２】
起動面情報管理手段１３０は、ＦＤＰ起動面判定手段１２１からの要求により、起動面判定情報１１２を報告し、ファームウェアバージョンアップ手段１５０からの指示により、バージョンアップに伴う起動面判定情報１１２の更新を実施する。制御ソフト展開手段１７０は、ファームウェアバージョンアップ管理手段１４０からの指示により、指示された制御ソフト起動面から制御ソフトをＲＡＭ１０３上に展開し、制御ソフトのエントリポイントに分岐する。リセット待ち手段１８０は、ＦＤＰ起動面判定手段１２１からの要求により、リセットされるのを待ち続ける。
【００７３】
このように構成されたリモートダウンローダ１００Ａの動作について、図２〜図１３を参照して説明する。
【００７４】
最初に、図９〜図１３を参照して、起動面判定情報１１２について詳細に説明する。
起動面判定情報１１２は、起動面を判定するための情報であり、フラッシュＲＯＭ１０２上のＦＤＰ格納領域（Ａ面）１１０及びＦＤＰ格納領域（Ｂ面）１１１それぞれの先頭に格納される。ＦＤＰ起動面判定手段１２１は、Ａ面及びＢ面両方の起動面判定情報１１２を参照し、起動面を判定する。起動面判定情報管理手段１３０は、ＦＤＰ起動面判定手段１２１が適切な起動面判定を実施できるように、起動面判定情報１１２を制御する。
【００７５】
図９及び図１０は起動面判定情報１１２のビットマップである。起動面判定情報１１２は起動面判定情報＿１と起動面判定情報＿２から構成される。起動面判定情報＿１はＦＤＰ処理中に異常が発生したかどうかを示すフラグである。他方、起動面判定情報＿２はＦＤＰのバージョンアップ処理のステータスを示すフラグである。
【００７６】
図１２は正常ケースのうちの運用時の起動面判定方法を示す図である。項番１〜３のＡ面及びＢ面のフラグ状態を逆にしたものが項番４〜６に相当する。
Ａ面及びＢ面の起動面判定情報＃２がフラッシュＲＯＭバージョンアップ完了を示す場合、
００００　００００　００００　１１１１をグー
００００　００００　１１１１　１１１１をチョキ
００００　１１１１　１１１１　１１１１をパー
とする「じゃんけん」の論理で「勝った」方を起動面と判定する。
【００７７】
制御としては、一方の面のバージョンアップが完了した場合、他方の面に対して「後出し」をしてわざと「じゃんけん」に勝つように一方の面の起動面判定情報＃２を設定する。例えば図１１に示すように、項番１のフラグ状態時は、Ａ面から起動するが、Ａ面で起動した後、Ｂ面をバージョンアップし、バージョンアップが完了した場合は、Ｂ面の起動面判定情報＃２を項番４のように制御する。
【００７８】
このような３値による論理を組むのは、起動面制御処理において、処理時間の大きいフラッシュＲＯＭイレーズ処理を極力無くし、ビット値”１”からビット値”０”の制御のみで起動面判定論理を実現するためである。
【００７９】
図１３は準正常ケースのうちのフラッシュＲＯＭバージョンアップ中の起動面判定方法を示す図である。項番１のＡ面及びＢ面のフラグ状態を逆にしたものが項番２に相当する。また、システム初期立ち上げ時については、実施の形態２で説明するが、システム初期立ち上げ後、はじめてフラッシュＲＯＭバージョンアップを実施した場合を項番３に示している。
【００８０】
一方の面の起動面判定情報＃２がフラッシュＲＯＭイレーズ中又はフラッシュＲＯＭライト中である場合、他方の面を起動面と判定する。制御としては、フラッシュＲＯＭイレーズを実施する直前にバージョンアップ対象面の起動面判定情報＃２をソフトで全て”０”（フラッシュＲＯＭイレーズ中）に設定し、フラッシュＲＯＭイレーズが完了した場合、ハードで全て”１”（フラッシュＲＯＭライト中）に設定される。フラッシュＲＯＭバージョンアップが完了した場合、ソフトで起動面判定情報＃２をフラッシュＲＯＭバージョンアップ完了に設定する。
【００８１】
なお、図１３の項番３の両面フラッシュＲＯＭライト中状態は、実施の形態２で説明するシステム初期立ち上げ状態と同じ状態であるが、どちらもＡ面を固定で起動面と判定するので問題はない。
【００８２】
続いて、図２〜図７のフロー図を参照して、リモートダウンロード処理の動作を説明する。
【００８３】
まず、図２を参照してメインフローについて説明する。なお、図中、ステップ７０３、７１０、７１１及び７１２についてはサブルーチン化しており、別途サブフローとして説明する。
ステップ７０１において、ＦＤＰをフラッシュＲＯＭからＲＡＭへ展開するために最低限必要なブート処理を実施する。次いで、ステップ７０３において、起動面判定情報よりＦＤＰの起動面を判定し、正常に判定できなかった場合は、リセット待ちを行う。正常に判定できた場合は、ステップ７０４において、判定結果が示す起動面からＦＤＰを展開する。ステップ７０５において、展開したＦＤＰのエントリポイントに分岐する。ステップ７０６において、その他残りのブート処理を実施する。
【００８４】
ステップ７０７において、ファームウェアバージョン情報を上位装置に報告し、上位装置に対してファームウェアバージョンアップの必要性を問い合わせ、上位装置より必要との指示を受けた場合は、ステップ７０８を実施する。ステップ７０８において、ファームウェアダウンロードを実施し、ファームウェアダウンロード処理の合否をサム値チェック等の方法で確認し、失敗と判断された場合はバージョンアップ処理を中止し、制御ソフトを展開する。
【００８５】
ファームウェア内ＦＤＰのバージョンアップの必要性については、ステップ７１０において、ＦＤＰ個別バージョン情報と、ダウンロードしたファームウェア内のＦＤＰ個別バージョン情報より判定し、必要と判定された場合は、ステップ７１１を実施する。ステップ７１１において、ＦＤＰのバージョンアップ（フラッシュＲＯＭへの格納）を実施し、バージョンアップに伴い起動面判定情報の更新及びバージョン情報の更新を行う。
【００８６】
ステップ７１２において、ステップ７１０と同様にファームウェア内制御ソフトのバージョンアップの必要性を判定し、必要と判定された場合は、ステップ７１３を実施する。ステップ７１３において、制御ソフトのバージョンアップ（フラッシュＲＯＭへの格納）を実施し、バージョンアップに伴いバージョン情報の更新を行う。ステップ７１４において、上位装置にファームウェアバージョンアップ結果を報告する。ステップ７１５において、フラッシュＲＯＭから制御ソフトをＲＡＭ上に展開する。ステップ７１６において、制御ソフトのエントリポイントに分岐する。
【００８７】
次に、図３を参照してサブフローであるＦＤＰ起動面判定処理＿１について説明する。
ステップ１１０２において、Ａ面及びＢ面の起動面判定情報＿２より、起動面を判定する。正常に判定できた場合、判定結果はステップ１１０２−１〜ステップ１１０２−８のようになる。正常に判定できなかった場合は、フラグ異常と判断し、ＡＬＭ処理を実施する。図７はＡＬＭ処理を示すサブフローである。この図において、ステップ２３０１において、リセットされるのを待つ処理（空処理の無限ループ）を行う。
【００８８】
次に、図４を参照してサブフローであるＦＤＰバージョンアップ判定＿１について説明する。
ステップ１５０１において、個別バージョンアップ判定を実施する。具体的には、リモートダウンローダが管理するＦＤＰ個別バージョン情報と、ダウンロードしたファームウェア内のＦＤＰ個別バージョン情報より判定する。バージョンが異なる場合、ステップ１５０１−１のようにＦＤＰバージョンアップ必要と判定される。バージョンが同一の場合、ステップ１５０１−２のようにＦＤＰバージョンアップ不要と判定される。
【００８９】
次に、図６を参照してサブフローであるＦＤＰバージョンアップ（フラッシュＲＯＭ書換）について説明する。
ステップ１９０１において、ＦＤＰ起動面を判定する。本実施の形態１では、図３のＦＤＰ起動面判定＿１の手順で判定し、後述する実施の形態２では、図１７、図１８のＦＤＰ起動面判定＿２の手順で判定する。また、実施の形態３及び４では、バージョンアップ判定情報を使用するので、バージョン判定情報内、ＦＤＰ起動面判定結果フラグによって判定できる。
【００９０】
ステップ１９０１−１及びステップ１９０１−２のように、ＦＤＰ起動面がＡ面の場合、ＦＤＰバージョンアップ面はＢ面となる。ＦＤＰ起動面がＢ面の場合、ＦＤＰバージョンアップ面はＡ面となる。ステップ１９０２において、ＦＤＰバージョンアップ面の起動面判定情報＿２に“０＿０＿０＿０”（０ｘ００００）を書き込む。
【００９１】
ステップ１９０３においてＦＤＰバージョンアップのためフラッシュＲＯＭのイレーズを行う。ステップ１９０４において、ＦＤＰバージョンアップのためフラッシュＲＯＭにプログラムを書き込む。ステップ１９０５において、ＦＤＰ起動面の起動面判定情報＿２に応じて、じゃんけん論理を適用する。正常に適用できた場合は、ステップ１９０５−１〜１９０５−３のように、ＦＤＰバージョンアップ面の起動面判定情報＿２に値を書き込む。正常に適用できなかった場合は、ステップ１９０５−４のように、フラグ異常としてＡＬＭ処理を行う。
【００９２】
次に、図５を参照してサブフローである制御ソフトバージョンアップ判定＿１について説明する。
ステップ１７０１において、個別バージョンアップ判定を実施する。具体的には、リモートダウンローダが管理する制御ソフト個別バージョン情報と、ダウンロードしたファームウェア内の制御ソフト個別バージョン情報より判定する。バージョンが異なる場合、ステップ１５０１−１のように制御ソフトバージョンアップ必要と判定される。バージョンが同一の場合、ステップ１５０１−２のように制御ソフトバージョンアップ不要と判定される。
【００９３】
最後に図８の物理構成図を参照して、リモートダウンロード処理の動作を説明する。
リモートダウンローダ１００は、基本的にフラッシュＲＯＭ１０２と、ＲＡＭ１０３から構成され、フラッシュＲＯＭ１０２上には、起動面判定プログラム格納及び動作領域２４０１と、ＦＤＰ格納領域（Ａ面）１１０と、ＦＤＰ格納領域（Ｂ面）１１１と、そして、制御ソフト格納領域２４０４の４つの領域が確保されている。また、ＲＡＭ上には、ＦＤＰ動作領域２４０３と、ファームウェア一時格納領域２４０２と、そして、制御ソフト動作領域２４０５の３つの領域が確保されている。
【００９４】
起動面判定プログラム２４１０は、ＦＤＰ格納領域（Ａ面）１１０の起動面判定情報１１２＿Ａと、ＦＤＰ格納領域（Ｂ面）１１１の起動面判定情報１１２＿Ｂより起動面を判定し、ＦＤＰ格納領域（Ａ面）１１０のＦＤＰ１１３＿Ａか、ＦＤＰ格納領域（Ｂ面）１１１のＦＤＰ１１３＿ＢのいずれかをＦＤＰ動作領域２４０３に展開し、ＦＤＰ１１３＿Ｄのエントリポイントに分岐する。
【００９５】
ＰＤＰ動作領域２４０３上のＦＤＰ１１３＿Ｄは、バージョンアップ判定情報５０１等より、ファームウェアを上位装置１０１からリモートダウンローダ１００内ファームウェア一時格納領域２４０２にダウンロードする。そして、ＦＤＰのバージョンアップが必要と判定された場合は、ファームウェア一時格納領域２４０２上のＦＤＰ１１３＿Ｋを、起動面の次面に相当するＦＤＰ格納領域にバージョンアップする。
【００９６】
同様に、制御ソフトのバージョンアップが必要と判定された場合は、ファームウェア一時格納領域２４０２上の制御ソフト２４２０＿Ｋを、制御ソフト格納領域２４０４にバージョンアップする。最後に、制御ソフト格納領域２４０４上の制御ソフト２４２０＿Ｓを制御ソフト動作領域２４０５に展開し、制御ソフト２４２０＿Ｄのエントリポイントに分岐する。制御ソフト動作領域２４０５上の制御ソフト２４２０＿Ｄは、組み込み処理を制御するメイン処理を開始する。
【００９７】
以上のように、本実施の形態のリモートダウンローダ１００Ａによれば、特にＦＤＰ自身のリモートダウンロード処理中に、ＦＤＰが起動面判定情報を適切に制御し、通信路障害、電源断の障害が発生しても、リセット後リモートダウンローダは起動可能であり、常にリモートダウンロード機能を確保することができる。また、その実現方法は、フラッシュＲＯＭ以外の特別な装置（メモリ等）を必要とせず、容易に実施することができる。
【００９８】
（実施の形態２）
図１４は、本発明の実施の形態２に係るリモートダウンローダの構成を示すブロック図である。本実施の形態のリモートダウンローダ１００Ｂは、実施の形態１のリモートダウンローダ１００Ａと同一の構成に加えてＦＤＰプログラム障害検出手段４００を備えている。ＦＤＰプログラム障害検出手段４００は、ＦＤＰによるリモートダウンロード処理におけるソフトウェア不具合等の処理異常を検出し、起動面判定情報管理手段１３０に起動面判定情報の制御を要求し、リセット待ち手段１８０にリセット待ちを要求する。
【００９９】
起動面情報管理手段１３０は、実施の形態１で説明した処理に加えて、ＦＤＰプログラム障害検出手段４００からの起動面判定情報の制御要求により、現起動面が次起動面と判定されないように現起動面の起動面判定情報を書き換える。リセット待ち手段１８０は、実施の形態１で説明した処理に加えて、ＦＤＰプログラム障害検出手段４００からの要求により、リセットされるのを待ち続ける。
【０１００】
このように構成されたリモートダウンローダ１００Ｂの動作について図１５〜図２５を参照して説明する。
最初に、図１９〜図２５を参照して起動面判定情報１１２について詳細に説明する。
【０１０１】
図２０は、準正常ケースのうちのＦＤＰ処理異常が発生した場合の起動面判定方法を示す図である。項番１のＡ面及びＢ面のフラグ状態を逆にしたものが項番２に相当する。また、システム初期立ち上げ後、はじめてフラッシュＲＯＭバージョンアップが完了するまでの間にＦＤＰ処理異常となった場合を項番３に示している。一方の面の起動面判定情報＿１がＦＤＰ処理異常である場合、他方の面を起動面と判定する。但し、システム初期立ち上げ時（他方の面がフラッシュＲＯＭライト中）は、起動面無しとし、リセット待ちのＡＬＭとする。制御としては、ＣＰＵ例外等、ソフトがＦＤＰ処理異常を検出した場合、起動面の起動面判定情報＿１をソフトで全て“０”（ＦＤＰ処理異常）に設定し、リセット待ちのあＬＭとする。
【０１０２】
図１９は、正常ケースのうちのシステム初期立ち上げ時の起動面判定方法を示す図である。
両方の面の起動面判定情報＿２がフラッシュＲＯＭライト中である場合は、システム初期立ち上げ時と判断し、Ａ面を固定で起動面と判定する。システム初期立ち上げ時は、Ａ面及びＢ面の起動面判定情報はフラッシュＲＯＭイレーズした状態、つまり全て“１”とする。また、ＩＣＥ等を使用し、Ａ面にＦＤＰが格納することとし、Ｂ面にはＦＤＰを格納しない。
【０１０３】
図２１は、準正常ケースのうちの、フラッシュＲＯＭイレーズ中またはフラッシュＲＯＭライト中と、ＦＤＰ処理異常が複合して発生した、２重障害の場合の起動面判定方法を示す図である。項番１〜３のＡ面及びＢ面のフラグ状態を逆にしたのが項番４〜６に相当する。また、システム初期立ち上げ後、はじめてフラッシュＲＯＭバージョンアップが完了するまでの間に２重障害となった場合を項番７に示している。
【０１０４】
一方の面の起動面判定情報＿１がＦＤＰ処理異常、起動面判定情報＿２がフラッシュＲＯＭイレーズ中またはフラッシュＲＯＭライト中であり、他方の面の起動面判定情報＿１がＦＤＰ処理正常、起動面判定情報＿２がフラッシュＲＯＭバージョンアップ完了である場合に限り、他方の面を起動面と判定する。両方の面の起動面判定情報＿１がＦＤＰ処理異常、または、起動面判定情報＿２がフラッシュＲＯＭイレーズ中またはフラッシュＲＯＭライト中である場合は、起動面無しとし、リセット待ちのＡＬＭとする。
【０１０５】
なお、図２１の項番７のＡ面ＦＤＰ処理異常の両面フラッシュＲＯＭライト中状態は、図２０の項番３のシステム初期立ち上げ状態と同じ状態であるが、いずれも起動面無しと判定するので問題はない。
【０１０６】
図２２〜図２５より、起動面判定情報のフラグ状態及びフラグ状態遷移について説明する。
図２２及び図２３は起動面判定情報のフラグ状態を示す図である。正常ケースの状態については、状態番号を”□”で囲う。
起動面判定情報のとり得るフラグ状態数は、合計５２である。正常ケースについては、システム初期立ち上げ時の１個と、運用時の６個の合計７個である。純正上ケースについてはＭ、システム初期立ち上げ時の３個と、運用時の４２個の合計４５個である。
【０１０７】
図１９の項番１の状態が図２２における状態番号０−０に相当する。また、図１２の項番１〜６の状態が、それぞれ図２２及び図２３における状態番号２−０、４−０、６−０、３−０、５−０、１−０に相当する。図２２及び図２３におけるその他の状態は純正常ケースの状態である。
【０１０８】
図２４及び図２５に起動面判定情報のフラグ状態遷移図を示す。
まず、システム初期立ち上げ時のフラグ状態遷移について説明する。
フラグ状態０−０は、システム初期立ち上げ時であり、リセット後、ＦＤＰバージョンアップを開始することにより、Ｂ面フラッシュＲＯＭイレーズ中を示すフラグ状態０−１に遷移する。フラッシュＲＯＭイレーズが完了すると、Ｂ面フラッシュＲＯＭライト中を示すフラグ状態０−０に遷移し、フラッシュＲＯＭライトが完了した時点で、フラッシュＲＯＭバージョンアップ完了を示すフラグ状態１−０に遷移する。
【０１０９】
フラグ状態０−０及び０−１で、ソフト不具合等によるＡＬＭ処理が実施された場合、それぞれ、Ａ面ＦＤＰ処理異常を示すフラグ状態０−０−１及び０−１−１に遷移する。フラグ状態０−０−１及び０−１−１では、その後リセットが行われても起動面無しでＡＬＭとなる。
【０１１０】
続いて、運用時のフラグ状態遷移について説明する。
フラグ状態１−０は、バージョンアップ完了状態を示し、リセット後、起動面判定処理によりＢ面が起動面と判定される。Ｂ面で起動後、Ａ面のバージョンアップを開始することにより、Ａ面フラッシュＲＯＭイレーズ中を示すフラグ状態１−１に遷移する。フラッシュＲＯＭイレーズが完了すると、Ａ面フラッシュＲＯＭライト中を示すフラグ状態１−２に遷移し、フラッシュＲＯＭライトが完了した時点で、フラッシュＲＯＭバージョンアップ完了を示すフラグ状態２−０に遷移する。
【０１１１】
フラグ状態１−０で、ソフト不具合等によるＡＬＭ処理が実施された場合、Ｂ面ＦＤＰ処理異常を示すフラグ状態１−０−１に遷移する。フラグ状態１−０−１では、その後リセットが行われた場合、起動面判定処理によりＡ面が起動面と判定される。Ａ面で起動した後、Ｂ面のバージョンアップを開始することにより、Ｂ面イレーズ中を示すフラグ状態１−０−２に遷移する。フラッシュＲＯＭイレーズが完了すると、Ｂ面フラッシュＲＯＭライト中を示すフラグ状態６−２に遷移し、フラッシュＲＯＭライトが完了した時点で、フラッシュＲＯＭバージョンアップ完了を示すフラグ状態１−０に遷移する。
【０１１２】
フラグ状態１−１及び１−２で、ソフト不具合等によるＡＬＭ処理が実施された場合、それぞれＦＤＰ処理異常を示すフラグ状態１−１−１及び１−２−１に遷移する。フラグ状態１−１−１及び１−２−１では、その後リセットが行われても起動面無しでＡＬＭとなる。フラグ状態２−０、３−０、４−０、５−０、６−０については、フラグ状態１−０からの状態遷移と全く同様である。
【０１１３】
フラグ状態遷移は、ソフト不具合等によるＡＬＭ処理が行われない限り、０−０から始まり、１−０、そしてフラッシュＲＯＭバージョンアップ中という過渡状態１−１そして１−２を経由して２−０、その後同様に３−０、４−０、５−０、６−０、そしてまた最初に戻って１−０となる。０−０の状態は、システム初期立ち上げ時に以降は遷移することはない。
【０１１４】
続いて、図１５〜図１８のフロー図を参照してリモートダウンロード処理の動作を説明する。
まず、図１５を参照してメインフローについて説明する。なお、ステップ８０３、８１０、８１１、８１２についてはサブルーチン化しており、別途サブフローとして説明する。
【０１１５】
ステップ８０１〜ステップ８１６までは、実施の形態１を示す図２のステップ７０１〜ステップ７１６と同じである。但し、ステップ８０３のＦＤＰ起動面の判定方法が異なる。ＦＤＰ起動面判定＿２については図１７及び図１８のサブフローで説明する。
ＣＰＵ例外発生時、ステップ８５１においてＦＤＰ起動面を判定する。ステップ８５２において、ＦＤＰ起動面の起動面判定情報＿１にＦＤＰ処理異常を示す“０”を書き込む。
【０１１６】
次に、図１７及び図１８を参照してサブフローであるＦＤＰ起動面判定処理＿２について説明する。
ステップ１２０１において、Ａ面及びＢ面の起動面判定情報＿１より、起動面を判定する。正常に判定できて起動面が存在する場合、判定結果はステップ１２０１−１−１又はステップ１２０１−２−１のようになる。正常に判定できたが起動面が存在しない場合は、判定結果はステップ１２０１−１−２又はステップ１２０１−２−２のようになり、ＡＬＭ処理を実施する。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１１７】
ステップ１２０２において、Ａ面及びＢ面の起動面判定情報＿２より、起動面を判定する。正常に判定できた場合、判定結果はステップ１２０２−１〜ステップ１２０２−８のようになる。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１１８】
なお、物理構成については、実施の形態１と同様なので、説明を省略する。
【０１１９】
以上のように、本実施の形態のリモートダウンローダ１００Ｂによれば、特にＦＤＰ自身のリモートダウンロード処理中に、ＦＤＰが起動面判定情報を適切に制御し、実施の形態１であげたような通信路障害、電源断の障害に加えて、起動しているＦＤＰ自身の不具合等によるプログラム暴走等の障害が発生してもリセット後リモートダウンローダは起動可能であり、常にリモートダウンロード機能を確保することができる。また、その実現方法は、実施の形態１と同様にフラッシュＲＯＭ以外の特別な装置（メモリ等）を必要とせず、容易に実施することができる。
【０１２０】
（実施の形態３）
図２６は、本発明の実施の形態３に係るリモートダウンローダの構成を示すブロック図である。本実施の形態のリモートダウンローダ１００Ｃは、実施の形態２のリモートダウンローダ１００Ｂと同一の構成に加えて、バージョンアップ判定情報管理手段５００を備えるとともに、ＲＡＭ１０３にバージョンアップ判定情報が格納されたものである。
【０１２１】
バージョンアップ判定情報管理手段５００は、ブート手段１２０及びＦＤＰ起動面判定手段１２１及びファームウェアバージョン管理手段１４０からのバージョンアップ判定情報の制御要求によりバージョンアップ判定情報を制御し、ファームウェアバージョン管理手段１４０からのバージョンアップ判定情報の報告要求に対してバージョンアップ判定情報を報告する。ブート手段１２０は、実施の形態１で説明した処理に加えて、バージョンアップ判定情報の初期化をバージョンアップ判定情報管理手段５００に要求する。
【０１２２】
ＦＤＰ起動面判定手段１２１は、実施の形態１で説明した処理に加えて、ＦＤＰの起動面を判定し、正常に判定できた場合は判定結果をバージョンアップ判定情報管理手段５００にも報告する。ファームウェアバージョンアップ管理手段１４０は、実施の形態１で説明した処理に加えて、ファームウェア内ＦＤＰのバージョンアップの必要性判定の判定結果と、同様にファームウェア内制御ソフトのバージョンアップの必要性判定結果をバージョンアップ判定情報管理手段５００に報告する。そして、制御ソフト起動後はバージョンアップ判定情報管理手段５００からの報告により、ＦＤＰ処理においてＦＤＰのバージョンアップ必要と判定されていた場合はファームウェアバージョンアップ手段１５０にＦＤＰのバージョンアップを要求する。同様にＦＤＰ処理において制御ソフトのバージョンアップ必要と判定されていた場合は、ファームウェアバージョンアップ手段１５０に制御ソフトのバージョンアップを要求し、正常にＦＤＰ又は制御ソフトのバージョンアップの必要性が判定されていなかった場合はリセット待ち手段１８０にリセット待ちを要求する。
【０１２３】
このように構成されたリモートダウンローダ１００Ｃの動作について、図２６〜図３８を参照して説明する。
【０１２４】
最初に図３６〜図３８を参照してバージョンアップ判定情報５０１について詳細に説明する。
バージョンアップ判定情報５０１は、バージョンアップに関連する情報であり、ＲＡＭ１０３上に格納される。図３６及び図３７はバージョンアップ判定情報５０１のビットマップである。バージョンアップ判定情報５０１は、バージョンアップ判定実施／未実施フラグと、ＦＤＰバージョンアップ判定フラグと、制御ソフトバージョンアップ判定フラグと、ＦＤＰ起動面判定結果フラグと、の４つの情報より構成される。
【０１２５】
バージョンアップ判定実施／未実施フラグは、実施の形態４で説明するバージョンアップしたＦＤＰの分岐による自律再起動を実施する場合に使用され、ＦＤＰ自身が、初期起動処理か、または自律再起動処理かを識別するために使用される。
【０１２６】
ＦＤＰバージョンアップ判定フラグは、ファームウェアのうちのＦＤＰの遅延フラッシュＲＯＭ書換を実施する場合に使用され、運用状態遷移後の制御ソフト処理で、（一時格納面に保存されている）バージョンアップ対象ＦＤＰのフラッシュＲＯＭ書込を実施すべきかを判定するために使用される。制御ソフトバージョンアップ判定フラグは、ファームウェアのうちの制御ソフトの遅延フラッシュＲＯＭ書換を実施する場合に使用され、運用状態遷移後の制御ソフト処理で、（一時格納面に保存されている）バージョンアップ対象制御ソフトのフラッシュＲＯＭ書込を実施すべきかを判定するために使用される。ＦＤＰ起動面判定結果フラグは、バージョンアップ対象面を判定（起動面の次面がバージョンアップ対象面）するために使用する。
【０１２７】
図３８はバージョンアップ判定方法を示す図である。
ＦＤＰ起動面判定結果フラグが起動面Ａ面（Ｂ面）を示している場合、バージョンアップ対象面をＢ面（Ａ面）と判定する。制御としては、リセット後、起動面判定方法に従って起動面を判定し、判定結果をＦＤＰ起動面判定結果フラグに設定する。
【０１２８】
バージョンアップ判定実施／未実施フラグがバージョンアップ判定未実施を示している場合、リセット後の初期起動時と判定する。初期起動時はＦＤＰでバージョンアップ判定処理を実施する。逆に、バージョンアップ判定実施／未実施フラグがバージョンアップ判定実施を示している場合、分岐による自律再起動時と判定する。分岐による自律再起動時はＦＤＰでバージョンアップ判定処理は実施済みであるので実施しない。なお、ＰＤＰの分岐による自律再起動については、実施の形態４で説明する。
【０１２９】
制御としては、バージョンアップ判定処理を実施後、バージョンアップ判定実施／未実施フラグをバージョンアップ判定実施に設定する。また、初期起動時は、バージョンアップ判定実施／未実施フラグをバージョンアップ判定未実施に初期化する。
【０１３０】
ＦＤＰバージョンアップ判定フラグがＦＤＰバージョンアップ必要を示している場合、運用状態遷移後、制御ソフトでのＦＤＰのフラッシュＲＯＭ書込処理が必要と判定する。制御としては、ＦＤＰ処理でのバージョンアップ判定実施後、ＦＤＰバージョンアップ判定結果をＦＤＰバージョン判定フラグに設定する。
【０１３１】
制御ソフトバージョンアップ判定フラグが制御ソフトバージョンアップ必要を示している場合、運用状態遷移後、制御ソフトでの制御ソフトのフラッシュＲＯＭ書込処理が必要と判定する。制御としては、ＦＤＰ処理でのバージョンアップ判定実施後、制御ソフトバージョンアップ判定結果を制御ソフトバージョン判定フラグに設定する。
【０１３２】
続いて、図２７〜図３５のフロー図を参照してリモートダウンロード処理の動作を説明する。
【０１３３】
まず、図２７及び図２８を参照してメインフローについて説明する。なお、ステップ９０２、９０３、９０９、９１０、９１４、９１６についてはサブルーチン化しており、別途サブフローとして説明する。
【０１３４】
ステップ９０１は、実施の形態１を示す図２のステップ７０１と同じである。ステップ９０２において、バージョンアップ判定情報５０１を初期化する。次いで、ステップ９０３において、起動面判定情報よりＦＤＰの起動面を判定し、判定結果をバージョンアップ判定情報５０１に格納する。ステップ９０４〜ステップ９０８までは実施の形態１を示す図２のステップ７０３〜ステップ７０８と同じである。
【０１３５】
ステップ９０９において、ファームウェア内ＦＤＰのバージョンアップの必要性について、ＦＤＰ個別バージョン情報とダウンロードしたファームウェア内のＦＤＰ個別バージョン情報より判定し、判定結果をバージョンアップ判定情報５０１に格納し、同様にファームウェア内制御ソフトのバージョンアップの必要性をＦＤＰと同様の方法で判定し、判定結果をバージョンアップ判定情報５０１に格納する。
【０１３６】
ステップ９１０において、バージョンアップ判定情報５０１より制御ソフトのバージョンアップが必要と判定された場合は、ステップ９１０−１を実施し、不要と判定された場合はステップ９１０−２を実施する。ステップ９１０−１において、制御ソフト起動面をＲＡＭ上の一次格納面とする。ステップ９１０−２において、制御ソフト起動面をフラッシュＲＯＭ上の制御ソフト面とする。
【０１３７】
ステップ９１１〜ステップ９１２までは、実施の形態１を示す図２のステップ７１５〜ステップ７１６と同じである。制御ソフト起動後、ステップ９１４において、バージョンアップ判定情報を参照し、ＦＤＰ処理においてＦＤＰのバージョンアップ必要と判定されていた場合は、ステップ９１５を実施する。バージョンアップ判定情報を参照し、正常にＦＤＰのバージョンアップの必要性が判定されていなかった場合はリセット待ちを行う。
【０１３８】
ステップ９１５において、ＦＤＰのバージョンアップ（フラッシュＲＯＭへの格納）を実施し、バージョンアップに伴い起動面判定情報の更新及びバージョン情報の更新を行う。同様に、ステップ９１６において、バージョンアップ判定情報を参照し、ＦＤＰ処理において制御ソフトのバージョンアップ必要と判定されていた場合は、ステップ９１７を実施する。バージョンアップ判定情報を参照し、正常に制御ソフトのバージョンアップの必要性が判定されていなかった場合は、リセット待ちを行う。
【０１３９】
ステップ９１７において、制御ソフトのバージョンアップ（フラッシュＲＯＭへの格納）を実施し、バージョンアップに伴いバージョン情報の更新を行う。ステップ９１８は、実施の形態１を示す図２のステップ７１４と同じである。ＣＰＵ例外発生時、ステップ９５１において、バージョンアップ判定情報を参照し、ステップ９５１―１又はステップ９５１−２のように、ＦＤＰ起動面を判定する。ステップ９５２は、実施の形態２を示す図１６のステップ８５２と同じである。
【０１４０】
次に、図２９及び図３０を参照してサブフローであるＦＤＰ起動面判定処理＿３について説明する。
ステップ１３０１において、Ａ面及びＢ面の起動面判定情報＿１より、起動面を判定する。正常に判定できて起動面が存在する場合、判定結果はステップ１３０１−１−１又はステップ１３０１−２−１のようになる。また、ステップ１３０１−１−１−１及びステップ１３０１−２−１−１において、バージョンアップ判定情報に判定結果を書き込む。正常に判定できたが起動面が存在しない場合は、判定結果はステップ１３０１−１−２又はステップ１３０１−２−２のようになりＡＬＭ処理を実施する。正常に判定出来なかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１４１】
ステップ１３０２において、Ａ面及びＢ面の起動面判定情報＿２より、起動面を判定する。正常に判定できた場合、判定結果はステップ１３０２−１〜ステップ１３０２−８のようになる。また、ステップ１３０２―１−１〜ステップ１３０２−８−１において、バージョンアップ判定情報に判定結果を書き込む。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１４２】
次に、図３１を参照してサブフローであるＦＤＰバージョンアップ判定＿２について説明する。
ステップ１６０１において、バージョンアップ判定情報よりＦＤＰのバージョンアップの必要性を判定する。正常に判定できた場合、判定結果はステップ１６０１−１かステップ１６０１−２のようになる。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１４３】
次に、図３２を参照してサブフローである制御ソフトバージョンアップ判定＿２について説明する。
ステップ１８０１において、バージョンアップ判定情報より、制御ソフトのバージョンアップの必要性を判定する。正常に判定できた場合、判定結果はステップ１８０１−１かステップ１８０１−２のようになる。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１４４】
次に、図３３を参照してサブフローであるバージョンアップ判定情報初期化について説明する。ステップ２００１において、バージョンアップ判定情報に初期値を書き込む。
【０１４５】
次に、図３４を参照してサブフローであるファームウェア内プログラム個別バージョンアップ判定について説明する。
ステップ２１０１において、ＦＤＰ個別バージョン情報と制御ソフト個別バージョン情報より、ファームウェア内プログラムの個別バージョンアップ判定を実施する。具体的にはリモートダウンローダが管理するＦＤＰまたは制御ソフト個別バージョン情報とダウンロードしたファームウェア内のＦＤＰ又は制御ソフト個別バージョン情報より判定する。
【０１４６】
判定結果は、ステップ２１０１―１〜ステップ２１０１―４のようになる。また、ステップ２１０１−１−１〜ステップ２１０１−４−１において、バージョンアップ判定情報に判定結果を書き込む。
【０１４７】
最後に図３５の物理構成図を参照してリモートダウンロード処理の動作を説明する。基本的には、実施の形態１とほぼ同様であるが、制御ソフト２４２０＿Ｄの展開元が複数存在する点が異なる。
【０１４８】
上位装置１０１からリモートダウンローダ１００Ｃ上のファームウェア一時格納領域２４０２にリモートダウンロードした制御ソフト２４２０＿Ｋを、フラッシュＲＯＭ１０２上の制御ソフト格納領域２４０４にバージョンアップしてから、制御ソフト動作領域２４０５に展開するのではなく、ファームウェア一時格納領域２４０２上の制御ソフト２４２０＿Ｋを、直接制御ソフト動作領域２４０５に展開する。展開後、ファームウェア一時格納領域２４０２上の制御ソフト２４２０＿ＫをフラッシュＲＯＭ１０２上の制御ソフト格納領域２４０４にバージョンアップする。
【０１４９】
以上のように、本実施の形態のリモートダウンローダ１００Ｃによれば、起動時にファームウェアのフラッシュＲＯＭへの書き込み処理を実施する必要が無くなり、起動後、メインとなる制御処理に影響を与えないような低優先度の処理としてファームウェアのフラッシュＲＯＭへの書き込み処理を実施することにより、メインとなる制御処理開始までの起動時間を大幅に短縮することができる。また、その実現方法は、実施の形態１及び２と同様に、フラッシュＲＯＭ以外の特別な装置（メモリ等）を必要とせず、容易に実施することができる。
【０１５０】
（実施の形態４）
図３９は、本発明の実施の形態４に係るリモートダウンローダの構成を示すブロック図である。本実施の形態のリモートダウンローダ１００Ｄは、実施の形態３のリモートダウンローダ１００Ｃと同一の構成に加えて自律再起動手段６００を備えている。自律再起動手段６００は、ファームウェアバージョンアップ管理手段１４０からの報告により、ファームウェア内ＦＤＰのバージョンアップ必要と判定された場合、ＦＤＰの自律再起動処理を実施する。
【０１５１】
ＦＤＰ起動面判定手段１２１は、実施の形態３で説明した処理に加えて、起動面判定情報管理手段１３０からの起動面判定情報の報告の他、バージョンアップ判定情報管理手段５００からのバージョンアップ判定情報の報告よりＦＤＰの起動面を判定する。ＦＤＰ展開手段１２３は、実施の形態１で説明した処理に加えて、ＦＤＰ起動面判定手段１２１からのＦＤＰ起動面の報告より、ファームウェア一次格納領域からの展開を報告された場合は、ファームウェア一次格納領域上のＦＤＰを展開する。
【０１５２】
ファームウェアバージョンアップ管理手段１４０は、バージョンアップ判定情報管理手段５００からのバージョンアップ判定情報より、ファームウェアバージョンアップ判定実施不要と判定された場合は、上位装置１０１からのファームウェアダウンロード処理及びファームウェアバージョンアップの必要性判定を実施せず、ファームウェアバージョンアップ判定実施必要と判定された場合で、ファームウェアダウンロード後、ファームウェア内ＦＤＰのバージョンアップが必要と判定された場合は自律再起動手段６００にＦＤＰの自律再起動を要求する。
【０１５３】
このように構成されたリモートダウンローダ１００の動作について図４０〜図４７を参照して説明する。
最初に、図４６及び図４７を参照して、バージョンアップ判定情報５０１の状態及び状態遷移について説明する。
図４６はバージョンアップ判定情報のフラグ状態を示す図である。とり得るフラグ状態数は１１通りである。図３８の項番１の状態が図４６における状態番号０−０に相当する。また、図３８の項番２〜６の状態が図４６における状態番号１−０〜２−４に相当する。
【０１５４】
図４７はバージョンアップ判定情報のフラグ状態遷移図である。
リセット後、バージョンアップ情報を初期化し、フラグ状態０に遷移する。フラグ状態０で起動面判定処理を実施し、起動面判定結果を本バージョンアップ判定情報に設定し、フラグ状態１−０又はフラグ状態２−０に遷移する。その後、バージョンアップ判定処理を実施し、バージョンアップ判定結果を本バージョンアップ判定情報に設定し、フラグ状態１−０からフラグ状態１−１〜１−４のいずれか、またはフラグ状態２−０からフラグ状態２−０〜２−４のいずれかに遷移する。
【０１５５】
続いて、図４０〜図４４のフロー図を参照して、リモートダウンロード処理の動作を説明する。
まず、図４０を参照してメインフローについて説明する。なお、ステップ１００２、１００３、１００７、１０１０、１０１１、１０１２、１０１６、１０１７、１０１８についてはサブルーチン化しており、別途サブフローとして説明する。
【０１５６】
ステップ１００１〜ステップ１００２は、実施の形態３を示す図２７のステップ９０１からステップ９０２と同じである。ステップ１００３において、起動面判定情報及びバージョンアップ判定情報５０１よりＦＤＰの起動面を判定し、判定結果をバージョンアップ判定情報５０１に格納する。ステップ１００４〜ステップ１００６までは、実施の形態１を示す図２のステップ７０４〜ステップ７０６と同じである。ステップ１００７において、ファームウェアバージョンアップ判定処理実施の要不要をバージョンアップ判定情報５０１より判定する。
【０１５７】
ステップ１００８〜ステップ１０１０までは、実施の形態３を示す図２７のステップ９０７〜ステップ９０９と同じである。ステップ１０１１において、バージョンアップ判定情報５０１よりＦＤＰのバージョンアップが必要と判定された場合は、ステップ１００３に戻る（自律再起動）。不要と判定された場合はステップ１０１２を実施する。ステップ１０１２〜ステップ１０２０までは、実施の形態３を示す図２７のステップ９１０〜ステップ９１８と同じである。ＣＰＵ例外発生時、ステップ１０５１〜ステップ１０５２までは、実施の形態３を示す図２８のステップ９５１〜ステップ９５２と同じである。
【０１５８】
図４２、図４３より、サブフローであるＦＤＰ起動面判定処理＿４について説明する。
ステップ１４０１において、バージョンアップ判定情報より、起動面を判定する。正常に判定できて一時格納面から起動と判定された場合は、ステップ１４０１−１となる。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１５９】
ステップ１４０２において、Ａ面及びＢ面の起動面判定情報＿１より、起動面を判定する。正常に判定できて起動面が存在する場合、判定結果はステップ１４０２−１−１又はステップ１４０２−２−１のようになる。また、ステップ１４０２−１−１−１及びステップ１４０２−２−１−１において、バージョンアップ判定情報に判定結果を書き込む。正常に判定できたが起動面が存在しない場合は、判定結果はステップ１４０２−１−２又はステップ１４０２−２−２のようになり、ＡＬＭ処理を実施する。
【０１６０】
正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。ステップ１４０３において、Ａ面及びＢ面の起動面判定情報＿２より起動面を判定する。正常に判定できた場合、判定結果はステップ１４０３−１〜ステップ１４０３−８のようになる。また、ステップ１４０３―１−１〜ステップ１４０３−８−１において、バージョンアップ判定情報に判定結果を書き込む。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１６１】
図４４より、サブフローであるファームウェアバージョンアップ判定処理実施判定について説明する。
【０１６２】
ステップ２２０１において、バージョンアップ判定情報より、ファームウェアバージョンアップ判定処理実施の必要性を判定する。正常に判定できた場合、判定結果はステップ２２０１−１かステップ２２０１―２のようになる。正常に判定できなかった場合はフラグ異常と判断してＡＬＭ処理を実施する。
【０１６３】
最後に、図４５の物理構成図を参照してリモートダウンロード処理の動作を説明する。基本的には、実施の形態３とほぼ同様であるが、ＦＤＰ１１３＿Ｄの展開元にファームウェア一時格納領域２４０２も加わる点が異なる。
【０１６４】
上位装置１０１からリモートダウンローダ１００Ｄ上のファームウェア一時格納領域２４０２にリモートダウンロードしたＦＤＰ１１３＿Ｋを、フラッシュＲＯＭ１０２上のＦＤＰ格納領域１１０又は１１１にバージョンアップし、次回リセット後の起動時にＦＤＰ動作領域２４０３に展開するのではなく、ファームウェア一時格納領域２４０２上のＦＤＰ１１３＿Ｋを、直接ＦＤＰ動作領域２４０３に展開し、リセットすることなく、ＦＤＰ動作領域２４０３上のＦＤＰ１１３＿Ｄのエントリポイントに分岐する。制御ソフト起動後、ファームウェア一時格納領域２４０２上のＦＤＰ１１３＿Ｋを、フラッシュＲＯＭ１０２上のＦＤＰ格納領域１１０または１１１にバージョンアップする。
【０１６５】
以上のように、本実施の形態のリモートダウンローダ１００Ｄによれば、ＦＤＰをバージョンアップ後、リセット処理を実施することなく、バージョンアップしたＦＤＰを自律的に再起動することが可能となる。また、その実現方法は、実施の形態１〜３と同様に、フラッシュＲＯＭ以外の特別な装置（メモリ等）を必要とせず、容易に実施することができる。
【０１６６】
【発明の効果】
本発明によれば、電子機器を制御するファームウェアを、リモートダウンロードを実施するリモートダウンロードプログラムと前記電子機器を制御するメインとなる制御プログラムの２つに分割し、それぞれ独立してリモートダウンロードするので、フラッシュＲＯＭ上に２面管理するのはリモートダウンローダのみで、制御ソフトについては１面管理となり、フラッシュＲＯＭ容量を必要最小限に抑えて２面管理方式を実現することができる。
【０１６７】
また、本発明によれば、特にリモートダウンローダ自身のリモートダウンロード処理中にリモートダウンローダが起動面判定情報を適切に制御するので、通信路障害、電源断の障害が発生してもリセット後ターゲットシステムは起動可能であり、常にリモートダウンロードを確保することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１に係るリモートダウンローダの構成を示すブロック図。
【図２】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図３】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図４】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図５】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図６】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図７】本発明の実施の形態１に係るリモートダウンローダの動作を説明するためのフロー図。
【図８】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための物理構成図。
【図９】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための起動面判定情報ビットマップ図。
【図１０】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための起動面判定情報ビットマップ図。
【図１１】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための起動面判定情報＿２制御例を示す図。
【図１２】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための起動面判定方法を示す図。
【図１３】本発明の実施の形態１に係るリモートダウンローダの動作を説明するための起動面判定方法を示す図。
【図１４】本発明の実施の形態２に係るリモートダウンローダの構成を示すブロック図。
【図１５】本発明の実施の形態２に係るリモートダウンローダの動作を説明するためのフロー図。
【図１６】本発明の実施の形態２に係るリモートダウンローダの動作を説明するためのフロー図。
【図１７】本発明の実施の形態２に係るリモートダウンローダの動作を説明するためのフロー図。
【図１８】本発明の実施の形態２に係るリモートダウンローダの動作を説明するためのフロー図。
【図１９】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定方法を示す図。
【図２０】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定方法を示す図。
【図２１】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定方法を示す図。
【図２２】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定情報状態定義を示す図。
【図２３】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定情報状態定義を示す図。
【図２４】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定情報状態遷移図。
【図２５】本発明の実施の形態２に係るリモートダウンローダの動作を説明するための起動面判定情報状態遷移図。
【図２６】本発明の実施の形態３に係るリモートダウンローダの構成を示すブロック図。
【図２７】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図２８】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図２９】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３０】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３１】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３２】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３３】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３４】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのフロー図。
【図３５】本発明の実施の形態３に係るリモートダウンローダの動作を説明するための物理構成図。
【図３６】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためバージョンアップ判定情報ビットマップ図。
【図３７】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためバージョンアップ判定情報ビットマップ図。
【図３８】本発明の実施の形態３に係るリモートダウンローダの動作を説明するためのバージョンアップ判定方法を示す図。
【図３９】本発明の実施の形態４に係るリモートダウンローダの構成を示すブロック図。
【図４０】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのフロー図。
【図４１】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのフロー図。
【図４２】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのフロー図。
【図４３】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのフロー図。
【図４４】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのフロー図。
【図４５】本発明の実施の形態４に係るリモートダウンローダの動作を説明するための物理構成図。
【図４６】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのバージョンアップ判定情報状態定義を示す図。
【図４７】本発明の実施の形態４に係るリモートダウンローダの動作を説明するためのバージョンアップ判定情報状態遷移図。
【図４８】本発明の実施の形態に係るリモートダウンローダを用いたターゲットシステムと上位装置の構成を示すブロック図。
【図４９】本発明の実施の形態に係るリモートダウンローダを用いたターゲットシステムと上位装置間のリモートダウンロードシーケンス図。
【図５０】本発明の実施の形態に係るリモートダウンローダのファームウェアバージョン情報の構成図。
【符号の説明】
１００Ａ〜１００Ｄ　リモートダウンローダ
１０１　上位装置
１０２　フラッシュＲＯＭ
１０３　ＲＡＭ
１１０、１１１　ＦＤＰ格納領域
１１３　ＦＤＰ
１２０　ブート手段
１２１　ＦＤＰ起動面判定手段
１２３　ＦＤＰ展開手段
１３０　起動面判定情報管理手段
１３１　バージョン情報管理手段
１４０　ファームウェアバージョンアップ管理手段
１５０　ファームウェアバージョンアップ手段
１６０　ファームウェアダウンロード手段
１６１　上位装置通信手段
１７０　制御ソフト展開手段
１８０　リセット待ち手段
２００　通信路
２０１　ＣＰＵ
２０２　上位装置コントローラ
４００　リモートダウンローダ障害検出手段
５００　バージョンアップ判定情報管理手段
６００　自律再起動手段[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention is applied to, for example, a base station in a mobile communication system, downloads a program held by a higher-level device to a target system via a communication path, and remotely upgrades the program to realize a remote downloader and a remote download method. About.
[0002]
[Prior art]
Conventionally, as this type of remote downloader and remote download method, the one disclosed in Japanese Patent Application Laid-Open No. H11-45182 is known. In the prior art disclosed in this publication, the remote downloader operates by expanding itself from the flash ROM to the RAM at the time of reset. Remote downloader running on RAM realizes version upgrade by downloading new version of remote downloader from upper device when version upgrade is necessary and overwriting old version remote downloader on flash ROM I do.
[0003]
Further, as a remote downloader and a remote download method for securing a two-side remote downloader storage area on a flash ROM, a method disclosed in Japanese Patent Application Laid-Open No. 2000-163268 is known. In the prior art disclosed in this publication, a remote read / write nonvolatile memory (NVRAM) is prepared separately from a flash ROM, and information about a surface of a remote downloader to be started is stored and controlled on the NVRAM, thereby enabling remote control. It realizes two-sided management of downloaders.
[0004]
[Problems to be solved by the invention]
However, in the conventional remote downloader and remote download method described in JP-A-11-45182, a new version of the remote downloader is directly stored in the remote downloader storage area on the flash ROM where the currently activated remote downloader is stored. Since the remote downloader is overwritten, if there is a problem with the new version of the remote downloader, there is a problem that the target system cannot be started for a subsequent reset.
[0005]
Considering the case where the target system is a base station in a mobile communication system, the fact that the target system does not start means that a technician actually needs to go to the site where the base station exists. However, there are a huge number of base stations all over the country, and in some cases it is difficult for a technician to actually go to a site such as a mountain. For mobile communication systems based on remote maintenance, including version upgrade work, it must be absolutely avoided that the target system cannot be started. In any case, the target system can be started and remote download can be performed. It is important that functions are secured.
[0006]
The following three cases can be considered as cases where a problem occurs in the new version of the remote download program.
In the first case, a communication path failure or the like occurs in the communication path 200 between the host device 101 and the target system 100, and a bit of a program of a new version of the remote downloader is corrupted.
[0007]
In the second case, during the remote download, a power failure occurs in the host device 101 or the target system 100 due to a power failure or the like, the remote download process is interrupted halfway, and a part of a new version of the remote downloader exists. do not do.
In the third case, a problem exists in the remote downloader of the new version in the first place, and a failure such as program runaway occurs. The third case is a problem that must be solved by operation and should not actually occur.
[0008]
However, with the shortening of the development cycle in recent years, the speed of development is essential, and the development process and the test process are performed in parallel, and it is a fact that a huge number of program versions exist. It cannot be said that an operation (artificial) error of the host device operator such as setting a certain remote downloader as a new version in the host device will never occur. Also, it cannot be said that there is absolutely no fatal problem in the remote downloader, such as the inability to start the target system after the release of the program. Furthermore, when the third case occurs, the problem that the target system cannot be started extends to all target systems under the host device. As described above, it is desired that the third case be implemented as one function of the target system.
[0009]
In the conventional remote downloader and remote download method disclosed in Japanese Patent Application Laid-Open No. 2000-163268, the problem that the target system cannot be started when the second case occurs can be avoided. When the first and third cases occur, a problem occurs that the target system cannot be started. Further, in addition to the flash ROM, an expensive NVRAM is required, which leads to complication of the target system and an increase in cost.
[0010]
SUMMARY OF THE INVENTION The present invention solves the above-mentioned conventional problems, and a remote downloader that can easily realize a two-sided management management method that enables starting of a target system when a problem occurs in a new version of a remote download program. And a remote download method. Also, even if any of the above three cases occurs for the new version of the remote download program, especially if the third case occurs, the target system can be started after reset, and the remote download function is always ensured. It is an object of the present invention to provide a remote downloader and a remote download method.
[0011]
[Means for Solving the Problems]
The remote downloader according to the first aspect of the present invention includes two programs, a remote download program for performing a remote download and a main control program for controlling the electronic device, the program controlling an electronic device having a function of remotely downloading itself. And remote downloading is performed independently of each other.
[0012]
According to this configuration, only the remote downloader manages two sides on the flash ROM, and only one side of the control software. Therefore, the two-side management method can be realized by minimizing the necessary capacity of the flash ROM. Can be.
[0013]
A remote downloader according to a second aspect of the present invention is the remote downloader according to the first aspect of the present invention, wherein two remote downloader storage areas, A-side and B-side, for storing the remote download program are set in a flash ROM. In the remote downloader storage area of each plane, start plane determination information for storing information regarding the start plane of the remote downloader to be started is set, and the start plane is determined only by the start plane determination information in each remote downloader storage area. It is characterized by the following.
[0014]
According to this configuration, no special device (memory or the like) other than the flash ROM is required, and the two-side management system can be easily realized.
[0015]
A remote downloader according to a third aspect of the present invention is the remote downloader according to the second aspect of the present invention, wherein version upgrade determination information for storing information relating to version upgrade determination is set in a RAM, and activation in the two remote downloader storage areas is performed. The activation plane is determined based on the version upgrade determination information in addition to the plane determination information.
[0016]
According to this configuration, it is possible to realize a more detailed two-side management method such as delayed firmware writing to a flash ROM for the purpose of shortening the startup process and autonomous restart of a remote downloader.
[0017]
A remote downloader according to a fourth aspect of the present invention is the remote downloader according to the third aspect of the present invention, in which boot processing and other remaining boot processing required for expanding the remote download program from the flash ROM to the RAM are performed. , A remote downloader starting surface determining unit that determines a starting surface of the remote downloader from the starting surface determining information, and a reset waiting unit that waits for a reset by a request from the remote downloader starting surface determining unit. Remote downloader deploying means for deploying the remote downloader from the remote downloader launch surface, branching to the entry point of the developed remote downloader, and reporting the launch surface determination information and updating the launch surface determination information with version upgrade. Boot surface determination information management means; version information management means for reporting version information and updating version information; storing downloaded firmware in the flash ROM; Firmware version upgrade means for instructing the update of the surface determination information and instructing the version information management means to update the version information with the version upgrade; firmware version upgrade management means for managing the firmware version upgrade; Firmware download means for downloading firmware from a higher-level device in accordance with an instruction from the management means; and control software instructed by an instruction from the firmware upgrade management means. Control software expanding means for expanding the control program on the RAM from the moving surface and branching to an entry point of the control program, wherein the remote downloader start-up surface judging means comprises a minimum boot process required by the boot means Is performed, determine the activation surface of the remote downloader from the report of the activation surface determination information from the activation surface determination information management means, and if the determination is successful, report the determination result to the remote downloader deployment means, If the determination is not normal, the reset wait unit is requested to wait for a reset, and the boot surface information determination management unit reports boot surface determination information in response to a request from the remote downloader boot surface determination unit, and the firmware version Updating of start-up surface judgment information with version upgrade in accordance with instructions from upgrade means The version information management means reports version information in response to a version information report request from the firmware version upgrade management means, and updates the version information in response to a request from the firmware version upgrade means. When the firmware version information of the firmware reported from the version information management means is reported to the higher-level device, the higher-level device is inquired about the necessity of upgrading the firmware, and the higher-level device receives an instruction that the firmware version is required. Performs the firmware download via the firmware download means, determines the success or failure of the firmware download processing immediately after the firmware download, Requesting the control software deploying means to deploy the control program, and as to the necessity of version upgrade of the remote downloader in the firmware, the remote downloader individual version information of the remote downloader reported from the version information managing means is used. Judgment is made from the remote downloader individual version information in the downloaded firmware, and if it is judged that it is necessary, the firmware version upgrade means is requested to upgrade the remote downloader. It is determined in the same manner as the downloader, and if it is determined that it is necessary, the firmware version upgrade means is requested to upgrade the control program, and The firmware version upgrade result is reported to the control software deployment means, and the firmware upgrade means stores the downloaded firmware in the flash ROM according to an instruction from the firmware version upgrade management means. And instructing the activation plane determination information management means to update the activation plane determination information with the version upgrade, and instructing the version information management means to update the version information with the version upgrade.
[0018]
According to this configuration, especially during the remote downloader's own remote download processing, the remote downloader appropriately controls the startup plane determination information, and even if a communication path failure or a power failure occurs, the target system is started after reset. It is possible, and the remote download function can always be secured.
[0019]
A remote downloader according to a fifth aspect of the present invention is the remote downloader according to the fourth aspect of the present invention, wherein the boot surface determination information management means upgrades a remote downloader storage area on a flash ROM for upgrading the remote downloader. The target surface is managed as surface B for surface A, which is the next surface after the activation surface, or surface A for surface B, and the version upgrade target surface is erased and the remote downloader is written in accordance with the remote downloader version upgrade. When the update is completed, refer to the startup plane determination information of the current startup plane, and update the startup plane determination information of the current version upgrade target plane so that the current version upgrade target plane is determined as the next startup boot plane. It is characterized by rewriting.
[0020]
According to this configuration, since the startup plane is determined only by the startup plane determination information on the flash ROM, a special device (memory) other than the flash ROM is not required, and the two-side management method can be easily realized. be able to.
[0021]
A remote downloader according to a sixth aspect of the present invention is the remote downloader according to the fifth aspect of the present invention, in which the current upgrade target surface is determined to be the next activation surface by referring to the activation surface determination information of the current activation surface. As a method of rewriting the boot surface determination information of the current version upgrade target surface, the "rock-paper-scissors" logic is applied, and in the boot surface determination at startup, the one that "wins" the rock-paper-scissors is determined as the boot surface. In other words, the activation plane determination information of the current activation plane is "first out", and the activation plane determination information of the current version upgrade target plane is "late". The logic of “later” is determined, and the activation surface determination information management means rewrites the activation surface determination information of the current version upgrade target surface.
[0022]
According to this configuration, it is possible to easily realize the start-up surface determination process using a very simple logic of “paper-scissors”.
[0023]
A remote downloader according to a seventh aspect of the present invention is the remote downloader according to any one of the fourth to sixth aspects, wherein the start-up surface determination information managing means is configured to determine a version upgrade target surface associated with the remote upgrader version upgrade. Immediately before erasing, all bits of the activation plane determination information of the plane to be upgraded are set to “0”.
[0024]
According to this configuration, by using the characteristics of the flash ROM, it is possible to easily determine the erasing process and the writing process completion status of the flash ROM.
[0025]
According to an eighth aspect of the present invention, in the remote downloader according to any one of the fourth to seventh aspects, the remote downloader according to any one of the fourth to seventh aspects detects a processing abnormality such as a software failure in the remote download processing, and executes the startup plane determination information management means Remote starter program failure detection means for requesting control of startup plane determination information and requesting the reset waiting means to wait for resetting, wherein the startup plane determination information management means starts up from the remote downloader program failure detection means. By the control request of the plane determination information, the activation plane determination information of the current activation plane is rewritten so that the current activation plane is not determined to be the next activation plane, and the remote downloader activation plane determination means is reported from the activation plane determination information management means. From the rewritten startup plane determination information, Characterized in that it does not determined that the resident boot surface.
[0026]
According to this configuration, in particular, during the remote downloader's own remote download processing, the remote downloader appropriately controls the startup surface determination information, and in addition to the communication path failure and the power failure, the remote downloader's own startup Even if a failure such as a program runaway due to a failure or the like occurs, the target system can be started after the reset, and the remote download means can always be secured.
[0027]
A remote downloader according to a ninth aspect of the present invention is the remote downloader according to any one of the fourth to eighth aspects, wherein the remote downloader activation surface determination means is an A surface when the system is initially started. If the remote downloader is stored in the storage area, even if the erasing is completed in the flash ROM in which the activation plane determination information of the remote downloader storage area and all bits of the entire remote downloader storage area on the B side are “1”, It is characterized in that the determination process of the starting surface in the subsequent system operation is normally performed.
[0028]
According to this configuration, after erasing the entire flash ROM at the time of initial system startup, it is possible to start up the system by writing a remote download program only to the A side, and to write a normal value to the startup side determination information for both sides. Also, there is no need to write a remote download program on the B side.
[0029]
A remote downloader according to a tenth aspect of the present invention is the remote downloader according to any one of the fourth to ninth aspects, wherein a version upgrade from the boot unit, the remote downloader activation plane determination unit, and the firmware version management unit is performed. A version upgrade determination information management unit that controls version upgrade determination information in response to a determination information control request, and reports version upgrade determination information in response to a version upgrade determination information report request from the firmware version management unit; Means for performing a minimum boot process required for expanding the remote download program from the flash ROM to the RAM and other boot processes, and initialize the version upgrade determination information to the version upgrade. Requesting the remote downloader activation plane determination means, after the minimum boot processing required by the boot means, based on the report of the activation plane determination information from the activation plane determination information management means, And if the determination is successful, the determination result is reported to the remote downloader developing means and the version upgrade determination information management means.If the determination is not successful, a reset wait is requested to the reset waiting means. The firmware version upgrade management means reports the firmware version information reported from the version information management means to the higher-level device, inquires of the higher-level device about the necessity of firmware upgrade, and determines that the higher-level device needs If you receive the instruction of the firmware The firmware download is performed via the download means, the pass / fail of the firmware download processing is confirmed, and if it is determined to be unsuccessful, the version upgrade processing is stopped, and the control software development means is requested to develop the control program. The necessity of version upgrade of the internal remote downloader is determined based on the remote downloader individual version information reported from the version information management means and the remote downloader individual version information in the downloaded firmware, and the determination result is determined by the version upgrade determination information management means. Similarly, the necessity of version upgrade of the control program in the firmware is determined by the same method as that of the remote downloader, and the determination result is reported to the version upgrade determination information management means. If it is determined that the firmware is necessary, the control software development unit requests the development of the control program from the firmware primary storage area, which is an area on the RAM that temporarily stores the downloaded firmware. Requesting the control software development means to expand the control program from the control software on the flash ROM, and after the control software is activated, the version upgrade determination information management means reports the version of the remote downloader in the remote downloader processing. If it is determined that the firmware needs to be upgraded, the firmware version upgrade means is requested to upgrade the remote downloader. Similarly, if it is determined that the control program needs to be upgraded in the remote downloader process, the firmware is upgraded. Requesting the version upgrade means to the control program, and if the necessity of version upgrade of the remote downloader or the control program has not been normally determined, requesting the reset waiting means to wait for a reset, and updating the host device to the version upgrade. The feature is to report the result.
[0030]
According to this configuration, it is not necessary to execute the process of writing the firmware to the flash ROM at the time of startup, and after startup, the firmware is written to the flash ROM as a low-priority process that does not affect the main control process. By performing the writing process, the startup time until the start of the main control process can be significantly reduced.
[0031]
According to a eleventh aspect of the present invention, in the remote downloader according to any one of the fourth to tenth aspects, it is determined by the report from the firmware version upgrade management means that the firmware remote downloader needs to be upgraded. In this case, the remote downloader includes an autonomous restarting unit that performs an autonomous restarting process of the remote downloader. From the report of the boot surface determination information and the report of the version upgrade determination information from the version upgrade determination information management unit, the boot surface of the remote downloader is determined, and if the determination is successful, the determination result is compared with the remote downloader deployment unit and the remote downloader deployment unit. Version upgrade Report to the constant information management means, and when the determination is not successful, request the reset waiting means to wait for a reset, and the remote downloader deployment means, based on the report of the remote downloader activation surface from the remote downloader activation surface determination means, If the deployment from the firmware primary storage area is reported, the remote download program on the firmware primary storage area is deployed, and if the deployment from the remote downloader storage area on the flash ROM is reported, the reported remote downloader storage area The firmware download upgrade management means expands the remote download program from the start surface of the program and branches to an entry point of the developed remote download program. If it is determined from the upgrade determination information that the firmware version upgrade determination is not required, the firmware download processing from the higher-level device and the necessity determination of the firmware version upgrade are not performed, and if it is determined that the firmware version upgrade determination needs to be performed, When the firmware version information reported from the version information management means is reported to the higher-level device, the higher-level device is inquired about the necessity of upgrading the firmware, and when the higher-level device receives an instruction that the firmware version is necessary, The firmware download is executed via the firmware download means, the pass / fail of the firmware download processing is confirmed, and if it is determined to be unsuccessful, the version upgrade processing is stopped, and the control Requesting the deployment of the firmware, the necessity of upgrading the version of the remote downloader in the firmware is determined based on the remote downloader individual version information reported from the version information management means and the remote downloader individual version information in the downloaded firmware. The result of the determination is reported to the version upgrade determination information management means, and if it is determined that the version is necessary, the autonomous restart means is requested to autonomously restart the remote downloader. A determination is made in the same manner as the remote downloader, and the determination result is reported to the version upgrade determination information management means. If it is determined that the control program is necessary, the control software development means reads the control program from the primary storage surface on the RAM. Requires deployment If it is determined that the control software is not required, the control software developing means is requested to develop the control program from the control software on the flash ROM. If it is determined in the remote downloader process that the remote downloader needs to be upgraded, a request is made to the firmware version upgrade means to upgrade the remote downloader, and similarly, it is determined that the control program needs to be upgraded in the remote downloader process. In this case, the firmware version upgrade means requests a version upgrade of the control program, and if the necessity of version upgrade of the remote downloader or the control program has not been normally determined, the Requesting reset waiting to set waiting means and to report the version-up result to the host device.
[0032]
According to this configuration, after upgrading the version of the remote download program, the upgraded version of the remote download program can be autonomously restarted without performing reset processing.
[0033]
A remote downloader according to a twelfth aspect of the present invention is the remote downloader according to any one of the fourth to eleventh aspects, wherein the startup plane determination information management means stores each information element of the startup plane determination information in a redundant bit. It is characterized in that it is managed in a multi-bit configuration having.
[0034]
According to this configuration, a hardware failure such as deterioration of the memory device and a software failure such as a failure of the remote download program can be realized by simple means.
[0035]
A remote downloader according to a thirteenth aspect of the present invention is the remote downloader according to any one of the fourth to eleventh aspects, wherein the version-up determination information management means stores each information element of the version-up determination information in a redundant bit. It is characterized in that it is managed in a multi-bit configuration having.
[0036]
According to this configuration, a hardware failure such as deterioration of the memory device and a software failure such as a failure of the remote download program can be realized by simple means.
[0037]
A base station apparatus according to a fourteenth aspect of the present invention includes the remote downloader according to any one of the first to thirteenth aspects.
[0038]
According to this configuration, in the wireless communication device, the same operation and effect as any of the above can be obtained.
[0039]
The remote download method of the invention according to claim 15 performs a minimum boot process for expanding the remote downloader from the flash ROM to the RAM, determines the start surface of the remote downloader from the start surface determination information, and normally executes the boot process. If it cannot be determined, it waits for a reset.If it can be determined normally, it deploys the remote downloader from the startup surface indicated by the determination result, branches to the expanded remote downloader entry point, and performs the remaining boot processing. , Reports the firmware version information to the higher-level device, inquires of the higher-level device about the necessity of upgrading the firmware, and executes the firmware download when the higher-level device indicates that the firmware version is required. And was determined to have failed If this is the case, cancel the version upgrade process and deploy the control program.The necessity of upgrading the remote downloader in the firmware is determined based on the remote downloader individual version information and the remote downloader individual version information in the downloaded firmware. If it is determined, the version of the remote downloader is upgraded, the startup plane determination information and the version information are updated with the version upgrade, and the necessity of upgrading the control program in the firmware is similarly determined as the remote downloader. If it is determined that it is necessary, the version of the control program is upgraded, the version information is updated with the version upgrade, and the firmware version upgrade Reported, the control program from the flash ROM developed on RAM, and characterized in that branching to the entry point of the control program.
[0040]
According to this method, particularly during the remote downloader's own remote download processing, the remote downloader appropriately controls the startup plane determination information, and even if a communication path failure or a power failure occurs, the target system is started after reset. It is possible, and the remote download function can always be secured.
[0041]
A remote download method according to a sixteenth aspect of the present invention is the remote download method according to the fifteenth aspect, wherein the version upgrade target surface is managed as the next surface of the activation surface, and the version upgrade target surface associated with the remote downloader version upgrade is updated. When the writing of the erase and remote downloader is completed, refer to the activation plane determination information of the current activation plane, and determine the activation plane determination information of the current upgrade target plane so that the current upgrade target plane is determined as the next activation plane. It is characterized by rewriting.
[0042]
According to this method, since the determination of the boot surface is performed only by the boot surface determination information in the flash ROM, a special device (memory) other than the flash ROM is not required, and the two-surface management method can be easily realized. be able to.
[0043]
According to a seventeenth aspect of the present invention, in the remote download method according to the fifteenth aspect, the current upgrade target surface is determined to be the next activation surface by referring to the activation surface determination information of the current activation surface. Applying the `` rock-paper-scissors '' logic as a method of rewriting the boot surface determination information of the current version upgrade target surface, and in the boot surface determination at startup, the one who `` wins '' the `` rock-paper-scissors '' is determined to be the boot surface, By comparing the activation plane determination information of the current activation plane with “first out” and the activation plane determination information of the current version upgrade target plane as “late”, the logic of “late” so that “win” is achieved with respect to the logic of “first” Is determined, and the activation surface determination information of the current version upgrade target surface is rewritten.
[0044]
According to this method, it is possible to easily realize the start-up surface determination process using a very simple logic of “paper-scissors”.
[0045]
The remote download method according to the eighteenth aspect of the present invention is the remote download method according to any one of the fifteenth to seventeenth aspects, wherein immediately before erasing the version upgrade target surface accompanying the version upgrade of the mote downloader, It is characterized in that all bits of the activation plane determination information of the plane to be upgraded are set to “0”.
[0046]
According to this method, by using the characteristics of the flash ROM, it is possible to easily determine the completion status of the erasing process and the writing process of the flash ROM.
[0047]
The remote download method according to the nineteenth aspect of the present invention is the remote download method according to any one of the fifteenth to eighteenth aspects, wherein when a processing abnormality such as a software defect is detected in the remote download processing by the remote downloader, Rewrite the startup plane determination information of the current startup plane so that the startup plane is not determined to be the next startup plane, wait for a reset, and reset the next startup. Is not determined.
[0048]
According to this method, in particular, during the remote download process of the remote downloader itself, the remote downloader appropriately controls the start-up surface determination information, and in addition to the communication path failure and the power failure, the remote downloader itself is activated. Even if a failure such as a program runaway due to a failure or the like occurs, the target system can be started after the reset, and the remote download function can always be secured.
[0049]
The remote download method according to a twentieth aspect of the present invention is the remote download method according to any one of the fifteenth to nineteenth aspects, wherein the remote downloader is located in one side of the remote downloader storage area when the system is initially started. If it is stored, even if the activation plane determination information of the remote downloader storage area and all the bits of the entire remote downloader storage area, which is the other side, are “1” indicating the erase completion state in the flash ROM, the subsequent system It is characterized in that it is possible to normally execute a start-up surface determination process in operation.
[0050]
According to this method, it is possible to start up the system by erasing the entire flash ROM at the time of initial start-up of the system and then writing the remote download program only to the A-side, and writing a normal value to the start-up surface determination information for both sides. Also, there is no need to write a remote download program on the B side.
[0051]
A remote download method according to a twenty-first aspect of the present invention is the remote download method according to any one of the fifteenth to twentieth aspects, wherein the minimum download after the boot processing for expanding the remote downloader from the flash ROM to the RAM is performed. Initialize the version upgrade determination information, determine the startup surface of the remote downloader from the startup surface determination information, and if the determination is successful, deploy the remote downloader from the startup surface indicated by the determination result. Branch to the entry point, and store the determination result in the version upgrade determination information initialized earlier. Regarding the necessity of upgrading the remote downloader in the firmware, the remote downloader individual version information and the Judge from the remote downloader individual version information, store the judgment result in the upgrade judgment information, judge the necessity of version upgrade of the control software in the firmware in the same way as the remote downloader, and judge the upgrade result Information, and if it is determined that the control program needs to be upgraded based on the version upgrade determination information, the control program from the primary storage surface on the RAM is expanded. After deploying the control program from the control software and starting the control software, refer to the version upgrade determination information.If the remote downloader processing determines that the remote downloader needs to be upgraded, upgrade the remote downloader. , Ba Update the startup plane determination information and the version information along with the version upgrade.Referring to the version upgrade determination information in the same manner, if it is determined that the control program needs to be upgraded in the remote downloader process, the control program Upgrade the version, update the version information according to the version upgrade, and refer to the version upgrade information. It is characterized by performing.
[0052]
According to this method, it is not necessary to execute the process of writing the firmware to the flash ROM at the time of startup, and after the startup, the firmware is written to the flash ROM as a low-priority process that does not affect the main control process. By performing the writing process, the startup time until the start of the main control process can be significantly reduced.
[0053]
A remote download method according to a twenty-second aspect of the present invention is the remote download method according to any one of the fifteenth to twenty-first aspects, wherein after the minimum necessary boot processing, the remote download method uses the startup plane determination information and the version upgrade determination information. Judge the starter of the downloader, if it can be judged normally and start from the primary storage area of the firmware, deploy the remote downloader on the primary storage area of the firmware, and do not need to perform the firmware upgrade judgment from the upgrade information Is not performed, the firmware download processing from the higher-level device and the necessity of firmware version upgrade are not performed, and the firmware download process from the higher-level device is performed only when it is determined that the firmware version upgrade determination is required. When the firmware download process from the host device and the firmware version upgrade necessity determination are performed and the remote downloader individual version upgrade is determined to be necessary, the remote downloader autonomously restarts. When the startup is performed and it is determined that the remote downloader individual version upgrade is unnecessary, the necessity determination of the version upgrade of the control software in the firmware is continuously performed by the same method as the remote downloader.
[0054]
According to this method, after upgrading the remote download program, the upgraded remote download program can be autonomously restarted without performing reset processing.
[0055]
A remote download method according to a twenty-third aspect of the present invention is the remote download method according to any one of the fifteenth to twenty-second aspects, wherein each information element of the activation plane determination information has a multi-bit configuration having redundant bits. And / or managing each information element of the version-up determination information in a multi-bit configuration having redundant bits.
[0056]
According to this method, a hardware failure such as deterioration of a memory device or a software failure such as a failure of a remote downloader program can be realized by simple means.
[0057]
Hereinafter, before describing an embodiment of the present invention, an outline of a system that implements a remote downloader will be described with reference to FIG.
[0058]
The remote download is performed for the purpose of realizing the program version upgrade by remote control, and is performed between the higher-level device 101 and the target system 100, and the program held by the higher-level device 101 is transmitted to the target system 100. Remote download. The host device 101 and the target system 100 are connected via a communication path. The target system 100 includes at least a CPU 201, a flash ROM (non-volatile memory) 102, a RAM (volatile memory) 103, and a host device communication controller 202.
[0059]
Next, an example of a communication protocol for remote download performed between the higher-level device 101 and the target system 100 will be described with reference to FIG.
In step (ST) 311, the target system 100 checks the currently held program version. Then, in step 312, the program version confirmed in the previous step is reported to the host device 101.
[0060]
Next, in step 321, the host device 101 compares the program version held by itself with the program version reported from the target system 100 to determine whether there is a version upgrade. Then, in step 322, the host device 101 instructs the target system 100 whether or not there is a version upgrade. After that, in step 330, remote download is performed between the host device 101 and the target system 100.
[0061]
After the remote download is completed, the target system 100 checks whether the download process is successful or not by a method such as a sum value check. In step 341, the target system 100 performs a version upgrade process. Then, in step 342, the result of the version upgrade is reported to the higher-level device 101. Next, in step 350, the host device 101 updates the program version information of the target system 100 from the report of the version upgrade result, and grasps the program version of the target system 100.
[0062]
Note that the following description will be made on the premise of the communication protocol, but the same applies to other communication protocols.
[0063]
Finally, the firmware version system will be described with reference to FIG.
The firmware is composed of an FDP (remote download program) and control software, and is composed of an individual version 4201 of FDP and an individual version 4202 of control software, in addition to a version 4200 of the entire firmware.
[0064]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
(Embodiment 1)
FIG. 1 is a block diagram showing a configuration of the remote downloader according to Embodiment 1 of the present invention. The remote downloader according to the present embodiment is provided, for example, in a base station apparatus of a mobile communication system.
[0065]
1, a flash ROM 102 and a RAM 103 are mounted on a remote downloader 100A, and are connected to a host device 101 via a communication path 200 (see FIG. 49). An FDP storage area (side A) 110 and an FDP storage area (side B) 111 are present as areas for storing the FDP 113 on the flash ROM 102, and activation plane determination information 112 _A and 112 _B are stored in the respective areas. I have. The flash ROM 102 also stores version information 114 such as firmware.
[0066]
The remote downloader 100A includes a boot unit 120, an FDP starting plane determining unit 121, an FDP expanding unit 123, a starting plane determining information managing unit 130, a version information managing unit 131, a firmware upgrade managing unit 140, a firmware version It includes an upload unit 150, a firmware download unit 160, a host device communication unit 161, a control software deployment unit 170, and a reset waiting unit 180.
[0067]
The boot unit 120 performs a minimum boot process for expanding the FDP 113 from the flash ROM 102 to the RAM 103 and other boot processes. The FDP activation plane determination unit 121 determines the activation plane of the FDP 113 based on the report of the activation plane determination information 112 from the activation plane determination information management unit 130 after the minimum necessary boot processing. Is reported to the FDP developing means 123, and if the judgment is not successful, the reset waiting means 180 is requested to wait for a reset. The FDP expanding unit 123 expands the FDP 113 from the reported start plane based on the report of the FDP start plane from the FDP start plane determining unit 121, and branches to the entry point of the expanded FDP 113.
[0068]
The firmware version upgrade management means 140 reports the firmware version information 114 reported from the version information management means 131 to the higher-level device 101 via the higher-level device communication means 161, and it is necessary to upgrade the firmware of the higher-level device 101. When a request is received from the higher-level device 101, the firmware is downloaded via the firmware download unit 160. Then, the pass / fail of the firmware download processing is confirmed by a method such as a checksum value, and if it is determined to be unsuccessful, the version upgrade processing is stopped, and the control software development means 17 is requested to develop the control software.
[0069]
Whether the FDP in the firmware needs to be upgraded is determined by the present unit based on the FDP individual version information 4201 reported from the version information management unit 131 and the FDP individual version information 4201 in the downloaded firmware. If it is determined that it is necessary, the firmware upgrade unit 150 is requested to upgrade the FDP 113, and similarly, the necessity of upgrade of the control software in the firmware is determined by the same method as the FDP. If it is determined that it is necessary, a request is made to the firmware upgrade unit 150 to upgrade the control software, the upgrade result is reported to the host device 101 via the host device communication unit 161, and the control software deployment unit 170 is controlled. Request software deployment.
[0070]
The version information management unit 131 reports the version information 114 in response to a request from the firmware version upgrade management unit 140, and updates the version information 114 in response to a request from the firmware version upgrade unit 150. The higher-level device communication means 161 reports the version information 114 to the higher-level device 101 in response to a request from the firmware version upgrade management means 140, and reports an instruction regarding the necessity of version upgrade from the higher-level device 101 to the firmware version upgrade management means 140. Then, communication is performed with the higher-level device 101 for download processing according to an instruction from the firmware download unit 160, and the upgrade result information is reported to the higher-level device 101.
[0071]
The firmware download unit 160 downloads firmware from the higher-level device 101 via the higher-level device communication unit 161 according to an instruction from the firmware version upgrade management unit 140. The firmware upgrade unit 150 stores the downloaded firmware in the flash ROM 102 according to an instruction from the firmware upgrade management unit 140. Then, it instructs the activation plane determination information management means 130 to update the activation plane determination information 112 with the version upgrade, and instructs the version information management means 131 to update the version information 114 with the version upgrade.
[0072]
The boot surface information management unit 130 reports the boot surface determination information 112 in response to a request from the FDP boot surface determination unit 121, and updates the boot surface determination information 112 accompanying the version upgrade in response to an instruction from the firmware version upgrade unit 150. carry out. The control software expanding means 170 expands the control software on the RAM 103 from the designated control software activation surface in accordance with the instruction from the firmware upgrade management means 140, and branches to the control software entry point. The reset waiting unit 180 continues to wait for a reset in response to a request from the FDP activation surface determination unit 121.
[0073]
The operation of the remote downloader 100A thus configured will be described with reference to FIGS.
[0074]
First, the startup plane determination information 112 will be described in detail with reference to FIGS.
The boot plane determination information 112 is information for determining a boot plane, and is stored at the head of each of the FDP storage area (side A) 110 and the FDP storage area (side B) 111 on the flash ROM 102. The FDP activation plane determination unit 121 determines the activation plane by referring to the activation plane determination information 112 on both the A side and the B side. The startup plane determination information management unit 130 controls the startup plane determination information 112 so that the FDP startup plane determination unit 121 can perform appropriate startup plane determination.
[0075]
9 and 10 are bitmaps of the activation plane determination information 112. The startup plane determination information 112 includes startup plane determination information_1 and startup plane determination information_2. The activation plane determination information_1 is a flag indicating whether or not an abnormality has occurred during the FDP processing. On the other hand, the startup plane determination information_2 is a flag indicating the status of the FDP version upgrade process.
[0076]
FIG. 12 is a diagram illustrating a method of determining a startup plane during operation in a normal case. The reverse of the flag states of the A-side and the B-side of the item numbers 1 to 3 correspond to the item numbers 4 to 6.
When the activation plane determination information # 2 on the sides A and B indicates that the flash ROM version upgrade has been completed,
Goo 0000 0000 0000 1111
0000 0000 1111 1111
0000 1111 1111 1111
Based on the logic of “paper-scissors”, the “winner” is determined to be the start surface.
[0077]
As the control, when the upgrade of one surface is completed, the activation surface determination information # 2 of one surface is set so as to “delay” the other surface and deliberately win “Janken”. For example, as shown in FIG. 11, when the item No. 1 is in the flag state, it is started from the side A, but after the start on the side A, the side B is upgraded, and when the upgrade is completed, the side B is activated. The surface determination information # 2 is controlled as in item number 4.
[0078]
Such a ternary logic is used to minimize the flash ROM erasing process, which requires a long processing time, in the startup plane control processing, and the startup plane determination logic is controlled only by controlling the bit value “1” to the bit value “0”. It is to realize.
[0079]
FIG. 13 is a diagram showing a boot surface determination method during flash ROM version upgrade in the quasi-normal case. The reverse of the flag states of the A-side and B-side of the item No. 1 corresponds to the item No. 2. In addition, although the description will be given in the second embodiment at the time of the initial startup of the system, item No. 3 shows a case where the flash ROM version is upgraded for the first time after the initial startup of the system.
[0080]
When the activation surface determination information # 2 of one surface is during flash ROM erase or flash ROM writing, the other surface is determined as the activation surface. As control, immediately before flash ROM erasing is performed, all the boot surface determination information # 2 of the version upgrade target surface is set to “0” (in flash ROM erasing) by software, and when flash ROM erasing is completed, hardware All are set to "1" (during flash ROM writing). When the flash ROM version upgrade is completed, the startup plane determination information # 2 is set to the flash ROM version upgrade completion by software.
[0081]
The state during the double-sided flash ROM writing of item No. 3 in FIG. 13 is the same as the system initial start-up state described in the second embodiment. There is no.
[0082]
Subsequently, the operation of the remote download process will be described with reference to the flowcharts of FIGS.
[0083]
First, the main flow will be described with reference to FIG. In the figure, steps 703, 710, 711, and 712 are subroutines, and will be separately described as subflows.
In step 701, a minimum boot process for expanding the FDP from the flash ROM to the RAM is performed. Next, in step 703, the starting plane of the FDP is determined from the starting plane determination information. If the FDP cannot be determined normally, a reset wait is performed. If the determination is successful, in step 704, the FDP is developed from the starting surface indicated by the determination result. In step 705, the process branches to the entry point of the developed FDP. In step 706, other remaining boot processing is performed.
[0084]
In step 707, the firmware version information is reported to the higher-level device, the upper-level device is inquired about the necessity of upgrading the firmware, and when the higher-level device is instructed by the higher-level device, step 708 is performed. In step 708, the firmware download is performed, and the pass / fail of the firmware download processing is confirmed by a method such as a sum value check. If it is determined that the firmware download processing has failed, the version upgrade processing is stopped and the control software is deployed.
[0085]
In step 710, the necessity of upgrading the FDP in the firmware is determined based on the FDP individual version information and the FDP individual version information in the downloaded firmware. If it is determined that the FDP is necessary, step 711 is performed. In step 711, the FDP is upgraded (stored in the flash ROM), and the startup plane determination information and the version information are updated with the upgrade.
[0086]
In step 712, it is determined whether the version of the control software in the firmware needs to be upgraded as in step 710. If it is determined that the version is necessary, step 713 is performed. In step 713, the control software is upgraded (stored in the flash ROM), and the version information is updated with the upgrade. In step 714, the firmware version upgrade result is reported to the host device. In step 715, the control software is loaded on the RAM from the flash ROM. In step 716, the process branches to an entry point of the control software.
[0087]
Next, the sub-flow FDP start-up surface determination process_1 will be described with reference to FIG.
In step 1102, the activation plane is determined from the activation plane determination information_2 on the A and B sides. If the determination is normal, the determination result is as shown in steps 1102-1 to 1102-8. If the determination is not normal, it is determined that the flag is abnormal, and the ALM process is performed. FIG. 7 is a sub-flow showing the ALM process. In this figure, in step 2301, a process of waiting for resetting (infinite loop of empty process) is performed.
[0088]
Next, the sub-flow FDP version upgrade determination_1 will be described with reference to FIG.
In step 1501, an individual version upgrade determination is performed. Specifically, the determination is made based on the FDP individual version information managed by the remote downloader and the FDP individual version information in the downloaded firmware. If the versions are different, it is determined that the FDP version needs to be upgraded as in step 1501-1. If the versions are the same, it is determined that the FDP version upgrade is not necessary as in step 1501-2.
[0089]
Next, referring to FIG. 6, a description will be given of the sub-flow FDP version upgrade (flash ROM rewriting).
In step 1901, the FDP start plane is determined. In the first embodiment, the determination is performed according to the procedure of FDP startup plane determination_1 in FIG. 3, and in the second embodiment described later, the determination is performed according to the procedure of FDP startup plane determination_2 in FIGS. Further, in the third and fourth embodiments, since the upgrade determination information is used, the determination can be made by using the FDP activation plane determination result flag in the version determination information.
[0090]
As in Step 1901-1 and Step 1901-2, when the FDP activation surface is the A surface, the FDP upgrade surface is the B surface. When the FDP activation surface is the B surface, the FDP version upgrade surface is the A surface. In step 1902, “0_0_0_0” (0x0000) is written to the activation plane determination information_2 of the FDP version upgrade plane.
[0091]
In step 1903, the flash ROM is erased to upgrade the FDP. In step 1904, a program is written to the flash ROM for upgrading the FDP. In step 1905, rock-paper-scissors logic is applied according to the startup plane determination information_2 of the FDP startup plane. If it can be applied normally, a value is written to the activation plane determination information_2 of the FDP version upgrade plane as in steps 1905-1 to 1905-3. If it cannot be applied normally, as in step 1905-4, ALM processing is performed as a flag abnormality.
[0092]
Next, the control software version upgrade determination_1, which is a subflow, will be described with reference to FIG.
In step 1701, an individual version upgrade determination is performed. Specifically, the determination is made based on the control software individual version information managed by the remote downloader and the control software individual version information in the downloaded firmware. If the versions are different, it is determined that the control software needs to be upgraded as in step 1501-1. If the versions are the same, it is determined that control software version upgrade is not necessary as in step 1501-2.
[0093]
Finally, the operation of the remote download processing will be described with reference to the physical configuration diagram of FIG.
The remote downloader 100 basically includes a flash ROM 102 and a RAM 103. On the flash ROM 102, an activation plane determination program storage and operation area 2401, an FDP storage area (side A) 110, and an FDP storage area (side B) ) 111 and a control software storage area 2404. On the RAM, three areas, an FDP operation area 2403, a firmware temporary storage area 2402, and a control software operation area 2405 are secured.
[0094]
The boot plane determination program 2410 determines the boot plane from the boot plane determination information 112_A of the FDP storage area (plane A) 110 and the boot plane determination information 112_B of the FDP storage area (plane B) 111, and determines the FDP storage area (plane A). Either the FDP 113_A of 110) or the FDP 113_B of the FDP storage area (surface B) 111 is developed in the FDP operation area 2403, and the flow branches to the entry point of FDP 113_D.
[0095]
The FDP 113_D on the PDP operation area 2403 downloads the firmware from the higher-level device 101 to the firmware temporary storage area 2402 in the remote downloader 100 based on the upgrade determination information 501 and the like. If it is determined that the FDP needs to be upgraded, the FDP 113_K on the firmware temporary storage area 2402 is upgraded to the FDP storage area corresponding to the next surface of the startup surface.
[0096]
Similarly, when it is determined that the control software needs to be upgraded, the control software 2420_K in the firmware temporary storage area 2402 is upgraded to the control software storage area 2404. Finally, the control software 2420_S in the control software storage area 2404 is developed in the control software operation area 2405, and branches to the entry point of the control software 2420_D. The control software 2420_D on the control software operation area 2405 starts the main processing for controlling the incorporation processing.
[0097]
As described above, according to the remote downloader 100A of the present embodiment, particularly during the remote download processing of the FDP itself, the FDP appropriately controls the startup plane determination information, and a communication path failure and a power failure occur. However, after the reset, the remote downloader can be started, and the remote download function can always be secured. In addition, the method can be easily implemented without requiring any special device (memory or the like) other than the flash ROM.
[0098]
(Embodiment 2)
FIG. 14 is a block diagram showing a configuration of a remote downloader according to Embodiment 2 of the present invention. The remote downloader 100B according to the present embodiment includes the same configuration as the remote downloader 100A according to the first embodiment, and further includes an FDP program failure detection unit 400. The FDP program failure detection means 400 detects a processing abnormality such as a software failure in the remote download processing by the FDP, requests the startup plane determination information management section 130 to control the startup plane determination information, and causes the reset waiting section 180 to wait for a reset. Request.
[0099]
In addition to the processing described in the first embodiment, the startup plane information management unit 130 determines that the current startup plane is not determined to be the next startup plane by the control request of the startup plane determination information from the FDP program failure detection unit 400. Rewrite the startup plane determination information of the startup plane. The reset waiting unit 180 continues to wait for a reset in response to a request from the FDP program failure detection unit 400 in addition to the processing described in the first embodiment.
[0100]
The operation of the remote downloader 100B thus configured will be described with reference to FIGS.
First, the activation plane determination information 112 will be described in detail with reference to FIGS.
[0101]
FIG. 20 is a diagram illustrating a startup plane determination method when an FDP processing abnormality occurs in the quasi-normal case. The reverse of the flag states of the A-side and B-side of the item No. 1 corresponds to the item No. 2. Item 3 shows a case where the FDP processing becomes abnormal for the first time after the flash ROM version upgrade is completed after the initial system startup. When the activation plane determination information_1 of one surface is abnormal in the FDP processing, the other surface is determined to be the activation surface. However, when the system is initially started (the other surface is writing to the flash ROM), there is no startup surface and the ALM waits for reset. As the control, when the software detects an abnormality in the FDP processing such as a CPU exception, the activation plane determination information_1 of the activation plane is all set to “0” (FDP processing abnormality) by the software, and the LM waits for reset.
[0102]
FIG. 19 is a diagram showing a startup plane determination method at the time of initial system startup in a normal case.
If the start-up surface determination information_2 for both surfaces is during flash ROM writing, it is determined that the system has been initially started, and the surface A is fixed and determined to be the start-up surface. When the system is initially started, the start-up surface determination information for the side A and the side B is in a flash ROM erased state, that is, all are set to “1”. The FDP is stored on the A side using ICE or the like, and the FDP is not stored on the B side.
[0103]
FIG. 21 is a diagram showing a start-up surface determination method in the case of a double failure in which the FDP processing abnormality occurs in combination with flash ROM erasing or flash ROM writing in the quasi-normal case. Inverting the flag states of the A-side and B-side of the item numbers 1 to 3 correspond to the item numbers 4 to 6. Item 7 shows a case in which a double failure occurs before the flash ROM version upgrade is completed for the first time after the initial system startup.
[0104]
The activation surface determination information_1 of one surface is FDP processing abnormal, the activation surface determination information_2 is flash ROM erase or flash ROM writing, and the activation surface determination information_1 of the other surface is FDP processing normal, activation surface determination information. Only when _2 indicates that the flash ROM version has been upgraded, the other surface is determined to be the activation surface. If the startup plane determination information_1 for both faces is abnormal in the FDP process, or if the startup face determination information_2 is during flash ROM erase or flash ROM write, it is determined that there is no startup face and the ALM waits for reset.
[0105]
The state during the double-sided flash ROM writing of the A-side FDP processing abnormality in item No. 7 in FIG. 21 is the same as the system initial start-up state in item No. 3 in FIG. So there is no problem.
[0106]
The flag state and the flag state transition of the activation plane determination information will be described with reference to FIGS.
FIG. 22 and FIG. 23 are diagrams showing the flag states of the startup plane determination information. For the status of the normal case, enclose the status number in “□”.
The total number of flag states that the activation plane determination information can take is 52. As for the normal case, one at the initial startup of the system and six at the time of operation, a total of seven. For the genuine upper case, there are M, three at the initial startup of the system, and 42 at the time of operation, for a total of 45 cases.
[0107]
The state of item No. 1 in FIG. 19 corresponds to the state numbers 0-0 in FIG. The states of item numbers 1 to 6 in FIG. 12 correspond to the state numbers 2-0, 4-0, 6-0, 3-0, 5-0, and 1-0 in FIGS. 22 and 23, respectively. The other states in FIGS. 22 and 23 are the states of the pure normal case.
[0108]
24 and 25 show flag state transition diagrams of the activation plane determination information.
First, the flag state transition at the time of initial system startup will be described.
The flag state 0-0 is at the time of the initial startup of the system. After resetting, by starting the FDP version upgrade, the state transits to the flag state 0-1 indicating that the B-side flash ROM is being erased. When the flash ROM erase is completed, the state transits to the flag state 0-0 indicating that the B-side flash ROM is being written. When the flash ROM write is completed, the state transits to the flag state 1-0 indicating the completion of the flash ROM version upgrade.
[0109]
When the ALM processing due to a software failure or the like is performed in the flag states 0-0 and 0-1, the state transits to the flag states 0-0-1 and 0-1-1 indicating the A-plane FDP processing abnormality, respectively. In the flag states 0-0-1 and 0-1-1, even if a reset is performed after that, the ALM is performed without the activation surface.
[0110]
Next, the flag state transition during operation will be described.
The flag state 1-0 indicates a version upgrade completed state, and after resetting, the surface B is determined to be the activation surface by the activation surface determination processing. After the activation on the side B, the version upgrade on the side A is started, so that a transition is made to the flag state 1-1 indicating that the flash ROM on the side A is being erased. When the flash ROM erasing is completed, the state transits to the flag state 1-2 indicating that the flash ROM writing on the A side is being performed, and when the flash ROM writing is completed, the state transits to the flag state 2-0 indicating the completion of flash ROM version upgrade.
[0111]
In the flag state 1-0, when the ALM processing is performed due to a software failure or the like, a transition is made to the flag state 1-0-1 indicating a B-side FDP processing abnormality. In the flag state 1-0-1, if the reset is performed thereafter, the surface A is determined to be the activation surface by the activation surface determination processing. After the activation on the A side, the version upgrade of the B side is started, so that a transition is made to the flag state 1-0-2 indicating that the B side is being erased. When the flash ROM erase is completed, the state transits to the flag state 6-2 indicating that the B-side flash ROM is being written. When the flash ROM write is completed, the state transits to the flag state 1-0 indicating the completion of the flash ROM version upgrade.
[0112]
When the ALM processing due to the software failure or the like is performed in the flag states 1-1 and 1-2, the state transits to the flag states 1-1-1 and 1-2-1 indicating the FDP processing abnormality, respectively. In the flag states 1-1-1 and 1-2-1, the ALM is performed without the activation surface even if the reset is performed thereafter. The flag states 2-0, 3-0, 4-0, 5-0, and 6-0 are exactly the same as the state transition from the flag state 1-0.
[0113]
The flag state transition starts from 0-0, 1-0, and 2-0 through the transitional states 1-1 and 1-2 that the flash ROM version is being upgraded, unless the ALM processing is performed due to a software failure or the like. And so on, 3-0, 4-0, 5-0, 6-0, and again back to 1-0. The state of 0-0 does not change after the initial startup of the system.
[0114]
Subsequently, the operation of the remote download process will be described with reference to the flowcharts of FIGS.
First, the main flow will be described with reference to FIG. Steps 803, 810, 811 and 812 are subroutines and will be described separately as subflows.
[0115]
Steps 801 to 816 are the same as steps 701 to 716 in FIG. 2 showing the first embodiment. However, the method of determining the FDP activation plane in step 803 is different. The FDP activation plane determination_2 will be described with reference to the subflows of FIGS.
When a CPU exception occurs, in step 851, the FDP activation surface is determined. In step 852, “0” indicating the FDP processing abnormality is written in the activation plane determination information_1 of the FDP activation plane.
[0116]
Next, the FDP activation plane determination process_2, which is a subflow, will be described with reference to FIGS.
In step 1201, the activation plane is determined from the activation plane determination information_1 of the A and B planes. If the startup plane exists because the determination can be made normally, the determination result is as shown in step 1201-1-1 or step 1201-2-1. If the determination is normal but there is no activation surface, the determination result is as shown in step 1201-1-2 or step 1201-2-2, and the ALM process is performed. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0117]
In step 1202, the activation plane is determined from the activation plane determination information_2 of the A and B planes. If the determination is normal, the determination results are as shown in steps 1202-1 to 1202-8. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0118]
Note that the physical configuration is the same as in the first embodiment, and a description thereof will be omitted.
[0119]
As described above, according to the remote downloader 100B of the present embodiment, especially during the remote download processing of the FDP itself, the FDP appropriately controls the startup plane determination information, and the communication path as described in the first embodiment. The remote downloader can be started after reset even if a fault such as a program runaway occurs due to a fault of the running FDP itself, in addition to a fault or a power failure, and the remote download function can always be secured. . Further, the realization method can be easily implemented without requiring any special device (memory or the like) other than the flash ROM as in the first embodiment.
[0120]
(Embodiment 3)
FIG. 26 is a block diagram showing a configuration of a remote downloader according to Embodiment 3 of the present invention. The remote downloader 100C according to the present embodiment has the same configuration as the remote downloader 100B according to the second embodiment, and further includes an upgrade determination information management unit 500, and stores the upgrade determination information in the RAM 103. .
[0121]
The version upgrade determination information management unit 500 controls the version upgrade determination information in response to the control request of the version upgrade determination information from the boot unit 120, the FDP startup plane determination unit 121, and the firmware version management unit 140. The version upgrade determination information is reported in response to the version upgrade determination information report request. The boot unit 120 requests the version upgrade determination information management unit 500 to initialize the version upgrade determination information, in addition to the processing described in the first embodiment.
[0122]
In addition to the processing described in the first embodiment, the FDP activation surface determination unit 121 determines the activation surface of the FDP, and reports the determination result to the version upgrade determination information management unit 500 if the determination is successful. In addition to the processing described in the first embodiment, the firmware version upgrade management means 140 determines the determination result of the necessity of version upgrade of the FDP in the firmware and the determination result of the necessity of version upgrade of the control software in the firmware. This is reported to the version upgrade determination information management means 500. Then, after the control software is started, if it is determined by the report from the version upgrade determination information management unit 500 that the FDP process requires the upgrade of the FDP, the firmware upgrade unit 150 requests the firmware upgrade unit 150 to upgrade the FDP. Similarly, if it is determined in the FDP process that the control software needs to be upgraded, the firmware upgrade unit 150 is requested to upgrade the control software, and the necessity of upgrading the FDP or the control software is determined normally. If not, it requests the reset waiting means 180 to wait for a reset.
[0123]
The operation of the remote downloader 100C thus configured will be described with reference to FIGS.
[0124]
First, the upgrade determination information 501 will be described in detail with reference to FIGS.
The upgrade determination information 501 is information related to the upgrade, and is stored on the RAM 103. FIG. 36 and FIG. 37 are bitmaps of the version upgrade determination information 501. The version upgrade determination information 501 is composed of four pieces of information: a version upgrade determination implementation / not-performed flag, an FDP version upgrade determination flag, a control software version upgrade determination flag, and an FDP activation plane determination result flag.
[0125]
The upgrade determination execution / non-execution flag is used when performing an autonomous restart by branching the upgraded FDP described in the fourth embodiment, and determines whether the FDP itself is an initial startup process or an autonomous restart process. Used to identify
[0126]
The FDP version upgrade determination flag is used when executing the delayed flash ROM rewriting of the FDP of the firmware, and is performed by the control software processing after the transition of the operation state to the version of the FDP to be upgraded (saved on the temporary storage surface). It is used to determine whether to perform flash ROM writing. The control software version upgrade determination flag is used when performing delay flash ROM rewriting of the control software in the firmware, and in the control software process after the operation state transition, the version of the upgrade target (saved in the temporary storage surface) It is used to determine whether to write flash ROM of control software. The FDP start-up surface determination result flag is used to determine the version upgrade target surface (the next surface after the start surface is the version upgrade target surface).
[0127]
FIG. 38 is a diagram showing a version upgrade determination method.
If the FDP start-up surface determination result flag indicates the start-up surface A (surface B), the upgrade target surface is determined to be surface B (surface A). As the control, after the reset, the starting plane is determined according to the starting plane determination method, and the determination result is set in the FDP startup plane determination result flag.
[0128]
When the version upgrade determination execution / non-execution flag indicates that the version upgrade determination has not been performed, it is determined that it is an initial startup after reset. At the time of initial startup, a version upgrade determination process is performed by FDP. Conversely, when the version upgrade determination / not-performed flag indicates that version upgrade determination has been performed, it is determined that autonomous restart due to branching has occurred. At the time of the autonomous restart due to the branch, the version upgrade determination processing is already performed by the FDP, so that it is not performed. The autonomous restart due to the PDP branch will be described in a fourth embodiment.
[0129]
As the control, after performing the version upgrade determination process, the version upgrade determination implementation / non-implementation flag is set to the version upgrade determination implementation. Also, at the time of initial startup, the version upgrade determination execution / non-execution flag is initialized to the version upgrade determination not implemented.
[0130]
When the FDP version upgrade determination flag indicates that the FDP version upgrade is necessary, it is determined that the FDP flash ROM writing process by the control software is necessary after the operation state transition. As the control, after performing the version upgrade determination in the FDP process, the result of the FDP version upgrade determination is set in the FDP version determination flag.
[0131]
If the control software version upgrade determination flag indicates that the control software version needs to be upgraded, it is determined that the control software needs to write the control software to the flash ROM after the operation state transition. As the control, after performing the version upgrade determination in the FDP process, the control software version upgrade determination result is set in the control software version determination flag.
[0132]
Subsequently, the operation of the remote download process will be described with reference to the flowcharts of FIGS.
[0133]
First, the main flow will be described with reference to FIGS. Steps 902, 903, 909, 910, 914, and 916 are subroutines, and will be separately described as subflows.
[0134]
Step 901 is the same as step 701 of FIG. 2 showing the first embodiment. In step 902, the version upgrade determination information 501 is initialized. Next, in step 903, the start plane of the FDP is determined from the start plane determination information, and the determination result is stored in the version upgrade determination information 501. Steps 904 to 908 are the same as steps 703 to 708 in FIG. 2 showing the first embodiment.
[0135]
In step 909, the necessity of upgrading the FDP in the firmware is determined based on the FDP individual version information and the FDP individual version information in the downloaded firmware, and the determination result is stored in the upgrade determination information 501. The necessity of upgrading the software is determined by a method similar to that of the FDP, and the determination result is stored in the upgrade determination information 501.
[0136]
In step 910, when it is determined from the version upgrade determination information 501 that the control software needs to be upgraded, step 910-1 is performed, and when it is determined that the control software is not required, step 910-2 is performed. In step 910-1, the control software activation surface is set as the primary storage surface on the RAM. In step 910-2, the control software activation surface is set to the control software surface on the flash ROM.
[0137]
Steps 911 to 912 are the same as steps 715 to 716 in FIG. 2 showing the first embodiment. After starting the control software, in step 914, the version upgrade determination information is referred to, and if it is determined in the FDP process that the FDP version needs to be upgraded, step 915 is performed. If the necessity of the FDP version upgrade is not normally determined with reference to the version upgrade determination information, a reset wait is performed.
[0138]
In step 915, the FDP is upgraded (stored in the flash ROM), and the startup plane determination information and the version information are updated with the version upgrade. Similarly, in step 916, referring to the version upgrade determination information, if it is determined in the FDP process that the control software needs to be upgraded, step 917 is performed. If the necessity of the version upgrade of the control software is not normally determined with reference to the version upgrade determination information, a reset wait is performed.
[0139]
In step 917, the control software is upgraded (stored in the flash ROM), and the version information is updated with the version upgrade. Step 918 is the same as step 714 of FIG. 2 showing the first embodiment. When a CPU exception occurs, in step 951, the FDP activation plane is determined as in step 951-1 or step 951-2 with reference to the upgrade determination information. Step 952 is the same as step 852 of FIG. 16 showing the second embodiment.
[0140]
Next, the FDP activation plane determination process_3, which is a subflow, will be described with reference to FIGS.
In step 1301, the activation plane is determined based on the activation plane determination information_1 of the A and B planes. If the activation plane exists because the determination can be made normally, the determination result is as shown in step 1301-1-1 or step 1301-2-1. In step 1301-1-1-1 and step 1301-2-1-1, the determination result is written in the upgrade determination information. If the determination is normal but there is no activation surface, the determination result is as shown in step 1301-1-2 or step 1301-2-2, and the ALM process is performed. If the determination is not normal, it is determined that the flag is abnormal, and the ALM process is performed.
[0141]
In step 1302, the activation plane is determined from the activation plane determination information_2 on the A and B sides. If the determination is normal, the determination result is as shown in steps 1302-1 to 1302-8. In Steps 1302-1-1 to 1302-8-1, the determination result is written to the upgrade determination information. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0142]
Next, the sub-flow FDP version upgrade determination_2 will be described with reference to FIG.
In step 1601, the necessity of upgrading the FDP is determined based on the upgrade determination information. If the determination is normal, the determination result is as shown in step 1601-1 or step 1601-2. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0143]
Next, the control software version upgrade determination_2, which is a subflow, will be described with reference to FIG.
In step 1801, the necessity of upgrading the control software is determined based on the upgrade determination information. If the determination is normal, the determination result is as in step 1801-1 or step 1801-2. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0144]
Next, with reference to FIG. 33, a description will be given of initialization of version upgrade determination information, which is a subflow. In step 2001, an initial value is written in the version upgrade determination information.
[0145]
Next, referring to FIG. 34, a description will be given of the sub-flow determination of the individual program upgrade in the firmware.
In step 2101, the individual version upgrade of the program in the firmware is performed based on the FDP individual version information and the control software individual version information. Specifically, the determination is made based on the FDP or control software individual version information managed by the remote downloader and the FDP or control software individual version information in the downloaded firmware.
[0146]
The result of the determination is as shown in Steps 2101-1 to 2101-4. In steps 2101-1-1 to 2101-4-1, the determination result is written to the upgrade determination information.
[0147]
Finally, the operation of the remote download process will be described with reference to the physical configuration diagram of FIG. Basically, it is almost the same as Embodiment 1, except that there are a plurality of expansion sources of the control software 2420_D.
[0148]
Instead of upgrading the control software 2420_K remotely downloaded from the higher-level device 101 to the firmware temporary storage area 2402 on the remote downloader 100C to the control software storage area 2404 on the flash ROM 102, the control software 2420_K is not developed on the control software operation area 2405. Then, the control software 2420_K in the firmware temporary storage area 2402 is directly developed in the control software operation area 2405. After the development, the control software 2420_K on the firmware temporary storage area 2402 is upgraded to the control software storage area 2404 on the flash ROM 102.
[0149]
As described above, according to the remote downloader 100C of the present embodiment, it is not necessary to perform the process of writing the firmware into the flash ROM at the time of booting, and after booting, the firmware does not affect the main control process. By executing the process of writing the firmware into the flash ROM as the priority process, the startup time until the start of the main control process can be significantly reduced. Further, as in the first and second embodiments, a method for realizing the method can be easily implemented without requiring any special device (memory or the like) other than the flash ROM.
[0150]
(Embodiment 4)
FIG. 39 is a block diagram showing a configuration of a remote downloader according to Embodiment 4 of the present invention. The remote downloader 100D according to the present embodiment includes the same configuration as the remote downloader 100C according to the third embodiment, and further includes an autonomous restarting unit 600. The autonomous restart means 600 executes the FDP autonomous restart processing when it is determined from the report from the firmware version upgrade management means 140 that the FDP in the firmware needs to be upgraded.
[0151]
The FDP start-up surface determination unit 121 performs the process described in the third embodiment, reports the start-up surface determination information from the start-up surface determination information management unit 130, and performs the version upgrade determination from the version upgrade determination information management unit 500. The start plane of FDP is determined from the information report. In addition to the processing described in the first embodiment, the FDP deployment unit 123, when reporting the deployment from the firmware primary storage area by the report of the FDP startup plane from the FDP startup plane determination unit 121, stores the firmware in the primary storage. Expand FDP on region.
[0152]
If the firmware version upgrade management means 140 determines from the version upgrade determination information from the version upgrade determination information management means 500 that it is not necessary to perform the firmware version upgrade determination, it is necessary to perform firmware download processing from the higher-level device 101 and upgrade the firmware version. If it is determined that the firmware version upgrade determination needs to be performed without performing the sex determination, and if it is determined that the FDP in the firmware needs to be upgraded after the firmware download, the autonomous restarting means 600 instructs the autonomous restart means 600 to autonomously restart the FDP. Request.
[0153]
The operation of the remote downloader 100 configured as described above will be described with reference to FIGS.
First, referring to FIGS. 46 and 47, the states and the state transitions of the version upgrade determination information 501 will be described.
FIG. 46 is a diagram showing a flag state of the version upgrade determination information. There are 11 possible flag states. The state of item number 1 in FIG. 38 corresponds to the state numbers 0-0 in FIG. The states of item numbers 2 to 6 in FIG. 38 correspond to the state numbers 1-0 to 2-4 in FIG.
[0154]
FIG. 47 is a flag state transition diagram of the version upgrade determination information.
After the reset, the version upgrade information is initialized and the state transits to the flag state 0. The activation plane determination process is performed in the flag state 0, the activation plane determination result is set in the version upgrade determination information, and the state transits to the flag state 1-0 or the flag state 2-0. Thereafter, a version upgrade determination process is performed, the version upgrade determination result is set in the version upgrade determination information, and any one of the flag states 1-0 to 1-1-4 or the flag state 2-0 is set. The state transits to any one of the flag states 2-0 to 2-4.
[0155]
Subsequently, the operation of the remote download process will be described with reference to the flowcharts of FIGS.
First, the main flow will be described with reference to FIG. Steps 1002, 1003, 1007, 1010, 1011, 1012, 1016, 1017, and 1018 are subroutines, and will be separately described as subflows.
[0156]
Steps 1001 to 1002 are the same as steps 901 to 902 of FIG. 27 showing the third embodiment. In step 1003, the startup plane of the FDP is determined from the startup plane determination information and the version upgrade determination information 501, and the determination result is stored in the version upgrade determination information 501. Steps 1004 to 1006 are the same as steps 704 to 706 in FIG. 2 showing the first embodiment. In step 1007, it is determined from the version upgrade determination information 501 whether or not it is necessary to perform the firmware version upgrade determination process.
[0157]
Steps 1008 to 1010 are the same as steps 907 to 909 in FIG. 27 showing the third embodiment. If it is determined in step 1011 that the FDP needs to be upgraded from the version upgrade determination information 501, the process returns to step 1003 (autonomous restart). If it is determined that it is unnecessary, step 1012 is performed. Steps 1012 to 1020 are the same as steps 910 to 918 in FIG. 27 showing the third embodiment. When a CPU exception occurs, steps 1051 to 1052 are the same as steps 951 to 952 in FIG. 28 showing the third embodiment.
[0158]
The FDP start-up surface determination process_4, which is a subflow, will be described with reference to FIGS.
In step 1401, a startup surface is determined based on the version upgrade determination information. If it can be determined normally and it is determined that it is activated from the temporary storage surface, the process proceeds to step 1401-1. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0159]
In step 1402, the starting plane is determined from the starting plane determination information_1 of the A and B planes. If the activation plane exists because it can be determined normally, the determination result is as shown in step 1402-1-1 or step 1402-2-1. In step 1402-1-1-1 and step 1402-2-1-1, the determination result is written in the upgrade determination information. If the determination is normal but there is no activation surface, the determination result is as shown in step 1402-1-2 or step 1402-2-2, and the ALM process is performed.
[0160]
If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed. In step 1403, the starting plane is determined from the starting plane determination information_2 of the A and B planes. If the determination is normal, the determination result is as shown in steps 1403-1 to 1403-8. In step 1403-1-1 to step 1403-8-1, the determination result is written to the upgrade determination information. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0161]
With reference to FIG. 44, a description will be given of the sub flow, ie, the determination of the execution of the firmware version upgrade determination processing.
[0162]
In step 2201, the necessity of performing the firmware version upgrade determination process is determined from the version upgrade determination information. If the determination is normal, the determination result is as shown in step 2201-1 or step 2201-2. If the determination is not normal, it is determined that the flag is abnormal and the ALM process is performed.
[0163]
Finally, the operation of the remote download process will be described with reference to the physical configuration diagram of FIG. Basically, it is almost the same as the third embodiment, except that the firmware temporary storage area 2402 is added to the expansion source of the FDP 113_D.
[0164]
The version of the FDP 113_K remotely downloaded from the higher-level device 101 to the firmware temporary storage area 2402 on the remote downloader 100D is upgraded to the FDP storage area 110 or 111 on the flash ROM 102, and is expanded in the FDP operation area 2403 at the next startup after reset. Instead, the FDP 113_K on the firmware temporary storage area 2402 is directly expanded into the FDP operation area 2403, and branches to the entry point of the FDP 113_D on the FDP operation area 2403 without resetting. After the control software is started, the FDP 113_K on the firmware temporary storage area 2402 is upgraded to the FDP storage area 110 or 111 on the flash ROM 102.
[0165]
As described above, according to the remote downloader 100D of the present embodiment, after upgrading the FDP, it is possible to autonomously restart the upgraded FDP without performing a reset process. In addition, as in the first to third embodiments, a method for realizing the method can be easily implemented without requiring a special device (a memory or the like) other than the flash ROM.
[0166]
【The invention's effect】
According to the present invention, the firmware for controlling the electronic device is divided into two parts, a remote download program for performing remote download and a main control program for controlling the electronic device, and the remote download is performed independently of each other. Only the remote downloader manages the two sides on the flash ROM, and the control software performs one-side management, and the two-side management method can be realized with the flash ROM capacity kept to a minimum.
[0167]
Further, according to the present invention, the remote downloader appropriately controls the startup plane determination information particularly during the remote download process of the remote downloader itself. Therefore, even if a communication path failure or a power supply failure occurs, the target system is reset. It is bootable and can always secure remote downloads.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a remote downloader according to Embodiment 1 of the present invention.
FIG. 2 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 3 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 4 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 5 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 6 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 7 is a flowchart for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 8 is a physical configuration diagram for explaining an operation of the remote downloader according to the first embodiment of the present invention.
FIG. 9 is an activation plane determination information bitmap diagram for explaining an operation of the remote downloader according to the first embodiment of the present invention.
FIG. 10 is an activation plane determination information bitmap diagram for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 11 is a diagram showing an example of control of activation plane determination information_2 for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 12 is a view showing a start-up surface determination method for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 13 is a view showing a startup plane determination method for explaining the operation of the remote downloader according to the first embodiment of the present invention.
FIG. 14 is a block diagram showing a configuration of a remote downloader according to Embodiment 2 of the present invention.
FIG. 15 is a flowchart for explaining the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 16 is a flowchart for explaining the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 17 is a flowchart for explaining the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 18 is a flowchart for explaining the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 19 is a diagram showing a startup plane determination method for explaining an operation of the remote downloader according to the second embodiment of the present invention.
FIG. 20 is a diagram showing a startup plane determination method for explaining the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 21 is a diagram showing a starting surface determination method for explaining an operation of the remote downloader according to the second embodiment of the present invention.
FIG. 22 is a diagram showing an activation plane determination information state definition for describing an operation of the remote downloader according to the second embodiment of the present invention.
FIG. 23 is a view showing a state definition of startup plane determination information for explaining an operation of the remote downloader according to the second embodiment of the present invention.
FIG. 24 is a state transition diagram of activation plane determination information for describing an operation of the remote downloader according to the second embodiment of the present invention.
FIG. 25 is a state transition diagram of activation plane determination information for describing the operation of the remote downloader according to the second embodiment of the present invention.
FIG. 26 is a block diagram showing a configuration of a remote downloader according to Embodiment 3 of the present invention.
FIG. 27 is a flowchart for explaining the operation of the remote downloader according to Embodiment 3 of the present invention.
FIG. 28 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 29 is a flowchart for explaining the operation of the remote downloader according to Embodiment 3 of the present invention.
FIG. 30 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 31 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 32 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 33 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 34 is a flowchart for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 35 is a physical configuration diagram for explaining an operation of the remote downloader according to the third embodiment of the present invention.
FIG. 36 is a version upgrade determination information bitmap diagram for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 37 is a version upgrade determination information bitmap diagram for explaining the operation of the remote downloader according to the third embodiment of the present invention.
FIG. 38 is a diagram showing a version upgrade determination method for describing an operation of the remote downloader according to the third embodiment of the present invention.
FIG. 39 is a block diagram showing a configuration of a remote downloader according to Embodiment 4 of the present invention.
FIG. 40 is a flowchart for explaining the operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 41 is a flowchart for explaining the operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 42 is a flowchart for explaining the operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 43 is a flowchart for explaining the operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 44 is a flowchart for explaining the operation of the remote downloader according to Embodiment 4 of the present invention.
FIG. 45 is a physical configuration diagram for explaining an operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 46 is a view showing a version upgrade determination information state definition for explaining an operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 47 is a state transition diagram of version upgrade determination information for describing an operation of the remote downloader according to the fourth embodiment of the present invention.
FIG. 48 is a block diagram showing a configuration of a target system and a host device using the remote downloader according to the embodiment of the present invention.
FIG. 49 is a remote download sequence diagram between a target system and a host device using the remote downloader according to the embodiment of the present invention.
FIG. 50 is a configuration diagram of firmware version information of the remote downloader according to the embodiment of the present invention.
[Explanation of symbols]
100A-100D remote downloader
101 Host device
102 Flash ROM
103 RAM
110, 111 FDP storage area
113 FDP
120 Boot means
121 FDP activation surface determination means
123 FDP expansion means
130 activation surface determination information management means
131 Version information management means
140 Firmware version upgrade management means
150 Firmware version upgrade
160 Firmware Download Method
161 upper device communication means
170 Control software deployment means
180 Reset waiting means
200 communication channel
201 CPU
202 Upper device controller
400 Remote downloader failure detection means
500 Version upgrade judgment information management means
600 Autonomous restart means

Claims

A program for controlling an electronic device having a function of remotely downloading itself is divided into a remote download program for performing remote download and a main control program for controlling the electronic device, and the remote download is performed independently of each other. A remote downloader characterized in that:

Two remote downloader storage areas, A-side and B-side, for storing the remote download program are set in the flash ROM, and information relating to the starting surface of the remote downloader to be started is stored in the remote downloader storage area on each side. 2. The remote downloader according to claim 1, wherein startup surface determination information to be executed is set, and the startup surface is determined only by the startup surface determination information in each remote downloader storage area.

Version upgrade determination information for storing information related to version upgrade determination is set in a RAM, and a startup plane is determined based on the version upgrade determination information in addition to the startup plane determination information in the two remote downloader storage areas. The remote downloader according to claim 2, wherein

Boot means for performing minimum boot processing and other remaining boot processing for expanding the remote download program from the flash ROM to the RAM;
Remote downloader start-up surface determining means for determining the start-up surface of the remote downloader from the start-up surface determination information;
A reset waiting unit that waits for a reset by a request from the remote downloader activation surface determination unit;
A remote downloader deployment unit that deploys the remote downloader from the remote downloader launch surface and branches to an entry point of the deployed remote downloader;
A boot surface determination information management unit that reports the boot surface determination information and updates the boot surface determination information with the version upgrade;
Version information management means for reporting version information and updating version information;
Storing the downloaded firmware in the flash ROM, instructing the boot surface determination information management means to update the boot surface determination information with the version upgrade, and instructing the version information management means to update the version information with the version upgrade Firmware version upgrade means,
Firmware version upgrade management means for managing firmware version upgrades;
Firmware download means for downloading firmware from a higher-level device according to an instruction from the firmware version upgrade management means;
Control software development means for developing a control program on the RAM from the designated control software activation surface in accordance with an instruction from the firmware version upgrade management means, and branching to an entry point of the control program;
The remote downloader start-up surface determination unit determines the start-up surface of the remote downloader from the report of the start-up surface determination information from the start-up surface determination information management unit after a minimum necessary boot process is performed by the boot unit. If it can be determined normally, the determination result is reported to the remote downloader deploying means, and if it cannot be determined normally, a reset wait is requested to the reset waiting means,
The boot surface information determination management unit reports the boot surface determination information in response to a request from the remote downloader boot surface determination unit, and updates the boot surface determination information accompanying the version upgrade according to an instruction from the firmware version upgrade unit. And
The version information management means reports version information according to a version information report request from the firmware version upgrade management means, and updates the version information according to a request from the firmware version upgrade means.
The firmware version upgrade management unit reports firmware version information of the firmware reported from the version information management unit to the host device, inquires of the host device about the necessity of firmware version upgrade, and When the instruction is received, the firmware download is performed via the firmware download means. Immediately after the firmware download, the pass / fail of the firmware download process is determined. A request is made to the expanding means to expand the control program, and the necessity of upgrading the version of the remote downloader in the firmware is confirmed by the remote downloader reported by the version information managing means. Judgment is made based on the downloader individual version information and the remote downloader individual version information in the downloaded firmware, and when it is judged that it is necessary, the firmware version upgrade means is requested to upgrade the remote downloader. Is determined in the same manner as the remote downloader, and if determined to be necessary, the firmware upgrade means is requested to upgrade the control program, the upgrade result is reported to the host device, and the control software deployment is performed. Requesting means to deploy control software,
The firmware version upgrade unit stores the downloaded firmware in the flash ROM in accordance with an instruction from the firmware version upgrade management unit, and instructs the startup plane determination information management unit to update the startup plane determination information accompanying the version upgrade. Instructing the version information management means to update the version information according to the version upgrade;
The remote downloader according to claim 3, wherein:

The start-up surface determination information management means sets the upgrade target surface of the remote downloader storage area on the flash ROM for upgrading the remote downloader to the B-side or the B-side for the A-side, which is the next surface after the start-up surface. Is managed as the A side, and when the erasure of the version upgrade target side and the writing of the remote downloader are completed with the remote downloader version upgrade, the activation version determination information of the current activation side is referred to, and the current version is checked. The remote downloader according to claim 4, wherein the activation surface determination information of the current version upgrade target surface is rewritten so that the upgrade target surface is determined to be the next activation surface.

"Janken" is a method that refers to the activation surface determination information of the current activation surface and rewrites the activation surface determination information of the current upgrade target surface so that the current upgrade target surface is determined as the activation surface for the next activation. Applying the logic, in the startup plane determination at startup, the one who wins "Janken" is determined as the startup plane, the startup plane determination information of the current startup plane is "first out", the current version is upgraded Comparing the activation plane determination information of the target plane with "late", the logic of "later" is determined so as to "win" the logic of "first advance", and the activation plane determination information management means determines the current version. The remote downloader according to claim 5, wherein the activation plane determination information of the plane to be uploaded is rewritten.

The activation plane determination information management means sets all bits of the activation plane determination information of the version upgrade target surface to “0” immediately before erasing the version upgrade target surface accompanying the remote downloader version upgrade. The remote downloader according to any one of claims 4 to 6, wherein:

A remote downloader program failure detecting means for detecting a processing abnormality such as a software defect in the remote download processing, requesting the boot plane determination information managing means to control the boot plane determination information, and requesting the reset waiting means to wait for a reset; And
The startup plane determination information management means, by the control request of the startup plane determination information from the remote downloader program failure detection means, rewrite the startup plane determination information of the current startup plane so that the current startup plane is not determined as the next startup plane,
The remote downloader start-up surface determination unit does not determine a previously started up surface as a current start-up surface based on rewritten start-up surface determination information reported from the start-up surface determination information management unit. The remote downloader according to any one of claims 4 to 7.

The remote downloader start-up surface judging means, at the time of initial system startup, if the remote downloader is stored in the remote downloader storage area that is the A-side, the start-up surface judgment information of the remote downloader storage area and the remote downloader storage of the B-side 9. The system according to claim 4, wherein, even when the erasure is completed in the flash ROM in which all the bits of the entire area are "1", the process of determining the startup surface in the subsequent system operation is performed normally. A remote downloader according to any of the above.

Controlling the upgrade determination information according to the control request of the upgrade determination information from the boot unit, the remote downloader activation surface determination unit and the firmware version management unit, and responding to the report request of the upgrade determination information from the firmware version management unit. Comprising version upgrade determination information management means for reporting version upgrade determination information to
The boot means performs a minimum boot process required for expanding the remote download program from the flash ROM to the RAM and other remaining boot processes, and initializes the version upgrade determination information to the version upgrade determination information. Request to management means,
The remote downloader start-up surface determination unit, after the minimum necessary boot processing by the boot unit, determines the start-up surface of the remote downloader from the report of the start-up surface determination information from the start-up surface determination information management unit, and can determine normally. If it has, the result of the determination is reported to the remote downloader deployment means and the version upgrade determination information management means.
The firmware version upgrade management unit reports the firmware version information reported from the version information management unit to the host device, inquires of the host device about the necessity of firmware upgrade, When the instruction is received, the firmware download is performed via the firmware download unit, and whether or not the firmware download process is successful is confirmed. When the firmware download process is determined to be unsuccessful, the version upgrade process is stopped, and control is performed by the control software deployment unit. Requesting the program development, the remote downloader individual version information reported by the version information management means and the downloaded firmware Of the remote downloader individual version information, report the determination result to the version upgrade determination information management means, similarly determine the necessity of version upgrade of the control program in the firmware in the same manner as the remote downloader, and determine the determination result. The control program is reported from the firmware primary storage area, which is an area on the RAM that temporarily stores the firmware downloaded to the control software expanding means when the firmware is reported to the version upgrade determination information management means and is determined to be necessary. Requesting the development, and when it is determined that it is not necessary, request the control software development means to develop the control program from the control software on the flash ROM, and, after the control software is started, by the report from the version upgrade determination information management means. For remote downloader processing If it is determined that the version of the remote downloader needs to be upgraded, the firmware version upgrade means is requested to upgrade the version of the remote downloader. Similarly, if it is determined in the remote downloader process that the version of the control program is required, the firmware is upgraded. Requesting the version upgrade means to upgrade the control program; if the necessity of version upgrade of the remote downloader or the control program has not been normally determined, a request is made to the reset waiting means to request a reset wait; 10. The remote downloader according to claim 4, wherein the remote downloader reports an upload result.

If it is determined that the firmware version upgrade management means needs to upgrade the version of the remote downloader in the firmware based on the report from the firmware version upgrade management means,
The remote downloader start-up surface determination unit, after the minimum necessary boot processing by the boot unit, reports the start-up surface determination information from the start-up surface determination information management unit and the version upgrade determination information from the version upgrade determination information management unit. The start side of the remote downloader is determined from the report, and if the determination is successful, the determination result is reported to the remote downloader deployment means and the version upgrade determination information management means, and if the determination is not successful, the reset is performed. Request the waiting means to wait for reset,
The remote downloader developing means expands the remote download program in the firmware primary storage area when the development from the firmware primary storage area is reported from the report of the remote downloader activation plane from the remote downloader activation plane determination means, and flashes. When the report is issued from the remote downloader storage area on the ROM, the remote download program is developed from the start surface of the reported remote downloader storage area, and the program branches to the expanded remote download program entry point.
The firmware version upgrade management means, when it is determined from the version upgrade determination information from the version upgrade determination information management means that the firmware version upgrade determination is not required, it is necessary to perform a firmware download process from the higher-level device and a firmware version upgrade. If it is determined that the firmware version upgrade determination needs to be performed without performing the determination, the firmware version information reported from the version information management unit is reported to the higher-level device, and the firmware version upgrade is performed on the higher-level device. When the necessity is inquired and an instruction of necessity is received from the higher-level device, a firmware download is performed via the firmware download means, and a firmware download process is performed. The pass / fail is confirmed, and if it is determined to be unsuccessful, the version upgrade process is stopped, a request is made to deploy the control program to the control software deployment means, and the version information management From the remote downloader individual version information reported from the server and the remote downloader individual version information in the downloaded firmware, and reports the result of the determination to the version upgrade determination information management means. Requesting the autonomous restart of the remote downloader to the means, similarly determine the necessity of version upgrade of the control software in the firmware in the same manner as the remote downloader, and report the determination result to the version upgrade determination information management means, Must Is determined, the control software expanding means is requested to expand the control program from the primary storage surface on the RAM, and if it is determined that the control software expanding means is not necessary, the control software expanding means is notified to the control software expanding means on the flash ROM. Requesting the development of the control program from the side, and after starting the control software, if it is determined by the report from the version upgrade determination information management means that the remote downloader processing needs to be upgraded, the firmware version upgrade means Requesting a version upgrade of the remote downloader, and similarly, when it is determined in the remote downloader processing that the version upgrade of the control program is necessary, the firmware version upgrade means is requested to upgrade the version of the control program. 5. The method according to claim 4, wherein when the necessity of upgrading the version of the remote downloader or the control program is not determined, the reset waiting unit is requested to wait for a reset, and a result of the upgrade is reported to the host device. The remote downloader according to any one of claims 1 to 10.

The remote downloader according to any one of claims 4 to 11, wherein the activation plane determination information management unit manages each information element of the activation plane determination information in a multi-bit configuration having redundant bits.

13. The remote downloader according to claim 10, wherein the version upgrade determination information management unit manages each information element of the version upgrade determination information in a multi-bit configuration having redundant bits.

A base station apparatus comprising the remote downloader according to any one of claims 1 to 13.

Performs the minimum boot process required to expand the remote downloader from the flash ROM to the RAM, determines the startup surface of the remote downloader from the startup surface determination information, and waits for a reset if it cannot be determined normally. If the determination is successful, the remote downloader is deployed from the boot surface indicated by the determination result, branching to the expanded remote downloader entry point is performed, the remaining boot processing is performed, and the firmware version information is reported to the higher-level device. Inquires about the necessity of upgrading the firmware to the device, downloads the firmware if an instruction from the host device indicates that it is necessary, checks whether the firmware download process was successful, and upgrades the firmware if it is determined to have failed Stop the control program Expand the firmware and determine the necessity of upgrading the remote downloader in the firmware based on the remote downloader individual version information and the remote downloader individual version information in the downloaded firmware.If it is determined that it is necessary, upgrade the remote downloader version. Execute, update the startup plane determination information and update the version information with the version upgrade, similarly determine the necessity of version upgrade of the control program in the firmware in the same way as the remote downloader, and determine that it is necessary Performs the version upgrade of the control program, updates the version information with the version upgrade, reports the result of the firmware version upgrade to the host device, and downloads the control program from the flash ROM. Spread on M, the process branches to entry point of the control program, remote downloading and wherein the.

The upgrade target surface is managed as the next surface of the start surface, and when the erasure of the upgrade target surface and the writing of the remote downloader with the version upgrade of the remote downloader are completed, refer to the activation surface determination information of the current activation surface, 16. The remote download method according to claim 15, wherein the activation surface determination information of the current version upgrade target surface is rewritten so that the current version upgrade target surface is determined as the next activation surface.

Refers to the activation surface determination information of the current activation surface, applies the `` rock-paper-scissors '' logic as a method of rewriting the activation surface determination information of the current upgrade target surface so that the current upgrade target surface is determined to be the next activation surface, and activates In the startup plane determination at the time, the one that "wins" over "Janken" is determined to be the startup plane, the startup plane determination information of the current startup plane is "first out", and the startup plane determination information of the current version upgrade target plane is Claim: wherein the logic of "late" is determined so as to "win" the logic of "first" with respect to the logic of "late", and the activation surface determination information of the current version upgrade target surface is rewritten. 15. The remote download method according to item 15.

16. The system according to claim 15, wherein immediately before erasing of the version upgrade target surface accompanying the remote downloader version upgrade, all bits of the activation surface determination information of the version upgrade target surface are set to "0". 17. The remote download method according to any one of 17.

When a processing error such as a software failure is detected in the remote download processing by the remote downloader, the startup plane determination information of the current startup plane is rewritten so that the current startup plane is not determined to be the next startup plane, a reset wait is performed, and reset is performed next time. 19. The remote download method according to claim 15, wherein a surface in which an abnormality was detected at the previous activation in the previous activation surface is not determined as a current activation surface.

At the time of initial system startup, if the remote downloader is stored in the remote downloader storage area on one side, the activation plane determination information of the remote downloader storage area and all bits of the entire remote downloader storage area on the other side are stored. 20. The method according to claim 15, wherein even if the flash ROM has an erase completion state of "1", the start-up surface determination processing in the subsequent system operation can be normally performed. The remote download method described.

After the minimum boot process required to expand the remote downloader from the flash ROM to the RAM, initialization of the version upgrade determination information was performed, and the boot surface of the remote downloader was determined from the boot surface determination information, and the normal determination was possible. In this case, deploy the remote downloader from the startup surface indicated by the determination result, branch to the entry point of the deployed remote downloader, store the determination result in the version upgrade determination information initialized earlier, and update the version of the remote downloader in the firmware. The necessity is determined based on the remote downloader individual version information and the remote downloader individual version information in the downloaded firmware, and the determination result is stored in the version upgrade determination information. The necessity of version upgrade is determined in the same manner as that of the remote downloader, and the determination result is stored in the version upgrade determination information. The control program from the primary storage surface is expanded, and if it is determined that it is not necessary, the control program from the control software surface on the flash ROM is expanded. If it is determined that the remote downloader needs to be upgraded, the remote downloader is upgraded, the startup plane determination information and the version information are updated with the version upgrade, and the version upgrade determination information is similarly updated. Browse and download remote If it is determined in the download process that the control program needs to be upgraded, the control program is upgraded, the version information is updated along with the version upgrade, and the version download information is referred to. 21. The remote download method according to claim 15, wherein if it is not determined that the control program needs to be upgraded, a reset wait is performed.

After the minimum necessary boot processing, the boot surface of the remote downloader is determined based on the boot surface determination information and the version upgrade determination information, and if it can be determined normally and the boot from the firmware primary storage area is determined, the firmware is stored on the primary storage area. If it is determined from the upgrade information that the firmware upgrade has not been performed, the firmware download process is not performed from the host device and the firmware upgrade necessity is not determined, and the firmware upgrade is determined. Only when it is determined that it is necessary, the firmware download processing from the higher-level device and the necessity of firmware version upgrade are performed, and the firmware download processing and the firmware version from the higher-level device are performed. If it is determined that remote downloader individual version upgrade is necessary, remote downloader autonomous restart is performed, and if remote downloader individual version upgrade is determined to be unnecessary, remote downloader continues. 22. The remote download method according to any one of claims 15 to 21, wherein the necessity determination of the version upgrade of the in-firmware control software is performed by the same method as described above.

Each information element of the activation plane determination information is managed in a multiple bit configuration having redundant bits, and similarly, each information element of the upgrade determination information is managed in a multiple bit configuration having redundant bits. 23. The remote download method according to claim 15, wherein the method is performed.