WO2023112359A1

WO2023112359A1 - 通信システム、管理装置及び端末

Info

Publication number: WO2023112359A1
Application number: PCT/JP2022/023197
Authority: WO
Inventors: 亮中野; 一登白根; 輔鈴木; 大樹山田
Original assignee: 株式会社日立産機システム
Priority date: 2021-12-17
Filing date: 2022-06-08
Publication date: 2023-06-22
Also published as: JP2023090412A; CN117642725A

Abstract

端末と接続される管理装置を含む通信システムであって、端末はログ情報を収集して管理装置へ送信するログ情報管理部と、ログ情報から端末における異常イベントの有無を解析して自己復旧処理を決定する自己障害解析部と、異常イベントに対する自己復旧処理を管理装置に通知する復旧通知送信部と、異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する自己復旧処理部と、を有し、管理装置は、端末から収集したログ情報を基に端末における異常イベントの有無を解析して復旧処理を決定する障害解析部と、端末から異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部と、通知の有無に応じて障害解析部で検知した異常イベントに対する復旧処理の実行命令を端末に指令する復旧命令部と、を有する。

Description

通信システム、管理装置及び端末

参照による取り込み

　本出願は、令和３年（２０２１年）１２月１７日に出願された日本出願である特願２０２１－２０５３５６の優先権を主張し、その内容を参照することにより、本出願に取り込む。

　本発明は、管理対象となる１以上の端末で発生した障害を解析し、当該障害に対する復旧処理を自動実行する手法に関する。

　近年、通信端末を介して工場等の現場装置に関するデータを収集し、現場装置の遠隔監視及び制御等を行うシステムが構築されている。一方、端末の増加や、システムの複雑化に伴い、障害発生時の解析、及び復旧工数の増大が課題となっており、障害解析及び復旧の自動化が求められている。

　本課題に対する解決策として、複数の端末を管理する管理装置を設け、端末から収集したログ情報を基に、管理装置が自動で障害解析を行い、復旧処理を講じる手法が存在する。しかし、障害により端末が通信の切断状態に陥り、管理装置が障害解析に必要なログ情報を収集できなくなった場合、管理装置は障害解析及び復旧処理が困難となる。

　また、通信帯域が狭い場合や、ログ情報の収集毎に通信料金が発生する場合、ログ情報の収集頻度を下げる必要があり、管理装置は障害発生から検知までに時間を要してしまうケースもある。

　そこで、管理装置ではなく、端末の自己解析により障害発生を検知し、復旧処理を講じる技術が存在する（例えば、特許文献１）。当該先行技術では、端末が管理装置から復旧方法の一覧を事前に取得し、自己解析によって異常を検知した際に、当該一覧を参照して復旧処理を実行する。

　当該先行技術によれば、端末が通信の切断状態に陥った場合でも、端末による通信切断の自己検知、及び自己復旧で通信を接続状態に復帰させることが可能になる。また、端末による自己解析は、管理装置に対するログ情報の送信を必要としないため、通信帯域や通信料金の増大を招くことなく、短周期で実行することが可能であり、早期の障害検知を実現できる。

国際公開第２０１７／１３５２２６号

　しかし、特許文献１では障害の解析を端末のみに委ねているため、端末が自己検知できない異常なイベントに対しては対応が困難である。例えば、管理装置から端末へのファームウェアの配信が失敗し、端末が誤って古いファームウェアを継続使用しているケースを想定する。

　この場合、本来適用されるべきファームウェアのバージョン情報は配信元である管理装置のみが把握しており、端末は自身に適用されているファームウェアが古いことを自己検知することはできない。このように、端末による自己検知が困難で、管理装置でしか検知できない異常も存在し、当該ケースへの対応も実現することが望ましい。

　本発明は、上記課題に鑑みてなされたものであり、端末の自己障害解析及び自己復旧により、通信の切断状態からの自己復旧や、障害の早期検知を実現することに加え、端末では自己検知できない異常イベントにも対応し、復旧可能にすることを目的としている。

　本発明は、管理対象となる１以上の端末と、前記端末と接続される管理装置からなる通信システムであって、前記端末は、自端末のログ情報を収集して、前記管理装置へ送信するログ情報管理部と、前記ログ情報から当該端末における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する自己障害解析部と、前記異常イベントに対する自己復旧処理を前記管理装置に通知する復旧通知送信部と、前記異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する自己復旧処理部と、を有し、前記管理装置は、前記端末から収集したログ情報を基に、前記端末における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する障害解析部と、前記端末から当該端末が検知した異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部と、前記通知の有無に応じて前記障害解析部で検知した異常イベントに対する復旧処理の実行命令を前記端末に指令する復旧命令部と、を有する。

　本発明によれば、端末で発生した異常イベントを、端末のログ情報を基に端末と管理装置の双方で解析することで、端末の自己解析及び復旧により障害の早期検知や、通信切断状態からの自己復旧を実現することに加え、管理装置による解析及び復旧命令で、端末では自己検知できない異常イベントも検知して端末を復旧させることが可能となる。

　本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

実施例１における通信システムの構成及び管理装置と端末のハードウェア構成を説明するブロック図である。実施例１における管理装置と端末の障害解析条件管理テーブルの一例を示す図である。実施例１における管理装置と端末のイベント判定条件管理テーブルの一例を示す図である。実施例１における管理装置と端末の復旧処理管理テーブルの一例を示す図である。実施例１における管理装置と端末による障害解析と復旧の流れを示すシーケンス図で、端末による自己復旧の例を示す。実施例１における管理装置と端末による障害解析と復旧の流れを示すシーケンス図で、管理装置による復旧命令の例を示す。実施例１における管理装置による障害解析処理、及び端末による自己障害解析処理の一例を示すフローチャートである。実施例１における管理装置による復旧命令の要否判定処理の一例を示すフローチャートである。実施例１における各種テーブルを設定するための画面表示の例を示す説明図である。実施例１における障害検知と復旧情報に関する画面表示例を示す説明図である。実施例２における管理装置の障害解析条件管理テーブルの一例を示す図である。実施例２における管理装置のイベント判定条件管理テーブルの一例を示す図である。実施例２における管理装置の復旧処理管理テーブルの一例を示す図である。実施例２における端末の復旧処理管理テーブルの一例を示す図である。実施例３における管理装置と端末による障害解析と復旧の流れを示すシーケンス図である。実施例３における管理装置が保持するシステム運用計画情報の一例を示す説明図である。実施例３における管理装置による復旧命令許可判定処理の一例を示すフローチャートである。

　まず、発明の原理（概要）について説明する。

　端末と管理装置は、障害解析条件管理部にてログ情報に対する障害解析条件一覧を各々で管理する。また、イベント判定条件管理部にて、一致した障害解析条件の組み合わせに基づくイベント判定条件一覧、さらに復旧処理管理部にて、イベント毎に講じるべき復旧処理一覧を管理する。

　端末と管理装置は、これらの管理情報に基づき、端末上で発生した異常イベントをそれぞれ解析し、当該イベントに対して講じるべき復旧処理を決定する。端末は、自己障害解析部にて前記障害解析条件管理部を参照し、条件毎に自端末内のログ情報に対する解析を実行して、ログ情報に合致した障害解析条件を抽出する。

　続いて、端末は、前記イベント判定条件管理部を参照し、合致した障害解析条件の組み合わせを基に、自端末内で発生した異常イベントを検知する。そして、端末は復旧処理管理部を参照し、当該異常イベントに対する自己復旧処理、ならびに管理装置に対する通知内容を決定する。

　その後、端末は復旧通知送信部にて、前記復旧処理実行に関する通知を管理装置宛に送信し、自己復旧処理部にて復旧処理を実行することで、異常状態からの自己復旧を実現する。

　また、管理装置も同様に、障害解析部にて前記障害解析条件管理部を参照して、端末から収集したログ情報に対する解析を実行し、合致した障害解析条件を抽出する。続いて、管理装置は前記イベント判定条件管理部を参照し、合致した障害解析条件の組み合わせを基に、当該端末で発生した異常イベントを検知する。

　そして、管理装置は復旧処理管理部を参照し、当該異常イベントに対する復旧処理を決定する。その後、管理装置は復旧通知受信部にて当該端末からの復旧通知を受信できない場合に、復旧処理の実行命令を当該端末へ送信し、異常状態からの復旧を実現する。一方、当該端末から復旧通知を受信した場合は、復旧処理の実行命令をキャンセルし、端末における冗長な復旧処理実行を回避する。

　このように端末と管理装置の双方で、端末上で発生した異常イベントを解析し、復旧処理を講じることにより、端末による早期障害検知及び自己復旧を実現することに加え、古いファームウェアの継続使用や設定ミスなど、管理装置でしか検知できない異常状態も検知し、自動的に復旧及び是正を講じることができる。特に、端末と管理装置の一方でしか検知できない異常イベントに対する障害解析条件やイベント判定条件、復旧処理も管理情報として登録しておくことで、様々な異常状態から復旧することが可能となる。また、端末から管理装置へ復旧処理に関する通知を送信させることで、冗長な復旧処理を抑止することも可能となる。

　以下、実施例について、図面を参照して説明する。尚、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

　以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報はどのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」とすることができる。

　以下に、本発明の障害解析及び復旧方法に係る実施例を図１～図１４を用いて説明する。実施例１を図１～図１０を用いて説明し、実施例２を図１１を用いて説明し、実施例３を図１２～図１４を用いて説明する。

　実施例１では、端末と管理装置による障害解析及び復旧処理について基本形を説明する。まず、図１を用いて通信システムの構成、及び端末と管理装置の構成を説明する。次に、図２～図４を用いて端末と管理装置が管理するテーブル情報を説明する。その後、図５～図８を用いて端末と管理装置による障害解析及び復旧処理の流れを説明し、図９と図１０で各種テーブル情報の入力、及び障害検知及び復旧情報に関する解析結果を出力する画面表示の例を説明する。

　図１を参照して、実施例１における通信システムの構成、及び端末と管理装置のハードウェア構成を説明する。図１の通信システムは、管理対象となる１台以上の端末１０１（１０１－ａ～１０１－ｂ）と、管理装置１０２とネットワーク１５０を含んで構成される。尚、以下の説明では端末１０１－ａ～１０１－ｂを個々に特定しない場合には「－」以降を省略した符号「１０１」を用いる。

　端末１０１と管理装置１０２は有線通信と無線通信の何れか、或いは両方を含むネットワーク１５０で接続されており、端末１０１は設置現場から取得したデータや、自端末の稼働情報等を記録したログ情報を管理装置１０２へ送信する。

　また、端末１０１は、該ログ情報を基に、自端末内で発生した異常イベントの有無を定期的に自己解析し、異常イベントの検知時には自己復旧処理を決定し、当該自己復旧処理に関する通知を管理装置１０２宛に送信した後、自己復旧処理を実行する。

　管理装置１０２は、端末１０１からの受信データを活用したサービスを提供する他、端末１０１の障害管理を担う。具体的には、管理装置１０２が各端末１０１から収集したログ情報を基に端末１０１における異常イベントの有無を定期的に解析し、異常を検知した場合は復旧処理を決定する。

　その後、管理装置１０２は、障害が発生した端末１０１からの自己復旧処理に関する通知の有無を判定し、通知が受信されてない場合には、該当する端末１０１に対して前記復旧処理の実行を命令する。

　尚、図１では、１台の管理装置１０２が受信データを活用したサービス提供と、端末１０１の障害管理の両方を担う構成を例示しているが、例えば前者のサービス提供のみを担う管理装置１０２と、後者の障害管理のみを担う管理装置１０２に分ける構成などであっても構わない。また、管理装置１０２は、端末１０１と同一の現場に設置する他、クラウド上など別拠点に設置する構成でも構わない。

　次に、端末１０１のハードウェア構成を説明する。端末１０１は、前述の通り現場から取得したデータや、自端末のログ情報等をパケットに格納して管理装置１０２へ送信するものであり、管理装置１０２との通信機能を有する計算機である。

　端末１０１は、取得するデータの種類に応じて種々の構成を有する。例えば、現場に存在する他の装置からデータを集約して送信するだけでなく、端末１０１自身も現場の温度を計測する場合は通信機能を有する温度計測端末、現場の映像を取得する場合は通信機能を有するカメラ端末などであってもよい。

　図１において、端末１０１は通信Ｉ／Ｆ１１１と、ＣＰＵ１１２、入力部１１３、出力部１１４、記憶装置１１５から構成されている。通信Ｉ／Ｆ１１１は、例えば無線通信を介して管理装置１０２とパケットの送受信を行う場合、デジタル信号と無線信号とを相互に変換し、生成したデジタルデータを無線信号に変換して送信する送信部と、受信した無線信号からデジタルデータを取り出す受信部から構成される。

　また、例えば端末１０１が管理装置１０２だけでなく、現場に存在する他の装置ともパケットの送受信を行う場合や、管理装置１０２と複数の通信手段を介してパケットの送受信を行う場合、複数の通信Ｉ／Ｆ１１１を搭載する形態であっても構わない。

