特許 7134771 通信システム及びプログラム更新方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-09-02

(45)【発行日】2022-09-12

(54)【発明の名称】通信システム及びプログラム更新方法

(51)【国際特許分類】

   G06F 8/65 20180101AFI20220905BHJP

【ＦＩ】

G06F8/65

【請求項の数】 8

(21)【出願番号】P 2018143328

(22)【出願日】2018-07-31

(65)【公開番号】P2020021201

(43)【公開日】2020-02-06

【審査請求日】2021-04-27

(73)【特許権者】

【識別番号】308033711

【氏名又は名称】ラピスセミコンダクタ株式会社

(74)【代理人】

【識別番号】100079119

【弁理士】

【氏名又は名称】藤村 元彦

(74)【代理人】

【識別番号】100147728

【弁理士】

【氏名又は名称】高野 信司

(72)【発明者】

【氏名】田中 義幸

(72)【発明者】

【氏名】斎藤 直孝

(72)【発明者】

【氏名】齋藤 栄一

【審査官】石川 亮

(56)【参考文献】

【文献】特開２０１２－２５２５５２（ＪＰ，Ａ）

【文献】国際公開第２０１６／０３９０３９（ＷＯ，Ａ１）

【文献】中国特許出願公開第１０４９１５２１９（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６５－８／６５８

(57)【特許請求の範囲】

【請求項1】

夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムであって、
前記複数の通信端末の各々は、
更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号を前記ホスト装置から受信した場合には、前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してからスタートリクエスト信号を前記ホスト装置に送信し、データ要求を行う権利を付与する許可信号を前記ホスト装置から受信した場合にはデータリクエスト信号を前記ホスト装置に送信し、
前記ホスト装置は、
前記配信準備完了信号をブロードキャスト送信し、その後、前記複数の通信端末のうちで最も早く前記スタートリクエスト信号を送信した１つの通信端末に前記許可信号を送信し、前記データリクエスト信号の受信に応じて前記更新用プログラムデータを前記複数の通信端末にブロードキャスト送信することを特徴とする通信システム。

【請求項2】

前記複数の通信端末の各々は、
前記スタートリクエスト信号の送信を行ってから所定のタイムアウト時間内に前記更新用プログラムデータを受信できなかった場合には、前記スタートリクエスト信号を再び前記ホスト装置に送信する再送信を行い、
前記ホスト装置は、前記複数の通信端末の各々のうちで最も早く前記スタートリクエスト信号の前記再送信を行った通信端末に前記許可信号を送信し、前記データリクエスト信号の受信に応じて前記更新用プログラムデータを再びブロードキャスト送信することを特徴とする請求項１に記載の通信システム。

【請求項3】

前記メモリは、前記プログラムデータが格納されている書換可能なユーザ領域と、前記プログラムデータの更新を行うための更新用プログラムが格納されている書換不可なシステム領域と、を含み、
前記複数の通信端末の各々は、前記配信準備完了信号の受信に応じて、前記ユーザ領域に格納されている前記プログラムデータを消去し、前記更新用プログラムデータの受信に応じて前記更新用プログラムデータを前記ユーザ領域に書き込むことを特徴とする請求項１又は２に記載の通信システム。

【請求項4】

前記複数の通信端末の各々は、前記プログラムデータの更新処理中であるか否かを表す更新状態フラグ及び前記ユーザ領域内の書換中のセクタ番号を示す書換中セクタ番号を記憶する不揮発性メモリを更に含むことを特徴とする請求項３に記載の通信システム。

【請求項5】

前記複数の通信端末の各々は、
前記プログラムデータの更新処理中にリセット処理が行われた場合には、前記不揮発性メモリから前記更新状態フラグ及び前記書換中セクタ番号を読み出し、
当該更新状態フラグが前記プログラムデータの更新処理中であることを示す場合には前記書換中セクタ番号にて示される前記ユーザ領域内のセクタのデータを消去し、前記スタートリクエスト信号を再び前記ホスト装置に送信する再送信を行うことを特徴とする請求項４に記載の通信システム。

【請求項6】

前記複数の通信端末の各々はセンサを有し、前記メモリに格納されている前記プログラムデータに従って前記センサで検知された検知情報を前記ホスト装置に送信することを特
徴とする請求項１～５のいずれか１に記載の通信システム。

【請求項7】

夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムであって、
前記複数の通信端末の各々は、
更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号を前記ホスト装置から受信した場合には、前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してからスタートリクエスト信号を前記ホスト装置に送信し、データ要求を行う権利を付与する許可信号を前記ホスト装置から受信した場合にはデータリクエスト信号を前記ホスト装置に送信し、
前記ホスト装置は、
前記複数の通信端末をｎ（ｎは２以上の整数）個のグループに区分けした際の所望の１つの前記グループに属する前記通信端末の各々にだけ前記配信準備完了信号をエニーキャスト送信し、その後、最も早く前記スタートリクエスト信号を送信した１つの通信端末に前記許可信号を送信し、前記データリクエスト信号の受信に応じて前記更新用プログラムデータを前記１つの前記グループに属する前記通信端末の各々にだけエニーキャスト送信することを特徴とする通信システム。

【請求項8】

夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムのプログラム更新方法であって、
前記ホスト装置が、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号をブロードキャストにて送信し、
前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してから前記複数の通信端末の各々がスタートリクエスト信号を前記ホスト装置に送信し、
前記複数の通信端末のうちで最も早く前記スタートリクエスト信号を送信した１つの通信端末に対して、前記ホスト装置が、データ要求を行う権利を付与する許可信号を送信し、
前記許可信号の受信に応じて前記１つの通信端末がデータリクエスト信号を前記ホスト装置に送信し、
前記データリクエスト信号の受信に応じて前記ホスト装置が前記更新用プログラムデータを前記複数の通信端末にブロードキャスト送信することを特徴とする通信システムのプログラム更新方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数の通信端末と、各通信端末との通信を行うホスト装置と、を含む通信システム、及び各通信端末に格納されているプログラムの更新方法に関する。

【背景技術】

【0002】

現在、センサノードと称されるセンサ搭載の無線通信端末を複数配置し、各センサノードのセンサが検知したセンシング情報を、無線中継ノード及び通信ネットワークを介して管理サーバに提供するようにした通信システムが提案されている。各センサノードは、プログラムが格納されているメモリと、当該プログラムに従って上記したセンシング情報の取得及び通信の為の制御を行うマイクロプロセッサと、を含んでいる。

【0003】

ところで、各センサノードのメモリに格納されているプログラムは、不具合が発覚した場合或いは機能変更等により、新たなプログラムへの更新が必要となる。

【0004】

そこで、各センサノードに対するプログラムの更新処理を無線通信で行うようにした通信システムが提案された（例えば、特許文献１参照）。

【0005】

当該通信システムでは、複数のセンサノードのうちで、プログラムの更新処理が必要となるセンサノードが、個別に更新用プログラムの送信元のゲートウェイに対してデータ送信要求を行う。ゲートウェイは、当該データ送信要求を行ったセンサノードに、更新用のプログラムデータを無線送信する。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２００８－２８８９７８号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

