JPH11338703A - ファームウェアダウンロード方式 - Google Patents

Abstract

(57)【要約】 【課題】 ファームウェアダウンロード方式に関し、マ
ルチＣＰＵシステムにおける任意ＣＰＵへのファームウ
ェアダウンロードを該ＣＰＵにおける本来の処理遅延を
起こさずに効率良く行えることを課題とする。 【解決手段】 ＣＰＵとメモリ（ＭＥＭ）とデータ通信
手段（ＣＯＭ）とを備える複数のプロセッサ手段１〜４
がメモリアクセスをするための共通バス６を介して相互
に接続するマルチＣＰＵシステムのファームウェアダウ
ンロード方式において、外部装置２００よりあるプロセ
ッサ手段２にデータ通信手段を介してダウンロードされ
たファームウェアを該プロセッサ手段２のＣＰＵ２が前
記共通バス６に対するメモリアクセスを介して他のＣＰ
Ｕ（例えばプロセッサ手段３）のメモリに直接書き込
む。従って、ＣＰＵ３へのダウンロードを該ＣＰＵ３に
おける本来の処理遅延を起こさずに他のＣＰＵ２から効
率良く行える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はファームウェアダウ
ンロード方式に関し、更に詳しくはＣＰＵとメモリとデ
ータ通信手段とを備える複数のプロセッサ手段がメモリ
アクセスをするための共通バスを介して相互に接続する
マルチＣＰＵシステムのファームウェアダウンロード方
式に関する。

【０００２】近年、データ通信及び情報処理の多種多様
化と需要の拡大に伴い、処理システムの高機能化、大容
量化が進んでいる。このため、システムにはより高い処
理能力が求められ、この要求はＣＰＵの高速化やマルチ
ＣＰＵ（負荷分散）化により改善が図られている。

【０００３】

【従来の技術】この種の処理システムでは、ファームウ
ェア交換によりサービス機能の変更、改善、拡大等を図
れるが、その都度ＲＯＭを交換するのは煩わしいため、
外部装置（パーソナルコンピュータ等）からファームウ
ェアをダウンロードする方式が一般的である。

【０００４】この点、従来は、シングルＣＰＵシステム
におけるファームウェアダウンロードを効率良く行うこ
とを目的とした、ファームウェアダウンロード方式（特
開平３−９９３２７号）や、ダウンロード装置（特開平
８−１９４６２１号）等が知られている。しかし、これ
らはいずれもファームウェアダウンロードを受けるＣＰ
Ｕ自信が、本来実行すべきデータ交換制御等の処理を一
時的に止めて、又は本来実行すべき処理と並行して、外
部装置から送られるファームウェアデータを自メモリ
（バッファメモリ等）に書き込むものであった。

【０００５】

【発明が解決しようとする課題】ところで、一般にマル
チＣＰＵシステムでは共通の制御対象（データ交換・伝
送制御等）を各ＣＰＵが機能（又は負荷）分担をして制
御する場合が少なくない。このため、どのＣＰＵにも常
にフル稼働できる体制が要求される。しかるに、かかる
システムのあるＣＰＵにつきダウンロードを実施しよう
とすると、上記従来方式ではダウンロードを受けるＣＰ
Ｕ自信が自メモリへのデータ書込制御に直接関与するた
め、該ＣＰＵの負荷が固定的に高くなり、本来の制御・
処理に遅延が生じていた。またこの処理遅延がシステム
全体の処理に悪影響を及ぼすこともあった。

【０００６】また、ダウンロード対象のＣＰＵが障害
（特にソフト障害）等でダウンロード処理が出来ない状
態にあるような場合には、そのＥＥＰＲＯＭを交換する
以外に復旧の方法がなかった。本発明は上記従来技術の
問題点に鑑み成されたものであって、その目的とする所
は、マルチＣＰＵシステムにおける任意ＣＰＵへのファ
ームウェアダウンロードを該ＣＰＵにおける本来の処理
遅延を起こさずに効率良く行えるファームウェアダウン
ロード方式を提供することにある。

【０００７】

【課題を解決するための手段】上記の課題は例えば図１
の構成により解決される。即ち、本発明（１）のファー
ムウェアダウンロード方式は、ＣＰＵとメモリ（ＭＥ
Ｍ）とデータ通信手段（ＣＯＭ）とを備える複数のプロ
セッサ手段１〜４がメモリアクセスをするための共通バ
ス６を介して相互に接続するマルチＣＰＵシステム１０
０のファームウェアダウンロード方式において、外部装
置２００よりあるプロセッサ手段（例えばプロセッサ手
段２）にデータ通信手段を介してダウンロードされたフ
ァームウェアを該プロセッサ手段２のＣＰＵ２（なお、
プロセッサ手段２のＣＰＵをＣＰＵ２と呼ぶ、以下も同
様）が前記共通バス６に対するメモリアクセスを介して
他のＣＰＵ（例えばＣＰＵ３）のメモリに直接書き込む
ものである。

【０００８】本発明（１）によれば、システムの当面の
目的であるプロセッサ手段３へのファームウェアダウン
ロードを、他のＣＰＵ２が共通バス６を介して仲介処理
することにより、ＣＰＵ３は自メモリへのファームウェ
アダウンロードに係る処理（メモリアクセス等）を一切
行う必要がない。従って、もともと負荷率の高かったよ
うなＣＰＵ３は専ら本来のデータ通信制御処理等に専念
できる。一方、負荷率の低くかったＣＰＵ２は、ＣＰＵ
３へのダウンロード仲介処理を実施することで負荷率が
増加する。こうして、マルチＣＰＵシステムにおける負
荷分担の公平化、適正化が容易に図れる。

【０００９】又は、仮にＣＰＵ３がバグ等によりソフト
ウェア障害を起こしており、自らは復帰できない場合で
も、他のＣＰＵ２がＣＰＵ３へのダウンロード処理を仲
介することで、ＣＰＵ３は新たなファームウェアにより
復帰できる。好ましくは、本発明（２）においては、上
記本発明（１）において、各ＣＰＵ１〜４は各データ通
信手段を介して相互に接続すると共に、該データ通信手
段を介して、外部装置２００からダウンロード制御の指
示を受けた制御ＣＰＵ（例えばＣＰＵ１）が、自ＣＰＵ
１又は他のＣＰＵ２〜４を選択して、該選択されたＣＰ
Ｕ（例えばＣＰＵ３）にダウンロード又は（例えばＣＰ
Ｕ２）に前記ダウンロードの仲介処理を実施させるもの
である。

【００１０】ここで、もし制御ＣＰＵ１がＣＰＵ２を選
択した場合は、該ＣＰＵ２はＣＰＵ３のメモリへのダウ
ンロード処理を仲介することになり、また制御ＣＰＵ１
がＣＰＵ３を選択した場合は、該ＣＰＵ３は自メモリへ
のダウンロード処理を自ら実施することになる。本発明
（２）によれば、マルチＣＰＵシステムの例えばＣＰＵ
１にダウンロード処理の指揮権を与える構成により、シ
ステム内でダウンロード処理の様々な運用（制御）が可
能となる。一方、外部装置２００は、所望の制御ＣＰＵ
を選択した後は、単にダウンロード実施ＣＰＵからのフ
ァイル転送要求に応じてファイルデータを転送するだけ
で良く、よって外部装置２００の処理負担が小さい。即
ち、外部装置２００に要求される機能は従来のものと殆
ど変わらない。

【００１１】また好ましくは、本発明（３）において
は、上記本発明（２）において、制御ＣＰＵ（例えばＣ
ＰＵ１）は、各ＣＰＵ１〜４から負荷率を収集して比較
すると共に、負荷率最小のＣＰＵ（例えばＣＰＵ３）に
ダウンロード又は（例えばＣＰＵ２に）その仲介処理を
実施させる。従って、各ＣＰＵ１〜４の負荷分担を公平
化，適正化でき、よって所望のＣＰＵ（例えばＣＰＵ
３）へのダウンロード処理を効率良く行える。

