JP2021139615A - 機器管理システム - Google Patents

Abstract

【課題】機器の異常発生時に機器が停止した場合であっても、機器の応急運転が可能でユーザの応急運転が可能な場合がある。しかし、過度の応急運転をすると、機器をさらに損傷させる恐れがある。【解決手段】機器管理システム（１、１ａ）は、機器で発生した異常に対応付けて機器の修理に関する情報を記憶する記憶部（１１）と、機器の修理に関する情報を取得し、前記記憶部に書き込む取得部（１２）と、応急運転の運転内容を決定する運転内容決定部（１３）とを備え、前記機器の修理に関する情報は、前記機器の異常に対する修理依頼の情報を含み、前記運転内容決定部は、前記修理依頼の有無に応じて前記応急運転の運転内容を決定する。【選択図】図３

Description

機器の異常発生時の応急運転方法に関する。

特許文献１は、空気調和機が異常により停止した際に、遠隔操作により応急運転を行うことを開示している。これによって、修理作業員が異常を示した機器のところに行かなくても、応急運転が実施され、ユーザの快適性が担保される。

機器に異常が発生した場合に、修理を行わずに応急運転を長期間継続した場合、機器にとってダメージを与える場合も起こりうる。

第１観点の機器管理システムは、機器の異常発生時に応急運転が可能か否かを判定し、可能な場合は応急運転を実施する。機器管理システムは、記憶部と、取得部と、運転内容決定部とを有する。記憶部は、機器で発生した異常に対応付けて機器の修理に関する情報を記憶する。取得部は、機器の修理に関する情報を取得し、記憶部に書き込む。運転内容決定部は、応急運転の運転内容を決定する。機器の修理に関する情報は、機器の異常に対する修理依頼の情報を含む。運転内容決定部は、修理依頼の有無に応じて応急運転の運転内容を決定する。

第１観点の機器管理システムは、修理依頼の有無に応じて応急運転の運転内容を決定するので、機器に損傷を与えるほど応急運転をしてしまうリスクを下げることができる。

第２観点の機器管理システムは、第１観点のシステムであって、運転内容決定部は、修理依頼が有るときは、応急運転の実施を決定する。修理依頼が有るときは、応急運転の期間もだいたい決まっているので、応急運転を実施しても機器に損傷を与えるリスクが少ない。

第３観点の機器管理システムは、第１観点又は第２観点のシステムであって、運転内容決定部は、修理依頼が無いときは、応急運転を実施する場合は、修理依頼が有るときよりも短期間の応急運転の実施を決定するか、または、応急運転の不実施を決定する。

第４観点の管理システムは、第１観点のシステムであって、運転内容決定部は、修理依頼が有るときは、機器が高い能力を出す高能力運転の実施を決定し、修理依頼が無いときは、機器が、高能力運転よりも低い能力を出す低能力運転の実施を決定する。

第５観点の機器管理システムは、第１観点〜第４観点のシステムであって、運転内容決定部は、修理予定日時までの時間に応じて、応急運転の運転内容を決定する。

第６観点の機器管理システムは、第１観点〜第５観点のシステムであって、運転内容決定部は、季節に応じて、応急運転の運転内容を決定する。

第７観点の機器管理システムは、第１観点〜第６観点のシステムであって、機器の修理に関する情報は、機器の運転データを含む。運転内容決定部は、機器の運転データに応じて、応急運転の運転内容を決定する。

第８観点の機器管理システムは、第１観点〜第７観点のシステムであって、機器は空気調和装置である。空気調和装置は室内機と室外機とを有する。室外機は圧縮機を含む。応急運転の運転内容としては、圧縮機の運転周波数、稼働される圧縮機数、稼働される室外機の数、室内機の設定温度、室内機の風量、室内機の風向、応急運転の期間、からなる群から一つまたはそれらの組み合わせを含む。

第９観点の機器管理システムは、第１観点〜第８観点のシステムであって、機器で発生した異常に関する異常情報を出力する出力部をさらに備える。出力部は、応急運転の実施状況および／または修理依頼状況に応じた異常情報を出力する。

第１０観点の機器管理システムは、第１観点〜第９観点のシステムであって、決定された応急運転の内容に基づいて応急運転を実行する実行部をさらに有する。

第１１観点の機器管理システムは、第１観点のシステムであって、機器を制御する制御部をさらに備える。制御部は、機器の異常発生時に、機器の運転を停止し、機器のユーザに第１の報知を行う。制御部は、さらに、機器の運転を停止した後で、機器を修理する前に応急運転を開始するときは、機器の通常の運転開始するときとは別の起動操作をユーザに要求する。

第１１観点の機器管理システムは、応急運転開始時に機器の通常の運転開始するときとは別の起動操作をユーザに要求するので、ユーザは修理依頼をしようという動機を高められる。

第１２観点の機器管理システムは、第１１観点のシステムであって、起動操作は、ボタン操作またはバルブ操作である。

第１３観点の機器管理システムは、第１１観点または第１２観点のシステムであって、制御部は、機器の応急運転開始後に機器のユーザに第２の報知を行う。

