JP7320375B2 - 通知管理サーバ、保守支援システム、および、通知管理方法 - Google Patents

Description

本発明は、通知管理サーバ、保守支援システム、および、通知管理方法に関する。

家庭内で使用される電気機器に不具合が発生した場合、電気機器の操作部に設置されたＬＥＤを点滅させたり、液晶などのパネルに故障内容を示すコードを表示させたりすることにより、ユーザに不具合を知らせることが一般的であった。
不具合を認識したユーザは、取扱説明書を参考に対応方法を考える。また、自力で対応できないユーザは、製造元のコールセンターに電話をかけ、故障に対する対処方法をオペレータに聞いて、所定の操作を施して故障に対応する。重度な不具合の場合には、ユーザは、電気機器を修理に出す、または該当機器の専門知識を備えた保守員の出動を要請する。

修理依頼を受けた保守員は、ユーザ宅を訪問して電気機器を診断し、補修部品などを用いて電気機器を修理する。なお、補修部品はあらかじめ想定して用意する場合もある。しかし、想定していた補修部品では修理できない場合、保守員は、電気機器を持ち帰って自社または別の修理機関にて修理を行うか、または設備機器をユーザ宅に置いたまま後日別の修理部品を持参して修理していた。

このように、従来では電気機器の不具合を解消するためには多くの労力と時間を費やす必要があった。このような課題に対して、例えば、特許文献１に示される診断技術が提案されている。
特許文献１には、ユーザの電気機器から送信された使用情報を受信する情報受信部と、電気機器の性能または運転状態に関わる外部情報を取得する外部情報取得部と、使用情報と外部情報に基づいて利用者に通知する情報を決定する提示情報決定部とを備えた情報通知装置が開示されている。
特許文献１によれば、電気機器からネットワークを介しサーバに収集した情報を解析することで、機器単体の異常状態検知に留まらず、使用者の生活において最も効果的な他機器への置き換えの提案や効果的な使用方法を提示することを可能とする、としている。

国際公開第２０１８／００３１１０号

電気機器が所定の性能が発揮できない状態に陥る不具合には、ユーザが自力で対応できる軽度な不具合と、保守員の出動を要請する重度な不具合とがそれぞれ存在する。
例えば、一定の周期でユーザによるメンテナンス（掃除など）が前提となっている電気製品においてメンテナンスがなされていない場合や、ユーザによる製品仕様の範囲を超えた誤った使い方がなされた場合には、それぞれの適切な案内をすることでユーザが自力で対応できる。一方、実際に機器の構造上または制御上に問題が生じているときには、専門知識を備えた保守員の要請を行うなどの対応が必要となる。

しかし、特許文献１などの従来技術では、ユーザと保守員とを区別せず、不具合の診断情報を報知するだけにとどまる。よって、電気機器の内部構造を知らないユーザに対しても、電気機器を分解して問題部品の交換を指示するなどの無駄な時間と労力を費やしてしまっていた。つまり、ユーザは解析結果として提示された内容によっては、その後に保守員の要請を行うなどの余分な手間を行っていた。

そこで、本発明は、電気機器の不具合解決に要する時間を削減することを、主な課題とする。

前記課題を解決するために、本発明の通知管理サーバは、以下の特徴を有する。
本発明は、受信した電気機器の運転データを参照して、前記電気機器に発生した異常の要因を求める要因決定部と、
異常の要因ごとに、異常の要因を解決可能な通知先の端末と、その要因を解決するための所定情報とが対応付けられている通知データベースを参照して、前記要因決定部が求めた異常の要因に対応する前記通知先の端末を複数の候補から選択する通知先選択部と、
選択された前記通知先の端末に前記所定情報を送信することで、前記所定情報を異常の対応者に報知させる情報送信部と、を有しており、
前記通知データベースに登録されている前記通知先の端末は、前記電気機器のユーザの端末と、前記電気機器の修理を担当する保守員の端末とを含み、
前記ユーザの端末に対応付けられている前記所定情報は、前記電気機器のメンテナンスを促すための前記電気機器のメンテナンス情報と、誤った使用法を今後行わないように理解させるための前記電気機器の使用法情報とを含み、
前記保守員の端末に対応付けられている前記所定情報は、要因を対応させるための前記要因決定部が求めた異常の要因を含むことを特徴とする。
その他の手段は、後記する。

本発明によれば、電気機器の不具合解決に要する時間を削減することができる。