【００１２】また好ましくは、本発明（４）において
は、上記本発明（２）又は（３）において、ダウンロー
ド又はその仲介処理を実施しているダウンロード実施Ｃ
ＰＵは、定期的にダウンロード又はその仲介処理の引継
情報を作成して制御ＣＰＵに通知する。ここで、定期的
にとは、ファイル転送の所定時間（例えば３０秒）毎
に、又はファイル転送の所定回数（例えば１０フレー
ム）毎に、又は転送ファイルの所定データ量（例えば１
０ブロック）毎に、等を意味する。以下も同様である。

【００１３】本発明（４）によれば、制御ＣＰＵはダウ
ンロード及びその仲介処理の進行状況を定期的に把握
（更新）できるので、ダウンロード実施ＣＰＵが不測の
事態（障害等）によりその処理を継続できなくなって
も、その続きを他のＣＰＵに実施させることが可能とな
る。また好ましくは、本発明（５）においては、上記本
発明（４）において、制御ＣＰＵは、ダウンロード実施
ＣＰＵからの引継情報の通知が所定時間内に得られない
ことにより、他のＣＰＵにダウンロード又はその仲介処
理を引き継がせる。

【００１４】従って、ダウンロード実施途中で不測の事
態（障害等）が発生しても、他のＣＰＵによりダウンロ
ード処理を最後まで遂行できる。また好ましくは、本発
明（６）においては、上記本発明（２）〜（４）におい
て、制御ＣＰＵ１は、各ＣＰＵ１〜４から定期的に負荷
率を収集して比較すると共に、ダウンロード又はその仲
介処理を実施しているダウンロード実施ＣＰＵ（例えば
ＣＰＵ２）よりも他のＣＰＵ４の負荷率が低い場合は、
前記ダウンロード実施ＣＰＵ２のダウンロード又はその
仲介処理を中断させ、かつ他の負荷率最小のＣＰＵ４に
ダウンロード又はその仲介処理を引き継がせる。

【００１５】例えば、データ通信制御処理を担うような
マルチＣＰＵシステムでは、通信トラフィックの増減に
応じて、各ＣＰＵ１〜４の負荷率も様々に変動する。係
る場合でも、本発明（６）によれば、各ＣＰＵ１〜４の
負荷分担を定期的（例えば３０秒等毎）に公平化，適正
化できるため、システムの本来の目的であるデータ通信
制御処理に悪影響を与えることは無い。

【００１６】また、負荷率を定期的に収集して比較する
構成により、各ＣＰＵの負荷率が頻繁かつ小刻みに変動
することによてダウンロード実施ＣＰＵの切替えが頻繁
に発生してしまうような状況を抑制できる。また好まし
くは、本発明（７）においては、上記本発明（６）にお
いて、ダウンロード中断の指示を受けたダウンロード実
施ＣＰＵは、ダウンロード又はその仲介処理を中断する
と共に、ダウンロード又はその仲介処理の引継情報を作
成して制御ＣＰＵに通知する。

【００１７】本発明（７）によれば、制御ＣＰＵには処
理中断時点の最新の引継情報がリアルタイムに得られ
る。従って、その続きのダウンロード又はその仲介処理
を過不足無く、他のＣＰＵに引き継がせることが可能と
なる。また好ましくは、本発明（８）においては、上記
本発明（２）〜（４）において、ダウンロード又はその
仲介処理を実施しているダウンロード実施ＣＰＵは、自
ＣＰＵの負荷率が所定以上（例えば過負荷状態）となっ
たことによりダウンロード又はその仲介処理の引継情報
を作成して制御ＣＰＵに通知する。

【００１８】本発明（８）によれば、制御ＣＰＵは、ダ
ウンロード実施ＣＰＵが過負荷状態になったことをリア
ルタイムに知ることができる。従って、システム本来の
サービス対象である通信トラフィック等の急激な増加に
対しても瞬時に対応できる。また好ましくは、本発明
（９）においては、上記本発明（２）〜（４）におい
て、ダウンロード及びその仲介処理を実施していないＣ
ＰＵは、自ＣＰＵの負荷率が所定以下（例えば軽負荷状
態）となったことによりその旨を制御ＣＰＵに通知す
る。

【００１９】本発明（９）によれば、制御ＣＰＵは、ダ
ウンロード実施ＣＰＵ以外のあるＣＰＵが軽負荷状態に
なったことをリアルタイムに知ることができる。従っ
て、通信トラフィック等に急激な変動があっても、瞬時
に負荷分担の公平化、適正化が図れる。また好ましく
は、本発明（１０）においては、上記本発明（６），
（８）又は（９）において、制御ＣＰＵは、ダウンロー
ド実施ＣＰＵからの引継情報を元にダウンロード又はそ
の仲介処理の残量を求め、該残量が所定以下の場合はダ
ウンロード実施ＣＰＵのダウンロード又はその仲介処理
を中断させない。

【００２０】本発明（１０）によれば、ダウンロード処
理の残量が所定（例えば１０％）以下となったような場
合には、むしろダウンロード実施ＣＰＵにそのまま処理
を継続させることにより、中断，引継による処理遅延を
発生させることも無く、残りの処理を速やかに完了でき
る。また好ましくは、本発明（１１）においては、上記
本発明（１）において、各ＣＰＵは各データ通信手段を
介して相互に接続すると共に、予めダウンロード又はそ
の仲介処理を実施するＣＰＵの順番を定めておき、かつ
前記データ通信手段を介して、まず外部装置からダウン
ロード開始の指示を受けたＣＰＵが所定時間のダウンロ
ード又はその仲介処理を実施し、次に該ＣＰＵが前記順
番に従ってダウンロード又はその仲介処理を次のＣＰＵ
に引き継がせ、こうして、各所定時間のダウンロード又
はその仲介処理を各ＣＰＵ間の持ち回りで順次実施す
る。

【００２１】本発明（１１）によれば、所望のＣＰＵ
（例えばＣＰＵ３）に対するダウンロード又はその仲介
処理を、各ＣＰＵ１〜４が各所定時間毎の持ち回りで順
次実施する構成により、特定の制御ＣＰＵ（例えばＣＰ
Ｕ１）に制御負担を掛けることも無く、ダウンロード負
荷を公平に分担処理できる。また好ましくは、本発明
（１２）においては、上記本発明（１）において、各Ｃ
ＰＵは各データ通信手段を介して相互に接続すると共
に、予めダウンロード又はその仲介処理を実施するＣＰ
Ｕの順番を定めておき、かつ前記データ通信手段を介し
て、まず外部装置からダウンロード開始の指示を受けた
ＣＰＵが所定量のダウンロード又はその仲介処理を実施
し、次に該ＣＰＵが前記順番に従ってダウンロード又は
その仲介処理を次のＣＰＵに引き継がせ、こうして、各
所定量のダウンロード又はその仲介処理を各ＣＰＵ間の
持ち回りで順次実施する。

【００２２】本発明（１２）によれば、所望のＣＰＵ
（例えばＣＰＵ３）に対するダウンロード又はその仲介
処理を、各ＣＰＵ１〜４が各所定量（所定データ転送
量）毎の持ち回りで順次実施する構成により、特定の制
御ＣＰＵ（例えばＣＰＵ１）に制御負担を掛けることも
無く、ダウンロード負荷を公平に分担処理できる。

【００２３】

【発明の実施の形態】以下、添付図面に従って本発明に
好適なる実施の形態を詳細に説明する。なお、全図を通
して同一符号は同一又は相当部分を示すものとする。図
２は実施の形態によるマルチＣＰＵシステムのブロック
図で、図において、１００は例えば不図示のデータ伝送
装置の通信制御処理を４つのＣＰＵにより負荷（又は機
能）分担処理するマルチＣＰＵシステム、１〜４は好ま
しくは同一構成からなるＣＰＵ１〜４盤（基板等）、５
はマルチＣＰＵシステムの立ち上げ情報を保持している
メモリ（ＭＥＭ）盤、６はＣＰＵ１〜４盤及びＭＥＭ盤
間のメモリアクセスを可能にするユニバーサルアクセス
バス、７はユニバーサルアクセスバスのバス調停を行う
バスアービタ（ＵＡＢ）、２００はデータ伝送装置の保
守，運用，監視等を行うための保守コンソール（パーソ
ナルコンピュータ等）、３００はＣＰＵ１〜４盤及び保
守コンソール間をデータ通信回線で接続するローカルエ
リアネットワーク（ＬＡＮ）である。

