JP2023127066A - エレベーターシステム及びファームウェア送信方法 - Google Patents

Abstract

【課題】エレベーターの運行状態に応じてファームウェアを更新するコントローラの順番を変更可能なエレベーターシステムを提供する。【解決手段】エレベーターシステム１００が備えるマスタコントローラ３０は、エレベーター１５の運行状態に応じて、複数のサブコントローラ４０に対するファームイメージ３１の送信順番を生成し、送信順番が優先されるサブコントローラ４０に対して、ファームイメージ３１及び送信順番を含むパケット５０を送信し、送信順番が優先されるサブコントローラ４０は、マスタコントローラ３０からパケット５０を受信してファームイメージ３１の更新を行い、送信順番が次に優先されるサブコントローラ４０にパケット５０を送信する。【選択図】図３

Description

本発明は、エレベーターシステム及びファームウェア送信方法に関する。

従来、エレベーターシステム１００は、複数の制御コントローラから構成されている。そして、任意の１台の制御コントローラが、複数の制御コントローラのプログラムを更新する、１対Ｎの構成でプログラム更新するシステムが知られている。

特許文献１には、「サーバは、複数のエレベーターの中の予め定められた１台の代表エレベーターに対して、代表エレベーター上にある更新前の版の制御プログラムと、更新すべき最新版の制御プログラムとの差分情報を含む更新データを通信回線を介して配信し、代表エレベーターは、サーバから受信した更新データに基づいて自己の制御プログラムを更新するとともに、予め定められた転送順番に従って次に転送すべきエレベーターに対して、更新データをネットワークを介して送信する」と記載されている。

特許文献２には、「伝送手順制御手段は、伝送路を介して複数の制御装置へ更新用の運転制御プログラムを伝送する伝送時間と、複数の制御装置が更新用の運転制御プログラムに書き換える書換時間とからエレベーターの停止時間を算出し、算出した停止時間に基づいて複数の制御装置へ更新用の運転制御プログラムを伝送する順番を選択する」と記載されている。

特許第４９６３２９２号 特許第５０７２４１１号

特許文献１に記載されているように、予め１台の代表エレベーターを定め、且つ予め更新データの転送順番を定めている場合、代表エレベーター以外のエレベーターから更新データを更新することはできない。代表エレベーターに不具合が発生すると、代表エレベーターの処理の負荷が高い場合等、データの更新処理を実施できない場合があった。さらに、予め定められた順番でしか更新処理を実行できないため、順番が決められた全てのエレベーターが更新処理を実行できる状態でしかエレベーターが更新処理を完遂することができなかった。例えば、１基のエレベーターのみが不具合発生や保守作業中であっても、制御処理が高負荷であると、更新処理を受け付けないため、通信処理に遅延又は通信遮断が起きる等の課題があった。

また、特許文献２には、伝送時間と書換時間とに基づいてエレベーターの停止時間を算出することが記載されている。しかし、プログラム容量、通信デバイス性能、及び、記憶デバイス書換性能は、予め定められた条件に該当しなければならない。特許文献１に記載された技術と同じく、実際の運用状態に適していない場合もあった。

本発明はこのような状況に鑑みて成されたものであり、エレベーターの運行状態に応じてファームウェアを更新するコントローラの順番を変更することを目的とする。

本発明に係るエレベーターシステムは、ファームウェアを送信するマスタコントローラと、ファームウェアを受信してファームウェアを更新するサブコントローラとを備える。マスタコントローラは、エレベーターの運行状態に応じて、複数のサブコントローラに対するファームウェアの送信順番を生成し、送信順番が優先されるサブコントローラに対して、ファームウェア及び送信順番を含む第１送信データを送信する。送信順番が優先されるサブコントローラは、マスタコントローラから第１送信データを受信してファームウェアの更新を行い、送信順番が次に優先されるサブコントローラに第１送信データを送信する。

本発明によれば、エレベーターの運行状態に応じてファームウェアの送信順番を生成するため、予めファームウェアの送信順番を決める必要がない。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の一実施形態に係るエレベーターシステムの全体構成例を示す図である。 本発明の一実施形態に係るコントローラのハードウェア構成例を示すブロック図である。 本発明の一実施形態に係るマスタコントローラとサブコントローラを含むパケット通信システムの基本構成例を示すブロック図である。 本発明の一実施形態に係るパケットの基本構成例を示す図である。図４Ａは、パケットの内部構成例を示す図である。図４Ｂは、マスタコントローラと、各サブコントローラとで生成されるパケットの例を示す図である。 本発明の一実施形態に係るパケット通信システムの正常通信処理の例を示すフローチャートである。 本発明の一実施形態に係るサブコントローラの処理の例を示すフローチャートである。 本発明の一実施形態に係る異常通知メッセージのパケット構成例を示す図である。 本発明の一実施形態に係るサブコントローラが異常の発生を通知する処理の例を示すフローチャートである。 本発明の一実施形態に係るサブコントローラがパケット送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。 本発明の一実施形態に係る通信エラーが発生したサブコントローラをスキップして、ファームイメージの更新処理を継続する処理の例を示すフローチャートである。 本発明の一実施形態に係るエレベーターコントローラと、複数のフロアコントローラと、で構成されたツリー構造の例を示すブロック図である。 本発明の一実施形態に係るフロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係るフロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る群管理コントローラと、複数のエレベーターコントローラと、で構成されるツリー構造の例を示すブロック図である。 本発明の一実施形態に係るエレベーターの呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る通信コントローラと、複数の群管理コントローラと、で構成されるツリー構造の例を示すブロック図である。 本発明の一実施形態に係るエレベーターへの呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。 本発明の一実施形態に係る群管理コントローラがファームイメージを適用するための再起動を判断する処理の例を示すフローチャートである。 本発明の一実施形態に係るエレベーターコントローラがファームイメージを適用するための再起動を判断する処理の例を示すフローチャートである。 本発明の一実施形態に係るフロアコントローラがファームイメージを適用するために再起動する処理の例を示すフローチャートである。

以下、本発明を実施するための形態に係るエレベーターシステム及びファームウェア送信方法の一例について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。なお、本発明は以下の実施形態に限定されるものではない。

［一実施形態］
図１は、本発明の一実施形態に係るエレベーターシステム１００の全体構成例を示す図である。
図１では、エレベーターシステム１００の説明を簡略化するために、１基のエレベーター１５の詳細な構成要素を図示しており、他のエレベーター１５については詳細な構成要素の図示を省略する。

エレベーターシステム１００は、複数のエレベーター１５を管理し、運行を監視し、保守するために、例えば、エレベーター１５から遠隔に設置されているセンタ１を有する。また、エレベーターシステム１００は、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、かごコントローラ１０、フロアコントローラ１１及び保守端末１９を有する。

センタ１は、専用回線のような有線又は無線による閉回路網やインターネットのような公衆回線である通信網２を経由して通信コントローラ３に接続されている。
通信コントローラ３は、センタ１とエレベーターとの間のデータ転送、遠隔操作及び遠隔保守を実行するための通信を担うコントローラである。通信コントローラ３は、通信路１７を介して、群管理コントローラ４に接続されている。通信コントローラ３は、複数のエレベーターコントローラ５の動作を制御する複数の群管理コントローラ４に対する通信を制御する。

群管理コントローラ４は、エレベーター１５の動作を制御する複数のエレベーターコントローラ５の動作を制御する。そこで、群管理コントローラ４は、複数のエレベーター１５をエレベーターグループ１８としてまとめて運行制御する。群管理コントローラ４は、複数のエレベーターコントローラ５と、通信路１６を介して接続されている。

エレベーター１５は、エレベーターコントローラ５、かごコントローラ１０及びフロアコントローラ１１を備える。

エレベーターコントローラ５は、エレベーター１５の動作を制御しており、かご７の上下移動及び停止の制御を実現することで利用者に上下移動のサービスを提供する。このサービスを提供するため、エレベーターコントローラ５は、主機であるモーター６を制御して、かご７と、カウンターウェイト８と、を連結しているロープ９の動きを操作する。エレベーターコントローラ５は、１台のかごコントローラ１０と、複数のフロアコントローラ１１と、通信路１２を経由して接続されている。

かごコントローラ１０は、かご７内に設置されている行先階ボタン及びドア開閉ボタン１３の、利用者による操作状況に対応して、かごドアの開閉動作を行い、エレベーターコントローラ５にかご状況の変化を伝える。

フロアコントローラ１１は、エレベーター１５が昇降するフロアごとに設けられ、フロアの状況をエレベーターコントローラ５に伝える。例えば、フロアコントローラ１１は、各階床に設置される上下ボタン１４の、各階における利用者による操作状況を監視して、エレベーターコントローラ５にフロアの状況変化を伝える。上下ボタン１４の代わりに、乗客がかごへの乗車前に行先階を登録可能な行先階登録装置を具備するエレベーターシステムもある。

