JP2011018112A - ネットワーク管理システムおよびバージョン管理方法 - Google Patents

Abstract

【課題】
従来のネットワーク管理システムおよびバージョン管理方法では、ファームウェアや機器情報が監視制御装置および通信装置でそれぞれ独立して管理されていたので、監視制御装置や通信装置の数だけ手動で１台ずつバージョンアップする作業を保守者が行わなければならなかった。
【解決手段】
本発明は、監視制御装置には、第１の通信手段と、第１の記憶手段と、バージョン変更要求受信手段と、受信したバージョン情報が第１の記憶手段に記憶されているバージョン情報より新しいか否かを比較する比較手段と、比較手段の比較結果が真の場合にファームウェアや機器情報を取得する情報取得手段と、情報取得手段で取得した情報に応じて第１の記憶手段に記憶されているバージョン情報を更新する情報更新手段と、バージョン変更完了通知手段とを設け、通信装置には、第２の通信手段と、バージョン変更要求手段と、バージョン変更完了受信手段と、バージョン変更完了応答手段とを設けたことを特徴とする。
【選択図】図１

Description

本発明は、ネットワークに接続される装置のファームウェアや機器情報のバージョンを管理するネットワーク管理システムおよびバージョン管理方法に関する。

従来、ネットワークに接続されている複数の通信装置のファームウェアや機器情報（ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）情報）のバージョンを監視制御装置（ＯｐＳ：監視制御マネージャ）で管理するネットワーク管理システムでは、監視制御装置と個々の通信装置がそれぞれ持っているファームウェアや機器情報は独立して管理されていた。

また、ファームウェアのバージョンを同一に保つ方法として、ファームウェアの情報を含む一斉同報パケットを定期的に送信するようにして、ネットワーク上の複数の装置のバージョンアップを行う技術が考えられている（例えば、特許文献１参照）。

特開２０００−０３１９９８号公報

従来のネットワーク管理システムおよびバージョン管理方法では、ファームウェアや機器情報が監視制御装置および通信装置でそれぞれ独立して管理されていたので、監視制御装置や通信装置の数だけ手動で１台ずつバージョンアップする作業を保守者が行わなければならなかった。特に、監視制御装置や通信装置のいずれかがバージョンアップされていない場合、監視制御装置と通信装置の機器情報が不一致となり、必要な情報の取得や設定を行うことができないという問題があった。また、監視制御装置が介在しないため、定期的にバージョン情報を全装置に対して送信しなければならず、通信トラフィックが増加するなどの問題があった。

上記課題に鑑み、本発明の目的は、ネットワークシステム上のいずれかの装置のファームウェアや機器情報が更新された場合に、監視制御装置に自動的に新しいバージョンを通知するようにし、監視制御装置が有するファームウェアや機器情報とバージョンが異なる場合に、バージョン更新を自動的に行うと共に新たな機器情報に対応するモニタ画面の構成を自動的に更新することができ、さらに監視ネットワーク内の他の装置に対してもバージョンアップを要求を行って自動的にバージョンアップを行うことができるネットワーク管理システムおよびバージョン管理方法を提供することである。

請求項１に係る発明は、複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムにおいて、前記監視制御装置には、前記各通信装置との間でメッセージの送受信を行う第１の通信手段と、前記各通信装置のバージョン情報を記憶する第１の記憶手段と、前記通信装置から送られてくるバージョン変更要求メッセージを前記第１の通信手段を介して受信するバージョン変更要求受信手段と、前記バージョン変更要求受信手段で受信したバージョン情報が前記第１の記憶手段に記憶されている当該通信装置のバージョン情報より新しいか否かを比較する比較手段と、前記比較手段の比較結果が真の場合に当該通信装置からファームウェアや機器情報を取得する情報取得手段と、前記情報取得手段で取得した情報に応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新する情報更新手段と、当該通信装置にバージョン変更完了メッセージを送信するバージョン変更完了通知手段とを設け、前記通信装置には、前記監視制御装置との間でメッセージの送受信を行う第２の通信手段と、バージョンが更新された場合に更新されたバージョン情報を含むバージョン変更要求メッセージを前記第２の通信手段を介して前記監視制御装置に送信するバージョン変更要求手段と、前記監視制御装置から送られてくるバージョン変更完了メッセージを前記第２の通信手段を介して受信するバージョン変更完了受信手段と、バージョン変更完了応答メッセージを前記第２の通信手段を介して前記監視制御装置に送信するバージョン変更完了応答手段とを設けたことを特徴とする。

請求項２に係る発明は、請求項１に記載のネットワーク管理システムにおいて、前記監視制御装置の情報更新手段は、前記情報取得手段で取得した情報に応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新すると共に、機器情報をモニタ画面に表示する際の画面構成も更新することを特徴とする。

請求項３に係る発明は、請求項１または２に記載のネットワーク管理システムにおいて、前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とする。

請求項４に係る発明は、複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムにおいて、前記監視制御装置には、前記各通信装置との間でメッセージの送受信を行う第１の通信手段と、前記各通信装置のバージョン情報を記憶する第１の記憶手段と、前記第１の記憶手段に記憶されている前記各通信装置のバージョンが異なっているか否かを検出する検出手段と、前記検出手段の検出結果が真の場合に古いバージョンの通信装置に対してバージョン情報を含むバージョンアップ要求メッセージを前記第１の通信手段を介して前記通信装置に送信するバージョンアップ要求手段と、前記通信装置から送られてくるバージョンアップ要求応答メッセージを前記第１の通信手段を介して受信するバージョンアップ要求応答受信手段と、前記バージョンアップ要求応答メッセージを受信した場合にファームウェアや機器情報を当該通信装置に送信する情報送信手段と、前記通信装置から送られてくるバージョンアップ完了メッセージを前記第１の通信手段を介して受信するバージョンアップ完了受信手段と、前記バージョンアップ完了メッセージに応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新する情報更新手段と、当該通信装置にバージョン変更完了メッセージを送信するバージョン変更完了通知手段とを設け、前記通信装置には、前記監視制御装置との間でメッセージの送受信を行う第２の通信手段と、自己の通信装置のバージョン情報を記憶する第２の記憶手段と、前記監視制御装置から送られてくるバージョン情報を含むバージョンアップ要求メッセージを前記第２の通信手段を介して受信するバージョンアップ要求受信手段と、前記バージョンアップ要求受信手段で受信したバージョン情報が前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報より新しいか否かを比較する比較手段と、前記比較手段の比較結果が真の場合に前記監視制御装置からファームウェアや機器情報を取得する情報取得手段と、前記情報取得手段で取得した情報に応じて前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報を更新する情報更新手段と、前記監視制御装置にバージョンアップ完了メッセージを送信するバージョンアップ完了通知手段とを設けたことを特徴とする。

請求項５に係る発明は、請求項４に記載のネットワーク管理システムにおいて、前記通信装置の情報更新手段は、前記情報取得手段で取得した情報に応じて前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報を更新すると共に、機器情報をモニタ画面に表示する際の画面構成も更新することを特徴とする。