【００２４】ＣＰＵ１盤において、１１はＣＰＵ１盤の
主制御処理（本来の通信制御処理及び後述のファームウ
ェアダウンロードに係る処理等）を行うＣＰＵ、１２は
ＣＰＵ１１がワークエリアとして使用するＲＡＭ、１
３，１４はＣＰＵ１１が使用するファームウェア（但
し、一方は実行ファームウェア、他方はダウンロードフ
ァームウェア）を夫々記憶するＥＥＰＲＯＭ（フラッシ
ュＲＯＭ等）、１５はＣＰＵ１盤（即ち、ＣＰＵ１１）
に固有の番号（例えば１）を設定するためのＤＩＰスイ
ッチ（ＤＳＷ）、１６は各ＣＰＵ間及び保守コンソール
との間でデータ通信を行うための通信制御部（ＣＯ
Ｍ）、１７はＣＰＵ１１のホスト（ローカル）バス、１
８はホストバス１７のバス調停を行うバスアービタ（Ｈ
ＡＢ）、１９はホストバス１７とユニバーサルアクセス
バス６間におけるデータ，アドレス及び制御信号の接続
制御を行うバスブリッジ（ＨＵＢ）である。ＣＰＵ２〜
４盤についても同様である。

【００２５】ＭＥＭ盤５において、５２はマルチＣＰＵ
システム（即ち、各ＣＰＵ）の立ち上げ用ファームウェ
アを格納しているＢＯＯＴ−ＲＯＭ、５３はＣＰＵ毎の
ファーム実行アドレス及びダウンロードアドレスを記憶
しているＥＥＰＲＯＭ、５７はメモリバス、５９はメモ
リバス５７とユニバーサルアクセスバス６間の信号接続
制御を行うバスブリッジ（ＭＵＢ）である。

【００２６】係る構成により、各ＣＰＵはＬＡＮ３００
を介して保守コンソール２００及び他のＣＰＵと相互に
データ通信可能である。各ＣＰＵ間及び保守コンソール
との間の各種メッセージのやり取りはＬＡＮ３００を介
して行われる。また、保守コンソール２００からダウン
ロード実施ＣＰＵへのファームウェアデータの一次的な
転送もＬＡＮ３００を介して行われる。

【００２７】この場合に、例えばＣＰＵ３１がダウンロ
ード実施ＣＰＵとなって自己のＥＥＰＲＯＭ３４にファ
ームウェアをダウンロードする場合は、従来と同様に、
保守コンソール２００から通信制御部３６を介して受信
される各ファイルデータをＣＰＵ３１のメモリアクセス
制御下でＥＥＰＲＯＭ３４に直接書き込む。一方、他の
例えばＣＰＵ２１がダウンロード仲介ＣＰＵとなってＣ
ＰＵ３１のＥＥＰＲＯＭ３４にファームウェアをダウン
ロードする場合は、保守コンソール２００から通信制御
部２６を介して受信される各ファイルデータを、ＣＰＵ
２１によるホストバス２７，ユニバーサルアクセスバス
７及びホストバス３７のメモリアクセス制御下で、ＣＰ
Ｕ２１がＥＥＰＲＯＭ３４に直接書き込む。

【００２８】なお、一例の各バスは、夫々が３２ビット
＋αのバス構成から成っており、例えばＰＣＩ(Periphe
ral Component interconnect) バス方式で採用されてい
るように、まずメモリアクセスのアドレス信号と制御
（リード／ライト等）信号とをバスに出力し、必要なら
バスアービタからのアクセス許可信号ＧＴを待ち、最終
的にターゲットバスの支配権を得たことにより、上記ア
ドレス信号に代えて１又は２以上のデータ信号をバスに
出力し、ターゲットメモリのアクセス（リード／ライ
ト）を行う。なお、動作の詳細は後述する。

【００２９】図３は実施の形態によるマルチＣＰＵシス
テムのメモリマップを説明する図である。本マルチＣＰ
Ｕシステムは例えば最大３２ビットのアドレス空間（メ
モリ空間，Ｉ／Ｏ空間）を有しており、その内の上位ビ
ット３１〜２４を使用してＭＥＭ盤５及びＣＰＵ１〜４
盤に夫々図示のようなメモリ空間を割り付けている。な
お、図示しないが、ＤＩＰスイッチは通信制御部と共に
Ｉ／Ｏ空間に割り付けられる。

【００３０】ＭＥＭ盤５において、アドレス「００００
０００Ｈ」〜「００ＦＦＦＦＦＨ」（Ｈはヘキサデシマ
ル表示）はＢＯＯＴ−ＲＯＭ５２に割り付けられ、ここ
にはシステム（各ＣＰＵ）立ち上げ用のＢＯＯＴプログ
ラムが格納されている。アドレス「０１０００００Ｈ」
〜「０１ＦＦＦＦＦＨ」はＥＥＰＲＯＭ５３に割り付け
られ、ここにはＣＰＵ毎のファーム実行アドレス及びバ
ージョンアップ等されたファームウェアのダウンロード
アドレスが各ＣＰＵ番号の対応に格納されている。

【００３１】挿入図（ａ），（ｂ）にダウンロード実行
前／後におけるＥＰＲＯＭ５３の各記憶内容を示す。
今、ＣＰＵ３盤に着目すると、ダウンロード実行前のＣ
ＰＵ３１のファーム実行アドレス＝「０９０００００
Ｈ」（ＥＥＰＲＯＭ３３）で、かつファームダウンロー
ドアドレス＝「０Ａ０００００Ｈ」（ＥＥＰＲＯＭ３
４）であった。またダウンロード実行後のＣＰＵ３１の
ファーム実行アドレス＝「０Ａ０００００Ｈ」（ＥＥＰ
ＲＯＭ３４）で、かつファームダウンロードアドレス＝
「０９０００００Ｈ」（ＥＥＰＲＯＭ３３）となってい
る。そして、このダウンロード実行後のＣＰＵ３１をリ
セットすると、該ＣＰＵ３１はＥＥＰＲＯＭ３４のファ
ームウェアで立ち上がることになる。このように、本マ
ルチＣＰＵシステムではＥＥＰＲＯＭ５３のファーム実
行アドレスとダウンロードアドレスとを書き換えること
により、ＥＥＰＲＯＭ３３，３４の選択が切り換わる。

【００３２】ＣＰＵ１盤において、アドレス「０２００
０００Ｈ」〜「０２ＦＦＦＦＦＨ」はＲＡＭ１２に、ま
たアドレス「０３０００００Ｈ」〜「０３ＦＦＦＦＦ
Ｈ」はＥＥＰＲＯＭ１３に、そしてアドレス「０４００
０００Ｈ」〜「０４ＦＦＦＦＦＨ」はＥＥＰＲＯＭ１４
に夫々割り付けられている。ＣＰＵ２〜４盤についても
同様である。

【００３３】図２に戻り、上記の如く保守コンソール２
００はＬＡＮ３００を介して本マルチＣＰＵシステムの
各ＣＰＵと相互にデータ通信可能である。但し、本実施
の形態における保守コンソール２００は、保守オペレー
タの指示入力に従い、ダウンロード処理の上位（全体的
な）制御を行う特定のＣＰＵ（以下、制御ＣＰＵとも呼
ぶ）に対してダウンロード指示のメッセージを送出した
り、又は実際にダウンロード処理を実施しているＣＰＵ
（以下、ダウンロード実施ＣＰＵとも呼ぶ）からのファ
イル転送要求メッセージに対して当該ＣＰＵにダウンロ
ードデータの転送等を行う。

【００３４】図１５に実施の形態による保守コンソール
−ＣＰＵ間の通信パケットを示す。図において、「Ｄ
Ａ」はパケットの送信先アドレス、「ＳＡ」は送信元ア
ドレス、「種別」はダウンロード処理の機能種別、「対
象ＣＰＵ」はダウンロード対象のＣＰＵ番号、「ファイ
ル名」はダウンロードファイルのファイル名、「ファイ
ルサイズ」はダウンロードファイルのトータルのファイ
ルサイズ、「結果」はダウンロードの処理結果、「ファ
イルアドレス」はファイルサイズ中の何ブロック目かを
表すブロック番号、「転送サイズ」はファイル１ブロッ
ク（１フレーム）分の転送サイズ、「ダウンロードデー
タ」はダウンロードファイルのファイルデータ（ファー
ムウェア）を夫々表す。

