JPWO2018181422A1 - 設備管理方法、設備管理装置及び設備管理システム - Google Patents

Abstract

設備管理方法は、設備のエラーの内容を含むアラートをデータベースに登録するステップＡと、前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップＢと、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理するステップＣと、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信するステップＤとを備える。前記ステップＤは、２以上のエラーが所定条件を満たしていない場合に、前記２以上のエラーを１つのエラー通知に統合せずに、前記２以上のエラーが所定条件を満たしている場合に、前記２以上のエラーを１つのエラー通知に統合するステップを含む。

Description

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

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

特開２００５−１８２３９９号公報

第１の特徴に係る設備管理方法は、設備のエラーの内容を含むアラートをデータベースに登録するステップＡと、前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップＢと、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理するステップＣと、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信するステップＤとを備える。前記ステップＤは、２以上のエラーが所定条件を満たしていない場合に、前記２以上のエラーを１つのエラー通知に統合せずに、前記２以上のエラーが前記所定条件を満たしている場合に、前記２以上のエラーを１つのエラー通知に統合するステップを含む。

第２の特徴に係る設備管理方法は、設備のエラーの内容を含むアラートをデータベースに登録するステップＡと、前記エラーに対する処理を含む処理ステータスを前記データベースに登録するステップＢと、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理するステップＣとを備える。前記ステップＣは、２以上のスレッドが所定条件を満たしていない場合に、前記２以上のスレッドを統合せずに、前記２以上のスレッドが前記所定条件を満たしている場合に、前記２以上のスレッドを統合するステップを含む。

第３の特徴に係る設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部と、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理する。前記送信部は、２以上のエラーが所定条件を満たしていない場合に、前記２以上のエラーを１つのエラー通知に統合せずに、前記２以上のエラーが前記所定条件を満たしている場合に、前記２以上のエラーを１つのエラー通知に統合する。

第４の特徴に係る設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部を備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理し、２以上のスレッドが所定条件を満たしていない場合に、前記２以上のスレッドを統合せずに、前記２以上のスレッドが前記所定条件を満たしている場合に、前記２以上のスレッドを統合する。

第５の特徴に係る設備管理システムは、少なくとも設備管理装置を有する。前記設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部と、前記エラーの発生を示す情報を含むエラー通知をユーザ端末に送信する送信部とを備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理する。前記送信部は、２以上のエラーが所定条件を満たしていない場合に、前記２以上のエラーを１つのエラー通知に統合せずに、前記２以上のエラーが前記所定条件を満たしている場合に、前記２以上のエラーを１つのエラー通知に統合する。

第６の特徴に係る設備管理システムは、少なくとも設備管理装置を有する。前記設備管理装置は、設備のエラーの内容を含むアラートをデータベースに登録する制御部を備える。前記制御部は、前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理し、２以上のスレッドが所定条件を満たしていない場合に、前記２以上のスレッドを統合せずに、前記２以上のスレッドが前記所定条件を満たしている場合に、前記２以上のスレッドを統合する。

図１は、実施形態に係る設備管理システム１００を示す図である。 図２は、実施形態に係る設備管理装置２００を示す図である。 図３は、実施形態に係るエラー通知の一例を示す図である。 図４は、実施形態に係るエラー通知の一例を示す図である。 図５は、実施形態に係るエラー通知の一例を示す図である。 図６は、実施形態に係る設備管理方法を示す図である。 図７は、実施形態に係る設備管理方法を示す図である。 図８は、変更例１に係るスレッドの統合を説明するための図である。 図９は、変更例１に係るスレッドの統合を説明するための図である。 図１０は、変更例１に係るスレッドの統合を説明するための図である。 図１１は、変更例１に係る設備管理方法を示す図である。 図１２は、変更例２に係る設備管理方法を示す図である。 図１３は、変更例３に係るエラーの階層構造を説明するための図である。 図１４は、変更例４に係るスレッドの一覧の一例を示す図である。 図１５は、変更例４に係るスレッドの一覧の一例を示す図である。 図１６は、変更例４に係るスレッドの一覧の一例を示す図である。 図１７は、変更例４に係るスレッドの一覧の一例を示す図である。

近年では、背景技術において述べた設備管理システムにおいて、設備のエラー等が発生した場合に、エラーの内容及びエラーに対する処理を１対１の関係で対応付けるスレッドを管理する仕組み（ワークフロー）も提案されている。さらに、エラーと１対１の関係でエラー通知をユーザ端末に送信する仕組みも提案されている。

しかしながら、設備管理システムで管理する設備の数の増大等に伴って、設備のエラーが頻発する可能性がある。従って、多数のスレッドが管理され、多数のエラー通知が通知される可能性がある。このようなケースにおいては、多数のスレッド又は多数のエラー通知を確認するユーザの作業が非常に煩雑になってしまう。

本発明は、多数のスレッド又は多数のエラー通知を確認するユーザの作業負荷を軽減することを可能とする設備管理方法、設備管理装置及び設備管理システムを提供する。

以下において、実施形態について図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。

ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。従って、具体的な寸法などは以下の説明を参酌して判断すべきである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。