請求項６に係る発明は、請求項４または５に記載のネットワーク管理システムにおいて、前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とする。

請求項７に係る発明は、複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムのバージョン管理方法において、前記通信装置のバージョンが更新された場合に、更新されたバージョン情報を含むバージョン変更要求メッセージを前記通信装置から前記監視制御装置に送信するバージョン変更要求手順と、前記通信装置から送られてくるバージョン変更要求メッセージのバージョン情報が前記監視制御装置の記憶媒体に記憶している当該通信装置のバージョン情報より新しいか否かを比較する比較手順と、前記比較手順の比較結果が真の場合に前記監視制御装置が当該通信装置からファームウェアや機器情報を取得する情報取得手順と、前記情報取得手順で取得した情報に応じて前記監視制御装置の記憶媒体に記憶されている当該通信装置のバージョン情報を更新する情報更新手順とを設けたことを特徴とする。

請求項８に係る発明は、複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムのバージョン管理方法において、前記監視制御装置の記憶媒体に記憶された前記各通信装置のバージョン情報が異なっているか否かを検出する検出手順と、前記検出手順の検出結果が真の場合に前記監視制御装置から古いバージョンの通信装置に対してバージョン情報を含むバージョンアップ要求メッセージを送信するバージョンアップ要求手順と、前記バージョンアップ要求受信手順で受信したバージョン情報が前記通信装置の記憶媒体に記憶されている自己のバージョン情報より新しいか否かを比較する比較手順と、前記比較手順の比較結果が真の場合に前記通信装置が前記監視制御装置からファームウェアや機器情報を取得する情報取得手順と、前記情報取得手順で取得した情報に応じて前記通信装置の記憶媒体に記憶されている自己のバージョン情報を更新する情報更新手順とを設けたことを特徴とする。

請求項９に係る発明は、請求項７または８に記載のネットワーク管理システムのバージョン管理方法において、前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とする。

本発明に係るネットワーク管理システムおよびバージョン管理方法では、ネットワークシステム上のいずれかの装置のファームウェアや機器情報が更新された場合に、監視制御装置に自動的に新しいバージョンを通知するようにし、監視制御装置が有するファームウェアや機器情報とバージョンが異なる場合に、バージョン更新を自動的に行うと共に新たな機器情報に対応するモニタ画面の構成を自動的に更新することができる。さらに、監視ネットワーク内の他の装置に対してもバージョンアップを要求を行って自動的にバージョンアップを行うことができる。これにより、監視制御装置と通信装置との間の機器情報を常に一致させることが可能になる。

第１の実施形態に係るネットワーク管理システム１００の構成例を示すブロック図である。 バージョン管理テーブルの例を示す説明図である。 画面構成定義ファイルの例を示す説明図である。 画面フォーマットの例を示す説明図である。 パラメータ定義ファイルの例を示す説明図である。 装置側でバージョンアップした時の処理を示すフローチャートである。 監視制御装置１０１側からバージョンアップする時の処理を示すフローチャートである。

以下、本発明に係る「ネットワーク管理システムおよびバージョン管理方法」の実施形態について詳しく説明する。
（第１の実施形態）
図１は、第１の実施形態に係るネットワーク管理システム１００の構成を示すブロック図である。図１のネットワーク管理システム１００は、監視制御装置１０１と、ネットワーク網１０２を介して接続される複数の装置とで構成される。図１の例では、複数の装置を装置Ａ、装置Ｂ、および装置Ｚとする。本実施形態に係るネットワーク管理システム１００は、ＳＮＭＰプロトコルを用いてネットワーク上で接続される複数の装置のファームウェアやＭＩＢ情報のバージョン管理などを行う管理システムである。尚、監視制御装置１０１（ＯｐＳ（オペレーションシステム）側）と各装置は、それぞれＭＩＢ情報を持っている。そして、監視制御装置１０１は、監視している各装置のＭＩＢ情報のバージョン（ＭＩＢバージョン）を「バージョン管理テーブル」で管理する。また、監視制御装置１０１は、ＭＩＢ情報の表示や設定を行うための「画面構成定義ファイル」や「パラメータ定義ファイル」なども保持する。尚、これらの「バージョン管理テーブル」，「画面構成定義ファイル」および「パラメータ定義ファイル」などについては後で詳しく説明する。

一方、各装置側では、「ＭＩＢ差分定義ファイル」，「ファームウェアファイル」を自装置内に保持する。「ＭＩＢ差分定義ファイル」は、追加／更新されたＭＩＢ情報と現在のＭＩＢ情報との相違部分を示すファイルで、監視制御装置１０１側でＭＩＢ情報を表示する際の画面番号や項目名などの情報も含んでいる。尚、「ＭＩＢ差分定義ファイル」，「ファームウェアファイル」，画面番号などについては後で詳しく説明する。また、バージョンの更新は、例えば保守者が装置Ａに保守装置４０１を接続してバージョンアップを行ったり、監視制御装置１０１側でバージョンアップを行う。以下、各部の構成について順番に説明する。

監視制御装置１０１は、制御部１５１と、通信部１５２と、ＭＩＢ情報データベース（ＤＢ）１５３と、記憶部１５４と、画面処理部１５５と、モニタ１５６と、操作部１５７と、各部を相互に接続するシステムバス１５８とで構成される。尚、ＭＩＢ情報ＤＢ１５３と記憶部１５４は、同じ記憶媒体で構成しても構わない。

制御部１５１は、ファームウェアが記憶されたプログラムメモリを有し、ファームウェアに従って監視制御装置１０１全体の動作を制御する。例えば、オペレータが操作部１５７で指定した装置のＭＩＢ情報をモニタ１５６に表示する。この時、通信部１５２を介してネットワーク網１０２に接続されている各装置の情報を取得し、取得した情報を画面処理部１５５を介してモニタ１５６に表示する。或いは、ＭＩＢ情報ＤＢ１５３や記憶部１５４の記憶内容を更新する。特に、本実施形態では、制御部１５１は、監視制御マネージャとしてＳＮＭＰマネージャ２０１と、バージョン管理部２０２とを有する。

ＳＮＭＰマネージャ２０１は、ネットワーク１０２を介して接続されている各装置情報（ＭＩＢ情報）の取得や設定あるいはファームウェアの更新などを行う。

バージョン管理部２０２は、主に監視制御装置１０１や各装置のＭＩＢ情報やファームウェアのバージョン管理を行い、バージョン管理テーブル２５１を常に最新の状態に維持する。また、画面構成定義ファイル２５２と、パラメータ定義ファイル２５３とを有し、各装置のＭＩＢ情報を画面処理部１５５を介してモニタ１５６に表示する際の画面フォーマットの管理や、ＭＩＢ情報のパラメータの定義情報の管理なども行う。

バージョン管理テーブル２５１は、例えば図２（ａ）に示すように、各装置のＭＩＢバージョンと、監視制御装置１０１自体のＭＩＢバージョン（ＯｐＳのＭＩＢバージョン）とが記載されている。図２（ａ）の例では、装置Ａ，装置Ｂ，装置ＺおよびＯｐＳのバージョンは、全て同じＶｅｒ．Ｘになっている。

