JP4286147B2 - エレベータの状態に基づいたメンテナンス監視 - Google Patents

Description

本発明は可変の閾値を超える顕著な事象あるいは状況の発生率に応じてメンテナンス勧告メッセージを生成することに関する。この閾値は前記発生率に従って継続的に調整される。

現在のところエレベータのメンテナンスは、前回のメンテナンスから経過した時間に応じて、あるいは前回のメンテナンス以降エレベータ、サブシステムあるいは構成部の操作された回数に応じて予定を組まれる。これは一部の装置に対して不必要なメンテナンスを施すこと、またその他の装置に対して不十分なメンテナンスを施すことにつながる。

最近の革新においては、同出願人の２００１年７月３日に出願された同時係属米国出願番号第０９／８９８，８５３号、および２００１年７月３日に出願された出願番号第０９／８９９，００７号に開示されている。この一対の出願においては、エレベータのドアの多数の事象および状況は監視され、特定の顕著な事象の発生に応じてメンテナンスメッセージがサービス要員に提供される。前記出願で開示されるシステムにおいては、例えば、顕著な事象の発生が一度だけであっても（平均値が高過ぎるなど）メンテナンスメッセージが生成し、他のケースでは、（ドアの開閉位置が狂っているなど）顕著な事象が閾値を超えた回数生じた場合のみメンテナンスメッセージが生成され、その閾値は一定である。それらのシステムは経過時間あるいは操作回数のみに基づくよりはむしろ状況に応じたメンテナンスメッセージを提供するが、メンテナンスの必要性は依然として特定のエレベータに対して適切ではない。例として、あるエレベータにおいて、エレベータの構成部に何も異常がない場合においても特定の顕著な事象あるいは状況はむしろ高い頻度で生じることが有り、実行された場合に状況を変えるサービスは存在しないが、同じ顕著な事象あるいは状況が等しいかより少ない回数生じた他のエレベータにおいて、サービスが必要な構成部の欠陥を示す場合が有り、上述のシステムにおいて両者を区別するものではない。

本発明の目的は、必要のないエレベータメンテナンスを省くこと、必要とされるレベルまでエレベータメンテナンスを向上すること、適したレベルのメンテナンスをエレベータに施すこと、環境の偏差および施されるメンテナンスの偏差によって変動する、エレベータ間のパラメータの状況における変化を考慮に入れたエレベータのメンテナンスの提供、エレベータの通常操作を乱す可能性の高いエレベータの状況にサービス要員が専念できるようにしたンテナンス勧告の提供、エレベータのメンテナンスの質の向上、およびエレベータのメンテナンスのコストの削減を含む。

本発明は、ここで「不具合」と呼ばれる顕著な事象あるいは顕著なパラメータ値の発生はエレベータの構成部あるいはサブシステムを取り換えたりメンテナンスを施したりする必要があることを必ずしも示さないという認識に基づいている。本発明はさらに、エレベータの構成部、サブシステム、あるいは調整における損傷は顕著なエレベータの事象または状況の傾向によって最もよく示されるという事実の見識に基づくものである。

本発明によれば、ここで「不具合」と呼ばれるエレベータのメンテナンスの必要性に関して顕著と見なされた事象および状況の発生は、そのような不具合の操作時における発生率の生成に活用され、またそのような不具合の閾値を生成するのに活用され、閾値は同様にメンテナンス勧告メッセージの必要性を示唆するのに活用される。本発明によれば、監視されるそれぞれの発生しうる不具合のため、有限だが可変のアルゴリズム期間が存在し、例えば、いくらかの不具合が発生する期間、操作回数が２，０００回を超える期間、または１４日経過する期間である。それぞれのアルゴリズム期間の終わりにおいては、不具合の発生率（不具合の回数と関係する構成部あるいはサブシステムの総操作回数との比）が算出され、次に確立された不具合の発生率の平均値およびアルゴリズム期間における操作回数に基づいて新しい閾値偏差が算出され、次に今算出された閾値偏差および確立された不具合の発生率の平均値に基づいて上方および下方閾値が算出される。

新しい不具合の発生率が最大の上方閾値を超えた場合、あるいは新しい不具合発生率および直前の不具合発生率が各自の上方閾値を超えた場合、内部フラグが生成される。連続する３回の発生率が対応した閾値を超えるかあるいは下回る場合、不具合の発生率の平均値は更新され、不具合の発生率の上方調整は、サービス要員が巡回した際にメンテナンスフラグが発生してからの操作回数および時間によって制限される。

本発明は、情報が要請された場合（中央エレベータ監視機関などから）またはサービス要員が巡回した際に関わってくる。いずれの場合も、メンテナンス勧告メッセージは、不具合の発生率の平均値の上方調整が行われ、それに続く下方調整が必要のないどんなパラメータに対しても、またサービス要員が最後に巡回したとき以降そのパラメータに対して内部フラグが発生され、そして不具合の発生率の平均値の下方調整がそれ以降発生しない場合に示される。

特定のメンテナンス勧告メッセージは自身に影響するパラメータ、およびその他の関連する因子、上述の一対の出願において説明された前記開示例によって決まる。

本発明のメンテナンス勧告メッセージは、情報の要請を発行するリモートメンテナンス設備により、またはメンテナンスが進行中であることを示すサービス要員によって要請されたときにおいてのみ示される。一方、本発明は従来技術で知られている方法と同様の方法でフラグおよび警報を発生させるのに用いられたり、他の目的で用いられてもよい。

メンテナンス勧告メッセージが生成される状況は従来技術のそれと大きく異なる。第一に、これらのメッセージは状況に依存したものであり、ここで不具合と呼ばれる顕著な事象あるいは状況を示すエレベータの実際のパラメータによって決まる。さらには、全ての顕著な事象あるいは状況が影響するわけではなく、本発明に従って生成したものは不具合の発生率がエレベータの最近の操作に基づいた特定のエレベータにおける特定のパラメータのための可変の、自動的に更新される閾値を超えたときにのみ、影響する。従って、エレベータ性能の低下を示す唯一の状況は、メンテナンス勧告メッセージが表示されることに帰着し、従ってメンテナンスを特定の時間における特定のエレベータに真に必要なものに限定する。

