JP2017210318A - 部品交換時期通知システム - Google Patents

Abstract

【課題】 好適な部品の交換タイミングを通知すること。
【解決手段】 実施形態に係る部品交換時期通知システムは、運行データ格納手段と、顧客が交わした保守契約の形態を示す顧客データを格納する顧客データ格納手段と、昇降機を構成する部品の起動回数を算出する手段と、部品毎に、異常が生じると推定される起動回数を第１の閾値として算出する手段と、部品毎に、異常の前兆が見られると推定される起動回数を第２の閾値として算出する手段と、部品毎に、起動回数が第２の閾値を超えているかどうかを判定する手段と、起動回数が第２の閾値を超えていると判定された場合、当該昇降機を所有する顧客の顧客データを取得する手段と、顧客データによって示される保守契約の形態に応じて、部品の発注を行う又は部品を交換する必要があることを知らせるための通知を発報する手段とを備える。
【選択図】 図１

Description

本発明の実施形態は、部品交換時期通知システムに関する。

一般に、昇降機を構成する各種部品は、昇降機の稼働回数に応じて消耗するため、所定のタイミングで交換する必要がある。部品を交換するタイミングは、保守点検作業を行う保守員によって判断される。保守員によって、部品を交換する必要があると判断された場合、その部品を交換して良いかどうかを、昇降機を所有する顧客に確認し、交換しても良い旨の確認がとれた場合、その部品の発注が行われる。このため、交換する必要があると判断されたタイミングと、実際に部品を交換するタイミングとには、タイムラグが生じてしまうという不都合がある。

特開２００１−７９５３２号公報

本発明が解決しようとする課題は、好適な部品の交換タイミングを通知可能な部品交換時期通知システムを提供することである。

実施形態に係る部品交換時期通知システムは、昇降機の運行履歴を示す運行データを格納する運行データ格納手段と、前記昇降機を所有する顧客が交わした保守契約の形態を示す顧客データを格納する顧客データ格納手段と、前記格納された運行データに基づいて、前記昇降機を構成する多数の部品の起動回数をそれぞれ算出する部品起動回数算出手段と、前記格納された運行データに基づいて、前記部品毎に、異常が生じると推定される起動回数を第１の閾値としてそれぞれ算出する第１の閾値算出手段と、前記算出された各第１の閾値に基づいて、前記部品毎に、異常の前兆が見られると推定される起動回数を第２の閾値としてそれぞれ算出する第２の閾値算出手段と、前記部品毎に、前記算出された起動回数が前記算出された第２の閾値を超えているかどうかを判定する第１の判定手段と、前記起動回数のいずれかが前記第２の閾値を超えていると判定された場合、当該昇降機を所有する顧客の顧客データを前記顧客データ格納手段から取得する第１の取得手段と、前記取得された顧客データによって示される保守契約の形態に応じて、部品の発注を行う又は部品を交換する必要があることを知らせるための通知を発報する発報手段とを具備する。

図１は、第１の実施形態に係る部品交換時期通知システムの概略構成例を示すブロック図である。 図２は、同実施形態に係るエレベータ制御装置の概略構成例を示すブロック図である。 図３は、同実施形態に係る顧客データのデータ構造の一例を示す模式図である。 図４は、同実施形態に係る部品価格データのデータ構造の一例を示す模式図である。 図５は、同実施形態に係る第１の解析処理の手順の一例を示すフローチャートである。 図６は、同実施形態に係る第２の解析処理の手順の一例を示すフローチャートである。 図７は、同実施形態に係る見積書作成処理の手順の一例を示すフローチャートである。 図８は、第２の実施形態に係る第２の解析処理の手順の一例を示すフローチャートである。

以下、図面を参照して実施形態を説明する。
＜第１の実施形態＞
以下では、昇降機に関する部品交換時期通知システムについて説明する。昇降機には、例えばエレベータ、エスカレータ、動く歩道などが含まれる。以下では、昇降機がエレベータである場合を想定して説明する。