　これらの通信手段はＬＴＥや、Ｅｔｈｅｒｎｅｔ、ＷｉＦｉ、光回線など任意のものとする。ＣＰＵ１１２は、記憶装置１１５に格納されている各種コンピュータプログラムを実行し、これにより端末１０１の有する各種機能が実現される。

　入力部１１３は、例えばキーボードやマウス或いはタッチパネルなどから構成され、作業者が各種操作や設定を入力するために用いられる。出力部１１４は、例えば液晶ディスプレイモニタなどから構成され、設定画面や各種処理の結果を表示する。ただし、別の外部機器から端末１０１へリモートログインを行う形態など、通信Ｉ／Ｆ１１１を介して外部機器からの入力情報の受け付けや、外部機器への出力情報の提供を行う場合は、入力部１１３と出力部１１４の搭載は必須ではない。

　記憶装置１１５は、例えば読み出し専用の半導体メモリなどから構成される記憶装置と、書き換え可能な半導体メモリ素子などから構成される記憶装置を含み、各種処理を実現するコンピュータプログラムや、取得したデータなどを格納する。

　アプリケーションプログラム１１６では、収集するデータの取得方法や送信スケジュールなどの各種設定が管理され、内部バスを介して接続されたＣＰＵ１１２により取得処理や、通信処理部１１７への送信命令が実行される。例えば、管理装置１０２に対して送信するログ情報の取得方法や、ログ情報の送信スケジュールなどもアプリケーションプログラム１１６で管理される。

　尚、アプリケーションプログラム１１６は、収集したログ情報をログバッファ３００へ格納し、所定のタイミングで管理装置１０２へログ情報を送信する。ログ情報としては、端末１０１の状態や端末１０１に接続されたセンサの測定値等の取得情報と、タイムスタンプと端末１０１の識別子を含むことができる。尚、アプリケーションプログラム１１６は、ログ情報を収集し、所定のタイミングでログ情報を管理装置１０２へ送信するログ情報管理部として機能することができる。

　通信処理部１１７は、通信における送受信処理を実現するものである。具体的には、送信する際のパケットの組立て処理や、受信する際の自端末宛のパケットか否かの判定等を始めとした、パケットの解析処理を行う。

　自己障害解析部１１８では、自端末のログバッファ３００からログ情報を参照して、自端末内の異常イベントの有無を定期的に解析する。また、自己障害解析部１１８は異常イベントを検知した場合は、講じるべき自己復旧処理と、管理装置１０２に対する通知内容を決定する。自己障害解析部１１８の処理内容については、後述の図７にて詳述する。

　復旧通知送信部１１９は、自己障害解析部１１８で検知した異常イベントに対する自己復旧処理を実行する前に、管理装置１０２宛に自己障害解析部１１８で決定した通知内容（復旧通知）を送信する。具体的には、復旧通知送信部１１９が通信処理部１１７に通知内容を出力し、送信処理を実行する。

　自己復旧処理部１２０は、自己障害解析部１１８で決定した自己復旧処理を実行する。尚、自己復旧処理の内容は、通信Ｉ／Ｆ１１１の再起動や、端末本体の再起動、ファームウェアの更新の実行など予め設定された処理であり、特定の処理に限定されるものではない。

　障害解析条件管理部１２１は、ログ情報に対する解析規則を定義した障害解析条件を管理する。具体的には、図２で後述する障害解析条件管理テーブル１２１ａを管理する。

　イベント判定条件管理部１２２は、障害解析条件管理テーブル１２１ａに合致した障害解析条件の組み合わせに対して、どのイベントを検知するかを定義したイベント判定条件を管理する。具体的には、図３で後述するイベント判定条件管理テーブル１２２ａを管理する。

　復旧処理管理部１２３は、検知された異常イベント毎に講じるべき復旧処理や、管理装置１０２に対する通知内容を管理する。具体的には、図４で管理する復旧処理管理テーブル１２３ａを管理する。

　尚、端末１０１は独立した装置である他、組み込み機器であってもよい。また、端末１０１は前述の通り、取得する現場データの種類に応じて構成が様々であり、例えば温度センサやカメラモジュール或いは加速度センサなども含む構成であって構わない。

　通信処理部１１７、自己障害解析部１１８、復旧通知送信部１１９、自己復旧処理部１２０、障害解析条件管理部１２１、イベント判定条件管理部１２２、復旧処理管理部１２３の各機能部は、プログラムとして記憶装置１１５にロードされてＣＰＵ１１２によって実行される。

　ＣＰＵ１１２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、ＣＰＵ１１２は、自己障害解析プログラムに従って処理を実行することで自己障害解析部１１８として機能する。他のプログラムについても同様である。さらに、ＣＰＵ１１２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

　続いて、管理装置１０２のハードウェア構成を説明する。管理装置１０２は、通信Ｉ／Ｆ１３１と、ＣＰＵ１３２、入力部１３３、出力部１３４、記憶装置１３５、通信処理部１３７、障害解析条件管理部１４１、イベント判定条件管理部１４２、復旧処理管理部１４３を含みこれらの構成要素は前述の端末１０１の構成要素と同様である。

　図１において、前述の端末１０１と同様に、別の外部機器から管理装置１０２へリモートログインを行う形態など、通信Ｉ／Ｆ１３１を介して外部機器からの入力情報の受け付けや、外部機器への出力情報の提供を行う場合は、入力部１３３と出力部１３４の搭載は必須ではない。

　また、アプリケーションプログラム１３６は、端末１０１から収集したデータやログ情報を活用したサービスをユーザに提供するプログラムである。アプリケーションプログラム１３６が、例えば、端末１０１から受信した現場データ（温度等）の単位時間当たりの平均値を提供するプログラムの場合、収集したデータの値から平均値を算出するなど、データの解析処理等を行う。

　その他、端末１０１におけるデータやログ情報の送信スケジュールを遠隔設定及び管理するプログラム等を有する場合も、当該アプリケーションプログラム１３６に含まれる。尚、アプリケーションプログラム１３６は、各端末１０１から収集したログ情報をログ蓄積情報２００に格納する。また、通信システムの計画停止時刻など、運用計画情報を管理する場合も当該アプリケーションプログラム１３６に含まれる。アプリケーションプログラム１３６は、当該運用計画情報をシステム運用計画情報１３００に格納して管理する。ただし、本実施例において当該運用計画情報の格納・管理は必須ではない。当該運用計画情報を活用する実施例については、実施例３で後述する。

　障害解析部１３８は、端末１０１から収集したログ蓄積情報２００のログ情報を管理し、当該ログ情報を解析して各端末１０１における異常イベントの有無を解析する以外は、前述の端末１０１が有する自己障害解析部１１８と同様である。

　障害解析部１３８は、収集したログ蓄積情報２００のログ情報の解析により、各端末１０１で発生した異常イベントの有無を定期的に判定し、異常イベントを検知した際には講じるべき復旧処理を決定する。障害解析部１３８の処理内容については、後述の図７にて詳述する。

　復旧通知受信部１３９では、各端末１０１から受信した、自己復旧処理に関する通知を管理する。具体的には、通信処理部１３７で受信パケットを解析した結果、当該パケットが自己復旧処理に関する通知であった場合、復旧通知受信部１３９に通知され、復旧通知受信部１３９はどの端末１０１から、どのような通知内容を受信したかを記録する。

　復旧命令部１４０では、障害解析部１３８で決定した復旧処理の実行を、異常発生元の端末１０１に対して命令する。このとき、復旧命令部１４０は復旧通知受信部１３９を参照し、当該端末１０１からの自己復旧処理に関する復旧通知の有無に応じて命令の要否を判定する。

　復旧命令部１４０は障害が発生した端末１０１から自己復旧処理に関する通知を未受信であれば、復旧処理の実行命令（以下、復旧命令）を該当の端末１０１に送信する。具体的には、通信処理部１３７に復旧命令を通知して、当該復旧命令を当該端末１０１へ送信させる。

　一方、障害が発生した端末１０１から前記通知を受信済みであれば復旧命令部１４０は復旧命令をキャンセルし、破棄することで、冗長な復旧命令を回避する。本処理の詳細は、図８にて後述する。

　尚、管理装置１０２は前述の通り、図１における全ての構成を１台の管理装置１０２に含む、複数台の管理装置１０２に分離して構成する形態であっても構わない。そのため、図１に示す構成を、１台の管理装置１０２に全てを含むことは必須ではない。

　図２を参照して、端末１０１の障害解析条件管理部１２１、及び管理装置１０２の障害解析条件管理部１４１で管理する障害解析条件管理テーブル１２１ａ、１４１ａについて説明する。

　障害解析条件管理テーブル１２１ａ、１４１ａは、端末１０１の各種ログ情報に対する解析規則を定義した障害解析条件を管理するもので、図２は実施例１における障害解析条件管理テーブルの構成図を示している。

　解析条件ＩＤ２０１は、障害解析条件の識別子を示しており、障害解析条件毎にユニークな識別子を設定する。このフィールドに記載する識別子は、任意の形式であって構わない。図２に例示の通り、参照するログ情報の種別を識別子として文字列で表現する他、「Ｎｏ．１、Ｎｏ．２、…」などの連番で識別子を定義する形態であっても構わない。

　参照情報２０２は、端末１０１のログ情報のうち、当該障害解析条件において参照するログ情報の種別を示している。図２の例では、「ＬＴＥ接続状態」など人間が解釈しやすい文字列の形式でログ情報種別を記載しているが、本記載の形式は任意である。例えば、端末１０１の各レジスタに個々のログ情報が格納されており、レジスタ値をログ情報種別として代用できる場合は、当該レジスタ値を参照情報２０２に記載しても構わない。

　比較方法２０３は、後述の閾値２０５に記載の値を、「絶対値」として比較するか、前回参照値からの「相対値」（変化量）として比較するかを示している。例えば、図２に例示する障害解析条件管理テーブルのうち、「障害解析条件ＩＤ：ＣｐｕＲａｔｉｏ」の行に登録された障害解析条件において、比較方法２０３に「絶対値」を登録した場合は、現在の端末１０１のＣＰＵ使用率が９５％（０．９５）以上であるかを判定し、「相対値」を登録した場合は、現在のＣＰＵ使用率が前回参照値から９５％以上増加しているかを判定する。

　このように、比較方法２０３で指定する比較方法を適切に設定することで、様々な障害解析条件を柔軟に定義することを可能にしている。尚、図２では比較方法２０３の選択肢として、「絶対値」と「相対値」の２パターンを例示しているが、他にも過去Ｎ回（Ｎは１以上の整数）の参照値に対する「平均値」、「最大値」、「最小値」など、任意の比較方法を追加しても構わない。

　比較条件２０４は、後述の閾値２０５に対する大小関係を規定する比較条件を示している。具体的には、「＝、≧、＞、＜、≦、≠」などの比較演算子を登録するフィールドである。ただし、比較演算子に限らず、「一致」や「以上」など文字列で大小関係を定義する形態であっても構わない。

　閾値２０５は、参照情報２０２で指定したログ情報に対する比較基準値を示している。ただし、閾値２０５における記載形式は数値に限らず、文字列であっても構わない。例えば、図２に例示のように、端末１０１において「ＬＴＥ接続状態」を「０」や「１」の数値ではなく、「切断」や「接続」などの文字列で表現する場合は、閾値２０５に「切断」という文字列を指定する。

　閾値２０５に文字列を登録する場合、多くの場合、比較条件２０４に登録される比較演算子は「＝（一致）」、「≠（不一致）」の何れかとなるが、「前方一致」や「後方一致」など任意の比較条件を追加しても構わない。

　合致回数２０６は、参照情報２０２で指定したログ情報種別に対して、比較方法２０３、比較条件２０４、閾値２０５で指定した解析条件を、連続で何回満たした場合に条件合致と見なすかを示している。

　例えば、瞬時的なＬＴＥ切断だけで過剰に異常を検知することを避けたい場合は、図２の「障害解析条件ＩＤ：ＬｔｅＳｔａｔｅ」の行に記載の通り、合致回数２０６を「３」などに設定することで対応できる。この場合、連続３回以上に亘って、「ＬＴＥ接続状態」が「０（切断）」であることを検知しない限り、「障害解析条件ＩＤ：ＬｔｅＳｔａｔｅ」は合致判定が下されないため、一定期間のＬＴＥ切断を以って、異常を検知することが可能となる。

　尚、障害解析条件管理テーブル１２１ａ、１４１ａは、端末１０１と管理装置１０２の双方で管理するが、各々に登録する障害解析条件の内容は異なっていても構わない。例えば、図２に例示のテーブルのうち、「障害解析条件ＩＤ：ＦｉｒｍＶｅｒ」の行では、端末１０１に適用されているファームウェアバージョンが１４．０１未満であるかを解析する障害解析条件を例示しているが、一般的に最新のファームウェアバージョン情報は管理装置１０２のみが管理するケースが多い。

