JP5266146B2 - ファームウェアのアップデート方法、および電力線搬送通信システム - Google Patents

Description

本発明は、電力線搬送通信を行う親局から子局に対してファームウェアを送信するファームウェアのアップデート方法、および電力線搬送通信システムに関するものである。

電力線搬送通信（ＰＬＣ：Power Line Communication）を行う親局と複数の子局からなる電力線搬送通信システムがある。

その一例として、集合住宅の各住戸やオフィスビル・商業ビルにおける各テナントが需要家である場合において、電気、ガス、水道等の検針メータに付設した子局と集合住宅やオフィスビル・商業ビルの電気室などに配置された親局との間で電力線搬送通信による通信を行い、各需要家の検針メータで得られた検針データ（つまり、消費電力量、ガス使用量、水道使用量等）を親局が子局から取得し、親局において検針データを集約する遠隔検針システムが提案されている（たとえば、特許文献１、２参照）。そして、親局は、電話網のような通信網を介して管理会社のセンターサーバ（集計装置）に接続されており、センター装置からの検針要求に応じて子局から検針データを取得してセンター装置に送信したり、あらかじめ定める周期毎に子局から検針データを取得してセンター装置に送信したりすることで遠隔での検針を可能にしている。

しかしながら、このような電力線搬送通信システムにおいて、子局に格納されたファームウェアのアップデートが必要となった場合、子局は需要家毎に設置されているため、１台１台の設置場所に赴いて、作業者が手作業でファームウェアをアップデートするのには膨大な手間と時間がかかる。

そこで、バージョンアップされたファームウェアをセンター装置から受信した親局が、このバージョンアップされたファームウェアを電力線搬送通信によって子局へ転送し、バージョンアップされたファームウェアを受信した子局がファームウェアのアップデート処理を自動で行うことによって、ファームウェアのアップデート処理の簡略化を図ることが提案された。

特開２０００−２８６７５７号公報 特開２００１−２８３３７０号公報

上述のように、親局から子局に対してファームウェアを転送する構成では、親局から子局へ一度に送信できるデータ量に上限があるため、ファームウェアを複数の分割ブロックに分割して、各分割ブロックを子局へ順次送信する必要がある。しかし、電力線搬送通信では、住戸に設置されている家電機器のノイズなどの影響を受けやすく、伝送路の変化によって親局から送信された分割ブロックの全部または一部が子局へ到達せず、所謂抜けブロックの発生によってファームウェアのアップデートが失敗する虞があった。

そこで、子局が、抜けブロックの発生に関する情報を記憶し、当該情報を親局へ送信することによって、親局が抜けブロックの再送を行っていた。しかし、抜けブロックの数が多くなると、子局が具備するメモリに大きいリソースが必要となり、低コスト化および小型化を阻害する要因となっていた。また、抜けブロックをできるだけ早く検知して、抜けブロックの補完を行いたいという要望もあった。

また、電力線搬送通信には、１０〜４５０ＫＨｚ帯を用いる低速電力線搬送通信と、２〜３０ＭＨｚを用いる高速電力線搬送通信があり、特に低速電力線搬送通信を用いた場合、その通信状況は、住戸に設置されている家電機器のノイズなどの影響を受けやすく、抜けブロックが発生しやすかった。

また、比較的特定の時間帯にノイズを出す機器を使っている場合、その特定時間帯では非常に通信しにくい状況となり、ファームウェアのアップデートが失敗しやすくなっていた。さらに、低速電力線搬送通信においては、通信帯域が狭いため、ファームウェアのアップデートのような、サイズの大きいデータ通信の完了までに時間がかかるが、アップデートに要する時間を短縮しようとすると通信成功率が悪化し、結果として、ファームウェアのアップデートが失敗しやすくなっていた。

本発明は、上記事由に鑑みてなされたものであり、その目的は、ファームウェアを複数の分割ブロックに分割して子局へ送信する際に抜けブロックが発生するのを抑制し、アップデート成功率を向上させるとともに、子局のメモリリソースを低減でき、さらには抜けブロックを早期に検知可能なファームウェアのアップデート方法、および電力線搬送通信システムを提供することにある。

請求項１の発明は、親局から子局に対してファームウェアを電力線搬送通信により送信するファームウェアのアップデート方法であって、親局がファームウェアを複数の分割ブロックに分割する分割工程と、当該分割された分割ブロックに親局が識別情報を付与する付与工程と、当該識別情報が付与された２以上の特定数の分割ブロック毎に親局が同報通信により各分割ブロックを所定間隔で子局に順次送信する同報送信工程と、子局が親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定する判定工程と、親局が前記２以上の特定数の分割ブロックを同報通信で送信する毎に、または親局が前記２以上の特定数の分割ブロックを同報通信で送信している期間に子局から抜けブロックの発生状況に関する情報を取得する確認工程と、当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して親局が当該抜けブロックをユニキャスト通信により再送するユニキャスト再送工程と、各子局における抜けブロックの数が第１の所定数に達した場合、当該子局は前記同報送信工程またはユニキャスト再送工程により抜けブロックを受信する度に抜けブロックの数をデクリメントし、抜けブロックの数が第２の所定数に低減するまでは抜けブロック以外の分割ブロックの受信を拒否し、抜けブロックの数が第２の所定数にまで低減すれば抜けブロック以外の分割ブロックの受信を許可する受信制限工程とを含むことを特徴とする。

この発明によれば、ファームウェアのアップデート方法において、ファームウェアを複数の分割ブロックに分割して子局へ送信する際に抜けブロックが発生するのを抑制し、アップデート成功率を向上させるとともに、子局のメモリリソースを低減でき、さらには抜けブロックを早期に検知することができる。

請求項２の発明は、請求項１において、前記親局は、前記同報送信工程において分割ブロックを順次送信する送信間隔を、全子局における抜けブロックの発生数と抜けブロックを発生した子局の台数との少なくとも一方に基づいて調整することを特徴とする。

この発明によれば、抜けブロックの発生状況に応じて、フラッディング時の送信間隔の調整処理を行うことで、アップデートの成功率を維持しながら、アップデートに要する時間を最適に調整できる。特に、良好な伝送環境では、アップデートに要する時間を短縮できる。

請求項３の発明は、請求項１または２において、前記親局は、前記同報送信工程において、前記分割ブロックを同報通信により子局に順次送信する際に、複数の分割ブロックで構成されるセット毎に複数回送信することを特徴とする。

この発明によれば、伝送路に発生するバーストノイズに対する耐性が向上し、抜けブロックの発生確率を低減できるので、ファームウェアのアップデート成功率のさらなる向上が可能となる。

請求項４の発明は、請求項３において、前記親局は、前記同報送信工程において、前記複数の分割ブロックで構成されるセット毎に送信する回数を、全子局での抜けブロックの発生数と抜けブロックを発生した子局の台数との少なくとも一方に基づいて調整することを特徴とする。

