JPH08329006A - 障害通知方式 - Google Patents

Abstract

(57)【要約】 【目的】オペレーティングシステムが起動されていなく
とも、障害情報をリモート保守センタへ通知することを
可能とする障害通知方式を提供する。 【構成】計算機システムを識別する計算機システム番号
７及びリモート保守センタへのメールダイヤル番号８を
保持するＥ2 ＰＲＯＭ６と、計算機システム番号７及び
メールダイヤル番号８を与えられ、この与えられたメー
ルダイヤル番号８で示されるリモート保守センタにこの
計算機システム番号７をメールとして送信するメール送
信回路１０と、計算機システムのブート処理中にハード
ウエア障害やファームウエア障害を含む各種障害を検知
したときに、Ｅ2 ＰＲＯＭ６に保持する計算機システム
番号７及びメールダイヤル番号８をメール送信回路１０
に与えることによりリモート保守センタへブート処理中
の障害を通知するメール送信プログラム２とを具備して
なることを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、遠隔地のリモート保守
センタにより運用監視される計算機システムであって、
障害を検知した際に上記リモート保守センタへその障害
を通知する計算機システムに適用して好適な障害通知方
式に係り、特に計算機システムのブート処理中に障害が
発生した等によりオペレーティングシステムを稼働させ
ることができない状況においても、リモート保守センタ
に障害を通知することを可能とする障害通知方式に関す
る。

【０００２】

【従来の技術】従来、計算機システムに障害が発生した
場合に、その障害をリモート保守センタへ通知するもの
として、その計算機システム上でアプリケーションとし
て動作するプログラム、例えばＵＵＣＰ（Unix to Unix
Copy ）等が使われていた。この動作概念を図６に示
す。

【０００３】図６に示すように、ハードウエア（Ｈ
Ｗ）、オペレーティングシステム（ＯＳ）及びアプリケ
ーション（ＡＰＬ）の各レベルで検出された障害は、オ
ペレーティングシステムを経由して（又はオペレーティ
ングシステム上で稼働するプログラムの機能により）、
リモート保守センタへの通知の要不要を判定する通知判
定プログラム２１に集められる。そして、この通知判定
プログラム２１は、リモート保守センタへ通知すべき情
報のみを選択してＵＵＣＰ２２に送信する。

【０００４】また、ＵＵＣＰ２２は、オペレーティング
システムインタフェース２３を経由して通信ドライバ２
４を起動し、通信回路２５及び通信モデム２６を介して
障害情報をリモート保守センタへ送信する。

【０００５】このように、通知判定や通知処理をアプリ
ケーションとして実装することにより、保守作業に必要
な情報（ハードウエア部品の型番等）を付加したり、通
信回線の種別に対応したりすることができ、柔軟な処理
が可能となる。

【０００６】しかし、上述したような従来の方式では、
オペレーティングシステムが稼働していることが前提と
なっているため、ブート処理が失敗したとき等オペレー
ティングシステムが起動できない状態に計算機システム
がなったときに、ハードウエア等で障害を検出した場合
であっても、通知判定プログラム２１やＵＵＣＰ２２等
のアプリケーションが動作していないため、リモート保
守センタに通知することができなかった。

【０００７】従って、このような場合には、計算機シス
テムの管理者やユーザが、システムが稼働していないこ
とに気付き次第、リモート保守センタに連絡していたと
いうのが現状である。しかし、計算機システムの無人運
転化が進められている近年においては、このような障害
が長時間のシステムダウンを引き起こしてしまう虞れが
ある。

【０００８】

【発明が解決しようとする課題】上述したように、従来
の障害通知方式においては、各種障害通知手段をオペレ
ーティングシステム上で稼働するアプリケーションとし
て実装していたために、オペレーティングシステムが稼
働していることが前提となってしまっており、オペレー
ティングシステムそのものを起動できないような障害が
発生した場合には、リモート保守センタにその障害を通
知できないといった問題があった。

【０００９】本発明は、上記実情に鑑みなされたもので
あり、オペレーティングシステムが起動されていなくと
も、障害情報をリモート保守センタへ通知することを可
能とする障害通知方式を提供することを目的とする。

【００１０】