図１は、実施形態に係る部品交換時期通知システムの概略構成例を示す。部品交換時期通知システムは、図１に示すように、エレベータ１１、監視センタ１２、パーツセンタ１３、保守員端末１４、営業担当端末１５及び管理者端末１６が通信ネットワーク１７を介して通信可能に接続されている。なお、図１の例では、エレベータ１１が１台しか図示されていないが、実際には多数のエレベータが部品交換時期通知システムに含まれる。

エレベータ１１には、エレベータ制御装置２１（「制御盤」と称されても良い）及び遠隔監視装置２２が設けられている。具体的には、エレベータ１１が設置されたビルの機械室などにエレベータ制御装置２１及び遠隔監視装置２２が設けられている。

エレベータ制御装置２１は、例えば乗りかごの速度制御やドアの開閉制御、各種操作ボタンに対応した制御などを含むエレベータ全体の運転制御を行う。このエレベータ制御装置２１は、図２に示すように、運行データ収集部２１ａ及び運行データ格納部２１ｂを備えている。運行データ収集部２１ａは、例えば稼働データや故障データなど、エレベータ１１の運行履歴を示す各種運行データを収集する。稼働データとは、エレベータ１１が稼働した回数（稼働回数）を示す。この稼働データには、エレベータ１１の稼働回数の他、エレベータ１１を識別するためのエレベータ識別データなどが含まれる。故障データとは、エレベータ１１に生じた故障（異常）の履歴を示す。収集された運行データは、運行データ格納部２１ｂに格納される。なお、運行データ格納部２１ｂには、容量の都合上、所定期間内（例えば当月分）の運行データだけが格納される。また、運行データ格納部２１ｂに格納された運行データは、監視センタ１２からの要求に応じて、遠隔監視装置２２を介して当該監視センタ１２に送られる。

エレベータ制御装置２１には遠隔監視装置２２が接続されている。この遠隔監視装置２２は、エレベータ１１の動作状態を監視するための端末装置であり、通信機能を備えている。遠隔監視装置２２は、この通信機能を利用して、エレベータ制御装置２１から送られてくる運行データを監視センタ１２に送信する。

監視センタ１２には、運行データ格納部３１、顧客データ格納部３２、運行データ解析部３３及び見積書作成部３４が設けられている。なお、監視センタ１２に設けられる各部３３，３４の一部または全ては、ＣＰＵ（Central Processing Unit）などの処理装置にプログラムを実行させること、すなわち、ソフトウェアによって実現されても良いし、ＩＣ（Integrated Circuit）などのハードウェアによって実現されても良いし、ソフトウェア及びハードウェアの組み合わせによって実現されても良い。

監視センタ１２は、所定のタイミング毎（例えば月末など）に、所定期間内（例えば当月分）の運行データをエレベータ１１から取得する。取得された運行データは、運行データ格納部３１に格納される。なお、この運行データ格納部３１には、当月分の運行データだけでなく、エレベータ１１が稼働し始めてから現在までの運行データが格納される。

顧客データ格納部３２には、エレベータ１１を所有する顧客が交わした保守契約の形態を示す顧客データが格納されている。顧客データとは、図３に示すように、エレベータ識別データ、顧客識別データ及び契約形態の項目が対応づけられたデータである。エレベータ識別データとは、エレベータ１１を識別するためのデータである。顧客識別データとは、対応づけられたエレベータ識別データによって識別されるエレベータ１１の所有者（顧客）を識別するためのデータである。契約形態とは、対応づけられた顧客識別データによって識別される顧客が、対応づけられたエレベータ識別データによって識別されるエレベータ１１を設置した際に交わした保守契約の形態を示すデータである。

例えば、図３に示す顧客データ３２ａによれば、「顧客Ｘ」がエレベータ識別データ「Ａ」によって識別されるエレベータ１１を設置した際に交わした保守契約の形態が「部品交換費用を含む」形態（フルメンテナンス契約）であることが分かる。つまり、保守契約の形態が「部品交換費用を含む」形態であるので、交換した方が良い部品が保守点検作業時に見つかった場合には、顧客に部品の交換の要否を確認することなく、部品の交換をして良いことが分かる。

