JP6866275B2 - 外部システム連携配車システム及び方法 - Google Patents

Description

本発明は、エレベーター装置の運行管理に係り、特に外部システムと連携してエレベーターの乗り場の混雑時におけるかご配車を適切に行うための外部システム連携配車システム及び方法に関する。

従来からエレベーター装置の運行管理について、多くの提案がなされている。これらの中には、エレベーター装置の利用者が各階の乗場で混雑するときの運行管理について提案したものがある。

例えば特許文献１は、複数のエレベーターを１群とするエレベータシステムに対して、混雑階に的確な台数のかごを配車することのできるエレベーターの制御装置を得ることを目的とし、「エレベーター乗場およびかご内の混雑状態を検出する乗場カメラ１Ｂ、かご内カメラ１Ａと、これらのカメラの出力に基づいて現在のエレベーター乗場の乗客面積およびかご内の占有面積を計測する乗場面積検出手段３Ａ、かご内面積検出手段３Ｂと、これらの検出手段の出力と過去の学習結果に基づいてエレベーター乗場およびかご内両方の将来混雑度を予測する追加割当判定手段３Ｃ、交通情報学習手段３Ｇと、この予測結果に基づいて乗場に複数台のかごを配車する割当演算手段３Ｄ、運転制御手段３Ｅとを備える。」ものである。

特開２００２−３０２３４８号公報

特許文献１に記載の装置によれば、エレベーター乗場の混雑状態を検出し、検出出力と過去の学習結果に基づいてエレベーター乗場の将来混雑度を予測し、乗場に複数台のかごを配車することで、エレベーターの乗り場の混雑時におけるかご配車を適切に行うことができる。

特許文献１の手法によれば、過去の学習結果に基づいてエレベーター乗場の将来混雑度を予測しているので、エレベーターを設置したビル内で定常的に発生する混雑事象に対しては対応が可能である。例えば、朝晩の出退勤、昼食時の混雑などは、週末を除き、ルーチン的に発生する事象であるので、これに対応したエレベーターの乗り場の混雑時におけるかご配車を適切に行うことには有効である。

然しながらルーチン以外の突発事象に対する対応としては不十分である。特許文献１の手法における過去の学習結果には、ルーチン以外の突発事象は含まれておらず、突発事象の予測は不可能である。

また特許文献１では、乗場に利用者が集まり、呼びが発生してから対応に入るので混雑が発生してしまっている可能性が大であり、適切な台数の配車には有効であっても、混雑を生じさせないための対応としては不十分なものである。

このことから、本発明においては、突発事象時の対応も含めて先行的に配車可能な外部システム連携配車システム及び方法を提供することを目的とする。

以上ことから本発明においては「ビルなどの施設内に設置された複数のエレベーター装置の運行管理を行う外部システム連携配車システムであって、複数のエレベーター装置の運転実績と外部システムからのイベント情報を入力する受信部と、受信部から得られる運転実績の情報を過去経験データとして記憶し、学習する学習部と、学習部の記憶情報とイベント情報を用いて乗場の階床別に利用者数を予測する予測部と、イベント情報の時刻情報に基づいて、混雑発生が予測される予測混雑階にエレベーターかごを事前配車する乗場呼び登録判定部を備えていることを特徴とする外部システム連携配車システム。」としたものである。

また本発明においては「ビルなどの施設内に設置された複数のエレベーター装置の運行管理を行うエレベーター運行管理方法であって、複数のエレベーター装置の運転実績と外部システムからのイベント情報を用いて乗場の階床別に利用者数を予測し、イベント情報の時刻情報に基づいて、混雑発生が予測される予測混雑階にエレベーターかごを事前配車することを特徴とする外部システム連携配車方法。」としたものである。

本発明によれば、適切台数での事前配車が可能であるので、ルーチンによる混雑以外に、突発的な混雑にも対応可能である。

本発明に係る予測混雑時先行かご配車処理機能を備えたエレベーター運行管理システムの概略構成を示す図。 本発明に好適な乗り場環境事例を示した図。 学習部３１で学習した過去経験データの記憶フォーマット例を示す図。 階床別人数予測部３２で予測した予測乗り人数テーブルＴＢ１の一例を示す図。 階床別人数予測部３２で予測した予測降り人数テーブルＴＢ２の一例を示す図。 図１の階床別人数予測部３２における処理内容を具体的に例示したフロー図。 精度検証で追加した実データを含む予測乗り人数テーブルＴＢ１の一例を示す図。 精度検証で追加した実データを含む予測降り人数テーブルＴＢ２の一例を示す図。 本発明の実施例１に係る予測混雑時先行かご配車処理機能の処理フローを示す図。 エレベーターかご１台当りの定員数を示す図。 図７の予測混雑時先行かご配車処理を行った時の、混雑階（の様子を示した図す図。 号機別、階床別、最大乗り込み可能定員数（定員数＊乗車率）を示す図。 本発明の実施例２に係る予測混雑時先行かご配車処理機能の処理フローを示す図。 本発明の実施例３に係る予測混雑時先行かご配車処理機能の処理フローを示す図。 図１２の予測混雑時先行かご配車処理を行った時の、混雑階（混雑予想階：例えば１階）の様子を示した図。

