特開 2023-176974 管理装置、管理方法、管理プログラムおよび管理システム

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

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

(11)【公開番号】P2023176974

(43)【公開日】2023-12-13

(54)【発明の名称】管理装置、管理方法、管理プログラムおよび管理システム

(51)【国際特許分類】

   F04B 51/00 20060101AFI20231206BHJP

   F04B 49/10 20060101ALI20231206BHJP

【ＦＩ】

F04B51/00

F04B49/10 311

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022089601

(22)【出願日】2022-06-01

(71)【出願人】

【識別番号】000148209

【氏名又は名称】株式会社川本製作所

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100199565

【弁理士】

【氏名又は名称】飯野 茂

(74)【代理人】

【識別番号】100162570

【弁理士】

【氏名又は名称】金子 早苗

(72)【発明者】

【氏名】稲垣 裕大

(72)【発明者】

【氏名】飯見 一真

(72)【発明者】

【氏名】豊田 耕司

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

3H145

【Ｆターム（参考）】

3H145AA16

3H145AA23

3H145AA42

3H145BA41

3H145CA22

3H145CA24

3H145CA25

3H145EA11

3H145FA02

3H145FA16

3H145FA23

(57)【要約】

【課題】ポンプの状態を判定および予測すること。
【解決手段】本発明の一態様によれば、管理装置は、取得部と、判定部とを含む。取得部は、ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得する。判定部は、前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報とに基づいて、前記ポンプを含むポンプ装置の状態を判定する。
【選択図】 図１

【特許請求の範囲】

【請求項1】

ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得する取得部と、
前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報とに基づいて、前記ポンプを含むポンプ装置の状態を判定する判定部と、
を具備する管理装置。

【請求項2】

前記判定部は、
所定期間ごとに区分された前記運転履歴情報に関する第１給水パターンと、前記運転情報とが閾値以上乖離している場合、および
所定の値範囲ごとに区分された前記運転履歴情報に関する第２給水パターンと、前記運転情報とが閾値以上乖離している場合の少なくともどちらか一方であれば、前記ポンプ装置に異常があると判定する、請求項１に記載の管理装置。

【請求項3】

前記判定部は、
所定期間ごとに区分された前記運転履歴情報に関する第１給水パターンと、前記運転情報との乖離傾向、および
所定の値範囲ごとに区分された前記運転履歴情報に関する第２給水パターンと、前記運転情報との乖離傾向の少なくともどちらか一方に基づき、前記ポンプ装置の異常または故障を予測する、請求項１に記載の管理装置。

【請求項4】

前記所定期間は、時間帯ごと、曜日ごと、月ごとおよび年ごとの少なくともいずれか１つであり、
前記第１給水パターンは、前記所定期間に応じて複数に区分され、
前記判定部は、前記運転情報に含まれる期間に対応する第１給水パターンを用いる、請求項２または請求項３に記載の管理装置。

【請求項5】

前記第２給水パターンは、前記ポンプの負荷レベルに応じて複数に区分され、
前記判定部は、前記運転情報から得られる負荷レベルに対応する第２給水パターンを用いる、請求項２または請求項３に記載の管理装置。

【請求項6】

前記ポンプは、温度センサが接続されたインバータが搭載され、
前記負荷レベルは、前記温度センサで計測された温度の上昇率に基づき決定される、請求項５に記載の管理装置。

【請求項7】

前記取得部は、前記ポンプ装置が試験運転中または凍結防止運転中である場合に前記運転情報を取得する、請求項１に記載の管理装置。

【請求項8】

異常が発生した日時、前記異常の箇所および内容を正解データとし、前記異常が発生した日時よりも前の前記運転履歴情報および環境情報を入力データとして学習した学習済みモデルを格納する格納部と、をさらに具備し、
前記判定部は、前記運転情報を前記学習済みモデルに入力することで、異常が発生している箇所および内容、異常が発生すると想定される予測日時の少なくとも１つを含む推定結果を出力する、請求項１に記載の管理装置。

【請求項9】

ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得し、
前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報に基づいて、前記ポンプを含むポンプ装置の状態を判定する、管理方法。

【請求項10】

コンピュータを、
ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得する取得手段と、
前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報とに基づいて、前記ポンプを含むポンプ装置の状態を判定する判定手段として機能させるための管理プログラム。

【請求項11】

ポンプ装置と管理装置とを具備する管理システムであって、
前記ポンプ装置は、
ポンプと、
前記ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得する取得部と、
前記運転情報を前記管理装置に送信する送信部と、を具備し、
前記管理装置は、
前記運転情報を前記ポンプ装置から受信する受信部と、
前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報とに基づいて、前記ポンプ装置の状態を判定する判定部と、を具備する、
管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、給水装置の管理に関する。

【背景技術】

【0002】

昨今のポンプ装置のメンテナンス要員の人員不足により、ポンプ装置の遠隔監視が求められる。遠隔監視においては、ポンプ装置から取得できる情報量が多いほど、ポンプ装置の故障などの運転状態の推定精度が向上する。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかし、単純にセンサを増設することはコストアップにつながるため、できるだけコストを低減しつつ、ポンプ装置の運転状態の推定精度を向上させることが望まれる。
本発明は、ポンプの状態を判定および予測することを目的とする。

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

