特許 7230974 保守管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2023-02-20

(45)【発行日】2023-03-01

(54)【発明の名称】保守管理システム

(51)【国際特許分類】

   B66B 5/00 20060101AFI20230221BHJP

   B66B 3/00 20060101ALI20230221BHJP

   B66B 5/02 20060101ALI20230221BHJP

【ＦＩ】

B66B5/00 G

B66B3/00 F

B66B5/02 X

【請求項の数】 5

(21)【出願番号】P 2021145646

(22)【出願日】2021-09-07

【審査請求日】2022-05-26

(73)【特許権者】

【識別番号】000236056

【氏名又は名称】三菱電機ビルソリューションズ株式会社

(74)【代理人】

【識別番号】110003199

【氏名又は名称】弁理士法人高田・高橋国際特許事務所

(72)【発明者】

【氏名】村田 圭三

【審査官】吉川 直也

(56)【参考文献】

【文献】特開平０５－０４３１６０（ＪＰ，Ａ）

【文献】特開２０１４－１０５０４７（ＪＰ，Ａ）

【文献】特開２０１４－１７２７０７（ＪＰ，Ａ）

【文献】特開２０２１－１１８４０１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｂ６６Ｂ ５／００ －５／０２

Ｂ６６Ｂ ３／００；１３／１４

(57)【特許請求の範囲】

【請求項1】

エレベーターの監視データに基づいて前記エレベーターを監視する監視装置と、前記監視装置とネットワークを介して接続された管理サーバと、を備える保守管理システムにおいて、
前記監視装置は、
前記監視データに前記エレベーターの故障兆候が含まれている場合、当該故障兆候に対応する通報であるトリガ通報を前記管理サーバに送信するように構成され、
前記管理サーバは、
前記トリガ通報に対応する故障兆候要因を特定するための情報を含む保守データベースが格納されたサーバメモリと、
前記サーバメモリと結合されたプロセッサと、を備え、
前記プロセッサは、前記監視装置から前記トリガ通報を受信した場合、
前記トリガ通報と前記保守データベースを用いて、前記エレベーターの乗員に対して前記故障兆候要因を確認するための確認メッセージを生成する生成処理と、
前記確認メッセージを乗員に送信する送信処理と、
前記確認メッセージに対する乗員の応答メッセージを受信する受信処理と、
前記応答メッセージに基づいて、保守員の現場への出動要否を判定する判定処理と、
を実行するように構成され、
前記判定処理において、前記プロセッサは、
前記応答メッセージを認識し、
前記応答メッセージの認識結果に基づいて、前記故障兆候要因を特定し、
前記故障兆候要因に基づいて、前記保守員の出動要否を判定する
ように構成されるエレベーターの保守管理システム。

【請求項2】

前記送信処理において、前記プロセッサは、
前記エレベーターのかご内に設置された音声通話装置へ音声による前記確認メッセージを送信する
ように構成される請求項１に記載のエレベーターの保守管理システム。

【請求項3】

前記プロセッサは、
前記判定処理において前記保守員の出動が不要と判断された場合、前記トリガ通報と前記故障兆候要因とを登録する登録処理を実行する
ように構成される請求項１又は請求項２に記載のエレベーターの保守管理システム。

【請求項4】

前記トリガ通報は、前記エレベーターの戸開閉不良の故障兆候を含む
ことを特徴とする請求項１から請求項３の何れか１項に記載のエレベーターの保守管理システム。

【請求項5】

エレベーターの監視データに基づいて前記エレベーターを監視する監視装置と、前記監視装置とネットワークを介して接続された管理サーバと、を備える保守管理システムにおいて、
前記管理サーバは、
前記エレベーターの故障兆候に対応する通報であるトリガ通報を前記監視装置から受信した場合、保守員の現場への出動を要請するように構成され、
前記監視装置は、
前記監視データに前記故障兆候が含まれている場合、前記エレベーターの乗員に対して故障兆候要因を確認するための確認メッセージを生成する処理と、
前記確認メッセージを前記エレベーターの乗員に送信する処理と、
前記確認メッセージに対する乗員の応答メッセージを受信する処理と、
前記応答メッセージに基づいて、前記保守員の現場への出動要否を判定する処理と、
前記保守員の出動が必要と判定された場合、前記トリガ通報を前記管理サーバに送信する処理と、
を実行するように構成され、
前記出動要否を判定する処理において、前記監視装置は、
前記応答メッセージを認識し、
前記応答メッセージの認識結果に基づいて、前記故障兆候要因を特定し、
前記故障兆候要因に基づいて、前記保守員の出動要否を判定する
ように構成されるエレベーターの保守管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、保守管理システムに係り、特にエレベーターの故障兆候に対して保守員の出動要否を判断する保守管理システムに関する。