本発明の一実施形態に関する保守支援システムの構成図である。 本発明の一実施形態に関する通知管理サーバの詳細を示すブロック図である。 本発明の一実施形態に関する通知データベースの一例を示すテーブルである。 本発明の一実施形態に関する情報送信部のデータ処理を示すフローチャートである。 本発明の一実施形態に関する保守端末の表示画面例である。 本発明の一実施形態に関するユーザ端末の表示画面例である。

以下、本発明の一実施形態を、図面を参照して詳細に説明する。

図１は、保守支援システムの構成図である。
保守支援システムは、洗濯乾燥機１と、ユーザ端末２と、保守端末３と、通知管理サーバ４とが情報通信網９で接続されて構成される。保守支援システムの各機器の存在場所は、例えば、ユーザが保持する洗濯乾燥機１とユーザ端末２とはユーザ宅５に存在し、洗濯乾燥機１の専門家である保守員の所有物である保守端末３はサービスセンタに存在し、通知管理サーバ４はユーザ宅５から離れた遠隔監視センタに存在する。
ここで、洗濯乾燥機１の不具合の有無とその要因を解析する機能を、通知管理サーバ４が代行することにより、洗濯乾燥機１には高い計算機能を搭載しなくて済む。なお、洗濯乾燥機１は洗濯乾燥によって発生する振動などにより、高い計算機能を搭載するには不向きな筐体である。

洗濯乾燥機１は、定期的にユーザまたは保守員による機器の保守が行われる保守対象の電気機器の一例である。また、掃除機、冷蔵庫、空気調和機など他の電気機器を保守対象としてもよい。
洗濯乾燥機１には、通常の洗濯乾燥を行う機能の他、情報蓄積部１１と、情報送信部１２と、情報受信部１３と、家電側報知部１４とが備えられている。
ユーザ端末２は一般に入手可能な携帯端末であって、ここではユーザ所有のスマートフォンを想定している。ユーザ端末２には、予め洗濯乾燥機１専用のアプリケーションがインストールされている。また、ユーザ端末２には、情報演算部２１と、情報送信部２２と、情報受信部２３と、ユーザ側報知部２４とが備えられている。

ユーザは洗濯乾燥機１の使用中に不具合を感じた場合に、ユーザ端末２の洗濯乾燥機１専用のアプリケーションを介して、洗濯乾燥機１へデータの送信を要請する。この要請メッセージは、情報送信部２２から情報受信部１３に通知される。
このように、ユーザの要請に応じて洗濯乾燥機１の不具合要因を診断する構造としているため、洗濯乾燥機１は常時通知管理サーバ４と通信している必要はない。このため、ユーザの洗濯乾燥機１の使用環境に関わらず、ユーザ端末２さえあれば不具合の解決を容易にすることができる。

データ送信を要請された洗濯乾燥機１は、情報蓄積部１１に保存されている使用情報である運転データの少なくとも一部を情報送信部１２から情報受信部２３へ送信する。情報蓄積部１１には、洗濯乾燥機１での運転データが一定期間分保存されている。この運転データには、洗濯乾燥機１に関するセンサデータの瞬時値、制御値、設定値、運転モードなどが含まれる。なお、洗濯乾燥機１の運転データであるセンサデータは、複数種類のセンサの測定値を用いてもよい。

洗濯乾燥機１とユーザ端末２とのデータの送受信は有線での通信であっても良いが、配線を保有しない利点がある分情報通信網９を介した無線通信であるほうが好ましい。なお、データ送信を要請されたときにだけ運転データを送信する方式により、常時運転データを通知管理サーバ４へ送信する方式に比べデータ容量を抑えることができる。よって、洗濯乾燥機１自体の製造コストを削減できる。

ユーザ端末２で受信した運転データは、アプリケーション内の情報演算部２１においてデータ加工がなされる。このデータ加工とは受信した運転データを基に、性能の指標となる演算値や設定値、瞬時値などのデータへ変換するものであり、運転データの一部のデータのみの加工でもよい。以下、加工された後のデータを、加工データとする。
情報演算部２１は、例えば、時系列のセンサデータを読み込み、その最大値と最小値との組み合わせを加工データとする。このように、運転データから加工データに変換することで、運転データを送信するための通信量を適切に削減できる。
加工データはユーザ端末２の情報送信部１２から情報通信網９を介して通知管理サーバ４へ送信される。または、情報送信部１２は、運転データを加工しないで通知管理サーバ４へ送信してもよい。

