JP5826073B2 - エレベータの群管理システム - Google Patents

Description

本発明の実施形態は、複数台のエレベータの運転を制御するエレベータの群管理システムに関する。

エレベータの群管理システムでは、利用者の乗車・降車の状態、システム全体としての平均未応答時間、ホール呼びの発生頻度などからなる交通需要データを学習データとして保存している。そして、これらの学習データを下に制御パラメータを最適化して、交通需要に適した群管理制御を行っている。

なお、「制御パラメータ」とは、一般的に知られている群管理制御の評価関数に用いられるものであり、例えば平均未応答時間に対する重み係数などである。

ここで、上述した学習データを保存する際に、各号機の運転状態はチェックされない。例えば号機台数が６台であった場合に、その６台の中に点検中や故障中などで運休している号機が含まれていても、６台分の学習データとして管理され、その学習データを下に制御パラメータが作成される。このため、制御パラメータが実際の交通需要と合わず、群管理性能が低下することがあった。

特開平４−２３５８６９号公報

上述したように、従来の群管理システムでは、点検や故障により運休している号機があった場合に、学習データの精度が損なわれ、その学習データを元に作成される制御パラメータが実際の交通需要と合わず、群管理性能が低下する可能性があった。

この場合、通常運転中の号機の台数に合わせて評価関数を変更すれば良い。しかし、評価関数自体はプログラムとして予め組み込まれているため、その都度、システム全体をメンテナンスする面倒な作業が必要となり、簡単には変更できない。

本発明が解決しようとする課題は、運休している号機が存在する場合でも学習データの精度を維持でき、群管理性能の低下を防ぐことのできるエレベータの群管理システムを提供することである。

本実施形態に係るエレベータの群管理システムは、複数の号機の運転状態を管理すると共に現在の交通需要を示す交通需要データを作成する運転管理手段と、上記各号機の運行情報に含まれる運転状態情報に基づいて上記各号機の中で通常運転状態にある通常号機の台数を求め、上記通常号機の台数と予め保存判定条件として設定された設定値との比較により上記運転管理手段によって作成された交通需要データが学習データとして保存可能か否かを判定する保存判定手段と、この保存判定手段によって保存可能と判定された交通需要データを学習データとして保存するデータベース手段と、このデータベース手段に保存された学習データに基づいて群管理用の制御パラメータを作成する学習手段と、この学習手段によって作成された群管理用の制御パラメータを用いて上記各号機の運転を群管理制御する群管理制御手段とを具備する。

図１は第１の実施形態に係るエレベータの群管理システムの構成を示すブロック図である。 図２は同実施形態におけるエレベータの群管理システムの処理動作を示すフローチャートである。 図３は同実施形態における各号機の運転状態を示す図であり、群管理システム内の全台数が全て通常運転の状態を示す図である。 図４は同実施形態における各号機の運転状態を示す図であり、群管理システム内の１台の号機が点検運転の状態を示す図である。 図５は同実施形態における各号機の運転状態を示す図であり、群管理システム内の１台の号機が点検運転の状態、別の１台の号機が故障中の状態を示す図である。 図６は同実施形態における群管理制御装置の修正部の処理動作を示すフローチャートである。 図７は同実施形態における任意の号機のＵＰ運転時のかご内の乗降情報を示す図である。 図８は同実施形態における任意の号機に割り当てられたホール呼びの登録時間を示す図である。 図９は同実施形態における交通需要管理表の一例を示す図である。 図１０は同実施形態における交通需要データの修正方法を具体的に説明するための図である。 図１１は第２の実施形態に係るエレベータの群管理システムの構成を示すブロック図である。 図１２は同実施形態におけるエレベータの群管理システムの処理動作を示すフローチャートである。

以下、図面を参照して実施形態を説明する。

（第１の実施形態）
図１は第１の実施形態に係るエレベータの群管理システムの構成を示すブロック図であり、複数台（ここではＡ〜Ｄ号機の４台）のエレベータが群管理された構成が示されている。