第１３観点の機器管理システムにおいては、ユーザは繰り返し報知を受けるので、修理依頼をしようという動機を高められる。

第１４観点の機器管理システムは、第１１観点〜第１３観点のいずれかのシステムであって、制御部は、第１の報知または第２の報知において、ユーザに早期修繕の許可を求め、許可を促し、ユーザが修理依頼に応答した内容を、修理業者に連絡する。

第１５観点の機器管理システムは、第１４観点のシステムであって、制御部は、修理業者から機器の複数の修理可能日時を入手し、第１の報知または第２の報知のとき、複数の修理可能日時を提示し、ユーザに修理可能日時を選択させることにより、修理日時を決定する。

第１５観点の機器管理システムは、複数の修理可能日時を提示されるので、ユーザは比較的容易に修理依頼できる。

第１６観点の機器管理システムは、第１１観点〜第１５観点のいずれかのシステムであって、さらに、ディスプレイを備える。制御部は、第１の報知または第２の報知において、報知の内容をディスプレイに表示する。

第１７観点の機器管理システムは、第１６観点のシステムであって、制御部は、第１の報知のとき、または、第２の報知のときに、その内容とともに、機器の異常と判断した理由をディスプレイに表示する。

第１７観点の機器管理システムにおいては、ユーザは、機器の異常と判断した理由を知ることができるので、修理依頼の必要性が理解しやすい。

第１８観点の機器管理システムは、第１７観点のシステムであって、機器の異常と判断した理由は、機器のデータを含む。

第１および第３実施形態の機器管理システム１の概略構成図である。 第１実施形態の機器管理システム１の演算部１０の機能を説明する図である。 第１実施形態の機器２の例である空気調和装置２０の概略構成図である。 第１実施形態の機器管理システム１における機器２の運転制御方法を説明するフローチャートである。 第１および第２実施形態の機器管理システム１、１ａにおいて、ユーザに機器の修理、および、応急運転の申し込みを提示するディスプレイ３０の表示画面を示す。 第２実施形態の機器管理システム１ａの概略構成図である。 第２実施形態の機器管理システム１ａにおける機器２の運転制御方法を説明するフローチャートである。 第３実施形態の機器管理システム１における機器２の運転制御方法を説明するフローチャートである。 第３実施形態の機器管理システム１において、ユーザに機器の異常を報知するディスプレイ３０の表示画面を示す。

＜第１実施形態＞
（１）機器管理システム１とその周辺の構成
第１実施形態の機器管理システム１の概略構成を図１Ａに、機器管理システム１の演算部１０の機能を説明する図を図１Ｂに示す。機器管理システム１は、演算部１０と、記憶部１１と、ディスプレイ３０と、入力部１６とを備えている。演算部１０は、取得部１２と、運転内容決定部１３と、出力部１４と、実行部１５とを備えている。言い換えれば、機器管理システム１は、１または複数のコンピュータ１００である。演算部１０に含まれる取得部１２と、運転内容決定部１３と、出力部１４と、実行部１５とは、演算部１０の実行する機能を意味している。取得部１２と、運転内容決定部１３と、出力部１４と、実行部１５とは、複数の演算部１０またはコンピュータに分かれて配置されていてもよい。

演算部１０は、制御部と呼んでもよい。制御部は、機器２の運転を制御する。

本実施形態においては、機器管理システムプログラムは、記憶部１１に記憶され、演算部１０で実行される。

取得部１２は、機器２の運転データを取得する。運転には、通常運転、および、応急運転を含む。応急運転とは、機器２に異常が発生した場合に、通常運転よりも機器２の能力に制限を加えたうえで実行する運転である。機器２の運転データとは、機器２の全体、または、パーツの起動停止、機器２のモータの回転数、機器２に備えられたセンサの検知した測定値、などである。機器２の運転データには、機器２に発生した異常に関する情報を含む。また、取得部１２は、ユーザが入力部１６に入力した情報を取得する。取得部１２は、機器２の異常に関する情報および修理に関する情報を取得する。修理に関する情報には、機器の異常発生時にユーザが修理依頼する情報を含む。取得部１２は、取得した情報を記憶部１１に書き込む。

記憶部１１は、取得部１２の取得した機器２の運転データ、および、機器２の修理に関する情報を記憶する。

実行部１５は、機器２の応急運転を実行する。実行部１５は、機器２の通常運転を実行してもよい。

運転内容決定部１３は、機器２の応急運転の内容を決定する。運転内容決定部１３は、通常運転の内容を決定してもよい。

本実施形態の機器管理システム１は、さらに、出力部１４を含む。出力部１４は、異常情報を出力する。異常情報とは、機器で発生した異常に関する情報である。出力部１４の出力した異常情報は、ディスプレイ３０に表示される。ユーザは、ディスプレイ３０上で、異常情報を視認することができる。出力部１４は、さらに、修理申し込みボタン、応急運転申し込みボタン、修理依頼情報、または、応急運転の実施状況を出力してもよい。

入力部１６には、修理依頼または応急運転の依頼を、ユーザが入力をすることができる。