　最新のファームウェアバージョンが更新された場合、管理装置１０２は閾値２０５の設定値を、例えば「１４．０１」から「１５．００」などに更新することが可能であるが、端末１０１は明示的に管理装置１０２から指示されない限り、障害解析条件管理テーブル１２１ａを管理装置１０２と同様に更新することは困難である。

　そのため、「障害解析条件ＩＤ：ＦｉｒｍＶｅｒ」に関する障害解析条件は、管理装置１０２の障害解析条件管理部１４１でのみ登録し、端末１０１には登録しないことで、端末１０１における障害解析処理の負荷を軽減することが可能となる。また、同一のログ情報に対して、端末１０１と管理装置１０２で異なる閾値２０５や合致回数２０６を指定してもよい。

　例えば、端末１０１が３分以上に亘ってＬＴＥ切断状態に陥った場合に、異常を検知したいケースを想定する。このとき、端末１０１の自己障害解析部１１８による自己解析周期を１分、管理装置１０２の障害解析部１３８による解析周期を１分３０秒とした場合、端末１０１の「障害解析条件ＩＤ：ＬｔｅＳｔａｔｅ」に対する合致回数２０６を「３」（＝３分÷１分）、管理装置１０２における合致回数２０６を「２」（＝３分÷１分３０秒）とすることなどが考えられる。

　このように、端末１０１と管理装置１０２で管理する障害解析条件管理テーブル１２１ａ、１４１ａに各々適切な障害解析条件を定義することで、柔軟に端末１０１で発生した異常を検知することが可能となる。特に、端末１０１又は管理装置１０２の一方でしか検知できない異常に関する障害解析条件も登録することで、様々な障害や異常を検知することが可能となる。

　図３を参照して、端末１０１のイベント判定条件管理部１２２、及び管理装置１０２のイベント判定条件管理部１４２で管理するイベント判定条件管理テーブル１２２ａ、１４２ａについて説明する。

　イベント判定条件管理テーブル１２２ａ、１４２ａは、前記障害解析条件毎の合致判定結果を基に、どのイベントを異常イベントとして検知すべきかを定義したイベント判定条件を管理するものである。図３は実施例１におけるイベント判定条件管理テーブル１２２ａ、１４２ａの構成図を示している。

　イベントＩＤ３０１は、検知する異常イベント種別を区別するための識別子を示しており、イベント毎にユニークな識別子を登録する。当該識別子の命名規則は任意であり、図３の例では「ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」のような可読性を優先した表記を採用しているが、例えば「ｅｖｅｎｔ０１、ｅｖｅｎｔ０２、…」などの連番で、識別子を表記しても構わない。

　合致条件（１）３０２、合致条件（２）３０３、合致条件（３）３０４は、イベントＩＤ３０１で指定した異常イベントの検知において、合致すべき障害解析条件の識別子を示している。

　当該フィールドには、図２の障害解析条件管理テーブル１２１ａ、１４１ａの解析条件ＩＤ２０１に記載した識別子の何れかを登録する。尚、図３の「イベントＩＤ：ＬａｃｋＲｘＣａｐａｂｉｌｉｔｙ（負荷上昇による受信能力不足）」の行に例示の通り、単一のイベントに対して複数の障害解析条件ＩＤを指定しても構わない。

　本ケースでは、これらの障害解析条件の全てに合致した場合のみ、当該異常イベントを検知する。図３の例では、図２の「障害解析条件ＩＤ：ＣｐｕＲａｔｉｏ（９５％以上のＣＰＵ使用率を３回連続検知）」と、「障害解析条件ＩＤ：ＰａｃｋｅｔＤｒｏｐ（パケットドロップ数の増加量が３回連続で３００パケットを超過）」の両方を満たした場合に、端末１０１における「負荷上昇による受信能力不足」を異常イベントとして検知する。

　尚、単一の障害解析条件の合致を以って、複数の異常イベントを検知したい場合は、複数の異常イベントに対して同一の障害解析条件ＩＤを登録することで検知可能となる。このように、各異常イベントに対して単一又は複数の障害解析条件ＩＤを登録可能にすることで、複雑かつ多様な異常イベントを検知することが可能である。図３の例では、合致条件（１）～合致条件（３）の計３つの合致条件フィールドを記載しているが、当該フィールド数は任意に変更して構わない。

　尚、イベント判定条件管理テーブル１２２ａ、１４２ａは、端末１０１と管理装置１０２の双方で管理するが、各々に登録するイベント判定条件の内容は異なっていても構わない。

　例えば、前述の通り、端末１０１が自身に適用されているファームウェアバージョンが古いことを自己検知することが困難なケースを想定する。この場合、図３の「イベントＩＤ：ＯｌｄＦｉｒｍ（古いファームウェア適用）」に関するイベント判定条件を、端末１０１には登録せず、管理装置１０２のイベント判定条件管理部１４２のみに登録する形態などが考えられる。

　図４を参照して、端末１０１の復旧処理管理部１２３、及び管理装置１０２の復旧処理管理部１４３で管理する復旧処理管理テーブル１２３ａ、１４３ａについて説明する。復旧処理管理テーブル１２３ａ、１４３ａは、異常イベント毎に講じるべき復旧処理を管理するものであり、図４は実施例１における復旧処理管理テーブル１２３ａ、１４３ａの構成図を示している。

　イベントＩＤ４０１は、異常イベントの種別を区別するための識別子を示している。図３のイベント判定条件管理テーブルのイベントＩＤ３０１と同様であり、記載形式は図３のイベントＩＤ３０１に準拠する。

　通知メッセージ４０２は、端末１０１がイベントＩＤ４０１に記載の異常イベントを検知した際に、管理装置１０２宛に送信する通知内容を示している。図４の例では、復旧処理内容を示す文字列（例：ＬｔｅＲｅｂｏｏｔ（ＬＴＥに関する通信Ｉ／Ｆ再起動））と、検知したイベントＩＤ（例：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断））の組み合わせを通知するよう登録しているが、本通知内容は任意の形式であって構わない。

　ただし、管理装置１０２が本通知を受信した際に、通知元の端末１０１がどのような自己復旧処理を実行するのか、或いはどのような異常イベントを検知したのかを判別できるような形式であることが望ましい。尚、通知メッセージ４０２のフィールドは、管理装置１０２が管理する復旧処理管理テーブルにおいては空欄とする他、省略しても構わない。

　復旧施策４０３は、端末１０１や管理装置１０２がイベントＩＤ４０１に記載の異常イベントを検知した際に、講じるべき復旧処理を示している。端末１０１がイベントＩＤ４０１に記載の異常イベントを検知した場合は、復旧施策４０３に登録された自己復旧処理を自己復旧処理部１２０にて実行する。

　また、管理装置１０２が異常イベントを検知した場合は、復旧施策４０３に登録された復旧処理の実行命令を、復旧命令部１４０より対象の端末１０１宛に送信する。尚、図４の例では、「通信Ｉ／Ｆ再起動（ＬＴＥ）」など可読性を優先した形式で復旧処理を記載しているが、復旧施策４０３への記載形式は復旧処理を識別可能な形式であれば、任意の形式であって構わない。

　例えば、復旧処理の実行に必要なコマンドを、復旧施策４０３に直接記載する形態であってもよい。また、図４の例では、各異常イベントに対して単一の復旧処理しか記載していないが、複数の復旧処理を実行する必要がある場合は、復旧施策４０３に複数の復旧処理を記載し、必要に応じて実行順序などの情報を追記しても構わない。

　待ち時間４０４は、イベントＩＤ４０１に記載の異常イベントを検知した際に、復旧施策４０３の復旧処理を講じるまでの待ち時間を示している。端末１０１がイベントＩＤ４０１に記載の異常イベントを検知した場合は、当該異常イベントの検知から待ち時間４０４に記載された時間だけ待機した後に、復旧施策４０３に記載の自己復旧処理を実行する。

　一方、管理装置１０２が異常イベントを検知した場合は、当該異常イベントの検知から待ち時間４０４に記載された時間だけ待機した後に、復旧施策４０３に記載された復旧処理の実行命令を、復旧命令部１４０より端末１０１へ送信する。

　例えば、端末１０１の再起動等の復旧処理を実行することで、他の現場装置からのデータ収集が中断される場合もあり、異常イベントの検知直後に、これらのシステム停止を招く復旧処理を実行されると不都合なケースも想定される。

　このような場合、待ち時間４０４に復旧処理を講じるまでの待ち時間を適宜設定することで、システム停止までの時間の猶予を設け、停止に向けた準備などを事前に行うことが可能となる。勿論、異常イベントの検知直後に即時復旧処理を講じる必要がある場合は、待ち時間４０４を「０分」に設定しても構わない。また、図４の例では待ち時間４０４を分単位で指定しているが、時間の単位は任意に変更して構わない。

　尚、復旧処理管理テーブル１２３ａ、１４３ａは、端末１０１と管理装置１０２の双方で管理するが、各々に登録する当該テーブルの内容は異なっていても構わない。例えば、管理装置１０２における待ち時間４０４の値を、端末１０１に設定する待ち時間よりも長く設定することなどが考えられる。

　これにより、管理装置１０２での異常イベントの検知から復旧命令送信までの時間猶予が長く設けられるため、端末１０１からの自己復旧処理に関する通知受信をより長い時間待機することが可能となり、冗長な復旧命令の発生確率を低減することができる。

　また、図４に例示したフィールド以外にも、任意のフィールドを追加しても構わない。例えば、複数の異常イベントを同時検知した場合に備えて、優先して講じるべき復旧処理を明確化するために、優先順位などのフィールドを追加してもよい。

　尚、図２の障害解析条件管理テーブル１２１ａ、１４１ａ、図３のイベント判定条件管理テーブル１２２ａ，１４２ａ、図４の復旧処理管理テーブル１２３ａ、１４３ａの登録は、システム構築段階で行う他、システム運用中の任意のタイミングで登録又は変更しても構わない。これらの登録又は変更に係る画面表示例については、図９にて後述する。

　また、図３のイベント判定条件管理テーブル１２２ａ，１４２ａと、図４の復旧処理管理テーブル１２３ａ、１４３ａを分けて例示したが、当該２つのテーブルを統合し、異常イベント毎の判定条件と復旧処理を纏めて、一つのテーブルで管理する形態であっても構わない。

　この場合、端末１０１のイベント判定条件管理部１２２と復旧処理管理部１２３、ならびに管理装置１０２のイベント判定条件管理部１４２と復旧処理管理部１４３を統合することも可能である。

　図５を参照して、端末１０１と管理装置１０２による障害解析及び復旧処理の流れについて説明する。図５では、端末１０１の自己障害解析及び自己復旧処理により、障害からの復旧を実現するケースを例示しており、以下詳細を説明する。

　図５のステップＳ５０１ａ、Ｓ５０１ｂ、Ｓ５０１ｃは、端末１０１が各種ログ情報を管理装置１０２へ送信する処理である。送信するログ情報の種別は、少なくとも図２の障害解析条件管理テーブルの参照情報２０２に記載されたログ情報を含むものとする。ただし、参照情報２０２に記載されていないログ情報を含めて送信しても構わない。

　端末１０１は、アプリケーションプログラム１１６で管理される方法に従って自端末のログ情報を取得し、一旦ログバッファ３００へ格納した後に、同じくアプリケーションプログラム１１６で管理される送信スケジュールに沿って、通信処理部１１７を介して管理装置１０２へのログ情報の送信を実行する。

　図５に例示の通り、例えば、所定のログ送信周期ΔＴの時間間隔でログ情報の送信を実行するよう、アプリケーションプログラム１１６で規定されている場合、アプリケーションプログラム１１６はステップＳ５０１ａでログ情報を送信した後、ログ送信周期ΔＴが経過したステップＳ５０１ｂで再びログ情報の送信を行う。

　ステップＳ５０２ａ、Ｓ５０２ｂ、Ｓ５０２ｃは、端末１０１の自己障害解析部１１８が、自端末のログ情報を基に自端末における異常イベントの有無を自己解析し、異常イベントが検知された場合に、講じるべき自己復旧処理と、管理装置１０２への通知内容を決定する処理である。

　ステップＳ５０２ａ、Ｓ５０２ｂ、Ｓ５０２ｃの自己障害解析処理の詳細については、図７で後述する。尚、ステップＳ５０２ａ、Ｓ５０２ｂ、Ｓ５０２ｃの自己障害解析処理の実行タイミングは、端末１０１の自己障害解析部１１８で管理するものとし、例えば図５に例示の通り、所定の自己障害解析周期Δｔ１の時間間隔で実行される。

　自己障害解析部１１８は自己障害解析処理により、異常イベントが検知されなかった場合（例：ステップＳ５０２ａ、Ｓ５０２ｂ）は自己障害解析周期Δｔ１だけ経過した後に、再び自己障害解析処理を実行する。一方、自己障害解析部１１８は、異常イベントを検知した場合（例：ステップＳ５０２ｃ）は、本ステップで管理装置１０２宛の通知内容と、実行すべき自己復旧処理を決定し、後述のステップＳ５０４、Ｓ５０５の処理を実行する。