以下本発明の実施例について、図面を用いて説明する。

図１は、本発明に係る予測混雑時先行かご配車処理機能を備えたエレベーター運行管理システムの概略構成を示している。なお本発明の機能を特許文献１と区別して表現すると、予測混雑時先行かご配車処理機能というのが適切である。特許文献１の機能は、混雑時かご配車処理機能というべきものである。

図１には、ビル１などの施設内の設備やシステムと、外部のシステム２が記述されている。このうち、ビル１などの施設内の設備やシステムは、エレベーター運行管理システム３、各階の乗場エレベーターサービス要求装置４、各階の監視カメラ５、ビル管理システム６などであり、これらの間では通信手段８を介して相互にデータ通信が行われている。またエレベーター制御システム７ａ・・・７ｎが複数号機設置されており、エレベーター運行管理システム３により制御されている。

さらに図１では、外部のシステム２の一事例として、公共機関管理システムを例示している。ここでエレベーター運行管理システム３は、エレベーター運行管理システム３以外の外部システムとして、ビル管理システム６や公共機関管理システム２に連携したシステムであり、外部システム連携配車システムを構成している。

本発明に係るエレベーター運行管理システム３は、多くの入力や設定を得て、出力を与えている。これら入出力のうち、エレベーター制御システム７ａ・・・７ｎとエレベーター運行管理システム３の間では、エレベーター制御システム７ａ・・・７ｎから運転状態情報Ｓ７１をエレベーター運行管理システム３に報告し、エレベーター制御システム７ａ・・・７ｎは、エレベーター運行管理システム３からの制御指令信号Ｓ７２により各号機エレベーターが制御されている。ここで特徴的なことは、エレベーター運行管理システム３がビル１内の全ての号機を運用管理していることであり、それ以外の事項は通常のエレベーター制御と変わることがないのでここでの説明を割愛する。

本発明では、さらに他の入力として、各階の乗場エレベーターサービス要求装置４からサービス要求信号Ｓ４、各階の監視カメラ５から映像信号Ｓ５、ビル管理システム６からビル管理情報Ｓ６、公共機関管理システム２から公共機関管理情報Ｓ２などを得る。

図２は、本発明に好適な乗り場環境事例を示した図である。各階のエレベーター乗場には、エレベーター扉を含む空間を監視、撮影する監視カメラ５（５−１、５−２、５−３、５−４）と、乗場エレベーターサービス要求装置４として上下式釦４（４−１、４−２、４−３、４−４）が設置されている。また、は、エレベーターかごの到着を予報する、或いは方向を案内するランタン２０（２０−１、２０−２、２０−３）が配置されている。図２には、さらにエレベーターのかご２４内にかご内カメラ２１、荷重センサ２２を備えている。

以下に説明するように、本発明におけるサービス要求信号Ｓ４の位置づけは、乗り場からエレベーターへの上り、下りのサービス方向を確認するためのものである。図２には上下式釦４が例示されているが、これは乗り場から行先階を登録する行先階登録装置などであってもよい。

また本発明における映像信号Ｓ５の位置づけは、利用者の人数を計測するためのものであり、直接的、間接的に利用者数を確認可能なものであれば他の手段で代替可能である。図２の例では、エレベーターのかご２４内に設けたかご内カメラ２１や、エレベーターのかご２４内下部に設けた荷重センサ２２からも利用者数の情報入手が可能である。

このようにして、サービス要求信号Ｓ４からは、エレベーターの上り、下りの方向を確認することができ、映像信号Ｓ５からは利用者の人数が確認でき、ビル管理情報Ｓ６からは施設内での会議、イベントなどの行動予定が確認でき、公共機関管理情報Ｓ２からは当日の公共機関の運行情報（例えば列車遅れ）などを把握可能である。なお、これらの情報の一部は、夫々既存のシステムでも入力して何らかの目的で使用されているものを含んでいるが、本発明においては予測乗り降り人数の推定に用いている点が新しい。

図１のエレベーター運行管理システム３内の受信部３６では、通信手段８を介してサービス要求信号Ｓ４、映像信号Ｓ５、ビル管理情報Ｓ６などを得、またエレベーター制御システム７ａ・・・７ｎから運転状態情報Ｓ７１を入力する。

受信部３６からの入力信号は、乗り場呼び登録判定部３９と学習部３１に与えられ利用されるが、これらは本発明の本質に関わる部分であるので、この説明を後述することにし、一般的な機能である総合評価部３７と割当て司令部３８の説明を先に行う事にする。