本発明におけるその他の目的、特徴および利点は、続く添付図に示される典型的な実施例の詳細な説明と照らし合わせることによってより一層明らかになる。

本発明は、上述の一対の出願において説明されたたぐいの不具合に対して働くよう用いられることが考えられる。本発明は主として、例えば上述の一対の出願に出現する５０から６０個のパラメータなど、多数のパラメータを監視するシステムにおいて用いられる。ここにおける実施例では、各々のパラメータについて、個々のパラメータに対してのみ働く不具合発生率処理ソフトウェア一式が存在する。図面で説明されるソフトウェアは従って、一つのパラメータに必要なソフトウェアであり、監視される各々のパラメータのための同等のソフトウェアを提供するために必要な回数だけ乗じられる。しかしながら、本発明は一組のソフトウェアのみが提供されたシステムにおいて用いられてもよく、各々のパラメータは一組のソフトウェアにより次々に処理され、続けて次のパラメータが順々に同じソフトウェアによって処理される。マルチパラメータソフトウェアは図面および以下の教示と照らし合わせて当業者に十分実施される範囲である。

ここで、不具合は顕著な事象であり、早過ぎるあるいは遅過ぎるないしは長過ぎる操作、また過度に不規則なパラメータ、間違った位置、などによって生じる。上述の一対の出願において、幅広い種類の例が説明されている。本実施例では、操作の回数は、監視される不具合に関連したドアの開閉した回数であり、あるいはドアに関するボタンスイッチが押された回数であり、あるいはエレベータかごの走行回数などである。

ドアの操作において、ドアが完全に開き、閉まったことが一回の操作と見なされ、ドアの操作はエレベータかごのドアおよび乗降場ドアに関する多数のパラメータに対応する。乗降場ドアについては、各々のパラメータは各々の乗降場ドアに個々に保持される。ドアの開閉ボタン、呼び出しおよび下車ボタンについては、ボタンを一度押すことがそのボタンの一度の操作となる。以後参照される因子は以下のように初期化される。

ｋ＝０
ｄ_CTR＝０
ｏ_CTR＝０
О_IFＡＣＵＭ＝０
О_UAＡＣＵＭ＝０
О_MFVＡＣＵＭ＝２０，００１
Ｔ_AP＝０
Ｔ_MFV＝０
ＬＥＡＲＮＩＮＧ ＦＬＧ＝ＳＥＴ
ＩＮＴ ＦＬＧ＝ＲＥＳＥＴ
ＵＡＲ ＦＬＧ＝ＲＥＳＥＴ
ＩＮＦО ＦＬＧ＝ＲＥＳＥＴ
ＶＩＳＩＴ ＦＬＧ＝ＲＥＳＥＴ
ＶＩＳＩＴＥＤ ＦＬＧ＝ＲＥＳＥＴ
以後図１において説明される事象はルーチンが待機状態６１０である時においてのみ有効である。図１において、このパラメータに対応する操作が起こる度に、操作事象６１１が生じ、ステップ６１２によりオペレーションカウンターｏ_CTRにインクリメントされる。パラメータ内に不具合が生じる（顕著な事象あるいは状況である不具合）度に、不具合事象６１６が生じ、この特定のパラメータのためにステップ６１７によって不具合カウンターｄ_CTRにインクリメントされる。一日の始まりには、新しい一日の事象６１８がステップ６１９に達し、アルゴリズム期間タイマーＴ_APがインクリメントされる。第一のテスト６２５は検討中のパラメータである不具合の回数ｄが２を超えたかを判断する。不具合総数は０に初期化されるため、テスト６２５は初めは否定であり、テスト６２６に達し、関連する操作回数が２，０００を超えるかを判断する。初めは、テスト６２６は否定であり、よってテスト６２７が学習プロセスが開始されてから１４日が経過したかを判断する。それはステップ６１９により一日毎にインクリメントされるアルゴリズム期間タイマーＴ_APによって示されている。初めはそうではないため、テスト６２７の否定の結果が待機状態６１０に戻り、図１における次の事象６１１、６１６、６１８が生じるまでこの状態を保ち、その後プロセスが繰り返される。ステップおよびテスト６２５〜６２７を通過したプロセスは、最終的に不具合の回数または操作の回数のいずれか、または経過時間がテスト６２５〜６２７の内の一つに肯定的な結果を引き起こすまで、次のどんな事象をも繰り返す。これらテストの内の一つの肯定的な結果はアルゴリズム期間の終結を示し、続いて様々な計算が行われる。望ましくないが、必要な場合、アルゴリズム期間はテスト６２５〜６２７の一つのみによって、あるいは他のテストのセットによって画定される。

テスト６３０に達し、学習フラグが設定されるかが判断される。初め、学習フラグは設定されるため（図２の上部の初期化された項目で示される）、テスト６３０の肯定的な結果は中継点６３２を介して学習サブルーチン６３１（図２）に達する。ステップ６３３は不具合の発生する割合ｒを、不具合の回数ｄ_CTRの対応した操作の操作ｏ_CTRに対する比として、算出する。テスト６３７は最も最近に生成された不具合の発生率が最大の上方閾値ＵＴ_MAXを超えるかを判断する。最大の上方閾値および最小の上方閾値（以降よく参照される）はエレベータの専門家によって確立され、本発明を用いたエレベータの寿命を通して変えられることはない。最も最近の不具合の発生率がそのパラメータにおいて最大の上方閾値を超えた場合、この発生率は無視され、プログラムはリターンポイント６３８を通して待機状態６１０になる。しかしながら最も最近の不具合発生率ｒが最大の上方閾値ＵＴ_MAXを超えない場合、テスト６３７の否定の結果がステップ６３９に達し、０に初期化された学習カウンターｋをインクリメントするため、通常３〜６の間の数値を取るＫ学習ステップの最初のひとつを指し示し、要求に応じてパラメータは互いに異なっても異ならなくてもよい。次にステップ６４０は現在の不具合の数を学習ステップｋのための不具合の数として保存し、またステップ６４１は現在の操作の回数を現在の学習ステップのための操作の回数として保存する。テスト６４４は学習ステップが必要な学習ステップの総数Ｋと等しいかを判断する。そうでない場合は、プロセスはステップ６４５〜６４７においてＴ_ap、ｄおよびｏカウンターを０にして、リターンポイント６３８を通って図１のメインプログラムに戻り、待機状態６１０に達し、もう一度繰り返す。ここで用いられる“リターン”は図１において中継が行われた地点に戻ることを意味する。

