JP3824972B2 - ネットワーク管理装置 - Google Patents
ネットワーク管理装置 Download PDFInfo
- Publication number
- JP3824972B2 JP3824972B2 JP2002193093A JP2002193093A JP3824972B2 JP 3824972 B2 JP3824972 B2 JP 3824972B2 JP 2002193093 A JP2002193093 A JP 2002193093A JP 2002193093 A JP2002193093 A JP 2002193093A JP 3824972 B2 JP3824972 B2 JP 3824972B2
- Authority
- JP
- Japan
- Prior art keywords
- state
- change request
- handling data
- status
- operator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Exchange Systems With Centralized Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はネットワーク管理装置に関し、特にネットワークの管理を行うネットワーク管理装置に関する。
【０００２】
【従来の技術】
近年、情報ネットワーク・サービスは、多種多様なものが求められ、これらのサービスを提供するための情報インフラストラクチャは、複雑化、巨大化している。このような状況の中で、ネットワークを構成する伝送装置などのネットワーク装置（ＮＥ：Network Element）の保守管理を行うネットワーク管理装置（ＮＭＳ：Network Management System）の需要が高まっている。
【０００３】
オペレータがＮＥの現在の状態を変更しようとした場合、状態変更要求をＮＭＳへ入力する。ＮＭＳは、オペレータからの状態変更要求を受けると、この要求に該当するコマンドを生成してＮＥへ送信し、そのレスポンスデータを受信する。これによりＮＥの状態が変更され、装置状態が管理される。また、ＮＥには、誤った運用設定がなされて、ネットワーク上に重大な障害を起すことがないように、通常は複雑な制約条件が設けられている。
【０００４】
制約条件とは、ＮＥの状態と、受け付け可能な状態変更要求との関係を定めた規則のことである（あるＮＥが状態Ａのときは状態変更要求Ａに関するコマンドは受け付けるが、状態変更要求Ｂに関するコマンドは受け付けないというように、ＮＥはコマンドを受け付けるための条件（制約条件）を持っているということ）。
【０００５】
したがって、オペレータは、制約条件を満足するように状態変更要求を行う必要がある。ＮＥは、状態変更要求のコマンドを受信した場合、そのときの装置状態によって、コマンドが制約条件を満足していれば受け付け、満足していない場合には、そのコマンドに対するエラーレスポンスをＮＭＳへ返送する。
【０００６】
【発明が解決しようとする課題】
オペレータは、コマンド送信等に関する履歴（操作履歴）を効率よく管理するためには、無駄なオペレーションを省く必要がある。したがって、ＮＥに状態変更要求を行う場合、現在のＮＥの状態で、制約条件を満足するか否かを事前に確認して、正常な状態変更要求を送信することで、ＮＥからのエラーレスポンスをできるだけ受信しないことが望ましい。
【０００７】
しかし、従来の管理制御では、制約条件を確認するためには、新規導入または既設のＮＥに対し、オペレータがＮＥの取扱説明書やヘルプ機能等を用いて、状態変更要求の制約条件をあらかじめ調査しなければならず、さらに、オペレータ自身が、その制約条件を現在の装置状態が満足しているか否かを判断しなければならなかった。このため、作業にはかなりの手間がかかり、保守管理における利便性が低いといった問題があった。
【０００８】
また、状態変更要求に関するコマンドがＮＥで受け付けられず、エラーレスポンスが返送された場合、どのような問題対処をすれば、ＮＥがそのコマンドを受け付けられるかを、オペレータがエラー内容、ＮＥの現在の装置状態、制約条件などから調査しなければならなかった。さらに、調査後に複数の問題対処があることがわかった場合、オペレータがそれらの問題対処による操作を逐一実行していく必要があった。このように、従来のネットワーク管理では、オペレータの負担が大きく効率的でなかった。
【０００９】
一方、ネットワーク管理技術の従来技術として例えば、特開２０００−３３９２８９号公報が提案されている。これは、エラー内容から想定される問題原因、対処方法をあらかじめ作成して保持しておき、エラーが発生した場合、対応する問題原因、対処方法をヘルプ機能で表示し、オペレータが問題原因を判断して、再度コマンドを投入するものである。
【００１０】
ところが、この従来技術では、ＮＥの現在の運用状態を考慮していないため、現時点での問題原因が明確に特定できない。このため、想定される複数の問題対処から、オペレータが結局、問題原因や対処方法を調査する必要があるために、作業効率の向上が望めなかった。また、対処方法をあらかじめ作成する方法では、問題原因に関する対処の手順をすべて記載しておく必要があるが、この場合、現在運用している装置状態として不要な手順も含まれることになり、管理効率の向上が望めなかった。
【００１１】
本発明はこのような点に鑑みてなされたものであり、現在のＮＥの状態に応じた適切な問題解決を実行して、保守管理に対する作業効率及び利便性の向上を図ったネットワーク管理装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような、ネットワークの管理を行うネットワーク管理装置１０において、現在の装置状態を管理する装置状態テーブルＴ１、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブルＴ２、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルＴ３、を格納するテーブル格納部１１と、テーブル格納部１１内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部１２と、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部１３と、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する装置通信部１４と、を有することを特徴とするネットワーク管理装置１０が提供される。
【００１３】
ここで、テーブル格納部１１は、現在の装置状態を管理する装置状態テーブルＴ１、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブルＴ２、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルＴ３を格納する。解析処理部１２は、テーブル格納部１１内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う。ユーザインタフェース部１３は、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知する。装置通信部１４は、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１はネットワーク管理装置の原理図である。ネットワーク管理システム１は、ネットワーク１ａを構成するネットワーク装置（以下、ＮＥまたは単に装置と呼ぶ）２０−１〜２０−ｎと、ＮＥ２０−１〜２０−ｎを管理するネットワーク管理装置（以下、ＮＭＳ）１０で構成される。
【００１５】
ＮＭＳ１０に対し、テーブル格納部１１は、装置状態テーブルＴ１、制約条件テーブルＴ２、問題対処テーブルＴ３を格納管理する。装置状態テーブルＴ１は、ＮＥ２０−１〜２０−ｎ（総称する場合はＮＥ２０とする）の現在の装置状態を管理するテーブルである。
【００１６】
制約条件テーブルＴ２は、ＮＥ２０が状態変更要求を受け付けるための制約条件を管理するテーブルである。問題対処テーブルＴ３は、制約の原因になっている問題に対処するための問題対処データを管理するテーブルである。なお、システム運用中でも各データの値は必要に応じて書き替え可能である。各テーブルの詳細は図２〜図６で後述する。
【００１７】
解析処理部１２は、状態変更要求の正常性の解析処理を行う。具体的にはまず、状態変更要求が現在の装置状態で制約条件を満足しているか否かを、テーブル格納部１１で格納されている各種データにもとづき判断する。
【００１８】
そして、制約条件を満足していないが問題を回避できる場合は、制約がかかっている問題がすべてなくなるまで、すべての問題対処データを抽出する。また、制約条件が満足していなく、かつ問題を回避できない場合には、回避できない原因である回避不可原因を抽出する。詳細は図７以降で後述する。
【００１９】
ユーザインタフェース部１３は、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知（表示制御）する。装置通信部１４は、ＮＥ２０へコマンドを送信したり、ＮＥ２０からレスポンスを受信したりする。例えば、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成してＮＥ２０へ送信し、そのレスポンスを受信する。
【００２０】
次にテーブル格納部１１について図２〜図６を用いて説明する（なお、図２〜図６中のＳ※の符号は、本発明の動作説明を行うために付した符号であり、図７以降で用いる）。図２は装置状態テーブルの構成例を示す図である。装置状態テーブルＴ１は、装置状態のデータを管理するテーブルであり、装置構成要素名、属性名、属性値の項目からなる。例えば図では、装置名がOS1-TC-1であるＮＥのstate（現在の運用状態）は、ＩＳ−ＮＲ（サービス中）になっている。
【００２１】
なお、本発明では、属性名としてはstateを扱うため、図中の他の属性名（vendid、dom、cleli）及び対応する属性値（FC9518AIA1、01.09、WM2WHR0CAA）についての説明は省略する。
【００２２】
図３、図４は制約条件テーブルの構成例を示す図である。制約条件テーブルＴ２は、ＮＥへの要求内容ｔ２−１、制約条件ｔ２−２、実行権限ｔ２−３、複数条件ｔ２−４、エラーコードｔ２−５の項目から構成される。また、ＮＥへの要求内容ｔ２−１は、状態変更要求名、装置構成要素名、属性名、属性値の項目から構成され、制約条件ｔ２−２は、符号、装置構成要素名、属性名、属性値の項目から構成され、実行権限ｔ２−３は、ＮＭＳと装置の項目から構成され、複数条件ｔ２−４は、連結と論理関係の項目から構成される。
【００２３】
テーブルの見方について説明する。ＮＥへの要求内容ｔ２−１に記載されている要求が受け付けられるためには、制約条件ｔ２−２に記載されている条件を満たす必要がある。データの２行目を例にすると、ＮＥへの要求内容ｔ２−１として、状態変更要求名がED-EQPT（保守状態に変更する要求）、装置構成要素名がOS1-TC-2、属性名がstate、属性値がOOS-MA（保守状態）となっている。
【００２４】
また、制約条件ｔ２−２として、符号＝１（符号については後述する）、装置構成要素名がOS1-TC-1、属性名がstate、属性値がUAS（削除状態：未登録状態のこと）となっている。
【００２５】
これは、装置名がOS1-TC-2のＮＥに対して、状態変更要求をED-EQPTにして、OS1-TC-2の運用状態をOOS-MAに変更するには、制約条件として、装置名OS1-TC-1のＮＥがUASになっていなければならないということである。すなわち、OS1-TC-1がUASでなければ、OS1-TC-2はOOS-MAへ状態遷移できないということである。
【００２６】
また、同様にして、４行目のデータを例にすれば、装置名がOS1-TC-1のＮＥに対して、状態変更要求をDLT-EQPT（削除状態に変更する要求）にして、OS1-TC-1の運用状態をUASに変更するには、制約条件として、OS1-TC-1がOOS-MAになっていなければならないということである。すなわち、OS1-TC-1はOOS-MAでなければ、OS1-TC-1はUASへ状態遷移できないということである。
【００２７】
ここで、符号、実行権限ｔ２−３、複数条件ｔ２−４、エラーコードｔ２−５について説明する。符号＝１の場合は、制約条件ｔ２−２に記載されたデータであること、符号＝２の場合は、制約条件ｔ２−２に記載されたデータでないことという意味である。
【００２８】
例えば、データ２行目のＮＥへの要求内容ｔ２−１に対し、図では符号＝１なので、制約条件は、OS1-TC-1がUASであること、ということである（もし、符号＝２であったならば、OS1-TC-1がUASでないこと、という内容が制約条件になる）。
【００２９】
実行権限ｔ２−３とは、ＮＥへ状態変更要求を行うために必要なオペレータの権限であり、図に示す“３”とはオペレータに権限があることを示している数字である。また、実行権限ｔ２−３のＮＭＳとは、ＮＭＳ１０にloginしているユーザの権限を示し、実行権限ｔ２−３の装置とは、ＮＭＳ１０からＮＥにloginしているユーザの権限を示す。
【００３０】
複数条件ｔ２−４とは、制約条件ｔ２−２の内容が次の行に続くか否かを示すものである。制約条件ｔ２−２の内容が次の行に続く場合は、複数条件ｔ２−４の連結がＹと記載され、続かない場合はＮと記載される。また、複数条件ｔ２−４の論理関係とは、制約条件ｔ２−２が次の行に続く場合の論理（ＡＮＤ、ＯＲなど）を示す。
【００３１】
例えば、データ２行目の複数条件ｔ２−４の連結が、図ではＮと記載されて論理関係は記載なしであるから、２行目の制約条件ｔ２−２の内容は次の行には続かないことになる（すなわち、制約条件はOS1-TC-1がUASであること）。また、もしデータ２行目の複数条件ｔ２−４の連結がＹ、論理関係がＡＮＤと記載され、３行目の複数条件ｔ２−４の連結がＮ、論理関係が記載されてなければ、制約条件は３行目まで続く。すなわち、２行目のＮＥへの要求内容ｔ２−１を満たすためには、この場合、OS1-TC-1がUASで、かつOS1-TC-2がUASであることが制約条件となる。
【００３２】
エラーコードｔ２−５とは、ＮＥへの要求内容ｔ２−１に記載されている要求があった場合に、制約条件ｔ２−２を満足していないときは、どのようなエラーのコードを出力するかということが記載された欄である。図の場合、それぞれの行の要求が制約条件ｔ２−２を満足していないときは、すべてＳＮＶＳというコードをエラーコードとして出力するようになっている。
【００３３】
図５、図６は問題対処テーブルの構成例を示す図である。なお、本発明でいう“問題”とは制約条件と同等の意味で使っている。したがって、“問題を解決する”とは、制約条件を満足するということであり、また、問題対処とは、制約条件を満足するためには、どのような対処をすればよいかということである。さらに、問題対処データとは、制約条件満足データのことで、制約条件を満足するための状態変更要求ということにもなる。
【００３４】
問題対処テーブルＴ３は、変更条件ｔ３−１、問題対処データの内容ｔ３−２の項目から構成される。変更条件ｔ３−１は、さらに装置状態の現状値ｔ３−１ａ、装置状態の変更値ｔ３−１ｂからなり、装置状態の現状値ｔ３−１ａ及び装置状態の変更値ｔ３−１ｂそれぞれは、装置構成要素名、属性名、属性値からなる。また、問題対処データの内容ｔ３−２は、有無、状態変更要求名、装置構成要素名、属性名、属性値、コメントからなる。
【００３５】
テーブルの見方について説明する。問題対処テーブルＴ３には、装置状態の変更値ｔ３−１ｂに記載されている属性値に変更するための、装置状態の現状値ｔ３−１ａに記載されている現状の属性値に応じた、問題対処データが記載されている。
【００３６】
例えば、OS1-TC-1をUASに変更したい場合（図のデータ３行目）、OS1-TC-1の現状の状態がIS-NRのときは、問題対処データとして、状態変更要求をED-EQPTにして、OS1-TC-1をOOS-MAに変更し、その後、状態変更要求をDLT-EQPTにして、OS1-TC-1を削除する、ということが記載されている。
【００３７】
すなわち、IS-NR中のOS1-TC-1をUASの状態に変更するには、OS1-TC-1を一旦OOS-MAに変更した後にOS1-TC-1を削除（未登録）する。このようにOS1-TC-1の状態を削除状態にして、UASへ状態変更するためのコマンドを送信すれば、OS1-TC-1はそのコマンドを受け付けることができる。
【００３８】
また、OS1-TC-1をUASに変更したい場合（図のデータ４行目）、OS1-TC-1の現状の状態がOOS-MAのときは、問題対処データとして、状態変更要求をDLT-EQPTにして、OS1-TC-1を削除する、ということが記載されている。
【００３９】
すなわち、OOS-MA中のOS1-TC-1をUASの状態に変更するには、OS1-TC-1を削除する。このようにOS1-TC-1の状態を削除状態にして、UASへ状態変更するためのコマンドを送信すれば、OS1-TC-1はそのコマンドを受け付けることができる。
【００４０】
なお、テーブル中の項目“有無”とは、問題対処データがあれば有（図６では有を“１”）、なければ無（図６で無を“２”）と記載される。また、コメントは、問題対処データの内容を示すものである（問題対処データとして、このコメントがＮＭＳ１０の画面上に表示される）。
【００４１】
次に本発明の動作について詳しく説明する。ここでは、装置名がOS1-TC-3のＮＥを削除（未登録）する動作について、図２〜図６に示した各種データを利用して具体的に説明する。図７はOS1-TC-3を削除する際の状態遷移を示す図である。
〔Ｓ１〕オペレータは、OS1-TC-3を削除しようとして、その旨の状態変更要求をユーザインタフェース部１３を介しＮＭＳ１０へ入力する。
〔Ｓ２〕ＮＭＳ１０の解析処理部１２は、OS1-TC-3削除の内容の状態変更要求に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-3のstateがOOS-MAであること”である。
〔Ｓ３〕解析処理部１２は、OS1-TC-3の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-3のstateがIS-NR”である。
〔Ｓ４〕解析処理部１２は、オペレータからの状態変更要求が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-3を削除するためには、OS1-TC-3のstateがOOS-MAであることが必要だが、現在のOS1-TC-3のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ５〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-3、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-3、state、OOS-MA）に対する問題対処データは、“OS1-TC-3へstate=OOS-MAのED-EQPTコマンドを投入”であることを認識する（OS1-TC-3を保守状態にすること）。
〔Ｓ６〕解析処理部１２は、ステップＳ５で読み出した問題対処データを保持する。
〔Ｓ７〕解析処理部１２は、“OS1-TC-3へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-3を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-2のstateがUAS”である。
〔Ｓ８〕解析処理部１２は、OS1-TC-2の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-2のstateがIS-NR”である。
〔Ｓ９〕解析処理部１２は、ステップＳ８の読み出し結果（“OS1-TC-2のstateがIS-NR”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-3を保守状態にするためには、OS1-TC-2のstateがUASであることが必要だが、現在のOS1-TC-2のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ１０〕解析処理部１２は、問題対処テーブルをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-2、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-2、state、UAS）に対する問題対処データは、“OS1-TC-2へstate=OOS-MAのED-EQPTコマンド投入後、DLT-EQPTコマンドを投入”であることを認識する（OS1-TC-2を保守状態にした後に削除すること）。
〔Ｓ１１〕解析処理部１２は、ステップＳ１０で読み出した問題対処データを保持する。
〔Ｓ１２〕解析処理部１２は、“OS1-TC-2へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-2を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-1のstateがUAS”である。
〔Ｓ１３〕解析処理部１２は、OS1-TC-１の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-１のstateがIS-NR”である。
〔Ｓ１４〕解析処理部１２は、ステップＳ１３の読み出し結果（“OS1-TC-1のstateがIS-NR”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-2を保守状態にするためには、OS1-TC-1のstateがUASであることが必要だが、現在のOS1-TC-1のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ１５〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-1、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-1、state、UAS）に対する問題対処データは、“OS1-TC-1へstate=OOS-MAのED-EQPTコマンド投入後、DLT-EQPTコマンドを投入”であることを認識する（OS1-TC-1を保守状態にした後に削除すること）。
〔Ｓ１６〕解析処理部１２は、ステップＳ１５で読み出した問題対処データを保持する。
〔Ｓ１７〕解析処理部１２は、“OS1-TC-1へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-1を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。テーブル中に記載事項がないので、制約条件の読み出し結果は、“制約条件なし”となる。
〔Ｓ１８〕解析処理部１２は、ステップＳ１７の読み出し結果が“制約条件なし”なので、すべての問題対処データを抽出したことを認識する。
〔Ｓ１９〕ユーザインタフェース部１３は、解析処理部１２で保持されている問題対処データをステップＳ１６、Ｓ１１、Ｓ６の順でＮＭＳ１０の画面上に表示する。
【００４２】
図８はＮＭＳ１０の表示画面の例を示す図である。表示画面１３ａには、番号、実行、状態変更要求、コマンドの項目が表示され、ボタンとして全選択ボタンＢ１、全選択解除ボタンＢ２、全実行ボタンＢ３、１コマンド実行ボタンＢ４、中止ボタンＢ５が表示される。
【００４３】
図の表示例は、上述の図７の解析処理で抽出された問題対処データ（すなわち、解析処理で読み出された状態変更要求及び対応するコマンド）と、オペレータが入力した状態変更要求（＃６）及びそのコマンドとを示している。
【００４４】
オペレータが、OS1-TC-3を削除しようとして、その旨の状態変更要求をＮＭＳ１０へ入力すると、ＮＭＳ１０が上述したステップＳ２〜Ｓ１９までの処理を自動的に行い、すべての問題対処データを抽出して画面上に表示する。
【００４５】
問題対処データが表示された後に、オペレータは全選択ボタンＢ１を押下すると、実行欄にチェックマークが表示される。そして、全実行ボタンＢ３を押下することにより、＃１から＃６の番号順に、状態変更要求に対応するコマンドが（コマンドはＮＭＳ１０内の装置通信部１４で生成される）、該当するＮＥへ順次送信される。
【００４６】
従来では、＃６に示すようにOS1-TC-3を削除しようとした場合は、＃１〜＃５までの内容をオペレータが調べる必要があったが、本発明では、＃６の内容をＮＭＳ１０へ入力するだけで、ＮＭＳ１０が＃１〜＃５を自動的に調査して表示、実行するので、保守管理効率を格段に向上させることが可能になる。
【００４７】
図９はＮＭＳ１０の表示画面の例を示す図である。表示画面１３ｂでは、オペレータが画面を見て全選択ボタンＢ１を押下するのではなく、実行したくないコマンドがあった場合の例を示している。
【００４８】
表示された問題対処データに対して、例えば、オペレータは＃４のOS1-TC-2を削除したくないとして、＃３の項目だけ指示して（＃１、＃２、＃３の実行欄にチェックマークが付く）、オペレータが全実行ボタンＢ３を押下したとする。
【００４９】
この場合、ＮＭＳ１０は＃３のコマンドだけでなく、＃１〜＃３のコマンドも実行する。すなわち、＃３のコマンドだけを該当のＮＥへ送信するのではなく、＃１〜＃３のコマンドを番号順に該当するＮＥへ送信することになる。
【００５０】
ここで全実行ボタンＢ３と１コマンド実行ボタンＢ４の違いについて述べると、全実行ボタンＢ３は実行欄でチェックされている状態変更要求をすべて実施する。また、１コマンド実行ボタンＢ４は実行欄でチェックされている状態変更要求のうち、まず＃１の状態変更要求を実施し、ボタンを押下する度に＃１、＃２・・・と１要求ずつ実行していく。
【００５１】
なぜなら、途中の＃ｋの状態変更要求を実行するためには、＃１〜＃ｋ−１の状態変更要求を先に実行しておく必要があるからである。したがって、ＮＭＳ１０の表示画面にすべての問題対処データが表示され、表示された問題対処データの中で、オペレータの判断で＃ｋの状態変更要求を行いたくないときは、オペレータは＃ｋ−１の状態変更要求のみを指示して、全実行ボタンＢ３を押下すれば、＃１〜＃ｋ−１の状態変更要求だけが実行されることになる。
【００５２】
以上説明したように、本発明のＮＭＳ１０は、オペレータが状態変更要求を入力すると、現在の装置状態に応じた適切な問題対処データを自動的に抽出・表示してくれるので、オペレータはその表示結果を見てボタン操作するだけでよい。したがって、従来のように、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった面倒な作業を大幅に省くことができるので、保守管理に対する作業効率及び利便性を著しく向上させることが可能になる。
【００５３】
次に問題を回避できない場合の動作について説明する。上記の説明では、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出することができたが、問題対処データの読み出し中に、途中で回避できない問題にぶつかったときは、その問題を回避不可原因として抽出し表示することになる。
【００５４】
図１０は装置状態テーブルの構成を示す図である。装置状態テーブルＴ１ａは、図２と異なる点はOS1-TC-1のstateがFLT（障害発生）であり、OS1-TC-1が正常動作していない点である。その他は同様である。
【００５５】
図１１はOS1-TC-3を削除する際の状態遷移を示す図である。回避不可原因がある場合の動作を示している。
〔Ｓ２１〕ステップＳ１〜ステップＳ１２と同じ処理である。
〔Ｓ２２〕解析処理部１２は、OS1-TC-1の現在の装置状態をテーブル格納部１１（図１０に示す装置状態テーブルＴ１ａ）から読み出す。装置状態の読み出し結果は、“OS1-TC-1のstateがFLT”である。
〔Ｓ２３〕解析処理部１２は、ステップＳ２２の読み出し結果（“OS1-TC-1のstateがFLT”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-2を保守状態にするためには、OS1-TC-1のstateがUASであることが必要だが、現在のOS1-TC-1のstateはFLTであるため、制約条件は満足していないと認識する。
〔Ｓ２４〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出そうとするが、装置状態の現状値ｔ３−１ａが障害発生の場合は（OS1-TC-1、state、FLT）、問題対処データは存在しないため問題回避できない（制約条件は解除できない）と認識する。
〔Ｓ２５〕解析処理部１２は、回避不可原因（“OS1-TC-1のstateがFLT”）を保持する。
〔Ｓ２６〕解析処理部１２は、回避不可原因を抽出したので、この時点で問題対処データの読み出し処理を停止する。
〔Ｓ２７〕ユーザインタフェース部１３は、解析処理部１２で保持されている回避不可原因及び問題対処データをＮＭＳ１０の画面上に表示する。
【００５６】
図１２はＮＭＳ１０の表示画面の例を示す図である。図の例は、上述の図１１で抽出された回避不可原因を示している表示である。図８で上述した表示画面１３ａと異なる点は、＃１の欄と、実行欄及び中止ボタンＢ５を除くボタンＢ１〜Ｂ４が、オペレータにより操作できないように表示されている点である（オペレータが操作できないことを図中点線で示している）。
【００５７】
ユーザインタフェース部１３は、OS1-TC-1に障害が発生している場合は、＃１の状態変更要求の欄に回避不可原因のコメント（“OS1-TC-1の障害を復旧させてから再度実行してください”）を表示する（対応するコマンドはないので、コマンド欄は空欄になる）。
【００５８】
また、この例の場合、最初にコマンドを送信すべきOS1-TC-1に障害が発生しているので、＃２以下のコマンドも送信することができない。したがって、ユーザインタフェース部１３は、すべての実行欄と、中止ボタンＢ５を除くボタンＢ１〜Ｂ４とが、オペレータにより操作できないように表示して、オペレータの誤操作を防止する。なお、このような画面が表示された場合は、オペレータは中止ボタンＢ５を押下してリセットし、障害を復旧させた後に、再び操作すればよい。
【００５９】
次に解析処理を実行する際のトリガについて説明する。上記の説明では、解析処理部１２が状態変更要求の正常性の解析処理を行う場合、オペレータからの状態変更要求に対応するコマンドが、ＮＥ２０へ送信される前に実行するものであった。
【００６０】
すなわち、ＮＭＳ１０は、オペレータからの状態変更要求を受信した場合に、制約条件を満たすような問題対処データや、あるいは回避不可原因を自動的に抽出して、表示制御した後、オペレータの指示にもとづいてコマンドを該当のＮＥへ送信するものであった（オペレータからの状態変更要求の入力が解析処理のトリガになっている）。
【００６１】
または、別の実施の形態として、オペレータからの状態変更要求に対応するコマンドがＮＥへ送信されてエラーレスポンスを受信した場合に、解析処理を行うようにしてもよい。
【００６２】
すなわち、ＮＭＳ１０は、オペレータからの状態変更要求を受信した場合に、その状態変更要求に対応するコマンドを生成して該当のＮＥへ即座に送信する。そして、そのＮＥからエラーレスポンスを受信した場合に初めて、制約条件を満たすような問題対処データや、あるいは回避不可原因を自動的に抽出したり、表示制御したりする（ＮＥからのエラーレスポンスの受信が解析処理のトリガになっている）。
【００６３】
このように、解析処理を行う場合は、オペレータからの状態変更要求の入力、またはＮＥからのエラーレスポンス受信のいずれをトリガにして行う。なお、最初のオペレータからの状態変更要求の入力に対して、何ら制約条件がなかった場合には、ＮＥからのエラーレスポンス受信をトリガにするようにＮＭＳ１０に設定しておいた方が、より速く処理することができる。
【００６４】
次に解析処理によりすべての問題対処データを抽出し、それらに対応するコマンドを生成してＮＥへ送信したにもかかわらず、エラーレスポンスを受信した場合の本発明の動作について説明する。
【００６５】
オペレータからの状態変更要求をＮＭＳ１０へ入力し、ＮＭＳ１０が解析処理を行って、すべての問題対処データを抽出して表示し、オペレータが全選択を操作して、対応するコマンドがＮＥへ送信されたとする。この場合、通常は、本発明によりすべての問題対処データに対応した、適切なコマンドを生成しているから、ＮＥからエラーレスポンスが送信されることはないはずである。
【００６６】
ところが、ＮＭＳが管理している装置状態と、ＮＥの現在の装置状態に不一致がある場合には、エラーレスポンスが送信される場合がありうる。したがって、解析処理を行った後にコマンドを送信し、エラーレスポンスを受信した場合は、本発明の解析処理部１２では、装置状態に不一致があるものとして、状態整合を行う。具体的には、各ＮＥへ現在の装置状態をあらためて取得しに行き、装置状態テーブルＴ１を作成し直す。その後に再度、解析処理を行うことになる。
【００６７】
次に本発明の動作についてフローチャートを用いて説明する。図１３は本発明の全体の動作を示すフローチャートである。図は、オペレータからの状態変更要求の入力を解析処理のトリガにした場合を示している。
〔Ｓ３１〕ユーザインタフェース部１３は、オペレータからの状態変更要求を受信する。
〔Ｓ３２〕ユーザインタフェース部１３は、状態変更要求のパラメータチェックを行う。パラメータに誤りがあったら、その旨を表示する。
〔Ｓ３３〕解析処理部１２は、テーブル格納部１１で格納管理されている装置状態テーブルＴ１、制約条件テーブルＴ２、問題対処テーブルＴ３を利用して、解析処理を行う。そして、問題対処データまたは回避不可原因を抽出し保持する。
〔Ｓ３４〕ユーザインタフェース部１３は、保持している問題対処データまたは回避不可原因を表示する。
〔Ｓ３５〕オペレータは、表示画面を見て、コマンド送信要求を行う。
〔Ｓ３６〕装置通信部１４は、問題対処データ（状態変更要求）に対応するコマンドを該当するＮＥへ送信する（コマンドは、問題対処データが解析処理部１２で保持されている時点で、装置通信部１４ですでに生成されている）。そして、ＮＥからのレスポンスを受信する。
〔Ｓ３７〕解析処理部１２は、レスポンスがエラーレスポンスか否かを判断する。エラーレスポンスでなければ、状態変更処理は完了である。エラーレスポンスであればステップＳ３８へ行く。
〔Ｓ３８〕解析処理部１２は、装置状態に不一致があるものとして、ＮＥへアクセスし、現在の装置状態を取得して、装置状態テーブルＴ１を書き替える。テーブル書き替え後、ステップＳ３３へ行き、再び解析処理を行う。
【００６８】
図１４は解析処理の動作を示すフローチャートである。解析処理部１２におけるステップＳ３３の詳細フローである。
〔Ｓ３３ａ〕状態変更要求（オペレータが入力した状態変更要求、または問題対処データに対応する状態変更要求）に対する制約条件を制約条件テーブルＴ２から読み出す。
〔Ｓ３３ｂ〕制約条件に該当する装置状態データを装置状態テーブルＴ１から読み出す。
〔Ｓ３３ｃ〕状態変更要求は、現在の装置状態で制約条件を満足するか否かを判断する。満足すれば図１３のステップＳ３４の表示制御へ行く。満足しなければステップＳ３３ｄへ行く。
〔Ｓ３３ｄ〕問題対処テーブルＴ３に対して、状態変更要求に対する問題対処データがあるか否かを判断する。問題対処データがなければステップＳ３３ｅへ行き、あればステップＳ３３ｆへ行く。
〔Ｓ３３ｅ〕回避不可原因を保持する。そして、図１３のステップＳ３４の表示制御へ行く。
〔Ｓ３３ｆ〕問題対処データを問題対処テーブルＴ３から読み出して保持する。そして、ステップＳ３３ａへ戻る。
【００６９】
以上説明したように、本発明によれば、ＮＭＳ１０が現在の装置状態に応じた適切な問題解決を自動的に抽出・実行してくれるので、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった作業の手間が省け、保守管理効率及び利便性の向上を図ることが可能になる。また、ＮＥのバージョンアップ等で制約条件が変更された場合でも、オペレータは、制約条件データ及び問題対処データだけを変更修正するだけでよいので作業効率の向上が図れる。
【００７０】
なお、上記では、ＮＥを伝送装置として、具体的なパラメータ名を用いて動作について説明したが、伝送装置に限らず、または属性としてstateだけに限らず、本発明はネットワークの管理手法として幅広い分野で適用可能である。
【００７１】
（付記１） ネットワークの管理を行うネットワーク管理装置において、
現在の装置状態を管理する装置状態テーブル、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブル、を格納するテーブル格納部と、
前記テーブル格納部内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部と、
ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部と、
問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する装置通信部と、
を有することを特徴とするネットワーク管理装置。
【００７２】
（付記２） 前記解析処理部は、オペレータからの状態変更要求に対応するコマンドが装置へ送信される前、またはオペレータからの状態変更要求に対応するコマンドが装置へ送信されてエラーレスポンスを受信した場合に、前記解析処理を自動的に行うことを特徴とする付記１記載のネットワーク管理装置。
【００７３】
（付記３） 前記解析処理部は、前記解析処理を行って、コマンドが装置へ送信され、エラーレスポンスを受信した場合は、装置状態をあらためて収集して状態整合を行い、再度、解析処理を行うことを特徴とする付記１記載のネットワーク管理装置。
【００７４】
（付記４） 前記装置通信部は、＃１〜＃ｎ（ｎは自然数）の問題対処データが表示されて、オペレータが＃ｋ（２≦ｋ＜ｎ）の問題対処データのみ指示した場合は、＃１〜＃ｋ−１の問題対処データに対応するコマンドを該当する装置へ送信することを特徴とする付記１記載のネットワーク管理装置。
【００７５】
（付記５） 前記ユーザインタフェース部は、回避不可原因がある場合には、オペレータが状態変更を実行できないように画面表示することを特徴とする付記１記載のネットワーク管理装置。
【００７６】
（付記６） ネットワークの管理を行うネットワーク管理システムにおいて、
ネットワークを構成するネットワーク装置と、
現在の装置状態を管理する装置状態テーブル、前記ネットワーク装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブル、を格納するテーブル格納部と、前記テーブル格納部内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部と、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部と、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して前記ネットワーク管理装置へ送信し、レスポンスを受信する装置通信部と、から構成されるネットワーク管理装置と、
を有することを特徴とするネットワーク管理システム。
【００７７】
（付記７） 前記解析処理部は、オペレータからの状態変更要求に対応するコマンドが装置へ送信される前、またはオペレータからの状態変更要求に対応するコマンドが装置へ送信されてエラーレスポンスを受信した場合に、前記解析処理を自動的に行うことを特徴とする付記６記載のネットワーク管理システム。
【００７８】
（付記８） 前記解析処理部は、前記解析処理を行って、コマンドが装置へ送信され、エラーレスポンスを受信した場合は、装置状態をあらためて収集して状態整合を行い、再度、解析処理を行うことを特徴とする付記６記載のネットワーク管理システム。
【００７９】
（付記９） 前記装置通信部は、＃１〜＃ｎ（ｎは自然数）の問題対処データが表示されて、オペレータが＃ｋ（２≦ｋ＜ｎ）の問題対処データのみ指示した場合は、＃１〜＃ｋ−１の問題対処データに対応するコマンドを該当する装置へ送信することを特徴とする付記６記載のネットワーク管理システム。
【００８０】
（付記１０） 前記ユーザインタフェース部は、回避不可原因がある場合には、オペレータが状態変更を実行できないように画面表示することを特徴とする付記６記載のネットワークシステム。
【００８１】
（付記１１） ネットワーク管理を行うネットワーク管理方法において、
現在の装置状態を管理する装置状態テーブル、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルを格納し、
テーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、
満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行い、
ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知し、
問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信してネットワーク管理を行うことを特徴とするネットワーク管理方法。
【００８２】
【発明の効果】
以上説明したように、本発明のネットワーク管理装置は、オペレータからの状態変更要求が、現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出する。また、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う。そして、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して、装置へ送信する構成とした。これにより、ネットワーク管理装置が、現在の装置状態に応じた適切な問題解決を自動的に実行してくれるので、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった作業の手間が省け、保守管理に対する作業効率及び利便性の向上を図ることが可能になる。
【図面の簡単な説明】
【図１】本発明のネットワーク管理装置の原理図である。
【図２】装置状態テーブルの構成例を示す図である。
【図３】制約条件テーブルの構成例を示す図である。
【図４】制約条件テーブルの構成例を示す図である。
【図５】問題対処テーブルの構成例を示す図である。
【図６】問題対処テーブルの構成例を示す図である。
【図７】 OS1-TC-3を削除する際の状態遷移を示す図である。
【図８】ＮＭＳの表示画面の例を示す図である。
【図９】ＮＭＳの表示画面の例を示す図である。
【図１０】装置状態テーブルの構成を示す図である。
【図１１】 OS1-TC-3を削除する際の状態遷移を示す図である。
【図１２】ＮＭＳの表示画面の例を示す図である。
【図１３】本発明の全体の動作を示すフローチャートである。
【図１４】解析処理の動作を示すフローチャートである。
【符号の説明】
１ ネットワーク管理システム
１ａ ネットワーク
１０ ネットワーク管理装置（ＮＭＳ）
１１ テーブル格納部
１２ 解析処理部
１３ ユーザインタフェース部
１４ 装置通信部
２０、２０−１〜２０−ｎ ネットワーク装置（ＮＥ）
Ｔ１ 装置状態テーブル
Ｔ２ 制約条件テーブル
Ｔ３ 問題対処テーブル
【発明の属する技術分野】
本発明はネットワーク管理装置に関し、特にネットワークの管理を行うネットワーク管理装置に関する。
【０００２】
【従来の技術】
近年、情報ネットワーク・サービスは、多種多様なものが求められ、これらのサービスを提供するための情報インフラストラクチャは、複雑化、巨大化している。このような状況の中で、ネットワークを構成する伝送装置などのネットワーク装置（ＮＥ：Network Element）の保守管理を行うネットワーク管理装置（ＮＭＳ：Network Management System）の需要が高まっている。
【０００３】
オペレータがＮＥの現在の状態を変更しようとした場合、状態変更要求をＮＭＳへ入力する。ＮＭＳは、オペレータからの状態変更要求を受けると、この要求に該当するコマンドを生成してＮＥへ送信し、そのレスポンスデータを受信する。これによりＮＥの状態が変更され、装置状態が管理される。また、ＮＥには、誤った運用設定がなされて、ネットワーク上に重大な障害を起すことがないように、通常は複雑な制約条件が設けられている。
【０００４】
制約条件とは、ＮＥの状態と、受け付け可能な状態変更要求との関係を定めた規則のことである（あるＮＥが状態Ａのときは状態変更要求Ａに関するコマンドは受け付けるが、状態変更要求Ｂに関するコマンドは受け付けないというように、ＮＥはコマンドを受け付けるための条件（制約条件）を持っているということ）。
【０００５】
したがって、オペレータは、制約条件を満足するように状態変更要求を行う必要がある。ＮＥは、状態変更要求のコマンドを受信した場合、そのときの装置状態によって、コマンドが制約条件を満足していれば受け付け、満足していない場合には、そのコマンドに対するエラーレスポンスをＮＭＳへ返送する。
【０００６】
【発明が解決しようとする課題】
オペレータは、コマンド送信等に関する履歴（操作履歴）を効率よく管理するためには、無駄なオペレーションを省く必要がある。したがって、ＮＥに状態変更要求を行う場合、現在のＮＥの状態で、制約条件を満足するか否かを事前に確認して、正常な状態変更要求を送信することで、ＮＥからのエラーレスポンスをできるだけ受信しないことが望ましい。
【０００７】
しかし、従来の管理制御では、制約条件を確認するためには、新規導入または既設のＮＥに対し、オペレータがＮＥの取扱説明書やヘルプ機能等を用いて、状態変更要求の制約条件をあらかじめ調査しなければならず、さらに、オペレータ自身が、その制約条件を現在の装置状態が満足しているか否かを判断しなければならなかった。このため、作業にはかなりの手間がかかり、保守管理における利便性が低いといった問題があった。
【０００８】
また、状態変更要求に関するコマンドがＮＥで受け付けられず、エラーレスポンスが返送された場合、どのような問題対処をすれば、ＮＥがそのコマンドを受け付けられるかを、オペレータがエラー内容、ＮＥの現在の装置状態、制約条件などから調査しなければならなかった。さらに、調査後に複数の問題対処があることがわかった場合、オペレータがそれらの問題対処による操作を逐一実行していく必要があった。このように、従来のネットワーク管理では、オペレータの負担が大きく効率的でなかった。
【０００９】
一方、ネットワーク管理技術の従来技術として例えば、特開２０００−３３９２８９号公報が提案されている。これは、エラー内容から想定される問題原因、対処方法をあらかじめ作成して保持しておき、エラーが発生した場合、対応する問題原因、対処方法をヘルプ機能で表示し、オペレータが問題原因を判断して、再度コマンドを投入するものである。
【００１０】
ところが、この従来技術では、ＮＥの現在の運用状態を考慮していないため、現時点での問題原因が明確に特定できない。このため、想定される複数の問題対処から、オペレータが結局、問題原因や対処方法を調査する必要があるために、作業効率の向上が望めなかった。また、対処方法をあらかじめ作成する方法では、問題原因に関する対処の手順をすべて記載しておく必要があるが、この場合、現在運用している装置状態として不要な手順も含まれることになり、管理効率の向上が望めなかった。
【００１１】
本発明はこのような点に鑑みてなされたものであり、現在のＮＥの状態に応じた適切な問題解決を実行して、保守管理に対する作業効率及び利便性の向上を図ったネットワーク管理装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような、ネットワークの管理を行うネットワーク管理装置１０において、現在の装置状態を管理する装置状態テーブルＴ１、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブルＴ２、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルＴ３、を格納するテーブル格納部１１と、テーブル格納部１１内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部１２と、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部１３と、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する装置通信部１４と、を有することを特徴とするネットワーク管理装置１０が提供される。
【００１３】
ここで、テーブル格納部１１は、現在の装置状態を管理する装置状態テーブルＴ１、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブルＴ２、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルＴ３を格納する。解析処理部１２は、テーブル格納部１１内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う。ユーザインタフェース部１３は、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知する。装置通信部１４は、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１はネットワーク管理装置の原理図である。ネットワーク管理システム１は、ネットワーク１ａを構成するネットワーク装置（以下、ＮＥまたは単に装置と呼ぶ）２０−１〜２０−ｎと、ＮＥ２０−１〜２０−ｎを管理するネットワーク管理装置（以下、ＮＭＳ）１０で構成される。
【００１５】
ＮＭＳ１０に対し、テーブル格納部１１は、装置状態テーブルＴ１、制約条件テーブルＴ２、問題対処テーブルＴ３を格納管理する。装置状態テーブルＴ１は、ＮＥ２０−１〜２０−ｎ（総称する場合はＮＥ２０とする）の現在の装置状態を管理するテーブルである。
【００１６】
制約条件テーブルＴ２は、ＮＥ２０が状態変更要求を受け付けるための制約条件を管理するテーブルである。問題対処テーブルＴ３は、制約の原因になっている問題に対処するための問題対処データを管理するテーブルである。なお、システム運用中でも各データの値は必要に応じて書き替え可能である。各テーブルの詳細は図２〜図６で後述する。
【００１７】
解析処理部１２は、状態変更要求の正常性の解析処理を行う。具体的にはまず、状態変更要求が現在の装置状態で制約条件を満足しているか否かを、テーブル格納部１１で格納されている各種データにもとづき判断する。
【００１８】
そして、制約条件を満足していないが問題を回避できる場合は、制約がかかっている問題がすべてなくなるまで、すべての問題対処データを抽出する。また、制約条件が満足していなく、かつ問題を回避できない場合には、回避できない原因である回避不可原因を抽出する。詳細は図７以降で後述する。
【００１９】
ユーザインタフェース部１３は、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知（表示制御）する。装置通信部１４は、ＮＥ２０へコマンドを送信したり、ＮＥ２０からレスポンスを受信したりする。例えば、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成してＮＥ２０へ送信し、そのレスポンスを受信する。
【００２０】
次にテーブル格納部１１について図２〜図６を用いて説明する（なお、図２〜図６中のＳ※の符号は、本発明の動作説明を行うために付した符号であり、図７以降で用いる）。図２は装置状態テーブルの構成例を示す図である。装置状態テーブルＴ１は、装置状態のデータを管理するテーブルであり、装置構成要素名、属性名、属性値の項目からなる。例えば図では、装置名がOS1-TC-1であるＮＥのstate（現在の運用状態）は、ＩＳ−ＮＲ（サービス中）になっている。
【００２１】
なお、本発明では、属性名としてはstateを扱うため、図中の他の属性名（vendid、dom、cleli）及び対応する属性値（FC9518AIA1、01.09、WM2WHR0CAA）についての説明は省略する。
【００２２】
図３、図４は制約条件テーブルの構成例を示す図である。制約条件テーブルＴ２は、ＮＥへの要求内容ｔ２−１、制約条件ｔ２−２、実行権限ｔ２−３、複数条件ｔ２−４、エラーコードｔ２−５の項目から構成される。また、ＮＥへの要求内容ｔ２−１は、状態変更要求名、装置構成要素名、属性名、属性値の項目から構成され、制約条件ｔ２−２は、符号、装置構成要素名、属性名、属性値の項目から構成され、実行権限ｔ２−３は、ＮＭＳと装置の項目から構成され、複数条件ｔ２−４は、連結と論理関係の項目から構成される。
【００２３】
テーブルの見方について説明する。ＮＥへの要求内容ｔ２−１に記載されている要求が受け付けられるためには、制約条件ｔ２−２に記載されている条件を満たす必要がある。データの２行目を例にすると、ＮＥへの要求内容ｔ２−１として、状態変更要求名がED-EQPT（保守状態に変更する要求）、装置構成要素名がOS1-TC-2、属性名がstate、属性値がOOS-MA（保守状態）となっている。
【００２４】
また、制約条件ｔ２−２として、符号＝１（符号については後述する）、装置構成要素名がOS1-TC-1、属性名がstate、属性値がUAS（削除状態：未登録状態のこと）となっている。
【００２５】
これは、装置名がOS1-TC-2のＮＥに対して、状態変更要求をED-EQPTにして、OS1-TC-2の運用状態をOOS-MAに変更するには、制約条件として、装置名OS1-TC-1のＮＥがUASになっていなければならないということである。すなわち、OS1-TC-1がUASでなければ、OS1-TC-2はOOS-MAへ状態遷移できないということである。
【００２６】
また、同様にして、４行目のデータを例にすれば、装置名がOS1-TC-1のＮＥに対して、状態変更要求をDLT-EQPT（削除状態に変更する要求）にして、OS1-TC-1の運用状態をUASに変更するには、制約条件として、OS1-TC-1がOOS-MAになっていなければならないということである。すなわち、OS1-TC-1はOOS-MAでなければ、OS1-TC-1はUASへ状態遷移できないということである。
【００２７】
ここで、符号、実行権限ｔ２−３、複数条件ｔ２−４、エラーコードｔ２−５について説明する。符号＝１の場合は、制約条件ｔ２−２に記載されたデータであること、符号＝２の場合は、制約条件ｔ２−２に記載されたデータでないことという意味である。
【００２８】
例えば、データ２行目のＮＥへの要求内容ｔ２−１に対し、図では符号＝１なので、制約条件は、OS1-TC-1がUASであること、ということである（もし、符号＝２であったならば、OS1-TC-1がUASでないこと、という内容が制約条件になる）。
【００２９】
実行権限ｔ２−３とは、ＮＥへ状態変更要求を行うために必要なオペレータの権限であり、図に示す“３”とはオペレータに権限があることを示している数字である。また、実行権限ｔ２−３のＮＭＳとは、ＮＭＳ１０にloginしているユーザの権限を示し、実行権限ｔ２−３の装置とは、ＮＭＳ１０からＮＥにloginしているユーザの権限を示す。
【００３０】
複数条件ｔ２−４とは、制約条件ｔ２−２の内容が次の行に続くか否かを示すものである。制約条件ｔ２−２の内容が次の行に続く場合は、複数条件ｔ２−４の連結がＹと記載され、続かない場合はＮと記載される。また、複数条件ｔ２−４の論理関係とは、制約条件ｔ２−２が次の行に続く場合の論理（ＡＮＤ、ＯＲなど）を示す。
【００３１】
例えば、データ２行目の複数条件ｔ２−４の連結が、図ではＮと記載されて論理関係は記載なしであるから、２行目の制約条件ｔ２−２の内容は次の行には続かないことになる（すなわち、制約条件はOS1-TC-1がUASであること）。また、もしデータ２行目の複数条件ｔ２−４の連結がＹ、論理関係がＡＮＤと記載され、３行目の複数条件ｔ２−４の連結がＮ、論理関係が記載されてなければ、制約条件は３行目まで続く。すなわち、２行目のＮＥへの要求内容ｔ２−１を満たすためには、この場合、OS1-TC-1がUASで、かつOS1-TC-2がUASであることが制約条件となる。
【００３２】
エラーコードｔ２−５とは、ＮＥへの要求内容ｔ２−１に記載されている要求があった場合に、制約条件ｔ２−２を満足していないときは、どのようなエラーのコードを出力するかということが記載された欄である。図の場合、それぞれの行の要求が制約条件ｔ２−２を満足していないときは、すべてＳＮＶＳというコードをエラーコードとして出力するようになっている。
【００３３】
図５、図６は問題対処テーブルの構成例を示す図である。なお、本発明でいう“問題”とは制約条件と同等の意味で使っている。したがって、“問題を解決する”とは、制約条件を満足するということであり、また、問題対処とは、制約条件を満足するためには、どのような対処をすればよいかということである。さらに、問題対処データとは、制約条件満足データのことで、制約条件を満足するための状態変更要求ということにもなる。
【００３４】
問題対処テーブルＴ３は、変更条件ｔ３−１、問題対処データの内容ｔ３−２の項目から構成される。変更条件ｔ３−１は、さらに装置状態の現状値ｔ３−１ａ、装置状態の変更値ｔ３−１ｂからなり、装置状態の現状値ｔ３−１ａ及び装置状態の変更値ｔ３−１ｂそれぞれは、装置構成要素名、属性名、属性値からなる。また、問題対処データの内容ｔ３−２は、有無、状態変更要求名、装置構成要素名、属性名、属性値、コメントからなる。
【００３５】
テーブルの見方について説明する。問題対処テーブルＴ３には、装置状態の変更値ｔ３−１ｂに記載されている属性値に変更するための、装置状態の現状値ｔ３−１ａに記載されている現状の属性値に応じた、問題対処データが記載されている。
【００３６】
例えば、OS1-TC-1をUASに変更したい場合（図のデータ３行目）、OS1-TC-1の現状の状態がIS-NRのときは、問題対処データとして、状態変更要求をED-EQPTにして、OS1-TC-1をOOS-MAに変更し、その後、状態変更要求をDLT-EQPTにして、OS1-TC-1を削除する、ということが記載されている。
【００３７】
すなわち、IS-NR中のOS1-TC-1をUASの状態に変更するには、OS1-TC-1を一旦OOS-MAに変更した後にOS1-TC-1を削除（未登録）する。このようにOS1-TC-1の状態を削除状態にして、UASへ状態変更するためのコマンドを送信すれば、OS1-TC-1はそのコマンドを受け付けることができる。
【００３８】
また、OS1-TC-1をUASに変更したい場合（図のデータ４行目）、OS1-TC-1の現状の状態がOOS-MAのときは、問題対処データとして、状態変更要求をDLT-EQPTにして、OS1-TC-1を削除する、ということが記載されている。
【００３９】
すなわち、OOS-MA中のOS1-TC-1をUASの状態に変更するには、OS1-TC-1を削除する。このようにOS1-TC-1の状態を削除状態にして、UASへ状態変更するためのコマンドを送信すれば、OS1-TC-1はそのコマンドを受け付けることができる。
【００４０】
なお、テーブル中の項目“有無”とは、問題対処データがあれば有（図６では有を“１”）、なければ無（図６で無を“２”）と記載される。また、コメントは、問題対処データの内容を示すものである（問題対処データとして、このコメントがＮＭＳ１０の画面上に表示される）。
【００４１】
次に本発明の動作について詳しく説明する。ここでは、装置名がOS1-TC-3のＮＥを削除（未登録）する動作について、図２〜図６に示した各種データを利用して具体的に説明する。図７はOS1-TC-3を削除する際の状態遷移を示す図である。
〔Ｓ１〕オペレータは、OS1-TC-3を削除しようとして、その旨の状態変更要求をユーザインタフェース部１３を介しＮＭＳ１０へ入力する。
〔Ｓ２〕ＮＭＳ１０の解析処理部１２は、OS1-TC-3削除の内容の状態変更要求に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-3のstateがOOS-MAであること”である。
〔Ｓ３〕解析処理部１２は、OS1-TC-3の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-3のstateがIS-NR”である。
〔Ｓ４〕解析処理部１２は、オペレータからの状態変更要求が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-3を削除するためには、OS1-TC-3のstateがOOS-MAであることが必要だが、現在のOS1-TC-3のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ５〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-3、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-3、state、OOS-MA）に対する問題対処データは、“OS1-TC-3へstate=OOS-MAのED-EQPTコマンドを投入”であることを認識する（OS1-TC-3を保守状態にすること）。
〔Ｓ６〕解析処理部１２は、ステップＳ５で読み出した問題対処データを保持する。
〔Ｓ７〕解析処理部１２は、“OS1-TC-3へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-3を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-2のstateがUAS”である。
〔Ｓ８〕解析処理部１２は、OS1-TC-2の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-2のstateがIS-NR”である。
〔Ｓ９〕解析処理部１２は、ステップＳ８の読み出し結果（“OS1-TC-2のstateがIS-NR”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-3を保守状態にするためには、OS1-TC-2のstateがUASであることが必要だが、現在のOS1-TC-2のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ１０〕解析処理部１２は、問題対処テーブルをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-2、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-2、state、UAS）に対する問題対処データは、“OS1-TC-2へstate=OOS-MAのED-EQPTコマンド投入後、DLT-EQPTコマンドを投入”であることを認識する（OS1-TC-2を保守状態にした後に削除すること）。
〔Ｓ１１〕解析処理部１２は、ステップＳ１０で読み出した問題対処データを保持する。
〔Ｓ１２〕解析処理部１２は、“OS1-TC-2へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-2を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。制約条件の読み出し結果は、“OS1-TC-1のstateがUAS”である。
〔Ｓ１３〕解析処理部１２は、OS1-TC-１の現在の装置状態をテーブル格納部１１（図２に示す装置状態テーブルＴ１）から読み出す。装置状態の読み出し結果は、“OS1-TC-１のstateがIS-NR”である。
〔Ｓ１４〕解析処理部１２は、ステップＳ１３の読み出し結果（“OS1-TC-1のstateがIS-NR”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-2を保守状態にするためには、OS1-TC-1のstateがUASであることが必要だが、現在のOS1-TC-1のstateはIS-NRであるため、制約条件は満足していないと認識する。
〔Ｓ１５〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出す。装置状態の現状値ｔ３−１ａ（OS1-TC-1、state、IS-NR）から装置状態の変更値ｔ３−１ｂ（OS1-TC-1、state、UAS）に対する問題対処データは、“OS1-TC-1へstate=OOS-MAのED-EQPTコマンド投入後、DLT-EQPTコマンドを投入”であることを認識する（OS1-TC-1を保守状態にした後に削除すること）。
〔Ｓ１６〕解析処理部１２は、ステップＳ１５で読み出した問題対処データを保持する。
〔Ｓ１７〕解析処理部１２は、“OS1-TC-1へstate=OOS-MAのED-EQPTコマンド投入”（OS1-TC-1を保守状態にするための状態変更要求に該当する）に対する制約条件をテーブル格納部１１（図３、図４に示す制約条件テーブルＴ２）から読み出す。テーブル中に記載事項がないので、制約条件の読み出し結果は、“制約条件なし”となる。
〔Ｓ１８〕解析処理部１２は、ステップＳ１７の読み出し結果が“制約条件なし”なので、すべての問題対処データを抽出したことを認識する。
〔Ｓ１９〕ユーザインタフェース部１３は、解析処理部１２で保持されている問題対処データをステップＳ１６、Ｓ１１、Ｓ６の順でＮＭＳ１０の画面上に表示する。
【００４２】
図８はＮＭＳ１０の表示画面の例を示す図である。表示画面１３ａには、番号、実行、状態変更要求、コマンドの項目が表示され、ボタンとして全選択ボタンＢ１、全選択解除ボタンＢ２、全実行ボタンＢ３、１コマンド実行ボタンＢ４、中止ボタンＢ５が表示される。
【００４３】
図の表示例は、上述の図７の解析処理で抽出された問題対処データ（すなわち、解析処理で読み出された状態変更要求及び対応するコマンド）と、オペレータが入力した状態変更要求（＃６）及びそのコマンドとを示している。
【００４４】
オペレータが、OS1-TC-3を削除しようとして、その旨の状態変更要求をＮＭＳ１０へ入力すると、ＮＭＳ１０が上述したステップＳ２〜Ｓ１９までの処理を自動的に行い、すべての問題対処データを抽出して画面上に表示する。
【００４５】
問題対処データが表示された後に、オペレータは全選択ボタンＢ１を押下すると、実行欄にチェックマークが表示される。そして、全実行ボタンＢ３を押下することにより、＃１から＃６の番号順に、状態変更要求に対応するコマンドが（コマンドはＮＭＳ１０内の装置通信部１４で生成される）、該当するＮＥへ順次送信される。
【００４６】
従来では、＃６に示すようにOS1-TC-3を削除しようとした場合は、＃１〜＃５までの内容をオペレータが調べる必要があったが、本発明では、＃６の内容をＮＭＳ１０へ入力するだけで、ＮＭＳ１０が＃１〜＃５を自動的に調査して表示、実行するので、保守管理効率を格段に向上させることが可能になる。
【００４７】
図９はＮＭＳ１０の表示画面の例を示す図である。表示画面１３ｂでは、オペレータが画面を見て全選択ボタンＢ１を押下するのではなく、実行したくないコマンドがあった場合の例を示している。
【００４８】
表示された問題対処データに対して、例えば、オペレータは＃４のOS1-TC-2を削除したくないとして、＃３の項目だけ指示して（＃１、＃２、＃３の実行欄にチェックマークが付く）、オペレータが全実行ボタンＢ３を押下したとする。
【００４９】
この場合、ＮＭＳ１０は＃３のコマンドだけでなく、＃１〜＃３のコマンドも実行する。すなわち、＃３のコマンドだけを該当のＮＥへ送信するのではなく、＃１〜＃３のコマンドを番号順に該当するＮＥへ送信することになる。
【００５０】
ここで全実行ボタンＢ３と１コマンド実行ボタンＢ４の違いについて述べると、全実行ボタンＢ３は実行欄でチェックされている状態変更要求をすべて実施する。また、１コマンド実行ボタンＢ４は実行欄でチェックされている状態変更要求のうち、まず＃１の状態変更要求を実施し、ボタンを押下する度に＃１、＃２・・・と１要求ずつ実行していく。
【００５１】
なぜなら、途中の＃ｋの状態変更要求を実行するためには、＃１〜＃ｋ−１の状態変更要求を先に実行しておく必要があるからである。したがって、ＮＭＳ１０の表示画面にすべての問題対処データが表示され、表示された問題対処データの中で、オペレータの判断で＃ｋの状態変更要求を行いたくないときは、オペレータは＃ｋ−１の状態変更要求のみを指示して、全実行ボタンＢ３を押下すれば、＃１〜＃ｋ−１の状態変更要求だけが実行されることになる。
【００５２】
以上説明したように、本発明のＮＭＳ１０は、オペレータが状態変更要求を入力すると、現在の装置状態に応じた適切な問題対処データを自動的に抽出・表示してくれるので、オペレータはその表示結果を見てボタン操作するだけでよい。したがって、従来のように、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった面倒な作業を大幅に省くことができるので、保守管理に対する作業効率及び利便性を著しく向上させることが可能になる。
【００５３】
次に問題を回避できない場合の動作について説明する。上記の説明では、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出することができたが、問題対処データの読み出し中に、途中で回避できない問題にぶつかったときは、その問題を回避不可原因として抽出し表示することになる。
【００５４】
図１０は装置状態テーブルの構成を示す図である。装置状態テーブルＴ１ａは、図２と異なる点はOS1-TC-1のstateがFLT（障害発生）であり、OS1-TC-1が正常動作していない点である。その他は同様である。
【００５５】
図１１はOS1-TC-3を削除する際の状態遷移を示す図である。回避不可原因がある場合の動作を示している。
〔Ｓ２１〕ステップＳ１〜ステップＳ１２と同じ処理である。
〔Ｓ２２〕解析処理部１２は、OS1-TC-1の現在の装置状態をテーブル格納部１１（図１０に示す装置状態テーブルＴ１ａ）から読み出す。装置状態の読み出し結果は、“OS1-TC-1のstateがFLT”である。
〔Ｓ２３〕解析処理部１２は、ステップＳ２２の読み出し結果（“OS1-TC-1のstateがFLT”）が、制約条件を満足しているか否かを判断する。ここでは、OS1-TC-2を保守状態にするためには、OS1-TC-1のstateがUASであることが必要だが、現在のOS1-TC-1のstateはFLTであるため、制約条件は満足していないと認識する。
〔Ｓ２４〕解析処理部１２は、問題対処データをテーブル格納部１１（図５、図６に示した問題対処テーブルＴ３）から読み出そうとするが、装置状態の現状値ｔ３−１ａが障害発生の場合は（OS1-TC-1、state、FLT）、問題対処データは存在しないため問題回避できない（制約条件は解除できない）と認識する。
〔Ｓ２５〕解析処理部１２は、回避不可原因（“OS1-TC-1のstateがFLT”）を保持する。
〔Ｓ２６〕解析処理部１２は、回避不可原因を抽出したので、この時点で問題対処データの読み出し処理を停止する。
〔Ｓ２７〕ユーザインタフェース部１３は、解析処理部１２で保持されている回避不可原因及び問題対処データをＮＭＳ１０の画面上に表示する。
【００５６】
図１２はＮＭＳ１０の表示画面の例を示す図である。図の例は、上述の図１１で抽出された回避不可原因を示している表示である。図８で上述した表示画面１３ａと異なる点は、＃１の欄と、実行欄及び中止ボタンＢ５を除くボタンＢ１〜Ｂ４が、オペレータにより操作できないように表示されている点である（オペレータが操作できないことを図中点線で示している）。
【００５７】
ユーザインタフェース部１３は、OS1-TC-1に障害が発生している場合は、＃１の状態変更要求の欄に回避不可原因のコメント（“OS1-TC-1の障害を復旧させてから再度実行してください”）を表示する（対応するコマンドはないので、コマンド欄は空欄になる）。
【００５８】
また、この例の場合、最初にコマンドを送信すべきOS1-TC-1に障害が発生しているので、＃２以下のコマンドも送信することができない。したがって、ユーザインタフェース部１３は、すべての実行欄と、中止ボタンＢ５を除くボタンＢ１〜Ｂ４とが、オペレータにより操作できないように表示して、オペレータの誤操作を防止する。なお、このような画面が表示された場合は、オペレータは中止ボタンＢ５を押下してリセットし、障害を復旧させた後に、再び操作すればよい。
【００５９】
次に解析処理を実行する際のトリガについて説明する。上記の説明では、解析処理部１２が状態変更要求の正常性の解析処理を行う場合、オペレータからの状態変更要求に対応するコマンドが、ＮＥ２０へ送信される前に実行するものであった。
【００６０】
すなわち、ＮＭＳ１０は、オペレータからの状態変更要求を受信した場合に、制約条件を満たすような問題対処データや、あるいは回避不可原因を自動的に抽出して、表示制御した後、オペレータの指示にもとづいてコマンドを該当のＮＥへ送信するものであった（オペレータからの状態変更要求の入力が解析処理のトリガになっている）。
【００６１】
または、別の実施の形態として、オペレータからの状態変更要求に対応するコマンドがＮＥへ送信されてエラーレスポンスを受信した場合に、解析処理を行うようにしてもよい。
【００６２】
すなわち、ＮＭＳ１０は、オペレータからの状態変更要求を受信した場合に、その状態変更要求に対応するコマンドを生成して該当のＮＥへ即座に送信する。そして、そのＮＥからエラーレスポンスを受信した場合に初めて、制約条件を満たすような問題対処データや、あるいは回避不可原因を自動的に抽出したり、表示制御したりする（ＮＥからのエラーレスポンスの受信が解析処理のトリガになっている）。
【００６３】
このように、解析処理を行う場合は、オペレータからの状態変更要求の入力、またはＮＥからのエラーレスポンス受信のいずれをトリガにして行う。なお、最初のオペレータからの状態変更要求の入力に対して、何ら制約条件がなかった場合には、ＮＥからのエラーレスポンス受信をトリガにするようにＮＭＳ１０に設定しておいた方が、より速く処理することができる。
【００６４】
次に解析処理によりすべての問題対処データを抽出し、それらに対応するコマンドを生成してＮＥへ送信したにもかかわらず、エラーレスポンスを受信した場合の本発明の動作について説明する。
【００６５】
オペレータからの状態変更要求をＮＭＳ１０へ入力し、ＮＭＳ１０が解析処理を行って、すべての問題対処データを抽出して表示し、オペレータが全選択を操作して、対応するコマンドがＮＥへ送信されたとする。この場合、通常は、本発明によりすべての問題対処データに対応した、適切なコマンドを生成しているから、ＮＥからエラーレスポンスが送信されることはないはずである。
【００６６】
ところが、ＮＭＳが管理している装置状態と、ＮＥの現在の装置状態に不一致がある場合には、エラーレスポンスが送信される場合がありうる。したがって、解析処理を行った後にコマンドを送信し、エラーレスポンスを受信した場合は、本発明の解析処理部１２では、装置状態に不一致があるものとして、状態整合を行う。具体的には、各ＮＥへ現在の装置状態をあらためて取得しに行き、装置状態テーブルＴ１を作成し直す。その後に再度、解析処理を行うことになる。
【００６７】
次に本発明の動作についてフローチャートを用いて説明する。図１３は本発明の全体の動作を示すフローチャートである。図は、オペレータからの状態変更要求の入力を解析処理のトリガにした場合を示している。
〔Ｓ３１〕ユーザインタフェース部１３は、オペレータからの状態変更要求を受信する。
〔Ｓ３２〕ユーザインタフェース部１３は、状態変更要求のパラメータチェックを行う。パラメータに誤りがあったら、その旨を表示する。
〔Ｓ３３〕解析処理部１２は、テーブル格納部１１で格納管理されている装置状態テーブルＴ１、制約条件テーブルＴ２、問題対処テーブルＴ３を利用して、解析処理を行う。そして、問題対処データまたは回避不可原因を抽出し保持する。
〔Ｓ３４〕ユーザインタフェース部１３は、保持している問題対処データまたは回避不可原因を表示する。
〔Ｓ３５〕オペレータは、表示画面を見て、コマンド送信要求を行う。
〔Ｓ３６〕装置通信部１４は、問題対処データ（状態変更要求）に対応するコマンドを該当するＮＥへ送信する（コマンドは、問題対処データが解析処理部１２で保持されている時点で、装置通信部１４ですでに生成されている）。そして、ＮＥからのレスポンスを受信する。
〔Ｓ３７〕解析処理部１２は、レスポンスがエラーレスポンスか否かを判断する。エラーレスポンスでなければ、状態変更処理は完了である。エラーレスポンスであればステップＳ３８へ行く。
〔Ｓ３８〕解析処理部１２は、装置状態に不一致があるものとして、ＮＥへアクセスし、現在の装置状態を取得して、装置状態テーブルＴ１を書き替える。テーブル書き替え後、ステップＳ３３へ行き、再び解析処理を行う。
【００６８】
図１４は解析処理の動作を示すフローチャートである。解析処理部１２におけるステップＳ３３の詳細フローである。
〔Ｓ３３ａ〕状態変更要求（オペレータが入力した状態変更要求、または問題対処データに対応する状態変更要求）に対する制約条件を制約条件テーブルＴ２から読み出す。
〔Ｓ３３ｂ〕制約条件に該当する装置状態データを装置状態テーブルＴ１から読み出す。
〔Ｓ３３ｃ〕状態変更要求は、現在の装置状態で制約条件を満足するか否かを判断する。満足すれば図１３のステップＳ３４の表示制御へ行く。満足しなければステップＳ３３ｄへ行く。
〔Ｓ３３ｄ〕問題対処テーブルＴ３に対して、状態変更要求に対する問題対処データがあるか否かを判断する。問題対処データがなければステップＳ３３ｅへ行き、あればステップＳ３３ｆへ行く。
〔Ｓ３３ｅ〕回避不可原因を保持する。そして、図１３のステップＳ３４の表示制御へ行く。
〔Ｓ３３ｆ〕問題対処データを問題対処テーブルＴ３から読み出して保持する。そして、ステップＳ３３ａへ戻る。
【００６９】
以上説明したように、本発明によれば、ＮＭＳ１０が現在の装置状態に応じた適切な問題解決を自動的に抽出・実行してくれるので、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった作業の手間が省け、保守管理効率及び利便性の向上を図ることが可能になる。また、ＮＥのバージョンアップ等で制約条件が変更された場合でも、オペレータは、制約条件データ及び問題対処データだけを変更修正するだけでよいので作業効率の向上が図れる。
【００７０】
なお、上記では、ＮＥを伝送装置として、具体的なパラメータ名を用いて動作について説明したが、伝送装置に限らず、または属性としてstateだけに限らず、本発明はネットワークの管理手法として幅広い分野で適用可能である。
【００７１】
（付記１） ネットワークの管理を行うネットワーク管理装置において、
現在の装置状態を管理する装置状態テーブル、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブル、を格納するテーブル格納部と、
前記テーブル格納部内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部と、
ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部と、
問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する装置通信部と、
を有することを特徴とするネットワーク管理装置。
【００７２】
（付記２） 前記解析処理部は、オペレータからの状態変更要求に対応するコマンドが装置へ送信される前、またはオペレータからの状態変更要求に対応するコマンドが装置へ送信されてエラーレスポンスを受信した場合に、前記解析処理を自動的に行うことを特徴とする付記１記載のネットワーク管理装置。
【００７３】
（付記３） 前記解析処理部は、前記解析処理を行って、コマンドが装置へ送信され、エラーレスポンスを受信した場合は、装置状態をあらためて収集して状態整合を行い、再度、解析処理を行うことを特徴とする付記１記載のネットワーク管理装置。
【００７４】
（付記４） 前記装置通信部は、＃１〜＃ｎ（ｎは自然数）の問題対処データが表示されて、オペレータが＃ｋ（２≦ｋ＜ｎ）の問題対処データのみ指示した場合は、＃１〜＃ｋ−１の問題対処データに対応するコマンドを該当する装置へ送信することを特徴とする付記１記載のネットワーク管理装置。
【００７５】
（付記５） 前記ユーザインタフェース部は、回避不可原因がある場合には、オペレータが状態変更を実行できないように画面表示することを特徴とする付記１記載のネットワーク管理装置。
【００７６】
（付記６） ネットワークの管理を行うネットワーク管理システムにおいて、
ネットワークを構成するネットワーク装置と、
現在の装置状態を管理する装置状態テーブル、前記ネットワーク装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブル、を格納するテーブル格納部と、前記テーブル格納部内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部と、ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部と、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して前記ネットワーク管理装置へ送信し、レスポンスを受信する装置通信部と、から構成されるネットワーク管理装置と、
を有することを特徴とするネットワーク管理システム。
【００７７】
（付記７） 前記解析処理部は、オペレータからの状態変更要求に対応するコマンドが装置へ送信される前、またはオペレータからの状態変更要求に対応するコマンドが装置へ送信されてエラーレスポンスを受信した場合に、前記解析処理を自動的に行うことを特徴とする付記６記載のネットワーク管理システム。
【００７８】
（付記８） 前記解析処理部は、前記解析処理を行って、コマンドが装置へ送信され、エラーレスポンスを受信した場合は、装置状態をあらためて収集して状態整合を行い、再度、解析処理を行うことを特徴とする付記６記載のネットワーク管理システム。
【００７９】
（付記９） 前記装置通信部は、＃１〜＃ｎ（ｎは自然数）の問題対処データが表示されて、オペレータが＃ｋ（２≦ｋ＜ｎ）の問題対処データのみ指示した場合は、＃１〜＃ｋ−１の問題対処データに対応するコマンドを該当する装置へ送信することを特徴とする付記６記載のネットワーク管理システム。
【００８０】
（付記１０） 前記ユーザインタフェース部は、回避不可原因がある場合には、オペレータが状態変更を実行できないように画面表示することを特徴とする付記６記載のネットワークシステム。
【００８１】
（付記１１） ネットワーク管理を行うネットワーク管理方法において、
現在の装置状態を管理する装置状態テーブル、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブルを格納し、
テーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、
満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行い、
ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知し、
問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信してネットワーク管理を行うことを特徴とするネットワーク管理方法。
【００８２】
【発明の効果】
以上説明したように、本発明のネットワーク管理装置は、オペレータからの状態変更要求が、現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出する。また、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う。そして、問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して、装置へ送信する構成とした。これにより、ネットワーク管理装置が、現在の装置状態に応じた適切な問題解決を自動的に実行してくれるので、オペレータが状態変更要求の制約条件をあらかじめ調査したりするなどといった作業の手間が省け、保守管理に対する作業効率及び利便性の向上を図ることが可能になる。
【図面の簡単な説明】
【図１】本発明のネットワーク管理装置の原理図である。
【図２】装置状態テーブルの構成例を示す図である。
【図３】制約条件テーブルの構成例を示す図である。
【図４】制約条件テーブルの構成例を示す図である。
【図５】問題対処テーブルの構成例を示す図である。
【図６】問題対処テーブルの構成例を示す図である。
【図７】 OS1-TC-3を削除する際の状態遷移を示す図である。
【図８】ＮＭＳの表示画面の例を示す図である。
【図９】ＮＭＳの表示画面の例を示す図である。
【図１０】装置状態テーブルの構成を示す図である。
【図１１】 OS1-TC-3を削除する際の状態遷移を示す図である。
【図１２】ＮＭＳの表示画面の例を示す図である。
【図１３】本発明の全体の動作を示すフローチャートである。
【図１４】解析処理の動作を示すフローチャートである。
【符号の説明】
１ ネットワーク管理システム
１ａ ネットワーク
１０ ネットワーク管理装置（ＮＭＳ）
１１ テーブル格納部
１２ 解析処理部
１３ ユーザインタフェース部
１４ 装置通信部
２０、２０−１〜２０−ｎ ネットワーク装置（ＮＥ）
Ｔ１ 装置状態テーブル
Ｔ２ 制約条件テーブル
Ｔ３ 問題対処テーブル
Claims (5)
- ネットワークの管理を行うネットワーク管理装置において、
現在の装置状態を管理する装置状態テーブル、装置が状態変更要求を受け付けるための制約条件を管理する制約条件テーブル、制約の原因になっている問題に対処するための問題対処データを管理する問題対処テーブル、を格納するテーブル格納部と、
前記テーブル格納部内のテーブルを利用して、状態変更要求が現在の装置状態で制約条件を満足しているか否かを判断し、満足していなく、かつ問題を回避できる場合は、制約がかかっている問題がなくなるまで、すべての問題対処データを抽出し、満足していなく、かつ問題を回避できない場合は、回避できない原因である回避不可原因を抽出して、状態変更要求の正常性の解析処理を行う解析処理部と、
ユーザインタフェース処理を行って、抽出した問題対処データまたは回避不可原因を通知するユーザインタフェース部と、
問題対処データにもとづき、問題を解決するための状態変更要求に対応するコマンドを生成して装置へ送信し、レスポンスを受信する装置通信部と、
を有することを特徴とするネットワーク管理装置。 - 前記解析処理部は、オペレータからの状態変更要求に対応するコマンドが装置へ送信される前、またはオペレータからの状態変更要求に対応するコマンドが装置へ送信されてエラーレスポンスを受信した場合に、前記解析処理を自動的に行うことを特徴とする請求項１記載のネットワーク管理装置。
- 前記解析処理部は、前記解析処理を行って、コマンドが装置へ送信され、エラーレスポンスを受信した場合は、装置状態をあらためて収集して状態整合を行い、再度、解析処理を行うことを特徴とする請求項１記載のネットワーク管理装置。
- 前記装置通信部は、＃１〜＃ｎ（ｎは自然数）の問題対処データが表示されて、オペレータが＃ｋ（２≦ｋ＜ｎ）の問題対処データのみ指示した場合は、＃１〜＃ｋ−１の問題対処データに対応するコマンドを該当する装置へ送信することを特徴とする請求項１記載のネットワーク管理装置。
- 前記ユーザインタフェース部は、回避不可原因がある場合には、オペレータが状態変更を実行できないように画面表示することを特徴とする請求項１記載のネットワーク管理装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002193093A JP3824972B2 (ja) | 2002-07-02 | 2002-07-02 | ネットワーク管理装置 |
| US10/402,178 US7395326B2 (en) | 2002-07-02 | 2003-03-27 | Network management apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002193093A JP3824972B2 (ja) | 2002-07-02 | 2002-07-02 | ネットワーク管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004040359A JP2004040359A (ja) | 2004-02-05 |
| JP3824972B2 true JP3824972B2 (ja) | 2006-09-20 |
Family
ID=29996993
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002193093A Expired - Fee Related JP3824972B2 (ja) | 2002-07-02 | 2002-07-02 | ネットワーク管理装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7395326B2 (ja) |
| JP (1) | JP3824972B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060168173A1 (en) * | 2004-12-15 | 2006-07-27 | Cisco Technology, Inc. | Method and apparatus for conditional application of management commands |
| EP1925118A4 (en) | 2005-03-31 | 2010-10-13 | Bang & Olufsen As | TABLE-BASED DISTRIBUTED CONTROL FOR A NETWORK OF ENTERTAINMENT ELECTRONICS |
| US7788289B2 (en) * | 2005-12-12 | 2010-08-31 | Verizon Business Global Llc | Tracking user access of a network management system |
| US9483791B2 (en) | 2007-03-02 | 2016-11-01 | Spiceworks, Inc. | Network software and hardware monitoring and marketplace |
| US7984143B2 (en) * | 2007-05-11 | 2011-07-19 | Spiceworks, Inc. | Computer network software and hardware event monitoring and reporting system and method |
| WO2011021886A2 (en) | 2009-08-21 | 2011-02-24 | Samsung Electronics Co., Ltd. | Device capable of notifying operation state change thereof through network and communication method of the device |
| KR101698485B1 (ko) * | 2010-04-13 | 2017-01-20 | 삼성전자 주식회사 | 네트워크를 통해 작동 상태 변경 알림이 가능한 디바이스 및 그 통신 방법 |
| US9009220B2 (en) * | 2011-10-14 | 2015-04-14 | Mimecast North America Inc. | Analyzing stored electronic communications |
| US11163898B2 (en) | 2013-09-11 | 2021-11-02 | Mimecast Services Ltd. | Sharing artifacts in permission-protected archives |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6128657A (en) * | 1996-02-14 | 2000-10-03 | Fujitsu Limited | Load sharing system |
| JP3398542B2 (ja) | 1996-04-22 | 2003-04-21 | 富士通株式会社 | ネットワーク監視装置 |
| US6177942B1 (en) * | 1996-04-30 | 2001-01-23 | Mentor Graphics Corporation | Part development system |
| US6131117A (en) * | 1997-12-29 | 2000-10-10 | Cisco Technology, Inc. | Technique for correlating logical names with IP addresses on internetworking platforms |
| US6128656A (en) * | 1998-09-10 | 2000-10-03 | Cisco Technology, Inc. | System for updating selected part of configuration information stored in a memory of a network element depending on status of received state variable |
| US6167445A (en) * | 1998-10-26 | 2000-12-26 | Cisco Technology, Inc. | Method and apparatus for defining and implementing high-level quality of service policies in computer networks |
| US6301613B1 (en) * | 1998-12-03 | 2001-10-09 | Cisco Technology, Inc. | Verifying that a network management policy used by a computer system can be satisfied and is feasible for use |
| US6393473B1 (en) * | 1998-12-18 | 2002-05-21 | Cisco Technology, Inc. | Representing and verifying network management policies using collective constraints |
| US6282678B1 (en) * | 1999-01-08 | 2001-08-28 | Cisco Technology, Inc. | Generic test execution method and apparatus |
| US6742141B1 (en) * | 1999-05-10 | 2004-05-25 | Handsfree Networks, Inc. | System for automated problem detection, diagnosis, and resolution in a software driven system |
| US6507565B1 (en) * | 1999-05-11 | 2003-01-14 | Cisco Technology, Inc. | Method and system for managing remote resources in a telecommunications system |
| JP2000339289A (ja) | 1999-05-26 | 2000-12-08 | Nec Corp | エラーレスポンス解析装置 |
-
2002
- 2002-07-02 JP JP2002193093A patent/JP3824972B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-27 US US10/402,178 patent/US7395326B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004040359A (ja) | 2004-02-05 |
| US20040006617A1 (en) | 2004-01-08 |
| US7395326B2 (en) | 2008-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7949906B2 (en) | Management supporting system, management supporting method, and management supporting program | |
| US7827446B2 (en) | Failure recovery system and server | |
| EP1437857B1 (en) | A network management programmable configuration management framework | |
| EP1191758B1 (en) | Terminal for computer network and recording method of control history | |
| JP3824972B2 (ja) | ネットワーク管理装置 | |
| US5991814A (en) | Method and apparatus for controlling command line transfer to a network element | |
| JP2010532502A (ja) | リアルタイム統合管理情報データ変換及びモニタリング装置並びにその方法 | |
| JP4863125B2 (ja) | 運用管理システム及び方法、並びに、プログラム | |
| JP2007079896A (ja) | 監視装置及び監視方法 | |
| US20090282141A1 (en) | Server managing apparatus and server managing method | |
| CN100450013C (zh) | 通信设备配置数据的存储方法 | |
| CN109861836A (zh) | 一种网络管理设备及其管理方法 | |
| US20050165787A1 (en) | Management computer and method of managing data storage apparatus | |
| JP2007072546A (ja) | フロー編集装置及びフロー編集方法 | |
| CN114048080A (zh) | 一种光矩阵设备调度系统、方法、电子设备及存储介质 | |
| US20050207347A1 (en) | Provisioning control apparatus | |
| JP4922992B2 (ja) | ネットワークログ取得解析システム | |
| JP5330302B2 (ja) | 操作記録プログラム及び装置 | |
| JP2007164284A (ja) | 情報管理装置 | |
| JP2907174B2 (ja) | 監視制御システムのユーザインタフェースシステム | |
| JP3987531B2 (ja) | ネットワーク管理システム | |
| JP2674465B2 (ja) | オンライン情報処理システム | |
| JP4829612B2 (ja) | ネットワーク接続機器、ネットワーク接続機器の障害対応システムおよび障害対応プログラム | |
| JP2004080297A (ja) | 故障措置システム、及び、故障措置方法 | |
| JP4198361B2 (ja) | 制御動作実行方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041124 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060616 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060627 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060628 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100707 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100707 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110707 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110707 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120707 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120707 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130707 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |