ホーム > 特許ランキング > 株式会社新日本コンサルタント
▶ 株式会社新日本コンサルタントの特許一覧 ▶ 株式会社日水コンの特許一覧 ▶ エコモット株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022027685
(43)【公開日】2022-02-14
(54)【発明の名称】マンホールポンプの監視システム
(51)【国際特許分類】
G01M 99/00 20110101AFI20220203BHJP
F04B 51/00 20060101ALI20220203BHJP
【ＦＩ】
G01M99/00 A
F04B51/00
【審査請求】未請求
【請求項の数】1
【出願形態】ＯＬ
(21)【出願番号】P 2021124839
(22)【出願日】2021-07-29
(31)【優先権主張番号】P 2020128208
(32)【優先日】2020-07-29
(33)【優先権主張国・地域又は機関】JP
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（令和元年度国土技術政策総合研究所「下水道革新的技術実証事業（Ｂ－ＤＡＳＨプロジェクト）」委託研究、産業技術力強化法１７条の適用を受ける出願）
(71)【出願人】
【識別番号】515195440
【氏名又は名称】株式会社新日本コンサルタント
(71)【出願人】
【識別番号】397028016
【氏名又は名称】株式会社日水コン
(71)【出願人】
【識別番号】509042518
【氏名又は名称】エコモット株式会社
(74)【代理人】
【識別番号】110002996
【氏名又は名称】特許業務法人宮田特許事務所
(72)【発明者】
【氏名】阿曽 克司
(72)【発明者】
【氏名】堀 孝成
(72)【発明者】
【氏名】中村 元紀
(72)【発明者】
【氏名】服部 貴彦
(72)【発明者】
【氏名】水谷 智彦
(72)【発明者】
【氏名】谷裏 弘晃
(72)【発明者】
【氏名】松永 崇
(72)【発明者】
【氏名】庄内 道博
(72)【発明者】
【氏名】吉村 貴志
(72)【発明者】
【氏名】岩本 卓三
(72)【発明者】
【氏名】田川 哲哉
【テーマコード（参考）】
2G024
3H145
【Ｆターム（参考）】
2G024AD03
2G024BA12
2G024BA21
2G024BA22
2G024BA27
2G024CA30
2G024EA13
2G024FA06
2G024FA20
3H145AA01
3H145AA23
3H145AA40
3H145FA02
3H145FA16
(57)【要約】 （修正有）
【課題】維持管理費の効率化やコスト削減し、さらには現場作業員の負担の軽減するマンホールポンプ監視システムを提供する。
【解決手段】情報をクラウドシステムにより一元管理する統合監視クラウドシステム１と、ＡＩにより異常検知識別器を構築し異常の未然検知さらには劣化予測を行うＡＩエンジン搭載検知予測システム２と、統合監視クラウドシステム１に集積した情報を基にストックマネジメント計画の立案支援を図るストックマネジメント支援システム３と、を備える。
【選択図】図１
【解決手段】情報をクラウドシステムにより一元管理する統合監視クラウドシステム１と、ＡＩにより異常検知識別器を構築し異常の未然検知さらには劣化予測を行うＡＩエンジン搭載検知予測システム２と、統合監視クラウドシステム１に集積した情報を基にストックマネジメント計画の立案支援を図るストックマネジメント支援システム３と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
情報をクラウドシステムにより一元管理する統合監視クラウドシステムと、
前記情報を活用してＡＩにより異常検知識別器を構築し異常の未然検知さらには劣化予測を行うＡＩエンジン搭載検知予測システムと、
前記統合監視クラウドシステムに集積した情報を基にストックマネジメント計画の立案支援を図るストックマネジメント支援システムと、を備え、
前記統合監視クラウドシステムと前記ＡＩエンジン搭載検知予測システムと前記ストックマネジメント支援システムはいずれもクラウド上で実装構築されており、
前記ＡＩエンジン搭載検知予測システムは、ＩｏＴデバイスからのリアルタイム計測データを用いてリアルタイムで異常未然検知と劣化予測を行い、
前記統合監視クラウドシステムは、前記異常未然検知と劣化予測の情報を受け取って蓄積し、
前記ストックマネジメント支援システムは、前記統合監視クラウドシステムに蓄積された前記情報を基に状態監視によるストックマネジメント計画の適正な立案支援を図り、
前記ストックマネジメント計画と前記異常未然検知と劣化予測の情報は必要に応じて維持管理業者及び自治体に通知されることを特徴とするマンホールポンプの監視システム。
前記情報を活用してＡＩにより異常検知識別器を構築し異常の未然検知さらには劣化予測を行うＡＩエンジン搭載検知予測システムと、
前記統合監視クラウドシステムに集積した情報を基にストックマネジメント計画の立案支援を図るストックマネジメント支援システムと、を備え、
前記統合監視クラウドシステムと前記ＡＩエンジン搭載検知予測システムと前記ストックマネジメント支援システムはいずれもクラウド上で実装構築されており、
前記ＡＩエンジン搭載検知予測システムは、ＩｏＴデバイスからのリアルタイム計測データを用いてリアルタイムで異常未然検知と劣化予測を行い、
前記統合監視クラウドシステムは、前記異常未然検知と劣化予測の情報を受け取って蓄積し、
前記ストックマネジメント支援システムは、前記統合監視クラウドシステムに蓄積された前記情報を基に状態監視によるストックマネジメント計画の適正な立案支援を図り、
前記ストックマネジメント計画と前記異常未然検知と劣化予測の情報は必要に応じて維持管理業者及び自治体に通知されることを特徴とするマンホールポンプの監視システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マンホールポンプの異常未然検知や劣化予測情報の有効活用を目的とするマンホールポンプの監視システムに関する。
【背景技術】
【0002】
汚水を流すマンホールポンプは、全国に約４万７千基設置されている。多くのマンホールポンプを抱える中小自治体は、維持管理・ストックマネジメントにおいて、人材不足・財政難などの課題が顕在化している。これらを抜本的に改善するには、適正なストックマネジメントを実現することが必要で、「人」「モノ」「カネ」の３要素のマネジメントが必須となる。
マンホールポンプは、設置されている箇所毎に特有の挙動を示す場合が多い。そのため、施設の維持管理には、実際の流入量に応じた運転制御の見極め・実行、緊急出動対応などに対して、判断可能な特別な技能を有する熟練した技術者が24時間365日体制にて対応している。このような技術者は、近年の人口減少により高齢化が進んでおり、減少傾向が強くなっている。また、次世代技術者の確保・育成が必要となるが、次世代技術者についても地方都市では確保が困難である。このため、技術的な精度を確保した持続可能な下水道管理を行う仕組みが必要となる。
マンホールポンプの維持管理においては、日常的な点検を実施しても、異常・故障を予測することは困難なことから、事象発生対応型（事後保全型）による対応が主である。このため、計測機器の設置等によるマンホールポンプ及び機材の異常・故障の早期検知を実施することで、資機材の効率的な運用によるリスクを緩和し、状態監視保全（予防保全型）への管理にシフトする必要がある。
ストックマネジメント計画の現状では、点検対象施設の抽出、点検時期の見極め及び更新時期の予測が困難なため、団塊期に整備した施設の更新の平準化を図ることは困難であり、計画的な更新及び事業費の確保が難しい。事業費の確保が困難な自治体に至っては、今後下水道の使用制限措置などを取る必要性が高まっている。
このような事態を避けるために、予算の平滑化を図り事業計画を容易に立案することが必要となる。
日常及び定期点検情報は、ペーパーにて民間委託業者より管理者（維持管理部署）へ報告され、維持管理部署においてのみ共有・保管されていることから、計画的な点検・更新計画を策定するための基礎情報として有益に活用されていない。このことから、下水道事業として非効率な運営となっており事業費の確保が難しくなることが想定されること踏まえ、今後効率的に運営を図る必要がある。
マンホールポンプは、設置されている箇所毎に特有の挙動を示す場合が多い。そのため、施設の維持管理には、実際の流入量に応じた運転制御の見極め・実行、緊急出動対応などに対して、判断可能な特別な技能を有する熟練した技術者が24時間365日体制にて対応している。このような技術者は、近年の人口減少により高齢化が進んでおり、減少傾向が強くなっている。また、次世代技術者の確保・育成が必要となるが、次世代技術者についても地方都市では確保が困難である。このため、技術的な精度を確保した持続可能な下水道管理を行う仕組みが必要となる。
マンホールポンプの維持管理においては、日常的な点検を実施しても、異常・故障を予測することは困難なことから、事象発生対応型（事後保全型）による対応が主である。このため、計測機器の設置等によるマンホールポンプ及び機材の異常・故障の早期検知を実施することで、資機材の効率的な運用によるリスクを緩和し、状態監視保全（予防保全型）への管理にシフトする必要がある。
ストックマネジメント計画の現状では、点検対象施設の抽出、点検時期の見極め及び更新時期の予測が困難なため、団塊期に整備した施設の更新の平準化を図ることは困難であり、計画的な更新及び事業費の確保が難しい。事業費の確保が困難な自治体に至っては、今後下水道の使用制限措置などを取る必要性が高まっている。
このような事態を避けるために、予算の平滑化を図り事業計画を容易に立案することが必要となる。
日常及び定期点検情報は、ペーパーにて民間委託業者より管理者（維持管理部署）へ報告され、維持管理部署においてのみ共有・保管されていることから、計画的な点検・更新計画を策定するための基礎情報として有益に活用されていない。このことから、下水道事業として非効率な運営となっており事業費の確保が難しくなることが想定されること踏まえ、今後効率的に運営を図る必要がある。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１９－０２０２６４
【特許文献2】特開２０１６－０１８５２６
【特許文献3】特開２０１６－０１２１５８
【特許文献4】特開２０１２－０３８２９８
【発明の概要】
【発明が解決しようとする課題】
【0004】
そこで本発明は、上記事情に鑑みて、維持管理費の効率化やコスト削減し、さらには現場作業員の負担を軽減するマンホールポンプの監視システムの提供を目的とする。
【課題を解決するための手段】
【0005】
上記目的を達成するために本発明に係るマンホールポンプの監視システムは、情報をクラウドシステムにより一元管理する統合監視クラウドシステムと、前記情報を活用してＡＩにより異常検知識別器を構築し異常の未然検知さらには劣化予測を行うＡＩエンジン搭載検知予測システムと、前記統合監視クラウドシステムに集積した情報を基にストックマネジメント計画の立案支援を図るストックマネジメント支援システムと、を備え、前記統合監視クラウドシステムと前記ＡＩエンジン搭載検知予測システムと前記ストックマネジメント支援システムはいずれもクラウド上で実装構築されており、前記ＡＩエンジン搭載検知予測システムは、ＩｏＴデバイスからのリアルタイム計測データを用いてリアルタイムで異常未然検知と劣化予測を行い、前記統合監視クラウドシステムは、前記異常未然検知と劣化予測の情報を受け取って蓄積し、前記ストックマネジメント支援システムは、前記統合監視クラウドシステムに蓄積された前記情報を基に状態監視によるストックマネジメント計画の適正な立案支援を図り、前記ストックマネジメント計画と前記異常未然検知と劣化予測の情報は必要に応じて維持管理業者及び自治体に通知されることを特徴とするものである。
【発明の効果】
【0006】
本発明によれば、異常が発生する前の異常未然検知情報は、そのデータを一元管理する統合監視クラウドシステムを通じて維持管理業者及び最終的な責任者である自治体に送られる。そして、維持管理業者は異常が起こる前の所定時間を確保し、現場作業員の負担の軽減を図り、必要に応じて現地で補修修繕を行うことができる。また、前記劣化予測情報は、統合監視クラウドシステムに蓄積され管理され、さらには、ストックマネジメント支援システムにおいて劣化予測に関連するデータを受け取ることで、これをポンプの健全度評価やリスク検討等に活用することができ、各自治体との情報の共有化を図り、改築計画の精度の向上及び人材不足の解消並びに経費の削減など、効率的で且つ継続的な支援を図ることができる。
【図面の簡単な説明】
【0007】
【図1】マンホールポンプ監視システムの概略図である。
【図2】異常検知識別器のフローを示す説明図である。
【図3】オートエンコーダのネットワーク図である。
【図4】異常検知識別器による復元誤差と警報・緊急出動の関係を示すグラフである。
【図5】異常判定器の教師データの説明図である。
【図6】学習済みニューラルネットワークの評価データにおける異常と正常それぞれの正解数を示すグラフである。
【図7】ポンプ劣化予測のフローチャートである。
【図8】決定木の構造を示す説明図である。
【図9】決定木モデルによる分類結果を示すグラフである。
【図10】ポンプの余寿命を示すグラフである。
【図11】ストックマネジメント支援システムの説明図である。
【図12】APIによるデータ授受の説明図である。
【図13】マンホールポンプ監視システムの運用事例のグラフである。
【発明を実施するための形態】
【0008】
以下、本発明の実施形態にかかるマンホールポンプの監視システムについて、図面を参照しながら説明する。図１は本システムの概要を示す概略説明図である。本監視システムでは、３つの要素システム、すなわち、情報をクラウドシステムにより一元管理する統合監視クラウドシステム１、前記情報を活用してＡＩにより異常検知識別器２１を構築するＡＩエンジン搭載検知予測システム２、ストックマネジメント支援システム３からなるシステムを、クラウド環境上に構築する。各要素システムはそれぞれ独立しているが、互いに必要なデータを受け渡す仕組みを持つことで、一つの「クラウドＡＩシステム」として機能する。また、既存のマンホールポンプに取り付けた電流・絶縁抵抗（漏れ電流）状態を計測するＩｏＴデバイス５といった外部システム・外部機器からのデータを取り込み、利用する仕組みも備える前記ＡＩエンジン搭載検知予測システム２は、ＩｏＴデバイス５によるリアルタイム計測データを用いてマンホールポンプの異常の未然検知や劣化の予測を行う。そして、統合監視クラウドシステム１は、前記ＡＩエンジン搭載検知予測システム２による異常未然検知と劣化予測の情報を受け取って蓄積する。そして、ストックマネジメント支援システム３は、統合監視クラウドシステム１に蓄積された前記異常未然検知と劣化予測の情報を基に状態監視によるストックマネジメント計画の適正な立案支援を図る。そして、前記ストックマネジメント計画と前記異常未然検知と劣化予測の情報は、必要に応じて維持管理業者及び自治体に通知される。
【0009】
ＡＩエンジン搭載検知予測システム２によるマンホールポンプの異常未然検知は次のようにして行う。異常未然検知を行うためには、異常検知識別器の構築が必要である。異常検知識別器は、電流値の異常時データと正常時データを自動的に峻別するためのものである。図２は異常検知識別器のフローを示す説明図である。
【0010】
異常検知識別器を構築するためには、「異常」である状態の定義を行う必要がある。一般的には「異常」はあまり発生しておらず、リアルタイムモニタリングで得られる時系列データから「異常」の特徴を定義することは複雑で難しい。仮に「異常」が定義できたとしても、ほとんどの状態が「正常」に偏っていて、全状態に占める「異常」の割合（以下、異常確率とする）が非常に小さい。そのため、リアルタイムモニタリングで得られるデータから「正常」と「異常」を区別する識別器を作る場合、誤認する確率は異常確率よりも大きくなり、すべての出力を「正常」とする方がシステムとして高評価となってしまう可能性が高い。そこで、初めから無理にリアルタイムモニタリングで得られる時系列データから「異常」を定義せず、日報データまたはリアルタイムモニタリングで得られる時系列データから「正常」を定義して、その状態から逸脱した状態を「異常」と定義することでこれらの問題を回避する方法を採用した。「正常」を定義する方法として、入力データを再現するニューラルネットワーク（ノードを束ねた層や活性化関数の組み合わせによるネットワーク）であるオートエンコーダ（自己符号化器）を使用した。オートエンコーダは、正解データに入力データそのものを使うため教師なし学習に分類される。そして、オートエンコーダは、入力層及び出力層よりも小さい次元の中間層を有する３層以上のニューラルネットワークにおいて、入力特徴ベクトルと出力ベクトルとが同じ値になるように重み付けを決定する機械学習によって、入力データの特徴を次元圧縮により抽出する手法であって、ノイズ除去などデータの本質を獲得するために利用される。
【0011】
＜運転回数２４と運転時間２５の選出、データセットの作成＞
前記オートエンコーダの入力層に入力するデータの選定に当たり、既存の日報データに着目し収集を行った。しかしながら、日報データは、マンホールポンプの各施設においてポンプの属性等、記載項目が異なる等の理由により、すべてのデータを統一的に使用することはできない。例えば全国展開時に新たなポンプの形式や出力などの属性が発生すると、同じシステムが適用できず汎用性が確保できないことから、ポンプの属性等の汎用性を阻害する恐れのある項目を入力値に含めないこととした。そこで、マンホールポンプの一般的な運用で作成される各種日報の共通のデータ項目を割り出し、その中でポンプの正常又は異常に影響を及ぼすものとして、ポンプの毎時の「運転回数２４」と「運転時間２５」を選定し、この２つの指標を利用することにした。そして、オートエンコーダに入力するためのデータは、連続した２４時間分の、１時間毎の運転回数２４と運転時間２５のデータとした。そして、対象時刻から１時間後までの状態が正常または異常のいずれであるかを推定するために、対象時刻から２３時間前までの計２４時間分の運転回数２４と運転時間２５のデータセットを作成した。なお、運転回数２４と運転時間２５の２つの指標のみによってオートエンコーダによる算出結果に汎用性を持たせるために、過去何年にも亘る日報データを収集整理した。このデータセットをオートエンコーダに入力し、入力の復元を行う。
前記オートエンコーダの入力層に入力するデータの選定に当たり、既存の日報データに着目し収集を行った。しかしながら、日報データは、マンホールポンプの各施設においてポンプの属性等、記載項目が異なる等の理由により、すべてのデータを統一的に使用することはできない。例えば全国展開時に新たなポンプの形式や出力などの属性が発生すると、同じシステムが適用できず汎用性が確保できないことから、ポンプの属性等の汎用性を阻害する恐れのある項目を入力値に含めないこととした。そこで、マンホールポンプの一般的な運用で作成される各種日報の共通のデータ項目を割り出し、その中でポンプの正常又は異常に影響を及ぼすものとして、ポンプの毎時の「運転回数２４」と「運転時間２５」を選定し、この２つの指標を利用することにした。そして、オートエンコーダに入力するためのデータは、連続した２４時間分の、１時間毎の運転回数２４と運転時間２５のデータとした。そして、対象時刻から１時間後までの状態が正常または異常のいずれであるかを推定するために、対象時刻から２３時間前までの計２４時間分の運転回数２４と運転時間２５のデータセットを作成した。なお、運転回数２４と運転時間２５の２つの指標のみによってオートエンコーダによる算出結果に汎用性を持たせるために、過去何年にも亘る日報データを収集整理した。このデータセットをオートエンコーダに入力し、入力の復元を行う。
【0012】
＜オートエンコーダによる学習、復元誤差Ａの算出＞
オートエンコーダのネットワーク図を図３に示す。このオートエンコーダは次の６つの部位からなっている。なお、運転回数２４と運転時間２５では数値の取りうる幅が２桁程度異なることから、それぞれの入力処理を分離した。
オートエンコーダのネットワーク図を図３に示す。このオートエンコーダは次の６つの部位からなっている。なお、運転回数２４と運転時間２５では数値の取りうる幅が２桁程度異なることから、それぞれの入力処理を分離した。
【0013】
＜運転回数時系列の規格化部２７＞
運転回数入力ベクトルCIを48次元ベクトル{CI1_23, CI2_23, CI1_22, CI2_22, CI1_21, CI2_21, …, CI1_n, CI2_ｎ, …, CI1_2, CI2_2, CI1_1, CI2_1, CI1_0, CI2_0}とする。ここで、CI1,CI2はそれぞれ同一ポンプ所におけるポンプNo.1、ポンプNo.2を、_nは復元対象時刻からn時間前を表している。例えば、復元対象時刻が21時台とすると、CI2_23は前日の22時台（21時の23時間前）のポンプNo.2の運転回数４（回）を、CI1_0は当日21時台のポンプNo.1の運転回数４（回）を表す。通常、同一ポンプ所におけるポンプNo.1とポンプNo.2は交互に運転しているため、通常均等な値になると考えられる。このようなことから、ポンプNo.1とポンプNo.2の区別なく、全体の平均運転回数（回）を各値から減じ偏差を求め、偏差の絶対値の最大値で除することで規格化した。これにより、規格化後の運転回数入力ベクトルCI’の各要素の値域は{-1≦CI’(1,2)_n≦1}となる。
運転回数入力ベクトルCIを48次元ベクトル{CI1_23, CI2_23, CI1_22, CI2_22, CI1_21, CI2_21, …, CI1_n, CI2_ｎ, …, CI1_2, CI2_2, CI1_1, CI2_1, CI1_0, CI2_0}とする。ここで、CI1,CI2はそれぞれ同一ポンプ所におけるポンプNo.1、ポンプNo.2を、_nは復元対象時刻からn時間前を表している。例えば、復元対象時刻が21時台とすると、CI2_23は前日の22時台（21時の23時間前）のポンプNo.2の運転回数４（回）を、CI1_0は当日21時台のポンプNo.1の運転回数４（回）を表す。通常、同一ポンプ所におけるポンプNo.1とポンプNo.2は交互に運転しているため、通常均等な値になると考えられる。このようなことから、ポンプNo.1とポンプNo.2の区別なく、全体の平均運転回数（回）を各値から減じ偏差を求め、偏差の絶対値の最大値で除することで規格化した。これにより、規格化後の運転回数入力ベクトルCI’の各要素の値域は{-1≦CI’(1,2)_n≦1}となる。
【0014】
＜運転時間時系列の規格化部２８＞
運転時間入力ベクトルTIを48次元ベクトル{TI1_23,TI2_23,TI1_22,TI2_22, TI1_21,TI2_21,…,TI1_n,TI2_ｎ,…,TI1_2,TI2_2,TI1_1,TI2_1,TI1_0,TI2_0}とする。ここで、TI1,TI2はそれぞれポンプNo.1、ポンプNo.2を、_nは復元対象時刻からn時間前を表している。例えば、復元対象時刻が21時台とすると、TI2_23は前日の22時台（21時の23時間前）のポンプNo.2の運転時間５（秒）を、TI1_0は当日21時台のポンプNo.1の運転時間５（秒）を表す。通常、同一ポンプ所におけるポンプNo.1とポンプNo.2は交互に運転しているため、通常均等な値になると考えられる。このようなことから、ポンプNo.1とポンプNo.2の区別なく、全体の平均運転時間（秒）を各値から減じ偏差を求め、偏差の絶対値の最大値で除することで規格化した。これにより、規格化後の運転時間入力ベクトルTI’の値域は{-1≦TI’(1,2)_n≦1}となる。
運転時間入力ベクトルTIを48次元ベクトル{TI1_23,TI2_23,TI1_22,TI2_22, TI1_21,TI2_21,…,TI1_n,TI2_ｎ,…,TI1_2,TI2_2,TI1_1,TI2_1,TI1_0,TI2_0}とする。ここで、TI1,TI2はそれぞれポンプNo.1、ポンプNo.2を、_nは復元対象時刻からn時間前を表している。例えば、復元対象時刻が21時台とすると、TI2_23は前日の22時台（21時の23時間前）のポンプNo.2の運転時間５（秒）を、TI1_0は当日21時台のポンプNo.1の運転時間５（秒）を表す。通常、同一ポンプ所におけるポンプNo.1とポンプNo.2は交互に運転しているため、通常均等な値になると考えられる。このようなことから、ポンプNo.1とポンプNo.2の区別なく、全体の平均運転時間（秒）を各値から減じ偏差を求め、偏差の絶対値の最大値で除することで規格化した。これにより、規格化後の運転時間入力ベクトルTI’の値域は{-1≦TI’(1,2)_n≦1}となる。
【0015】
＜エンコーダ部２９＞
規格化した運転回数入力ベクトルCI’と運転時間入力ベクトルTI’をconcatinate関数で結合し、2×48行列P’を作成し、４層の畳込み層（畳込み（カーネルサイズ：3，マップ数：32）と活性化関数（LeakyReLU，Alpha:0.1）のセット）と２層の畳込み層（畳込み（カーネルサイズ：3，マップ数：16）と活性化関数（LeakyReLU，Alpha:0.1）のセット）の計６層を通すことで、16×2行列に圧縮（エンコード）した（圧縮率は1/3）。
規格化した運転回数入力ベクトルCI’と運転時間入力ベクトルTI’をconcatinate関数で結合し、2×48行列P’を作成し、４層の畳込み層（畳込み（カーネルサイズ：3，マップ数：32）と活性化関数（LeakyReLU，Alpha:0.1）のセット）と２層の畳込み層（畳込み（カーネルサイズ：3，マップ数：16）と活性化関数（LeakyReLU，Alpha:0.1）のセット）の計６層を通すことで、16×2行列に圧縮（エンコード）した（圧縮率は1/3）。
【0016】
＜デコーダ部２１０＞
エンコーダ部２９の出力した16×2行列を2層の逆畳み込み層（逆畳み込み（カーネルサイズ：5、マップ数：16）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：4、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：3、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：4、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）及び逆畳み込み層（逆畳み込み（カーネルサイズ：6、マップ数：2））の計6層を通し、48×2行列を出力する。
エンコーダ部２９の出力した16×2行列を2層の逆畳み込み層（逆畳み込み（カーネルサイズ：5、マップ数：16）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：4、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：3、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）、逆畳み込み層（逆畳み込み（カーネルサイズ：4、マップ数：32）と活性化関数（LeakyReLU、Alpha:0.1）のセット）及び逆畳み込み層（逆畳み込み（カーネルサイズ：6、マップ数：2））の計6層を通し、48×2行列を出力する。
【0017】
＜運転回数時系列の復元部２１１＞
デコーダ部２１０により生成した48×2行列の前半を48次元規格化運転回数出力ベクトルCO’として復元（規格化と逆の処理：残差の絶対値の最大値をかけて、平均値を足す）し、48次元運転回数出力ベクトルCOを得る。
デコーダ部２１０により生成した48×2行列の前半を48次元規格化運転回数出力ベクトルCO’として復元（規格化と逆の処理：残差の絶対値の最大値をかけて、平均値を足す）し、48次元運転回数出力ベクトルCOを得る。
【0018】
＜運転時間時系列の復元部２１２＞
デコーダ部２１０により生成した48×2行列の後半を48次元規格化運転時間出力ベクトルTO’として、復元（規格化と逆の処理：残差の絶対値の最大値をかけて、平均値を足す）し、48次元運転回数出力ベクトルTOを得る。
デコーダ部２１０により生成した48×2行列の後半を48次元規格化運転時間出力ベクトルTO’として、復元（規格化と逆の処理：残差の絶対値の最大値をかけて、平均値を足す）し、48次元運転回数出力ベクトルTOを得る。
【0019】
以上のオートエンコーダのネットワークに損失関数（HuberLoss）を適用し、オプティマイザーはAdam（α=0.001，β1=0.9，β2=0.999，ε=1e-8）を用いた。訓練用データ（4,346,997）と評価用データ（711,258）で、バッチサイズ64，2000エポックの訓練を行った。学習には、Nvidia社製DGX-Staion（GPU:TeslaV100）、深層学習フレームワークはSONY社製Neural Network Console version 1.6.7263.14761及びNNabla（Version 1.1.0, Build 190820052242）を用いた。
【0020】
上記のようなオートエンコーダに対し、過去２４時間分の運転回数２４と運転時間２５を入力し学習させると、オートエンコーダが、入力データと、オートエンコーダの出力（正常を表す）との差である復元誤差Ａを算出し、その復元誤差Ａがしきい値Ｄを超えた時間帯を正常と異なる運転である「異常」として定義し、当該時間帯を異常状態の時間帯データとして自動的に抽出した。なお、復元誤差Ａは、オートエンコーダへの入力データとオートエンコーダの出力との比であってもよい。また、この異常を区別するための復元誤差Ａのしきい値Ｄもハイパーパラメータである。しきい値Ｄの決定方法については、まず仮の「異常」を決めて、過去データ（緊急出動記録等）との突合せを行うことで、現実的なしきい値Ｄを決定した。
【0021】
ここで、オートエンコーダにIoT機能を有する電流計によるリアルタイムモニタリングで得られる時系列データ（運転回数２４と運転時間２５）を入力すると、リアルタイムモニタリングで得られる時系列データから、各時間帯について「正常」もしくは「異常」が出力される。すなわち、異常検知識別器によれば、日報データに限らず、リアルタイムモニタリングで得られる時系列データに対しても、復元誤差Ａを算出し、復元誤差Ａがしきい値Ｄを超えた時間帯を正常と異なる運転である「異常」として定義し、当該時間帯が異常状態の時間帯データとして自動的に抽出される。
【0022】
このように、オートエンコーダを用いて、２つの指標、すなわち、日報から容易に取得できる運転回数２４と運転時間２５のみの２つの指標で正常か異常かを簡単に判別できる異常検知識別器を構築した。過去の膨大なデータから、どのデータが正常か異常かを膨大な時間を掛けて人の手で突合しての判別は困難であるのに対し、上記のような異常検知識別器を構築すれば、オートエンコーダに前記２つの指標を入力するだけで、自動的に正常か異常の判別が可能になった。
【0023】
因みに、ポンプ異常による警報の代表的な例としては、定格電流の１～１．１倍を超えた値が３～５秒以上続いた場合の「ポンプ過負荷による発報」、ある一定時間（標準２０分）以上連続運転した場合の「ポンプ長時間運転による発報」、ポンプ毎にモータブレーカーによって検出される「ポンプ故障による発報」がいわゆる３大警報と言われ、異常全体の９５％を占めている。この過去の警報・緊急出動のデータを異常検知識別器に入力すると、図４に示すように、復元誤差Ａがしきい値Ｄとして設定した0.3を超過した部分が、警報・緊急出動に至った異常時に略合致しており、適時に異常検知がほぼ判定可能であることが分かった。ここで、図４において、横軸は時間の経過を表し、縦軸は復元誤差Ａを表している。図中の破線Ａは復元誤差Ａのしきい値Ｄを表している。また、黒丸Ｂは緊急出動した異常時を示し、白丸Ｃは緊急出動に至らなかった警報のみの異常時を示す。
なお、構築した異常検知識別器において緊急出動や警報に紐づかない異常を検知したのは、オートエンコーダが、通常のポンプの動きと異なる現象（例えば、不明水の流入、不定期排水等、従来見落とされていた異常）を捉えたものであると思料される。
なお、構築した異常検知識別器において緊急出動や警報に紐づかない異常を検知したのは、オートエンコーダが、通常のポンプの動きと異なる現象（例えば、不明水の流入、不定期排水等、従来見落とされていた異常）を捉えたものであると思料される。
【0024】
前記異常検知識別器により日報データの運転回数と運転時間から異常検知を行い、検知された異常データと、ＩｏＴデバイス５からリアルタイムで取得している電流値データとを結び付けることによって異常時の電流値データとして活用し、ポンプ異常の未然検知を行う。異常未然検知の方法は次に示す通りである。
【0025】
本実施例の異常未然検知方法は、現場作業員の夜間（18:00～翌日9:00の15時間を想定）の出動を軽減することを主な目的としている。そのためには、現在から15時間後までの間にポンプの異常が発生する予兆を捉えることが必要である。
本実施例では、教師データを作成してニューラルネットワークに入力し学習させることによって、予測検出期間内の異常確度計算器を作成し、異常確度計算器によって算出される、評価用基準時刻Ｒ２を始点とする予測検出期間Ｅ内にポンプ異常が起こる確度Ｊを以て、ポンプ異常の未然検知を行う。予測検出期間Ｅとは、ポンプ異常の発生の予測の対象となる、評価用基準時刻Ｒ２を始点とする一定期間のことであって、予測検出期間Ｅの長さは教師データの作成時に定めるものである。なお、以降において学習用基準時刻Ｒ１および評価用基準時刻Ｒ２とは、ともに各種イベントを代表する、例えば現在時刻や任意の判定時刻、ポンプの異常発生時刻等を指していて、学習用基準時刻Ｒ１は教師データの作成時に用いる時刻であり、評価用基準時刻Ｒ２は異常確度計算器の利用時にユーザーが指定する時刻のことである。また、教師データの作成において、ポンプの異常発生時刻とは、前記異常検知識別器によって検知された異常の発生時刻を指す。
本実施例では、教師データを作成してニューラルネットワークに入力し学習させることによって、予測検出期間内の異常確度計算器を作成し、異常確度計算器によって算出される、評価用基準時刻Ｒ２を始点とする予測検出期間Ｅ内にポンプ異常が起こる確度Ｊを以て、ポンプ異常の未然検知を行う。予測検出期間Ｅとは、ポンプ異常の発生の予測の対象となる、評価用基準時刻Ｒ２を始点とする一定期間のことであって、予測検出期間Ｅの長さは教師データの作成時に定めるものである。なお、以降において学習用基準時刻Ｒ１および評価用基準時刻Ｒ２とは、ともに各種イベントを代表する、例えば現在時刻や任意の判定時刻、ポンプの異常発生時刻等を指していて、学習用基準時刻Ｒ１は教師データの作成時に用いる時刻であり、評価用基準時刻Ｒ２は異常確度計算器の利用時にユーザーが指定する時刻のことである。また、教師データの作成において、ポンプの異常発生時刻とは、前記異常検知識別器によって検知された異常の発生時刻を指す。
【0026】
本実施例では、IoT機能を有する電流計（以降、IoT電流計と記す）を用いてリアルタイムで取得される電流値データを用いる。
本実施例におけるIoT電流計は、０．０５秒毎にサンプリングした電流値データを１分毎に１２００個ずつ送信するものである。
また、以降において電流値時系列データとは、前記電流値データが時刻毎に並んでいるデータ列のことであり、前記IoT電流計による電流値データから、本実施例では最短１分間隔（IoT電流計による電流値データ転送の最短間隔）の任意の学習用基準時刻Ｒ１または評価用基準時刻Ｒ２を終点として収集される。そして、１つの電流値時系列データは、学習用基準時刻Ｒ１または任意の評価用基準時刻Ｒ２を終点とした所定期間Ｐ（本実施例では24時間とする）分の、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データの列（本実施例では１４３８分刻分と１２０秒刻分の計２４時間分）として構成されている。
ここで、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データとはそれぞれ、IoT電流計が計測した１分間（本実施例では当該分刻の０秒から５９．９５秒まで）の電流値データ１２００個または1秒間（本実施例では当該秒刻の０秒から０．９５秒まで）の電流値データ２０個のうち、ポンプが運転した時刻（分刻または秒刻）の電流値データのみ、すなわち値がゼロ以外の電流値データについて、その電流値の合計をそのデータ数の合計で除することで平均した電流値データのことであり、毎分刻または毎秒刻を代表した電流値データを意味する。
そして、所定期間Ｐ分の、１分刻毎または1秒刻毎のポンプの運転時間平均の電流値データの列（電流値時系列データ）とは、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データが、所定時間Ｐ分連なったデータ列のことである。（本実施例では、1分刻毎の運転時間平均１４３８個ののち1秒刻毎の運転時間平均１２０個の連続した２４時間分のデータ列を用いた。）つまり、所定期間Ｐの長さが、異常確度計算器への入力データである電流値時系列データのデータ長となる。
本実施例におけるIoT電流計は、０．０５秒毎にサンプリングした電流値データを１分毎に１２００個ずつ送信するものである。
また、以降において電流値時系列データとは、前記電流値データが時刻毎に並んでいるデータ列のことであり、前記IoT電流計による電流値データから、本実施例では最短１分間隔（IoT電流計による電流値データ転送の最短間隔）の任意の学習用基準時刻Ｒ１または評価用基準時刻Ｒ２を終点として収集される。そして、１つの電流値時系列データは、学習用基準時刻Ｒ１または任意の評価用基準時刻Ｒ２を終点とした所定期間Ｐ（本実施例では24時間とする）分の、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データの列（本実施例では１４３８分刻分と１２０秒刻分の計２４時間分）として構成されている。
ここで、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データとはそれぞれ、IoT電流計が計測した１分間（本実施例では当該分刻の０秒から５９．９５秒まで）の電流値データ１２００個または1秒間（本実施例では当該秒刻の０秒から０．９５秒まで）の電流値データ２０個のうち、ポンプが運転した時刻（分刻または秒刻）の電流値データのみ、すなわち値がゼロ以外の電流値データについて、その電流値の合計をそのデータ数の合計で除することで平均した電流値データのことであり、毎分刻または毎秒刻を代表した電流値データを意味する。
そして、所定期間Ｐ分の、１分刻毎または1秒刻毎のポンプの運転時間平均の電流値データの列（電流値時系列データ）とは、１分刻毎または１秒刻毎のポンプの運転時間平均の電流値データが、所定時間Ｐ分連なったデータ列のことである。（本実施例では、1分刻毎の運転時間平均１４３８個ののち1秒刻毎の運転時間平均１２０個の連続した２４時間分のデータ列を用いた。）つまり、所定期間Ｐの長さが、異常確度計算器への入力データである電流値時系列データのデータ長となる。
【0027】
異常確度計算器とは、ポンプ異常が発生する時刻よりも前の電流値時系列データから、評価用基準時刻Ｒ２を始点とする予測検出期間Ｅ内にポンプが異常状態となる確からしさである確度Ｊを出力するものである。
異常確度計算器の構築は、ニューラルネットワークを用いて次のように行う。まずは、ニューラルネットワークに学習させる教師データを作成する。図５は教師データの説明図である。
異常確度計算器の構築は、ニューラルネットワークを用いて次のように行う。まずは、ニューラルネットワークに学習させる教師データを作成する。図５は教師データの説明図である。
【0028】
教師データは、電流値時系列データの集合である入力データと、その時のポンプの状態（正常または異常の別）から構成されており、入力データは、正常時データ５５と異常時データ５６からなる。正常時データ５５と異常時データ５６はともに、学習用基準時刻Ｒ１を所定期間Ｐの終点として収集された電流値時系列データから、それぞれ選別されたものである。
異常時データ５６は、ポンプの異常発生時刻に至るまでの予測検出期間Ｅ（本実施例では15時間とする）に所定期間Ｐの終点（学習用基準時刻Ｒ１）が含まれる電流値時系列データのことである。したがって実際のポンプ異常１ケースにつき、15時間×60分=900個の時刻をそれぞれ学習用基準時刻Ｒ１とする異常時データ５６が収集可能である。但し、これら900個のすべてのデータを使うと、判定される異常に占める当該異常ケースの寄与が高くなりすぎると考えられることから、ランダムに選択した25%程度（本実施例では225個）を採用する。
正常時データ５５は、収集した全ての電流値時系列データのうち異常時データ５６以外のもの、すなわち、所定期間Ｐの終点（学習用基準時刻Ｒ１）から予測検出期間Ｅ（本実施例では15時間とする）が経過するまでの間にポンプ異常が発生していない場合の電流値時系列データのことである。正常時データ５５の個数については、通常は異常発生数が少ないことから大量に収集可能であるが、異常時データ５６との識別能力を獲得するために異常時データ数の2倍程度（本実施例では異常時データ１件当たり正常時データ450個）を採用する。
上記を言い換えると、教師データは、所定期間Ｐの終点（学習用基準時刻Ｒ１）から予測検出期間Ｅ経過時点までの間に異常が発生したか否かの状態と、当該所定期間Ｐ分抽出された電流値時系列データとのセットが複数集まったデータ行列である。
異常時データ５６は、ポンプの異常発生時刻に至るまでの予測検出期間Ｅ（本実施例では15時間とする）に所定期間Ｐの終点（学習用基準時刻Ｒ１）が含まれる電流値時系列データのことである。したがって実際のポンプ異常１ケースにつき、15時間×60分=900個の時刻をそれぞれ学習用基準時刻Ｒ１とする異常時データ５６が収集可能である。但し、これら900個のすべてのデータを使うと、判定される異常に占める当該異常ケースの寄与が高くなりすぎると考えられることから、ランダムに選択した25%程度（本実施例では225個）を採用する。
正常時データ５５は、収集した全ての電流値時系列データのうち異常時データ５６以外のもの、すなわち、所定期間Ｐの終点（学習用基準時刻Ｒ１）から予測検出期間Ｅ（本実施例では15時間とする）が経過するまでの間にポンプ異常が発生していない場合の電流値時系列データのことである。正常時データ５５の個数については、通常は異常発生数が少ないことから大量に収集可能であるが、異常時データ５６との識別能力を獲得するために異常時データ数の2倍程度（本実施例では異常時データ１件当たり正常時データ450個）を採用する。
上記を言い換えると、教師データは、所定期間Ｐの終点（学習用基準時刻Ｒ１）から予測検出期間Ｅ経過時点までの間に異常が発生したか否かの状態と、当該所定期間Ｐ分抽出された電流値時系列データとのセットが複数集まったデータ行列である。
【0029】
今回の異常確度計算器の構築の対象としたポンプ施設は、島本郷・田島・永楽町の３つの施設であり、学習及び検証に利用した各施設における異常データは表１および表２に示す通りである。なお、表１および表２のような緊急出動時の修繕記録等から得られるポンプ異常の発生時刻と、その時刻に合致する、ＩｏＴ機能を有する電流計を用いてリアルタイムで取得している電流値データとを照らし合わせることによって、前記異常発生時刻におけるリアルタイムの電流値が、異常発生時の電流値データであることを知ることができる。
【表1】
【表2】
【0030】
教師データは以下のようにして、ニューラルネットワークに学習させる。
まず、Squeeze-and-Excitationブロックを多段にした多層SE構造によりマルチスケールで特徴が獲得しやすいニューラルネットワークをベースネットワークとして学習を開始し、AutoML/NASにより300～400個程度の学習済みニューラルネットワークを自動で作成する。AutoML/NASによる学習とは、ニューラルネットワークの学習において、一般にハイパーパラメータと呼ばれる技術者が設定するパラメータをソフトウエアで自動的に設定したり（AutoML）、ネットワーク構造を自動的に変更（NAS：ネットワーク構造自動検索）して、自動的にチューニング作業を進める機能の総称である。
ニューラルネットワークへの入力項目は、同一ポンプ場の異常３件以上を含む学習データと、ポンプの定格電流と、アラート設定値である。アラート設定値とは、既存システムにおけるアラートがポンプの定格電流の何倍で発報することになっているかを指す係数である。本発明の異常確度計算器は、対象ポンプにつき学習用の異常データが３件以上あれば構築が可能であるため、一般に大量のデータが必要であるといわれる深層学習において、異常データが少ない状況下でもデータを確保しやすい量であることから、有用性が非常に高いものである。
まず、Squeeze-and-Excitationブロックを多段にした多層SE構造によりマルチスケールで特徴が獲得しやすいニューラルネットワークをベースネットワークとして学習を開始し、AutoML/NASにより300～400個程度の学習済みニューラルネットワークを自動で作成する。AutoML/NASによる学習とは、ニューラルネットワークの学習において、一般にハイパーパラメータと呼ばれる技術者が設定するパラメータをソフトウエアで自動的に設定したり（AutoML）、ネットワーク構造を自動的に変更（NAS：ネットワーク構造自動検索）して、自動的にチューニング作業を進める機能の総称である。
ニューラルネットワークへの入力項目は、同一ポンプ場の異常３件以上を含む学習データと、ポンプの定格電流と、アラート設定値である。アラート設定値とは、既存システムにおけるアラートがポンプの定格電流の何倍で発報することになっているかを指す係数である。本発明の異常確度計算器は、対象ポンプにつき学習用の異常データが３件以上あれば構築が可能であるため、一般に大量のデータが必要であるといわれる深層学習において、異常データが少ない状況下でもデータを確保しやすい量であることから、有用性が非常に高いものである。
【0031】
こうして作られた300～400個の学習済みニューラルネットワークに表２の評価用データを入力し、正常／異常の正解数の組が最適なニューラルネットワークを選定する。なお、評価データの入力の際には、教師データに含まれてない異常発生日時の含まれる期間をそれぞれ評価用基準時刻Ｒ２として入力した。図６は学習済みニューラルネットワークの評価用データにおける異常と正常それぞれの正解数を示したグラフである。一般にすべてが正解となるような完全なニューラルネットワークは発見できないため、パレート最適解により現実的なニューラルネットワークを選定する。ポンプ施設の特性や現場の要望などを考慮し、見逃し低減を重視したニューラルネットワーク（図６中の一点鎖線の円内）か空振り低減（図６中の二点鎖線の円内）を重視したニューラルネットワークのどちらかを選定する。なお、ニューラルネットワークの選定にあたり各ニューラルネットワークの特性をグラフにより可視化する場合は、対数軸で表示することにより、正常／異常のデータ数が異なることによる見づらさを解消できる場合がある。以上のようにして、異常確度計算器が構築される。
また、選定したニューラルネットワークはパレート最適解であるので、実際に異常発報アプリケーションに組み込み使用する際には、入力データに含まれるノイズ等を原因とする確度Ｊの時間的なバラツキによる異常未然検知の不具合を抑えるため、異常発報アプリケーションの運用時に移動平均等の手法でノイズ除去し、確度Ｊを安定させる必要がある。なお、異常発報アプリケーションは、異常確度計算器により算出された確度Ｊの呼び出し、表示、他セクションへの受け渡し、および異常未然検知情報の発報等の機能を有するものである。
また、選定したニューラルネットワークはパレート最適解であるので、実際に異常発報アプリケーションに組み込み使用する際には、入力データに含まれるノイズ等を原因とする確度Ｊの時間的なバラツキによる異常未然検知の不具合を抑えるため、異常発報アプリケーションの運用時に移動平均等の手法でノイズ除去し、確度Ｊを安定させる必要がある。なお、異常発報アプリケーションは、異常確度計算器により算出された確度Ｊの呼び出し、表示、他セクションへの受け渡し、および異常未然検知情報の発報等の機能を有するものである。
【0032】
選定された学習済みニューラルネットワーク（異常確度計算器）は、俗に言う重みファイルとして、入力データである評価用基準時刻Ｒ２までの所定期間Ｐ分の電流値時系列データとともに異常発報アプリケーションに読み込まれて、当該マンホールポンプにおいて評価用基準時刻Ｒ２から前記予測検出期間Ｅ経過後までの間に異常が発生する確度Ｊを算出する。この確度Ｊに対して、前述のように移動平均等の手法で異常発報アプリケーションによりノイズ除去を行ったものを、最終異常確度Ｋとする。なお、本実施例では確度Ｊに対し１５時間の移動平均をとったものを最終異常確度Ｋとした。この最終異常確度Ｋがしきい値Ｔ（本実施例では60％とする）を超えたときに異常発報アプリケーションにより異常未然検知情報の発報を行うこととする。なお、本実施例では入力データとしてIoT機能を有する電流計によるリアルタイム計測結果を用い、30分毎に最終異常確度Ｋの算出を行った。
【0033】
次いで、構築した異常確度計算器の的中率について記載する。的中率の算定の定義は以下の通りである。既存システムのアラート発報以前の時刻帯において、最終異常確度Ｋが60%以上である異常検知(予報通知)があった場合を的中と判定する。既存システムのアラート発報に対して異常確度計算器による異常未然検知が的中した件数の割合を的中率とする。
上記表２の検証用データに対する、異常確度計算器の的中率は表３の通りである。８件の既存アラート発報のうち７件について的中となり、的中率は87.5%であった。
上記表２の検証用データに対する、異常確度計算器の的中率は表３の通りである。８件の既存アラート発報のうち７件について的中となり、的中率は87.5%であった。
【表3】
【0034】
なお、上記異常未然検知の各種設定値は、上記の実施例に限定されず、例えば、予測検出期間Ｅは15時間に限らず、15時間後までの各１時間単位のように、複数に分けてもよい。
【0035】
上記のようにして得られた異常未然検知情報は、そのデータを一元管理する統合監視クラウドシステム１を通じて維持管理業者６及び最終的な責任者である自治体７に送られる。そして、維持管理業者６は異常が起こる前の所定期間Ｐを確保し、必要に応じて現地で補修修繕を行うことができる。
【0036】
次に、マンホールポンプの劣化予測について説明する。
マンホールポンプ（以下、ポンプとする）の劣化予測のフローチャートS1～S9を図７に示す。本実施形態では、ポンプの寿命時期は、同種の設備であっても運転状況や環境等により分散することから、「ポンプの寿命は単なる時間経過ではなく、運転した仕事量に依存する」と仮定し、各ポンプの累積仕事量の変化からポンプ寿命を予測する。また、ＩｏＴデバイスを活用することでポンプのリアルタイムでの状態監視が可能となり、現地での点検作業を省力化するとともに、蓄積した計測データを用いて累積仕事量の変化の予測式である余寿命算定モデル７３を構築する。この余寿命算定モデル７３により将来的なポンプの限界累積仕事量（ポンプ寿命時点での累積仕事量）に達するまでの残り年数（余寿命）を算定し、将来的な更新時期を予測する。
マンホールポンプ（以下、ポンプとする）の劣化予測のフローチャートS1～S9を図７に示す。本実施形態では、ポンプの寿命時期は、同種の設備であっても運転状況や環境等により分散することから、「ポンプの寿命は単なる時間経過ではなく、運転した仕事量に依存する」と仮定し、各ポンプの累積仕事量の変化からポンプ寿命を予測する。また、ＩｏＴデバイスを活用することでポンプのリアルタイムでの状態監視が可能となり、現地での点検作業を省力化するとともに、蓄積した計測データを用いて累積仕事量の変化の予測式である余寿命算定モデル７３を構築する。この余寿命算定モデル７３により将来的なポンプの限界累積仕事量（ポンプ寿命時点での累積仕事量）に達するまでの残り年数（余寿命）を算定し、将来的な更新時期を予測する。
【0037】
ここで、累積仕事量から精度良く余寿命を算定するために、上述のようにポンプの寿命が設備によってばらつきがあり、同一設備でも運転状況や環境等により寿命時期が分散することから、ＡＩによる分析によって構築される決定木モデル７２を用いることとした。決定木モデル７２は、各ポンプの運転状況を、「短命につながる運転状態（以下、「短命」とする）」または、「長命につながる運転状態（以下、「長命」とする）」に分類するものである。前記決定木モデル７２によって、長命または短命に分類した各ポンプについて、ＩｏＴデバイスによるリアルタイム計測データを、ポンプが故障するまでの余寿命を返すモデルである余寿命算定モデル７３に対して入力することにより、ポンプの余寿命を算定する。これにより、ポンプの実際の運転状況を踏まえた劣化予測が可能となる。以下に、上記決定木モデル７２と余寿命算定モデル７３について詳説する。
【0038】
＜決定木モデル７２＞
決定木モデル７２は、維持管理業者（熟練技術者）による、経験に基づく長命または短命の判断の曖昧な特徴を明確化して定義するための、ＡＩによる教師データありの識別手法である。分類問題を解くＡＩ分析には様々な方法があるが、存在するデータ項目や用途（余寿命算定結果をストックマネジメントや最適運転等に利用すること）を考慮し、ポンプの劣化予測には機械学習のうち教師データありの識別の手法に該当する決定木を用いた分析を行う。該決定木分析の特徴は、カテゴリ変数と数値変数を混合して取り扱えること、
及び、木構造により簡潔明瞭に出力ができることである。
決定木モデル７２は、維持管理業者（熟練技術者）による、経験に基づく長命または短命の判断の曖昧な特徴を明確化して定義するための、ＡＩによる教師データありの識別手法である。分類問題を解くＡＩ分析には様々な方法があるが、存在するデータ項目や用途（余寿命算定結果をストックマネジメントや最適運転等に利用すること）を考慮し、ポンプの劣化予測には機械学習のうち教師データありの識別の手法に該当する決定木を用いた分析を行う。該決定木分析の特徴は、カテゴリ変数と数値変数を混合して取り扱えること、
及び、木構造により簡潔明瞭に出力ができることである。
【0039】
地域管理区分（自治体等）毎に決定木モデル７２を構成するために、教師データ７４として地域管理区分の一つである富山市のポンプのうち６０箇所について、維持管理業者による長命／短命判断の結果をＡＩに学習させた。ポンプの長命／短命の分類判断においては、維持管理業者への定性的なヒアリング結果を用いた。この決定木作成により、熟練技術者である維持管理業者が直感的に分類を行う際に用いる曖昧な特徴を簡易的に把握することができる。長命短命のヒアリング（教師データ７４の作成）は表４に示す条件を基に実施した。
維持管理業者へのヒアリング結果として、ポンプ120基（60施設）に対する長命／短命の峻別データ（長命78基，短命42基）を得た。
【表4】
【0040】
さらに、長命／短命の分類に必要な項目およびその値を抽出するために、ＡIに学習データとして表５に示すポンプ諸元や過去の日報データからなる要素データ７５であるデータセットを学習させ、各ポンプを長命または短命に分類するための特徴を抽出した。なお、ここでは工場、商業施設、病院介護施設、新興住宅などによる特殊な排水影響を受ける環境条件なども項目として参照した。データセット項目のうち、特殊な排水影響については、ＡＨＰ法による重み係数を算定した。前記重み係数である社会的影響度Ｘ［1］は、維持管理業者にヒアリングを行い数値化したものであり、0.00（影響を受けない）＜0.03（工場）＜0.05（温泉を含む商業施設）＜0.08（病院・介護施設）とした。なお、前記データセットに含めるデータの種類は多いほどよく、表５に記載のデータ項目に限定されるものではない。
【表5】
【0041】
上記のようにして、維持管理業者へヒアリングを行った結果から、地域管理区分別の分析を実施し、「短命につながる運転状態」の特徴を決定木（ＡＩ）により分析を行った。分析データの項目を集約し、決定木モデル７２を作成した結果、特に特徴量の大きい「運転時間」および「特殊な排水影響（特に飲食店等の商業や病院・介護施設等からの外部的要因による異物等の詰まりの影響）」の２項目によって分類が行われていることが判明した。なお、「運転時間」が長い（稼働率が高い）施設においては、流入量が多く槽内のスカムによる影響を受けやすいため、劣化判断における最も大きな特徴であると考えられる。また、特殊な排水影響を受ける施設は、特に飲食店等の商業や病院・介護施設等からの外部的要因（異物等の詰まりの影響）が大きいといったことが推察される。
【0042】
以上のように、維持管理業者による長命／短命分類結果と各データセット項目から特徴データをＡＩが分析抽出し、決定木モデル７２が構築された。このようにして得られた決定木モデル７２の決定木（ツリー構造）T1～T9を図８に示す。決定木モデル７２における短命ポンプの特徴は以下の通りであり、決定木の上段にある要素ほど大きな特徴がある。
短命ポンプの特徴：
（１）年間運転時間Ｘ［0］が761.5h（約2.1h/日）以上である。
（２）特殊な排水影響を受け、かつ年間運転時間Ｘ［0］が210h（約0.6h/日）以上である。
（３）年間運転時間Ｘ［0］が209.5h（約0.6h/日）以下かつ、社会的影響度Ｘ［1］が大きい、病院・介護施設及び商業施設からの排水影響を受ける施設である。
なお、図８中のginiとは、決定木分析において不純度や不平等度を示す指標であるジニ係数であり、決定木はジニ係数を指標に構築される。具体的には、多くの要素に対し決定木分析を行うと、自動的に数値化されるジニ係数の値が小さくなるように、決定木が構成される。また、ジニ係数の値が大きい要素が、維持管理業者が長命／短命を分類した特徴や共通点を表す。そして、図９の決定木分析結果を示すグラフ中の点Ｐ１およびＰ２で表されるように、運転時間の短い施設であっても、特殊な排水影響を受ける施設は決定木モデル７２によって短命に分類された。
短命ポンプの特徴：
（１）年間運転時間Ｘ［0］が761.5h（約2.1h/日）以上である。
（２）特殊な排水影響を受け、かつ年間運転時間Ｘ［0］が210h（約0.6h/日）以上である。
（３）年間運転時間Ｘ［0］が209.5h（約0.6h/日）以下かつ、社会的影響度Ｘ［1］が大きい、病院・介護施設及び商業施設からの排水影響を受ける施設である。
なお、図８中のginiとは、決定木分析において不純度や不平等度を示す指標であるジニ係数であり、決定木はジニ係数を指標に構築される。具体的には、多くの要素に対し決定木分析を行うと、自動的に数値化されるジニ係数の値が小さくなるように、決定木が構成される。また、ジニ係数の値が大きい要素が、維持管理業者が長命／短命を分類した特徴や共通点を表す。そして、図９の決定木分析結果を示すグラフ中の点Ｐ１およびＰ２で表されるように、運転時間の短い施設であっても、特殊な排水影響を受ける施設は決定木モデル７２によって短命に分類された。
【0043】
次いで、同一の地域管理区分内の他のポンプへの決定木モデル７２の拡張展開を実施し、その正答率を算定することで決定木モデル７２の精度の検証を行った。上記のようにＩｏＴデバイス設置ポンプ60箇所を教師データ７４として作成した決定木モデル７２に対する検証の方法を以下に示す。まず、ＩｏＴデバイス５未設置のポンプ300箇所に対して、決定木モデル７２による長命短命の峻別を実施した。そして、該ＩｏＴデバイス未設置のポンプに対して、維持管理業者へ再度、長命／短命判断のヒアリングを実施した。その上で、決定木モデル７２と維持管理業者の正答率を算定し評価した。
【0044】
上記の検証結果を以下に示す。表６内の決定木モデルＯに示すように、決定木モデル７２では、85％の精度で長命／短命の峻別が可能であった。また、以下のような３つの決定木モデルＭ，Ｎ，Ｏのケース別分析を行った結果、モデルＭおよびＮのように、し渣等の詰まりによる異常（出動回数や特殊な排水影響）が短命につながる運転状態に関係していることが把握できた。
・決定木モデルＭ：運転時間のみで分類したケース。
・決定木モデルＮ：運転時間と出動頻度で分類したケース。
・決定木モデルＯ：運転時間と特殊な排水影響で分類したケース。
・決定木モデルＭ：運転時間のみで分類したケース。
・決定木モデルＮ：運転時間と出動頻度で分類したケース。
・決定木モデルＯ：運転時間と特殊な排水影響で分類したケース。
【表6】
【0045】
以上のように、決定木モデル７２を構築したことにより、各ポンプの維持管理において注意すべき項目がわかるので、特に短命ポンプにおいては、例えば単位時間運転が長いものはフロート水位設定の見直し等に活用でき、長命化に向けた対応が可能である。さらに、更新計画において、長命ポンプでの運用に移行できるよう改善計画の立案が可能となる。また、他の地域管理区分においても、同様にして決定木モデル７２を構築することでポンプの長命／短命を分類するための特徴データが抽出できると考えられるため、汎用性にも優れる。
【0046】
＜余寿命算定モデル７３＞
次に、上記の決定木モデル７２による各ポンプの長命／短命分類の結果を用いて、余寿命算定モデル７３による余寿命算定を行う。
次に、上記の決定木モデル７２による各ポンプの長命／短命分類の結果を用いて、余寿命算定モデル７３による余寿命算定を行う。
【0047】
本実施例におけるポンプの劣化予測方法は、ポンプの仕事量が（電圧）×（電流）×（運転時間）として定義されることから、ポンプが寿命を迎える時点での累積仕事量である、ポンプの限界累積仕事量Ｇをこれまでの実績から仮定することで、ポンプが寿命を迎えるまでの残りの年数である余寿命Ｈを算定するものである。各ポンプ設備にＩｏＴデバイス５を設置し、電流値をリアルタイムでモニタリングすることで、各ポンプの仕事量の変化（特徴）を把握する。各ポンプの特徴および分類別に将来的な仕事量の変化の予測式である余寿命算定モデル３を構築することで、余寿命算定を行う。
【0048】
ポンプの劣化は、し渣等の詰まりが発生しやすい特殊な排水影響を受ける施設において、電流過負荷が頻発し、ポンプへの負荷が蓄積することで摩耗・劣化による故障期間が早まると考えらえる。したがって、「ポンプの寿命は、単なる時間経過ではなく運転した仕事量に依存する」と仮定し、「仕事経過率ｙ」に着目し算定することとする。前記仮定に基づくと、電圧が200Ｖで一定であることから負荷は直接電流の変化に現れるので、ポンプがした仕事は「電流値」と「運転時間」に依存すると考えることができる。
ポンプの仕事量について以下に定義する。
［数１］ ポンプの累積仕事量Ｗ＝仕事率ｗ×総運転時間t＝電圧Ｖ（一定）×消費電流Ｉ×総運転時間ｔ
ポンプが寿命を迎える時点での累積仕事量Ｗである限界累積仕事量Ｇは、これまでの実績から平均的な運転時間（6時間/日）とポンプの標準耐用年数（15年）から算定したものである。
［数２］ 限界運転時間＝標準耐用年数15年×365日×6時間/日
［数３］ 限界累積仕事量Ｇ（ポンプ寿命）＝電圧Ｖ（一定）×計画電流Ｉp×限界運転時間
なお、「計画電流Ｉp」は最大電流値の７０～８０％の、仕事率が最も効率的となるときの電流値である。
［数４］ 仕事経過率ｙ（%）＝累積仕事量Ｗ／限界累積仕事量Ｇ
である。
そして、仕事経過率ｙの近似式を以下のように得る。
ポンプの寿命は環境や地域性等により異なり、各ポンプによって運転状況も異なることから、上記決定木モデル７２によって分類された長命／短命ポンプそれぞれのグループについて余寿命算定を行った結果を以下に示す。
［数５］ 余寿命（年）＝寿命年数－稼働年数
寿命予測式（余寿命算定モデル７３）を
［数６］ ｙ＝ｆ（ｘ）
とする。ここで、ｙは仕事経過率、ｘは稼働年数であり、ｙ＝100％のときのｘを寿命年数とする。
ある時点までのポンプの稼働年数と累積仕事量Ｗとは、前述したように、蓄積してあるリアルタイム電流値データを基に算出することができるので、これを、図１０に示すように、横軸を時間（稼働年数）ｘとし、縦軸を仕事経過率ｙとしたグラフ上にプロットする。なお、グラフは縦軸を累積仕事量Ｗとしてもよいが、本実施形態例ではよりわかりやすくするために縦軸を仕事経過率ｙとした。
そして、逆関数
［数７］ ｘ＝ｇ（ｙ）
とし、グラフにプロットした仕事経過率（座標点）から寿命予測式（余寿命算定モデル７３）を近似すると、
余寿命算定モデル７３は
短命ポンプの場合
［数８］ ｙ＝0.0831ｅ＾（0.1375ｘ）
長命ポンプの場合
［数９］ ｙ＝0.0157ｘ
となった。
ポンプの仕事量について以下に定義する。
［数１］ ポンプの累積仕事量Ｗ＝仕事率ｗ×総運転時間t＝電圧Ｖ（一定）×消費電流Ｉ×総運転時間ｔ
ポンプが寿命を迎える時点での累積仕事量Ｗである限界累積仕事量Ｇは、これまでの実績から平均的な運転時間（6時間/日）とポンプの標準耐用年数（15年）から算定したものである。
［数２］ 限界運転時間＝標準耐用年数15年×365日×6時間/日
［数３］ 限界累積仕事量Ｇ（ポンプ寿命）＝電圧Ｖ（一定）×計画電流Ｉp×限界運転時間
なお、「計画電流Ｉp」は最大電流値の７０～８０％の、仕事率が最も効率的となるときの電流値である。
［数４］ 仕事経過率ｙ（%）＝累積仕事量Ｗ／限界累積仕事量Ｇ
である。
そして、仕事経過率ｙの近似式を以下のように得る。
ポンプの寿命は環境や地域性等により異なり、各ポンプによって運転状況も異なることから、上記決定木モデル７２によって分類された長命／短命ポンプそれぞれのグループについて余寿命算定を行った結果を以下に示す。
［数５］ 余寿命（年）＝寿命年数－稼働年数
寿命予測式（余寿命算定モデル７３）を
［数６］ ｙ＝ｆ（ｘ）
とする。ここで、ｙは仕事経過率、ｘは稼働年数であり、ｙ＝100％のときのｘを寿命年数とする。
ある時点までのポンプの稼働年数と累積仕事量Ｗとは、前述したように、蓄積してあるリアルタイム電流値データを基に算出することができるので、これを、図１０に示すように、横軸を時間（稼働年数）ｘとし、縦軸を仕事経過率ｙとしたグラフ上にプロットする。なお、グラフは縦軸を累積仕事量Ｗとしてもよいが、本実施形態例ではよりわかりやすくするために縦軸を仕事経過率ｙとした。
そして、逆関数
［数７］ ｘ＝ｇ（ｙ）
とし、グラフにプロットした仕事経過率（座標点）から寿命予測式（余寿命算定モデル７３）を近似すると、
余寿命算定モデル７３は
短命ポンプの場合
［数８］ ｙ＝0.0831ｅ＾（0.1375ｘ）
長命ポンプの場合
［数９］ ｙ＝0.0157ｘ
となった。
【0049】
そして、図１０に示すように、前記グラフ上に限界累積仕事量Ｇを破線で示す。前記短命／長命ポンプそれぞれの寿命予測式（余寿命算定モデル７３）のグラフと、限界累積仕事量Ｇを示す直線との交点が当該ポンプの寿命点Ｌであり、現時点から前記寿命点Ｌまでの期間が当該ポンプの余寿命Ｈとなり、劣化予測を行うことができる。
【0050】
本余寿命算定モデル７３の技術的特徴は、マンホールポンプに設けたＩｏＴデバイス５から送られてくるリアルタイムの電流値データを余寿命算定に利用した点にある。
前記ポンプの累積仕事量Ｗにおける「消費電流Ｉ」及び「総運転時間ｔ」は、ＩｏＴデバイス５により常時送られてくるポンプの稼働時間を含むリアルタイム電流値データが蓄積されているので、前記蓄積した電流値データから算出することができる。
前記ポンプの累積仕事量Ｗにおける「消費電流Ｉ」及び「総運転時間ｔ」は、ＩｏＴデバイス５により常時送られてくるポンプの稼働時間を含むリアルタイム電流値データが蓄積されているので、前記蓄積した電流値データから算出することができる。
【0051】
上記のようなポンプの劣化予測により、点在する複数施設を管理し、常時の点検が難しく劣化状況の把握が困難なポンプにおいて、ＩｏＴデバイス５によるリアルタイム計測データを活用し、個別の詳細点検調査を実施せずに余寿命を算定することで、ポンプの将来的な改築量が推定可能となり、維持管理並びにストックマネジメント計画の効率化が期待できる。また、従来のストックマネジメント計画においては、時間計画的な管理では、優先度順位に差がなく、劣化状態において実態との乖離が大きかったが、決定木モデル７２において、計画以上に稼働しているマンホールポンプを長命／短命分類によって抽出し、余寿命の予測式を作成し余寿命算定を行うことで、調査箇所の優先順位付け（スクリーニング）を行い、点検調査計画の効率化やポンプ全体の中長期的な改築事業シナリオ作成を支援することが可能となる。さらに、決定木モデル７２を構築したことにより、各ポンプの維持管理において注意すべき項目がわかるので、特に短命ポンプにおいては、例えば単位時間運転が長いものはフロート水位設定の見直し等に活用でき、長命化に向けた対応が可能である。さらに、更新計画において、長命ポンプでの運用に移行できるよう改善計画の立案が可能となる。また、他の地域管理区分（自治体等）においても、同様にして決定木モデル７２を構築することでポンプの長命／短命を分類するための特徴データが抽出できると考えられるため、汎用性にも優れる。
【0052】
上記のようにして得られた劣化予測情報は、統合監視クラウドシステム１に蓄積され管理され、さらには、ストックマネジメント支援システム３において劣化予測に関連するデータを受け取ることで、これをポンプの健全度評価やリスク検討等に活用することができ、各自治体７との情報の共有化を図り、改築計画の精度の向上及び経費の削減など、効率的で且つ継続的な支援を図ることができる。
【0053】
次に、統合監視クラウドシステム１について説明する。統合監視クラウドシステム１は、既存の監視システムからの施設運転データ（計測および日報）、維持管理データ（緊急出動履歴）の連携および、ストックマネジメント支援システム３からの設備台帳の連携を受け、マンホールポンプの異常未然検知および劣化予測に必要な情報の一元管理を行う。さらに、AIエンジン搭載検知予測システムとの連携により、IoTデバイス５によるマンホールポンプの状態監視（異常未然検知および維持管理部署等への通知）、施設運転情報から得られたポンプの劣化予測情報を蓄積し、その結果を「ストックマネジメント支援システム３」へ連携させ、マンホールポンプの維持管理におけるデータ管理センターとしての役割を担うものである。統合監視クラウドシステム１を構築する目的は次の５つである。
目的１：既存システムなどの日報データを取り込み、自動的にAIエンジン搭載検知予測システムに連携することで、AIエンジンに教師データを受け渡す。
目的２：AIエンジン搭載検知予測システムからの異常未然検知の連携を受け、維持管理者に対してアラートメールを通知、および画面上で異常検知状況をリアルタイムでモニタリングを可能とすることで、マンホールポンプの異常に対する早期の対処を可能にする。また、異常を検知したマンホールに対する対応を入力することにより、マンホールポンプに対するメンテナンスの管理を可能にする。
目的３：マンホールポンプの異常未然検知状況を地図と一覧で表示することにより、現在異常を検知しているマンホールポンプをまとめて把握することを可能にする。
目的４：異常未然検知の内容に対する維持管理業者の対応を記録として残すことにより、異常検知の内容・マンホールポンプの設備諸元・電流値の波形に対する熟練した技術者の対応を若手の技術者に伝えることを可能にする。また、AIエンジン搭載検知予測システムにフィードバックすることにより、予測精度向上に役立つ教師データの蓄積を可能にする。
目的５：維持管理業者が実施する点検・修繕業務を入力可能にすることにより、入力した点検・修繕のデータを蓄積及び維持管理部署等との情報連携を可能にする。
以上の５つの目的のための統合監視クラウドシステム１の機能は次のとおりである。
目的１：既存システムなどの日報データを取り込み、自動的にAIエンジン搭載検知予測システムに連携することで、AIエンジンに教師データを受け渡す。
目的２：AIエンジン搭載検知予測システムからの異常未然検知の連携を受け、維持管理者に対してアラートメールを通知、および画面上で異常検知状況をリアルタイムでモニタリングを可能とすることで、マンホールポンプの異常に対する早期の対処を可能にする。また、異常を検知したマンホールに対する対応を入力することにより、マンホールポンプに対するメンテナンスの管理を可能にする。
目的３：マンホールポンプの異常未然検知状況を地図と一覧で表示することにより、現在異常を検知しているマンホールポンプをまとめて把握することを可能にする。
目的４：異常未然検知の内容に対する維持管理業者の対応を記録として残すことにより、異常検知の内容・マンホールポンプの設備諸元・電流値の波形に対する熟練した技術者の対応を若手の技術者に伝えることを可能にする。また、AIエンジン搭載検知予測システムにフィードバックすることにより、予測精度向上に役立つ教師データの蓄積を可能にする。
目的５：維持管理業者が実施する点検・修繕業務を入力可能にすることにより、入力した点検・修繕のデータを蓄積及び維持管理部署等との情報連携を可能にする。
以上の５つの目的のための統合監視クラウドシステム１の機能は次のとおりである。
【0054】
＜設備諸元取り込み機能＞
ストックマネジメント支援システム３より電流・漏れ電流計測地点の施設情報の連携を受け、データベースに反映する。データベースの同期手法として,ストックマネジメント支援システム３側のAPIを呼び出し、同期対象データを取得する。なお、同期対象データは表７の施設諸元とする。
ストックマネジメント支援システム３より電流・漏れ電流計測地点の施設情報の連携を受け、データベースに反映する。データベースの同期手法として,ストックマネジメント支援システム３側のAPIを呼び出し、同期対象データを取得する。なお、同期対象データは表７の施設諸元とする。
【表7】
【0055】
＜運転日報データ連携機能＞
既存の遠隔監視システムの運転日報データ取り込み、運転日報データとして蓄積する。本実施例で対象とする既存の遠隔監視システムの運転日報データは、フィールドで広く採用されている既存遠隔監視システムが保有する運転日報データ項目(Excel形式)を標準とする。その他の既存遠隔監視システムの日報データについては、標準形式に変換した上で連携する。表８に標準データ項目を示す。
IoTデバイス５で測定したリアルタイム電流値を統合監視クラウドシステム１に取り込むことにより、運転日報データとしてマンホールポンプの運転記録を蓄積することができる。蓄積した運転記録の各項目は「運転日報」画面にて閲覧することができる。また、「運転日報」のデータは「帳票出力」ボタンを選択することにより帳票出力することができる。
既存の遠隔監視システムの運転日報データ取り込み、運転日報データとして蓄積する。本実施例で対象とする既存の遠隔監視システムの運転日報データは、フィールドで広く採用されている既存遠隔監視システムが保有する運転日報データ項目(Excel形式)を標準とする。その他の既存遠隔監視システムの日報データについては、標準形式に変換した上で連携する。表８に標準データ項目を示す。
【表8】
【0056】
＜異常未然検知のアラート通知機能＞
統合監視クラウドシステム１はAIエンジン搭載検知予測システム２により、異常未然検知の通知（ポンプID，異常検知日時，異常予測日時，異常種別，15時間以内の異常発生確率）を受け取る。
異常発生確率が所定のしきい値を超えている異常未然検知の通知を受け取った時、維持管理業者に異常未然検知のアラートメールを送信する。アラートメールを受け取った維持管理業者は、メールに記載されているURLを選択することにより、異常未然検知の状況やマンホールポンプ施設の地図を確認できる画面を表示する。
統合監視クラウドシステム１はAIエンジン搭載検知予測システム２により、異常未然検知の通知（ポンプID，異常検知日時，異常予測日時，異常種別，15時間以内の異常発生確率）を受け取る。
異常発生確率が所定のしきい値を超えている異常未然検知の通知を受け取った時、維持管理業者に異常未然検知のアラートメールを送信する。アラートメールを受け取った維持管理業者は、メールに記載されているURLを選択することにより、異常未然検知の状況やマンホールポンプ施設の地図を確認できる画面を表示する。
【0057】
＜対応状況の入力機能＞
異常未然検知を検出したマンホールポンプの施設について、異常発生確率がしきい値を超えている異常未然検知の通知を受け取った時、維持管理業者に異常未然検知のアラートメールを送信する。アラートメールを受け取った維持管理業者は、メールに記載されているURLを選択することにより異常未然検知の状況を確認できる画面を表示する。
該画面で、詳細な異常未然検知内容を表示するには、画面内の「異常未然検知内容」内メニューにて「詳細」を選択すると、最終異常確度Ｋの時間変化をグラフで表示する。
また、「異常未然検知内容」内メニューの「電流値グラフ」を選択することで、異常未然検知の通知があった時刻周辺の電流値の時間変化をグラフ表示することができる。
そして、維持管理業者は設備諸元・電流値グラフと異常未然検知の内容から判断して、マンホールポンプの異常に対する対応を行い、対応の内容を「対応入力」の欄に記入し、「対応状況」を「完了」に変更する。対応が完了となっている場合には、「帳票出力」ボタンを選択することで、緊急出動時の記録を帳票出力することができる。
異常未然検知を検出したマンホールポンプの施設について、異常発生確率がしきい値を超えている異常未然検知の通知を受け取った時、維持管理業者に異常未然検知のアラートメールを送信する。アラートメールを受け取った維持管理業者は、メールに記載されているURLを選択することにより異常未然検知の状況を確認できる画面を表示する。
該画面で、詳細な異常未然検知内容を表示するには、画面内の「異常未然検知内容」内メニューにて「詳細」を選択すると、最終異常確度Ｋの時間変化をグラフで表示する。
また、「異常未然検知内容」内メニューの「電流値グラフ」を選択することで、異常未然検知の通知があった時刻周辺の電流値の時間変化をグラフ表示することができる。
そして、維持管理業者は設備諸元・電流値グラフと異常未然検知の内容から判断して、マンホールポンプの異常に対する対応を行い、対応の内容を「対応入力」の欄に記入し、「対応状況」を「完了」に変更する。対応が完了となっている場合には、「帳票出力」ボタンを選択することで、緊急出動時の記録を帳票出力することができる。
【0058】
＜異常未然検知履歴機能＞
蓄積された異常未然検知の履歴および、通知された異常検知に対して過去に維持管理業者が対応した内容を画面に表示することで、異常検知の内容・マンホールポンプの設備諸元・電流値の波形に対する熟練した技術者の対応を若手の技術者に伝えることを可能にする。
蓄積された異常未然検知の履歴および、通知された異常検知に対して過去に維持管理業者が対応した内容を画面に表示することで、異常検知の内容・マンホールポンプの設備諸元・電流値の波形に対する熟練した技術者の対応を若手の技術者に伝えることを可能にする。
【0059】
＜運転概況モニター機能＞
マンホールポンプの維持管理業者向けに、AIエンジン搭載検知予測システム２で異常未然検知された結果を地図上に一覧表示した画面で閲覧可能とする。異常が検知された施設は、画面上で強調表示され、維持管理業者は当該情報をもとに現地調査を行う。また、異常検知された内容に対して、異常なし、ポンプの詰まり等の調査結果を維持管理業者が登録することにより、AIの教師データとして実現象の情報を蓄積可能とする。
マンホールポンプの維持管理業者向けに、AIエンジン搭載検知予測システム２で異常未然検知された結果を地図上に一覧表示した画面で閲覧可能とする。異常が検知された施設は、画面上で強調表示され、維持管理業者は当該情報をもとに現地調査を行う。また、異常検知された内容に対して、異常なし、ポンプの詰まり等の調査結果を維持管理業者が登録することにより、AIの教師データとして実現象の情報を蓄積可能とする。
【0060】
＜点検の入力・閲覧機能＞
マンホールポンプの維持管理業者６が実施した定期点検及び通常点検の結果を入力することで、点検結果の蓄積及び維持管理部署等との情報連携を可能にする。マンホールポンプの定期点検結果は点検登録画面より入力することができる。登録した点検結果は、点検履歴画面にて一覧表示することができ、詳細ボタンより点検の内容を閲覧することができる。
マンホールポンプの維持管理業者６が実施した定期点検及び通常点検の結果を入力することで、点検結果の蓄積及び維持管理部署等との情報連携を可能にする。マンホールポンプの定期点検結果は点検登録画面より入力することができる。登録した点検結果は、点検履歴画面にて一覧表示することができ、詳細ボタンより点検の内容を閲覧することができる。
【0061】
＜修繕の入力・閲覧機能＞
既存システムのアラート発報及び異常未然検知により出動して実施したマンホールポンプの修繕、定期点検によって見つかった異常に対する修繕、周辺住民等からの連絡により実施した調査に対する修繕について、実施した内容を入力することで、修繕の記録を蓄積し、維持管理部署等との情報連携を可能にする。修繕の内容は修繕登録画面より入力することができ、入力した修繕内容は修繕履歴画面より一覧で表示することができる。また、「帳票出力」のボタンを選択することにより、修繕内容を帳票出力することができる。
統合監視クラウドシステム１の機能は以上である。
既存システムのアラート発報及び異常未然検知により出動して実施したマンホールポンプの修繕、定期点検によって見つかった異常に対する修繕、周辺住民等からの連絡により実施した調査に対する修繕について、実施した内容を入力することで、修繕の記録を蓄積し、維持管理部署等との情報連携を可能にする。修繕の内容は修繕登録画面より入力することができ、入力した修繕内容は修繕履歴画面より一覧で表示することができる。また、「帳票出力」のボタンを選択することにより、修繕内容を帳票出力することができる。
統合監視クラウドシステム１の機能は以上である。
【0062】
次に、ストックマネジメント支援システム３について説明する。ストックマネジメント支援システム３は、最新の施設台帳諸元データと維持管理の実施状況や劣化予測状況に基づき具体的な改築需要の規模を明らかにし、中長期的な改築計画立案への適切な情報提供を行うシステムである。ストックマネジメント支援システム３は、統合監視クラウドシステム１に集積された維持管理情報（点検・調査）や劣化予測に関連するデータを受け取り、これをポンプの健全度評価やリスク検討等に活用することで、各種情報の見える化や改築計画の精度の向上、LCCの削減などの効率的かつ継続的なストックマネジメント支援を図ることを目的とする。本実施例において、ストックマネジメント支援システム３は、既に実証・製品化されているクラウド型の情報システム（サービス名：Blitz GROW，日水コン）を用いる。本システムは自治体への導入・運用実績を有していることから信頼性の高いシステムである。
【0063】
ストックマネジメント支援システム３の機能は図１１に示す通り、設備台帳、工事台帳、現況図管理、保守点検管理、改築計画に大別され、施設管理に携わる多くの関係者が業務の過程で本システム機能を利活用することで、効率的かつ継続的なストックマネジメントを実現する。また、ストックマネジメント支援システム３と統合監視クラウドシステム１の設備諸元の連携はWeb APIを使用して行うものとした。統合監視クラウドシステム１に連携する設備諸元は表９の通りである。
【表9】
【0064】
また、ストックマネジメント支援システム３は、統合監視クラウドシステム１からWeb APIを用いて劣化予測データの取得を行う。システム管理者権限を持ったユーザが任意のタイミングで、統合監視クラウドシステム１から劣化予測データを取得することが可能である。劣化予測データとは、予測日時、長命／短命の分類データ、余寿命データである。そして、ストックマネジメント支援システム３に反映された劣化予測データは、台帳管理の設備台帳詳細画面より確認可能となる。さらに、ストックマネジメント支援システム３に蓄積され、設備台帳情報と関連付けられた劣化予測データは、汎用性のあるEXCELデータとして出力可能である。EXCELによる出力と長命／短命の分類データ、および余寿命データから、ストックマネジメント計画（更新）の対象施設の容易な抽出が可能となる。
【0065】
そして、修繕工事・改築工事履歴の連携は、設備諸元の連携と同様に、Web APIを使用して行うものとした。なお、工事情報の連携は、設備諸元に記載の設備IDを必要とするため、設備諸元の連携を行った後で実行するものとする。また、ストックマネジメント支援システム３に登録されている完成図書などの資料も連携可能とした。統合監視クラウドシステム１に連携している工事情報は表１０の通りである。
【表10】
【0066】
次いで、統合監視クラウドシステム１の構築方法について説明する。まず、設備諸元を取得するバッチプログラムを実行し、設備諸元を取得する。そして、既存の遠隔監視システムより出力した日報データを、日報データ取り込み用フォルダに保存する。コマンドプロンプトで命令を実行することで、統合監視クラウドのS3領域(データを保存する場所)にアップロードする。次に、統合監視クラウドシステム１のサーバでバッチ処理を実行すると、統合監視クラウドシステム１のデータベースに日報データが登録される。また、既存の遠隔監視システムより取り込んだ日報データに加えて、IoTデバイス５で計測したリアルタイム電流値を月次のバッチ処理により取り込み、運転記録として利用する。リアルタイム電流値の取り込みが完了すると、取り込みを行った月までの日報データを統合監視クラウドシステム１の画面にて表示することができる。
【0067】
そして、AIエンジンから異常未然検知のAPI呼び出しを行うことにより、異常未然検知の通知を受け取る。異常未然検知のデータはjson形式である。この異常未然検知の通知を受け取ることにより、異常未然検知メールを送信する。メールに記載されたURLを選択することにより、画面に異常未然検知の内容が表示される。また、異常未然検知の通知があった時に電流値グラフを表示するために、AIエンジンにより電流値データを取得する。電流値データを取得するには次の手順でAPI呼び出しを行う。まず、電流値データをダウンロードできるURL一覧を取得するAPIを呼び出す。次いで、URLに保存されている電流値データをダウンロードする。電流値データはparquet形式でAWSのS3領域に保存する。
【0068】
次に、ストックマネジメント支援システム３と統合監視クラウドシステム１との連携を行う。図１２に示すように、ストックマネジメント支援システム３と統合監視クラウドシステム１との連携を図るためのAPIを構築する。ストックマネジメント支援システム３と統合監視クラウドシステム１との連携においては、次の２つのケースを想定し、各々必要とされるデータ項目を決定した。
（ケース１）マンホールポンプの基本的な設備台帳諸元データなどの属性情報を双方システムが同期・共有するための連携（統合監視クラウドシステム１がデータを受け取るための連携）。
（ケース２）統合監視クラウドシステムで蓄積・管理された劣化予測結果データをストックマネジメント支援システムが受け取るための連携。
なお、APIは、一般的なデータ形式（JSON形式など）での応答が可能な汎用性のあるWeb-APIとすることで、普及展開時における柔軟性な対応を可能とする。各ケースにおけるデータ取得及び応答の流れを図１２（ａ）および（ｂ）にそれぞれ示す。
（ケース１）
統合監視クラウドシステム１から設備台帳APIを呼び出す。
呼び出された設備台帳APIが統合監視クラウドシステム１に、設備台帳ID・設備名称等のデータを渡す。
（ケース２）
ストックマネジメント支援システム３から統合監視クラウドシステム１のAPIを呼び出す。
呼び出された統合監視クラウドシステム１のAPIがストックマネジメント支援システム３に、設備台帳ID・余寿命等のデータを渡す。
上記のようにして、ストックマネジメント支援システム３と統合監視クラウドシステム１との連携を行った。
（ケース１）マンホールポンプの基本的な設備台帳諸元データなどの属性情報を双方システムが同期・共有するための連携（統合監視クラウドシステム１がデータを受け取るための連携）。
（ケース２）統合監視クラウドシステムで蓄積・管理された劣化予測結果データをストックマネジメント支援システムが受け取るための連携。
なお、APIは、一般的なデータ形式（JSON形式など）での応答が可能な汎用性のあるWeb-APIとすることで、普及展開時における柔軟性な対応を可能とする。各ケースにおけるデータ取得及び応答の流れを図１２（ａ）および（ｂ）にそれぞれ示す。
（ケース１）
統合監視クラウドシステム１から設備台帳APIを呼び出す。
呼び出された設備台帳APIが統合監視クラウドシステム１に、設備台帳ID・設備名称等のデータを渡す。
（ケース２）
ストックマネジメント支援システム３から統合監視クラウドシステム１のAPIを呼び出す。
呼び出された統合監視クラウドシステム１のAPIがストックマネジメント支援システム３に、設備台帳ID・余寿命等のデータを渡す。
上記のようにして、ストックマネジメント支援システム３と統合監視クラウドシステム１との連携を行った。
【0069】
以上のようにして、統合監視クラウドシステム１は、前記ＡＩエンジン搭載検知予測システム２による異常未然検知と劣化予測の情報を受け取って蓄積する。そして、ストックマネジメント支援システム３は、統合監視クラウドシステム１に蓄積された前記異常未然検知と劣化予測の情報を基に状態監視によるストックマネジメント計画の適正な立案支援を図る。そして、前記ストックマネジメント計画と前記異常未然検知と劣化予測の情報は、これらの情報を一元管理する統合監視クラウドシステムを通じて、必要に応じて維持管理業者及び最終的な責任者である自治体に通知される。その結果、維持管理業者は異常未然検知の情報から、異常が起こる前の所定時間を確保し、現場作業員の負担の軽減を図り、必要に応じて現地で補修修繕を行うことができる。さらに維持管理業者及び自治体は、ストックマネジメント支援システムにおいて劣化予測に関連するデータを受け取ることで、これをポンプの健全度評価やリスク検討等に活用することができ、各自治体との情報の共有化を図り、改築計画の精度の向上及び人材不足の解消並びに経費の削減など、効率的で且つ継続的な支援を図ることができる。
【0070】
次に、マンホールポンプの監視システムを実際に運用した結果を示す。本結果は、統合監視クラウドシステム１によって異常未然検知情報が維持管理業者６に通知され、維持管理業者６が対応を行った事例である。図１３は、ＡＩエンジン搭載検知予測システム２が算出し、統合監視クラウドシステム１が通知した、田屋北汚水中継ポンプ所No.1マンホールポンプの異常確度と時間の関係を示すグラフである。2021年7月8日5:30に最終異常確度Ｋ（確度Ｊの１５時間移動平均）が60%に到達したことにより、統合監視クラウドシステム１から維持管理業者６に異常未然検知の通知が発報された。この通知を受け、2021年7月8日14:00に維持管理業者６が現場対応を行った。この現場対応においては、ケーシング内部に異物（し渣）が混入していることが発見されたため異物除去を行ったところ、当該ポンプの電流値が定格電流以下に下がった。その結果、2021年7月9日6:30に最終異常確度Ｋが60%を下回り、維持管理業者６の待機体制は解除となった。このようにして、統合監視クラウドシステム１によって異常未然検知情報が維持管理業者６に予め昼間に通知されたことで、異常が起こる前に補修修繕対応のための時間を昼間のうちに確保できた結果、維持管理業者６が夜間（18:00～翌日9:00）に出動することなく対応を完了することができた。これにより、現場作業員の負担の軽減に大きく貢献できた。
【符号の説明】
【0071】
１ 統合監視クラウドシステム
２ ＡＩエンジン搭載検知予測システム
３ ストックマネジメント支援システム
５ ＩｏＴデバイス
６ 維持管理業者
７ 自治体
２ ＡＩエンジン搭載検知予測システム
３ ストックマネジメント支援システム
５ ＩｏＴデバイス
６ 維持管理業者
７ 自治体
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】