図１を示して説明したように、エレベーターシステム１００は、複数のコントローラが１対Ｎ構成であるツリー構造が多段に階層化されたシステムである。また、同一種別のコントローラが複数存在する場合には、当該コントローラの任意の一台をツリー構造のルートとし、残りのコントローラをツリー構造のリーフとしてツリー構造を構成することも可能である。

センタ１は、各コントローラで用いられるファームウェアをファームイメージ３１（後述する図３を参照）として不図示の記憶部に保持している。センタ１は、通信網２、通信路１２、１６、１７と、通信路に接続されている各種のコントローラと、を経由することにより、任意のコントローラにファームウェアを送信することが可能である。

通信網２に接続される保守端末１９は、センタ１からファームウェアをコピーすることができる。保守端末１９は、ファームウェアをコピーした後、任意のコントローラに接続されることで、保守端末１９が保持するファームウェアを、接続したコントローラに出力可能である。このため、保守端末１９は、保守端末１９に接続したコントローラにファームウェアを保持させることができる。また、ファームウェアを保持したコントローラは、自身のファームウェアをアップデートしたり、他のコントローラにファームウェアを送信したりすることができる。

なお、各コントローラがファームウェアを更新する方法としては、ファームウェアの全体イメージを用いた全体更新の場合と、新旧のファームウェアの差分イメージを用いて部分的に差分更新する場合と、がある。

＜コントローラのハードウェア構成例＞
次に、エレベーターシステム１００が備える各コントローラ２０のハードウェア構成について、図２を参照して説明する。ここでは、通信コントローラ３、群管理コントローラ４，エレベーターコントローラ５、かごコントローラ１０，フロアコントローラ１１が備える計算機のハードウェア構成を説明する。これらを総称してコントローラ２０と呼ぶ。

図２は、コントローラ２０のハードウェア構成例を示すブロック図である。
コントローラ２０は、システムバス２１に、それぞれ接続されたＭＰＵ（Micro Processing Unit）２２、ＲＯＭ（Read Only Memory）２３、ＲＡＭ（Random Access Memory）２４、及び通信インタフェース２５を備える。なお、ＭＰＵに類する演算装置の上位概念としてＣＰＵ（Central Processing Unit）がある。

ＭＰＵ２２、ＲＯＭ２３、ＲＡＭ２４は、処理部を構成する。ＭＰＵ２２は、本実施形態の形態で、係る各機能を実現するプログラムコードのバイナリデータであるファームイメージ３１（後述する図３を参照）はＲＯＭ２３に記録されており、ＲＯＭ２３からリードしてＲＡＭ２４にロードし、プログラムコードを実行する。また、ＭＰＵ２２は、プログラムコードをＲＯＭ２３から直接リードしてそのままプログラムコードを実行する場合もある。

ＲＡＭ２４には、ＭＰＵ２２で行われる処理の実行途中で発生した変数やパラメータ等が一時的に書き込まれ、これらの変数及びパラメータ等がＭＰＵ２２から適宜読み出される。

コントローラ２０は、通信インタフェース２５を通じて、複数のコントローラ２０間でデータを送受信することが可能である。各コントローラ２０間を接続する通信路として、例えば、ＲＳ－４８５のようなマルチドロップ形態のシリアル通信デバイスや、イーサネット（登録商標）のような複数のトポロジを提供する有線の通信路であるＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、さらには無線の通信路であるＲＡＮ（Radio Area Network）がある。各コントローラ２０は、例えば、Ｗｉ－Ｆｉ（登録商標）のような無線や、インフラ無線通信によって、各コントローラのデータを装置間で送受信することが可能となる。

なお、ＲＯＭ２３へのデータの書換時に生じる不具合に対処するために、コントローラ２０が複数のＲＯＭ２３を搭載する場合がある。この構成であれば、一方のＲＯＭ２３に現在のファームイメージ３１（ファームウェアの一例）が記録され、他方のＲＯＭ２３に新規のファームイメージ３１が記録される。後者のＲＯＭ２３に対する新規のファームイメージ３１の書換時に不具合が発生しても、前者のＲＯＭ２３には、現在のファームイメージ３１が残っているので、現状復帰が可能である。また、コントローラ２０は、ＲＯＭ２３が複数ある場合には、所望のファームイメージ３１が記憶されているＲＯＭ２３を選択して起動する。

＜マスタコントローラとサブコントローラの基本システム構成＞
次に、図１に示したエレベーターシステム１００の実施形態に基づいて、本発明の実施形態に係るマスタコントローラとサブコントローラの基本システム構成について説明する。
図３は、マスタコントローラ３０とサブコントローラ４０を含むパケット通信システム２００の基本構成例を示すブロック図である。

パケット通信システム２００は、ファームイメージ３１を送信するマスタコントローラ３０と、ファームイメージ３１を受信してファームイメージ３１を更新するサブコントローラ４０とを備えるエレベーターシステム１００の一形態である。図１に示したように、エレベーターシステム１００は、複数のコントローラが１対Ｎで接続されるツリー構造が、多重に組み合わさっている大規模なシステムである。ここでは、１台のコントローラ２０をマスタコントローラ３０、Ｎ台のコントローラ２０をサブコントローラ４０としたパケット通信システム２００について説明する。また、パケット通信システム２００では、同階層、又は異なる階層のコントローラ２０をマスタとサブの関係としている。マスタとサブの関係は、隣接する階層だけでなく、一又は複数の階層をまたいでもよい。例えば、一つの群管理コントローラ４をマスタコントローラ３０とし、エレベーターコントローラ５をまたいで、複数のフロアコントローラ１１をサブコントローラ４０とすることも可能である。

マスタコントローラ３０は、エレベーター１５の運行状態に応じて、複数のサブコントローラ４０に対するファームイメージ３１の送信順番を生成する。そして、マスタコントローラ３０は、送信順番が優先されるサブコントローラ４０に対して、ファームイメージ３１及び送信順番を含むパケット５０を送信する。マスタコントローラ３０は、通信路３７を介して、サブコントローラ４０に接続されている。マスタコントローラ３０からパケット５０が直接送信されるサブコントローラ４０は、送信順番が最先であることが多い。ただし、パケット５０を受信するサブコントローラ４０に異常が生じた場合、マスタコントローラ３０は、異常が生じたサブコントローラ４０の次の送信順番であるサブコントローラ４０を優先してパケット５０を送信することがある。このようにマスタコントローラ３０は、送信順番が優先されるサブコントローラ４０にパケット５０を送信するので、送信順番が優先されるサブコントローラ４０がパケット５０を受信できる。また、パケット５０を受信したサブコントローラ４０は、送信順番が次に優先されるサブコントローラ４０にパケット５０を送信するので、パケット５０が複数のサブコントローラ４０を転送されることとなる。このため、マスタコントローラ３０が複数のサブコントローラ４０にパケット５０を一斉配信する場合に比べて、各サブコントローラ４０にパケット５０を確実に送信することが可能となる。

このマスタコントローラ３０は、ファームイメージ３１、イメージ分割部３２、運行状態取得部３３、順番生成部３４、パケット生成部３５及びマスタ通信部３６を備える。

ファームイメージ３１は、ファームウェアの実体である。ファームウェアは、コントローラ２０の動作を制御するプログラムの一例である。ファームイメージ３１は、マスタコントローラ３０に設けられたＲＯＭ２３等に保存される。

イメージ分割部３２は、ファームイメージ３１を分割するファームウェア分割部の一例として用いられる。イメージ分割部３２がファームイメージ３１を分割するため、１回当たりの通信でサブコントローラ４０に送信されるパケット５０のバイナリデータ５７（後述する図４Ａを参照）のデータ量が減少する。マスタコントローラ３０とサブコントローラ４０との間の通信路３７の通信効率を向上させることができる。

運行状態取得部３３は、エレベーターの運行状態を取得する。エレベーター１５の運行状態は、例えば、かご状態、呼びの割当状態等を含む。運行状態取得部３３は、かごコントローラ１０、フロアコントローラ１１等から運行状態を取得できる。

順番生成部３４は、イメージ分割部３２により分割されたファームイメージ３１の送信先であるサブコントローラ４０の送信順番を、運行状態取得部３３が取得したエレベーター１５の運行状態に応じて生成する。なお、ファームイメージ３１のファイルサイズが十分に小さい場合、分割されないファームイメージ３１がサブコントローラ４０に送信されることがある。

パケット生成部３５（第１送信データ生成部の一例）は、順番生成部３４が生成した送信順番にしたがってマスタコントローラ３０がサブコントローラ４０にファームイメージ３１を送信するためのパケット５０を生成する。パケット５０は、第１送信データの一例として用いられる。後述する図４に示すように、パケット生成部３５は、パケット５０の送信元であるマスタコントローラ３０を識別する情報（送信元５１）と、パケット５０の送信先であるサブコントローラ４０を識別する情報（送信先５２）と、送信順番（送信順番５３）と、分割されたファームイメージ３１の構築順番（番号５６）と、分割されたファームイメージ３１（バイナリデータ５７）とを含むパケット５０を生成する。