機器管理システム１は、機器２に接続されている。機器管理システム１は、機器２の運転を制御する。運転とは、通常運転、および、応急運転である。機器２の運転データは、機器管理システム１に伝えられる。

機器管理システム１は、さらに、ネットワークを介して、機器管理会社のサーバー６０に接続されている。サーバー６０は、コンピュータであり、プロセッサーと記憶部とを含んでいる。サーバー６０には、機器２の情報、機器２の運転データなどが記憶されている。サーバー６０には、さらに、機器管理会社の保守サービス派遣可能スケジュールも記憶されている。

機器管理会社の端末５０は、ネットワークに接続されている。機器管理会社の端末５０は、ネットワークを介してサーバー６０にアクセス可能である。機器管理会社の端末５０の利用者は、サーバー６０にアクセスすることによって、サーバー６０に保守管理サービスの出張可能日時を記憶させること、または、コンピュータ１００の利用者が入力した保守管理サービス(修理依頼)の日時を確認することができる。

（２）機器２の例としての空気調和装置２０
機器２の例としての空気調和装置２０について図２を用いて説明する。本実施形態においては、空気調和装置２０は、複数の室外機２１ａ、２１ｂと、複数の室内機２２ａ、２２ｂ、２２ｃと、を含んでいる。空気調和装置２０は、単数の室外機、または／および、単数の室内機を含んでもよい。空気調和装置２０は、室内機２２ａ、２２ｂ、２２ｃの設置された部屋の空気調和を行う。空気調和とは、冷房、暖房等である。室内機２２ａ、２２ｂ、２２ｃは、空気調和する側、言い換えると冷房または暖房する側に設置され、室外機２１ａ、２１ｂは、熱源側に設置される。

室内機２２ａ、２２ｂ、２２ｃは、それぞれ、室内熱交換器、室内機の吹出し風量を制御するファン、風向を調整するフラップ、室内温度センサ（いずれも図示せず。）などを含んでいる。

室外機２１ａ、２１ｂは、それぞれ、室外熱交換、圧縮機（いずれも図示せず。）を含んでいる。

本実施形態の空気調和装置２０においては、機器２の通常運転時に機器２の異常が発生して機器２が停止した時に、異常の種類によっては、応急運転が可能である。たとえば、室外機２１ａの圧縮機に異常があるとき、応急運転として、室外機２１ａは停止したまま、室外機２１ｂの運転が可能である。室外機２１ａに複数の圧縮機がある場合には、応急運転として、異常の発生した圧縮機を停止させ、他の圧縮機を運転することにより、室外機２１ａの運転が可能である。また、異常の種類や程度によっては、応急運転として、異常の生じた圧縮機の運転周波数を一定値以下に制御した状態で運転することが可能である。

空気調和装置２０の室内機２２ａ、２２ｂ、２２ｃに異常が生じた場合も応急運転が可能である。たとえば、１室内に複数の室内機２２ａ、２２ｂが設置されている場合には、室内機２２ａに異常が生じたときに、応急運転として、室内機２２ａを停止した状態で、室内機２２ｂを運転することによって、室内の空気調和を行うことができる。この場合、室内の空気調和の能力は、１台停止している分は低下している。また、１台の室内機２２ａの異常であっても、異常の程度、状況によっては、制限能力下、室内機２２ａの応急運転が可能である。例えば、室内機２２ａのファンの風量を制限したり、冷房運転時の目標室温を高めにしたり、室内機２２ａのフラップが停止しているときは、風向きを一定にした状態で、応急運転が可能である。

（３）機器管理システム１による機器２の運転制御方法
機器２に異常が発生した場合の機器管理システム１による機器２の運転制御方法を、図３のフローチャートを用いて説明する。

まず、機器２に異常が発生したときに、機器２の運転が停止する。そして、ステップＳ１０１では、機器２に異常が発生した事と異常の内容に関する情報、および、機器２の運転が停止したとの情報を機器管理システム１は取得する。

次に、ステップＳ１０２では、機器管理システム１の出力部１４は、機器で発生した異常に関する異常情報をディスプレイ３０に出力する。同時に、出力部１４は、機器の修理申し込み画面、応急運転申し込み画面をディスプレイ３０に出力する（図４）。言い換えると、ディスプレイ３０に、修理申し込み画面、応急運転申し込み画面が表示される。

機器２が空気調和装置２０の場合の、ディスプレイ３０の、修理申し込み画面、応急運転申し込み画面の表示例を図４に示す。図４においては、ディスプレイ３０の表示画面に、異常情報３１、修理申し込みボタン３２、応急運転申し込みボタン３３が表示されている。異常情報３１とは、機器２に発生した異常の具体的内容を示すものである。修理申し込みボタン３２とは、このボタンをクリックすることにより、修理申し込み画面が表示され、ユーザはさらに修理申し込み画面に入力することにより、修理の申し込みが可能になる。ユーザは、修理申し込み画面で、入力部１６により修理の申し込みを行う。修理の申し込みが行われると、取得部１２が、修理依頼情報を取得し、記憶部１１に記憶する。ディスプレイ３０の表示画面で応急運転申し込みボタン３３とは、このボタンをクリックすることにより、応急運転の申し込みが可能になるボタンである。