【課題を解決するための手段】本発明は、遠隔地のリモ
ート保守センタにより運用監視される計算機システムで
あって、障害を検知した際に上記リモート保守センタへ
その障害を通知する計算機システムの障害通知方式にお
いて、上記計算機システムを識別する計算機システム番
号及び上記リモート保守センタへのメールダイヤル番号
を保持する不揮発性の記憶回路と、計算機システム番号
及びメールダイヤル番号を与えられ、この与えられたメ
ールダイヤル番号で示される上記リモート保守センタに
この計算機システム番号をメールとして送信するメール
送信回路と、上記計算機システムのブート処理中にハー
ドウエア障害やファームウエア障害を含む各種障害を検
知したときに、上記不揮発性記憶回路に保持する計算機
システム番号及びメールダイヤル番号を上記メール送信
回路に与えることにより上記リモート保守センタへブー
ト処理中の障害を通知する手段とを具備してなることを
特徴とする。

【００１１】また、本発明は、上記計算機システムが、
ブート処理完了後、システム稼働中に障害を検知した際
に、オペレーティングシステム上で稼働するアプリケー
ションにより上記リモート保守センタへ障害を詳細に通
知する機能を有し、上記計算機システムそれぞれに、上
記リモート保守センタ向けの二つのメールダイヤル番号
を割り付け、一方を上記ブート処理中の障害に対する簡
易な障害通知用に使用し、他方を上記ブート処理完了後
の障害に対する詳細な障害通知用に使用することを特徴
とする。

【００１２】また、本発明は、上記計算機システムが、
複数のプロセッサを有し、いずれか一つのプロセッサが
システムのブート処理を実施するマルチプロセッサシス
テムであって、いずれかのプロセッサによるシステムの
ブート処理が失敗し、他のプロセッサによるシステムの
ブート処理が成功した際に、ブート処理を失敗したプロ
セッサを識別するプロセッサ番号とともに、そのプロセ
ッサがブート処理を失敗した旨を通知することを特徴と
する。

【００１３】また、本発明は、上記計算機システムが、
補助電源装置を有し、システム立ち上げ時に主電源から
の電力供給が遮断されている際に、上記補助電源装置か
らの電力供給によりシステムのブート処理を試み、電源
障害を上記リモート保守センタに通知することを特徴と
する。

【００１４】

【作用】本発明によれば、システムを立ち上げる際、ブ
ート処理中にハードウエア障害やファームウエア障害等
を検知した場合に、通知手段が、不揮発性記憶回路から
計算機システムを識別する計算機システム番号と、リモ
ート保守センタへのメールダイヤル番号とを読み出す。

【００１５】そして、通知手段は、この読み出した計算
機システム番号及びメールダイヤル番号をメール送信回
路に入力する。一方、メール送信回路は、入力されたメ
ールダイヤル番号で示されるリモート保守センタに、こ
の計算機システム番号をメールとして送信する。

【００１６】これにより、ブート処理中の障害等、オペ
レーティングシステムが稼働していない状況において
も、計算機システム番号等、最低限の情報を付加してリ
モート保守センタに障害発生を通知することができる。

【００１７】また、計算機それぞれに、リモート保守セ
ンタ向けのメールダイヤル番号を二つずつ割り振ってお
き、一方をブート処理中の障害に対する簡易な障害通知
用に使用し、他方をブート処理完了後の障害に対する詳
細な障害通知用に使用するように設定する。

【００１８】上述したように、ブート処理が完了しオペ
レーティングシステムが正常に稼働した後の障害通知
は、ＵＵＣＰ等のアプリケーションにより詳細な情報が
付加され、かつ通信回線の種別に対応した柔軟な障害通
知が行われる。一方、リモート保守センタ側は、ＵＵＣ
Ｐ等の通信規約で障害通知がされることを前提としてい
る。しかし、オペレーティングシステム稼働前の障害通
知のプログラムは、ＲＯＭプログラム等として実装させ
なければならず、その大きさは限られているために、Ｕ
ＵＣＰ等の通信規約で送信することは困難である。ま
た、このような場合には、計算機システム番号等の情報
を送信できればよく、ＵＵＣＰ等の大部分の機能は不要
である。

【００１９】そこで、メールダイヤル番号を、ブート処
理中の障害とオペレーティングシステム稼働後の障害と
で使い分けることにより、ＲＯＭ等に実装させるブート
処理中の障害通知プログラムを小型化することが可能と
なる。