総合評価部３７では、これらの入力した信号から利用者の要求や移動方向を判断し、割当て司令部３８において各号機のエレベーター制御システム７ａ・・・７ｎに対して制御指令信号Ｓ７２を与え、これを制御する。この部分は、従来からのエレベーター制御と何ら変わるところがないものであるので、これ以上の説明を割愛する。

通信手段８を介して得たサービス要求信号Ｓ４、映像信号Ｓ５、ビル管理情報Ｓ６などは、学習部３１において記録され、利用される。ここでは、サービス要求信号Ｓ４および映像信号Ｓ５は、これら信号を発生した時刻の情報とともに記憶されることで、過去における経験情報として利用される。これにより過去のある場面（曜日、季節など）、ある時刻における利用者の行動や、態様が統計的に把握される。例えば、出退勤時、昼食時、夜間などでの人の移動状況の概要が把握可能である。従って、同じような将来の場面では、利用者は過去経験と同じような行動パターンを示すものと推定可能である。

因みに特許文献１において、「過去の学習結果」に利用される情報は、これらの情報である。特許文献１の混雑時かご配車処理機能を実現するためには、サービス要求信号Ｓ４および映像信号Ｓ５があればよい。これらの情報は、複数のエレベーター装置の運転実績についての情報ということができ、エレベーター運行管理システムが制御、管理する範囲内で得られた情報である。

本発明のように、予測混雑時先行かご配車処理機能を実現するためには、さらにビル管理システム６からのビル管理情報Ｓ６、および公共機関管理情報Ｓ２が利用される。

サービス要求信号Ｓ４と映像信号Ｓ５が、過去における経験情報、運転実績情報として利用されるものであるに対し、ビル管理システム６からのビル管理情報Ｓ６は、近未来における施設内での会議などの行動予定（開催場所、出席者及びその在席場所）が、ビル管理システム６に登録された情報であり、これによれば、例えば本日の３時からの５階での会議のときに各階からの人の動きが予測可能である。

また公共機関管理情報Ｓ２から、当日の公共機関の運行情報として、例えば列車遅れとその程度が把握できれば、特に出勤時の利用者の移動動向が、遅れのない通常時の移動動向とは相違し、変更されることが予測可能である。

本発明においては、運転実績情報に対して、ビル管理情報Ｓ６、および公共機関管理情報Ｓ２を、外部システムからのイベント情報と称することにする。イベント情報には計画的なもの（ビル管理情報Ｓ６）と、突発的なもの（公共機関管理情報Ｓ２）があるが、いずれもエレベーター運行管理システム以外の、外部システムから提供されたものである。

なお、ビル管理情報Ｓ６および公共機関管理情報Ｓ２は、これらのイベントの発生時刻或は終了時刻の情報と共に得られるものである。

このようにして、学習部３１は、通常のエレベーターの利用される利用人数を日々学習する。ここでは、マクロな人数情報を出力可能である。更に学習部３１は、階床別の乗車率を学習している。

乗車率の学習方法としては、エレベーター内の荷重やかご内カメラによって、エレベーターかご内の乗車人数を、検出、或いは算出する。更に、乗り場の人数を検出するため、乗り場カメラや、距離センサ等を用いて乗り場の人数を直接検出する。或いは乗場のボタン登録状況から、乗り場ボタンが押下された時点で乗り場に人がいるということを認識すう方式でも良い。

各階からの乗り場ボタン登録に応答し、到着してドアが開いた際、乗り場の人数がいなくなるか否かを判定し、乗り場の人数がいた場合、現在の乗車人数から、人が乗車可能と判断する乗車率を記録する。具体的には、５階乗り場に１０名存在し、かご内に１０名乗車していた状態で、かごが５階に到着し、乗り場の人数が２名残った場合、かご内の乗車人数は１８名となる。定員数が２４人乗りであった場合、かご内の乗車率は７５％となる。或いは、人数でなく、その際のかご内利用者の占有率、またはかご内の空き率を検出し、その占有率、或いは空き率を記録する方式でも良い。

乗り場のカメラが不付きの場合、５階の呼びが作成され、かごが５階に到着した際に、
ドアが戸閉した後、ある任意の時間内に同一方向への乗場呼び、或いは同一行先階へのサービス要求があった場合、乗り場に利用者が乗車できず、再登録したと判断し、その際の当該階の乗車人数、或いは占有率、空き率を記録する。

記録された、乗車人数、或いは占有率、空き率を乗車率とし、これらを日々、階別に学習する。

ここで階床別の乗車率とは、各階の利用比率を求めたものであり、さらには各階の利用者の人数による重みづけをして求めたものであってもよい。さらに階床別の乗車率は、上り下り別に把握されるのがよい。例えば８階の建物の場合に、５階での乗車率として上り方向での乗車率と下り方向での乗車率をそれぞれ求めておくのがよい。