　ステップＳ５０３ａ、Ｓ５０３ｂ、Ｓ５０３ｃは、管理装置１０２の障害解析部１３８が、端末１０１から収集したログ蓄積情報２００のログ情報を基に端末１０１における異常イベントの有無を解析し、異常イベントが検知された場合に、端末１０１へ命令すべき復旧処理を決定する処理である。

　ステップＳ５０３ａ～５０３ｃの障害解析処理の詳細についても、図７で後述する。尚、ステップＳ５０３ａ～５０３ｃの障害解析処理の実行タイミングは、管理装置１０２の障害解析部１３８で管理するものとし、例えば図５に例示の通り、障害解析周期Δｔ２の時間間隔で実行される。

　障害解析部１３８は障害解析処理により、端末１０１の異常イベントが検知されなかった場合（例：ステップＳ５０３ａ、Ｓ５０３ｂ）は障害解析周期Δｔ２だけ経過した後に、再び障害解析処理を実行し、異常イベントが検知された場合（例：ステップＳ５０３ｃ）は後述のステップＳ５０６の処理を実行する。

　尚、図５に例示の通り、ステップＳ５０１の端末１０１によるログ送信周期ΔＴ、ステップＳ５０２の端末１０１による自己障害解析周期Δｔ１、ステップＳ５０３の管理装置１０２による障害解析周期Δｔ２は、各々異なる周期を設定しても構わない。

　特に、端末１０１と管理装置１０２の間の通信帯域が狭い場合や、ログ情報の送信に通信料金が伴う場合は、ログ送信周期ΔＴを長めに設定する必要があり、付随して管理装置１０２による障害解析周期Δｔ２も長めに設定せざるを得ないケースもある。

　一方、端末１０１による自己障害解析周期Δｔ１は、通信帯域や通信料金に関わらず、短く設定することが可能である。特に、自己障害解析周期Δｔ１を短く設定することで、管理装置１０２でのみ障害解析処理を実行する形態と比較して、障害発生から検知までに要する時間を短縮することが可能となる。

　尚、図５では説明の便宜上、ステップＳ５０１ａ～Ｓ５０３ｃの各処理を定周期で実行する形態のみを例示したが、これらを指定時刻に実行する形態などであっても構わない。例えば、毎日１２時と１８時に管理装置１０２による障害解析処理を実行するなどの設定も可能であり、ステップＳ５０１ａ～Ｓ５０３ｃの実行スケジュールは任意に設定して構わない。

　ステップＳ５０４は、端末１０１の復旧通知送信部１１９が、自己復旧処理に関する通知を管理装置１０２宛に送信する処理である。当該通知は、ステップＳ５０２ｃで自己障害解析部１１８が異常イベントを検知した際に決定した通知内容であり、具体的には復旧処理管理部１２３で管理される図４の復旧処理管理テーブルにおいて、通知メッセージ４０２に記載の通知内容に該当する。

　本処理では、復旧通知送信部１１９が、当該通知内容を通信処理部１１７に通知し、当該通知内容を格納したパケットを管理装置１０２宛に送信する。一方、管理装置１０２は当該通知を受信すると、通信処理部１３７にてパケットの解析を行い、どの端末１０１が通知を送信し、どのような異常イベントを検知したのか、或いはどのような復旧処理を講じるのか、といった通知内容を復旧通知受信部１３９に通知し、当該通知内容を記録する。

　尚、ステップＳ５０４の復旧通知送信処理は、ステップＳ５０２ｃでの異常イベントの検知後に実行されるが、検知直後に復旧通知を送信する他、図４の復旧処理管理テーブルにおける待ち時間４０４の指定時間だけ、復旧通知送信部１１９で通知の送信を保留（遅延）し、後述のステップＳ５０５で自己復旧処理を実行する直前に送信する形態であっても構わない。

　ステップＳ５０５は、端末１０１の自己復旧処理部１２０が、ステップＳ５０２ｃで異常イベントを検知した際に決定した自己復旧処理を実行する処理である。具体的には復旧処理管理部１２３で管理される図４の復旧処理管理テーブル１２３ａ、１４３ａにおいて、復旧施策４０３に記載の復旧処理を実行する。

　ステップＳ５０２ｃでの異常イベントの検知から、復旧処理管理テーブル１２３ａ、１４３ａの待ち時間４０４に記載された待ち時間が経過したタイミングで、自己復旧処理部１２０は当該復旧処理を実行する。これにより、端末１０１は検知した異常イベントからの自己復旧を実現することができる。

　ステップＳ５０６は、管理装置１０２の復旧命令部１４０が、ステップＳ５０３ｃで決定した復旧処理を、異常発生元の端末１０１に対して命令する必要があるか、命令の発行の要否を判定する処理である。

　当該復旧命令処理は、ステップＳ５０３ｃでの異常イベントの検知から、復旧処理管理部１４３で管理される図４の復旧処理管理テーブルにおける待ち時間４０４で指定した時間が経過したタイミングで実行される。

　当該復旧命令処理では、復旧命令部１４０が復旧通知受信部１３９を参照し、ステップＳ５０４で述べた復旧通知を当該端末１０１から受信済みであるかを判定し、受信済みであれば後述のステップＳ５０７に進んで復旧命令をキャンセルする。

　復旧通知が未受信であれば図６で後述するステップＳ６０１の処理に進み、復旧命令部１４０は前記復旧命令の内容を通信処理部１３７に通知し、当該端末１０１に対して復旧命令を送信する。本処理の詳細については、図８で後述する。図５の例では、ステップＳ５０４にて端末１０１から復旧通知を受信済みであるため、ステップＳ５０７の処理に進む。

　ステップＳ５０７は、管理装置１０２の復旧命令部１４０が、ステップＳ５０３ｃで決定した復旧処理の実行命令をキャンセルする処理である。ステップＳ５０４により異常発生元の端末１０１から復旧通知を受信済みの場合は、管理装置１０２が命令せずとも端末１０１による自己復旧処理が実行されため、管理装置１０２から冗長に復旧命令を送信すべきではない。本ステップＳ５０７により復旧命令部１４０が復旧命令をキャンセルすることで、端末１０１において冗長な復旧処理を講じることなく、異常イベントから復旧することが可能となる。

　尚、図５では端末１０１において、ステップＳ５０４で復旧通知を送信した後に、ステップＳ５０５で自己復旧処理を実行する形態を例示したが、本順序は逆であっても構わない。ただし、自己復旧処理の実行前に、早期に管理装置１０２に対して復旧通知を送信することで、より高い確率で管理装置１０２にて冗長な復旧命令をキャンセルすることが可能となり、効率化を図ることができる。

　続いて、図６を参照して、管理装置１０２の障害解析及び復旧命令処理により、端末１０１を障害から復旧させるケースも例示する。以下、詳細を説明する。

　図６において、ステップＳ５０１ａ～Ｓ５０１ｃ、ステップＳ５０２ａ～Ｓ５０２ｃ、ステップＳ５０３ａ～Ｓ５０３ｃ、ステップＳ５０６は図５と同様であるため、説明を省略する。

　図６の例では、ステップＳ５０３ｃで障害解析部１３８が端末１０１の異常イベントを検知後、ステップＳ５０６の復旧命令要否判定処理までに、端末１０１からの復旧通知が行われていないことから、通知の未受信に伴いステップＳ６０１の処理に進む。

　ステップＳ６０１は、管理装置１０２の復旧命令部１４０が、ステップＳ５０３ｃで決定された復旧処理を、異常イベントが発生した端末１０１に対して命令する処理である。具体的には、復旧命令部１４０が当該復旧処理を通信処理部１３７に通知し、実行すべき復旧処理内容を格納したパケットを当該端末１０１宛に送信する。

　ステップＳ６０２は、ステップＳ６０１で送信された復旧命令を受信した端末１０１が、管理装置１０２から指定された復旧処理を、自己復旧処理部１２０で実行する処理である。具体的には、端末１０１が管理装置１０２から復旧命令を受信すると、通信処理部１１７でパケットの解析を行い、実行すべき復旧処理を自己復旧処理部１２０に通知して、自己復旧処理部１２０が当該復旧処理を実行する。これにより、端末１０１の異常イベントからの復旧が実現される。

　このように、端末１０１が異常イベントを自己検知しておらず、管理装置１０２が異常イベントを検知した場合、図５のステップＳ５０４で述べた端末１０１からの復旧通知の送信が行われていないことを以って、管理装置１０２は復旧命令を送信する。

　これにより、前述の古いファームウェアの継続使用など、端末１０１が自己検知困難な異常イベントに対しても、復旧及び是正処理を講じることが可能となる。

　また、端末１０１が自己検知可能な異常イベントであっても、端末１０１が自己検知する前に管理装置１０２が早期検知した場合は、図６のように管理装置１０２が復旧命令を送信することで、端末１０１のみが自己障害解析を行う形態と比較して、障害復旧を早期に実現することが可能となる。

　図７を参照して、端末１０１の自己障害解析部１１８が実行する自己障害解析処理、ならびに管理装置１０２の障害解析部１３８が実行する障害解析処理について説明する。具体的には、図５と図６のステップＳ５０２ａ～Ｓ５０２ｃ、Ｓ５０３ａ～Ｓ５０３ｃで実行する処理に該当する。

　本処理では、端末１０１や管理装置１０２が、端末１０１のログ情報を参照して異常イベントの有無を解析し、異常イベントを検知した場合は、講じるべき復旧処理まで決定する。端末１０１の自己障害解析部１１８による自己障害解析処理の場合は、管理装置１０２に通知する復旧通知の内容も本処理で決定する。

　図７は、実施例１における端末１０１による自己障害解析処理と、管理装置１０２による障害解析処理を示すフローチャートであり、以下詳細を説明する。尚、管理装置１０２は、ログ蓄積情報２００のうち未処理のログ情報について処理を行い、端末１０１は、ログバッファ３００のうち未処理のログ情報について処理を行う。

　図７のステップＳ７０１は、障害解析部１３８（自己障害解析部１１８）が図２の障害解析条件管理テーブル１２１ａ、１４１ａを参照し、端末１０１のログ情報に対して解析条件ＩＤ２０１毎に解析処理を行い、異常イベントの判定を行う処理である。

　尚、図２の例では、ＬＴＥ（無線ネットワーク）の切断、ＣＰＵ使用率の増大、パケットドロップ数の増大、ファームウェアのバージョン違い等の例を示したが、異常イベントの種類はこれらに限定されるものではない。端末１０１が扱うデータやセンサ等に応じて適宜変更することができる。

　端末１０１の自己障害解析部１１８による自己障害解析処理の場合、障害解析条件管理部１２１で管理される障害解析条件管理テーブル１２１ａを参照し、自端末のログ情報に対して解析を実行する。

　一方、管理装置１０２の障害解析部１３８による障害解析処理の場合は、障害解析条件管理部１４１で管理される障害解析条件管理テーブル１４１ａを参照し、各端末１０１から収集したログ情報に対して解析を実行する。

　障害解析条件管理テーブル１２１ａ、１４１ａに登録された全ての障害解析条件について解析処理が終了し、条件に合致する障害解析条件が存在した場合、障害解析部１３８（自己障害解析部１１８）は当該解析条件ＩＤ（図２の解析条件ＩＤ２０１）を記録する。例えば、端末１０１のログ情報にて、過去３回連続で「ＬＴＥ接続状態」が「０（切断）」であった場合は、図２のテーブル例であれば「解析条件ＩＤ：ＬｔｅＳｔａｔｅ」を記憶装置１１５、１３５に記録する。ステップＳ７０１の処理が終了すると、ステップＳ７０２に進む。

　ステップＳ７０２は、ステップＳ７０１の処理において、障害解析条件に合致した解析条件ＩＤが存在するか否かを障害解析部１３８（自己障害解析部１１８）が判定する処理である。

　前述の「解析条件ＩＤ：ＬｔｅＳｔａｔｅ」で合致した例のように、一つでも合致した解析条件ＩＤが存在する場合（ＹＥＳ）はステップＳ７０３に進む。一方、合致した解析条件ＩＤが存在しない場合（ＮＯ）は、検知すべき異常イベントが存在しないことが明らかであるため、図７の処理を終了する。

　ステップＳ７０３は、障害解析部１３８（自己障害解析部１１８）が図３のイベント判定条件管理テーブル１２２ａ、１４２ａを参照し、ステップＳ７０１で合致した解析条件ＩＤの組み合わせを基に、端末１０１での異常イベントを判定する処理である。

　端末１０１の自己障害解析部１１８による自己障害解析処理の場合、イベント判定条件管理部１２２で管理されるイベント判定条件管理テーブル１２２ａを参照して判定を実行する。

　一方、管理装置１０２の障害解析部１３８による障害解析処理の場合は、イベント判定条件管理部１４２で管理されるイベント判定条件管理テーブル１４２ａを参照して判定を実行する。

　障害解析部１３８（自己障害解析部１１８）は、該当する異常イベントが存在した場合は、当該イベントＩＤ（図３のイベントＩＤ３０１）を記憶装置１１５、１３５に記録する。

