JP2015012348A - 端末装置の遠隔監視方法 - Google Patents

Abstract

【課題】ユーザ拠点に設置される端末装置において、ファームウェアが動作不能な障害が発生した際も、警報通知フレームを複数の監視制御装置に送信可能とし、また、通知先の変更にも柔軟に対応すること、および端末装置内の故障状態を示す詳細情報を送信することを目的とする。【解決手段】端末装置のファームウェアは、装置起動時に通知先・故障内容毎に予め警報通知フレームを生成し、警報バッファ内に格納しておく。一方ハードウェアは、起動後、ファームウェアが動作不能となる障害を常時監視し、ファームウェア動作不能時には、ファームウェアが格納した警報通知フレームに対して、故障発生時刻情報および装置内詳細情報を追加した上で、フレーム送信トリガを掛けることで警報通知フレームの送信を可能とする。また、通知先アドレス情報の変更があった場合は、ファームウェア制御によりその都度通知先アドレス情報を書き換えることとする。【選択図】 図１

Description

本発明は、広域通信網を介して管理装置（監視制御装置）と通信を行う端末装置の障害発生状況を監視するための端末警報通知方法に関する。

通信キャリアの提供する通信網サービスは、生活及び企業活動における不可欠なインフラとして位置づけられている。近年、Ｌ２／Ｌ３−ＶＰＮ（Ｌａｙｅｒ２／Ｌａｙｅｒ３−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）技術を利用した通信網サービスは、国内全域をカバーするような広域を対象とした通信網サービスへとその提供範囲を拡大している。また、国内のみにとどまらず、企業の海外拠点においてもＬ２／Ｌ３−ＶＰＮサービスを利用できる環境を目指して国際的な通信網サービス事業が推進されている。このように国境を跨る通信網サービスの広域化が進む中で、サービス適用範囲の広域化を促進するため、国内通信キャリアが管理する国内／国際通信網と海外通信キャリアが管理する現地通信網とを相互接続してＬ２／Ｌ３−ＶＰＮサービスの提供範囲を拡大するケースが増えている。

通信キャリアの提供するＬ２／Ｌ３−ＶＰＮのような通信網サービスでは、企業などユーザ（サービス加入者）拠点内に設置され、通信キャリアが管理する回線終端装置、通信キャリアが提供する通信網とユーザ拠点との相互接続点（以下、通信網エッジと称する）に設置される網終端装置、通信網内での長距離伝送を実現する伝送装置で構成される通信システムを用いる。また、これらの通信装置（回線終端装置、網終端装置、伝送装置の総称）を監視および制御するための監視制御装置を備える。

通信網サービスでは一般に高い信頼性と共に高い保守性が求められる。例えば、ユーザの視点からは障害発生から復旧までの時間が短いこと、通信キャリアの視点からは障害復旧のためのコストが低いことが重要な要件となる。網終端装置や伝送装置は通信キャリアが管理する通信網内に設置されるため、監視制御装置による両装置の監視及び制御では、ユーザのデータが流れるサービス網とは隔離された両装置の監視及び制御のみを行う専用の監視制御網を構築することができる。一方、ユーザ拠点内に設置される回線終端装置については、通信キャリアが独自に専用の監視制御網を構築することができないため、ユーザ向けに開放しているサービス網を利用しての監視制御が必要となる。このとき、監視制御装置と回線終端装置とはサービス網を介してそれぞれ異なる拠点に設置されるため、通信プロトコルを利用した監視制御の手段が必要となる。

このような遠隔監視システムで利用可能な監視制御プロトコルとして、例えばＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で規定され、Ｌ２スイッチやＩＰルータの監視に用いられるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）技術が知られている。

ＶＰＮサービスの回線終端装置は更に、通信キャリアが滞在したり直接現地へ頻繁に赴いたりすることが難しいユーザ拠点内に設置されるため、当該装置に対し遠隔制御システムによる保守性の向上が望まれている。多数の通信装置を管理するため、制御監視装置から個々の通信装置に対し頻繁に状態確認信号を送出する代わりに、監視対象である通信装置が自律的に故障発生などのイベント情報を通知する方法が望ましい。これにより通信網内のトラフィックを低減でき、端末や制御監視装置、及び運用オペレータの処理負荷を低減できる。

このようなイベント通知技術の一つに、特開２００６−３３４１５号公報（特許文献１）がある。この公報には、「アドホックネットワークにおける無線端末装置の電源断を他端末へ通知するために、必要な箇所に電圧、電流を供給するエネルギー蓄積領域と、最新のシャットダウンメッセージを作成・保存する手段および、電源断時にシャットダウンメッセージを送出する手段を備える。」と記載されている。本公知例によれば、自装置の故障を近隣の装置に早期に自立的に伝達することにより、故障等により端末が突然ネットワークを離脱することによって発生するネットワークの混乱を最小限に抑えることが可能となる。

特開２００６−３３４１５号公報

これまでの通信装置では、電源故障等の障害発生時に、隣接する（物理回線で直接接続される）別の通信装置に対して緊急信号を送信している。この方法では電源断後の装置内残電圧を利用して（予め固定的に設定される）単純な信号だけを送出するため、例えば一つ以上の通信装置を介して更に別の装置へ信号通知するケース、特に他の通信網を介して遠隔地に状態通知するケースには対応できない。広域通信網サービスで自立的な状態通知を行うには、警報通知フレームに警報通知先のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスやＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス等のネットワーク情報、或いはＳＮＭＰプロトコル情報のような、複雑な情報を折り込む必要がある。またこれらの情報はルーティングプロトコル等の働きにより、随時変更される。従ってこれらの情報を含む警報通知処理をハードウェアのみで実現することは困難である。仮に実現した場合、ハードウェアの規模が膨大となりコストの増加を伴う。端末装置はコストが重要なセールスファクタであるため、このコスト要求が通信網サービスの普及に大きな障害となり得る。

さらに、状態通知の宛先となる監視制御装置は通信網サービス毎に単一ではない。例えば国内通信キャリアが海外通信キャリアとの相互接続により海外拠点を含む通信網サービスを展開するようなケースでは、海外拠点に設置する回線終端装置の保守を海外通信キャリアに委託するケースもある。このため、海外通信キャリアの通信網内にも第２の監視制御装置を配備し、国内通信キャリアと海外通信キャリアの双方が回線終端装置の状態監視を行うことが求められる。

通信装置から情報発信するには、ファームウェアによる信号生成が一般的である。しかしながら、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）故障のようにファームウェアが動作不能なケースでは、回線終端装置は監視制御装置に対して警報を通知できない。つまり不通の原因が、回線終端装置の故障か伝送路の障害かを判断できず、障害切り分けが困難となる。更に、障害通知後の要因解析に際し、警報通知フレームから得られる情報以外に、回線終端装置内の装置状態を示す詳細情報が必要となるケースがあるため、装置内部情報を選択的に収集及び発行する仕組みが必要である。