よって、上記した通信システムでは、ゲートウェイと各センサノードとの一対一の無線通信によってプログラムデータの配信が行われる。

【0008】

したがって、プログラムの更新対象となるセンサノードの数が多いと、全てのセンサノードに対するプログラム更新が完了するまでに時間が掛るという問題が生じる。特に、送信時間総和に制限がある通信帯域を使用する通信システムでは、プログラム更新に費やされる延べ時間が長大となるので、更新用プログラムデータの送信元のゲートウェイにおいて通信効率が低下する。

【0009】

そこで、本発明は、複数の通信端末に対して、その台数に拘らずプログラムの更新を迅速に行うことが可能な通信システム及びプログラム更新方法を提供することを目的とする。

【課題を解決するための手段】

【0010】

本発明に係る通信システムは、夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムであって、前記複数の通信端末の各々は、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号を前記ホスト装置から受信した場合には、前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してからスタートリクエスト信号を前記ホスト装置に送信し、データ要求を行う権利を付与する許可信号を前記ホスト装置から受信した場合にはデータリクエスト信号を前記ホスト装置に送信し、前記ホスト装置は、前記配信準備完了信号をブロードキャスト送信し、その後、前記複数の通信端末のうちで最も早く前記スタートリクエスト信号を送信した１つの通信端末に前記許可信号を送信し、前記データリクエスト信号の受信に応じて前記更新用プログラムデータを前記複数の通信端末にブロードキャスト送信する。

【0011】

また、本発明に係る通信システムは、夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムであって、前記複数の通信端末の各々は、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号を前記ホスト装置から受信した場合には、前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してからスタートリクエスト信号を前記ホスト装置に送信し、データ要求を行う権利を付与する許可信号を前記ホスト装置から受信した場合にはデータリクエスト信号を前記ホスト装置に送信し、前記ホスト装置は、前記複数の通信端末をｎ（ｎは２以上の整数）個のグループに区分けした際の所望の１つの前記グループに属する前記通信端末の各々にだけ前記配信準備完了信号をエニーキャスト送信し、その後、最も早く前記スタートリクエスト信号を送信した１つの通信端末に前記許可信号を送信し、前記データリクエスト信号の受信に応じて前記更新用プログラムデータを前記１つの前記グループに属する前記通信端末の各々にだけエニーキャスト送信する。

【0012】

本発明に係るプログラム更新方法は、夫々が情報通信を担うプログラムデータが格納されているメモリを有する複数の通信端末と、前記複数の通信端末と通信を行うホスト装置と、を有する通信システムのプログラム更新方法であって、前記ホスト装置が、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号をブロードキャストにて送信し、前記配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してから前記複数の通信端末の各々がスタートリクエスト信号を前記ホスト装置に送信し、前記複数の通信端末のうちで最も早く前記スタートリクエスト信号を送信した１つの通信端末に対して、前記ホスト装置が、データ要求を行う権利を付与する許可信号を送信し、前記許可信号の受信に応じて前記１つの通信端末がデータリクエスト信号を前記ホスト装置に送信し、前記データリクエスト信号の受信に応じて前記ホスト装置が前記更新用プログラムデータを前記複数の通信端末にブロードキャスト送信する。

【発明の効果】

【0013】

本発明に係る通信システムでは、複数の通信端末の各々に格納されているプログラムを更新するにあたり、ホスト装置が、先ず、配信準備完了信号をブロードキャスト送信する。この配信準備完了信号の受信に応じて複数の通信端末の各々がスタートリクエスト信号をホスト装置に送信する。ホスト装置は、ホスト装置が最も早くスタートリクエスト信号を受信した１つの通信端末に対して、データ要求を行う権利を付与する許可信号を送信する。当該１つの通信端末は、許可信号の受信に応じてデータリクエスト信号をホスト装置に送信する。ホスト装置は、このデータリクエスト信号の受信に応じて更新用プログラムデータを複数の通信端末にブロードキャスト送信する。

【0014】

よって、本発明によれば、ホスト装置が複数の通信端末の各々との一対一の通信によって更新用プログラムデータの配信を行う場合に比べて短い期間でプログラム更新を完了することが可能となる。

【図面の簡単な説明】

【0015】

【図1】本発明に係る通信システム１００の構成を示すブロック図である。

【図2】通信端末１０ａ～１０ｆ各々の内部構成を示すブロック図である。

【図3】メモリ１０１のメモリマップの一部を示す図である。

【図4】ホスト装置３０が実行するプログラム配信処理を示すフローチャートである。

【図5】通信端末１０ａ～１０ｆ各々のＭＣＵ１０２が実行するプログラム更新処理を示すフローチャートである。

【図6】トリガールーチンを示すフローチャートである。

【図7】ネゴシエーションルーチンを示すフローチャートである。

【図8】アクティブ書換ルーチンを示すフローチャートである。

【図9】パッシブ書換ルーチンを示すフローチャートである。

【図10】終了ルーチンを示すフローチャートである。

【図11】プログラムの更新時にホスト装置３０及び通信端末１０ａ～１０ｆ間で行われる通信の手順を示す通信フロー図である。

【図12】リセット対応ルーチンを示すフローチャートである。

【図13A】通信エラー発生時における通信端末１０ａ～１０ｃ各々のユーザ領域ＵＳＲ内の更新用プログラムデータの第１段階での更新形態の一例を表す図である。

【図13B】通信エラー発生時における通信端末１０ａ～１０ｃ各々のユーザ領域ＵＳＲ内の更新用プログラムデータの第２段階での更新形態の一例を表す図である。

【図13C】通信エラー発生時における通信端末１０ａ～１０ｃ各々のユーザ領域ＵＳＲ内の更新用プログラムデータの第３段階での更新形態の一例を表す図である。

【図14】本発明に係る他の一例である通信システム２００の構成を示すブロック図である。

【発明を実施するための形態】

【0016】

以下、本発明の実施例を図面を参照しつつ詳細に説明する。

【0017】

図１は、本発明に係る通信システム１００の構成を示すブロック図である。図１に示す通信システム１００は、互いに同一構成の通信端末１０ａ～１０ｆと、これら通信端末１０ａ～１０ｆと通信を行うホスト装置３０と、を有する。

【0018】

通信端末１０ａ～１０ｆの各々は、例えば工場に備えられている各種の製造装置、或いは建造物の壁、床、又は天井等に設置される。また、通信端末１０ａ～１０ｆの各々を、例えば人又は動物等に携帯、或いは車両、船舶、航空機等の移動体に搭載しても良い。通信端末１０ａ～１０ｆは同一の内部構成を有し、夫々に内蔵されているプログラムに従って動作する。尚、通信端末１０ａ～１０ｆは、ホスト装置３０から無線送信された更新用プログラムデータによって、自身に格納されているプログラムの更新を行う機能を有する。

【0019】

図２は、通信端末１０ａ～１０ｆ各々の内部構成の一例を示すブロック図である。

【0020】

通信端末１０ａ～１０ｆの各々は、メモリ１０１、マイクロコントローラ１０２（以下、ＭＣＵ１０２と称する）、センサ１０４、送受信部１０５及びアンテナ１１０を有する。