ステップＳ１０３では、運転内容決定部１３はユーザの応急運転の依頼を受け付ける。そして、Ｓ１０３でユーザの応急運転の依頼が有ったときは、ステップＳ１０４に進み、運転内容決定部１３は、機器２の修理の依頼があったかどうか確認する。修理の依頼があったときは、ステップＳ１０５に応急運転を実施すると決定し、実行部１５は応急運転を実施する。ステップＳ１０４の修理の依頼が無かったときは、運転内容決定部１３は応急運転をしないと決定し、実行部１５は応急運転を実施しない。

（４）特徴
（４−１）
本実施形態の機器管理システム１は、ユーザからの応急運転の申し込みがあったとき、修理依頼があったか否かを判断する。そして、修理依頼の有無に応じて、応急運転の内容を決定する。

このように応急運転を制限することで、応急運転を過度の時間、または、過度の能力で実行することによって、機器にダメージを与えてしまうことを防止する。

（４−２）
本実施形態の機器管理システム１は、応急運転の申し込みがあったとき、修理依頼が無かったときは、応急運転を実施しない。これによって、確実に、機器へのダメージを防止する。

（５）変形例
（５−１）変形例１Ａ
第１実施形態においては、出力部１４は、機器で発生した異常に関する情報、応急運転の申し込み画面、機器の修理依頼画面等をディスプレイ３０に表示していた。変形例１Ａにおいては、出力部１４は、これらの情報をユーザの携帯端末に出力する。携帯端末とは、たとえば、スマートフォン、ノートＰＣ、タブレットなどである。この場合、入力部１６は、この携帯端末である。ユーザは修理依頼の申し込み、応急運転の申し込みを携帯端末を用いて行ってもよい。

＜第２実施形態＞
（６）第２実施形態の機器管理システム１ａの構成と動作
第２実施形態の機器管理システム１ａの構成を図５に示す。第２実施形態において、コンピュータ１００、サーバー６０などの構成は、基本的に、第１実施形態と同じである。異なる点は、機器管理システム１ａを実行するプログラムは、サーバー６０に格納され、サーバー６０において、実行される。機器２に直結したコンピュータ１００は、サーバー６０において実行されるプログラムをブラウザとして利用する。

次に、第２実施形態の機器管理システム１ａの制御フローについて、図６を用いて説明する。

機器管理システム１ａのコンピュータ１００は、第１実施形態と同様に、機器２の異常の発生と、その異常の内容、異常の発生により機器が停止したこと等の情報を取得する（Ｓ２０１）。この情報は、ネットワークを介して、コンピュータ１００からサーバー６０に伝達される。ほとんど同時に、機器２の異常情報は、ユーザにも伝達される。ユーザは、コンピュータ１００において、機器管理システム１ａの管理プログラムのブラウザを立ち上げる。ブラウザは、機器２の異常情報の取得により自動的に立ち上がってもよい。演算部１０は、ディスプレイ３０に、図４と同様に、機器２の異常情報を表示する。同時に、表示画面には、機器２の修理の申し込み画面を表示する（Ｓ２０２）。この表示には、機器の応急運転の申し込み画面も同時に表示してもよい（Ｓ２０２）。

機器管理システム１ａは、ユーザの機器２の修理依頼を受け付ける（Ｓ２０３）。修理依頼を受け付けたとき、機器管理システム１ａは、ユーザの申し込みと、機器管理会社のスケジュールとを勘案して、機器の修理日程を決定する。機器管理会社のスケジュールは、予めサーバー６０に記憶されていてもよいし、ユーザの申し込み日程を機器管理会社の端末５０にネットワーク経由で問い合わせて決定してもよい。または、サーバー６０は、常に、機器管理会社のスケジュールを把握しており、ユーザからの修理依頼があったときにユーザに表示してもよい。いずれにしても、ユーザからの機器２の修理の申し込みにより、機器管理システム１ａは、修理予定日時を決定する（Ｓ２０４）。決定された修理予定日時は、サーバー６０の記憶部に記憶される。

次に、ユーザは、ブラウザを利用して、応急運転の申し込みを行う（Ｓ２０５）。機器管理システム１ａは、修理予定日時に応じて、応急運転の内容を決定し（Ｓ２０６）、実行する（Ｓ２０７）。

機器２の修理の予定日時が決まっていないときは、応急運転を実施しない、または、応急運転を実施する場合も、機器の能力を大きく制限した運転を行う。修理の予定が決まっているときでも、その日時が現在よりかなり先の日時である場合、たとえば、１月先の場合には、機器の能力を非常に小さく制限して応急運転を行う。

一方、機器２の修理の予定が近日中たとえば、２日後に決まっている場合には、比較的、機器の能力の大きい状態で応急運転を行う。

機器管理システム１ａは、このように、機器２の修理の予定に応じた応急運転を実行することにより、ユーザの快適性を最大限確保しながら、異常を起こした機器２のダメージを大きくしないようにできる。