エレベーター運行管理システムの管理者は、学習部３１に蓄積した過去の乗車率実績などを参考にして、乗車率設定部４０を用いて、乗車率を設定しておく。設定される乗車率は、利用者が次の配車を待つ判断をする限界の混み具合を定めたものである。例えば２４人乗りのかごであっても、１８人乗車していたら次の配車を待つ人が現れる限界の乗車率である。出勤時であれば高い乗車率であっても、通常時は低くなることがあるので、限界の乗車率は、階別、上り下り別、時間帯別などに設定されるのがよい。

学習部３１で学習した過去経験データは、例えば図３のように整理され記憶されている。図３は、例えば過去実績乗り人数の記憶フォーマットを例示しており、過去の日時ごとに、各階での乗降者数と、階別の上り下り別の乗車率の情報を関連付けして記憶している。過去実績降り人数の記憶フォーマットも同様形式で作成される。なお、上記記憶フォーマットは、日毎に例えば１０分の時間帯毎に人数把握されて記憶され、かつ過去の長期にわたり蓄積した情報を備えるのがよい。また過去経験データには、付随情報として会議や各種イベントなどの行事情報を含んでおくのがよい。学習部３１で学習した過去経験データは、過去経験として、以下の処理において予測処理に利用される。

階床別人数予測部３２では、過去経験や、当日の会議予定などから、例えば今日の人の動きを階床別に人数予測する。図４ａは、階床別人数予測部３２で予測した予測乗り人数テーブルＴＢ１の一例、図４ｂは、階床別人数予測部３２で予測した予測降り人数テーブルＴＢ２の一例を示している。

予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２は、上段から順次時刻データＤ１、Ｄ６、階床データＤ２、Ｄ７、予測人数データＤ３、Ｄ８、実人数データＤ４、Ｄ９、予測精度データＤ５、Ｄ１０、乗車率Ｄ１１、Ｄ１２で構成されている。階床別人数予測部３２では、これらテーブルの内、上から３段目までのデータを、図３の過去経験データなどを用いて形成している。

例えば予測乗り人数テーブルＴＢ１について、８時の時刻（後述するが例えば８時からの１０分間を表している）では、各階（ここでは１回から８階まで）の乗り人数は、それぞれ２０、９、７、１４、１３、７、８、５人であると予測したことを示している。また例えば予測降り人数テーブルＴＢ２について、８時の時刻（後述するが例えば８時からの１０分間を表している）では、各階（ここでは１回から８階まで）の降り人数は、それぞれ２０、５、９、１５、１１、１５、１８、１１人であると予測したことを示している。

なお、予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の作成手法に関して、前記したように過去の経験や本日の予定を考慮して作成することができ、さらには本日の列車遅れなどを考慮して補正により求めることができる。

図５は、図１の階床別人数予測部３２における処理内容を具体的に例示したフロー図である。なお、この前提としては学習部３１での処理により、日々計測された時系列的な利用者数が、階別、上り下り方向別に乗車率の情報と共に把握され、図３の過去経験データが形成されているものとする。つまり、予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２について、実人数データＤ４、Ｄ９に対応する過去経験データが、時系列的、かつ相当日数分確保、記憶されているものとする。また、過去の日々についてその日に行われたイベントや会議の情報を含めて記憶されているものとする。

図５の処理の開始は、適宜のタイミングで行われてよいが、例えば前日に翌日１日分の情報として提供されるのであれば、前日の適当な時間で処理されることになる。あるいは、外部からの要求で提供するのであれば、要求があった時点で開始してもよい。また新たな状態変化が生じた場合には、当日であってもその都度見直しをされるのがよい。

階床別人数予測部３２の最初の処理ステップＳ１００では、過去経験データなどを取り込む。この中には過去における実人数データＤ４、Ｄ９、時刻データＤ１、Ｄ６、乗車率、ビル管理情報Ｓ６などを含んでいる。処理ステップＳ１０１では、時間幅や指定時刻などの設定情報を取り込む。

処理ステップＳ１０２では、出力日（例えば明日）について判定する。出力日が平日か、休日か、あるいは一部休止かなどを判定して、図３の過去経験データから該当する条件のもののみを抽出する。処理ステップＳ１０３では、例えば、出力日が平日なら平日の過去経験データのみを抽出し、出力日が休日なら休日の過去経験データのみを抽出する。なお利用者について季節的な変動、曜日的な変動が顕著に表れる場合には、これらの点を考慮して抽出するのがよい。

処理ステップＳ１０４では、抽出した複数日分の時系列的利用実績について、時刻別の利用平均を求め、予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の予測人数データＤ３、Ｄ８とする。なお、上記処理は階ごとの利用者数について行われているので、併せて、階床データＤ２、Ｄ７も得られている。