通知管理サーバ４は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
通知管理サーバ４には、情報送信部４１と、情報受信部４２と、情報判定部４３と、要因決定部４４と、通知内容分類部４５とが備えられている。

情報受信部４２は、ユーザ端末２から加工データを受信する。
情報判定部４３は、加工データを解析し、洗濯乾燥機１に異常が発生しているか否かを判定する。なお、異常の定義は、洗濯乾燥機１の運転データをもとに任意に設定できる。例えば、あらかじめ定めた所定の性能が得られていないときに、異常が発生していると判定される。
要因決定部４４は、情報判定部４３において異常が発生していると判断された加工データに対して、その異常の要因を決定する。
通知内容分類部４５は、要因決定部４４が決定した異常の要因に基づき、異常を解決するための所定情報（通知内容）および通知先を分類する。つまり、通知内容分類部４５は、複数の通知先の候補から、通知先がユーザ端末２または洗濯乾燥機１であるユーザ用の報知と、通知先が保守端末３である保守員用の報知とをそれぞれ決定する。

保守端末３には予め洗濯乾燥機１専用のアプリケーションがインストールされていて、さらに情報受信部３１と、センタ側報知部３２とが備えられている。ここで、洗濯乾燥機１専用のアプリケーションは、ユーザ端末２と保守端末３とでは、同じものである必要はなく、その活用方法に合わせたバージョンを想定している。

図２は、通知管理サーバ４の詳細を示すブロック図である。
情報判定部４３は、異常度算出部４３ａと、異常モデル算出用データ４３ｂと、異常判定部４３ｃと、異常閾値データ４３ｄとを有する。通知内容分類部４５は、通知先選択部４５ａと、通知データベース４５ｂとを有する。

情報受信部４２が受信した加工データから、洗濯乾燥機１の異常を判定する情報判定部４３の処理の詳細を説明する。
異常度算出部４３ａは、異常モデル算出用データ４３ｂごとの換算値である異常度を算出する。そのため、想定される各異常モデルに基づくデータおよび演算値の変化傾向を関数化したものが、異常モデル算出用データ４３ｂとして備えられている。異常モデルとは、例えば、洗濯乾燥機１の各部品ごとに設定され、フィルタのモデル、ダクトのモデルなどである。
異常モデル算出用データ４３ｂは、例えば、加工データを引数とし、異常度を出力する異常モデルごとの関数として用意されたものである。この関数は、保守員の経験則や過去の運転データから機械学習されたものとして事前に入力される。

異常判定部４３ｃは、算出された異常度と異常閾値データ４３ｄの閾値とを比較し、閾値を超えていれば異常有と判定し、要因決定部４４に異常有を通知する。一方、異常判定部４３ｃは、比較結果が閾値を超えていなければ、異常無の応答を情報送信部４１からユーザ端末２の情報受信部２３に送信する。
要因決定部４４は、異常判定部４３ｃから異常有の判定結果を受け、その要因を決定する。例えば、要因決定部４４は、異常モデルごとに設けられた閾値と、異常度算出部４３ａが計算した異常度とを比較し、閾値を超過した異常度の異常モデルに対応する要因を決定する。
通知内容分類部４５の通知先選択部４５ａは、要因決定部４４が決定した要因に従って、通知内容および通知先を分類する。この分類処理には、通知データベース４５ｂに登録された要因ごとの内容が参照される。

以下、通知内容分類部４５が行った分類の一例を列挙する。
・情報受信部２３を介して通知される正常報知２３ａは、洗濯乾燥機１に異常が発生していないことをユーザに知らせるメッセージである。
・情報受信部２３を介して通知される案内報知２３ｂは、洗濯乾燥機１にユーザ自身がメンテナンスを行うことをユーザに知らせるメッセージである。または、案内報知２３ｂは、洗濯乾燥機１の適切な使用法をユーザに知らせるメッセージである。
・情報受信部２３を介して通知される手配中報知２３ｃは、洗濯乾燥機１の異常を修理する保守員を手配中であることをユーザに知らせるメッセージである。
・情報受信部３１を介して通知される要因報知３１ａは、洗濯乾燥機１に発生した異常の要因を保守員に知らせるメッセージである。