この発明によれば、アップデートの成功率を維持しながら、アップデートに要する時間を最適に調整できる。また、良好な伝送環境では、ファームウェア転送時の通信量を低減でき、ファームウェアのアップデートに要する時間を短縮することができる。

請求項５の発明は、請求項３または４において、前記親局が前記同報送信工程において前記複数の分割ブロックで構成されるセットを送信すると、前記子局は親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定し、親局は当該抜けブロックの発生状況に関する情報を子局から取得し、次回に親局が前記複数の分割ブロックで構成されるセットを再送する場合、親局は、前記取得した抜けブロックの発生状況に関する情報に基づいて、抜けブロックのみを再送することを特徴とする。

この発明によれば、アップデートの成功率を維持しながら通信量を低減でき、ファームウェアのアップデートに要する時間を短縮することができる。

請求項６の発明は、請求項１乃至５いずれかにおいて、前記子局が、前記判定工程において抜けブロックの発生を検知した場合、前記親局に対して抜けブロックが発生した旨の通知を行う通知工程を含み、通知情報を受信した親局が、前記確認工程において子局から抜けブロックの発生状況に関する情報を取得し、前記ユニキャスト再送工程において、当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して当該抜けブロックをユニキャスト通信により再送することを特徴とする。

この発明によれば、親局は、子局における抜けブロックの発生をより早く検知でき、抜けブロックの補完処理を迅速に行うことができる。

請求項７の発明は、電力線搬送通信を行う親局と子局とを備える電力線搬送通信システムであって、親局は、ファームウェアを複数の分割ブロックに分割する分割手段と、当該分割された分割ブロックに識別情報を付与する付与手段と、当該識別情報が付与された２以上の特定数の分割ブロック毎に同報通信により各分割ブロックを所定間隔で子局に順次送信する送信手段とを備え、子局は、親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定する管理手段を備え、親局は、前記２以上の特定数の分割ブロックを同報通信で送信する毎または前記２以上の特定数の分割ブロックを同報通信で送信している期間に子局から抜けブロックの発生状況に関する情報を取得する確認手段と、当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して当該抜けブロックをユニキャスト通信により再送する再送手段とをさらに備え、子局の管理手段は、自局における抜けブロックの数が第１の所定数に達した場合、親局から抜けブロックを受信する度に抜けブロックの数をデクリメントし、抜けブロックの数が第２の所定数に低減するまでは抜けブロック以外の分割ブロックの受信を拒否し、抜けブロックの数が第２の所定数にまで低減すれば抜けブロック以外の分割ブロックの受信を許可することを特徴とする。

この発明によれば、電力線搬送通信システムにおいて、ファームウェアを複数の分割ブロックに分割して子局へ送信する際に抜けブロックが発生するのを抑制し、アップデート成功率を向上させるとともに、子局のメモリリソースを低減でき、さらには抜けブロックを早期に検知することができる。

以上説明したように、本発明では、ファームウェアを複数の分割ブロックに分割して子局へ送信する際に抜けブロックが発生するのを抑制し、アップデート成功率を向上させるとともに、子局のメモリリソースを低減でき、さらには抜けブロックを早期に検知できるという効果がある。

本発明の電力線搬送通信システム（遠隔検針システム）のブロック構成を示す図である。 同上の親局のブロック構成を示す図である。 同上の子局のブロック構成を示す図である。 実施形態１の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 実施形態３の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。 実施形態４の通信シーケンスを示す図である。 同上の通信シーケンスを示す図である。

以下、本発明の実施の形態を図面に基づいて説明する。

（実施形態１）
本実施形態のファームウェアのアップデート方法は、集合住宅やオフィスビル・商業ビルのように１つの建物内に複数台の電力計測装置が配置された遠隔検針システムを用いることを想定している。

この遠隔検針システムでは集合住宅の住戸別に電気料金を課金するために、図１に示すように、検針メータ３０が、各住戸に配設した電力線Ｌｐの各電力供給状態を監視する監視手段として設けられる。検針メータ３０は瞬時電力を計測し、瞬時電力を積算することによって時間帯別に電力量を計量する。したがって、たとえば昼間時間と夜間時間のように料金単価の異なる時間帯における使用電力量を個別に計量することができる。

そして、遠隔検針システムは、各住戸における電力の使用量を遠隔で検針することを目的にしているから、各住戸の検針メータ３０で得られた検針データ（つまり、消費電力量）を通信により伝送する必要がある。ここでは、検針メータ３０で得られる検針データを伝送する通信路に電力線Ｌｐを用いた電力線搬送通信（ＰＬＣ：Power Line Communication）を行う。各住戸に設けた検針メータ３０の検針データは、たとえば建物を単位として設けられた親局１０に電力線搬送通信によって集められる。さらに親局１０は、電力会社が管理する上位系サーバ４０との間でインターネットのような広域情報通信網ＮＴを通して通信を行う。したがって、上位系サーバ４０では各住戸での電力の使用量を個別に取得することが可能になる。

各住戸に設けた検針メータ３０の検針データを親局１０に伝送するために、各検針メータ３０には親局１０との間で通信を行う子局２０がそれぞれ付設される。子局２０は電力線Ｌｐに接続されており、通常は１組（単相３線）の電力線Ｌｐから複数の住戸に給電するから、１組の電力線Ｌｐに複数台の端局２が接続されることになる。また、電力線Ｌｐの構成は、単相３線に限定されるものではなく、単相２線または３相３線等の他の構成であってもよい。

このように、検針メータ３０は各住戸での電力の使用量を計測しており、子局２０は各検針メータ３０から検針データ（積算電力量）を取得するから、子局２０は建物内の住戸毎に分散して配置される。一方、親局１０は各子局２０が取得した検針データを電力線搬送通信を用いて集めるために、建物の１箇所に配置され、例えば建物において電力系統の幹線や降圧トランスを収納している電気室に配置される。

このように、親局１０および子局２０が電力線搬送通信により相互に通信する電力線搬送通信システムを例示しているが、電力線搬送通信としては、通信帯域が１０〜４５０ＫＨｚを用いる低速電力線搬送通信、通信帯域が２〜３０ＭＨｚを用いる高速電力線搬送通信のいずれを採用してもよい。なお、低速電力線搬送通信システムの場合、親局１０が子局２０に対してユニキャストでファームウェアを転送すると、全ての子局２０への転送に膨大な時間がかかってしまうため、フラッディングをベースにした本実施形態のアップデート方法を用いることによる効果が大きくなる。

また、親局１０を広域情報通信網ＮＴに接続するために、親局１０を含む構内情報通信網と広域情報通信網ＮＴとの間に介在して親局１と上位系サーバ４０との間での通信を可能にする通信装置としての図示しないモデムを設けており、光通信を行う場合にはモデムとしてＯＮＵ（Optical Network Unit）を用いる。さらに、複数の親局１０を用いる場合、図示しないハブを設けて、親局１０はハブ経由でモデムに接続してもよい。

