特開 2022-185392 予兆診断装置、予兆診断方法及び機器管理プログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022185392

(43)【公開日】2022-12-14

(54)【発明の名称】予兆診断装置、予兆診断方法及び機器管理プログラム

(51)【国際特許分類】

   G06F 13/00 20060101AFI20221207BHJP

   H04Q 9/00 20060101ALI20221207BHJP

   G05B 23/02 20060101ALI20221207BHJP

   F24F 11/38 20180101ALI20221207BHJP

   F24F 11/64 20180101ALI20221207BHJP

   F24F 11/54 20180101ALI20221207BHJP

   F24F 140/00 20180101ALN20221207BHJP

【ＦＩ】

G06F13/00 358A

H04Q9/00 301D

H04Q9/00 301B

G05B23/02 T

F24F11/38

F24F11/64

F24F11/54

F24F140:00

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2021093047

(22)【出願日】2021-06-02

(71)【出願人】

【識別番号】399048917

【氏名又は名称】日立グローバルライフソリューションズ株式会社

(74)【代理人】

【識別番号】110000350

【氏名又は名称】ポレール弁理士法人

(72)【発明者】

【氏名】國眼 陽子

(72)【発明者】

【氏名】高野 雅樹

(72)【発明者】

【氏名】飯澤 憲次

(72)【発明者】

【氏名】山岡 静夫

【テーマコード（参考）】

3C223

3L260

5K048

【Ｆターム（参考）】

3C223AA11

3C223AA17

3C223BA03

3C223BB12

3C223CC02

3C223DD03

3C223EB01

3C223EB02

3C223EB03

3C223EB07

3C223FF02

3C223FF03

3C223FF12

3C223FF13

3C223FF35

3C223FF42

3C223FF45

3C223FF52

3C223GG01

3C223HH02

3C223HH08

3C223HH29

3L260BA51

3L260BA57

3L260BA64

3L260CB01

3L260DA10

3L260EA07

3L260EA08

3L260EA19

3L260FA15

3L260GA15

3L260GA17

3L260JA12

3L260JA19

3L260JA22

5K048AA05

5K048AA06

5K048BA01

5K048BA12

5K048EB08

5K048EB10

5K048EB12

5K048FB15

5K048GB03

5K048GB08

5K048HA01

5K048HA02

(57)【要約】

【課題】
本発明は、機器における故障状態に関する予兆に応じて、保守事業者が適切に対応することを支援することを課題とする。
【解決手段】
上記の課題を解決するために、本発明は、保守対象である診断対象機器の故障に関する予兆を検知する予兆診断サーバ３において、前記診断対象機器の運転情報を受信する情報受信部３６と、前記運転情報に基づいて、前記診断対象機器における故障に関する複数の予兆を検知する予兆診断部３１と、検知された前記複数の予兆のそれぞれに対して、当該予兆への保守の優先順位を決定する優先順位決定部３３と、前記優先順位および前記診断対象機器の保守を行う保守事業者の状況を示す保守事業者属性情報に基づいて、前記予兆における通知の要否を決定する通知決定部３４と、前記通知決定部で通知が必要と決定された予兆に関する通知を実行する情報送信部３５を有する。
【選択図】 図２

【特許請求の範囲】

【請求項1】

保守対象である診断対象機器の故障に関する予兆を検知する予兆診断装置において、
前記診断対象機器の運転情報を受信する受信部と、
前記運転情報に基づいて、前記診断対象機器における故障に関する複数の予兆を検知する予兆診断部と、
検知された前記複数の予兆のそれぞれに対して、当該予兆への保守の優先順位を決定する優先順位決定部と、
前記優先順位および前記診断対象機器の保守を行う保守事業者の状況を示す保守事業者属性情報に基づいて、前記予兆における通知の要否を決定する通知決定部と、
前記通知決定部で通知が必要と決定された予兆に関する通知を実行する情報送信部を有する予兆診断装置。

【請求項2】