［実施形態］
（設備管理システム）
以下において、実施形態に係る設備管理システムについて説明する。図１に示すように、設備管理システム１００は、設備管理装置２００と、施設３００と、ユーザ端末４００とを有する。図１では、施設３００として、施設３００Ａ〜施設３００Ｃが例示されている。設備管理装置２００及び施設３００は、ネットワーク１２０に接続されている。ネットワーク１２０は、設備管理装置２００と施設３００との間の回線、設備管理装置２００とユーザ端末４００との間の回線を提供すればよい。ネットワーク１２０は、例えば、インターネットである。ネットワーク１２０は、ＶＰＮなどの専用回線を提供してもよい。

設備管理装置２００は、施設３００に設けられる設備を管理する。設備管理装置２００の詳細については後述する（図２を参照）。

施設３００は、発電設備３１０及び負荷設備３２０を有する。発電設備３１０は、発電を行う設備であり、電力系統１１０に接続される。発電設備３１０は、太陽光、風力又は地熱などの自然エネルギーを利用して発電を行う設備であってもよい。発電設備３１０は、燃料電池装置であってもよく、蓄電池装置であってもよい。施設３００は、２種類以上の発電設備３１０を有してもよい。負荷設備３２０は、電力を消費する設備であり、電力系統１１０及び発電設備３１０の少なくともいずれか１つに接続される。負荷設備３２０は、空調設備であってもよく、照明設備であってもよい。

ユーザ端末４００は、施設３００に設けられる設備を管理する管理者などのユーザが所持する端末であってもよい。ユーザ端末４００は、施設３００に設けられる設備のメンテナンスを行う作業者などのユーザが所持する端末であってもよい。ユーザ端末４００は、スマートフォンであってもよく、タブレット端末であってもよく、パーソナルコンピュータであってもよい。

ここで、設備管理システム１００は、電力管理サーバを有していてもよい。電力管理サーバは、例えば、電力系統１１０から施設３００に対する潮流量の制御を要求する潮流制御メッセージ、施設３００から電力系統１１０に対する逆潮流量の制御を要求する逆潮流制御メッセージ、施設３００に設けられる発電設備３１０（分散電源）の制御を要求する電源制御メッセージなどを施設３００に送信する。

（設備管理装置）
以下において、実施形態に係る設備管理装置について説明する。図２に示すように、設備管理装置２００は、管理部２１０と、通信部２２０と、制御部２３０とを有する。

管理部２１０は、不揮発性メモリ又は／及びＨＤＤなどの記憶媒体によって構成されており、複数の施設３００に関する情報を管理する。管理部２１０は、設備情報ＤＢ２１１と、メンテナンス情報ＤＢ２１２と、スレッド情報ＤＢ２１３とを有する。

設備情報ＤＢ２１１は、複数の施設３００のそれぞれに設けられる設備の基本情報を記憶する。設備情報ＤＢ２１１は、例えば、施設名、施設ＩＤ、設備名、設備ＩＤ、導入年、経年及び耐用年数を対応付けて記憶する。施設名は、設備が設置される施設３００の名称である。施設ＩＤは、施設３００を識別する識別子である。設備名は、設備の名称である。設備ＩＤは、設備を識別する識別子である。導入年は、設備が導入された年である。経年は、設備が導入されてから経過した年である。耐用年数は、設備のメーカ等によって定められており、設備を導入してから設備を適切に使用可能な期間を示す情報である。

メンテナンス情報ＤＢ２１２は、複数の施設３００のそれぞれについて、複数の施設３００のそれぞれに設けられる設備のメンテナンス情報を記憶する。メンテナンス情報ＤＢ２１２は、例えば、施設名、設備名、メンテナンス日、メンテナンス概要及びメンテナンス詳細を対応付けて記憶する。メンテナンス情報ＤＢ２１２は、これらの情報とともに、施設ＩＤ及び設備ＩＤを対応付けて記憶してもよい。施設名及び設備名は、上述した通りである。メンテナンス日は、メンテナンスが行われた日付である。メンテナンス概要は、メンテナンスの概要を示す情報であり、メンテナンス詳細は、メンテナンスの詳細を示す情報である。実施形態に係るメンテナンス情報は、少なくとも、将来において発電設備３１０のメンテナンスを行うメンテナンス期間（予定）を含んでいればよい。メンテナンス情報は、過去において発電設備３１０のメンテナンスを行ったメンテナンス期間を含んでいてもよい。

ここで、メンテナンスは、例えば、設備の劣化状態を調査する点検、点検時に軽微な手入れを行う保守、設備の機能及び性能を設置当初の状態に戻すために設備の不具合を処置する修繕、既存の設備を新しい設備に交換する取替等を含む。

スレッド情報ＤＢ２１３は、アラートと処理ステータスとを１対１の関係で管理するためのスレッドを記憶する。アラートは、施設３００に設けられる設備のエラーの内容を含む情報要素である。アラートは、施設３００から送信される。処理ステータスは、施設３００に設けられる設備のエラーに対する処理を含む情報要素である。処理ステータスは、自動的に生成され、メンテナンスを行う作業者などのユーザによって更新される。処理ステータスは、エラーに対する処理を手配していない「手配待ち」、エラーに対する処理を手配した「手配済み」、エラーに対する処理を行っている「作業中」、エラーに対する処理を完了した「完了済み」を含んでもよい。エラーに対する処理は、上述したように、点検、保守、修繕、取替などを含んでもよい。スレッドは、アラートと処理ステータスとの関係を管理するための１つの単位である。スレッドは、例えば、このような関係をワンクリックで閲覧するための情報要素であってもよい。但し、スレッドは、アラートと処理ステータスとを１対１の関係で管理するためのコンセプトを逸脱しない情報要素であればよく、上述した関係をワンクリックで閲覧するための情報要素でなくてもよい。