以上より、本発明の目的は、回線終端装置（端末装置）におけるハードウェア実装規模の拡大を回避しつつ、ファームウェアが動作不能な場合にも装置状態を外部装置へ通知できる遠隔監視システムを提供することである。

上記課題を解決するため、本願発明の通信装置は、装置の障害を通知するために装置外部へ送出するフレームを格納するバッファと、前記バッファに格納されたフレームを装置外部へ送出する、ハードウェアにより構成された送信処理部と、ファームウェアの動作、もしくは、ファームウェアの実行環境の少なくともいずれかを監視し、ファームウェアの障害を検知すると警報を出力する、ハードウェアにより構成された監視部と、前記監視部からの警報を受けて、前記バッファに格納されたフレームを送出するよう前記送信処理部に指示する、ハードウェアにより構成された送信トリガ生成部と、を有するよう構成される。

本発明により、通信装置がファームウェア動作不能に陥った場合、ハードウェア処理によりメッセージを外部の装置へ送出することが可能となり、当該外部の装置では障害の発生を検知することが可能となる。

通信システム構成例を示すネットワーク図である。 本実施例における端末装置１０の機能構成例を示す機能ブロック図である。 警報バッファ１１０４の構成例及び警報通知フレームの信号構成例を示すテーブル構成図である。 警報バッファ対応テーブル１１１００の一構成例を示す図である。 警報通知送信トリガ生成部１１１０の入出力の一例を示す図である。 レジスタ情報管理部１１１１の入出力の一例を示す図である。 一連の処理の結果、警報バッファ１１０４に生成される警報通知フレームの信号構成例を示すテーブル構成図である。 端末装置１０内の起動時点から警報通知フレーム送信完了間までの一連の動作を示すシーケンス図である。 端末装置１０内の障害検知から警報通知フレーム送信完了までの処理の流れを示すシーケンス図である。 警報バッファ１１０４内の警報通知フレーム情報を更新する処理を示すシーケンス図である。 リセットフレーム終端部１１１２およびリセット管理部１１１３の動作例を説明する図である。 網終端装置としてネットワークのエッジにＮＷ（Ｎｅｔｗｏｒｋ）エッジ装置を配備する構成を示す図である。 網終端装置としてネットワークのエッジにＮＷ（Ｎｅｔｗｏｒｋ）エッジ装置を配備した場合の端末装置の構成を示す図である。

以下、実施例を図面を用いて説明する。

本実施例では、Ｌ２／Ｌ３−ＶＰＮサービスを提供する通信システム（以下、ＶＰＮシステムと称する）を想定し、回線終端装置（端末装置）におけるファームウェア動作不能時に、監視制御装置宛てに当該端末装置のファームウェア障害に関する警報通知を行う遠隔監視方法について説明する。

図１は、国内通信キャリアが提供する通信網サービス１００を海外キャリアが運用するアクセス網４０を利用して海外まで広域化する場合の通信システム構成例を示すネットワーク図である。本図は、本発明の実施の形態として想定する遠隔監視システムの基本的な構成を示す。

国内通信キャリアが運用するＬ２／Ｌ３広域ネットワーク（以下、広域ネットワーク）３０と海外通信キャリアが運用するアクセス網（以下、アクセス網）４０は回線４００により相互接続される。接続回線４００は広域ネットワーク３０の接続装置２１０とアクセス網４０の接続装置３１０を直接つなぐ回線である。国内通信キャリア或いは海外通信キャリアのいずれかが接続回線４００を所有し他方に使用権を与える形が一般的である。通信網サービス１００は、国内のユーザ拠点に設置される端末装置１０Ａ，１０Ｍ，海外のユーザ拠点に設置される端末装置１０Ｂ、１０Ｎを含む。端末装置１０Ａ、１０Ｂ、１０Ｍ，１０Ｎは、それぞれユーザ収容装置２２０Ａ，３２０Ｂ，２２０Ｍ，３２０Ｎを介して通信網サービス１００に接続する。ユーザ収容装置２２０Ａと端末装置１０Ａ，ユーザ収容装置３２０Ｂと端末装置１０Ｂはそれぞれアクセス回線６１０Ａ，６１０Ｂで接続される。アクセス回線６１０Ａと６１０Ｂには、ＰＯＮ（Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ）やＭＣ（Ｍｅｄｉａ Ｃｏｎｖｅｒｔｅｒ）などの光アクセス回線やＥｔｈｅｒｎｅｔ(登録商標)等の物理回線を利用できる。ユーザ収容装置２２０Ｍ，３２０Ｎと端末装置１０Ｍ、１０Ｎの接続についても同様である。

広域ネットワーク３０には、広域ネットワーク３０の運用管理を行う監視制御装置２０Ａを備える。監視制御装置２０Ａは国内通信キャリアの局舎に設置され、広域ネットワーク３０の通信状況の監視や、広域ネットワーク３０内の通信装置に対する経路設定やＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）設定の展開を行う。アクセス網４０には監視制御装置２０Ｂが接続され、監視制御装置２０Ａと同様にアクセス網４０の通信状況の監視や、アクセス網４０内の通信装置（端末装置、ユーザ収容装置、接続装置、及び広域ネットワーク３０とアクセス網４０を構成するＬ２スイッチやＩＰルータを含む網構成装置の総称）に対する経路設定やＱｏＳ設定の展開を行う。広域ネットワーク４０及びアクセス網４０に接続される各端末装置１０Ａ，１０Ｂ，１０Ｍ、１０Ｎは、自装置内で異常状態を検知した場合に、監視制御装置２０Ａ或いは２０Ｂ宛てに警報通知フレームを送信する。保守担当者は、監視制御装置２０Ａ或いは２０Ｂを介して端末装置の動作状況を監視することができる。

