JP2023127066A - エレベーターシステム及びファームウェア送信方法 - Google Patents
エレベーターシステム及びファームウェア送信方法 Download PDFInfo
- Publication number
- JP2023127066A JP2023127066A JP2022030614A JP2022030614A JP2023127066A JP 2023127066 A JP2023127066 A JP 2023127066A JP 2022030614 A JP2022030614 A JP 2022030614A JP 2022030614 A JP2022030614 A JP 2022030614A JP 2023127066 A JP2023127066 A JP 2023127066A
- Authority
- JP
- Japan
- Prior art keywords
- controller
- sub
- firmware
- elevator
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 205
- 238000000034 method Methods 0.000 title claims description 106
- 238000004891 communication Methods 0.000 claims description 135
- 230000008569 process Effects 0.000 claims description 94
- 238000012545 processing Methods 0.000 claims description 78
- 230000005856 abnormality Effects 0.000 claims description 55
- 238000010276 construction Methods 0.000 claims description 29
- 238000000605 extraction Methods 0.000 claims description 6
- 239000000284 extract Substances 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 20
- 238000012423 maintenance Methods 0.000 description 18
- 230000001174 ascending effect Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 4
- 239000000470 constituent Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B66—HOISTING; LIFTING; HAULING
- B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
- B66B3/00—Applications of devices for indicating or signalling operating conditions of elevators
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B66—HOISTING; LIFTING; HAULING
- B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
- B66B5/00—Applications of checking, fault-correcting, or safety devices in elevators
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Indicating And Signalling Devices For Elevators (AREA)
- Maintenance And Inspection Apparatuses For Elevators (AREA)
- Stored Programmes (AREA)
Abstract
【課題】エレベーターの運行状態に応じてファームウェアを更新するコントローラの順番を変更可能なエレベーターシステムを提供する。【解決手段】エレベーターシステム100が備えるマスタコントローラ30は、エレベーター15の運行状態に応じて、複数のサブコントローラ40に対するファームイメージ31の送信順番を生成し、送信順番が優先されるサブコントローラ40に対して、ファームイメージ31及び送信順番を含むパケット50を送信し、送信順番が優先されるサブコントローラ40は、マスタコントローラ30からパケット50を受信してファームイメージ31の更新を行い、送信順番が次に優先されるサブコントローラ40にパケット50を送信する。【選択図】図3
Description
本発明は、エレベーターシステム及びファームウェア送信方法に関する。
従来、エレベーターシステム100は、複数の制御コントローラから構成されている。そして、任意の1台の制御コントローラが、複数の制御コントローラのプログラムを更新する、1対Nの構成でプログラム更新するシステムが知られている。
特許文献1には、「サーバは、複数のエレベーターの中の予め定められた1台の代表エレベーターに対して、代表エレベーター上にある更新前の版の制御プログラムと、更新すべき最新版の制御プログラムとの差分情報を含む更新データを通信回線を介して配信し、代表エレベーターは、サーバから受信した更新データに基づいて自己の制御プログラムを更新するとともに、予め定められた転送順番に従って次に転送すべきエレベーターに対して、更新データをネットワークを介して送信する」と記載されている。
特許文献2には、「伝送手順制御手段は、伝送路を介して複数の制御装置へ更新用の運転制御プログラムを伝送する伝送時間と、複数の制御装置が更新用の運転制御プログラムに書き換える書換時間とからエレベーターの停止時間を算出し、算出した停止時間に基づいて複数の制御装置へ更新用の運転制御プログラムを伝送する順番を選択する」と記載されている。
特許文献1に記載されているように、予め1台の代表エレベーターを定め、且つ予め更新データの転送順番を定めている場合、代表エレベーター以外のエレベーターから更新データを更新することはできない。代表エレベーターに不具合が発生すると、代表エレベーターの処理の負荷が高い場合等、データの更新処理を実施できない場合があった。さらに、予め定められた順番でしか更新処理を実行できないため、順番が決められた全てのエレベーターが更新処理を実行できる状態でしかエレベーターが更新処理を完遂することができなかった。例えば、1基のエレベーターのみが不具合発生や保守作業中であっても、制御処理が高負荷であると、更新処理を受け付けないため、通信処理に遅延又は通信遮断が起きる等の課題があった。
また、特許文献2には、伝送時間と書換時間とに基づいてエレベーターの停止時間を算出することが記載されている。しかし、プログラム容量、通信デバイス性能、及び、記憶デバイス書換性能は、予め定められた条件に該当しなければならない。特許文献1に記載された技術と同じく、実際の運用状態に適していない場合もあった。
本発明はこのような状況に鑑みて成されたものであり、エレベーターの運行状態に応じてファームウェアを更新するコントローラの順番を変更することを目的とする。
本発明に係るエレベーターシステムは、ファームウェアを送信するマスタコントローラと、ファームウェアを受信してファームウェアを更新するサブコントローラとを備える。マスタコントローラは、エレベーターの運行状態に応じて、複数のサブコントローラに対するファームウェアの送信順番を生成し、送信順番が優先されるサブコントローラに対して、ファームウェア及び送信順番を含む第1送信データを送信する。送信順番が優先されるサブコントローラは、マスタコントローラから第1送信データを受信してファームウェアの更新を行い、送信順番が次に優先されるサブコントローラに第1送信データを送信する。
本発明によれば、エレベーターの運行状態に応じてファームウェアの送信順番を生成するため、予めファームウェアの送信順番を決める必要がない。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
以下、本発明を実施するための形態に係るエレベーターシステム及びファームウェア送信方法の一例について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。なお、本発明は以下の実施形態に限定されるものではない。
[一実施形態]
図1は、本発明の一実施形態に係るエレベーターシステム100の全体構成例を示す図である。
図1では、エレベーターシステム100の説明を簡略化するために、1基のエレベーター15の詳細な構成要素を図示しており、他のエレベーター15については詳細な構成要素の図示を省略する。
図1は、本発明の一実施形態に係るエレベーターシステム100の全体構成例を示す図である。
図1では、エレベーターシステム100の説明を簡略化するために、1基のエレベーター15の詳細な構成要素を図示しており、他のエレベーター15については詳細な構成要素の図示を省略する。
エレベーターシステム100は、複数のエレベーター15を管理し、運行を監視し、保守するために、例えば、エレベーター15から遠隔に設置されているセンタ1を有する。また、エレベーターシステム100は、通信コントローラ3、群管理コントローラ4、エレベーターコントローラ5、かごコントローラ10、フロアコントローラ11及び保守端末19を有する。
センタ1は、専用回線のような有線又は無線による閉回路網やインターネットのような公衆回線である通信網2を経由して通信コントローラ3に接続されている。
通信コントローラ3は、センタ1とエレベーターとの間のデータ転送、遠隔操作及び遠隔保守を実行するための通信を担うコントローラである。通信コントローラ3は、通信路17を介して、群管理コントローラ4に接続されている。通信コントローラ3は、複数のエレベーターコントローラ5の動作を制御する複数の群管理コントローラ4に対する通信を制御する。
通信コントローラ3は、センタ1とエレベーターとの間のデータ転送、遠隔操作及び遠隔保守を実行するための通信を担うコントローラである。通信コントローラ3は、通信路17を介して、群管理コントローラ4に接続されている。通信コントローラ3は、複数のエレベーターコントローラ5の動作を制御する複数の群管理コントローラ4に対する通信を制御する。
群管理コントローラ4は、エレベーター15の動作を制御する複数のエレベーターコントローラ5の動作を制御する。そこで、群管理コントローラ4は、複数のエレベーター15をエレベーターグループ18としてまとめて運行制御する。群管理コントローラ4は、複数のエレベーターコントローラ5と、通信路16を介して接続されている。
エレベーター15は、エレベーターコントローラ5、かごコントローラ10及びフロアコントローラ11を備える。
エレベーターコントローラ5は、エレベーター15の動作を制御しており、かご7の上下移動及び停止の制御を実現することで利用者に上下移動のサービスを提供する。このサービスを提供するため、エレベーターコントローラ5は、主機であるモーター6を制御して、かご7と、カウンターウェイト8と、を連結しているロープ9の動きを操作する。エレベーターコントローラ5は、1台のかごコントローラ10と、複数のフロアコントローラ11と、通信路12を経由して接続されている。
かごコントローラ10は、かご7内に設置されている行先階ボタン及びドア開閉ボタン13の、利用者による操作状況に対応して、かごドアの開閉動作を行い、エレベーターコントローラ5にかご状況の変化を伝える。
フロアコントローラ11は、エレベーター15が昇降するフロアごとに設けられ、フロアの状況をエレベーターコントローラ5に伝える。例えば、フロアコントローラ11は、各階床に設置される上下ボタン14の、各階における利用者による操作状況を監視して、エレベーターコントローラ5にフロアの状況変化を伝える。上下ボタン14の代わりに、乗客がかごへの乗車前に行先階を登録可能な行先階登録装置を具備するエレベーターシステムもある。
図1を示して説明したように、エレベーターシステム100は、複数のコントローラが1対N構成であるツリー構造が多段に階層化されたシステムである。また、同一種別のコントローラが複数存在する場合には、当該コントローラの任意の一台をツリー構造のルートとし、残りのコントローラをツリー構造のリーフとしてツリー構造を構成することも可能である。
センタ1は、各コントローラで用いられるファームウェアをファームイメージ31(後述する図3を参照)として不図示の記憶部に保持している。センタ1は、通信網2、通信路12、16、17と、通信路に接続されている各種のコントローラと、を経由することにより、任意のコントローラにファームウェアを送信することが可能である。
通信網2に接続される保守端末19は、センタ1からファームウェアをコピーすることができる。保守端末19は、ファームウェアをコピーした後、任意のコントローラに接続されることで、保守端末19が保持するファームウェアを、接続したコントローラに出力可能である。このため、保守端末19は、保守端末19に接続したコントローラにファームウェアを保持させることができる。また、ファームウェアを保持したコントローラは、自身のファームウェアをアップデートしたり、他のコントローラにファームウェアを送信したりすることができる。
なお、各コントローラがファームウェアを更新する方法としては、ファームウェアの全体イメージを用いた全体更新の場合と、新旧のファームウェアの差分イメージを用いて部分的に差分更新する場合と、がある。
<コントローラのハードウェア構成例>
次に、エレベーターシステム100が備える各コントローラ20のハードウェア構成について、図2を参照して説明する。ここでは、通信コントローラ3、群管理コントローラ4,エレベーターコントローラ5、かごコントローラ10,フロアコントローラ11が備える計算機のハードウェア構成を説明する。これらを総称してコントローラ20と呼ぶ。
次に、エレベーターシステム100が備える各コントローラ20のハードウェア構成について、図2を参照して説明する。ここでは、通信コントローラ3、群管理コントローラ4,エレベーターコントローラ5、かごコントローラ10,フロアコントローラ11が備える計算機のハードウェア構成を説明する。これらを総称してコントローラ20と呼ぶ。
図2は、コントローラ20のハードウェア構成例を示すブロック図である。
コントローラ20は、システムバス21に、それぞれ接続されたMPU(Micro Processing Unit)22、ROM(Read Only Memory)23、RAM(Random Access Memory)24、及び通信インタフェース25を備える。なお、MPUに類する演算装置の上位概念としてCPU(Central Processing Unit)がある。
コントローラ20は、システムバス21に、それぞれ接続されたMPU(Micro Processing Unit)22、ROM(Read Only Memory)23、RAM(Random Access Memory)24、及び通信インタフェース25を備える。なお、MPUに類する演算装置の上位概念としてCPU(Central Processing Unit)がある。
MPU22、ROM23、RAM24は、処理部を構成する。MPU22は、本実施形態の形態で、係る各機能を実現するプログラムコードのバイナリデータであるファームイメージ31(後述する図3を参照)はROM23に記録されており、ROM23からリードしてRAM24にロードし、プログラムコードを実行する。また、MPU22は、プログラムコードをROM23から直接リードしてそのままプログラムコードを実行する場合もある。
RAM24には、MPU22で行われる処理の実行途中で発生した変数やパラメータ等が一時的に書き込まれ、これらの変数及びパラメータ等がMPU22から適宜読み出される。
コントローラ20は、通信インタフェース25を通じて、複数のコントローラ20間でデータを送受信することが可能である。各コントローラ20間を接続する通信路として、例えば、RS-485のようなマルチドロップ形態のシリアル通信デバイスや、イーサネット(登録商標)のような複数のトポロジを提供する有線の通信路であるLAN(Local Area Network)、WAN(Wide Area Network)、さらには無線の通信路であるRAN(Radio Area Network)がある。各コントローラ20は、例えば、Wi-Fi(登録商標)のような無線や、インフラ無線通信によって、各コントローラのデータを装置間で送受信することが可能となる。
なお、ROM23へのデータの書換時に生じる不具合に対処するために、コントローラ20が複数のROM23を搭載する場合がある。この構成であれば、一方のROM23に現在のファームイメージ31(ファームウェアの一例)が記録され、他方のROM23に新規のファームイメージ31が記録される。後者のROM23に対する新規のファームイメージ31の書換時に不具合が発生しても、前者のROM23には、現在のファームイメージ31が残っているので、現状復帰が可能である。また、コントローラ20は、ROM23が複数ある場合には、所望のファームイメージ31が記憶されているROM23を選択して起動する。
<マスタコントローラとサブコントローラの基本システム構成>
次に、図1に示したエレベーターシステム100の実施形態に基づいて、本発明の実施形態に係るマスタコントローラとサブコントローラの基本システム構成について説明する。
図3は、マスタコントローラ30とサブコントローラ40を含むパケット通信システム200の基本構成例を示すブロック図である。
次に、図1に示したエレベーターシステム100の実施形態に基づいて、本発明の実施形態に係るマスタコントローラとサブコントローラの基本システム構成について説明する。
図3は、マスタコントローラ30とサブコントローラ40を含むパケット通信システム200の基本構成例を示すブロック図である。
パケット通信システム200は、ファームイメージ31を送信するマスタコントローラ30と、ファームイメージ31を受信してファームイメージ31を更新するサブコントローラ40とを備えるエレベーターシステム100の一形態である。図1に示したように、エレベーターシステム100は、複数のコントローラが1対Nで接続されるツリー構造が、多重に組み合わさっている大規模なシステムである。ここでは、1台のコントローラ20をマスタコントローラ30、N台のコントローラ20をサブコントローラ40としたパケット通信システム200について説明する。また、パケット通信システム200では、同階層、又は異なる階層のコントローラ20をマスタとサブの関係としている。マスタとサブの関係は、隣接する階層だけでなく、一又は複数の階層をまたいでもよい。例えば、一つの群管理コントローラ4をマスタコントローラ30とし、エレベーターコントローラ5をまたいで、複数のフロアコントローラ11をサブコントローラ40とすることも可能である。
マスタコントローラ30は、エレベーター15の運行状態に応じて、複数のサブコントローラ40に対するファームイメージ31の送信順番を生成する。そして、マスタコントローラ30は、送信順番が優先されるサブコントローラ40に対して、ファームイメージ31及び送信順番を含むパケット50を送信する。マスタコントローラ30は、通信路37を介して、サブコントローラ40に接続されている。マスタコントローラ30からパケット50が直接送信されるサブコントローラ40は、送信順番が最先であることが多い。ただし、パケット50を受信するサブコントローラ40に異常が生じた場合、マスタコントローラ30は、異常が生じたサブコントローラ40の次の送信順番であるサブコントローラ40を優先してパケット50を送信することがある。このようにマスタコントローラ30は、送信順番が優先されるサブコントローラ40にパケット50を送信するので、送信順番が優先されるサブコントローラ40がパケット50を受信できる。また、パケット50を受信したサブコントローラ40は、送信順番が次に優先されるサブコントローラ40にパケット50を送信するので、パケット50が複数のサブコントローラ40を転送されることとなる。このため、マスタコントローラ30が複数のサブコントローラ40にパケット50を一斉配信する場合に比べて、各サブコントローラ40にパケット50を確実に送信することが可能となる。
このマスタコントローラ30は、ファームイメージ31、イメージ分割部32、運行状態取得部33、順番生成部34、パケット生成部35及びマスタ通信部36を備える。
ファームイメージ31は、ファームウェアの実体である。ファームウェアは、コントローラ20の動作を制御するプログラムの一例である。ファームイメージ31は、マスタコントローラ30に設けられたROM23等に保存される。
イメージ分割部32は、ファームイメージ31を分割するファームウェア分割部の一例として用いられる。イメージ分割部32がファームイメージ31を分割するため、1回当たりの通信でサブコントローラ40に送信されるパケット50のバイナリデータ57(後述する図4Aを参照)のデータ量が減少する。マスタコントローラ30とサブコントローラ40との間の通信路37の通信効率を向上させることができる。
運行状態取得部33は、エレベーターの運行状態を取得する。エレベーター15の運行状態は、例えば、かご状態、呼びの割当状態等を含む。運行状態取得部33は、かごコントローラ10、フロアコントローラ11等から運行状態を取得できる。
順番生成部34は、イメージ分割部32により分割されたファームイメージ31の送信先であるサブコントローラ40の送信順番を、運行状態取得部33が取得したエレベーター15の運行状態に応じて生成する。なお、ファームイメージ31のファイルサイズが十分に小さい場合、分割されないファームイメージ31がサブコントローラ40に送信されることがある。
パケット生成部35(第1送信データ生成部の一例)は、順番生成部34が生成した送信順番にしたがってマスタコントローラ30がサブコントローラ40にファームイメージ31を送信するためのパケット50を生成する。パケット50は、第1送信データの一例として用いられる。後述する図4に示すように、パケット生成部35は、パケット50の送信元であるマスタコントローラ30を識別する情報(送信元51)と、パケット50の送信先であるサブコントローラ40を識別する情報(送信先52)と、送信順番(送信順番53)と、分割されたファームイメージ31の構築順番(番号56)と、分割されたファームイメージ31(バイナリデータ57)とを含むパケット50を生成する。
マスタ通信部36は、順番生成部34により生成された送信順番が最先であるサブコントローラ40に対して、パケット生成部35により生成されたパケット50を送信する。
送信順番が優先されるサブコントローラ40は、マスタコントローラ30からパケット50を受信してファームイメージ31の更新を行い、送信順番が次に優先されるサブコントローラ40にパケット50を送信する。このサブコントローラ40は、サブ通信部41、パケット解釈部42、送信先抽出部43、パケット生成部44、イメージ構築部45及びファームイメージ記憶部46を備える。
サブ通信部41は、通信路37に接続されている。このサブ通信部41は、通信路37を介してマスタコントローラ30、又はパケット50の送信元である他のサブコントローラ40からパケット50を受信する第2通信部の一例として用いられる。
パケット解釈部42は、サブ通信部41が受信したパケット50を解釈するデータ解釈部の一例として用いられる。パケット50の解釈は、規定のパケットフォーマットに従って、パケット50からデータを取り出し、所定の出力先にデータを出力する処理である。パケット解釈部42が解釈したファームイメージ31の分割されたイメージデータは、イメージ構築部45に出力される。また、パケット解釈部42によるパケット50の解釈結果は送信先抽出部43に出力される。
送信先抽出部43は、パケット解釈部42が解釈した送信順番に基づいて、パケット50の次の送信先であるサブコントローラ40を抽出する。
パケット生成部44は、パケット50の次の送信先であるサブコントローラ40にファームイメージ31を送信するためのパケット50(第2送信データの一例)を生成する第2送信データ生成部の一例として用いられる。例えば、パケット生成部44は、パケット解釈部42によるパケット50の解釈結果と、送信先抽出部43により抽出されたパケットの送信先である残りのサブコントローラ40の送信順番とに基づいて、新たなパケット50を生成する。パケット生成部44が生成するパケット50に含まれるファームイメージ31の分割されたイメージデータは、基本的には、サブ通信部41が受信したパケット50に含まれる、ファームイメージ31の分割されたイメージデータと同じである。パケット生成部44によりパケット50が生成されると、サブ通信部41が、パケット50に格納された送信順番に基づいて、次の送信先であるサブコントローラ40にパケット50を送信する。
イメージ構築部45は、パケット解釈部42が解釈した、分割されたファームイメージ31を構築順番に従って元のファームイメージ31に構築するファームウェア構築部の一例として用いられる。イメージ構築部45は、パケット解釈部42から受け取った、分割されたファームイメージ31を溜めるバッファ(不図示)を有する。そして、分割されたファームイメージ31がバッファに十分溜まると、ファームイメージ31を再構築する。
ファームイメージ記憶部46は、イメージ構築部45により構築されたファームイメージ31を記憶する。サブコントローラ40が更新するファームイメージ31は、ファームイメージ記憶部46から読み出されたものである。ファームイメージ記憶部46には、複数のファームイメージ31がバージョンごとに世代管理されてもよい。このため、仮に更新が失敗した場合には、以前のファームイメージ31に戻すことができる。
サブコントローラ40の各部の処理が繰り返し行われることで、エレベーター15の運行状況に応じた効率のよいサブコントローラ40の送信順番に基づいてファームイメージ31の送信が実現される。
運行状態が、例えば深夜時間帯のようにエレベーターシステム100全体が待機状態である場合には、コントローラ20の順番が更新処理に与える影響は少ない。このため、パケット生成部44は、パケット50がサブコントローラ40に送信される順番を、階床数に応じた昇順/降順の順番、コントローラ20に割り当てられているシリアル番号の順番、又は乱数を用いて決定してもよい。
マスタコントローラ30とサブコントローラ40の関係は、保守端末19を使用するユーザが決定してもよい。また、保守端末19からファームイメージ31をダウンロードしたコントローラをマスタコントローラ30とし、他のコントローラをサブコントローラ40として自動的に決定してもよい。
<パケットの基本構成>
次に、図3に示したパケット通信システム200において生成されるパケット50の基本構成について図4を用いて説明する。
図4は、パケット50の基本構成例を示す図である。
次に、図3に示したパケット通信システム200において生成されるパケット50の基本構成について図4を用いて説明する。
図4は、パケット50の基本構成例を示す図である。
図4Aは、パケット50の内部構成例を示す図である。
パケット50は、パケット50の送信元51のデータと、パケット50の送信先52のデータと、パケット50の送信順番53のデータと、ファームイメージ31を分割したイメージデータ54と、パケット50のデータ不整合を確認するためのチェックデータ55と、から構成される。
パケット50は、パケット50の送信元51のデータと、パケット50の送信先52のデータと、パケット50の送信順番53のデータと、ファームイメージ31を分割したイメージデータ54と、パケット50のデータ不整合を確認するためのチェックデータ55と、から構成される。
イメージデータ54は、図3に示したイメージ分割部32によってファームイメージ31が分割された複数のイメージデータの一つである。このため、イメージデータ54は、ファームイメージ31が分割された構築順番を示す番号56と、分割されたイメージの実体であるバイナリデータ57と、から構成される。このようにパケット50の構造を定義することにより、マスタコントローラ30及びサブコントローラ40は、順番生成部34で生成された複数のサブコントローラ40の順番通りにファームイメージ31を送信できる。このため、各サブコントローラ40は、ファームイメージ31を受信した順番でファームイメージ31を更新することができる。
なお、イメージデータ54又はバイナリデータ57には、通信コントローラ3、群管理コントローラ4、エレベーターコントローラ5、フロアコントローラ11のうち、どのコントローラに対応したファームウェアなのかを示す識別データが含まれている。よって、マスタコントローラ30である場合に各コントローラに搭載されるイメージ構築部45は、識別データによって、別のコントローラ向けのファームウェアを識別することが可能である。
図4Bは、マスタコントローラ30と、各サブコントローラ40とによって生成されるパケット50の構成例を示す図である。ここでは、4階床の建屋に設けられたエレベーター15を想定する。マスタコントローラ30がエレベーターコントローラ5に対応し、サブコントローラ40がフロアコントローラ11に対応する。そして、送信順番53が、4階―2階―3階―1階の順番として生成された場合を示している。ここで、番号56に格納される「1」は、分割されたファームイメージ31のうち、1番目のバイナリデータであることを表している。
マスタコントローラ30は、送信元51に自身のID番号「0」を設定し、送信先52に送信順番53の最初のID番号「4」を設定し、送信順番53にID番号「4」より後の順番「2-3-1」を設定したパケット50(1)を生成する。このため、送信順番53が最先である4階のフロアコントローラ11にパケット50(1)が送信される。
4階のフロアコントローラ11は、パケット50(1)を受信すると、送信元51に自身のID番号「4」を設定し、送信先52に送信順番53の最初のID番号「2」を設定し、送信順番53にID番号「2」より後の順番「3-1」を設定したパケット50(2)を生成する。このため、送信順番53が最先である2階のフロアコントローラ11にパケット50(2)が送信される。
2階のフロアコントローラ11は、パケット50(2)を受信すると、送信元51に自身のID番号「2」を設定し、送信先52に送信順番53の最初のID番号「3」を設定し、送信順番53にID番号「3」より後の順番「1」を設定したパケット50(3)を生成する。このため、送信順番53が最先である3階のフロアコントローラ11にパケット50(3)が送信される。
3階のフロアコントローラ11は、パケット50(3)を受信すると、送信元51に自身のID番号「3」を設定し、送信先52に送信順番53の最初のID番号「1」を設定し、自身が送信順番の最後となるので送信順番53を無設定にしたパケット50(4)を生成する。このため、送信順番53が最先である1階のフロアコントローラ11にパケット50(4)が送信される。
パケット50をこのような構造にすることで、マスタコントローラ30から送信されたパケット50が、エレベーター15の運行状態に応じた送信順番53に基づいて、複数のサブコントローラ40を順番に経由して送信される。このため、マスタコントローラ30の処理の負荷を軽減できるとともに、サブコントローラ40もエレベーター15の運行状態に基づいて効率よく処理を実行することが可能となる。また、本実施の形態に係る通信方法は、マスタコントローラ30から複数のサブコントローラ40にパケットを一斉配信するブロードキャストに比べてネットワークを占有しなくて済む。また、マスタコントローラ30は、ファームイメージ31の送信順番の割当てを管理しやすくなる。
なお、多くのコントローラ20が待機状態の場合、例えば利用が少ない深夜等の場合には、運転状態によるコントローラ20の状態に差異が少ない。このため、送信順番53を、単純に、コントローラ20のID順に、またはフロア番号順にしても構わない。
また、任意のサブコントローラ40から、マスタコントローラ30に直接通信することを想定した場合には、送信元51と、送信先52に加えて、マスタコントローラ30に相当するパケットの送信源の項目をパケットに追加してもよい。サブコントローラ40からマスタコントローラ30への通信は、例えば、サブコントローラ40が管理する範囲のエレベーター15の運行状況をマスタコントローラ30に通知するために行われる。また、サブコントローラ40からマスタコントローラ30への通信は、エレベーター15の通常運転における状態通知に使われる。また、サブコントローラ40が、複数のサブコントローラ40を逆に辿らずに、マスタコントローラ30に対して直接不具合情報を送るためにも使われる。
<正常時の通信処理>
次に、図3に示したパケット通信システム200における処理(ファームウェア送信方法の一例)について、図5以降のフローチャートを参照して説明する。
図5は、パケット通信システム200の正常通信処理の例を示すフローチャートである。図5は、マスタコントローラ30が、ファームイメージ31を分割し、エレベーター15の運行状態に基づいて生成した順番でパケット50を送信することで、全てのサブコントローラ40にファームイメージ31を配布する処理を表している。
次に、図3に示したパケット通信システム200における処理(ファームウェア送信方法の一例)について、図5以降のフローチャートを参照して説明する。
図5は、パケット通信システム200の正常通信処理の例を示すフローチャートである。図5は、マスタコントローラ30が、ファームイメージ31を分割し、エレベーター15の運行状態に基づいて生成した順番でパケット50を送信することで、全てのサブコントローラ40にファームイメージ31を配布する処理を表している。
始めに、マスタコントローラ30のイメージ分割部32(図3参照)は、ファームイメージ31を通信に適したサイズに分割する(S1)。イメージ分割部32は、ファームイメージ31を分割する時に、分割順が分かるように、例えば昇順とした番号56(図4参照)も生成する。なお、最後の分割したファームイメージ31の番号は特別な終端番号とする場合がある。この終端番号を、パケット50の受信側のコントローラ20が共有していれば、分割されたファームイメージ31の個数が多くても、コントローラ20が最後まで受信することができる。
次に、運行状態取得部33は、エレベーター15の運行状態を取得する(S2)。次に、順番生成部34は、運行状態に基づいて、分割されたファームイメージ31を通信する、サブコントローラ40の順番を生成する(S3)。次に、パケット生成部35は、順番生成部34により生成された順番に従って、次のサブコントローラ40へ送信するパケット50を生成する(S4)。そして、マスタ通信部36は、生成されたパケット50を、順番に従って、次のサブコントローラ40に送信する(S5)。
マスタ通信部36は、パケット50の送信が成功したか否かを確認する(S6)。パケット50の送信が失敗した場合(S6のNO)、マスタ通信部36は、サブコントローラ40からの異常通知を受信した後(S7)、本処理を終了する。なお、一定時間後、マスタコントローラ30は、パケット50を再送信するために、本処理を再実行する。
一方、パケット50の送信が成功した場合(S6のYES)、マスタ通信部36は、ファームイメージ31を分割した残りが存在するか否かを確認する(S8)。ファームイメージ31を分割した残りが有る場合には(S8のYES)、マスタコントローラ30は、ステップS1に戻って、処理を繰り返す。残りが無い場合には(S8のNO)、マスタコントローラ30は、本処理を終了する。
次に、サブコントローラ40の処理について、図6を参照して説明する。
図6は、サブコントローラ40の処理の例を示すフローチャートである。
図6は、サブコントローラ40の処理の例を示すフローチャートである。
始めに、サブコントローラ40のサブ通信部41は、マスタコントローラ30又は一つ前の順番のサブコントローラ40からパケット50を受信する(S11)。
次に、パケット解釈部42は、サブ通信部41が受信したパケット50を解釈し(S12)、送信元51、送信先52、送信順番53、分割されたイメージデータ54、チェックデータ55のそれぞれを識別する。ステップS12のパケット50を解釈する処理は、後述する図8に詳細な例が示される。
次に、送信先抽出部43は、パケット解釈部42が識別した送信順番53から次の送信先を抽出する(S13)。また、イメージ構築部45は、分割されたイメージデータ54からファームイメージ31を順次構築する(S14)。ステップS13,S14の処理は、並列処理としているが、逐次処理としてもよい。
次に、送信先抽出部43は、分割されたイメージデータ54を送る次の送信先が存在するか否かを送信順番53で確認する(S15)。
次の送信先が存在する場合(S15のYES)、パケット生成部44は、新たに送信先52を次のサブコントローラ40に変更したパケット50を生成する(S16)。サブ通信部41は、生成したパケット50を次のサブコントローラ40に送信し(S17)、パケット50の送信が成功したか否かを確認する(S18)。
パケット50の送信が失敗した場合(S18のNO)、サブコントローラ40は、後述する図7又は図10に示す異常対応処理を行う(S19)。ステップS19は、後述する図9と図10に示すように異なる行先がある。
一方、パケット50の送信が成功した場合(S18のYES)、又は、ステップS15にて分割されたイメージデータ54を送る次のサブコントローラ40が存在しないと判定した場合(S15のNO)、パケット解釈部42は、イメージデータ54がファームイメージ31の終端であるか否かを確認する(S20)。
ファームイメージ31の終端であれば(S20のYES)、パケット解釈部42がイメージ構築部45によるファームイメージ31の構築が終了したかを確認した後、サブコントローラ40は、本処理を終了する。一方、ファームイメージ31の終端でなければ(S20のNO)、ステップS11に戻って、サブコントローラ40が処理を繰り返す。
なお、サブ通信部41は、分割されたイメージデータ54を含むパケット50を受信する度に、パケット解釈部42が解釈した送信元51を記憶しておいてもよい。この場合、サブ通信部41は、パケット50の順番を逆に辿って通信することで、マスタコントローラ30と、通信することも可能となる。例えば、サブ通信部41は、サブコントローラ40の不具合発生をマスタコントローラ30に通知することも可能となる。
図5と図6に示した処理フローにより、マスタコントローラ30は、エレベーター15の運行状態に応じた順番の最初のサブコントローラ40にパケット50を送信するだけで、ファームイメージ31を複数のサブコントローラ40全てに対して自ら配信することなく、ファームイメージ31の更新が可能となる。複数のサブコントローラ40は、マスタコントローラ30が生成した順番に従って、他のサブコントローラ40にファームイメージ31を通信する。このようにマスタコントローラ30は、効率の良い通信処理を組み合わせることで、全てのサブコントローラ40のファームイメージ31を更新することが可能となる。
なお、ファームイメージ31のサイズが小さい、又は差分アップデートで差分イメージのデータサイズが小さい場合には、イメージ分割せずにパケット50を通信することがある。この場合、1回の通信でマスタコントローラ30とサブコントローラ40の処理が終了する場合もある。
<通信異常の通知処理>
次に、通信異常が発生した時にサブコントローラ40がマスタコントローラ30に異常の発生を通知する処理について、図7~図10を用いて説明する。
次に、通信異常が発生した時にサブコントローラ40がマスタコントローラ30に異常の発生を通知する処理について、図7~図10を用いて説明する。
始めに、本処理で用いられる異常通知メッセージの構成例を説明する。
図7は、異常通知メッセージのパケット構成例を示す図である。
図7は、異常通知メッセージのパケット構成例を示す図である。
パケット50を受信した時に通信異常を検知したサブコントローラ40は、パケット50の送信元である前段のサブコントローラ40に対して異常通知メッセージを送信する。この異常通知メッセージは、図7に示すように、送信元51のデータと、送信先52のデータと、イメージデータ54のデータと、チェックデータ55とで構成される。なお、送信順番53にはデータが記憶されない。
そして、イメージデータ54は、コマンド58と、このコマンド58に対応するコマンドデータ59とで構成される。本実施形態においては、コマンド58に「異常発生通知コマンド」が格納され、コマンドデータ59には通信異常が発生したコントローラ20のIDが格納される。
図8は、サブコントローラ40が異常の発生を通知する処理の例を示すフローチャートである。ここでは、図6のステップS12に示したパケット解釈処理の詳細な例を説明する。
始めに、任意のコントローラ20のパケット解釈部42は、パケット50を解釈して、送信順番53のデータを確認する(S21)。次に、パケット解釈部42は、送信順番53のデータに送信先のサブコントローラ40のIDが、パケット50の送信順番で格納されているか否かを確認する(S22)。送信順番53のデータにサブコントローラ40のIDが送信順番で格納されている場合(S22のYES)、本処理を抜けて、図6のステップS13に移る。
一方、送信順番53のデータにサブコントローラ40のIDが送信順番で格納されていない場合には(S22のNO)、イメージ構築部45によるファームイメージ31の更新途中に異常が発生している。この場合、サブ通信部41は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ30に送信する。このため、マスタコントローラ30は、サブコントローラ40で発生した異常を直ちに把握し、パケット50の送信停止等の指示等を対処できる。
例えば、パケット解釈部42は、イメージデータ54から、図7に示したコマンド58と、コマンド58に対応したコマンドデータ59を解釈する(S23)。そして、パケット解釈部42は、送信元51を、本処理を実行するサブコントローラ40自身とし、送信先52を、パケット50を送信した前のサブコントローラ40とに置き換えた異常通知メッセージを生成する(S24)。
サブコントローラ40のサブ通信部41は、異常通知メッセージを、送信順番が前のサブコントローラ40に送信する(S25)。その後、イメージ構築部45は、今までに構築してきたファームイメージ31を消去して(S26)、処理を終了する。このため、図6のステップS13,S14以降の処理は行われない。
図7に示す異常通知の処理フローにより、サブコントローラ40は、通信異常が発生した時には処理途中のファームイメージ31を消去できる。また、サブコントローラ40は、異常通知メッセージをマスタコントローラ30に通知することができる。
<異常時の通信処理>
次に、通信エラーが発生した異常時において、パケット50を受信したサブコントローラ40が構築途中のイメージを消去する場合と、通信エラーが発生したサブコントローラ40をスキップする場合の各処理について、図9と図10を用いて説明する。
次に、通信エラーが発生した異常時において、パケット50を受信したサブコントローラ40が構築途中のイメージを消去する場合と、通信エラーが発生したサブコントローラ40をスキップする場合の各処理について、図9と図10を用いて説明する。
<第1の異常通知処理>
図9は、サブコントローラ40がパケット50送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。この異常対応処理では、サブコントローラ40が、パケット50の送信失敗時に、これまで送信先のサブコントローラ40に送信してきたイメージデータ54を消去する処理が行われる。なお、ステップS17より前の処理は、図6に示した通りであるため、詳細な説明を省略する。
図9は、サブコントローラ40がパケット50送信の失敗時に行われる異常対応処理の一例を示すフローチャートである。この異常対応処理では、サブコントローラ40が、パケット50の送信失敗時に、これまで送信先のサブコントローラ40に送信してきたイメージデータ54を消去する処理が行われる。なお、ステップS17より前の処理は、図6に示した通りであるため、詳細な説明を省略する。
図6に示したように、任意のコントローラ20のサブ通信部41は、生成したパケット50を次のコントローラ20に送信する(S17)。任意のコントローラ20として、例えば、通信コントローラ3、群管理コントローラ4、エレベーターコントローラ5、かごコントローラ10、フロアコントローラ11がある。次に、サブ通信部41は、パケット50の送信が成功したか否かを確認する(S18)。
パケット50の送信が成功した場合(S18のYES)、コントローラ20は、図6のステップS20以降の処理に移る。一方、パケット50の送信が失敗した場合(S18のNO)、イメージ構築部45によるファームイメージ31の更新途中に異常が発生する。この場合、サブ通信部41は、異常に関する情報を含むデータを、送信順番とは逆順でマスタコントローラ30に送信する。このため、マスタコントローラ30は、サブコントローラ40で発生した異常を直ちに把握し、パケット50の送信停止等の指示等を対処できる。また、サブコントローラ40は、ファームイメージ31の更新途中に異常が発生した場合に、イメージ構築部45が構築していたファームイメージ31を消去する。このため、サブコントローラ40では、不正確なファームイメージ31による更新処理が行われない。
例えば、コントローラ20のパケット生成部44は、前の順番のコントローラ20に通信異常を通知するための異常通知メッセージのパケット50を生成する(S31)。次に、サブ通信部41は、前の順番のコントローラ20に異常通知メッセージのパケット50を送信する(S32)。そして、イメージ構築部45は、これまでに構築してきたファームイメージ31を消去し(S33)、本処理を終了する。
<第2の異常通知処理>
図10は、通信エラーが発生したサブコントローラ40をスキップして、ファームイメージ31の更新処理を継続する処理の例を示すフローチャートである。この異常対応処理では、通信エラーが発生していないサブコントローラ40に対して優先してパケット50の送信が行われる。例えば、コントローラ20がサブコントローラ40であることを想定する。この場合、サブコントローラ40は、パケット50の次の送信先であるサブコントローラ40からファームイメージ31の更新途中に発生した異常に関する情報を含むデータを受信した場合に、異常に関する情報を含むデータを送信したサブコントローラ40をスキップして、後続のサブコントローラ40にパケット50を送信する。この結果、異常が発生したサブコントローラ40の更新処理を後回しにして、他のサブコントローラ40の更新処理が先に行われる。このため、サブコントローラ40の更新処理の完了率を早期に高めることができる。なお、ステップS16より前の処理は、図6に示した通りであるため、詳細な説明を省略する。
図10は、通信エラーが発生したサブコントローラ40をスキップして、ファームイメージ31の更新処理を継続する処理の例を示すフローチャートである。この異常対応処理では、通信エラーが発生していないサブコントローラ40に対して優先してパケット50の送信が行われる。例えば、コントローラ20がサブコントローラ40であることを想定する。この場合、サブコントローラ40は、パケット50の次の送信先であるサブコントローラ40からファームイメージ31の更新途中に発生した異常に関する情報を含むデータを受信した場合に、異常に関する情報を含むデータを送信したサブコントローラ40をスキップして、後続のサブコントローラ40にパケット50を送信する。この結果、異常が発生したサブコントローラ40の更新処理を後回しにして、他のサブコントローラ40の更新処理が先に行われる。このため、サブコントローラ40の更新処理の完了率を早期に高めることができる。なお、ステップS16より前の処理は、図6に示した通りであるため、詳細な説明を省略する。
図6に示したように、任意のコントローラ20のパケット生成部44がパケット50を生成し(S16)、サブ通信部41がパケット50を送信する(S17)。次に、サブ通信部41は、パケット50の送信が成功したか否かを確認する(S18)。
パケット50の送信が成功した場合(S18のYES)、コントローラ20は、図6のステップS20以降の処理に移る。一方、パケット50の送信が失敗した場合(S18のNO)、コントローラ20は、ステップS19の異常対応処理を行う。
そこで、コントローラ20のパケット生成部44は、通信異常が発生したコントローラ20の次の順番のコントローラ20に通信異常を通知するための異常通知メッセージのパケット50を生成する(S41)。本処理では、コマンド58が「スキップ発生通知コマンド」、コマンドデータ59が「通信異常が発生したコントローラ20のID」となる。
次に、サブ通信部41は、通信異常が発生したコントローラ20の次の順番のコントローラ20に異常通知メッセージのパケット50を送信する(S42)。そして、イメージ構築部45は、パケット50の送信に失敗したコントローラ20をスキップした送信順番53にデータを更新し(S43)、ステップS16に移る。
その後、コントローラ20は、更新した送信順番53を基にステップS16でパケット50を生成する。このパケット50は、コントローラ20が、スキップ先のコントローラ20に改めてファームイメージ31を送信し直すものであり、ステップS17で送信されるパケット50の送信先は、スキップ先のコントローラ20である。
このような処理フローにより、通信異常の発生時においても、マスタコントローラ30は、サブコントローラ40に対するファームイメージ31の更新を継続できる。また、サブコントローラ40は、この通信異常によってスキップしたサブコントローラ40の情報をマスタコントローラ30に通知することができる。このため、マスタコントローラ30は、図10に示した処理フローによりスキップされたサブコントローラ40に対して再度、ファームイメージ31の更新を実行できる。
なお、マスタコントローラ30が再度、ファームイメージ31の更新を実行する際には、マスタコントローラ30からサブコントローラ40に対して、コマンド58を「イメージ消去コマンド」としたパケット50を送る必要がある。イメージ消去コマンドは、サブコントローラ40にファームイメージ31の残骸が残っている場合、マスタコントローラ30がサブコントローラ40に対して、ファームイメージ31の残骸の消去を指示するために用いられる。
[ツリー構造]
次に、図1に示したエレベーターシステム100からマスタコントローラ30とサブコントローラ40の関係となるコントローラを抽出した、様々なツリー構造について説明する。
次に、図1に示したエレベーターシステム100からマスタコントローラ30とサブコントローラ40の関係となるコントローラを抽出した、様々なツリー構造について説明する。
<エレベーターコントローラ+フロアコントローラの構成>
まず、エレベーターコントローラ5と、複数のフロアコントローラ11と、で構成されるツリー構造について、図11を用いて説明する。
図11は、エレベーターコントローラ5と、複数のフロアコントローラ11と、で構成されたツリー構造の例を示すブロック図である。
まず、エレベーターコントローラ5と、複数のフロアコントローラ11と、で構成されるツリー構造について、図11を用いて説明する。
図11は、エレベーターコントローラ5と、複数のフロアコントローラ11と、で構成されたツリー構造の例を示すブロック図である。
1基のエレベーター15は、一つのエレベーターコントローラ5と、階床数M分だけ存在するフロアコントローラ11(1)~11(M)とが、通信路12で接続されたツリー構造である。
上位の群管理コントローラ4からエレベーターコントローラ5にファームイメージ31がダウンロードされた場合を想定する。そして、エレベーターコントローラ5又は複数のフロアコントローラ11のうち、ファームイメージ31が記憶されている一つがマスタコントローラ30であり、他がサブコントローラ40である構成とする。例えば、エレベーターコントローラ5がマスタコントローラ30となり、フロアコントローラ11がサブコントローラ40となる。マスタコントローラ30は、送信順番を含むパケット50をサブコントローラ40に送信し、パケット50を受信したサブコントローラ40は、ファームイメージ31を更新する。このようにエレベーターコントローラ5と、複数のフロアコントローラ11(1)~11(M)とをマスタコントローラ30とサブコントローラ40の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ40のファームイメージ31の更新処理を行うことが可能となる。
なお、エレベーターコントローラ5を経由して、任意のフロアコントローラ11がファームイメージ31をダウンロードする場合がある。この場合には、一つのフロアコントローラ11がマスタコントローラ30となり、それ以外のフロアコントローラ11及びエレベーターコントローラ5とがサブコントローラ40となる。このような構成とした場合、ツリー構造の下位のコントローラ(フロアコントローラ11)がマスタコントローラ30、上位のコントローラ(エレベーターコントローラ5)がサブコントローラ40となる。このため、マスタコントローラ30となるフロアコントローラ11が、エレベーターコントローラ5から各フロアの呼び登録情報を取得できる。逆に、エレベーターコントローラ5が各フロアコントローラ11から呼び登録情報を取得することもできる。このため、本実施の形態によれば、ツリー構造の上位、下位の区別による限定なく、パケット通信システム200が動作することが可能となる。
また、保守端末19に接続されてファームイメージ31をダウンロードしたコントローラ20がマスタコントローラ30となる場合、このコントローラ20と同一セグメントに接続されている他のコントローラ20がサブコントローラ40となる。ここで、同一セグメントに接続されているその他のコントローラ20とは、マスタコントローラ30が通信コントローラ3の場合には、群管理コントローラ4である。また、マスタコントローラ30が群管理コントローラ4の場合には、エレベーターコントローラ5である。また、マスタコントローラ30がエレベーターコントローラ5の場合は、かごコントローラ10及びフロアコントローラ11である。
<フロアの呼び登録の有無に応じた順番の生成処理>
次に、エレベーターコントローラ5が、運行状態の一つである各フロアにおける呼び登録を基にして、送信順番53のデータを生成する処理について、図12を用いて説明する。
図12は、フロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。
次に、エレベーターコントローラ5が、運行状態の一つである各フロアにおける呼び登録を基にして、送信順番53のデータを生成する処理について、図12を用いて説明する。
図12は、フロアの呼び登録の有無に応じた順番の生成処理の例を示すフローチャートである。
ここでは、マスタコントローラ30として用いられるエレベーターコントローラ5は、フロアコントローラ11から運行状態として取得した、各フロアの呼び登録の状況に応じて送信順番を生成し、フロアの滞在人数の状況に応じて、送信順番を並べ替える。このため、フロアコントローラ11の呼び登録による処理の負荷に応じた送信順番が生成される。また、フロアの滞在人数の状況に応じてエレベーター15のフロア毎の稼働状況が判明するので、フロアコントローラ11への送信順番を並べ替えることで、負荷が低いフロアコントローラ11から順にファームイメージ31が更新されるようになる。
始めに、エレベーターコントローラ5の運行状態取得部33は、各フロアのフロアコントローラ11から、各フロアの呼び登録情報を取得する(S51)。次に、エレベーターコントローラ5は、全てのフロアの呼び登録情報を取得できたか否かを判断する(S52)。
全てのフロアの呼び登録情報を取得できた場合(S52のYES)、エレベーターコントローラ5の順番生成部34は、取得された呼び登録情報に応じて、フロアコントローラ11の送信順を並び替えて送信順番53のデータを生成し(S53)、本処理を終了する。送信順の並び替えは、呼び登録の有無、及び呼び登録の昇順とする。
一方、呼び登録情報を取得できていないフロアが残っている場合(S52のNO)、エレベーターコントローラ5は、再びステップS51に戻って、全てのフロアの呼び登録情報を取得するまでステップS51,S52の処理を続ける。
ここで、呼び登録情報を取得できていないフロアでは、フロアコントローラ11に処理が割り付けられていない。ここで、上下の呼びの一方に登録がある場合には、処理が割り当てられている。さらに、上下両方の呼びの登録がある場合には、処理の負荷が一番大きくなる。
このため、順番生成部34は、フロアへの呼び登録情報の割り当てに応じた送信順番53のデータを生成することで、処理割り当ての無いフロアコントローラ11を先の順番とし、処理割り当てが多いフロアコントローラ11を後の順番としてファームイメージ31を適用することができる。なお、群管理コントローラ4が各フロアの呼び登録情報を一括して管理している場合には、エレベーターコントローラ5が群管理コントローラ4から各フロアの呼び登録情報を一括して取得してもよい。
また、順番生成部34は、ファームイメージ31の送信順を、エレベーター15の運行情報に応じた順番にすることで、処理割り当ての無いフロアコントローラ11からファームイメージ31を更新できる。このため、エレベーターコントローラ5は、効率よく更新データを通信することが可能となる。また、エレベーターコントローラ5はフロアコントローラ11に更新された新しいファームイメージ31を適用するために、フロアコントローラ11をすぐに再起動できる可能性が向上する。
<各フロアの滞在人数に応じた順番の生成処理>
次に、エレベーターコントローラ5が、運行状態の一つである各フロアの滞在人数を基にして、送信順番53のデータを生成する処理について、図13を用いて説明する。ここで、滞在人数とは、各フロアにいると予想される人数である。かごからフロアに乗降した人数をフロアごとに算出することで滞在人数を求めることができる。
図13は、フロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。
次に、エレベーターコントローラ5が、運行状態の一つである各フロアの滞在人数を基にして、送信順番53のデータを生成する処理について、図13を用いて説明する。ここで、滞在人数とは、各フロアにいると予想される人数である。かごからフロアに乗降した人数をフロアごとに算出することで滞在人数を求めることができる。
図13は、フロアの滞在人数に応じた順番の生成処理の例を示すフローチャートである。
始めに、エレベーターコントローラ5の運行状態取得部33は、他のエレベーターコントローラ5、又は各フロアのフロアコントローラ11から、各フロアの滞在人数を取得する(S61)。
次に、エレベーターコントローラ5は、全フロアの滞在人数を取得したか否かを確認する(S62)。滞在人数を取得できていないフロアが存在する場合(S62のNO)、エレベーターコントローラ5は、再びステップS61に戻って、全てのフロアの滞在人数を取得するまでステップS61,S62の処理を続ける。
一方、全フロアの滞在人数を取得できた場合(S62のYES)、エレベーターコントローラ5の順番生成部34は、各フロアの滞在人数に応じて、フロアコントローラ11へのパケット50の送信順を並べ替えて(S63)、送信順番53のデータを生成する。その後、本処理を終了する。
並べ替えの送信順は、例えば、滞在人数の昇順とする。滞在人数が多い方が、呼び発生の確率が高くなるので、処理の負荷が大きくなる可能性が高くなる。逆に滞在人数が少ないと、呼び発生の確率が低くなるので、処理に余裕がある可能性が高くなる。
よって、この滞在人数に応じた送信順番53のデータを生成することで、処理に余裕のあるフロアコントローラ11を最初とし、処理の負荷が大きくなる可能性のあるフロアコントローラ11を最後とする順番にファームイメージ31を適用することができる。なお、各フロアの滞在人数を、群管理コントローラ4が一括して管理している場合には、エレベーターコントローラ5が群管理コントローラ4から各フロアの滞在人数を取得してもよい。また、エレベーターコントローラ5自身が各フロアの滞在人数を管理している場合には、その管理データを利用してもよい。
このようにエレベーターコントローラ5は、エレベーター15の運行情報(各フロアの滞在人数)に応じてフロアコントローラ11への送信順を並べ替えることで、処理に余裕のあるフロアコントローラ11からファームイメージ31を更新できる。このため、エレベーターコントローラ5は、ファームイメージ31の更新データをフロアコントローラ11に効率よく送信することが可能となる。また、ファームイメージ31の更新データを受信したフロアコントローラ11は、更新された新しいファームイメージ31を適用するために、すぐに再起動できる可能性が向上する。
<群管理コントローラ+エレベーターコントローラ>
次に、複数のエレベーター15と、群管理コントローラ4とが通信路16で接続されて構成されるツリー構造について、図14を用いて説明する。
図14は、群管理コントローラ4と、複数のエレベーターコントローラ5と、で構成されるツリー構造の例を示すブロック図である。ここでは、図1に示したエレベーターグループ18が、1台の群管理コントローラ4と、任意の数だけ存在するエレベーター15(1)~15(M)にそれぞれ対応して設けられた複数のエレベーターコントローラ5とを含んでいる。
次に、複数のエレベーター15と、群管理コントローラ4とが通信路16で接続されて構成されるツリー構造について、図14を用いて説明する。
図14は、群管理コントローラ4と、複数のエレベーターコントローラ5と、で構成されるツリー構造の例を示すブロック図である。ここでは、図1に示したエレベーターグループ18が、1台の群管理コントローラ4と、任意の数だけ存在するエレベーター15(1)~15(M)にそれぞれ対応して設けられた複数のエレベーターコントローラ5とを含んでいる。
ここでは、群管理コントローラ4又は複数のエレベーターコントローラ5のうち、ファームイメージ31が記憶されている一つがマスタコントローラ30であり、他がサブコントローラ40とする。この場合、マスタコントローラ30が送信順番を含むパケット50をサブコントローラ40に送信し、パケット50を受信したサブコントローラ40がファームイメージ31を更新する。
そこで、上位の通信コントローラ3から群管理コントローラ4にファームイメージ31がダウンロードされた場合を想定する。この場合には、群管理コントローラ4がマスタコントローラ30となり、複数のエレベーターコントローラ5がサブコントローラ40となる構成である。このように群管理コントローラ4と、複数のエレベーターコントローラ5とをマスタコントローラ30とサブコントローラ40の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ40のファームイメージ31の更新処理を行うことが可能となる。
なお、群管理コントローラ4を経由して、任意のエレベーターコントローラ5がファームイメージ31をダウンロードする場合がある。この場合、一つのエレベーターコントローラ5がマスタコントローラ30となり、それ以外のエレベーターコントローラ5及び群管理コントローラ4とがサブコントローラ40となる構成である。本実施の形態に係る構成であれば、マスタコントローラ30となる一つのエレベーターコントローラ5が、サブコントローラ40となる群管理コントローラ4又は他のエレベーターコントローラ5から、各エレベーターコントローラ5に割り当てた呼びの呼び数を取得できる。
また、保守端末19に接続されてファームイメージ31をダウンロードしたコントローラ20がマスタコントローラ30となる場合、このコントローラ20と同一セグメントに接続されているその他のコントローラ20がサブコントローラ40となる。ここで、ファームイメージ31をダウンロードしたコントローラ20として、例えば、エレベーターコントローラ5、かごコントローラ10、又はフロアコントローラ11が想定される。
<エレベーターの呼びの割当の有無及び大小に応じた順番の生成処理>
次に、群管理コントローラ4が、運行状態の一つであるエレベーター15の呼びの割当数を基にして、送信順番53のデータを生成する処理について、図15を用いて説明する。
図15は、エレベーター15の呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。この処理では、マスタコントローラ30の順番生成部34は、運行状態として取得した、複数のエレベーター15への呼びの割当の状況に応じて送信順番を生成する。このため、エレベーターコントローラ5の処理の負荷に応じた送信順番が生成される。
次に、群管理コントローラ4が、運行状態の一つであるエレベーター15の呼びの割当数を基にして、送信順番53のデータを生成する処理について、図15を用いて説明する。
図15は、エレベーター15の呼びの割当数に応じた順番の生成処理の例を示すフローチャートである。この処理では、マスタコントローラ30の順番生成部34は、運行状態として取得した、複数のエレベーター15への呼びの割当の状況に応じて送信順番を生成する。このため、エレベーターコントローラ5の処理の負荷に応じた送信順番が生成される。
始めに、群管理コントローラ4の運行状態取得部33は、各エレベーター15に割り当てられた呼びの割当数を取得する(S71)。次に、群管理コントローラ4の順番生成部34は、呼びの割当数に応じてエレベーターコントローラ5の送信順を並べ替えて送信順番53のデータを生成し(S72)、本処理を終了する。
送信順の並べ替えは、呼びの割当数の昇順とする。呼びの割当数が多い方が、呼びの割り当てられたフロアへのかご7の移動、停止、出発の処理回数が多くなるので、エレベーターコントローラ5の処理の負荷も大きくなる可能性がある。逆に、呼びの割当数が少ない方が、エレベーターコントローラ5の処理の負荷が少ない。また、エレベーターコントローラ5が、停止つまり待機状態に遷移する可能性が高くなる。
また、群管理コントローラ4の順番生成部34は、エレベーターコントローラ5へのファームイメージ31の送信順を、エレベーター15の運行状態に応じた順番にすることで、処理に余裕がある、又は直近で待機状態になる可能性が高いエレベーターコントローラ5からファームイメージ31を更新できる。このため、エレベーターコントローラ5は、効率よく更新データの通信が可能となる。また、群管理コントローラ4は、エレベーターコントローラ5に更新された新しいファームイメージ31を適用するために、すぐにエレベーターコントローラ5を再起動できる可能性が向上する。
<通信コントローラ+群管理コントローラ>
次に、複数のエレベーターグループ18と、通信コントローラ3とが通信路17で接続されるツリー構造について、図16を用いて説明する。
図16は、通信コントローラ3と、複数の群管理コントローラ4と、で構成されるツリー構造の例を示すブロック図である。ここでは、図1に示した1台の通信コントローラ3と、任意の数だけ存在するエレベーターグループ18(1)~18(M)にそれぞれ対応して設けられた複数の群管理コントローラ4とを示す。なお、図11、図14、図16に示したコントローラ、グループの数を表すMの値はそれぞれ異なってよい。
次に、複数のエレベーターグループ18と、通信コントローラ3とが通信路17で接続されるツリー構造について、図16を用いて説明する。
図16は、通信コントローラ3と、複数の群管理コントローラ4と、で構成されるツリー構造の例を示すブロック図である。ここでは、図1に示した1台の通信コントローラ3と、任意の数だけ存在するエレベーターグループ18(1)~18(M)にそれぞれ対応して設けられた複数の群管理コントローラ4とを示す。なお、図11、図14、図16に示したコントローラ、グループの数を表すMの値はそれぞれ異なってよい。
この処理では、通信コントローラ3又は複数の群管理コントローラ4のうち、ファームイメージ31が記憶されている一つがマスタコントローラ30であり、他がサブコントローラ40である。そして、マスタコントローラ30が送信順番を含むパケット50をサブコントローラ40に送信し、パケット50を受信したサブコントローラ40がファームイメージ31を更新する。このように通信コントローラ3と、複数の群管理コントローラ4とをマスタコントローラ30とサブコントローラ40の関係とすることで、一つのコントローラに限定されることなく、サブコントローラ40のファームイメージ31の更新処理を行うことが可能となる。
そこで、上位の通信コントローラ3から群管理コントローラ4にファームイメージ31がダウンロードされた場合を想定する。この場合には、通信コントローラ3がマスタコントローラ30となり、複数の群管理コントローラ4がサブコントローラ40となる構成になる。
また、通信コントローラ3を経由して、任意の群管理コントローラ4がファームイメージ31をダウンロードする場合がある。この場合には、一つの群管理コントローラ4がマスタコントローラ30となり、それ以外の群管理コントローラ4及び通信コントローラ3がサブコントローラ40となる構成になる。この構成とした場合、一つの群管理コントローラ4が通信コントローラ3及び他の群管理コントローラ4にファームイメージ31を送信することも可能である。
また、保守端末19に接続されてファームイメージ31をダウンロードしたコントローラ20がマスタコントローラ30となる場合、このコントローラ20と同一セグメントに接続されているその他のコントローラ20がサブコントローラ40となる。ここで、ファームイメージ31をダウンロードしたコントローラ20として、例えば、通信コントローラ3が想定される。
<群管理コントローラの割当数に応じた順番の生成処理>
次に、通信コントローラ3の順番生成部34は、運行状態の一つである群管理コントローラ4の割当処理の結果である複数の群管理コントローラ4への呼びの割当回数の状況、つまりエレベーター15への呼びの割当数と、割当処理状態とを元に、送信順番53のデータを生成する処理について、図17を用いて説明する。ここでは、このため、群管理コントローラ4への呼びの割当回数の状況による処理の負荷に応じた送信順番が生成される。
図17は、エレベーター15への呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。
次に、通信コントローラ3の順番生成部34は、運行状態の一つである群管理コントローラ4の割当処理の結果である複数の群管理コントローラ4への呼びの割当回数の状況、つまりエレベーター15への呼びの割当数と、割当処理状態とを元に、送信順番53のデータを生成する処理について、図17を用いて説明する。ここでは、このため、群管理コントローラ4への呼びの割当回数の状況による処理の負荷に応じた送信順番が生成される。
図17は、エレベーター15への呼びの割当数と、割当処理状態に応じた順番の生成処理の例を示すフローチャートである。
始めに、通信コントローラ3の運行状態取得部33は、各群管理コントローラ4から呼びの割当数及び割当処理状態を取得する(S81)。次に、運行状態取得部33は、全ての群管理コントローラ4から呼びの割当数及び割当処理状態を取得したか否かを確認する(S82)。全ての群管理コントローラ4から取得してない場合(S82のNO)、運行状態取得部33は、ステップS81に戻って、呼びの割当数及び割当処理状態の取得を繰り返す。
一方、全ての群管理コントローラ4について取得した場合には(S82のYES)、通信コントローラ3の順番生成部34は、運行状態取得部33が取得した割当数及び割当処理状態に応じて群管理コントローラ4の送信順を並べ替えて送信順番53のデータを生成し(S83)、本処理を終了する。
送信順の並べ替えは、呼びの割当処理の有無及び割当数の昇順とする。呼びの割当処理が終了した群管理コントローラ4は、処理の負荷に余裕がある。呼びの割り当て処理が終了している群管理コントローラ4であっても、呼びの割当数が多い群管理コントローラ4の方が、割当できる選択肢が少ないために、群管理コントローラ4の処理の負荷が増える可能性が低い。つまり、呼びが割当てられる選択肢が少ないので、群管理コントローラ4の処理の負荷が増加する可能性が低くなる。
一方、呼びの割当処理中の群管理コントローラ4は、割当処理が終了した群管理コントローラ4よりも処理の負荷が大きい。呼びの割当処理中の群管理コントローラ4であっても、既に割り当てられた呼びの割当数が少ない群管理コントローラ4の方が、これから呼びが割当られる選択肢が多いために、群管理コントローラ4の処理の負荷が増える可能性が高い。
このため、順番生成部34は、呼びの割当処理か否かという点、及び呼びの割当数の大小に応じて送信順番53のデータを生成することで、割当処理が終了した群管理コントローラ4を最初とし、処理中で且つ割当数が少ない処理の負荷の大きい群管理コントローラ4を最後とする順番にファームイメージ31を適用することができる。
このような運行情報に応じた順番にすることで、処理に余裕のある群管理コントローラ4からファームイメージ31を効率よく更新できる。このため、通信コントローラ3は、更新された新しいファームイメージ31を群管理コントローラ4に適用するために、すぐに群管理コントローラ4を再起動できる可能性が向上する。
<各コントローラの再起動の処理>
次に、群管理コントローラ4、エレベーターコントローラ5、フロアコントローラ11がそれぞれファームイメージ31を適用するための再起動の処理について、図18~図20を用いて説明する。
次に、群管理コントローラ4、エレベーターコントローラ5、フロアコントローラ11がそれぞれファームイメージ31を適用するための再起動の処理について、図18~図20を用いて説明する。
<群管理コントローラの再起動(割り当て済み)>
まず、群管理コントローラ4が、運行状態の一つである呼びの割当処理状態に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図18を用いて説明する。
図18は、群管理コントローラ4がファームイメージ31を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、群管理コントローラ4に対するファームイメージ31の更新が完了した時点で呼びの割当処理が実行されていない場合に、ファームイメージ31の更新が完了した群管理コントローラ4のイメージ構築部45が再起動を実施する。このため、群管理コントローラ4が管理するエレベーター15で利用者のいない時間帯に群管理コントローラ4が再起動されることとなり、利用者に不便を生じさせない。
まず、群管理コントローラ4が、運行状態の一つである呼びの割当処理状態に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図18を用いて説明する。
図18は、群管理コントローラ4がファームイメージ31を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、群管理コントローラ4に対するファームイメージ31の更新が完了した時点で呼びの割当処理が実行されていない場合に、ファームイメージ31の更新が完了した群管理コントローラ4のイメージ構築部45が再起動を実施する。このため、群管理コントローラ4が管理するエレベーター15で利用者のいない時間帯に群管理コントローラ4が再起動されることとなり、利用者に不便を生じさせない。
始めに、群管理コントローラ4は、呼びの割当処理の実行状態を取得する(S91)。群管理コントローラ4は、呼びの割当処理が実行中か否かを確認する(S92)。呼びの割当処理が実行中であれば(S92のYES)、再起動は実行せず、本処理を終了する。一定時間後、群管理コントローラ4は、ステップS91から処理を再開する。一方、呼びの割当処理が実行中でない、すなわち呼びの割当処理が終了し、呼びが割当済みであれば(S92のNO)、群管理コントローラ4を再起動し(S93)、本処理を終了する。
このような処理により、群管理コントローラ4は、ファームイメージ31を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ31を適用するための再起動をすることが可能となる。
<エレベーターコントローラの再起動(次回到着前に停止モードを予約)>
次に、エレベーターコントローラ5が、運行状態の一つである行先階情報に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図19を用いて説明する。
図19は、エレベーターコントローラ5がファームイメージ31を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、エレベーターコントローラ5のイメージ構築部45が、エレベーターコントローラ5のファームイメージ31の更新が完了した時点でエレベーター15の行先階が登録された場合に、エレベーターコントローラ5の新たな呼びの受付を保留とする。そして、エレベーターコントローラ5のイメージ構築部45は、行先階にかごが到着した後に、かごの安全状態を確認できた場合に、エレベーターコントローラ5の再起動を実施する。このため、利用者のいないエレベーター15でエレベーターコントローラ5が再起動されることとなり、利用者に不便を生じさせない。
次に、エレベーターコントローラ5が、運行状態の一つである行先階情報に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図19を用いて説明する。
図19は、エレベーターコントローラ5がファームイメージ31を適用するための再起動を判断する処理の例を示すフローチャートである。この処理では、エレベーターコントローラ5のイメージ構築部45が、エレベーターコントローラ5のファームイメージ31の更新が完了した時点でエレベーター15の行先階が登録された場合に、エレベーターコントローラ5の新たな呼びの受付を保留とする。そして、エレベーターコントローラ5のイメージ構築部45は、行先階にかごが到着した後に、かごの安全状態を確認できた場合に、エレベーターコントローラ5の再起動を実施する。このため、利用者のいないエレベーター15でエレベーターコントローラ5が再起動されることとなり、利用者に不便を生じさせない。
始めに、エレベーターコントローラ5は、運行状態の一つである行先階情報を取得する(S101)。次に、エレベーターコントローラ5は、行先階情報を判定する(S102)。行先階が複数登録されている場合には、エレベーター15の運行を継続する必要があるため再起動することはできない。一方、行先階に一つの階が登録されている、又は行先階が登録されていない場合には(S102のNO)、エレベーターコントローラ5は、新たに呼びの登録が発生しないように呼び登録をマスクする(S103)。そこで、エレベーターコントローラ5は、新たな呼びを受け付けないモードに遷移すると共に、かご7が行先階に到着した際に再起動できる運行モードとして、例えば保守モードにするように処理する。
次に、エレベーターコントローラ5は、かご7が行先階に到着したか否かを確認し(S104)、かご7が行先階に到着したか否かを判定する(S105)。かご7が行先階に到着していなければ(S105のNO)、エレベーターコントローラ5は、ステップS104に戻ってかご7の到着の確認を継続する。
一方、かご7が行先階に到着した場合には(S105のYES)、エレベーターコントローラ5は、かご状態を取得する(S106)。次に、エレベーターコントローラ5は、取得したかご状態が、少なくとも乗客に対して安全な状態であるか否かを判定する(S107)。
かご7に乗客が乗っておらず且つドアが閉じている状態が一番安全な状態である。安全状態でないと判定した場合(S107のNO)、エレベーターコントローラ5は、本処理を終了する。一定時間後、エレベーターコントローラ5は、ステップS101から処理を再開する。一方、安全状態と判定した場合には(S107のYES)、エレベーターコントローラ5は、自身の再起動を実行し(S108)、本処理を終了する。
このような処理により、エレベーターコントローラ5は、ファームイメージ31を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ31を適用するための再起動をすることが可能となる。
<フロアコントローラの再起動(呼び登録の確認)>
次に、フロアコントローラ11が、運行状態の一つである上下呼びの登録に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図20を用いて説明する。ここでは、フロアコントローラ11のイメージ構築部45が、フロアコントローラ11のファームイメージ31の更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、フロアコントローラ11の再起動を実施する。このため、利用者のいないフロアでフロアコントローラ11が再起動されることとなり、利用者に不便を生じさせない。
図20は、フロアコントローラ11がファームイメージ31を適用するために再起動する処理の例を示すフローチャートである。
次に、フロアコントローラ11が、運行状態の一つである上下呼びの登録に応じて、更新されたファームイメージ31を適用するために再起動する処理について、図20を用いて説明する。ここでは、フロアコントローラ11のイメージ構築部45が、フロアコントローラ11のファームイメージ31の更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、フロアコントローラ11の再起動を実施する。このため、利用者のいないフロアでフロアコントローラ11が再起動されることとなり、利用者に不便を生じさせない。
図20は、フロアコントローラ11がファームイメージ31を適用するために再起動する処理の例を示すフローチャートである。
始めに、フロアコントローラ11は、上下呼びの登録の状態を取得する(S111)。次に、フロアコントローラ11は、上下呼びの登録の有無を判定する(S112)。上下呼びの登録が有る場合(S112のYES)、エレベーター15の運転が継続しているので再起動できない。したがって、本処理はここで終了し、一定時間後、フロアコントローラ11は、ステップS111から処理を再開する。
一方、上下呼びの登録が無い場合(S112のNO)、エレベーター15の運行状態から当該フロアのフロアコントローラ11が一時的に切り離された状態に相当するので、フロアコントローラ11は、再起動を実行し(S113)、本処理を終了する。
このような処理により、フロアコントローラ11は、ファームイメージ31を更新した際に、保守モードのように特別なモードや作業時間を確保することなく、新たなファームイメージ31を適用するための再起動をすることが可能となる。
なお、本発明は上述した各実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した各実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
例えば、上述した各実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
1…センタ、3…通信コントローラ、4…群管理コントローラ、5…エレベーターコントローラ、10…かごコントローラ、11…フロアコントローラ、18…エレベーターグループ、19…保守端末、20…コントローラ、30…マスタコントローラ、31…ファームイメージ、32…イメージ分割部、33…運行状態取得部、34…順番生成部、35…パケット生成部、36…マスタ通信部、40…サブコントローラ、41…サブ通信部、42…パケット解釈部、43…送信先抽出部、44…パケット生成部、45…イメージ構築部、50…パケット、100…エレベーターシステム、200…パケット通信システム
Claims (15)
- ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムであって、
前記マスタコントローラは、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第1送信データを送信し、
前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第1送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第1送信データを送信する
エレベーターシステム。 - 前記マスタコントローラは、
エレベーターの運行状態を取得する運行状態取得部と、
前記ファームウェアの送信先である前記サブコントローラの送信順番を前記運行状態に応じて生成する順番生成部と、
前記ファームウェアを分割するファームウェア分割部と、
前記送信順番にしたがって前記サブコントローラに前記ファームウェアを送信するための第1送信データを生成する第1送信データ生成部と、
前記送信順番が最先である前記サブコントローラに前記第1送信データを送信する第1通信部と、を備え、
前記第1送信データ生成部は、前記マスタコントローラを識別する情報と、前記サブコントローラを識別する情報と、前記送信順番と、分割された前記ファームウェアの構築順番と、分割された前記ファームウェアとを含む前記第1送信データを生成する
請求項1に記載のエレベーターシステム。 - 前記サブコントローラは、前記マスタコントローラ、又は前記第1送信データの送信元である前記サブコントローラから前記第1送信データを受信する第2通信部と、
前記第1送信データを解釈するデータ解釈部と、
前記データ解釈部が解釈した、分割された前記ファームウェアを前記構築順番に従って元の前記ファームウェアに構築するファームウェア構築部と、
前記データ解釈部が解釈した、前記送信順番に基づいて、前記第1送信データの次の送信先である前記サブコントローラを抽出する送信先抽出部と、
前記第1送信データの次の送信先である前記サブコントローラに前記ファームウェアを送信するための第2送信データを生成する第2送信データ生成部と、を有し、
前記第2通信部は、前記第2送信データを次の送信先である前記サブコントローラに送信する
請求項2に記載のエレベーターシステム。 - 前記ファームウェア構築部による前記ファームウェアの更新途中に異常が発生した場合に、前記第2通信部は、前記異常に関する情報を含むデータを、前記送信順番とは逆順で前記マスタコントローラに送信する
請求項3に記載のエレベーターシステム。 - 前記ファームウェア構築部は、前記ファームウェアの更新途中に異常が発生した場合に、前記ファームウェア構築部が構築していた前記ファームウェアを消去する
請求項4に記載のエレベーターシステム。 - 前記第2通信部は、前記第1送信データの次の送信先である前記サブコントローラから前記ファームウェアの更新途中に発生した異常に関する情報を含むデータを受信した場合に、前記異常に関する情報を含むデータを送信した前記サブコントローラをスキップして、後続の前記サブコントローラに前記第2送信データを送信する
請求項3に記載のエレベーターシステム。 - 前記エレベーターの動作を制御するエレベーターコントローラと、
前記エレベーターが昇降するフロアごとに設けられ、前記フロアの状況を前記エレベーターコントローラに伝える複数のフロアコントローラと、を備え、
前記エレベーターコントローラ又は複数のフロアコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第1送信データを前記サブコントローラに送信し、前記第1送信データを受信した前記サブコントローラが前記ファームウェアを更新する
請求項3に記載のエレベーターシステム。 - 前記マスタコントローラは、前記運行状態として取得した、各フロアの呼び登録の状況に応じて前記送信順番を生成し、前記フロアの滞在人数の状況に応じて、前記送信順番を並べ替える
請求項7に記載のエレベーターシステム。 - 前記ファームウェア構築部は、前記フロアコントローラのファームウェアの更新が完了した時点で呼びの登録を確認し、呼びが登録されていない場合に、前記フロアコントローラの再起動を実施する
請求項7に記載のエレベーターシステム。 - 前記エレベーターの動作を制御する複数のエレベーターコントローラの動作を制御する群管理コントローラと、
複数のエレベーターコントローラと、を備え、
前記群管理コントローラ又は複数のエレベーターコントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第1送信データを前記サブコントローラに送信し、前記第1送信データを受信した前記サブコントローラが前記ファームウェアを更新する
請求項3に記載のエレベーターシステム。 - 前記順番生成部は、前記運行状態として取得した、複数の前記エレベーターへの呼びの割当の状況に応じて前記送信順番を生成する
請求項10に記載のエレベーターシステム。 - 前記ファームウェア構築部は、前記エレベーターコントローラの前記ファームウェアの更新が完了した時点で前記エレベーターの行先階が登録された場合に、前記エレベーターコントローラの新たな呼びの受付を保留とし、前記行先階にかごが到着した後に、前記かごの安全状態を確認できた場合に、前記エレベーターコントローラが再起動を実施する
請求項10に記載のエレベーターシステム。 - 複数のエレベーターコントローラの動作を制御する複数の群管理コントローラに対する通信を制御する通信コントローラと、
複数の前記群管理コントローラと、を備え、
前記通信コントローラ又は複数の前記群管理コントロ―ラのうち、前記ファームウェアが記憶されている一つがマスタコントローラであり、他がサブコントローラである場合に、前記マスタコントローラが前記送信順番を含む前記第1送信データを前記サブコントローラに送信し、前記第1送信データを受信した前記サブコントローラが前記ファームウェアを更新する
請求項3に記載のエレベーターシステム。 - 前記順番生成部は、前記運行状態として取得した、複数の前記群管理コントローラへの呼びの割当回数の状況に応じて前記送信順番を生成し、
前記ファームウェア構築部は、前記群管理コントローラに対する前記ファームウェアの更新が完了した時点で呼びの割当処理が実行されていない場合に、前記ファームウェアの更新が完了した群管理コントローラが再起動を実施する
請求項13に記載のエレベーターシステム。 - ファームウェアを送信するマスタコントローラと、前記ファームウェアを受信して前記ファームウェアを更新するサブコントローラとを備えるエレベーターシステムで行われるファームウェア送信方法であって、
前記マスタコントローラが、前記エレベーターの運行状態に応じて、複数の前記サブコントローラに対する前記ファームウェアの送信順番を生成し、前記送信順番が優先される前記サブコントローラに対して、前記ファームウェア及び前記送信順番を含む第1送信データを送信する処理と、
前記送信順番が優先される前記サブコントローラは、前記マスタコントローラから前記第1送信データを受信して前記ファームウェアの更新を行い、前記送信順番が次に優先される前記サブコントローラに前記第1送信データを送信する処理と、を含む
ファームウェア送信方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022030614A JP2023127066A (ja) | 2022-03-01 | 2022-03-01 | エレベーターシステム及びファームウェア送信方法 |
CN202280077187.8A CN118284573A (zh) | 2022-03-01 | 2022-11-22 | 电梯***和固件发送方法 |
PCT/JP2022/043113 WO2023166795A1 (ja) | 2022-03-01 | 2022-11-22 | エレベーターシステム及びファームウェア送信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022030614A JP2023127066A (ja) | 2022-03-01 | 2022-03-01 | エレベーターシステム及びファームウェア送信方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023127066A true JP2023127066A (ja) | 2023-09-13 |
Family
ID=87883569
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022030614A Pending JP2023127066A (ja) | 2022-03-01 | 2022-03-01 | エレベーターシステム及びファームウェア送信方法 |
Country Status (3)
Country | Link |
---|---|
JP (1) | JP2023127066A (ja) |
CN (1) | CN118284573A (ja) |
WO (1) | WO2023166795A1 (ja) |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE112006003745T8 (de) * | 2006-02-10 | 2009-04-16 | Mitsubishi Electric Corp. | Fernaktualisierungssystem für ein Aufzugssteuerprogramm |
JP5072411B2 (ja) * | 2007-04-05 | 2012-11-14 | 三菱電機株式会社 | エレベータの制御システム |
JP2016143359A (ja) * | 2015-02-05 | 2016-08-08 | シャープ株式会社 | 電子機器及びファームウェア更新方法 |
CN104973466B (zh) * | 2015-05-25 | 2017-01-11 | 广州日滨科技发展有限公司 | 电梯控制程序的远程更新方法和*** |
JP6531060B2 (ja) * | 2016-04-08 | 2019-06-12 | 株式会社日立製作所 | 群管理エレベーター装置及び呼び登録装置の機能変更方法 |
CN111212805B (zh) * | 2017-10-27 | 2021-07-09 | 因温特奥股份公司 | 用于建筑物的人员运送设备的安全*** |
JP2021130534A (ja) * | 2020-02-19 | 2021-09-09 | 株式会社日立製作所 | エレベーター制御装置及びエレベーター制御方法 |
-
2022
- 2022-03-01 JP JP2022030614A patent/JP2023127066A/ja active Pending
- 2022-11-22 CN CN202280077187.8A patent/CN118284573A/zh active Pending
- 2022-11-22 WO PCT/JP2022/043113 patent/WO2023166795A1/ja unknown
Also Published As
Publication number | Publication date |
---|---|
CN118284573A (zh) | 2024-07-02 |
WO2023166795A1 (ja) | 2023-09-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101076736B (zh) | 在监督处理控制***中配置冗余的设备和方法 | |
US5884729A (en) | Apparatus and method for controlling a plurality of elevator cars | |
CN112910937B (zh) | 容器集群中的对象调度方法、装置、服务器和容器集群 | |
CN107750442A (zh) | 用于更换输送设备中的控制单元的方法 | |
CN104486394B (zh) | 不中断业务软件升级方法及装置 | |
CN102426415A (zh) | 冗余管理器 | |
US9413552B2 (en) | Internet protocol addressing of devices employing the network ring topology | |
CN109960233A (zh) | 用于自动配置在过程控制***中的更换现场设备的方法和设备 | |
JP5396766B2 (ja) | 分散電源系統の制御方式 | |
CN113849264A (zh) | 用于编排终端设备上的基于容器的应用的方法 | |
CN110247980B (zh) | 一种局域网中的网关控制方法及网关 | |
JP2023127066A (ja) | エレベーターシステム及びファームウェア送信方法 | |
CN107872404A (zh) | 业务分片处理方法、装置及软件定义网络控制器 | |
JP5473346B2 (ja) | エレベータの群管理制御装置 | |
CN113086783B (zh) | 一种电梯群管制运行***及方法 | |
CN111556126B (zh) | 模型管理方法、***、计算机设备和存储介质 | |
CN114644267A (zh) | 双层电梯的组群管理控制装置以及组群管理控制方法 | |
CN112532454A (zh) | 一种fc交换网络***网络管理方法 | |
CN115448116A (zh) | 一种电梯云控制*** | |
CN110022220A (zh) | 名片识别中的路由激活方法及*** | |
JP2020175975A (ja) | エレベーター群管理システム及びエレベーター群管理方法 | |
JP7423705B1 (ja) | エレベータ制御システム | |
CN113703972A (zh) | 一种防止大数据任务资源占用过高的方法 | |
JP2004326531A (ja) | プログラマブルコントローラ及びプログラマブルコントローラの多重化システム | |
US10924345B2 (en) | Method for changing the configuration of connected networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20240603 |