JPS6279181A - エレベ−タの群管理制御装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［発明の技術分野］ 本発明は、エレベータの群管理制御に係わり、特にビル
交通流の先取りによる交通形態のモデル化と、それに適
応し、且つ、需要変化に即応して最適運行するエレベー
タの群管理制御装置に関するものである。

［発明の技術的背景とその問題点］ 近年、複数台のエレベータを並設した場合に、エレベー
タの運転効率の向上およびエレベータ利用者へのサービ
ス向上を図るため、各階床のホール呼びに対する応答号
様をマイクロコンピュータ等の小形コ゛ンビュータを用
いて合理的に、且つ、速やかに割当てることが行なわれ
ている。

すなわちこれは群管理制御と呼ばれる制御方式であり、
ホール呼びが発生すると、そのホール呼びに対処するの
に最適なエレベータを選定し、早期にそのホール呼びに
応答させるエレベータを割当てるとともに、他のエレベ
ータはそのホール呼びに応答せないようにしたり、ある
いは朝の出動時や退社時、昼食時等のような交通需要の
増加時、更には夜間等のような交通減少時などそのビル
独特の交通変化に合わせて予め設定した運転モードに切
換えつつ効率的な運用を図るべく各エレベータを制御す
るものである。

ところで近年のような小型コンピュータの著しい発達に
伴う小型コンピュータのコスト低減により群管理装置の
他にも単体のエレベータの制御を行うエレベータ制御装
置等にも小型コンピュータは使用されるようになった。

またこれらのコンピュータに対する情報の伝達方法とし
てはシリアル伝送方法が主流となりつつある。そして、
これら群管理制御装置とエレベータ単体制御装置は各伝
送装置と、ソフトウェアによる一定の手続により、単純
に結ＩＩ！（又は光ケーブル接続）で自由に群管理デー
タを授受出来るようになっている。

また、多数台のエレベータを群管理制御する大規模ビル
においても、ビル管理用コンピュータや、ＯＡ（オフィ
スオートメーション）用コンピュータなどにより、ビル
全体を管理したり、各フロア間の情報の授受を行ってい
る。これらの情報の中にはビルの交通に関係するものが
多数台まれている。また群管理制御用のコンピュータの
情報にも、ビル管理時に必要なホールデータ（例えばホ
ールの乗客検出）も含まれている。しかしながら、これ
らのビル管理用のデータと群管理制御データの授受は、
はとんど行われていない。このため、それぞれに情報入
手のためのセンサや報知装置を取付るケースも見受けら
れる。

一方、エレベータの群管理制御装置において、交通需要
の変化に合った群管理を行うために、交通のデータを常
に学習し、一定の交通パターンを検出し、それにしたが
って制御アルゴリズムを変更しているものがある。これ
らのシステムにおいては学習データによる交通パターン
が平均化されているために、大きな傾向の変化にのみ対
応できる構成となっている。つまり、マクロ変化対応の
システムであると云える。そのため、より俊敏な交通需
要の変化、ミクロ変化への対応はなされず、これらに対
するサービスの悪化が見られる。特に一定周期の需要の
動きが無い会議室や、ホテルにおける宴会場などの、対
応がなされず、サービスの悪化が見られ、学習の効果が
十分に表われない。

また昼食時等のピーク運転に対しても、数分間の人の動
向の変化がサービスの悪化につながるために、平均化さ
れたマクロのデータでは不十分である。特に昼食時の場
合などは、前半、中間帯。

後半とピークの交通流が変化し、これらの、高需要をう
まくコントロールし輸送力を向上させるためには、ミク
ロの変化をタイムリーにとらえる必要がある。この他の
ミクロ変化の高需要（会議室。

宴会場）や、出動時の高需要も同様であり、平均化れた
学習データのみでは不十分であるといえる。

［発明の目的］ 羊こで、本発明の目的は交通流のミクロ及びマクロの変
化を先取りして適確にとらえ、交通流の形態をモデル化
して、タイムリーにそのモデルに適応した群管理制御を
行うことのできるようにしたエレベータの群管理制御装
置を提供することにある。

［発明の概要］ すなわち、上記目的を達成するため本発明は、複数のサ
ービス階床に対して複数台のエレベータを就役させ、各
々のエレベータの動向を把握して発生したホール呼びに
対してサービスするエレベータを選択決定して応答させ
るようにしたエレベータの群管理制御装置において、ビ
ルの利用状況及び予約状況等の交通需要に関連する情報
を受ける情報授受手段と、これらの入手情報をもとに予
測される交通需要の形態に合わせたエレベータ運行パタ
ーンのモデルを作成する作成手段と、各々のエレベータ
の動向データを収集すると共にこれらデータをもとに交
通需要の変化を知り、交通需要予測を行い、この予測に
応じて前記作成手段の作成するモデルを変更する修正手
段とを備えて構成し、前記交通需要関連情報をもとに予
測される交通需要時間帯でのエレベータの最適運行パタ
ーンのモデルを作成すると共に前記予測される交通需要
時間帯には前記作成したエレベータ運行パターンで群管
理制御するようにし、また、交通需要の変化を知ってこ
の変化に応じた交通需要予測を行い、この予測に応じて
前記モデルの変更を行って運行パターンを修正して群管
理制御するようにしたことを特徴とする。

