JPH0725493B2

JPH0725493B2 - エレベ−タの群管理制御方法

Info

Publication number: JPH0725493B2
Application number: JP60216634A
Authority: JP
Inventors: 亨山口
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1985-09-30
Filing date: 1985-09-30
Publication date: 1995-03-22
Anticipated expiration: 2010-03-22
Also published as: JPS6279173A

Description

【発明の詳細な説明】〔発明の技術分野〕本発明は、エレベータの群管理制御方法に係り、特にビ
ル交通流の予測とモデル化による、モデル適応群管理制
御方法の実現にあり、低需要だけでなく、高需要時も、
システム総合の輸送力を増強させ、需要モデルに適応し
高需要をつつみこむ群管理制御の実現するエレベータの
群管理制御方法に関する。

〔発明の技術的背景とその問題点〕

近年、エレベータの群管理制御において、交通流のモー
ドに合った群管理を行なうために、交通データを常に学
習し、一定の交通パターンを検出し、それにしたがって
群管理の評価パラメータを変化させるものが現われてき
ている。これらのシステムにおいては、学習データは、
平均化されたものであり、大きな交通パターンの傾向を
示すものでありこのため、マクロ変化対応のシステムで
あるといえる。またピーク時のオペレーションもあらか
じめセットされたオペレーションであり、計画された一
定量の輸送力である。

特にアップピーク時、２フロアに基準階のもつビルにお
いては、固定されたオペレーションでは、２フロアの需
要の時間的変化に対応できない。

また１フロアの基準階のビルであっても、基準階の需要
が計画以上となった場合や、逆に空需要の場合にそれぞ
れ輸送力、有効なかごの運行に問題を生じる。また、会
議室、宴会場等の変動のあるフロアにおいても、あらか
じめプリセットされたオペレーションでは、アップピー
ク同様に、高需要時や、空需要時に輸送力や、有効なか
ごの運行に問題を生じる。

〔発明の目的〕

本発明は上記事情に基づいてなされたもので、その目的
は、交通流のマクロの変化に加えてミクロの変化を適確
にとらえ、交通需要を予測しモデル化し、タイムリーに
そのモデルに適応した群管理制御を行なうことにより、
低需要はもとより高需要となった場合もシステムとして
の総合の輸送力の向上を可能とするエレベータの群管理
制御方法を提供することにある。

〔発明の概要〕

本発明は上記目的を達成するために、過去のホール呼の
発生やかごの乗・降情報やかごの行先情報を、ビルのそ
れぞれの交通モードに対応して学習してマクロの交通流
として使用し、現在の収集できるかぎりのビルの交通関
連データや前記の現在のデータを収集してミクロの交通
流として使用し、それぞれの交通流の需要予測より方向
を考慮した各階の集中，発散の需要予測を求めてモデル
化することにより交通流の傾向を先取抽出して該傾向に
適合した群管理制御を行なうものである。

上記方法を実施することにより、できるかぎりのビル情
報の収集と、各フロアのアンバランス集中人数や、一定
時間の集中人数等のデータより、ミクロの変化を予測
し、学習データより、マクロの変化を予測し、交通の予
測需要より的確に交通流を、集中，発散，発散集中，複
合モデルの４モデルに分類し、群管理評価テーブルの変
化で対応できなき需要予測となった場合は、その交通流
に対応してオペレーションモードを変化させ、集中需要
予測部に対して適当な台数の急行かごを用意し、また発
散需要予測部に対しては適当な台数のピーク輸送かごを
用意し、一周時間の変化を目的として、停止階を変化さ
せ、急送レベルをかえて輸送力を向上させ、交通流に適
応したコントロールを行ない、特に高需要に対しても、
システムの輸送力を向上させ高需要をつつみこむことが
できるようにしたものである。

〔発明の実施例〕

以下本発明の一実施例に係るエレベータの群管理制御方
法を第１図を参照して説明する。