また、図３に示す顧客データ３２ｂによれば、「顧客Ｙ」がエレベータ識別データ「Ｂ」によって識別されるエレベータ１１を設置した際に交わした保守契約の形態が「部品交換費用を含まない」形態（ＰＯＧ（Parts Oil Grease）契約）であることが分かる。つまり、保守契約の形態が「部品交換費用を含まない」形態であるので、交換した方が良い部品が保守点検作業時に見つかった場合には、顧客に部品の交換の要否を確認する必要があることが分かる。

なお、顧客データは、監視センタ１２と通信可能に接続されるエレベータ１１が設置される度に更新される。また、顧客データは、顧客の保守契約の形態が変更された場合にも更新される。

運行データ解析部３３は、運行データ格納部３１に格納される運行データ、具体的には稼働データに基づいて、エレベータ１１を構成する部品毎に、現在までに部品が起動した回数（以下、「部品起動回数」と表記する）をそれぞれ算出する。

また、運行データ解析部３３は、運行データ格納部３１に格納される運行データ、具体的には故障データに基づいて、部品を交換した方が良いかどうかを判断するための指標となる閾値を算出する第１の解析処理を実行する。さらに、運行データ解析部３３は、部品毎に算出された部品起動回数に基づいて、部品を交換した方が良いかどうかを判断すると共に、顧客データ格納部３２に格納される顧客データによって示される保守契約の形態に応じて、顧客に部品交換の要否を確認する必要があるかどうかを判断する第２の解析処理を実行する。

また、運行データ解析部３３は、上述した第２の解析処理の一環として、すぐにでも部品を交換した方が良いことを知らせるための部品交換警告通知や、少し余裕を見てもうそろそろ部品を交換した方が良いことを知らせるための部品交換注意通知を各種端末１４〜１６に発報したり、見積書作成要求を見積書作成部３４に送ったり、交換した方が良い部品の自動発注を行ったりする機能も有している。

なお、第１及び第２の解析処理の詳細については、フローチャートの説明と共に後述するため、ここではその詳しい説明は省略する。

見積書作成部３４は、運行データ解析部３３から送られる見積書作成要求を受けた場合、当該見積書作成要求に含まれる部品識別データによって識別される部品を交換する際にかかる費用を算出し、当該算出された費用が記された見積書を作成する見積書作成処理を実行する。作成された見積書は、運行データ解析部３３に送られる。

なお、見積書作成処理の詳細についても、フローチャートの説明と共に後述するため、ここではその詳しい説明は省略する。

パーツセンタ１３は、発注受付部４１及び部品価格データ格納部４２を備えている。発注受付部４１は、監視センタ１２から所定の部品の発注要求を受けると、当該発注要求に含まれる部品識別データによって識別される部品の発注を受けたことをパーツセンタ１３の職員に通知する。これによれば、パーツセンタ１３の職員は、交換用の部品を用意することができる。

部品価格データ格納部４２には、部品の価格を示す部品価格データが格納されている。部品価格データとは、図４に示すように、部品識別データ及び価格の項目が対応づけられたデータである。

例えば、図４に示す部品価格データ４２ａによれば、部品識別データ「ａ」によって識別される部品の価格が「１０００円」であることが分かる。また、図４に示す部品価格データ４２ｂによれば、部品識別データ「ｂ」によって識別される部品の価格が「５００円」であることが分かる。

保守員端末１４は、保守員が所持している端末であり、営業担当端末１５は、営業担当が所持している端末である。保守員端末１４及び営業担当端末１５は、監視センタ１２からの部品交換注意通知及び見積書の入力を受け付ける。これによれば、保守員端末１４及び営業担当端末１５を所持する保守員や営業担当は、部品交換注意通知と共に入力を受け付けた見積書を顧客に提示し、部品交換の要否を容易に問うことができる。