すなわち、具体的には複数のサービス階に対し、複数台
のエレベータを就役させ、エレベータの運行データを収
集し、学習する機能を利用し、総括してコントロールす
る群管理制御装置において、ビル管理用各種データ、ビ
ル内ＯＡ用コンピュータデータ、その他ビルデータ（タ
イムレコーダデータ、会議室予約データ、出入口人数カ
ウンタデータ、会議終了報知データ、休日、夜間の部屋
の利用データ、ホテルの場合にはその客室利用状況デー
タ、予約データ、団体客の到着や出発予約データ、及び
報知データ、パーティや宴会場の予約データ）の一部又
は全部をその関連する時刻付近のミクロ変化の交通流予
測として利用し、また収集されている交通流の学習デー
タをマクロ変化（共通の時間帯、曜日、季節に関する交
通流の変化パターン）の交通流予測に利用し、これらを
用いて交通需要や、その継続時間、また、特定階への集
中、特定階からの人の発散による交通流の傾向の先取抽
出を行い、ビル交通流の形態をモデル化しそれに適応し
た制御を行うものである。

また、前記の交通流の傾向の先取抽出による交通形態の
モデル化において、各フロアの出入人数データと、その
時の交通流におけるその時間帯の各フロアの平均人数と
の差によるアンバランス集中人数を利用したり、各フロ
アの出入人数データより、各フロアの一定時間集中人数
を求め、それを利用し、また、ビル内各種データや、学
習データ及び前記アンバランス集中人数及び一定時間の
集中人数により、交通流を先取し、モデル化するうえで
、これらを発散モデル（特定階より人が発散するモデル
）、集中モデル（特定階へ人が集中するモデル）、発散
集中モデル（特定階からの人の発散及び特定階への人の
集中が起きるモデル）、複合モデル（前記のモデルの複
合）と分類し、それらのビル全体に対するアンバランス
のストレスの大きさより、その影響度を予測し、ビルに
適応した群管理制御を行うようにし、更に、先取りされ
た交通流モデルがビル全体におよぼす影響が少ないと予
測された場合、群管理制御の各種評価テーブルの変更に
より、ビルに適応させ、また、先取された交通流モデル
が、ビル全体におよぼす影響が大きいと予測された場合
、輸送力強化を図るためにオペレーションモードを変更
し、集中モデルに対し適正な台数の集中階（人が集中す
る特定階）への急行かごを用意し、また発散モデルに対
し発散階（人が発散する特定階）へのサービスを行うピ
ーク輸送かごを用意するなどして輸送力向上を図り、ビ
ルの交通流モデルに適応した群管理制御を行うようにす
る。

更に、集中階への急行かごや、発散階のピーク輸送かど
の運行に対し、ホールの先行表示や、乗込案内表示器に
よるかごの先行表示又はかご内操作盤の利用可能な階の
ボタン表示を行う等して不停止階のフレキシブルなセッ
トを行い乗客の利用上のサービスを強化する。

［発明の実施例］ 以下本発明の一実施例について図面を参照して説明する
。第１図は本発明の一実施例に係る群管理制御システム
の構成を示すブロック図である。

図において１は全体の群管理制御を司る群管理制御装置
、２は単体のエレベータの運行等の制御を行うエレベー
タ単体制御装置であり、また３は外部とのデータの授受
を行う伝送コントローラ、４はエレベータの運行状況を
監視する監視モニタである。群管理制御装置１はエレベ
ータ制御装置２や伝送コントローラ３、エレベータ監視
モニタ４とそれぞれ伝送専用ＬＳＩを用いてシリアル伝
送ラインによるシステムバスで結合されている。

また、ホールのゲート、ランプセンサ、ディスプレイ等
とホール入出力機器５とのｌ１０（入出力）結合はシリ
アル伝送ラインにより行われている。

これは伝送専用ＬＳＩと汎用の伝送ソフトウェアによる
。また、かご内に設けであるかご内コントローラ６とそ
れに対応するエレベータ制御装置２もシリアル伝送ライ
ンにより結合されている。また、ビル管理コンピュータ
１１のデータや、ＯＡコンピュータ１２のデータ、タイ
ムレコーダ１３のデータ、また、報知データ入力端末装
置１４よりＩ１０コントローラ１５を介して与えられる
例えば会議室の利用、終了、ホテル等における団体の到
着、出発等のような報知データ、入ロ力つンタデータ（
出入りする人員数）は伝送コントローラ３のインターフ
ェースにより結合され、エレベータシステム側のシリア
ルシステムバスに伝送される。これによって、群管理制
御装置１には上記各種のデータを与えることができる他
、群管理に関するデータを上記コンピュータ１１．１２
に与えることができる構成となっている。

本システムは最大規模に近い例である。このため、一部
分を削除したシステムであっても、本発明を適用できる
。

次にそのソフトウェア構成の説明を行う。第２図に示す
ように群管理制御用のソフトウェアの構成は種々の機能
別タスクとそのサブルーチン及び、これらのタスクを管
理するためのタスク管理プロダラムよりなる。そして、
群管理制ｍＴ装置１内の小型コンピュータ（一般的には
マイクロコンピュータを使用するので、以下マイコンと
称する）を動作開始させるとこのマイコンはまずスター
ト後、タスク管理プログラム２０を実行してどのタスク
すなわち、機能別に分離されたソフトウェアモジュール
を起動するかを決定する。タスクは機能別のソフトウェ
アモジュールであり、条件により起動される。

ここで、各タスクの説明を簡単に行う。３２はイニシャ
ライズタスクであり、このタスクはＲＡＭやＣＰＵのレ
ジスタのイニシャライズや、ＬＳＩのイニシャライズを
行うタスクであって、初期状態や、動作のモードが切り
かわった時、起動される。

２１は外部入力タスクであり、これはＣＣＴ。