以下、図１の構成を参照して遠隔監視システムの具体的な動作を説明する。広域ネットワーク３０に接続された監視制御装置２０Ａは、端末装置１０Ａ、１０Ｍ、１０Ｂ、１０Ｎに対する各種設定を実施するとともに、各端末装置１０Ａ，１０Ｂ，１０Ｍ、１０Ｎからの警報通知フレームを受信する。一方、海外通信キャリアは、海外キャリア保守エリア５０内のみを保守しており、監視制御装置２０Ｂによりアクセス網４０に接続された端末装置１０Ｂ、１０Ｎを制御並びに監視している。また、広域ネットワーク３０に接続された端末装置１０Ａ、１０Ｍは、広域ネットワーク３０に接続された監視制御装置２０Ａのみへ警報を通知し、アクセス網４０に接続された端末装置１０Ｂ、１０Ｎは、保守を担当する海外通信キャリアへの警報通知と通信網サービス１００のサービス主管となる国内通信キャリアへの警報通知が必要となるため、広域ネットワーク３０に接続された監視制御装置２０Ａ、アクセス網４０に接続された２０Ｂの双方へ警報を通知する。図１の中で、警報通知５１０Ａ，５１０Ｂ，５１０Ｍ，５１０Ｎはそれぞれ端末装置１０Ａ，１０Ｂ，１０Ｍ，１０Ｎから監視制御装置２０Ａ宛ての警報通知信号の流れを示しており、警報通知５２０Ｂ、５２０Ｎはそれぞれ端末装置１０Ｂ，１０Ｎが発行する監視制御装置２０Ｂ宛ての警報通知信号の流れを示す。

なお、図１では国内通信キャリアと海外通信キャリアの相互接続を例にしているが、国内通信キャリア同士の相互接続を利用しても同様の通信網サービスを提供できる。また単一の通信キャリアが自前の通信網を用いて同様の通信システムを構築することもできる。

図２は本実施例における端末装置１０の機能構成例を示す機能ブロック図である。端末装置１０の警報通知に関する機能は主にハードウェア１１００とファームウェア１２００で実行される。

本実施例における警報通知に関わるハードウェア機能には、装置故障（ハードウェア障害や誤動作等）や通信障害を検出し記録する内部警報監視部１１０１、ファームウェア機能の動作状況を監視するファームウェア機能監視部１１０２、装置内部の時刻を管理する時刻管理部（ＲＴＣ：Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）１１０３、警報通知フレームを格納する警報通知フレーム送信バッファ（以下、警報バッファ）１１０４Ａ〜１１０４Ｎ、ＣＰＵおよびメモリに電源を供給するオンボード電源の電圧を監視する電圧監視部１１０６、ＣＰＵにクロックを供給する発振器の正常性を監視するＣＬＫ監視部１１０７、ＣＰＵおよびメモリ動作の正常性を監視するＣＰＵ／メモリ監視部１１０８、端末装置１０外部からの電力供給源である外部入力電源の正常性を監視する入力電源監視部１１０９、警報通知フレームを送信するためのトリガを生成する警報通知送信トリガ生成部１１１０、警報通知フレームに装置内の詳細情報を付加するためのレジスタ情報管理部１１１１、監視制御装置２０からのリセットフレームを終端するリセットフレーム終端部１１１２、リセットフレーム終端部からリセット指示を受け、端末装置１０にリセットを掛けるリセット管理部１１１３、ＣＰＵにクロックを供給する発振器１１１４、ＣＰＵおよびメモリに電源を供給するオンボードのＣＰＵ／メモリ用電源１１１５、外部入力電源の異常により電源が供給されなくなった場合に、警報通知フレームを送信するための非常電源を保持する電源保持部１１１６、警報通知フレーム送信バッファ１１０４に格納された警報通知フレームの送信を制御する送信処理部１１１７を含む。なお、ＣＰＵ／メモリ用電源１１１５は、外部入力電源から各部へ電源供給されたものの一部であり、外部入力電源の電圧を変換するなどして供給された電源である。

警報通知に関わるファームウェア機能には、内部警報監視部１１０１を常時監視する警報監視制御部１２０１、警報通知フレームの宛先アドレスを管理する通知先アドレス管理部１２０２、装置時刻を管理する時刻管理部１２０３、警報通知フレームを編集し警報通知フレーム送信バッファ１１０４に書き込む警報通知編集制御部１２０４、端末装置１０の状態変化を監視し、警報通知フレーム送信バッファ１１０４に保持される警報通知フレームに対し送信トリガを掛ける警報通知送信制御部１２０５、ファームウェア１２００内の各プロセスの動作状況を常時監視するファームウェアプロセス監視部１２０６を含む。ファームウェア１２００はこれら各機能を実現するための、例えば組み込みソフトウェアで実装され、メモリ等の記憶部に格納された各機能用のプログラムをＣＰＵが読み出して実行するものである。なお、図２におけるハードウェアとしてのＣＰＵやメモリの位置は、ファームウェア１２００の機能ブロックの位置と置き換えて考えて良い。

ハードウェア１１００の内部警報監視部１１０１は、既存の通信警報や装置警報を検出するブロックであり、警報監視制御部１２０１は内部警報監視部１１０１を周期的に監視している。内部警報監視部１１０１が通信警報や装置警報といった異常を検出すると、警報監視制御部１２０１が当該内部警報監視部１１０１を監視することによって異常の発生を検知し、ファームウェア１２００は警報通知フレームを生成するための端末装置１０に関する情報収集を行い、収集した情報をハードウェア１１００の警報バッファ１１０４に順次格納する。必要な情報が格納されるとファームウェア１２００の警報通知送信制御部１２０５からハードウェア１１００の送信処理部１１１７に対して警報通知フレーム送信トリガ（読み出し指示）を送り、この送信トリガを受けた送信処理部１１１７は警報バッファ１１０４から警報通知フレームを読み出して装置外部へ送出する。

このように、ハードウェア１１００の内部警報監視部１１０１が収集した警報をファームウェア１２００の警報監視制御部１２０１が検出し、その後警報通知編集制御部１２０４にて警報通知フレームを警報バッファ１１０４内に作成し、警報通知送信制御部１２０５が送信トリガをかける方法では、障害検出から警報通知フレーム送信までにファームウェア１２００の処理が必要となるため、ファームウェア１２００が動作不能な状態となる障害や故障が発生した場合には、監視制御装置２０に対して警報通知フレームを送信できない。

このため本実施例では、ファームウェア１２００が動作不能な状態となったかどうかをハードウェア１１００側で検知するための機能部として、ファームウェア機能監視部１１０２、電圧監視部１１０６、ＣＬＫ監視部１１０７、ＣＰＵ／メモリ監視部１１０８、入力電源監視部１１０９を備える。また、ファームウェア１２００側には、ファームウェアプロセス監視部１２０６を備え、ファームウェア機能監視部１１０２にファームウェアのプロセス異常に関する情報を提供するようにしている。これらのうち、ファームウェア１２００の動作状態を直接監視するものがファームウェア機能監視部１１０２、ファームウェアプロセス監視部１２０６であり、ファームウェア１２００の実行環境を監視するものが電圧監視部１１０６、ＣＬＫ監視部１１０７、ＣＰＵ／メモリ監視部１１０８、入力電源監視部１１０９である。ファームウェア１２００が正常に動作し得ない状態にある場合に、これら機能部がファームウェア１２００の障害や故障もしくはその要因となる現象を検知して、ハードウェア１１００の警報通知送信トリガ生成部１１１０がファームウェア１２００の警報通知送信制御部１２０５に代わって警報通知フレームの送信トリガをかける。