【0021】

メモリ１０１は、例えばＮＡＮＤ型フラッシュメモリ等の不揮発性メモリである。

【0022】

図３は、メモリ１０１のメモリマップの一例を示す図である。メモリ１０１には、予め、自身の識別番号、通信チャネル番号、及びホスト装置３０のアドレスを示すホストアドレスが記憶されている。また、メモリ１０１には、ＭＣＵ１０２により、プログラム更新に必要となる情報として、プログラムの更新処理中であるか否かを表す更新状態フラグＦｕｐ、及びプログラム書換中のセクタ番号を示す書換中セクタ番号ＳＮが書き込まれる。メモリ１０１に記憶されている各種情報は、必要に応じてＭＣＵ１０２によって読み出される。

【0023】

乱数生成器１０３は、乱数を生成してこれをＭＣＵ１０２に供給する。

【0024】

センサ１０４は、例えば、振動、温度、湿度、気圧、照度、紫外線、音圧、又は地磁気等の自然現象や人工物の機械的、電磁気的、熱的、音響的、又は化学的な性質を物理量で検知し、検知した物理量を表す検知情報をＭＣＵ１０２に供給する。

【0025】

ＭＣＵ１０２は、プログラムメモリＰＭ及びタイマＴＭを内蔵している。

【0026】

タイマＴＭは、プログラム実行時における処理の待機時間、又はタイムアウト時間等を計測する。また、タイマＴＭは、乱数生成器１０３で生成された乱数に基づく時間をランダム時間として設定し、当該ランダム時間の計時を行う。

【0027】

プログラムメモリＰＭは、データ書換が可能な領域であるユーザ領域ＵＳＲと、データ書換が不許可な領域であるシステム領域ＳＹＳと、を有する。ユーザ領域ＵＳＲには、通信端末１０の主機能を担うメインプログラムを表すプログラムデータが格納されている。システム領域ＳＹＳには、メインプログラムの更新を行うための更新用プログラム、無線通信を担うプログラム及びＩＰＬ（Initial Program Loader）等が格納されている。

【0028】

ＭＣＵ１０２は、電源投入に応じて上記したＩＰＬを実行して自身の初期化を行った後、引き続きユーザ領域ＵＳＲに格納されているメインプログラムに従った制御を実行する。

【0029】

また、ＭＣＵ１０２は、送受信部１０５から配信準備完了信号を受けると、プログラムメモリＰＭのシステム領域ＳＹＳに格納されている更新用プログラムを読み出し、これを実行することでプログラムデータの更新状態に遷移する（プログラム更新処理）。

【0030】

当該プログラム更新処理により、ＭＣＵ１０２は、通信時の応答、承認、又は要求等を表す各種の通信信号を受信又は送信させるように送受信部１０５を制御する。この際、送受信部１０５によって受信した更新用プログラムデータを受けた場合には、ＭＣＵ１０２は、この更新用プログラムデータで、プログラムメモリＰＭのユーザ領域ＵＳＲに格納されているメインプログラムを書き換える。

【0031】

送受信部１０５は、ＭＣＵ１０２の制御により、例えば９２０ＭＨｚ帯テレメータ用の搬送波信号を、上記した検知情報を含む端末データで変調した変調信号をアンテナ１１０を介してホスト装置３０に無線送信する。

【0032】

また、送受信部１０５は、ＭＣＵ１０２の制御により、ホスト装置３０から無線送信された９２０ＭＨｚ帯テレメータ用の電波に対応した高周波信号をアンテナ１１０を介して受ける。そして、送受信部１０５は、当該高周波信号に復調処理を施すことで、ホスト装置３０から送信された各種通信信号、及び更新用プログラムデータを取得する。

【0033】

上記した構成により、通信端末１０ａ～１０ｆの各々は、自身に搭載されているセンサ１０４で検知した検知情報を含む端末データをホスト装置３０に無線送信する。また、通信端末１０ａ～１０ｆの各々は、ホスト装置３０から無線送信された更新用プログラムデータを受信した場合に、この更新用プログラムデータで、自身のプログラムメモリＰＭに格納されているメインプログラムを書き換える。

【0034】

ホスト装置３０は、通信端末１０ａ～１０ｆの各々から無線送信された端末データから検知情報を抽出し、通信端末１０ａ～１０ｆに夫々対応した検知情報を収集した検知情報群を、例えばインターネット等の通信ネットワークＮＷに送出する。

【0035】

更に、ホスト装置３０は、通信システム１００の管理者からのプログラム更新要求に応じて、プログラム配信処理を実行する。これにより、ホスト装置３０は、例えば９２０ＭＨｚ帯テレメータ用の搬送波信号を、通信時の応答、承認、又は要求等を表す各種の通信信号、又は更新用プログラムデータで変調した変調信号を無線送信する。

【0036】

以下に、ホスト装置３０で実施されるプログラム配信処理、及び通信端末１０ａ～１０ｆの各々で行われるプログラム更新処理について詳細に説明する。
［ホスト装置３０のプログラム配信処理］
図４は、ホスト装置３０で実行されるプログラム配信処理の手順を示すフローチャートである。

【0037】

図４において、ホスト装置３０は、先ず、プログラムの配信準備が完了したことを示す配信準備完了信号を、通信端末１０ａ～１０ｆに対してブロードキャストにて無線送信する（ステップＳ１１）。

【0038】

次に、ホスト装置３０は、スタートリクエスト信号Ｓｒｑの受信待ち状態となり、スタートリクエスト信号Ｓｒｑを受信した場合に、スタートリクエスト信号Ｓｒｑの送信元の通信端末に、承認を表すアクノリッジ信号（以下、ＡＣＫと称する）を無線送信する（ステップＳ１２）。

【0039】

次に、ホスト装置３０は、ステップＳ１２において最初に受信したスタートリクエスト信号Ｓｒｑの送信元の通信端末１０に、アクティブＯＫ信号を無線送信する（ステップＳ１３）。尚、アクティブＯＫ信号は、ホスト装置３０に対してデータ要求を行う権利を付与する許可信号である。ここで、ホスト装置３０は、当該スタートリクエスト信号Ｓｒｑの送信元の通信端末から無線送信されたＡＣＫを受信した場合に、このＡＣＫの送信元の通信端末をアクティブ端末として設定し、以下のステップＳ１４の実行に移行する。

【0040】

ホスト装置３０は、データリクエスト信号Ｄｒｑの受信待ち状態となり、データリクエスト信号Ｄｒｑを受信した場合に、このデータリクエスト信号Ｄｒｑの送信元の通信端末に、ＡＣＫを無線送信する（ステップＳ１４）。尚、ホスト装置３０は、この間、所定のタイムアウト時間が経過する前にデータリクエスト信号Ｄｒｑを受信できなかった場合には、アクティブ端末の設定を解除し、引き続き上記ステップＳ１２の実行に戻り、アクティブ端末の設定をやり直す。

【0041】