図２のプロセスは図１中の事象に応じて全ての学習ステップＫが達成されるまで続けられる。次に、不具合発生率の平均値Ｒが、全てのＫ学習ステップにおける保存された不具合の発生率ｄ_kの値の合計を全てのＫ学習ステップにおける保存された操作回数ｏ_kの値の合計で割られることで、ステップ６５０において生成される。ステップ６５１は学習サブルーチン６３１が終了したことを知らせる学習フラグをリセットし、ステップ６５２はアルゴリズム期間指示子ｉ（後述する）を０にリセットする。続いてテスト６５３は、パラメータのための新しく算出された不具合発生率の平均値ＲがＫ学習ステップの操作回数の平均値の逆数の１／２よりも小さいなど、ある最小値よりも値が小さいかを判断する。小さい場合、ステップ６５４においてその値に設定され、そうでない場合ステップ６５４は飛び越される。次にステップ６４５〜６４７はカウンターを０に戻し、プログラムは中継点６３８を介して図１のメインルーチンに戻り、従って待機状態６１０に戻る。完全なオーバーホールが行われない限り学習は（このパラメータに対して）エレベータの寿命を通して二度と行われない。

学習が完了すると、どの事象６１１、６１６、６１８（図１）も対応したカウンターおよびアキュムレータをインクリメントし、一連のテスト６２５〜６２７に到達して、アルゴリズム期間が完了されているかを上述した方法で判断する。そうでない場合は、プログラムは待機状態６１０に達し、次の事象６１１、６１６、６１８を待つ。

続く全てのプロセスにおいて、下付き文字ｉは連続するアルゴリズム期間を意味する。図８Ａ〜８Ｈにおいて平面に垂直な線はアルゴリズム期間を区分し、垂直な矢印は情報の要求あるいは巡回を示す。以後に説明される理由により、一つのアルゴリズム期間で回収されたデータは次のアルゴリズム期間において、前のアルゴリズム期間ｉ−１およびｉ−２の処理結果とともに処理される。現在の処理期間はｉである。

最終的に、テスト６２５〜６２７の内の一つが肯定的となり、テスト６３０に到達する。テスト６３０は本発明の関わるエレベータのその後の寿命を通して否定である。これにより中継点６５７を通してサブルーチン６５６に到達し、それぞれの対応したアルゴリズム期間の終わりで行われる一連のアルゴリズムステップを用いて顕著な事象を示す内部フラグを発生させるか否かを評価する。テスト６５８では、後述する巡回フラグを確認し、通常は設定されず、従ってテスト６５９に達してｉが０かが判断される。ｉが０である場合はアルゴリズムを通して第一のパスにおいてのみ生じる。ｉ＞０の場合、ステップ６６０は操作回数ｏ_iで割った不具合の回数ｄ_iと同じ値として期間ｉのための不具合の発生率ｒ_iを生成する。続いてステップ６６１は、現在の発生率の平均値（１）と１から現在の発生率の平均値を引いた値（２）の積（ａ）を操作回数ｏ_iで割った値（ｂ）の平方根として、偏差σ_iを生成する。次にステップ６６２はこの期間における上方閾値ＵＴ_iを、不変の最小の上方閾値ＵＴ_MIN（１）または不具合の発生率の平均値Ｒに２．３３と現在の偏差σ_iとの積を加えた値（２）のいずれかの最大値として生成する。１％の可能性でサンプル値が関心領域を越えるため、値２．３３は偏差のための定数であることが知られている。ステップ６６２の最大値を用いることにより、上方閾値が、専門家によって決められた特定のパラメータのできるだけ小さい値である最小の上方閾値を下回らないことが保証される。しかしながら、本発明はＵＴ_MINを全く考慮に入れずに用いられてもよい。ステップ６６３は不具合の発生率の平均値から、２．３３と現在の偏差との積を引いた値と同じ値として下方閾値ＬＴ_iを設定する。

後述するが、テストはここで特定の状況下でメンテナンス勧告要請を発生させるのに用いられる内部フラグを設定するか否かを判断する。テスト６６６はｉが１より大きいかを判断し、これはアルゴリズム期間ｉ−１からの情報と関わるこれらのテストに必要である。そうでない場合は、テストはリターンポイント６６７を介して図１に戻り、順に閾値を更新するサブルーチンに導く次のアルゴリズム期間を待つ。しかしｉが１より大きい場合、テスト６６９は現在の不具合発生率が最大の上方閾値を超えるかを判断し、そうであれば、ステップ６７０は内部フラグを設定する。続いて内部フラグ実行アキュムレータｏ_IFＡＣＵＭはステップ６７１において０にリセットされる。ステップ６７１において初期化された操作累積回数は、後述するように内部フラグのみに関連した方法で用いられる。一方、テスト６６９が否定である場合、テスト６７２は現在の不具合の発生率ｒ_iが現在の上方閾値ＵＴ_iを超えるかを判断する。その場合、テスト６７３は次に先行するアルゴリズム期間の不具合の発生率ｒ_i-1が前のアルゴリズム期間の上方閾値ＵＴ_i-1を超えるかを判断する。テスト６７２および６７３が共に肯定であるならば、続いてステップ６７０および６７１が上述した内部フラグを構築する。テスト６６９およびテスト６７２と６７３のいずれかが共に否定の場合、ステップ６７０および６７１は飛び越される。好ましくはないものの、ステップ６７０は前のアルゴリズム期間を考慮に入れず（テスト６７３なしで）、テスト６７２の肯定的な結果に応じて内部フラグを設定してもよい。その結果プログラムはリターンポイント６６７を介して図１に戻る。