図２は、親局１０のブロック図を示し、親局１０は、制御部１１０、記憶部１２０、通信部１３０を備えている。制御部１１０は、ＣＰＵ等を備え、親局１０全体を統括制御するものであり、分割部１１１、付与部１１２、送信制御部１１３、確認部１１４、再送制御部１１５、指示部１１６で構成される。

分割部１１１は、親局１０から子局２０へ送信されるファームウェアを複数の分割ブロックに分割する。ここで、ファームウェアとは子局２０の制御プログラムであり、子局２０の種々の制御を司るアプリ層ファームウェアと子局２０の通信制御を司るＮＥＴ層ファームウェアとの２種類のファームウェアが含まれ、分割部１１１は、アプリ層ファームウェアおよびＮＥＴ層ファームウェアをそれぞれ複数の分割ブロックに分割する。また、ファームウェアを複数の分割ブロックに分割するのは、親局１０から子局２０へ一度に送信できるデータ量に上限があるからである。

付与部１１２は、分割部１１１により分割された分割ブロックに識別情報を付与する。この識別情報は、各分割ブロックに一意的に割り付けられ、互いに連続する分割ブロックの各識別情報は、互いに連続した情報（例えば数字情報）を含んでいる。

送信制御部１１３は、通信部１３０を制御して送信制御を行うものであり、例えば、付与部１１２に識別情報を付与された分割ブロックを同報通信により順次に子局２０へ送信する。本実施形態では、同報通信として、分割ブロックを受信した子局２０がさらに同報通信を行うフラッディングが採用されている。そのため、分割ブロックが全子局２０へ送信される確率を高めることができる。

確認部１１４は、子局２０に対して、全ての分割ブロックの送信が完了した後、全ての子局２０に対して抜けブロックの発生状況（抜けブロックの有無等）を確認する。具体的には、確認部１１４は、抜けブロックの発生状況を確認する確認処理を全子局２０に対して順次実行するものであり、ある子局２０において確認処理に失敗した場合、次の子局２０に対して確認処理を実行する。ここで、抜けブロックとは、子局２０が受信に失敗した分割ブロックを示す。

再送制御部１１５は、通信部１３０を制御して、確認部１１４により抜けブロックの発生が確認された子局２０に対して、ユニキャストによって抜けブロックを再送する。

指示部１１６は、子局２０に対してファームウェアをアップデートするように指示する。

通信部１３０は、ＰＬＣモデム等の電力線搬送通信を実行する通信モジュールで構成され、通信制御を司る。記憶部１２０は、例えば書き換え可能な不揮発性の記憶装置から構成され、ファームウェア記憶部１２１および抜けブロック管理情報記憶部１２２を備えている。ファームウェア記憶部１２１は、送信対象となるファームウェアを記憶している。抜けブロック管理情報記憶部１２２は、各子局２０から取得した後述の抜けブロック管理情報を記憶している。

図３は、子局２０の構成を示す。子局２０は、制御部２１０、通信部２２０、記憶部２３０を備えている。制御部２１０は、ＣＰＵ等から構成され、受信制御部２１１および管理部２１２で構成されている。受信制御部２１１は、通信部２１０を制御して、親局１０から分割ブロック等を受信する。管理部２１２は、分割ブロックに付与された識別情報を基に、抜けブロックの発生状況を管理し、各子局２０における抜けブロックの発生状況を示す抜けブロック管理情報を生成する。

記憶部２３０は、例えば書き換え可能な不揮発性の記憶装置から構成され、管理部２１２が生成した抜けブロック管理情報や、受信した分割ブロックや、複数の分割ブロックから生成されたファームウェア等を記憶している。

通信部２２０は、ＰＬＣモデム等の電力線搬送通信を実行する通信モジュールで構成され、通信制御を司る。

次に、図４〜図９は、子局２０でファームウェアのアップデートが必要な場合におけるファームウェアのアップデート方法を示す通信シーケンスであり、１台の親局１０に例えばｎ台の子局２０が電力線Ｌｐを介して接続されているものとする。

まず、上位系サーバ４０は、親局１０にファームファイルの送信開始を親局１０へ通知するためのファーム転送要求を親局１０へ送信する（ステップＳ１）。次に、親局１０は、ファーム転送応答を上位系サーバ４０へ送信する（ステップＳ２）。次に、上位系サーバ４０は、ファームファイルをＦＴＰ（File Transfer Protocol）により親局１０に送信する（ステップＳ３）。ファームファイルは、子局２０の種々の制御を司るアプリ層ファームウェアと子局２０の通信制御を司るＮＥＴ層ファームウェアが所定のフォーマットによりひとまとめにされたものであってもよく、例えばｔａｒ形式により圧縮されたものであってもよい。なお、本実施形態ではアプリ層ファームウェアおよびＮＥＴ層ファームウェアを区別することなくファームウェアと称す。

次に、親局１０は、ファームファイルの受信が完了したことを通知するためのＰＬＣイベント発生通知を上位系サーバ４０へ送信する（ステップＳ４）。次に、上位系サーバ４０は、ＰＬＣイベント発生応答を親局１０へ送信する（ステップＳ５）。

次に、親局１０は、アップデートモードに移行し、ファームウェアの転送処理を開始する（ステップＳ６）。このとき、親局１０は、上位系サーバ４０から取得したファームファイルを解凍、分離したファームウェアをファームウェア記憶部１２１に記憶する。

次に、親局１０は、各子局２０に対してユニキャストにより、ファームウェア転送要求（初期化）を送信する（ステップＳ７）。ファームウェア転送要求（初期化）を受信した子局２０は、前回のアップデート時のファームウェア情報や、抜けブロック管理情報をクリアして、初期化を行った後に、ファームウェア転送応答（初期化）を親局１０へ送信する。なお、各子局２０に対するファームウェア転送要求（初期化）のユニキャスト送信は一回に限らず、所定回数の再送処理を行ってもよい（図４では、再送回数：２回）。すなわち子局２０が、ファームウェア転送要求（初期化）の受信や、ファームウェアの初期化に失敗したとしても、ファームウェア転送要求（初期化）の再送処理によって、初期化の成功率が向上する。なお、ステップＳ７における初期化に失敗した子局２０に対しては、以降のアップデート処理を行わない。

次に、親局１０では、分割部１１１が、ファームウェア記憶部１２１に記憶したファームウェアを複数の分割ブロックに分割し［分割工程］、付与部１２１は、各分割ブロックに識別情報を付与する［付与工程］。ここで、ファームウェアは、１行または複数行ずつ分割され、各分割ブロックに付与される識別情報は、分割順に連番となるように割り付けられた数字情報等で構成され、さらにはファームウェアの種類を示す情報を含んでもよい。