ステップＳ１４の実行後、ホスト装置３０は、受信したデータリクエスト信号Ｄｒｑに付随する書換アドレス情報に対応した１パケット分の更新用プログラムデータを、当該書換アドレス情報と共にブロードキャストにて無線送信する（ステップＳ１５）。尚、書換アドレス情報とは、各通信端末のプログラムメモリＰＭのユーザ領域ＵＳＲ内における更新用プログラムデータの書き込み先のアドレスを示す情報である。

【0042】

ステップＳ１５の実行後、ホスト装置３０は、書換アドレス情報にて示されるアドレスが、更新用プログラムデータにおける最後の１パケット分が書き込まれるユーザ領域ＵＳＲの最終アドレスであるか否かを判定する（ステップＳ１６）。ステップＳ１６において最終アドレスでないと判定された場合、ホスト装置３０は、上記したステップＳ１４の実行に戻る。

【0043】

よって、上記したステップＳ１４～Ｓ１６からなる一連の処理を繰り返し実行することで、ホスト装置３０は、更新用プログラムデータを１パケット分ずつ順に、ブロードキャスト送信する。

【0044】

そして、ステップＳ１６において最終アドレスであると判定された場合、ホスト装置３０は、このプログラム配信処理を終了する。
［通信端末１０ａ～１０ｆ各々のプログラム更新処理］
通信端末１０ａ～１０ｆ各々のＭＣＵ１０２は、ホスト装置３０がブロードキャストにて無線送信した配信準備完了信号を受信すると、プログラムメモリＰＭのシステム領域に格納されている更新処理用プログラムを読み出す。そして、ＭＣＵ１０２は、当該更新処理用プログラムに従ったプログラム更新処理を実行する。

【0045】

図５は、プログラム更新処理の手順を示すフローチャートである。図５に示すように、ＭＣＵ１０２は、トリガールーチンＳ３００、ネゴシエーションルーチンＳ４００、アクティブ書換ルーチンＳ５００（又はパッシブ書換ルーチンＳ７００）、及び終了ルーチンＳ８００を順に実行する。

【0046】

図６は、トリガールーチンＳ３００を示すフローチャートである。

【0047】

図６において、先ず、ＭＣＵ１０２は、プログラムメモリＰＭのユーザ領域ＵＳＲに格納されているプログラムデータを消去する（ステップＳ３１）。次に、ＭＣＵ１０２は、タイマＴＭにより、乱数生成器１０３で生成された乱数に基づくランダム時間の分だけ待機してから（ステップＳ３２）、次のネゴシエーションルーチンＳ４００の実行に移る。

【0048】

図７は、ネゴシエーションルーチンＳ４００を示すフローチャートである。

【0049】

図７において、ＭＣＵ１０２は、先ず、送受信部１０５を制御することでスタートリクエスト信号Ｓｒｑをホスト装置３０に無線送信させる（ステップＳ４１）。ここで、上記したように各通信端末１０とホスト装置３０との間の無線通信は、実際にはＭＣＵ１０２が送受信部１０５を制御することによって行う。しかしながら、以降、記載を簡略化する為に送受信部１０５の動作を省略し、ＭＣＵ１０２が直にホスト装置３０との無線通信（送信、受信）を行うような形態で記載を行う。

【0050】

図６に示すトリガールーチンのステップＳ３２及び上記ステップＳ４１の実行により、ＭＣＵ１０２は、配信準備完了信号の受信後、乱数に基づくランダムな時間だけ待機してからスタートリクエスト信号Ｓｒｑをホスト装置３０に無線送信する。

【0051】

次に、ＭＣＵ１０２は、所定の初期値からタイマＴＭの計時を開始させる（ステップＳ４２）。ステップＳ４２の実行後、ＭＣＵ１０２は、ＡＣＫを受信したか否かを判定する（ステップＳ４３）。ステップＳ４３においてＡＣＫを受信したと判定された場合、ＭＣＵ１０２は、次に、データ要求を行う権利を付与する許可信号としてのアクティブＯＫ信号を受信したか否かを判定する（ステップＳ４４）。ステップＳ４４においてアクティブＯＫ信号を受信したと判定された場合、ＭＣＵ１０２は、ＡＣＫをホスト装置３０に無線送信する（ステップＳ４５）。次に、ＭＣＵ１０２は、タイマＴＭにより所定時間だけ待機してから（ステップＳ４６）、アクティブ書換ルーチンＳ５００の実行に移る。

【0052】

一方、上記ステップＳ４３でＡＣＫを受信していないと判定された場合、又は上記ステップＳ４４でアクティブＯＫ信号を受信していないと判定された場合、ＭＣＵ１０２は、タイマＴＭの計時時間が所定時間を経過したか否かを判定する（ステップＳ４７）。ステップＳ４７において所定時間を経過していないと判定された場合、ＭＣＵ１０２は、上記したステップＳ４３の実行に戻る。

【0053】

ステップＳ４７において所定時間を経過したと判定された場合、ＭＣＵ１０２は、パッシブ書換ルーチンＳ７００の実行に移る。すなわち、スタートリクエスト信号Ｓｒｑを送信したものの、ホスト装置３０からアクティブＯＫ信号を受けることができなかった、又はスタートリクエスト信号Ｓｒｑの送信自体が失敗した通信端末１０のＭＣＵ１０２は、パッシブ書換ルーチンＳ７００の実行に移る。

【0054】

図８は、アクティブ書換ルーチンＳ５００を示すフローチャートである。

【0055】

図８において、ＭＣＵ１０２は、メモリ１０１に記憶されている更新状態フラグＦｕｐとして、プログラムの更新処理中であることを示す論理レベル１を書き込む（ステップＳ５０）。更に、当該ステップＳ５０において、ＭＣＵ１０２は、更新用プログラムデータが書き込まれるユーザ領域ＵＳＲ内の先頭アドレスを示す書換アドレス情報を生成する。

【0056】

次に、ＭＣＵ１０２は、書換アドレス情報及びデータリクエスト信号Ｄｒｑをホスト装置３０に無線送信する（ステップＳ５１）。次に、ＭＣＵ１０２は、ＡＣＫを受信したか否かを判定する（ステップＳ５２）。ステップＳ５２においてＡＣＫを受信したと判定された場合、ＭＣＵ１０２は、更新用プログラムデータを受信したか否かを判定する（ステップＳ５３）。

【0057】

上記したステップＳ５２にてＡＣＫを受信していないと判定、又はステップＳ５３にて更新用プログラムデータを受信していないと判定された場合、ＭＣＵ１０２は、タイマＴＭの計時時間が所定のタイムアウト時間を経過したか否かを判定する（ステップＳ５４）。すなわち、ステップＳ５４においてＭＣＵ１０２は、上記したステップＳ４１でスタートリクエスト信号Ｓｒｑを送信してからタイムアウト時間が経過したか否かを判定する。

【0058】

ステップＳ５４においてタイムアウト時間が経過したと判定された場合、ＭＣＵ１０２は、図７に示すネゴシエーションルーチンのステップＳ４１の実行に戻る。すなわち、ＭＣＵ１０２は、スタートリクエスト信号Ｓｒｑを再びホスト装置３０に送信する再送信を行う。

【0059】

一方、ステップＳ５４においてタイムアウト時間を経過していないと判定された場合、ＭＣＵ１０２は、上記したステップＳ５２の実行に戻る。