管理者端末１６は、保守員や営業担当を管理する管理者が所持している端末であり、監視センタ１２から発報される部品交換警告通知及び見積書の入力を受け付ける。これによれば、管理者は、部品交換警告通知と共に入力を受け付けた見積書を顧客に提示して、部品交換の要否を確認するよう保守員や営業担当に指示することができる。

次に、図５のフローチャートを参照して、運行データ解析部３３によって実行される第１の解析処理の手順の一例について説明する。但し、ここでは、運行データ格納部３１には、エレベータ１１が稼働し始めてから現在までの稼働データ及び故障データが格納されている場合を想定する。

始めに、運行データ解析部３３は、運行データ格納部３１に格納されるエレベータ１１が稼働し始めてから現在までの稼働データに基づいて、エレベータ１１を構成する部品毎に部品起動回数を算出する（ステップＳ１）。例えば、稼働データによって示されるエレベータ１１の稼働回数が１００回であって、エレベータ１１が１回稼働する毎に２回起動する部品の場合、当該部品の部品起動回数は２００（＝１００×２）回と算出される。

続いて、運行データ解析部３３は、運行データ格納部３１に格納される故障データによって示されるエレベータ１１の故障履歴を参照して、エレベータ１１を構成する部品毎に、現在の部品起動回数からあとどの程度起動したら当該部品に異常が生じるかを推定し、すぐにでも部品を交換した方が良いかどうかを判断するための指標（換言すると、部品交換警告通知を管理者端末１６に送信するかどうかを判断するための指標）となる第１の閾値を算出する（ステップＳ２）。つまり、第１の閾値は、エレベータ１１を構成する各種部品に異常が生じると推定される部品起動回数に相当する。

次に、運行データ解析部３３は、エレベータ１１を構成する部品毎に算出された第１の閾値に基づいて、少し余裕を見てそろそろ部品を交換した方が良いかどうかを判断するための指標（換言すると、部品交換注意通知を保守員端末１４及び営業担当端末１５に送信するかどうかを判断するための指標）となる第２の閾値を算出する（ステップＳ３）。つまり、第２の閾値は、エレベータ１１を構成する各種部品にもう少しで異常が生じると推定される部品起動回数（換言すると、異常の前兆が見られると推定される部品起動回数）に相当し、例えば、第１の閾値をＮ倍（但しＮ＜１である）した値がこれに相当する。

しかる後、運行データ解析部３３は、算出された第１及び第２の閾値を、第２の解析処理時に使用されるパラメータとして図示せぬメモリに設定し（ステップＳ４）、ここでの処理を終了させる。

次に、図６のフローチャートを参照して、運行データ解析部３３によって実行される第２の解析処理の手順の一例について説明する。但し、ここでは、監視センタ１２内の図示せぬメモリには、上述した第１の解析処理によってそれぞれ算出された第１及び第２の閾値が、第２の解析処理時に使用されるパラメータとして記憶（設定）されているものとする。なお、図６に示す第２の解析処理は、所定のタイミング（例えば月末）毎に実行されるものとする。

始めに、運行データ解析部３３は、エレベータ１１内の運行データ格納部２１ｂに格納される所定期間分（例えば当月分）の稼働データ及び故障データを取得する（ステップＳ１１）。取得された稼働データ及び故障データは運行データ格納部３１に適宜格納される。なお、運行データ格納部３１には、取得された稼働データ及び故障データを含めて、エレベータ１１が稼働し始めてから現在までの稼働データ及び故障データが格納されている。

続いて、運行データ解析部３３は、運行データ格納部３１に格納されるエレベータ１１が稼働し始めてから現在までの稼働データに基づいて、エレベータ１１を構成する部品毎に部品起動回数を算出する（ステップＳ１２）。