ＫＣＴ、ＨＣＴ等の外部入力をＲＡＭ　（ランダムアク
セスメモリ）上にセットする入力タスクである。このタ
スクは優先度が高く、起動させると１００■Ｓ程度ごと
に再起動がかかる。

また、トリガのチェック等もこのタスク中で行われる。

ここで上記ＨＣＴはホールコンディションテーブルであ
り、これにはエレベータ制′ｗＪ装置によりホール呼び
登録された、そのデータが入力される。

ＯＣＴはカーコンディションテーブル、ＫＣＴはかごコ
ンディションテーブルであって今、仮りに群を構成する
エレベータがＡ−Ｄ＠Ｉａの４台とし、サービス階床を
１〜８フロアと仮定すると上記ＨＣＴ、ＣＣＴ、ＫＣＴ
はそれぞれ第３図、第４図。

第５図のようなビット構成となっている。

すなわち、第３図に示したホール状態を表わすＨＣＴに
おいて、Ｏ〜１３のホールサブインデックス（Ｈ８）に
対して８階の下降（８Ｄ）から７階の上昇（７Ｕ）まで
各８ビツトの情報が格納されている。各階ごとのホール
状態を具体的に説明する。

例えば、５階のエレベータホールにて上昇呼びホール釦
が押されたとすると、Ｈ８の１１（５Ｕ）の７番ビット
が１となり、このホール呼びに対応するサービスエレベ
ータが後述する手法でＡ号様と決定すると、Ｈ３の１１
における０番ビットおよび６番ビットが１となる。そし
て、上記Ａ＠ｎが５１１１に到着するとＨ８の１１にお
ける０、６゜７番ビットがすべてＯにリセットされる。

すなわち、０〜３番ビットは各エレベータの号機セット
を示し、６番ビットはホール呼びに対するエレベータの
割付の有無を示し、さらに、７番ビットはホール呼びの
有無を示す。

第４図のかご状態を表わすＯＣＴにおいては、０〜３の
インデックスに対して、エレベータＡ号機からＤ＠機ま
で各１６ビツトの情報が格納されている。すなわち、０
〜３番ビットにはかごの荷重状態が２進法で示されてい
る。これら０〜３番ビットの意味は“０００１　”　、
　　”００１０”　。

“００１１”、　　“０１００”、　　“０１０”。

“０１１０″、“”０１１１”、“”１０００”。

“１００１　”　、　　“１０１０”、“’１０１１’
”。

“１１００”に対して、それぞれ、０〜１０％。

１１〜２０％、２１〜３０％、〜３１〜４０％。

４１〜５０％、５１〜６０％、６１〜７０％。

７１〜８０％、８１〜９０％、９１〜１００％。

１０１〜１１０％、１１１％以上ヲ示ス。

５番ビットはかごの走行状態を示し、１１１　ＩＩは走
行中、“ＯＩＩは減速中を示す。７番ビットは扉の開閉
状態を示し、１″′は開放中、０″は閉鎖中を示す。８
〜１３番ビットはかご位置を２進法で示したものである
。１４．１５番ビットはかごの移動方向を示し、″“１
ｏ”は上昇中、“０１″は下降中、ざらに００ｎは無方
向、すなわち停止中を示す。

第５図はかご呼び状態を表わすＫＣＴを示しており、該
ＫＣＴにおいて、第３図に示すＨＣＴと同様に、Ｏ〜３
ビットがエレベータＡ−Ｄ号機に対するかご呼びの有無
を示す。

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

２２は割付タスクであってかごの割付を行うタスクであ
る。このタスクは１００ｍ５ｅＣ程度ごとに新発生ホー
ル呼びをチェックし、もし発生があれば、予測未応答時
間、満員等のダメージによる評価を行い、評価の最良な
号磯を決定する。

２６は割付見直しタスクであり、この割付見直しタスク
２６は約１秒に１回程度起動されるレベルの低いタスク
であって、長待ちや、満員となったり、予測されるホー
ル呼びに対して、割付変更を行うものである。

２８は各単体エレベータとの交信を行うための各単体エ
レベータ交信用タスクであり、このタスクはサイクリッ
クに行われるデータの伝送の他に、必要に応じてコント
ロール出力（割付、割付キャンセル等）や、乗車人数、
降車人数、新発生かご呼び等のデータ要求などが行われ
る。これらはバッファを利用して行われ、第６図のよう
なデータが第７図のように運ばれてくる。

２９は年間タイマ、各種タイマであり、これは１０ｎ＋
ｓｅｃ、　１００ｍ５ｅｃ、　１秒等の各種のインター
バルタイマと、それらと組み合わされた年間タイマのル
ーチンである。また、これらのデータは外部タイマによ
り補正される。年間タイマには月、日付、曜日、休日、
六曜、その他の行事等の情報があり、フロッピディスク
用の第２のＩ１０タスクや、ＣＲＴ用の第１のＩ１０タ
スクにより情報が更新される。

３０はＣＲＴ　（キャクタ・ディスプレイ・ターミナル
）伝送用の第１の■〜０（インプットアウトプット）タ
スクであり、このタスクは外部の端末や、他のコンピュ
ータ等との情報の伝送に使用される。このタスクは他の
群管理マスクを害さないように低い割込みレベルでタイ
ムスライスされて起動される。また３１はフロッピ（フ
レキシブル）ディスクコントール用の第２のＩ１０タス
クであり、このタスクは外部のフロッピディスクに学習
データ等を記憶するときに起動される。ＣＲＴ伝送用第
１のＩ１０タスク３０と同様に低い割込みレベルで起動
される。