【0060】

ここで、上記ステップＳ５３で更新用プログラムデータを受信したと判定された場合、ＭＣＵ１０２は、当該更新用プログラムデータに付随する書換アドレス情報と、ステップＳ５１でデータリクエスト信号Ｄｒｑと共に無線送信した書換アドレス情報とが一致しているか否かを判定する（ステップＳ５５）。ステップＳ５５において、書換アドレス情報同士が一致していないと判定した場合、ＭＣＵ１０２は、上記ステップＳ５１の実行に戻る。また、ステップＳ５５において書換アドレス情報同士が一致していると判定された場合、ＭＣＵ１０２は、その書換アドレス情報がプログラムメモリＰＭのセクタの先頭アドレスを示すか否かを判定する（ステップＳ５６）。

【0061】

ステップＳ５６において、書換アドレス情報がセクタの先頭アドレスを示すと判定された場合、ＭＣＵ１０２は、このセクタを示すセクタ番号を図３に示す書換中セクタ番号ＳＮとしてメモリ１０１に上書きする（ステップＳ５７）。

【0062】

ステップＳ５７の実行後、又はステップＳ５６にて書換アドレス情報がセクタの先頭アドレスを示していないと判定された場合、ＭＣＵ１０２は、プログラムメモリＰＭのユーザ領域ＵＳＲにおける書換アドレス情報にて示される位置に、受信した１パケット分の更新用プログラムデータを書き込む（ステップＳ５８）。次に、ＭＣＵ１０２は、この書換アドレス情報が上記した最終アドレスを示すか否かを判定する（ステップＳ５９）。ステップＳ５９において書換アドレス情報が最終アドレスを示していないと判定された場合、ＭＣＵ１０２は、この書換アドレス情報にて示されるアドレスの値を、ユーザ領域ＵＳＲ内の次の書き込み位置を表す値にインクリメントする（ステップＳ６０）。ステップＳ６０の実行後、ＭＣＵ１０２は、上記ステップＳ５１の実行に戻る。

【0063】

また、上記ステップＳ５９において、書換アドレス情報が最終アドレスを示すと判定されると、ＭＣＵ１０２は、このアクティブ書換ルーチンを抜けて、次の終了ルーチンＳ８００の実行に移る。

【0064】

図９は、パッシブ書換ルーチンＳ７００を示すフローチャートである。

【0065】

図９において、ＭＣＵ１０２は、メモリ１０１に記憶されている更新状態フラグＦｕｐとして、プログラムの更新処理中であることを示す論理レベル１を書き込む（ステップＳ７０）。更に、当該ステップＳ７０において、ＭＣＵ１０２は、更新用プログラムデータが書き込まれるユーザ領域ＵＳＲ内の先頭アドレスを示す書換アドレス情報を生成する。

【0066】

次に、ＭＣＵ１０２は、更新用プログラムデータを受信したか否かを判定する（ステップＳ７１）。

【0067】

上記ステップＳ７１にて更新用プログラムデータを受信していないと判定された場合、ＭＣＵ１０２は、タイマＴＭの計時時間が所定のタイムアウト時間を経過したか否かを判定する（ステップＳ７２）。すなわち、ステップＳ７２において、ＭＣＵ１０２は、上記したステップＳ４１でスタートリクエスト信号Ｓｒｑを送信してからタイムアウト時間が経過したか否かを判定する。

【0068】

ステップＳ７２においてタイムアウト時間を経過したと判定された場合、ＭＣＵ１０２は、図７に示すネゴシエーションルーチンのステップＳ４１の実行に戻る。すなわち、ＭＣＵ１０２は、スタートリクエスト信号Ｓｒｑを再びホスト装置３０に送信する再送信を行う。

【0069】

一方、ステップＳ７２においてタイムアウト時間を経過していないと判定された場合、ＭＣＵ１０２は、上記したステップＳ７１の実行に戻る。

【0070】

ステップＳ７１において更新用プログラムデータを受信したと判定された場合、ＭＣＵ１０２は、当該更新用プログラムデータに付随する書換アドレス情報と、自身で生成した書込アドレス情報とが一致しているか否かを判定する（ステップＳ７３）。

【0071】

ステップＳ７３において書換アドレス情報同士が一致していると判定された場合、ＭＣＵ１０２は、その書換アドレス情報がプログラムメモリＰＭのセクタの先頭アドレスを示すか否かを判定する（ステップＳ７４）。

【0072】

ステップＳ７４において、書換アドレス情報がセクタの先頭アドレスを示すと判定された場合、ＭＣＵ１０２は、このセクタを示すセクタ番号を図３に示す書換中セクタ番号ＳＮとしてメモリ１０１に書き込む（ステップＳ７５）。

【0073】

ステップＳ７５の実行後、又はステップＳ７４にて書換アドレス情報がセクタの先頭アドレスを示していないと判定された場合、ＭＣＵ１０２は、プログラムメモリＰＭのユーザ領域ＵＳＲにおける書換アドレス情報にて示される位置に、受信した１パケット分の更新用プログラムデータを書き込む（ステップＳ７６）。

【0074】

次に、ＭＣＵ１０２は、この書換アドレス情報が最終アドレスを示すか否かを判定する（ステップＳ７７）。ステップＳ７７において書換アドレス情報が最終アドレスを示していないと判定された場合、ＭＣＵ１０２は、この書換アドレス情報にて示されるアドレスの値を、ユーザ領域ＵＳＲ内の次の書き込み位置を表す値にインクリメントする（ステップＳ７８）。ステップＳ７８の実行後、ＭＣＵ１０２は、上記ステップＳ７１の実行に戻る。

【0075】

また、上記ステップＳ７７において、書換アドレス情報が最終アドレスを示すと判定されると、更新用プログラムデータによるプログラムの更新が完了するので、ＭＣＵ１０２は、このパッシブ書換ルーチンを抜けて、次の終了ルーチンＳ８００の実行に移る。

【0076】

図１０は、終了ルーチンＳ８００を示すフローチャートである。

【0077】

図１０において、ＭＣＵ１０２は、メモリ１０１に記憶されている更新状態フラグＦｕｐをプログラムの更新処理中ではないことを示す論理レベル０、書換中セクタ番号ＳＮを初期値としての０に夫々書き換える（ステップＳ８０）。ステップＳ８０の実行後、ＭＣＵ１０２は、タイマＴＭにより、乱数生成器１０３で生成された乱数に基づくランダム時間の分だけ待機（ステップＳ８１）してから、ソフトウェアリセットを行う（ステップＳ８２）。

【0078】

以下に、上記したホスト装置３０のプログラム配信処理、及び通信端末１０ａ～１０ｆ各々のプログラム更新処理によって行われる通信動作について、図１１に示す通信フローに沿って説明する。

【0079】

図１１に示すように、プログラムの更新は、以下のトリガステップＴＲＧ、ネゴシエーションステップＮＥＧ、アクティブ書換ステップＷＴａ又はパッシブ書換ステップＷＴｐ、及び終了ステップＥＮＸの順に行われる。

【0080】