次に、親局１０では、送信制御部１１３が、まず１〜５００ブロックまでの分割ブロックを含む各ファームウェア転送要求（Ｚブロック目）（なお、Ｚは任意の自然数）を、フラッディングによって１ブロック目から順次同報送信する（ステップＳａ１）［同報送信工程］。なお、本実施形態では、１つのファームウェアの全分割ブロックを５００ブロック毎に区切り、１回の同報送信工程で５００ブロック分のファーム転送要求（Ｚブロック目）を送信する。但し、１回の同報送信工程で送信するブロック数は２以上の特定数であればよく、５００ブロックに限定されない。

１回の同報送信工程で５００ブロック分のファーム転送要求（Ｚブロック目）を順次受信する子局２０では、管理部２１２がファーム転送要求（Ｚブロック目）から分割ブロックを抽出して記憶部２３０に格納する（分割ブロックの受信完了）。さらに管理部２１２は、抜けブロックの発生状況を示す抜けブロック管理情報を生成して記憶部２３０に格納する［判定工程］。ここで、抜けブロックの有無の判定は、分割ブロックの識別情報に基づいて行われ、今回受信した分割ブロックの識別情報と前回受信した分割ブロックの識別情報とを比較し、互いの識別情報が連続していなければ、今回受信した分割ブロックと前回受信した分割ブロックとの間の分割ブロックが抜けているとして、抜けブロックありと判定する。そして、この判定結果に基づいて生成される抜けブロック管理情報には、抜けブロック情報（何ブロック目の分割ブロックが抜けブロックとなっているか）、抜けブロック数上限到達フラグ情報（自局における抜けブロックの総数が３０個に達した場合にセットされる）、受信完了ブロック情報（それまでに抜けブロックがなく、連続で受信完了している分割ブロック列の最終の分割ブロックの情報）が含まれる。特に、受信完了ブロックとは、例えば１〜５００ブロックまでの分割ブロックが送信されて、１〜４００ブロックまでは受信完了したが、４０１ブロック目が抜けブロックとなった場合、４０２ブロック以降を受信完了したとしても、受信完了ブロックは４００ブロックとなる。

親局１０は、１〜５００ブロックまでの各ファームウェア転送要求（Ｚブロック目）を、フラッディングにより子局２０へ順次送信した後、確認部１１４が転送状況確認（途中経過）を行う（ステップＳｂ１）［確認工程］。確認工程では、確認部１１４が、各子局２０に対してユニキャストにより、ファームウェア転送状況確認要求を送信する。ファームウェア転送状況確認要求を受信した子局２０では、管理部２１２が、自局で生成した抜けブロック管理情報を含むファームウェア転送状況確認応答を親局１０へ送信する。なお、親局１０から各子局２０に対するファームウェア転送状況確認要求のユニキャスト送信は一回に限らず、所定回数の再送処理を行ってもよい（図５では、再送回数：２回）。すなわち、ファームウェア転送状況確認要求の送信や、ファームウェアの転送状況確認に失敗したとしても、再送処理によって転送状況確認の成功率が向上する。また、ステップＳｂ１において転送状況確認が失敗した子局２０については、次のステップＳｃ１における抜けブロック補完の処理を行わない。

次に、子局２０からファームウェア転送状況確認応答を受信した親局１０は、ファームウェア転送状況確認応答に含まれる抜けブロック管理情報を抜けブロック管理情報記憶部１２２に格納する。而して、親局１０の抜けブロック管理情報記憶部１２２には、システム内の各子局２０の抜けブロック管理情報が格納されることになり、再送制御部１１５は、各子局２０の抜けブロック管理情報に基づいて、抜けブロックが発生した子局２０に対して抜けブロックの補完処理を行う（ステップＳｃ１）［ユニキャスト再送工程］。親局１０は、各子局１０の抜けブロック管理情報から、抜けブロック情報、抜けブロック数上限到達フラグ情報、受信完了ブロック情報を参照して、抜けブロックの補完処理を以下のように行う。

まず、抜けブロックの数が３０個未満（抜けブロック数上限到達フラグがリセット状態）の子局２０に対する抜けブロック補完処理を、ステップＳｃ１Ａに示している。親局１０の再送制御部１１５は、抜けブロックが発生した子局２０に対して、当該子局２０で発生した抜けブロックを含むファームウェア転送要求（ｘ１ブロック目）をユニキャストで送信する。１台の子局に対して抜けブロックが複数ある場合には、抜けブロック毎にファームウェア転送要求（ｘ１，ｘ２，．．．ブロック目）を順次送信する。ファームウェア転送要求（ｘ１ブロック目）を受信した子局２０では、管理部２１２が、記憶部２３０に記憶している抜けブロック管理情報から、今回受信したｘ１ブロック目の抜けブロックに関する情報を削除して抜けブロック管理情報を更新した後に（すなわち、抜けブロック管理情報で管理されている抜けブロックの数がデクリメントされる）、ファームウェア転送応答を親局１０へ送信する。

子局２０から最後の抜けブロックに対応するファームウェア転送応答を受信した親局１０では、確認部１１４が、抜けブロックの補完を行った子局２０に対してユニキャストにより、ファームウェア転送状況確認要求を送信する。ファームウェア転送状況確認要求を受信した子局２０では、管理部２１２が、抜けブロックの補完処理によって更新された抜けブロック管理情報を含むファームウェア転送状況確認応答を親局１０へ送信し、親局１０も、抜けブロック管理情報記憶部１２２内の抜けブロック管理情報を更新する。本例では、今回の抜けブロック補完処理によって子局２０が１〜５００ブロックまでの全分割ブロックを受信したとして、子局２０はファームウェア転送状況確認応答（受信完了ブロック：５００）を送信する。なお、抜けブロック補完処理によって抜けブロックがゼロになった場合だけでなく、抜けブロック補完処理で全ての抜けブロックを補完できなかった場合でも、次のステップに移行する。

次に、抜けブロックの数が３０個以上（抜けブロック数上限到達フラグがセット状態）の子局２０に対する抜けブロック補完処理を、ステップＳｃ１Ｂに示す。まず、子局２０は、ステップＳａ１における分割ブロックのフラッディング処理において、自局の抜けブロックの数が３０個（ｙ１、ｙ２、ｙ３、．．．、ｙ３０ブロック目）となった時点で、記憶部２３０の抜けブロック管理情報内の抜けブロック数上限到達フラグをセットする。子局２０において抜けブロック数上限到達フラグがセットされると、以降に親局１０から送信された分割ブロックのうち、抜けブロック管理情報で管理されている３０個の抜けブロックのみを受信許可し、抜けブロック管理情報で管理されているいずれかの抜けブロックを受信すると、受信した抜けブロックに関する情報を抜けブロック管理情報から削除して抜けブロック管理情報を更新する（すなわち、抜けブロック管理情報で管理されている抜けブロックの数がデクリメントされる）。しかし、抜けブロック管理情報で管理されている３０個の抜けブロック以外の分割ブロックは受信を拒否し、この受信拒否した分割ブロックを抜けブロックとして抜けブロック管理情報に反映することもない。そして、抜けブロック補完処理や分割ブロックのフラッディング処理によって、３０個の抜けブロックが完全に補完された時点で抜けブロック数上限到達フラグをリセットし、親局１０から送信された他の分割ブロックの受信を再開する［受信制限工程］。なお、抜けブロック数上限到達フラグをセットする抜けブロックの数は３０個に限定されるものではなく、他の個数であってもよい。