【００２０】また、複数のプロセッサを有するマルチプ
ロセッサの場合、いずれか一つのプロセッサがシステム
のブート処理を実施することになるが、そのプロセッサ
がブート処理を失敗したような場合には、他のプロセッ
サが次にブート処理を実施することになる。

【００２１】ここで、この他のプロセッサによるブート
処理が成功した場合、従来であれば、リモート保守セン
タへの障害通知は行われていなかった。しかし、このい
ずれかのプロセッサによるブート処理失敗が通知されな
いままにシステムの稼働が続けられると、正常稼働して
いたプロセッサが故障を発生させてしまったような場合
に、リブート処理が行えない等の問題が発生することも
考えられる。

【００２２】そこで、他のプロセッサによるブート処理
が成功した場合であっても、ブート処理を失敗したプロ
セッサを識別するプロセッサ番号をとともに、そのプロ
セッサがブート処理を失敗した旨をリモート保守センタ
に通知する。

【００２３】これにより、プロセッサの交換等の保守作
業が迅速に行えることになり、計算機システムの運用面
での信頼性を高めることができる。また、補助電源装置
を備えることにより、システム立ち上げ時に主電源から
の電力供給が遮断されている場合であっても、この補助
電源装置からの電力供給によりブート処理を試みる。

【００２４】そして、仮にこのブート処理が失敗に終わ
った場合であっても、ブート処理中の障害として最低限
の障害通知がリモート保守センタに通知されるため、主
電源の電力供給遮断によるシステムの長時間ダウンを回
避でき、迅速な対応をとることが可能となる。

【００２５】

【実施例】以下図面を参照して本発明の一実施例を説明
する。図１は同実施例に係る障害通知方式を適用してな
る計算機システムの概略構成を示す図である。

【００２６】同実施例に係る計算機システムは、２つの
演算プロセッサ５ａ〜５ｂを有するマルチプロセッサシ
ステムである。そして、これら２つの演算プロセッサ５
ａ〜５ｂには、それぞれＲＯＭ４ａ〜４ｂが接続されて
おり、オペレーティングシステムがロードされる前であ
っても、その内部のプログラムが実行できるようになっ
ている。このＲＯＭ４ａ〜４ｂには、ＣＰＵ選択プログ
ラム１、メール送信プログラム２及びブート処理プログ
ラム３が保持されている。また、同実施例に係る計算機
システムは、メール送信プログラム２の指示に従ってリ
モート保守センタへメールを送信するメール送信回路１
０と、リモート保守センタでこの計算機を識別するため
の計算機システム番号７及びリモート保守センタに対応
するメールダイヤル番号８を記憶するＥ2 ＰＲＯＭ６
と、ＣＰＵ選択プログラム１の指示に従って、ブート処
理やメール送信を行うプロセッサを決定するＣＰＵ選択
回路９とを備えている。

【００２７】次に、図２乃至図５を参照して同実施例の
動作を説明する。同実施例に係る計算機システムが電源
投入により電力を供給された際、演算プロセッサ５ａ〜
５ｂは、それぞれのＲＯＭ４ａ〜４ｂに格納されたＣＰ
Ｕ選択プログラム１を実行することによりＣＰＵ選択回
路９に対して選択要求を送信し（図２のステップＡ
１）、その回答を待機する（図２のステップＡ２）。こ
のＣＰＵ選択プログラム１により送信された選択要求
は、ＣＰＵ選択回路９で選択されたいずれか一つのプロ
セッサのみが選択要求を受理され（図２のステップＡ
３）、受理されたプロセッサのみがブート処理を実行し
（図２のステップＡ６）、他の演算プロセッサは、その
ブート処理の完了を待つ（図２のステップＡ４〜Ａ
５）。ここでは、演算プロセッサ５ａがＣＰＵ選択回路
９から選択要求を受理されたものとする。

【００２８】選択要求を受理された演算プロセッサ５ａ
は、ブート処理を行うため、ＲＯＭ４ａに格納されたブ
ート処理プログラム３を実行する（図２のステップＡ
６）。このブート処理プログラム３は、ブート処理に必
要な種々の条件をチェックしながらオペレーティングシ
ステムを外部記憶装置等のデバイスからメモリへロード
する処理を行う。