【背景技術】

【0002】

特許文献１には、かご内に乗客が閉じ込められたときに乗客を救出する方法に関する技術が開示されている。この技術では、何らかの異常原因によりエレベーターのかごを非常停止させることによってかご内に乗客が閉じ込められたとき、エレベーターと通信を行う遠隔の監視センターからの指令によって乗客の救出が行われる。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００６－４４９３０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

エレベーターの監視装置は、エレベーターに故障の兆候がないかを常時監視している。エレベーターに故障の兆候が見られた場合、監視装置は、遠隔地の情報センターに対してトリガ通報と呼ばれる通報を送ることがある。トリガ通報を受けた情報センターは、保守員を現場へ出動させて故障に対して対処する。

【0005】

しかしながら、トリガ通報には、乗員によるかご扉の押さえ等、故障以外の要因が含まれている場合がある。このような場合、現場に保守員を出動させることが必ずしも最善の判断であるとはいえない。

【0006】

本開示は、エレベーターの故障兆候に対して、保守員の不必要な出動を抑制することのできる保守管理システムを提供することを目的とする。

【課題を解決するための手段】

【0007】

本開示は、エレベーターの監視データに基づいてエレベーターを監視する監視装置と、監視装置とネットワークを介して接続された管理サーバと、を備える保守管理システムに適用される。監視装置は、監視データにエレベーターの故障兆候が含まれている場合、当該故障兆候に対応する通報であるトリガ通報を管理サーバに送信するように構成される。管理サーバは、トリガ通報に対応する故障兆候要因を特定するための情報を含む保守データベースが格納されたサーバメモリと、サーバメモリと結合されたプロセッサと、を備える。プロセッサは、監視装置からトリガ通報を受信した場合、トリガ通報と保守データベースを用いて、エレベーターの乗員に対して故障兆候要因を確認するための確認メッセージを生成する生成処理と、確認メッセージを乗員に送信する送信処理と、確認メッセージに対する乗員の応答メッセージを受信する受信処理と、応答メッセージに基づいて、保守員の現場への出動要否を判定する判定処理と、を実行するように構成され、判定処理において、プロセッサは、応答メッセージを認識し、応答メッセージの認識結果に基づいて、故障兆候要因を特定し、故障兆候要因に基づいて、保守員の出動要否を判定するように構成される。

【0008】

また、本開示は、エレベーターの監視データに基づいてエレベーターを監視する監視装置と、監視装置とネットワークを介して接続された管理サーバと、を備える保守管理システムに適用される。管理サーバは、エレベーターの故障兆候に対応する通報であるトリガ通報を監視装置から受信した場合、保守員の現場への出動を要請するように構成される。監視装置は、監視データに故障兆候が含まれている場合、エレベーターの乗員に対して故障兆候要因を確認するための確認メッセージを生成する処理と、確認メッセージをエレベーターの乗員に送信する処理と、確認メッセージに対する乗員の応答メッセージを受信する処理と、応答メッセージに基づいて、保守員の現場への出動要否を判定する処理と、保守員の出動が必要と判定された場合、トリガ通報を管理サーバに送信する処理と、を実行するように構成され、出動要否を判定する処理において、監視装置は、応答メッセージを認識し、応答メッセージの認識結果に基づいて、故障兆候要因を特定し、故障兆候要因に基づいて、保守員の出動要否を判定するように構成される。

【発明の効果】

【0009】

本開示の保守管理システムによれば、エレベーターの乗員によって故障兆候要因の確認が行われる。これにより、エレベーターの故障兆候に対して、保守員の不必要な出動を抑制することが可能となる。

【図面の簡単な説明】

【0010】

【図1】保守管理システムが適用されるエレベーターの例を示す図である。

【図2】監視装置の構成の一例を説明するためのブロック図である。

【図3】管理サーバの構成の一例を示すブロック図である。

【図4】管理サーバのプロセッサがプログラムを実行することによって実現される機能を示す機能ブロック図である。