通信部２２０は、通信モジュールによって構成されており、ネットワーク１２０を介して施設３００及びユーザ端末４００と通信を行う。通信部２２０は、施設３００に設けられる設備のエラーの内容を含むアラートを施設３００から受信する。通信部２２０は、施設３００に設けられる設備のエラーの発生を示す情報を含むエラー通知をユーザ端末４００に送信する。

制御部２３０は、メモリ及びＣＰＵなどによって構成されており、設備管理装置２００に設けられる各構成を制御する。実施形態において、制御部２３０は、例えば、以下に示す制御を行う。

制御部２３０は、施設３００に設けられる設備のエラーの内容を含むアラートをスレッド情報ＤＢ２１３に登録する。制御部２３０は、施設３００に設けられる設備のエラーに対する処理を含む処理ステータスをスレッド情報ＤＢ２１３に登録する。制御部２３０は、アラートと処理ステータスとを１対１の関係で管理するためのスレッドを管理する。スレッドは、上述したように、スレッド情報ＤＢ２１３に記憶される。すなわち、制御部２３０は、スレッド情報ＤＢ２１３を用いてスレッドを管理する。

ここで、制御部２３０は、２以上のエラーが所定条件を満たしている場合に、２以上のエラーを１つのエラー通知に統合すると判定する。このようなケースにおいて、通信部２２０は、２以上のエラーの発生を示す情報を含むエラー通知をユーザ端末４００に送信する。すなわち、通信部２２０は、１つのエラー通知をユーザ端末４００に送信する。一方で、制御部２３０は、２以上のエラーが所定条件を満たしていない場合に、２以上のエラーを１つのエラー通知に統合しないと判定する。このようなケースにおいて、通信部２２０は、２以上のエラーのそれぞれと１対１の関係でエラー通知をユーザ端末４００に送信する。すなわち、通信部２２０は、２以上のエラー通知をユーザ端末４００に送信する。

ここで、所定条件は、２以上のエラーが同一の原因から発生する条件を含んでもよい。同一の原因は、２以上のエラーのいずれか一方であってもよく、２以上のエラーとは異なる原因であってもよい。２以上のエラーとは異なる原因は、施設３００から送信されるアラート以外によって特定される原因（例えば、災害等に伴うインフラストラクチャの機能不全（停電など））であってもよい。

所定条件は、２以上のエラーが１つの設備において同一の原因から発生する条件を含んでもよい。所定条件は、２以上のエラーが１つのエリアに設けられる２以上の設備において同一の原因から発生する条件を含んでもよい。所定条件は、２以上のエラーが２以上のエリアに設けられる２以上の設備において同一の原因から発生する条件を含んでもよい。

エリアは、１つの施設３００が設けられるエリアと考えてもよく、グループ化された２以上の施設３００が設けられるエリアと考えてもよい。エリアは、１つ以上の施設３００についてグループ化された２以上の設備が設けられるエリアと考えてもよい。２以上の施設３００のグループ化は、例えば、電力系統１１０を介する施設３００の接続関係に基づいて行われてもよい。２以上の設備のグループ化は、例えば、設備の接続関係に基づいて行われてもよい。このように、エリアは、地理的な要素によって区画されるエリアであってもよく、施設３００及び設備の少なくともいずれか１つの接続関係によって区画されるエリアであってもよい。

所定条件は、さらに時間的な要素を含んでもよい。具体的には、所定条件は、２以上のエラーが１つの設備において第１時間（例えば、６０秒）内に同一の原因から発生する条件（以下、第１条件）を含んでもよい。所定条件は、２以上のエラーが１つのエリアに設けられる２以上の設備において第１時間よりも長い第２時間（例えば、１２０秒）内に同一の原因から発生する条件（以下、第２条件）を含んでもよい。所定条件は、２以上のエラーが２以上のエリアに設けられる２以上の設備において第２時間よりも長い第３時間（例えば、１８０秒）内に同一の原因から発生する条件（以下、第３条件）を含んでもよい。

第１時間は、アラートの収集頻度に基づいて定められてもよい。アラートの収集頻度は、施設３００に対してアラートを問い合わせる頻度であってもよく、施設３００から受信するアラートを格納するバッファを制御部２３０が確認する頻度であってもよい。第２時間は、１つのエリアに設けられる２以上の設備についてシステムで許容可能な遅延時間に基づいて定められてもよい。第３時間は、２以上のエリアについてシステムで許容可能な遅延時間に基づいて定められてもよい。