【００３５】例えば、保守コンソールから制御ＣＰＵに
送られる「ダウンロード指示」のメッセージについて説
明すると、「ＳＡ」＝コンソール２００、「ＤＡ」＝制
御ＣＰＵ１、「種別」＝ダウンロード指示、「対象ＣＰ
Ｕ」＝ＣＰＵ３（但し、３はＣＰＵ番号を表す）、「フ
ァイル名」＝download.hex、「ファイルサイズ」＝１０
０ブロックである。

【００３６】またダウンロード実施ＣＰＵから保守コン
ソールに送られる「ファイル転送要求」のメッセージに
ついて説明すると、「ＳＡ」＝ダウンロード実施ＣＰＵ
ｎ、「ＤＡ」＝コンソール２００、「種別」＝ファイル
転送要求、「ファイルアドレス」＝１０ブロック目、
「転送サイズ」＝１０２４バイト等である。また保守コ
ンソールからダウンロード実施ＣＰＵに送られる「デー
タ転送」のメッセージについて説明すると、「ＳＡ」＝
コンソール２００、「ＤＡ」＝ダウンロード実施ＣＰＵ
ｎ、「種別」＝データ転送、「ファイルアドレス」＝１
０ブロック目、「転送サイズ」＝１０２４バイト、「ダ
ウンロードデータ」＝ファームウェアデータである。

【００３７】また、図２に戻り、上記の如く本マルチＣ
ＰＵシステムの各ＣＰＵはＬＡＮ３００を介して相互に
データ通信可能である。図１６に実施の形態によるＣＰ
Ｕ−ＣＰＵ間の通信パケットを示す。図において、「負
荷率」は各ＣＰＵの負荷率（使用率，稼働率等）、「次
ファイルアドレス」は保守コンソール２００がダウンロ
ード実施ＣＰＵからの次ファイル転送要求に対して送信
すべきファイルデータのファイルアドレス、「次メモリ
アドレス」はダウンロード実施ＣＰＵが次の転送ファイ
ルデータを格納すべきＥＥＰＲＯＭの格納開始アドレス
を夫々表す。

【００３８】ここで、上記負荷率は、各ＣＰＵにおい
て、単位時間（例えば１秒）当たりのアイドルタスクの
実行時間に基づき、ＯＳ等により時々刻々と求められ
る。例えば１秒間にアイドルタスクがトータルで０．７
秒間実行された時の負荷率は３０％である。例えば、ダ
ウンロード実施ＣＰＵから制御ＣＰＵに対して定期的に
通知される「引継情報定期通知」のメッセージについて
説明すると、「ＳＡ」＝ダウンロード実施ＣＰＵｎ、
「ＤＡ」＝制御ＣＰＵ１、「種別」＝引継情報定期通
知、「対象ＣＰＵ」＝ＣＰＵ３、「ファイルサイズ」＝
１００ブロック、「次ファイルアドレス」＝８０ブロッ
ク目、「次メモリアドレス」＝０Ａ００８０００Ｈ等で
ある。他の各種メッセージについても同様に理解でき
る。

【００３９】図２に戻り、更に、上記した如く、保守コ
ンソール２００からダウンロード実施ＣＰＵｎ（例えば
ＣＰＵ２）に転送されたファームウェアデータは、一旦
当該ＣＰＵ２１のＲＡＭ２２に蓄えられ、その後にユニ
バーサルアクセスバス６を介してダウンロード対象ＣＰ
Ｕｎ（例えばＣＰＵ３）のバックアップ用ＥＥＰＲＯＭ
３４に直接に書き込まれる。即ち、ダウンロード実施Ｃ
ＰＵ２１はＥＥＰＲＯＭ３４へのダウンロードデータの
書き込みを、ダウンロード対象のＣＰＵ３１の処理を介
さずに、直接に行う。以下、この動作を具体的に説明す
る。

【００４０】今、ＣＰＵ２１がＥＥＰＲＯＭ３４へのデ
ータ書込サイクルを起動（データ書込制御信号及びアド
レス信号を付勢）すると、バスブリッジ２９は、ホスト
バス２７のデータ書込アドレスがＣＰＵ２盤のメモリ空
間の外側にあることにより、バスアービタ７に対してバ
ス要求信号ＲＱ２を出力する。やがて、バスアービタ７
よりバス許可信号ＧＴ２が返されると、バスブリッジ２
９が閉成され、これによりユニバーサルバス６は上記Ｃ
ＰＵ２１の出力したデータ書込制御信号及びアドレス信
号によりドライブされる。

【００４１】この時、ＣＰＵ３盤のバスブリッジ３９
は、ユニバーサルバス６のアドレス信号がＣＰＵ３盤の
メモリ空間の内側を指していることにより、バスアービ
タ３８に対してバス要求信号ＲＱを出力する。やがて、
バスアービタ３８よりバス許可信号ＧＴが返されると、
バスブリッジ３９が閉成され、これによりホストバス３
７は上記ＣＰＵ２１の出力したデータ書込制御信号及び
アドレス信号によりドライブされる。

【００４２】一方、ＣＰＵ２１に対しては、メモリアク
セスの最終ターゲットに係るホストバス３７につきバス
許可ＧＴが得られたことがバスアービタ３８，７，２８
等を介して知らされ、これを受けたＣＰＵ２１は上記ア
ドレスサイクルに続くデータ書込サイクルを付勢するこ
とで、１又は２以上のデータをＥＥＰＲＯＭ３４に直接
書き込む。かくして、本マルチＣＰＵシステムにいて
は、どのＣＰＵからどのメモリ（ＲＡＭ，ＥＥＰＲＯ
Ｍ，ＢＯＯＴ−ＲＯＭ）へでも直接にメモリアクセスが
可能である。

【００４３】以下、実施の形態によるファームウェアダ
ウンロード処理を詳細に説明する。なお、以下の説明で
は図２のＣＰＵ１１〜４１を夫々のＣＰＵ番号１〜４に
従ってＣＰＵ１〜４と呼ぶ。図４は実施の形態によるＢ
ＯＯＴ処理のフローチャートである。本マルチＣＰＵシ
ステム１００に電源投入され、又は各ＣＰＵが個別にリ
セットされると、この処理に入力する。

【００４４】即ち、例えばリセットされたＣＰＵのプロ
グラムカウンタ＝０により、当該ＣＰＵのプログラム
（ファームウェア）はＢＯＯＴ−ＲＯＭ５２の０番地か
ら実行開始される。ステップＳ１では自ＣＰＵ盤のＤＩ
Ｐスイッチより自ＣＰＵの番号を求める。ステップＳ２
ではＭＥＭ盤５のＥＥＰＲＯＭ５３から自ＣＰＵ番号に
対応する欄のファーム実行アドレスを求める。ステップ
Ｓ３では前記求めた実行アドレスにジャンプする。以後
このＣＰＵは自ＣＰＵ盤のＥＥＰＲＯＭ（実行ファーム
ウェア）を使用して処理を続行する。

【００４５】図５〜図７は実施の形態による制御ＣＰＵ
処理のフローチャート（１）〜（３）である。なお、図
５〜図７において、ステップＳ５，Ｓ６の各処理は所謂
マルチプログラミング方式によるＯＳの処理であり、そ
れ以外の処理はこのＯＳにより起動されるタスク処理と
考えて良い。図５において、ステップＳ５ではＯＳがイ
ベント（メッセージ受信割込、タイマ割込等）の発生を
待ち、何らかのイベントが発生すると、ステップＳ６で
はイベント種別に応じて処理分岐（対応するタスクを起
動）する。

【００４６】今、制御ＣＰＵ１が保守コンソール２００
からＣＰＵ３に対するダウンロード指示を受けると、ス
テップＳ１１以降の処理に入力する。ステップＳ１１で
は各ＣＰＵ（制御ＣＰＵ１を含む）の負荷率を収集す
る。ステップＳ１２では負荷率最小のＣＰＵ（例えばＣ
ＰＵ２）を求める。ステップＳ１３では制御ＣＰＵ１が
負荷率最小のＣＰＵ２に対してＣＰＵ３へのダウンロー
ド開始を指示する。ステップＳ１４ではダウンロード処
理進行を管理するためのダウンロード管理情報を設定す
る。ステップＳ１５では次回の負荷率収集タイミングを
決めるための定期監視用タイマ（例えば３０秒）を起動
する。ステップＳ１６ではダウンロード実施ＣＰＵ２に
対する障害監視用タイマ（例えば２分）を起動し、この
処理を抜ける。