２７は学習データ処理タスクであり、この学習データ処
理タスクは外部入力や、単体エレベータからのデータに
より、その時点の状態をデータテーブルにセットしてゆ
き、また次の状態に変化する時などにおいてはそのデー
タの入れ換えを行うタスクであって、データの変化時や
、状態の変化時に起動される。また、このタスクは低い
割込レベルのタスクであり、高い割込みレベルの群管理
タスクを害さないように起動される。ただし特別のフラ
グや、優先順位の変更等が行われた場合は変化する。

学習データは第８図に示すような月、曜日、六曜、休日
、時間帯（タイムバンド）などの要素により、いくつか
の同等の交通モ、−ドに分類され、そのモード別に、次
のデータを持つ。

第９図、第１０図にそれらの例を示しである。

ここで ＨＣＴ＄ＲＡＴは１５分間の平均ホール呼び発生回数、 ＫＣＴ＄ＲＡＴは平均かご呼び発生回数、ｌＮ８ＲＡＴ
は乗車人数平均、 ＯＵ　Ｔ　＄　ＲＡ　Ｔ　ｌｅｔ降者人数平均、ＫＣＴ
＄ＳＥＴは各階に対するかご呼び発生率を示す。

ＨＣＴ＄ＲＡＴ、〜ＯＵＴ＄ＲＡＴは、方向付階床のイ
ンデックスＨ８（ホールサブインデックス）によって示
される。

ＫＣＴ＄ＳＥＴは、例えば、Ａ階からＢ階へという個々
のかご呼び発生率を格納すべくＡ、Ｂのマトリックスに
より示されている。

またこの他に平均フロア人数、ＡＶ＄ＭＥＮ（Ｈ８）（
各Ｈ８について）が蓄えられている。

また、高需要時はそれらの変化が、細かいインターバル
で学習されている。これは各Ｈ８とｔについてＡＶ＄Ｍ
ＥＮ＄Ｐ　（Ｈ３，ｔ　’）で示される。

ただし、ｔは時刻である。

第２図に示したその他のタスクとして、１秒おきに起動
され、外部のコンピュータとデータの入力、出力のデー
タ交信や、それによるデータ収集を行うビルコンピュー
タ等交信、データ収集タスク３４や、そのデータを利用
して、需要の先取りを、行い、交通需要を予測し、運転
モデルを決定する交通需要予測タスク３３（１００＋ｓ
ｅｃ毎に起動）があり、また、これによって起動される
運転モデルのタスクとして各運転タスク３５がある。

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

ベースのデータとして４０で示す号機の状態、４１で示
す学習データ、４２で示すホールデータ、４３で示すビ
ルデータが用意される。ビルデータ４３は４４で示すビ
ル管理用コンピュータ（その他第１図で示した装置）等
とのデータ交信プログラムにより求められる。またこの
データ交信プログラム４４は群管理のホールデータ４２
を要求に応じてビル管理用コンピュータ等へ送信する（
相互の必要データの授受）。

また制御モデルの決定においては、ベースデータの特に
学習データ４１と、ビルデータ４３により、長期傾向シ
ミュレートプログラム５２で集中、発散の交通需要モデ
ルが予測され、各種ルールを集めたルール集合部４５を
選択・変更用プログラム４６で選択しその予測需要モデ
ルに適応する運転制御モデルの決定を行い且つパラメー
タの決定、パラメータの変更が行われる。

ルール集合部４５は、ユーザの指定による部分、エキス
パート作成の部分、自動作成部分があり、ＲＡＭ上に作
られていて追加変更が容易な構造となっている。そのル
ール情報は第１２図のようになっている。

また、長期傾向シミュレートプログラム５４はルールの
自動作成等に使用され、５３で示す近い将来のシミュレ
ート及び、予測到着時間演算のプログラムは割当の評価
演算に利用される。

また、ビルの各階床での集中、発散（この集中、発散に
ついては後に詳しく説明する。）の需要レベルが高い場
合は、上述のプログラム４８〜５１での特殊制御が使用
される。通常はモデルマツチング適応制御プログラム４
７が使用され、需要により、パラメータの選択や変更が
行われる。

本発明の特徴は、ビルデータや学習データにより、ビル
の特定の階床における集中、発散の需要予測を行い、モ
デル化し先取りした需要予測モデルに適合する制御を行
うようにしたことにある。

ここでこの集中、発散のビルモデルについて第１３図を
参照して説明する。図ではＰｌが発散階、Ｐ２が集中階
、Ｐ３が発散集中階を示している。

第１３図（ａ　）が発散モデルであり、特定の階として
ここでは基準階より、人が発散している。また、（ｂ）
が集中モデルであり、特定の階へ人が集中している。（
Ｃ）は特定階で集中と発散が成されているモデルであり
、また、これらの複合モデルが（ｄ　）に示されている
。これらは以前の交通パターンのイメージで考えると第
１４図の表に示す如くとなる。

これらの（ａ）〜（ｄ　）のモデルで、はぼすべての交
通モデルを示すことができる。この発散や、集中の需要
がひどい場合には特殊な運転が必要となる。

一般に集中モデルに対しては特定階へ直行する急行かご
オペレーションを用い、発散モデルに対しては引き戻し
と出発間隔オペレーションがよく使用されている。これ
らの特殊オペレーションを行うのが第１１図の各モデル
制御のソフトウェア４８〜５１である。

また、本発明においては、従来の交通パターンのような
マクロのく巨視的な）変化にプラスして、ミクロの（微
視的な）変化もビルデータより先取りし、これらの需要
に対応するようにする。