このように、抜けブロック管理情報において管理する抜けブロックの数を上限３０個に制限しているので、子局２０が具備する記憶部２３０の容量（リソース）を抑えることができ、最小限のリソースで抜けブロックを管理して、ファームウェアのアップデート失敗を防止することができる。而して、子局２０の低コスト化および小型化が可能となる。

また、子局２０が抜けブロック数上限到達フラグをリセットするタイミングは、３０個の抜けブロックのうち、予め設定された所定個数（例えば１５個）の抜けブロック、または予め設定された所定割合（例えば管理可能な抜けブロック数の上限値の１／２）の抜けブロックが補完された時点でもよい。この場合は、３０個の抜けブロックが全て補完されなくても、一部の抜けブロックが補完された時点で抜けブロック数上限到達フラグをリセットすることで、親局１０から送信された他の分割ブロックの受信を早く再開することができ、ファームウェアのアップデートに要する時間を短縮することができる。

そしてステップＳｃ１Ｂにおいて、親局１０の再送制御部１１５は最初に、補完対象の子局２０の抜けブロック管理情報で管理されているｙ１、ｙ２、ｙ３、．．．、ｙ３０ブロック目の各抜けブロックを含むファームウェア転送要求（ｙ１、ｙ２、ｙ３、．．．、ｙ３０ブロック目）をユニキャストで順次送信する。ファームウェア転送要求（ｙ１、ｙ２、ｙ３、．．．、ｙ３０ブロック目）を受信した子局２０では、管理部２１２が、記憶部２３０に記憶している抜けブロック管理情報から、今回受信したＺブロック目の抜けブロックに関する情報を削除して抜けブロック管理情報を更新した後に（すなわち、抜けブロック管理情報で管理されている抜けブロックの数がデクリメントされる）、ファームウェア転送応答を親局１０へ送信する。本例では、ここまでの抜けブロック補完処理によってｙ１、ｙ２、ｙ３、．．．、ｙ３０ブロック目の各抜けブロックを全て受信しており、子局２０の管理部２１２は、記憶部２３０の抜けブロック管理情報内の抜けブロック情報をクリアするとともに、抜けブロック数上限到達フラグをリセットする。以降は、親局１０から送信された他の分割ブロックの受信を再開する。

次に、親局１０の再送制御部１１５は、抜けブロック管理情報記憶部１２２に記憶している補完対象の子局２０の抜けブロック管理情報の抜けブロック情報を参照して、最後尾の抜けブロック（ｙ３０ブロック目）以降の分割ブロックを含むファームウェア転送要求（ｙ３１〜５００ブロック目）をユニキャストで順次送信する。子局２０では、分割ブロックの受信状況に応じて、上記同様に記憶部２３０内の抜けブロック管理情報を更新する。抜けブロック補完処理によって抜けブロックがゼロになった場合だけでなく、抜けブロック補完処理を行っても全ての抜けブロックを補完できなかったり、新たな抜けブロックが発生した場合でも、次のステップに移行する。ステップＳｃ１Ｂでは、ｙ１〜ｙ３０ブロックの全ての抜けブロックを補完でき、ｙ３１〜ｙ５００ブロック間で新たな抜けブロックの発生もなかったものとする。

なお、図６のステップＳｃ１Ａ，Ｓｃ１Ｂにおいて、ファームウェア転送要求（Ｚブロック目）を受信した子局２０から返送されるファームウェア転送応答に、抜けブロックの補完処理によって更新された抜けブロック管理情報を含めて、親局１０へ送信してもよい。この場合、ステップＳｃ１Ａ，Ｓｃ１Ｂにおけるファームウェア転送状況確認要求、ファームウェア転送状況確認応答の送信は不要となる。

次に、親局１０では、送信制御部１１３が、５０１〜１０００ブロックまでの分割ブロックを含む各ファームウェア転送要求（Ｚブロック目）を、フラッディングによって５０１ブロック目から順次同報送信し［同報送信工程］、ファームウェア転送要求（Ｚブロック目）を順次受信する子局２０では、管理部２１２がファーム転送要求（Ｚブロック目）から分割ブロックを抽出して記憶部２３０に格納するとともに、記憶部２３０内の抜けブロック管理情報を更新する［判定工程］（ステップＳａ２）。

親局１０は、５０１〜１０００ブロックまでの各ファームウェア転送要求（Ｚブロック目）を、フラッディングにより子局２０へ順次送信した後、確認部１１４が転送状況確認（途中経過）を行う（ステップＳｂ２）［確認工程］。次に、親局１０の再送制御部１１５は、各子局２０から取得した抜けブロック管理情報に基づいて、抜けブロックが発生した子局２０に対して抜けブロックの補完処理を行う（ステップＳｃ２）［ユニキャスト再送工程］。このステップＳａ２〜Ｓｃ２の各処理は、５０１〜１０００ブロックまでの分割ブロックに対して、上記ステップＳａ１〜Ｓｃ１と同様の処理を行い、本処理にも上記［受信制限工程］が含まれる。

また、ステップＳｂ２の転送状況確認では、ステップＳｂ１において転送状況確認が失敗した子局２０は、５０１〜１０００ブロックだけでなく、１〜５００ブロックの分割ブロックの転送状況についても応答し、ステップＳｃ２の抜けブロック補完では、５０１〜１０００ブロックだけでなく、１〜５００ブロックの抜けブロックの補完処理も併せて行う。例えば、ステップＳｂ１における１〜５００ブロックの分割ブロックの転送状況確認では、伝送環境が一時的に悪く、ある子局２０で発生した１〜５００ブロックの範囲における抜けブロックの情報を得ることができなかったとする。しかし、ステップＳｂ２の転送状況確認時点では伝送環境が良好になり、５０１〜１０００ブロックの抜けブロックだけでなく、１〜５００ブロックの抜けブロックの情報も得ることができ、ステップＳｃ２の補完処理では、５０１〜１０００ブロックの抜けブロックだけでなく、１〜５００ブロックの抜けブロックについても補完処理を行う。したがって、抜けブロックの補完処理の機会が増え、アップデートの成功率を向上させることができる。