第１時間、第２時間及び第３時間は、エラーの内容に基づいて定められてもよい。電力ケーブルの欠損に伴う停電などの原因から広範囲に亘ってエラーが生じる場合には、第１時間、第２時間及び第３時間として相対的に長い時間が定められてもよい。停電などの原因からエラーが生じるケースにおいて、非常電源を有する設備又は施設３００について、第１時間、第２時間及び第３時間として相対的に長い時間が定められてもよい。

第１時間、第２時間及び第３時間は、アラートを確認するためのヒューマンリソースに基づいて定められてもよい。例えば、ヒューマンリソースが少ないほど、第１時間、第２時間及び第３時間として相対的に長い時間が定められてもよい。

ここで、第１条件、第２条件及び第３条件は、排他的な条件と考える必要がない。すなわち、第１条件、第２条件及び第３条件のうち、２以上の条件が同時に満たされることがあってもよい。

（エラー通知の一例）
以下において、エラー通知の一例について説明する。図３〜図５に示すように、エラー通知は、「案件番号」、「エリア」、「アラート種別」、「メッセージ」、「参照ＵＲＬ」などの情報要素を含む。「案件番号」は、エラー通知に割り当てられる識別子である。「エリア」は、エラーを生じた設備が設けられるエリアの名称である。「設備」は、エラーを生じた設備の識別子である。「メッセージ」は、ユーザが取るべき動作をガイドする文字列である。「参照ＵＲＬ」は、スレッド情報ＤＢ２１３に記憶されたスレッドにアクセスするためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。

第１に、上述した第１条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図３に示すように、１つのエリア及び１つの設備を対象として、３つのエラー（ここでは、エラーＡ、エラーＣ及びエラーＥ）が統合されている。エラーＡ、エラーＣ及びエラーＥは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。

第２に、上述した第２条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図４に示すように、１つのエリアにおける２つの設備を対象として、４つのエラー（ここでは、２つのエラーＢ及び２つのエラーＤ）が統合されている。エラーＢ及びエラーＤは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。

第３に、上述した第３条件が満たされるケースにおけるエラー通知の一例について説明する。このようなケースに係るエラー通知においては、図５に示すように、２つのエリアにおける５つの設備を対象として、１３個のエラー（ここでは、５つのエラーＢ、５つのエラーＤ及び３つのエラーＦ）が統合されている。エラーＢ、エラーＤ及びエラーＦは、同一の原因から発生するエラーの一例であり、これらの内容は特に限定されるものではない。

図５に示すケースでは、「参照ＵＲＬ」としてエリア毎の２つの参照ＵＲＬが通知される。但し、スレッドがエリア毎に管理されない場合には、「参照ＵＲＬ」として１つの参照ＵＲＬが通知されてもよい。

（設備管理方法）
以下において、実施形態に係る設備管理方法について説明する。

図６に示すように、ステップＳ１１において、施設３００は、施設３００に設けられる設備のエラーの内容を含むアラートを設備管理装置２００に送信する。ここでは、３つのアラートが設備管理装置２００に送信される（ステップＳ１１Ａ、ステップＳ１１Ｂ及びステップＳ１１Ｃ）。

ステップＳ１２において、設備管理装置２００は、施設３００に設けられる設備のエラーに対する処理を含む処理ステータスをスレッド情報ＤＢ２１３に登録する。

ステップＳ１３において、設備管理装置２００は、アラートと処理ステータスとを１対１の関係で管理するためのスレッドを管理する。スレッドは、上述したように、スレッド情報ＤＢ２１３に記憶される。

ステップＳ１４において、設備管理装置２００は、エラー通知をユーザ端末４００に送信する。ここで、設備管理装置２００は、２以上のエラーが所定条件を満たしている場合に、２以上のエラーの発生を示す情報を含むエラー通知を送信する。一方で、設備管理装置２００は、２以上のエラーが所定条件を満たしていない場合に、２以上のエラーのそれぞれと１対１の関係でエラー通知を送信する。

続いて、ステップＳ１４の詳細について、図７を参照しながら説明を続ける。図７は、所定周期（例えば、５分）毎に繰り返されるフローである。所定周期は、例えば、上述した第３時間よりも長い周期であってもよい。

図７に示すように、ステップＳ２１において、設備管理装置２００は、上述した第３条件を満たす未通知アラートが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ２４の処理が行われ、判定結果がＮＯである場合には、ステップＳ２２の処理が行われる。

ステップＳ２２において、設備管理装置２００は、上述した第２条件を満たす未通知アラートが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ２５の処理が行われ、判定結果がＮＯである場合には、ステップＳ２３の処理が行われる。

ステップＳ２３において、設備管理装置２００は、上述した第１条件を満たす未通知アラートが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ２６の処理が行われ、判定結果がＮＯである場合には、ステップＳ２７の処理が行われる。

ステップＳ２４において、設備管理装置２００は、第３条件を満たす２以上の未通知アラートを統合する。すなわち、設備管理装置２００は、２以上のエラー（未通知アラート）の発生を示す情報を含むエラー通知を送信する。

ステップＳ２５において、設備管理装置２００は、第２条件を満たす２以上の未通知アラートを統合する。すなわち、設備管理装置２００は、２以上のエラー（未通知アラート）の発生を示す情報を含むエラー通知を送信する。