ここで、本発明のポイントの一つである第１１図におけ
るビルコンピュータ等との交信ルーチン４４の説明を行
う。

この交信は第１図の伝送コントローラ３を介して行う。

すなわち、上記交信ルーチン４４は外部とのデータの授
受のための機能であり、ビル管理コンピュータ１１、Ｏ
Ａコンピュータ１２に対するデータの授受、タイムレコ
ーダ１３のデータ、報知データ入力端末装置１４からの
各種報知データ及び入口カウンタデータ等の入力を行う
。ここで扱うデータの一覧表を第１５図に示す。

この交信ルーチン４４は第１６図のフローチャートの如
きであり、このルーチンがエントリされると、まず受信
バッファの内容をチェックしくＳＴ１　’）　、受信バ
ッファにデータが無ければこのルーチンを終了する。ま
た、データがあれば受信データであるか否かを判別しく
５Ｔ２）、受信データでなければ送信バッファにデータ
送信の要求のためのデータをセットしく５Ｔ３）、受信
バッファリセットポインタをインクリメントして（ＳＴ
４）受信バッファチェックのルーチンに戻る。

先のＳＴ２における受信データ判別の結果、受信データ
であると判別したときはそのデータが需要モデル利用か
否かを判別しく５Ｔ５）、否であればＳＴ６に移る。ま
た、ＳＴ５の判別の結果、利用していればＳＴ７に移り
、ここでビル情報素データを作成した後、ＳＴ６に入る
。ＳＴ６は学習データ補正の要否を判別するルーチンで
、補正要であれば学習データの補正を行い（ＳＴ８）、
ＳＲ４に入り、受信バッファリセットポインタのインク
リメントを行ってＳＴ１に戻る。ＳＴ６において補正不
要と判断したときはＳＴ４を経てＳＴ１に戻る。

第１５図に示すデータのうち、需要モデル予測に利用さ
れるものはビル情報素データ（第１７図）とされ、この
ビル情報素データを用いて需要予測が行われる。また、
学習データの補正に利用されるものはその場で利用され
る。

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

次に本発明のポイントである第１１図集中、発散の交通
需要のモデル化と先取予測のルーチン５２の説明を行う
。

このルーチンはフローチャートで示すと第１８図の如き
であり、ステップ６０においてまず前記交信ルーチンで
入力したビル情報素データを入力する。ここでそのバッ
ファは第１７図のようなフォマットとなっている。すな
わち、図示の如くレコードナンバ、情報コード、通常処
理の有無、変更、削除の有無、月、日、時間（スタート
、エンド）、何階（スタート、エンド）、最大ｎ階床ま
で（ビット対応のホールサブインデックス形式）、また
、その予測人数の各項目で形成されている。

次にステップ６１のルーチンに入り、このルーチンで、
上記データがビルデータ予定リストに変換される。これ
は、第２６図に示すフローチャートに従って行われる。

すなわち、ステップ７０によりレコードナンバーチェッ
クが成され、スタート時間がリミット値に近いものが先
に行われる。そして、前データの通常処理がオンされ、
素データレコードナンバーが第２１図に示すようなバッ
ファ中へ移動する。

このときステップ７１が実行−され、第１９図−に示さ
れているように、その情報コードに対し、リスト化変換
処理が行われ、ビルデータ予定リストに変更される。

ここで情報コードに対するリスト化変換処理とは、集中
モデル順序、発散モデル順序、第１９図中の■で示す１
番目のリストに対するＯＮ＜オン）トリガコード、ＯＦ
Ｆ　（オフ）トリガコード、第１９図中の■で示す２番
目のリストに対するＯＮトリガコード、ＯＦＦトリガコ
ード、１番目のすスト■に対するＯＮトリガタイム変化
、２番目のりスト■に対するＯＮトリガタイム変化のセ
ット等を行うことで、かかる処理を指す。ここで、トリ
ガコードとは第２３図に示すようにコードｒＯＪ〜「６
」まで用意され、この「０」〜「６」までの内容は図示
の如くである。

第１９図のビル情報コード「０」の場合を例にとうてリ
スト化変換処理を説明する。ビル情報コード「０」は会
議室の予約を示しており、この場合、フィールドＡ部に
ビルデータ予定リストの１番目のりスト■として集中モ
デルを用いるべく「１」を、また、フィールド８部に２
番目のりスト■として発散モデルを用いるべく「２」を
セットしである。従って、ビルデータ予定リストとして
は、集中モデルを用いた■のリストと、発散モデルを用
いた■のリストの計２種のリストを作成する。

１番目のりスト■に対しては第１９図のフィールドＣ部
にセットされた「１」のトリガコードを使用する。トリ
ガコードについては第２３図にその一覧を示す。２番目
のりスト■に対して第１９図のフィールドＥ部にセット
された「３」のトリガコードを使用する。これでリスト
■、■ともにビルデータ予定リストのフィールドＣ，Ｅ
、Ｇ部の内容がセットできる。またフィール１０部はイ
ニシャルクリアを行う。また、フィールドＡ部は第１７
図のフィールド０部の内容に従ってセットされる。また
、第２５図に示すごルデータ予定リストのフィールドＦ
部の内容としては、集中モデルを用いた１番目のりスト
■については１分間の集中人数、また、発散モデルを用
いた２番目のりスト■については、乗車人数となるため
、第１７図のフィールドＨ部が１００人であり、また１
０分でその会議室に集合する場合は、リスト■における
第２５図のフィールドＦ部のデータが１００／１０−１
０人／分となり、また、リスト■のワールド１部のデー
タは１００人となる。また、第２５図に示すビルデータ
予定リストのフィールドＣ部にセットするトリガ起動時
間は、第１９図のフィールドＧ、Ｈのデータを変えるこ
とにより変化させるとができる。

