(57)【要約】【課題】群管理サービス状況を自動分析し、群管理制御装置上で常時サービス良否を表示可能なエレベータ群管理システムを得る。【解決手段】複数のかご３０のサービス状態を判断するサービス状態検出手段１Ｂ１と、サービス状態からサービスレベルを判定するサービスレベル判定手段１Ｂ２と、サービス状態およびサービスレベルを記憶するサービス記憶手段１Ｂ３と、サービスレベル判定手段１Ｂ２に関連したサービスレベル警告手段１Ｂ４と、サービスレベル警告手段に関連したＣＰＵ表示装置１Ｅと、を備えている。サービス状態は、乗場呼び数、平均待ち時間、長待ち率、予報変更率および予報外れ率のうちの少なくとも１つを含み、サービス記憶手段１Ｂ３は、一定期間毎のデータおよび現在のデータを保持し、サービスレベル警告手段１Ｂ４は、サービスレベルが一定基準を超えて悪化方向に変化したときに、ＣＰＵ表示装置１Ｅに対して警告表示指令を生成する。【選択図】図１
2005263384.tif 000002
【特許請求の範囲】
【請求項１】
複数台のエレベータかごが就役するビルのエレベータ群管理システムにおいて、
前記複数台のエレベータかごのサービス状態を判断するサービス状態検出手段と、
前記サービス状態からサービスレベルを判定するサービスレベル判定手段と、
前記サービス状態および前記サービスレベルを記憶するサービス記憶手段と、
前記サービスレベル判定手段に関連したサービスレベル警告手段と、
前記サービスレベル警告手段に関連したＣＰＵ表示装置と、を備え、
前記サービス状態は、乗場呼び数、平均待ち時間、長待ち率、予報変更率および予報外れ率のうちの少なくとも１つを含み、
前記サービス記憶手段は、一定期間毎のデータおよび現在のデータを保持し、
前記サービスレベル警告手段は、前記サービスレベルが一定基準を超えて悪化方向に変化したときに、前記ＣＰＵ表示装置に対して警告表示指令を生成することを特徴とするエレベータ群管理システム。
【請求項２】
前記サービス記憶手段に関連したサービス変化検出手段と、
前記サービス変化検出手段に関連したサービス変化警告手段と、を備え、
前記サービス変化検出手段は、前記サービス記憶手段に記憶された過去のサービス状態およびサービスレベルと現在のサービス状態およびサービスレベルとを比較し、
前記サービス変化警告手段は、前記サービス変化検出手段の比較結果に基づいて、過去から現在までの前記ビルの利用状況に所定量以上の大きな変化があると判定された場合に、前記ＣＰＵ表示装置に対して警告表示指令を生成することを特徴とする請求項１に記載のエレベータ群管理システム。
【請求項３】
前記サービス状態検出手段、前記サービスレベル判定手段、前記サービス記憶手段および前記サービスレベル警告手段は、
前記ビルの全体または複数のゾーンに対して、前記ビルの特定階床毎に、全方向または方向毎に、全時間帯または特定時間帯毎に、各処理を実行することを特徴とする請求項１または請求項２に記載のエレベータ群管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数台のエレベータかごが就役するビルのエレベータ群管理システムに関し、特にエレベータかごの群管理サービス状況を分析する際に、別途装置を接続してデータ収集を行うことなく、群管理制御装置上で常時サービス良否を表示させるための技術に関するものである。
【背景技術】
【０００２】
従来のエレベータ群管理システムは、複数台のエレベータかごの運行状態を解析するために、エレベータ群管理制御装置と運行状態データ採取装置とを接続して、運行状態データを採取している（たとえば、特許文献１参照）。
このように、従来システムにおいては、運行状態データ採取装置を介して採取されたデータに基づいて運行状態を分析し、各エレベータかごのサービス状況を判断している。
【０００３】
【特許文献１】特開平４−１８２２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のエレベータ群管理システムでは、サービス状況分析のためには、まず運行状態データ採取装置を用意する必要があり、データ取得後においても、人間の判断で分析を行う必要があるので、サービス状況分析のために多大の時間および労力を要するという課題があった。
【０００５】
この発明は、上記のような課題を解決するためになされたものであり、群管理サービスに関わる情報量を軽減することにより群管理制御装置内に保持可能とし、また、サービスの良否を判定する手段と、経年変化によるビル交通流変化を判定する手段とを設けることにより、運行状態データ採取装置を別途用意することなく、瞬時にサービスレベルの悪化を判定することのできるエレベータ群管理システムを得ることを目的とする。
【課題を解決するための手段】
【０００６】
この発明によるエレベータ群管理システムは、複数台のエレベータかごが就役するビルのエレベータ群管理システムにおいて、複数台のエレベータかごのサービス状態を判断するサービス状態検出手段と、サービス状態からサービスレベルを判定するサービスレベル判定手段と、サービス状態およびサービスレベルを記憶するサービス記憶手段と、サービスレベル判定手段に関連したサービスレベル警告手段と、サービスレベル警告手段に関連したＣＰＵ表示装置と、を備え、サービス状態は、乗場呼び数、平均待ち時間、長待ち率、予報変更率および予報外れ率のうちの少なくとも１つを含み、サービス記憶手段は、一定期間毎のデータおよび現在のデータを保持し、サービスレベル警告手段は、サービスレベルが一定基準を超えて悪化方向に変化したときに、ＣＰＵ表示装置に対して警告表示指令を生成するものである。
【発明の効果】
【０００７】
この発明によれば、エレベータかごの群管理サービス状況を分析する際に、別途装置を接続してデータ収集を行うことなく、群管理制御装置上で常時サービス良否を表示させることができる。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
図１はこの発明の実施の形態１に係るエレベータ群管理システムの全体構成を概略的に示すブロック図である。
図１において、群管理制御装置１０は、各台制御装置２０を介して、複数のエレベータかご（以下、単に「かご」と記す）３０を効率的に管理制御する。
乗場呼び登録装置４０は、各かご３０が就役するビル内の各乗場に設置されており、利用者によってＵＰ釦４ＡまたはＤＮ釦４Ｂを押されたときに、群管理制御装置１０に乗場呼び情報を通知する。
【０００９】
図１に示す群管理制御装置１０は、通信インターフェイス１Ａと、サービス状態検出手段１Ｂ１と、サービスレベル判定手段１Ｂ２と、サービス記憶手段１Ｂ３と、サービスレベル警告手段１Ｂ４と、サービス変化検出手段１Ｂ５と、サービス変化警告手段１Ｂ６と、割当決定手段１Ｃと、運転制御手段１Ｄと、ＣＰＵ表示装置１Ｅと、を備えている。
【００１０】
通信インターフェイス１Ａは、各台制御装置２０との間で通信を行う。
サービス状態検出手段１Ｂ１は、各台制御装置２０からの情報に基づいて、現在のサービス状態を演算して判定する。
サービスレベル判定手段１Ｂ２は、サービス状態検出手段１Ｂ１の検出情報に基づいてサービスレベルを判定する。
サービス記憶手段１Ｂ３は、サービス状態検出手段１Ｂ１と、サービスレベル判定手段１Ｂ２と、サービス変化検出手段１Ｂ５とより判定（検出）された各情報を記憶する。
【００１１】
サービスレベル警告手段１Ｂ４は、サービスレベル判定手段１Ｂ２による判定結果をＣＰＵ表示装置１Ｅに表示させる。
サービス変化検出手段１Ｂ５は、サービス記憶手段１Ｂ３に記憶された情報に基づいてビルのサービス状態が変化したことを判定する。
サービス変化警告手段１Ｂ６は、サービス変化検出手段１Ｂ５の検出結果をＣＰＵ表示装置１Ｅに表示させる。
【００１２】
割当決定手段１Ｃは、乗場呼び登録装置４０の操作に応答した乗場呼びに対する割当かごを算出するとともに、かご３０内の操作盤（図示せず）の操作に応答したかご呼びに応じた行先階を算出する。
運転制御手段１Ｄは、割当決定手段１Ｃの演算結果に応じて、各かご３０に対して運転指令を行う。
【００１３】
ＣＰＵ表示装置１Ｅは、群管理制御装置１０内の各手段を制御するとともに、サービスレベル警告手段１Ｂ４およびサービス変化警告手段１Ｂ６の情報に基づいて、必要に応じて警告表示などを行う。
【００１４】
サービス状態検出手段１Ｂ１、サービスレベル判定手段１Ｂ２、サービス変化警告手段１Ｂ４、サービス変化検出手段１Ｂ５およびサービス変化警告手段１Ｂ６は、サービス記憶手段１Ｂ３に関連している。
また、サービス変化警告手段１Ｂ４およびサービス変化警告手段１Ｂ６は、ＣＰＵ表示装置１Ｅに関連している。
するとともに、
【００１５】
すなわち、後述するように、サービス記憶手段１Ｂ３は、一定期間毎のデータおよび現在のデータを保持するようになっている。
サービスレベル警告手段１Ｂ４は、サービスレベルが一定基準を超えて悪化方向に変化したときに、ＣＰＵ表示装置１Ｅに対して警告表示指令を生成する。
【００１６】
また、サービス変化検出手段１Ｂ５は、サービス記憶手段１Ｂ３に記憶された過去のサービス状態およびサービスレベルと現在のサービス状態およびサービスレベルとを比較してサービス変化状態を検出する。
【００１７】
サービス変化警告手段１Ｂ６は、サービス変化検出手段１Ｂ５の比較結果に基づいて、過去から現在までのビルの利用状況に所定量以上の大きな変化があると判定された場合に、ＣＰＵ表示装置１Ｅに対して警告表示指令を生成する。
【００１８】
さらに、サービス状態検出手段１Ｂ１、サービスレベル判定手段１Ｂ２、サービス記憶手段１Ｂ３、サービスレベル警告手段１Ｂ４、サービス変化検出手段１Ｂ５およびサービス変化警告手段１Ｂ６は、ビルの全体または複数のゾーンに対して、ビルの特定階床毎に、全方向または方向毎に、全時間帯または特定時間帯毎に、各処理を実行するようになっている。
【００１９】
図２および図３はサービス状態検出手段１Ｂ１の具体的な処理動作を示すフローチャートであり、図３は図２内のサービス状態演算処理ステップＳ３をさらに具体的に示している。
図２および図３の処理ルーチンは電源投入時または集計期間が１ヶ月を超えたときに実行される。また、サービス状態検出手段１Ｂ１は、設定したゾーンおよび方向に対して、時間帯毎に図２の処理ルーチンを実行する。
【００２０】
群管理制御装置１０は、ＣＰＵ表示装置１Ｅ内のメモリ情報として、あらかじめ以下の設定情報を有している。
まず、ゾーン設定情報として、以下の３つの階床範囲（Ａ１）〜（Ａ３）を有する。
（Ａ１）第０ゾーン階床範囲（全階床）、
（Ａ２）第１ゾーン階床範囲（たとえば、Ｂ２階〜１階）、
（Ａ３）第２ゾーン階床範囲（たとえば、２階〜１５階）。
【００２１】
また、時間帯設定情報として、以下の３つの時間帯（Ｂ１）〜（Ｂ４）を有する。
（Ｂ１）第０時間帯（全時間帯）、
（Ｂ２）第１時間帯（たとえば、８時〜９時）、
（Ｂ３）第２時間帯（たとえば、１２時〜１３時）、
（Ｂ４）第３時間帯（たとえば、１８時〜１９時）。
【００２２】
さらに、方向設定情報として、以下の３つの方向（Ｃ１）〜（Ｃ３）を有する。
（Ｃ１）第０方向（ＵＰおよびＤＮ方向）、
（Ｃ２）第１方向（ＵＰ方向）、
（Ｃ３）第２方向（ＤＮ方向）。
【００２３】
なお、ゾーン設定においては、あらかじめ混雑が予想される特定の１階床を指定してもよい。
また、群管理制御装置１０内のメモリ記憶容量に余裕があれば、ゾーン設定数および時間帯設定数を増やしてもよい。
さらに、オフィスビルなどのように、休日と平日とで混雑状況が異なる場合には、平日のみにおいてデータ集計してもよい。
【００２４】
サービス状態検出手段１Ｂ１は、上記のように設定されたゾーン情報、時間帯情報、方向情報毎に、サービス状態の検出を行う。
すなわち、群管理制御装置１０は、各台制御装置２０からの乗場呼び発生状況、予報変更状況、および、かご到着状況を受け取り、図２および図３の手順にしたがって、乗場呼び発生数、平均待ち時間、長待ち率、予報外れ率、予報変更率の集計を行う。
【００２５】
以下、図２および図３を参照しながら、図１に示したこの発明の実施の形態１によるサービス状態検出手段１Ｂ１の処理動作について説明する。
まず、図２において、電源投入時または集計期間が１ヶ月を超えた時点で、乗場呼び発生数、待ち時間累計、長待ち回数、予報外れ回数、予報変更回数などの各種パラメータを、初期設定して「０クリア」する（ステップＳ１）。
【００２６】
続いて、現在注目しているゾーン、時間帯、方向において、乗場呼びが発生した場合に（ステップＳ２）、サービス状態検出手段１Ｂ１は、サービス状態演算処理（ステップＳ３）（図３参照）を実行する。
【００２７】
図３において、サービス状態検出手段１Ｂ１は、まず、乗場呼びの発生時刻を取得し、待ち時間の計測を開始する（ステップＳ３１）。
続いて、予報変更の有無を判定し（ステップＳ３２）、乗場呼びに対して割当てられた割当かごが変更されていて、予報変更が有り（すなわち、Ｙｅｓ）と判定されれば、予報変更回数をインクリメント（「１」だけ増加）して（ステップＳ３２ａ）、ステップＳ３４に進む。
【００２８】
一方、ステップＳ３２において、予報変更がない（すなわち、Ｎｏ）と判定されれば、続いて、他のかごが先に到着したか否かを判定する（ステップＳ３３）。
ステップＳ３３において、乗場呼びに対する割当かご以外のかごが乗場呼び階に先に到着していて、他のかごが先に到着した（すなわち、Ｙｅｓ）と判定されれば、予報が外れたものと見なし、予報外れ回数をインクリメントして（ステップＳ３３ａ）、ステップＳ３４に進む。
【００２９】
一方、ステップＳ３３において、他のかごが先に到着していない（すなわち、Ｎｏ）と判定されれば、直ちにステップＳ３４に進む。
ステップＳ３４においては、割当かご、または、他のかごが、乗場呼び階に到着する。
こうして、乗場呼び発生階にかご３０が到着したときに、かご３０の到着時刻と乗場呼び発生時刻との時間差から、待ち時間を取得する（ステップＳ３５）。
【００３０】
続いて、前回までの待ち時間累計（前回値）に今回取得した待ち時間を加算して、最新の待ち時間累計（今回値）を更新し（ステップＳ３６）、乗場呼び発生回数をインクリメントする（ステップＳ３７）。
また、今回取得した待ち時間が６０秒以上か否かを判定して（ステップＳ３８）、待ち時間が６０秒以上である（すなわち、Ｙｅｓ）と判定されれば、長待ち発生回数をインクリメントして（ステップＳ３８ａ）、図３の処理ルーチンを終了する。
一方、ステップＳ３８において、待ち時間が６０未満である（すなわち、Ｎｏ）と判定されれば、ステップＳ３８ａを実行せずに、直ちに図３の処理ルーチンを終了する。
【００３１】
以下、図２の処理に戻り、サービス状態検出手段１Ｂ１は、以下の式（１）〜（４）により、平均待ち時間［秒］、長待ち率［％］、予報外れ率［％］、予報変更率［％］を演算する（ステップＳ１０）。
【００３２】
平均待ち時間［秒］＝待ち時間累計／乗場呼び発生数          ・・・（１）
長待ち率［％］＝１００×長待ち回数／乗場呼び発生数    ・・・（２）
予報外れ率［％］＝１００×予報外れ回数／乗場呼び発生数・・・（３）
予報変更率［％］＝１００×予報変更回数／乗場呼び発生数・・・（４）
【００３３】
次に、サービス記憶手段１Ｂ３は、当月の乗場呼び発生数とともに、式（１）〜（４）から求められた平均待ち時間、長待ち率、予報外れ率および予報変更率を保存する（ステップＳ１１）。
【００３４】
最後に、データ集計期間が所定期間（１ヶ月）を超えたか否かにより、集計が終了したか否かを判定し（ステップＳ１２）、１ヶ月の集計期間を終了した（すなわち、Ｙｅｓ）と判定されれば、初期設定ステップＳ１に戻って上記処理を繰り返す。
一方、集計期間が１ヶ月未満であって、まだ終了していない（すなわち、Ｎｏ）と判定されれば、ステップＳ２に戻って上記処理を繰り返す。
【００３５】
図４はサービスレベル判定手段１Ｂ２の処理動作を示すフローチャートであり、図４の処理ルーチンは、１日に１回起動される。
図５はサービス変化検出手段１Ｂ５の判定動作を示すフローチャートである。
図５の処理ルーチンは、１日に１回起動され、設定したゾーン・方向・時間帯毎に処理が行われる。
【００３６】
サービスレベル判定手段１Ｂ２は、サービス状態検出手段１Ｂ１により検出されたサービス状態のレベル判定を行うとともに、サービス記憶手段１Ｂ３に記憶された各種パラメータ（平均待ち時間、長待ち率、予報外れ率、予報変更率など）を読み出し、１日に１回、図４の手順にしたがって判定処理を行う。
以下、図４を参照しながら、サービスレベル判定手段１Ｂ２の具体的な判定動作について説明する。
【００３７】
図４において、まず、平均待ち時間が３０秒以上か否かを判定し（ステップＳ４１）、平均待ち時間＜３０秒（すなわち、Ｎｏ）と判定されれば、続いて、長待ち率が８％以上か否かを判定する（ステップＳ４２）。
一方、ステップＳ４１において、平均待ち時間≧３０秒（すなわち、Ｙｅｓ）と判定されれば、平均待ち時間の警告設定を行い（ステップＳ４１ａ）、ステップＳ４２に進む。
【００３８】
ステップＳ４２において、長待ち率＜８％（すなわち、Ｎｏ）と判定されれば、続いて、予報外れ率が５％以上か否かを判定する（ステップＳ４３）。
一方、ステップＳ４２において、長待ち率≧８％（すなわち、Ｙｅｓ）と判定されれば、長待ち率の警告設定を行い（ステップＳ４２ａ）、ステップＳ４３に進む。
【００３９】
ステップＳ４３において、予報外れ率＜５％（すなわち、Ｎｏ）と判定されれば、続いて、予報変更率が５％以上か否かを判定する（ステップＳ４４）。
一方、ステップＳ４３において、予報外れ率≧５％（すなわち、Ｙｅｓ）と判定されれば、予報外れ率の警告設定を行い（ステップＳ４３ａ）、ステップＳ４４に進む。
【００４０】
ステップＳ４４において、予報変更率＜５％（すなわち、Ｎｏ）と判定されれば、続いて、平均待ち時間、長待ち率、予報外れ率、予報変更率のうちの少なくとも１つの警告が設定されているか否かを判定する（ステップＳ４５）。
一方、ステップＳ４４において、予報変更率≧５％（すなわち、Ｙｅｓ）と判定されれば、予報変更率の警告設定を行い（ステップＳ４４ａ）、ステップＳ４５に進む。
【００４１】
ステップＳ４５において、平均待ち時間、長待ち率、予報外れ率、予報変更率のいずれの警告も設定されていない（すなわち、Ｎｏ）と判定されれば、その時点の設定状態を、当月の平均待ち時間、長待ち率、予報外れ率、予報変更率の各警告情報として、サービス記憶手段１Ｂ３に保存する（ステップＳ４６）。
【００４２】
一方、ステップＳ４５において、平均待ち時間、長待ち率、予報外れ率、予報変更率のいずれかの警告設定が設定されている（すなわち、Ｙｅｓ）と判定されれば、サービスレベルの警告設定を行い（ステップＳ４５ａ）、ステップＳ４６に進む。
【００４３】
最後に、サービスレベル警告手段１Ｂ４により、平均待ち時間、長待ち率、予報外れ率および予報変更率の各警告表示（図６参照）を行い（ステップＳ４７）、図４の処理ルーチンを終了する。
【００４４】
サービス変化検出手段１Ｂ５は、サービスレベル判定手段１Ｂ２からサービス記憶手段１Ｂ３に保存された月次情報に基づいて、サービスの変化状況を判定する。
すなわち、１日に１回、図５の手順にしたがって判定処理を行う。
以下、図５を参照しながら、サービス変化検出手段１Ｂ５の具体的な判定動作について説明する。
【００４５】
図５において、まず、サービス記憶手段１Ｂ３に保存された情報が１ヶ月分以内か否かにより、現時点が計測開始月か否かを判定する（ステップＳ５１）。
ステップＳ５１において、計測開始月（保存情報が１ヶ月分以内）である（すなわち、Ｙｅｓ）と判定されれば、開始月の「乗場呼び数」および「経過日数」を用いて、以下の式（５）により、「開始月の１日あたりの乗場呼び数」を算出し（ステップＳ５１ａ）、ステップＳ５６（後述する）に進む。
【００４６】
開始月１日あたりの乗場呼び数＝開始月の乗場呼び数／開始月の経過日数・・・（５）
【００４７】
一方、サービス記憶手段１Ｂ３の保存情報が１ヶ月分を超えていて、ステップＳ５１において、計測開始月でない（すなわち、Ｎｏ）と判定されれば、当月の「乗場呼び数」および「経過日数」を用いて、以下の式（６）により、「当月の１日あたりの乗場呼び数」を算出する（ステップＳ５２）。
【００４８】
当月の１日あたりの乗場呼び数＝当月の乗場呼び数／当月の経過日数・・・（６）
【００４９】
続いて、「当月の１日あたりの乗場呼び数」が、「開始月の１日あたりの乗場呼び数」の１．５倍以上であるか否かを判定し（ステップＳ５３）、「当月の１日あたりの乗場呼び数」＜「開始月の１日あたりの乗場呼び数」×１．５（すなわち、Ｙｅｓ）と判定されれば、ステップＳ５５に進む。
【００５０】
一方、ステップＳ５３において、「当月の１日あたりの乗場呼び数」＜「開始月の１日あたりの乗場呼び数」×１．５（すなわち、Ｎｏ）と判定されれば、続いて、当月にサービスレベルの警告設定がされているか否かを判定する（ステップＳ５４）。
【００５１】
ステップＳ５４において、当月にサービスレベルの警告設定がされている（すなわち、Ｙｅｓ）と判定されれば、サービス変化の警告設定を行い（ステップＳ５５）、サービス変化の警告設定を、当月の警告情報としてサービス記憶手段１Ｂ３に保存する（ステップＳ５６）。
【００５２】
一方、ステップＳ５５において、当月にサービスレベルの警告設定がされていない（すなわち、Ｎｏ）と判定されれば、直ちに警告保存処理（ステップＳ５６）に進む。
最後に、サービス変化警告手段１Ｂ６により、サービス変化警告の表示（図７参照）を行い（ステップＳ５７）、図５の処理ルーチンを終了する。
【００５３】
図６はサービスレベル警告手段１Ｂ４の判定処理（図４）に基づく警告設定の有無を表示情報として具体的に示す説明図であり、「○」印は警告設定が有りの状態を示し、「×」印は警告設定が無しの状態を示している。
図６においては、一例として、サービスレベル警告手段１Ｂ４が、前述の（Ｂ２）第１時間帯（８時〜９時）でのデータを集計した場合を示している。
【００５４】
ここでは、（ａ）ビル全体と、（ｂ）ゾーン１・ＵＰ方向（Ｂ２階，Ｂ１階，１階）と、（ｃ）ゾーン１・ＤＮ方向（Ｂ２階，Ｂ１階，１階）と、（ｄ）ゾーン２・ＵＰ方向（２階〜１５階）と、（ｅ）ゾーン２・ＤＮ方向（２階〜１５階）と、の５通りのゾーンをデータ集計対象として考慮している。
【００５５】
サービスレベル警告手段１Ｂ４は、サービスレベル判定手段１Ｂ２により取得された当月の「平均待ち時間」、「長待ち率」、「予報外れ率」、「予報変更率」の各警告情報の表示指令を、設定されたゾーン、方向、時間帯毎に行い、これに応答して、ＣＰＵ表示装置１Ｅは、警告情報を表示する。
【００５６】
図６の警告情報例において、（ａ）ビル全体としては、平均待ち時間（＝３０．５秒）が基準値（＝３０秒）を超えているので、サービスレベルの警告情報として「平均待ち時間」の警告が行われ、また、「平均待ち時間」の警告が行われることによって、「サービスレベル」の警告も行われる。
【００５７】
また、（ｂ）ゾーン１・ＵＰ方向においては、平均待ち時間＝３５．５秒（＞３０秒）、長待ち率＝１０．２％（＞８％）、予報外れ率＝１２．８％（＞５％）であり、それぞれ基準値を上回っているので、各警告表示が行われる。
【００５８】
したがって、（ｂ）ゾーン１の場合、出勤時に、玄関階から上方階への混雑があり、アップピーク時の群管理性能が悪いものと推定することができる。また、予報外れ率が高いので、なんらかの対策を行う必要があることが分かる。
なお、ここでは、計測値と基準値との比較結果により、警告設定の有無を判定したが、基準値を複数段階で設定することにより、警告方法として、警告の「有無」のみでなく、複数レベルで段階的に表示させることもできる。
【００５９】
図７はサービス変化警告手段１Ｂ６の判定処理（図５）に基づく警告設定の有無を表示情報として具体的に示す説明図であり、図６と同様に、（Ｂ２）ゾーン１・ＵＰ、８時〜９時の設定時間帯でのデータを、４月（計測開始月）から７月までの４ヶ月にわたって、各月毎に集計した場合を示している。
【００６０】
図７において、（ａ）はゾーン１・ＵＰの記憶情報を示し、各欄内の下段は、サービス変化警告手段１Ｂ６による警告の有無（「○」、「×」）を示している。
また、（ｂ）は「１日あたりの乗場呼び発生数」を示し、各欄内の中段は「１日あたりの乗場呼び発生数の増加率」、下段は、サービス変化警告手段１Ｂ６によるサービス変化警告の有無（「○」、「×」）を示している。
【００６１】
サービス変化警告手段１Ｂ６は、サービス変化検出手段１Ｂ５により取得されたサービス変化に関する警告情報の表示指令を、設定されたゾーン、方向、時間帯毎に行い、これに応答して、ＣＰＵ表示装置１Ｅは、警告情報を表示する。
【００６２】
図７（ｂ）において、１日あたりの乗場呼び発生数は、４月（計測開始月）の「５０個」に対して、７月では「８０個」となり、６０％も増加している（１．５倍以上になっている）ことが分かる。
また、「サービスレベル」の警告設定が行われていることから、「サービス変化」の警告表示が行われる。
【００６３】
すなわち、図７（ｂ）の例では、４月時期では、出勤時のアップピークが緩やか（乗場呼び＝５０個）であったものの、その後、ビル内のテナント入居率が高くなったものと思われ、７月時期には、アップピーク時の性能が劣化している（乗場呼び＝８０個、増加率＝１６０％）ことが分かる。
【００６４】
図８および図９は実際の表示例を示す説明図であり、サービスレベル警告手段１Ｂ４およびサービス変化警告手段１Ｂ６からの各指令に応じて、ＣＰＵ表示装置１Ｅに実際に表示される一例を示している。
【００６５】
図８はサービスレベル警告手段１Ｂ４の判定処理（図４）に関連したロータリースイッチ（乗場呼び登録装置４０に対応）毎の表示例を示している。
図９はサービスレベル警告手段１Ｂ４の判定処理（図４）に基づく表示例を具体的に示す説明図であり、８時〜９時の時間帯での「ゾーン１・ＵＰの警告情報」（サービスレベル、サービス変化の各警告の有無）を具体的に示している。
【００６６】
この場合、ＣＰＵ表示装置１Ｅは、たとえば、群管理制御装置１０上の基板に設置されたロータリースイッチ（図示せず）と、２つのＬＥＤ１、ＬＥＤ２（図示せず）とを有するものとする。
【００６７】
ＬＥＤ１、ＬＥＤ２は、それぞれ、数字表示用の７セグメントの表示部を有しており、ＬＥＤ１は４ビットの表示部からなり、ＬＥＤ２は２ビットの表示部からなる。
ＬＥＤ１、ＬＥＤ２は、ロータリースイッチの設定に応じて、ゾーン、方向および時間帯毎の警告情報を表示することができるようになっている。
【００６８】
また、ＬＥＤ１、ＬＥＤ２は、ロータリースイッチによって、図８のように、「Ｎ０．１」〜「Ｎｏ．１６」のモードに切替え可能であり、たとえば、「モードＮｏ．５」を設定した場合には、図９のように、「ゾーン１・ＵＰ・８時〜９時」の警告情報を表示することができる。
【００６９】
ＬＥＤ１、２上の具体的な表示方法としては、各種警告を２進数のビットに見立てて、図９のように、ＬＥＤ１については、「平均待ち時間」を１ビット目、「長待ち率」を２ビット目、「予報外れ率」を３ビット目、「予報変更率」を４ビット目とし、ＬＥＤ２については、「サービスレベル」を１ビット目、「サービス変化」を２ビット目とし、警告設定状態の表示を、１６進数のＬＥＤ表示で行うものとする。
【００７０】
図８および図９において、たとえば、８時〜９時でのゾーン１・ＵＰの平均待ち時間、長待ち率、サービスレベル、にそれぞれ警告が出ている。
したがって、図８内のロータリースイッチＮｏ．を「５」に合わせると、図９内の各ビット欄に示すように、ＬＥＤ１のビット１、２がＯＮ（ビット３、４はＯＦＦ）となり、ＬＥＤ２のビット１がＯＮ（ビット２はＯＦＦ）となるので、ＣＰＵ表示欄に示すように、ＬＥＤ１に「３」、ＬＥＤ２に「１」が表示される。
【００７１】
すなわち、平均待ち時間、長待ち率、サービスレベルにそれぞれ警告が出ている場合、ＬＥＤ１は、２進数の「００１１」となるので、１６進数の「３」となり、ＬＥＤ２は、２進数の「０００１」となるので、１６進数の「１」と表示される。
【００７２】
これにより、ＣＰＵ表示装置１Ｅを観測すれば、警告情報（警告の有無）を容易に認識することができる。
なお、ここでは、図８のように、ロータリースイッチの設定数を「１６」としたが、ロータリースイッチの設定数をさらに増やすことにより、警告の有無のみでなく、平均待ち時間などの具体的な数値を表示することもできる。
【００７３】
以上のように、群管理サービスに関わる情報（乗場呼び発生数、平均待ち時間、長待ち率、予報外れ率、予報変更率など）について、情報量を少なくすることにより、群管理制御装置１０内のメモリ（サービス記憶手段１Ｂ３）に保持することができる。
また、サービス状態の良否を判定するサービス状態検出手段１Ｂ１と、経年変化によるビル交通流変化を判定するサービス変化検出手段１Ｂ５とを設けることにより、複数のかご運行状態に関するデータ採取を、別途の装置を用意することなく瞬時に行い、コストアップを招くことなく、サービスレベルの悪化を正確に自動的に判定することができる。
【００７４】
すなわち、複数かごの群管理サービス状況を分析する際に、別途装置を接続してデータ収集を行うことなく、群管理制御装置１０上でサービスの良否を常時表示させることができる。
また、一定基準を超えてサービスが悪化している場合に警告を行うことにより、保守定期点検時などに警告設定状態を容易に確認することができ、顧客からのクレームを受ける前に未然にその対策を実行することができる。
また、ビルの利用状況変化（ビルにテナントが新たに入居するなど）が分かり、ビル竣工時に想定していた居住人口または交通流が変化した際に、サービス変化に対応するための群管理仕様変更を顧客に提案することができる。
【００７５】
なお、上記実施の形態１では、群管理制御装置１０内に、サービス変化検出手段１Ｂ５およびサービス変化警告手段１Ｂ６を設けたが、サービス状態検出手段１Ｂ１、サービスレベル判定手段１Ｂ２およびサービスレベル警告手段１Ｂ４のみを設けてもよい。この場合、サービスレベルに関して警告情報を取得することにより、同等の作用効果を奏する。
また、サービス状態を示すパラメータとして、乗場呼び数、平均待ち時間、長待ち率、予報変更率および予報外れ率を用いたが、これらのパラメータのうちの少なくとも１つを用いてもよい。この場合も、前述と同様の処理を実行することにより、対象パラメータに関する警告情報を取得することができ、同等の作用効果を奏することは言うまでもない。
【図面の簡単な説明】
【００７６】
【図１】この発明の実施の形態１に係るエレベータ群管理システムの全体構成を概略的に示すブロック図である。
【図２】この発明の実施の形態１に係るサービス状態検出手段の処理動作を示すフローチャートである。
【図３】図２内のサービス状態演算処理動作を具体的に示すフローチャートである。
【図４】この発明の実施の形態１に係るサービスレベル判定手段の処理動作を示すフローチャートである。
【図５】この発明の実施の形態１に係るサービス変化判定手段の処理動作を示すフローチャートである。
【図６】この発明の実施の形態１に係るサービスレベル警告手段の処理動作を表示情報として示す説明図である。
【図７】この発明の実施の形態１に係るサービス変化警告手段の処理動作を表示情報として示す説明図である。
【図８】この発明の実施の形態１に係るＣＰＵ表示装置による各モードの表示例を示す説明図である。
【図９】この発明の実施の形態１に係るＣＰＵ表示装置による具体的な警告情報の表示例を示す説明図である。
【符号の説明】
【００７７】
１０  群管理制御装置、１Ａ  通信インターフェイス、１Ｂ１  サービス状態検出手段、１Ｂ２  サービスレベル判定手段、１Ｂ３  サービス記憶手段、１Ｂ４  サービスレベル警告手段、１Ｂ５  サービス変化検出手段、１Ｂ６  サービス変化警告手段、１Ｃ  割当決定手段、１Ｄ  運転制御手段、１Ｅ  ＣＰＵ表示装置、２０  各台制御装置、３０  エレベータかご、４０  乗場呼び登録装置。
【図１】
2005263384.tif 000003
【図２】
2005263384.tif 000004
【図３】
2005263384.tif 000005
【図４】
2005263384.tif 000006
【図５】
2005263384.tif 000007
【図６】
2005263384.tif 000008
【図７】
2005263384.tif 000009
【図８】
2005263384.tif 000010
【図９】
2005263384.tif 000011