ステップＳ２６において、設備管理装置２００は、第１条件を満たす２以上の未通知アラートを統合する。すなわち、設備管理装置２００は、２以上のエラー（未通知アラート）の発生を示す情報を含むエラー通知を送信する。

ステップＳ２７において、設備管理装置２００は、１つのエラー（未通知アラート）を個別に送信する。未通知アラートが存在しない場合には、ステップＳ２７の処理は省略される。

図７においては、所定条件として、第１条件、第２条件及び第３条件が用いられるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。所定条件は、時間的な要素を含まなくてもよい。

（作用及び効果）
実施形態では、設備管理装置２００は、２以上のエラーが所定条件を満たしている場合に、２以上のエラーの発生を示す情報を含むエラー通知をユーザ端末４００に送信する。このような構成によれば、エラー毎にエラー通知がユーザ端末４００に送信されるケースと比べて、エラー通知を確認するユーザの作業負荷を軽減することができる。

実施形態では、設備管理装置２００は、２以上のエラーが所定条件を満たしていない場合に、２以上のエラーのそれぞれと１対１の関係でエラー通知をユーザ端末４００に送信する。このような構成によれば、１つのエラー通知に対する２以上のエラーの統合を無制限に行わないため、エラーの発生の見逃しを低減することができる。

［変更例１］
以下において、実施形態の変更例１について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例１は、上述した実施形態と組み合わせることができる。

具体的には、実施形態では、所定条件を満たす２以上のエラーを１つのエラー通知に統合するケースについて説明した。これに対して、変更例１では、所定条件を満たす２以上のスレッドの統合について説明する。

詳細には、設備管理装置２００の制御部２３０は、２以上のスレッドが所定条件を満たしている場合に、２以上のスレッドを統合する。ここで、統合後のスレッドは、２以上のエラーについて、アラート及び処理ステータスを含んでもよい。一方で、制御部２３０は、２以上のスレッドが所定条件を満たしていない場合に、２以上のスレッドを統合しない。

ここで、所定条件は、２以上のスレッドが同一の原因から生成される条件を含んでもよい。同一の原因は、２以上のスレッドのいずれか一方のスレッドが生成される原因であってもよく、２以上のスレッドが生成される原因とは異なる原因であってもよい。２以上のスレッドが生成される原因とは異なる原因は、施設３００から送信されるアラート以外によって特定される原因（例えば、災害等に伴うインフラストラクチャの機能不全（停電など））であってもよい。

所定条件は、２以上のスレッドが１つの設備において同一の原因から生成される条件を含んでもよい。所定条件は、２以上のスレッドが１つのエリアに設けられる２以上の設備において同一の原因から生成される条件を含んでもよい。所定条件は、２以上のスレッドが２以上のエリアに設けられる２以上の設備において同一の原因から生成される条件を含んでもよい。エリアの考え方は実施形態と同様である。

所定条件は、さらに時間的な要素を含んでもよい。具体的には、所定条件は、２以上のスレッドが１つの設備において第４時間（例えば、６０秒）内に同一の原因から生成される条件（以下、第４条件）を含んでもよい。所定条件は、２以上のスレッドが１つのエリアに設けられる２以上の設備において第４時間よりも長い第５時間（例えば、１２０秒）内に同一の原因から生成される条件（以下、第５条件）を含んでもよい。所定条件は、２以上のスレッドが２以上のエリアに設けられる２以上の設備において第５時間よりも長い第６時間（例えば、１８０秒）内に同一の原因から生成される条件（以下、第６条件）を含んでもよい。

ここで、第４条件、第５条件及び第６条件は、排他的な条件と考える必要がない。すなわち、第４条件、第５条件及び第６条件のうち、２以上の条件が同時に満たされることがあってもよい。

変更例１に係る第４条件（すなわち、第４時間）は、実施形態に係る第１条件（すなわち、第１時間）と同じであってもよく、実施形態に係る第１条件と異なっていてもよい。変更例１に係る第５条件（すなわち、第５時間）は、実施形態に係る第２条件（すなわち、第２時間）と同じであってもよく、実施形態に係る第２条件と異なっていてもよい。変更例１に係る第６条件（すなわち、第６時間）は、実施形態に係る第３条件（すなわち、第３時間）と同じであってもよく、実施形態に係る第３条件と異なっていてもよい。

このような前提下において、第１エラーと対応する第１スレッドと第１エラーが原因で生じる第２エラーと対応する第２スレッドとを２以上のスレッドが含むケースについて考える。

第１に、制御部２３０は、第２エラーが生じる原因と考えられる第１エラーが１つである場合に、第１スレッド及び第２スレッドを統合してもよい。例えば、図８に示すように、エラーＡが原因でエラーＢ１及びエラーＢ２が生じるケースについて考える。このようなケースにおいては、エラーＡと対応する第１スレッド及びエラーＢ１と対応する第２スレッドが統合される。同様に、エラーＡと対応する第１スレッド及びエラーＢ２と対応する第２スレッドが統合される。すなわち、３つのスレッドが２つのスレッドに統合される。更に、エラーＢ１及びエラーＢ２が同一の原因（エラーＡ）から発生するため、エラーＢ１と対応するスレッド及びエラーＢ２と対応するスレッドが統合されてもよい。すなわち、３つのスレッドが１つのスレッドに統合される。