仮に第１７図に示すビル情報素データのフィール１０部
が「９月１０日１３：００から」とセットされ、また、
フィールリド５部がｒ９角１０日１４：００まで」とセ
ットされているとすると第２５図に示すビルデータ予定
リストは、リスト■に対してはトリガ起動時間をセット
するフィールド８部は第１９図のフィールド０部にセッ
トされたデータより「９月１０日１２　：　５０」とな
り、また、リスト■に対しては第１９図のフィールド８
部は、第１９図のフィールドＥ部にセットされたデータ
より［９月１０日１４：ＯＯＪとなる。

これで第２５図のビルデータ予定リストが作成された。

これをもとに第２６図のステップ７２を経て第２７図の
ビルデータ予定リストレコードナンババッファをセット
し、第２１図の処理中ビル素データレコードナンバ、ビ
ルデータ予定リスト、レコードナンバ、ビルデータ予定
リスト、レコードナンバ対応バッファのうち、素データ
レコードナンバ、ビルデータ予定リストの２つがセット
される。これらはごルデータ予定リストクリア時にクリ
アされる。

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

次に１１８図のルーチン６２へ入る。このルーチンの詳
細は第２８図の如く、まず、ステップ８０のビルデータ
予定リストチェックルーチンで、トリガ起動の時間をチ
ェックし、もしＯＮ（オン）となっていたならば、トリ
ガチェックルーチンは第２４図に示されており条件が成
立した場合、そのレコードナンバのエリアをＯＮする。

もし、トリガがＯＮしたらステップ８１のごルデータ実
効リスト作成ルーチンへ進む。このルーチンにより第２
９図に示すビル実働データリストが作成される。

ここで以前と変わるのは、第２９図のリストのうちフィ
ールドＢ、Ｃ，Ｄ部である。まずフィ−ルビ８部に現時
間をセットし、０部には第１９図のＯＦＦ　（オフ）ト
リガをセットする（第１９図でフィールドＤ、Ｆに関す
る部分）。第２９図のフィールド０部はクリアを行う。

また、第３０図のレコードナンバがセットされる。また
、今後のビル実働データリストチェック時、フィールド
Ｆ部が最新データに更新される。次にステップ８２のル
ーチンで第２７図よりレコードナンバがクリアされ、ま
た以前のトリガチェックルーチンがＯＦＦされ、またビ
ル素データレコードナンバもクリアされる。トリガがＯ
ＦＦのままリミットを超えた場合は、こ時点でクリアさ
れる。

次にポイント２８Ａよりステップ８３の実働データチェ
ックルーチンへ入る。ここでは、第２９図フィールドＦ
部の需要予定５が常に更新される。

本発明においては、特定の階に対し常に、一定時間の集
中人数と、平均フロア人数よりの偏差であるアンバラン
ス集中人数をサーチしている（外部入力タスクによる。

）。第２２図に会議室の需要のデータ例を示す。第２２
図においてハツチング部分の面積Ｓがアンバランス集中
人数に相当する。これらのデータにより需要予定が更新
される。

また、トリガ条件の成立チェックにも利用される。

次にもし、ここでＯＦＦトリガ条件が成立した場合、ス
テップ８４のトリガチェックのクリアと実働リスト、レ
コードナンバのクリアが行われる。

また、トリガがＯＦＦのままリミットを超えた場合も同
様である。

第１８図のステップ６２のルーチンが終ると、ステップ
６３．６４のルーチンへくる。ここでは実際のかごデー
タ等よりの集中、発散のモデルをサーチしている。これ
はあらかじめ指定された特定階に対し、同様に行われて
いる。

例えば、会議室予約のケースにおいて、人員が乗車率４
５％以下で集中階に到着し、８０％以上の乗車率で出発
し、すぐにホール呼びが発生した場合等では、ステップ
６４において第２９図と同様なフォーマットで、発散モ
デルの実データリストが新たに作成される。そして、次
にステップ６５のルーチンで、このような実データリス
トと、前の実働リストが合成され、ミクロ変化に対する
需要リストが作成される（同様なフォーマットとなる）
。

また一方、ステップ６６．６７において学習データより
、同様のフォーマットでマクロ変化需要リストが作成さ
れる。これらの需要リストの合成により、ステップ６８
において、集中発散の需要予測データが作成される（こ
れも需要リストと同様なフォーマットで高需要類に、集
中、発散とも並べられる。）。これらは第２９図のよう
なフォーマットで各集中、発散フロアに対し用意される
。

以上の合成においては、需要データの確実性の割合をも
って合成が行われている。

以上により、ビルデータ、学習データにより先取による
需要予測が行われた。その集中、発散の需要予測データ
により第１１図におけるルール集合体４５中の制御モデ
ルと需要レベルの決定が行われる（第１８図のステップ
６９）。

もし、１００人収容の会議室の予約があり、このルーチ
ンでこの予約が浮びあがったとして、これが初期状態で
５人／分の会議室集中モデルの場合、この時点ではこの
需要が通常運転の素数変化で対応できると予測された場
合は第１１図のステップ４７の制御を用い、次の時点で
１０人／分となり、通常モデルでは不可能な場合〈通常
リミットは６人／分とする）ステップ４９の集中モデル
制御で、例えばエレベータ４台中、２台を上記予約会議
室内のある階床への急行かごとして割当て。