このように本実施例では、端末装置１０のハードウェア１１００は起動後、ファームウェア機能監視部１１０２、電圧監視部１１０６、ＣＬＫ監視部１１０７、ＣＰＵ／メモリ監視部１１０８、入力電源監視部１１０９の各監視部にて、ファームウェアが動作不能となる障害要因を常時監視しておく構成とする。

また、ファームウェアの動作を主体として警報通知フレームを作成・送信する場合、通常運用時にはファームウェアは警報を検出してから警報通知フレームを作成する。よってファームウェアの動作を主体とする場合は、ファームウェアに異常が生じて動作不能となると警報通知フレームを生成できない。

このため本実施例の端末装置１０は、ファームウェア１２００が機能しなくなった場合にも警報通知フレームを送信できるようにするため、端末装置１０の運用中には変化しない情報について、例えば起動時などに予め故障内容毎に例えばＳＮＭＰ等のプロトコルで定められた形式で警報通知フレームを生成し、警報バッファ１１０４Ａ〜１１０４Ｎに格納しておく。図２に示す警報バッファ１１０４内の書き込み内容のうち、端末装置１０の起動時に書き込む情報は、予め保持している通知先アドレス情報１１０５ｂ（監視制御装置２０Ａ又は２０Ｂのアドレス情報）、通知元アドレス情報１１０５ｃ（当該端末装置１０に付与されている、広域ネットワーク３０又はアクセス網４０内で有効なアドレス情報）、通知元装置情報１１０５ｅ（端末装置１０固有の装置識別情報など）である。警報バッファ１１０４は、発生した障害の種類を表わす障害内容１１０５ｄと同数準備しておく。また、通知先のＭＡＣアドレス・ＩＰアドレス等のアドレス情報１１０５ｂについては、複数の通知先がある場合は、通知先毎にそれぞれ警報バッファ１１０４を確保し、警報通知フレームを生成、格納しておく。

このように、障害発生前に、予め故障内容毎・通知先毎の警報通知フレームをファームウェア１２００により生成しておき、情報変更があった場合には、その都度ファームウェア処理にて情報を編集することで、ファームウェア１２００が動作不能となる故障モードに備える。情報更新があった場合の処理については後述する。

警報通知フレームに含まれる情報のうち障害発生時刻１１０５ａはあらかじめ格納しておくことができない。しかしファームウェア１２００異常時は時刻管理部１２０３は機能しない可能性がある。そこで本実施例の端末装置１０は、障害発生時刻をファームウェアに依らず打刻できるよう、ハードウェア１１００に時刻管理部（ＲＴＣ）１１０３を備え、ファームウェア１２００が動作不能時には時刻管理部１２０３に代わって時刻管理部（ＲＴＣ）１１０３が警報通知フレーム送信バッファ１１０４に障害発生時刻を格納する。

さらに本実施例の端末装置１０は、障害・故障発生時の装置内の詳細情報であるレジスタ情報１１０５ｆを警報通知フレームに含ませるため、ハードウェア１１００側にレジスタ情報管理部１１１１を備える。障害発生時にレジスタ情報管理部１１１１は、レジスタ情報１１０５ｆを警報通知フレーム送信バッファ１１０４に格納する。

これらの情報（障害発生時刻１１０５ａおよびレジスタ情報１１０５ｆ）の警報通知フレームへの格納位置および格納書式は、使用するプロトコルにより一意に決められるため、ハードウェア制御による格納が可能である。

図３は、警報バッファ１１０４の構成例を示すテーブル構成図である。本図に、端末装置１０のファームウェア１２００が、例えば起動時などあらかじめ警報バッファ１１０４に書き込んでおく警報通知フレームの信号構成例を示す。警報バッファ１１０４にＮ個のバッファ２０００１を設け、それぞれのバッファ２０００１に通知先監視制御装置２０Ａ、２０Ｂのアドレス情報である通知先アドレス１１０５ｂ、端末装置１０自身のアドレス情報である通知元アドレス１１０５ｃを記入する。ここでは、通知先監視制御装置２０ＡのＩＰアドレスおよびＭＡＣアドレスをＸ、通知先監視制御装置２０ＢのＩＰアドレスおよびＭＡＣアドレスをＹとしている。バッファ１とバッファ２の障害内容２０００６は同じ「ファームウェアプロセス異常」であるが、通知先アドレス２０００３が異なるため２つのフレーム用の情報をバッファ１とバッファ２とで格納している。

またファームウェアプロセス異常、ＣＰＵ／メモリ故障等の障害内容１１０５ｄ、Ｓ／Ｎ（Ｓｅｒｉａｌ Ｎｕｍｂｅｒ）等の端末装置自身を特定する通知元装置情報１１０５ｅを書き込んでおくこととする。バッファ１とバッファ３は同じ通知先アドレス１１０５ｂであるＩＰ＝Ｘ、ＭＡＣ＝Ｘを宛先としているが、障害内容２０００５が異なるため２つのフレーム用の情報をバッファ１とバッファ３で格納している。

なお、この時点（端末装置１０の起動時点、或いは端末装置１０の正常動作中）では、障害発生時のリアルタイム情報に相当する障害発生時刻１１０５ａ及びレジスタ情報１１０５ｆについては書き込まれていない。

図４は、警報通知トリガ生成部１１１０における、警報種別とバッファ番号との対応付けの一例を示す警報バッファ対応テーブル１１１００のテーブル構成図である。警報通知トリガ生成部１１１０は、入力電源監視部１１０９や電圧監視部１１０６、ＣＬＫ監視部１１０７、ファームウェア機能監視部１１０２、ＣＰＵ／メモリ監視部１１０８から、それぞれの機能部が検出した障害情報の通知を受ける。警報バッファ対応テーブル１１１０は、通知を受けた障害情報から、警報通知フレーム送信バッファ１１０４内のどのバッファの警報通知フレームを送信すべきかを判断するために使用される。

警報バッファ対応テーブル１１１００には、障害箇所情報３０００１と障害検出時にトリガを掛けるバッファ３０００２の関係性を予め登録しておく。本図の対応関係は、端末装置１０を起動した段階で決定できる。そのためには、システムまたは装置の管理者が、どのバッファ１１０４にどの種類の警報の通知フレームを格納するかをあらかじめ決めておき、初期設定情報の１つとして端末装置１０に設定しておく。そして端末装置１０の例えば起動時に、ファームウェア１２００が初期設定情報を参照して警報バッファ対応テーブル１１１００を設定することができる。