次に、運行データ解析部３３は、エレベータ１１を構成する部品毎に、算出された部品起動回数が図示せぬメモリに設定された第２の閾値を超えているかどうかを判定する（ステップＳ１３）。なお、エレベータ１１を構成する各種部品の部品起動回数のいずれもが、部品毎に設定された第２の閾値を超えていないと判定された場合（ステップＳ１３のＮＯ）、運行データ解析部３３は、エレベータ１１を構成する部品の交換は必要ないと判断し、ここでの処理を終了させる。

一方、エレベータ１１を構成する各種部品の部品起動回数のいずれかが、部品毎に設定された第２の閾値を超えていると判定された場合（ステップＳ１３のＹＥＳ）、運行データ解析部３３は、取得された稼働データに含まれるエレベータ識別データと同値のエレベータ識別データを有する顧客データを顧客データ格納部３２から取得する（ステップＳ１４）。つまり、当該エレベータ１１のエレベータ識別データを有する顧客データを顧客データ格納部３２から取得する。

続いて、運行データ解析部３３は、取得された顧客データに含まれる契約形態の項目を参照して、当該顧客データに含まれる顧客識別データによって識別される顧客の契約形態が「部品交換費用を含む」形態（フルメンテナンス契約）であるかどうかを判定する（ステップＳ１５）。

顧客の契約形態が「部品交換費用を含む」形態であると判定された場合（ステップＳ１５のＹＥＳ）、運行データ解析部３３は、部品交換の要否を顧客に確認する必要がないと判断し、交換用の部品を自動発注する。具体的には、運行データ解析部３３は、交換する必要がある部品の部品識別データを含む発注要求をパーツセンタ１３に対して送ることで、交換用の部品の発注を行い（ステップＳ１６）、ここでの処理を終了させる。

一方、顧客の契約形態が「部品交換費用を含まない」形態であると判定された場合（ステップＳ１５のＮＯ）、運行データ解析部３３は、ステップＳ１３の処理において第２の閾値を超えていると判定された部品を交換する際にかかる費用が記された見積書を作成して欲しい旨の見積書作成要求を見積書作成部３４に送る（ステップＳ１７）。見積書作成部３４は、見積書作成要求を受けると、当該要求に応じて見積書を作成する見積書作成処理を実行し、作成した見積書を運行データ解析部３３に送る。なお、見積書作成処理の詳細については、後述するため、ここではその詳しい説明は省略する。

次に、運行データ解析部３３は、ステップＳ１３の処理において第２の閾値を超えていると判定された部品の部品起動回数が図示せぬメモリに設定された第１の閾値を超えているかどうかを判定する（ステップＳ１８）。

部品起動回数が第１の閾値を超えていると判定された場合（ステップＳ１８のＹＥＳ）、運行データ解析部３３は、見積書作成部３４から送られた見積書が付された部品交換警告通知を管理者端末１６に発報し（ステップＳ１９）、ここでの処理を終了させる。

一方、部品起動回数が第１の閾値を超えていないと判定された場合（ステップＳ１８のＮＯ）、運行データ解析部３３は、見積書作成部３４から送られた見積書が付された部品交換注意通知を保守員端末１４及び営業担当端末１５に発報し（ステップＳ２０）、ここでの処理を終了させる。

次に、図７のフローチャートを参照して、見積書作成部３４によって実行される見積書作成処理の手順の一例について説明する。

始めに、見積書作成部３４は、運行データ解析部３３から送られた見積書作成要求に含まれる部品識別データを含む部品価格データをパーツセンタ１３内の部品価格データ格納部４２から取得する（ステップＳ２１）。

続いて、見積書作成部３４は、見積書作成要求に含まれる全ての部品識別データに関して、部品価格データを取得したかどうかを判定する。つまり、見積書を作成するにあたって必要な部品価格データを全て取得したかどうかを判定する（ステップＳ２２）。なお、必要な部品価格データを全て取得していないと判定された場合（ステップＳ２２のＮＯ）、必要な部品価格データを取得するべく、ステップＳ２１の処理を再度実行する。