　前述の「解析条件ＩＤ：ＬｔｅＳｔａｔｅ」が合致した例であれば、図３のテーブル例の場合、「イベントＩＤ：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」に該当するため、障害解析部１３８（自己障害解析部１１８）は端末１０１における「ＬＴＥ切断」の異常イベントを検知し、当該イベントＩＤを記録する。ステップＳ７０３の処理が終了すると、ステップＳ７０４に進む。

　ステップＳ７０４は、ステップＳ７０３の処理において、障害解析部１３８（自己障害解析部１１８）が該当するイベントＩＤ３０１が存在したか否かを判定する処理である。前述の「イベントＩＤ：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」にて該当した例のように、一つでも該当したイベントＩＤ３０１が存在する場合（ＹＥＳ）はステップＳ７０５に進む。一方、該当したイベントＩＤが存在しない場合（ＮＯ）は、端末１０１における異常イベントは無しと判定し、図７の処理を終了する。

　ステップＳ７０５は、復旧命令部１４０（自己復旧処理部１２０）が図４の復旧処理管理テーブル１２３ａ、１４３ａを参照し、ステップＳ７０３で該当したイベントＩＤ３０１に対応する復旧処理（復旧施策４０３）と、当該復旧処理の実行タイミングを決定する処理である。

　図４に示す復旧処理管理テーブル１２３ａ、１４３ａにおいて、復旧命令部１４０（自己復旧処理部１２０）は復旧施策４０３と待ち時間４０４のフィールドを参照し、ステップＳ７０３で該当したイベントＩＤ３０１に対して実行すべき復旧処理と、どれだけの待ち時間４０４を挟んで当該復旧処理を実行、或いは命令すべきかを決定する。

　例えば、前述の「イベントＩＤ：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」に該当した例であれば、復旧命令部１４０（自己復旧処理部１２０）は図４の例では「５分後」に「ＬＴＥに関する通信Ｉ／Ｆ再起動」を実行し、或いは命令することを決定できる。

　端末１０１の自己障害解析部１１８による自己障害解析処理の場合、自己復旧処理部１２０は復旧処理管理部１２３で管理される復旧処理管理テーブル１２３ａを参照してステップＳ７０５の処理を実行する。さらに自己復旧処理部１２０は復旧処理管理テーブル１２３ａの通知メッセージ４０２のフィールドも参照して、管理装置１０２に対して通知すべき通知内容も含めて決定する。

　本処理で決定した通知内容は、図５のステップＳ５０４の復旧通知送信処理にて管理装置１０２へ送信され、指定の待ち時間経過後に、図５のステップＳ５０５で前記復旧処理が実行される。

　一方、管理装置１０２の障害解析部１３８による障害解析処理の場合は、復旧処理管理部１４３で管理される復旧処理管理テーブル１４３ａを参照してステップＳ７０５の処理を実行する。

　そして、障害解析部１３８は指定の待ち時間経過後に、図５と図６に記載のステップＳ５０６の復旧命令要否判定処理を経て、復旧命令が必要と判断された場合に、図６のステップＳ６０１にて前記復旧処理の実行命令が送信される。ステップＳ７０５の処理が終了すると、図７の処理を終了する。

　以上の図７の処理を行うことで、端末１０１と管理装置１０２は、端末１０１における異常イベントの有無を解析することに加え、異常イベントの検知時には講じるべき復旧処理と、当該復旧処理の実行タイミングまで決定することが可能となる。

　図８を参照して、管理装置１０２の復旧命令部１４０が実行する復旧命令要否判定処理について説明する。具体的には、図５と図６のステップＳ５０６で実行する処理に該当する。

　本処理では、管理装置１０２が図７の障害解析処理で決定した復旧処理に関する命令の送信の要否を、端末１０１からの復旧通知の有無に応じて判定する。図８は、実施例１における管理装置１０２による復旧命令要否判定処理を示すフローチャートであり、以下詳細を説明する。

　ステップＳ８０１は、管理装置１０２の復旧命令部１４０が、復旧通知受信部１３９を参照して、復旧命令対象の端末１０１からの復旧通知を受信済みであるか否かを判定する処理である。

　具体的には、復旧命令部１４０が、図７の障害解析処理で検知した異常イベントが発生した端末１０１から復旧通知を受信しているか否かを判定し、さらに当該通知が図７の障害解析処理で検知した異常イベント、或いは図７の障害解析処理で決定した復旧処理に関するものであれば受信済みと判定する。

　例えば、図７で前述した例のように、障害解析部１３８の障害解析処理により、端末１０１について「イベントＩＤ：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」の異常イベントを検知し、復旧処理として「ＬＴＥに関する通信Ｉ／Ｆ再起動」を講じるべきであることを決定したとする。

　この場合、ステップＳ８０１では復旧命令部１４０が復旧通知受信部１３９を参照した結果、当該端末１０１より「ＬＴＥ切断」を自己検知した旨の復旧通知、或いは「ＬＴＥに関する通信Ｉ／Ｆ再起動」を自己復旧処理として実行する旨の復旧通知を受信していれば、受信済みと判定する。

　例えば、端末１０１が自己検知した異常イベントは異なるが、当該異常イベントに対して「ＬＴＥに関する通信Ｉ／Ｆ再起動」を講じる旨の復旧通知を受信したのであれば、検知された異常イベントは異なっていても所望の復旧処理が端末１０１で実行されるため、復旧命令部１４０は冗長な復旧処理回避のために復旧命令は控えるべきであることが判断できる。管理装置１０２は対象の端末１０１から当該復旧通知を受信済みの場合（ＹＥＳ）はステップＳ８０２に進み、未受信の場合（ＮＯ）はステップＳ８０３に進む。

　ステップＳ８０２は、復旧命令部１４０が図７の障害解析処理で決定した復旧処理の実行命令は不要と判断し、復旧命令をキャンセルする処理である。具体的には、図５のステップＳ５０７で説明した復旧命令をキャンセルする処理に遷移する。

　ステップＳ８０１にて、対象の端末１０１からの復旧通知を受信済みであることが判定できたことを以って、復旧命令をキャンセルすることで、端末１０１における冗長な復旧処理の実行を回避することができる。ステップＳ８０２の処理が終了すると、図８の処理を終了する。

　ステップＳ８０３は、復旧命令部１４０が図７の障害解析処理で決定した復旧処理の実行命令は必要と判断し、復旧命令を対象の端末１０１に対して送信する処理である。具体的には、図６のステップＳ６０１で説明した復旧命令の送信処理に遷移する。

　ステップＳ８０１にて、対象の端末１０１から復旧通知を未受信であることが判定された場合、当該端末１０１は異常イベントを自己検知できていない状態であるため、管理装置１０２からの復旧命令により復旧処理を講じることが可能となる。ステップＳ８０３の処理が終了すると、図８の処理を終了する。

　以上の図８の復旧命令要否判定処理により、管理装置１０２の復旧命令部１４０は、図７の障害解析処理で決定した復旧処理の命令が必要であるかを判定することができる。また、復旧命令の対象となる端末１０１からの復旧通知の受信の判定を以って命令不要と判断された場合に、当該復旧命令をキャンセルすることで、端末１０１における冗長な復旧処理の実行を抑止することが可能となる。

　図９を参照して、図２の障害解析条件管理テーブル１２１ａ、１４１ａ、図３のイベント判定条件管理テーブル１２２ａ、１４２ａ、図４の復旧処理管理テーブル１２３ａ、１４３ａを登録するための画面の表示例を説明する。

　図９において、端末１０１の出力部１１４、及び管理装置１０２の出力部１３４は表示画面９００を表示可能であり、表示画面９００には障害解析条件を設定するための表示エリア９０１と、イベント判定条件を設定するための表示エリア９０２と、復旧処理を設定するための表示エリア９０３が設けられている。

　表示エリア９０１は、端末１０１や管理装置１０２の障害解析条件管理部１２１、１４１で管理する、図２の障害解析条件管理テーブル１２１ａ、１４１ａを設定するための領域である。

　表示エリア９０１では、入力部１１３、１３３から障害解析条件毎に参照情報や閾値等の各種情報を入力すると、当該入力値が障害解析条件管理テーブル１２１ａ、１４１ａに設定される。尚、通信システムの運用過程で、障害解析条件が随時追加されるケースも考えられる。そこで、図９の例では、障害解析条件の入力欄（行）を追加するための追加ボタン９０４を搭載しており、当該ボタンの押下（又はクリック）により、障害解析条件を任意に追加することを可能にしている。

　表示エリア９０２は、端末１０１や管理装置１０２のイベント判定条件管理部１２２、１４２で管理する、図３のイベント判定条件管理テーブル１２２ａ、１４２ａを設定するための領域である。

　表示エリア９０２では、入力部１１３、１３３から異常イベント毎に合致すべき障害解析条件を入力すると、当該入力値がイベント判定条件管理テーブル１２２ａ、１４２ａに設定される。検知すべき異常イベント種別や、合致判定に必要な障害解析条件の数も、システムの運用過程で随時追加されるケースも考えられるため、同じく追加ボタン９０４を搭載している。

　表示エリア９０３は、端末１０１や管理装置１０２の復旧処理管理部１２３、１４３で管理する、図４の復旧処理管理テーブル１２３ａ、１４３ａを設定するための領域である。

　表示エリア９０３では、入力部１１３、１３３から異常イベント毎に講じるべき復旧処理や、復旧処理実行までの待ち時間等を入力すると、当該入力値が復旧処理管理テーブルに設定される。前記同様の理由で、表示エリア９０３にも追加ボタン９０４を搭載している。

　また、各種テーブル情報を、図９の表示画面９００上で管理するだけでなく、別の外部ファイル等でも管理する形態が考えられる。そこで、図９の画面表示例では、ファイル入力ボタン９０５と、ファイル出力ボタン９０６を設けている。

　入力部１１３、１３３からファイル入力ボタン９０５を押下することで、別の外部ファイルに保存された各種テーブル値を図９の表示画面９００上に読み込む機能が提供され、ファイル出力ボタン９０６を押下することで図９の表示画面９００上で入力されたテーブル値を外部ファイルに出力する機能が提供される。

　これにより、テーブルの値が格納される外部ファイルとの連携を容易に実現することが可能となる。ただし、当該機能の搭載は任意である。図９のように各種テーブル情報の設定画面を表示することで、各種テーブル値の登録や途中変更等を容易にすることが可能となる。尚、図９の画面表示例では、テーブルの値をプルダウン形式で選択又は設定する形態や、直接入力する形態などを例示しているが、設定を受け付ける表示形式は任意とする。

　また、端末１０１と管理装置１０２の各々で図９の画面表示を行う他、例えば管理装置１０２の出力部１３４にて、端末１０１の各種テーブル情報を設定するための画面表示も行い、ファイル出力ボタン９０６を押下して出力された外部ファイルを端末１０１に送信することで、端末１０１の各種テーブル値を登録する形態も考えられる。このように、必ずしも端末１０１と管理装置１０２の双方に入力部と出力部を含むことは必須ではない。

　図１０を参照して、図７の端末１０１による自己障害解析処理、又は管理装置１０２による障害解析処理によって検知された異常イベント、及び決定された復旧処理を出力する画面表示例を説明する。

　図１０において、端末１０１の出力部１１４、及び管理装置１０２の出力部１３４は表示画面１０００を表示可能であり、表示画面１０００には障害検知及び復旧情報を表示する表示エリア１００１が設定されている。

　表示エリア１００１には、端末１０１の自己障害解析部１１８や、管理装置１０２の障害解析部１３８によって解析された検知異常イベント情報や、当該異常イベントに対する復旧処理情報が表示される。

　図１０の例では、障害の発生元となる端末１０１の識別子情報、及び検知された異常イベント情報、当該異常イベントの検知時刻、当該異常イベントの検知元情報、当該異常イベントに対して講じる復旧処理を表示しているが、必要に応じて任意の情報を出力しても構わない。例えば、図４の復旧処理管理テーブル１２３ａ、１４３ａにおける待ち時間４０４から決定される、復旧処理の実行予定時刻などを追加してもよい。

　図１０のような画面を表示することで、システム管理者や作業者は、どの端末１０１で異常イベントが検知され、どのような復旧処理が実行されるのかを容易に判断することができる。

　特に、端末１０１の再起動など、通信システムの稼働中断を伴う可能性のある復旧処理が実行される場合、当該表示画面１０００を参照することで、システム停止に備えた事前準備を講じるなどの対応要否も判断することが可能となる。

　尚、図１０のような表示画面１０００以外にも、例えば表形式ではなく、テキスト形式で出力する画面表示等でもよく、障害検知及び復旧に関する情報の表示形式は特定の方法に限定されるものではない。

　以上のように、本実施例によれば、端末１０１の自己解析及び復旧により早期の障害検知や、通信切断状態からの自己復旧を実現することに加え、管理装置１０２による解析及び復旧命令で、端末１０１では自己検知できない異常イベントも検知し、復旧させることが可能となる。

