このアプリケーションの一部のコンテンツは現時点では利用できません。
このような状況が続く場合は、にお問い合わせくださいフィードバック & お問い合わせ
1. (WO2018181422) 設備管理方法、設備管理装置及び設備管理システム
Document

明 細 書

発明の名称 設備管理方法、設備管理装置及び設備管理システム

技術分野

0001  

背景技術

0002  

先行技術文献

特許文献

0003  

発明の概要

0004   0005   0006   0007   0008   0009  

図面の簡単な説明

0010  

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

0011   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   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17  

明 細 書

発明の名称 : 設備管理方法、設備管理装置及び設備管理システム

技術分野

[0001]
 本発明は、設備管理方法、設備管理装置及び設備管理システムに関する。

背景技術

[0002]
 複数の設備に関する様々な情報を管理する設備管理システムが知られている。様々な情報としては、設備に関する基本情報やメンテナンス情報が挙げられる。基本情報は、例えば、例えば、設置年月日、既定耐用年数及び定格消費電力等を含む。メンテナンス情報は、過去のメンテナンスの履歴を含む(例えば、特許文献1)。

先行技術文献

特許文献

[0003]
特許文献1 : 特開2005-182399号公報

発明の概要

[0004]
 第1の特徴に係る設備管理方法は、設備のエラーの内容を含むアラートをデータベースに登録するステップAと、前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップBと、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理するステップCと、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信するステップDとを備える。前記ステップDは、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合するステップを含む。
[0005]
 第2の特徴に係る設備管理方法は、設備のエラーの内容を含むアラートをデータベースに登録するステップAと、前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップBと、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理するステップCとを備える。前記ステップCは、2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合するステップを含む。
[0006]
 第3の特徴に係る設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部と、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理する。前記送信部は、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合する。
[0007]
 第4の特徴に係る設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部を備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合する。
[0008]
 第5の特徴に係る設備管理システムは、少なくとも設備管理装置を有する。前記設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部と、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理する。前記送信部は、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合する。
[0009]
 第6の特徴に係る設備管理システムは、少なくとも設備管理装置を有する。前記設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部を備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合する。

図面の簡単な説明

[0010]
[図1] 図1は、実施形態に係る設備管理システム100を示す図である。
[図2] 図2は、実施形態に係る設備管理装置200を示す図である。
[図3] 図3は、実施形態に係るエラー通知の一例を示す図である。
[図4] 図4は、実施形態に係るエラー通知の一例を示す図である。
[図5] 図5は、実施形態に係るエラー通知の一例を示す図である。
[図6] 図6は、実施形態に係る設備管理方法を示す図である。
[図7] 図7は、実施形態に係る設備管理方法を示す図である。
[図8] 図8は、変更例1に係るスレッドの統合を説明するための図である。
[図9] 図9は、変更例1に係るスレッドの統合を説明するための図である。
[図10] 図10は、変更例1に係るスレッドの統合を説明するための図である。
[図11] 図11は、変更例1に係る設備管理方法を示す図である。
[図12] 図12は、変更例2に係る設備管理方法を示す図である。
[図13] 図13は、変更例3に係るエラーの階層構造を説明するための図である。
[図14] 図14は、変更例4に係るスレッドの一覧の一例を示す図である。
[図15] 図15は、変更例4に係るスレッドの一覧の一例を示す図である。
[図16] 図16は、変更例4に係るスレッドの一覧の一例を示す図である。
[図17] 図17は、変更例4に係るスレッドの一覧の一例を示す図である。

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

[0011]
 近年では、背景技術において述べた設備管理システムにおいて、設備のエラー等が発生した場合に、エラーの内容及びエラーに対する処理を1対1の関係で対応付けるスレッドを管理する仕組み(ワークフロー)も提案されている。さらに、エラーと1対1の関係でエラー通知をユーザ端末に送信する仕組みも提案されている。
[0012]
 しかしながら、設備管理システムで管理する設備の数の増大等に伴って、設備のエラーが頻発する可能性がある。従って、多数のスレッドが管理され、多数のエラー通知が通知される可能性がある。このようなケースにおいては、多数のスレッド又は多数のエラー通知を確認するユーザの作業が非常に煩雑になってしまう。
[0013]
 本発明は、多数のスレッド又は多数のエラー通知を確認するユーザの作業負荷を軽減することを可能とする設備管理方法、設備管理装置及び設備管理システムを提供する。
[0014]
 以下において、実施形態について図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。
[0015]
 ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。従って、具体的な寸法などは以下の説明を参酌して判断すべきである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
[0016]
 [実施形態]
 (設備管理システム)
 以下において、実施形態に係る設備管理システムについて説明する。図1に示すように、設備管理システム100は、設備管理装置200と、施設300と、ユーザ端末400とを有する。図1では、施設300として、施設300A~施設300Cが例示されている。設備管理装置200及び施設300は、ネットワーク120に接続されている。ネットワーク120は、設備管理装置200と施設300との間の回線、設備管理装置200とユーザ端末400との間の回線を提供すればよい。ネットワーク120は、例えば、インターネットである。ネットワーク120は、VPNなどの専用回線を提供してもよい。
[0017]
 設備管理装置200は、施設300に設けられる設備を管理する。設備管理装置200の詳細については後述する(図2を参照)。
[0018]
 施設300は、発電設備310及び負荷設備320を有する。発電設備310は、発電を行う設備であり、電力系統110に接続される。発電設備310は、太陽光、風力又は地熱などの自然エネルギーを利用して発電を行う設備であってもよい。発電設備310は、燃料電池装置であってもよく、蓄電池装置であってもよい。施設300は、2種類以上の発電設備310を有してもよい。負荷設備320は、電力を消費する設備であり、電力系統110及び発電設備310の少なくともいずれか1つに接続される。負荷設備320は、空調設備であってもよく、照明設備であってもよい。