て使用し、この１０人／分以上の輸送を行う。当然、会
議終了時も同様のアルゴリズムで発散モデルとして扱わ
れる。このように早い需要予測とモデル化で群管理性能
は飛躍的に向上する。

以上により、第１１図のステップ５２における集中、発
散の交通需要モデル予測ブロックと、会議室集中モデル
に対する制御へのフィードバックの例を説明した。

次に昼食時の制御の流れを例にとって、交通需要モデル
の予測が、制御にフィードバックされる部分を説明する
。第３１図に昼食時のモデルの変化を示した。

図に示すように、昼食時は前半は集中モデルとなり、中
間帯では発散、集中モデルとなり、後半は発散モデルと
なる。

また昼食時が近づくにしたがって、食堂階への集中が起
きてくる。すなわち、昼食時制御は学習データでトリガ
され、食堂階への一定時間集中人数により常にモニタリ
ングされる。集中需要の影響が少くない（Ａ）の時間帯
では通常コントロール（第１１図の４７）のブロックに
よりコントロールが行われ、評価パラメータは食堂階方
向へのホール呼びを優先するものに切りかえられている
。

次に時刻ｔ１で集中モデルの食堂階の集中需要の影響が
大きくなると、オペレーションが、輸送力を強化する集
中モデル制御（第１１図の４９）に切りかえられる。

ここで、群管理対象を第３２図に示されるでいるような
、Ｂ１，１．〜１７階（２Ｆ急行ゾーン）７台のシステ
ムであると仮定する。また、食堂階は８１階（地下１階
）とし、１Ｆへの需要もあると仮定する。

昼食時においてはその前半は、食堂階や、１Ｆへの集中
モード（第３１図（Ｂ）の部分）となる。

従って、この場合第３２図（ａ　）のように、降り呼び
専門の急行エレベータを、その需要レベルに応じて用意
し、食堂階方向への輸送力を高める。

次に中間帯となり、時刻ｔ２において食堂階や、１Ｆへ
の集中モードと、そこからの発散モードが重なり、発散
集中モード（第３１図（Ｃ）の部分）となる。このこと
によりオペレーションモードは第１１図に５０で示す発
散集中モデル制御となり、第３２図（Ｃ）の制御を行う
。

この場合は下降方向の集中需要交通流と共に、食堂階と
玄関１Ｆ階からの上昇方向発散需要があるため、これを
効率良く処理するように、その需要レベルに応じた台数
の輸送力強化エレベータを用意する。（例においては４
台となっている。）また、全エレベータを食堂階と玄関
階には強制的に停止させ、ピーク輸送運転を行う（発散
階対策）。

時刻ｔ３となり、発散需要が中心となると、昼食期間も
後半であり、オペレーションモードが第１１図の４８で
示す発散モデル制御に切り換えられる（第３１図（Ｄ）
の部分）。これは朝のアップビーク時発散制御に似てい
て第３２図（Ｃ）の様式となる。

上昇の発散需要に対し、需要レベルに応じた台数のピー
ク輸送号機を用意し、輸送能力をあげる。

この場合も、食堂階と玄関階には強制停止甘さ、輸送力
をあげる。発散需要が弱くなって時刻ｔ４となると、第
３１図（Ｅ）の部分となり、再び通常制御が行われる。

ただし、多少の発散需要があるために、評価パラメータ
を食堂階と１Ｆの優先を行うものとする。

以上の特殊オペレーションにおいて、学習結果等により
、需要に偏りがみられた場合は、停止階の変更や、台数
分割の方法を変更する。

これらの制御により、交通流のモデルに適合した輸送力
の強化が実現できた。

以上説明したオベーレーションモードの変化に対して、
不停止階のセット等で乗客にとまどいを起こさせないた
めに、第３３図に示すようにモード変化に対応した案内
表示を行うかごの乗込案内表示器９２を設ける、モード
変化に対応して停止階入力用の釦等の操用釦のうち使用
不可能となるものの表示を消すことのできるようにした
かご操作盤９１を設けてその表示変化を行うようにする
、主要な階にモードに応じた利用可能等の表示案内をす
る第３４図の如き、大形案内表示器９２を用意すること
などの対策を講じると良い。そして、第３１図（Ｂ）の
モードにおいて、降り呼び専用エレベータは、上昇中、
かご呼びに応答しないために、乗客の乗り込み防止を図
るべく、第３３図の如くエレベータかどの出入口の見易
い位置に設けた乗込案内表示器９０に第３６図に示すよ
うな“お乗りになれません”なる旨の表示を行う。また
かご操作盤９１の応答階床名を示す数字は全て消す。さ
らに主要な階に設けた大形案内表示器９２にも、乗車で
きない旨を表示する。また、第３１図（Ｃ）のモードに
おいては、輸送力強化エレベータは上昇時に登録できる
階を、主要な階に設けた大形案内表示器９１にて表示す
る。また。

かご操作盤９１の階床数字は、第３５図に示す如く登録
できる階床名対応の釦の数字を表示（ランプ式であれば
ランプを点灯）して案内表示する。

また、第３１図（Ｄ）のモードにおいては、上昇客専用
エレベータは主要な階に設けた大形案内表示器９２にて
上昇時の停止可能階を表示し、かご操作盤９１の階床数
字は登録できる階の釦のみ階床名の数字を表示し案内す
る。

以上により停止階を自由に設定でき、また、乗客に対す
る案内や指示も合わせて行えるために、エレベータの需
要変化に対応したよりきめ細かいコントロールが実現で
き、しかも、利用者のとまどいも生じさせることがない
など、高い輸送効率を確保できて、しかも、サービス面
で飛躍的な向上を図ることができるようになる。