一方、必要な部品価格データを全て取得していると判定された場合（ステップＳ２２のＹＥＳ）、見積書作成部３４は、取得された部品価格データに基づいて、第２の閾値を超えていると判定された部品を交換するにあたってかかる費用が記された見積書を作成する（ステップＳ２３）。具体的には、見積書作成部３４は、取得された部品価格データが１つである場合には、当該部品価格データによって示される部品の価格が記された見積書を作成する。また、見積書作成部３４は、取得された部品価格データが複数である場合には、当該各部品価格データによって示される各部品の価格の総和を算出し、当該各部品の価格の総和が記された見積書を作成する。

しかる後、見積書作成部３４は、作成された見積書を運行データ解析部３３に送り（ステップＳ２４）、ここでの処理を終了させる。

以上説明した第１の実施形態によれば、部品交換時期通知システムは、上述した第１及び第２の解析処理を実行可能な運行データ解析部３３を備えているので、顧客が交わした保守契約の形態に応じて、エレベータ１１を構成する部品を自動発注したり、保守員や営業担当、管理者に対して部品交換警告通知や部品交換注意通知を発報したりすることができる。

＜第２の実施形態＞
次に、第２の実施形態について説明する。第２の実施形態では、監視センタ１２内の図示せぬメモリに、上述した第１及び第２の閾値に加えて、第３の閾値がさらに設定されている場合の処理について説明する。なお、第１の実施形態と同様な機能を有する部分には同一の符号を付し、その詳しい説明を省略するものとする。

監視センタ１２は、自身にかかる処理負荷の都合上、例えば月に１度しかエレベータ１１から運行データを取得しない。つまり、図６に示した第２の解析処理は月に１度しか実行されない。これによれば、監視センタ１２にかかる処理負荷を減らすことはできるが、次のような不都合が生じ得る。

例えば、今月取得された運行データを用いて算出された部品起動回数が第２の閾値よりも少しだけ小さな値であり、部品を交換する必要がないと判断された場合であっても、次月に取得された運行データを用いて算出された部品起動回数が第２の閾値だけでなく、第１の閾値も超えてしまい、すぐに部品を交換する必要があると判断される場合がある。この場合、すぐに部品を交換する必要があるにも関わらず、部品を発注したり、保守契約の形態によっては顧客に部品交換の要否を確認したりする必要が生じてしまうので、すぐに部品を交換することができず、結果的に、顧客に不利益を与えてしまうという不都合が生じてしまう。

このような不都合を解消するべく、本実施形態では、第２の閾値をＭ倍（但しＭ＜１である）することで得られる第３の閾値をさらに設ける。この第３の閾値は、部品起動回数が次月の途中で少なくとも第２の閾値を超えるかどうかを判断するための指標である。

ここで、図８のフローチャートを参照して、監視センタ１２内の図示せぬメモリに、上述した第１及び第２の閾値に加えて、第３の閾値が設定されている場合の第２の解析処理の手順の一例について説明する。但し、図６に示した処理手順と同一の処理手順については同一の符号を付し、その詳しい説明を省略するものとする。

ステップＳ１１，Ｓ１２の処理の後、運行データ解析部３３は、エレベータ１１を構成する部品毎に、算出された部品起動回数が図示せぬメモリに設定された第３の閾値を超えているかどうかを判定する（ステップＳ３１）。なお、エレベータ１１を構成する各種部品の部品起動回数のいずれもが、部品毎に設定された第３の閾値を超えていないと判定された場合（ステップＳ３１のＮＯ）、運行データ解析部３３は、エレベータ１１を構成する部品の交換は必要ないと判断し、ここでの処理を終了させる。

一方、エレベータ１１を構成する各種部品の部品起動回数のいずれかが、部品毎に設定された第３の閾値を超えていると判定された場合（ステップＳ３１のＹＥＳ）、運行データ解析部３３は、第３の閾値を超えていると判定された部品の部品起動回数が図示せぬメモリに設定された第２の閾値を超えているかどうかを判定する（ステップＳ３２）。