また、本実施形態においても第１実施形態と同様に、機器２の通常運転時、異常発生時および応急運転時の運転データは、記憶部１１に蓄積される。運転データは、サーバー６０に蓄積されてもよい。応急運転の運転内容は、機器２の異常の内容、または／および、機器２の運転データに基づいて決定されてもよい。

（７）第２実施形態の特徴
（７−１）
第２実施形態の機器管理システム１ａは、機器２を通常運転中に機器２に異常が発生し、機器２が停止したときに、修理予定日時に応じて、応急運転内容を決定し、応急運転を実行する。

第２実施形態の機器管理システム１ａは、修理予定日時に応じて応急運転の内容を決定するので、ユーザの利便性をなるべく損なわないで、機器２に与えるダメージが課題になることを防止することができる。

（８）変形例
（８−１）変形例２Ａ
第２実施形態では、機器管理システム１ａは、応急運転の内容を、機器２の修理予定日時が現在よりどれだけ先かで決定していた。変形例２Ａでは、機器の負荷やユーザの快適性も考慮する。具体的には、応急運転の内容を決定する際に、季節も考慮する。

たとえば、機器２が空気調和装置２０であるときに、夏季または冬季である場合は、機器の修理予定日が多少先であっても、機器の能力を比較的大きくした応急運転を行い。逆に、春季、秋季である場合は、同じ修理予定日であっても、機器の能力を比較的小さくした応急運転を行う。このように制御することにより、ユーザの快適性を最大限確保することができる。

（８−２）変形例２Ｂ
第２実施形態においては、機器管理システム１ａは、機器２で発生した異常に関する情報、応急運転の申し込み画面、機器の修理依頼画面等をディスプレイ３０に表示する。変形例１Ａにおいては、機器管理システム１ａは、これらの情報をユーザの携帯端末に出力する。携帯端末とは、たとえば、スマートフォン、ノートＰＣ、タブレットなどである。ユーザは修理依頼の申し込み、または／および、応急運転の申し込みを、携帯端末を用いて行ってもよい。

＜第３実施形態＞
（９）第３実施形態の機器管理システム１の構成
第３実施形態の機器管理システム１の構成は、図１Ａに示すように、第１実施形態の機器管理システム１の構成と同じである。したがって、ここでは、機器管理システム１の詳細な説明を省略する。ただし、演算部１０は、ここでは制御部１０と読み替える。そして、重複も含むが、第１実施形態の説明を以下に補足しておく。

制御部１０は、図１Ａに示すように、機器２に接続されている。制御部１０は、機器２に内蔵されていてもよい。制御部１０は、機器２を制御する。特に、制御部１０は、機器２の運転を制御する。ここで、運転とは、通常運転、および、応急運転である。

また、制御部１０は、機器２に設置された機器のデータを収集するためのセンサを制御する。センサとはたとえば温度センサである。

制御部１０は、センサの取得した機器２のデータを収集し、蓄積し、機器２の異常を判定してもよい。

ディスプレイ３０は、機器管理システム１すなわちコンピュータ１００の表示装置である。制御部１０は、ユーザに示すための情報をディスプレイ３０に表示させる。ユーザは、ディスプレイ３０を見ながら、コンピュータ１００の入力部１６に制御指令を入力する。入力部１６は、キーボード、マウス、タッチパネル、音声入力手段などの入力手段である。

そして、第１実施形態の「（２）機器２の例としての空気調和装置２０」で説明したように、ここでは、機器２は、空気調和装置２０である。空気調和装置２０は、冷房運転、暖房運転、除湿運転、換気運転が可能である。空気調和装置２０は冷媒を用いた冷媒回路を有している。冷媒回路には、図２に示すように、少なくとも１つの室外機２１ａと、複数の室内機２２ａ、２２ｂ、２２ｃが接続されている。室内機２２ａ、２２ｂ、２２ｃは、それぞれ、室内熱交換器と、室内膨張弁を有している。室外機２１ａは、圧縮機、アキュムレータ、室外熱交換器、過冷却熱交換器、主膨張弁、主膨張弁と過冷却熱交換器との間の配管と圧縮機の吸入側の配管とを接続するバイパス回路と、バイパス回路上の過冷却熱交換器の膨張弁とを備えている。

第３実施形態の機器管理システム１の構成は、別の形態であってもよい。例えば、制御部１０の機能の一部または全部は、サーバー６０にあってもよい。この場合、サーバー６０は、機器の運転データを取得、蓄積し、機器２の運転が異常か否かを判定してもよい。あるいは、第２実施形態で示したように、制御プログラムは、サーバー６０で実行され、機器２に直結したコンピュータ１００は、端末として用いてもよい。

また、別の形態では、変形例１Ａに記載したように、ユーザは携帯端末を所持し、ユーザへの報知は、携帯端末に付属のディスプレイに対して行ってもよい。ユーザの運転の起動操作は、携帯端末によって入力されてもよい。

（１０）第３実施形態の機器管理システム１による機器２の運転制御方法
第３実施形態の機器管理システム１による機器２の運転制御方法を、図７のフローチャートを用いて説明する。なお、ここで機器の異常として例示しているのは、冷媒漏洩である。また、機器２は空気調和装置２０であり、冷房運転を行っている場合である。