尚、図１１では、通信端末１０ａ～１０ｆのうちの通信端末１０ａと、その他の通信端末１０ｂ～１０ｆと、ホスト装置３０と、に分けて各通信端末とホスト装置間の通信動作の一例を示している。

【0081】

［トリガステップＴＲＧ］
まず、ホスト装置３０が、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号を、ブロードキャストにて無線送信する。通信端末１０ａ～１０ｆは、配信準備完了信号を受信すると、夫々個別に図６に示すトリガールーチンを実行する。これにより、通信端末１０ａ～１０ｆの各々は、自身のプログラムメモリＰＭのユーザ領域ＵＳＲに格納されているデータ、つまりプログラムデータを全て消去する（Ｓ３１）。このデータ消去が終了すると、通信端末１０ａ～１０ｆは、夫々の乱数生成器１０３で生成された乱数に基づくランダム時間だけ待機（Ｓ３２）してから、次のネゴシエーションステップＮＥＧの処理に移行する。

【0082】

尚、図１１に示す一例では、通信端末１０ａでのランダム時間ｔａは、通信端末１０ｂ～１０ｆのランダム時間ｔｂ～ｔｆよりも短い。

【0083】

［ネゴシエーションステップＮＥＧ］
通信端末１０ａ～１０ｆは個別に、自身のユーザ領域ＵＳＲに格納されているデータの消去が完了してから、夫々のランダム時間ｔａ～ｔｆが経過した時点で、スタートリクエスト信号Ｓｒｑをホスト装置３０に無線送信する（Ｓ４１）。ホスト装置３０は、スタートリクエスト信号Ｓｒｑを受信した場合に、このスタートリクエスト信号Ｓｒｑの送信元の通信端末１０に対してＡＣＫを無線送信する（Ｓ１２）。ここで、ホスト装置３０は、配信準備完了信号の送信（Ｓ１１）の終了後、或いはアクティブ端末としての設定を解除した後で、最初にスタートリクエスト信号Ｓｒｑを送信した通信端末１０を、アクティブ端末として設定（Ｓ１３）する。そして、この通信端末１０に対して、データ要求を行う権利を付与する許可信号であるアクティブＯＫ信号を無線送信する（Ｓ１３）。この際、アクティブＯＫ信号を受信した通信端末１０は、ＡＣＫをホスト装置３０に無線送信する（Ｓ４５）。

【0084】

尚、図１１に示す一例では、前述したように通信端末１０ａ～１０ｆのうちで１０ａが最も早くスタートリクエスト信号Ｓｒｑを送信する。よって、この際、ホスト装置３０は、図１１に示すように、通信端末１０ａ～１０ｆのうちの１０ａのみにアクティブＯＫ信号を無線送信する。

【0085】

ここで、アクティブＯＫ信号を受信した通信端末、つまりアクティブ端末に設定された通信端末１０ａは、所定時間待機（Ｓ４６）した後、アクティブ書換ステップＷＴａの処理に移行する。一方、所定時間内にアクティブＯＫ信号を受信しなかったと判定（Ｓ４４、Ｓ４７）された通信端末、及びスタートリクエスト信号Ｓｒｑの送信に失敗した通信端末、つまり通信端末１０ｂ～１０ｆは、パッシブ書換ステップＷＴｐの処理に移行する。
［アクティブ書換ステップＷＴａ］
アクティブＯＫ信号を受信した通信端末１０ａは、先ず、ユーザ領域ＵＳＲ内に、更新用プログラムデータの１パケット分を書き込む為のアドレスを示す書換アドレス情報を含むデータリクエスト信号Ｄｒｑをホスト装置３０に無線送信する（Ｓ５１）。ホスト装置３０は、当該データリクエスト信号Ｄｒｑを受信すると、先ず、承認を表すＡＣＫをデータリクエスト信号Ｄｒｑの送信元の通信端末１０ａに無線送信する（Ｓ１４）。そして、ホスト装置３０は、上記した書換アドレス情報に示されるアドレスに対応した１パケット分の更新用プログラムデータ（書換アドレス情報を含む）を、ブロードキャストにて通信端末１０ａ～１０ｆに無線送信する（Ｓ１５）。

【0086】

この更新用プログラムデータ（書換アドレス情報を含む）を受信した通信端末１０ａは、ユーザ領域ＵＳＲ内のセクタの先頭でデータ書換中であることを記録する為に、そのセクタ番号表す書換中セクタ番号ＳＮを、メモリ１０１に書き込む（Ｓ５７）。そして、通信端末１０ａは、ユーザ領域ＵＳＲ内における書換アドレス情報にて示されるアドレスに、受信した１パケット分の更新用プログラムデータを書き込む（Ｓ５８）。
［パッシブ書換ステップＷＴｐ］
一方、アクティブＯＫ信号を受信しなかった通信端末１０ｂ～１０ｆは、上記したネゴシエーションステップＮＥＧの終了後、更新用プログラムデータの受信待ち（Ｓ７１、Ｓ７２）となる。ここで、更新用プログラムデータ（書換アドレス情報を含む）を受信した通信端末１０ｂ～１０ｆの各々は、通信端末１０ａと同様に、自身のユーザ領域ＵＳＲ内のセクタの先頭でデータ書換中であることを記録する為に、そのセクタ番号表す書換中セクタ番号ＳＮを、メモリ１０１に書き込む（Ｓ７５）。そして、通信端末１０ｂ～１０ｆの各々は、自身のユーザ領域ＵＳＲ内における書換アドレス情報にて示されるアドレスに、受信した１パケット分の更新用プログラムデータを書き込む（Ｓ７６）
当該パッシブ書換ステップＷＴｐ及びアクティブ書換ステップＷＴａでは、上記した一連の処理、つまり図１１において破線にて囲まれた書込処理ＷＤを、書換アドレス情報にて示されるアドレスが最終アドレスに到るまで繰り返し実行する。これにより、更新用プログラムデータの全てが１パケット分ずつ順に、通信端末１０ａ～１０ｆ各々のプログラムメモリＰＭのユーザ領域ＵＳＲに書き込まれて行く。

【0087】

ここで、上記したパッシブ書換ステップＷＴｐ及びアクティブ書換ステップＷＴａでの更新用プログラムデータの書き込みが完了すると、通信端末１０ａ～１０ｆは、終了ステップＥＮＸの処理に移行する。
［終了ステップＥＮＸ］
通信端末１０ａ～１０ｆの各々は、更新状態フラグＦｕｐをプログラムの更新処理中ではないことを示す論理レベル０、書換中セクタ番号ＳＮを初期値としての０に夫々リセット（Ｓ８０）すると共に、ソフトウェアリセット（Ｓ８２）を行う。

【0088】

上記したように、通信システム１００では、ホスト装置３０が、更新用プログラムデータを全ての通信端末１０ａ～１０ｆに対してブロードキャストにて無線送信する。よって、ホスト装置３０が通信端末１０ａ～１０ｆに対して一対一の通信で順次、更新用プログラムデータの配信を行う場合に比べて短い期間でプログラム更新を完了することが可能となる。

【0089】