[0019]
 ユーザ端末400は、施設300に設けられる設備を管理する管理者などのユーザが所持する端末であってもよい。ユーザ端末400は、施設300に設けられる設備のメンテナンスを行う作業者などのユーザが所持する端末であってもよい。ユーザ端末400は、スマートフォンであってもよく、タブレット端末であってもよく、パーソナルコンピュータであってもよい。
[0020]
 ここで、設備管理システム100は、電力管理サーバを有していてもよい。電力管理サーバは、例えば、電力系統110から施設300に対する潮流量の制御を要求する潮流制御メッセージ、施設300から電力系統110に対する逆潮流量の制御を要求する逆潮流制御メッセージ、施設300に設けられる発電設備310(分散電源)の制御を要求する電源制御メッセージなどを施設300に送信する。
[0021]
 (設備管理装置)
 以下において、実施形態に係る設備管理装置について説明する。図2に示すように、設備管理装置200は、管理部210と、通信部220と、制御部230とを有する。
[0022]
 管理部210は、不揮発性メモリ又は/及びHDDなどの記憶媒体によって構成されており、複数の施設300に関する情報を管理する。管理部210は、設備情報DB211と、メンテナンス情報DB212と、スレッド情報DB213とを有する。
[0023]
 設備情報DB211は、複数の施設300のそれぞれに設けられる設備の基本情報を記憶する。設備情報DB211は、例えば、施設名、施設ID、設備名、設備ID、導入年、経年及び耐用年数を対応付けて記憶する。施設名は、設備が設置される施設300の名称である。施設IDは、施設300を識別する識別子である。設備名は、設備の名称である。設備IDは、設備を識別する識別子である。導入年は、設備が導入された年である。経年は、設備が導入されてから経過した年である。耐用年数は、設備のメーカ等によって定められており、設備を導入してから設備を適切に使用可能な期間を示す情報である。
[0024]
 メンテナンス情報DB212は、複数の施設300のそれぞれについて、複数の施設300のそれぞれに設けられる設備のメンテナンス情報を記憶する。メンテナンス情報DB212は、例えば、施設名、設備名、メンテナンス日、メンテナンス概要及びメンテナンス詳細を対応付けて記憶する。メンテナンス情報DB212は、これらの情報とともに、施設ID及び設備IDを対応付けて記憶してもよい。施設名及び設備名は、上述した通りである。メンテナンス日は、メンテナンスが行われた日付である。メンテナンス概要は、メンテナンスの概要を示す情報であり、メンテナンス詳細は、メンテナンスの詳細を示す情報である。実施形態に係るメンテナンス情報は、少なくとも、将来において発電設備310のメンテナンスを行うメンテナンス期間(予定)を含んでいればよい。メンテナンス情報は、過去において発電設備310のメンテナンスを行ったメンテナンス期間を含んでいてもよい。
[0025]
 ここで、メンテナンスは、例えば、設備の劣化状態を調査する点検、点検時に軽微な手入れを行う保守、設備の機能及び性能を設置当初の状態に戻すために設備の不具合を処置する修繕、既存の設備を新しい設備に交換する取替等を含む。
[0026]
 スレッド情報DB213は、アラートと処理ステータスとを1対1の関係で管理するためのスレッドを記憶する。アラートは、施設300に設けられる設備のエラーの内容を含む情報要素である。アラートは、施設300から送信される。処理ステータスは、施設300に設けられる設備のエラーに対する処理を含む情報要素である。処理ステータスは、自動的に生成され、メンテナンスを行う作業者などのユーザによって更新される。処理ステータスは、エラーに対する処理を手配していない「手配待ち」、エラーに対する処理を手配した「手配済み」、エラーに対する処理を行っている「作業中」、エラーに対する処理を完了した「完了済み」を含んでもよい。エラーに対する処理は、上述したように、点検、保守、修繕、取替などを含んでもよい。スレッドは、アラートと処理ステータスとの関係を管理するための1つの単位である。スレッドは、例えば、このような関係をワンクリックで閲覧するための情報要素であってもよい。但し、スレッドは、アラートと処理ステータスとを1対1の関係で管理するためのコンセプトを逸脱しない情報要素であればよく、上述した関係をワンクリックで閲覧するための情報要素でなくてもよい。
[0027]
 通信部220は、通信モジュールによって構成されており、ネットワーク120を介して施設300及びユーザ端末400と通信を行う。通信部220は、施設300に設けられる設備のエラーの内容を含むアラートを施設300から受信する。通信部220は、施設300に設けられる設備のエラーの発生を示す情報を含むエラー通知をユーザ端末400に送信する。
[0028]
 制御部230は、メモリ及びCPUなどによって構成されており、設備管理装置200に設けられる各構成を制御する。実施形態において、制御部230は、例えば、以下に示す制御を行う。
[0029]
 制御部230は、施設300に設けられる設備のエラーの内容を含むアラートをスレッド情報DB213に登録する。制御部230は、施設300に設けられる設備のエラーに対する処理を含む処理ステータスをスレッド情報DB213に登録する。制御部230は、アラートと処理ステータスとを1対1の関係で管理するためのスレッドを管理する。スレッドは、上述したように、スレッド情報DB213に記憶される。すなわち、制御部230は、スレッド情報DB213を用いてスレッドを管理する。
[0030]
 ここで、制御部230は、2以上のエラーが所定条件を満たしている場合に、2以上のエラーを1つのエラー通知に統合すると判定する。このようなケースにおいて、通信部220は、2以上のエラーの発生を示す情報を含むエラー通知をユーザ端末400に送信する。すなわち、通信部220は、1つのエラー通知をユーザ端末400に送信する。一方で、制御部230は、2以上のエラーが所定条件を満たしていない場合に、2以上のエラーを1つのエラー通知に統合しないと判定する。このようなケースにおいて、通信部220は、2以上のエラーのそれぞれと1対1の関係でエラー通知をユーザ端末400に送信する。すなわち、通信部220は、2以上のエラー通知をユーザ端末400に送信する。