第１図において、１は群管理制御装置で群管理コントロ
ール部1A、知識工学応用部1B、補助記憶1cからなり、エ
レベータ制御装置２、伝送コントローラー３、エレベー
タ監視モニタ４と、シリアル伝送による伝送専用LISに
よるシステムバスで結合されている。ホールゲート，ラ
ンプ，センサ，ディプレイとのI/Oコントローラ５との
結合は伝送専用LISと汎用の伝送ソフトウェアによるシ
リアル伝送により行なわれている。かご内コントローラ
ー６とエレベータ制御装置２もシリアル伝送により結合
されている。ビル管理コンピュータ７のデータや、OA用
コンピュータ８のデータ、タイムレコーダ9Aのデータ入
力装置７、報知データや入口カウンタ10AのデータのI/O
コントローラ10は伝送コントローラ３のインタフェース
により結合され、シリアルシステムバスに伝送される。

本システムは最大仕様に近い例であり、このため一部分
がないシステムであっても、本発明は行なうことが出来
る（入力されたものに対して行なう）。尚、7A,8A,4Aは
CRT端末、キー入力等の操作表示系である。

次に第２図を参照してそのソフトウェア構成の説明を行
なう。

第２図において、群管理制御装置１（第１図）がスター
ト（Ｓ）後、タスク管理プログラム20により、どのタス
クを起動するかが決定される。タスクは機能別ソフトウ
ェアモジュールであり、条件により起動される。

ここで各タスクの説明を簡単に行なう。

32はRAMやCPUのレジスタのイニシャライズ及び各LSIの
イニシャライズを行なうイニシャライズタスクであり、
初期状態や動作のモードが切りかわった場合に起動され
る。

21はCCT（カーコンデションテーブル）、KCT（かごコン
デションテーブル）、HCT（ホールコンデションテーブ
ル）等の外部入力をRAM上にセットする外部入力タスク
である。この外部入力タスク21は優先度が高く、100mse
c程度ごとに再起動が行なわれる。ここで、HCTはホール
コンディションテーブルの略名で、エレベータ制御装置
によりホール呼び登録されそのデータが入力される。CC
Tとはカーコンディションテーブル、KCTとはかごコンデ
ィションテーブルである。

ここで仮に群中号機をＡ〜Ｄの４台として、１〜８フロ
アと仮定すると、上記HCT、CCT、KCTはそれぞれ第３
図，第４図，第５図のようなビット構成となっている。
すなわち、第３図に示したホール状態を表わすHCTにお
いて、０〜13のホールサプインデックス（HS）に対して
８階の下降（8D）から７階の上昇（7U）まで各８ビット
の情報が格納されている。各階毎のホール状態を具体的
に説明する。例えば５階のエレベータホールにて上昇ス
イッチが押されるとHS11（5U）の７ビットが１となり、
このホール呼びに対応するサービスエレベータが後述す
る手法でＡ号機と決定すると、HS11の０ビットおよび６
ビットが１となる。そして、上記Ａ号機が５階に到着す
るHS11の０、６、７ビットがすべて０にリセットされ
る。すなわち、０〜３ビットは各エレベータの号機セッ
トを示し、６ビットはホール呼びに対するエレベータの
割付の有無を示し、さらに、７ビットはホール呼びの有
無を示す。

第４図のかご状態を表わすCCTにおいて、０〜３のイン
デックスに対して、エレベータＡ号機からＤ号機まで各
16ビットの情報が格納されている。すなわち、０〜３ビ
ットにはかごの荷重状態が２進法で示されている。これ
ら０〜３ビットの意味は、“0001"“0010"“0011"“010
0"“0101"“0110"“0111"“1000"“1001"“1010"“101
1"“1100"に対してそれぞれ０〜10％、11〜20％、21〜3
0％、31〜40％、41〜50％、51〜60％、61〜70％、71〜8
0％、81〜90％、91〜100％、101〜110％、111％以上を
示す。