請求項１に記載の予兆診断装置において、
さらに、前記予兆を、前記保守事業者が保守を行う予兆と前記診断対象機器の利用者が保守を行う予兆に分類する保守実行分類部を有する予兆診断装置。

【請求項3】

請求項２に記載の予兆診断装置において、
前記情報送信部は、前記予兆を、前記保守実行分類部により前記利用者が保守を行う予兆と分類した場合、前記利用者の診断対象機器を利用する利用者に対して、前記予兆に関する通知として、前記予兆の内容を示す情報を通知する予兆診断装置。

【請求項4】

請求項２に記載の予兆診断装置において、
前記保守実行分類部により前記保守事業者が保守を行う予兆と分類した場合、前記通知決定部は、前記保守事業者属性情報から前記保守事業者により対応可能な対応件数を算出し、前記優先順位および前記対応件数に応じて、前記複数の予兆から、前記通知が必要な予兆を決定する予兆診断装置。

【請求項5】

請求項４に記載の予兆診断装置において、
前記予兆診断部は、さらに、前記診断対象機器の故障を検知し、
前記優先順位決定部は、前記故障への保守を最優先とする優先順位を決定する予兆診断装置。

【請求項6】

保守対象である診断対象機器の故障に関する予兆を検知する予兆診断装置を用いた予兆診断方法において、
受信部により、前記診断対象機器の運転情報を受信し、
予兆診断部により、前記運転情報に基づいて、前記診断対象機器における故障に関する複数の予兆を検知し、
優先順位決定部により、検知された前記複数の予兆のそれぞれに対して、当該予兆への保守の優先順位を決定し、
通知決定部により、前記優先順位および前記診断対象機器の保守を行う保守事業者の状況を示す保守事業者属性情報に基づいて、前記予兆における通知の要否を決定し、
情報送信部により、前記通知決定部で通知が必要と決定された予兆に関する通知を実行する予兆診断方法。

【請求項7】

請求項６に記載の予兆診断方法において、
さらに、保守実行分類部により、前記予兆を、前記保守事業者が保守を行う予兆と前記診断対象機器の利用者が保守を行う予兆に分類する予兆診断方法。

【請求項8】

請求項７に記載の予兆診断方法において、
前記情報送信部により、前記予兆を、前記保守実行分類部により前記利用者が保守を行う予兆と分類した場合、前記利用者の診断対象機器を利用する利用者に対して、前記予兆に関する通知として、前記予兆の内容を示す情報を通知する予兆診断方法。

【請求項9】

請求項７に記載の予兆診断方法において、
前記保守実行分類部により前記保守事業者が保守を行う予兆と分類した場合、前記通知決定部により、前記保守事業者属性情報から前記保守事業者により対応可能な対応件数を算出し、前記優先順位および前記対応件数に応じて、前記複数の予兆から、前記通知が必要な予兆を決定する予兆診断方法。

【請求項10】

請求項９に記載の予兆診断方法において、
前記予兆診断部により、さらに、前記診断対象機器の故障を検知し、
前記優先順位決定部により、前記故障への保守を最優先とする優先順位を決定する予兆診断方法。

【請求項11】

診断対象機器の運転を管理するためのコンピュータである端末装置に以下のステップを実行させる機器管理プログラムにおいて、
前記診断対象機器に対して、運転指示を出力するステップと、
前記診断対象機器の故障に関する予兆を検知する予兆診断装置から、前記診断対象機器の運転情報に基づいて算出される前記診断対象機器における故障に関する複数の予兆のそれぞれに対する優先順位および前記診断対象機器の保守を行う保守事業者の状況を示す保守事業者属性情報に基づいて決定された予兆に関する通知を受信するステップと、
前記端末装置の利用者からの指示に従って、前記予兆に対する前記保守事業者での保守依頼を通知するステップを有し、
前記予兆は、前記保守事業者での保守が必要な予兆である機器管理プログラム。

【請求項12】

請求項１１に記載の機器管理プログラムにおいて、
前記予兆には、前記保守事業者での保守が必要な故障が含まれ、
前記予兆に関する通知を受信するステップは、前記故障に関する通知を優先的に受信するステップである機器管理プログラム。