[0031]
 ここで、所定条件は、2以上のエラーが同一の原因から発生する条件を含んでもよい。同一の原因は、2以上のエラーのいずれか一方であってもよく、2以上のエラーとは異なる原因であってもよい。2以上のエラーとは異なる原因は、施設300から送信されるアラート以外によって特定される原因(例えば、災害等に伴うインフラストラクチャの機能不全(停電など))であってもよい。
[0032]
 所定条件は、2以上のエラーが1つの設備において同一の原因から発生する条件を含んでもよい。所定条件は、2以上のエラーが1つのエリアに設けられる2以上の設備において同一の原因から発生する条件を含んでもよい。所定条件は、2以上のエラーが2以上のエリアに設けられる2以上の設備において同一の原因から発生する条件を含んでもよい。
[0033]
 エリアは、1つの施設300が設けられるエリアと考えてもよく、グループ化された2以上の施設300が設けられるエリアと考えてもよい。エリアは、1つ以上の施設300についてグループ化された2以上の設備が設けられるエリアと考えてもよい。2以上の施設300のグループ化は、例えば、電力系統110を介する施設300の接続関係に基づいて行われてもよい。2以上の設備のグループ化は、例えば、設備の接続関係に基づいて行われてもよい。このように、エリアは、地理的な要素によって区画されるエリアであってもよく、施設300及び設備の少なくともいずれか1つの接続関係によって区画されるエリアであってもよい。
[0034]
 所定条件は、さらに時間的な要素を含んでもよい。具体的には、所定条件は、2以上のエラーが1つの設備において第1時間(例えば、60秒)内に同一の原因から発生する条件(以下、第1条件)を含んでもよい。所定条件は、2以上のエラーが1つのエリアに設けられる2以上の設備において第1時間よりも長い第2時間(例えば、120秒)内に同一の原因から発生する条件(以下、第2条件)を含んでもよい。所定条件は、2以上のエラーが2以上のエリアに設けられる2以上の設備において第2時間よりも長い第3時間(例えば、180秒)内に同一の原因から発生する条件(以下、第3条件)を含んでもよい。
[0035]
 第1時間は、アラートの収集頻度に基づいて定められてもよい。アラートの収集頻度は、施設300に対してアラートを問い合わせる頻度であってもよく、施設300から受信するアラートを格納するバッファを制御部230が確認する頻度であってもよい。第2時間は、1つのエリアに設けられる2以上の設備についてシステムで許容可能な遅延時間に基づいて定められてもよい。第3時間は、2以上のエリアについてシステムで許容可能な遅延時間に基づいて定められてもよい。
[0036]
 第1時間、第2時間及び第3時間は、エラーの内容に基づいて定められてもよい。電力ケーブルの欠損に伴う停電などの原因から広範囲に亘ってエラーが生じる場合には、第1時間、第2時間及び第3時間として相対的に長い時間が定められてもよい。停電などの原因からエラーが生じるケースにおいて、非常電源を有する設備又は施設300について、第1時間、第2時間及び第3時間として相対的に長い時間が定められてもよい。
[0037]
 第1時間、第2時間及び第3時間は、アラートを確認するためのヒューマンリソースに基づいて定められてもよい。例えば、ヒューマンリソースが少ないほど、第1時間、第2時間及び第3時間として相対的に長い時間が定められてもよい。
[0038]
 ここで、第1条件、第2条件及び第3条件は、排他的な条件と考える必要がない。すなわち、第1条件、第2条件及び第3条件のうち、2以上の条件が同時に満たされることがあってもよい。
[0039]
 (エラー通知の一例)
 以下において、エラー通知の一例について説明する。図3~図5に示すように、エラー通知は、「案件番号」、「エリア」、「アラート種別」、「メッセージ」、「参照URL」などの情報要素を含む。「案件番号」は、エラー通知に割り当てられる識別子である。「エリア」は、エラーを生じた設備が設けられるエリアの名称である。「設備」は、エラーを生じた設備の識別子である。「メッセージ」は、ユーザが取るべき動作をガイドする文字列である。「参照URL」は、スレッド情報DB213に記憶されたスレッドにアクセスするためのURL(Uniform Resource Locator)である。
[0040]
 第1に、上述した第1条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図3に示すように、1つのエリア及び1つの設備を対象として、3つのエラー(ここでは、エラーA、エラーC及びエラーE)が統合されている。エラーA、エラーC及びエラーEは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。
[0041]
 第2に、上述した第2条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図4に示すように、1つのエリアにおける2つの設備を対象として、4つのエラー(ここでは、2つのエラーB及び2つのエラーD)が統合されている。エラーB及びエラーDは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。
[0042]
 第3に、上述した第3条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図5に示すように、2つのエリアにおける5つの設備を対象として、13個のエラー(ここでは、5つのエラーB、5つのエラーD及び3つのエラーF)が統合されている。エラーB、エラーD及びエラーFは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。
[0043]
 図5に示すケースでは、「参照URL」としてエリア毎の2つの参照URLが通知される。但し、スレッドがエリア毎に管理されない場合には、「参照URL」として1つの参照URLが通知されてもよい。
[0044]
 (設備管理方法)
 以下において、実施形態に係る設備管理方法について説明する。
[0045]
 図6に示すように、ステップS11において、施設300は、施設300に設けられる設備のエラーの内容を含むアラートを設備管理装置200に送信する。ここでは、3つのアラートが設備管理装置200に送信される(ステップS11A、ステップS11B及びステップS11C)。
[0046]
 ステップS12において、設備管理装置200は、施設300に設けられる設備のエラーに対する処理を含む処理ステータスをスレッド情報DB213に登録する。
[0047]
 ステップS13において、設備管理装置200は、アラートと処理ステータスとを1対1の関係で管理するためのスレッドを管理する。スレッドは、上述したように、スレッド情報DB213に記憶される。