５ビットはかごの走行状態を示し、“1"は走行中、“0"
は減速中を示す。７ビットは扉の開閉状態を示し、“1"
は開放中、“0"は閉鎖中を示す。８〜13ビットはかご位
置を２進法で示したものである。14,15ビットはかごの
移動方向を示し、“10"は上昇中、“01"は下降中、さら
に“00"は無方向、すなわち停止中を示す。

第５図のかご呼び状態を表わすKCTにおいて、第３図のH
CTと同様に、０〜３ビットがエレベータＡ〜Ｄ号機に対
するかご呼びの有無を示す。

以上によりエレベータやホール呼の状態が入力されたこ
とになる。

第２図において、22は割付を行なう割付タスクである。
この割付タスク22は100msec程度ごとに新発生ホール呼
びをチェックし、もし発生があれば、予測未応答時間演
算サブルーチン24、満員等、ダメージ予測サブルーチン
25及び評価サブルーチン23により、予測未応答時間、満
員等のダメージに対する評価を行ない、評価の最良な号
機を決定する。

26は割付見直しタスクであり、この割付見直しタスク26
は約１秒に１回程度起動されるレベルの低いタスクで、
長持ちや満員となったり、予測されたりするホール呼び
に対して、割付変更を行なうものである。28は各単体エ
レベータ交信用タスクであり、サイクリックに行なわれ
るデータの伝送の他に、必要に応じてコントロールの出
力やデータ要求など割付、割付キャンセル等、乗車人
数、降車人数、新発生かご呼び等が行なわれる。これら
はバッファを利用して行なわれ、第６図に示すような内
容のデータが第７図に示すようなフォーマットで伝送さ
れてくる。

29は年間タイマ、各種タイマであり、10ms、100ms、１
秒等の各種のインターバルタイマと、それらと組み合わ
された年間タイマのルーチンである。また、これらのデ
ータは外部タイマにより補正される。

年間タイマには月、日付、曜日、休日、六曜、その他の
行事等情報があり、第２のI/Oタスク31のフロッピディ
スクや第１のI/Oタスク30のCRT等により情報が更新され
る。

第１のI/Oタスク30のCRT伝送インプットアウトプット、
キャラクタディスプレイターミナル用のタスクは、外部
の端末や他のコンピュータ等との情報の伝送に使用され
る。このタスク30は他の群管理タスクを害さないように
低いレベルでタイムスライスされて起動する。

また、第２のI/Oタスク31の（フレキシブル）フロッピ
ーディスクコントロール用は、外部のフロッピーディス
クに学習データ等を記憶するときに起動される。第１の
I/Oタスク30と同様に低いレベルで起動される。学習デ
ータ処理タスク27は、外部入力や単体からのデータによ
り、その時点の状態のデータテーブルにセットしてい
き、また次の状態に変化する時などそのデータの入れか
えを行なうタスクであり、データの変化時や状態の変化
時に起動される。また、低いレベルのタスクであり、高
い群管理タスクを害さないように起動される。ただし、
特別のフラグや優先順の変更等が行なわれた場合は変化
する。ここで、学習データは第８図（ａ）（ｂ）（ｃ）
（ｄ）（ｅ）に示すように月、日付、曜日、六曜、休
日、時間帯（タイムバンド）などの要素によりいくつか
の同等の交通モードに分類され、そのモード別に第９図
及び第10図に示すようなデータをもつ。

第９図及び第10図にそれらの例を示してある。第９図及
び第10図において記号は以下である。

HCT＄RAT:15分間の平均ホール呼び発生個数。

KCT＄RAT:平均かご呼び発生個数。

IN＄RAT :乗車人数平均。

OUT＄RAT:降車人数平均。

KCT＄SET:各階に対するかご呼び発生率。

HCT＄RAT〜OUT＄RATは方向付階床のインデックスHS（ホ
ールサブインデックス）によって示される。KCT＄RATは
Ａ階からＢ階へというA,Bのマトリクスにより示されて
いる。

また、高需要時はそれらの変化がこまかいインタバルで
学習されている。これはAV＄MEN＄Ｐ（HS.t）で各HSと
ｔについて示される。ただしｔは時刻である。