処理ステップＳ１０５では、ビル管理情報Ｓ６の有無を確認し、例えば本日の１５時から５階で会議が開催予定されている場合には、処理ステップＳ１０６において、その開催規模に応じて利用者の動き、エレベーターの利用の仕方を反映して、処理ステップＳ１０４で求めた予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の予測人数データＤ３、Ｄ８を修正する。なお、過去経験データの中に、この会議と同趣旨の会議が過去に実施された経験を有している場合には、その時の利用者情報を参考にして予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の予測人数データＤ３、Ｄ８を修正するのがよい。

処理ステップＳ１０７では、公共機関管理情報Ｓ２の有無を確認し、例えば本日の８時にビルの最寄駅に到着予定の電車が遅れているという情報が得られている場合には、処理ステップＳ１０８において、その遅れの程度に応じて利用者の動き、エレベーターの利用の仕方を反映して、処理ステップＳ１０４、Ｓ１０６で求めた予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の予測人数データＤ３、Ｄ８を修正する。なお、処理ステップＳ１０７、Ｓ１０８の処理は、当日入手された外部情報により実行されることになる。

以上述べたように、過去実績を行動予定や公共機関の情報をもとに修正して、予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の予測人数データＤ３、Ｄ８を求める。なお、図５のフローには明記されていないが、図３の過去経験データを用いて、乗車率設定部４０で設定された乗車率のデータは、予測乗り人数テーブルＴＢ１と予測降り人数テーブルＴＢ２の乗車率Ｄ１１、Ｄ１２の欄に反映される。

階床別人数予測部３２は、さらに精度検証機能を備えており、階床別人数予測部３２で作成した上位３段のデータにさらに下位２段の情報を、予測した日の実経験に基づいてデータ追加する。図６ａは、精度検証により追加した実データを含む予測乗り人数テーブルＴＢ１の一例、図６ｂは、精度検証により追加した実データを含む予測降り人数テーブルＴＢ２の一例を示している。

この事例では、例えば予測乗り人数テーブルＴＢ１について、８時の時刻では、各階の乗り人数を、それぞれ２０、９、７、１４、１３、７、８、５人であると予測したが、実際には１８、１３、１０、１９、１４、１４、１０、９人であり、夫々の精度は８２、３８、６０、７５、９２、８８、９５、９０％であったことがわかる。

またこの事例では、例えば予測降り人数テーブルＴＢ２について、８時の時刻では、各階の降り人数は、それぞれ２０、５、９、１５、１１、１５、１８、１１人であると予測したが、実際には１７、１３、１５、１２、１２、１７、１９、１０人であり、夫々の精度は８９、６９、７０、７４、９３、５０、８０、５６％であったことがわかる。

なお、図６ａ、図６ｂのテーブルにおいて、データＤ４、Ｄ９を追加したということは、学習部３１に新たな過去経験データとして追記したことを意味している。

図１の乗場呼び登録判定部３９は、通常は各階の乗場エレベーターサービス要求装置４からのサービス要求信号Ｓ４に基づいて、乗場呼び登録判定処理を実施し、総合評価部３７、割り当て指令部３８を介して、登録した階にかごを配車しているが、予測混雑時先行かご配車処理機能を有する本発明においてはさらに以下のように機能する。

図７には、本発明の実施例１に係る予測混雑時先行かご配車処理機能の処理フローを示している。実施例１は、予測混雑情報に基づいて、予測混雑階にエレベーターかごを戸開待機させるものである。

この場合に予測混雑情報は、ビル管理システム６からのビル管理情報Ｓ６、公共機関管理システム２からの公共機関管理情報Ｓ２である。これらの情報によれば、近未来における施設内での会議、イベントなどの行動予定、あるいは列車遅延に基づく利用者の集中とその時刻を含んでいるので、予測混雑情報として利用可能である。

図７の予測混雑時先行かご配車処理機能の処理フローでは、最初に処理ステップＳ１１０において「公共機関の遅延情報／イベント情報有りか？」を確認する。公共機関の遅延情報は、公共機関管理システム２からの公共機関管理情報Ｓ２により判断し、イベント情報はビル管理システム６からのビル管理情報Ｓ６により判断する。遅延情報／イベント情報が特にない場合（Ｓ１１０、ＮＯ）には、処理ステップＳ１１５に移り、戸開待機による事前配車処理を解除する。

公共機関管理情報Ｓ２あるいはビル管理情報Ｓ６から、混雑が予見される場合（Ｓ１１０、ＹＥＳ）、処理ステップＳ１１１において、「当該情報の時刻と現在時刻は一致しているか？」を確認する。公共機関管理情報Ｓ２やビル管理情報Ｓ６は、遅延時間や、会議の開催、終了についての時刻情報を含んでいることから、これらのイベント発生時刻と現在時刻との関係を判断している。例えば、現在時刻がイベント発生時刻の１分前に至ったことをもって、当該情報と現在時刻は一致したと判断（Ｓ１１１、ＹＥＳ）して、処理ステップＳ１１２の処理に入る。なお、当該情報と現在時刻が一致していない時（Ｓ１１１、ＮＯ）には、処理ステップＳ１１５に移り、戸開待機による事前配車処理を解除する。