[0048]
 ステップS14において、設備管理装置200は、エラー通知をユーザ端末400に送信する。ここで、設備管理装置200は、2以上のエラーが所定条件を満たしている場合に、2以上のエラーの発生を示す情報を含むエラー通知を送信する。一方で、設備管理装置200は、2以上のエラーが所定条件を満たしていない場合に、2以上のエラーのそれぞれと1対1の関係でエラー通知を送信する。
[0049]
 続いて、ステップS14の詳細について、図7を参照しながら説明を続ける。図7は、所定周期(例えば、5分)毎に繰り返されるフローである。所定周期は、例えば、上述した第3時間よりも長い周期であってもよい。
[0050]
 図7に示すように、ステップS21において、設備管理装置200は、上述した第3条件を満たす未通知アラートが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS24の処理が行われ、判定結果がNOである場合には、ステップS22の処理が行われる。
[0051]
 ステップS22において、設備管理装置200は、上述した第2条件を満たす未通知アラートが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS25の処理が行われ、判定結果がNOである場合には、ステップS23の処理が行われる。
[0052]
 ステップS23において、設備管理装置200は、上述した第1条件を満たす未通知アラートが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS26の処理が行われ、判定結果がNOである場合には、ステップS27の処理が行われる。
[0053]
 ステップS24において、設備管理装置200は、第3条件を満たす2以上の未通知アラートを統合する。すなわち、設備管理装置200は、2以上のエラー(未通知アラート)の発生を示す情報を含むエラー通知を送信する。
[0054]
 ステップS25において、設備管理装置200は、第2条件を満たす2以上の未通知アラートを統合する。すなわち、設備管理装置200は、2以上のエラー(未通知アラート)の発生を示す情報を含むエラー通知を送信する。
[0055]
 ステップS26において、設備管理装置200は、第1条件を満たす2以上の未通知アラートを統合する。すなわち、設備管理装置200は、2以上のエラー(未通知アラート)の発生を示す情報を含むエラー通知を送信する。
[0056]
 ステップS27において、設備管理装置200は、1つのエラー(未通知アラート)を個別に送信する。未通知アラートが存在しない場合には、ステップS27の処理は省略される。
[0057]
 図7においては、所定条件として、第1条件、第2条件及び第3条件が用いられるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。所定条件は、時間的な要素を含まなくてもよい。
[0058]
 (作用及び効果)
 実施形態では、設備管理装置200は、2以上のエラーが所定条件を満たしている場合に、2以上のエラーの発生を示す情報を含むエラー通知をユーザ端末400に送信する。このような構成によれば、エラー毎にエラー通知がユーザ端末400に送信されるケースと比べて、エラー通知を確認するユーザの作業負荷を軽減することができる。
[0059]
 実施形態では、設備管理装置200は、2以上のエラーが所定条件を満たしていない場合に、2以上のエラーのそれぞれと1対1の関係でエラー通知をユーザ端末400に送信する。このような構成によれば、1つのエラー通知に対する2以上のエラーの統合を無制限に行わないため、エラーの発生の見逃しを低減することができる。
[0060]
 [変更例1]
 以下において、実施形態の変更例1について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例1は、上述した実施形態と組み合わせることができる。
[0061]
 具体的には、実施形態では、所定条件を満たす2以上のエラーを1つのエラー通知に統合するケースについて説明した。これに対して、変更例1では、所定条件を満たす2以上のスレッドの統合について説明する。
[0062]
 詳細には、設備管理装置200の制御部230は、2以上のスレッドが所定条件を満たしている場合に、2以上のスレッドを統合する。ここで、統合後のスレッドは、2以上のエラーについて、アラート及び処理ステータスを含んでもよい。一方で、制御部230は、2以上のスレッドが所定条件を満たしていない場合に、2以上のスレッドを統合しない。
[0063]
 ここで、所定条件は、2以上のスレッドが同一の原因から生成される条件を含んでもよい。同一の原因は、2以上のスレッドのいずれか一方のスレッドが生成される原因であってもよく、2以上のスレッドが生成される原因とは異なる原因であってもよい。2以上のスレッドが生成される原因とは異なる原因は、施設300から送信されるアラート以外によって特定される原因(例えば、災害等に伴うインフラストラクチャの機能不全(停電など))であってもよい。
[0064]
 所定条件は、2以上のスレッドが1つの設備において同一の原因から生成される条件を含んでもよい。所定条件は、2以上のスレッドが1つのエリアに設けられる2以上の設備において同一の原因から生成される条件を含んでもよい。所定条件は、2以上のスレッドが2以上のエリアに設けられる2以上の設備において同一の原因から生成される条件を含んでもよい。エリアの考え方は実施形態と同様である。
[0065]
 所定条件は、さらに時間的な要素を含んでもよい。具体的には、所定条件は、2以上のスレッドが1つの設備において第4時間(例えば、60秒)内に同一の原因から生成される条件(以下、第4条件)を含んでもよい。所定条件は、2以上のスレッドが1つのエリアに設けられる2以上の設備において第4時間よりも長い第5時間(例えば、120秒)内に同一の原因から生成される条件(以下、第5条件)を含んでもよい。所定条件は、2以上のスレッドが2以上のエリアに設けられる2以上の設備において第5時間よりも長い第6時間(例えば、180秒)内に同一の原因から生成される条件(以下、第6条件)を含んでもよい。
[0066]
 ここで、第4条件、第5条件及び第6条件は、排他的な条件と考える必要がない。すなわち、第4条件、第5条件及び第6条件のうち、2以上の条件が同時に満たされることがあってもよい。
[0067]
 変更例1に係る第4条件(すなわち、第4時間)は、実施形態に係る第1条件(すなわち、第1時間)と同じであってもよく、実施形態に係る第1条件と異なっていてもよい。変更例1に係る第5条件(すなわち、第5時間)は、実施形態に係る第2条件(すなわち、第2時間)と同じであってもよく、実施形態に係る第2条件と異なっていてもよい。変更例1に係る第6条件(すなわち、第6時間)は、実施形態に係る第3条件(すなわち、第3時間)と同じであってもよく、実施形態に係る第3条件と異なっていてもよい。