【００４７】挿入図（ａ）に一例のダウンロード管理情
報を示す。例えば、「ダウンロード対象ＣＰＵ」＝ＣＰ
Ｕ３、「ファイル名」＝download.hex、「ファイルサイ
ズ」＝１００ブロック、「ダウンロード実施ＣＰＵ」＝
ＣＰＵ２、「次ファイルアドレス」＝１ブロック目、
「次メモリアドレス」＝０Ａ００００００Ｈが記録され
る。

【００４８】図６に進み、制御ＣＰＵ１がダウンロード
実施ＣＰＵ２からのダウンロード引継情報定期通知を受
けると、ステップＳ３１以降の処理に入力する。このダ
ウンロード引継情報定期通知はダウンロード実施ＣＰＵ
２が所定ブロック数（例えば１０ブロック程度）のダウ
ンロードを行った時点でダウンロード実施ＣＰＵ２によ
り生成され、制御ＣＰＵ１に送られる。

【００４９】ステップＳ３１では、ダウンロード実施Ｃ
ＰＵ２が稼働（ダウンロードを実施）していることによ
り、障害監視用タイマ（２分）を再起動する。ステップ
Ｓ３２ではダウンロード管理情報（次ファイルアドレ
ス，次メモリアドレス等）を更新し、この処理を抜け
る。図５に戻り、制御ＣＰＵ１の上記定期監視用タイマ
（３０秒）がタイムアウトすると、ステップＳ２１以降
の処理に入力する。

【００５０】ステップＳ２１ではダウンロード管理情報
に基づきダウンロードファイルの残量が所定（例えば１
０％）以下か否かを判別する。残量が所定以下の場合
は、このまま最後まで現時点のダウンロード実施ＣＰＵ
２にダウンロード処理を続行させるのが能率的と考える
ので、ステップＳ３０で定期監視用タイマ（３０秒）を
再起動し、この処理を抜ける。

【００５１】また残量が所定以下でない場合は、ステッ
プＳ２２で各ＣＰＵ（制御ＣＰＵ１を含む）の負荷率を
収集する。ステップＳ２３では負荷率最小のＣＰＵを求
める。ステップＳ２４ではこの負荷率最小のＣＰＵが現
時点のダウンロード実施ＣＰＵと同一か否かを判別す
る。ダウンロード実施ＣＰＵと同一の場合は、このまま
ダウンロード処理を継続させれば良いので、ステップＳ
３０で定期監視用タイマ（３０秒）を再起動し、この処
理を抜ける。

【００５２】またダウンロード実施ＣＰＵと同一でない
場合は、ステップＳ２５でダウンロード実施ＣＰＵにダ
ウンロード中止を指示する。ステップＳ２６では当該Ｃ
ＰＵからのダウンロード中断通知（中断通知引継情報メ
ッセージに相当）を待つ。やがて、ダウンロード中断通
知を受けると、該通知には中断時最新の次ファイルアド
レス、次メモリアドレス等の情報が含まれている。制御
はステップＳ２７に進み、この負荷率最小のＣＰＵ（例
えばＣＰＵ４）にダウンロード引継を指示する。ステッ
プＳ２８ではダウンロード管理情報（ダウンロード実施
ＣＰＵ等）を更新する。ステップＳ２９では障害監視用
タイマ（２分）を再起動する。ステップＳ３０では定期
監視用タイマ（３０秒）を再起動し、この処理を抜け
る。

【００５３】図６に進み、ダウンロード実施ＣＰＵ２が
何らかの理由で障害（ファームの暴走等）になると、制
御ＣＰＵ１には上記ダウンロード引継情報の定期通知が
行われず、やがて障害監視用タイマ（２分）がタイムア
ウトし、ステップＳ４１以降の処理に入力する。ステッ
プＳ４１ではダウンロード実施ＣＰＵ２を除く各ＣＰＵ
（制御ＣＰＵ１を含む）の負荷率を収集する。ステップ
Ｓ４２では負荷率最小のＣＰＵ（例えばＣＰＵ４）を求
める。ステップＳ４３ではダウンロード管理情報に基づ
きダウンロード引継メッセージを作成する。ステップＳ
４４では負荷率最小のＣＰＵ４にダウンロード引継を指
示する。ステップＳ４５では定期監視用タイマ（３０
秒）を再起動する。ステップＳ４６では障害監視用タイ
マ（２分）を再起動し、この処理を抜ける。

【００５４】また制御ＣＰＵ１がダウンロード実施ＣＰ
Ｕ２からの自発的（過負荷状態等の理由による）なダウ
ンロード中断通知を受けると、ステップＳ５１以降の処
理に入力する。テップＳ５１ではダウンロード実施ＣＰ
Ｕ２を除く各ＣＰＵ（制御ＣＰＵ１を含む）の負荷率を
収集する。ステップＳ５２では負荷率最小のＣＰＵ（例
えばＣＰＵ４）を求める。ステップＳ５３では負荷率最
小のＣＰＵ４にダウンロード引継を指示する。ステップ
Ｓ５４ではダウンロード管理情報を更新する。ステップ
Ｓ５５では定期監視用タイマ（３０秒）を再起動する。
ステップＳ４６では障害監視用タイマ（２分）を再起動
し、この処理を抜ける。

【００５５】図７において、制御ＣＰＵ１がダウンロー
ド非実施ＣＰＵ（例えばＣＰＵ４）からダウンロード引
受通知（例えば軽負荷状態による）を受けると、ステッ
プＳ６１以降の処理に入力する。ステップＳ６１ではダ
ウンロード実施ＣＰＵ２にダウンロード中止を指示す
る。ステップＳ６２では当該ＣＰＵ２からのダウンロー
ド中断通知を待つ。やがて、ダウンロード中断通知を受
けると、ステップＳ６３に進み、ダウンロード引受ＣＰ
Ｕ４にダウンロード引継を指示する。ステップＳ６４で
はダウンロード管理情報を更新する。ステップＳ６５で
は定期監視用タイマ（３０秒）を再起動する。そして、
ステップＳ６６では障害監視用タイマ（２分）を再起動
し、この処理を抜ける。

【００５６】また、制御ＣＰＵ１がダウンロード実施Ｃ
ＰＵ２からのダウンロード完了通知を受けると、ステッ
プＳ７１以降の処理に入力する。ステップＳ７１では定
期監視用タイマを停止する。ステップＳ７２では障害監
視用タイマを停止する。ステップＳ７３では保守コンソ
ール２００にダウンロード終了の通知を行う。

【００５７】図８，図９は実施の形態によるダウンロー
ド実施ＣＰＵ処理のフローチャート（１），（２）であ
る。なお、図８，図９において、ステップＳ５ではＯＳ
がイベント（メッセージ受信割込、タスク割付処理等）
の発生を待ち、何らかのイベントが発生すると、ステッ
プＳ６ではイベント種別に応じて処理分岐（対応するタ
スクを起動）する。

【００５８】図８において、負荷率最小のＣＰＵ（例え
ばＣＰＵ２）が制御ＣＰＵ１からＣＰＵ３に対するダウ
ンロード開始メッセージを受けると、ステップＳ８１以
降の処理に入力する。ステップＳ８１ではＭＥＭ盤５の
ＥＥＰＲＯＭ５３よりダウンロード対象ＣＰＵ３のダウ
ンロードアドレスを求める。ステップＳ８２ではダウン
ロード管理情報を作成する。ステップＳ８３では図９に
示すダウンロードタスクを生成してＯＳに対する処理待
ち状態となし、この処理を抜ける。

【００５９】挿入図（ａ）に一例のダウンロード管理情
報を示す。例えば、「ダウンロード対象ＣＰＵ」＝ＣＰ
Ｕ３、「ファイル名」＝download.hex、「ファイルサイ
ズ」＝１００ブロック、「ダウンロード実施回数」＝
０、「次ファイルアドレス」＝１ブロック目、「次メモ
リアドレス」＝０Ａ００００００Ｈが記録される。