本実施形態の機器管理システム１は、冷媒漏れ量を常時監視している。ここで、冷媒漏れ量の指標としては、例えば、ＲＬＩまたはその変化量であるΔＲＬＩである。ＲＬＩとは、凝縮器の過冷却域と二相域のエクセルギの比である。冷媒の漏洩が発生することにより、ＲＬＩが減少する。

ＲＬＩ指標を計算することにより、例えば、１０％程度の冷媒が漏洩しても冷媒漏れを検出することができる。空気調和装置は初期値から通常２０％程度まで冷媒が失われても、正常運転を行うことができる。さらに、５０％を超え７０％の冷媒が失われても空調運転を行うことができる。このように冷媒漏れを起こして空調運転が行われている状態は、もちろん、５０％を超えるような冷媒漏れは圧縮機の負荷という点で好ましくはないが、ユーザに直ちに支障があるわけではなく、機器が冷媒漏れを検知していたとしてもユーザに放置されやすい。ましてや１０％や２０％程度の冷媒漏れは、空調能力の低下は少なく、機器への支障も少なく、また、従来は検知も困難であったので、放置されがちであった。しかし、冷媒漏れは地球環境への負荷を考えれば、好ましくない。たとえ、１０％や２０％であっても系が大きくなれば、大量の冷媒漏れにつながる。そして、冷媒漏れは、各国や国際的な規制上の問題を起こすことも起こりうる。

そこで、本実施形態においては、冷媒漏れを低減するために、システムの冷媒漏れをいち早く検知し、それによって、ユーザに早期の修理への動機づけを行うことを一つの目的としている。

図７の説明に戻る。

機器管理システム１は、冷媒漏れ量を常時監視しており、所定量、たとえば、１０％の冷媒漏れを取得する（Ｓ３０１）。なお、機器管理システム１は、冷媒漏れ量を検知してもよいし、直接検知しなくても、機器２の冷媒漏れを検知している他の装置から、冷媒漏れの情報を取得してもよい。いずれにしても制御部１０は、機器２の異常の情報を取得する。また、ここで、機器の異常とは、上述の冷媒漏れの場合に１０％〜２０％程度の冷媒漏れを含む。言い換えると、機器の運転に特に支障をきたさない異常も含む。

制御部１０は、機器２の異常の情報を取得した時は、機器２を停止させるか否かの判断を行い、停止させると決定した場合は、機器２の運転を停止させる（Ｓ３０２）。そして、運転を停止させた後、または、運転停止と前後して、ユーザに機器の異常を報知する（Ｓ３０３）。報知の時のディスプレイ３０の表示例を図８に示す。

図８は、まず、１行目で、異常発報のあった機器２を示している。具体的には、「ＩＤ：００１２３４５６ ○○ビル ＰＡＣ−１」と表示されている。次に、表示の左側の３行目から８行目は、異常の内容の項目を示している。各項目ごとに、緑（左側のランプ）、赤（右側のランプ）のどちらのランプが点灯しているかで、緑（正常）か赤（異常）かを示している。３行目は、「ＲＬＩ低下」で、「ＲＬＩ」の冷媒漏れパラメータが正常か否かを示している。図８では、ＲＬＩパラメータが異常に低下していることを示している。４行目は、「漏洩」を示すランプで、「ＲＬＩ低下」から、制御部１０が機器２について冷媒漏れを起こしていると判断していることを示している。図８では、これも赤ランプが点灯しており、冷媒漏れが発生していることを示している。次に、５行目は、「Ｔｂ」であり、室外熱交換器の出口温度が正常か異常かを示している。図８は「Ｔｂ」が正常であることを示している。次に、６行目は、「Ｔｓｈ」であり、バイパス回路上の過冷却熱交換器出口温度が正常か異常かを示している。図８は「Ｔｓｈ」が正常であることを示している。次に、７行目は、「ＥＶ２」であり、過冷却熱交換器の膨張弁開度が正常か異常かを示している。図８は「ＥＶ２」が正常であることを示している。次に、８行目は、「内ＥＶ」であり、室内膨張弁の開度が正常か異常かを示している。図８は「内ＥＶ」が正常であることを示している。

図８の表示の左側の緑（正常）か赤（異常）かを示すランプの下、９行目には、「冷媒漏洩です。」との表示がされている。これは、ユーザに異常が起こって機器の運転が停止された理由を端的に示している。

図８の表示の右側には、冷媒漏洩指標のＲＬＩの変化を示す、ΔＲＬＩの時間変化を示すグラフが示されている。そして、発報時刻に近い時間、言い換えると右端近傍において、ΔＲＬＩの低下を示す矢印が記載されている。

そして、そのグラフの下には、「修理と点検に伺わせてください。再起動には所定の操作が必要です。」と表示されている。「修理と点検に伺わせてください。」は、機器管理会社側からユーザに向かって、ユーザに早期修繕の許可を求め、または修理を行う許可を促す意図である。また、「再起動には所定の操作が必要です。」のメッセージは、ユーザが応急運転をする際に、通常とは別の起動操作を要求することをユーザに教える意図である。