部品起動回数が第２の閾値を超えていないと判定された場合（ステップＳ３２のＮＯ）、運行データ解析部３３は、現段階では部品の交換は必要ないが、次月には部品の交換が必要になる可能性が高いと判断し、この旨を知らせるための通知を保守員端末１４及び営業担当端末１５に発報し（ステップＳ３３）、ここでの処理を終了させる。

一方、部品起動回数が第２の閾値を超えていると判定された場合（ステップＳ３２のＹＥＳ）、運行データ解析部３３は、ステップＳ１４の処理を実行する。以降、運行データ解析部３３は、図６に示した場合と同様に、ステップＳ１５〜Ｓ２０の処理を実行し、ここでの処理を終了させる。

以上説明した第２の実施形態によれば、運行データ解析部３３は、次月には部品の交換が必要になる可能性が高い旨を知らせるための通知を保守員端末１４及び営業担当端末１５に発報する機能をさらに備えているので、保守員や営業担当は、部品の発注や顧客への部品交換の要否の確認を予め行うことができ、次月の途中で部品起動回数が第２及び第１の閾値を超えてしまった場合であっても、スムーズに部品交換を行うことができる。

以上説明した少なくとも１つの実施形態によれば、好適な部品の交換タイミングを通知可能な部品交換時期通知システムを提供することができる。

なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１１…エレベータ、１２…監視センタ、１３…パーツセンタ、１４…保守員端末、１５…営業担当端末、１６…管理者端末、１７…ネットワーク、２１…エレベータ制御装置、２１ａ…運行データ収集部、２１ｂ…運行データ格納部、２２…遠隔監視装置、３１…運行データ格納部、３２…顧客データ格納部、３３…運行データ解析部、３４…見積書作成部。

実施形態に係る部品交換時期通知システムは、昇降機の運行履歴を示す運行データを格納する運行データ格納手段と、前記昇降機を所有する顧客が交わした保守契約の形態を示す顧客データを格納する顧客データ格納手段と、前記格納された運行データに基づいて、前記昇降機を構成する多数の部品の起動回数をそれぞれ算出する部品起動回数算出手段と、前記格納された運行データに基づいて、前記部品毎に、異常が生じると推定される起動回数を第１の閾値としてそれぞれ算出する第１の閾値算出手段と、前記算出された各第１の閾値に基づいて、前記部品毎に、異常の前兆が見られると推定される起動回数を第２の閾値としてそれぞれ算出する第２の閾値算出手段と、前記部品毎に、前記算出された起動回数が前記算出された第２の閾値を超えているかどうかを判定する第１の判定手段と、前記部品毎に算出された起動回数のいずれかが前記第２の閾値を超えていると判定された場合、当該昇降機を所有する顧客の顧客データを前記顧客データ格納手段から取得する第１の取得手段と、前記取得された顧客データによって示される保守契約の形態に応じて部品の発注を行う、又は前記取得された顧客データによって示される保守契約の形態に応じて部品を交換する必要があることを知らせるための通知を発報する発報手段とを具備する。

Claims (7)

1. 昇降機の運行履歴を示す運行データを格納する運行データ格納手段と、
   前記昇降機を所有する顧客が交わした保守契約の形態を示す顧客データを格納する顧客データ格納手段と、
   前記格納された運行データに基づいて、前記昇降機を構成する多数の部品の起動回数をそれぞれ算出する部品起動回数算出手段と、
   前記格納された運行データに基づいて、前記部品毎に、異常が生じると推定される起動回数を第１の閾値としてそれぞれ算出する第１の閾値算出手段と、
   前記算出された各第１の閾値に基づいて、前記部品毎に、異常の前兆が見られると推定される起動回数を第２の閾値としてそれぞれ算出する第２の閾値算出手段と、
   前記部品毎に、前記算出された起動回数が前記算出された第２の閾値を超えているかどうかを判定する第１の判定手段と、
   前記起動回数のいずれかが前記第２の閾値を超えていると判定された場合、当該昇降機を所有する顧客の顧客データを前記顧客データ格納手段から取得する第１の取得手段と、
   前記取得された顧客データによって示される保守契約の形態に応じて、部品の発注を行う又は部品を交換する必要があることを知らせるための通知を発報する発報手段と
   を具備することを特徴とする部品交換時期通知システム。