[0068]
 このような前提下において、第1エラーと対応する第1スレッドと第1エラーが原因で生じる第2エラーと対応する第2スレッドとを2以上のスレッドが含むケースについて考える。
[0069]
 第1に、制御部230は、第2エラーが生じる原因と考えられる第1エラーが1つである場合に、第1スレッド及び第2スレッドを統合してもよい。例えば、図8に示すように、エラーAが原因でエラーB1及びエラーB2が生じるケースについて考える。このようなケースにおいては、エラーAと対応する第1スレッド及びエラーB1と対応する第2スレッドが統合される。同様に、エラーAと対応する第1スレッド及びエラーB2と対応する第2スレッドが統合される。すなわち、3つのスレッドが2つのスレッドに統合される。更に、エラーB1及びエラーB2が同一の原因(エラーA)から発生するため、エラーB1と対応するスレッド及びエラーB2と対応するスレッドが統合されてもよい。すなわち、3つのスレッドが1つのスレッドに統合される。
[0070]
 なお、エラーAは、例えば、施設300に設けられるGW(Gateway)の異常である。エラーB1は、例えば、設備から送信されるべきデータの欠損である。エラーB2は、例えば、通信の切断に伴う設備の制御異常である。
[0071]
 第2に、制御部230は、第2エラーが生じる原因と考えられる第1エラーが2以上である場合に、第1スレッド及び第2スレッドを統合しなくてもよい。例えば、図9に示すように、エラーA1及びエラーA2が原因でエラーBが生じるケースについて考える。このようなケースにおいては、エラーA1と対応する第1スレッド及びエラーBと対応する第2スレッドが統合されない。同様に、エラーA2と対応する第1スレッド及びエラーBと対応する第2スレッドが統合されない。
[0072]
 なお、エラーA1は、例えば、施設300に設けられるGW(Gateway)の異常である。エラーA2は、例えば、設備に設けられる一部の装置の異常である。エラーBは、例えば、通信の切断又は一部の装置の異常に伴う設備の制御異常である。
[0073]
 第3に、制御部230は、2以上の第1エラーのうち、1つの第1エラーを除いた残りの第1エラーが復旧しても第2エラーが復旧していない場合に、1つの第1エラーと対応する第1スレッド及び第2エラーと対応する第2スレッドを統合してもよい。さらに時間的な要素が考慮されてもよい。具体的には、制御部230は、残りの第1エラーが復旧してから所定期間が経過しても、第2エラーが復旧していない場合に、1つの第1エラーと対応する第1スレッド及び第2エラーと対応する第2スレッドを統合してもよい。例えば、図10に示すように、図9に示す状態からエラーA2が復旧したケースについて考える。このようなケースにおいては、エラーA1と対応する第1スレッド及びエラーBと対応する第2スレッドが統合される。
[0074]
 (設備管理方法)
 以下において、変更例1に係る設備管理方法について説明する。図11は、所定周期(例えば、5分)毎に繰り返されるフローである。所定周期は、例えば、上述した第6時間よりも長い周期であってもよい。
[0075]
 図11に示すように、ステップS31において、設備管理装置200は、上述した第6条件を満たすスレッドが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS34の処理が行われ、判定結果がNOである場合には、ステップS32の処理が行われる。
[0076]
 ステップS32において、設備管理装置200は、上述した第5条件を満たすスレッドが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS35の処理が行われ、判定結果がNOである場合には、ステップS33の処理が行われる。
[0077]
 ステップS33において、設備管理装置200は、上述した第4条件を満たすスレッドが2以上であるか否かを判定する。判定結果がYESである場合には、ステップS36の処理が行われ、判定結果がNOである場合には、一連の処理が終了する。
[0078]
 ステップS34において、設備管理装置200は、第6条件を満たす2以上のスレッドを統合する。
[0079]
 ステップS35において、設備管理装置200は、第5条件を満たす2以上のスレッドを統合する。
[0080]
 ステップS36において、設備管理装置200は、第4条件を満たす2以上のスレッドを統合する。
[0081]
 図11においては、所定条件として、第4条件、第5条件及び第6条件が用いられるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。所定条件は、時間的な要素を含まなくてもよい。さらに、図8~図10に示したように、第2エラーが生じる原因と考えられる第1エラーが2以上であるか否かに応じて、2以上のスレッドを統合するか否かが判定されてもよい。
[0082]
 (作用及び効果)
 変更例1では、設備管理装置200は、2以上のスレッドが所定条件を満たしている場合に、2以上のスレッドを統合する。このような構成によれば、エラー毎にスレッドが管理されるケースと比べて、スレッドを確認するユーザの作業負荷を軽減することができる。
[0083]
 変更例1では、設備管理装置200は、2以上のスレッドが所定条件を満たしていない場合に、2以上のスレッドを統合しない。このような構成によれば、1つのスレッドに対する2以上のエラーの統合を無制限に行わないため、エラーの発生の見逃し及びエラーに対する処理の漏れを低減することができる。
[0084]
 [変更例2]
 以下において、実施形態の変更例2について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例2は、上述した実施形態及び変更例1の少なくともいずれか1つと組み合わせることができる。
[0085]
 変更例2では、設備管理装置200の制御部230は、エラーの内容に応じてスレッドの優先度を管理する。例えば、制御部230は、施設300に与える影響が相対的に小さい内容を含むエラーと対応するスレッドの優先度として低優先度で管理し、施設300に与える影響が相対的に大きい内容を含むエラーと対応するスレッドの優先度として高優先度で管理する。制御部230は、スレッドの優先度に応じて、スレッドの一覧における表示態様を変更してもよい。例えば、制御部230は、高優先度のスレッドを第1態様で表示し、低優先度のスレッドを第1態様とは異なる第2態様で表示してもよい。第1態様は、第2態様よりも目立つ態様であってもよい。第1態様は、例えば、太字、赤字マーカなどによって文字列が強調された態様である。