尚、上記した実施例では、通信システム１００に含まれる通信端末は１０ａ～１０ｆの６個であるが、少なくとも２つ以上の複数であれば良い。また、上記実施例では、ホスト装置及３０と、通信端末１０ａ～１０ｆ各々との間の通信を無線で行っているが有線通信で行っても良い。

【0090】

要するに、通信システム１００としては、夫々が情報通信を担うプログラムデータが格納されているメモリ（ＰＭ）を有する複数の通信端末（１０ａ～１０ｆ）と、ホスト装置（３０）とを含むものであれば良い。複数の通信端末の各々は、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号をホスト装置から受信した場合に、スタートリクエスト信号（Ｓｒｑ）をホスト装置（３０）に送信する（Ｓ４１）。更に、複数の通信端末（１０ａ～１０ｆ）の各々は、データ要求を行う権利を付与する許可信号（アクティブＯＫ信号）をホスト装置から受信（Ｓ４４）した場合にはデータリクエスト信号（Ｄｒｑ）をホスト装置に送信する（Ｓ５１）。

【0091】

ホスト装置（３０）は、上記した配信準備完了信号をブロードキャスト送信し（Ｓ１１）。その後、複数の通信端末のうちで最も早くスタートリクエスト信号（Ｓｒｑ）を送信した１つの通信端末に、上記した許可信号（アクティブＯＫ信号）を送信する（Ｓ１３）。その後、ホスト装置は、データリクエスト信号（Ｄｒｑ）の受信（Ｓ１４）に応じて、更新用プログラムデータをブロードキャスト送信する（Ｓ１５）。

【0092】

尚、通信システム１００では、プログラム更新処理途中における、不慮のリセット、バッテリ残量不足等に伴う電源遮断、或いは通信エラーへの対処を行っている。
［リセット発生又は電源遮断時の対処］
例えば、プログラム更新処理途中でリセットが生じた場合、通信端末１０ａ～１０ｆ各々のＭＣＵ１０２は、リセット処理後、プログラムメモリＰＭのシステム領域ＳＹＳに格納されている更新処理プログラム中のリセット対応ルーチンを実行する。また、ＭＣＵ１０２は、プログラム更新処理途中に電源遮断が生じた場合にも、その後の電源投入に応じて、このリセット対応ルーチンを実行する。

【0093】

図１２は、リセット対応ルーチンを示すフローチャートである。

【0094】

図１２において、先ず、ＭＣＵ１０２は、図３に示すようにメモリ１０１に書き込まれている内容を読み出す（ステップＳ９０）。次に、ＭＣＵ１０２は、図３に示す更新状態フラグＦｕｐが、プログラムの更新処理中であることを示す論理レベル１であるか否かを判定する（ステップＳ９１）。ステップＳ９１において更新状態フラグＦｕｐが論理レベル１ではないと判定された場合には、プログラム更新中のリセットではないので、ＭＣＵ１０２は、このリセット対応ルーチンを抜けてメインプログラムの動作に戻る。一方、更新状態フラグＦｕｐが論理レベル１である場合には、プログラム更新中のリセットであるため、書き込み途中のセクタには更新用プログラムデータの一部が書き込まれていない虞がある。

【0095】

そこで、ステップＳ９１で更新状態フラグＦｕｐが論理レベル１であると判定された場合、ＭＣＵ１０２は、図３に示す書換中セクタ番号ＳＮにて示されるユーザ領域ＵＳＲ内のセクタに対してデータの消去処理を施す（ステップＳ９２）。次に、ＭＣＵ１０２は、乱数生成器１０３で生成された乱数に基づくランダム時間の分だけ待機し（ステップＳ９３）、引き続き図７に示すネゴシエーションルーチンの実行に移る。

【0096】

上記したリセット対応ルーチンの実行により、通信端末１０ａ～１０ｆの各々は、リセット後、そのリセットの発生時点で更新用プログラムデータの書き込み対象となっていたセクタに対して、更新用プログラムデータの再書き込みが行われる。

【0097】

これにより、プログラムの更新途中でリセット又は電源遮断が生じても、プログラムの更新を正しく行うことが可能となる。
［通信エラー発生時の対処］
一時的に通信エラーが生じると、その間、通信端末１０ａ～１０ｆは、更新用プログラムデータを受けることができなくなるが、その後、正常な通信が再開されると各通信端末１０ａ～１０ｆは、更新用プログラムデータの受信が可能となる。しかしながら、通信が正常化するまでにかかる時間が長くなる場合には、その間、ホスト装置３０側で繰り返し更新用プログラムデータの送信を実施しなければならない。よって、無効な通信を実施する期間が長くなることから、通信効率の低下及び電力消費量の増加を招く。また、送信時間総和が規定されている場合、ホスト装置３０は、更新用プログラムデータの送信に多くの時間を費やしてしまうので、他の用途を担う送信に割り当てる時間を確保できなくなるという、通信効率の低下を招く。

【0098】

そこで、各通信端末１０ａ～１０ｆは、更新用プログラムデータの受信待ちに対してタイムアウトを設定し（Ｓ５４、Ｓ７２）、タイムアウト時には図７に示すネゴシエーション処理の実行に戻る。これにより、図１１に示すネゴシエーションステップＮＥＧから、プログラム更新処理をやり直す。

【0099】

以下に、上記した処理による、通信エラー発生時のプログラム更新動作について説明する。

【0100】

図１３Ａは、通信エラー発生時の通信端末１０ａ～１０ｃ各々のユーザ領域ＵＳＲ内の書込状態（書込済：斜線、未書込：空白）の一例を表す図である。尚、図１３Ａでは、アクティブ端末として設定された通信端末１０ａでは、アクティブ書換（ＷＴａ）により自身のユーザ領域ＵＳＲ内に更新用プログラムデータの書き込みが完了している。しかしながら、通信エラーに伴い、通信端末１０ｂでは、自身のユーザ領域ＵＳＲ内のセクタＷ以降はデータ未書き込みであり、通信端末１０ｃでは、自身のユーザ領域ＵＳＲ内のセクタＪ以降はデータ未書き込みである。

【0101】

当該通信エラーの影響により、通信端末１０ｂ及び１０ｃでは、タイムアウトとなり（Ｓ７２）、再びネゴシエーションステップＮＥＧが実施される。よって、通信端末１０ｂ及び１０ｃは、スタートリクエスト信号Ｓｒｑを再びホスト装置３０に無線送信する（Ｓ４１）。

【0102】

ここで、通信端末１０ｂよりも１０ｃの方が先にスタートリクエスト信号Ｓｒｑをホスト装置３０に送信した場合、通信端末１０ｃがアクティブ端末として設定される。よって、当該通信端末１０ｃは、セクタＪの先頭アドレス以降の更新用プログラムデータを要求する為のアドレスを示す書換アドレス情報と共にデータリクエスト信号Ｄｒｑをホスト装置３０に無線送信する（Ｓ５１）。これに応じて、ホスト装置３０は、セクタＪの先頭アドレスに対応した更新用プログラムデータをブロードキャストにて無線送信する（Ｓ１５）。この際、通信端末１０ｃは、図１３Ｂに示すように、自身のユーザ領域ＵＳＲのセクタＪの先頭アドレスから、受信した更新用プログラムデータを書き込む（Ｓ５８）。