【図5】実施の形態１に係る保守管理システムが実行する監視処理の制御ルーチンを示すフローチャートである。

【図6】実施の形態１に係る保守管理システムが実行する処理の制御ルーチンを示すフローチャートである。

【図7】管理サーバのハードウェア資源の変形例を示す図である。

【図8】実施の形態２に係る保守管理システムが実行する処理の制御ルーチンを示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、図面を参照して本開示の実施の形態について説明する。ただし、以下に示す実施の形態において各要素の個数、数量、量、範囲等の数に言及した場合、特に明示した場合又は原理的に明らかにその数に特定される場合を除いて、その言及した数に、本開示に係る思想が限定されるものではない。また、以下に示す実施の形態において説明する構造等は、特に明示した場合又は明らかに原理的にそれに特定される場合を除いて、本開示に係る思想に必ずしも必須のものではない。

【0012】

実施の形態．
１．実施の形態のエレベーターの構成

【0013】

図１は、保守管理システムが適用されるエレベーターの例を示す図である。エレベーターは、かご１及びつり合いおもり２を備えている。かご１は、昇降路３を上下に移動する。つり合いおもり２は、昇降路３を上下に移動する。昇降路３は、建物に形成された上下に延びる空間である。かご１及びつり合いおもり２は、ロープ４によって昇降路３に吊り下げられる。図１では、１：１ローピング方式のエレベーター装置を一例として示している。

【0014】

ロープ４は、巻上機５に巻き掛けられている。かご１は、巻上機５によって駆動される。制御盤６は、巻上機５を制御する。即ち、かご１の移動は、制御盤６によって制御される。図１は、巻上機５及び制御盤６が昇降路３の上方の機械室７に設けられる例を示している。巻上機５及び制御盤６は、昇降路３に設けられても良い。巻上機５は、昇降路３の頂部に設けられても良いし、昇降路３のピットに設けられても良い。

【0015】

監視装置８は、制御盤６に接続されている。監視装置８は、ネットワーク９を介して外部機器と通信する。当該外部機器に、管理サーバ１０が含まれる。一例として、管理サーバ１０は、当該エレベーターを管理する遠隔の情報センターに備えられる。

【0016】

本実施の形態の保守管理システム１００は、監視装置８と、管理サーバ１０と、を含んで構成される。以下、図１も参照しながら、保守管理システム１００を構成する監視装置８、及び管理サーバ１０の構成について更に詳しく説明する。

【0017】

２．監視装置８の構成
図２は、監視装置の構成の一例を説明するためのブロック図である。監視装置８は、制御装置２０と、かご内通話装置２２と、を備える。制御装置２０は、プロセッサ２０１と、プロセッサ２０１と結合されたメモリ２０２と、を備えている。メモリ２０２には、プロセッサ２０１で実行可能な１つ又は複数のプログラム２０３とそれに関連する種々のデータ２０４とが記憶されている。プロセッサ２０１がプログラム２０３を実行することにより、プロセッサ２０１による各種処理が実現される。プログラム２０３には、例えば、後述するエレベーターの監視プログラムが含まれる。

【0018】

監視装置８は、制御盤６から送信される監視データを受信する。監視データは、例えば、エレベーターの制御対象機器の動作データ又は呼びデータである。動作データは、例えば走行状態、ドアの開閉状態、かご負荷、又はかご位置を含む。呼びデータは、例えばエレベーターの呼び登録、呼びの割り当て、又は呼びへの応答のデータを含む。取得された監視データは、メモリ２０２に格納される。

【0019】

また、監視装置８は、監視データに基づいてエレベーターの状態を総合的に監視する。典型的には、監視装置８のプロセッサ２０１は、プログラム２０３に含まれる監視プログラムを実行することにより、エレベーターの動作に故障兆候が含まれているかどうかを常時監視する。この処理は、以下「監視処理」と呼ばれる。監視処理の結果、故障兆候が含まれていた場合、プロセッサ２０１は、当該故障兆候に対応する通報をトリガ通報としてメモリ２０２に格納するとともに管理サーバ１０へと送信する。

【0020】