なお、警報バッファ対応テーブル１１１００に登録した本関係性は、端末装置１０への設定により変更可能とする。端末装置１０の運用中に、万が一、いずれかの警報バッファ１１０４にハードウェア障害が発生した場合には、本テーブルの設定を変更することで対応可能である。例えば、故障した警報バッファ１１０４に格納されている警報通知フレームを他の正常な警報バッファ１１０４に格納し、警報バッファ対応テーブル１１１００においてトリガを掛けるバッファ３０００２のバッファ識別情報を変更すれば良い。ファームウェア１２００が正常に動作している間は、ファームウェア１２００が警報バッファ対応テーブル１１１００を変更・修正してバッファ番号と警報種別の対応関係を適宜変更しても良い。

次に、端末１０のファームウェア１２００が動作不能となる障害が発生した場合の警報通知に関わる処理について、ファームウェア機能監視部１１０２がファームウェアプロセス監視部１２０６を監視することにより検出したファームウェアプロセス異常の場合を例として説明する。

端末装置１０のファームウェア１２００内にあるファームウェアプロセス監視部１２０６は、ファームウェア１２００内の各プロセスの動作状況を常時監視し、ファームウェアプロセス異常が発生した際は、プロセス異常を検出し本機能ブロック１２０６内に当該情報を保持する。例えば、警報通知編集制御部１２０４や、警報通知送信制御部１２０５のプロセスに異常が発生した場合には、ファームウェア制御による警報通知フレームの送信が不能となるが、その障害情報は、ファームウェアプロセス監視部１２０６が記録しておき、動作異常が発生しているプロセスを特定できる構成とする。ハードウェア１１００内のファームウェア機能監視部１１０２は、ファームウェア１２００内のファームウェアプロセス監視部１２０６を常時監視しておき、ファームウェアのプロセス異常の有無を確認する。プロセス異常を検出した場合、ファームウェア機能監視部１１０２は警報通知送信トリガ生成部１１１０にファームウェアプロセス異常が発生したことを通知する。

図５は、ファームウェアプロセス異常発生時のファームウェア機能監視部１１０２から警報通知送信トリガ生成部１１１０へのインプットおよび該入力に対応する警報通知トリガ生成部１１１０のアウトプットを示す機能ブロック図である。警報通知送信トリガ生成部１１１０は、ファームウェア機能監視部１１０２から障害箇所情報８００１を受信する。この障害箇所情報８００１は、ファームウェアプロセスに異常が生じたことを示す情報である。警報通知送信トリガ生成部１１１０は、受信した障害箇所情報８００１と、図４で示した自身の持つ警報バッファ対応テーブル１１１００の障害箇所３０００１とを照合し、トリガを掛ける対象となるバッファ３０００２を決定する。

警報通知送信トリガ生成部１１１０は、どの警報バッファ１１０４にトリガを掛けるかを示す対象バッファ情報８０２０を送信処理部１１１７、時刻管理部（ＲＴＣ）１１０３、レジスタ情報管理部１１１１に展開する。これと同時に警報通知送信トリガ生成部１１１０は、レジスタ情報管理部１１１１に対しファームウェアプロセスに異常が生じたことを示す障害箇所情報８０１０を送信する。これを受けたレジスタ情報管理部１１１１は、障害箇所情報８０１０に対応するレジスタ情報を警報バッファ１１０４へ書き込む。本図のエントリ８０００の例では警報通知送信トリガ生成部１１１０は、トリガを掛けるバッファを特定するための対象バッファ情報８０２０の具体値として「バッファ１／バッファ２」を、障害種別を示す障害箇所情報８０１０の具体値として「ファームウェアプロセス異常」を、各機能ブロックへそれぞれ展開する。

図６は、ファームウェアプロセス異常発生時の警報通知送信トリガ生成部１１１０からレジスタ情報管理部１１１１へのインプットおよび該入力に対応するレジスタ情報管理部１１１１のアウトプットを示す機能ブロック図である。レジスタ情報管理部１１１１は、障害箇所情報４０００１と装置内部アドレス情報４０００２との対応関係を記憶するレジスタテーブル９１００を有する。障害箇所情報４０００１は、ファームウェアプロセス異常やＣＰＵ故障といった障害の種別である。装置内部アドレス情報４０００２とは、障害箇所情報４０００１に記憶された障害種別に応じて、その障害の調査等に有用なレジスタ情報を格納する記憶領域の装置内部のアドレスである。

レジスタ情報管理部１１１１は、警報通知送信トリガ生成部１１１０から展開された障害箇所情報８０１０をレジスタテーブル９１００の障害箇所４０００１と照合し、障害箇所情報８０１０が示す障害種別に応じたレジスタ情報を格納する装置内部アドレス４０００２を検索する。さらに、警報通知送信トリガ生成部１１１０から展開された対象バッファ情報８０２０から、レジスタ情報を書き込むべき警報バッファ１１０４を特定し、特定した警報バッファ１１０４内の警報通知フレームに、検索した装置内部アドレス４０００２で特定されるレジスタ情報を追加する。

ここで、レジスタ情報とはハードウェア１１００が検出した通信装置１０の異常や障害に関する情報であり、例えばファームウェアプロセス異常や、ＣＰＵ故障といった障害種別ごとにビット列が構成される。このビット列の各ビットは、０もしくは１のいずれかの値を取ることでさらに詳細な情報を提供する。例えばファームウェアプロセス異常に関するレジスタ情報の３ビット目は、ファームウェア１２００の警報通知送信制御部１２０５のプロセスが稼動している場合は１、停止している場合は０の値を取るというように決めておく。ファームウェア１２００のその他のプロセスについてもビット列中の任意のビットにて稼動状態を表わすようにすれば、単にファームウェアプロセスに異常がある、という情報だけではなく、どのプロセスが稼動／停止しているのかといった情報も警報通知フレームにて送信することができる。このように、レジスタ情報とは、通信装置１０における障害種別ごとのビット列であり、それぞれのビットに故障や障害の箇所等のさらに詳細な情報を与えたものである。

なお、レジスタ情報の読み方については予め定義しておき、監視制御装置２０で受信した警報通知フレームからレジスタ情報が意味する内容を保守者が読み取れるように当該システムを運用する。

また、時刻管理部１１０３は、警報通知送信トリガ生成部１１１０から展開されたバッファ情報を元に、警報バッファ１１０４内の警報通知フレームに自身で管理している時刻情報を障害発生時刻として追加する。これらの処理より、ファームウェアプロセス異常発生時に、警報バッファ１１０４に格納されている警報通知フレームに、障害発生時刻１１０５ａおよびレジスタ情報１１０５ｆの書き込みを実行する。