なお、エラーＡは、例えば、施設３００に設けられるＧＷ（Ｇａｔｅｗａｙ）の異常である。エラーＢ１は、例えば、設備から送信されるべきデータの欠損である。エラーＢ２は、例えば、通信の切断に伴う設備の制御異常である。

第２に、制御部２３０は、第２エラーが生じる原因と考えられる第１エラーが２以上である場合に、第１スレッド及び第２スレッドを統合しなくてもよい。例えば、図９に示すように、エラーＡ１及びエラーＡ２が原因でエラーＢが生じるケースについて考える。このようなケースにおいては、エラーＡ１と対応する第１スレッド及びエラーＢと対応する第２スレッドが統合されない。同様に、エラーＡ２と対応する第１スレッド及びエラーＢと対応する第２スレッドが統合されない。

なお、エラーＡ１は、例えば、施設３００に設けられるＧＷ（Ｇａｔｅｗａｙ）の異常である。エラーＡ２は、例えば、設備に設けられる一部の装置の異常である。エラーＢは、例えば、通信の切断又は一部の装置の異常に伴う設備の制御異常である。

第３に、制御部２３０は、２以上の第１エラーのうち、１つの第１エラーを除いた残りの第１エラーが復旧しても第２エラーが復旧していない場合に、１つの第１エラーと対応する第１スレッド及び第２エラーと対応する第２スレッドを統合してもよい。さらに時間的な要素が考慮されてもよい。具体的には、制御部２３０は、残りの第１エラーが復旧してから所定期間が経過しても、第２エラーが復旧していない場合に、１つの第１エラーと対応する第１スレッド及び第２エラーと対応する第２スレッドを統合してもよい。例えば、図１０に示すように、図９に示す状態からエラーＡ２が復旧したケースについて考える。このようなケースにおいては、エラーＡ１と対応する第１スレッド及びエラーＢと対応する第２スレッドが統合される。

（設備管理方法）
以下において、変更例１に係る設備管理方法について説明する。図１１は、所定周期（例えば、５分）毎に繰り返されるフローである。所定周期は、例えば、上述した第６時間よりも長い周期であってもよい。

図１１に示すように、ステップＳ３１において、設備管理装置２００は、上述した第６条件を満たすスレッドが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ３４の処理が行われ、判定結果がＮＯである場合には、ステップＳ３２の処理が行われる。

ステップＳ３２において、設備管理装置２００は、上述した第５条件を満たすスレッドが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ３５の処理が行われ、判定結果がＮＯである場合には、ステップＳ３３の処理が行われる。

ステップＳ３３において、設備管理装置２００は、上述した第４条件を満たすスレッドが２以上であるか否かを判定する。判定結果がＹＥＳである場合には、ステップＳ３６の処理が行われ、判定結果がＮＯである場合には、一連の処理が終了する。

ステップＳ３４において、設備管理装置２００は、第６条件を満たす２以上のスレッドを統合する。

ステップＳ３５において、設備管理装置２００は、第５条件を満たす２以上のスレッドを統合する。

ステップＳ３６において、設備管理装置２００は、第４条件を満たす２以上のスレッドを統合する。

図１１においては、所定条件として、第４条件、第５条件及び第６条件が用いられるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。所定条件は、時間的な要素を含まなくてもよい。さらに、図８〜図１０に示したように、第２エラーが生じる原因と考えられる第１エラーが２以上であるか否かに応じて、２以上のスレッドを統合するか否かが判定されてもよい。

（作用及び効果）
変更例１では、設備管理装置２００は、２以上のスレッドが所定条件を満たしている場合に、２以上のスレッドを統合する。このような構成によれば、エラー毎にスレッドが管理されるケースと比べて、スレッドを確認するユーザの作業負荷を軽減することができる。

変更例１では、設備管理装置２００は、２以上のスレッドが所定条件を満たしていない場合に、２以上のスレッドを統合しない。このような構成によれば、１つのスレッドに対する２以上のエラーの統合を無制限に行わないため、エラーの発生の見逃し及びエラーに対する処理の漏れを低減することができる。

［変更例２］
以下において、実施形態の変更例２について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例２は、上述した実施形態及び変更例１の少なくともいずれか１つと組み合わせることができる。

変更例２では、設備管理装置２００の制御部２３０は、エラーの内容に応じてスレッドの優先度を管理する。例えば、制御部２３０は、施設３００に与える影響が相対的に小さい内容を含むエラーと対応するスレッドの優先度として低優先度で管理し、施設３００に与える影響が相対的に大きい内容を含むエラーと対応するスレッドの優先度として高優先度で管理する。制御部２３０は、スレッドの優先度に応じて、スレッドの一覧における表示態様を変更してもよい。例えば、制御部２３０は、高優先度のスレッドを第１態様で表示し、低優先度のスレッドを第１態様とは異なる第２態様で表示してもよい。第１態様は、第２態様よりも目立つ態様であってもよい。第１態様は、例えば、太字、赤字マーカなどによって文字列が強調された態様である。