【００２９】ここで、このブート処理の動作を図３を参
照して説明する。ブート処理プログラム３は、まず、オ
ペレーティングシステムを保持しているデバイスを調べ
（図３のステップＢ１）、そのデバイスがアクセス可能
か否かをチェックする（図３のステップＢ２）。デバイ
スがアクセス可能であるときは（図３のステップＢ２の
Ｙ）、次にオペレーティングシステムを保持するファイ
ルを調べ（図３のステップＢ３）、そのファイルが読み
出し可能か否かをチェックする（図３のステップＢ
４）。

【００３０】このファイルが読み出し可能であるときは
（図３のステップＢ４のＹ）、このファイル内のオペレ
ーティングシステムをメモリに読み込む（図３のステッ
プＢ５）。ここで、最後まで読み込まれたか否かをチェ
ックし（図３のステップＢ６）、最後まで読み込まれて
いる場合には（図３のステップＢ６のＹ）、この読み込
んだオペレーティングシステムが正しいものか否かをチ
ェックする（図３のステップＢ８）。

【００３１】以上の処理がすべて正常であった場合に
は、ブート処理は成功であったと判定し（図３のステッ
プＢ９）、ブート処理を終了する。一方、一つでも異常
が検出された場合には、その時点でブート処理は失敗で
あったと判定し（図３のステップＢ１０）、ブート処理
を終了する。

【００３２】この演算プロセッサ５ａによるブート処理
が成功した場合には（図２のステップＡ７のＹ）、他の
プロセッサ（この例では演算プロセッサ５ｂ）へ成功を
通知して（図２のステップＡ８）、ＣＰＵ選択プログラ
ム１を終了し、ブートしたオペレーティングプログラム
に制御を移す。そして、ＣＰＵ選択回路９から選択要求
を受理されなかった演算プロセッサ５ｂも、このブート
処理成功通知の受信により（図２のステップＡ５の
Ｙ）、ＣＰＵ選択プログラム１を終了する。

【００３３】一方、ブート処理が失敗した場合には（図
２のステップＡ７のＮ）、他のプロセッサへの通知を行
わず、自分がブート処理を実行した最後のプロセッサで
あるか否かを判定する（図２のステップＡ９）。この判
定は、ＣＰＵ選択回路９から選択要求を受理する際に、
最後か否かを示すデータを付加情報として与えてもらう
等によればよい。

【００３４】この場合、演算プロセッサ５ａは最後のプ
ロセッサではないので（図２のステップＡ９のＮ）、そ
のまま処理を終了する。一方、ブート処理成功通知を受
信しないままブート処理に必要と思われる所定時間分待
機した演算プロセッサ５ｂは（図２のステップＡ４の
Ｙ）、ＣＰＵ選択プログラム１を再度最初から実行して
ブート処理を試みる（図２のステップＡ１）。

【００３５】ここで、演算プロセッサ５ｂのブート処理
も失敗した場合を考えてみると（図２のステップＡ７の
Ｎ）、今度はブート処理を実行した最後のプロセッサと
なるため（図２のステップＡ９のＹ）、メール送信プロ
グラム２によりブート処理失敗をリモート保守センタヘ
通知する（図２のステップＡ１０）。

【００３６】ここで、このメール送信処理の動作を図４
を参照して説明する。メール送信プログラム２は、ま
ず、Ｅ2 ＰＲＯＭ６からメールダイヤル番号８を読みだ
し（図４のステップＣ１）、メール送信回路１０にその
ダイヤル番号のリモート保守センタへ接続させる（図４
のステップＣ２〜Ｃ３）。

【００３７】次に、Ｅ2 ＰＲＯＭ６からこの計算機を識
別する計算機システム番号７を読み出し（図４のステッ
プＣ４）、ブート処理に失敗した原因を組み合わせてメ
ール情報を作成する（図４のステップＣ５）。

【００３８】そして最後に、このメール情報を、接続し
ているリモート保守センタに送信するようにメール送信
回路１０に要求する（図４のステップＣ６〜Ｃ７）。以
上のように、同実施例の計算機システムによれば、オペ
レーティングシステムが動作していなくとも、図５に示
すように、ハードウエア障害（ＨＷ）やファームウエア
障害（ＦＷ）等の各レベルの障害を、メール送信プログ
ラム２により通信回路１１及び通信モデム１２を介して
リモート保守センタに通知することが可能となる。