図中の１ａ〜１ｄは号機制御部、２ａ〜２ｄは乗りかごである。号機制御部１ａ〜１ｄは、各号機毎に設けられており、それぞれに対応した号機の運転制御を行う。具体的には、乗りかご２ａ〜２ｄを昇降動作させるための図示せぬモータ（巻上機）の制御やドアの開閉制御などを行う。これらの号機制御部１ａ〜１ｄは、コンピュータによって構成される。

乗りかご２ａ〜２ｄは、モータの駆動により昇降路内を昇降動作する。乗りかご２ａ〜２ｄには、それぞれにかご室内の積載荷重を検知するための荷重検知器３ａ〜３ｄが設置されている。荷重検知器３ａ〜３ｄによって検知された荷重データは、図示せぬかご室内の行先階釦の操作によって登録されたかご呼びの情報などと共に号機制御部１ａ〜１ｄを介して群管理制御装置１０に伝送される。

また、各階の乗場（エレベータホール）には、ホール呼びを登録するためのホール釦４ａ，４ｂ，４ｃ…が設置されている。このホール釦４ａ，４ｂ，４ｃ…は、図示せぬ伝送ケーブルを介して群管理制御装置１０に接続されている。ホール釦４ａ，４ｂ，４ｃ…は、上方向釦と下方向釦から構成され、利用者の行先方向に応じて、上方向釦または下方向釦を押下するように構成されている。なお、最下階では上方向釦、最上階では下方向釦だけで構成される。

なお、「ホール呼び」とは、各階の乗場に設置されたホール釦の操作により登録される呼びの信号のことであり、登録階と行先方向の情報を含む。「かご呼び」とは、かご室内に設けられた行先階釦の操作により登録される呼びの信号のことであり、行先階の情報を含む。

群管理制御装置１０は、複数台のエレベータ号機の運転を群管理制御するための装置であり、号機制御部１ａ〜１ｄと同様にコンピュータによって構成される。本実施形態において、この群管理制御装置１０には、群管理制御部１１、運転管理部１２、保存判定部１３、データベース部１４、修正部１５、学習部１６が備えられている。なお、これらの処理部は、実際にはソフトウェアによって実現される。

群管理制御部１１は、群管理システム内の各号機の運転を群管理制御する。具体的には、新たな乗場呼びが発生した際に、号機制御部１ａ〜１ｄから得られる各号機の運転状態（かご位置、運転方向、戸開閉状態など）や、ホール呼び・かご呼びの発生状況、荷重データなどの情報に基づいて各号機の中で最適な号機を選出し、その号機に対して当該乗場呼びの割当情報を出力する。

この場合、予め設定された評価関数（群管理用の制御プログラム）を用いて、当該乗場呼びを割り当てた場合の最適さを表す評価値を各号機毎に算出し、最も評価の高い号機に対し、乗場呼びの割当信号を出力する。なお、上記評価値は、その数値が小さいほど評価が高く、その数値が大きいほど評価が低くなることを示す。この群管理制御部１１から出力された割当情報は号機制御部１ａ〜１ｄの中の該当する号機の制御部に送信される。

ここで、上記評価関数には制御パラメータが組み込まれている。この制御パラメータには、例えば平均未応答時間（ホール呼びに対してエレベータの号機が応答するまでの平均的な時間）に対する重み係数、戸開閉時間に対する重み係数などがあり、これらの重み係数を交通需要に適した値に設定しておく必要がある。

運転管理部１２は、群管理制御部１１を介して各号機の運行情報を取得することにより、各号機の運転状態を管理すると共に交通需要データを作成する。

なお、「運行情報」は、各号機の運行に関する情報であり、各号機の運転状態（通常運転／点検／故障等）の他に、ホール呼び／かご呼びの登録状態、平均未応答時間、積載荷重などの情報が含まれる。「交通需要データ」は、建物の交通需要に関するデータであり、利用者の乗車・降車に関する乗降情報、システム全体としての平均未応答時間、ホール呼びの発生頻度などを含む。