画面構成定義ファイル２５２は、例えば図３（ａ）に示すように、ＭＩＢ名称毎に対応する画面番号と、設定項目名（表示名）と、ＯＩＤ（Ｏｂｊｅｃｔ ＩＤｅｎｔｉｆｉｅｒ：オブジェクト識別子）との対応が記載されたファイルである。ここで、ＯＩＤは、１つ１つの装置情報に対応するオブジェクトを区別するために振られた識別子で、オブジェクトツリー構造で管理される。例えば、図３（ａ）の場合、光出力をＯＮ／ＯＦＦするＯＩＤは（１．２．３．４．５．６．１） のツリー構造に相当し、ＭＩＢ名称のｍｉｂＡＡＡはＯＩＤ（１．２．３．４．５．６．１）を分かり易くするために付けたニーモニックに相当する。図３（ａ）において、例えばｍｉｂＡＡＡは項目名Ｎ１の光出力に対応し、ｍｉｂＢＢＢは項目名Ｎ２のＩＦ（インターフェース）状態に対応し、ｍｉｂＡＡＡおよびｍｉｂＢＢＢ共に画面番号はＡ１である。同様に、例えばｍｉｂＣＣＣは項目名Ｎ３のＩＰアドレスに対応し、ｍｉｂＤＤＤは項目名Ｎ４のエラー数に対応し、ｍｉｂＣＣＣおよびｍｉｂＤＤＤ共に画面番号はＡ２である。

ここで、画面番号について説明する。画面番号は、画面処理部１５５がモニタ１５６にＭＩＢ情報を表示する際の画面フォーマットの種類を示す番号である。図４（ａ）は、装置ＡのＭＩＢ情報を取得して、画面番号Ａ１の画面フォーマットに対応する画面をモニタ１５６に表示した時の例である。画面番号がＡ１の項目は、図３（ａ）ではＮ１（光出力）とＮ２（ＩＦ状態）の２つだけなので、図４（ａ）に示したモニタ１５６の画面に表示される項目もＮ１（光出力）とＮ２（ＩＦ状態）の２つである。そして、装置ＡのＯＩＤ（１．２．３．４．５．６．１）から読み出したＮ１（光出力）の読出値：１（ＯＮ）と、装置ＡのＯＩＤ（１．２．３．４．５．６．２）から読み出したＮ２（ＩＦ状態）の読出値：２（無効）とが表示される。ここで、図４（ａ）の場合は、Ｎ１（光出力）の設定やＮ２（ＩＦ状態）の設定を変更することができる。新たに設定値を入力する場合は、図４（ｄ）に示すように、設定値の欄の右端の逆三角形印にカーソルを当てるとポップアップメニューが画面に現れ、設定可能な設定値一覧が表示される。そして、新たな設定値を選択するとその値が設定値欄に入力されるので、画面上の設定更新ボタンにカーソルを合わせて押下すると監視制御装置１０１のＳＮＭＰマネージャ２０１は当該装置のＭＩＢ情報を書き換えることができる。例えば図４（ｄ）の場合は、装置ＡのＮ１（光出力）の設定がＯＦＦになる。

尚、読出値が何を意味するのかは、バージョン管理部２０２が保持するパラメータ定義ファイル２５３に定義されている。パラメータ定義ファイル２５３の一例を図５（ａ）に示す。「パラメータ定義ファイル」は、ＭＩＢ名称と全てのパラメータとの対応を示すテーブルが記載されたファイルである。図５（ａ）に示したパラメータ定義ファイル２５３の場合は、ＭＩＢ名称のｍｉｂＡＡＡとｍｉｂＢＢＢのそれぞれの値が何を意味するのかが記載されている。図５（ａ）において、ｍｉｂＡＡＡの読出値が１のときはパラメータ名：ＯＮで、ｍｉｂＡＡＡの読出値が２のときはパラメータ名：ＯＦＦに対応することがわかる。ここで、ｍｉｂＡＡＡは、図３（ａ）で説明したように光出力の状態を示すＭＩＢ情報なので、図４（ａ）の場合は、装置ＡのｍｉｂＡＡＡに対応する光出力はＯＮの状態であることを示している。同様に、項目名Ｎ２（ＩＦ状態）の読出値は２なので、図５（ａ）のパラメータ定義ファイル２５３より、装置ＡのｍｉｂＢＢＢに対応するＩＦ状態は無効の状態であることを示している。このように、パラメータ定義ファイル２５３は、装置から読み出したＭＩＢ情報の読出値が何を意味するのかを定義するためのファイルである。このようにして、画面番号毎に画面構成定義ファイル２５２に定義された画面フォーマットに基づいて、各装置のＭＩＢ情報が表示される。

尚、図３（ａ）の画面番号がＡ２の場合は、図４（ａ）の例とは異なる画面フォーマットで構成される。例えば図３（ａ）において、画面番号がＡ２の項目はＩＰアドレスとエラー数なので、図４（ｂ）に示すように、それぞれの項目の読出値のみが表示される画面フォーマットになっている。

また、装置Ａ以外の装置のＭＩＢ情報を表示する場合でも、同型の装置でバージョンが同じであればＯＩＤのツリー構成は同じなので、図３（ａ）に示す画面構成定義ファイル２５２を共通の画面構成ファイルとして用いることができる。従って、ＳＮＭＰマネージャ２０１は、例えば装置ＡのｍｉｂＡＡＡの情報を取得する場合は、装置ＡのＯＩＤ（１．２．３．４．５．６．１）の情報を読み取って画面番号：Ａ１の画面フォーマットでモニタ１５６に表示し、装置ＺのｍｉｂＡＡＡの情報を取得する場合は、装置ＺのＯＩＤ（１．２．３．４．５．６．１）の情報を読み取って画面番号：Ａ１の画面フォーマットでモニタ１５６に表示する。尚、監視制御装置１０１側には、各装置に接続するための識別番号（ＭＡＣアドレスなど）が事前に登録されているものとする。

以上説明したように、図１の監視制御装置１０１の制御部１５１は構成される。

図１において、通信部１５２は、イーサネット（登録商標）などの所定の通信方式でネットワーク網１０２に接続し、ネットワーク網１０２に接続されている各装置に接続する。

ＭＩＢ情報ＤＢ１５３は、ＭＩＢ名称，ＯＩＤ，項目名などを記憶するデータベースである。先に説明した制御部１５１のＳＮＭＰマネージャ２０１は、ＭＩＢ情報ＤＢ１５３に記憶されたＭＩＢ情報に基づいて、各装置のＭＩＢ名称のＯＩＤから装置情報を読み出す。

記憶部１５４は、バージョンアップ時に、最新のファームウェアファイル２０３と、ＭＩＢ定義差分ファイル２０４とを記憶する。ここで、ＭＩＢ定義差分ファイル２０４は追加や更新されたＭＩＢ情報で、表示するための画面番号の情報や項目名などが記載されている。尚、バージョンアップ後は、ＭＩＢ情報ＤＢ１５３の記憶内容が更新され、制御部１５１のファームウェアが最新のバージョンに書き換えられる。