図３は、通知データベース４５ｂの一例を示すテーブルである。通知データベース４５ｂには、異常の要因ごとに、要因を解決可能な通知先と通知内容とを対応付ける。以下、通知内容の３つの分類を説明する。
（１）メンテナンス案内とは、案内報知２３ｂによりユーザ端末２からユーザに報知される。例えば、レコード番号「１」のフィルタ詰まりは、乾燥フィルタ詰まり、糸くずフィルタ詰まりなどであり、該当するフィルタの掃除手順を報知することで、現在の異常を回復させる（詳細は図６）。
（２）使用法案内とは、案内報知２３ｂによりユーザ端末２からユーザに報知される。洗剤を過剰に投入するなど、ユーザによる製品仕様の範囲を超えた使い方を注意することで、将来の異常を予防する。
（３）異常要因通知とは、要因報知３１ａにより保守端末３から保守員に報知される（詳細は図５）。報知内容は、例えば、機器の構造上または制御上に異常があることにより生じる不具合である。一例としては、センサ異常、ファンモータ異常などがこれに当たる。これに対しては、ユーザが不具合の要因が分かったとしても解決することは困難であり、専門知識を備えた保守員による修理が必要となる。

なお、通知データベース４５ｂには、１つの要因に対して１つの通知先が対応付けられるのが基本だが、複数の通知先を対応付けてもよい。例えば、番号「９」の要因「ダクト詰まり」に対しては、通知管理サーバ４が（３）異常要因通知を保守員に通知して、現状のダクト修理を促すとともに、（２）使用法案内をユーザに通知して、将来のダクト詰まりが発生しないように、正しい使用法の理解を促す。

また、通知データベース４５ｂには、異常の要因に応じた通知先に加えて、その通知先の人間に適した通知内容が登録されている。
例えば、機器の構造を知らないユーザに知らせる（１）メンテナンス案内と（２）使用法案内については、不具合の要因を直接知らせるよりは、今後どう対処すればよいかという案内を報知すればよい。
一方、機器の構造を熟知する保守員に知らせる（３）異常要因通知については、修理内容を細かく説明するよりも、不具合の要因を直接知らせるほうが効果的である。

図２に戻り、通知先選択部４５ａは、通知データベース４５ｂに基づいた分類により決定した通知内容および通知先を情報送信部４１に知らせる。情報送信部４１は、分類された通知内容および通知先をもとに、前記した各種報知用のメッセージ（正常報知２３ａ、案内報知２３ｂ、手配中報知２３ｃ、要因報知３１ａ）を作成し、該当する通知先に送信する。

以下、通知先での報知処理を説明する。ここでの「報知」とは対象とする人に通知内容を知らせる処理であり、例えば、画面表示、音声出力、ＬＥＤランプの点灯などが挙げられる。
洗濯乾燥機１の家電側報知部１４およびユーザ端末２のユーザ側報知部２４は、それぞれ情報送信部４１から通知されたユーザ報知用のメッセージ（正常報知２３ａ、案内報知２３ｂ、手配中報知２３ｃ）を、異常の対応者であるユーザに報知する。
保守端末３のセンタ側報知部３２は、情報送信部４１から通知された保守員報知用のメッセージ（要因報知３１ａ）を、異常の対応者である保守員に報知する。

図４は、情報送信部４１のデータ処理を示すフローチャートである。
情報送信部４１は、通知管理サーバ４の各処理部から、以下に列挙するデータを収集する（Ｓ１０１）。
・異常判定部４３ｃから収集した、異常の有無
・通知先選択部４５ａから収集した、異常の通知内容と通知先
・情報受信部４２から収集した、診断対象の洗濯乾燥機１の固体を認識するための機器番号
情報送信部４１は、Ｓ１０１の収集したデータから異常の有無を判定する（Ｓ１０２）。異常がない場合は、情報送信部４１は、ユーザ端末２へ正常である旨の正常報知２３ａを送信する（Ｓ１０３）。

異常がある場合は、情報送信部４１は、通知先に保守員があるか否かを判定する（Ｓ１０４）。通知先に保守員がなければ、情報送信部４１は、１つ以上の通知内容を含む案内報知２３ｂをユーザ端末２へ送信する（Ｓ１０５）。これにより、ユーザが解決可能な不具合が生じた場合には、ユーザが専門知識を備えた保守員を要請する必要はなく、ユーザ自身で解決することができる。