[0086]
 このような前提下において、制御部230は、メンテナンス期間外で所定エラーが生じた場合に、スレッドの優先度として第1優先度を管理する。一方で、制御部230は、メンテナンス期間内に所定エラーが生じた場合に、スレッドの優先度として第1優先度よりも低い第2優先度を管理する。すなわち、所定エラーがメンテナンス期間内に生じたか否かに応じて、所定エラーと対応するスレッドの優先度が変更される。
[0087]
 ここで、メンテナンス期間は、実施形態で説明したように、メンテナンス情報DB212に記憶される。所定エラーは、施設300から送信されるアラートによって設備管理装置200に通知されるエラーであればよい。
[0088]
 制御部230は、メンテナンス期間が終わっても所定エラーが復旧しない場合に、第2優先度を第1優先度に戻してもよい。言い換えると、制御部230は、所定エラーの原因がメンテナンスではない場合に、第2優先度を第1優先度に戻してもよい。
[0089]
 制御部230は、所定エラーに対応するスレッドが第1優先度で管理されている場合に、エラー通知を第1方法で扱うとともに、所定エラーに対応するスレッドが第2優先度で管理されている場合に、エラー通知を第1方法とは異なる第2方法で扱ってもよい。
[0090]
 第1方法は、例えば、メンテナンス期間とは関係なく、所定エラーの発生に応じてエラー通知を送信する方法であってもよい。第2方法は、少なくともメンテナンス期間内においてエラー通知を行わない方法であってもよい。さらに、第2方法は、メンテナンス期間後においてエラー通知を行う方法であってもよい。このような第2方法において、メンテナンス期間内に生じた2以上の所定エラーは、1つのエラー通知に統合されてもよい。実施形態と同様に、メンテナンス期間内に生じた2以上の所定エラーが所定条件を満たす場合に、2以上の所定エラーが1つのエラー通知に統合されてもよい。
[0091]
 第1方法は、第1態様でエラー通知を行う方法であってもよい。第2方法は、第1態様とは異なる第2態様でエラー通知を行う方法であってもよい。第1態様は、第2態様よりも目立つ態様であってもよい。第1態様は、例えば、太字、赤字マーカなどによって文字列が強調された態様である。
[0092]
 (設備管理方法)
 以下において、変更例2に係る設備管理方法について説明する。図12は、施設300からアラートを受信した際に実行されるフローである。
[0093]
 図12に示すように、ステップS41において、設備管理装置200は、所定エラーがメンテナンス期間外に生じたか否かを判定する。判定結果がYESである場合に、ステップS42の処理が行われる。判定結果がNOである場合には、ステップS44の処理が行われる。
[0094]
 ステップS42において、設備管理装置200は、所定エラーと対応するスレッドを第1優先度で管理する。設備管理装置200は、スレッドの一覧において、所定エラーと対応するスレッドを第1態様で表示してもよい。
[0095]
 ステップS43において、設備管理装置200は、エラー通知を第1方法で扱う。第1方法の詳細は、上述した通りである。
[0096]
 ステップS44において、設備管理装置200は、所定エラーと対応するスレッドを第2優先度で管理する。設備管理装置200は、スレッドの一覧において、所定エラーと対応するスレッドを第2態様で表示してもよい。ステップS44の第2態様は、ステップS42の第1態様よりも目立たない態様である。
[0097]
 ステップS45において、設備管理装置200は、エラー通知を第2方法で扱う。第2方法の詳細は、上述した通りである。
[0098]
 (作用及び効果)
 変更例2では、設備管理装置200は、メンテナンス期間外で所定エラーが生じた場合に、スレッドの優先度として第1優先度を管理する。一方で、設備管理装置200は、メンテナンス期間内に所定エラーが生じた場合に、スレッドの優先度として第1優先度よりも低い第2優先度を管理する。このような構成によれば、メンテナンス期間内において所定エラーが頻発する可能性について着目し、このような所定エラーと対応するスレッドの優先度を下げることによって、スレッドを確認するユーザの作業負荷を軽減することができる。
[0099]
 [変更例3]
 以下において、実施形態の変更例3について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例3は、上述した実施形態、変更例1及び変更例2の少なくともいずれか1つと組み合わせることができる。
[0100]
 変更例3では、設備管理装置200の制御部230は、図13に示すように、エラーの階層構造を特定する。具体的には、エラーAが原因でエラーB1及びエラーB2が生じ、エラーB1が原因でエラーC1及びエラーC2が生じ、エラーB2が原因でエラーC3及びエラーC4が生じる。例えば、エラーAは、施設300と設備管理装置200との間の通信を中継するネットワークサーバの通信異常である。エラーB1は、施設300Aに設けられるゲートウェイの異常であり、エラーB2は、施設300Bに設けられるゲートウェイの通信異常である。エラーC1及びエラーC2は、施設300Aに設けられる設備の制御異常であり、エラーC3及びエラーC4は、施設300Bに設けられる設備の制御異常である。
[0101]
 このようなケースにおいて、制御部230は、実施形態と同様に、エラーA、エラーB1~B2及びエラーC1~C4を1つのエラー通知に統合してもよい。ここで、1つのエラー通知は、エラーB1~B2及びエラーC1~C4の発生を示す情報を含まずに、エラーAの発生を示す情報を含んでもよい。
[0102]
 さらに、制御部230は、変更例1と同様に、エラーA、エラーB1~B2及びエラーC1~C4と対応するスレッドを統合してもよい。統合後のスレッドは、エラーB1~B2及びエラーC1~C4についてアラート及び処理ステータスを含まずに、エラーAについてアラート及び処理ステータスを含んでもよい。
[0103]
 このように、設備管理装置200は、2以上のエラーの階層構造を特定し、階層構造を有するエラーを統合することによって、エラー通知又はスレッドの数を減少することができる。階層構造の特定は、過去に発生したエラーの学習によって行われてもよい。