このような前提下において、制御部２３０は、メンテナンス期間外で所定エラーが生じた場合に、スレッドの優先度として第１優先度を管理する。一方で、制御部２３０は、メンテナンス期間内に所定エラーが生じた場合に、スレッドの優先度として第１優先度よりも低い第２優先度を管理する。すなわち、所定エラーがメンテナンス期間内に生じたか否かに応じて、所定エラーと対応するスレッドの優先度が変更される。

ここで、メンテナンス期間は、実施形態で説明したように、メンテナンス情報ＤＢ２１２に記憶される。所定エラーは、施設３００から送信されるアラートによって設備管理装置２００に通知されるエラーであればよい。

制御部２３０は、メンテナンス期間が終わっても所定エラーが復旧しない場合に、第２優先度を第１優先度に戻してもよい。言い換えると、制御部２３０は、所定エラーの原因がメンテナンスではない場合に、第２優先度を第１優先度に戻してもよい。

制御部２３０は、所定エラーに対応するスレッドが第１優先度で管理されている場合に、エラー通知を第１方法で扱うとともに、所定エラーに対応するスレッドが第２優先度で管理されている場合に、エラー通知を第１方法とは異なる第２方法で扱ってもよい。

第１方法は、例えば、メンテナンス期間とは関係なく、所定エラーの発生に応じてエラー通知を送信する方法であってもよい。第２方法は、少なくともメンテナンス期間内においてエラー通知を行わない方法であってもよい。さらに、第２方法は、メンテナンス期間後においてエラー通知を行う方法であってもよい。このような第２方法において、メンテナンス期間内に生じた２以上の所定エラーは、１つのエラー通知に統合されてもよい。実施形態と同様に、メンテナンス期間内に生じた２以上の所定エラーが所定条件を満たす場合に、２以上の所定エラーが１つのエラー通知に統合されてもよい。

第１方法は、第１態様でエラー通知を行う方法であってもよい。第２方法は、第１態様とは異なる第２態様でエラー通知を行う方法であってもよい。第１態様は、第２態様よりも目立つ態様であってもよい。第１態様は、例えば、太字、赤字マーカなどによって文字列が強調された態様である。

（設備管理方法）
以下において、変更例２に係る設備管理方法について説明する。図１２は、施設３００からアラートを受信した際に実行されるフローである。

図１２に示すように、ステップＳ４１において、設備管理装置２００は、所定エラーがメンテナンス期間外に生じたか否かを判定する。判定結果がＹＥＳである場合に、ステップＳ４２の処理が行われる。判定結果がＮＯである場合には、ステップＳ４４の処理が行われる。

ステップＳ４２において、設備管理装置２００は、所定エラーと対応するスレッドを第１優先度で管理する。設備管理装置２００は、スレッドの一覧において、所定エラーと対応するスレッドを第１態様で表示してもよい。

ステップＳ４３において、設備管理装置２００は、エラー通知を第１方法で扱う。第１方法の詳細は、上述した通りである。

ステップＳ４４において、設備管理装置２００は、所定エラーと対応するスレッドを第２優先度で管理する。設備管理装置２００は、スレッドの一覧において、所定エラーと対応するスレッドを第２態様で表示してもよい。ステップＳ４４の第２態様は、ステップＳ４２の第１態様よりも目立たない態様である。

ステップＳ４５において、設備管理装置２００は、エラー通知を第２方法で扱う。第２方法の詳細は、上述した通りである。

（作用及び効果）
変更例２では、設備管理装置２００は、メンテナンス期間外で所定エラーが生じた場合に、スレッドの優先度として第１優先度を管理する。一方で、設備管理装置２００は、メンテナンス期間内に所定エラーが生じた場合に、スレッドの優先度として第１優先度よりも低い第２優先度を管理する。このような構成によれば、メンテナンス期間内において所定エラーが頻発する可能性について着目し、このような所定エラーと対応するスレッドの優先度を下げることによって、スレッドを確認するユーザの作業負荷を軽減することができる。

［変更例３］
以下において、実施形態の変更例３について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例３は、上述した実施形態、変更例１及び変更例２の少なくともいずれか１つと組み合わせることができる。

変更例３では、設備管理装置２００の制御部２３０は、図１３に示すように、エラーの階層構造を特定する。具体的には、エラーＡが原因でエラーＢ１及びエラーＢ２が生じ、エラーＢ１が原因でエラーＣ１及びエラーＣ２が生じ、エラーＢ２が原因でエラーＣ３及びエラーＣ４が生じる。例えば、エラーＡは、施設３００と設備管理装置２００との間の通信を中継するネットワークサーバの通信異常である。エラーＢ１は、施設３００Ａに設けられるゲートウェイの異常であり、エラーＢ２は、施設３００Ｂに設けられるゲートウェイの通信異常である。エラーＣ１及びエラーＣ２は、施設３００Ａに設けられる設備の制御異常であり、エラーＣ３及びエラーＣ４は、施設３００Ｂに設けられる設備の制御異常である。

このようなケースにおいて、制御部２３０は、実施形態と同様に、エラーＡ、エラーＢ１〜Ｂ２及びエラーＣ１〜Ｃ４を１つのエラー通知に統合してもよい。ここで、１つのエラー通知は、エラーＢ１〜Ｂ２及びエラーＣ１〜Ｃ４の発生を示す情報を含まずに、エラーＡの発生を示す情報を含んでもよい。