かご内通話装置２２は、かご１内の図示しないかご内操作盤に設置されている。かご内通話装置２２は、マイクとスピーカとを備える音声通話装置である。監視装置８のプロセッサ２０１は、プログラム２０３に含まれる通話プログラムを実行することにより、かご内通話装置２２と管理サーバ１０との間で音声通話を行う。この処理は、以下「通話処理」と呼ばれる。典型的には、通話処理では、かご内通話装置２２から入力された音声信号をネットワーク９を介して管理サーバ１０へ送信するとともに、管理サーバ１０からネットワーク９を介して受信した音声信号をかご内通話装置２２から出力する。

【0021】

４．管理サーバ１０の構成
管理サーバ１０は、監視装置８から送信される監視データに基づいて、エレベーターの保守管理を行うための装置である。図３は、管理サーバ１０の構成の一例を示すブロック図である。

【0022】

管理サーバ１０は、１つのコンピュータ、又は、通信ネットワークで接続された複数のコンピュータの集合体である。管理サーバ１０は、１つ又は複数のプロセッサ３０とプロセッサ３０に結合された１つ又は複数のサーバメモリ３２とを備えている。サーバメモリ３２には、プロセッサ３０で実行可能な１つ又は複数のプログラム３２１とそれに関連する種々のデータ３２２とが記憶されている。データ３２２は、エレベーターの故障兆候要因を特定するための保守データベース３２３を含む。換言すると、保守データベース３２３は、トリガ通報にエレベーターの故障兆候要因が対応付けられたデータベースである。

【0023】

プロセッサ３０がプログラム３２１を実行することにより、プロセッサ３０による各種処理が実現される。図４は、管理サーバ１０のプロセッサ３０がプログラムを実行することによって実現される機能を示す機能ブロック図である。図４に示すように、プロセッサ３０は、生成処理部３０２と、送信処理部３０４と、受信処理部３０６と、判定処理部３０８と、を備える。

【0024】

生成処理部３０２は、監視装置８から受信したトリガ通報及び後述する応答メッセージに基づいて、エレベーターに発生した故障兆候要因をエレベーターのかご１内の乗員に確認するための確認メッセージを生成する。この処理は、以下「生成処理」と呼ばれる。ここでの故障兆候要因は、例えば、エレベーターの戸開閉不良、ボタン不良、照明不良、等が例示される。

【0025】

戸開閉不良は、エレベーターのかご１の扉が完全に閉まらない或いは完全に開かない不良である。戸開閉不良は、機器の故障の他、異物の挟まり、荷物を運搬する乗員による扉の押さえ等によっても発生する。ボタン不良は、行先階ボタン等のボタンが押され続けた状態又は押しても反応しない状態となる不良を含む。照明不良は、かご１内の照明の電球切れ又は点滅等の不良を含む。

【0026】

保守データベース３２３には、故障兆候要因に対応する確認メッセージが記憶されている。生成処理では、生成処理部３０２は、保守データベース３２３を参照して、故障兆候要因に対応する確認メッセージを生成する。

【0027】

送信処理部３０４は、生成された確認メッセージをかご１内の乗員に送信する。この処理は、以下「送信処理」と呼ばれる。送信処理では、送信処理部３０４は、確認メッセージを監視装置８に送信する。監視装置８は、通話処理によってかご内通話装置２２から確認メッセージを出力する。

【0028】

確認メッセージを聞いた乗員がかご内通話装置２２を用いて応答メッセージを発声すると、監視装置８は、ネットワーク９を介して応答メッセージを管理サーバ１０へと送信する。受信処理部３０６は、監視装置８からネットワーク９を介して応答メッセージを受信する。この処理は、以下「受信処理」と呼ばれる。受信された応答メッセージは、生成処理及び後述する判定処理に利用される。

【0029】

判定処理部３０８は、応答メッセージに基づいて、保守員の現場への出動要否を判定する。この処理は、以下「判定処理」と呼ばれる。判定処理では、判定処理部３０８は、公知の音声認識機能によって応答メッセージの内容を認識する。ここでの音声認識機能の内容に限定はない。判定処理部３０８は、認識された応答メッセージの認識結果及びトリガ通報の内容に基づいて、具体的な故障兆候要因を特定する。そして、判定処理部３０８は、特定された故障兆候要因に基づいて、保守員の現場への出動要否を判定する。

【0030】

５．実施の形態の保守管理システムにおいて実行される具体的処理
実施の形態に係る保守管理システム１００によって実行される処理の流れについて図５及び図６を用いて説明する。

【0031】