図４のテストはアルゴリズム期間ｉ−２の情報に関わり、テスト６７７はｉが２より大きいかを判断し、そうでない場合はｉ−２を用いて更新を行うことが不可能になり、リターンポイント６９３を介してルーチンは図１に戻る。しかしｉ＞２である場合、第一ステップ６７９は、既存の不具合の発生率の平均値Ｒ（ａ）に、新しく計算された三つのアルゴリズム期間に渡る不具合の発生率の算術平均（１）と既存の不具合の発生率の平均値（２）との差の１／２（ｂ）を加えた値として、新しい不具合の発生率の平均値Ｒ_NEWを発生させる。新しく算出された不具合の発生率の平均値は、図４のステップ６７９で示されるように、現在のサイクルｉおよび先行する二つのサイクルｉ−１、ｉ−２におけるｒとｏの値の和の比である。ここで用いられ「平均」は「算術平均」を意味するのではなく、ステップ６７９由来の準積算値を意味する。一度新しい発生率が算出されると、テスト６８０は不具合の発生率の平均値の上方あるいは下方調整を制定するかを判断する。上方調整を仮定すると、一連のテスト６８３〜６８５が最後の三つのアルゴリズム期間の不具合の発生率がそれぞれ最後の三つのアルゴリズム期間に対応した上方閾値を超えるかを判断する。超える場合、不具合の発生率の平均値は、オペレーションアキュムレータО_MFVＡＣＵＭによって示された、サービス要員による査察に応じて生成された最後のメンテナンス勧告メッセージ（図６に関して後述されるメンテナンスフラグ）からの実行が２０，０００回以内である操作期間に収まり、エレベータ現場にサービス要員が巡回したときに応じて発生された最後のメンテナンス勧告メッセージから６ヶ月以内（Ｔ_MFV）である場合、すなわち、テスト６８６および６８７が肯定的な結果の場合、上方に調整されてよい。不具合の発生率が上述の時間および操作制限内で三つの連続したアルゴリズム期間（または他の全ての実施例において選択された他の期間の数）の対応した上方閾値を超える場合、テスト６８３〜６８７の肯定的な結果は新しく作られた不具合の発生率の平均値Ｒ_NEWと同じ値に不具合の発生率の平均値Ｒを設定するステップ６９０に到達する。次に不具合の発生率の平均値の上方調整を記憶しているフラグＵＡＲはステップ６９１で設定される。また、ステップ６９２は不具合の発生率の平均値の最後の上方調整以来の操作回数を記憶していたアキュムレータО_UAＡＣＵＭを０に戻す。テスト６８３〜６８７の内一つでも否定の場合、不具合の発生率の平均値は上方調整されない。しかしながら、好ましくはないが、必要ならばテスト６８６および６８７はどんな実施例においてもその一方もしくは両方が省略されてもよい。更新サブルーチンは次にリターンポイント６９３を介して図１のメインルーチンに戻る。

一方、テスト６８０が新しく発生した不具合の発生率の平均値が現在の不具合の発生率の平均値よりも小さいことを示す場合、複数のテスト６９６〜６９８が最後の三つのアルゴリズム期間の不具合の発生率が対応した期間のそれぞれの下方閾値を下回るかを判断する。下回る場合、テスト６９６〜６９８（または別の実施例で選択される多数のテスト）の肯定的な結果はステップ６９９に達し、不具合の発生率の平均値Ｒが新しく算出された不具合の発生率の平均値Ｒ_NEWと同じ値に設定される。これがより低い閾値の唯一の関数である。ステップ７００は前にステップ６７０（図３）において設定された内部フラグをリセットする。これは内部フラグの後に生じる下方調整が、内部フラグ（内部フラグの唯一の関数は図６に関してより詳しく後述する）の結果、メンテナンスフラグを無効にするからである。同様に、ステップ７０１は不具合の発生率の上方調整を記憶しているフラグＵＡＲをリセットし、よって下方調整が続いて起こらない上方調整はなく、従って図６に関して後述するようにメンテナンスフラグおよび関連した勧告の発生を無効にする。望ましくはないが、必要ならば本発明の特定の実施例においてはステップ７００および７０１は省略することができる。その後、ルーチンはリターンポイント６９３を介して図１に戻る。

図３および図４の内部フラグおよび更新ルーチンの後、一連の日常業務ステップ７０８〜７１７（図１）は現在のアルゴリズム期間を終結し、次の期間に備える。ステップ７０８は次のアルゴリズム期間を指し示すためにｉの値をインクリメントし、ステップ７０９および７１０は次のアルゴリズム期間のためにｄ_CTRおよびｏ_CTRの値をｄ_iおよびｏ_iとして保存する。続いて、ステップ７１１〜７１３は上方調整（О_UF）から、内部フラグ（О_IF）が発生してから、そして巡回に応じたメンテナンスフラグ（О_MFV）が発生してからの操作回数の値をアキュムレータにインクリメントする。巡回の結果としてメンテナンスフラグが生成されてからの時間（Ｔ_MFV）はステップ７１４において現在のアルゴリズム期間の範囲（Ｔ_AP）に加えている。次にステップ７１５〜７１７はｄおよびｏカウンターとアルゴリズム期間タイマーを０に戻す。ルーチンは続いて待機状態６１０に戻る。

図１、３および図４のルーチンは引き続き実行され、場合により不具合の発生率の上方あるいは下方調整へとつながり、順に閾値の調整（図３、ステップ６６１〜６６３）および場合によってこのパラメータのために内部フラグを設定すること（図３、ステップ６７０）につながる。閾値の上方調整あるいは内部フラグを設定することは後述するようにこのパラメータに対応したメンテナンス勧告メッセージを出す指示である図６におけるメンテナンスフラグを設定することにつながってよい。