[0104]
 [変更例4]
 以下において、実施形態の変更例4について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例4は、上述した実施形態、変更例1、変更例2及び変更例3の少なくともいずれか1つと組み合わせることができる。
[0105]
 変更例4において、設備管理装置200の制御部230は、変更例1と同様に、所定条件を満たす2以上のスレッドを統合する。所定条件は、エラーに対する処理を完了する前において、同様のエラーが再発することである。
[0106]
 例えば、スレッドの一覧は、図14~図17に示すように、「管理ID」、「詳細」、「状況」、「経過」、「施設」、「設備種別」、「対象設備」、「原因」、「稼働状況」、「継続状況」などの項目を含む。
[0107]
 「管理ID」は、スレッドを識別する識別子である。「詳細」は、スレッドの詳細を表示するためのアイコンである。「状況」は、上述した処理ステータスである。「経過」は、エラーが発生してから経過した時間である。「施設」は、エラーを生じた設備が設けられた施設の名称又は識別子である。「設備種別」は、エラーを生じた設備の種別である。「対象設備」は、エラーを生じた設備の名称又は識別子である。「原因」は、エラーの内容を示すコードである。「稼働状況」は、エラーを生じていない状態の稼働率が100%である前提においてエラーを生じた設備の稼働率である。「継続状況」は、エラーの継続状況であり、エラーの再発回数を示す「再発カウント」を含んでもよい。
[0108]
 図14に示すように、管理IDがA15000004であるスレッドは、エラーに対する処理を手配しておらず、エラーが3回に亘って再発していることを意味している。さらに、このスレッドは、エラーが継続していることを意味している。
[0109]
 図15に示すように、管理IDがA15000005であるスレッドは、エラーに対する処理を手配しているが、エラーが2回に亘って再発していることを意味している。さらに、このスレッドは、自動復旧によってエラーが復旧していることを意味している。自動復旧は、設備の再起動によって設備が自動的に復旧を試みる処理である。
[0110]
 図16に示すように、管理IDがA15000006であるスレッドは、エラーに対する処理を手配していることを意味している。このスレッドは、設備のエラーが暫定対応によってエラーが復旧していることを意味している。暫定対応は、依然としてメンテナンスを必要とする応急的な処理である。
[0111]
 図17に示すように、管理IDがA15000006であるスレッドは、エラーに対する処理を手配していることを意味している。このスレッドは、設備のエラーが暫定対応によって復旧した後にエラーが再発したことを意味している。
[0112]
 このようなスレッドの管理が行われるケースにおいて、制御部230は、自動復旧又は暫定対応によってエラーが復旧した後においてエラーが再発した場合であっても、再発エラーと対応する新たなスレッドを生成することなく、再発エラーを既存のスレッドに統合する。さらに、制御部230は、再発エラーを既存のスレッドに統合する場合に、既存のスレッドにおいて再発回数をカウントする。
[0113]
 一方で、制御部230は、自動復旧又は暫定対応ではなくメンテナンスによってエラーが復旧した後においてエラーが再発した場合には、再発エラーと対応する新たなスレッドを生成してもよい。さらに、制御部230は、再発エラーと対応する新たなスレッドにおいて再発回数をカウントしてもよい。
[0114]
 [その他の実施形態]
 本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
[0115]
 実施形態では、管理部210を構成する各種データベース(設備情報DB211、メンテナンス情報DB212及びスレッド情報DB213)が設備管理装置200に設けられるが、実施形態はこれに限定されるものではない。例えば、設備情報DB211、メンテナンス情報DB212及びスレッド情報DB213の少なくとも1以上のデータベースは、ネットワーク120を介して設備管理装置200と接続されるサーバに設けられてもよい。
[0116]
 なお、日本国特許出願第2017-064898号(2017年3月29日出願)の全内容が、参照により、本願に組み込まれている。

請求の範囲

[請求項1]
 設備のエラーの内容を含むアラートをデータベースに登録するステップAと、
 前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップBと、
 前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理するステップCと、
 前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信するステップDとを備え、
 前記ステップDは、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合するステップを含む、設備管理方法。
[請求項2]
 前記所定条件は、前記2以上のエラーが同一の原因から発生する条件を含む、請求項1に記載の設備管理方法。
[請求項3]
 前記所定条件は、前記2以上のエラーが1つの設備において同一の原因から発生する条件を含む、請求項1又は請求項2に記載の設備管理方法。
[請求項4]
 前記所定条件は、前記2以上のエラーが1つのエリアに設けられる2以上の設備において同一の原因から発生する条件を含む、請求項1乃至請求項3のいずれかに記載の設備管理方法。
[請求項5]
 前記所定条件は、前記2以上のエラーが2以上のエリアに設けられる2以上の設備において同一の原因から発生する条件を含む、請求項1乃至請求項4のいずれかに記載の設備管理方法。
[請求項6]
 前記所定条件は、前記2以上のエラーが1つの設備において第1時間内に同一の原因から発生する条件、及び、前記2以上のエラーが1つのエリアに設けられる2以上の設備において前記第1時間よりも長い第2時間内に同一の原因から発生する条件の少なくともいずれか1つを含む、請求項1乃至請求項5のいずれかに記載の設備管理方法。
[請求項7]
 前記所定条件は、前記2以上のエラーが1つのエリアに設けられる2以上の設備において第2時間内に同一の原因から発生する条件、及び、前記2以上のエラーが2以上のエリアに設けられる2以上の設備において前記第2時間よりも長い第3時間内に同一の原因から発生する条件の少なくともいずれか1つを含む、請求項1乃至請求項6のいずれかに記載の設備管理方法。
[請求項8]
 設備のエラーの内容を含むアラートをデータベースに登録するステップAと、
 前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップBと、
 前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理するステップCとを備え、
 前記ステップCは、2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合するステップを含む、設備管理方法。