図５は、実施の形態１に係る保守管理システムが実行する監視処理の制御ルーチンを示すフローチャートである。図５に示すルーチンは、監視装置８のプロセッサ２０１によって繰り返し実行されるルーチンである。

【0032】

図５に示すルーチンのステップＳ１００では、プロセッサ２０１は、制御盤６から送信される監視データを受信する。受信された監視データは、メモリ２０２に格納される。次のステップＳ１０２では、プロセッサ２０１は、プログラム２０３に含まれる監視プログラムを実行することにより、エレベーターの動作に故障兆候が含まれているかどうかを監視する。その結果、故障兆候が含まれていない場合、本ルーチンは終了される。一方、エレベーターの動作に故障兆候が含まれていた場合、処理はステップＳ１０４に進む。ステップＳ１０４では、プロセッサ２０１は、トリガ通報を生成し、管理サーバ１０へと送信する。

【0033】

図６は、実施の形態１に係る保守管理システムが実行する処理の制御ルーチンを示すフローチャートである。この図に示すルーチンは、管理サーバ１０のプロセッサ３０によって繰り返し実行されるルーチンである。

【0034】

ステップＳ１１２では、プロセッサ３０は、監視装置８からトリガ通報を受信したかどうかを判定する。その結果、トリガ通報を受信していない場合、本ルーチンは終了される。

【0035】

一方、ステップＳ１１２において、トリガ通報を受信した場合、処理はステップＳ１１４に進む。ステップＳ１１４では、プロセッサ３０は、かご１内の乗員に対して確認メッセージを送信する。ここでは、プロセッサ３０は、生成処理部３０２において、トリガ通報に対応する確認メッセージを生成する。例えば、トリガ通報が戸開閉不良の故障兆候を含む場合、生成処理部３０２は、先ず「こちら情報センターですが、かご内にどなたかいらっしゃいますか」等の確認メッセージを生成する。プロセッサ３０は、送信処理部３０４において、生成された確認メッセージをネットワーク９を介して監視装置８へと送信する。ステップＳ１１４の処理が完了すると、処理はステップＳ１１６に進む。

【0036】

監視装置８は、かご内通話装置２２から受信した確認メッセージを音声発信する。確認メッセージを聞いた乗員がかご内通話装置２２を用いて応答メッセージを発声すると、監視装置８は、ネットワーク９を介して応答メッセージを監視装置８へと送信する。

【0037】

ステップＳ１１６では、プロセッサ３０は、受信処理部３０６において乗員からの応答メッセージを受信したかどうかを判定する。その結果、応答メッセージを受信していない場合、ステップＳ１１６の処理が繰り返し実行される。一方、応答メッセージを受信した場合、処理はステップＳ１１８に進む。

【0038】

ステップＳ１１８では、プロセッサ３０は、判定処理部３０８において、応答メッセージを受けて故障兆候要因が特定できたかどうかを判定する。ここでは、プロセッサ３０は、音声認識機能を用いて、受信した応答メッセージの内容を認識する。そして、プロセッサ３０は、応答メッセージによって具体的な故障兆候要因が特定できたかどうかを判定する。一例では、応答メッセージが「今、荷物の搬入で扉が閉まらないように押さえています。」である場合、故障兆候要因が人的な作業によるものであると特定されて、ステップＳ１２０に進む。

【0039】

また、他の例では、応答メッセージが「エレベーターの戸開閉の状態が何かおかしいようです。」のように、応答メッセージの内容だけでは具体的な故障兆候要因を特定できない場合、ステップＳ１２２に進む。ステップＳ１２２では、プロセッサ３０は、判定処理部３０８において、確認メッセージが規定回数繰り返されたかどうかを判定する。ここでの規定回数は、故障兆候要因を特定するために送信される確認メッセージの上限回数である。ステップＳ１２２では、確認メッセージが規定回数繰り返されたと判定された場合、故障兆候要因を特定できないと判断し、ステップＳ１２４に進む。一方、確認メッセージが規定回数繰り返されていない場合、故障兆候要因を特定するための更なる確認メッセージがあると判断し、再びステップＳ１１４に進む。そして、プロセッサ３０は、ステップＳ１１６において受信した応答メッセージを受けて、生成処理部３０２において故障兆候要因を更に絞り込むための確認メッセージを生成する。一例では、生成処理部３０２は、「何か扉に挟まったりはしておりませんか」等の確認メッセージを生成する。