図１を参照すると、情報要請（ＩＮＦОＲＥＱ）は現場から離れたサービス要員あるいは装置によって起こされる事象であり、エレベータの状態の情報が（電話線などを通して）中央監視ステーションに送られる。ＶＩＳＩＴ（巡回）はエレベータ現場を訪れているサービス要員によるスイッチ等の操作である。これらの事象はメンテナンスフラグを導き、それは次にメンテナンス勧告メッセージを引き起こす。情報要請の事象または巡回の事象のいずれかが上述したようなアルゴリズム期間の終結と同じような方法でステップおよびテストの実行を引き起こす。これは更新された情報を提供するということであり、メンテナンスフラグが設定されるべきか否かを判断し、これは次に情報要請が起こされた遠隔地または巡回の事象を引き起こした現場のサービス要員へのメンテナンス勧告メッセージの提供を引き起こす。情報要請が処理されると、それが受け取られたアルゴリズム期間が復旧される（ｏカウンターおよびｄカウンター内の数値は先に送られることを意味する）。これは情報要請がアルゴリズム期間の早い時期（図８Ｂ）に受け取られ、統合されたアルゴリズム期間（図８Ｃ）を要するか、あるいはアルゴリズム期間が正常に処理されるようにアルゴリズム期間内で十分に遅い時期（図８Ａ）であるかに関わらない。この復旧は二つの事柄により生じ、それは情報要請フラグがｏおよびｄのアルゴリズム期間ｉ＋１の数値をアルゴリズム期間ｉと統合される前の数値に戻すことを引き起こし、新しいアルゴリズム期間を始めるステップ７８０〜７９１を飛び越えることである。ｏカウンターの数値がｏ_iの半分の値を超えるときに情報要請が受け取られる（図８Ａ）と、アルゴリズム期間ｉ＋１は図８Ｄで示されるように復旧される。図８Ａと図８Ｂの状況の違いは、図８Ｂにおいてはアルゴリズム期間ｉのデータを元に戻す必要があるのに対し、図８Ａにおいては元に戻す必要がないことにある。巡回のケースにおいては、その巡回の処理の最後（図８Ｅ）において新しいアルゴリズム期間が開始される。情報要請および巡回の両方のケースにおいては、二つの期間のデータが統合される（図８Ｃ）ならばたった一度の処理の繰り返しが必要である（図８Ｃおよび８Ｅ）。他方では、情報要請あるいは巡回が受け入れられるアルゴリズム期間内の数値が十分に大きい場合（図８Ａ）、統合は起こらず、二回の処理の繰り返しが必要（図８Ｇおよび８Ｈ）で、第一の処理でアルゴリズム期間ｉが処理され、第二の処理でアルゴリズム期間ｉ＋１が処理される（図８Ｇ、図８Ｈにおける期間ｉとなる）。

情報要請あるいは巡回の発生はそれぞれ対応する事象７２０、７２１に帰着する。情報要請の事象は関連するステップ７２２において対応したフラグを設定する。情報要請によって中断されたどんなアルゴリズム期間も処理のあとに復旧される。これを実行するため、図５における中継点７２５を介してデータ記憶サブルーチン７２４に達する。関連するアルゴリズム期間ｉ_MEMはステップ７３０に保存され、現在のｏおよびｄの値はｏ_MEMおよびｄ_MEMとしてステップ７３１および７３２に保存される。同様に、ｏアキュムレータの記憶値Ｔ_MFC（後述する）、内部フラグおよびＵＡＲフラグはステップ７３３〜７３８に保存される。ルーチンは続いてリターンポイント７３９を介して図１に戻る。

情報要請および巡回は学習が完了するまで処理されず、このような場合、テスト７４３が待機状態６１０に戻る。

情報要請あるいは巡回は、アルゴリズム期間内のいつでも発生することができるため、これらは共に前のアルゴリズム期間が完了した直後（図８Ｂの矢印）、あるいは前のアルゴリズム期間が完了してからいくらか長い時間が経過した後（図８Ａの矢印）においても発生してもよい。テスト７４４は、オペレーションカウンターｏＣＴＲが、現在、前のアルゴリズム期間ｏｉ内の操作回数の半分の値よりも高い設定を有するかを判断する。その場合（図８Ａ）、次にこのパラメータのための現在のアルゴリズム期間は完結したアルゴリズム期間として扱われ、処理は上で説明したように中継点７４５を通してルーチン６５６および６７６（図３および４）まで進む。このような場合、アルゴリズム期間ｉに割り当てられたデータは図８Ｇのようにルーチン６５６および６７６で処理される。巡回のケースでは、アルゴリズム期間ｉ＋１に関連してその時間に回収されたデータは図８Ｅで示されるようにアルゴリズム期間ｉがインクリメントされた後に次のアルゴリズム期間内で処理される。巡回の後、データを元に戻すことなく新しいアルゴリズム期間が常に開始される。従って、図３および４内の処理が期間ｉのためのサブルーチン６５６および６７６において一旦完了すると、複数のステップ７４７〜７５３（ステップ７０８〜７１４と同じ）が実行され、次のアルゴリズム期間へと進み、続いて再度中継点７５６を介して図３および図４のサブルーチン６５６、６７６に到達し、図８Ｈの処理を実行する。一方、現在のアルゴリズムが前の期間の操作回数の半分以下である場合（図８Ｂ）、テスト７４４は否定となり（図１）、二つの期間の操作回数と二つの期間の不具合の回数は一組のステップ７５７、７５８（図１）において統合される（図８Ｃ）。アキュムレータはステップ７５７、７５８においてｏカウンターによってインクリメントされ、巡回の間にメンテナンスフラグが発生されてからの時間はステップ７６２において最後のアルゴリズム期間の継続時間によってインクリメントされる。そして次に図３および図４の内部フラグおよびサブルーチン６５６、６７６に中継点７６４を介して到達する。メンテナンスフラグ評価サブルーチン７６５には中継点７６６を介して図６において到達する。テスト７６７は図６において不具合の発生率の平均値Ｒが最後に上方調整されてから２０，０００回の操作が生じたかを判断する。そうである場合には、メンテナンスフラグはＲの上方調整に基づいて確立されない。しかしながら、２０，０００回の操作が行われていない場合、テスト７６７の肯定的な結果はテスト７６８に達し、ＵＡＲフラグが、ステップ６９１（図４）で設定され、かつ図４のステップ７０１でまだリセット（Ｒの下方調整によって）されていないか、を判断する。テスト７６８の肯定的な結果は、従って下方調整が続いて起こらない最後の巡回からの不具合の発生率の平均値の上方調整（従って閾値の調整）が最後の２０，０００回の操作内で行われたことを示す。テスト７６７および７６８が共に否定の場合、テスト７７１は内部フラグが設定されてから２０，０００回の操作が行われたかを判断し、アキュムレータО_IFＡＣＵＭは図３のステップ６７１における内部フラグの確立によりリセットされる。２０，０００回の操作が行われていない場合、テスト７７２は内部フラグが設定されているか判断する。設定されている場合、図４のステップ７００において別の方法で内部フラグはリセットされるので、内部フラグが設定されてから不具合の発生率の平均値の下方調整（従って閾値の調整）が起こらなかったことを意味する。図６において、２０，０００回の操作内で下方調整が続いて起こらない上方調整あるいは内部フラグが起こった場合、テスト７６８または７７２いずれかの肯定的な結果はステップ７７３に達し、メンテナンスフラグが生成されるべきであることを示し、上述の同時継続出願で説明された種類の対応したメンテナンスメッセージの生成を引き起こすために用いられる。次にリターンポイント７７４を介して図１に戻る。