マスタ通信部３６は、順番生成部３４により生成された送信順番が最先であるサブコントローラ４０に対して、パケット生成部３５により生成されたパケット５０を送信する。

送信順番が優先されるサブコントローラ４０は、マスタコントローラ３０からパケット５０を受信してファームイメージ３１の更新を行い、送信順番が次に優先されるサブコントローラ４０にパケット５０を送信する。このサブコントローラ４０は、サブ通信部４１、パケット解釈部４２、送信先抽出部４３、パケット生成部４４、イメージ構築部４５及びファームイメージ記憶部４６を備える。

サブ通信部４１は、通信路３７に接続されている。このサブ通信部４１は、通信路３７を介してマスタコントローラ３０、又はパケット５０の送信元である他のサブコントローラ４０からパケット５０を受信する第２通信部の一例として用いられる。

パケット解釈部４２は、サブ通信部４１が受信したパケット５０を解釈するデータ解釈部の一例として用いられる。パケット５０の解釈は、規定のパケットフォーマットに従って、パケット５０からデータを取り出し、所定の出力先にデータを出力する処理である。パケット解釈部４２が解釈したファームイメージ３１の分割されたイメージデータは、イメージ構築部４５に出力される。また、パケット解釈部４２によるパケット５０の解釈結果は送信先抽出部４３に出力される。

送信先抽出部４３は、パケット解釈部４２が解釈した送信順番に基づいて、パケット５０の次の送信先であるサブコントローラ４０を抽出する。

パケット生成部４４は、パケット５０の次の送信先であるサブコントローラ４０にファームイメージ３１を送信するためのパケット５０（第２送信データの一例）を生成する第２送信データ生成部の一例として用いられる。例えば、パケット生成部４４は、パケット解釈部４２によるパケット５０の解釈結果と、送信先抽出部４３により抽出されたパケットの送信先である残りのサブコントローラ４０の送信順番とに基づいて、新たなパケット５０を生成する。パケット生成部４４が生成するパケット５０に含まれるファームイメージ３１の分割されたイメージデータは、基本的には、サブ通信部４１が受信したパケット５０に含まれる、ファームイメージ３１の分割されたイメージデータと同じである。パケット生成部４４によりパケット５０が生成されると、サブ通信部４１が、パケット５０に格納された送信順番に基づいて、次の送信先であるサブコントローラ４０にパケット５０を送信する。

イメージ構築部４５は、パケット解釈部４２が解釈した、分割されたファームイメージ３１を構築順番に従って元のファームイメージ３１に構築するファームウェア構築部の一例として用いられる。イメージ構築部４５は、パケット解釈部４２から受け取った、分割されたファームイメージ３１を溜めるバッファ（不図示）を有する。そして、分割されたファームイメージ３１がバッファに十分溜まると、ファームイメージ３１を再構築する。

ファームイメージ記憶部４６は、イメージ構築部４５により構築されたファームイメージ３１を記憶する。サブコントローラ４０が更新するファームイメージ３１は、ファームイメージ記憶部４６から読み出されたものである。ファームイメージ記憶部４６には、複数のファームイメージ３１がバージョンごとに世代管理されてもよい。このため、仮に更新が失敗した場合には、以前のファームイメージ３１に戻すことができる。

サブコントローラ４０の各部の処理が繰り返し行われることで、エレベーター１５の運行状況に応じた効率のよいサブコントローラ４０の送信順番に基づいてファームイメージ３１の送信が実現される。

運行状態が、例えば深夜時間帯のようにエレベーターシステム１００全体が待機状態である場合には、コントローラ２０の順番が更新処理に与える影響は少ない。このため、パケット生成部４４は、パケット５０がサブコントローラ４０に送信される順番を、階床数に応じた昇順／降順の順番、コントローラ２０に割り当てられているシリアル番号の順番、又は乱数を用いて決定してもよい。

マスタコントローラ３０とサブコントローラ４０の関係は、保守端末１９を使用するユーザが決定してもよい。また、保守端末１９からファームイメージ３１をダウンロードしたコントローラをマスタコントローラ３０とし、他のコントローラをサブコントローラ４０として自動的に決定してもよい。

＜パケットの基本構成＞
次に、図３に示したパケット通信システム２００において生成されるパケット５０の基本構成について図４を用いて説明する。
図４は、パケット５０の基本構成例を示す図である。

図４Ａは、パケット５０の内部構成例を示す図である。
パケット５０は、パケット５０の送信元５１のデータと、パケット５０の送信先５２のデータと、パケット５０の送信順番５３のデータと、ファームイメージ３１を分割したイメージデータ５４と、パケット５０のデータ不整合を確認するためのチェックデータ５５と、から構成される。

イメージデータ５４は、図３に示したイメージ分割部３２によってファームイメージ３１が分割された複数のイメージデータの一つである。このため、イメージデータ５４は、ファームイメージ３１が分割された構築順番を示す番号５６と、分割されたイメージの実体であるバイナリデータ５７と、から構成される。このようにパケット５０の構造を定義することにより、マスタコントローラ３０及びサブコントローラ４０は、順番生成部３４で生成された複数のサブコントローラ４０の順番通りにファームイメージ３１を送信できる。このため、各サブコントローラ４０は、ファームイメージ３１を受信した順番でファームイメージ３１を更新することができる。

なお、イメージデータ５４又はバイナリデータ５７には、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、フロアコントローラ１１のうち、どのコントローラに対応したファームウェアなのかを示す識別データが含まれている。よって、マスタコントローラ３０である場合に各コントローラに搭載されるイメージ構築部４５は、識別データによって、別のコントローラ向けのファームウェアを識別することが可能である。

図４Ｂは、マスタコントローラ３０と、各サブコントローラ４０とによって生成されるパケット５０の構成例を示す図である。ここでは、４階床の建屋に設けられたエレベーター１５を想定する。マスタコントローラ３０がエレベーターコントローラ５に対応し、サブコントローラ４０がフロアコントローラ１１に対応する。そして、送信順番５３が、４階―２階―３階―１階の順番として生成された場合を示している。ここで、番号５６に格納される「１」は、分割されたファームイメージ３１のうち、１番目のバイナリデータであることを表している。

マスタコントローラ３０は、送信元５１に自身のＩＤ番号「０」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「４」を設定し、送信順番５３にＩＤ番号「４」より後の順番「２－３－１」を設定したパケット５０（１）を生成する。このため、送信順番５３が最先である４階のフロアコントローラ１１にパケット５０（１）が送信される。

４階のフロアコントローラ１１は、パケット５０（１）を受信すると、送信元５１に自身のＩＤ番号「４」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「２」を設定し、送信順番５３にＩＤ番号「２」より後の順番「３－１」を設定したパケット５０（２）を生成する。このため、送信順番５３が最先である２階のフロアコントローラ１１にパケット５０（２）が送信される。

２階のフロアコントローラ１１は、パケット５０（２）を受信すると、送信元５１に自身のＩＤ番号「２」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「３」を設定し、送信順番５３にＩＤ番号「３」より後の順番「１」を設定したパケット５０（３）を生成する。このため、送信順番５３が最先である３階のフロアコントローラ１１にパケット５０（３）が送信される。

３階のフロアコントローラ１１は、パケット５０（３）を受信すると、送信元５１に自身のＩＤ番号「３」を設定し、送信先５２に送信順番５３の最初のＩＤ番号「１」を設定し、自身が送信順番の最後となるので送信順番５３を無設定にしたパケット５０（４）を生成する。このため、送信順番５３が最先である１階のフロアコントローラ１１にパケット５０（４）が送信される。

パケット５０をこのような構造にすることで、マスタコントローラ３０から送信されたパケット５０が、エレベーター１５の運行状態に応じた送信順番５３に基づいて、複数のサブコントローラ４０を順番に経由して送信される。このため、マスタコントローラ３０の処理の負荷を軽減できるとともに、サブコントローラ４０もエレベーター１５の運行状態に基づいて効率よく処理を実行することが可能となる。また、本実施の形態に係る通信方法は、マスタコントローラ３０から複数のサブコントローラ４０にパケットを一斉配信するブロードキャストに比べてネットワークを占有しなくて済む。また、マスタコントローラ３０は、ファームイメージ３１の送信順番の割当てを管理しやすくなる。

なお、多くのコントローラ２０が待機状態の場合、例えば利用が少ない深夜等の場合には、運転状態によるコントローラ２０の状態に差異が少ない。このため、送信順番５３を、単純に、コントローラ２０のＩＤ順に、またはフロア番号順にしても構わない。

また、任意のサブコントローラ４０から、マスタコントローラ３０に直接通信することを想定した場合には、送信元５１と、送信先５２に加えて、マスタコントローラ３０に相当するパケットの送信源の項目をパケットに追加してもよい。サブコントローラ４０からマスタコントローラ３０への通信は、例えば、サブコントローラ４０が管理する範囲のエレベーター１５の運行状況をマスタコントローラ３０に通知するために行われる。また、サブコントローラ４０からマスタコントローラ３０への通信は、エレベーター１５の通常運転における状態通知に使われる。また、サブコントローラ４０が、複数のサブコントローラ４０を逆に辿らずに、マスタコントローラ３０に対して直接不具合情報を送るためにも使われる。