保存判定部１３は、各号機の運行情報に基づいて、運転管理部１２によって作成された交通需要データが学習データとして保存可能か否かを判定する。この保存判定部１３により、使用可能と判定された交通需要データは学習データとしてデータベース部１４に保存される。

修正部１５は、保存判定部１３によって使用不可と判定された交通需要データを必要に応じて学習データとして使用可能なデータに修正する。学習部１６は、データベース部１４に保存された学習データを用いて、群管理の評価関数に用いられる制御パラメータを作成する。

次に、上記のように構成されるエレベータの群管理システムの動作について、図２を用いて説明する。

図２は第１の実施形態におけるエレベータの群管理システムの処理動作を示すフローチャートである。なお、このフローチャートで示される処理は、コンピュータである群管理制御装置１０によって実行される。

第１の実施形態では、群管理システム内の通常号機の台数によって交通需要データをどのように扱うかを決定する。すなわち、まず、群管理制御装置１０に設けられた運転管理部１２が群管理制御部１１を介して各号機の運転状態や、ホール呼び割当個数／かご呼び登録個数、平均未応答時間、積載荷重などからなる運行情報を取得する（ステップＳ１）。

そして、運転管理部１２は、群管理制御部１１を介して取得した各号機の運行情報に基づいて、利用者の乗車・降車の状態、システム全体としての平均未応答時間、ホール呼びの発生頻度などからなる交通需要データを作成する（ステップＳ２）。この交通需要データは、学習データの元となるデータである。運転管理部１２は、群管理制御部１１から定期的（例えば５分毎）に各号機の運行情報を取得して交通需要データを作成する。

続いて、運転管理部１２は、各号機の運行情報に含まれる運転状態情報に基づいて通常運転状態にある通常号機の台数を求め、その結果を保存判定部１３に与える（ステップＳ３）。

保存判定部１３は、運転管理部１２で作成された交通需要データをどのように扱うかの判定を行う（ステップＳ４，Ｓ５）。判定条件は、以下のようになる。

＜保存判定部１３における判定条件＞
条件１：群管理システム台数（全台数）のＸ_１％以上が通常号機である。
→交通需要データをそのまま学習データとして使用する。
条件２：群管理システム台数（全台数）のＸ_２％以下が通常号機である。
→交通需要データを破棄し、学習データとして使用しない。
条件３：群管理システム台数（全台数）のＸ_１％〜Ｘ_２％が通常号機である。
→交通需要データを修正し、修正後のデータを学習データとして使用する。
なお、Ｘ_１＞Ｘ_２である。

条件１は、ある一定台数が通常運転中にある場合の条件である。この場合、交通需要データは通常時の群管理システムの性能を示していると考えられる。したがって、学習に必要なデータであると判断して、交通需要データをそのまま学習データとして使用することにする。

条件２は、通常号機がある一定台数以下の場合である。この場合、交通需要データに示された性能は、通常時の群管理システムの性能を適切に示していないと考えられる。したがって、本来の性能とは大きくかけ離れたデータであり、学習には使用できないデータであると判断して、本データは破棄し、学習データとしては用いないことにする。

条件３は、上記条件１と上記条件２の中間に該当する。この場合、通常時の群管理システムにおける性能とは異なるが、大きく異なることはないと考えられる。したがって、本データについては、学習データとして使用可能なデータに修正することにする。

すなわち、交通需要データの多くが上記条件２または３に該当する場合において、条件３に該当する交通需要データまで破棄すると、学習データの収集速度が遅くなり、学習進度が鈍化する可能性がある。このような状態を防止するため、ある程度使用可能な交通需要データについては、適宜修正して学習データとして使用することが好ましい。

なお、Ｘ_１、Ｘ_２は予め設定された値である。例えば、群管理システム台数が８台で、台数Ｘ_１＝７５％、Ｘ_２＝５０％と設定した場合には、通常号機が６台以上であれば、交通需要データをそのまま学習データとして使用する。また、通常号機が４台以下であれば、交通需要データを破棄する。通常号機が５台（Ｘ_１％未満〜Ｘ_２％より多い）の場合は、交通需要データを修正して学習データとして使用する。