その他のタスクとしては、第２図において、１秒おきに
起動され、外部のビル管理コンピュータとデータの入
力、出力のデータ交信やそれによるデータ収集を行なう
タスク34や、そのデータを利用して需要の先取りを行な
い、交通需要を予測し、運転モデルを決定する交通需要
予測タスク33があり、これらタスク33,34は、100msecご
とに起動する。また、これらによって起動される運転モ
デルのタスクとして各種運転タスク35がある。

これらのタスクの関係を説明するために第11図にソフト
ウェア構成を示す。

第11図において、ベースのデータとして各号機の状態4
0、学習データ41、ホールデータ42、ビルデータ43が用
意される。ビルデータはビルコンピュータ44（その他の
要素は第１図で示した装置に相当する）とのデータ交信
により求められる。また、群管理のホールデータを要求
に応じてビルコンピュータ等に送信する（相互の必要デ
ータの授受がなされる）。

また、制御モデルの決定においては、ベースデータ、特
に学習データ40とビルデータ43により処理系52で集中発
散の交通需要モデルが予測され、ルール集合対45により
処理系46でその予測需要モデルに適応する運転適応モデ
ルの決定やパラメータの決定、パラメータの変更が行な
われ、制御される。

ルールの集合体45は、ユーザの指定による部分、エキス
パート作成の部分、自動作成部分があり、追加変更が容
易な構造（RAM上に作られる）となっている。そのルー
ル情報は第12図のようになっている。また、長期傾向シ
ュミレート54はルールの自動作成等に使用され、処理系
53の近い未来のシュミレート及び予測到着時間演算は割
当の評価演算に利用される。

また、ビルのフロアの集中，発散レベルが高い場合は群
管理実コントロール部にて（集中，発散については後に
くわしく説明する）、制御系48〜51の特殊制御が使用さ
れ、通常は集中モデル制御47が使用され、需要によりパ
ラメータの選択や変更が行なわれる。

ここで、この集中，発散のビルモデルについて第13図を
参照して説明する。

第13図（ａ）が発散モデルであり、特定の階より人が発
散している。第13図（ｂ）が集中モデルであり、特定の
階へ人が集中している。第13図（ｃ）は特定階で集中と
発散しているモデルであり、これらの複合モードが第13
図（ｄ）に示されている。これらは以前の交通パターン
のイメージで考えると第14図で示されるようになる。こ
れらの第13図（ａ）〜（ｄ）のモデルでほぼすべての交
通モデルを示すことができる。この発散や集中の需要が
ひどい場合には特殊な運転が必要となる。

一般に集中モデルに対しては急行かごであり、発散モデ
ルに対しては引き戻しや出発間隔オペレーションがよく
使用されている（ピーク輸送オペレーション）。これら
の特殊パターンが第11図の各モデル制御48〜51である。
またこれらはそれぞれ複数用意されている。かつ追加変
更が容易な構成となっている。

また、本実施例においては、以前の交通パターンのよう
なマクロの変化にプラスして、ミクロの変化もビルデー
タ現在の交通データより先取し、これらの需要に対応す
る。

ここで第11図におけるビルコンピュータ等との交信ルー
チン44の説明を行なう。

第１図の伝送コントローラ３では、ビル管理コンピュー
タ７、OAコンピュータ８、タイムレコーダデータ９、各
種報知データ、入口カウンタデータ等がI/Oコントロー
ラ10により入力される。これらの一覧を第15図に示す。

これらのもののうち、このコードが需要モデル予測に利
用されるものは、ビル情報素データ（第17図）とされ、
予測に利用される。学習データの予測に利用されるもの
は、その場で利用される。利用されたものは、バッファ
より消去される（第16図を参照）。

また、送信要求があった場合には、その要求データを送
信する。休日や夜間において、未使用フロアのホール、
人検出データをビルコントロールコンピュータへ送信す
る。

次に本発明の集中，発散の交通需要のモデル化と先取予
測のルーチンの説明を第11図及び第18図を参照して行な
う。