＜正常時の通信処理＞
次に、図３に示したパケット通信システム２００における処理（ファームウェア送信方法の一例）について、図５以降のフローチャートを参照して説明する。
図５は、パケット通信システム２００の正常通信処理の例を示すフローチャートである。図５は、マスタコントローラ３０が、ファームイメージ３１を分割し、エレベーター１５の運行状態に基づいて生成した順番でパケット５０を送信することで、全てのサブコントローラ４０にファームイメージ３１を配布する処理を表している。

始めに、マスタコントローラ３０のイメージ分割部３２（図３参照）は、ファームイメージ３１を通信に適したサイズに分割する（Ｓ１）。イメージ分割部３２は、ファームイメージ３１を分割する時に、分割順が分かるように、例えば昇順とした番号５６（図４参照）も生成する。なお、最後の分割したファームイメージ３１の番号は特別な終端番号とする場合がある。この終端番号を、パケット５０の受信側のコントローラ２０が共有していれば、分割されたファームイメージ３１の個数が多くても、コントローラ２０が最後まで受信することができる。

次に、運行状態取得部３３は、エレベーター１５の運行状態を取得する（Ｓ２）。次に、順番生成部３４は、運行状態に基づいて、分割されたファームイメージ３１を通信する、サブコントローラ４０の順番を生成する（Ｓ３）。次に、パケット生成部３５は、順番生成部３４により生成された順番に従って、次のサブコントローラ４０へ送信するパケット５０を生成する（Ｓ４）。そして、マスタ通信部３６は、生成されたパケット５０を、順番に従って、次のサブコントローラ４０に送信する（Ｓ５）。

マスタ通信部３６は、パケット５０の送信が成功したか否かを確認する（Ｓ６）。パケット５０の送信が失敗した場合（Ｓ６のＮＯ）、マスタ通信部３６は、サブコントローラ４０からの異常通知を受信した後（Ｓ７）、本処理を終了する。なお、一定時間後、マスタコントローラ３０は、パケット５０を再送信するために、本処理を再実行する。

一方、パケット５０の送信が成功した場合（Ｓ６のＹＥＳ）、マスタ通信部３６は、ファームイメージ３１を分割した残りが存在するか否かを確認する（Ｓ８）。ファームイメージ３１を分割した残りが有る場合には（Ｓ８のＹＥＳ）、マスタコントローラ３０は、ステップＳ１に戻って、処理を繰り返す。残りが無い場合には（Ｓ８のＮＯ）、マスタコントローラ３０は、本処理を終了する。

次に、サブコントローラ４０の処理について、図６を参照して説明する。
図６は、サブコントローラ４０の処理の例を示すフローチャートである。

始めに、サブコントローラ４０のサブ通信部４１は、マスタコントローラ３０又は一つ前の順番のサブコントローラ４０からパケット５０を受信する（Ｓ１１）。

次に、パケット解釈部４２は、サブ通信部４１が受信したパケット５０を解釈し（Ｓ１２）、送信元５１、送信先５２、送信順番５３、分割されたイメージデータ５４、チェックデータ５５のそれぞれを識別する。ステップＳ１２のパケット５０を解釈する処理は、後述する図８に詳細な例が示される。

次に、送信先抽出部４３は、パケット解釈部４２が識別した送信順番５３から次の送信先を抽出する（Ｓ１３）。また、イメージ構築部４５は、分割されたイメージデータ５４からファームイメージ３１を順次構築する（Ｓ１４）。ステップＳ１３，Ｓ１４の処理は、並列処理としているが、逐次処理としてもよい。

次に、送信先抽出部４３は、分割されたイメージデータ５４を送る次の送信先が存在するか否かを送信順番５３で確認する（Ｓ１５）。

次の送信先が存在する場合（Ｓ１５のＹＥＳ）、パケット生成部４４は、新たに送信先５２を次のサブコントローラ４０に変更したパケット５０を生成する（Ｓ１６）。サブ通信部４１は、生成したパケット５０を次のサブコントローラ４０に送信し（Ｓ１７）、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。

パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、サブコントローラ４０は、後述する図７又は図１０に示す異常対応処理を行う（Ｓ１９）。ステップＳ１９は、後述する図９と図１０に示すように異なる行先がある。

一方、パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、又は、ステップＳ１５にて分割されたイメージデータ５４を送る次のサブコントローラ４０が存在しないと判定した場合（Ｓ１５のＮＯ）、パケット解釈部４２は、イメージデータ５４がファームイメージ３１の終端であるか否かを確認する（Ｓ２０）。

ファームイメージ３１の終端であれば（Ｓ２０のＹＥＳ）、パケット解釈部４２がイメージ構築部４５によるファームイメージ３１の構築が終了したかを確認した後、サブコントローラ４０は、本処理を終了する。一方、ファームイメージ３１の終端でなければ（Ｓ２０のＮＯ）、ステップＳ１１に戻って、サブコントローラ４０が処理を繰り返す。

なお、サブ通信部４１は、分割されたイメージデータ５４を含むパケット５０を受信する度に、パケット解釈部４２が解釈した送信元５１を記憶しておいてもよい。この場合、サブ通信部４１は、パケット５０の順番を逆に辿って通信することで、マスタコントローラ３０と、通信することも可能となる。例えば、サブ通信部４１は、サブコントローラ４０の不具合発生をマスタコントローラ３０に通知することも可能となる。

図５と図６に示した処理フローにより、マスタコントローラ３０は、エレベーター１５の運行状態に応じた順番の最初のサブコントローラ４０にパケット５０を送信するだけで、ファームイメージ３１を複数のサブコントローラ４０全てに対して自ら配信することなく、ファームイメージ３１の更新が可能となる。複数のサブコントローラ４０は、マスタコントローラ３０が生成した順番に従って、他のサブコントローラ４０にファームイメージ３１を通信する。このようにマスタコントローラ３０は、効率の良い通信処理を組み合わせることで、全てのサブコントローラ４０のファームイメージ３１を更新することが可能となる。

なお、ファームイメージ３１のサイズが小さい、又は差分アップデートで差分イメージのデータサイズが小さい場合には、イメージ分割せずにパケット５０を通信することがある。この場合、１回の通信でマスタコントローラ３０とサブコントローラ４０の処理が終了する場合もある。

＜通信異常の通知処理＞
次に、通信異常が発生した時にサブコントローラ４０がマスタコントローラ３０に異常の発生を通知する処理について、図７～図１０を用いて説明する。

始めに、本処理で用いられる異常通知メッセージの構成例を説明する。
図７は、異常通知メッセージのパケット構成例を示す図である。

パケット５０を受信した時に通信異常を検知したサブコントローラ４０は、パケット５０の送信元である前段のサブコントローラ４０に対して異常通知メッセージを送信する。この異常通知メッセージは、図７に示すように、送信元５１のデータと、送信先５２のデータと、イメージデータ５４のデータと、チェックデータ５５とで構成される。なお、送信順番５３にはデータが記憶されない。

そして、イメージデータ５４は、コマンド５８と、このコマンド５８に対応するコマンドデータ５９とで構成される。本実施形態においては、コマンド５８に「異常発生通知コマンド」が格納され、コマンドデータ５９には通信異常が発生したコントローラ２０のＩＤが格納される。

図８は、サブコントローラ４０が異常の発生を通知する処理の例を示すフローチャートである。ここでは、図６のステップＳ１２に示したパケット解釈処理の詳細な例を説明する。

始めに、任意のコントローラ２０のパケット解釈部４２は、パケット５０を解釈して、送信順番５３のデータを確認する（Ｓ２１）。次に、パケット解釈部４２は、送信順番５３のデータに送信先のサブコントローラ４０のＩＤが、パケット５０の送信順番で格納されているか否かを確認する（Ｓ２２）。送信順番５３のデータにサブコントローラ４０のＩＤが送信順番で格納されている場合（Ｓ２２のＹＥＳ）、本処理を抜けて、図６のステップＳ１３に移る。

一方、送信順番５３のデータにサブコントローラ４０のＩＤが送信順番で格納されていない場合には（Ｓ２２のＮＯ）、イメージ構築部４５によるファームイメージ３１の更新途中に異常が発生している。この場合、サブ通信部４１は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ３０に送信する。このため、マスタコントローラ３０は、サブコントローラ４０で発生した異常を直ちに把握し、パケット５０の送信停止等の指示等を対処できる。

例えば、パケット解釈部４２は、イメージデータ５４から、図７に示したコマンド５８と、コマンド５８に対応したコマンドデータ５９を解釈する（Ｓ２３）。そして、パケット解釈部４２は、送信元５１を、本処理を実行するサブコントローラ４０自身とし、送信先５２を、パケット５０を送信した前のサブコントローラ４０とに置き換えた異常通知メッセージを生成する（Ｓ２４）。