ここで、通常号機とは、「乗客を通常に乗車・降車させることができる号機」と定義する。例えば、次のような号機は通常号機として扱わない。これらの号機を特殊号機と称する。

通常号機として扱わない号機（特殊号機）の例
・点検号機（点検運転中の号機）
・故障号機（故障中の号機）
・運転休止号機（運転サービスを休止している号機）
・管制運転号機（管制運転中の号機）
・電源未投入号機（電源が投入されていない号機）。

図３乃至図５に群管理システムにおける各号機の運転状態を３つのケースに分けて示す。図３のケースＡは群管理システム内の全台数（４台）が全て通常運転の状態である。図４のケースＢは群管理システム内の１台の号機（Ｄ号機）点検運転の状態である。図５のケースＣは群管理システム内の１台の号機（Ｃ号機）が点検運転の状態、別の１台の号機（Ｄ号機）が故障中である。

いま、群管理システムの全台数が４台であり、Ｘ_１＝１００％、Ｘ_２＝５０％で設定されているとする。このような設定の場合には、ケースＡでは、交通需要データがそのまま学習データとして保存される。ケースＢでは、交通需要データが修正され、学習データとして保存される。ケースＣでは、交通需要データが破棄され、学習データとして保存されない。

図２において、上記条件１を満たすと判定された場合は（ステップＳ４のＹＥＳ）、交通需要データをそのまま学習データに使用することが可能であるため、保存判定部１３は運転管理部１２に対してデータ保存指令を出力する（ステップＳ６）。データ保存指令を受け取った運転管理部１２は、上記ステップＳ２で作成した交通需要データをデータベース部１４へ送って学習データとして保存する（ステップＳ７）。

上記条件１を満たさない場合、保存判定部１３は上記条件２の判定を行う（ステップＳ５）。上記条件２を満たすと判定された場合は（ステップＳ５のＹＥＳ）、交通需要データを学習データとして保存しないため、保存判定部１３は運転管理部１２に対してデータ破棄指令を出力する（ステップＳ８）。データ破棄指令を受け取った運転管理部１２は、上記ステップＳ２で作成した交通需要データを破棄する（ステップＳ９）
また、上記条件１，２を満たさない場合、上記条件３に該当することになる。この場合、保存判定部１３は運転管理部１２に対して、データ修正指令を出力する（ステップＳ１０）。データ修正指令を受け取った運転管理部１２は、上記ステップＳ２で作成した交通需要データを運行情報と共に修正部１５へ送る（ステップＳ１１）。

修正部１５では、交通需要データと運行情報に基づいて各号機の運行シミュレーションを実行し、そのシミュレーション結果に応じて交通需要データを修正する（ステップＳ１２）。そして、修正部１５は、修正後の交通需要データをデータベース部１４へ送って学習データとして保存する（ステップＳ１３）。

ここで、上記ステップＳ１２で実行されるデータ修正の処理について、図６を用いて説明する。

図６はエレベータの群管理システムにおける群管理制御装置１０の修正部１５の処理動作を示すフローチャートである。

修正部１５は、運転管理部１２から与えられた交通需要データと運行情報に基づいて、所定の時間間隔（例えば、５分間）毎に交通需要管理表を作成する（ステップＳ１２−１）。この交通需要管理表の作成には、交通需要データに含まれる各階床毎の乗降情報と、運行情報に含まれるホール呼びの登録タイミングを使用する。

図７乃至図９に具体例を示す。
図７は任意の号機（Ｎとする）のＵＰ運転時の期間Ｔ_１−Ｔ_２におけるかご内の乗降情報を示している。なお、ＵＰ運転とは、上昇方向の運転のことである。期間Ｔ_１−Ｔ_２は、号機ＮがＵＰ方向に運転サービスを開始し、ＵＰ方向のホール呼びに応答を完了するまでの間である。図８はその期間Ｔ_１−Ｔ_２における号機Ｎに割り当てられたホール呼びの登録時間を示している。