次に、図８の１０行目〜１５行目、言い換えると、最も下部には、
１０行目：修繕前発報数 ：３回目(前回９月１０日）
１１行目：予想修理規模 ：フレア配管部接手交換4か所
１２行目：予想修繕時間 ：１．５時間弱
１３〜１４行目：修繕と点検に伺います。下記候補日のご都合はいかがでしょうか。ご承諾をお待ちしております。 電話番号06-6789-1234
１５行目：(1)９月２９日９時、(2)１０月４日９時、(3)１０月９日１５時」
の記載がある。

１０行目の記載は、発報回数を示している。制御部１０が機器２の異常の情報を最初に取得して（Ｓ３０１）、運転を停止し（Ｓ３０２）、ユーザに報知し（Ｓ３０３）、最初の応急運転を行う（Ｓ３０４，Ｓ３０５）を行うプロセスは、後で説明するように修理を行うまで繰り返す可能性がある。そこで、何回目の発報、報知であるのかを示すのが、この記載である。制御部１０が機器２の異常の情報を最初に取得して、ユーザに報知した場合は、「１回目」と記載されているはずである。図８では、「３回目」と表示されている。

１１行目の「予想修理規模」、１２行目の「予想修繕時間」は、制御部１０またはサーバー６０が異常の内容、異常の修理の内容を予測して記載したものである。

１３〜１５行目は、機器管理システム１からユーザに対して、修理依頼の提案である。１５行目は、制御部１０が、機器管理会社のサーバー６０または端末５０から機器２の複数の修理可能日時を複数取得し、ユーザに提示したものである。このような報知を受けたユーザは、提示された複数の修理可能日時から、ユーザの都合の良い修理可能日時を選択して、機器管理会社に連絡することにより、修理日時を決定することができる。

ステップＳ３０２で機器２は停止し、ステップＳ３０３で機器２の異常を報知されたユーザは、機器２の修理を依頼する場合も依頼しない場合も考えられるが、次に応急運転を行うことが多い。機器２の異常が、上述した比較的少量の冷媒漏れの場合のように、機器２の運転に大きな支障をきたさない場合には、制御部１０は、応急運転を許可する。

応急運転が可能な場合は、ユーザは応急運転の起動操作を行う。図８の機器２の報知例で説明したように、ユーザは応急運転（再起動）が可能であることを報知され、かつ、応急運転（再起動）には、通常の起動操作とは別の起動操作（所定の操作）が必要なことを知る。

別の起動操作の例としては、たとえば、ボタン操作、または、バルブ操作である。より具体的には、たとえば、次のＡ、Ｂ、Ｃである。
Ａ：室内機側面のカバーを開けてボタンを押す。
Ｂ：室内機内フィルター下に隠れているつまみ（このつまみは、オートバイのリザーブタンクのつまみと同様のもの）を９０°右に回す。
Ｃ：サービスセンターにボタン操作問い合わせ（リモコンの着色ボタンを支持順に押す。青々赤青黒．．．などである。

応急運転の起動操作としては、Ａ〜Ｃのように、通常の起動操作とは別の起動操作によって起動するようにしてもよいし、さらに通常の運転操作を加えて起動するものであってもよい。

ユーザは、このような通常の起動操作とは別の起動操作を行う（Ｓ３０４）。ユーザの起動操作を受けた制御部１０は、機器２の応急運転を開始する（Ｓ３０５）。

応急運転の内容は、第１実施形態の場合と同様に、ステップＳ３０３でユーザに機器の異常が報知され、同時に、図８の表示に示すように、修理依頼の問い合わせに対して、ユーザが修理依頼を行ったか否かによって、変更されてもよい。

機器管理システム１は、応急運転の開始後も機器の異常を監視し続ける。本実施形態の場合は、冷媒の漏洩を監視し続ける。冷媒漏れパラメータの監視を続ける。図７のフローチャートでは、ステップＳ３０５から、再び、ステップＳ３０１の前へ戻る。たとえば、冷媒漏れの場合は、冷媒が一度漏洩を始めると、修理しない限り、冷媒漏洩量は増加していくのが通常である。たとえば、１回目に１０％の冷媒漏洩で機器の運転停止を行った場合は、２回目は、応急運転中に、２０％の冷媒漏洩と判定されたときに、制御部１０は機器の異常と判定し（Ｓ３０１）、運転を停止させる（Ｓ３０２）。

ユーザが修理をしないで、応急運転を繰り返すと、制御部１０は、ステップＳ３０３でユーザへの発報を繰り返す。当然に図８のディスプレイ３０への表示の内容は、ユーザにより強く修理を促すものになる。

以上、本開示の実施形態を説明したが、特許請求の範囲に記載された本開示の趣旨及び範囲から逸脱することなく、形態や詳細の多様な変更が可能なことが理解されるであろう。

１、１ａ 機器管理システム
２ 機器
１０ 演算部
１１ 記憶部
１２ 取得部
１３ 運転内容決定部
１４ 出力部
１５ 実行部
１６ 入力部
２０ 空気調和装置
２１ａ、２１ｂ 室外機
２２ａ、２２ｂ、２２ｃ 室内機
３０ ディスプレイ
５０ 機器管理会社の端末
６０ サーバー
１００ コンピュータ

特開２００４−６９０８０号公報

Claims (18)

1. 機器（２）の異常発生時に応急運転が可能か否かを判定し、可能な場合は応急運転を実施する機器管理システム（１、１ａ）であって、
   前記機器で発生した異常に対応付けて前記機器の修理に関する情報を記憶する記憶部（１１）と、
   前記機器の修理に関する情報を取得し、前記記憶部に書き込む取得部（１２）と、
   応急運転の運転内容を決定する運転内容決定部（１３）と
   を備え、
   前記機器の修理に関する情報は、前記機器の異常に対する修理依頼の情報を含み、
   前記運転内容決定部は、前記修理依頼の有無に応じて前記応急運転の運転内容を決定する、
   機器管理システム。
2. 前記運転内容決定部は、前記修理依頼が有るときは、前記応急運転の実施を決定する、
   請求項１に記載の機器管理システム。
3. 前記運転内容決定部は、前記修理依頼が無いときは、前記応急運転を実施する場合は前記修理依頼が有るときよりも短期間の前記応急運転の実施を決定するか、または、前記応急運転の不実施を決定する、
   請求項１または２に記載の機器管理システム。
4. 前記運転内容決定部は、前記修理依頼が有るときは、前記機器が高い能力を出す高能力運転の実施を決定し、前記修理依頼が無いときは、前記機器が、前記高能力運転よりも低い能力を出す低能力運転の実施を決定する、
   請求項１に記載の機器管理システム。
5. 前記運転内容決定部は、修理予定日時までの時間に応じて、前記応急運転の運転内容を決定する、
   請求項１〜４のいずれか１項に記載の機器管理システム。
6. 前記運転内容決定部は、季節に応じて、前記応急運転の運転内容を決定する、
   請求項１〜５のいずれか１項に記載の機器管理システム。
7. 前記機器の修理に関する情報は、前記機器の運転データを含み、
   前記運転内容決定部は、前記機器の運転データに応じて、前記応急運転の運転内容を決定する、
   請求項１〜６のいずれか１項に記載の機器管理システム。
8. 前記機器は空気調和装置（２０）であり、前記空気調和装置は室内機（２２）と室外機（２１）とを有し、前記室外機は圧縮機（２３）を含み、
   前記応急運転の運転内容としては、前記圧縮機の運転周波数、稼働される圧縮機数、稼働される前記室外機の数、前記室内機の設定温度、前記室内機の風量、前記室内機の風向、前記応急運転の期間、からなる群から一つまたはそれらの組み合わせを含む、
   請求項１〜７のいずれか１項に記載の機器管理システム。
9. 機器で発生した異常に関する異常情報を出力する出力部（１４）をさらに備え、
   前記出力部は、前記応急運転の実施状況および／または修理依頼状況に応じた前記異常情報を出力する、請求項１〜８のいずれか１項に記載の機器管理システム。
10. 前記決定された応急運転の内容に基づいて前記応急運転を実行する実行部をさらに有する、
    請求項１〜９のいずれか１項に記載の機器管理システム。
11. 前記機器を制御する制御部（１０）をさらに備え、
    前記制御部は、前記機器の異常発生時に、前記機器の運転を停止し、前記機器のユーザに第１の報知を行い、
    さらに、前記制御部は、前記機器の運転を停止した後で、前記機器を修理する前に前記応急運転を開始するときは、前記機器の通常の運転開始するときとは別の起動操作をユーザに要求する、
    請求項１に記載の機器管理システム。
12. 前記起動操作は、ボタン操作またはバルブ操作である、
    請求項１１に記載の機器管理システム。
13. 前記制御部は、前記機器の応急運転開始後に前記機器のユーザに第２の報知を行う、
    請求項１１または１２に記載の機器管理システム。
14. 前記制御部は、前記第１の報知または前記第２の報知において、ユーザに早期修繕の許可を求め、許可を促し、ユーザが修理依頼に応答した内容を、修理業者に連絡する、
    請求項１１〜１３のいずれか１項に記載の機器管理システム。
15. 前記制御部は、前記修理業者から前記機器の複数の修理可能日時を入手し、前記第１の報知または前記第２の報知のとき、前記複数の修理可能日時を提示し、ユーザに修理可能日時を選択させることにより、修理日時を決定する、
    請求項１４に記載の機器管理システム。
16. 前記機器管理システムは、さらに、ディスプレイ（３０）を備え、
    前記制御部は、前記第１の報知または前記第２の報知において、報知の内容を前記ディスプレイに表示する、
    請求項１１〜１５のいずれか１項に記載の機器管理システム。
17. 前記制御部は、前記第１の報知のとき、または、前記第２の報知のときに、その内容とともに、前記機器の異常と判断した理由を前記ディスプレイに表示する、
    請求項１６に記載の機器管理システム。
18. 前記機器の異常と判断した理由は、前記機器のデータを含む、
    請求項１７に記載の機器管理システム。

Images