以下、本発明に係る昇降装置の保守システム(以下、単に保守システムという)について説明する。保守システムは、昇降装置に異常等が発生した場合にこの昇降装置を保守するためのシステムである。昇降装置の保守は、例えば、技術員携帯端末(以下、単に携帯端末という)を所持する技術員により行われる。この保守システムでは、保守の必要性及び必要性のランクが決定されると共に出力されるため、技術員は、この出力結果により保守の要否を把握することができる。
尚、昇降装置にはエレベータ、エスカレータ等があるが、以下では、エレベータの保守システムを説明する。また、エレベータの保守は、例えば、ガイドレールの点検やかごドアの整備等の保守対応と、かごドアの修理等の故障対応とを含む。
保守システムは、図1に示すように、エレベータ2と、判断部3とを備える。判断部3は、決定部30を有する第一サーバー31と、データベース32を有する第二サーバー33と、出力部34を有する携帯端末35とを含む。本実施形態の保守システム1は、エレベータ2と判断部3との間に接続された遠隔監視ユニット4を備える。尚、図1では一台のエレベータ2が示されているが、本実施形態の保守システム1に備えられるエレベータは、複数台存在する。また、図1では一台の携帯端末35が示されているが、本実施形態の保守システム1に備えられる携帯端末は、複数台存在する。
エレベータ2は、昇降路を昇降するかご等を有する動作部20、及び、イベントコードとエレベータ2の動作についての状況情報とを出力可能な情報出力部21等を有する。エレベータ2は、第一サーバー31に通信系統R1を介して接続されている。通信系統R1は、例えば、エレベータ2から順に遠隔監視ユニット4と電話回線とを介して第一サーバー31に通信可能であり、且つ、第一サーバー31から逆に電話回線と遠隔監視ユニット4とを介してエレベータ2に通信可能な通信系統である。本実施形態の保守システム1では、エレベータ2は、携帯端末35に通信系統R2を介して通信可能である。通信系統R2は、例えば、有線回線である。
本実施形態の保守システム1では、情報出力部21は、イベントコードを出力すると共に状況情報としてログデータを出力する制御マイコン22と、かご内を撮影すると共に状況情報としてかご内の撮影画像を出力するカメラ等の撮影機(撮像装置)23とを含む。また、情報出力部21は、出力したイベントコードの履歴を記憶している。
制御マイコン22から出力されるイベントコードは、エレベータ2自身の動作状況に対応づけられたコードである。具体的に、イベントコードは、かごの位置情報、かごドアの開閉情報、モーターの駆動情報、及び停電等を示す。尚、イベントコードは、イベントコードの発生日時についての情報を含む。
本実施形態の保守システム1では、制御マイコン22からイベントコードが出力される際に、荷重情報、かごの速度情報、制御段階情報、及び、運転モード情報のような付加情報が同時に出力される。そのため、情報出力部21は、出力したイベントコードの履歴と共に、出力した付加情報の履歴も記憶している。
付加情報の一つである運転モード情報は、例えば、エレベータ2が点検作業中であること等を示す。尚、広義のイベントコードは、イベントコード自身に加えて、これらの付加情報も含む。以上により、広義のイベントコードは、点検作業又は停電が要因で発生したイベントコードを含むといえる。
制御マイコン22から出力されるログデータは、例えば、かごの走行特性である。具体的に、このログデータは、かごを移動させるモーターに対する速度指令、モーターの速度帰還、モーターのトルク指令、及び、その他の入出力情報等を示す。
撮影機23から出力される撮影画像は、上述のようにかご内の撮影画像である。そのため、判断部3は、撮影画像によりかご内が無人であると判断できる場合には、イベントコードの発生原因となった事象が人為的なもので無いと判断することができる。
携帯端末35は、例えば、PDA(Personal Digital Assistant)、ノートパソコン等の持ち運び可能な端末である。携帯端末35は、エレベータ2の保守を担当する技術員により所持される。また、携帯端末35は、通信系統R3を介して、第一サーバー31に通信可能である。通信系統R3は、携帯端末35からインターネットを介して第一サーバー31に通信可能であり且つ第一サーバー31からインターネットを介して携帯端末35に通信可能な通信系統である。
本実施形態の保守システム1では、携帯端末35は、技術員の操作により、制御マイコン22からイベントコードを取得する。尚、携帯端末35は、技術員の操作のタイミング(即ち、任意のタイミング)以外に、一定期間毎に、制御マイコン22からイベントコードを取得してもよい。本実施形態の保守システム1では、携帯端末35は、イベントコードとして、制御マイコン22に記憶されているイベントコードの履歴を取得する。携帯端末35は、制御マイコン22から取得したイベントコードとして、イベントコードの履歴を第一サーバー31に出力する。
携帯端末35の出力部34は、携帯端末35に入力された情報を出力する。出力部34は、出力する情報が画像情報や文字情報である場合にはディスプレイであり、出力する情報が音声情報である場合にはスピーカーである。
第二サーバー33は、データベース32を記憶している。また、第二サーバー33は、例えば、有線回線により、第一サーバー31に接続されている。
データベース32は、情報出力部21(例えば、制御マイコン22)から出力されるイベントコードと対応した基準イベントコードと、情報出力部21(例えば、制御マイコン22及び撮影機23)から出力される状況情報と対応した基準状況情報と、基準イベントコードと基準状況情報との組み合わせ毎に設定され且つ保守の必要性を示すランクとを有する。基準イベントコード(本実施形態では、基準イベントコード及び基準付加情報)は、情報出力部21から出力されるイベントコード(本実施形態では、イベントコード及び付加情報)のうち、保守作業がイベントコード(本実施形態では、イベントコード及び付加情報)に対して一義的に定まるものである。基準状況情報は、情報出力部21から出力される状況情報のうち、イベントコードとの組み合わせにより保守の必要性を示すランクの判断基準となるものである。
データベース32は、例えば、具体的に、基準イベントコードと基準状況情報との組み合わせ毎に設定され且つ保守の必要性を示すランクに関する情報を有するテーブル1と、前回のランク決定日時、及び、前回のランク通知日時に関する情報を有するテーブル2と、イベントコードの組み合わせに関する情報を有するテーブル3と、各基準イベントコードに対応する資料に関する情報を示すテーブル4と、各エレベータに対応する通知先に関する情報を示すテーブル5とを含む。本実施形態の保守システム1では、データベース32は、各種テーブルに加えて、指示文及び資料(技術情報)も含む。
具体的に、テーブル1は、図2に示すように、基準イベントコード、基準付加情報、一日当たりのイベントコードの発生頻度の下限値、一週間当たりのイベントコード発生頻度の下限値、基準状況情報(例えば、画像の要否、及び、ログデータの要否)、指示文番号(指示文の番号)、及び、ランク(保守の必要性のランク)についてのデータをそれぞれ有する。
本実施形態の保守システム1では、保守の必要性のランクは、A、B、C、Dの四段階に分かれている。Aランクは、緊急性が高く、且つ、即時の保守作業が必要であることを示す。Aランクに相当する事象としては、ブレーキの不調等がある。Bランクは、緊急性が低く、且つ、数日以内若しくは数カ月以内に保守作業が必要であることを示す。Bランクに相当する事象としては、撮影機23の異常等がある。Cランクは、緊急性がさらに低く、且つ、一年以内に保守作業が必要であることを示す。Cランクに相当する事象としては、例えば、荷重検出器のずれ等がある。Dランクは、保守作業が必要無いことを示す。Dランクに相当する事象としては、かご内での利用者の飛び跳ねによる異常等がある。保守の必要性のランクは、イベントコードの発生頻度の下限値(基準発生回数)に応じて設定されている。
具体的に、テーブル1は、発生頻度が異なる同一の基準イベントコードと基準付加情報との組み合わせに対して、異なるランクについてのデータを含んでいる。例えば、基準イベントコードが02であり且つ基準付加情報がE2である場合、発生頻度が低い場合はDランクとなり、発生頻度が高い場合Aランクとなっている。
本実施形態の保守システム1では、イベントコードの発生頻度の下限値(基準発生回数)は、基準イベントコード及び基準付加情報毎に設定されている。発生頻度の下限値は、一定の期間(イベントコードの発生の当日、又は、イベントコード発生日までの一週間)において、基準イベントコードに対応するイベントコードの発生回数がこの下限値以下であれば、このイベントコードの発生に対して保守が必要無いことを示す。
画像の要否の項目に1が入っている場合、保守のランクの判断の際に撮影機23から出力されるかご内の撮影画像の確認が必要であり、画像の要否の項目に0が入っている場合、保守の必要性のランクを判断する際にこのかご内の撮影画像の確認が必要ない。ログデータ確認の要否の項目に1が入っている場合、保守のランクの判断の際に制御マイコン22から出力されるログデータの確認が必要であり、ログデータの要否の項目に0が入っている場合、保守の必要性のランクを判断する際にこのログデータの確認が必要ない。
画像の確認及びログデータの確認の両方が必要な事象としては、例えば、かごの振動がある。画像の確認が必要な事象としては、例えば、かご揺らしの有無がある。ログデータの確認が必要な事象としては、例えば、かごの走行速度異常がある。画像の確認及びログデータの確認がいずれも必要無い事象としては、例えば、ブレーキの異常がある。
本実施形態の保守システム1では、指示文を示すデータ(保守内容を示すデータ)は、基準イベントコード毎に設定されている。指示文は、エレベータ2の保守についての指示文である。指示文には、基準イベントコードと基準付加情報との組み合わせに対応した保守についての指示が記載されている。例えば、指示文には、「ブレーキを確認する」との指示や「プリント基板を確認する」との指示が記載されている。指示文の番号は、指示文のうちどの箇所を参照するべきかを示している。
テーブル2は、エレベータ2に固有の情報であるエレベータ識別番号(機番)、イベントコード、付加情報、前回決定日時(前回のランク決定日時)、前回通知日時(前回のランク通知日時、即ち、前回、第一サーバー31が携帯端末35にランクを通知した日時)、及び、前回ランク(前回通知したランク、前回のランク)についてのデータをそれぞれ含む。
テーブル3は、図3に示すように、基準イベントコード、基準付加情報、組み合わせイベントコード、対象期間(組み合わせイベントコードの対象期間)、及び保守対象(保守対象に当てはまるか否か)についてのデータをそれぞれ含む。組み合わせイベントコードは、基準イベントコードと基準付加情報との組み合わせにあわせて、発生し得る組み合わせイベントコードを示す。基準イベントコード及び基準付加情報の組み合わせ毎に対応する組み合わせイベントコードは、一つであってもよいし、複数であってもよい。対象期間の項目に1が入っている場合、対象期間は、基準イベントコードの発生の当日である。対象期間の項目に7が入っている場合、対象期間は、基準イベントコードの発生から一週間以内である。尚、ここでは、対象期間を日単位の期間としているが、対象期間を時間単位、分単位等の期間としてもよい。テーブル3に組み合わせイベントコードがあるか否かの判断は、例えば、組み合わせイベントコードの対象期間内に、組み合わせイベントコードと同じイベントコードが発生しているか否かを確認することにより行われる。
保守対象の項目は、イベントコードが発生したエレベータ2が保守対象であるか否かを示している。具体的に、保守対象の項目に1が入っている場合、エレベータ2は保守対象となるが、保守対象の項目に0が入っている場合、エレベータ2は保守対象とならない。例えば、テーブル3の基準付加情報がエレベータ2の保守状態を示す付加情報である場合、全ての基準イベントコードに対して保守対象の項目に0が入っている。
テーブル4は、基準イベントコード、及び、これに対応する資料番号(技術情報の番号)のデータをそれぞれ含む。本実施形態の保守システム1では、資料番号(技術情報の番号)は、基準イベントコード毎に設定されている。資料は、エレベータ2の保守の作業手順を示す仕様書である。この資料には、例えば、「プリント基板を交換する」との作業についての作業手順が記載されている。資料番号は、基準イベントコードに対応しており、資料のどの箇所を参照するべきかを示している
テーブル5は、エレベータ識別番号、及び、これに対応する通知先情報を含む。通知先情報は、各エレベータの保守作業を担当する技術員が所持する携帯端末35の情報である。本実施形態の保守システム1では、第一サーバー31からインターネットを介して携帯端末35に通信可能であるため、テーブル5の通知先情報は、携帯端末35のIPアドレスである。
第一サーバー31は、CPU(Central Processing Unit)等を有する。第一サーバー31では、CPUが所望のプログラムを実行することで、機能的に、決定部30が形成される。また、第一サーバー31は、第二サーバー33に、有線により接続され、例えば、P2P(Peer to Peer)により接続されている。
決定部30は、データベース32内の基準イベントコード及び基準状況情報と、情報出力部21から取得されるイベントコード及び状況情報との比較に基づいて、保守の必要性と該必要性のランクとを決定する。さらに、本実施形態の保守システム1では、決定部30は、前回ランクを通知した日時から所定期間が経過している場合、又は、所定期間が経過していなくても前回のランクよりも今回のランクがランクアップしている場合、ランク等を携帯端末35の出力部34に出力させる。以下、決定部30の処理について詳細に説明する。
決定部30は、携帯端末35からイベントコード及び付加情報の履歴を受けると、このイベントコード等の履歴から、ランクの決定の対象となる対象レコードを抽出する。決定部30は、対象レコードとして、例えば、所定期間内に制御マイコン22から出力され、且つ、ランク決定の処理が未だ行われていないレコードを抽出する。レコードが所定期間内に制御マイコン22から出力されているか否かは、上述したイベントコードに含まれるイベントコードの発生日時の情報により判断できる。ランク決定の処理が行われているか否かは、テーブル2の前回決定日時を参照することで判断できる。
本実施形態の保守システム1では、決定部30は、対象レコードを抽出すると、これに含まれるイベントコードの発生頻度を算出する。例えば、決定部30は、イベントコード及び付加情報の履歴から所定期間内のレコードを抽出し、この抽出したレコードに、対象イベントコード及び対象付加情報(対象レコードに含まれるイベントコード及び付加情報)を含むレコードが発生する回数を計算して、発生頻度を算出する。
具体的に、決定部30は、一日当たりのイベントコードの発生頻度を算出するために、イベントコード及び付加情報の履歴のレコードから、対象イベントコードの発生の当日に発生したレコードを抽出する。さらに、決定部30は、この抽出したレコードから、対象イベントコード及び対象付加情報と同一のイベントコード及び付加情報を有するレコードの総数を計算する。同様に、決定部30は、一週間当たりのイベントコードの発生頻度についても、イベントコード及び付加情報の履歴のレコードから、対象イベントコードの発生の当日から一週間前までに発生したレコードを抽出し、対象イベントコード及び対象付加情報と同一のイベントコード及び付加情報を有するレコードの総数を計算する。
決定部30は、イベントコードの発生頻度を算出すると、対象イベントコード等とテーブル1とを比較する。具体的に、決定部30は、対象イベントコード及び対象付加情報と、テーブル1における基準イベントコード及び基準付加情報と、を比較する。本実施形態の保守システム1では、決定部30は、さらに、対象イベントコード及び対象付加情報に基づいて算出した一日当たりの発生頻度とテーブル1の一日当たりの発生頻度下限を比較すると共に、算出した一週間当たりの発生頻度とテーブル1の一週間当たりの発生頻度下限とを比較する。
決定部30は、対象イベントコード及び対象付加情報と、テーブル1における基準イベントコード及び基準付加情報とが一致すると共に、算出した一日又は一週間当たりの発生頻度が対応する発生頻度下限を上回る場合、テーブル3を用いて、イベントコードの組み合わせに基づいて、保守対象か否かを判断する。
尚、算出した一日又は一週間当たりの発生頻度が対応する発生頻度下限を下回る場合、この対象イベントコードは保守対象外であるため、決定部30は、未だテーブル1と比較していない対象イベントコードがあれば、この対象イベントコードとテーブル1との比較を行い、未だテーブル1と比較していない対象イベントコードがなければ、処理を終了する。
例えば、決定部30は、対象イベントコード及び対象付加情報と、テーブル3の基準イベントコード及び基準付加情報とを比較する。決定部30は、これらが一致した場合には、テーブル3の組み合わせイベントコードを読み出し、イベントコード及び付加情報の履歴のレコードから、組み合わせイベントコードと同一のイベントコードを有するレコードを抽出し、このイベントコードの発生日時が、組み合わせイベントコードの対象期間内であるか否かを判断する。決定部30は、このようなレコードがある場合、保守対象であるか否かについての項目を確認する。
また、決定部30は、対象イベントコードが保守対象で無い場合には、未だテーブル1と比較していない対象イベントコードがあれば、この対象イベントコードとテーブル1との比較を行い、未だテーブル1と比較していない対象イベントコードがなければ、処理を終了する。
本実施形態の保守システム1では、決定部30は、テーブル3を用いた比較により、情報出力部21から点検作業又は停電が要因で発生したイベントコードを含む複数のイベントコードを受信した場合に、保守の必要性がないと判断する。
決定部30は、テーブル3に対象イベントコードの組み合わせコードが無い場合、又は、組み合わせコードがあるが保守対象である場合には、再び、テーブル1を参照し、必要に応じて状況情報に基づき、対象イベントコードが発生したエレベータ2が保守対象であるか否かを判断する。本実施形態の保守システム1では、決定部30は、テーブル1に基づいて、必要に応じて状況情報の発生が人為的であるか否かを判断し、人為的であると判断したときに、エレベータ2は保守対象でないと判断する。
例えば、決定部30は、テーブル1のレコードのうち、基準イベントコード及び基準付加情報が対象イベントコード及び対象付加情報と一致するレコードを参照し、状況情報の取得の要否(画像取得の要否、ログデータ取得の要否)を確認する。決定部30は、必要な状況情報を取得し、この状況情報に基づいて対象イベントコードが保守対象か否かを判断する。具体的に、決定部30は、撮影機23から撮影画像を取得し、この撮影画像が飛び跳ね等の人為的な異常についての情報を含んでいる場合、保守対象でないと判断する。また、決定部30は、撮影画像が人為的な異常についての情報を含んでいるか否かについて、例えば、画像認識により判断する。さらに、決定部30は、制御マイコン22からログデータを取得し、飛び跳ね等の人為的と見られる走行速度の変動が見られる場合、保守対象でないと判断する。
決定部30は、状況情報の取得が必要でない場合、及び、状況情報に基づいて保守対象であると判断した場合、テーブル1を参照して保守の必要性のランクを抽出する。
本実施形態の保守システム1では、決定部30は、必要に応じて先ほど抽出したランク等を出力する。例えば、決定部30は、前回のランク等の通知日時から所定期間が経過している場合、テーブル4を参照して必要に応じて保守の際に用いる資料の番号を抽出すると共に、テーブル1を参照して保守の際に用いる指示文の番号を抽出する。具体的に、テーブル4のレコードのうち基準イベントコード及び基準付加情報が、対象イベントコード及び対象付加情報と一致するレコードがある場合、このレコードの資料の番号を抽出する。さらに、決定部30は、テーブル1のレコードのうち、基準イベントコード及び基準付加情報が対象イベントコード及び対象付加情報と一致するレコードから、指示文の番号とランクとを抽出する。
また、決定部30は、これらの抽出した情報を通知する際に用いる通知先情報を抽出する。例えば、決定部30は、テーブル5を参照し、対象イベントコードが発生したエレベータ識別番号(以下、対象エレベータ識別番号)とエレベータ識別番号が一致するレコードから、通知先情報を抽出する。本実施形態の保守システムでは、決定部30は、通知先情報として、携帯端末35のIPアドレスを取得する。その後、決定部30は、抽出したランク等を携帯端末35の出力部34に出力させる。
尚、決定部30は、前回のランク等の通知日時から所定期間が経過していなくても、今回のランクが前回のランクと比べてランクアップしていれば、技術員に通知の必要があるものとして、出力部34に保守の必要性と該必要性のランク等を出力させる。
具体的に、決定部30は、テーブル2から、対象イベントコード及び対象付加情報と一致するイベントコード及び付加情報を含むレコードについて、前回のランクの通知日時を確認する。決定部30は、前回の通知日時から今回の処理日時までの期間が所定期間を上回った場合、保守が必要である旨、保守の必要性のランク、及び、指示文番号(指示文の番号)を携帯端末35の出力部34に出力させ、さらに、テーブル4より資料番号(資料の番号)が抽出されている場合には、資料番号(資料の番号)も携帯端末35の出力部34に出力させる。その後、決定部30は、テーブル2を更新し、未だテーブル1と比較していない対象イベントコードがあれば、この対象イベントコードとテーブル1との比較から一連のランク決定の処理を行い、未だテーブル1と比較していない対象イベントコードがなければ、処理を終了する。具体的に、決定部30は、テーブル2の更新の際に、前回通知日時の項目に今回の通知日時を保存し、前回ランクの項目に今回の通知ランクを保存する。
また、決定部30は、前回の通知日時から今回の処理日時までの期間が所定期間以内である場合、今回のランクが前回のランクよりもランクアップしていれば(今回のランクがBの場合、前回のランクがC,Dであれば)、同様に指示文の番号やランク等を、出力部34に出力させ、テーブル2を更新し、未だテーブル1と比較していない対象イベントコードがあれば、この対象イベントコードとテーブル1との比較から一連のランク決定の処理を行い、未だテーブル1と比較していない対象イベントコードがなければ、処理を終了する。
さらに、決定部30は、前回の通知日時から今回の処理日時までの期間が所定期間以内である場合、今回のランクが前回のランクよりもランクアップしていないとき(今回のランクがBの場合、前回のランクがA,Bであれば)、未だテーブル1と比較していない対象イベントコードがあれば、この対象イベントコードとテーブル1との比較から一連のランク決定の処理を行い、未だテーブル1と比較していない対象イベントコードがなければ、処理を終了する。
以下、図4〜図6のフローチャート図を用いて、保守システム1における処理の流れを説明する。
携帯端末35は、技術員の操作により、制御マイコン22からイベントコード及び付加情報の履歴を取得し(S01)、このイベントコード等の履歴を第一サーバー31(決定部30)に出力する(S02)。
決定部30は、イベントコード及び付加情報の履歴を受けると、このイベントコード等の履歴から、ランクの決定の対象となる対象レコード(例えば、所定期間内に制御マイコン22から出力されたレコード)を抽出し(S03)、この抽出したレコードに、対象イベントコード及び対象付加情報(対象レコードに含まれるイベントコード及び付加情報)を含むレコードが発生する回数を計算して、発生頻度を算出する(S04)。
次に、決定部30は、対象イベントコード等とテーブル1とを比較する(S05)。具体的に、決定部30は、対象イベントコード及び対象付加情報と、テーブル1における基準イベントコード及び基準付加情報とを比較し、さらに、対象イベントコード及び対象付加情報に基づいて算出した一日当たりの発生頻度とテーブル1に含まれる一日当たりの発生頻度下限とを比較すると共に、算出した一週間当たりの発生頻度と一週間当たりの発生頻度下限とを比較する。
決定部30は、対象イベントコード及び対象付加情報と、テーブル1における基準イベントコード及び基準付加情報とが一致すると共に、算出した一日又は一週間当たりの発生頻度が対応する発生頻度下限を上回る場合(S06においてYes)、対象イベントコード及び対象付加情報とテーブル3とを比較する(S07)。
尚、算出した一日又は一週間当たりの発生頻度が対応する発生頻度下限以下である場合(S06においてNo)、決定部30は、対象イベントコードを全件比較していなければ(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
決定部30は、対象イベントコード及び対象付加情報とテーブル3とを比較し(S07)、イベントコード及び付加情報の履歴のレコードから、対象イベントコードの発生の当日に発生したレコードを抽出し、この抽出したレコードに、テーブル3の組み合わせイベントコードがあり(S09においてYes)、テーブル3の対応する保守対象の項目に基づいて保守対象であれば(S10においてYes)、テーブル1を用いて状況情報の取得の要否(画像確認要否及びログデータ要否)を判断する(S11(図5))。
尚、決定部30は、対象イベントコードの発生の当日に発生したレコードを抽出し、この抽出したレコードに、テーブル3の組み合わせイベントコードがない場合にも(S09においてNo)、テーブル1を用いて状況情報の取得の要否(画像確認要否及びログデータ要否)を判断する(S11)。
また、決定部30は、対象イベントコードの発生の当日に発生したレコードを抽出し、この抽出したレコードに、テーブル3の組み合わせイベントコードがあり(S09においてYes)、テーブル3の対応する保守対象の項目に基づいて保守対象でなければ(S10においてNo)、S08に進み、対象イベントコードを全件比較しているか否かを判断する(S08)。決定部30は、対象イベントコードを全件比較していなければ(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
決定部30は、テーブル1に基づいて、状況情報の取得が必要と判断した場合(S11においてYes)、状況情報を情報出力部21から取得し(S12)、状況情報に基づきエレベータ2が保守対象か否かを判断する(S13)。即ち、決定部30は、テーブル1に基づいて、必要に応じて状況情報の発生が人為的であるか否かを判断し、人為的であると判断したときに、エレベータ2は保守対象でないと判断する。
決定部30は、エレベータ2が保守対象であると判断した場合(S14においてYes)、テーブル1から保守の必要性のランクを抽出し(S15)、前回のランク等の通知日時から所定期間が経過している場合(S16においてYes(図6))、対象イベントコード及び対象付加情報とテーブル4の基準イベントコード及び基準付加情報とを比較し(S17)、対象イベントコードとテーブル4の基準イベントコードとが一致していれば(S18においてYes)、テーブル4からエレベータ2の保守の際に用いる資料の番号を抽出すると共に(S19)、テーブル1から指示文の番号を抽出し(S20)、テーブル5から対象イベントコードを出力したエレベータに対応する通知先情報を抽出する(S21)。尚、決定部30は、対象イベントコードとテーブル4の基準イベントコードとが一致しなければ(S18においてNo)、テーブル1から指示文の番号を抽出し(S20)、テーブル5から対象イベントコードを出力したエレベータに対応する通知先情報を抽出する(S21)。
処理部30は、抽出したランク等を携帯端末35の出力部34に出力させて(S22)、テーブル2(例えば、テーブル2における前回通知日時の項目及び前回ランクの項目)を更新し(S23)、S08に進み、対象イベントコードを全件比較しているかを判断する(S08)。決定部30は、対象イベントコードを全件比較していなければ(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
尚、決定部30は、状況情報の取得が必要でないと判断した場合(S11においてNo)、S15に進み、テーブル1から保守の必要性のランクを抽出し(S15)、前回のランク等の通知日時から所定期間が経過しているか否かを判定する(S16)。
決定部30は、状況情報に基づきエレベータ2が保守対象でないと判断した場合(S14においてNo)、S08に進み、対象イベントコードを全件比較しているか否かを判断する(S08)。決定部30は、対象イベントコードを全件比較していなければ(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
尚、決定部30は、前回のランク等の通知日時から所定期間が経過していない場合(S16においてNo)、今回のランクが前回のランクと比べてランクアップしていれば(S24においてYes)、必要に応じて資料の番号を抽出し(S18,S19)、指示文の番号及び通知先情報を抽出し(S20,S21)、ランク等を出力部34に出力させて(S22)、テーブル2を更新し(S23)、S08に進み、対象イベントコードを全件比較しているかを判断する(S08)。決定部30は、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
また、決定部30は、前回の通知日時から所定期間が経過していない場合(S16においてNo)、今回のランクが前回のランクよりもランクアップしていなければ(S24においてNo)、S08に進み、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがあれば、S08においてNo)、この対象イベントコードとテーブル1との比較を行い、対象イベントコードを全件比較していれば(未だテーブル1と比較していない対象イベントコードがなければ、S08においてYes)、処理を終了する。
以上の保守システム1では、情報出力部21から出力されたイベントコード及び状況情報(自身の動作についての状況情報)の組み合わせと、データベース32に予め設定された基準イベントコード及び基準状況情報とを比較し、この比較に基づいて、保守の必要性及び保守の必要性のランクが決定され(S15)、携帯端末35の出力部34からこの決定結果が出力される(S22)。そのため、携帯端末35を所持する技術員は、この決定結果に基づいて、エレベータ2の保守の必要性を適確に判断できる。
データベース32に含まれるテーブル1において、保守の必要性のランクが、基準イベントコード毎に設定された発生頻度下限(基準発生回数)に応じて設定される。そのため、イベントコードの発生回数が、保守の必要性のランクの判断基準として用いられている。これにより、保守の必要性のランクの判断がより適確なものとなる。
また、データベース32に含まれるテーブル1において、基準イベントコード毎に指示文(保守内容を示すデータ)が設定され、情報出力部21から出力されたイベントコードに対応した基準イベントコードに対応する指示文が、携帯端末35の出力部34から出力される。そのため、携帯端末35を所持する技術員は、指示文に基づいて適確に保守作業を行うことができる。
データベース32に含まれるテーブル4において、基準イベントコード毎に資料の番号(技術情報を示すデータ)が設定され、昇降装置から出力されたイベントコードに対応した基準イベントコードに対応する資料の番号が出力される。そのため、携帯端末35を所持する技術員は、この資料に基づいて適確に保守作業を行うことができる。
保守システム1では、エレベータ2において点検作業中又は停電が生じている場合に、保守の必要性がないと判断されるため、無駄な対応を防止することができる。
また、保守システム1では、状況情報の発生が人為的である場合に、保守の必要性がないと判断されるため、無駄な対応を防止することができる。
尚、本発明の保守システムは、上記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。例えば、ある実施形態の構成に他の実施形態の構成を追加することができ、また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることができる。さらに、ある実施形態の構成の一部を削除することができる。
例えば、テーブル1では、基準イベントコード及び基準付加情報に対応して指示文が設定され、対象イベントコード及び対象付加情報が、基準イベントコード及び基準付加情報と一致していれば、ランクがどのようなものであっても、出力部34から同一の指示文が出力されていたが、異なるランクそれぞれに対応して出力部34から異なる指示文が出力されてもよいし、特定のランクに対してのみ出力部34から指示文が出力されてもよい。例えば、ランクA,Bの場合に出力部34から指示文が出力され、ランクC,Dの場合に指示文が出力されなくてもよい。この場合、対象イベントコード及び基準付加情報に対してランクを決定した後、テーブル1に基づいて指示文を抽出すればよい。
上記実施形態の保守システム1では、判断部3は、情報出力部21から点検作業又は停電が要因で発生したイベントコードを含む複数のイベントコードを受信した場合に、保守の必要性がないと判断していたが、このような判断を行わなくてもよい。
また、上記実施形態の保守システム1では、判断部3は、状況情報の発生が人為的であるか否かを判断し、人為的であると判断したときに、保守の必要性がないと判断していたが、このような判断を行わなくてもよい。
判断部3は、第一サーバー31及び第二サーバー33といったサーバーと、携帯端末35とを含んでいたが、例えば、監視端末を含んでいてもよい。監視端末は、エレベータ2から離れた建物に設置されると共に、この建物においてエレベータ2を遠隔監視するための端末である。
また、判断部3は、第一サーバー31、第二サーバー33、及び、携帯端末35を含んでいたが、決定部30、データベース32、及び、出力部34を有する一つのサーバーで構成されてもよい。この場合、通信系統R2は、通信系統R1と共通することになる。
出力部34は、携帯端末35に含まれていたが、上記監視端末に含まれていてもよい。監視端末に出力部が含まれていれば、例えば、監視センターに常駐している監視員(オペレータ)が、監視端末を用いてエレベータ2の保守の必要性及びこの必要性のランクを確認できるため、これらに基づいて技術員の出向の要否を判断することができる。尚、携帯端末及び監視端末の両方が出力部を有している場合、決定部が、決定結果を携帯端末の出力部及び監視端末の出力部の両方に必要性のランク等を出力することで、技術員及び監視員の両方が、エレベータ2の保守の必要性及びこの必要性のランクを確認できる。
上記実施形態の保守システム1では、イベントコードは、携帯端末35により取得されていたが、第一サーバー31等のサーバーにより取得されてもよい。また、イベントコードは、遠隔監視ユニット4により取得されると共に、第一サーバー31に出力されてもよい。
情報出力部21は、制御マイコン22と、撮影機23との両方を含んでいたが、これらの少なくとも一方を含んでいればよい。制御マイコン及び撮影機の少なくとも一方を含んでいれば、これらの少なくとも一方からの状況情報に基づき、状況情報の発生が人為的か否かを判断し、人為的であると判断した時に保守の必要性が無いと判断することができる。そのため、状況情報の発生が人為的である場合、技術員の無駄な出向を防ぐことができる。
上記実施形態の保守システム1では、決定部30は、対象イベントコードの抽出の際に、ランク決定の処理が行われているか否かを、テーブル2の前回決定日時により判断したが、テーブル2の前回通知日時により判断してもよい。また、例えば、決定部30が、ランクを決定して通知した後にテーブル2を更新する際に、ランクを決定したイベントコードのレコードについて何らかのフラグ信号を立てて、対象イベントコードの抽出の際に、ランク決定の処理が行われているか否かをこのフラグ信号に基づいて判断してもよい。
データベース32は、ランクの決定に用いられる情報を有する各種テーブルに加えて、指示文及び資料(技術情報)も含んでいたが、ランクの決定に用いられる情報と、指示文及び資料は、例えば、別々のサーバー等に含まれてもよい。
上記実施形態の保守システム1は、複数台のエレベータを備えていたが、一台のエレベータを備えていてもよい。この場合、テーブル2及びテーブル5は、エレベータ識別番号の情報を有していなくてもよい。また、保守システム1は、複数台の携帯端末を備えていたが、一台の携帯端末を備えていてもよい。この場合、テーブル5が有する通知先情報は一つとなる。
通信系統R1は、電話回線の代わりにインターネットを含んでいてもよい。通信系統R1は、例えば、図7に示すように、エレベータ2から順に遠隔監視ユニット4とインターネットとを介して第一サーバー31に通信可能であり、且つ、第一サーバー31から逆にインターネットと遠隔監視ユニット4とを介してエレベータ2に通信可能な通信系統である。通信系統R1,R3は、一部(インターネット)で共通している。尚、通信系統R1は、遠隔監視ユニット4を含んでいたが、これを含んでいなくてもよい。この場合、エレベータ2は、インターネットを介して第一サーバー31に接続される。