【００３９】これにより、無人運転等、まったくシステ
ム管理者がいない場合でも、ブート処理の失敗により計
算機システムが無動作状態のまま長時間放置されるよう
なことがない。

【００４０】なお、上述した例では、ブート処理実行時
の障害を考えているが、ここで一旦、ブート処理が成功
してオペレーティングシステムが立ち上がった後のアプ
リケーションプログラムを使用した障害通知を考えてみ
る。

【００４１】この場合、リモート保守センタとの接続プ
ロトコルはＵＵＣＰ等のプロトコルを使用することにな
り、一方、リモート保守センタではＵＵＣＰのプロトコ
ルでデータが送られてくることを前提としている。

【００４２】従って、ブート処理に失敗した場合のメー
ル送信プログラムもＵＵＣＰプロトコルに従って送信す
る必要がある。しかし、ＵＵＣＰプロトコルは、種々の
機能をサポートするため、複雑なプロトコルになってお
り、そのプログラムも非常に大きい。即ち、メール送信
プログラムもＵＵＣＰプロトコルを処理するために非常
に大きなものにならざるをえない。また、デバッグが難
しいＲＯＭプログラムが大きくなってしまうことから、
メール送信プログラムの信頼性も低下してしまう。さら
に、ブート処理に失敗した場合には、その原因と計算機
システム番号とをリモート保守センタに送信するだけで
よく、ＵＵＣＰの大部分の機能は不必要である。

【００４３】そこで、リモート保守センタに２つのメー
ルダイヤル番号を持たせ、ＵＵＣＰで障害通知する場合
のダイヤル番号と、ブート時の障害を通知する場合の緊
急ダイヤル番号を使い分ければ、ブート時のリモート保
守センタとの間のプロトコルを任意に設定できるように
なる。

【００４４】これにより、メール送信プログラムを必要
最小限の大きさのプログラムで実現できることになる。
また、上述した例では、全演算プロセッサがブート処理
に失敗した場合にのみリモート保守センタに障害を通知
していた。従って、いずれかの演算プロセッサがブート
処理に成功した場合には、ブート処理に失敗した演算プ
ロセッサが存在していても、リモート保守センタでは知
ることができない。

【００４５】しかし、ある演算プロセッサによるブート
処理の失敗が知らされないままでシステム運用を続けて
いると、正常に動いていた演算プロセッサが故障した場
合、リブート処理が行えなくなることも考えられる。

【００４６】例えば、図１に示す計算機システムにおい
て、演算プロセッサ５ａでのブート処理が失敗し、演算
プロセッサ５ｂでのブート処理が成功していたような場
合には、もし演算プロセッサ５ｂが何等かの理由で故障
したとき、この計算機システムはリブート処理ができな
い状態になってしまうことも考えられる。

【００４７】そこで、いずれかの演算プロセッサがブー
ト処理に失敗した場合には、最後のプロセッサであるか
否かに関わらず、リモート保守センタへ失敗した演算プ
ロセッサを識別するプロセッサ番号とともに、その旨を
通知することにより、その演算プロセッサの交換等、保
守作業を迅速に行うことができ、運用面での信頼性を向
上させることとなる。

【００４８】また、計算機システムに電力を供給する主
電源装置が何等かの理由で故障し、又は電力の供給が遮
断された場合に、図１に示す計算機システムは全く動作
することができないことになる。即ち、計算機システム
がブート処理をすべき時点でブート処理ができなかった
ことがリモート保守センタへも通知されず、長時間のシ
ステムダウンになってしまう危険がある。

【００４９】そこで、この計算機システムに所定の時間
電力を供給可能な補助電源装置を設け、主電源装置から
の電力供給が遮断されているときに、この補助電源装置
から電力を供給するとともに、例えばブート処理の先頭
で主電源装置からの電力供給遮断を検出し、電源障害と
してリモート保守センタへ通知する。これにより、主電
源装置からの電力供給遮断による計算機システムの長時
間ダウンを回避でき、迅速な対応を講じることが可能と
なる。

【００５０】

【発明の効果】以上詳述したように本発明によれば、ブ
ート処理中の障害等、オペレーティングシステムが稼働
していない状況においても、計算機システム番号等、最
低限の情報を付加してリモート保守センタに障害発生を
通知することができる。