これらの情報を用いて、どの階床にどの方向のホール呼びがどのタイミングで登録され、待ち人数が何人であるのかを判断する。また、通常のホール呼び登録方法では、利用者の乗車階は判断できるが、降車階については判断できないことがある。

すなわち、図７の例で、１階から５人の利用者が乗車したことは分かるが、その５人のうちの誰が４階／６階／８階／９階で降車したのかまでは分からない。また、６階で降車した利用者が、１階で乗車した利用者であるのか、３階で乗車した利用者であるのかまでは分からない。

このように、利用者の乗車情報は一意に判断できるが、降車情報については正確に判断できないため、降車情報からランダムに決定するものとする。ただし、乗車人数と降車人数が一致するように交通需要管理表を作成する。

図９は交通需要管理表の一例を示す図である。交通需要管理表とは、利用者の出発階と目標階の状況を表したもので、ＯＤ（Object／departure）表とも呼ばれる。図９の例は、図７のかご内の乗降情報と図８のホール呼びの登録時間を元に作成されたもので、ＵＰ運転時の状況が表されている。

なお、ここでは一定期間のみの状況を示したが、実際には交通需要データを作成した時間帯で交通需要管理表を作成することで、運行シミュレーションに用いる詳細な交通需要管理表が得られる。

交通需要管理表の作成後、修正部１５は、かご情報とシステム情報をセットする（ステップＳ１２−２）。ここでいう「かご情報」とは、定格速度や積載人数といった乗りかごの性能に関する情報である。「システム情報」とは、階床数や階高データなど、群管理システムが適用されている建物情報に関する情報である。

かご情報・システム情報がセットされると、修正部１５は、交通需要管理表に従って各号機を仮想的に運行させる運行シミュレーションを実行する（ステップＳ１２−３）。この場合、実際には点検中や故障中などで特殊状態であった号機も運転サービス可能であるとして通常号機に含め、群管理システム台数のＸ_１％以上が通常号機である状態あると仮定して運行シミュレーションを実行するものとする。

修正部１５は、そのシミュレーション結果から修正後の交通需要データを求める（ステップＳ１２−４）。このとき得られる交通需要データは、運行シミュレーションにて群管理システム台数のＸ_１％以上が通常号機として求めたものであるため、学習データとして使用しても問題はない。

具体的には説明すると、図４のケースＢのように、群管理システム台数が４台のうちの１台（この例ではＤ号機）が点検中で運休を停止していたとする。このとき、図１０に示すように、運転管理部１２から交通需要データとして得られるシステム全体の平均未応答時間Ｔｘが４０秒であったとする。

ここで、４台が通常号機であると仮定して運行シミュレーションを実行した結果、平均未応答時間Ｔｘが２５秒であったとする。このような場合、Ｔｘ＝４０秒→２５秒に修正してデータベース部１４に保存し、学習データとして使用するものとする。これは、本システムの号機台数が４台であるとして群管理の評価関数が予め設定されているからである。

このように、群管理システム内の通常号機の台数がある一定範囲内にあれば、交通需要データを破棄せずに、運行シミュレーションにより使用可能な交通需要データに修正することで、学習データとして使用することが可能となる。

なお、通常号機が群管理システム台数のＸ_２％以下の場合に、運行シミュレーションにより交通需要データを修正することも考えられるが、この場合、交通需要管理表が正しく作成できず、実際の需要と異なる状態で運行シミュレーションを行ってしまう可能性がある。

例えば、同じ交通需要が発生していたとしても、図３のケースＡのように全号機が通常号機である場合と、図４のケースＢや図５のケースＣのように特殊号機が存在する場合とでは、実際にかご内に乗車・降車する人数が異なることが予想される。