　また、端末１０１が自己復旧処理を講じる際に、管理装置１０２に対して復旧通知を送信することで、管理装置１０２による冗長な復旧命令を抑止することも可能となり、端末１０１の障害復旧を効率的に実現することができる。これらの処理は自動で行われるため、障害発生時の復旧作業に要する工数を削減する他、早期障害復旧の実現により、ひいては通信システムの稼働率向上にも寄与することができる。

　前記実施例１では、管理装置１０２が障害解析部１３８で障害解析処理を行う際、図２の障害解析条件管理テーブル１２１ａ、１４１ａを参照し、各端末１０１のログ情報に対して障害解析条件に合致するか否かを判定した。

　一方、図１のように管理装置１０２に複数の端末１０１が接続される構成の場合、複数の端末１０１が同時に同一の障害解析条件に合致したことを以って、異常イベントをより詳細に検知できるケースがある。

　例えば、図２の例のように端末１０１のＬＴＥ切断状態が「０（切断）」であることを判定する障害解析条件が存在したときに、複数（２以上）の端末１０１が同時に当該解析条件に合致した場合、端末１０１のハードウェアの異常等によるＬＴＥ切断よりも、ＬＴＥ通信網（モバイルネットワーク）を提供するキャリアの設備（基地局など）の障害発生により、複数の端末１０１が同時に切断された可能性が疑われる。この場合は、端末１０１の障害ではなく、外部環境の障害となる。

　このように、複数の端末１０１が同時に障害解析条件に合致したことも検知基準に加えて判定を行うことで、より幅広い異常を検知することが可能となる。また、前述の例のように端末１０１に起因した障害ではなく、外部環境に起因した障害の場合、端末１０１の自己復旧処理だけでは異常状態から復旧することは困難である。

　例えば、前述のキャリア障害の例においても、キャリアの設備の障害が解決するまでは、端末１０１が自己復旧を試みてもＬＴＥ網に再接続することが困難であることは自明である。

　そのため、キャリアでの障害が解決するまでは、端末１０１ではＬＴＥ切断を自己検知しても、自己復旧処理を控えることが望ましい。特に、端末１０１による自己復旧処理には、端末本体の再起動など、通信システムの稼働の中断を伴う可能性がある処理も含まれるため、当該ケースにおいては無駄な自己復旧処理を講じないよう、一時的に端末１０１による当該復旧処理を無効化することが望ましい。

　そこで、実施例２では、管理装置１０２において、複数の端末１０１が同時に同一の障害解析条件に合致したことも異常イベントの検知基準として加え、さらに当該異常イベントの種別に応じた端末１０１の自己復旧処理の有効化又は無効化も可能にした形態について説明する。

　実施例２において、図１１Ａ～図１１Ｄを用いて管理装置１０２の障害解析条件管理部１４１、イベント判定条件管理部１４２、復旧処理管理部１４３、ならびに端末１０１の復旧処理管理部１２３で管理する各種テーブルの構成を説明する。尚、実施例２に係る各種構成や処理等について、図１１Ａ～図１１Ｄに示すテーブルの構成以外は前記実施例１と同様であるため、これらの説明は省略する。

　図１１Ａは、実施例２における、管理装置１０２の障害解析条件管理部１４１で管理する障害解析条件管理テーブル１４１ａの構成図を示している。解析条件ＩＤ２０１、参照情報２０２、比較方法３０３、比較条件２０４、閾値２０５、合致回数２０６は、図２の実施例１における障害解析条件管理テーブル１４１ａと同様であるが、実施例２では同時検知台数１１０１のフィールドを新たに追加している。

　同時検知台数１１０１は、管理装置１０２が各端末１０１から収集したログ情報に対して解析を行った結果、本解析条件を満たす端末１０１が何台以上存在した場合に、条件合致と見なすのかを示している。

　参照情報２０２、比較方法２０３、比較条件２０４、閾値２０５、合致回数２０６に記載の解析条件を満たした端末１０１の台数が、同時検知台数１１０１のフィールドに記載の値以上であれば、管理装置１０２の障害解析部１３８は本障害解析条件の合致を判定する。

　図１１Ａの例の場合、「ＬＴＥ接続状態」が「０（切断）」に該当する端末１０１が５台以上存在した場合に、管理装置１０２は図７の障害解析処理（ステップＳ７０１）で「解析条件ＩＤ：Ｍｕｌｔｉ－ＬｔｅＳｔａｔｅ」に対して合致の判定を下す。尚、端末１０１は自端末のログ情報に対してのみ自己障害解析処理を行うため、端末１０１で管理する障害解析条件管理テーブル１２１ａには、同時検知台数１１０１のフィールドは追加不要である。

　図１１Ｂは、実施例２における、管理装置１０２のイベント判定条件管理部１４２で管理するイベント判定条件管理テーブル１４２ａの構成図を示している。イベント判定条件管理テーブル１４２ａは、図３の実施例１におけるイベント判定条件管理テーブル１４２ａと同様である。図１１Ｂの例の場合、図１１Ａの「解析条件ＩＤ：Ｍｕｌｔｉ－ＬｔｅＳｔａｔｅ」の合致を基に、管理装置１０２は図７の障害解析処理（ステップＳ７０３）で「イベントＩＤ：ＮｗＦａｉｌｕｒｅ（キャリア障害）」を検知することが可能となる。

　図１１Ｃ、図１１Ｄは、実施例２における、管理装置１０２の復旧処理管理部１４３で管理する復旧処理管理テーブル１４３ａと、端末１０１の復旧処理管理部１２３で管理する復旧処理管理テーブル１２３ａの構成図を示している。

　図１１Ｃ、図１１ＤのイベントＩＤ４０１、通知メッセージ４０２、復旧施策４０３、待ち時間４０４は、図４の実施例１における復旧処理管理テーブル１２３ａ、１４３ａと同様であるが、実施例２における復旧処理管理テーブル１２３ａ、１４３ａでは、有効／無効１１０２のフィールドを新たに追加している。

　図１１Ｃ、図１１Ｄの有効／無効１１０２は、イベントＩＤ４０１に記載の異常イベントを検知した際の復旧処理の実行を有効とするか、無効とするかを指定するフィールドである。本フィールドに「無効」が指定されている場合は、イベントＩＤ４０１に記載の異常イベントを検知しても復旧施策４０３に記載の処理は実行しない。

　図１１Ｃの例の場合、管理装置１０２は「イベントＩＤ：ＮｗＦａｉｌｕｒｅ（キャリア障害）」を検知すると、「解析条件ＩＤ：Ｍｕｌｔｉ－ＬｔｅＳｔａｔｅ」に合致した端末１０１に対して、図７の障害解析処理（ステップＳ７０５）にて、「ＬＴＥ切断」を自己検知した際の復旧処理の無効化を決定する。

　その後、管理装置１０２は、図６に記載の流れと同様、図８の復旧命令要否判定処理を行った後に、当該無効化の旨を復旧命令として、ＬＴＥ以外の通信Ｉ／Ｆを介して対象の端末へ送信する。そして、本復旧命令を受信した端末１０１は、当該命令に従い、図１１Ｄに例示の通り、「イベントＩＤ：ＬｔｅＤｉｓｃｏｎｎ（ＬＴＥ切断）」に対応する有効／無効１１０２のフィールドを「無効」に変更する。

　これにより、当該端末１０１は、「ＬＴＥ切断」を検知しても自己復旧処理を実行しないため、キャリア障害の発生中に不必要な自己復旧処理を講じずに済むこととなる。

　尚、無効化した復旧処理を再度有効化するタイミングは任意に設定して構わない。例えば、前述の例であれば、キャリア障害が解決されたタイミングで、無効化した復旧処理を再度有効化するよう管理装置１０２から命令する他、無効化を命令された端末１０１が一定時間経過後に自動で再度有効化する形態などであっても構わない。

　以上のように、本実施例によれば、管理装置１０２の障害解析処理において、複数の端末１０１が同時に同一の障害解析条件に合致したことも異常イベントの検知基準として採用することで、単一の端末１０１のログ情報だけでは検知できない異常イベントも検知可能となる。

　また、検知した異常イベントに応じて、端末１０１による自己復旧処理の有効化／無効化を行うことで、端末１０１だけでは明らかに自己復旧できないケースにおいて、不必要な自己復旧処理の実行を抑止することが可能となる。

　前記実施例１では、端末１０１による異常検知の直後に、自己復旧処理を講じると不都合が生じるケースを考慮し、図４の復旧処理管理テーブル１２３ａ、１４３ａにて、待ち時間４０４のフィールドを設ける形態を説明した。

　一方、異常イベントが発生した状況に応じて、異常検知から自己復旧処理実行までの待ち時間を柔軟に変更すべきケースも考えられる。この場合、新たなアプローチとして、端末１０１が自己復旧処理に関する復旧通知を管理装置１０２へ送信した後、管理装置１０２からの復旧命令（許可）を受信するまで、当該復旧処理の実行を待機する形態も考えられる。

　管理装置１０２が復旧処理の実行を許可するタイミングで復旧命令を端末１０１に指令することで、任意の待ち時間を設けることが可能となる。例えば、管理装置１０２が通信システムの運用計画に関する情報を保持しており、現場装置のファームウェア更新等で通信切断を招いてはならない時間帯を把握している場合、当該時間帯に端末１０１から復旧通知を受信しても、すぐに復旧命令を送信せず、当該時間帯の終了まで復旧命令を保留することで、自己復旧処理（端末１０１の再起動等）による一時的な通信切断を回避することができる。

　また、端末１０１が異常を検知したものの、実際はそれが計画的なシステム停止等による故意の異常イベントであり、自己復旧処理が不要であるケースも想定される。例えば、端末１０１と他の現場装置が有線通信で接続されており、通信システムの計画停止によって現場装置の電源が切られたことで、端末１０１が有線通信の切断を自己検知したとする。

　本ケースは計画停止による人為的なものであるため、切断に対する自己復旧処理が不要であることは自明である。本ケースにおいても上記と同様に、管理装置１０２が通信システムの運用計画情報を保持し、システム稼働停止の時間帯を把握している場合は、当該時間帯に端末１０１から復旧通知を受信しても、復旧命令の送信を控えることにより、不必要な自己復旧処理を抑止することが可能となる。

　そこで、実施例３では、端末１０１が自己復旧処理に関する復旧通知を管理装置１０２へ送信した後、管理装置１０２から復旧命令を得るまで、当該復旧処理の実行を待機する形態について説明する。

　前記実施例１では、図５に例示の通り、端末１０１は復旧通知を管理装置１０２へ送信した後に自己復旧処理を実行していたが、本実施例では管理装置１０２から復旧命令を受信するまで、復旧処理の実行を保留する。

　また、管理装置１０２は、前記実施例１では端末１０１から復旧通知を受信すると、復旧通知受信部１３９にて通知内容を記録するだけであったが、実施例３では端末１０１による自己復旧処理について実行の許可判定も行う。そして、管理装置１０２は実行可能と判断された場合にのみ、適切なタイミングで復旧命令を当該端末１０１に返信する形態とする。尚、管理装置１０２が送信する復旧命令は、端末１０１が送信した復旧通知に対する返信とする。

　実施例３における、端末１０１と管理装置１０２による障害解析と復旧の流れを図１２で説明する。また、管理装置１０２が保持するシステム運用計画情報１３００の例を図１３で説明する。また、管理装置１０２が端末１０１から復旧通知を受信した際に実行する、復旧命令許可判定処理について図１４を用いて説明する。尚、実施例３に係る各種構成及び処理等について、図１２～図１４に示す処理以外は、前記実施例１又は実施例２と同様であるため、重複する構成の説明は省略する。

　図１２を参照して、実施例３における端末１０１と管理装置１０２による障害解析と復旧処理の流れについて説明する。図１２のステップＳ５０１、Ｓ５０２、Ｓ５０４、Ｓ６０２は図５や図６と同様であり、実施例１又は実施例２と同様であるため、これらの説明は省略する。

　端末１０１は、ステップＳ５０４で復旧通知を送信すると、図１２に記載の通り、管理装置１０２から復旧命令を受信するまで復旧処理の実行を保留する。一方、ステップＳ５０４で端末１０１が送信した復旧通知を管理装置１０２が受信すると、実施例３では、通信処理部１３７での解析を経て、通知内容を復旧通知受信部１３９に出力することに加え、復旧命令部１４０にも通知内容を出力して、ステップＳ１２０１の処理に進む。

　ステップＳ１２０１は、ステップＳ５０４で端末１０１が送信した復旧通知を基に、通知された異常イベントに対する自己復旧処理の実行を、当該端末１０１に許可してもよいかを管理装置１０２の復旧命令部１４０で判定する処理である。

　具体的には、管理装置１０２が保持するシステム運用計画情報１３００（図１３で後述）を参照して、端末１０１が検知した異常イベントが通信システムの計画停止によるものか否かを判定し、該当する場合は自己復旧処理が不要のため、復旧命令の送信をキャンセルする。

　一方、端末１０１が検知した異常イベントが通信システムの計画停止には該当せず、予期せぬ異常状態であれば、管理装置１０２は、通信システムの運用計画上、適切なタイミングでステップＳ１２０２の復旧命令送信処理に遷移する。尚、ステップＳ１２０１の詳細な処理については、図１４で後述する。