画面処理部１５５は、制御部１５１から指示された画面フォーマットで出力画面を生成し、モニタ１５６に表示する。例えば、図１に示すように、画面番号：Ａ１や画面番号：Ａ２に対応する出力画面を生成し、図４（ａ）や図４（ｂ）で説明したようにモニタ１５６に表示する。また、画面処理部１５５は、先に説明した「画面構成定義ファイル」，「パラメータ定義ファイル」の更新を監視し、ファイルが変更された場合に「画面フォーマットの変更処理」を自動的に行う。そして、画面の更新処理後、制御部１５１のバージョン管理部２０２へ通知を行い、バージョン管理部２０２は、バージョン管理テーブル２５１の中の該当する装置のバージョン番号を更新する。

モニタ１５６は、液晶などの表示媒体で構成され、画面処理部１５５が出力する画面番号に対応する画面フォーマットの画面を表示する。

操作部１５７は、マウスやキーボードなどの操作部材で構成され、保守を行うオペレータが操作する。例えば、監視制御装置１０１のＯｐＳのバージョンアップなどを行う。或いは、各装置を指定してＭＩＢ情報の取得を行って、モニタ１５６に指定した装置のＭＩＢ情報を表示して設定値の変更などを行う。

尚、監視制御装置１０１は、例えばＵＮＩＸ（登録商標）システム上で動作するＷｅｂサーバとｊａｖａ（登録商標）アプリケーションを用い、Ｗｅｂブラウザ上で監視対象となる装置の状態を読み出したり或いは設定を行うＯｐＳ（オペレーションシステム）で実現できる。この場合の監視制御装置１０１は、例えばＷｅｂブラウザ上の画面操作にて、各装置の状態の読出／設定を行う。そして、画面処理部１５５は、「画面構成定義ファイル」，「パラメータ定義ファイル」の更新を監視し、ファイルが変更された場合に、ＪＳＰ（ＪＡＶＡ（登録商標） Ｓｅｒｖｅｒ Ｐａｇｅｓ）機能を用いてＷｅｂブラウザからの要求に従って「画面フォーマットの変更処理」を行ってモニタ１５６に画面を表示する。尚、「画面フォーマットの変更処理」は、ＪＳＰで出力するＨＴＭＬベースのフォーマット変更を行うことで画面の再構成を行うことができる。
［各装置の構成について］
次に、各装置の構成例について、図１を用いて説明する。図１において、装置Ａ，装置Ｂおよび装置Ｚは同じ構成の装置とする。ここでは、装置Ａの構成について説明する。装置Ａは、制御部３０１と、通信部３０２と、ＭＩＢ情報ＤＢ３０３と、記憶部３０４と、各部を相互に接続するシステムバス３０５とで構成される。尚、ＭＩＢ情報ＤＢ３０３と記憶部３０４は、同じ記憶媒体で構成しても構わない。

制御部３０１は、ファームウェアが記憶されたプログラムメモリを有し、ファームウェアに従って装置Ａ全体の動作を制御する。例えば、通信部３０２を介してネットワーク網１０２に接続されている監視制御装置１０１に接続し、制御信号の送受信やＭＩＢ情報の送受信などを行う。或いは、ＭＩＢ情報ＤＢ３０３や記憶部３０４の記憶内容を更新する。特に、本実施形態では、制御部３０１は、監視制御装置１０１のＳＮＭＰマネージャ２０１に接続するＳＮＭＰエージェント３５１を有する。

ＳＮＭＰエージェント３５１は、ＳＮＭＰマネージャ２０１との間で制御信号の送受信してバージョン情報やＭＩＢ情報の取得や設定あるいは更新などを行う。

通信部３０２は、イーサネット（登録商標）などの所定の通信方式でネットワーク網１０２に接続し、さらにネットワーク網１０２に接続されている監視制御装置１０１に接続する。

ＭＩＢ情報ＤＢ３０３は、自装置のＭＩＢ名称，ＯＩＤ，項目名などを記憶するデータベースである。制御部３０１は、先に説明した監視制御装置１０１から要求されるＭＩＢ名称のＯＩＤから装置情報を読み出して監視制御装置１０１側に送信する。尚、ＭＩＢ情報ＤＢ３０３には、自装置の現バージョン番号も記憶されているものとする。

記憶部３０４は、バージョンアップ時に、最新のファームウェアファイル３５２と、ＭＩＢ定義差分ファイル３５３とを記憶する。ここで、ＭＩＢ定義差分ファイル３５３は追加や更新されたＭＩＢ情報である。尚、バージョンアップ後は、ＭＩＢ情報ＤＢ３０３の記憶内容が更新され、制御部３０１のファームウェアが最新のバージョンに書き換えられる。

以上のように装置Ａは構成され、監視制御装置１０１との間でＭＩＢ情報やファームウェアのバージョン管理が行われる。尚、装置Ｂおよび装置Ｚについても同様に動作する。

次に、図６を用いて、ネットワーク管理システム１００のバージョン管理方法の手順について図６のフローチャートを用いて詳しく説明する。

図６において、１００番台の処理ステップは監視制御装置１０１側のバージョン変更処理の流れを示し、２００番台の処理ステップは装置Ａ側のバージョン変更処理の流れをそれぞれ示している。図６は、装置Ａ側においてバージョンアップ（Ｖｅｒ．ＸからＶｅｒ．Ｘ＋１に更新）が為された場合の処理を示すフローチャートである。尚、装置Ａについてのみ説明するが、装置Ｂおよび装置Ｚについても同様である。また、図６のフローチャートは、監視制御装置１０１の制御部１５１と、装置Ａの制御部３０１とによって行われる処理である。
［監視制御装置１０１側のバージョン変更処理］
（ステップＳ１０１）監視制御装置１０１側のバージョン変更処理を開始する。

（ステップＳ１０２）制御部１５１は、「バージョン変更要求」のＴｒａｐ信号を受信したか否かを判別する。「バージョン変更要求」のＴｒａｐ信号を受信した場合はステップＳ１０３に進み、受信していない場合はステップＳ１０２で待機する。尚、図６では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ１０２で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ１０３）制御部１５１は、「バージョン変更要求」のＴｒａｐ信号を受信した場合は、受信したＴｒａｐ信号に記載されているバージョンと、バージョン管理部２０２で管理しているバージョン管理テーブル２５１とを比較して、新バージョンであるか否かを判別する。新バージョンである場合はステップＳ１０４に進み、新バージョンではない場合（同じバージョンか古いバージョンの場合）は、バージョンアップ済みとしてステップＳ１１０に進む。