以降は、５００ブロック毎に上記ステップＳａ２〜Ｓｃ２と同様の処理を行う
そして、ｍブロック〜最終ブロックの分割ブロックの転送処理においても、上記ステップＳａ２〜Ｓｃ２と同様に、親局１０がｍブロックから最終ブロックの分割ブロックをフラッディングした後に（ステップＳａ３）、転送状況確認（最終）（ステップＳｂ３）、抜けブロックの補完処理（ステップＳｃ３）を行う。但し、ステップＳｃ３の抜けブロックの補完処理は、抜けブロックが発生した子局２０に対して所定回数の再送処理を行ってもよく（図８では、再送回数：２回）、さらにはステップＳｃ１，Ｓｃ２（図６、図７）の抜けブロックの補完処理においても、抜けブロックが発生した子局２０に対して所定回数の再送処理を行ってもよい。

ｍブロック〜最終ブロックの分割ブロックの転送処理では、ステップＳｂ３の転送状況確認処理（最終）、ステップＳｃ３の抜けブロックの補完処理での再送処理を２回繰り返して行うが、ステップＳｂ３，Ｓｃ３の実行後に、転送状況確認や抜けブロックの補完を失敗した子局２０は、ファームウェアのアップデート対象外とし、以降のアップデート処理を行わない。

そして、１ブロックから最終ブロックの分割ブロックの転送処理を完了した親局１０は（ステップＳ１１）、ファームウェアの更新開始処理を開始する（ステップＳ１２）。まず、親局１０の指示部１１６は、各子局２０に対してユニキャストにより、ファームウェア更新開始要求（更新開始時刻）を送信する。ファームウェア更新開始要求には更新開始時刻の情報が含まれている。ファームウェア更新開始要求（更新開始時刻）を受信した子局２０は、ファームウェア更新開始応答を親局１０へ送信する。なお、各子局２０に対するファームウェア更新開始要求（更新開始時刻）のユニキャスト送信は一回に限らず、所定回数の再送処理を行ってもよい（図９では、再送回数：２回）。すなわち子局２０が、ファームウェア更新開始要求（更新開始時刻）の受信に失敗したとしても、ファームウェア更新開始要求（更新開始時刻）の再送処理によって、要求受信の成功率が向上する。

そして、ファームウェア更新開始要求（更新開始時刻）を受信した子局２０は、更新開始時刻になるとファームウェアの更新を一斉に行い、ファームウェアのアップデートが完了する（ステップＳ１３）。

このように、ファームウェアを複数の分割ブロックに分割し、子局２０へ分割ブロックをフラッディングした後に、転送状況確認、抜けブロック補完の各処理を行うので、抜けブロックが発生するのを抑制し、アップデート成功率が向上している。さらに、所定ブロック数（本実施形態では５００ブロック）毎に、子局２０への分割ブロックのフラッディング、転送状況確認、抜けブロック補完の各処理を行うので、前記各処理を全ての分割ブロックに対して一括して行う方法に比べて、子局２０における抜けブロックの発生を早く検知でき、抜けブロックの補完処理を迅速に行うことができる。

また、本実施形態のファームウェアのアップデート方法において、親局１０からのユニキャスト送信を行う工程（ファームウェア転送初期化、転送状況確認、抜けブロック補完等）は、子局２０からの応答がなければ、通信に失敗したとしてすぐにユニキャストで再送してもよいが、ノイズ等によって伝送環境が悪化したことが原因であれば、すぐに再送しても伝送環境が復旧していない虞が高く、ある程度時間が経過した後に再送するほうが望ましい。特に、本実施形態のファームウェアのアップデート方法のように、親局１０が子局２０から定期的に検針データを取得している場合、ユニキャスト送信の失敗時の再送は、次の定期的な検針データ取得タイミングに行ってもよい。この場合、再送時には伝送環境が安定している可能性が高く、通信成功率の向上が期待でき、ファームウェアのアップデート成功率の向上が可能となる。

（実施形態２）
実施形態１におけるファームウェアのアップデート方法では、分割ブロックを含むファームウェア転送要求（Ｚブロック目）をフラッディングで同報送信する際に、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａ（図５参照）を一定の時間間隔（例えば３０秒間隔）に設定している。しかし、本実施形態では、抜けブロックの総発生個数（全子局２０において発生した抜けブロックの総数）に応じて送信間隔Ｔａを動的に調整する。

例えば、親局１０は、１〜５００ブロックの分割ブロックをフラッディングし（ステップＳａ１）、その後の転送状況確認処理（ステップＳｂ１）で全子局２０から取得した抜けブロック管理情報に基づいて抜けブロックの総発生個数を導出する。そして、抜けブロックの総発生個数が１０〜２０個であれば、次の５０１〜１０００ブロックの分割ブロックをフラッディングする際に（ステップＳａ２）、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを「現状の送信間隔Ｔａ＋５秒」に設定し、抜けブロックの総発生個数が２０〜３０個であれば、次の５０１〜１０００ブロックの分割ブロックをフラッディングする際に（ステップＳａ２）、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを「現状の送信間隔Ｔａ＋１０秒」に設定する。このように、抜けブロックが発生した場合、次の分割ブロックのフラッディング処理では、送信間隔Ｔａを増大させる方向に調整する。

また、抜けブロックが発生しなかった場合、次の分割ブロックのフラッディング処理では、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを減少させる方向（または元に戻す方向）に調整する。例えば、５０１〜１０００ブロックの分割ブロックをフラッディングし、その後の転送状況確認処理で抜けブロックの総発生個数が０個であれば、次の１００１〜１５００ブロックの分割ブロックをフラッディングする際に、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを「現状の送信間隔Ｔａ−５秒」に設定する。

このように、前回の抜けブロックの総発生個数に応じて、フラッディング時の送信間隔Ｔａの調整処理を行うことで、アップデートの成功率を維持しながら、アップデートに要する時間を最適に調整できる。特に、良好な伝送環境では、アップデートに要する時間を短縮できる。

さらに、この送信間隔Ｔａの調整処理は、抜けブロックを発生した子局２０の台数に基づいて行ってもよい。例えば、抜けブロックを発生した子局２０の台数が５〜１０台であれば、次に分割ブロックをフラッディングする際には、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを「現状の送信間隔Ｔａ＋５秒」に設定し、抜けブロックを発生した子局２０の台数が１０〜１５台であれば、次に分割ブロックをフラッディングする際には、ファームウェア転送要求（Ｚブロック目）の送信間隔Ｔａを「現状の送信間隔Ｔａ＋１０秒」に設定する。

これは、例えば抜けブロック数の総発生個数が１０個であっても、その１０個の抜けブロックを１台の子局２０が発生したのか、１０台の子局２０が抜けブロックを１個づつ発生したのかによって、電力線搬送通信の伝送環境が異なり、後者の場合では伝送環境が本システムの全体的によくない（全体的に信号が到達し難い）と判断できる。したがって、抜けブロックを発生した子局２０の台数に基づいて送信間隔Ｔａを調整することによって、特定の子局２０だけではなく、システム全体の伝送環境を考慮して、アップデートの成功率を改善できる。