処理ステップＳ１１２では、予測した利用者の人数とエレベーターかご１台当りの乗員数を比較する。予測した利用者の人数は、階床別人数予測部３２において図４ａ、図４ｂのように、時刻別、階床別、乗り降り別に人数が得られているので、これを参照する。この利用者数は、過去経験データによる人数以外に、公共機関管理情報Ｓ２やビル管理情報Ｓ６に基づき、近い将来におけるイベントなどにより過渡的に増加する人数も加味された人数とされている。

ここで、乗員数は定員数、あるいは先述の乗車率を乗じた人数であるが、ここではまず定員数を乗員数として説明する。エレベーターかご１台当りの乗員数（定員数）は、図８に示すようにエレベーター号機ごとの仕様として既知であり、例えば２４人／かご、１５６０ｋｇ／かごである。処理ステップＳ１１２では、予測した利用者の人数とエレベーターかご１台当りの乗員数（定員数）を比較して、予測した利用者の人数＞エレベーターかご１台当りの乗員数である場合には、処理ステップＳ１１４においてエレベーター複数台事前配車しこれらをエレベーター複数台戸開待機とする。予測した利用者の人数≦エレベーターかご１台当りの乗員数である場合には、処理ステップＳ１１３においてエレベーター１台事前配車しこれをエレベーター複数台戸開待機とする。

図９は、図７の予測混雑時先行かご配車処理を行った時の、混雑階（混雑予想階：例えば１階）の様子を示した図である。エレベーターかご２４は、例えば３台のうち１台（２４ａ）、または複数台（２４ａ、２４ｃ）が事前配車され、混雑階に到着すると各扉２５（２５ａ、２５ｂ、２５ｃ）を開放し、開放状態のまま待機（戸開待機）する。このとき、利用者の大半が同じ上り、下りの方向への移動を行う事が明らかであれば、予測混雑階の乗場エレベーターサービス要求装置４は、上り、下りともに、行先方向の表示を行わないものであってもよい。混雑予定時刻になって乗場に表れた利用者は、戸開待機中のエレベーターに順次搭乗する。

図７の処理ステップＳ１０２では、予測した利用者の人数とエレベーターかご１台当りの乗員数を比較するに際し、乗員数（定員数）＊乗車率を乗員数としている。ここで乗車率は、階床別人数予測部３２の乗車率設定部４０において、図４ａ、図４ｂのように、時刻別、階床別、乗り降り別に人数が設定されているので、これを参照する。ここで、乗車率を加味して乗員数とした理由は、利用者の心理として、ある程度以上のかご内混雑状態においては搭乗しない（次を待つ）傾向があることから、この利用者心理に基づいて、より実際的な運用として、多めにかご台数を配車しておくものである。

図１０は、号機別、階床別、最大乗り込み可能定員数（定員数＊乗車率）を求めたものであり、図７の処理ステップＳ１０２では予測した利用者の人数と図１０の人数を比較して、エレベーターの配車台数を定めている。

上記処理により、列車遅延あるいは大きな会議の開催に伴い、大量の利用者が同一階に集まることが予想される予測混雑状態において、利用者の円滑な移動を可能とする。特に電車や地下鉄の駅に直結したビルの入り口階を備えている場合に本発明の効果が大きいといえる。

図１１には、実施例２に係る予測混雑時先行かご配車処理機能の処理フローを示している。実施例２は、予測混雑情報に基づいて、予測混雑階の乗場エレベーターサービス要求装置４に上り、下り方向の呼びボタンを自動登録するものである。

この場合に予測混雑情報は、ビル管理システム６からのビル管理情報Ｓ６、公共機関管理システム２からの公共機関管理情報Ｓ２である。これらの情報によれば、近未来における施設内での会議、イベントなどの行動予定、あるいは列車遅延に基づく利用者の集中とその時刻が明確化でき、予測混雑情報として利用可能である。

図１１の混雑時かご配車機能の処理フローでは、最初に処理ステップＳ１１０において「公共機関の遅延情報／イベント情報有りか？」を確認する。公共機関の遅延情報は、公共機関管理システム２からの公共機関管理情報Ｓ２により判断し、イベント情報はビル管理システム６からのビル管理情報Ｓ６により判断する。遅延情報／イベント情報が特にない場合（Ｓ１１０、ＮＯ）には、処理ステップＳ２０４に移る。