（ステップＳ１０４）制御部１５１は、新バージョンと現バージョンとの差分ファイルや新しいファームウェアファイルを取得する。尚、差分ファイルの取得は、ＦＴＰプロトコルを用いて行われる。ここで、差分ファイルとは、先に図１で説明した装置Ａの記憶部３０４に準備されているＭＩＢ定義差分ファイル３５３で、ファームウェアファイルとは、先に図１で説明した装置Ａの記憶部３０４に準備されているファームウェアファイル３５２である。尚、取得したＭＩＢ定義差分ファイル３５３およびファームウェアファイル３５２は、最新のＭＩＢ定義差分ファイル２０４およびファームウェアファイル２０３として記憶部１５４に保持される。ここで、記憶部１５４に保持されたこれらの最新ファイルは、後で図７を用いて詳しく説明するように、監視制御装置１０１から他の装置をバージョンアップする際に用いられる。

（ステップＳ１０５）制御部１５１は、装置Ａから取得したＭＩＢ定義差分ファイル３５３をコンパイルしてＭＩＢ情報ＤＢ１５３に記憶されているＭＩＢ情報を更新する。

（ステップＳ１０６）制御部１５１は、更新されたＭＩＢ情報に応じて、画面構成定義ファイル２５２とパラメータ定義ファイル２５３とを更新する。ここで、画面構成定義ファイル２５２を更新する例を図３を用いて説明する。図３(ａ)は、先に説明したように、ｍｉｂＡＡＡと、ｍｉｂＢＢＢと、ｍｉｂＣＣＣと、ｍｉｂＤＤＤとの４つのＭＩＢ名称が定義されている。図３（ｂ）の画面構成定義ファイル２５２ａは、図３（ａ）にｍｉｂＥＥＥのＭＩＢ名称が新たに追加された様子を示す。そして、ｍｉｂＥＥＥは画面番号がＡ１に対応し、項目名はＮ５（出力レベル）でＯＩＤは（１．２．３．４．５．６．５）であることがわかる。

また、図５（ａ）で説明したパラメータ定義ファイル２５３には、新たに追加されたｍｉｂＥＥＥのパラメータ名は定義されていないので、図５（ｂ）に示したようにパラメータ定義ファイル２５３ａのように更新され、ｍｉｂＥＥＥのパラメータ名が定義される。図５（ｂ）のパラメータ定義ファイル２５３ａにおいて、ｍｉｂＥＥＥの値が１の時はレベル高、値が２の時はレベル中、値が３の時はレベル低のように定義される。このように、
（ステップＳ１０７）制御部１５１は、更新された画面構成定義ファイル２５２ａおよびパラメータ定義ファイル２５３ａに応じて、画面処理部１５５で作成する画面フォーマットの変更処理を行う。ここで、画面フォーマットを変更する例を図４を用いて説明する。更新前のモニタ１５６の画面フォーマットは、先に説明した図４（ａ）のように、項目名Ｎ１（光出力）と項目名Ｎ２（ＩＦ状態）の２つしか表示されていない。これに対して、更新後のモニタ１５６の画面フォーマットは、図４（ｃ）のように、項目名Ｎ１（光出力）と項目名Ｎ２（ＩＦ状態）に加えて、項目名Ｎ５（出力レベル）が追加される。ここで、図４（ａ）の場合と同様に、Ｎ５（出力レベル）の設定を変更することができる。新たに設定値を入力する場合は、図４（ｄ）の場合と同様に、図４（ｅ）に示すように、設定値の欄の右端の逆三角形印にカーソルを当てるとポップアップメニューが画面に現れ、設定可能な設定値一覧が表示される。そして、新たな設定値を選択するとその値が設定値欄に入力されるので、画面上の設定更新ボタンにカーソルを合わせて押下すると監視制御装置１０１のＳＮＭＰマネージャ２０１は当該装置のＭＩＢ情報を書き換えることができる。例えば図４（ｅ）の場合は、装置ＡのＮ５（出力レベル）の設定をレベル高からレベル中に変更される。

（ステップＳ１０８）制御部１５１は、バージョン管理部２０２のバージョン管理テーブル２５１の装置ＡのバージョンをＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新する（図２（ｂ））。

（ステップＳ１０９）制御部１５１は、バージョン管理部２０２のバージョン管理テーブル２５１の監視制御装置１０１のバージョン（ＯｐＳのバージョン）をＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新する（図２（ｃ））。

このようにして、装置ＡのバージョンがＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新された場合、自動的に監視制御装置１０１のバージョンもＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新される。

（ステップＳ１１０）制御部１５１は、通信部１５２を介して装置Ａに「バージョン変更完了通知」を送信する。

（ステップＳ１１１）制御部１５１は、「バージョン変更完了応答」を装置Ａから受信したか否かを判別する。「バージョン変更完了応答」を受信した場合はステップＳ１１２に進み、受信していない場合はステップＳ１１１で待機する。尚、図６では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ１１１で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ１１２）監視制御装置１０１側のバージョン変更処理を終了する。
［装置Ａ側のバージョン変更処理］
次に、装置Ａ側のバージョン変更処理の流れについて説明する。

（ステップＳ２０１）装置Ａ側のバージョン変更処理を開始する。

（ステップＳ２０２）制御部３０１は、保守者などによって自装置のバージョンが変更されたか否かを判別する。バージョンが更新された場合はステップＳ２０３に進み、更新されていない場合はステップＳ２０２で待機する。尚、図６では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ２０２で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ２０３）制御部３０１は、バージョン更新中であることを示すフラグをＯＮする。尚、フラグは、制御部３０１内のレジスタなどで一時的に保持される。

（ステップＳ２０４）制御部３０１は、「バージョン変更要求」のＴｒａｐ信号を監視制御装置１０１に送信する。尚、Ｔｒａｐ信号とは、非同期で行われる通信信号である。

（ステップＳ２０５）監視制御装置１０１側からのＦＴＰ処理が開始されたか否かを判別する。ＦＴＰ処理が開始された場合はステップＳ２０６に進み、開始されていない場合はステップＳ２０７に進む。

（ステップＳ２０６）ＦＴＰ処理で監視制御装置１０１側に新バージョンと現バージョンとの差分ファイルや新しいファームウェアファイルを送信する。尚、差分ファイルの送信は、ＦＴＰプロトコルを用いて行われる。ここで、差分ファイルとは、先に図１で説明した装置Ａの記憶部３０４に準備されているＭＩＢ定義差分ファイル３５３で、ファームウェアファイルとは、先に図１で説明した装置Ａの記憶部３０４に準備されているファームウェアファイル３５２である。

（ステップＳ２０７）制御部３０１は、「バージョン変更完了通知」を受信したか否かを判別する。「バージョン変更完了通知」を受信した場合はステップＳ２０９に進み、受信していない場合はステップＳ２０８に進む。

（ステップＳ２０８）所定時間（例えば５秒など）が経過したか否かを判別する。ここで、所定時間とは、ステップＳ２０４で「バージョン変更要求」をＴｒａｐ送信してからの時間を意味し、例えばステップＳ２０４で「バージョン変更要求」をＴｒａｐ送信したときにタイマー（例えば１秒に１カウントするカウンタ）をリセットすることにより判別できる。所定時間が経過した場合はステップＳ２０４に戻って、再び「バージョン変更要求」をＴｒａｐ送信し、所定時間が経過していない場合はステップＳ２０７で「バージョン変更完了通知」の受信を待つ。このように、定期的に「バージョン変更要求」をＴｒａｐ送信することで、装置のみがバージョンアップされた状態が続くことを防止することができる。