さらに、前回の抜けブロックの総発生個数と抜けブロックを発生した子局２０の台数との両方に基づいて、フラッディング時の送信間隔Ｔａの調整処理を行ってもよい。

（実施形態３）
実施形態１，２におけるファームウェアのアップデート方法において、分割ブロックを含む各ファームウェア転送要求（Ｚブロック目）をフラッディングする同報送信工程は、１つの分割ブロックを１回のみ送信しているが、同一の分割ブロックを連続して複数回（例えば３回）送信するようにしてもよい。この場合、子局２０への分割ブロックの到達率が改善され、ファームウェアのアップデート成功率の向上が可能となる。しかし、伝送路にバーストノイズが発生した場合、同一の分割ブロックを連続して複数回送信しても、当該分割ブロックの複数回の送信の全てがバーストノイズの影響を受けて抜けブロックとなる虞が高い。

そこで、図１０、図１１にフラッディングによるファームウェア転送の別例を示す。まず、図１０に示すように、同報送信工程（ステップＳａ）において、分割ブロックを５００ブロック単位でフラッディングすることを「１セットのフラッディング」とすると、５００ブロック単位で複数セット（例えば３セット）を連続してフラッディングし、その後、転送状況確認（途中経過）を行ってもよい（ステップＳｂ）［確認工程］。または図１１に示すように、同報送信工程（ステップＳａ）において、５００ブロックを１０ブロック毎に分けて、当該１０ブロック単位でフラッディングすることを「１セットのフラッディング」とすると、１０ブロック単位で複数セット（例えば３セット）を連続してフラッディングし、この動作を５００ブロックまで１０ブロック単位で順次行ってもよい。この場合、伝送路に発生するバーストノイズに対する耐性が向上し、抜けブロックの発生確率を低減できるので、ファームウェアのアップデート成功率のさらなる向上が可能となる。

ここで、ファームウェアを１行毎に分割して分割ブロックを生成する方法と、ファームウェアを複数行毎に分割して分割ブロックを生成する方法とがある。分割ブロックの再送処理を行う場合には、複数行毎に分割した分割ブロックを用いるほうが、同一の分割ブロックを再送する際に送信間隔が長くなって、伝送路上のバーストノイズの影響を受け難くなる。

また、図１０、図１１の同報送信工程（ステップＳａ）において、複数セットを連続してフラッディングする場合、連続してフラッディングするセット数は所定回数（例えば３回）に固定してもよいが、抜けブロックの総発生個数（全子局２０において発生した抜けブロックの総数）に応じてフラッディングするセット数を動的に調整してもよい。

例えば、親局１は、１〜５００ブロックの分割ブロックをフラッディングする際には、３セット連続して送信するが、その後の転送状況確認処理で抜けブロックがなければ、次の５０１〜１０００ブロックの分割ブロックをフラッディングする際に１セットのみ送信し、転送状況確認処理で例えば抜けブロックの総発生個数が１０個以上であれば、次の５０１〜１０００ブロックの分割ブロックをフラッディングする際に、送信セット数を「現状の送信セット数＋１セット」に設定する。さらに、この送信セット数の調整処理は、抜けブロックを発生した子局２０の台数に基づいて行ってもよい。

このように、前回の抜けブロックの総発生個数や前回の抜けブロックを発生した子局２０の台数に応じて、フラッディング時の送信セット数の調整処理を行うことで、アップデートの成功率を維持しながら、アップデートに要する時間を最適に調整できる。また、ノイズの少ない伝送環境であり、且つ伝送環境の変動が少ない環境であれば、ファームウェア転送時の通信量を低減でき、ファームウェアのアップデートに要する時間を短縮することができる。

（実施形態４）
本実施形態では、実施形態１，２の同報通信工程におけるフラッディングによるファームウェア転送の別例を図１２、図１３に示す。

まず、図１２では、同報送信工程（ステップＳａ）において、分割ブロックを５００ブロック単位でフラッディングすることを「１セットのフラッディング」とすると、フラッディングを１セット行う毎に転送状況確認を行う［確認工程］。すなわち、１セット目のフラッディング（ステップＳａ１１）に対する転送状況確認処理（ステップＳｂ１１）で抜けブロックの発生を確認した場合、２セット目のフラッディングを行う（ステップＳａ１２）。そして、２セット目のフラッディングに対する転送状況確認処理（ステップＳｂ１２）で抜けブロックの発生を確認した場合、３セット目のフラッディングを行い（ステップＳａ１３）、さらに３セット目のフラッディングに対する転送状況確認処理（ステップＳｂ１３）を行う。転送状況確認で抜けブロックの発生がなければ、２セット目、３セット目のフラッディングは行わない。

この流れを最大規定セット（例えば最大３セット）繰り返し、最大規定セットが終了した時点でまだ抜けブロックがある場合には、ユニキャストによる抜けブロックの補完処理を行う（ステップＳｃ１１）［ユニキャスト再送工程］。そして、抜けブロックの補完処理が完了した場合、または抜けブロックのフラッディングがセット毎に終了した時点で抜けブロックがない場合には、次の５００ブロック単位でファームウェア転送要求（Ｚブロック目）をステップＳａ１１と同様にフラッディングする（ステップＳａ２１）。

このように、分割ブロックのフラッディングを、抜けブロックの発生状況に応じて複数セット繰り返す。したがって、分割ブロックのフラッディング完了後に抜けブロックがない場合には、ユニキャストによる抜けブロックの補完処理を行わないので、ファームウェア転送時の通信量を低減でき、ファームウェアのアップデートに要する時間を短縮することができる。

さらに親局１０は、２セット目以降に分割ブロックのフラッディングを行う場合、転送状況確認処理で把握した抜けブロックのみを送信してもよい。例えば、親局１０は、１セット目に１〜５００ブロックの分割ブロックをフラッディングし、その後の転送状況確認処理で、３台の子局２０で抜けブロックを発生したことを確認する。ここで、１台目の子局２０の抜けブロック「１０ブロック目」、２台目の子局２０の抜けブロック「２０，２１ブロック目」、３台目の子局２０の抜けブロック「１０，３０ブロック目」とすると、抜けブロックを最大公約数的に捉えて、親局１０は、２セット目に「１０，２０，２１，３０ブロック目」の分割ブロックのみをフラッディングする。したがって、２セット目以降のフラッディングでは抜けブロックのみを送信するので、アップデートの成功率を維持しながら通信量を低減でき、ファームウェアのアップデートに要する時間を短縮することができる。