【請求項13】

請求項１１に記載の機器管理プログラムにおいて、
さらに、
前記診断対象機器から自身の運転情報を受信するステップと、
前記予兆診断装置に対して、前記運転情報を送信するステップを実行させる機器管理プログラム。

【請求項14】

請求項１１乃至１３のいずれかに記載の機器管理プログラムにおいて、
前記予兆に関する通知は、前記保守事業者属性情報に基づき算出される前記保守事業者により対応可能な対応件数および前記優先順位に応じて決定される機器管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、機器の異常を診断するための技術に関する。

【背景技術】

【0002】

現在、家電製品や設備機械など定常的にメンテナンスを行いながら稼働することが想定される機器（特に、電気機器）を対象として、その運転データから予兆診断を行う技術が提案されている。このような予兆診断は、機器の状態が正常動作状態であるか、異常の予兆発生状態であるかを診断し、その結果として異常の予兆発生状態であると判定された場合にはその予兆を報知するものである。

【0003】

ここで異常状態とは、機器に何らかの故障、劣化、不具合など機器の性能、品質の低下が生じている状態を示す。一方予兆発生状態とは、異常状態ではないものの、異常状態へ向かっている予兆をとらえた状態を示す。このような予兆診断により、機器に故障や劣化が顕在化する前に、保守事業者がメンテナンスを実行することで、機器の安定稼働を支援することが期待されている。

【0004】

このような予兆診断を提供する予兆診断システムとして、例えば、特許文献１が開示されている。特許文献１には、予兆診断システムは不具合事象の予兆を検知した場合、その予兆の情報をメンテナンス管理装置に通知することが開示されている。

【0005】

また、特許文献２には、発生する故障を予測し、サービスステーション端末又はコールセンタ端末に通知することが記載され、さらに顧客の属性情報に応じて、対応内容を調整することで、機器の処理の実施予定を妨げずに、検知された予兆に対処することが記載されている。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１５－２１５６９０号公報

【特許文献2】特開２０１７－１６２３８号公報

【発明の概要】

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

【0007】

ところで、異常状態が発生する時期は、機器の運転環境などの影響を受けるため、一定の繁忙期、閑散期があり、繁忙期には、保守事業者の人員不足が課題となっている。予兆診断はこれを緩和するために、異常の予兆発生状態で検知するものである。但し、異常の予兆発生状態を検知するという特性上、単に検知した予兆状態を検知するだけでは、検知の頻度の増加につながり、保守事業者の人員不足解消という課題を解決することができない可能性がある。さらに、予兆の通知は受けたものの、保守事業者の対応に遅れが生じることで、早期の修理で故障が顕在化する前に改善されたものが故障に至る可能性もある。

【0008】

本発明はこのような背景に鑑みてなされたのであり、検知された機器における故障状態に関する予兆に応じて、保守事業者が適切に対応することを支援することを課題とする。なお、保守事業者とは、保守を行う組織、個人であればよく、専門業者に限定されない。また、保守事業者は、企業等を単位としてもよいし、企業内の部署単位で管理してもよい。

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

【0009】

上記目的を達成するために、本発明は、保守対象である診断対象機器の故障に関する予兆を検知する予兆診断装置において、前記診断対象機器の運転情報を受信する受信部と、前記運転情報に基づいて、前記診断対象機器における故障に関する複数の予兆を検知する予兆診断部と、検知された前記複数の予兆のそれぞれに対して、当該予兆への保守の優先順位を決定する優先順位決定部と、前記優先順位および前記診断対象機器の保守を行う保守事業者の状況を示す保守事業者属性情報に基づいて、前記予兆における通知の要否を決定する通知決定部と、前記通知決定部で通知が必要と決定された予兆に関する通知を実行する情報送信部を有する予兆診断装置である。

【0010】

また、本発明には、予兆診断装置を用いた予兆診断方法や予兆診断装置を機能させるためのプログラム、このプログラムを格納した記憶媒体も、含まれる。さらに、本発明には、予兆診断装置を含む予兆診断システムも含まれる。またさらに、本発明には、予兆診断システムを構成する携帯端末やこれを機能させるためのプログラムも含まれる。