図７は、図５および図６で説明した一連の警報信号生成並びに警報発行トリガ処理の結果、警報バッファ１１０４に生成される警報通知フレームの信号構成例を示すテーブル構成図である。本図のテーブル内容は、図３で示した事前作業による警報通知フレーム構成情報に加えて、障害発生時刻１１０５ａおよびレジスタ情報１１０５ｆ（本図のエントリ１０１００部分）が書き込まれた状態となる。

本図に示す警報通知フレームの完成とともに、送信処理部１１１７は警報通知送信トリガ生成部１１１０から展開された対象バッファ情報８０２０を参照し、当該バッファに対し、生成完了した警報通知フレームの読み出し指示を発行する。該指示を受けた警報バッファ１１０４は、送信処理部１１１７が指定する警報バッファから警報通知フレームを読出し、監視制御装置２０Ａ，２０Ｂへ送信する。本図の例では、「バッファ１／バッファ２」から障害発生時刻「ＹＹＹＹ．ＭＭ．ＤＤ．ＨＨ．ＭＭ．ＳＳ」およびレジスタ情報「０ｘ００１０・・・・・・・・０１ＦＦ」が追加書き込みされた警報通知フレームを送信する。この時の通知先は、ＩＰアドレス＝Ｘ、ＭＡＣアドレス＝Ｘを持つ監視制御装置２０ＡおよびＩＰアドレス＝Ｙ、ＭＡＣアドレス＝Ｙを持つ監視制御装置２０Ｂとなる。

図８は、ファームウェアプロセス異常が発生した場合を想定して、端末装置１０内の起動時点から警報通知フレーム送信完了間までの一連の動作を示すシーケンス図である。端末装置１０のハードウェア１１００およびファームウェア１２００が起動（５０００１）した後、ファームウェア１２００は警報通知編集制御部１２０４にて警報通知フレームを生成する。このため装置状態を確認し、関連するパラメータ（装置情報）を収集する（５０００２）。警報通知編集制御部１２０４は収集した装置情報を用いて、ハードウェア１１００の警報バッファ１１０４に、警報通知フレームのうち（障害発生時刻などの）リアルタイム情報を除いた基本情報を書き込む（５０００３）。以降の処理については、図１２のシーケンスを用いて説明する。

図９は、ファームウェアプロセス異常が発生した場合を想定して、端末装置１０内の障害検知から警報通知フレーム送信完了までの端末装置１０内各機能ブロックにおける処理の流れを示すシーケンス図である。本図では、図５〜図７で説明した障害発生時の一連の処理をまとめて示している。

端末装置１０のハードウェア１１００内のファームウェア機能監視部１１０２は、端末装置１０の動作中は、ファームウェア１２００内のファームウェアプロセス監視部１２０６を常時監視している（６００１０）。ファームウェアプロセス監視部１２０６がプロセス異常を検出すると（６０００１）、ファームウェア機能監視部１１０２は、常時監視６００１１の結果、プロセス異常が発生したことを検出する（６０００２）。該プロセス異常を検出したファームウェア機能監視部１１０２は、警報通知送信トリガ生成部１１１０に障害箇所情報８０１０を展開する（６００１２）。警報通知送信トリガ生成部１１１０は、展開された障害箇所情報８０１０から警報バッファ対応テーブル１１１００を検索し（６０００３）、検索結果である対象バッファ情報８０２０を時刻管理部１１０３に展開する（６００１３−１）。時刻管理部１１０３は、対象バッファ情報８０２０で特定される警報通知フレーム送信バッファ１１０４に、自身の管理している装置内時刻情報を障害発生時刻として書き込む（６００１５）。

また、警報通知送信トリガ生成部１１１０は、レジスタ情報管理部１１１１に対象バッファ情報８０２０および障害箇所情報８０１０を展開する（６００１３−２、６００１４）。レジスタ情報管理部１１１１は、展開された障害箇所情報８０１０から警報通知フレーム送信バッファ１１０４に書き込むべきレジスタ情報を検索（６０００４）し、検索結果のレジスタ情報を展開された警報通知フレーム送信バッファ１１０４に書き込む（６００１６）。さらに、警報通知送信トリガ生成部１１１０は、送信処理部１１１７に対象バッファ情報８０２０を展開し（６００１３−３）、送信処理部１１１７は、対象バッファ情報８０２０にて特定される警報通知フレーム送信バッファ１１０４に対して読み出し指示を発行する（６００１７）。送信処理部１１１７は、読み出し指示されたバッファから監視制御装置２０に対して警報通知フレーム（６００１８）を送信する（６０００５）。

なお、図９に示す一連の処理はハードウェア制御で実行されるため、各処理の処理時間（クロック数）はあらかじめ見積もることが可能である。このため、例えば警報通知送信トリガ生成部１１１０が、送信制御部１１１７が警報通知フレームに必要な情報が格納される前に当該フレームをの送出トリガを発することを防止するためには、それぞれの処理に必要なクロック数分の待ち時間（Ｗａｉｔ）を設けて処理順序を守って各処理を実行すれば良い。

本シーケンスに示す通り、端末装置のハードウェア１１００がファームウェアプロセス異常を検出してから警報通知フレームを送信するまでの処理において、動作不能となっているファームウェア１２００による制御は介在しない。比較的安定して動作継続できるハードウェア（論理回路）レベルでのトリガを構成することにより、装置状態の変化に伴う機能低下の影響を受けずに、確実に警報通知を発行できる。

これらの手段により、ファームウェアプロセス異常のような、ファームウェアが動作不能となる障害が発生した場合も、警報バッファ１１０４内の警報通知フレームに障害発生時刻１１０５ａとレジスタ情報１１０５ｆを書き込み、監視制御装置２０へ警報通知フレームを送信することを可能とする。障害発生時刻１１０５ａおよびレジスタ情報１１０５ｆについては、障害発生時のリアルタイムな情報を監視制御装置２０へ通知する必要がある。そこで本図に示すように他の警報通知フレーム情報とは独立した処理を採用することで、当該情報の外部装置（監視制御装置２０）宛ての通知を実現する。

ここまでの実施例では、ファームウェア機能監視部１１０２がファームウェアプロセス監視部１２０６を監視してファームウェアプロセス異常を検出する場合を説明した。本実施例の端末１０は、他の障害・異常時にもハードウェア１１００による警報通知メッセージの送出が可能である。ファームウェア（プロセス）動作不能となる原因には、ＣＰＵおよびメモリに電源を供給するＣＰＵ／メモリ用電源１１１５（オンボード電源）の電圧異常、ＣＰＵにクロックを供給する発振器１１１４のクロック異常、ＣＰＵおよびメモリの異常、外部入力電源異常が含まれる。これら異常動作についても、図２に示すように、電圧監視部１１０６、ＣＬＫ監視部１１０７、ＣＰＵ／メモリ監視部１１０８、入力電源監視部１１０９が、それぞれオンボード電源電圧異常、発振器異常、ＣＰＵ／メモリの動作異常、入力電源電圧異常の有無を監視している。従って、これらの要因に対しても、ここまでに説明したファームウェアプロセス異常の例ケースと同様の処理により監視制御装置２０Ａ，２０Ｂに対して警報通知フレームを送信可能である。