【0103】

一方、通信端末１０ｂは、受信した書換アドレス情報が、自身が所望とする書換アドレス（Ｗ）とは異なるので受信待ち状態となる（Ｓ７３、Ｓ７１）。この間、通信端末１０ｃにおいて、図１３Ｂに示すように更新用プログラムデータの書き込みが完了すると、更新用プログラムデータのブロードキャスト送信が行われなくなる。これにより、通信端末１０ｂでは、タイマＴＭの計時時間がクリアされないので、受信待ちがタイムアウトし（Ｓ７２）、再びネゴシエーションステップＮＥＧが実施される。よって、通信端末１０ｂは、スタートリクエスト信号Ｓｒｑをホスト装置３０に無線送信する（Ｓ４１）。これにより、通信端末１０ｃが新たなアクティブ端末として設定され、当該通信端末１０ｃは、セクタＷの先頭アドレス以降の更新用プログラムを要求する為のアドレスを示す書換アドレス情報と共にデータリクエスト信号Ｄｒｑをホスト装置３０に無線送信する（Ｓ５１）。これに応じて、ホスト装置３０は、セクタＷの先頭アドレスに対応した更新用プログラムをブロードキャストにて無線送信する（Ｓ１５）。よって、通信端末１０ｂは、図１３Ｃに示すように、自身のユーザ領域ＵＳＲのセクタＷの先頭アドレスから、受信した更新用プログラムを書き込む（Ｓ５８）。

【0104】

このように、各通信端末１０は、更新用プログラムの受信待ちに対してタイムアウト時間を設定し、プログラム更新処理中の通信エラーによってタイムアウトした場合には、アクティブ端末を決定するネゴシエーション（ＮＥＧ）をやり直す。これにより、通信エラーが継続している間に亘り、ホスト装置３０が更新用プログラムデータの送信を繰り返し実行する場合に比べて、無効な通信が行われる期間を短くすることが可能となる。よって、通信効率の低下及び無効な電力消費が抑えられる。また、無効な通信が行われる期間を短くすることができるので、送信時間総和が規定されている場合でも、ホスト装置３０は、更新用プログラムデータ以外の他のデータ送信を行うことが可能となる。

【0105】

ところで、図１に示す通信システム１００では、ホスト装置３０が更新用プログラムを全ての通信端末１０ａ～１０ｆにブロードキャスト送信している。しかしながら、通信端末１０ａ～１０ｆを複数のグループに分け、特定のグループに属する通信端末群のみに更新用プログラムデータをエニーキャストで配信するようにしても良い。

【0106】

図１４は、かかる点に鑑みて成された通信システム２００の構成を示すブロック図である。通信システム２００では、ホスト装置３０及び通信端末１０ａ～１０ｆ間において、例えばＩＥＥ(Institute of Electrical and Electronics Engineers) ８０２.１５.４規格に準拠した無線通信を行う。また、通信システム２００では、通信端末１０ａ～１０ｆを１０ａ～１０ｃからなる第１のグループＧＰ１と、１０ｄ～１０ｆからなる第２のグループＧＰ２とに分け、夫々に異なるＰＡＮ（Personal Area Network）ＩＤを割り当てる。

【0107】

ホスト装置３０は、図１１に示すトリガステップＴＲＧにて、グループＧＰ１及びＧＰ２のうちでプログラム更新を必要とするグループにだけ、そのグループに対応したＰＡＮ ＩＤを利用して配信準備完了信号をエニーキャストにて無線送信する。それ以降の処理については、図１１に示す通信フローによって示されるものと同一である。よって、ホスト装置３０が例えばグループＧＰ１にだけ配信準備完了信号を送信した場合には、ホスト装置３０は、グループＧＰ２に属する通信端末群に対しては更新用プログラムデータの送信は行わない。

【0108】

このように、図１４に示す通信システム２００によれば、全ての通信端末１０のうちで、プログラム更新の要望があるグループに属する通信端末１０だけにプログラムの更新処理を施すことが可能となる。例えば、センサ１０４として、温度センサを搭載している通信端末をグループＧＰ１、加速度センサを搭載している通信端末をグループＧＰ２にグループ分けした場合、グループＧＰ１にだけエニーキャストにて更新用プログラムデータを配信できる。よって、温度センサに関するプログラムを搭載していない、グループＧＰ２に属する通信端末群には更新用プログラムデータが配信されないので、無効な通信及び電力消費を省くことが可能となる。

【0109】

また、上記したように、通信端末に搭載されているセンサ１０４の機能別にグループ分けする以外にも、通信端末を設置する場所単位でグループ分けを行っても良い。例えば、工場Ａに設置する通信端末群をグループＧＰ１、工場Ｂに設置する通信端末群をグループＧＰ２とすることで、プログラム更新を必要としている工場に設置されている通信端末群のみに、更新用プログラムデータを配信することが可能となる。

【0110】

尚、図１４に示す実施例では、通信システム２００に含まれる通信端末は１０ａ～１０ｆの６個であるが、少なくとも２つ以上の複数であれば良い。また、上記実施例では、通信端末は１０ａ～１０ｆを２つのグループＧＰ１及びＧＰ２に分けているが、グループ分けする数は３個以上であっても良く、また各グループに属する通信端末の数も２つ以上の複数であれば良い。

【0111】

要するに、通信システム２００に含まれている、夫々が情報通信を担うプログラムデータが格納されているメモリ（ＰＭ）を有する複数の通信端末と、ホスト装置として、以下のような構成を採用すれば良いのである。つまり、複数の通信端末（１０ａ～１０ｆ）の各々は、更新用プログラムデータの配信準備が完了したことを示す配信準備完了信号をホスト装置（３０）から受信した場合に、スタートリクエスト信号（Ｓｒｑ）をホスト装置に送信する（Ｓ４１）。更に、複数の通信端末の各々は、データ要求を行う権利を付与する許可信号（アクティブＯＫ信号）をホスト装置から受信（Ｓ４４）した場合には、データリクエスト信号（Ｄｒｑ）をホスト装置に送信する（Ｓ５１）。

【0112】

ホスト装置（３０）は、複数の通信端末をｎ（ｎは２以上の整数）個のグループに区分けした際の所望の１つのグループに属する通信端末の各々にだけ配信準備完了信号をエニーキャスト送信する。その後、ホスト装置は、複数の通信端末のうちで最も早くスタートリクエスト信号（Ｓｒｑ）を送信した１つの通信端末に上記許可信号（アクティブＯＫ信号）を送信する（Ｓ１３）。そして、ホスト装置は、データリクエスト信号（Ｄｒｑ）の受信（Ｓ１４）に応じて、更新用プログラムデータを上記した１つのグループに属する通信端末にエニーキャスト送信する。

【符号の説明】

【0113】

１０ａ～１０ｆ 通信端末
３０ ホスト装置
１００ 通信システム
１０１ メモリ
１０２ ＭＣＵ
１０３ 乱数生成器
１０４ センサ
１０５ 送受信部
ＰＭ プログラムメモリ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13A】

【図13B】

【図13C】

【図14】