（ステップＳ２０９）制御部３０１は、ステップＳ２０３でセットしたバージョン更新中であることを示すフラグをＯＦＦする。

（ステップＳ２１０）制御部３０１は、「バージョン変更完了応答」を監視制御装置１０１に送信する。

（ステップＳ２１１）装置Ａ側のバージョン変更処理を終了する。

このようにして、装置ＡのバージョンがＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新された場合、自動的に監視制御装置１０１にバージョンの変更があったことを通知し、監視制御装置１０１に差分ファイルを送信することによって、バージョン管理部２０２のバージョン管理テーブル２５１の装置Ａのバージョンを更新する。同時に、監視制御装置１０１のバージョン（ＯｐＳのバージョン）もＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新される。この結果、図２（ｃ）に示すように、装置Ａのバージョンと監視制御装置１０１のＯｐＳのバージョンとを常に最新のバージョンに更新することができる。

上記のフローチャートにおいて、装置側はバージョン更新中を示す更新中フラグがＯＮの状態では、装置が「バージョン変更完了」を受けていない場合は定期的に「バージョン変更要求」をＴｒａｐ送信し続け、監視制御装置１０１側のＭＩＢ情報の更新完了を示す「バージョン変更完了」を受けるまで待機する。そして、「バージョン変更完了」を受信して「バージョン変更完了応答」を送信した後、更新中フラグをＯＦＦして、「バージョン変更要求」のＴｒａｐ送信を停止するので、確実に監視制御装置１０１側と装置側のバージョンアップを行うことができる。

尚、図２（ｃ）の状態では、装置Ｂや装置Ｚのバージョンは、更新前のＶｅｒ．Ｘになったままなので、これらの装置のバージョンも更新する必要がある。或いは、図２（ａ）の状態から図２（ｄ）に示すように、ＯｐＳのバージョンを最初に更新した場合は、他の全ての装置のバージョンを更新する必要がある。このようにＭＩＢバージョンが異なっていると、ＳＮＭＰマネージャ２０１で各装置情報を適切に取得できなくなり、装置管理が行えないなど様々な問題が生じる。このような場合、従来は保守管理者が各装置およびＯｐＳのバージョンが同じになるように、１台ずつマニュアルで管理しなければならなかった。これに対して、本実施形態に係るネットワーク管理システム１００では、以下のようにして全ての装置やＯｐＳのバージョンを自動的に更新して同じバージョンに保つことができる。

次に、図２（ｃ）や図２（ｄ）の状態から他の装置のバージョンを更新する処理について図７のフローチャートを用いて説明する。

図７において、３００番台の処理ステップは監視制御装置１０１側のバージョン変更処理の流れを示し、４００番台の処理ステップは装置Ｂ側のバージョン変更処理の流れをそれぞれ示している。図７は、監視制御装置１０１側（ＯｐＳ側）においてバージョンアップ（Ｖｅｒ．ＸからＶｅｒ．Ｘ＋１に更新）が為された場合の処理を示すフローチャートである。尚、装置Ｂについてのみ説明するが、装置Ｚなどその他の装置についても同様である。また、図７のフローチャートは、監視制御装置１０１の制御部１５１と、装置Ｂの制御部３０１との間で行われる処理を示しているが、装置Ｚなどに対しても同様に行われる。以下の説明では、分かり易いように装置Ｂとの間のバージョンアップ処理について説明する。
［監視制御装置１０１側のバージョン変更処理］
（ステップＳ３０１）監視制御装置１０１側のバージョン変更処理を開始する。

（ステップＳ３０２）制御部１５１は、バージョン管理部２０２のバージョン管理テーブル２５１をチェックして、異なるバージョンが混在しているか否かを判別する。異なるバージョンが混在している場合はステップＳ３０３に進み、混在していない場合はステップＳ３０２で待機する。尚、図７では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ３０２で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ３０３）「バージョンアップ要求」をバージョンの異なる装置に対して送信する。例えば、図２（ｃ）の場合は装置Ｂおよび装置Ｚに対して送信し、図２（ｄ）の場合は装置Ａ，装置Ｂおよび装置Ｚに対して送信する。

（ステップＳ３０４）制御部１５１は、「バージョンアップ要求応答」をステップＳ３０３で要求した各装置から受信したか否かを判別する。尚、先に説明したように、以下の処理は、ステップＳ３０３で要求した各装置についてそれぞれ行われる処理であるが、ここでの説明では分かり易いように装置Ｂの場合について説明する。

「バージョンアップ要求応答」をステップＳ３０３で要求した各装置（ここでは装置Ｂ）から受信した場合はステップＳ３０５に進み、受信していない場合はステップＳ３０６に進む。

（ステップＳ３０５）「バージョンアップ要求応答」を受信した各装置（ここでは装置Ｂ）にＦＴＰ処理を用いて新バージョンと現バージョンとの差分ファイルを送信する。尚、差分ファイルの送信は、ＦＴＰプロトコルを用いて行われる。ここで、差分ファイルとは、先に図１で説明した装置Ａ（ここでは装置Ｂ）の記憶部３０４に準備されているＭＩＢ定義差分ファイル３５３である。これにより、装置Ｂは、監視制御装置１０１からＦＴＰでＭＩＢ定義差分ファイル３５３を取得する。尚、装置Ｂ側の処理は後で詳しく説明する。

（ステップＳ３０６）制御部１５１は、「バージョンアップ完了通知」のＴｒａｐ信号を受信したか否かを判別する。「バージョンアップ完了通知」のＴｒａｐ信号を受信した場合はステップＳ３０７に進み、受信していない場合はステップＳ３０４に戻る。尚、図７では、分かり易いようにバージョン管理処理のみについて説明しているので、バージョンアップ完了通知」のＴｒａｐ信号を受信するまでステップＳ３０４からステップＳ３０６をループするように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ３０７）バージョン管理部２０２のバージョン管理テーブル２５１の装置ＢのバージョンをＶｅｒ．ＸからＶｅｒ．Ｘ＋１に更新する（図２（ｅ））。尚、先に述べたように、ここでは装置Ｂの場合について説明しているが、装置ＺについてもステップＳ３０３以降の処理が同様に行われるので、図２（ｆ）に示すように、全ての装置およびＯｐＳのバージョンがＶｅｒ．Ｘ＋１に更新される。

（ステップＳ３０８）制御部１５１は、通信部１５２を介して装置Ａに「バージョン変更完了通知」を送信する。

（ステップＳ３０９）制御部１５１は、「バージョン変更完了応答」を各装置（ここでは装置Ｂ）から受信したか否かを判別する。「バージョン変更完了応答」を受信した場合はステップＳ３１０に進み、受信していない場合はステップＳ３０９で待機する。尚、図７では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ３０９で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ３１０）監視制御装置１０１側のバージョン変更処理を終了する。
［装置Ｂ側のバージョン変更処理］
次に、装置Ｂ側のバージョン変更処理の流れについて説明する。尚、上記のステップＳ３０３で「バージョンアップ要求応答」を送信した装置Ｚなど他の装置についても同様に動作する。