【００５１】また、メールダイヤル番号を、ブート処理
中の障害とオペレーティングシステム稼働後の障害とで
使い分けることにより、ＲＯＭ等に実装させるブート処
理中の障害通知プログラムを小型化することが可能とな
る。

【００５２】また、他のプロセッサによるブート処理が
成功した場合であっても、ブート処理を失敗したプロセ
ッサを識別するプロセッサ番号をとともに、そのプロセ
ッサがブート処理を失敗した旨をリモート保守センタに
通知することにより、プロセッサの交換等の保守作業が
迅速に行えることになり、計算機システムの運用面での
信頼性を高めることができる。

【００５３】また、電源障害をリモート保守センタへ通
知することにより、主電源の電力供給遮断によるシステ
ムの長時間ダウンを回避でき、迅速な対応をとることが
可能となる。

【図面の簡単な説明】

【図１】本発明の実施例に係る障害通知方式を適用して
なる計算機システムの概略構成を示す図。

【図２】同実施例の動作を説明するためのフローチャー
ト。

【図３】同実施例のブート処理時の動作を説明するため
のフローチャート。

【図４】同実施例のメール送信処理時の動作を説明する
ためのフローチャート。

【図５】同実施例の動作原理を説明するための概念図。

【図６】従来の障害通知の動作原理を説明するための概
念図。

【符号の説明】

１…ＣＰＵ選択プログラム、２…メール送信プログラ
ム、３…ブート処理プログラム、４ａ，４ｂ…ＲＯＭ、
５ａ，５ｂ…演算プロセッサ、６…Ｅ2 ＰＲＯＭ、７…
ホスト識別番号、８…メールダイヤル番号、９…ＣＰＵ
選択回路、１０…メール送信回路。

Claims (4)

【特許請求の範囲】
1. 【請求項１】 遠隔地のリモート保守センタにより運用
   監視される計算機システムであって、障害を検知した際
   に上記リモート保守センタへその障害を通知する計算機
   システムの障害通知方式において、 上記計算機システムを識別する計算機システム番号及び
   上記リモート保守センタへのメールダイヤル番号を保持
   する不揮発性の記憶回路と、計算機システム番号及びメ
   ールダイヤル番号を与えられ、この与えられたメールダ
   イヤル番号で示される上記リモート保守センタにこの計
   算機システム番号をメールとして送信するメール送信回
   路と、上記計算機システムのブート処理中にハードウエ
   ア障害やファームウエア障害を含む各種障害を検知した
   ときに、上記不揮発性記憶回路に保持する計算機システ
   ム番号及びメールダイヤル番号を上記メール送信回路に
   与えることにより上記リモート保守センタへブート処理
   中の障害を通知する手段とを具備してなることを特徴と
   する障害通知方式。
2. 【請求項２】 上記計算機システムは、ブート処理完了
   後、システム稼働中に障害を検知した際に、オペレーテ
   ィングシステム上で稼働するアプリケーションにより上
   記リモート保守センタへ障害を詳細に通知する機能を有
   し、上記計算機システムそれぞれに、上記リモート保守
   センタ向けの二つのメールダイヤル番号を割り付け、一
   方を上記ブート処理中の障害に対する簡易な障害通知用
   に使用し、他方を上記ブート処理完了後の障害に対する
   詳細な障害通知用に使用することを特徴とする請求項１
   記載の障害通知方式。
3. 【請求項３】 上記計算機システムは、複数のプロセッ
   サを有し、いずれか一つのプロセッサがシステムのブー
   ト処理を実施するマルチプロセッサシステムであって、
   いずれかのプロセッサによるシステムのブート処理が失
   敗し、他のプロセッサによるシステムのブート処理が成
   功した際に、ブート処理を失敗したプロセッサを識別す
   るプロセッサ番号とともに、そのプロセッサがブート処
   理を失敗した旨を上記リモート保守センタに通知するこ
   とを特徴とする請求項１記載の障害通知方式。
4. 【請求項４】 上記計算機システムは、補助電源装置を
   有し、システム立ち上げ時に主電源からの電力供給が遮
   断されている際に、上記補助電源装置からの電力供給に
   よりシステムのブート処理を試み、電源障害を上記リモ
   ート保守センタに通知することを特徴とする請求項１記
   載の障害通知方式。