【発明の効果】

【0011】

本発明によれば、機器の故障に関する予兆診断部で検知された予兆に対して、保守事業者が適切に対応することを支援することが可能となる。

【図面の簡単な説明】

【0012】

【図1】実施例１における予兆診断システムの全体構成を示す図である。

【図2】実施例１における予兆診断システムの機能ブロック図である。

【図3】実施例１における予兆診断用サーバ３の処理を説明するための図である。

【図4】実施例１で用いられる保守実行データベース３２１を表形式で構成した一例を示す図である。

【図5】実施例１で用いられる予兆内容優先度データベースを表形式で構成した一例を示す図である。

【図6】実施例１における処理３４２の概念を説明するための図である。

【図7】実施例２における遠隔診断サーバ３ｂの処理を説明するための図である。

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

【実施例0013】

以下、本発明の実施例１について、図１から図６を参照しながら詳細に説明する。図１は、実施例１における予兆診断システム０の全体構成を示す図である。予兆診断システム０は、診断対象機器設置場所１０、遠隔監視センタ３０およびサービスセンタ４０で用いられる各種装置で構成される。ここで、診断対象機器設置場所１０は、例えば、家庭内であって、ホームゲートウェイ５が設置されている。ホームゲートウェイ５は、Bluetooth（登録商標）等の近距離間の無線データ通信機能を有し、診断対象機器と通信することができる。なお、診断対象機器は、保守対象となる機器でもある。

【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】

以下、本発明の実施例２について、図７を参照しながら詳細に説明する。図７は、本発明の実施例２における予兆診断用サーバ３ｂの処理を説明するための図である。

【0059】

予兆診断用サーバ３ｂは、実施例１の予兆診断サーバ３に対して、故障診断機能が追加されている点で異なる。つまり、予兆診断用サーバ３ｂの予兆診断部３１は、所定周期で故障診断を行う（処理３１０－２）。なお、本実施例では、予兆診断部３１で、処理３１０－２を実行する構成とするが、別途故障診断部を設けてもよい。このように、予兆診断および故障診断を行うため、本実施例の予兆診断用サーバ３ｂは、遠隔診断サーバと称することも可能である。

【0060】

以上のように、図７は、実施例１の図３に対応する図である。そして、実施例１の図１、図２、図４～６は、実施例２でも共通である。また、図７では、図３と異なり処理主体（３１～３４）の記載を省略した。

【0061】

以下、その処理を説明するが、診断対象機器を実施例１と同様に、洗濯乾燥機１として説明するが、これに限ったものではない。

【0062】

なお、本実施例における故障とは、必ずしも機能の停止や運転の停止を示すわけではなく、経年劣化などによる機能の低下も含む。故障診断の要求は、不具合を感じたユーザ起点でもよいし、周期的に自動実行する仕組みとしてもよい。さらに、本実施例では、洗濯乾燥機１のユーザが、機器に何らかの障害状態を感じて保守事業者へ遠隔からの故障診断を依頼した場合を想定して説明する。

【0063】

以下、本実施例における予兆診断用サーバ３ｂの処理について説明する。なお、ここでは、予兆診断（処理３１０－１）は、実施例１の予兆診断部３１の処理（処理３１２、処理３１４）と同様であるため詳細については省略する。また、予兆診断用サーバ３ｂを構成する各部は、実施例１の予兆診断用サーバ３と同様とする。但し、上述のように、予兆診断部３１で、故障診断が可能である。

【0064】

保守事業者は、ユーザから故障診断を依頼されると、携帯端末４から予兆診断用サーバ３ｂに故障診断の開始する指示を通知する。診断開始の指示により予兆診断用サーバ３ｂの情報受信部３６では、洗濯乾燥機１の情報取得部１１からの運転情報を受信する（処理３６０）。なお、この受信は、予兆診断用サーバ３ｂの情報送信部３５からの要求に応じてもよいし、洗濯乾燥機１の情報取得部１１が能動的に送信することで実現してもよい。つまり、ｐｕｌｌ型でもｐｕｓｈ型でもよい。