特に、特殊号機が多く存在するケースＣのような場合、通常号機が常に満員状態となり、各階床で長待ちや満員通過が多発することが予想される。このような状況が続くと、利用者は階段やエスカレータなど、エレベータ以外の手段により移動することがあり、実際の交通需要と合わなくなる。

つまり、このような状況で各階床の乗降情報とホール呼び登録タイミングから交通需要管理表を作成すると、エレベータに乗車していない利用者が多く存在するため、交通需要管理表では実際の交通需要よりも利用者が少なく算出されてしまう。また、例えば満員通過によりホール呼びを再登録するこが多くなると、ホール呼び登録発生タイミングに誤差が発生する可能性が高くなる。

そのため、実際の交通需要とは乖離した交通需要管理表が作成され、その交通需要管理表を元に運行シミュレーションを行って交通需要データを求めても、実際の交通需要との誤差が大きく、学習結果に悪影響を及ぼす可能性が高くなってしまう。これを防ぐため、群管理システム台数のＸ_２％以下の場合には、運行シミュレーションを行わず、交通需要データを破棄することで、実際の交通需要に即した交通需要データのみを学習データとして保存することができる。

このように第１の実施形態によれば、群管理システム内の通常号機の台数をチェックし、通常号機の台数が一定台数（Ｘ_２）以下であれば、そのときに得られる交通需要データを破棄することで、運休中の号機が存在する場合であっても学習データの精度を維持して群管理性能の低下を防ぐことができる。

また、通常号機が一定台数（Ｘ_２）以上ではあるが、すべてが通常号機でない場合に運行シミュレーションにより交通需要データを修正して学習データとして保存することで、学習データを早く収集して制御パラメータに反映させることができる。

（第２の実施形態）
次に、第２の実施形態について説明する。

上記第１の実施形態では、交通需要データを必要に応じて修正して学習し、その学習結果を元に制御パラメータを作成する構成とした。第２の実施形態では、第１の実施形態で作成された制御パラメータを実際に群管理制御に使用可能であるか否かを判断し、使用不可であればデフォルト設定された標準の制御パラメータを使用する。

図１１は第２の実施形態に係るエレベータの群管理システムの構成を示すブロック図である。なお、上記第１の実施形態における図１の構成と同じ部分には同一符号を付して、その説明は省略するものとする。

第２の実施形態において、群管理制御装置１０には使用判定部１７が備えられている。使用判定部１７は、学習部１５で学習データを元に作成された制御パラメータを実際の制御に適用するか否かを判定する。当該制御パラメータを適用できない場合には、使用判定部１７はデフォルト設定の制御パラメータを使用するように群管理制御部１１に指示する。「デフォルト設定の制御パラメータ」とは、通常号機の台数に関係なく、標準的に使用可能な制御パラメータのことである。

以下に、第２の実施形態の動作を説明する。
図１２は第２の実施形態におけるエレベータの群管理システムの処理動作を示すフローチャートである。なお、このフローチャートで示される処理は、コンピュータである群管理制御装置１０によって実行される。

学習部１５では、データベース部１４に保存された学習データに基づいて現在の交通需要に応じた制御パラメータを作成する。上述したように、「制御パラメータ」とは、群管理制御の評価関数に用いられるものであり、例えば平均未応答時間に対する重み係数などである。「制御パラメータを作成する」とは、上記重み係数などを現在の交通需要に応じて最適化することを言う。

学習部１６で作成された制御パラメータは、使用判定部１７へ送られる。ここで、使用判定部１７では、学習結果として得られた制御パラメータを使用するかの判定を行う。図１２のフローチャートは、この使用判定部１７での判定処理を示している。

すなわち、まず、使用判定部１７は、学習結果として得られた制御パラメータが作成されているか否かを判定する（ステップＳ２１）。制御パラメータが作成されていない場合つまり学習が完了していない場合は（ステップＳ２１のＮＯ）、使用判定部１７は、群管理制御部１１に対して、デフォルト設定値使用指令を出力する（ステップＳ２６）。デフォルト設定値使用指令を受け取った群管理制御部１１は、予め記憶されたデフォルト設定の制御パラメータを用いて群管理制御を実行する（ステップＳ２７）。