【００６０】又は、負荷率最小のＣＰＵ（例えばＣＰＵ
４）が制御ＣＰＵ１からのダウンロード引継メッセージ
を受けると、ステップＳ８４の処理に入力する。ステッ
プＳ８４ではダウンロード引継メッセージのダウンロー
ド引継情報に従い上記挿入図（ａ）と同様のダウンロー
ド管理情報（但し、次ファイルアドレス，次メモリアド
レスの内容は異なる）を作成する。ステップＳ８５では
図９に示すダウンロードタスクを生成してＯＳに対する
処理待ち状態となし、この処理を抜ける。

【００６１】また、ダウンロード実施ＣＰＵ（例えばＣ
ＰＵ２）が制御ＣＰＵ１からのダウンロード中止メッセ
ージを受けると、ステップＳ８６以降の処理に入力す
る。ステップＳ８６ではダウンロード管理情報に基づき
中断通知引継情報メッセージを作成する。ステップＳ８
７では制御ＣＰＵ１にダウンロード中断（中断通知引継
情報メッセージ）を通知する。ステップＳ８７ではダウ
ンロードタスクのＯＳに対する処理待ち状態を消勢す
る。

【００６２】図９において、例えばダウンロード実施Ｃ
ＰＵ２のＯＳが処理待ちのダウンロードタスクを実行に
移すとステップＳ９１以降の処理に入力する。ステップ
Ｓ９１では保守コンソール２００にファイル転送要求メ
ッセージを送信する。ステップＳ９２では保守コンソー
ル２００からのファイルデータ転送を待つ。やがて、保
守コンソール２００からファイルデータが転送される
と、ステップＳ９３では受信データを一旦ＲＡＭ２２に
書き込み、その後に該受信データをＲＡＭ２２から読み
出し、これらを共通バス６のバスアクセスを介してダウ
ンロード対象ＣＰＵ（例えばＣＰＵ３）のダウンロード
用ＥＥＰＲＯＭ３４に直接書き込む。ステップＳ９４で
はダウンロード管理情報（ダウンロード実施回数，次フ
ァイルアドレス，次メモリアドレス）を更新する。

【００６３】ステップＳ９５ではダウンロード処理完了
か否かを判別する。ダウンロード完了でない場合は、更
にステップＳ９６でダウンロードサイクルを所定回数
（例えば１０回）実施したか否かを判別する。未だ所定
回数実施していない場合はこのまま処理を抜ける。こう
して、次にこのダウンロードタスクが実行に移される
と、上記同様の処理を繰り返す。

【００６４】また上記ステップＳ９６の判別でダウンロ
ードサイクルを所定回数実施した場合は更にステップＳ
９７で自ＣＰＵの負荷率が所定（例えば６０％）未満か
否かを判別する。なお、この自ＣＰＵの負荷率について
は、例えばＯＳが常時監視・管理しており、このダウン
ロードタスクからＯＳに問い合わせることにより、容易
に得られる。そして、自ＣＰＵの負荷率が６０％未満
（過負荷状態ではない）の場合は、ステップＳ９８でダ
ウンロード引継情報を作成し、制御ＣＰＵ１に定期通知
する。

【００６５】また、自ＣＰＵの負荷率が６０％以上（過
負荷状態）の場合は、ステップＳ９９に進み、ダウンロ
ード管理情報に基づき当該ダウンロードの中断通知引継
情報メッセージを作成する。ステップＳ１００では制御
ＣＰＵ１にダウンロード中断（中断通知引継情報メッセ
ージ）を通知する。ステップＳ１０１ではダウンロード
タスクのＯＳに対する処理待ち状態を消勢し、この処理
を抜ける。

【００６６】また、上記ステップＳ９５の判別でダウン
ロード完了の場合は、ステップＳ１０２でＭＥＭ盤５の
ＥＥＰＲＯＭ３４の実行アドレスとダウンロードアドレ
スとを入れ替える。ステップＳ１０３では制御ＣＰＵ１
にダウンロード完了を通知し、ステップＳ１０１に進
む。なお、上記実施の形態では、自ＣＰＵの負荷率の検
査（即ち、ステップＳ９７の判別）をダウンロード処理
の１０サイクルイ毎に行う構成としたが、これに限らな
い。例えばダウンロード処理の１サイクルイ毎に毎回行
うように構成しても良い。

【００６７】但し、通常この自ＣＰＵの負荷率は、本来
のデータ通信制御処理における通信トラフィックの増減
に伴い、比較的大きくかつ頻繁に変動することが予想さ
れるので、ダウンロード処理の１サイクル毎に行うより
も、複数サイクル毎に行う方が、瞬時的な過負荷状態を
検出してしまう機会が少ない。即ち、これによりダウン
ロード実施ＣＰＵが頻繁に切り換わるような状態を緩和
できる。

【００６８】なお、図示しないが、ダウンロード実施Ｃ
ＰＵ２以外の、例えば軽負荷状態となったＣＰＵ４がダ
ウンロード引受メッセージを作成して制御ＣＰＵ１に送
出するような処理等は、上記各処理の説明より容易に作
成できる。図１０〜図１４は実施の形態によるダウンロ
ード処理のシーケンス図（１）〜（５）である。図１０
は制御ＣＰＵ１が定期的に全ＣＰＵの負荷率を収集・比
較することにより、各時点で負荷率最小のＣＰＵにダウ
ンロード処理を実行させる場合を示している。

【００６９】保守コンソール２００は制御ＣＰＵ１にＣ
ＰＵ３へのダウンロード指示を送信する。これを受けた
制御ＣＰＵ１は、ＣＰＵ２〜４に負荷率の送出を要求す
る。これに対して各ＣＰＵ２〜４は、制御ＣＰＵ１に現
時点の負荷率（例えば２０％，５０％，３０％）を通知
する。制御ＣＰＵ１は通知された各負荷率及び自ＣＰＵ
１の負荷率（例えば４０％）を比較し、負荷率の最も低
いＣＰＵ２にＣＰＵ３のダウンロード開始を指示する。

【００７０】これを受けたダウンロード実施ＣＰＵ２
は、まずＭＥＭ盤５のＥＥＰＲＯＭ５３からＣＰＵ３
（ＥＰＲＯＭ３４）のダウンロード開始アドレス「０Ａ
００００００Ｈ」を求める。次に保守コンソール２００
にファイルデータの転送を要求する。次いで保守コンソ
ールからのダウンロードデータを受信し、該受信データ
をユニバーサルアクセスバス６を介してＥＰＲＯＭ３４
のダウンロード開始アドレスから書き込む。

【００７１】以下、同様にしてダウンロード処理を繰り
返し、やがて、ダウンロード実施ＣＰＵ２は例えば１０
フレーム分のデータ書込を終了すると、その時点のダウ
ンロード引継情報を生成し、制御ＣＰＵ１に通知する。
制御ＣＰＵ１は通知されたダウンロード引継情報に基づ
き自己のダウンロード管理情報を更新する。更に、ダウ
ンロード実施ＣＰＵ２は、ダウンロード処理を継続す
る。

【００７２】一方、制御ＣＰＵ１は、上記ダウンロード
開始の指示から例えば３０秒を経過したことにより、再
び各ＣＰＵ２〜４より負荷率（今度は例えば４０％，５
０％，２０％）を収集し、該収集した各負荷率及び自Ｃ
ＰＵ１の負荷率（例えば４０％）を比較する。そして、
この例ではダウンロード実施ＣＰＵ２よりも負荷率の低
いＣＰＵ（例えばＣＰＵ４）があることにより、これま
でのダウンロード実施ＣＰＵ２にダウンロード中断（中
止）を指示する。これを受けたダウンロード実施ＣＰＵ
２は、ダウンロード処理を中止すると共に、ダウンロー
ド中断通知引継情報メッセージを生成して、これを制御
ＣＰＵ１に通知する。

【００７３】これを受けた制御ＣＰＵ１は、ダウンロー
ド引継情報と共に上記負荷率最小のＣＰＵ４にダウンロ
ード引継を指示する。これを受けたＣＰＵ４は、以後は
ダウンロード実施ＣＰＵ４として上記と同様のダウンロ
ード処理を実行する。そして、ダウンロード実施ＣＰＵ
４は、やがて全てのダウンロード処理を完了すると、制
御ＣＰＵ１にダウンロード完了を通知する。