サブコントローラ４０のサブ通信部４１は、異常通知メッセージを、送信順番が前のサブコントローラ４０に送信する（Ｓ２５）。その後、イメージ構築部４５は、今までに構築してきたファームイメージ３１を消去して（Ｓ２６）、処理を終了する。このため、図６のステップＳ１３，Ｓ１４以降の処理は行われない。

図７に示す異常通知の処理フローにより、サブコントローラ４０は、通信異常が発生した時には処理途中のファームイメージ３１を消去できる。また、サブコントローラ４０は、異常通知メッセージをマスタコントローラ３０に通知することができる。

＜異常時の通信処理＞
次に、通信エラーが発生した異常時において、パケット５０を受信したサブコントローラ４０が構築途中のイメージを消去する場合と、通信エラーが発生したサブコントローラ４０をスキップする場合の各処理について、図９と図１０を用いて説明する。

＜第１の異常通知処理＞
図９は、サブコントローラ４０がパケット５０送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。この異常対応処理では、サブコントローラ４０が、パケット５０の送信失敗時に、これまで送信先のサブコントローラ４０に送信してきたイメージデータ５４を消去する処理が行われる。なお、ステップＳ１７より前の処理は、図６に示した通りであるため、詳細な説明を省略する。

図６に示したように、任意のコントローラ２０のサブ通信部４１は、生成したパケット５０を次のコントローラ２０に送信する（Ｓ１７）。任意のコントローラ２０として、例えば、通信コントローラ３、群管理コントローラ４、エレベーターコントローラ５、かごコントローラ１０、フロアコントローラ１１がある。次に、サブ通信部４１は、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。

パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、コントローラ２０は、図６のステップＳ２０以降の処理に移る。一方、パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、イメージ構築部４５によるファームイメージ３１の更新途中に異常が発生する。この場合、サブ通信部４１は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ３０に送信する。このため、マスタコントローラ３０は、サブコントローラ４０で発生した異常を直ちに把握し、パケット５０の送信停止等の指示等を対処できる。また、サブコントローラ４０は、ファームイメージ３１の更新途中に異常が発生した場合に、イメージ構築部４５が構築していたファームイメージ３１を消去する。このため、サブコントローラ４０では、不正確なファームイメージ３１による更新処理が行われない。

例えば、コントローラ２０のパケット生成部４４は、前の順番のコントローラ２０に通信異常を通知するための異常通知メッセージのパケット５０を生成する（Ｓ３１）。次に、サブ通信部４１は、前の順番のコントローラ２０に異常通知メッセージのパケット５０を送信する（Ｓ３２）。そして、イメージ構築部４５は、これまでに構築してきたファームイメージ３１を消去し（Ｓ３３）、本処理を終了する。

＜第２の異常通知処理＞
図１０は、通信エラーが発生したサブコントローラ４０をスキップして、ファームイメージ３１の更新処理を継続する処理の例を示すフローチャートである。この異常対応処理では、通信エラーが発生していないサブコントローラ４０に対して優先してパケット５０の送信が行われる。例えば、コントローラ２０がサブコントローラ４０であることを想定する。この場合、サブコントローラ４０は、パケット５０の次の送信先であるサブコントローラ４０からファームイメージ３１の更新途中に発生した異常に関する情報を含むデータを受信した場合に、異常に関する情報を含むデータを送信したサブコントローラ４０をスキップして、後続のサブコントローラ４０にパケット５０を送信する。この結果、異常が発生したサブコントローラ４０の更新処理を後回しにして、他のサブコントローラ４０の更新処理が先に行われる。このため、サブコントローラ４０の更新処理の完了率を早期に高めることができる。なお、ステップＳ１６より前の処理は、図６に示した通りであるため、詳細な説明を省略する。

図６に示したように、任意のコントローラ２０のパケット生成部４４がパケット５０を生成し（Ｓ１６）、サブ通信部４１がパケット５０を送信する（Ｓ１７）。次に、サブ通信部４１は、パケット５０の送信が成功したか否かを確認する（Ｓ１８）。

パケット５０の送信が成功した場合（Ｓ１８のＹＥＳ）、コントローラ２０は、図６のステップＳ２０以降の処理に移る。一方、パケット５０の送信が失敗した場合（Ｓ１８のＮＯ）、コントローラ２０は、ステップＳ１９の異常対応処理を行う。

そこで、コントローラ２０のパケット生成部４４は、通信異常が発生したコントローラ２０の次の順番のコントローラ２０に通信異常を通知するための異常通知メッセージのパケット５０を生成する（Ｓ４１）。本処理では、コマンド５８が「スキップ発生通知コマンド」、コマンドデータ５９が「通信異常が発生したコントローラ２０のＩＤ」となる。

次に、サブ通信部４１は、通信異常が発生したコントローラ２０の次の順番のコントローラ２０に異常通知メッセージのパケット５０を送信する（Ｓ４２）。そして、イメージ構築部４５は、パケット５０の送信に失敗したコントローラ２０をスキップした送信順番５３にデータを更新し（Ｓ４３）、ステップＳ１６に移る。

その後、コントローラ２０は、更新した送信順番５３を基にステップＳ１６でパケット５０を生成する。このパケット５０は、コントローラ２０が、スキップ先のコントローラ２０に改めてファームイメージ３１を送信し直すものであり、ステップＳ１７で送信されるパケット５０の送信先は、スキップ先のコントローラ２０である。

このような処理フローにより、通信異常の発生時においても、マスタコントローラ３０は、サブコントローラ４０に対するファームイメージ３１の更新を継続できる。また、サブコントローラ４０は、この通信異常によってスキップしたサブコントローラ４０の情報をマスタコントローラ３０に通知することができる。このため、マスタコントローラ３０は、図１０に示した処理フローによりスキップされたサブコントローラ４０に対して再度、ファームイメージ３１の更新を実行できる。

なお、マスタコントローラ３０が再度、ファームイメージ３１の更新を実行する際には、マスタコントローラ３０からサブコントローラ４０に対して、コマンド５８を「イメージ消去コマンド」としたパケット５０を送る必要がある。イメージ消去コマンドは、サブコントローラ４０にファームイメージ３１の残骸が残っている場合、マスタコントローラ３０がサブコントローラ４０に対して、ファームイメージ３１の残骸の消去を指示するために用いられる。

［ツリー構造］
次に、図１に示したエレベーターシステム１００からマスタコントローラ３０とサブコントローラ４０の関係となるコントローラを抽出した、様々なツリー構造について説明する。

＜エレベーターコントローラ＋フロアコントローラの構成＞
まず、エレベーターコントローラ５と、複数のフロアコントローラ１１と、で構成されるツリー構造について、図１１を用いて説明する。
図１１は、エレベーターコントローラ５と、複数のフロアコントローラ１１と、で構成されたツリー構造の例を示すブロック図である。

１基のエレベーター１５は、一つのエレベーターコントローラ５と、階床数Ｍ分だけ存在するフロアコントローラ１１（１）～１１（Ｍ）とが、通信路１２で接続されたツリー構造である。

上位の群管理コントローラ４からエレベーターコントローラ５にファームイメージ３１がダウンロードされた場合を想定する。そして、エレベーターコントローラ５又は複数のフロアコントローラ１１のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０である構成とする。例えば、エレベーターコントローラ５がマスタコントローラ３０となり、フロアコントローラ１１がサブコントローラ４０となる。マスタコントローラ３０は、送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０は、ファームイメージ３１を更新する。このようにエレベーターコントローラ５と、複数のフロアコントローラ１１（１）～１１（Ｍ）とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。

なお、エレベーターコントローラ５を経由して、任意のフロアコントローラ１１がファームイメージ３１をダウンロードする場合がある。この場合には、一つのフロアコントローラ１１がマスタコントローラ３０となり、それ以外のフロアコントローラ１１及びエレベーターコントローラ５とがサブコントローラ４０となる。このような構成とした場合、ツリー構造の下位のコントローラ（フロアコントローラ１１）がマスタコントローラ３０、上位のコントローラ（エレベーターコントローラ５）がサブコントローラ４０となる。このため、マスタコントローラ３０となるフロアコントローラ１１が、エレベーターコントローラ５から各フロアの呼び登録情報を取得できる。逆に、エレベーターコントローラ５が各フロアコントローラ１１から呼び登録情報を取得することもできる。このため、本実施の形態によれば、ツリー構造の上位、下位の区別による限定なく、パケット通信システム２００が動作することが可能となる。

また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されている他のコントローラ２０がサブコントローラ４０となる。ここで、同一セグメントに接続されているその他のコントローラ２０とは、マスタコントローラ３０が通信コントローラ３の場合には、群管理コントローラ４である。また、マスタコントローラ３０が群管理コントローラ４の場合には、エレベーターコントローラ５である。また、マスタコントローラ３０がエレベーターコントローラ５の場合は、かごコントローラ１０及びフロアコントローラ１１である。