第18図においてエントリ、結合子Ａを経てルーチン60に
おいて前ルーチンで入力したビル情報素データを入力す
る。ここで、そのバッファは第17図のようなフォーマッ
トとなっている。レコードナンバー、情報コード、通常
処理の有無、変更削除の有無、月、日付、時間（スター
ト・エンド）、付階（スタート・エンド）、最大ｎ階床
まで（ビット対応のホールサブインデックス形式）、ま
たその予測人数で形成されている。

次にルーチン61でそれがビルデータ予定リストに変換さ
れる。これはスタート時間がリミット値より近いもの
（第25図のルーチン70）が行なわれ前データの通常処理
がONされ、素データレコードナンバーが第21図に示すバ
ッファ中へ移動する。このとき第19図に示されているよ
うに、その情報コードに対し、左部の処理を行ない、ビ
ルデータ予定リストに変更される（第25図のルーチン7
1）。

情報コードに対する処理とは、第19図において集中モデ
ル順序、発散モデル順序、に対するONトリガコード、
OFFトリガコード、に対するONトリガコード、OFFトリ
ガコード、に対するONトリガタイム変化、に対する
ONトリガタイム変化の各フィールド部により成っている
（Ａ〜Ｈフィールド）。

第19図のビル情報コード０の場合を例に説明する。

会議室の予約の場合、ビル予定リスト（Ａ部）のとし
て集中モデルとして（Ｂ部）発散モデルとする。この
２種のリストを作成するに対してＣ部より１のトリガ
コールを使用する（第22図を参照）。に対してＥ部よ
り３のトリガコードを使用する（第22図を参照）。これ
でともにビルデータ予定リストのC,E,G部がセット
できる。また、Ｄ部はイニシャルCLRを行なう。また、
Ａ部は第17図のＧ部によりセットされる。また第24図の
Ｆ部はの集中モデルについては１分間の集中人数、
の発散モデルについては乗車人数となるため、第17図の
Ｈ部が100人で、10分でその会議室に集合する場合は、
の第24図Ｆ部には100/10＝10人／分となりのＦ部に
は100人となる。また第24図のＢのトリガ起動時間は、
第19図のG,Hにより変化させられる。

仮りに、第17図のＤ部が９月10日13:00から、Ｅ部が９
月10日14:00までであったとすると、第24図のに対し
ては、Ｂ部は第19図のＧ部により９月10日の12:50とな
り、に対してはＢ部は第19図のＥ部より９月10日14:0
0となる。

これで第24図のビルデータ予定リストとなった。

これにより、第25図のルーチン72により第26図のビルデ
ータ予定リストレコードナンバーバッファにセットし、
第21図の対応バッファの右に２つセットされる。これら
はビルデータ所定リストクリア時、クリアされる。

このように、１つの素データから２つの予定リストが生
成されることがある。また、ものによっては、（情報コ
ード2,3）多数の素データから１つの予定リストが生成
されることもある。

次に第18図のルーチン62へはいる（第27図を参照）。ビ
ルデータ予定リストチェックルーチン80で、トリガが起
動の時間をチェックし、もしONとなっていたらトリガチ
ェックを起動する。トリガチェックルーチンは第23図に
示されており、条件が成立した場合、そのレコードナン
バーのエリアをONする。もしトリガがONしたら、ビルデ
ータ実動リスト作成ルーチン81へ進む（第28図を参
照）。

ここで以前とかわるのは、第28図のB,C,D部である。

まずＢ部に現時間をセットし、Ｃ部は第19図のOFFトリ
ガをセットする（第19図でD,Fに関する部分）。第28図
のＤ部がCLRを行なう。第29図にレコードナンバーがセ
ットされる。また、今後のビル実動データリストチェッ
ク時、Ｆ部が最近データに更新される。ルーチン82で、
第26図よりレコードナンバーがCLRされ、また以前のト
リガチェックルーチンがOFFされ、また、ビル素データ
レコードナンバーもCLRされる。トリガがOFFのままリミ
ットをこえた場合は、この時点でCLRされる。