【００７４】これを受けた制御ＣＰＵ１は、保守コンソ
ール２００にダウンロード終了を通知し、これによりＥ
ＥＰＲＯＭ３４へのファームウェアダウンロード処理を
終了する。なお、上記の如く、制御ＣＰＵ１は所定時間
（例えば２０秒）間隔で全ＣＰＵの負荷率を収集し、各
時点で負荷最小のＣＰＵにダウンロード処理を引き継が
せているが、ある時点におけるダウンロードデータの残
量が既に所定（例えば１０％）を切っていたような場合
には、その後のダウンロード引継処理を行なう時間内に
ダウンロード処理を完了できるため、他のＣＰＵへのダ
ウンロード引継を行わない。

【００７５】図１１はダウンロード実施中のＣＰＵ２が
自ら過負荷状態を検出してダウンロード処理を中断した
ことにより、これを受けた制御ＣＰＵ１が他のＣＰＵに
ダウンロード処理を引き継がせる場合を示している。Ｃ
ＰＵ２は、当初は負荷率最小（２０％）によりダウンロ
ード実施ＣＰＵ２となってダウンロード処理を実行して
いたが、ダウンロード処理実行によりＣＰＵ２の負荷率
が増加したことに加え、その後の通信トフィックの増大
等によりＣＰＵ２本来のデータ通信制御量が大幅に増大
したことにより、図示の時点では過負荷状態となってい
る。

【００７６】この場合のダウンロード実施ＣＰＵ２は、
図９のステップＳ９７の判別で過負荷状態を検出したこ
とによりダウンロード中断通知引継情報メッセージを制
御ＣＰＵ１に送信して、自らダウンロード処理を中断す
る。これを受けた制御ＣＰＵ１は、ダウンロードを中断
したＣＰＵ２を除く各ＣＰＵ３，４から負荷率（例えば
５０％，２０％）を収集すると共に、自ＣＰＵ１の負荷
率（４０％）をも含めて負荷率の比較を行い、この時点
で負荷率最小のＣＰＵ４にダウンロード引継の指示を行
う。以後、このＣＰＵ４はダウンロード実施ＣＰＵ４と
なって上記ダウンロード処理の続きを実行する。

【００７７】図１２はダウンロード実施中のＣＰＵ２に
ソフトウェア障害等が発生したことにより、これを検出
した制御ＣＰＵ１が他のＣＰＵにダウンロード処理を引
き継がせる場合を示している。ＣＰＵ２は、当初は負荷
率最小（２０％）によりダウンロード実施ＣＰＵ２とな
ってダウンロード処理を実行していたが、その後のファ
ームウェアの暴走又はループ等により図示の時点では障
害状態となっている。

【００７８】制御ＣＰＵ１では、ダウンロード実施ＣＰ
Ｕ２からの引継情報定期通知が定期的（２分以内）に得
られないことにより内部で障害監視用タイマがタイムア
ウトし、ダウンロード実施ＣＰＵ２の障害を検出する。
これにより、制御ＣＰＵ１は障害ＣＰＵ２を除く各ＣＰ
Ｕ３，４から負荷率（例えば５０％，２０％）を収集す
ると共に、自ＣＰＵ１の負荷率（４０％）をも含めて負
荷率の比較を行い、この時点で負荷率最小のＣＰＵ４に
ダウンロード引継の指示を行う。以後、このＣＰＵ４は
ダウンロード実施ＣＰＵ４となって上記ダウンロード処
理の続きを実行する。

【００７９】図１３は、ＣＰＵ２によるダウンロード実
施中に、制御ＣＰＵ１に対して自己の負荷率が所定（例
えば２０％）以下の旨を通知した例えばＣＰＵ４に対し
て、制御ＣＰＵ１がダウンロード処理を引き継がせる場
合を示している。ＣＰＵ２は、当初は負荷率最小（２０
％）によりダウンロード実施ＣＰＵ２となってダウンロ
ード処理を実行している。

【００８０】一方、他のＣＰＵ（例えばＣＰＵ４）は既
に制御ＣＰＵ１より１回又は２回以上の負荷率の送信要
求を受けたことにより、本マルチＣＰＵシステムにおい
てダウンロード処理が進行中であることを自ら認識でき
る。係る状況下で、ＣＰＵ４は自己の負荷率が所定（例
えば２０％）以下となったことにより制御ＣＰＵ１に対
してダウンロード引受通知を送信する。

【００８１】これを受けた制御ＣＰＵ１は、ダウンロー
ド実施ＣＰＵ２に対してダウンロード中断を指示する。
これを受けたＣＰＵ２は、自己のダウンロード処理を中
止してダウンロード引継情報を作成し、ダウンロード中
断の旨と共に制御ＣＰＵ１に通知する。これを受けた制
御ＣＰＵ１は、ダウンロード引継情報を伴ってＣＰＵ４
にダウンロード引継の指示を行う。以後、このＣＰＵ４
はダウンロード実施ＣＰＵ４となって上記ダウンロード
処理の続きを実行する。

【００８２】なお、上記制御ＣＰＵ１がＣＰＵ４からダ
ウンロード引受通知を受信した場合であっても、例えば
制御ＣＰＵ１がＣＰＵ２とＣＰＵ４の負荷率を比較する
ことにより、もしダウンロード実施ＣＰＵ２の負荷率が
低い場合は、ＣＰＵ４にダウンロードを引き継がせない
事が可能である。図１４は、本マルチＣＰＵシステムの
各ＣＰＵ１〜４が、システムで予め定められた順番に従
って、所定時間（例えば３０秒）毎にダウンロード処理
を持ち回りで実行する場合を示している。

【００８３】まず保守コンソール２００より制御ＣＰＵ
１に対しＣＰＵ３（ＥＥＰＲＯＭ３４）へのファームウ
ェアダウンロード実施を指示する。これを受けた制御Ｃ
ＰＵ１は、内部タイマ（例えば３０秒）を起動し、ＣＰ
Ｕ３に対するダウンロードを実施する。やがて、内部タ
イマがタイムアウトすると、ダウンロード引継情報を作
成し、制御ＣＰＵ１からＣＰＵ２にダウンロード引継を
指示する。

【００８４】これを受けたＣＰＵ２は、内部タイマ（例
えば３０秒）を起動し、ＣＰＵ３に対するダウンロード
を実施する。やがて、内部タイマがタイムアウトする
と、ダウンロード引継情報を作成し、ＣＰＵ２からＣＰ
Ｕ３にダウンロード引継を指示する。以下同様にして、
このダウンロード処理はＣＰＵ３→ＣＰＵ４→ＣＰＵ１
→ＣＰＵ２等と順次引き継がれる。そして、ダウンロー
ド処理を完了したＣＰＵは制御ＣＰＵ１にダウンロード
完了を通知し、これを受けた制御ＣＰＵ１は保守コンソ
ール２００にダウンロード終了を通知する。

【００８５】なお、上記ダウンロード処理を各ＣＰＵ１
〜４が各所定時間間隔で持ち回る代わりに、各ＣＰＵ１
〜４がダウンロードサイクルの所定回数（又は所定デー
タ量等）で持ち回るように構成しても良いことは明らか
である。また、上記実施の形態では制御ＣＰＵ１は各Ｃ
ＰＵの負荷率に基づき負荷率最小のＣＰＵをダウンロー
ド実施ＣＰＵに決定したが、その際には各ＣＰＵの機能
分担等を考慮に入れても良い。例えば、ＣＰＵ４は実時
間性の高い（レスポンスの速い）処理を担当しているた
め、比較の対象から外されるか、又はＣＰＵ４の実際の
負荷率に例えば１０％程度上乗せされた負荷率で比較さ
れる。

【００８６】また、上記実施の形態では各ＣＰＵ間の通
信をＬＡＮ３００を介して行ったが、ユニバーサルアク
セスバス６を介して行うように構成しても良い。また、
上記本発明に好適なる実施の形態を述べたが、本発明思
想を逸脱しない範囲内で各部の構成、制御、及びこれら
の組合せの様々な変更が行えることは言うまでも無い。
例えばバス構造やＬＡＮの構造等は、上記実施の形態に
は限定されず、他にも様々な構造を採用できる。