＜フロアの呼び登録の有無に応じた順番の生成処理＞
次に、エレベーターコントローラ５が、運行状態の一つである各フロアにおける呼び登録を基にして、送信順番５３のデータを生成する処理について、図１２を用いて説明する。
図１２は、フロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。

ここでは、マスタコントローラ３０として用いられるエレベーターコントローラ５は、フロアコントローラ１１から運行状態として取得した、各フロアの呼び登録の状況に応じて送信順番を生成し、フロアの滞在人数の状況に応じて、送信順番を並べ替える。このため、フロアコントローラ１１の呼び登録による処理の負荷に応じた送信順番が生成される。また、フロアの滞在人数の状況に応じてエレベーター１５のフロア毎の稼働状況が判明するので、フロアコントローラ１１への送信順番を並べ替えることで、負荷が低いフロアコントローラ１１から順にファームイメージ３１が更新されるようになる。

始めに、エレベーターコントローラ５の運行状態取得部３３は、各フロアのフロアコントローラ１１から、各フロアの呼び登録情報を取得する（Ｓ５１）。次に、エレベーターコントローラ５は、全てのフロアの呼び登録情報を取得できたか否かを判断する（Ｓ５２）。

全てのフロアの呼び登録情報を取得できた場合（Ｓ５２のＹＥＳ）、エレベーターコントローラ５の順番生成部３４は、取得された呼び登録情報に応じて、フロアコントローラ１１の送信順を並び替えて送信順番５３のデータを生成し（Ｓ５３）、本処理を終了する。送信順の並び替えは、呼び登録の有無、及び呼び登録の昇順とする。

一方、呼び登録情報を取得できていないフロアが残っている場合（Ｓ５２のＮＯ）、エレベーターコントローラ５は、再びステップＳ５１に戻って、全てのフロアの呼び登録情報を取得するまでステップＳ５１，Ｓ５２の処理を続ける。

ここで、呼び登録情報を取得できていないフロアでは、フロアコントローラ１１に処理が割り付けられていない。ここで、上下の呼びの一方に登録がある場合には、処理が割り当てられている。さらに、上下両方の呼びの登録がある場合には、処理の負荷が一番大きくなる。

このため、順番生成部３４は、フロアへの呼び登録情報の割り当てに応じた送信順番５３のデータを生成することで、処理割り当ての無いフロアコントローラ１１を先の順番とし、処理割り当てが多いフロアコントローラ１１を後の順番としてファームイメージ３１を適用することができる。なお、群管理コントローラ４が各フロアの呼び登録情報を一括して管理している場合には、エレベーターコントローラ５が群管理コントローラ４から各フロアの呼び登録情報を一括して取得してもよい。

また、順番生成部３４は、ファームイメージ３１の送信順を、エレベーター１５の運行情報に応じた順番にすることで、処理割り当ての無いフロアコントローラ１１からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、効率よく更新データを通信することが可能となる。また、エレベーターコントローラ５はフロアコントローラ１１に更新された新しいファームイメージ３１を適用するために、フロアコントローラ１１をすぐに再起動できる可能性が向上する。

＜各フロアの滞在人数に応じた順番の生成処理＞
次に、エレベーターコントローラ５が、運行状態の一つである各フロアの滞在人数を基にして、送信順番５３のデータを生成する処理について、図１３を用いて説明する。ここで、滞在人数とは、各フロアにいると予想される人数である。かごからフロアに乗降した人数をフロアごとに算出することで滞在人数を求めることができる。
図１３は、フロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。

始めに、エレベーターコントローラ５の運行状態取得部３３は、他のエレベーターコントローラ５、又は各フロアのフロアコントローラ１１から、各フロアの滞在人数を取得する（Ｓ６１）。

次に、エレベーターコントローラ５は、全フロアの滞在人数を取得したか否かを確認する（Ｓ６２）。滞在人数を取得できていないフロアが存在する場合（Ｓ６２のＮＯ）、エレベーターコントローラ５は、再びステップＳ６１に戻って、全てのフロアの滞在人数を取得するまでステップＳ６１，Ｓ６２の処理を続ける。

一方、全フロアの滞在人数を取得できた場合（Ｓ６２のＹＥＳ）、エレベーターコントローラ５の順番生成部３４は、各フロアの滞在人数に応じて、フロアコントローラ１１へのパケット５０の送信順を並べ替えて（Ｓ６３）、送信順番５３のデータを生成する。その後、本処理を終了する。

並べ替えの送信順は、例えば、滞在人数の昇順とする。滞在人数が多い方が、呼び発生の確率が高くなるので、処理の負荷が大きくなる可能性が高くなる。逆に滞在人数が少ないと、呼び発生の確率が低くなるので、処理に余裕がある可能性が高くなる。

よって、この滞在人数に応じた送信順番５３のデータを生成することで、処理に余裕のあるフロアコントローラ１１を最初とし、処理の負荷が大きくなる可能性のあるフロアコントローラ１１を最後とする順番にファームイメージ３１を適用することができる。なお、各フロアの滞在人数を、群管理コントローラ４が一括して管理している場合には、エレベーターコントローラ５が群管理コントローラ４から各フロアの滞在人数を取得してもよい。また、エレベーターコントローラ５自身が各フロアの滞在人数を管理している場合には、その管理データを利用してもよい。

このようにエレベーターコントローラ５は、エレベーター１５の運行情報（各フロアの滞在人数）に応じてフロアコントローラ１１への送信順を並べ替えることで、処理に余裕のあるフロアコントローラ１１からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、ファームイメージ３１の更新データをフロアコントローラ１１に効率よく送信することが可能となる。また、ファームイメージ３１の更新データを受信したフロアコントローラ１１は、更新された新しいファームイメージ３１を適用するために、すぐに再起動できる可能性が向上する。

＜群管理コントローラ＋エレベーターコントローラ＞
次に、複数のエレベーター１５と、群管理コントローラ４とが通信路１６で接続されて構成されるツリー構造について、図１４を用いて説明する。
図１４は、群管理コントローラ４と、複数のエレベーターコントローラ５と、で構成されるツリー構造の例を示すブロック図である。ここでは、図１に示したエレベーターグループ１８が、１台の群管理コントローラ４と、任意の数だけ存在するエレベーター１５（１）～１５（Ｍ）にそれぞれ対応して設けられた複数のエレベーターコントローラ５とを含んでいる。

ここでは、群管理コントローラ４又は複数のエレベーターコントローラ５のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０とする。この場合、マスタコントローラ３０が送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０がファームイメージ３１を更新する。

そこで、上位の通信コントローラ３から群管理コントローラ４にファームイメージ３１がダウンロードされた場合を想定する。この場合には、群管理コントローラ４がマスタコントローラ３０となり、複数のエレベーターコントローラ５がサブコントローラ４０となる構成である。このように群管理コントローラ４と、複数のエレベーターコントローラ５とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。

なお、群管理コントローラ４を経由して、任意のエレベーターコントローラ５がファームイメージ３１をダウンロードする場合がある。この場合、一つのエレベーターコントローラ５がマスタコントローラ３０となり、それ以外のエレベーターコントローラ５及び群管理コントローラ４とがサブコントローラ４０となる構成である。本実施の形態に係る構成であれば、マスタコントローラ３０となる一つのエレベーターコントローラ５が、サブコントローラ４０となる群管理コントローラ４又は他のエレベーターコントローラ５から、各エレベーターコントローラ５に割り当てた呼びの呼び数を取得できる。

また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されているその他のコントローラ２０がサブコントローラ４０となる。ここで、ファームイメージ３１をダウンロードしたコントローラ２０として、例えば、エレベーターコントローラ５、かごコントローラ１０、又はフロアコントローラ１１が想定される。

＜エレベーターの呼びの割当の有無及び大小に応じた順番の生成処理＞
次に、群管理コントローラ４が、運行状態の一つであるエレベーター１５の呼びの割当数を基にして、送信順番５３のデータを生成する処理について、図１５を用いて説明する。
図１５は、エレベーター１５の呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。この処理では、マスタコントローラ３０の順番生成部３４は、運行状態として取得した、複数のエレベーター１５への呼びの割当の状況に応じて送信順番を生成する。このため、エレベーターコントローラ５の処理の負荷に応じた送信順番が生成される。

始めに、群管理コントローラ４の運行状態取得部３３は、各エレベーター１５に割り当てられた呼びの割当数を取得する（Ｓ７１）。次に、群管理コントローラ４の順番生成部３４は、呼びの割当数に応じてエレベーターコントローラ５の送信順を並べ替えて送信順番５３のデータを生成し（Ｓ７２）、本処理を終了する。

送信順の並べ替えは、呼びの割当数の昇順とする。呼びの割当数が多い方が、呼びの割り当てられたフロアへのかご７の移動、停止、出発の処理回数が多くなるので、エレベーターコントローラ５の処理の負荷も大きくなる可能性がある。逆に、呼びの割当数が少ない方が、エレベーターコントローラ５の処理の負荷が少ない。また、エレベーターコントローラ５が、停止つまり待機状態に遷移する可能性が高くなる。