次に、警報通知フレームの通知先アドレス変更を行う場合の処理を説明する。警報通知フレームの通知先アドレス変更は、例えば監視制御装置２０Ａ、２０Ｂの新規追加や移転等、図１の通信システムにおける監視制御装置２０Ａ、２０Ｂの収容変更等があった場合に必要となる。このとき、ファームウェア１２００内の通知先アドレス管理部１２０２では、ＡＲＰによるアドレス解決を実施し、変更後の通知先アドレス情報を得る。アドレス解決により得られる新たな監視制御装置２０のＭＡＣアドレスは、通知先アドレス管理部１２０２から警報通知編集制御部１２０４へ展開される。これを受けて警報通知編集制御部１２０４は、警報バッファ１１０４内の警報通知フレームの通知先アドレス情報１１０５ｂを書き替える。

通知先アドレス情報１１０５ｂに限らず、起動時に警報バッファ１１０４に書き込んだ警報通知フレームの内容に変更があった場合、警報通知編集制御部１２０４は、その都度警報通知フレームの内容を編集する。これは障害発生時などの警報通知の契機に、ハードウェア処理による迅速性とリアルタイム性を生かした警報通知フレーム発行処理を行うためである。

図１０は、警報バッファ１１０４内の警報通知フレーム情報を更新する処理を示すシーケンス図である。本ケースのように警報通知フレーム情報を更新する場合は、図８に示したシーケンスに対して、変更情報の収集５０００５および警報通知フレーム編集５０００６の処理が追加される。

図１〜図１０に説明した通信システム構成、装置機能構成、及び処理手順により、ファームウェア動作不良といった、早期に検知、状況特定及び原因究明が困難な障害が発生した場合も、警報通知フレームを複数の監視制御装置２０Ａ，２０Ｂに送信することを可能とし、また、通信網サービス１００運用中に警報通知フレームの送付先が変更されるケースについても、装置情報を確認し柔軟に対応することができる。更に、ハードウェア１１００による内部状態監視及びトリガ生成のための論理回路を活用することにより、端末装置１０から離れた場所に設置された監視制御装置２０Ａ（２０Ｂ）に於いても、端末装置の動作状態について、詳細な情報を確認することが可能となる。

以下、さらに高い保守性を実現するため、監視制御端末２０から端末装置１０に対し、遠隔操作コマンドを用いた状態監視方法を考える。ここでは使用頻度が高い遠隔操作コマンドとして、リセットコマンドを例に説明する。尚、遠隔操作コマンドを導入することにより、保守者は例えば警報通知フレーム内のレジスタ情報１１０５ｆからファームウェアが動作不能に陥っている要因を特定することが可能となり、現地（端末装置１０の設置場所）に赴くことなく各状況において最適な保守アクションを選択できる。その中でも特に、本発明が想定するファームウェアプロセス異常のような暫時的な障害に対しては、端末装置１０が設置されているユーザ拠点に駆け付けて端末装置１０を交換するという古典的な復旧手段に代わるより効率的な方法として、監視制御装置２０Ａ（２０Ｂ）から端末装置１０に対して遠隔操作コマンドを用いてリセットを掛け、障害要因を取り去ることが可能である。

本実施例の端末装置１０は、ファームウェア動作不能時の対応策として、監視制御装置２０Ａ、２０Ｂから遠隔操作コマンドを受信する論理回路を構成する。これらの機能はハードウェア実装であるため、ファームウェア動作異常時であっても主信号系を支えるハードウェア回路が正常動作している限りはコマンド処理が可能である。図２の例では、リセットフレーム終端部１１１２が監視制御装置２０からのリセットフレームを受信して当該フレームを終端する。そしてリセットフレーム終端部１１１２はリセット管理部１１１３にリセット指示を行い、リセット管理部１１１３は装置内の各部にリセットを掛ける。

図１１は、端末装置１０が監視制御装置２０からリセットフレーム１１１２１を受信した時の、リセットフレーム終端部１１１２およびリセット管理部１１１３が取り扱うべき信号内容と両機能の相関関係を示す機能ブロック図である。リセットフレーム終端部１１１２内のヘッダ解析部１１１２１は、監視制御装置２０からのリセットフレーム１１１２１のヘッダ６０００１、６０００２を解析し、これらヘッダの宛先が自装置であるか否かに応じて、自分が取り込むべきリセットフレームであるかを判断する。リセットコード終端部１１１２２では、リセットフレーム１１１２１内のリセットコード６０００３を終端し、リセット指示１１１２２をリセット管理部１１１３へ展開する。リセット管理部１１１３は、リセット指示１１１２１を受けると端末装置１０自身の各部にリセット１１１２３を掛ける。

以上、本実施例の端末装置１０は、通常の装置故障や通信障害についての警報通知フレーム生成・送信制御は、従来通りのファームウェア制御とし、例えばＣＰＵ故障のような、ファームウェアが動作不能となる障害の場合は、ハードウェア制御により警報通知フレームを生成・送信する。警報通知フレームには、通知先（監視制御装置）のＭＡＣアドレス・ＩＰアドレス等のネットワーク情報、通知元のＭＡＣアドレス・ＩＰアドレス等のアドレス情報、故障内容情報、故障発生時刻情報、シリアルナンバー等の通知元装置情報、装置内詳細情報を表すレジスタ情報を持たせるものとした。

ファームウェアは、装置起動時に通知先・故障内容毎に予め警報通知フレームを生成し、警報通知フレーム送信バッファ内に格納しておく。一方ハードウェアは、起動後、障害発生時にファームウェアが動作不能となるファームウェア機能、ＣＰＵおよびメモリ、ＣＰＵにクロックを供給する発振器、ＣＰＵおよびメモリに電源を供給するオンボード電源の電圧、外部入力電源の正常性を常時監視し、ファームウェアの動作状態を監視しておく。ファームウェア動作不能時には、ファームウェアが格納した警報通知フレーム送信バッファ内の警報通知フレームに対して、ハードウェアにより故障発生時刻情報および装置内詳細情報を追加した上で、フレーム送信トリガを掛ける。

通知先のＭＡＣアドレス・ＩＰアドレス等のネットワーク情報については、複数の通知先がある場合は、通知先毎に警報通知フレームを生成しておき、通知先アドレス情報の変更（ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）テーブルの更新等）があった場合は、その都度警報通知フレーム送信バッファ内の通知先アドレス情報を書き換えることとした。他にも、通知内容の変更があった場合には、その都度警報通知フレームの内容を編集しておくこととする。