【0005】

本発明の一態様によれば、管理装置は、取得部と、判定部とを含む。取得部は、ポンプの運転に関するパラメータおよびセンサから取得されるセンサ値の少なくとも１つと、前記ポンプの運転時間とに関する運転情報を取得する。判定部は、前記運転情報と、前記ポンプの過去の運転情報を示す運転履歴情報とに基づいて、前記ポンプを含むポンプ装置の状態を判定する。

【発明の効果】

【0006】

本発明によれば、ポンプの状態を判定および予測することができる。

【図面の簡単な説明】

【0007】

【図1】本実施形態に係る管理システムの一例を示す図。

【図2】本実施形態に係るポンプ装置を示すブロック図。

【図3】運転情報の一例を示す図。

【図4】第１給水パターンの一例を示す図。

【図5】第２給水パターンの一例を示す図。

【図6】第１の実施形態に係る管理装置の第１判定例を示すフローチャート。

【図7】第１の実施形態に係る管理装置の第１判定例を示すフローチャート。

【図8】第２の実施形態に係る管理システムを示すブロック図。

【図9】第２の実施形態に係るネットワークモデルの学習例を示す図。

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

【0008】

以下、図面を参照しながら実施形態に係る管理装置、管理方法、管理プログラムおよび管理システムについて説明する。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

【0009】

図１は、本実施形態に係る管理システムを例示するブロック図である。図１に示すように、管理システムは、管理サーバ１、複数のポンプ装置３－ｎ（ｎはインデックス）および複数の端末５－ｎを含む。図１では、ｎが２である場合の構成を示しているが、これに限定する必要はなく、ｎは１以上であれば幾つでもよい。以下、特に区別しないときは単にポンプ装置３、端末５と記載することとする。管理システムは、ポンプ装置３の運転状態の判定、故障の予測などの運転状態の予測を管理サーバ１を用いて実行するシステムである。

【0010】

図１に示すように、管理サーバ１とポンプ装置３と端末５とは、ネットワークＮＷを介して、４Ｇ、５Ｇといった携帯通信網や、Ｗｉｍａｘなどの比較的遠距離の無線通信回線を介して接続される。また、ポンプ装置３と端末５とは、上述した無線通信回線に加え、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Near Filed Communication）、赤外線通信といった比較的近距離の無線通信手段により接続されることを想定する。なお、ポンプ装置３と端末５とは、ＵＳＢ（Universal Serial Bus）やケーブルによるＬＡＮ（Local Area Network）接続といった有線通信回線を介して接続されてもよい。

【0011】

管理サーバ１は、ＣＰＵ（Central Processing Unit）等のプロセッサ、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等のメモリ、表示機器、入力機器及び通信機器を有するコンピュータである。管理サーバ１は、複数のポンプ装置３に関する各種データを管理するためのＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、集積回路記憶装置等の大容量記憶装置を有する。当該大容量記憶装置をデータベースと呼ぶことにする。例えば、管理サーバ１は、ポンプ装置３に関する各種データをデータベースに記憶したり、ポンプ装置３の稼働状況を管理する。なお、管理サーバ１は、オンプレミスサーバに限らず、クラウドサーバであってもよい。

【0012】

ポンプ装置３は、例えば、建物に給水する機械装置（給水装置）である。ポンプ装置３は、例えば、水道本管に直結され、水道本管を流れる水を直接増圧し、建物に設けられた蛇口やシャワーヘッド等の供給先に給水する、いわゆる直結増圧型給水装置であるとする。なお、本実施形態に係るポンプ装置３の型は直結増圧型のみに限定されず、直結直圧型でもよいし、受水槽を利用する貯水槽水道型その他の如何なる型式でもよい。

【0013】

端末５は、点検作業員等のユーザが持ち運び可能な通信端末であり、例えば、ノートＰＣ、モバイル端末（スマートフォン、フィーチャーフォン、タブレット）が挙げられる。なお、端末５は、ポンプ装置３の管理専用に構成された通信デバイスであってもよい。端末５から、ポンプ装置３を制御可能としてもよく、例えば、ポンプ装置３を制御するためのアプリケーション（以下、制御アプリケーションともいう）が搭載されてもよいし、Ｗｅｂブラウザにアクセスし、Ｗｅｂブラウザに所定の値および操作を入力することにより、ポンプ装置３を制御可能としてもよい。

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

１・・・管理サーバ、２・・・ポンプ装置、３・・・ポンプ装置、５・・・端末、３０・・・制御盤、３１・・・近距離通信器、３２・・・遠距離通信器、３３・・・入力機器、３４・・・インバータ、３５・・・インタフェース、３６・・・表示機器、３７・・・記憶装置、３８・・・プロセッサ、６０・・・ポンプ部、９０・・・ネットワークモデル、９５・・・学習済みモデル、１０１・・・格納部、１０２・・・学習部、１０３・・・モデル実行部、３４１・・・センサ、３８１・・・取得部、３８２・・・生成部、３８３・・・判定部、３８４・・・通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】