一方、通知先に保守員があれば、情報送信部４１は、通知内容と機器番号との組み合わせを１つ以上含む要因報知３１ａを保守端末３に送信する（Ｓ１１１）。これにより、ユーザが解決不可能な不具合要因に対しては、ユーザが保守員を要請せずにも、通知管理サーバ４を介して自動的に保守員への要請が完了する。よって、不具合解決に対するユーザの工数を減らすことができる。
さらに、保守員へ出動要請する際に、洗濯乾燥機１で発生している不具合の要因が伝達されているため、ユーザ宅５へ保守員がメンテナンスのために訪問した際にも、事前に不具合の要因を把握した状態で、効率的に対処できる。

そして、情報送信部４１は、通知内容が複数であるか否かを判定する（Ｓ１１２）。通知内容が１つであれば、情報送信部４１は、Ｓ１１１で保守員に要因報知３１ａした旨を、ユーザに手配中報知２３ｃとして通知する（Ｓ１１５）。
また、情報送信部４１は、通知内容が複数であり、かつ、そのいずれも通知先がユーザではない（Ｓ１１３，Ｎｏ）ときにも、同様に、ユーザに手配中報知２３ｃを通知する（Ｓ１１５）。

一方、通知内容が複数であり、その通知先の少なくとも１つがユーザである（Ｓ１１３，Ｙｅｓ）ときには、Ｓ１０５の案内報知２３ｂと、Ｓ１１５の手配中報知２３ｃとの双方をユーザ端末２へ送信する（Ｓ１１４）。この場合、ユーザ側での作業と、保守員側での作業とが分担されるので、ユーザ側には「一部の作業をユーザが行い、その他の作業を保守員で行う」ように通知することで、役割分担を把握させることができる。

図５は、保守端末３の表示画面例である。
保守端末３には、要因報知３１ａに従い要因ごとの異常度を成分表示したレーダーチャート２０１と、保守員の作業に役立つ案内欄２０２とが表示されている。案内欄２０２として、要因の異常度が高い順に修理する旨を例示したが、案内する修理の順序は、洗濯乾燥機１を分解したときに手前にある部品の順序など、さまざまなルールで決めてもよい。
この表示画面により、保守員は、ユーザ自身から直接口頭で要因を伺うよりも効率的に、洗濯乾燥機１の修理内容を把握できる。一方、ユーザ自身から要因を伺う場合には、不具合が発生した状況（投入した洗濯物の種類と量など）を再現する必要があり、ユーザにも負担を与えてしまう。

図６は、ユーザ端末２の表示画面例である。
ユーザ端末２には、ユーザが行うメンテナンスを示す案内報知２３ｂのガイド欄２１１と、手配中報知２３ｃによって保守員を手配したことを示す手配中報知欄２１２とが表示されている。
これにより、ユーザは、手配された保守員がユーザ宅５に到着するまでの間に、自分で解決できるガイド欄２１１のメンテナンス作業を実行できる。つまり、複数の要因をユーザと保守員とで分担して効率よく解決できる。

以上説明した本実施形態の保守支援システムでは、不具合の要因を解消可能な通知先へ通知することを主な特徴とする。そのため、通知管理サーバ４は、洗濯乾燥機１から出力される運転データを解析することにより不具合原因を特定し、専門家によるメンテナンスが必要な不具合と、顧客による対応可能な不具合とに分類する。そして、事前に用意された通知データベース４５ｂに基づき、ユーザ端末２だけ、保守端末３だけ、ユーザ端末２と保守端末３との双方など、不具合の要因に応じた通知先がその都度適切に選択される。

これにより、電気機器の保守作業の効率が向上する。例えば、ユーザ自身が解決可能な不具合は保守員に通知されず、保守員による専門的な解決法を要する不具合はユーザに通知されないことで、洗濯乾燥機１で発生した異常（不具合）の解決にかかる労力や時間を、総合的に減らすことができる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。
また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。
また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤカード、ＤＶＤ（Digital Versatile Disc）などの記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１ 洗濯乾燥機（電気機器）
２ ユーザ端末
３ 保守端末
４ 通知管理サーバ
５ ユーザ宅
９ 情報通信網
１１ 情報蓄積部
１２ 情報送信部
１３ 情報受信部
１４ 家電側報知部
２１ 情報演算部
２２ 情報送信部
２３ 情報受信部
２４ ユーザ側報知部
３１ 情報受信部
３２ センタ側報知部
４１ 情報送信部
４２ 情報受信部
４３ 情報判定部
４３ａ 異常度算出部
４３ｂ 異常モデル算出用データ
４３ｃ 異常判定部
４３ｄ 異常閾値データ
４４ 要因決定部
４５ 通知内容分類部
４５ａ 通知先選択部
４５ｂ 通知データベース

Claims (8)