【0040】

その結果、ステップＳ１１６において、例えば「何か挟まっていたものがとれ、復帰したみたいです。」との応答メッセージを受信した場合、処理はステップＳ１１８に進み、故障兆候要因が既に解決した物の挟まりであったと特定される。また、他の例では、「まだ何かおかしいようです。」との応答メッセージを受信した場合、処理はステップＳ１１８に進み、故障兆候要因が機器の故障であると特定されてる。ステップＳ１１８において、応答メッセージの内容から故障兆候要因を特定できた場合、処理はステップ１２０に進み、故障兆候要因を未だ特定できない場合、処理は再びステップＳ１２２に進む。このように、ステップＳ１１８において故障兆候要因が特定されるか、或いはステップＳ１２２において確認メッセージが規定回数繰り返されるまでステップＳ１１４からステップＳ１１８、及びステップ１２２の処理が繰り返し実行される。

【0041】

ステップＳ１２０では、プロセッサ３０は、判定処理部３０８において、ステップＳ１１８にて特定された故障兆候要因に基づいて、保守員の出動の要否を判定する。例えば、ステップＳ１１８の処理において故障兆候要因が人的な作業によるものと判断された場合、判定処理部３０８は、保守員の出動が不要と判定し、ステップＳ１２６に進む。或いは、ステップＳ１１８の処理において、故障兆候要因が既に解決済みの物の挟まりであったと判断された場合、判定処理部３０８は、保守員の出動が不要と判定し、ステップＳ１２６に進む。或いは、ステップＳ１１８の処理において、故障兆候要因が機器の故障であると判断された場合、保守員の出動が必要と判定し、ステップＳ１２４に進む。

【0042】

ステップＳ１２４では、プロセッサ３０は、保守員の出動を要請する。また、ステップＳ１２４では、生成処理部３０２において、乗員に対して、保守員の出動を要請した旨のメッセージを生成する。

【0043】

ステップＳ１２６では、プロセッサ３０は、保守員の出動要請を行わず、故障兆候要因を含めた判定結果情報をサーバメモリ３２に登録する。この処理は、「登録処理」と呼ばれる。また、ステップＳ１２６では、生成処理部３０２において、乗員に対して、保守員の出動を要請しない旨のメッセージを生成する。

【0044】

このような保守管理システム１００によれば、以下のような効果が得られる。

【0045】

トリガ通報が生成される状況の中には、現地でのエレベーター機器の取り扱い不良に起因する故障兆候も多数含まれている。保守管理システム１００によれば、かご１内に居る乗員に対して具体的な故障兆候要因を確認させることにより、保守員の出動が必要な状況かどうかを判断することができる。これにより、保守員の不要な出動を減らすことができる。

【0046】

保守管理システム１００によれば、保守員の出動要請を行わなかった場合に、トリガ通報及び故障兆候要因を含めた判定結果情報が登録される。これにより、故障兆候が発生したときの詳細な状況を後に参照することができるので、故障兆候要因の解析等にこれらの情報を利用することができる。

【0047】

６．変形例
本開示の保守管理システム１００は、以下のように変形した形態を採用することができる。

【0048】

かご１内の乗員が情報センターのオペレータとの通路を希望する場合がある。そこで、かご１内のかご内操作盤には、オペレータとの直接通話時に押下するインターホンボタンが設けられていてもよい。このような場合、「インターホンボタンを押すとオペレータと通話できます」と記載されたラベルを、インターホンボタンの横に張り付けておけばよい。

【0049】

乗員の応答メッセージは、音声による入力に限らない。すなわち応答メッセージは、かご１内に設けられたタッチパネル等の表示装置から入力してもよいし、また、かご内操作盤のボタン類を利用して入力してもよい。

【0050】

トリガ通報の故障兆候要因の中には、かご１内の乗員が目視等によって確認困難な要因も存在する。そこで、保守管理システム１００は、管理サーバ１０がトリガ通報を受信した場合に、かご１内の乗員に故障兆候要因の確認メッセージを送信すべきかどうかを判定してもよい。この場合、保守管理システム１００は、例えば、乗員による確認が可能な故障兆候要因のリストを保守データベース３２３に格納しておき、当該リストを参照して、乗員への確認メッセージの送信要否を判定すればよい。

【0051】