公共機関管理情報Ｓ２あるいはビル管理情報Ｓ６から混雑が予見される場合（Ｓ１１０、ＹＥＳ）、処理ステップＳ１１１において、「当該情報の時刻と現在時刻は一致しているか？」を確認する。公共機関管理情報Ｓ２やビル管理情報Ｓ６は、遅延時間や、会議の開催、終了についての時刻情報を含んでいることから、これらのイベント発生時刻と現在時刻との関係を判断している。例えば、現在時刻がイベント発生時刻の１分前に至ったことをもって、当該情報と現在時刻は一致したと判断（Ｓ１１１、ＹＥＳ）して、処理ステップＳ２００の処理に入る。なお、当該情報と現在時刻が一致していない時（Ｓ１１１、ＮＯ）には、処理ステップＳ１０５に２０４に移る。

処理ステップＳ２００では、「公共機関から流入が予測される階か、一般在籍階か？」を判定する。公共機関から流入が予測される階は、一般にはビル下部にあり、外部からの利用者の多くは上りを志向していることから、処理ステップＳ２０１において上り方向の呼びボタンを自動登録し、また一般在籍階である場合には、処理ステップＳ２０２において当該階における行先階が多い方向として下り方向の呼びボタンを自動登録する。これにより、これらの階の乗場エレベーターサービス要求装置４は、上り、或は下り方向の呼び表示が行われる。なお、呼びボタンの自動登録により、図４の総合評価部３７と割当て司令部３８を介して、かごの配車が行われる。

なお処理ステップＳ２００では、公共機関からの流入を想定しているが、同様にして会議などのイベントに対応した呼び自動登録を行う事が可能である。例えば途中階で開催された会議の終了であれば、上り、下りについて自動呼び登録をすることで、対応が可能である。

また呼びボタンを自動登録した後は、処理ステップＳ２０３においてタイマ起動しておく。このタイマは、例えば混雑が解消するまでの時間を適宜設定したものであり、この期間内は基本的に呼びボタンの自動登録状態を継続し、上り、或は下り方向の呼び表示を継続表示とする。

処理ステップＳ２０４では、「タイマ時間満了するまでに、別方向の釦が登録されたか？」を確認する。ＮＯであれば、何もしなくてもよい。別方向の釦が登録された場合、この後の対応は種々のものが考えられる。処理ステップＳ２０５では、混雑が解消したものという前提で、呼びボタンの自動登録をキャンセルする処理を行う事例を示している。ここで混雑が解消したことの確認は、監視カメラの映像を用いて判断してもよい。あるいは処理ステップＳ２０５の処理として、設定したタイマの時間経過までは呼び表示を継続表示し、別方向の釦についての釦を点灯する方法も考えられる。

なお、タイマによる混雑が解消するまでの時間設定に関して、混雑開始予測時刻から２段階に設定することも可能である。混雑開始予測時刻に直近の第１段階では、再配車を行っていくが、その後の第２段階では、混雑の様子を見ながら配車を調整し、或は混雑時かご配車処理を中断する判断を行うなどするのがよい。

実施例２によれば、予測混雑時先行かご配車処理として呼びボタンの自動登録を行うので、利用者が配車状態を確認可能である。

図１２には、実施例３に係る予測混雑時先行かご配車処理の処理フローを示している。実施例３は、予測混雑情報に基づいて、予測混雑階にエレベーターかごを事前配車させるものである。

この場合に予測混雑情報は、ビル管理システム６からのビル管理情報Ｓ６、公共機関管理システム２からの公共機関管理情報Ｓ２である。これらの情報によれば、近未来における施設内での会議、イベントなどの行動予定、あるいは列車遅延に基づく利用者の集中とその時刻が明確化でき、予測混雑情報として利用可能である。

図１２の予測混雑時先行かご配車処理機能の処理フローでは、最初に処理ステップＳ１１０において「公共機関の遅延情報／イベント情報有りか？」を確認する。公共機関の遅延情報は、公共機関管理システム２からの公共機関管理情報Ｓ２により判断し、イベント情報はビル管理システム６からのビル管理情報Ｓ６により判断する。遅延情報／イベント情報が特にない場合（Ｓ１１０、ＮＯ）には、処理ステップＳ３０５に移り、事前配車を行わない。

公共機関管理情報Ｓ２あるいはビル管理情報Ｓ６から混雑が予見される場合（Ｓ１１０、ＹＥＳ）、処理ステップＳ１１１において、「当該情報の時刻と現在時刻は一致しているか？」を確認する。公共機関管理情報Ｓ２やビル管理情報Ｓ６は、遅延時間や、会議の開催、終了についての時刻情報を含んでいることから、これらのイベント発生時刻と現在時刻との関係を判断している。例えば、現在時刻がイベント発生時刻の１分前に至ったことをもって、当該情報と現在時刻は一致したと判断（Ｓ１１１、ＹＥＳ）して、処理ステップＳ２００の処理に入る。なお、当該情報と現在時刻が一致していない時（Ｓ１１１、ＮＯ）には、処理ステップＳ３０５に移り、事前配車を行わない。