また、群管理コントローラ４の順番生成部３４は、エレベーターコントローラ５へのファームイメージ３１の送信順を、エレベーター１５の運行状態に応じた順番にすることで、処理に余裕がある、又は直近で待機状態になる可能性が高いエレベーターコントローラ５からファームイメージ３１を更新できる。このため、エレベーターコントローラ５は、効率よく更新データの通信が可能となる。また、群管理コントローラ４は、エレベーターコントローラ５に更新された新しいファームイメージ３１を適用するために、すぐにエレベーターコントローラ５を再起動できる可能性が向上する。

＜通信コントローラ＋群管理コントローラ＞
次に、複数のエレベーターグループ１８と、通信コントローラ３とが通信路１７で接続されるツリー構造について、図１６を用いて説明する。
図１６は、通信コントローラ３と、複数の群管理コントローラ４と、で構成されるツリー構造の例を示すブロック図である。ここでは、図１に示した１台の通信コントローラ３と、任意の数だけ存在するエレベーターグループ１８（１）～１８（Ｍ）にそれぞれ対応して設けられた複数の群管理コントローラ４とを示す。なお、図１１、図１４、図１６に示したコントローラ、グループの数を表すＭの値はそれぞれ異なってよい。

この処理では、通信コントローラ３又は複数の群管理コントローラ４のうち、ファームイメージ３１が記憶されている一つがマスタコントローラ３０であり、他がサブコントローラ４０である。そして、マスタコントローラ３０が送信順番を含むパケット５０をサブコントローラ４０に送信し、パケット５０を受信したサブコントローラ４０がファームイメージ３１を更新する。このように通信コントローラ３と、複数の群管理コントローラ４とをマスタコントローラ３０とサブコントローラ４０の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ４０のファームイメージ３１の更新処理を行うことが可能となる。

そこで、上位の通信コントローラ３から群管理コントローラ４にファームイメージ３１がダウンロードされた場合を想定する。この場合には、通信コントローラ３がマスタコントローラ３０となり、複数の群管理コントローラ４がサブコントローラ４０となる構成になる。

また、通信コントローラ３を経由して、任意の群管理コントローラ４がファームイメージ３１をダウンロードする場合がある。この場合には、一つの群管理コントローラ４がマスタコントローラ３０となり、それ以外の群管理コントローラ４及び通信コントローラ３がサブコントローラ４０となる構成になる。この構成とした場合、一つの群管理コントローラ４が通信コントローラ３及び他の群管理コントローラ４にファームイメージ３１を送信することも可能である。

また、保守端末１９に接続されてファームイメージ３１をダウンロードしたコントローラ２０がマスタコントローラ３０となる場合、このコントローラ２０と同一セグメントに接続されているその他のコントローラ２０がサブコントローラ４０となる。ここで、ファームイメージ３１をダウンロードしたコントローラ２０として、例えば、通信コントローラ３が想定される。

＜群管理コントローラの割当数に応じた順番の生成処理＞
次に、通信コントローラ３の順番生成部３４は、運行状態の一つである群管理コントローラ４の割当処理の結果である複数の群管理コントローラ４への呼びの割当回数の状況、つまりエレベーター１５への呼びの割当数と、割当処理状態とを元に、送信順番５３のデータを生成する処理について、図１７を用いて説明する。ここでは、このため、群管理コントローラ４への呼びの割当回数の状況による処理の負荷に応じた送信順番が生成される。
図１７は、エレベーター１５への呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。

始めに、通信コントローラ３の運行状態取得部３３は、各群管理コントローラ４から呼びの割当数及び割当処理状態を取得する（Ｓ８１）。次に、運行状態取得部３３は、全ての群管理コントローラ４から呼びの割当数及び割当処理状態を取得したか否かを確認する（Ｓ８２）。全ての群管理コントローラ４から取得してない場合（Ｓ８２のＮＯ）、運行状態取得部３３は、ステップＳ８１に戻って、呼びの割当数及び割当処理状態の取得を繰り返す。

一方、全ての群管理コントローラ４について取得した場合には（Ｓ８２のＹＥＳ）、通信コントローラ３の順番生成部３４は、運行状態取得部３３が取得した割当数及び割当処理状態に応じて群管理コントローラ４の送信順を並べ替えて送信順番５３のデータを生成し（Ｓ８３）、本処理を終了する。

送信順の並べ替えは、呼びの割当処理の有無及び割当数の昇順とする。呼びの割当処理が終了した群管理コントローラ４は、処理の負荷に余裕がある。呼びの割り当て処理が終了している群管理コントローラ４であっても、呼びの割当数が多い群管理コントローラ４の方が、割当できる選択肢が少ないために、群管理コントローラ４の処理の負荷が増える可能性が低い。つまり、呼びが割当てられる選択肢が少ないので、群管理コントローラ４の処理の負荷が増加する可能性が低くなる。

一方、呼びの割当処理中の群管理コントローラ４は、割当処理が終了した群管理コントローラ４よりも処理の負荷が大きい。呼びの割当処理中の群管理コントローラ４であっても、既に割り当てられた呼びの割当数が少ない群管理コントローラ４の方が、これから呼びが割当られる選択肢が多いために、群管理コントローラ４の処理の負荷が増える可能性が高い。

このため、順番生成部３４は、呼びの割当処理か否かという点、及び呼びの割当数の大小に応じて送信順番５３のデータを生成することで、割当処理が終了した群管理コントローラ４を最初とし、処理中で且つ割当数が少ない処理の負荷の大きい群管理コントローラ４を最後とする順番にファームイメージ３１を適用することができる。

このような運行情報に応じた順番にすることで、処理に余裕のある群管理コントローラ４からファームイメージ３１を効率よく更新できる。このため、通信コントローラ３は、更新された新しいファームイメージ３１を群管理コントローラ４に適用するために、すぐに群管理コントローラ４を再起動できる可能性が向上する。

＜各コントローラの再起動の処理＞
次に、群管理コントローラ４、エレベーターコントローラ５、フロアコントローラ１１がそれぞれファームイメージ３１を適用するための再起動の処理について、図１８～図２０を用いて説明する。

＜群管理コントローラの再起動（割り当て済み）＞
まず、群管理コントローラ４が、運行状態の一つである呼びの割当処理状態に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図１８を用いて説明する。
図１８は、群管理コントローラ４がファームイメージ３１を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、群管理コントローラ４に対するファームイメージ３１の更新が完了した時点で呼びの割当処理が実行されていない場合に、ファームイメージ３１の更新が完了した群管理コントローラ４のイメージ構築部４５が再起動を実施する。このため、群管理コントローラ４が管理するエレベーター１５で利用者のいない時間帯に群管理コントローラ４が再起動されることとなり、利用者に不便を生じさせない。

始めに、群管理コントローラ４は、呼びの割当処理の実行状態を取得する（Ｓ９１）。群管理コントローラ４は、呼びの割当処理が実行中か否かを確認する（Ｓ９２）。呼びの割当処理が実行中であれば（Ｓ９２のＹＥＳ）、再起動は実行せず、本処理を終了する。一定時間後、群管理コントローラ４は、ステップＳ９１から処理を再開する。一方、呼びの割当処理が実行中でない、すなわち呼びの割当処理が終了し、呼びが割当済みであれば（Ｓ９２のＮＯ）、群管理コントローラ４を再起動し（Ｓ９３）、本処理を終了する。

このような処理により、群管理コントローラ４は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。

＜エレベーターコントローラの再起動（次回到着前に停止モードを予約）＞
次に、エレベーターコントローラ５が、運行状態の一つである行先階情報に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図１９を用いて説明する。
図１９は、エレベーターコントローラ５がファームイメージ３１を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、エレベーターコントローラ５のイメージ構築部４５が、エレベーターコントローラ５のファームイメージ３１の更新が完了した時点でエレベーター１５の行先階が登録された場合に、エレベーターコントローラ５の新たな呼びの受付を保留とする。そして、エレベーターコントローラ５のイメージ構築部４５は、行先階にかごが到着した後に、かごの安全状態を確認できた場合に、エレベーターコントローラ５の再起動を実施する。このため、利用者のいないエレベーター１５でエレベーターコントローラ５が再起動されることとなり、利用者に不便を生じさせない。

始めに、エレベーターコントローラ５は、運行状態の一つである行先階情報を取得する（Ｓ１０１）。次に、エレベーターコントローラ５は、行先階情報を判定する（Ｓ１０２）。行先階が複数登録されている場合には、エレベーター１５の運行を継続する必要があるため再起動することはできない。一方、行先階に一つの階が登録されている、又は行先階が登録されていない場合には（Ｓ１０２のＮＯ）、エレベーターコントローラ５は、新たに呼びの登録が発生しないように呼び登録をマスクする（Ｓ１０３）。そこで、エレベーターコントローラ５は、新たな呼びを受け付けないモードに遷移すると共に、かご７が行先階に到着した際に再起動できる運行モードとして、例えば保守モードにするように処理する。