　ステップＳ１２０２は、管理装置１０２の復旧命令部１４０より、対象の端末１０１に対して復旧命令を送信する処理である。実施例１又は実施例２における、図６の復旧命令送信処理（Ｓ６０１）では、障害解析処理（Ｓ５０３）で決定した復旧処理の実行命令を送信する形態であったが、ステップＳ１２０２の復旧命令送信処理では、ステップＳ５０４の復旧通知に記された自己復旧処理に対する実行命令を送信する。

　ただし、端末１０１が送信した復旧通知に、端末１０１が自己検知した異常イベントの情報しか記されていない場合は、復旧処理管理部１４３で管理される復旧処理管理テーブルを参照し、当該異常イベントに対応した復旧処理の実行命令を送信する。

　そして、当該復旧命令を端末１０１が受信すると、ステップＳ６０２で端末１０１は自己復旧処理部１２０にて、指定された復旧処理を実行する。

　このように、端末１０１による自己復旧処理実行について、管理装置１０２が許可の判定を行い、復旧命令の送信キャンセルや送信タイミングを制御することで、通信システムの運用計画上、不都合なタイミングでの復旧処理の実行や、不必要な復旧処理の実行を回避することが可能となる。

　図１３を参照して、管理装置１０２が保持するシステム運用計画情報１３００の例を説明する。当該システム運用計画情報１３００は、管理装置１０２のアプリケーションプログラム１３６で管理され、前述の通り、管理装置１０２が復旧通知を受信した際に、端末１０１での自己復旧処理の実行の許可判定に使用する。尚、システム運用計画情報１３００は管理装置１０２の記憶装置１３５に格納される。

　図１３の運用計画１３０１は、通信システムの運用計画情報を示すものである。本フィールドの記載形式は任意であり、図１３に例示の通り、現場装置（端末１０１）のファームウェア更新により通信切断を回避すべき場合や、通信切断を伴う恐れのある復旧処理禁止（端末本体、通信Ｉ／Ｆ再起動等）を併記するなどしても構わない。

　図１３において、関連端末１３０２は、運用計画１３０１に記載の運用計画の対象となる端末１０１の識別子を記載するフィールドである。図１３では、端末１０１の識別子を図１の添字部分で例示しているが、当該識別子は端末１０１の製造番号や、通信Ｉ／Ｆに割り当てられたＩＰアドレス（又はＭＡＣアドレス）など任意の形式であって構わない。

　管理装置１０２は、端末１０１から復旧通知を受信して自己復旧処理を許可するか否かの判定を行う際、関連端末１３０２を参照することで、当該端末１０１の復旧処理において、どの運用計画を考慮すべきかを識別することが可能となる。

　対象日時１３０３は、運用計画１３０１に記載の運用計画を実行する日時情報を示している。管理装置１０２は、本フィールドを参照することで、例えば「２０２１／９／２２　０２：００：００～０３：００：００」の間は通信システムが計画停止しており、当該時間帯に端末１０１－ａ、端末１０１－ｂが検知した異常イベントは計画の上で招かれたものであり、管理装置１０２は自己復旧が不要であることを判断できる。

　尚、図１３では、システム運用計画情報１３００として、運用計画１３０１、関連端末１３０２、対象日時１３０３のフィールドにて例示したが、管理装置１０２が保持するシステム運用計画情報は特定の形式に限定されるものではない。例えば、各種運用計画が特定の曜日、特定の時間帯で周期的に適用される場合は、対象日時１３０３のフィールドを変更して、曜日や時間帯を記載する形式にする他、新たな入力フィールドを任意に追加しても構わない。

　図１４を参照して、管理装置１０２の復旧命令部１４０が実行する復旧命令の許可判定処理について説明する。具体的には、図１２のステップＳ１２０１で実行する処理に該当する。本処理は、管理装置１０２が端末１０１から復旧通知を受信した際に実行され、システム運用計画情報１３００を基に、当該端末１０１による自己復旧処理の実行を許可してもよいかを判定する。

　図１４は、実施例３における管理装置１０２による復旧命令許可判定処理の一例を示すフローチャートであり、以下詳細を説明する。

　ステップＳ１４０１は、復旧通知の送信元の端末１０１で検知された異常イベントが、通信システムの計画停止によって招かれたものであるかを管理装置１０２で判定する処理である。具体的には、管理装置１０２の復旧命令部１４０が、アプリケーションプログラム１３６で管理される図１３のシステム運用計画情報１３００を参照し、復旧通知の送信元の端末１０１が属する通信システムが計画停止中であるかを判定する。

　例えば、図１３の例では、端末１０１－ａからの復旧通知を「２０２１／９／２２　０２：３０：００」に受信した場合、復旧命令部１４０は計画停止によって発生したイベントであることが判断できる。

　復旧命令部１４０は計画停止によって招かれたものであることが判断できる場合（ＹＥＳ）はステップＳ１４０２に進み、計画停止の時間外に発生した想定外の異常イベントである場合（ＮＯ）はステップＳ１４０３に進む。

　ステップＳ１４０２は、管理装置１０２の復旧命令部１４０が復旧命令は不要と判断し、前記復旧通知に対する復旧命令をキャンセルする処理である。ステップＳ１４０１で、復旧命令部１４０は計画停止によって招かれた異常イベントであることが判断できた場合、端末１０１による自己復旧処理は不要であるため、本処理による復旧命令のキャンセルで、不必要な自己復旧処理の実行を抑止することができる。

　尚、図１４の例では復旧命令部１４０が復旧命令をキャンセルするのみとしているが、例えば端末１０１に対して、自己復旧処理が不要の旨を明示的に通知する処理を行っても構わない。ステップＳ１４０２の処理が終了すると、図１４の処理を終了する。

　ステップＳ１４０３は、復旧命令部１４０が復旧通知の送信元の端末１０１において復旧処理を即時実行しても問題無いかを判定する処理である。具体的には、管理装置１０２の復旧命令部１４０が、アプリケーションプログラム１３６で管理される図１３のシステム運用計画情報１３００を参照し、当該端末１０１が実行しようとしている復旧処理を禁じられていないかを判定する。

　例えば、「端末本体の再起動」を自己復旧処理とする旨の復旧通知を端末１０１－ａより「２０２１／９／２０　００：１５：００」に受信した場合、図１３の例では「現場装置のファームウェア更新」のため「２０２１／９／２０　００：３０：００」まで前記復旧処理の実行を禁止されており、少なくとも１５分間は実行を保留すべきであることが判断できる。

　端末１０１において復旧処理を即時実行可能であることが判断できる場合（ＹＥＳ）はステップＳ１４０４に進み、前述の例のように実行保留が必要な場合（ＮＯ）はステップＳ１４０５に進む。

　ステップＳ１４０４は、復旧命令部１４０は復旧通知の送信元の端末１０１による復旧処理の即時実行を許可してよいものと判断し、復旧命令を当該端末１０１に対して送信する処理である。

　具体的には、復旧命令部１４０は図１２のステップＳ１２０２で説明した復旧命令の送信処理に即時遷移し、端末１０１への復旧命令を行う。ステップＳ１４０４の処理が終了すると、図１４の処理を終了する。

　ステップＳ１４０５は、復旧命令部１４０が復旧通知の送信元の端末１０１による復旧処理の実行を保留する処理が必要と判断し、通信システムの運用計画上、復旧処理実行可能となったタイミングで復旧命令を当該端末１０１に対して送信する処理である。

　具体的には、復旧命令部１４０は図１３のシステム運用計画情報１３００を参照し、端末１０１による復旧処理を実行可能となったタイミングで、図１２のステップＳ１２０２で説明した復旧命令の送信処理に遷移し、端末１０１への復旧命令を行う。

　ステップＳ１４０３で示した例の場合、復旧通知受信から少なくとも１５分間の待機が必要であるため、復旧命令部１４０は１５分経過後に復旧命令の送信処理を行う。

　ステップＳ１４０５による復旧命令送信の保留により、通信システムの運用計画上、適切なタイミングで端末１０１は自己復旧処理を講じることが可能となる。尚、図１４のステップＳ１４０５では、復旧処理が実行可能となるまで復旧命令の送信を保留する形態にて例示したが、例えば、復旧処理の実行タイミングを格納した復旧命令を復旧命令部１４０が端末１０１に対して即時送信し、当該命令を受信した端末１０１が、指定されたタイミングまで自己復旧処理実行を保留する形態であっても構わない。

　以上のように、本実施例により、端末１０１による自己復旧処理の実行の可否を管理装置１０２が決定することで、通信システムの人為的な計画停止によって招かれた異常イベントに対する不必要な自己復旧処理を抑止することに加え、通信システムの運用計画に対して、より適切なタイミングで復旧処理を実行することが可能となる。

　特に、自己復旧処理によって通信システムの稼働を妨げることは本末転倒であり、運用計画に即したタイミングで復旧処理を実行することで、さらなる通信システムの稼働率向上に寄与することが可能となる。

　＜結び＞
　以上のように、上記実施例１～３の通信システムは、以下のような構成とすることができる。

　（１）管理対象となる１以上の端末（１０１）と、前記端末（１０１）と接続される管理装置（１０２）からなる通信システムであって、前記端末（１０１）は、自端末（１０１）のログ情報を収集して、前記管理装置（１０２）へ送信するログ情報管理部（アプリケーションプログラム１１６）と、前記ログ情報から当該端末（１０１）における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する自己障害解析部（１１８）と、前記異常イベントに対する自己復旧処理を前記管理装置（１０２）に通知する復旧通知送信部（１１９）と、前記異常イベントに対する自己復旧処理又は前記管理装置（１０２）から命令された復旧処理を実行する自己復旧処理部（１２０）と、を有し、前記管理装置（１０２）は、前記端末（１０１）から収集したログ情報を基に、前記端末（１０１）における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する障害解析部（１３８）と、前記端末（１０１）から当該端末（１０１）が検知した異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部（１３９）と、前記通知の有無に応じて前記障害解析部（１３８）で検知した異常イベントに対する復旧処理の実行命令を前記端末（１０１）に指令する復旧命令部（１４０）と、を有すること特徴とする通信システム。

　上記構成により、端末１０１で発生した異常イベントを、端末１０１のログ情報を基に端末と管理装置１０２の双方で解析することで、端末１０１の自己解析及び復旧により障害の早期検知や、通信切断状態からの自己復旧を実現することに加え、管理装置１０２による解析及び復旧命令で、端末１０１では自己検知できない異常イベントも検知して端末１０１を復旧させることが可能となる。

　一方、単に端末１０１と管理装置１０２の双方で異常イベントを解析し、復旧処理を講じるだけでは、端末１０１が復旧処理を冗長に実行する恐れがある。例えば、端末１０１と管理装置１０２がほぼ同時刻に、端末１０１上の異常イベントを検知したとする。このとき、端末１０１は検知した異常イベントに対する自己復旧処理を講じるが、管理装置１０２は自己復旧済みであることを知らずに、当該端末１０１に対して復旧処理の実行命令を指令してしまう。これにより、端末１０１は再度冗長な復旧処理を実行することになり、再起動による復旧などの場合、端末１０１の連続稼働を妨げてしまう。しかし、本発明によれば、端末１０１が自己復旧処理の実行時に、当該復旧処理に関する通知を管理装置１０２へ明示的に送信することで、管理装置１０２は復旧命令が不要の旨を判定し、復旧処理の冗長な実行を回避することが可能となる。

　（２）プロセッサ（ＣＰＵ１３２）とメモリ（記憶装置１３５）を有して、管理対象となる１以上の端末（１０１）と接続される管理装置（１０２）であって、前記端末（１０１）から収集したログ情報を基に、前記端末（１０１）における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する障害解析部（１３８）と、前記端末（１０１）から、当該端末（１０１）で検知した異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部（１３９）と、前記通知の有無に応じて前記障害解析部（１３８）で検知した異常イベントに対する復旧処理の実行命令を前記端末（１０１）に指令する復旧命令部（１４０）と、を有すること特徴とする管理装置（１０２）。

　（３）上記（２）に記載の管理装置（１０２）であって、前記ログ情報に対する障害解析条件を管理する障害解析条件管理部（１４１）と、前記ログ情報と合致した前記障害解析条件の組み合わせに基づくイベント判定条件を管理するイベント判定条件管理部（１４２）と、前記異常イベント毎に講じるべき復旧処理を管理する復旧処理管理部（１４３）と、をさらに有し、前記障害解析部（１３８）は、前記障害解析条件管理部（１４１）の障害解析条件に従って前記ログ情報を解析して、解析結果と、前記イベント判定条件管理部（１４２）のイベント判定条件を基に前記端末（１０１）の異常イベントを検知した後、前記復旧処理管理部（１４３）を参照して前記異常イベントに対する復旧処理を決定し、前記復旧命令部（１４０）は、前記復旧通知受信部（１３９）にて前記端末（１０１）から前記異常イベントに対する自己復旧処理の通知が受信されない場合に、前記復旧処理の実行命令を前記端末（１０１）に指令することを特徴とする管理装置（１０２）。

