イベント発生通知装置、イベント発生通知方法、イベント発生通知プログラム
【課題】 本発明の目的は、センサの検出値に応じて、通知の送信先を決定するイベント通知装置を提供することにある。
【解決手段】 本発明のイベント発生通知装置は、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段とを含む。
【解決手段】 本発明のイベント発生通知装置は、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センサの検出値に基づきイベントの発生を通知するイベント発生通知装置に関し、特に、センサの検出値に応じた通知先にイベントの発生を通知するイベント発生通知装置に関する。
【背景技術】
【０００２】
特許文献１には、センサが所定の状態を検知したことを検出した場合、通知先に通知を行うセンサ監視装置が記載されている。特許文献１のセンサ監視装置は、センサを監視するセンサ監視部と、通知部と、通知確認部と、制御部とを含み、次のように動作する。
【０００３】
センサが所定の状態を検知したことをセンサ監視部が検出した場合、通知部は第１の通知先にその旨の通知を送信する。通知確認部は、通知部が送信した通知を第１の通知先が認識したことを確認する。通知部が送信した通知を第１の通知先が認識したことを、通知確認部が確認できなかった場合、制御部は、第２の通知先を決定し、決定した第２の通知先に対する通知の送信を通知部に行わせる。
【０００４】
特許文献１のセンサ監視装置は、通知先の状態に応じて、複数の通知先から、通知を送信する通知先を選択する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】再表２００４／００８４０９
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載のセンサ監視装置は、センサが検知した状態とは関係なく、通知を送信する通知先を決める。従って、特許文献１に記載のセンサ監視装置には、センサの検出値に応じて、通知の送信先を決定することはできないという問題があった。
【０００７】
本発明の目的は、センサの検出値に応じて、通知の送信先を決定するイベント通知装置を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のイベント発生通知装置は、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段とを含む。
【０００９】
本発明のイベント発生通知方法は、センサが検出した検出値を受信し、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出し、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定し、前記障害イベントの種別に応じて前記通知の送信先を決定する。
【００１０】
本発明のイベント発生通知プログラムは、コンピュータを、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段として動作させる。
【発明の効果】
【００１１】
本発明には、発生した事象に応じた適切な送信先に、通知を送信できるという効果がある。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態のイベント発生通知装置１の構成を表すブロック図である。
【図２】第１の実施形態のイベント発生通知装置１の動作を表すフローチャートである。
【図３】第２、第３の実施形態のイベント発生通知装置１Ａの構成を表すブロック図である。
【図４】第２の実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【図５】第３の実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【発明を実施するための形態】
【００１３】
以下で説明する本発明の各実施形態は、ハードウェア、又は、コンピュータとコンピュータを制御するためのソフトウェア、又は、これらの組み合わせによって実現することができる。
【００１４】
（第１の実施形態）
まず、本発明の第１の実施形態について図面を参照して詳細に説明する。
【００１５】
図１は本実施形態に係るイベント発生通知装置の構成を表すブロック図である。
【００１６】
図１を参照すると、イベント発生通知装置１は、検出値入力部１１と、通知先決定部１２を含む。イベント発生通知装置１は、センサ２の監視の対象からセンサ２が検出した検出値を受信することが可能である。
【００１７】
検出値入力部１１は、センサ２が検出した検出値を受信する。
【００１８】
通知先決定部１２は、検出値入力部１１が受信した検出値に応じて、複数の送信先装置４（図１の例では、送信先装置４１から送信先装置４ＭまでのＭ個）の中の一つ以上の送信先装置を、通知の送信先に決定する。以下、複数の送信先装置のうち、通知先決定部１２が決定した通知の送信先である送信先装置を、送信先装置Ｄと表記する。通知先決定部１２が決定した通知の送信先である送信先装置Ｄに対して、通知送信装置３が通知を送信する。
【００１９】
次に、本実施形態のイベント発生通知装置１の動作について、図面を参照して詳細に説明する。
【００２０】
図２は、本実施形態のイベント発生通知装置１の動作を表すフローチャートである。
【００２１】
図２を参照すると、まず、検出値入力部１１が、センサ２が検出した検出値を受信する（ステップＳ１１）。
【００２２】
センサ２は、例えば監視の対象を測定し、温度、電圧、湿度、風量、回転数等の物理量から検出値を検出するセンサである。以下の説明では、一つのセンサが一つの検出値を検出するとして説明するが、一つのセンサが検出する検出値は１種類であっても複数種類であってもよい。監視の対象は、例えば、ハードディスク装置やファンなどの部品や、コンピュータ装置や冷却装置、エレベータ等の装置や、データセンターや発電所などの施設等である。また、センサ２は、例えばハードディスク装置を監視し、書き込みエラーや読み込みエラー及びそれらの確率や不良セクタの増加数等の、ハードディスク装置の状態を検出する機構であってもよい。センサ２は、監視の対象が故障する可能性の程度を推定し、検出結果にしてもよい。センサ２は、検出した結果を検出値として出力する。検出値は、不連続値、連続値のいずれであってもよい。なお、センサ２は１つであっても、複数であってもよい。
【００２３】
次に、通知先決定部１２が、検出値入力部１１が受信した検出値に基づき、通知の送信先（送信先装置Ｄ）を決定する（ステップＳ１２）。
【００２４】
ステップＳ１２において、通知先決定部１２は、検出値に対する所定の条件に基づき、受信した検出値から送信先装置Ｄを決定する。通知先決定部１２は、例えば、検出値が含まれる値の範囲に応じて送信先装置Ｄを決定すればよい。また、通知先決定部１２は、例えば、検出値が所定の値であるセンサの個数に応じて送信先装置Ｄを決定してもよい。あるいは、通知先決定部１２は、例えば、一定時間継続して、所定の検出値を検出し続けた場合や、一定時間内に所定の回数以上所定の検出値を検出した場合に、これらの状況に応じて送信先装置Ｄを決定してもよい。通知先決定部１２が検出値に応じて通知の送信先として決定する送信先装置Ｄは、一つであっても複数であってもよい。
【００２５】
通知先決定部１２は、例えば、センサを特定する情報（センサＩＤ；ｉｄｅｎｔｉｆｉｅｒ）と、検出値に対する条件と、通知の送信先を特定する情報と、通知の送信方法との組（通知ルール）を、複数含むテーブル（通知テーブル）を参照して、通知先を決定すればよい。検出値に対する条件は、例えば値の範囲である。通知先決定部１２は、受信した検出値が、その検出値を検出したセンサのセンサＩＤに対応する「検出値に対する条件」で表される値の範囲に含まれる場合、対応する「通知の送信先を特定する情報」で特定される送信先装置を、通知の送信先に決定することができる。通知先決定部１２は、さらに、決定した通知の送信先に対応する「通知の送信方法」を通知を送信する方法に決めることもできる。通知テーブルは、通知先決定部１２が参照可能な、例えば記憶部等に格納されていればよい。また、通知先決定部１２は、複数の通知ルールを内部に保持し、自らが保持する通知ルールに基づき通知の送信先を決定してもよい。このように、各通知ルールは、各通知ルールが含む情報や条件の対応を得ることができるものであれば、必ずしもテーブルの形になっていなくてもよい。
【００２６】
通知の内容は、例えば、単に警告を表す情報であっても、検出値そのものであっても、検出値によって判断される監視の対象の状況を表す情報であってもよい。通知の媒体は、情報を伝達できる媒体であれば、テキスト、画像、音声、光など、どのような媒体であってもよい。通知の方法の例として、電子メールの送信、ファクシミリの送信、電話、端末装置の画面への表示、スピーカ等による音声の発生、例えば回転灯等の発光装置の点灯等による光の発生等が挙げられる。通知の方法は、例えば前述の方法を、複数組み合わせたものであってもよい。
【００２７】
通知の送信先となる送信先装置は、例えば、携帯端末やコンピュータ装置、サーバや、スピーカや回転灯、あるいは電話やその他の装置である。これらの通知の送信先を特定する情報は、例えば、個人や何人かのグループ等のメールアドレス、コンピュータ装置やサーバ等のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、電話番号やファックス番号、スピーカや回転灯等が存在する場所を特定する情報等である。
【００２８】
通知送信装置３は、例えば通知テーブルを参照して、通知先決定部１２が決定した通知先の装置に応じた送信方法を決定する（ステップＳ１３）。
【００２９】
通知送信装置３は、例えば、センサＩＤ及び検出値を受信し、受信したセンサＩＤ及び検出値をもとに、前述の通知テーブルを参照して、決定された通知の送信先に対応する「通知の送信方法」を、通知を送信する方法に決定すればよい。通知先送信装置３は、通知先決定部１２から、通知の送信先と共に通知の送信方法を受け取ってもよい。
【００３０】
通知送信装置３は、通知先決定部１２が決定した通知の送信先の装置に対して、決定した送信方法により通知を送信する（ステップＳ１４）。
【００３１】
通知送信装置３は、通知先決定部１２が決定した送信先装置Ｄである、例えば、メールアドレス、ファックス番号や電話番号、配線等に対し、通知を送信する。通知送信装置３は、イベント発生通知装置１とは別の装置であっても、イベント発生通知装置１と同じ装置であってもよい。
【００３２】
以上で説明した本実施形態には、発生した事象に応じた適切な送信先に、通知を送信できるという効果がある。
【００３３】
その理由は、通知先決定部１２がセンサの検出値に応じて通知の送信先を決定することで、センサの検出値に応じた送信先のみに通知が送信されるからである。このことにより、検出値に基づき予め設定した必要な通知以外の、不必要な通知が送信先に送られなくなり、送信先の負担が軽減される。
【００３４】
（第２の実施形態）
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。
【００３５】
図３は、本実施形態のイベント通知装置１Ａの構成を表すブロック図である。
【００３６】
図３を参照すると、イベント通知装置１Ａは、検出値入力部１１と、通知先決定部１２と、センサイベント検出部１３と、障害イベント判定部１４と、通知部１５とを含む。イベント通知装置１Ａは、通知ルール記憶部１６を含んでいてもよい。
【００３７】
検出値入力部１１は、センサ２１〜センサ２Ｎ（Ｎは２以上の整数）から、それぞれの検出値を受信する。検出値入力部１１は、第１の実施形態の検出値入力部１１と同じであるので、説明を省略する。センサ２１〜センサ２Ｎは、単一の種類のセンサであっても、複数の種類のセンサであってもよい。センサ２１〜センサ２Ｎの各センサは、前述のセンサ２と同じであるので、詳細な説明を省略する。
【００３８】
センサイベント検出部１３は、センサ毎に定められた条件により、検出値入力部１１が受信した検出値からセンサ毎のイベントを検出する。イベントは、例えば、検出値が、予め定められた条件で表される特定の状態にあることである。センサイベント検出部１３は、検出値が取りうる全ての値から何らかのイベントを検出してよい。また、検出値が取りうる値の範囲に、センサイベント検出部１３がイベントを検出しない検出値の範囲が存在してもよい。
【００３９】
センサイベント検出部１３は、例えば、センサＩＤと検出値に対する条件との組を複数含むテーブル（イベントテーブル）を参照して、検出値からセンサ毎のイベントを検出すればよい。センサイベント検出部１３は、イベントの検出の際、例えば後述の通知ルール記憶部１６が記憶するイベントテーブルを参照してもよく、自らの内部に保持するイベントテーブルを参照してもよい。また、センサイベント検出部１３は、イベントテーブルを参照するのではなく、内部に組み込まれた、検出値とイベントを対応付けるロジックにより、イベントを検出してもよい。
【００４０】
障害イベント判定部１４は、センサイベント検出部１３が検出したイベントの組み合わせから、障害イベントが発生したか否かを判定する。障害イベント判定部１４は、障害イベントが発生したと判定した場合、発生した障害イベントの種類を判定する。障害イベント判定部１４は、センサイベント検出部１３が検出したイベントの組み合わせが、予め定義されたいずれかの条件（通常、監視の対象に異常が生じたとみなされる状態）に当てはまった場合、障害イベントが発生したと判定する。イベントの条件は、例えば、所定のイベントの数や、所定のイベントの割合や、それらに対する閾値等の条件や、イベントの所定の組み合わせ等である。イベントの条件は、検出したイベントの組み合わせが当てはまるか否かを判断する基準となるものであればよい。
【００４１】
障害イベント判定部１４は、例えば、障害イベントとして検出するイベントの条件と、対応する障害イベントの種類の組を、複数含むテーブル（障害イベントテーブル）を参照して、障害イベントの発生を判定すればよい。障害イベント判定部１４は、例えば、検出されたイベントの組み合わせが、障害イベントテーブルのいずれかのイベントの条件に当てはまる場合、障害イベントが発生を判定すればよい。さらに、障害イベント判定部１４は、例えば、障害イベントテーブルにおいて、検出されたイベントの組み合わせが当てはまるイベントの条件に対応する障害イベントの種類を、発生した障害イベントの種類と判定すればよい。
【００４２】
障害イベント判定部１４は、障害イベントの発生及び種類の判定の際、例えば後述の通知ルール記憶部１６が記憶する障害イベントテーブルを参照してもよく、自らが内部に含む障害イベントテーブルを参照してもよい。また、障害イベント判定部１４は、障害イベントテーブルを参照するのではなく、内部に組み込まれた、イベントの状態と障害イベントの種類を対応付けるロジックにより、障害イベントの発生及び発生した障害イベントの種類を判定してもよい。
【００４３】
通知先決定部１２は、障害イベント判定部１４が判定した障害イベントの種類に応じて、複数の送信先装置（図３の例では、送信先装置４１から送信先装置４ＭまでのＭ個、Ｍは２以上の整数）の中の一つ以上の送信先装置を、通知の送信先である送信先装置Ｄに決定する。本実施形態の通知先判定部１２は、第１の実施形態の通知先判定部１２と比較すると、検出値ではなく障害イベントの種類に応じて、通知の送信先である送信先装置Ｄを決定する点が異なる。すなわち、本実施形態における通知ルールは、第１の実施形態における通知ルールとは異なり、センサＩＤ及び検出値に対する条件の代わりに、障害イベントの種類を含む。
【００４４】
通知先決定部１２は、第１の実施形態の通知先決定部１２と同様に、例えば通知テーブルを参照して、通知の送信先を決定する。ただし、本実施形態における通知テーブルは、障害イベントの種類と、通知の送信先を特定する情報と、通知の送信方法の組である通知ルールを複数含む点が、第１の実施形態における通知テーブルと異なる。なお、第１の実施形態と同様に、通知ルールは必ずしもテーブルの形になっていなくてもよい。
【００４５】
通知部１５は、例えば通知テーブルを参照して、通知先決定部１２が決定した送信先装置Ｄに応じた通知の送信方法を決定する。通知部１５は、送信先装置Ｄに対して、決定した送信方法により通知を送信する。
【００４６】
送信先装置４１〜送信先装置４Ｍは、第１の実施形態における送信先装置４１〜送信先装置４Ｍと同じなので、説明を省略する。
【００４７】
通知ルール記憶部１６は、イベントテーブルや、障害イベントテーブルや、通知テーブルを記憶してもよい。この場合、センサイベント検出部１３は、センサ毎のイベントを検出する際、通知ルール記憶部１６が記憶するイベントテーブルを参照する。また、障害イベント判定部１４は、障害イベントの発生及び種類を判定する際、通知ルール記憶部１６が記憶する障害イベントテーブルを参照する。また、通知先決定部１２は、通知の送信先である送信先装置Ｄを決定する際、通知ルール記憶部１６が記憶する通知テーブルを参照する。
【００４８】
イベント通知装置１Ａには、ユーザ端末５が接続されていてもよい。ユーザは、ユーザ端末５を介し、通知ルール記憶部１６が記憶する各テーブルの内容の、追加や削除、変更を行うことができる。
【００４９】
次に、本実施形態のイベント通知装置１Ａの動作について、図面を参照して詳細に説明する。
【００５０】
図４は、本実施形態のイベント通知装置１Ａの動作を表すフローチャートである。
【００５１】
図４を参照すると、まず、検出値入力部１１が、各センサが検出した検出値を受信する（ステップＳ２１）。検出値の例として、例えば、温度、気圧、湿度、ファンやハードディスク装置などの回転数、音の大きさ、電圧、ファンなどの風量等の流体の流量、振動等が挙げられる。検出値は、例えば、ハードディスク装置の書き込みエラーの発生率など、監視対象に何らかの状況が発生している確率でもよい。また、検出値は、「異常」や「正常」のような、状態を表す値であってもよい。
【００５２】
次に、センサイベント検出部１３が、センサ毎に定められたイベントを検出する条件を含む、例えばイベントテーブルを参照して、検出値入力部１１が受信した各検出値からセンサ毎のイベントを検出する（ステップＳ２２）。
【００５３】
センサイベント検出部１３は、受信した全ての検出値に対してイベントを検出するので、センサイベント検出部１３が一度に検出するイベントは一つとは限らない。また、受信した全ての検出値が、センサ毎に定められた条件に当てはまらない場合、センサイベント検出部１３はイベントを検出しない。
【００５４】
また、センサイベント検出部１３が検出するイベントは、例えば「低温」や「高温」のような検出値を定性的に表すものであってもよく、検出値そのもの（例えば温度の値など）のように定量的なものであってもよい。
【００５５】
センサイベント検出部１３がいずれかのイベントを検出した場合（ステップＳ２３、Ｙ）、障害イベント判定部１４は、例えば前述の障害イベントテーブルを参照して、センサイベント検出部１３が検出したイベントが、障害イベントであるか否かを判定する（ステップＳ２４）。センサイベント検出部１３がイベントを検出しなかった場合（ステップＳ２３、Ｎ）、処理は終了する。
【００５６】
障害イベント判定部１４は、検出したイベントの組み合わせが、障害イベントテーブルに含まれる条件に合致するか否かにより、障害イベントの発生及び種類を判定する。一つのイベントが、異なる複数の条件で判定の対象になっていてもよい。一つの組み合わせに対して、障害イベントと判定するための条件が複数存在していてもよい。障害イベント判定部１４は、例えば、センサイベント検出部１３が検出したイベントの組み合わせが、障害イベントと判定する条件のいずれかに合致する場合、障害イベントが発生したと判定する。例えば、センサイベント検出部１３が検出したイベントの組み合わせがイベント１、イベント２、イベント３であり、障害イベントと判定する条件が、イベント２とイベント３の検出である時、障害イベント判定部１４は障害イベントが発生したと判定すればよい。また、障害イベントと判定する条件となるイベントの組み合わせは、一つのイベントのみを含む組み合わせであってもよく、過去に検出したイベントを含む組み合わせであってもよい。
【００５７】
また、障害イベント判定部１４は、所定の時間継続して、センサイベント検出部１３が所定のイベントが検出し続けた場合や、所定の時間内に所定の回数以上、センサイベント検出部１３が所定のイベントを検出した場合、障害イベントの発生を判定してもよい。また、イベントが検出値そのものである場合、障害イベント判定部１４は、検出値の変化量が所定の閾値を上回った場合や下回った場合に、障害イベントの発生を判定してもよい。さらに、障害イベント判定部１４は、以上で説明した障害イベントの発生を判定する条件を組み合わせて、障害イベントの発生を判定してもよい。
【００５８】
次に、障害イベント判定部１４が障害イベントと判定する条件の具体的な例を挙げる。
【００５９】
（１）同一種センサにおけるイベントの組み合わせ
以下の説明は、同じ種類のセンサによる検出値から検出したイベントの組み合わせにより、障害イベントを判定する場合の条件の具体例である。
【００６０】
最も単純な例としては、センサイベント検出部１３が、障害や故障が発生したと判断される一つのイベントを検出した場合、障害イベント判定部１４が障害イベントの発生を判定することが挙げられる。この場合、障害イベントの発生を障害イベント判定部１４が判定するための条件となるイベントの組み合わせは、１つのイベントだけを含む。このようなイベントの例として、例えばハードディスク装置の故障がある。例えば、センサがハードディスク装置の故障センサであり、センサイベント検出部１３がハードディスク装置の故障を検出した場合、障害イベント判定部１４は、障害イベントとして、例えばハードディスク装置の故障の発生を判定すればよい。
【００６１】
また、検出したイベントが、単独ではすぐに障害や故障につながるようなものではない軽微なものであっても、同種のイベントが同時に多発した場合、重大な障害につながる例がある。このような例では、例えば若干数（例えば経験に基づいて定めた、重大な障害につながる可能性があると判断される閾値より、小さい数）のイベントが検出されている場合、障害イベント判定部１４は、障害イベントの発生を判定しなくてよい。またこの場合、障害イベント判定部１４は、重大ではない障害イベントの発生を判定してもよい。一方、故障につながる可能性が高くなる数（前述の閾値以上の数）のイベントが検出されている場合、障害イベント判定部１４は、緊急の、あるいは、重大な障害イベントの発生を判定すればよい。
【００６２】
例えば、一般に冷却装置は冷却能力に余裕を持たせて設計されているので、多数のファンを含む冷却装置で、１個のファンの故障が、すぐに冷却の対象の故障や障害につながる訳ではない。しかし、このような冷却装置において多数のファンが一度に故障した場合、冷却装置の冷却能力が温度上昇を防ぐのに必要な能力を下回り、冷却の対象の重大な障害や故障につながる可能性がある。
【００６３】
この例では、センサはファンの故障を検出するものであればよい。イベント検出部１３は、個別のファンの故障を、それぞれイベントとして検出すればよい。障害イベント検出部１４は、例えば必要な冷却能力に対応するファンの個数を閾値として、ファンの故障が発生した場合、故障したファンの個数が閾値を上回るか否かで、別の障害イベントの発生を判定すればよい。
【００６４】
例えば必要な冷却能力に対応する所定の個数未満の個数のファンの故障をイベントとして検出した場合、障害イベント判定部１４は、障害イベントとして、例えばファンの故障の発生を判定すればよい。また、例えば前述の所定の個数以上の個数のファンの故障をイベントとして検出した場合、障害イベント判定部１４は、障害イベントとして、前述のファンの故障の発生より重大な障害である、例えば緊急にファンの交換が必要な状態の発生を判定すればよい。
【００６５】
必要な冷却能力に対応するファンの個数は、例えば経験に基づいて予め設定されていればよい。また、図示しない入力部などを介して、管理者が必要な冷却能力に対応するファンの個数を入力してもよい。この例において、必要な冷却能力に対応するファンの個数は、ファンの総数に対する割合により算出することもできる。この場合、管理者が、図示しない入力部を介し、ファンの総数を入力すればよい。あるいは、各ファンをそれぞれ別のセンサが観測しているのであれば、例えば検出値入力部１１が、検出値を受信するセンサの個数により、ファンの総数を得ることもできる。あるいは、障害イベント検出部１４は、ファンの総数に対する故障したファンの個数の割合が閾値を上回るか否かにより、障害イベントの発生及び種類を判定してもよい。
【００６６】
また、同種の軽微なイベントの同時多発が重大な障害につながる例として、ＲＡＩＤ（Redundant Arrays of Independent Disks）を構成する複数のハードディスク装置の、エラー率（書き込みエラー率又は読み出しエラー率）に関するイベントが考えられる。
【００６７】
例えばＲＡＩＤ５やＲＡＩＤ６等のように、冗長構成のディスクアレイ装置には、ディスクアレイ装置を構成する複数のハードディスク装置のうち、所定の個数以下が故障しても、記録されているデータの復旧が可能なものがある。例えばＲＡＩＤ５の構成のディスクアレイ装置であれば１台のハードディスク装置が故障しても、ＲＡＩＤ６の構成のディスクアレイ装置であれば２台のハードディスク装置が故障しても、ディスクアレイ装置に記憶されているデータの復旧は可能である。しかし、所定の個数より多数のハードディスク装置の故障によって、ディスクアレイ装置に記録されているデータは失われる。
【００６８】
また、一般に、ハードディスク装置のエラー率が増大した場合、そのハードディスク装置は故障する可能性がある。そこで、センサイベント検出部１３は、所定値を超えるたエラー率の検出をイベントとして検出してもよい。しかし、エラー率の一時的な増大が故障につながるとは限らない。また、前述のディスクアレイ装置を構成するハードディスク装置の１台が故障しても、データの復旧は可能である。従って、ディスクアレイ装置の１台のハードディスク装置にのエラー率が、所定値（故障の可能性があると考えられるエラー率）を超えることは軽微なイベントと考えてもよい。従って、この場合、障害イベント判定部１４は、障害イベントの発生を判定しなくてよい。
【００６９】
しかし、エラー率が所定値を超えたハードディスク装置の全てに、故障する可能性がある。従って、前述のディスクアレイ装置のデータの復旧が可能な、ハードディスク装置の最大の故障台数より、多い台数のハードディスク装置のエラー率が、前述の所定値を超えた場合、重大な障害につながる可能性がある。よって、この場合、障害イベント判定部１４は、障害イベントとして、例えばハードディスクの故障について注意する必要がある状態になったことを判定すればよい。
【００７０】
なお、このディスクアレイ装置において実際にハードディスク装置の故障が発生した場合、障害イベント判定部１４は、以下で述べるように障害イベントの発生を判定すればよい。故障したハードディスク装置の台数が、データの復旧が可能なハードディスク装置の最大の故障台数より少ない場合、障害イベント判定部１４は、障害イベントとして、メンテナンスが必要な状態になったことを判定すればよい。故障したハードディスク装置の台数が、データの復旧が可能なハードディスク装置の最大の故障台数と等しい場合、障害イベント判定部１４は、障害イベントとして、緊急にメンテナンスが必要な状態になったことを判定すればよい。
【００７１】
また、同一環境にある複数の監視対象をそれぞれ計測する複数のセンサの検出値から検出されるイベントのうち、少数のイベントが他の多数のイベントと異なるイベントである場合、障害イベント判定部１４が障害イベントの発生を判定することが考えられる。
【００７２】
このようなイベントの例として、ディスクアレイ装置を構成する複数のハードディスク装置の温度から検出するイベントがある。なお、この例におけるディスクアレイ装置は、特定のハードディスク装置にアクセスが集中しないディスクアレイ装置である。このようなディスクアレイ装置を構成する複数のハードディスク装置の温度は、おおむね均等になると考えられる。多数のハードディスク装置の中で、少数のハードディスク装置の温度が他と比較して著しく高い場合や、著しく低い場合は、他の多数のハードディスク装置と温度が異なるハードディスク装置には障害が発生している可能性がある。
【００７３】
従って、例えば、ディスクアレイ装置の各ハードディスク装置の温度から検出されるイベントが、多数の「常温」と少数の「高温」である場合、高温のディスク装置に異常が発生した可能性がある。また、例えば、ハードディスク装置の温度から検出されるイベントが、多数の「高温」と少数の「常温」である場合、常温のハードディスク装置に異常が発生した可能性がある。また、例えば、ハードディスク装置の温度から検出されるイベントが、多数の「常温」と少数の「低温」である場合、常温のハードディスク装置に異常が発生した可能性がある。従って、これらの場合のように、多数のハードディスク装置とは異なる状態の少数のハードディスク装置が存在する場合、障害イベント判定部１４は、障害イベントが発生したと判定すればよい。
【００７４】
一方、全てのイベントが「常温」であれば、障害イベント判定部１４は、障害イベントが発生したと判定しなくてよい。また、全てのイベントが「高温」である場合も、原因は故障ではなく例えばディスクアレイ装置に対してアクセスが行われたことであると考えられるので、障害イベント判定部１４は、障害イベントが発生したと判定しなくてもよい。すなわち、全てのイベントが均等である場合、そのイベントが障害や故障に直接つながる状態を意味しないのであれば、障害イベントが発生したと判定しなくてもよい。なお、上述の「常温」は、温度の測定対象のハードディスク装置が、特別な状況ではない場合の温度、例えば負荷が高い時間が少ないハードディスク装置であれば負荷が高くない場合温度がおおむね含まれるような、所定の範囲の温度を表す。
【００７５】
この例において、イベント検出部１３は各ハードディスク装置の温度の測定値そのものをイベントとして検出してもよい。この場合、障害イベント判定部１４は、いずれかのハードディスク装置（ハードディスク装置Ａ）の温度の測定値と、他のハードディスク装置の温度の測定値の代表値の差の大きさが、所定の閾値を超える場合、ハードディスク装置Ａにおける障害の発生を判定してもよい。なお、閾値は、例えば経験に基づいて定めた値であればよい。また、代表値は、例えば、平均値、中央値、最頻値などである。温度の測定値は、連続値ではなく、所定の間隔の離散値であってもよい。
【００７６】
また、イベントの組み合わせは、必ずしも同時に検出したイベントのみにより構成される必要はない。イベントの組み合わせは、検出の時期が異なるイベントを含んでいてもよい。そのような例について、以下で説明する。
【００７７】
例えば、ハードディスク装置の故障がイベントとして検出され、その故障したハードディスク装置の交換後、再びそのハードディスク装置の故障がイベントとされた場合、２回の故障の間の時間が十分長ければ、２回の故障は自然な故障であると考えられる。この場合、障害イベント判定部１４は、ハードディスク装置の故障の度に、障害イベントとしてハードディスク装置の故障の発生を判定すればよい。しかし、２回の故障の間の時間が短い場合、２回の故障は、例えばハードディスク装置の設置場所に問題があることが原因の故障等、自然ではない故障である可能性があると考えられる。
【００７８】
この場合、障害イベント判定部１４は、ハードディスク装置の故障の発生後、同一の場所で所定期間内に再びハードディスク装置の故障の発生した場合、障害イベントとして、ハードディスク装置の故障に加え、例えば、故障の再発を判定してもよい。この場合のイベントの組み合わせは、所定の期間内に発生した、特定の場所のハードディスク装置の故障という、同一の種類のイベント２つの組み合わせにより、障害イベントの発生を判定していることになる。
【００７９】
（２）複数種センサにおける複数のイベントの組み合わせ
以下の説明は、複数の種類のセンサによる検出値から検出したイベントの組み合わせにより、障害イベントを判定する場合の条件の具体例である。
【００８０】
一般に、冷却ファンは、故障時や故障直前には、正常動作時と比較して、同一回転数では発生する音や振動が大きくなる。しかし、例えば、冷却対象の温度などにより回転数を変えることができる冷却ファンは、風量を増やすため回転数を上昇させると、通常、発生する音や振動が大きくなる。従って、音や振動の大きさの測定結果の検出値だけから、故障や故障が近いことを判定することはできない。
【００８１】
しかし、ファンの回転数や風量の測定結果と音や振動の大きさの測定結果を組み合わせることで、故障や故障が近いことを判定することが可能である。予め測定して対応付けておいた正常なファンの回転数や風量と音や振動の大きさの関係と、ファンの回転数や風量を測定した検出値と、音や振動を測定した検出値により、ファンの故障や故障が近いことを判定することが可能である。
【００８２】
ファンの回転数や風量と音や振動の大きさはおおむね比例関係にあるので、例えば回転数や風量の測定結果のイベントが「大」で、音や振動の測定結果のイベントが「大」である場合は、障害イベント判定部１４は、ファンは正常であると判断してよい。また、例えば回転数や風量の測定結果のイベントが「小」で、音や振動の測定結果のイベントが「小」である場合も、障害イベント判定部１４は、ファンは正常であると判断してよい。一方、例えば回転数や風量の測定結果のイベントが「大」で、音や振動の測定結果のイベントが「小」である場合は、障害イベント判定部１４は、ファンは故障又は故障直前の状態であると判断することができる。
【００８３】
なお、イベント検出部１３は、回転数や風量、音や振動の測定結果の、それぞれに対して定められた閾値に対する大小関係に基づき、イベントが「大」であるか「小」であるかを決定すればよい。また、回転数や風量、音や振動に対する閾値は、経験に基づいて予め決定されたものであればよい。
【００８４】
また、イベント検出部１３は、回転数や風量、音や振動を測定した検出値をイベントとして検出してもよい。この場合、障害イベント判定部１４は、回転数や風量の検出値に対する音や振動の検出値の割合が、例えば経験に基づき決定した閾値を上回る場合、故障又は故障の直前の状態であると判断すればよい。なお、回転数、風量、音、振動の測定値は、それぞれ、連続値であっても離散値であってもよい。
【００８５】
また、ハードディスク装置は、故障時又は故障の直前に、正常動作時と比較して音や振動が大きい傾向がある。一方、正常なハードディスク装置であっても、アクセスの発生中は、音や振動が大きくなる。従って、音や振動の測定値のみから、ハードディスク装置が故障又は故障の直前の状態にあることを判定することは難しい。
【００８６】
しかし、検出値入力部１１が、ハードディスク装置の音や振動を測定するセンサの検出値に加え、例えばハードディスク装置にアクセスする装置から、アクセス中であるか否かを表す情報を得ることで、ハードディスク装置が故障又は故障の直前の状態にあることの判定が可能となる。例えば、ハードディスク装置にアクセスがない状態（通常時）の音や振動を予め測定しておき、ハードディスク装置の音や振動が通常時より大きい状態であるイベントが検出された時、ハードディスク装置へのアクセスのイベントが検出されれば、障害イベント判定部１４は、障害イベントの発生を判定しなければよい。一方、ハードディスク装置の音や振動が通常時より大きい状態であるイベントが検出された時、ハードディスク装置へのアクセスのイベントが検出さなければ、障害イベント判定部１４は、障害イベントの発生として、ハードディスク装置が故障又は故障の直前の状態にあることを判定すればよい。
【００８７】
（３）所定時間内のイベント検出回数、イベント検出状態の継続時間
以下の説明は、所定時間内に所定回数以上、同一のイベントが検出された場合と、所定の時間、所定のイベントが検出されている状態が継続した場合の、障害イベントの発生を判定する条件の具体例である。
【００８８】
検出したイベントが、すぐに障害や故障につながるようなものではない軽微なものであっても、イベントが検出される状態が継続すれば、障害や故障につながったり、障害や故障が疑われたりする場合がある。
【００８９】
例えば、ハードディスク装置の温度が一時的に高くなっても、すぐには故障にはつながらない。しかし、高温状態が続いた場合、ハードディスク装置が故障する確率は増大する。
【００９０】
そこで、温度センサが測定したハードディスク装置の温度が所定値以上である場合、センサイベント検出部１３は、ハードディスク装置が高温であるイベントを検出すればよい。ハードディスク装置が高温であるイベントが、所定の時間検出され続けた場合や、所定の時間内に所定の回数以上検出された場合、障害イベント判定部１４は、障害イベントとして、例えば高温による要注意状態にあることを判定すればよい。
【００９１】
また、例えば、落雷などの影響によって、電圧の瞬間的な低下が発生することがある。電圧の瞬間的な低下が発生しても、無停電電源装置を使用することで、コンピュータ装置などの継続運用が可能である。従って、電圧の瞬間的な低下の発生は、軽微なイベントと言うことができる。しかし、電圧の瞬間的な低下が所定時間内に何度も発生するような場合、例えば周辺の地域に落雷が多発しており、停電が発生することが考えられる。
【００９２】
この場合、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の瞬間的な低下を検出すればよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間内に所定回数以上電圧の瞬間的な低下を検出した場合、例えば停電発生注意の障害イベントを判定すればよい。
【００９３】
また、電圧の低下が所定時間以上継続した場合、停電が発生したと考えられる。
【００９４】
この場合、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の低下を検出すればよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間以上の電圧の低下の継続を検出した場合、例えば停電発生の障害イベントを判定すればよい。あるいは、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の低下が一定時間以上継続したことを検出してもよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間以上の電圧の低下を検出した場合、例えば停電発生の障害イベントを判定すればよい。
【００９５】
（４）（１）〜（３）に記載の条件の組み合わせ
障害イベント判定部１４は、（１）〜（３）に記載した条件の組み合わせにより、障害イベントの発生を判定してもよい。
【００９６】
例えば、上述のように、ディスクアレイ装置を構成する複数のハードディスク装置の温度から検出するイベントが、全て「高温」である場合、障害イベント判定部１４は、障害イベントが発生したと判定しなくてもよい。しかし、全てあるいは多数のイベントが「高温」である状態が長時間継続した場合、高温状態にあるハードディスク装置の寿命が短縮して故障が発生する可能性がある。また、全てのイベントが「高温」である状態が長時間継続した場合、例えば冷却装置が故障しているなど、ハードディスク装置以外に何か障害が発生していることも考えられる。
【００９７】
よって、障害イベント判定部１４は、全てあるいは多数のイベントが「高温」である状態が所定の時間以上継続した場合、障害イベントとして、例えば高温による要注意状態にあることを判定すればよい。また、全てのイベントが「高温」である状態が所定の時間以上継続した場合、障害イベント判定部１４は、障害イベントとして、例えば冷却能力が不足状態にあることを判定すればよい。
【００９８】
障害イベント判定部１４が障害イベントの発生を判定した場合（ステップＳ２５、Ｙ）、障害イベント判定部１４が判定した障害イベントの種類に基づき、通知先決定部１２が、例えば通知テーブルを参照して、通知の送信先である送信先装置Ｄを決定する（ステップＳ２６）。通知先決定部１２は、障害イベント判定部１４が判定した障害イベントの種類と、例えば予め定められた障害イベントの種類と送信先装置Ｄの対応に基づき、送信先装置Ｄを決定すればよい。通知先決定部１２が通知の送信先として決定する送信先装置Ｄは、障害イベント判定部１４が判定した障害イベントを必要に応じて解決することができる、例えば装置やシステム等の管理者や管理部門であればよい。
【００９９】
障害イベント判定部１４が判定した障害イベントの種類に対応する送信先が定まっていない場合、通知先決定部１２は、デフォルトとして定められた送信先を送信先装置Ｄと決定すればよい。
【０１００】
通知部１５は、障害イベント判定部１４が決定した送信先装置Ｄに、通知を送信する（ステップＳ２８）。
【０１０１】
以上で説明した本実施形態には、第１の実施形態と同様、通知の送信先の負担を軽減できるという効果がある。
【０１０２】
その理由は、障害イベント判定部１４が判定した障害イベントの種類に基づき、通知の通知先決定部１２が送信先を決定することで、センサの検出値に応じた送信先のみに通知が送信されるからである。上述のように、障害イベント判定部１４は、センサイベント検出部１３がセンサの検出値から検出したイベントに基づき、障害イベントの種類を判定する。このことにより、検出値に基づき予め設定した必要な通知以外の、不必要な通知が送信先に送られなくなり、送信先の負担が軽減される。
【０１０３】
本実施形態には、さらに、通知の通知先決定部１２が送信先を決定する規則を簡単化できるという効果がある。
【０１０４】
その理由は、通知の通知先決定部１２は、検出値の値そのものではなく、障害イベント判定部１４が判定した障害イベントの種類に基づき、送信先を決定するからである。
【０１０５】
（第３の実施形態）
次に、本発明の第３の実施形態について、図面を参照して詳細に説明する。
【０１０６】
本実施形態のイベント発生通知装置１Ａの構成は、図３に示す第２の実施形態のイベント発生通知装置１Ａの構成と同じである。
【０１０７】
以下では、本実施形態と、第２の実施形態との相違点を中心に説明する。
【０１０８】
本実施形態では、障害イベント判定部１４が、障害イベントの発生及び種類の判定に加え、障害イベントの種類に応じて、緊急性の度合いを表す重要度の判定を行う点が、第２の実施形態と異なる。重要度は、障害イベントの緊急性に応じて、適宜定められたものであればよい。
【０１０９】
また、通知先決定部１２が、障害イベントの種類だけでなく、重要度に応じて通知の送信先を決定する点が、第２の実施形態と異なる。
【０１１０】
さらに、通知部１５が、通知先決定部１２が決定した送信先及び障害イベント判定部１４が判定した重要度に応じて、通知の送信方法を決定し、通知先決定部１２が決定した送信先に対し、決定した送信方法で通知を送信する点が、第２の実施形態と異なる。なお、通知先決定部１２が、通知の送信先と共に通知の送信方法を決定する構成でも構わないが、本実施形態では、通知部１５が通知の送信方法を決定する構成について説明する。
【０１１１】
本実施形態の他の構成要素は、第２の実施形態と同じであるので、説明を省略する。
【０１１２】
次に、本実施形態の動作について、図面を参照して詳細に説明する。
【０１１３】
図５は、本実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【０１１４】
図５を参照すると、図５のステップＳ２１からステップＳ２５は、図４に示す第２の実施形態のステップＳ２１からステップＳ２５までの動作と同じであるので、説明を省略する。
【０１１５】
障害イベント判定部１４は、障害イベントの発生を判定した場合（ステップＳ２５、Ｙ）、例えば障害イベントテーブルを参照し、判定した障害イベントの種類に応じて、当該障害イベントの重要度を判定する（ステップＳ３０）。
【０１１６】
本実施形態の障害イベントテーブルは、第２の実施形態の障害イベントテーブルと異なり、障害イベントとして検出するイベントの条件と、対応する障害イベントの種類と、障害イベントの重要度の組を複数含む。本実施形態の障害イベントテーブルは、障害イベントの種類に対応する重要度を含む点が、第２の実施形態の障害イベントテーブルと異なる。
【０１１７】
重要度は、例えば、「情報」、「注意」、「異常」、「警告」、「緊急」等の、適宜定義された緊急性の度合いを表す情報である。また、重要度は、緊急性の度合いを表す数値であってもよい。
【０１１８】
障害イベントの種別が、例えば、ハードディスク装置の温度が所定値を超えたような、自動的な復旧が可能な軽微な障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性が低いことを表す「情報」と判定すればよい。また、障害イベントの種別が、例えば、特定のコンピュータ装置のハードディスクが故障したような、やや緊急性が高い障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性がやや高いことを表す「異常」と判定すればよい。障害イベントの種別が、例えば、データセンターの停電のような緊急性が高い障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性が高いことを表す「緊急」と判定すればよい。
【０１１９】
通知先決定部１２は、例えば通知テーブルを参照し、障害イベントの種類と重要度に応じて、通知の送信先を決定する（ステップＳ３１）。
【０１２０】
本実施形態の通知テーブルは、例えば、障害イベントの種類と、障害イベントの重要度と、通知の送信先を特定する情報と、通知の送信方法の組である通知ルールを複数含む。本実施形態の通知ルールは、障害イベントの重要度を含む点が、第２の実施形態の通知ルールと異なる。通知先決定部１２は、例えば、障害イベントの種類及び重要度が行及び列に対応し、各要素は、行及び列に対応する障害イベントの種類と重要度の場合の通知の送信先を表すような通知テーブルを参照して、通知の送信先を決定することもできる。ただし、障害イベントの種類及び重要度と通知の送信先の対応付けの方法は、これらの例に限られるものではなく、任意である。
【０１２１】
例えば、障害イベントの種別が自動的な復旧が可能な軽微な障害であり、緊急性が低く重要度が「情報」である場合、通知先決定部１２は、通知の送信先を例えば管理サーバにすればよい。また、障害イベントの種別が、例えば、特定のコンピュータ装置のハードディスクが故障したようなやや緊急性が高い障害であり、緊急性がやや高く重要度が「異常」である場合、通知先決定部１２は、通知の送信先を例えばハードディスクが故障したコンピュータ装置の管理者の端末にすればよい。障害イベントの種別が、例えば、データセンターの停電のような緊急性が高い障害であり、重要度が障害の緊急性が高いことを表す「緊急」である場合、通知先決定部１２は、通知の送信先を例えば施設管理部の部屋にすればよい。
【０１２２】
通知部１５は、例えば通知テーブルを参照して、障害イベントの種類及び重要度と通知先決定部１２が決定した通知の送信先をもとに送信方法を決定する（ステップＳ３２）。通知部１５は、通知先決定部１２が決定した通知先に対し、決定した送信方法により、通知を送信する（ステップＳ３３）。
【０１２３】
なお、通知部１５は、障害イベントの種類によらず、重要度と通知の送信先に基づき、通知の送信方法を決定してもよい。この場合、通知部１５は、例えば、重要度と通知の送信先と通知の送信方法の組を複数含むテーブルを参照して、重要度と通知の送信先に基づいて通知の送信方法を決定すればよい。
【０１２４】
次に、重要度に応じた送信方法の決定について、例を挙げて説明する。
【０１２５】
例えば、重要度が、緊急度の低い「情報」であり、送信先が管理サーバである場合、通知部１５は、例えば「メッセージの送信」を送信方法にする。この場合、通知部１５は、管理サーバにメッセージを送信する。メッセージを受信した管理サーバは、例えば、メッセージログに記録したり、管理サーバの管理者に受信したメッセージをまとめた電子メールを送信するなどすればよい。このようにして送信することで、重要度が「情報」であるような緊急度の低い通知より重要な通知が、緊急度の低い通知に紛れて読まれない可能性が低くなる。
【０１２６】
例えば、重要度が「異常」であり、送信先がハードディスクが故障したコンピュータ装置の管理者の端末である場合、通知部１５は、例えば電子メールを送信方法にすればよい。この場合、通知部１５は、その管理者に対して電子メールを送信する。一方、例えば、送信先はハードディスクが故障したコンピュータ装置の管理者の端末であり、重要度は「異常」より緊急性の高い「警告」である場合、通知部１５は、例えば端末の画面へのメッセージのポップアップ及び電子メールを送信方法にすればよい。この場合、通知部１５は、その管理者の端末の画面にメッセージをポップアップさせると共に、その管理者に対して電子メールを送信すればよい。受信したメッセージの端末の画面へのポップアップは、当該端末で動作するソフトウェアにより実現できる。電子メール及び画面へのポップアップにより送信することで、端末の使用者が早期に通知に気付く可能性が高まる。
【０１２７】
例えば、重要度が「緊急」であり、送信先が例えば施設管理部の部屋である場合、通知部１５は、例えばサイレンと回転灯と放送を送信方法にする。この場合、通知部１５は、例えば施設管理部の部屋のサイレンを鳴らして回転灯を点灯させると共に、施設管理部の部屋に対して障害イベント発生を告げる放送を行えばよい。通知部１５は、障害イベント発生を告げる放送を、予め準備しておいた音声をスピーカにより発生させることで行えばよい。サイレン及び回転灯は、例えば制御用ハードウェアやコンピュータからの制御が可能なように構成されていればよい。このようにサイレン、回転灯、放送により通知を送信することで、送信先となった部屋にいる人が即時に通知に気付くことが期待できる。
【０１２８】
以上で説明した本実施形態には、第２の実施形態と同じ効果の他に、障害イベントの緊急性に応じて通知の伝達の即時性を制御できるという効果がある。
【０１２９】
その理由は、通知部１５が、障害イベント判定部１４が判定した重要度と通知先決定部１２が決定した通知先をもとに送信方法を決定し、決定した送信方法により、通知を送信するからである。このことにより、本実施形態のイベント発生通知装置１Ａは、緊急性の高い障害イベントを通知する際、短時間で確実に伝達されることを期待できる送信方法で通知を送信することができる。一方、本実施形態のイベント発生通知装置１Ａは、緊急性の低い障害イベントを通知する際、緊急性の高い障害イベントの伝達を阻害しない送信方法で通知を送信することができる。
【０１３０】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【０１３１】
１、１Ａ イベント発生通知装置
１１ 検出値入力部
１２ 通知先決定部
１３ センサイベント検出部
１４ 障害イベント判定部
１５ 通知部
１６ 通知ルール記憶部
２、２１、２２、２Ｎ センサ
３ 通知送信装置
４、４１、４２、４Ｍ 送信先装置
５ ユーザ端末
【技術分野】
【０００１】
本発明は、センサの検出値に基づきイベントの発生を通知するイベント発生通知装置に関し、特に、センサの検出値に応じた通知先にイベントの発生を通知するイベント発生通知装置に関する。
【背景技術】
【０００２】
特許文献１には、センサが所定の状態を検知したことを検出した場合、通知先に通知を行うセンサ監視装置が記載されている。特許文献１のセンサ監視装置は、センサを監視するセンサ監視部と、通知部と、通知確認部と、制御部とを含み、次のように動作する。
【０００３】
センサが所定の状態を検知したことをセンサ監視部が検出した場合、通知部は第１の通知先にその旨の通知を送信する。通知確認部は、通知部が送信した通知を第１の通知先が認識したことを確認する。通知部が送信した通知を第１の通知先が認識したことを、通知確認部が確認できなかった場合、制御部は、第２の通知先を決定し、決定した第２の通知先に対する通知の送信を通知部に行わせる。
【０００４】
特許文献１のセンサ監視装置は、通知先の状態に応じて、複数の通知先から、通知を送信する通知先を選択する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】再表２００４／００８４０９
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載のセンサ監視装置は、センサが検知した状態とは関係なく、通知を送信する通知先を決める。従って、特許文献１に記載のセンサ監視装置には、センサの検出値に応じて、通知の送信先を決定することはできないという問題があった。
【０００７】
本発明の目的は、センサの検出値に応じて、通知の送信先を決定するイベント通知装置を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のイベント発生通知装置は、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段とを含む。
【０００９】
本発明のイベント発生通知方法は、センサが検出した検出値を受信し、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出し、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定し、前記障害イベントの種別に応じて前記通知の送信先を決定する。
【００１０】
本発明のイベント発生通知プログラムは、コンピュータを、センサが検出した検出値を受信する検出値入力手段と、複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段として動作させる。
【発明の効果】
【００１１】
本発明には、発生した事象に応じた適切な送信先に、通知を送信できるという効果がある。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態のイベント発生通知装置１の構成を表すブロック図である。
【図２】第１の実施形態のイベント発生通知装置１の動作を表すフローチャートである。
【図３】第２、第３の実施形態のイベント発生通知装置１Ａの構成を表すブロック図である。
【図４】第２の実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【図５】第３の実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【発明を実施するための形態】
【００１３】
以下で説明する本発明の各実施形態は、ハードウェア、又は、コンピュータとコンピュータを制御するためのソフトウェア、又は、これらの組み合わせによって実現することができる。
【００１４】
（第１の実施形態）
まず、本発明の第１の実施形態について図面を参照して詳細に説明する。
【００１５】
図１は本実施形態に係るイベント発生通知装置の構成を表すブロック図である。
【００１６】
図１を参照すると、イベント発生通知装置１は、検出値入力部１１と、通知先決定部１２を含む。イベント発生通知装置１は、センサ２の監視の対象からセンサ２が検出した検出値を受信することが可能である。
【００１７】
検出値入力部１１は、センサ２が検出した検出値を受信する。
【００１８】
通知先決定部１２は、検出値入力部１１が受信した検出値に応じて、複数の送信先装置４（図１の例では、送信先装置４１から送信先装置４ＭまでのＭ個）の中の一つ以上の送信先装置を、通知の送信先に決定する。以下、複数の送信先装置のうち、通知先決定部１２が決定した通知の送信先である送信先装置を、送信先装置Ｄと表記する。通知先決定部１２が決定した通知の送信先である送信先装置Ｄに対して、通知送信装置３が通知を送信する。
【００１９】
次に、本実施形態のイベント発生通知装置１の動作について、図面を参照して詳細に説明する。
【００２０】
図２は、本実施形態のイベント発生通知装置１の動作を表すフローチャートである。
【００２１】
図２を参照すると、まず、検出値入力部１１が、センサ２が検出した検出値を受信する（ステップＳ１１）。
【００２２】
センサ２は、例えば監視の対象を測定し、温度、電圧、湿度、風量、回転数等の物理量から検出値を検出するセンサである。以下の説明では、一つのセンサが一つの検出値を検出するとして説明するが、一つのセンサが検出する検出値は１種類であっても複数種類であってもよい。監視の対象は、例えば、ハードディスク装置やファンなどの部品や、コンピュータ装置や冷却装置、エレベータ等の装置や、データセンターや発電所などの施設等である。また、センサ２は、例えばハードディスク装置を監視し、書き込みエラーや読み込みエラー及びそれらの確率や不良セクタの増加数等の、ハードディスク装置の状態を検出する機構であってもよい。センサ２は、監視の対象が故障する可能性の程度を推定し、検出結果にしてもよい。センサ２は、検出した結果を検出値として出力する。検出値は、不連続値、連続値のいずれであってもよい。なお、センサ２は１つであっても、複数であってもよい。
【００２３】
次に、通知先決定部１２が、検出値入力部１１が受信した検出値に基づき、通知の送信先（送信先装置Ｄ）を決定する（ステップＳ１２）。
【００２４】
ステップＳ１２において、通知先決定部１２は、検出値に対する所定の条件に基づき、受信した検出値から送信先装置Ｄを決定する。通知先決定部１２は、例えば、検出値が含まれる値の範囲に応じて送信先装置Ｄを決定すればよい。また、通知先決定部１２は、例えば、検出値が所定の値であるセンサの個数に応じて送信先装置Ｄを決定してもよい。あるいは、通知先決定部１２は、例えば、一定時間継続して、所定の検出値を検出し続けた場合や、一定時間内に所定の回数以上所定の検出値を検出した場合に、これらの状況に応じて送信先装置Ｄを決定してもよい。通知先決定部１２が検出値に応じて通知の送信先として決定する送信先装置Ｄは、一つであっても複数であってもよい。
【００２５】
通知先決定部１２は、例えば、センサを特定する情報（センサＩＤ；ｉｄｅｎｔｉｆｉｅｒ）と、検出値に対する条件と、通知の送信先を特定する情報と、通知の送信方法との組（通知ルール）を、複数含むテーブル（通知テーブル）を参照して、通知先を決定すればよい。検出値に対する条件は、例えば値の範囲である。通知先決定部１２は、受信した検出値が、その検出値を検出したセンサのセンサＩＤに対応する「検出値に対する条件」で表される値の範囲に含まれる場合、対応する「通知の送信先を特定する情報」で特定される送信先装置を、通知の送信先に決定することができる。通知先決定部１２は、さらに、決定した通知の送信先に対応する「通知の送信方法」を通知を送信する方法に決めることもできる。通知テーブルは、通知先決定部１２が参照可能な、例えば記憶部等に格納されていればよい。また、通知先決定部１２は、複数の通知ルールを内部に保持し、自らが保持する通知ルールに基づき通知の送信先を決定してもよい。このように、各通知ルールは、各通知ルールが含む情報や条件の対応を得ることができるものであれば、必ずしもテーブルの形になっていなくてもよい。
【００２６】
通知の内容は、例えば、単に警告を表す情報であっても、検出値そのものであっても、検出値によって判断される監視の対象の状況を表す情報であってもよい。通知の媒体は、情報を伝達できる媒体であれば、テキスト、画像、音声、光など、どのような媒体であってもよい。通知の方法の例として、電子メールの送信、ファクシミリの送信、電話、端末装置の画面への表示、スピーカ等による音声の発生、例えば回転灯等の発光装置の点灯等による光の発生等が挙げられる。通知の方法は、例えば前述の方法を、複数組み合わせたものであってもよい。
【００２７】
通知の送信先となる送信先装置は、例えば、携帯端末やコンピュータ装置、サーバや、スピーカや回転灯、あるいは電話やその他の装置である。これらの通知の送信先を特定する情報は、例えば、個人や何人かのグループ等のメールアドレス、コンピュータ装置やサーバ等のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、電話番号やファックス番号、スピーカや回転灯等が存在する場所を特定する情報等である。
【００２８】
通知送信装置３は、例えば通知テーブルを参照して、通知先決定部１２が決定した通知先の装置に応じた送信方法を決定する（ステップＳ１３）。
【００２９】
通知送信装置３は、例えば、センサＩＤ及び検出値を受信し、受信したセンサＩＤ及び検出値をもとに、前述の通知テーブルを参照して、決定された通知の送信先に対応する「通知の送信方法」を、通知を送信する方法に決定すればよい。通知先送信装置３は、通知先決定部１２から、通知の送信先と共に通知の送信方法を受け取ってもよい。
【００３０】
通知送信装置３は、通知先決定部１２が決定した通知の送信先の装置に対して、決定した送信方法により通知を送信する（ステップＳ１４）。
【００３１】
通知送信装置３は、通知先決定部１２が決定した送信先装置Ｄである、例えば、メールアドレス、ファックス番号や電話番号、配線等に対し、通知を送信する。通知送信装置３は、イベント発生通知装置１とは別の装置であっても、イベント発生通知装置１と同じ装置であってもよい。
【００３２】
以上で説明した本実施形態には、発生した事象に応じた適切な送信先に、通知を送信できるという効果がある。
【００３３】
その理由は、通知先決定部１２がセンサの検出値に応じて通知の送信先を決定することで、センサの検出値に応じた送信先のみに通知が送信されるからである。このことにより、検出値に基づき予め設定した必要な通知以外の、不必要な通知が送信先に送られなくなり、送信先の負担が軽減される。
【００３４】
（第２の実施形態）
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。
【００３５】
図３は、本実施形態のイベント通知装置１Ａの構成を表すブロック図である。
【００３６】
図３を参照すると、イベント通知装置１Ａは、検出値入力部１１と、通知先決定部１２と、センサイベント検出部１３と、障害イベント判定部１４と、通知部１５とを含む。イベント通知装置１Ａは、通知ルール記憶部１６を含んでいてもよい。
【００３７】
検出値入力部１１は、センサ２１〜センサ２Ｎ（Ｎは２以上の整数）から、それぞれの検出値を受信する。検出値入力部１１は、第１の実施形態の検出値入力部１１と同じであるので、説明を省略する。センサ２１〜センサ２Ｎは、単一の種類のセンサであっても、複数の種類のセンサであってもよい。センサ２１〜センサ２Ｎの各センサは、前述のセンサ２と同じであるので、詳細な説明を省略する。
【００３８】
センサイベント検出部１３は、センサ毎に定められた条件により、検出値入力部１１が受信した検出値からセンサ毎のイベントを検出する。イベントは、例えば、検出値が、予め定められた条件で表される特定の状態にあることである。センサイベント検出部１３は、検出値が取りうる全ての値から何らかのイベントを検出してよい。また、検出値が取りうる値の範囲に、センサイベント検出部１３がイベントを検出しない検出値の範囲が存在してもよい。
【００３９】
センサイベント検出部１３は、例えば、センサＩＤと検出値に対する条件との組を複数含むテーブル（イベントテーブル）を参照して、検出値からセンサ毎のイベントを検出すればよい。センサイベント検出部１３は、イベントの検出の際、例えば後述の通知ルール記憶部１６が記憶するイベントテーブルを参照してもよく、自らの内部に保持するイベントテーブルを参照してもよい。また、センサイベント検出部１３は、イベントテーブルを参照するのではなく、内部に組み込まれた、検出値とイベントを対応付けるロジックにより、イベントを検出してもよい。
【００４０】
障害イベント判定部１４は、センサイベント検出部１３が検出したイベントの組み合わせから、障害イベントが発生したか否かを判定する。障害イベント判定部１４は、障害イベントが発生したと判定した場合、発生した障害イベントの種類を判定する。障害イベント判定部１４は、センサイベント検出部１３が検出したイベントの組み合わせが、予め定義されたいずれかの条件（通常、監視の対象に異常が生じたとみなされる状態）に当てはまった場合、障害イベントが発生したと判定する。イベントの条件は、例えば、所定のイベントの数や、所定のイベントの割合や、それらに対する閾値等の条件や、イベントの所定の組み合わせ等である。イベントの条件は、検出したイベントの組み合わせが当てはまるか否かを判断する基準となるものであればよい。
【００４１】
障害イベント判定部１４は、例えば、障害イベントとして検出するイベントの条件と、対応する障害イベントの種類の組を、複数含むテーブル（障害イベントテーブル）を参照して、障害イベントの発生を判定すればよい。障害イベント判定部１４は、例えば、検出されたイベントの組み合わせが、障害イベントテーブルのいずれかのイベントの条件に当てはまる場合、障害イベントが発生を判定すればよい。さらに、障害イベント判定部１４は、例えば、障害イベントテーブルにおいて、検出されたイベントの組み合わせが当てはまるイベントの条件に対応する障害イベントの種類を、発生した障害イベントの種類と判定すればよい。
【００４２】
障害イベント判定部１４は、障害イベントの発生及び種類の判定の際、例えば後述の通知ルール記憶部１６が記憶する障害イベントテーブルを参照してもよく、自らが内部に含む障害イベントテーブルを参照してもよい。また、障害イベント判定部１４は、障害イベントテーブルを参照するのではなく、内部に組み込まれた、イベントの状態と障害イベントの種類を対応付けるロジックにより、障害イベントの発生及び発生した障害イベントの種類を判定してもよい。
【００４３】
通知先決定部１２は、障害イベント判定部１４が判定した障害イベントの種類に応じて、複数の送信先装置（図３の例では、送信先装置４１から送信先装置４ＭまでのＭ個、Ｍは２以上の整数）の中の一つ以上の送信先装置を、通知の送信先である送信先装置Ｄに決定する。本実施形態の通知先判定部１２は、第１の実施形態の通知先判定部１２と比較すると、検出値ではなく障害イベントの種類に応じて、通知の送信先である送信先装置Ｄを決定する点が異なる。すなわち、本実施形態における通知ルールは、第１の実施形態における通知ルールとは異なり、センサＩＤ及び検出値に対する条件の代わりに、障害イベントの種類を含む。
【００４４】
通知先決定部１２は、第１の実施形態の通知先決定部１２と同様に、例えば通知テーブルを参照して、通知の送信先を決定する。ただし、本実施形態における通知テーブルは、障害イベントの種類と、通知の送信先を特定する情報と、通知の送信方法の組である通知ルールを複数含む点が、第１の実施形態における通知テーブルと異なる。なお、第１の実施形態と同様に、通知ルールは必ずしもテーブルの形になっていなくてもよい。
【００４５】
通知部１５は、例えば通知テーブルを参照して、通知先決定部１２が決定した送信先装置Ｄに応じた通知の送信方法を決定する。通知部１５は、送信先装置Ｄに対して、決定した送信方法により通知を送信する。
【００４６】
送信先装置４１〜送信先装置４Ｍは、第１の実施形態における送信先装置４１〜送信先装置４Ｍと同じなので、説明を省略する。
【００４７】
通知ルール記憶部１６は、イベントテーブルや、障害イベントテーブルや、通知テーブルを記憶してもよい。この場合、センサイベント検出部１３は、センサ毎のイベントを検出する際、通知ルール記憶部１６が記憶するイベントテーブルを参照する。また、障害イベント判定部１４は、障害イベントの発生及び種類を判定する際、通知ルール記憶部１６が記憶する障害イベントテーブルを参照する。また、通知先決定部１２は、通知の送信先である送信先装置Ｄを決定する際、通知ルール記憶部１６が記憶する通知テーブルを参照する。
【００４８】
イベント通知装置１Ａには、ユーザ端末５が接続されていてもよい。ユーザは、ユーザ端末５を介し、通知ルール記憶部１６が記憶する各テーブルの内容の、追加や削除、変更を行うことができる。
【００４９】
次に、本実施形態のイベント通知装置１Ａの動作について、図面を参照して詳細に説明する。
【００５０】
図４は、本実施形態のイベント通知装置１Ａの動作を表すフローチャートである。
【００５１】
図４を参照すると、まず、検出値入力部１１が、各センサが検出した検出値を受信する（ステップＳ２１）。検出値の例として、例えば、温度、気圧、湿度、ファンやハードディスク装置などの回転数、音の大きさ、電圧、ファンなどの風量等の流体の流量、振動等が挙げられる。検出値は、例えば、ハードディスク装置の書き込みエラーの発生率など、監視対象に何らかの状況が発生している確率でもよい。また、検出値は、「異常」や「正常」のような、状態を表す値であってもよい。
【００５２】
次に、センサイベント検出部１３が、センサ毎に定められたイベントを検出する条件を含む、例えばイベントテーブルを参照して、検出値入力部１１が受信した各検出値からセンサ毎のイベントを検出する（ステップＳ２２）。
【００５３】
センサイベント検出部１３は、受信した全ての検出値に対してイベントを検出するので、センサイベント検出部１３が一度に検出するイベントは一つとは限らない。また、受信した全ての検出値が、センサ毎に定められた条件に当てはまらない場合、センサイベント検出部１３はイベントを検出しない。
【００５４】
また、センサイベント検出部１３が検出するイベントは、例えば「低温」や「高温」のような検出値を定性的に表すものであってもよく、検出値そのもの（例えば温度の値など）のように定量的なものであってもよい。
【００５５】
センサイベント検出部１３がいずれかのイベントを検出した場合（ステップＳ２３、Ｙ）、障害イベント判定部１４は、例えば前述の障害イベントテーブルを参照して、センサイベント検出部１３が検出したイベントが、障害イベントであるか否かを判定する（ステップＳ２４）。センサイベント検出部１３がイベントを検出しなかった場合（ステップＳ２３、Ｎ）、処理は終了する。
【００５６】
障害イベント判定部１４は、検出したイベントの組み合わせが、障害イベントテーブルに含まれる条件に合致するか否かにより、障害イベントの発生及び種類を判定する。一つのイベントが、異なる複数の条件で判定の対象になっていてもよい。一つの組み合わせに対して、障害イベントと判定するための条件が複数存在していてもよい。障害イベント判定部１４は、例えば、センサイベント検出部１３が検出したイベントの組み合わせが、障害イベントと判定する条件のいずれかに合致する場合、障害イベントが発生したと判定する。例えば、センサイベント検出部１３が検出したイベントの組み合わせがイベント１、イベント２、イベント３であり、障害イベントと判定する条件が、イベント２とイベント３の検出である時、障害イベント判定部１４は障害イベントが発生したと判定すればよい。また、障害イベントと判定する条件となるイベントの組み合わせは、一つのイベントのみを含む組み合わせであってもよく、過去に検出したイベントを含む組み合わせであってもよい。
【００５７】
また、障害イベント判定部１４は、所定の時間継続して、センサイベント検出部１３が所定のイベントが検出し続けた場合や、所定の時間内に所定の回数以上、センサイベント検出部１３が所定のイベントを検出した場合、障害イベントの発生を判定してもよい。また、イベントが検出値そのものである場合、障害イベント判定部１４は、検出値の変化量が所定の閾値を上回った場合や下回った場合に、障害イベントの発生を判定してもよい。さらに、障害イベント判定部１４は、以上で説明した障害イベントの発生を判定する条件を組み合わせて、障害イベントの発生を判定してもよい。
【００５８】
次に、障害イベント判定部１４が障害イベントと判定する条件の具体的な例を挙げる。
【００５９】
（１）同一種センサにおけるイベントの組み合わせ
以下の説明は、同じ種類のセンサによる検出値から検出したイベントの組み合わせにより、障害イベントを判定する場合の条件の具体例である。
【００６０】
最も単純な例としては、センサイベント検出部１３が、障害や故障が発生したと判断される一つのイベントを検出した場合、障害イベント判定部１４が障害イベントの発生を判定することが挙げられる。この場合、障害イベントの発生を障害イベント判定部１４が判定するための条件となるイベントの組み合わせは、１つのイベントだけを含む。このようなイベントの例として、例えばハードディスク装置の故障がある。例えば、センサがハードディスク装置の故障センサであり、センサイベント検出部１３がハードディスク装置の故障を検出した場合、障害イベント判定部１４は、障害イベントとして、例えばハードディスク装置の故障の発生を判定すればよい。
【００６１】
また、検出したイベントが、単独ではすぐに障害や故障につながるようなものではない軽微なものであっても、同種のイベントが同時に多発した場合、重大な障害につながる例がある。このような例では、例えば若干数（例えば経験に基づいて定めた、重大な障害につながる可能性があると判断される閾値より、小さい数）のイベントが検出されている場合、障害イベント判定部１４は、障害イベントの発生を判定しなくてよい。またこの場合、障害イベント判定部１４は、重大ではない障害イベントの発生を判定してもよい。一方、故障につながる可能性が高くなる数（前述の閾値以上の数）のイベントが検出されている場合、障害イベント判定部１４は、緊急の、あるいは、重大な障害イベントの発生を判定すればよい。
【００６２】
例えば、一般に冷却装置は冷却能力に余裕を持たせて設計されているので、多数のファンを含む冷却装置で、１個のファンの故障が、すぐに冷却の対象の故障や障害につながる訳ではない。しかし、このような冷却装置において多数のファンが一度に故障した場合、冷却装置の冷却能力が温度上昇を防ぐのに必要な能力を下回り、冷却の対象の重大な障害や故障につながる可能性がある。
【００６３】
この例では、センサはファンの故障を検出するものであればよい。イベント検出部１３は、個別のファンの故障を、それぞれイベントとして検出すればよい。障害イベント検出部１４は、例えば必要な冷却能力に対応するファンの個数を閾値として、ファンの故障が発生した場合、故障したファンの個数が閾値を上回るか否かで、別の障害イベントの発生を判定すればよい。
【００６４】
例えば必要な冷却能力に対応する所定の個数未満の個数のファンの故障をイベントとして検出した場合、障害イベント判定部１４は、障害イベントとして、例えばファンの故障の発生を判定すればよい。また、例えば前述の所定の個数以上の個数のファンの故障をイベントとして検出した場合、障害イベント判定部１４は、障害イベントとして、前述のファンの故障の発生より重大な障害である、例えば緊急にファンの交換が必要な状態の発生を判定すればよい。
【００６５】
必要な冷却能力に対応するファンの個数は、例えば経験に基づいて予め設定されていればよい。また、図示しない入力部などを介して、管理者が必要な冷却能力に対応するファンの個数を入力してもよい。この例において、必要な冷却能力に対応するファンの個数は、ファンの総数に対する割合により算出することもできる。この場合、管理者が、図示しない入力部を介し、ファンの総数を入力すればよい。あるいは、各ファンをそれぞれ別のセンサが観測しているのであれば、例えば検出値入力部１１が、検出値を受信するセンサの個数により、ファンの総数を得ることもできる。あるいは、障害イベント検出部１４は、ファンの総数に対する故障したファンの個数の割合が閾値を上回るか否かにより、障害イベントの発生及び種類を判定してもよい。
【００６６】
また、同種の軽微なイベントの同時多発が重大な障害につながる例として、ＲＡＩＤ（Redundant Arrays of Independent Disks）を構成する複数のハードディスク装置の、エラー率（書き込みエラー率又は読み出しエラー率）に関するイベントが考えられる。
【００６７】
例えばＲＡＩＤ５やＲＡＩＤ６等のように、冗長構成のディスクアレイ装置には、ディスクアレイ装置を構成する複数のハードディスク装置のうち、所定の個数以下が故障しても、記録されているデータの復旧が可能なものがある。例えばＲＡＩＤ５の構成のディスクアレイ装置であれば１台のハードディスク装置が故障しても、ＲＡＩＤ６の構成のディスクアレイ装置であれば２台のハードディスク装置が故障しても、ディスクアレイ装置に記憶されているデータの復旧は可能である。しかし、所定の個数より多数のハードディスク装置の故障によって、ディスクアレイ装置に記録されているデータは失われる。
【００６８】
また、一般に、ハードディスク装置のエラー率が増大した場合、そのハードディスク装置は故障する可能性がある。そこで、センサイベント検出部１３は、所定値を超えるたエラー率の検出をイベントとして検出してもよい。しかし、エラー率の一時的な増大が故障につながるとは限らない。また、前述のディスクアレイ装置を構成するハードディスク装置の１台が故障しても、データの復旧は可能である。従って、ディスクアレイ装置の１台のハードディスク装置にのエラー率が、所定値（故障の可能性があると考えられるエラー率）を超えることは軽微なイベントと考えてもよい。従って、この場合、障害イベント判定部１４は、障害イベントの発生を判定しなくてよい。
【００６９】
しかし、エラー率が所定値を超えたハードディスク装置の全てに、故障する可能性がある。従って、前述のディスクアレイ装置のデータの復旧が可能な、ハードディスク装置の最大の故障台数より、多い台数のハードディスク装置のエラー率が、前述の所定値を超えた場合、重大な障害につながる可能性がある。よって、この場合、障害イベント判定部１４は、障害イベントとして、例えばハードディスクの故障について注意する必要がある状態になったことを判定すればよい。
【００７０】
なお、このディスクアレイ装置において実際にハードディスク装置の故障が発生した場合、障害イベント判定部１４は、以下で述べるように障害イベントの発生を判定すればよい。故障したハードディスク装置の台数が、データの復旧が可能なハードディスク装置の最大の故障台数より少ない場合、障害イベント判定部１４は、障害イベントとして、メンテナンスが必要な状態になったことを判定すればよい。故障したハードディスク装置の台数が、データの復旧が可能なハードディスク装置の最大の故障台数と等しい場合、障害イベント判定部１４は、障害イベントとして、緊急にメンテナンスが必要な状態になったことを判定すればよい。
【００７１】
また、同一環境にある複数の監視対象をそれぞれ計測する複数のセンサの検出値から検出されるイベントのうち、少数のイベントが他の多数のイベントと異なるイベントである場合、障害イベント判定部１４が障害イベントの発生を判定することが考えられる。
【００７２】
このようなイベントの例として、ディスクアレイ装置を構成する複数のハードディスク装置の温度から検出するイベントがある。なお、この例におけるディスクアレイ装置は、特定のハードディスク装置にアクセスが集中しないディスクアレイ装置である。このようなディスクアレイ装置を構成する複数のハードディスク装置の温度は、おおむね均等になると考えられる。多数のハードディスク装置の中で、少数のハードディスク装置の温度が他と比較して著しく高い場合や、著しく低い場合は、他の多数のハードディスク装置と温度が異なるハードディスク装置には障害が発生している可能性がある。
【００７３】
従って、例えば、ディスクアレイ装置の各ハードディスク装置の温度から検出されるイベントが、多数の「常温」と少数の「高温」である場合、高温のディスク装置に異常が発生した可能性がある。また、例えば、ハードディスク装置の温度から検出されるイベントが、多数の「高温」と少数の「常温」である場合、常温のハードディスク装置に異常が発生した可能性がある。また、例えば、ハードディスク装置の温度から検出されるイベントが、多数の「常温」と少数の「低温」である場合、常温のハードディスク装置に異常が発生した可能性がある。従って、これらの場合のように、多数のハードディスク装置とは異なる状態の少数のハードディスク装置が存在する場合、障害イベント判定部１４は、障害イベントが発生したと判定すればよい。
【００７４】
一方、全てのイベントが「常温」であれば、障害イベント判定部１４は、障害イベントが発生したと判定しなくてよい。また、全てのイベントが「高温」である場合も、原因は故障ではなく例えばディスクアレイ装置に対してアクセスが行われたことであると考えられるので、障害イベント判定部１４は、障害イベントが発生したと判定しなくてもよい。すなわち、全てのイベントが均等である場合、そのイベントが障害や故障に直接つながる状態を意味しないのであれば、障害イベントが発生したと判定しなくてもよい。なお、上述の「常温」は、温度の測定対象のハードディスク装置が、特別な状況ではない場合の温度、例えば負荷が高い時間が少ないハードディスク装置であれば負荷が高くない場合温度がおおむね含まれるような、所定の範囲の温度を表す。
【００７５】
この例において、イベント検出部１３は各ハードディスク装置の温度の測定値そのものをイベントとして検出してもよい。この場合、障害イベント判定部１４は、いずれかのハードディスク装置（ハードディスク装置Ａ）の温度の測定値と、他のハードディスク装置の温度の測定値の代表値の差の大きさが、所定の閾値を超える場合、ハードディスク装置Ａにおける障害の発生を判定してもよい。なお、閾値は、例えば経験に基づいて定めた値であればよい。また、代表値は、例えば、平均値、中央値、最頻値などである。温度の測定値は、連続値ではなく、所定の間隔の離散値であってもよい。
【００７６】
また、イベントの組み合わせは、必ずしも同時に検出したイベントのみにより構成される必要はない。イベントの組み合わせは、検出の時期が異なるイベントを含んでいてもよい。そのような例について、以下で説明する。
【００７７】
例えば、ハードディスク装置の故障がイベントとして検出され、その故障したハードディスク装置の交換後、再びそのハードディスク装置の故障がイベントとされた場合、２回の故障の間の時間が十分長ければ、２回の故障は自然な故障であると考えられる。この場合、障害イベント判定部１４は、ハードディスク装置の故障の度に、障害イベントとしてハードディスク装置の故障の発生を判定すればよい。しかし、２回の故障の間の時間が短い場合、２回の故障は、例えばハードディスク装置の設置場所に問題があることが原因の故障等、自然ではない故障である可能性があると考えられる。
【００７８】
この場合、障害イベント判定部１４は、ハードディスク装置の故障の発生後、同一の場所で所定期間内に再びハードディスク装置の故障の発生した場合、障害イベントとして、ハードディスク装置の故障に加え、例えば、故障の再発を判定してもよい。この場合のイベントの組み合わせは、所定の期間内に発生した、特定の場所のハードディスク装置の故障という、同一の種類のイベント２つの組み合わせにより、障害イベントの発生を判定していることになる。
【００７９】
（２）複数種センサにおける複数のイベントの組み合わせ
以下の説明は、複数の種類のセンサによる検出値から検出したイベントの組み合わせにより、障害イベントを判定する場合の条件の具体例である。
【００８０】
一般に、冷却ファンは、故障時や故障直前には、正常動作時と比較して、同一回転数では発生する音や振動が大きくなる。しかし、例えば、冷却対象の温度などにより回転数を変えることができる冷却ファンは、風量を増やすため回転数を上昇させると、通常、発生する音や振動が大きくなる。従って、音や振動の大きさの測定結果の検出値だけから、故障や故障が近いことを判定することはできない。
【００８１】
しかし、ファンの回転数や風量の測定結果と音や振動の大きさの測定結果を組み合わせることで、故障や故障が近いことを判定することが可能である。予め測定して対応付けておいた正常なファンの回転数や風量と音や振動の大きさの関係と、ファンの回転数や風量を測定した検出値と、音や振動を測定した検出値により、ファンの故障や故障が近いことを判定することが可能である。
【００８２】
ファンの回転数や風量と音や振動の大きさはおおむね比例関係にあるので、例えば回転数や風量の測定結果のイベントが「大」で、音や振動の測定結果のイベントが「大」である場合は、障害イベント判定部１４は、ファンは正常であると判断してよい。また、例えば回転数や風量の測定結果のイベントが「小」で、音や振動の測定結果のイベントが「小」である場合も、障害イベント判定部１４は、ファンは正常であると判断してよい。一方、例えば回転数や風量の測定結果のイベントが「大」で、音や振動の測定結果のイベントが「小」である場合は、障害イベント判定部１４は、ファンは故障又は故障直前の状態であると判断することができる。
【００８３】
なお、イベント検出部１３は、回転数や風量、音や振動の測定結果の、それぞれに対して定められた閾値に対する大小関係に基づき、イベントが「大」であるか「小」であるかを決定すればよい。また、回転数や風量、音や振動に対する閾値は、経験に基づいて予め決定されたものであればよい。
【００８４】
また、イベント検出部１３は、回転数や風量、音や振動を測定した検出値をイベントとして検出してもよい。この場合、障害イベント判定部１４は、回転数や風量の検出値に対する音や振動の検出値の割合が、例えば経験に基づき決定した閾値を上回る場合、故障又は故障の直前の状態であると判断すればよい。なお、回転数、風量、音、振動の測定値は、それぞれ、連続値であっても離散値であってもよい。
【００８５】
また、ハードディスク装置は、故障時又は故障の直前に、正常動作時と比較して音や振動が大きい傾向がある。一方、正常なハードディスク装置であっても、アクセスの発生中は、音や振動が大きくなる。従って、音や振動の測定値のみから、ハードディスク装置が故障又は故障の直前の状態にあることを判定することは難しい。
【００８６】
しかし、検出値入力部１１が、ハードディスク装置の音や振動を測定するセンサの検出値に加え、例えばハードディスク装置にアクセスする装置から、アクセス中であるか否かを表す情報を得ることで、ハードディスク装置が故障又は故障の直前の状態にあることの判定が可能となる。例えば、ハードディスク装置にアクセスがない状態（通常時）の音や振動を予め測定しておき、ハードディスク装置の音や振動が通常時より大きい状態であるイベントが検出された時、ハードディスク装置へのアクセスのイベントが検出されれば、障害イベント判定部１４は、障害イベントの発生を判定しなければよい。一方、ハードディスク装置の音や振動が通常時より大きい状態であるイベントが検出された時、ハードディスク装置へのアクセスのイベントが検出さなければ、障害イベント判定部１４は、障害イベントの発生として、ハードディスク装置が故障又は故障の直前の状態にあることを判定すればよい。
【００８７】
（３）所定時間内のイベント検出回数、イベント検出状態の継続時間
以下の説明は、所定時間内に所定回数以上、同一のイベントが検出された場合と、所定の時間、所定のイベントが検出されている状態が継続した場合の、障害イベントの発生を判定する条件の具体例である。
【００８８】
検出したイベントが、すぐに障害や故障につながるようなものではない軽微なものであっても、イベントが検出される状態が継続すれば、障害や故障につながったり、障害や故障が疑われたりする場合がある。
【００８９】
例えば、ハードディスク装置の温度が一時的に高くなっても、すぐには故障にはつながらない。しかし、高温状態が続いた場合、ハードディスク装置が故障する確率は増大する。
【００９０】
そこで、温度センサが測定したハードディスク装置の温度が所定値以上である場合、センサイベント検出部１３は、ハードディスク装置が高温であるイベントを検出すればよい。ハードディスク装置が高温であるイベントが、所定の時間検出され続けた場合や、所定の時間内に所定の回数以上検出された場合、障害イベント判定部１４は、障害イベントとして、例えば高温による要注意状態にあることを判定すればよい。
【００９１】
また、例えば、落雷などの影響によって、電圧の瞬間的な低下が発生することがある。電圧の瞬間的な低下が発生しても、無停電電源装置を使用することで、コンピュータ装置などの継続運用が可能である。従って、電圧の瞬間的な低下の発生は、軽微なイベントと言うことができる。しかし、電圧の瞬間的な低下が所定時間内に何度も発生するような場合、例えば周辺の地域に落雷が多発しており、停電が発生することが考えられる。
【００９２】
この場合、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の瞬間的な低下を検出すればよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間内に所定回数以上電圧の瞬間的な低下を検出した場合、例えば停電発生注意の障害イベントを判定すればよい。
【００９３】
また、電圧の低下が所定時間以上継続した場合、停電が発生したと考えられる。
【００９４】
この場合、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の低下を検出すればよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間以上の電圧の低下の継続を検出した場合、例えば停電発生の障害イベントを判定すればよい。あるいは、センサイベント検出部１３は、電圧センサが測定した電圧から、電圧の低下が一定時間以上継続したことを検出してもよい。障害イベント判定部１４は、センサイベント検出部１３が所定時間以上の電圧の低下を検出した場合、例えば停電発生の障害イベントを判定すればよい。
【００９５】
（４）（１）〜（３）に記載の条件の組み合わせ
障害イベント判定部１４は、（１）〜（３）に記載した条件の組み合わせにより、障害イベントの発生を判定してもよい。
【００９６】
例えば、上述のように、ディスクアレイ装置を構成する複数のハードディスク装置の温度から検出するイベントが、全て「高温」である場合、障害イベント判定部１４は、障害イベントが発生したと判定しなくてもよい。しかし、全てあるいは多数のイベントが「高温」である状態が長時間継続した場合、高温状態にあるハードディスク装置の寿命が短縮して故障が発生する可能性がある。また、全てのイベントが「高温」である状態が長時間継続した場合、例えば冷却装置が故障しているなど、ハードディスク装置以外に何か障害が発生していることも考えられる。
【００９７】
よって、障害イベント判定部１４は、全てあるいは多数のイベントが「高温」である状態が所定の時間以上継続した場合、障害イベントとして、例えば高温による要注意状態にあることを判定すればよい。また、全てのイベントが「高温」である状態が所定の時間以上継続した場合、障害イベント判定部１４は、障害イベントとして、例えば冷却能力が不足状態にあることを判定すればよい。
【００９８】
障害イベント判定部１４が障害イベントの発生を判定した場合（ステップＳ２５、Ｙ）、障害イベント判定部１４が判定した障害イベントの種類に基づき、通知先決定部１２が、例えば通知テーブルを参照して、通知の送信先である送信先装置Ｄを決定する（ステップＳ２６）。通知先決定部１２は、障害イベント判定部１４が判定した障害イベントの種類と、例えば予め定められた障害イベントの種類と送信先装置Ｄの対応に基づき、送信先装置Ｄを決定すればよい。通知先決定部１２が通知の送信先として決定する送信先装置Ｄは、障害イベント判定部１４が判定した障害イベントを必要に応じて解決することができる、例えば装置やシステム等の管理者や管理部門であればよい。
【００９９】
障害イベント判定部１４が判定した障害イベントの種類に対応する送信先が定まっていない場合、通知先決定部１２は、デフォルトとして定められた送信先を送信先装置Ｄと決定すればよい。
【０１００】
通知部１５は、障害イベント判定部１４が決定した送信先装置Ｄに、通知を送信する（ステップＳ２８）。
【０１０１】
以上で説明した本実施形態には、第１の実施形態と同様、通知の送信先の負担を軽減できるという効果がある。
【０１０２】
その理由は、障害イベント判定部１４が判定した障害イベントの種類に基づき、通知の通知先決定部１２が送信先を決定することで、センサの検出値に応じた送信先のみに通知が送信されるからである。上述のように、障害イベント判定部１４は、センサイベント検出部１３がセンサの検出値から検出したイベントに基づき、障害イベントの種類を判定する。このことにより、検出値に基づき予め設定した必要な通知以外の、不必要な通知が送信先に送られなくなり、送信先の負担が軽減される。
【０１０３】
本実施形態には、さらに、通知の通知先決定部１２が送信先を決定する規則を簡単化できるという効果がある。
【０１０４】
その理由は、通知の通知先決定部１２は、検出値の値そのものではなく、障害イベント判定部１４が判定した障害イベントの種類に基づき、送信先を決定するからである。
【０１０５】
（第３の実施形態）
次に、本発明の第３の実施形態について、図面を参照して詳細に説明する。
【０１０６】
本実施形態のイベント発生通知装置１Ａの構成は、図３に示す第２の実施形態のイベント発生通知装置１Ａの構成と同じである。
【０１０７】
以下では、本実施形態と、第２の実施形態との相違点を中心に説明する。
【０１０８】
本実施形態では、障害イベント判定部１４が、障害イベントの発生及び種類の判定に加え、障害イベントの種類に応じて、緊急性の度合いを表す重要度の判定を行う点が、第２の実施形態と異なる。重要度は、障害イベントの緊急性に応じて、適宜定められたものであればよい。
【０１０９】
また、通知先決定部１２が、障害イベントの種類だけでなく、重要度に応じて通知の送信先を決定する点が、第２の実施形態と異なる。
【０１１０】
さらに、通知部１５が、通知先決定部１２が決定した送信先及び障害イベント判定部１４が判定した重要度に応じて、通知の送信方法を決定し、通知先決定部１２が決定した送信先に対し、決定した送信方法で通知を送信する点が、第２の実施形態と異なる。なお、通知先決定部１２が、通知の送信先と共に通知の送信方法を決定する構成でも構わないが、本実施形態では、通知部１５が通知の送信方法を決定する構成について説明する。
【０１１１】
本実施形態の他の構成要素は、第２の実施形態と同じであるので、説明を省略する。
【０１１２】
次に、本実施形態の動作について、図面を参照して詳細に説明する。
【０１１３】
図５は、本実施形態のイベント発生通知装置１Ａの動作を表すフローチャートである。
【０１１４】
図５を参照すると、図５のステップＳ２１からステップＳ２５は、図４に示す第２の実施形態のステップＳ２１からステップＳ２５までの動作と同じであるので、説明を省略する。
【０１１５】
障害イベント判定部１４は、障害イベントの発生を判定した場合（ステップＳ２５、Ｙ）、例えば障害イベントテーブルを参照し、判定した障害イベントの種類に応じて、当該障害イベントの重要度を判定する（ステップＳ３０）。
【０１１６】
本実施形態の障害イベントテーブルは、第２の実施形態の障害イベントテーブルと異なり、障害イベントとして検出するイベントの条件と、対応する障害イベントの種類と、障害イベントの重要度の組を複数含む。本実施形態の障害イベントテーブルは、障害イベントの種類に対応する重要度を含む点が、第２の実施形態の障害イベントテーブルと異なる。
【０１１７】
重要度は、例えば、「情報」、「注意」、「異常」、「警告」、「緊急」等の、適宜定義された緊急性の度合いを表す情報である。また、重要度は、緊急性の度合いを表す数値であってもよい。
【０１１８】
障害イベントの種別が、例えば、ハードディスク装置の温度が所定値を超えたような、自動的な復旧が可能な軽微な障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性が低いことを表す「情報」と判定すればよい。また、障害イベントの種別が、例えば、特定のコンピュータ装置のハードディスクが故障したような、やや緊急性が高い障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性がやや高いことを表す「異常」と判定すればよい。障害イベントの種別が、例えば、データセンターの停電のような緊急性が高い障害である場合、障害イベント判定部１４は、重要度を、障害の緊急性が高いことを表す「緊急」と判定すればよい。
【０１１９】
通知先決定部１２は、例えば通知テーブルを参照し、障害イベントの種類と重要度に応じて、通知の送信先を決定する（ステップＳ３１）。
【０１２０】
本実施形態の通知テーブルは、例えば、障害イベントの種類と、障害イベントの重要度と、通知の送信先を特定する情報と、通知の送信方法の組である通知ルールを複数含む。本実施形態の通知ルールは、障害イベントの重要度を含む点が、第２の実施形態の通知ルールと異なる。通知先決定部１２は、例えば、障害イベントの種類及び重要度が行及び列に対応し、各要素は、行及び列に対応する障害イベントの種類と重要度の場合の通知の送信先を表すような通知テーブルを参照して、通知の送信先を決定することもできる。ただし、障害イベントの種類及び重要度と通知の送信先の対応付けの方法は、これらの例に限られるものではなく、任意である。
【０１２１】
例えば、障害イベントの種別が自動的な復旧が可能な軽微な障害であり、緊急性が低く重要度が「情報」である場合、通知先決定部１２は、通知の送信先を例えば管理サーバにすればよい。また、障害イベントの種別が、例えば、特定のコンピュータ装置のハードディスクが故障したようなやや緊急性が高い障害であり、緊急性がやや高く重要度が「異常」である場合、通知先決定部１２は、通知の送信先を例えばハードディスクが故障したコンピュータ装置の管理者の端末にすればよい。障害イベントの種別が、例えば、データセンターの停電のような緊急性が高い障害であり、重要度が障害の緊急性が高いことを表す「緊急」である場合、通知先決定部１２は、通知の送信先を例えば施設管理部の部屋にすればよい。
【０１２２】
通知部１５は、例えば通知テーブルを参照して、障害イベントの種類及び重要度と通知先決定部１２が決定した通知の送信先をもとに送信方法を決定する（ステップＳ３２）。通知部１５は、通知先決定部１２が決定した通知先に対し、決定した送信方法により、通知を送信する（ステップＳ３３）。
【０１２３】
なお、通知部１５は、障害イベントの種類によらず、重要度と通知の送信先に基づき、通知の送信方法を決定してもよい。この場合、通知部１５は、例えば、重要度と通知の送信先と通知の送信方法の組を複数含むテーブルを参照して、重要度と通知の送信先に基づいて通知の送信方法を決定すればよい。
【０１２４】
次に、重要度に応じた送信方法の決定について、例を挙げて説明する。
【０１２５】
例えば、重要度が、緊急度の低い「情報」であり、送信先が管理サーバである場合、通知部１５は、例えば「メッセージの送信」を送信方法にする。この場合、通知部１５は、管理サーバにメッセージを送信する。メッセージを受信した管理サーバは、例えば、メッセージログに記録したり、管理サーバの管理者に受信したメッセージをまとめた電子メールを送信するなどすればよい。このようにして送信することで、重要度が「情報」であるような緊急度の低い通知より重要な通知が、緊急度の低い通知に紛れて読まれない可能性が低くなる。
【０１２６】
例えば、重要度が「異常」であり、送信先がハードディスクが故障したコンピュータ装置の管理者の端末である場合、通知部１５は、例えば電子メールを送信方法にすればよい。この場合、通知部１５は、その管理者に対して電子メールを送信する。一方、例えば、送信先はハードディスクが故障したコンピュータ装置の管理者の端末であり、重要度は「異常」より緊急性の高い「警告」である場合、通知部１５は、例えば端末の画面へのメッセージのポップアップ及び電子メールを送信方法にすればよい。この場合、通知部１５は、その管理者の端末の画面にメッセージをポップアップさせると共に、その管理者に対して電子メールを送信すればよい。受信したメッセージの端末の画面へのポップアップは、当該端末で動作するソフトウェアにより実現できる。電子メール及び画面へのポップアップにより送信することで、端末の使用者が早期に通知に気付く可能性が高まる。
【０１２７】
例えば、重要度が「緊急」であり、送信先が例えば施設管理部の部屋である場合、通知部１５は、例えばサイレンと回転灯と放送を送信方法にする。この場合、通知部１５は、例えば施設管理部の部屋のサイレンを鳴らして回転灯を点灯させると共に、施設管理部の部屋に対して障害イベント発生を告げる放送を行えばよい。通知部１５は、障害イベント発生を告げる放送を、予め準備しておいた音声をスピーカにより発生させることで行えばよい。サイレン及び回転灯は、例えば制御用ハードウェアやコンピュータからの制御が可能なように構成されていればよい。このようにサイレン、回転灯、放送により通知を送信することで、送信先となった部屋にいる人が即時に通知に気付くことが期待できる。
【０１２８】
以上で説明した本実施形態には、第２の実施形態と同じ効果の他に、障害イベントの緊急性に応じて通知の伝達の即時性を制御できるという効果がある。
【０１２９】
その理由は、通知部１５が、障害イベント判定部１４が判定した重要度と通知先決定部１２が決定した通知先をもとに送信方法を決定し、決定した送信方法により、通知を送信するからである。このことにより、本実施形態のイベント発生通知装置１Ａは、緊急性の高い障害イベントを通知する際、短時間で確実に伝達されることを期待できる送信方法で通知を送信することができる。一方、本実施形態のイベント発生通知装置１Ａは、緊急性の低い障害イベントを通知する際、緊急性の高い障害イベントの伝達を阻害しない送信方法で通知を送信することができる。
【０１３０】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【０１３１】
１、１Ａ イベント発生通知装置
１１ 検出値入力部
１２ 通知先決定部
１３ センサイベント検出部
１４ 障害イベント判定部
１５ 通知部
１６ 通知ルール記憶部
２、２１、２２、２Ｎ センサ
３ 通知送信装置
４、４１、４２、４Ｍ 送信先装置
５ ユーザ端末
【特許請求の範囲】
【請求項１】
センサが検出した検出値を受信する検出値入力手段と、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、
前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段と
を含むイベント発生通知装置。
【請求項２】
前記センサイベント検出手段は、ファンの故障を検出し、
前記故障イベント判定手段は、故障していないファンの個数が必要な冷却能力に対応する個数に満たない場合、障害イベントの発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項３】
前記センサイベント検出手段は、同一の種類の複数の装置の温度を検出し、
前記故障イベント判定手段は、前記複数の装置のいずれか一つの装置の温度と、他の装置の温度の平均値、中央値、または最頻値との差の大きさが閾値を上回った場合、前記一つの装置における障害の発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項４】
前記センサイベント検出手段は、回転する部分を含む装置の当該回転する部分の回転数と、当該装置が発する音又は振動の大きさを検出し、
前記故障イベント判定手段は、回転数に対する音又は振動の大きさの割合が閾値を上回った場合、前記装置における障害の発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項５】
前記障害イベント判定手段は、前記障害イベントの種別に応じて、緊急性の程度を表す重要度を判定し、
前記通知先決定手段は、前記重要度に応じて前記通知の送信先を決定し、
前記通知先決定手段が決定した前記通知の送信先に対し、当該送信先及び前記重要度に応じた送信方法で前記通知を送信する通知手段を含む
請求項１乃至５のいずれかに記載のイベント発生通知装置。
【請求項６】
センサが検出した検出値を受信し、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出し、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定し、
前記障害イベントの種別に応じて前記通知の送信先を決定する
イベント発生通知方法。
【請求項７】
コンピュータを、
センサが検出した検出値を受信する検出値入力手段と、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、
前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段と
して動作させるイベント発生通知プログラム。
【請求項８】
コンピュータを、
ファンの故障を検出する前記センサイベント検出手段と、
故障していないファンの個数が必要な冷却能力に対応する個数に満たない場合、障害イベントの発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【請求項９】
コンピュータを、
同一の種類の複数の装置の温度を検出する前記センサイベント検出手段と、
前記複数の装置のいずれか一つの装置の温度と、他の装置の温度の平均値、中央値、または最頻値との差の大きさが閾値を上回った場合、前記一つの装置における障害の発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【請求項１０】
コンピュータを、
回転する部分を含む装置の当該回転する部分の回転数と、当該装置が発する音又は振動の大きさを検出する前記センサイベント検出手段と、
回転数に対する音又は振動の大きさの割合が閾値を上回った場合、前記装置における障害の発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【請求項１】
センサが検出した検出値を受信する検出値入力手段と、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、
前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段と
を含むイベント発生通知装置。
【請求項２】
前記センサイベント検出手段は、ファンの故障を検出し、
前記故障イベント判定手段は、故障していないファンの個数が必要な冷却能力に対応する個数に満たない場合、障害イベントの発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項３】
前記センサイベント検出手段は、同一の種類の複数の装置の温度を検出し、
前記故障イベント判定手段は、前記複数の装置のいずれか一つの装置の温度と、他の装置の温度の平均値、中央値、または最頻値との差の大きさが閾値を上回った場合、前記一つの装置における障害の発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項４】
前記センサイベント検出手段は、回転する部分を含む装置の当該回転する部分の回転数と、当該装置が発する音又は振動の大きさを検出し、
前記故障イベント判定手段は、回転数に対する音又は振動の大きさの割合が閾値を上回った場合、前記装置における障害の発生を判定する
請求項１に記載のイベント発生通知装置。
【請求項５】
前記障害イベント判定手段は、前記障害イベントの種別に応じて、緊急性の程度を表す重要度を判定し、
前記通知先決定手段は、前記重要度に応じて前記通知の送信先を決定し、
前記通知先決定手段が決定した前記通知の送信先に対し、当該送信先及び前記重要度に応じた送信方法で前記通知を送信する通知手段を含む
請求項１乃至５のいずれかに記載のイベント発生通知装置。
【請求項６】
センサが検出した検出値を受信し、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出し、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定し、
前記障害イベントの種別に応じて前記通知の送信先を決定する
イベント発生通知方法。
【請求項７】
コンピュータを、
センサが検出した検出値を受信する検出値入力手段と、
複数の前記センサ毎に定められた検出値に対する条件により、前記検出値から前記センサ毎のイベントを検出するセンサイベント検出手段と、
前記イベントの組み合わせ、前記イベントを検出し続けている時間、または一定時間内に前記イベントを検出した回数から、障害イベントの発生及び発生した障害イベントの種別を判定する障害イベント判定手段と、
前記障害イベントの種別に応じて前記通知の送信先を決定する通知先決定手段と
して動作させるイベント発生通知プログラム。
【請求項８】
コンピュータを、
ファンの故障を検出する前記センサイベント検出手段と、
故障していないファンの個数が必要な冷却能力に対応する個数に満たない場合、障害イベントの発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【請求項９】
コンピュータを、
同一の種類の複数の装置の温度を検出する前記センサイベント検出手段と、
前記複数の装置のいずれか一つの装置の温度と、他の装置の温度の平均値、中央値、または最頻値との差の大きさが閾値を上回った場合、前記一つの装置における障害の発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【請求項１０】
コンピュータを、
回転する部分を含む装置の当該回転する部分の回転数と、当該装置が発する音又は振動の大きさを検出する前記センサイベント検出手段と、
回転数に対する音又は振動の大きさの割合が閾値を上回った場合、前記装置における障害の発生を判定する前記故障イベント判定手段と
して動作させる請求項７に記載のイベント発生通知プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−８８８５５（Ｐ２０１２−８８８５５Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１０−２３３７９６（Ｐ２０１０−２３３７９６）
【出願日】平成２２年１０月１８日（２０１０．１０．１８）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２２年１０月１８日（２０１０．１０．１８）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
[ Back to top ]