【0065】

次に、予兆診断部３１は、受信した運転情報を用いて、故障発生および予兆発生の有無を判断する（処理３１０－１，処理３１０－２）。ここで、本実施例では、処理３１０－１は、上述のように実施例１の処理３１２および処理３１４と同じであるが、これとは異なる処理アルゴリズムを用いてもよい。

【0066】

また、予兆診断部３１では、記憶部３００に記憶された故障の有無を判断するために複合故障モデルを用いて、運転情報が示す洗濯乾燥機１の故障の度合いを算出する。この際、予兆診断部３１は、洗濯乾燥機１で想定される異常想定個所毎に算出する。ここで、予兆診断部３１では、故障の度合いが予め設定された条件を満たすかにより、故障があるかないかを判断する。この結果、故障があると判断した場合には、予兆診断部３１は、運転情報に基づいて、故障内容を特定する。一方、故障がなければ、処理３５０に遷移する。

【0067】

また、保守実行分類部３２は、故障内容を用いて、保守実行データベース３２１に基づき保守実行者を選択する（処理３２２）。つまり、実施例１と同様の処理により、保守実行者を故障内容に基づいて特定する保守分類を行う。

【0068】

なお、図４に示す保守実行データベース３２１では、予兆内容と保守実行者が対応付けられているが、予兆内容に代わってもしくはこれに追加して、故障内容と保守実行者を対応付けておけばよい。なお、予兆診断でも故障診断でも、保守実行データベース３２１の故障または予兆内容に対する保守実行者は同じであり、共通で使用することができる。

【0069】

処理３２２の結果、予兆、故障があり、その保守実行者がユーザの場合および故障がありその保守実行者が保守員の場合、処理３５０に遷移する。また、予兆がありその保守実行者が保守員の場合、処理３３３に遷移する。そして、処理３３３以降の処理は、実施例１と同様である。

【0070】

但し、処理３２２、処理３３３および処理３４２については、以下の（１）もしくは（２）のように実行してもよい。

【0071】

（１）まず、処理３２２において、保守実行分類部３２が、予兆および故障に限らず、保守実行者が保守員の場合は、処理３３３に遷移する。また、保守実行者がユーザの場合、処理３５０に遷移する。

【0072】

次に、処理３３３において、優先順位決定部３３が、該当の故障もしくは予兆の優先順位を決定する。このために、優先順位決定部３３は、故障であれば、該当の故障の優先順位を最上位とする。つり、保守を最優先とする。このために、故障の優先度として、最上位（本例では０）を付与する。次に、実施例１と同様に、優先順位決定部３３は、他の機器の検知情報３３２を用いて、保守事業者で担当する家電機器の故障、予兆について、優先度の順にソートする。そして、優先順位決定部３３は、実施例１と同様の処理をソートされた結果に施して、優先順位を決定する。この結果、処理３４２において、通知決定部３４が、実施例１と同様の処理により、通知の要否を決定する。

【0073】

（２）処理３２２については、（１）と同様に処理する。次に、処理３３３において、優先順位決定部３３が、予兆について、優先度を特定し、これに基づいて、予兆に関する優先順位を決定する。つまり、実施例１と同様の処理を実行する。

【0074】

そして、処理３４２において、通知決定部３４が、故障については通知対象と決定する。次に、通知決定部３４では、保守事業者属性情報３４１を用いて対応可能な訪問件数（対応可能数）を算出する。そして、通知決定部３４は、算出された対応可能数から、故障の件数を差し引き、予兆対応可能件数を算出する。次に、通知決定部３４は、予兆対応可能件数と予兆の検知数の積算値を比較して、予兆対応可能数の範囲内となる優先順位の予兆内容を特定する。この結果、故障については、通知するものとして確定し、予兆についてはその優先順位に従って通知されるかが決定される。以上で、別案である（１）（２）の説明を終わるが、これらにより、ユーザ携帯端末２は、故障に関する通知を優先的に受信することになる。