すなわち、学習による制御パラメータが使えない状態では、デフォルト設定の制御パラメータを用いて各号機の運転が制御される。この場合、デフォルト設定の制御パラメータは標準的な制御パラメータであるので、必要最低限の群管理性能を維持して各号機に対するホール呼びの割当て制御などが実行されることになる。

一方、学習部１６から制御パラメータが与えられている場合には（ステップＳ２１のＹＥＳ）、使用判定部１７は、運転管理部１２から各号機の運転状態情報を取得する（ステップＳ２２）。そして、使用判定部１７は、各号機の運転状態情報から通常運転中にある通常号機の台数を算出し、学習による制御パラメータを使用するかどうかの判定を行う（ステップＳ２３）。

判定条件は、以下のようになる。なお、下記に示すパラメータＸ_１は、上記第１の実施形態で説明した保存判定部１３における判定条件で使用するパラメータＸ_１と同じデータである。

＜使用判定部１７における判定条件＞
条件４：群管理システム台数（全台数）のＸ_１％以上が通常号機である。
→学習結果として得られた制御パラメータを使用する。
条件５：群管理システム台数（全台数）のＸ_１％未満が通常号機である。
→デフォルト設定された標準の制御パラメータを使用する。

条件４は、ある一定台数が通常運転中であれば、学習データが現在の交通需要の状態と一致しているものと考えられるので、学習結果である制御パラメータを用いることで、より最適な制御を行うことが可能となる。

条件５は、通常号機の台数がある一定台数未満の場合である。この場合、学習データが現在の交通需要と異なる事が予想される。学習結果である制御パラメータ（交通需要データを修正する場合も含めて）は、通常号機の台数がシステム台数のＸ_１％以上における交通需要データを学習することで得ている。したがって、通常号機の台数がシステム台数のＸ_１％未満の場合に、学習による制御パラメータを適用しても、適切な制御が行えない可能性がある。そこで、デフォルト設定による標準の制御パラメータを使用するものとする。

なお、Ｘ_１は上記第１の実施形態と同様に予め設定された値である。例えば、群管理システム台数が８台で、台数Ｘ_１＝７５％と設定した場合、通常号機が６台以上であれば、学習による制御パラメータを使用する。通常号機が６台未満であれば、デフォルト設定による制御パラメータを使用する。

図１２において、通常号機の台数がシステム台数のＸ_１％以上の場合（ステップＳ２３のＹＥＳ）、使用判定部１７から群管理制御部１１に対して学習結果使用指令が出力される（ステップＳ２４）。このとき、使用判定部１７は、学習結果使用指令と共に、学習部１６から学習結果として取得した制御パラメータも出力する。

学習結果使用指令を受け取った群管理制御部１１は、その指令と同時に送られて来た制御パラメータを用いて群管理制御を実行する（ステップＳ２５）。この制御パラメータは現在の交通需要を反映させたものであるため、各号機の運転を交通需要に合わせて効率的に制御することができる。

また、通常号機の台数がシステム台数のＸ_１％未満の場合（ステップＳ２３のＮＯ）、使用判定部１７から群管理制御部１１に対してデフォルト設定値使用指令が出力される（ステップＳ２６）。このデフォルト設定値使用指令を受け取った群管理制御部１１は、予め記憶されたデフォルト設定の制御パラメータを用いて群管理制御を実行する（ステップＳ２７）。

このように第２の実施形態によれば、学習結果として得られた制御パラメータを使用する際に、群管理システム内の通常号機の台数をチェックし、一定台数以上の場合にのみ当該制御パラメータを適用することで、制御パラメータが現在の交通需要に合わずに群管理の性能が低下することを防ぐことができる。

また、学習結果としての制御パラメータが得られていない場合、あるいは、群管理システム内の通常号機の台数が一定台数未満の場合には、デフォルト設定された標準の制御パラメータを用いることで、必要最低限の群管理性能を維持して各号機の運転を制御することができる。