次に28Aより実動データチェックルーチン83へくる。こ
こでは、第28図の下の需要予定が常に更新される。本実
施例においては、特定の階に対し常に一定時間の集中人
数と、平均フロア人数よりの片寄りであるアンバランス
集中人数をサーチしている（外部入力タスクによる）。

第30図に会議室のデータ例を示す。これらのデータによ
り需要予定が更新される。また、トリガ条件の成立チェ
ックにも利用される。

次に、もしここでOFFトリガ条件が成立した場合、トリ
ガチェック84のCLRと実動リストレコードナンバーのCLR
が行なわれる。また、トリガがOFFのままリミットを起
えた場合も同様である。

以上で第18図のルーチン62の説明を終える。次にルーチ
ン63,64の説明を行なう。

このルーチンにおいては、実際のかごデータ等により、
集中，発散のモデルをサーチしている。またあらかじめ
指定された特定階に対しては同様に行なわれている。例
として会議室を例とする。45％以下で到着し、80％以上
で出発し、すぐにそのホール呼が発生した場合は、ルー
チン64で第28図と同様なフォーマットで、発散のモデル
の実データリストが作成される。ルーチン65で、この実
データリストと、前の実動リストが合成され、ミクロ変
化に対する予測需要リストが作成される（これも、同様
なフォーマットとなる）。また一方ルーチン66,67にお
いて学習データより同様のフォーマットでマクロ変化の
予測需要リストが作成される。発散に対してはIN＄RAT,
集中に対してはOUT＄RATのそのHSに対応したデータが使
用され、これがあるリミットを越えるものについて作成
される。フォーマットは前記同様である。またインター
バルは高需要時は短く、中需要時はある程度長いインバ
ーバルで予測需要テーブルが作成される。これらのミク
ロ，マクロ変化需要リストの合成により、ルーチン68に
おいて総合の集中，発散需要予測データが作成される。
これらは、高需要な順よりならべられて示されている。
以上で需要予測データが行なわれた。

これらの集中発散の需要予測データを利用し、第11図の
ルール集合体45中の制御モデルと需要レベルの決定が行
なわれる（第18図のルーチン69を参照）。

ここでその説明のために会議室の例を示す。

会議室100人収容の予約があり、このルーチンでこの予
約がうかびあがり、これが所期状態で５人／分の会議室
集中モデルがあったとする。この時点で、この需要が通
常運転の係数変化で対応できると予測された場合は第11
図の制御47を用いる。次の時点で10人／分となり、通常
モデルでは不可能な場合（通常リミットは６人／分とす
る）は集中モデル制御49で、４台中２台を会議室急行か
ごとして使用し、この10人／分以上の輸送を行なう。会
議終了時も同様に行なわれ、この場合は発散モデルとな
り、ピーク輸送運転が行なわれる。そのようにすばやい
需要予測とモデル化で群管理性能は向上された。

以上により第11図の集中，発散の交通需要モデル予測の
ルーチン52と、会議室の集中モデルに対する制御へのフ
ィードバック例を示した。

次にアップピーク時の制御の流れを例にとって、交通需
要モデルの予測が、制御にフィードバックされる部分を
説明する。ここでは特に輸送力を中心に制御される。

ビルの例として17STOP6台の場合を示す（第31図を参
照）。このビルはB1,1〜16F（内部信号は１〜17Fであ
る）となっており、学習データよりアップピーク時に
は、B1Uからの発散需要と1Uからの発散需要が予測され
ている。これはB1に地下鉄の乗降口があるためである。
しかも、B1Uの予測需要ピークと、1Uの予測需要ピーク
また予測需要量がことなっているために以前の一定のピ
ーク運転では、最大ピーク時には輸送力が不足し、その
他の場合は有効なかご運行が害される傾向となる。

本実施例で用いる例は第31図に示されているが、これら
のホール呼の系統はＡ〜ＣとＤ〜Ｆそれぞれに分離が可
能となっている。また存館人員は約2500人で、一社ビル
のために特にアップピークの需要は集中する。アップピ
ーク時の予測需要をわかりやすく示したものが、第32図
である。