【００８７】

【発明の効果】以上述べた如く本発明によれば、マルチ
ＣＰＵシステムにおける任意ＣＰＵへのファームウェア
ダウンロードを何時でも他のどのＣＰＵからでも効率良
く行えるので、システムの安定度を高め、かつサービス
品質の向上に寄与するところが極めて大きい。

【図面の簡単な説明】

【図１】本発明の原理を説明する図である。

【図２】実施の形態によるマルチＣＰＵシステムのブロ
ック図である。

【図３】実施の形態によるマルチＣＰＵシステムのメモ
リマップを説明する図である。

【図４】図４は実施の形態によるＢＯＯＴ処理のフロー
チャートである。

【図５】実施の形態による制御ＣＰＵ処理のフローチャ
ート（１）である。

【図６】実施の形態による制御ＣＰＵ処理のフローチャ
ート（２）である。

【図７】実施の形態による制御ＣＰＵ処理のフローチャ
ート（３）である。

【図８】実施の形態によるダウンロード実施ＣＰＵ処理
のフローチャート（１）である。

【図９】実施の形態によるダウンロード実施ＣＰＵ処理
のフローチャート（２）である。

【図１０】実施の形態によるダウンロード処理のシーケ
ンス図（１）である。

【図１１】実施の形態によるダウンロード処理のシーケ
ンス図（２）である。

【図１２】実施の形態によるダウンロード処理のシーケ
ンス図（３）である。

【図１３】実施の形態によるダウンロード処理のシーケ
ンス図（４）である。

【図１４】実施の形態によるダウンロード処理のシーケ
ンス図（５）である。

【図１５】実施の形態による保守コンソール−ＣＰＵ間
の通信パケットを説明する図である。

【図１６】実施の形態によるＣＰＵ−ＣＰＵ間の通信パ
ケットを説明する図である。

【符号の説明】

１〜４ ＣＰＵ１〜４盤 ５ メモリ（ＭＥＭ）盤 ６ ユニバーサルアクセスバス ７ バスアービタ（ＵＡＢ） １５〜４５ ＤＩＰスイッチ（ＤＳＷ） １６〜４６ 通信制御部（ＣＯＭ） １７〜４７ ホストバス ５７ メモリバス １８〜４８ バスアービタ（ＨＡＢ） １９〜５９ バスブリッジ（ＨＵＢ） １００ マルチＣＰＵシステム ２００ 保守コンソール ３００ ローカルエリアネットワーク（ＬＡＮ）

───────────────────────────────────────────────────── フロントページの続き (72)発明者 南野 謙一 石川県金沢市広岡３丁目１番１号 富士通 北陸通信システム株式会社内 (72)発明者 江川 和也 石川県金沢市広岡３丁目１番１号 富士通 北陸通信システム株式会社内

Claims (12)

【特許請求の範囲】
1. 【請求項１】 ＣＰＵとメモリとデータ通信手段とを備
   える複数のプロセッサ手段がメモリアクセスをするため
   の共通バスを介して相互に接続するマルチＣＰＵシステ
   ムのファームウェアダウンロード方式において、 外部装置よりあるプロセッサ手段にデータ通信手段を介
   してダウンロードされたファームウェアを該プロセッサ
   手段のＣＰＵが前記共通バスに対するメモリアクセスを
   介して他のＣＰＵのメモリに直接書き込むことを特徴と
   するファームウェアダウンロード方式。
2. 【請求項２】 各ＣＰＵは各データ通信手段を介して相
   互に接続すると共に、該データ通信手段を介して、外部
   装置からダウンロード制御の指示を受けた制御ＣＰＵ
   が、自ＣＰＵ又は他のＣＰＵを選択して、該選択された
   ＣＰＵにダウンロード又は前記ダウンロードの仲介処理
   を実施させることを特徴とする請求項１に記載のファー
   ムウェアダウンロード方式。
3. 【請求項３】 制御ＣＰＵは、各ＣＰＵから負荷率を収
   集して比較すると共に、負荷率最小のＣＰＵにダウンロ
   ード又はその仲介処理を実施させることを特徴とする請
   求項２に記載のファームウェアダウンロード方式。
4. 【請求項４】 ダウンロード又はその仲介処理を実施し
   ているダウンロード実施ＣＰＵは、定期的にダウンロー
   ド又はその仲介処理の引継情報を作成して制御ＣＰＵに
   通知することを特徴とする請求項２又は３に記載のファ
   ームウェアダウンロード方式。
5. 【請求項５】 制御ＣＰＵは、ダウンロード実施ＣＰＵ
   からの引継情報の通知が所定時間内に得られないことに
   より、他のＣＰＵにダウンロード又はその仲介処理を引
   き継がせることを特徴とする請求項４に記載のファーム
   ウェアダウンロード方式。
6. 【請求項６】 制御ＣＰＵは、各ＣＰＵから定期的に負
   荷率を収集して比較すると共に、ダウンロード又はその
   仲介処理を実施しているダウンロード実施ＣＰＵよりも
   他のＣＰＵの負荷率が低い場合は、前記ダウンロード実
   施ＣＰＵのダウンロード又はその仲介処理を中断させ、
   かつ他の負荷率最小のＣＰＵにダウンロード又はその仲
   介処理を引き継がせることを特徴とする請求項２乃至４
   の何れか一つに記載のファームウェアダウンロード方
   式。
7. 【請求項７】 ダウンロード中断の指示を受けたダウン
   ロード実施ＣＰＵは、ダウンロード又はその仲介処理を
   中断すると共に、ダウンロード又はその仲介処理の引継
   情報を作成して制御ＣＰＵに通知することを特徴とする
   請求項６に記載のファームウェアダウンロード方式。
8. 【請求項８】 ダウンロード又はその仲介処理を実施し
   ているダウンロード実施ＣＰＵは、自ＣＰＵの負荷率が
   所定以上となったことによりダウンロード又はその仲介
   処理の引継情報を作成して制御ＣＰＵに通知することを
   特徴とする請求項２乃至４の何れか一つに記載のファー
   ムウェアダウンロード方式。
9. 【請求項９】 ダウンロード及びその仲介処理を実施し
   ていないＣＰＵは、自ＣＰＵの負荷率が所定以下となっ
   たことによりその旨を制御ＣＰＵに通知することを特徴
   とする請求項２乃至４の何れか一つに記載のファームウ
   ェアダウンロード方式。
10. 【請求項１０】 制御ＣＰＵは、ダウンロード実施ＣＰ
    Ｕからの引継情報を元にダウンロード又はその仲介処理
    の残量を求め、該残量が所定以下の場合はダウンロード
    実施ＣＰＵのダウンロード又はその仲介処理を中断させ
    ないことを特徴とする請求項６，８又は９に記載のファ
    ームウェアダウンロード方式。
11. 【請求項１１】 各ＣＰＵは各データ通信手段を介して
    相互に接続すると共に、予めダウンロード又はその仲介
    処理を実施するＣＰＵの順番を定めておき、かつ前記デ
    ータ通信手段を介して、まず外部装置からダウンロード
    開始の指示を受けたＣＰＵが所定時間のダウンロード又
    はその仲介処理を実施し、次に該ＣＰＵが前記順番に従
    ってダウンロード又はその仲介処理を次のＣＰＵに引き
    継がせ、こうして、各所定時間のダウンロード又はその
    仲介処理を各ＣＰＵ間の持ち回りで順次実施することを
    特徴とする請求項１に記載のファームウェアダウンロー
    ド方式。
12. 【請求項１２】 各ＣＰＵは各データ通信手段を介して
    相互に接続すると共に、予めダウンロード又はその仲介
    処理を実施するＣＰＵの順番を定めておき、かつ前記デ
    ータ通信手段を介して、まず外部装置からダウンロード
    開始の指示を受けたＣＰＵが所定量のダウンロード又は
    その仲介処理を実施し、次に該ＣＰＵが前記順番に従っ
    てダウンロード又はその仲介処理を次のＣＰＵに引き継
    がせ、こうして、各所定量のダウンロード又はその仲介
    処理を各ＣＰＵ間の持ち回りで順次実施することを特徴
    とする請求項１に記載のファームウェアダウンロード方
    式。