なお、上記各実施形態では、Ａ〜Ｄの４台の号機（エレベータ）を有する群管理システムを想定して説明したが、本発明は４台の号機に限らず、２台以上の号機を有する群管理システムであれば、そのすべてに適用可能であり、上記同様の効果を得ることができるものである。

以上述べた少なくとも１つの実施形態によれば、運休している号機が存在する場合でも学習データの精度を維持でき、群管理性能の低下を防ぐことのできるエレベータの群管理システムを提供することができる。

なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ａ〜１ｄ…号機制御部、２ａ〜２ｄ…乗りかご、３ａ〜３ｄ…荷重検知器、４ａ，４ｂ，４ｃ…ホール釦、１０…群管理制御装置、１１…群管理制御部、１２…運転管理部、１３…保存判定部、１４…データベース部、１５…修正部、１６…学習部、１７…使用判定部。

Claims (7)

1. 複数の号機の運転状態を管理すると共に現在の交通需要を示す交通需要データを作成する運転管理手段と、
   上記各号機の運行情報に含まれる運転状態情報に基づいて上記各号機の中で通常運転状態にある通常号機の台数を求め、上記通常号機の台数と予め保存判定条件として設定された設定値との比較により上記運転管理手段によって作成された交通需要データが学習データとして保存可能か否かを判定する保存判定手段と、
   この保存判定手段によって保存可能と判定された交通需要データを学習データとして保存するデータベース手段と、
   このデータベース手段に保存された学習データに基づいて群管理用の制御パラメータを作成する学習手段と、
   この学習手段によって作成された群管理用の制御パラメータを用いて上記各号機の運転を群管理制御する群管理制御手段と
   を具備したことを特徴とするエレベータの群管理システム。
2. 上記保存判定手段は、
   上記各号機の中で通常運転状態にある通常号機の台数を求め、上記通常号機の台数が第１の設定値以上であった場合に上記運転管理手段によって作成された交通需要データを学習データとして保存可能であると判定し、上記通常号機の台数が上記第１の設定値よりも低く設定された第２の設定値以下であった場合に上記通需要データを学習データとして保存不可であると判定して破棄することを特徴とする請求項１記載のエレベータの群管理システム。
3. 上記通常号機の台数が上記第１の設定値から上記第２の設定値の間であった場合に上記運転管理手段によって作成された交通需要データを保存可能な状態に修正する修正手段を備え、
   上記データベース手段は、
   上記修正手段によって修正された交通需要データを学習データとして保存することを特徴とする請求項２記載のエレベータの群管理システム。
4. 上記修正手段は、
   上記各号機のすべてが上記通常号機であると仮定して運行シミュレーションを実行し、そのシミュレーション結果から修正後の交通需要データを求めることを特徴とする請求項３記載のエレベータの群管理システム。
5. 上記学習手段によって作成された群管理用の制御パラメータを実際の制御に適用するか否かを判定する使用判定手段を備え、
   上記群管理制御手段は、
   上記使用判定手段の判定結果に応じて、上記学習手段によって作成された群管理用の制御パラメータを用いて上記各号機の運転を群管理制御することを特徴とする請求項１記載のエレベータの群管理システム。
6. 上記使用判定手段は、
   上記各号機の中で通常運転状態にある通常号機の台数を求め、上記通常号機の台数が第１の設定値以上であった場合に上記群管理用の制御パラメータを使用可能であると判定し、上記第１の設定値未満の場合に上記群管理用の制御パラメータを使用不可であると判定することを特徴とする請求項５記載のエレベータの群管理システム。
7. 上記群管理制御手段は、
   上記使用判定手段によって上記群管理用の制御パラメータが使用不可であると判定された場合に、予めデフォルト設定された標準の制御パラメータを用いて上記各号機の運転を群管理制御することを特徴とする請求項６記載のエレベータの群管理システム。

Images