メンテナンスフラグ評価サブルーチン７６５を通る処理が情報要請ではなく巡回の結果である場合、テスト７７７の否定的な結果はステップ７８０に達し、巡回フラグが設定される。これは図３において用いられ、巡回の後（図８Ｈ）の処理の第二パスに続く第一のアルゴリズム期間におけるいかなるアルゴリズム操作をも阻止し、次のアルゴリズムにおいてデータ回収のみが起こるようになる。図３において、テスト６５８の肯定的な結果は巡回フラグをリセットするステップ７７８に達し、データは次のアルゴリズム期間内で回収されるため、図８Ｈの期間ｉに続くアルゴリズム期間の間に回収されたデータの処理が再び処理されないように図３の残りのステップを飛び越える。

図１において、ステップ７８１はｉをインクリメントし、一連のステップ７８２〜７８４は次のアルゴリズム期間のためにｏとｄカウンターおよびアルゴリズムタイマーをリセットする。複数のステップ７８５〜７８８は累算された時間および三つオペレーションアキュムレータを０に戻す。これはこれら全てが巡回の後の操作および時間の記録を保持しているからである。次に、内部フラグあるいはＵＡＲフラグの発生は巡回後に設定されるときのみにおいて重要であるため、ステップ７８９、７９０は内部フラグおよびＵＡＲフラグをリセットする。その後ルーチンは待機状態６１０に戻り、他の操作、不具合あるいは新しい日を待つ。一方、サブルーチン７６５を通る処理が情報要請（情報フラグはステップ７２２において設定される）の結果である場合、情報要請の直前に統合されたデータ（図８Ｃ）は図８Ｄで示されるようにアルゴリズム期間ｉおよびｉ＋１のために元に戻されなければならない。テスト７７７の肯定的な結果はステップ７９７に達し、情報要請フラグをリセットする。続いてデータ摘要サブルーチン８０１は中継点８０２を介して図７に達する。

図５のステップ７３０〜７３８の全ての設定は、それぞれ対応した図７のステップ８３０〜８３８と入れ換えられ、最後のアルゴリズム期間（図８Ｄ）は元に戻される。次に、プログラムはリターンポイント８３９を介して図１に戻り、他の操作、不具合あるいは新しい日を待つ。

本発明のどんな実施においても要望に応じて、前回のサービス要員の巡回が現時点から二週間以内であったならば巡回による中断は認識されない。これは二週間の期間（時間の一つのアルゴリズム期間）において結集されうる比較的不完全なデータを用いるよりも古い完全なデータを用いる方がより良いからである。このようなケースにおいては、メンテナンスフラグは二週間保持され、この期間内における巡回に応じて用いられてもよい。望ましくはないが、どの実施例においても必要であれば、メンテナンスフラグは巡回（情報要請ではなく）のみに応じて、あるいは情報要請（巡回ではなく）のみに応じて、あるいは一つ以上のその他の特定の事象に応じて生成されてもよい。

世界のある地域では、廊下からエレベータの昇降路へのアクセスを遮断する乗降場ドアは垂直にあるいは水平にスライドするよりむしろヒンジで動き前後に開閉する（スイングドア）ところもある。これらの多数は油圧ドアクローザーを用い、時折油圧を失い、ドアが適切に閉じないことが起きる。これはドアの操作ごとにおける乗降場ドアのリバウンドの比率が高いことに起因する（前記一対の出願の図３のパラメータ第６番）。図９において、スイングドアのリバウンドの監視の簡略化した例が図解され、どのようにして閾値が変動し、メンテナンスフラグが発生されるかを示す。図９において、円（中が空であるかないかに関わらず）は不具合発生率ｒを意味し、図９において０付近から概ね１１％の間を変動し、それらの円の内、アスタリスクを中に有するものは、不具合発生率が内部フラグを発生する結果となったことを意味する。図９のこの例においては、各々のアルゴリズム期間は５００回のドアの操作を含み、ちょうど２％を超える初期の不具合発生率Ｒを伴う。図９においては、Ｘは整備士の巡回を意味し、これは二ヶ月おきに生じることが想定され、５，０００回の操作毎であると言い換えられる。周りに正方形を有するそれぞれのＸは、スイングドアのリバウンドパラメータのためにメンテナンスフラグが生成されたことを示す。上方および下方閾値はそれぞれ４％の僅かに下および１％の僅かに下において始まる点線である。