1. 受信した電気機器の運転データを参照して、前記電気機器に発生した異常の要因を求める要因決定部と、
   異常の要因ごとに、異常の要因を解決可能な通知先の端末と、その要因を解決するための所定情報とが対応付けられている通知データベースを参照して、前記要因決定部が求めた異常の要因に対応する前記通知先の端末を複数の候補から選択する通知先選択部と、
   選択された前記通知先の端末に前記所定情報を送信することで、前記所定情報を異常の対応者に報知させる情報送信部と、を有しており、
   前記通知データベースに登録されている前記通知先の端末は、前記電気機器のユーザの端末と、前記電気機器の修理を担当する保守員の端末とを含み、
   前記ユーザの端末に対応付けられている前記所定情報は、前記電気機器のメンテナンスを促すための前記電気機器のメンテナンス情報と、誤った使用法を今後行わないように理解させるための前記電気機器の使用法情報とを含み、
   前記保守員の端末に対応付けられている前記所定情報は、要因を対応させるための前記要因決定部が求めた異常の要因を含むことを特徴とする
   通知管理サーバ。
2. 前記情報送信部は、異常の要因に対応する通知先として前記保守員の端末が選択された場合、前記保守員の端末に前記所定情報を送信するとともに、保守員に修理を手配中である旨を前記ユーザの端末に送信することを特徴とする
   請求項１に記載の通知管理サーバ。
3. 前記電気機器は、洗濯乾燥機であり、
   前記電気機器のメンテナンス情報に対応する前記異常の要因は、フィルタ詰まりと、排水トラップ詰まりとのうちの少なくとも１つであり、
   前記電気機器の使用法情報に対応する前記異常の要因は、洗濯モード選択エラーと、洗剤投入エラーと、ダクト詰まりとのうちの少なくとも１つであり、
   前記保守員の端末に通知する前記所定情報に対応する前記異常の要因は、ファンモータ異常と、サーミスタ異常と、水位センサ異常と、槽モータ異常と、ダクト詰まりと、弁切替異常とのうちの少なくとも１つであることを特徴とする
   請求項１に記載の通知管理サーバ。
4. 前記通知管理サーバは、さらに、前記電気機器に発生した異常の度合いを異常度として算出する異常度算出部を有しており、
   前記情報送信部は、前記所定情報として、要因ごとの異常度を成分表示したグラフと、要因の異常度が高い順に修理する旨を示す情報とを、前記保守員の端末に送信することを特徴とする
   請求項１に記載の通知管理サーバ。
5. 請求項１ないし請求項４のいずれか１項に記載の通知管理サーバと、前記電気機器と、前記通知先の端末とを含めて構成される保守支援システムであって、
   前記通知先の端末は、前記電気機器に要請メッセージを送信することで、前記通知管理サーバに送信する前記運転データを取得することを特徴とする
   保守支援システム。
6. 前記通知先の端末と前記電気機器との間の送受信は、無線通信により行われることを特徴とする
   請求項５に記載の保守支援システム。
7. 前記通知先の端末は、前記電気機器から取得した前記運転データから性能の指標となる演算値へのデータ変換処理により前記運転データを加工したデータを前記通知管理サーバに送信することを特徴とする
   請求項５に記載の保守支援システム。
8. 通知管理サーバは、要因決定部と、通知先選択部と、情報送信部と、を有しており、
   前記要因決定部は、受信した電気機器の運転データを参照して、前記電気機器に発生した異常の要因を求め、
   前記通知先選択部は、異常の要因ごとに、異常の要因を解決可能な通知先の端末と、その要因を解決するための所定情報とが対応付けられている通知データベースを参照して、前記要因決定部が求めた異常の要因に対応する前記通知先の端末を複数の候補から選択し、
   前記情報送信部は、選択された前記通知先の端末に前記所定情報を送信することで、前記所定情報を異常の対応者に報知させ、
   前記通知データベースに登録されている前記通知先の端末は、前記電気機器のユーザの端末と、前記電気機器の修理を担当する保守員の端末とを含み、
   前記ユーザの端末に対応付けられている前記所定情報は、前記電気機器のメンテナンスを促すための前記電気機器のメンテナンス情報と、誤った使用法を今後行わないように理解させるための前記電気機器の使用法情報とを含み、
   前記保守員の端末に対応付けられている前記所定情報は、要因を対応させるための前記要因決定部が求めた異常の要因を含むことを特徴とする
   通知管理方法。

Images