　上記構成により、管理装置１０２は端末１０１からのログ情報で異常イベントを検知し、端末１０１から当該復旧処理に関する通知を受信していなければ復旧処理の実行命令を端末１０１に指令することで、端末１０１では自己検知できない異常イベントも検知して端末１０１を復旧させることが可能となる。

　（４）請求項３に記載の管理装置（１０２）であって、前記障害解析条件管理部（１４１）は、前記障害解析条件毎に参照するログ情報（参照情報２０２）と、比較基準となる閾値（２０５）と、前記閾値（２０５）に対する大小関係を規定する比較条件（２０４）と、前記閾値（２０５）を絶対値と相対値の何れで扱うかを規定する比較方法（２０３）と、ログ情報が前記障害解析条件に合致した回数（合致回数２０６）を指定可能とすることを特徴とする管理装置。

　上記構成により、管理装置１０２の障害解析条件管理部１４１は、障害解析条件管理テーブル１４１ａで、障害解析条件毎に参照するログ情報（参照情報２０２）と、比較基準となる閾値２０５と、閾値２０５に対する大小関係を規定する比較条件２０４と、閾値２０５を絶対値と相対値の何れで扱うかを規定する比較方法２０３と、ログ情報が前記障害解析条件に合致した合致回数２０６を指定可能とすることで、端末１０１の環境に応じた障害解析条件を設定することが可能となる。

　（５）請求項３に記載の管理装置（１０２）であって、前記復旧処理管理部（１４３）は、前記異常イベント毎に講じるべき復旧処理（復旧施策４０３）と、前記異常イベントの検知から復旧命令実行までの待ち時間（４０４）を指定可能とすることを特徴とする管理装置。

　上記構成により、復旧処理管理部１４３は、復旧処理管理テーブル１４３ａで異常イベント毎に講じるべき復旧施策４０３と、異常イベントの検知から復旧命令の実行までの待ち時間４０４を指定することが可能となり、端末１０１で発生し得る異常イベントに応じた復旧処理を設定することが可能となる。

　（６）上記（３）に記載の管理装置（１０２）であって、前記障害解析条件管理部（１４１）で管理する障害解析条件と、前記イベント判定条件管理部（１４２）で管理するイベント判定条件と、前記復旧処理管理部（１４３）で管理する復旧処理と、を入力する入力部（１３３）と、前記障害解析部（１３８）で検知された異常イベントの情報と、当該異常イベントに対する復旧処理を出力する出力部（１３４）と、をさらに有することを特徴とする管理装置。

　上記構成により、管理装置１０２は入力部１３３で障害解析条件とイベント判定条件と復旧処理とを入力し、出力部１１４で異常イベントの情報と、異常イベントに対する復旧処理を出力することができる。

　（７）上記（２）に記載の管理装置（１０２）であって、前記障害解析部（１３８）は、２以上の前記端末（１０１）が所定の障害解析条件に合致したことを以って、前記端末（１０１）で発生した異常イベントを判定することを特徴とする管理装置。

　上記構成により、管理装置１０２の障害解析処理において、複数の端末１０１が同時に同一の障害解析条件に合致したことも異常イベントの検知基準として採用することで、単一の端末１０１のログ情報だけでは検知できない異常イベントも検知可能となる。

　（８）上記（７）に記載の管理装置（１０２）であって、前記復旧命令部（１４０）は、前記端末（１０１）で発生した異常イベントに応じて、前記端末（１０１）に対して所定の復旧処理の有効化又は無効化を命令することを特徴とする管理装置。

　上記構成により、管理装置１０２は検知した異常イベントに応じて、端末１０１による自己復旧処理の有効化／無効化を行うことで、端末１０１だけでは明らかに自己復旧できないケースにおいて、不必要な自己復旧処理の実行を抑止することが可能となる。

　（９）上記（２）に記載の管理装置（１０２）であって、前記復旧命令部（１４０）は、前記復旧通知受信部（１３９）で受信した前記端末（１０１）からの自己復旧処理の通知に応じて、当該復旧処理の実行可否を判定し、当該復旧処理を実行可能なタイミングで前記端末（１０１）へ実行命令を指令することを特徴とする管理装置。

　上記構成により、端末１０１による自己復旧処理の実行の可否を管理装置１０２が決定することで、通信システムの人為的な計画停止によって招かれた異常イベントに対する不必要な自己復旧処理を抑止することに加え、通信システムの運用計画に対して、より適切なタイミングで復旧処理を実行することが可能となる。自己復旧処理によって通信システムの稼働を妨げることは本末転倒であり、運用計画に即したタイミングで復旧処理を実行することで、さらなる通信システムの稼働率向上に寄与することが可能となる。

　尚、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を含むものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換の何れもが、単独で、又は組み合わせても適用可能である。

　また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に記録しておくことができる。

　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

　＜補足＞
　特許請求の範囲に記載した以外の本発明の観点の代表的なものとして、次のものがあげられる。

　＜１６＞
　プロセッサとメモリを有して管理装置と接続される端末であって、
　自端末のログ情報を収集して、前記管理装置へ送信するログ情報管理部と、
　前記ログ情報から当該端末における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する自己障害解析部と、
　前記異常イベントに対する自己復旧処理を前記管理装置に通知する復旧通知送信部と、
　前記異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する自己復旧処理部と、を有し、
　前記復旧処理部は、前記復旧通知送信部を介して復旧処理を通知した後、前記管理装置から実行命令を受信するまで、当該復旧処理の実行を待機することを特徴とする端末。

　＜１７＞
　１以上の端末と接続される管理装置が前記端末を管理する管理方法であって、
　前記端末が、自端末のログ情報を収集して、前記管理装置へ送信する第１のステップと、
　前記端末が、前記ログ情報から当該端末における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する第２のステップと、
　前記端末が、前記異常イベントに対する自己復旧処理を前記管理装置に通知する第３のステップと、
　前記管理装置が、前記端末から収集したログ情報を基に、前記端末における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する第４のステップと、
　前記管理装置が、前記端末から当該端末が検知した異常イベントに対する自己復旧処理の通知を受信する第５のステップと、
　前記管理装置が、前記通知の有無に応じて前記障害解析部で検知した異常イベントに対する復旧処理の実行命令を前記端末に指令する第６のステップと、
　前記端末が、前記異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する第７のステップと、を含むことを特徴とする管理方法。

Claims

　管理対象となる１以上の端末と、前記端末と接続される管理装置からなる通信システムであって、
　前記端末は、
　自端末のログ情報を収集して、前記管理装置へ送信するログ情報管理部と、
　前記ログ情報から当該端末における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する自己障害解析部と、
　前記異常イベントに対する自己復旧処理を前記管理装置に通知する復旧通知送信部と、
　前記異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する自己復旧処理部と、を有し、
　前記管理装置は、
　前記端末から収集したログ情報を基に、前記端末における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する障害解析部と、
　前記端末から当該端末が検知した異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部と、
　前記通知の有無に応じて前記障害解析部で検知した異常イベントに対する復旧処理の実行命令を前記端末に指令する復旧命令部と、を有すること特徴とする通信システム。
　プロセッサとメモリを有して、管理対象となる１以上の端末と接続される管理装置であって、
　前記端末から収集したログ情報を基に、前記端末における異常イベントの有無を解析して、前記異常イベントを検知した場合には復旧処理を決定する障害解析部と、
　前記端末から、当該端末で検知した異常イベントに対する自己復旧処理の通知を受信する復旧通知受信部と、
　前記通知の有無に応じて前記障害解析部で検知した異常イベントに対する復旧処理の実行命令を前記端末に指令する復旧命令部と、を有すること特徴とする管理装置。
　請求項２に記載の管理装置であって、
　前記ログ情報に対する障害解析条件を管理する障害解析条件管理部と、
　前記ログ情報と合致した１以上の前記障害解析条件の組み合わせに基づくイベント判定条件を管理するイベント判定条件管理部と、
　前記異常イベント毎に講じるべき復旧処理を管理する復旧処理管理部と、をさらに有し、
　前記障害解析部は、
　前記障害解析条件管理部の障害解析条件に従って前記ログ情報を解析して、解析結果と、前記イベント判定条件管理部のイベント判定条件を基に前記端末の異常イベントを検知した後、前記復旧処理管理部を参照して前記異常イベントに対する復旧処理を決定し、
　前記復旧命令部は、
　前記復旧通知受信部にて前記端末から前記異常イベントに対する自己復旧処理の通知が受信されない場合に、前記復旧処理の実行命令を前記端末に指令することを特徴とする管理装置。
　請求項３に記載の管理装置であって、
　前記障害解析条件管理部は、
　前記障害解析条件毎に参照するログ情報と、比較基準となる閾値と、前記閾値に対する大小関係を規定する比較条件と、前記閾値を絶対値と相対値の何れで扱うかを規定する比較方法と、ログ情報が前記障害解析条件に合致した回数を指定可能とすることを特徴とする管理装置。
　請求項３に記載の管理装置であって、
　前記復旧処理管理部は、
　前記異常イベント毎に講じるべき復旧処理と、前記異常イベントの検知から復旧命令実行までの待ち時間を指定可能とすることを特徴とする管理装置。
　請求項３に記載の管理装置であって、
　前記障害解析条件管理部で管理する障害解析条件と、前記イベント判定条件管理部で管理するイベント判定条件と、前記復旧処理管理部で管理する復旧処理と、を入力する入力部と、
　前記障害解析部で検知された異常イベントの情報と、当該異常イベントに対する復旧処理を出力する出力部と、をさらに有することを特徴とする管理装置。
　請求項２に記載の管理装置であって、
　前記障害解析部は、
　２以上の前記端末が所定の障害解析条件に合致したことを以って、前記端末で発生した異常イベントを判定することを特徴とする管理装置。
　請求項７に記載の管理装置であって、
　前記復旧命令部は、
　前記端末で発生した異常イベントに応じて、前記端末に対して所定の復旧処理の有効化又は無効化を命令することを特徴とする管理装置。
　請求項２に記載の管理装置であって、
　前記復旧命令部は、
　前記復旧通知受信部で受信した前記端末からの自己復旧処理の通知に応じて、当該復旧処理の実行可否を判定し、当該復旧処理を実行可能なタイミングで前記端末へ実行命令を指令することを特徴とする管理装置。
　プロセッサとメモリを有して管理装置と接続される端末であって、
　自端末のログ情報を収集して、前記管理装置へ送信するログ情報管理部と、
　前記ログ情報から当該端末における異常イベントの有無を解析して前記異常イベントを検知した場合には自己復旧処理を決定する自己障害解析部と、
　前記異常イベントに対する自己復旧処理を前記管理装置に通知する復旧通知送信部と、
　前記異常イベントに対する自己復旧処理又は前記管理装置から命令された復旧処理を実行する自己復旧処理部と、を有することを特徴とする端末。
　請求項１０に記載の端末であって、
　前記ログ情報に対する障害解析条件を管理する障害解析条件管理部と、
　前記ログ情報と合致した１以上の前記障害解析条件の組み合わせに基づくイベント判定条件を管理するイベント判定条件管理部と、
　前記異常イベント毎に講じるべき復旧処理を管理する復旧処理管理部と、をさらに有し、
　前記自己障害解析部は、
　前記障害解析条件管理部の障害解析条件に従って前記ログ情報を解析して、解析結果と、前記イベント判定条件管理部のイベント判定条件を基に自端末の異常イベントを検知した後、前記復旧処理管理部を参照して前記異常イベントに対する復旧処理を決定し、

　前記自己復旧処理部は、
　前記復旧通知送信部を介して当該復旧処理を前記管理装置へ通知した後に前記復旧処理を実行又は前記管理装置からの命令で指定された復旧処理を実行することを特徴とする端末。
　請求項１１に記載の端末であって、
　前記障害解析条件管理部は、
　前記障害解析条件毎に参照するログ情報と、比較基準となる閾値と、前記閾値に対する大小関係を規定する比較条件と、前記閾値を絶対値と相対値の何れで扱うかを規定する比較方法と、ログ情報が前記障害解析条件に合致した回数を指定可能とすることを特徴とする端末。
　請求項１１に記載の端末であって、
　前記復旧処理管理部は、
　前記異常イベント毎に講じるべき復旧処理と、前記異常イベントの検知から復旧処理実行までの待ち時間と、前記管理装置に対する通知内容を指定可能とすることを特徴とする端末。
　請求項１１に記載の端末であって、
　前記障害解析条件管理部で管理する障害解析条件と、前記イベント判定条件管理部で管理するイベント判定条件と、前記復旧処理管理部で管理する復旧処理を入力する入力部と、
　前記自己障害解析部で検知された異常イベントの情報と、当該異常イベントに対する復旧処理を出力する出力部と、をさらに有することを特徴とする端末。
　請求項１０に記載の端末であって、
　前記自己復旧処理部は、
　前記管理装置からの命令に従って、前記復旧処理の一部を有効化又は無効化することを特徴とする端末。