図９において、期間４６以前の全てのアルゴリズム期間についての不具合発生率は上方閾値を下回る。ここで留意すべきは下方閾値を下回る不具合発生率は不具合の発生率の平均値Ｒを調整することによって閾値を調整する場合においてのみ関連するという事実である。５０番目のアルゴリズム期間においては、４９番目および５０番目（連続している）のアルゴリズム期間が共にそれぞれの期間の現在の閾値（このケースでは同じである）を超えるため、内部フラグが発生する。サービス要員による五度目の巡回は、５０番目のアルゴリズム期間における内部フラグのため、メンテナンスフラグを発生する。５４番目のアルゴリズム期間は内部フラグの発生をもたらし、同様に５５番目のアルゴリズム期間も内部フラグを発生する。加えて、５５番目のアルゴリズム期間において、対応した上方閾値を超える三つの連続したアルゴリズム期間が存在するため、不具合の発生率の平均値Ｒはこの時点で上方調整され、５５番目のアルゴリズム期間の後の閾値が５５番目のアルゴリズム期間以前の閾値よりも大きな広がりを持つことからもわかるように、σのより大きな値の新しい上方および下方閾値となる。６度目の整備士の巡回において、５５番目のアルゴリズム期間で発生した内部フラグの影響でメンテナンスフラグが生成される。ここで５度目の巡回以降５０番目から５４番目のアルゴリズム期間の辺りにおいていくらか性能が向上しているが、その後著しく悪化していることに留意すべきである。従って整備士は５番目の巡回において問題を解決していない。一方、６度目の巡回の後においては性能が著しく向上し、サービス要員が問題を解決したことを意味する。

６５番目のアルゴリズム期間において、不具合の発生率が下方閾値を下回る連続した三つのアルゴリズム期間が連続して存在するため、閾値は下方調整される。７７番目のアルゴリズム期間において、閾値はもう一度下方調整される。１００番目のアルゴリズム期間において、閾値はもう一度下方調整される。１３１番目のアルゴリズム期間においては、上方閾値を超える二つの連続した不具合の発生率が存在するため、内部フラグが生成される。１３２番目のアルゴリズム期間においては、内部フラグが同様に生成されるが、メンテナンスフラグが生成された最後の巡回（ステップ７７３およびテスト７７２）である６度目の巡回からドアが２０，０００回以上操作されたため、閾値は上方調整されない。内部フラグは引き続き１４度目の巡回と一致する１４０番目のアルゴリズム期間を通して生成され、これによってメンテナンスフラグを発生する。１４度目の巡回以降、不具合の発生率が対応した閾値を超える連続した三つのアルゴリズム期間（１３９、１４０、１４１）が存在し、これによってアルゴリズム期間１４１において閾値の増大がもたらされる。その後間もなくアルゴリズム期間１４６において、下方閾値を下回る連続した不具合発生率が存在するため、閾値はもう一度下方調整される。図示されていないが、巡回あるいは情報要請への応答以外においてもメンテナンスフラグは当然生成される。

概して、本発明は前述の一対の出願における顕著な事象および状況に対して用いられるであろうものであるが、前述の一対の出願では、メンテナンスメッセージの発生は異常発生の回数と関連する操作回数との比によって決まり、前述の出願においては、一定の閾値が用いられている。それらのいくつかにおいては、専門家により閾値は本発明が用いられないケースにおいて特定の一定の閾値である必要があると知られている。

上述の全ての特許出願は本願の参照として援用される。

従って、本発明は典型的な実施例を用いて示され、また説明されたが、既述のおよび他の様々な変更、省略、追加は本発明の趣旨および範囲を逸脱することなく達成され得ることを当業者は理解すべきである。

本発明の機能のメインフローを示す高度な論理流れ図。 本発明の学習の機能の高度な論理流れ図。 本発明の内部フラグの評価の機能の高度な論理流れ図。 本発明の閾値の更新の機能の高度な論理流れ図。 本発明のデータ記憶の機能の高度な論理流れ図。データ記憶 本発明のメンテナンスフラグの評価の機能の高度な論理流れ図。 本発明のデータ復旧の機能の高度な論理流れ図。 共通時間基準における処理の説明図。 関係する操作の関数としての不具合のプロット図。

Claims (20)

1. エレベータの特定の対応するパラメータにそれぞれ関するひとつもしくはそれ以上の特定のメンテナンス勧告メッセージが生成されるべきときを決定する方法であって、
   （ａ） 前記パラメータに関連する状況および／または事象を監視して、エレベータメンテナンスに関して顕著であると見なされた状況または事象を判断して、それに応じて不具合の表示を生成するステップと、
   （ｂ） 一連の順次アルゴリズム期間それぞれにおいて、
   （ｉ） 生成された前記不具合の表示の数を記録し、
   （ｉｉ） 前記パラメータに関連するエレベータ要素の操作の回数を記録し、
   （ｉｉｉ） 各アルゴリズム期間における前記不具合の表示の数の、前記操作の数に対する比として、不具合発生率表示を提供するステップと、
   （ｃ） 前記各アルゴリズム期間の前のアルゴリズム期間をひとつ以上含む複数のアルゴリズム期間の間に記録された不具合の表示の数と操作の回数とから平均不具合発生率の表示を定期的に生成するステップと、
   （ｄ） 前記各アルゴリズム期間において、
   （ｉｖ） 前記平均不具合発生率の表示と前記関連する操作の回数とに応じて偏差の表示を生成し、
   （ｖ） 前記平均不具合発生率の表示と前記偏差の表示とに応じて上方閾値の表示を生成し、
   （ｖｉ） （１）アルゴリズム期間の少なくともひとつにおいて記録され、該少なくともひとつのアルゴリズム期間において生成された前記上方閾値の表示の対応するひとつを超える前記不具合の発生率表示、および（２）前記平均不具合発生率の上方修正をもたらす前記ステップ（ｃ）、の少なくともいずれか一方に応じて、前記パラメータに関してメンテナンス勧告メッセージが生成されるべきことを示すメンテナンスフラグ表示を選択的に生成するステップと、
   からなることを特徴とする方法。