処理ステップＳ１１２の処理は、基本的に図７の処理ステップＳ１１２の処理と同じであるので、説明を割愛するが、要するに予測した利用者の人数とエレベーターかご１台当りの乗員数を比較して、予測した利用者の人数＞エレベーターかご１台当りの乗員数である場合には、処理ステップＳ３０４においてエレベーター複数台事前配車する。予測した利用者の人数≦エレベーターかご１台当りの乗員数である場合には、処理ステップＳ３０３においてエレベーター１台事前配車する。この判断には、乗車率を勘案するのがよい。

図１３は、図１２の予測混雑時先行かご配車処理を行った時の、混雑階（混雑予想階：例えば１階）の様子を示した図である。エレベーターかご２４は、例えば３台のうち１台（２４ａ）、または複数台（２４ａ、２４ｃ）が事前配車され、混雑階に到着すると各扉２５（２５ａ、２５ｂ、２５ｃ）を閉じた状態のまま待機する。このとき、利用者の大半が同じ方向への移動を行う事が明らかであれば、混雑階の乗場エレベーターサービス要求装置４は、上り、下りともに、行先方向の表示を行わないものであってもよい。

混雑予定時刻になって乗場に表れた利用者は、乗場エレベーターサービス要求装置４の呼び釦を押すことで待機中のエレベーターの扉が開放するので速やかに順次搭乗することができる。

１：ビルなどの施設、２：外部のシステム（公共機関管理システム）、３：エレベーター運行管理システム、４：各階の乗場エレベーターサービス要求装置、５：各階の監視カメラ、６：ビル管理システム、７ａ・・・７ｎエレベーター制御システム、８：通信手段、３１：学習部、３２：階床別人数予測部、３６：受信部、３７：総合評価部、３８：割当て司令部、３９：乗場呼び登録判定部、４０：乗車率設定部、Ｓ２：公共機関管理情報、Ｓ４：サービス要求信号、Ｓ５：映像信号、Ｓ６：ビル管理情報、Ｓ７２：制御指令信号

Claims (4)

1. ビルなどの施設内に設置された複数のエレベーター装置の運行管理を行う外部システム連携配車システムであって、
   複数のエレベーター装置の運転実績と外部システムからのイベント情報を入力する受信部と、該受信部から得られる運転実績の情報を過去経験データとして記憶し、学習する学習部と、該学習部の記憶情報と前記イベント情報を用いて乗場の階床別に利用者数を予測する予測部と、前記イベント情報の遅れを含む時刻情報と現在時刻が一致するときに混雑発生が予測される予測混雑階にエレベーターかごを事前配車する乗場呼び登録判定部を備え、
   前記乗場呼び登録判定部は、エレベーター装置における利用者の乗車率を用いて、混雑発生が予測される予測混雑階に事前配車するエレベーターかごの台数を決定し、前記イベント情報による流入が予測される予測混雑階の乗場に設置された呼び釦自動登録を前記予測混雑階から一般在籍階に向かう方向について行い、所定時間内に前記予測混雑階において別方向の呼びが発生した場合には呼び釦自動登録をキャンセルし、
   予測混雑階に事前配車されたエレベーターかごは、予測混雑階において戸開待機していることを特徴とする外部システム連携配車システム。
2. 請求項１に記載の外部システム連携配車システムであって、
   複数のエレベーター装置の前記運転実績は、各階の利用者数および移動方向の情報であることを特徴とする外部システム連携配車システム。
3. ビルなどの施設内に設置された複数のエレベーター装置の運行管理を行う外部システム連携配車方法であって、
   複数のエレベーター装置の運転実績と外部システムからのイベント情報から得られる運転実績の情報を過去経験データとして記憶して学習し、学習した記憶情報と前記イベント情報を用いて乗場の階床別に利用者数を予測し、前記イベント情報の遅れを含む時刻情報と現在時刻が一致するときに混雑発生が予測される予測混雑階にエレベーターかごを事前配車するとともに、
   エレベーター装置における利用者の乗車率を用いて、混雑発生が予測される予測混雑階に事前配車するエレベーターかごの台数を決定し、前記イベント情報による流入が予測される予測混雑階の乗場に設置された呼び釦自動登録を前記予測混雑階から一般在籍階に向かう方向について行い、所定時間内に前記予測混雑階において別方向の呼びが発生した場合には呼び釦自動登録をキャンセルし、
   予測混雑階に事前配車されたエレベーターかごは、予測混雑階において戸開待機していることを特徴とする外部システム連携配車方法。
4. 請求項３に記載の外部システム連携配車方法であって、
   複数のエレベーター装置の前記運転実績は、各階の利用者数および移動方向の情報であることを特徴とする外部システム連携配車方法。

Images