さらに、制御部２３０は、変更例１と同様に、エラーＡ、エラーＢ１〜Ｂ２及びエラーＣ１〜Ｃ４と対応するスレッドを統合してもよい。統合後のスレッドは、エラーＢ１〜Ｂ２及びエラーＣ１〜Ｃ４についてアラート及び処理ステータスを含まずに、エラーＡについてアラート及び処理ステータスを含んでもよい。

このように、設備管理装置２００は、２以上のエラーの階層構造を特定し、階層構造を有するエラーを統合することによって、エラー通知又はスレッドの数を減少することができる。階層構造の特定は、過去に発生したエラーの学習によって行われてもよい。

［変更例４］
以下において、実施形態の変更例４について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例４は、上述した実施形態、変更例１、変更例２及び変更例３の少なくともいずれか１つと組み合わせることができる。

変更例４において、設備管理装置２００の制御部２３０は、変更例１と同様に、所定条件を満たす２以上のスレッドを統合する。所定条件は、エラーに対する処理を完了する前において、同様のエラーが再発することである。

例えば、スレッドの一覧は、図１４〜図１７に示すように、「管理ＩＤ」、「詳細」、「状況」、「経過」、「施設」、「設備種別」、「対象設備」、「原因」、「稼働状況」、「継続状況」などの項目を含む。

「管理ＩＤ」は、スレッドを識別する識別子である。「詳細」は、スレッドの詳細を表示するためのアイコンである。「状況」は、上述した処理ステータスである。「経過」は、エラーが発生してから経過した時間である。「施設」は、エラーを生じた設備が設けられた施設の名称又は識別子である。「設備種別」は、エラーを生じた設備の種別である。「対象設備」は、エラーを生じた設備の名称又は識別子である。「原因」は、エラーの内容を示すコードである。「稼働状況」は、エラーを生じていない状態の稼働率が１００％である前提においてエラーを生じた設備の稼働率である。「継続状況」は、エラーの継続状況であり、エラーの再発回数を示す「再発カウント」を含んでもよい。

図１４に示すように、管理ＩＤがＡ１５０００００４であるスレッドは、エラーに対する処理を手配しておらず、エラーが３回に亘って再発していることを意味している。さらに、このスレッドは、エラーが継続していることを意味している。

図１５に示すように、管理ＩＤがＡ１５０００００５であるスレッドは、エラーに対する処理を手配しているが、エラーが２回に亘って再発していることを意味している。さらに、このスレッドは、自動復旧によってエラーが復旧していることを意味している。自動復旧は、設備の再起動によって設備が自動的に復旧を試みる処理である。

図１６に示すように、管理ＩＤがＡ１５０００００６であるスレッドは、エラーに対する処理を手配していることを意味している。このスレッドは、設備のエラーが暫定対応によってエラーが復旧していることを意味している。暫定対応は、依然としてメンテナンスを必要とする応急的な処理である。

図１７に示すように、管理ＩＤがＡ１５０００００６であるスレッドは、エラーに対する処理を手配していることを意味している。このスレッドは、設備のエラーが暫定対応によって復旧した後にエラーが再発したことを意味している。

このようなスレッドの管理が行われるケースにおいて、制御部２３０は、自動復旧又は暫定対応によってエラーが復旧した後においてエラーが再発した場合であっても、再発エラーと対応する新たなスレッドを生成することなく、再発エラーを既存のスレッドに統合する。さらに、制御部２３０は、再発エラーを既存のスレッドに統合する場合に、既存のスレッドにおいて再発回数をカウントする。

一方で、制御部２３０は、自動復旧又は暫定対応ではなくメンテナンスによってエラーが復旧した後においてエラーが再発した場合には、再発エラーと対応する新たなスレッドを生成してもよい。さらに、制御部２３０は、再発エラーと対応する新たなスレッドにおいて再発回数をカウントしてもよい。

［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。

実施形態では、管理部２１０を構成する各種データベース（設備情報ＤＢ２１１、メンテナンス情報ＤＢ２１２及びスレッド情報ＤＢ２１３）が設備管理装置２００に設けられるが、実施形態はこれに限定されるものではない。例えば、設備情報ＤＢ２１１、メンテナンス情報ＤＢ２１２及びスレッド情報ＤＢ２１３の少なくとも１以上のデータベースは、ネットワーク１２０を介して設備管理装置２００と接続されるサーバに設けられてもよい。

なお、日本国特許出願第２０１７−０６４８９８号（２０１７年３月２９日出願）の全内容が、参照により、本願に組み込まれている。

Claims (27)

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. 少なくとも設備管理装置を有する設備管理システムであって、
    前記設備管理装置は、
    設備のエラーの内容を含むアラートをデータベースに登録する制御部を備え、
    前記制御部は、
    前記エラーに対する処理を含む処理ステータスを前記データベースに登録し、
    前記アラートと前記処理ステータスとを１対１の関係で管理するためのスレッドを管理し、
    ２以上のスレッドが所定条件を満たしていない場合に、前記２以上のスレッドを統合せずに、前記２以上のスレッドが前記所定条件を満たしている場合に、前記２以上のスレッドを統合する、設備管理システム。

Images