2. 前記アルゴリズム期間は（ａ）前記ステップ（ｉ）で記録された所定数の不具合、（ｂ）前記ステップ（ｉｉ）で記録された所定数の操作、または（ｃ）所定の時間のうち少なくともひとつによって画定されることを特徴とする、請求項１記載の方法。
3. 前記ステップ（ｖｉ）は、選択された複数のアルゴリズム期間における前記対応する上方閾値を超える不具合の前記発生率に応じて前記メンテナンスフラグ表示を生成することを含むことを特徴とする、請求項１記載の方法。
4. 前記選択された複数のアルゴリズム期間は互いに連続していることを特徴とする、請求項３記載の方法。
5. 前記ステップ（ｖｉ）は、特定の複数のアルゴリズム期間における前記平均不具合発生率の上方修正をもたらす前記ステップ（ｃ）に応じて前記メンテナンスフラグ表示を生成することを含むことを特徴とする請求項３記載の方法。
6. 前記選択された複数のアルゴリズム期間よりも多くの前記特定の複数のアルゴリズム期間があることを特徴とする、請求項５記載の方法。
7. 前記特定の複数のアルゴリズム期間は互いに連続していることを特徴とする、請求項５の方法。
8. 前記ステップ（ｃ）は、複数のアルゴリズム期間における前記対応する上方閾値表示を超える前記不具合の発生率表示に対応して前記アルゴリズム期間のいずれかひとつにおいて前記平均不具合発生率の表示の新たな値を生成することを含むことを特徴とする、請求項１記載の方法。
9. 前記ステップ（ｖｉ）は、複数のアルゴリズム期間における前記平均不具合発生率の上方修正をもたらす前記ステップ（ｃ）に応じて前記メンテナンスフラグ表示を生成することを含むことを特徴とする請求項１記載の方法。
10. 前記ステップ（ｃ）は、
    （ｉ） 既存の平均不具合発生率の表示に
    （ｉｉ） （１）前記各アルゴリズム期間の前のアルゴリズム期間をひとつ以上含む複数のアルゴリズム期間にわたる前記不具合の表示の数の新しく算出された総和を、前記複数のアルゴリズム期間にわたる前記操作の回数の新しく算出された総和で割った値と、（２）既存の平均発生率の表示との差異の半分を足したものとして、
    前記平均不具合発生率の表示の新たな値を定期的に生成することを特徴とする請求項１記載の方法。
11. 前記平均不具合発生率の表示と前記偏差の表示とに応じて下方閾値表示を生成することをさらに含むことを特徴とする、請求項１記載の方法。
12. 前記ステップ（ｃ）は、複数のアルゴリズム期間における前記対応する下方閾値表示よりも低い前記不具合の発生率表示に応じて前記アルゴリズム期間のいずれかひとつにおいて、前記平均不具合発生率の表示の新たな値を生成することを特徴とする請求項１１記載の方法。
13. 前記平均不具合発生率は下方に修正されることを特徴とする請求項１１記載の方法。
14. 前記ステップ（ｖｉ）は、特定の事象に続いて前記メンテナンスフラグ表示を選択的に生成することを含み、
    前記特定の事象は、（ｉ）メンテナンス要員による前記エレベータの巡回または（ｉｉ）エレベータの状況についての情報がもたらされる要請の少なくともいずれか一方であることを特徴とする請求項１記載の方法。
15. 前記ステップ（ｃ）は、メンテナンス要員による前記エレベータの巡回と同時に前記メンテナンスフラグが生成されてから発生した前記操作の総数が操作の関連する閾値よりも少ない場合にのみ前記平均不具合発生率を上方修正することを特徴とする請求項１記載の方法。
16. 前記ステップ（ｃ）は、メンテナンス要員による前記エレベータの巡回と同時に前記メンテナンスフラグが生成されてからの総経過時間が時間の関連する閾値よりも短い場合にのみ前記平均不具合発生率を上方修正することを特徴とする請求項１記載の方法。
17. 前記ステップ（ｖｉ）は、アルゴリズム期間の少なくともひとつにおいて記録された前記対応する上方閾値表示を超える前記不具合の発生率表示に応じて、特定の事象に続いて前記メンテナンスフラグ表示を選択的に生成することを含み、また前記ステップ（ｃ）は、前記特定の事象の前にもその後にも前記平均不具合発生率の下方修正を行わず、
    前記特定の事象は、（ｉ）メンテナンス要員による前記エレベータの巡回または（ｉｉ）エレベータの状況についての情報がもたらされる要請の少なくともいずれか一方であることを特徴とする、請求項１記載の方法。
18. 前記ステップ（ｖｉ）は、前記平均不具合発生率の上方修正をもたらす前記ステップ（ｃ）に応じて、特定の事象に続いて前記メンテナンスフラグ表示を選択的に生成することを含み、また前記ステップ（ｃ）は、前記特定の事象の前にもその後にも前記平均不具合発生率の下方修正を行わず、
    前記特定の事象は、（ｉ）メンテナンス要員による前記エレベータの巡回または（ｉｉ）エレベータの状況についての情報がもたらされる要請の少なくともいずれか一方であることを特徴とする、請求項１記載の方法。
19. 前記ステップ（ｖｉ）は、
    アルゴリズム期間のひとつにおいて記録された前記不具合の発生率表示が前記対応する上方閾値を越えてからの前記操作の総数が操作の関連する閾値よりも小さい場合にのみ、前記アルゴリズム期間のひとつに記録された前記不具合の発生率表示に応じて特定の事象に続いて前記メンテナンスフラグ表示を選択的に生成することを含み、
    前記特定の事象は、（ｉ）メンテナンス要員による前記エレベータの巡回または（ｉｉ）エレベータの状況についての情報がもたらされる要請の少なくともいずれか一方であることを特徴とする、請求項１記載の方法。
20. 前記ステップ（ｖｉ）は、
    前記ステップ（ｃ）が前記平均不具合発生率の上方修正をもたらしてからの前記操作の総数が操作の関連する閾値よりも小さい場合にのみ、前記平均不具合発生率の上方修正をもたらす前記ステップ（ｃ）に応じて、特定の事象に続いて前記メンテナンスフラグ表示を選択的に生成することを含み、
    前記特定の事象は、（ｉ）メンテナンス要員による前記エレベータの巡回または（ｉｉ）エレベータの状況についての情報がもたらされる要請の少なくともいずれか一方であることを特徴とする、請求項１記載の方法。

Images