これらの手段により、ファームウェアが動作不能な故障モードにおいて、警報通知フレームを複数の監視制御装置に送信可能とし、また、通知先の変更にも柔軟に対応すること、および端末装置の状態の詳細情報を送信することが可能となる。

本実施例は、図１２に示すように網終端装置としてネットワークのエッジにＮＷ（Ｎｅｔｗｏｒｋ）エッジ装置を配備する構成での例を説明する。

本構成は、ＮＷエッジ装置６０が、端末装置１０が具備している時刻管理、通知先アドレス管理および監視制御装置２０との警報通知プロトコル制御を肩代わりすることにより、端末装置１０のハードウェア規模を抑えてコストを低減しつつ、実施例１と同等の効果を達成するものである。

本構成での端末装置１０の構成は、図１３のようになり、図２と比較してハードウェア１１００では時刻管理部（ＲＴＣ）１１０３が不要となり、障害発生時に時刻情報を追加書き込みする機能も不要となる。また、警報通知フレームの情報として、通知先アドレス情報、通知元アドレス情報が不要となり、さらに警報通知フレームは、ＮＷエッジ装置６０へのみ送信すれば良いため、通知先毎に格納する必要がなくなるため、具備する警報バッファの数を抑えることが可能である。また、ファームウェア１２００の機能としては、時刻管理部１２０３、通知先アドレス管理部１２０２が不要となる。その他、図２と同一の符号を付された構成については、同一の機能を有し、実施例１と同様の処理となるため説明を省略する。

ＮＷエッジ装置６０では、端末装置１０から送信された警報通知フレームを終端し、ＮＷエッジ装置を通知元として監視制御装置２０へ警報通知フレームを送信する。ＮＷエッジ装置から監視制御装置２０へ送信する警報通知フレームには、端末装置１０から警報通知フレームを受信した時刻を打刻し、通知元アドレス情報として、ＮＷエッジ装置６０自身のＭＡＣアドレスおよびＩＰアドレスを付与する。また通知先アドレス情報は、ＮＷエッジ装置６０がＡＲＰによるアドレス解決を実施し、監視制御装置２０のＭＡＣアドレスを得て、警報通知フレームに付与する。これらの情報を監視制御装置２０のプロトコルに合わせたフレーム形式にして監視制御装置２０へ通知する。

１０ 端末装置
２０ 監視制御装置
６０ ＮＷエッジ装置
１１００ 端末装置ハードウェア
１１０４ 警報通知フレーム送信バッファ
１１１０ 警報通知送信トリガ生成部
１１１００ 警報バッファ対応テーブル
１１１１ レジスタ情報管理部
１１１７ 送信処理部
１２００ 端末装置ファームウェア

Claims (10)

1. 装置の障害を通知するために装置外部へ送出するフレームを格納するバッファと、
   前記バッファに格納されたフレームを装置外部へ送出する、ハードウェアにより構成された送信処理部と、
   ファームウェアの動作、もしくは、ファームウェアの実行環境の少なくともいずれかを監視し、ファームウェアの障害を検知すると警報を出力する、ハードウェアにより構成された監視部と、
   前記監視部からの警報を受けて、前記バッファに格納されたフレームを送出するよう前記送信処理部に指示する、ハードウェアにより構成された送信トリガ生成部と、を有することを特徴とする通信装置。
2. 請求項１に記載の通信装置であって、
   前記フレームごとに、当該フレームの通知先アドレスと、当該フレームの通知元アドレスと、当該フレームにより通知する障害の種別を表わす障害内容と、を障害が起こる前にあらかじめ前記バッファに格納する、ファームウェアにより構成された編集制御部を有し、
   前記送信トリガ生成部は、
   前記障害内容と、当該障害内容を格納するフレームを格納するバッファの識別情報と、の対応関係を保持し、
   前記監視部から警報を受信すると、当該警報に応じた前記障害内容を格納するフレームを格納するバッファを識別する情報を前記送信処理部に送出し、
   前記送信処理部は、前記トリガ生成部から受信した前記バッファを識別する情報で特定されるバッファに格納されたフレームを送出することを特徴とする通信装置。
3. 請求項２に記載の通信装置であって、
   前記フレームに装置の状態を示すレジスタ情報を格納する、ハードウェアにより構成されたレジスタ情報管理部を有し、
   前記送信トリガ生成部は、前記監視部から警報を受信すると、当該警報に応じた前記障害内容を格納するフレームを格納するバッファを識別する情報を前記レジスタ情報管理部に送出し、
   前記レジスタ情報管理部は、前記トリガ生成部から受信した前記バッファを識別する情報により特定されるバッファに格納されたフレームに前記レジスタ情報を格納することを特徴とする通信装置。
4. 請求項３に記載の通信装置であって、
   前記送信トリガ生成部は、前記監視部から警報を受信すると、当該警報に応じた前記障害内容を前記レジスタ情報管理部に送出し、
   前記レジスタ情報管理部は、前記トリガ生成部から受信した前記障害内容に応じたレジスタ情報を前記フレームに格納することを特徴とする通信装置。
5. 請求項４に記載の通信装置であって、
   前記レジスタ情報管理部は、前記障害内容と、前記障害内容の示す種別の障害が生じたときに参照すべきレジスタ情報が格納されている装置内のアドレスと、を対応付けて保持することを特徴とする通信装置。
6. 請求項２に記載の通信装置であって、
   前記フレームに障害の生じた時刻を格納する、ハードウェアにより構成された時刻管理部を有し、
   前記送信トリガ生成部は、前記監視部から警報を受信すると、当該警報に応じた前記障害内容を格納するフレームを格納するバッファを識別する情報を前記時刻管理部に送出し、
   前記時刻管理部は、前記トリガ生成部から受信した前記バッファを識別する情報により特定されるバッファに格納されたフレームに現在の時刻を格納することを特徴とする通信装置。
7. 請求項２に記載の通信装置であって、
   ファームウェアのプロセスを監視する、ファームウェアにより構成されたプロセス監視部を有し、
   前記監視部は、前記プロセス監視部がファームウェアのプロセスの異常を検出すると、警報を前記トリガ生成部に送出することを特徴とする通信装置。
8. 請求項７に記載の通信装置であって、
   前記監視部は、前記ファームウェアが動作するＣＰＵもしくはメモリに供給される電圧もしくはクロックの少なくともいずれかを監視することを特徴とする通信装置。
9. 請求項７に記載の通信装置であって、
   前記監視部は、ＣＰＵもしくはメモリの動作を監視することを特徴とする通信装置。
10. 請求項７に記載の通信装置であって、
    前記監視部は、外部入力電源を監視することを特徴とする通信装置。

Images