図７は、管理サーバ１０のハードウェア資源の変形例を示す図である。図７に示す例では、管理サーバ１０は、例えばプロセッサ３０、サーバメモリ３２、及び専用ハードウェア３３を含む処理回路３４を備えている。図７は、管理サーバ１０が有する機能の一部を専用ハードウェア３３によって実現する例を示している。管理サーバ１０が有する機能の全部を専用ハードウェア３３によって実現しても良い。専用ハードウェア３３として、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ、ＦＰＧＡ、又はこれらの組み合わせを採用できる。

【0052】

実施の形態２．
２－１．エレベーターの保守管理システムの構成
実施の形態２の保守管理システムは、実施の形態１の保守管理システム１００と同様のシステム構成を有している。実施の形態２のエレベーター監視システムのシステム構成は、実施の形態１の説明を参照することとし、ここではその説明を省略する。

【0053】

２－２．実施の形態２の保守管理システムの特徴
実施の形態２の保守管理システム１００は、監視装置８が監視データに故障兆候が含まれていると判定した場合に、監視装置８がかご内の乗員に対して故障兆候要因の確認を行わせ、トリガ通報の送信要否を判定する。以下、実施の形態に係る保守管理システム１００によって実行される処理の流れについて図８のフローチャートに沿って説明する。

【0054】

図８は、実施の形態２に係る保守管理システムが実行する処理の制御ルーチンを示すフローチャートである。図８に示すルーチンは、監視装置８のプロセッサ２０１によって繰り返し実行されるルーチンである。図８のステップＳ２０２及びＳ２０４では、プロセッサ２０１は、図５に示すルーチンのステップＳ１０２及びＳ１０４と同様の処理を実行する。ステップＳ２０４において乗員による故障兆候要因の確認が必要と判定された場合、処理はステップＳ２０６に進む。

【0055】

ステップＳ２０６、Ｓ２０８、Ｓ２１０、２１２、及びＳ２１４では、プロセッサ２０１は、図６に示すルーチンのステップＳ１１４、Ｓ１１６、Ｓ１１８、Ｓ１２０及びＳ１２２において管理サーバ１０のプロセッサ３０が実行した処理と同様の処理を実行する。

【0056】

ステップＳ２１２の処理において、保守員の出動が必要と判定した場合、処理はステップＳ２１６に進み、保守員の出動が不要と判定した場合、本ルーチンは終了される。ステップＳ２１６では、プロセッサ２０１は、トリガ通報を管理サーバ１０へと送信する。トリガ通報を受信した管理サーバ１０は、保守員の出動を要請する。

【0057】

以上のような制御によれば、監視装置８において、かご１内に居る乗員に対して故障兆候要因を確認させることができる。これにより、保守員の出動が必要な状況においてトリガ通報を送信することができるので、保守員の不要な出動を減らすことができる。

【符号の説明】

【0058】

３ 昇降路、 ４ ロープ、 ５ 巻上機、 ６ 制御盤、 ７ 機械室、 ８ 監視装置、 ９ ネットワーク、 １０ 管理サーバ、 ２０ 制御装置、 ２２ かご内通話装置、 ３０ プロセッサ、 ３２ サーバメモリ、 １００ 保守管理システム、 ２０１ プロセッサ、 ２０２ メモリ、 ２０３ プログラム、 ２０４ データ、 ３０２ 生成処理部、 ３０４ 送信処理部、 ３０６ 受信処理部、 ３０８ 判定処理部、 ３２１ プログラム、 ３２２ データ、 ３２３ 保守データベース、

【要約】

【課題】エレベーターの故障兆候に対して、保守員の不必要な出動を抑制することのできる保守管理システムを提供する。
【解決手段】保守管理システムは、監視データに基づいてエレベーターを監視する監視装置と、監視装置とネットワークを介して接続された管理サーバと、を備える。監視装置は、監視データにエレベーターの故障兆候が含まれている場合、トリガ通報を管理サーバに送信する。管理サーバのプロセッサは、監視装置からトリガ通報を受信した場合、トリガ通報と保守データベースを用いて、エレベーターの乗員に対して故障兆候要因を確認するための確認メッセージを生成する生成処理と、確認メッセージを乗員に送信する送信処理と、確認メッセージに対する乗員の応答メッセージを受信する受信処理と、応答メッセージに基づいて、保守員の現場への出動要否を判定する判定処理と、を実行する。
【選択図】図６

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】