7:30〜7:45頃は発散モデルＡとなり1U（１階アップ）よ
り約10人/5分間の需要がみこまれ、B1U（B1アップ）よ
りは約50人/5分間であると予測される。同様に7:45〜8:
00頃は発散モデルＢとなり、1Uより約95人/5分間、B1U
より約90人/5分間、また8:00〜8:30は1Uより約200人/5
分間、B1Uよりは約50人/5分間が見込まれる。

これらの交通流をモデル化したものが第33図（ａ）〜
（ｅ）に示されており、このデータが先に示したモデル
のリスト中にエントリされている。

このビルのアップピーク時の流れはB1UよりはじまりB1
U,1Uとなり、最終的に1Uが多くなり最大の需要となる傾
向をもっている（第33図においてはオペレーションも考
慮した交通流を示している）。

これらの交通流モデルに適応したピークオペレーション
を求めるうえで、第34図に示されているように、かごの
輸送力が計算される。ピーク輸送制御時（基準階で先
発，次発などが行なわれ戸開し、また出発後も基準階へ
引きもどされる制御）、その急送レベル（途中の不停止
階床間隔）を変化させた場合の輸送力を求める（通常の
交通計算により求められる）。7:30〜7:45のモデルＡの
場合、Ａ〜Ｃの３台のピーク輸送で十分であり第34図の
1.17.0（17ストップ全階床停止モード）より３台で81人
/5分間の輸送力となるためである（第35図を参照）。7:
45〜8:00モデルＢの場合Ａ〜Ｃで1.17.1（第35図を参
照）、Ｄ〜Ｆで1.16.1でそれぞれ1U、102人/5分間、B1U
96人/5分間となり輸送力は十分となる本形式は２分割ア
ップピークであり、ホール系統は分離される（第32図を
参照）。またこれらは１階床の不停止（オペレーション
であり、第36図に示されている（第36〜37図の記号は第
35図と同様である）。8:00〜8:30のモデルＣの場合需要
予測が特に多く、通常の方法では輸送力は不足する（通
常250人/29＝約８台のエレベータが必要となる）。

本実施例においては1Uへ発散需要を集め、これを急送レ
ベルを高くして輸送する。ここでH,L（ハイバンク，ロ
ーバンク）に分離した場合はH,L需要のばらつきによる
悪化があるために本発明においては第37図のように急行
レベル３（３階床おきに停止）で行なった。この場合輸
送力は258人/5分間となり輸送力は十分である。

1U,B1Uの発散予測需要をつつむようにシステムの総合の
輸送力が可能となった（第38図を参照）。また、これら
のオペレーションによる交通モデル先に参照した第33図
に示されている。

このように交通流の変動に適応した群管理制御を行な
い、高輸送力まで実現した。

本実施例で、急送レベルとして途中階不停止（スキッ
プ）としているのは、人がその急行階より目的階へ、階
段を利用して移動することをのぞんでいるからである。
また、乗客のこんらんをなくすために、基準階の行き先
を示す、第40図に示す大形案内表示器92やかごに第39図
における消えるボタンのかご操作盤91、乗込案内表示器
90等が使用されている。

以上でアップピーク時の発散モデルへの制御適応を説明
した。

以上説明したように本実施例では、ビル情報と学習デー
タ等により交通流のマクロ，ミクロの変化をとらえ、需
要の予測を的確に行ない、その交通流の幹をとらえてモ
デル化し、そのモデルに適応してゆく群管理制御を行な
い、このことによって強力なピーク需要や、変そく的な
ピーク需要に対し、フレキシブルに適応し、システムの
総合の輸送力を強力にした。このことによって高需要を
つつみこむような群管理制御を可能にした。

本発明の他の実施例としては以下のようにしてもよい。

即ち、発散モデルの適応制御の他に、集中モデルの適応
制御においても、モデル化、需要予測、輸送力の演算、
制御方法の決定、高需要をつつむ適応制御のアルゴリズ
ムは同様に利用できる。