（ステップＳ４０１）装置Ｂ側のバージョン変更処理を開始する。

（ステップＳ４０２）装置Ｂの制御部３０１は、「バージョンアップ要求」を受信したか否かを判別する。「バージョンアップ要求」を受信した場合はステップＳ４０３に進み、受信していない場合はステップＳ４０２で待機する。尚、図７では、分かり易いようにバージョン管理処理のみについて説明しているので、ステップＳ４０２で待機するように描いてあるが、バージョン管理処理以外の処理は、例えば割り込み処理などで動作しているものとする。

（ステップＳ４０３）装置Ｂの制御部３０１は、「バージョンアップ要求」に記載されているバージョンと、装置ＢのＭＩＢ情報ＤＢ３０３に記憶されている自装置の現バージョンとを比較して、新バージョンであるか否かを判別する。新バージョンである場合はステップＳ４０４に進み、新バージョンではない場合（同じバージョンか古いバージョンの場合）は、バージョンアップ済みとしてステップＳ４０８に進む。

（ステップＳ４０４）装置Ｂの制御部３０１は、「バージョンアップ要求応答」を監視制御装置１０１に送信する。

（ステップＳ４０５）装置Ｂの制御部３０１は、新バージョンと現バージョンとのＭＩＢ情報の差分ファイルや新しいファームウェアファイルを監視制御装置１０１側から取得する。尚、差分ファイル等の取得は、ＦＴＰプロトコルを用いて行われる。ここで、差分ファイルとは、先に図１で説明した監視制御装置１０１の記憶部１５４に準備されているＭＩＢ定義差分ファイル２０４で、ファームウェアファイルとは、先に図１で説明した監視制御装置１０１の記憶部１５４に準備されているファームウェアファイル２０３である。

（ステップＳ４０６）装置Ｂの制御部３０１は、監視制御装置１０１から取得したＭＩＢ定義差分ファイル２０４をコンパイルして装置ＢのＭＩＢ情報ＤＢ３０３に記憶されている自装置のＭＩＢ情報を更新する。また、ファームウェアファイル２０３によって自装置のファームウェアのバージョンも更新する。

（ステップＳ４０７）装置Ｂの制御部３０１は、バージョン更新中であることを示すフラグをＯＮする。尚、フラグは、装置Ｂの制御部３０１内のレジスタなどで一時的に保持される。

（ステップＳ４０８）装置Ｂの制御部３０１は、「バージョンアップ完了通知」のＴｒａｐ信号を監視制御装置１０１に送信する。

（ステップＳ４０９）装置Ｂの制御部３０１は、「バージョン変更完了通知」を受信したか否かを判別する。「バージョン変更完了通知」を受信した場合はステップＳ４１１に進み、受信していない場合はステップＳ４１０に進む。

（ステップＳ４１０）所定時間（例えば５秒など）が経過したか否かを判別する。ここで、所定時間とは、ステップＳ４０８で「バージョン変更要求」をＴｒａｐ送信してからの時間を意味し、例えばステップＳ４０８で「バージョン変更要求」をＴｒａｐ送信したときにタイマー（例えば１秒に１カウントするカウンタ）をリセットすることにより判別できる。所定時間が経過した場合はステップＳ４０８に戻って、再び「バージョン変更要求」をＴｒａｐ送信し、所定時間が経過していない場合はステップＳ４０９で「バージョン変更完了通知」の受信を待つ。

（ステップＳ４１１）装置Ｂの制御部３０１は、ステップＳ４０７でセットしたバージョン更新中であることを示すフラグをＯＦＦする。

（ステップＳ４１２）装置Ｂの制御部３０１は、「バージョン変更完了応答」を監視制御装置１０１に送信する。

（ステップＳ４１３）装置Ｂ側のバージョン変更処理を終了する。

このようにして、監視制御装置１０１のバージョン管理テーブル２５１で異なるバージョンが混在している場合に、古いバージョンの各装置に「バージョンアップ要求」を送信して、各装置のバージョンアップを行うことができる。この結果、図２（ｆ）に示すように、各装置のバージョンと監視制御装置１０１のＯｐＳのバージョンとを常に最新のバージョンに更新することができる。

ここで、通常は監視制御装置１０１側（ＯｐＳ側）と各装置側（クライアント側）とで同じＭＩＢ情報を独立して管理するので、従来のシステムでは、ＯｐＳ側またはクライアント側のいずれかでバージョンアップが行われた場合、その他のバージョンは更新されないという問題があった。このため、それぞれのバージョンアップ等に応じて保守者が手動でＯｐＳや装置の数だけ１台ずつ更新する必要があった。ファームウェアのバージョンアップについても同様である。例えば日本中に配置されている装置を東京のＯｐＳで管理するネットワーク管理システムの場合、九州に配置されている装置のバージョンアップが行われても、同じネットワーク上で接続されている大阪の装置や東京のＯｐＳ側のバージョンアップは行われないという問題が生じていた。

これに対して、本実施形態に係るネットワーク管理システム１００におけるバージョン管理方法では、例えば九州に配置されている装置のバージョンアップが行われた場合は、九州の装置から東京のＯｐＳ側にバージョンアップされたことをＴｒａｐ通知するので、東京のＯｐＳ側は、九州の装置がバージョンアップしたことを逐次知ることができる。同時に差分ファイルや新しいファームウェアファイルを取得して、バージョンの古い大阪の装置やその他の装置に対してバージョンアップ要求を送信し、全ての装置のバージョンを常に同一のバージョンに保つことができる。

このように、本発明に係るネットワーク管理システムおよびバージョン管理方法は、ネットワーク内の装置や監視制御装置１０１のいずれかのバージョンが更新された場合でも、ネットワーク内のすべてのＭＩＢ情報やファームウェアのバージョンを保守者の作業を行なうことなく、自動的に一致させることができる。この結果、ＭＩＢ情報の不一致等によって必要な装置情報の取得や設定ができないなどの問題を回避できる。

尚、本実施形態では、ネットワーク管理プロトコルとしてＳＮＭＰを用いた場合について説明したが、ＳＮＭＰ以外のＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）やＴＬ１（Ｔｒａｎｓａｃｔｉｏｎ Ｌａｎｇｕａｇｅｓ １）などを用いた場合でも、監視制御装置１０１と各装置間で送受信するプロトコルが異なるだけであり、バージョンアップに関する一連の処理方法は同じである。

以上、本発明に係るネットワーク管理システムおよびバージョン管理方法について、実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。

１００・・・ネットワーク管理システム
１０１・・・監視制御装置
１０２・・・ネットワーク網
１５１・・・制御部
１５２・・・通信部
１５３・・・ＭＩＢ情報データベース（ＤＢ）
１５４・・・記憶部
１５５・・・画面処理部
１５６・・・モニタ
１５７・・・操作部
１５８・・・システムバス
２０１・・・ＳＮＭＰマネージャ
２０２・・・バージョン管理部
２５１・・・バージョン管理テーブル
２５２，２５２ａ・・・画面構成定義ファイル
２５３，２５３ａ・・・パラメータ定義ファイル
３０１・・・制御部
３０２・・・通信部
３０３・・・ＭＩＢ情報ＤＢ
３０４・・・記憶部
３０５・・・システムバス
３５１・・・ＳＮＭＰエージェント
３５２・・・ファームウェアファイル
３５３・・・ＭＩＢ定義差分ファイル
４０１・・・保守装置