2. 前記運行データは、前記昇降機が稼働した回数を示す稼働データと前記昇降機の故障履歴を示す故障データとを含み、
   前記部品起動回数算出手段は、
   前記格納された運行データ内の稼働データに基づいて前記各起動回数を算出し、
   前記第１の閾値算出手段は、
   前記格納された運行データ内の故障データに基づいて前記各第１の閾値を算出することを特徴とする請求項１に記載の部品交換時期通知システム。
3. 前記第２の閾値算出手段は、
   前記算出された各第１の閾値に１未満の所定値を乗算して前記各第２の閾値を算出することを特徴とする請求項１又は請求項２に記載の部品交換時期通知システム。
4. 前記顧客データは、前記保守契約の形態として部品交換費用を含む形態であるかどうかを示し、
   前記発報手段は、
   前記取得された顧客データによって示される保守契約の形態が部品交換費用を含む形態である場合、前記起動回数が前記第２の閾値を超えていると判定された部品の発注を行い、当該顧客データによって示される保守契約の形態が部品交換費用を含まない形態である場合、保守員が所持する保守員端末に前記通知を発報することを特徴とする請求項１乃至請求項３のいずれか１項に記載の部品交換時期通知システム。
5. 前記起動回数が前記第２の閾値を超えていると判定された部品に関し、当該部品の起動回数が前記算出された第１の閾値を超えているかどうかを判定する第２の判定手段をさらに具備し、
   前記発報手段は、
   前記取得された顧客データによって示される保守契約の形態が部品交換費用を含まない形態であって、前記起動回数のいずれかが前記第１の閾値を超えていると判定された場合、保守員を管理する管理者が所持している管理者端末に前記通知を発報し、前記起動回数のいずれもが前記第１の閾値を超えていないと判定された場合、前記保守員が所持する保守員端末に前記通知を発報することを特徴とする請求項１乃至請求項４のいずれか１項に記載の部品交換時期通知システム。
6. 前記各部品の価格を示す部品価格データを格納する部品価格データ格納手段と、
   前記起動回数のいずれかが前記第２の閾値を超えていると判定された場合、当該第２の閾値を超えていると判定された部品の部品価格データを前記部品価格データ格納手段から取得する第２の取得手段と、
   前記取得された部品価格データに基づいて、部品を交換する際にかかる費用を算出して見積書を作成する見積書作成手段と
   をさらに具備し、
   前記発報手段は、
   前記取得された顧客データによって示される保守契約の形態が部品交換費用を含まない場合、前記作成された見積書を前記通知と共に発報することを特徴とする請求項１乃至請求項５のいずれか１項に記載の部品交換時期通知システム。
7. 前記算出された各第２の閾値に１未満の所定値を乗算して、前記部品毎に、前記各第２の閾値よりも小さな第３の閾値を算出する第３の閾値算出手段と、
   前記起動回数のいずれかが前記第３の閾値を超えているかどうかを判定する第３の判定手段と
   をさらに具備し、
   前記第１の判定手段は、
   前記起動回数が前記第３の閾値を超えていると判定された部品に関し、当該部品の起動回数が前記算出された第２の閾値を超えているかどうかを判定し、
   前記発報手段は、
   前記起動回数のいずれかが前記第３の閾値を超えていると判定され、かつ前記第２の閾値を超えていないと判定された場合、保守員が所持する保守員端末に、当該部品に近々異常の前兆が見られる可能性が高いことを知らせるための通知を発報することを特徴とする請求項１乃至請求項６のいずれか１項に記載の部品交換時期通知システム。

Images