【0075】

最後に、処理３５０において、情報送信部３５の送信先は、保守実行者の情報により決定される。つまり、保守実行者がユーザである場合には、ユーザ携帯端末２や洗濯乾燥機１へ、保守事業者であれば携帯端末４へ故障内容と度合いが合わせて送られる。また、洗濯乾燥機１では、情報受信部１３で通知を受信後、操作パネル（図示せず）を表示部１４として通知内容を表示される。

【0076】

ここで、本実施例の洗濯乾燥機１の表示部１４は、予兆診断において予兆を検知した場合にも使用することを想定している。そのため、予兆検知時と故障検知時とでは、検知した内容が予兆であるのか、故障であるのかを分かりやすくするため、異なる表示とすることが望ましい。異なる表示とは、例えば、操作パネルのバッククライトの色を故障と予兆とで変えることを想定している。洗濯乾燥機１以外の機器で、操作パネル等がない機器の場合は、その機器のリモコンのバックライトや運転ランプの色を変える等でもよい。

【0077】

これにより、故障を検知した場合においては、すぐに保守事業者が出動するか、自身での改善を行う。一方で、予兆を検知した場合においては、ユーザは時間的な余裕をもって保守事業者へ連絡を行うか、自身での改善を行う。

【0078】

このように、予兆と故障とで表示を変えることにより、機器の構成を複雑とすることなく、ユーザは洗濯乾燥機１の保守の必要性の緊急度を視覚的に理解しやすくなり、利便性が向上する。

【0079】

以上で、各実施例の説明を終了するが、本発明は各実施例に限定されるものでなく、様々な変形例が想定される。例えば、サービスセンタ４０と遠隔監視センタ３０は共通化してもよいし、サービスセンタ４０を複数用意してもよい。サービスセンタ４０を複数用意する場合、遠隔監視センタ３０をサービスセンタ４０毎に用意してもよいし、複数のサービスセンタ４０を１つの遠隔監視センタ３０で管理してもよい。後者の場合、予兆診断用サーバ３や予兆診断用サーバ３ｂは、いわゆるクラウドシステムで構築することができる。

【0080】

さらに、本発明には、以下の態様も含まれる。機器の運転情報を受信する受信部と、運転情報から機器が故障する前の不具合検知する予兆診断部と、予兆診断の結果の通知に優先順位をつける優先順位決定部と、を有する構成とする。さらに、機器の保守事業者の属性情報を取得する手段と記優先順位決定部の結果と、保守事業者の属性情報に基づき、予兆診断の結果を通知するか否かを決定する通知決定部と、を有する構成である。

【0081】

さらに、本発明は、機器の位置情報にかかる情報を取得する手段を有する構成とする。ここで、優先順位決定部は、保守事業者が対応する不具合に対して優先順位を付与してもよい。また、機器の保守事業者の属性情報を取得する手段は保守事業者の属性情報が格納されたデータベースを参照するものである。そして保守事業者の属性情報が格納されたデータベースは更新可能である。

【0082】

さらに通知決定部の結果に基づき、予兆診断部の診断結果を送信する、送信部を有する構成としてもよい。この送信部は、複数の機器へ予兆診断部の診断結果を送信するものである。

【0083】

また、機器と機器の管理者が所有する携帯端末のいずれかまたはその両方には、送信部からの情報を受信する受信部を有し、受信部から受信した情報を基に、検知内容を表示する表示部をする構成としてもよい。なお、送信部から受信部が受信する情報には、前期予兆診断部の診断結果とともに、修理依頼推奨期間が含まれていることが好ましい。

【0084】

また、運転情報から機器が故障したことを検知する、故障診断部を有する構成としてもよい。この場合、故障診断部の検知した内容と、予兆診断部の検知した内容は異なる表示とする。なお、機器の安定稼働を支援する予兆診断システムの診断対象機器は、家電機器でも、ヒートポンプ装置でも、業務用機器であってもよい。