[請求項9]
 前記所定条件は、前記2以上のスレッドが同一の原因から生成される条件を含む、請求項8に記載の設備管理方法。
[請求項10]
 前記所定条件は、前記2以上のスレッドが1つの設備において同一の原因から生成される条件を含む、請求項8又は請求項9に記載の設備管理方法。
[請求項11]
 前記所定条件は、前記2以上のスレッドが1つのエリアに設けられる2以上の設備において同一の原因から生成される条件を含む、請求項8乃至請求項10のいずれかに記載の設備管理方法。
[請求項12]
 前記所定条件は、前記2以上のスレッドが2以上のエリアに設けられる2以上の設備において同一の原因から生成される条件を含む、請求項8乃至請求項11のいずれかに記載の設備管理方法。
[請求項13]
 前記所定条件は、前記2以上のスレッドが1つの設備において第4時間内に同一の原因から生成される条件、及び、前記2以上のエラーが1つのエリアに設けられる2以上の設備において前記第4時間よりも長い第5時間内に同一の原因から生成される条件の少なくともいずれか1つを含む、請求項8乃至請求項12のいずれかに記載の設備管理方法。
[請求項14]
 前記所定条件は、前記2以上のスレッドが1つのエリアに設けられる2以上の設備において第5時間内に同一の原因から生成される条件、及び、前記2以上のスレッドが2以上のエリアに設けられる2以上の設備において前記第5時間よりも長い第6時間内に同一の原因から生成される条件の少なくともいずれか1つを含む、請求項8乃至請求項13のいずれかに記載の設備管理方法。
[請求項15]
 前記2以上のスレッドは、第1エラーと対応する第1スレッドと、前記第1エラーが原因で生じる第2エラーと対応する第2スレッドとを含み、
 前記ステップCは、前記第2エラーが生じる原因と考えられる前記第1エラーが2以上である場合に、前記第1スレッド及び前記第2スレッドを統合しないステップを含む、請求項8乃至請求項13のいずれかに記載の設備管理方法。
[請求項16]
 前記ステップCは、前記2以上の第1エラーのうち、1つの第1エラーを除いた残りの第1エラーが復旧しても前記第2エラーが復旧していない場合に、前記1つの第1エラーと対応する第1スレッド及び前記第2エラーと対応する第2スレッドを統合するステップを含む、請求項15に記載の設備管理方法。
[請求項17]
 前記ステップCは、前記残りの第1エラーが復旧してから所定期間が経過しても、前記第2エラーが復旧していない場合に、前記1つの第1エラーと対応する第1スレッド及び前記第2エラーと対応する第2スレッドを統合するステップを含む、請求項16に記載の設備管理方法。
[請求項18]
 前記ステップCは、
  前記エラーの内容に応じて前記スレッドの優先度を管理するステップと、
  前記設備のメンテナンス期間外で所定エラーが生じた場合に、前記スレッドの優先度として第1優先度を管理するステップと、
  前記メンテナンス期間内に前記所定エラーが生じた場合に、前記スレッドの優先度として前記第1優先度よりも低い第2優先度を管理するステップとを含む、請求項1乃至請求項17に記載の設備管理方法。
[請求項19]
 前記ステップCは、前記メンテナンス期間が終わっても前記所定エラーが復旧しない場合に、前記第2優先度を前記第1優先度に戻すステップを含む、請求項1乃至請求項18に記載の設備管理方法。
[請求項20]
 前記所定エラーの発生を示す情報を含むエラー通知をユーザ端末に送信するステップDとを備え、
 前記ステップDは、
  前記所定エラーに対応する前記スレッドが前記第1優先度で管理されている場合に、前記エラー通知を第1方法で扱うステップと、
  前記所定エラーに対応する前記スレッドが前記第2優先度で管理されている場合に、前記エラー通知を第1方法とは異なる第2方法で扱うステップとを含む、請求項17又は請求項19に記載の設備管理方法。
[請求項21]
 前記第2方法は、少なくとも前記メンテナンス期間内において前記エラー通知を行わない方法である、請求項20に記載の設備管理方法。
[請求項22]
 前記第2方法は、前記メンテナンス期間後において前記エラー通知を行う方法である、請求項21に記載の設備管理方法。
[請求項23]
 前記第1方法は、第1態様で前記エラー通知を行う方法であり、
 前記第2方法は、前記第1態様とは異なる第2態様で前記エラー通知を行う方法である、請求項20に記載の設備管理方法。
[請求項24]
 設備のエラーの内容を含むアラートをデータベースに登録する制御部と、
 前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備え、
 前記制御部は、
  前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、
  前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、
 前記送信部は、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合する、設備管理装置。
[請求項25]
 設備のエラーの内容を含むアラートをデータベースに登録する制御部を備え、
 前記制御部は、
  前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、
  前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、
  2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合する、設備管理装置。
[請求項26]
 少なくとも設備管理装置を有する設備管理システムであって、
 前記設備管理装置は、
 設備のエラーの内容を含むアラートをデータベースに登録する制御部と、
 前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備え、
 前記制御部は、
  前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、
  前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、
 前記送信部は、2以上のエラーが所定条件を満たしていない場合に、前記2以上のエラーを1つのエラー通知に統合せずに、前記2以上のエラーが前記所定条件を満たしている場合に、前記2以上のエラーを1つのエラー通知に統合する、設備管理システム。
[請求項27]
 少なくとも設備管理装置を有する設備管理システムであって、
 前記設備管理装置は、
 設備のエラーの内容を含むアラートをデータベースに登録する制御部を備え、
 前記制御部は、
  前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、
  前記アラートと前記処理ステータスとを1対1の関係で管理するためのスレッドを管理し、
  2以上のスレッドが所定条件を満たしていない場合に、前記2以上のスレッドを統合せずに、前記2以上のスレッドが前記所定条件を満たしている場合に、前記2以上のスレッドを統合する、設備管理システム。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]