以上説明したように、本装置はごルデータの収集と、学
習データやアンバランス集中人数や一定時間の集中人数
等のデータにより、交通流のマクロ変化過程に生じたミ
クロ変化を適確にとらえ交通モデルの先取りを行い、モ
デル化と、需要レベルを正確にとらえるようにし、これ
により、その需要のアンバランスがビル全体におよぼす
影響の度合いに応じて、評価テーブルの変化やオペレー
ションモードを切り換え、そのモデルに適応した群管理
制御を行い、閑散時からピーク時まで多次元に最適な制
御を行うことができるようにしたものである。そして、
閑散時には平等な待時間分布とすることができ、ピーク
時には高い輸送力を確保することが可能となる。また、
この制御方式により、アップビーク時は発散モデルとな
り、その需要レベルにより、コントロールモードが変化
するので、朝のアップビーク時間帯も、特にパターンを
持つことなく、その日々のミクロの変化に応じて最適な
コントロールを行うことができる。

特に本装置は交通流を先取し、適確にモデル化するよう
にしたことで交通流のマクロ変化上に起こるミクロ変化
も適確にとらえることができ、また、交通流のモデルは
、集中モデル、発散モデル、発散集中モデル、複合モデ
ルの４モデルに分類して、それらの需要のアンバランス
がビル全体におよぼす影響を予測し、影響が小さい場合
は、群管理評価用係数テーブルを変化させ、きめこまか
くコントロールを変えてゆき、また、影響が大きい場合
はオペレーションモードを変化させ、急行かごや、ピー
ク輸送かごなどにより、輸送力を大幅に向上させるよう
にすると共にこの場合フレキシブルに不停止階をセット
し、より輸送力を向上させるようにしたので、これによ
って一層きめのこまかいサービスが可能となるものであ
る。

このように、ビル情報の先取によるフレキシビリティで
、しかも、状況に即して最適な運行となる群管理コント
ロールが行えるようになる群管理制御装置が実現する。

尚、本発明は上記し且つ図面に示す実施例に限定するこ
となく要旨を変更しない範囲内で適宜変形して実施し得
るものである。

［発明の効果］ 以上詳述したように本発明は、ビル管理データ等のデー
タをもとにした需要の先取による需要モデルの予測から
ｆｉｌ　ｍモデルの選択を行うようにし、この選択した
制御モデルに基づいてエレベータの運行を行うとともに
需要変化を学習することでその変化に対応した最適の制
御モデルに移るようにしたので、需要に対して早い対応
が行えるようになり、需要状況に即応した最適な群管理
制御を行うことができて、サーとの飛躍的な向上を図る
ことが可能となるなどの効果が得られる。

【図面の簡単な説明】

第１図は本発明による群管理制御ｉＩｌ＠置を使用した
システムの構成図、第２図、第１１図はその装置を実現
するためのソフトウェア構成図、第３図〜第１０図及び
第１７図、第１９図〜第２１図及び第２５図、第２７図
、第２９図、第３０因はこの本発明に用いるメモリデー
タ例を示す図、第１２図〜第１５図及び第２２図、第２
３図はこの装置の作用を説明するための図であり、第１
６図、第１８図、第２４図、第２６図、第２８図は本発
明の要部詳細の作用を説明するためのフローチャート、
第３１図、第３２図は本発明を用いた制御例を説明する
ための図、第３３図、第３４図は案内のための手段の一
例を示す図、第３５図〜第３７図はその案内のための表
示例を示す図である。 １・・・群管理制御装置、２・・・エレベータ制御装置
、３・・・伝送コントローラ、４・・・エレベータ監視
モニタ、１１・・・ビル管理コンピュータ、１２・・・
ＯＡ用コンピュータ、１・・・タイムレコーダ、１４・
・・報知データ入力端末装置、９０・・・乗込案内表示
器、９１・・・かご操作盤、９２・・・大形案内表示器
。 出願人代理人　弁理士　鈴江武彦 ２さ 第２図 第５図 第６図 ｓ　９　図 にＣＴ＄ＳＥＴ　　ＣＸ、Ｙ） 第１４図 第１５図 第１６図 ＜集＋、１敗部宇予須１１ルーチンン ＜−７怨ｘｌｂ゛ｔｂｆ、　テ’−りしフート′ナンバ
゛　ハ゛ソフＴ〉１に２２図 ＠　２３図 第２４図 ＜ヒルテータ予定りスト作成ルーナシ〉第２８図 （ｂ） 第２８図 （かご゛内表示） 第３３図 （来り場の辰ホ） ９２Ｎ！８羽： ＠　３４図 第３７図

Claims (1)

【特許請求の範囲】
1. 複数のサービス階床に対して複数台のエレベータを就役
   させ、各々のエレベータの動向を把握して発生したホー
   ル呼びに対し、サービスするエレベータを選択決定して
   応答させるようにしたエレベータの群管理制御装置にお
   いて、ビルの利用状況及び予約状況等の交通需要に関連
   する情報を受ける情報授受手段と、これらの入手情報を
   もとに予測される交通需要の形態に合わせたエレベータ
   運行パターンのモデルを作成する作成手段と、各々のエ
   レベータの動向データを収集すると共にこれらデータを
   もとに交通需要の変化を知り、交通需要予測を行い、こ
   の予測に応じ前記作成手段の作成するモデルを変更する
   修正手段とを備え、予測される交通需要時に前記作成し
   たエレベータ運行パターンで群管理制御することを特徴
   とするエレベータの群管理制御装置。