Claims (9)

1. 複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムにおいて、
   前記監視制御装置には、
   前記各通信装置との間でメッセージの送受信を行う第１の通信手段と、
   前記各通信装置のバージョン情報を記憶する第１の記憶手段と、
   前記通信装置から送られてくるバージョン変更要求メッセージを前記第１の通信手段を介して受信するバージョン変更要求受信手段と、
   前記バージョン変更要求受信手段で受信したバージョン情報が前記第１の記憶手段に記憶されている当該通信装置のバージョン情報より新しいか否かを比較する比較手段と、
   前記比較手段の比較結果が真の場合に当該通信装置からファームウェアや機器情報を取得する情報取得手段と、
   前記情報取得手段で取得した情報に応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新する情報更新手段と、
   当該通信装置にバージョン変更完了メッセージを送信するバージョン変更完了通知手段と
   を設け、
   前記通信装置には、
   前記監視制御装置との間でメッセージの送受信を行う第２の通信手段と、
   バージョンが更新された場合に更新されたバージョン情報を含むバージョン変更要求メッセージを前記第２の通信手段を介して前記監視制御装置に送信するバージョン変更要求手段と、
   前記監視制御装置から送られてくるバージョン変更完了メッセージを前記第２の通信手段を介して受信するバージョン変更完了受信手段と、
   バージョン変更完了応答メッセージを前記第２の通信手段を介して前記監視制御装置に送信するバージョン変更完了応答手段と
   を設けた
   ことを特徴とするネットワーク管理システム。
2. 請求項１に記載のネットワーク管理システムにおいて、
   前記監視制御装置の情報更新手段は、前記情報取得手段で取得した情報に応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新すると共に、機器情報をモニタ画面に表示する際の画面構成も更新することを特徴とするネットワーク管理システム。
3. 請求項１または２に記載のネットワーク管理システムにおいて、
   前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とするネットワーク管理システム。
4. 複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムにおいて、
   前記監視制御装置には、
   前記各通信装置との間でメッセージの送受信を行う第１の通信手段と、
   前記各通信装置のバージョン情報を記憶する第１の記憶手段と、
   前記第１の記憶手段に記憶されている前記各通信装置のバージョンが異なっているか否かを検出する検出手段と、
   前記検出手段の検出結果が真の場合に古いバージョンの通信装置に対してバージョン情報を含むバージョンアップ要求メッセージを前記第１の通信手段を介して前記通信装置に送信するバージョンアップ要求手段と、
   前記通信装置から送られてくるバージョンアップ要求応答メッセージを前記第１の通信手段を介して受信するバージョンアップ要求応答受信手段と、
   前記バージョンアップ要求応答メッセージを受信した場合にファームウェアや機器情報を当該通信装置に送信する情報送信手段と、
   前記通信装置から送られてくるバージョンアップ完了メッセージを前記第１の通信手段を介して受信するバージョンアップ完了受信手段と、
   前記バージョンアップ完了メッセージに応じて前記第１の記憶手段に記憶されている当該通信装置のバージョン情報を更新する情報更新手段と、
   当該通信装置にバージョン変更完了メッセージを送信するバージョン変更完了通知手段と
   を設け、
   前記通信装置には、
   前記監視制御装置との間でメッセージの送受信を行う第２の通信手段と、
   自己の通信装置のバージョン情報を記憶する第２の記憶手段と、
   前記監視制御装置から送られてくるバージョン情報を含むバージョンアップ要求メッセージを前記第２の通信手段を介して受信するバージョンアップ要求受信手段と、
   前記バージョンアップ要求受信手段で受信したバージョン情報が前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報より新しいか否かを比較する比較手段と、
   前記比較手段の比較結果が真の場合に前記監視制御装置からファームウェアや機器情報を取得する情報取得手段と、
   前記情報取得手段で取得した情報に応じて前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報を更新する情報更新手段と、
   前記監視制御装置にバージョンアップ完了メッセージを送信するバージョンアップ完了通知手段と
   を設けた
   ことを特徴とするネットワーク管理システム。
5. 請求項４に記載のネットワーク管理システムにおいて、
   前記通信装置の情報更新手段は、前記情報取得手段で取得した情報に応じて前記第２の記憶手段に記憶されている自己の通信装置のバージョン情報を更新すると共に、機器情報をモニタ画面に表示する際の画面構成も更新することを特徴とするネットワーク管理システム。
6. 請求項４または５に記載のネットワーク管理システムにおいて、
   前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とするネットワーク管理システム。
7. 複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムのバージョン管理方法において、
   前記通信装置のバージョンが更新された場合に、更新されたバージョン情報を含むバージョン変更要求メッセージを前記通信装置から前記監視制御装置に送信するバージョン変更要求手順と、
   前記通信装置から送られてくるバージョン変更要求メッセージのバージョン情報が前記監視制御装置の記憶媒体に記憶している当該通信装置のバージョン情報より新しいか否かを比較する比較手順と、
   前記比較手順の比較結果が真の場合に前記監視制御装置が当該通信装置からファームウェアや機器情報を取得する情報取得手順と、
   前記情報取得手順で取得した情報に応じて前記監視制御装置の記憶媒体に記憶されている当該通信装置のバージョン情報を更新する情報更新手順と
   を設けたことを特徴とするネットワーク管理システムのバージョン管理方法。
8. 複数の通信装置と、予め決められた所定プロトコルを用いて前記通信装置毎のファームウェアや機器情報のバージョンを管理する少なくとも１つの監視制御装置とで構成されるネットワーク管理システムのバージョン管理方法において、
   前記監視制御装置の記憶媒体に記憶された前記各通信装置のバージョン情報が異なっているか否かを検出する検出手順と、
   前記検出手順の検出結果が真の場合に前記監視制御装置から古いバージョンの通信装置に対してバージョン情報を含むバージョンアップ要求メッセージを送信するバージョンアップ要求手順と、
   前記バージョンアップ要求受信手順で受信したバージョン情報が前記通信装置の記憶媒体に記憶されている自己のバージョン情報より新しいか否かを比較する比較手順と、
   前記比較手順の比較結果が真の場合に前記通信装置が前記監視制御装置からファームウェアや機器情報を取得する情報取得手順と、
   前記情報取得手順で取得した情報に応じて前記通信装置の記憶媒体に記憶されている自己のバージョン情報を更新する情報更新手順と
   を設けたことを特徴とするネットワーク管理システムのバージョン管理方法。
9. 請求項７または８に記載のネットワーク管理システムのバージョン管理方法において、
   前記所定プロトコルは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とするネットワーク管理システムのバージョン管理方法。

Images