〔発明の効果〕

以上詳述したように本発明によれば、ビルデータや学習
データにより、ビルの集中，発散の需要予測を行ないモ
デル化し、先取した需要モデルに適合する制御を行なう
ことにより、低需要はもとより高需要となった場合もシ
ステムとしての総合の輸送力の向上を可能としたエレベ
ータの群管理制御方法が提供できる。

【図面の簡単な説明】

第１図は本発明の一実施例によるエレベータの群管理制
御方法を使用したシステム構成図、第２図及び第11図は
同実施例を実現するソフトウェア構成図、第３図，第４
図〜第10図，第17図，第19図，第20図，第21図，第24
図，第26図，第28図，第29図は同実施例を実現するため
のメモリデータを示す図、第12図，第13図，第14図，第
15図，第22図，第30図は同実施例の動作を説明するため
の図、第16図，第18図，第23図，第25図，第27図は同実
施例のフローチャト、第31図〜第38図は同実施例におけ
る制御例を説明するための図、第39図及び第40図は同実
施例をスムーズに行なうための案内表示の例を示す図で
ある。１……群管理制御装置、２……エレベータ制御装置、３
……伝送コントローラ、４……エレベータ監視モニタ、
５……ホールゲート，ランプ，センサ，ディスプレイI/
Oコントローラ、６……かご内コントローラ。

Claims

【特許請求の範囲】

【請求項１】ビルの複数のサービス階に対して複数のエ
レベータを就役させ、当該複数のエレベータの動向を総
括して制御する群管理制御方法において、ビルのエレベータ設備から収集されるエレベータ利用状
況に関するマクロ交通流と、ビルのエレベータ以外の設
備から収集されるビル交通関連データに関するミクロ交
通流とを得、これらマクロ交通流及びミクロ交通流に基づき、特定ホ
ールから人が出発する人数が多い発散モデルと、特定ホ
ールへ人が集中する人数が多い集中モデルと、特定ホー
ルから人が出発する人数と特定ホールへ人が集中する人
数とが多い発散・集中モデルと、これらモデルを複合化
した複合モデルとを分類し、この分類した各モデルに基づき前記複数のエレベータ毎
の予測需要の大きさを先取り抽出して前記複数のエレベ
ータを群管理制御することを特徴とするエレベータの群
管理制御方法。
【請求項２】前記ミクロ交通流は、報知装置、ビル関連機器、ビル管理用コンピュータ及び
オフィースオートメーション用コンピュータから収集さ
れるものであって、タイムレコーダデータ、会議室利用予約データ、出入口
の人数カウンタデータ、会議終了報知データ、休日・夜
間の室の利用データ、ホテルの客室利用状況データ、ホ
テルの客室予約データ、団体客の到着データ、団体客の
出発予定データ、団体客の出発報知データ、パーティ及
び宴会場の予約データの一部又は全部に基づき得られる
ものであることを特徴とする特許請求の範囲第１項記載
のエレベータの群管理制御方法。
【請求項３】前記ミクロ交通流は、報知装置、ビル関連機器、ビル管理用コンピュータ及び
オフィースオートメーション用コンピュータから収集さ
れるものであって、タイムレコーダデータ、会議室利用予約データ、出入口
の人数カウンタデータ、会議終了報知データ、休日・夜
間の室の利用データ、ホテルの客室利用状況データ、ホ
テルの客室予約データ、団体客の到着データ、団体客の
出発予定データ、団体客の出発報知データ、パーティ及
び宴会場の予約データの一部又は全部と、各階の近い未来における平均在ホール人数と当該近い未
来時における在ホール人数との差によるアンバランス集
中人数とに基づき得られるものであることを特徴とする特許請求
の範囲第１項記載のエレベータの群管理制御方法。
【請求項４】前記ミクロ交通流は、各階の一定時間の集
中人数により得られるものであることを特徴とする特許
請求の範囲第１項記載のエレベータの群管理制御方法。