また、上記のように２セット目以降は抜けブロックのみを送信する形態では、抜けブロックの個数や、抜けブロックを発生した子局２０の台数が規定数以下（例えば、抜けブロック：５０個以下、抜けブロックの発生子局：１０台以下）であれば、２セット目以降に抜けブロックを送信する際に、全ての子局２０に対して抜けブロックのフラッディングを行うのではなく、抜けブロックを発生した子局２０にのみユニキャストで抜けブロックの補完を行うユニキャスト再送工程に移行してもよい。この場合、システム全体の通信量を低減することができるとともに、抜けブロックがない子局２０に対して不要な通信を行わないので、通信負荷を低減することができる。

（実施形態５）
実施形態１乃至４におけるファームウェアのアップデート方法では、親局１０が、各子局２０に対してユニキャストにより、ファームウェア転送状況確認要求を送信し、子局２０からファームウェア転送状況確認応答を受信することによって、親局１０が子局２０から抜けブロック管理情報を取得して転送状況確認を行っている。しかし、本実施形態では、親局１０が分割ブロックのフラッディングを行っているときに、子局２０が抜けブロックの発生を検知した時点で［判定工程］、当該子局２０から親局１０へ抜けブロックが発生した旨のイベント通知を行い［通知工程］、イベント通知を受信した親局１０は、抜けブロックが発生した子局２０に対して抜けブロックの補完を行う［ユニキャスト再送工程］。親局１０が抜けブロック補完を実行するタイミングは、子局２０からイベント通知を受信した時点、または現在行っている分割ブロックのフラッディング処理が完了した時点となる。

また、抜けブロックを発生した子局２０からイベント通知を受信した親局１０が、当該子局２０から抜けブロック管理情報を取得する確認工程は、子局２０から送信されるイベント通知に抜けブロック管理情報を含める構成や、子局２０からイベント通知を受信した親局２０がファームウェア転送状況確認要求を別途送信して、子局２０から抜けブロック管理情報を取得する構成のいずれであってもよい。

したがって、親局１０は、子局２０における抜けブロックの発生をより早く検知でき、抜けブロックの補完処理を迅速に行うことができる。

また、子局２０は、自局で発生した抜けブロックの個数が２以上の所定個数（例えば１０個）に達した時点で、イベント通知を親局１０へ送信してもよい。この場合、親局１０が、子局２０における抜けブロック発生を検知する速さを維持しながら、通信負荷を低減することが可能となる。

１０ 親局
２０ 子局
３０ 検針メータ
４０ 上位系サーバ
Ｌｐ 電力線
ＮＴ 広域情報通信網

Claims (7)

1. 親局から子局に対してファームウェアを電力線搬送通信により送信するファームウェアのアップデート方法であって、
   親局がファームウェアを複数の分割ブロックに分割する分割工程と、
   当該分割された分割ブロックに親局が識別情報を付与する付与工程と、
   当該識別情報が付与された２以上の特定数の分割ブロック毎に親局が同報通信により各分割ブロックを所定間隔で子局に順次送信する同報送信工程と、
   子局が親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定する判定工程と、
   親局が前記２以上の特定数の分割ブロックを同報通信で送信する毎に、または親局が前記２以上の特定数の分割ブロックを同報通信で送信している期間に子局から抜けブロックの発生状況に関する情報を取得する確認工程と、
   当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して親局が当該抜けブロックをユニキャスト通信により再送するユニキャスト再送工程と、
   各子局における抜けブロックの数が第１の所定数に達した場合、当該子局は前記同報送信工程またはユニキャスト再送工程により抜けブロックを受信する度に抜けブロックの数をデクリメントし、抜けブロックの数が第２の所定数に低減するまでは抜けブロック以外の分割ブロックの受信を拒否し、抜けブロックの数が第２の所定数にまで低減すれば抜けブロック以外の分割ブロックの受信を許可する受信制限工程と
   を含むことを特徴とするファームウェアのアップデート方法。
2. 前記親局は、前記同報送信工程において分割ブロックを順次送信する送信間隔を、全子局における抜けブロックの発生数と抜けブロックを発生した子局の台数との少なくとも一方に基づいて調整することを特徴とする請求項１記載のファームウェアのアップデート方法。
3. 前記親局は、前記同報送信工程において、前記分割ブロックを同報通信により子局に順次送信する際に、複数の分割ブロックで構成されるセット毎に複数回送信することを特徴とする請求項１または２記載のファームウェアのアップデート方法。
4. 前記親局は、前記同報送信工程において、前記複数の分割ブロックで構成されるセット毎に送信する回数を、全子局での抜けブロックの発生数と抜けブロックを発生した子局の台数との少なくとも一方に基づいて調整することを特徴とする請求項３記載のファームウェアのアップデート方法。
5. 前記親局が前記同報送信工程において前記複数の分割ブロックで構成されるセットを送信すると、前記子局は親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定し、親局は当該抜けブロックの発生状況に関する情報を子局から取得し、次回に親局が前記複数の分割ブロックで構成されるセットを再送する場合、親局は、前記取得した抜けブロックの発生状況に関する情報に基づいて、抜けブロックのみを再送することを特徴とする請求項３または４記載のファームウェアのアップデート方法。
6. 前記子局が、前記判定工程において抜けブロックの発生を検知した場合、前記親局に対して抜けブロックが発生した旨の通知を行う通知工程を含み、
   通知情報を受信した親局が、前記確認工程において子局から抜けブロックの発生状況に関する情報を取得し、前記ユニキャスト再送工程において、当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して当該抜けブロックをユニキャスト通信により再送する
   ことを特徴とする請求項１乃至５いずれか記載のファームウェアのアップデート方法。
7. 電力線搬送通信を行う親局と子局とを備える電力線搬送通信システムであって、
   親局は、
   ファームウェアを複数の分割ブロックに分割する分割手段と、
   当該分割された分割ブロックに識別情報を付与する付与手段と、
   当該識別情報が付与された２以上の特定数の分割ブロック毎に同報通信により各分割ブロックを所定間隔で子局に順次送信する送信手段とを備え、
   子局は、
   親局から受信した分割ブロックの識別情報に基づいて抜けブロックの発生状況を判定する管理手段を備え、
   親局は、
   前記２以上の特定数の分割ブロックを同報通信で送信する毎または前記２以上の特定数の分割ブロックを同報通信で送信している期間に子局から抜けブロックの発生状況に関する情報を取得する確認手段と、
   当該取得した抜けブロックの発生状況に関する情報に基づいて抜けブロックが発生したと判断された子局に対して当該抜けブロックをユニキャスト通信により再送する再送手段とをさらに備え、
   子局の管理手段は、自局における抜けブロックの数が第１の所定数に達した場合、親局から抜けブロックを受信する度に抜けブロックの数をデクリメントし、抜けブロックの数が第２の所定数に低減するまでは抜けブロック以外の分割ブロックの受信を拒否し、抜けブロックの数が第２の所定数にまで低減すれば抜けブロック以外の分割ブロックの受信を許可する
   ことを特徴とする電力線搬送通信システム。

Images