次に、エレベーターコントローラ５は、かご７が行先階に到着したか否かを確認し（Ｓ１０４）、かご７が行先階に到着したか否かを判定する（Ｓ１０５）。かご７が行先階に到着していなければ（Ｓ１０５のＮＯ）、エレベーターコントローラ５は、ステップＳ１０４に戻ってかご７の到着の確認を継続する。

一方、かご７が行先階に到着した場合には（Ｓ１０５のＹＥＳ）、エレベーターコントローラ５は、かご状態を取得する（Ｓ１０６）。次に、エレベーターコントローラ５は、取得したかご状態が、少なくとも乗客に対して安全な状態であるか否かを判定する（Ｓ１０７）。

かご７に乗客が乗っておらず且つドアが閉じている状態が一番安全な状態である。安全状態でないと判定した場合（Ｓ１０７のＮＯ）、エレベーターコントローラ５は、本処理を終了する。一定時間後、エレベーターコントローラ５は、ステップＳ１０１から処理を再開する。一方、安全状態と判定した場合には（Ｓ１０７のＹＥＳ）、エレベーターコントローラ５は、自身の再起動を実行し（Ｓ１０８）、本処理を終了する。

このような処理により、エレベーターコントローラ５は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。

＜フロアコントローラの再起動（呼び登録の確認）＞
次に、フロアコントローラ１１が、運行状態の一つである上下呼びの登録に応じて、更新されたファームイメージ３１を適用するために再起動する処理について、図２０を用いて説明する。ここでは、フロアコントローラ１１のイメージ構築部４５が、フロアコントローラ１１のファームイメージ３１の更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、フロアコントローラ１１の再起動を実施する。このため、利用者のいないフロアでフロアコントローラ１１が再起動されることとなり、利用者に不便を生じさせない。
図２０は、フロアコントローラ１１がファームイメージ３１を適用するために再起動する処理の例を示すフローチャートである。

始めに、フロアコントローラ１１は、上下呼びの登録の状態を取得する（Ｓ１１１）。次に、フロアコントローラ１１は、上下呼びの登録の有無を判定する（Ｓ１１２）。上下呼びの登録が有る場合（Ｓ１１２のＹＥＳ）、エレベーター１５の運転が継続しているので再起動できない。したがって、本処理はここで終了し、一定時間後、フロアコントローラ１１は、ステップＳ１１１から処理を再開する。

一方、上下呼びの登録が無い場合（Ｓ１１２のＮＯ）、エレベーター１５の運行状態から当該フロアのフロアコントローラ１１が一時的に切り離された状態に相当するので、フロアコントローラ１１は、再起動を実行し（Ｓ１１３）、本処理を終了する。

このような処理により、フロアコントローラ１１は、ファームイメージ３１を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ３１を適用するための再起動をすることが可能となる。

なお、本発明は上述した各実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した各実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…センタ、３…通信コントローラ、４…群管理コントローラ、５…エレベーターコントローラ、１０…かごコントローラ、１１…フロアコントローラ、１８…エレベーターグループ、１９…保守端末、２０…コントローラ、３０…マスタコントローラ、３１…ファームイメージ、３２…イメージ分割部、３３…運行状態取得部、３４…順番生成部、３５…パケット生成部、３６…マスタ通信部、４０…サブコントローラ、４１…サブ通信部、４２…パケット解釈部、４３…送信先抽出部、４４…パケット生成部、４５…イメージ構築部、５０…パケット、１００…エレベーターシステム、２００…パケット通信システム

Claims (15)

1. ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムであって、
   前記マスタコントローラは、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第１送信データを送信し、
   前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第１送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第１送信データを送信する
   エレベーターシステム。
2. 前記マスタコントローラは、
   エレベーターの運行状態を取得する運行状態取得部と、
   前記ファームウェアの送信先である前記サブコントローラの送信順番を前記運行状態に応じて生成する順番生成部と、
   前記ファームウェアを分割するファームウェア分割部と、
   前記送信順番にしたがって前記サブコントローラに前記ファームウェアを送信するための第１送信データを生成する第１送信データ生成部と、
   前記送信順番が最先である前記サブコントローラに前記第１送信データを送信する第１通信部と、を備え、
   前記第１送信データ生成部は、前記マスタコントローラを識別する情報と、前記サブコントローラを識別する情報と、前記送信順番と、分割された前記ファームウェアの構築順番と、分割された前記ファームウェアとを含む前記第１送信データを生成する
   請求項１に記載のエレベーターシステム。
3. 前記サブコントローラは、前記マスタコントローラ、又は前記第１送信データの送信元である前記サブコントローラから前記第１送信データを受信する第２通信部と、
   前記第１送信データを解釈するデータ解釈部と、
   前記データ解釈部が解釈した、分割された前記ファームウェアを前記構築順番に従って元の前記ファームウェアに構築するファームウェア構築部と、
   前記データ解釈部が解釈した、前記送信順番に基づいて、前記第１送信データの次の送信先である前記サブコントローラを抽出する送信先抽出部と、
   前記第１送信データの次の送信先である前記サブコントローラに前記ファームウェアを送信するための第２送信データを生成する第２送信データ生成部と、を有し、
   前記第２通信部は、前記第２送信データを次の送信先である前記サブコントローラに送信する
   請求項２に記載のエレベーターシステム。
4. 前記ファームウェア構築部による前記ファームウェアの更新途中に異常が発生した場合に、前記第２通信部は、前記異常に関する情報を含むデータを、前記送信順番とは逆順で前記マスタコントローラに送信する
   請求項３に記載のエレベーターシステム。
5. 前記ファームウェア構築部は、前記ファームウェアの更新途中に異常が発生した場合に、前記ファームウェア構築部が構築していた前記ファームウェアを消去する
   請求項４に記載のエレベーターシステム。
6. 前記第２通信部は、前記第１送信データの次の送信先である前記サブコントローラから前記ファームウェアの更新途中に発生した異常に関する情報を含むデータを受信した場合に、前記異常に関する情報を含むデータを送信した前記サブコントローラをスキップして、後続の前記サブコントローラに前記第２送信データを送信する
   請求項３に記載のエレベーターシステム。
7. 前記エレベーターの動作を制御するエレベーターコントローラと、
   前記エレベーターが昇降するフロアごとに設けられ、前記フロアの状況を前記エレベーターコントローラに伝える複数のフロアコントローラと、を備え、
   前記エレベーターコントローラ又は複数のフロアコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
   請求項３に記載のエレベーターシステム。
8. 前記マスタコントローラは、前記運行状態として取得した、各フロアの呼び登録の状況に応じて前記送信順番を生成し、前記フロアの滞在人数の状況に応じて、前記送信順番を並べ替える
   請求項７に記載のエレベーターシステム。
9. 前記ファームウェア構築部は、前記フロアコントローラのファームウェアの更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、前記フロアコントローラの再起動を実施する
   請求項７に記載のエレベーターシステム。
10. 前記エレベーターの動作を制御する複数のエレベーターコントローラの動作を制御する群管理コントローラと、
    複数のエレベーターコントローラと、を備え、
    前記群管理コントローラ又は複数のエレベーターコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
    請求項３に記載のエレベーターシステム。
11. 前記順番生成部は、前記運行状態として取得した、複数の前記エレベーターへの呼びの割当の状況に応じて前記送信順番を生成する
    請求項１０に記載のエレベーターシステム。
12. 前記ファームウェア構築部は、前記エレベーターコントローラの前記ファームウェアの更新が完了した時点で前記エレベーターの行先階が登録された場合に、前記エレベーターコントローラの新たな呼びの受付を保留とし、前記行先階にかごが到着した後に、前記かごの安全状態を確認できた場合に、前記エレベーターコントローラが再起動を実施する
    請求項１０に記載のエレベーターシステム。
13. 複数のエレベーターコントローラの動作を制御する複数の群管理コントローラに対する通信を制御する通信コントローラと、
    複数の前記群管理コントローラと、を備え、
    前記通信コントローラ又は複数の前記群管理コントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第１送信データを前記サブコントローラに送信し、前記第１送信データを受信した前記サブコントローラが前記ファームウェアを更新する
    請求項３に記載のエレベーターシステム。
14. 前記順番生成部は、前記運行状態として取得した、複数の前記群管理コントローラへの呼びの割当回数の状況に応じて前記送信順番を生成し、
    前記ファームウェア構築部は、前記群管理コントローラに対する前記ファームウェアの更新が完了した時点で呼びの割当処理が実行されていない場合に、前記ファームウェアの更新が完了した群管理コントローラが再起動を実施する
    請求項１３に記載のエレベーターシステム。
15. ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムで行われるファームウェア送信方法であって、
    前記マスタコントローラが、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第１送信データを送信する処理と、
    前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第１送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第１送信データを送信する処理と、を含む
    ファームウェア送信方法。

Images