(57)【要約】【課題】オペレータ端末のミスオペレーションを削減しつつ、ネットワーク装置とディスアグリ機器を効率的に運用管理することができるオペレーションシステムを提供する。【解決手段】オペレーションシステム１００は、論理的なＮＥの識別情報ごとに、当該ＮＥのベンダ種別と、各ディスアグリ機器の構成機器名とを示した情報であるベンダ種別・構成機器情報と、論理的なＮＥに対する制御要求に対して、呼び出す各ディスアグリ機器とその呼び出し順序を規定するマルチベンダ制御定義ファイル１４０と、ＮＥとディスアグリ機器とを判別し、ディスアグリ機器の場合は、マルチベンダ制御定義ファイル１２０を参照して個々のディスアグリ機器に対するアクセス要求に分解して要求を送信する抽象化部１３０と、を備える。【選択図】図２
2019004433.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク装置と、前記ネットワーク装置を小さい粒度に分離および部品化したディスアグリゲーション機器の監視および制御を行うためのオペレーションシステムであって、
論理的なネットワーク装置の識別情報ごとに、当該ネットワーク装置のベンダ種別と、各前記ディスアグリゲーション機器の構成機器名とを示した情報であるベンダ種別・構成機器情報と、論理的なネットワーク装置に対する制御要求に対して、前記論理的なネットワーク装置を構成する各前記ディスアグリゲーション機器とその呼び出し順序を規定するマルチベンダ制御定義ファイルと、当該ベンダ種別および装置種別のネットワーク装置へのコマンド投入に用いるコマンドシーケンスを示したコマンドシーケンス定義ファイル、前記コマンドシーケンス定義ファイルの適用順を示した投入順序定義ファイル、および、前記コマンド投入時に用いる機能ごとに、当該機能の実現のために適用する前記投入順序定義ファイルの識別情報を示した投入順序選択定義ファイルを含む定義ファイルを記憶する記憶部と、
前記ネットワーク装置への制御オーダの入力を受け付け、前記入力された制御オーダに含まれるコマンドの投入先の前記ネットワーク装置の識別情報をキーとして、前記ベンダ種別・装置種別情報を参照して、前記コマンドの投入先のネットワーク装置のベンダ種別および装置種別を特定する共通部と、
前記ネットワーク装置と前記ディスアグリゲーション機器とを判別し、前記ディスアグリゲーション機器の場合は、前記マルチベンダ制御定義ファイルを参照して個々の前記ディスアグリゲーション機器に対するアクセス要求に分解して要求を送信する抽象化部と、
前記特定したベンダ種別および装置種別の定義ファイルを参照して、当該ネットワーク装置または前記ディスアグリゲーション機器の投入順序選択定義ファイルを特定し、前記特定した投入順序選択定義ファイルと、前記入力された制御オーダに含まれるネットワーク装置へのコマンドの投入に必要な機能の識別情報とを参照して、前記機能を実現するために必要な前記投入順序定義ファイルを特定する要求受付部と、
前記特定した投入順序定義ファイルを参照して、前記投入順序定義ファイルに示される順序で前記コマンドシーケンス定義ファイルを順次呼び出し、前記呼び出したコマンドシーケンス定義ファイルに基づき、前記ネットワーク装置または前記ディスアグリゲーション機器へコマンド投入を順次実行するコマンド変換部と、を備えることを特徴とするオペレーションシステム。
【請求項２】
前記抽象化部は、
オペレータ端末から、前記論理的なネットワーク装置を単一の前記ネットワーク装置として制御オーダを受付けるとともに、
前記論理的なネットワーク装置を構成する個々の物理的なディスアグリゲーション機器を単一の前記ネットワーク装置として扱うように、前記論理的なネットワーク装置に対する要求を各物理的なディスアグリゲーション機器に対する個々の要求に分割し、かつ、前記マルチベンダ制御定義ファイルに記載された順序でその要求を実行する
ことを特徴とする請求項１に記載のオペレーションシステム。
【請求項３】
前記定義ファイルは、さらに、
前記ネットワーク装置からのイベント通知を前記共通部で用いるデータへ変換するための定義情報を示した通知情報定義ファイル、および、前記イベント通知の種別ごとの前記通知情報定義ファイルを示した通知種別定義ファイルを、前記ネットワーク装置のベンダ種別および装置種別ごとに含んでおり、
前記オペレーションシステムは、さらに、
前記ネットワーク装置からのイベント通知を受信したとき、前記ベンダ種別・装置種別情報と前記イベント通知の送信元のネットワーク装置の識別情報とを参照して、前記ネットワーク装置のベンダ種別および装置種別を特定し、前記特定したベンダ種別および装置種別の定義ファイルにおける前記通知種別定義ファイルを参照して、当該ネットワーク装置からのイベント通知の種別に関する通知情報定義ファイルを特定し、前記特定した通知情報定義ファイルを参照して、前記ネットワーク装置からのイベント通知を、前記共通部で用いるデータへ変換して、前記共通部へ出力するイベント通知変換部をさらに備え、
前記イベント通知変換部は、
前記ネットワーク装置と前記ディスアグリゲーション機器とを判別し、前記ディスアグリゲーション機器の場合は、警報発生点情報を論理的なネットワーク装置を示す情報に変換して、前記共通部に出力することを特徴とする請求項１に記載のオペレーションシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の異なる種別のネットワーク装置（ＮＥ：network element）で構成されるネットワークにおいて、各ＮＥを監視・制御するオペレーションシステム（OpS）に関する。
【背景技術】
【０００２】
従来、ネットワークのＮＥと当該ＮＥを監視・制御するためのオペレーションシステムとは、ＮＥのベンダがセットで開発し、通信キャリア（キャリア）はそれらＮＥとオペレーションシステムとをセットで導入してきた。その結果としてキャリアのネットワークには多数の異なるベンダのオペレーションシステムが存在するので、オペレータ端末１のオペレータは各ベンダのオペレーションシステムを習熟した上で使用する必要がある。例えば、図１８に示すように、ベンダＡ社製のＮＥ３ＡについてはベンダＡ社製のオペレーションシステム２Ａを用い、ベンダＢ社製のＮＥ３ＢについてはベンダＢ社製のオペレーションシステム２Ｂを用い、ベンダＣ社製のＮＥ３ＣについてはベンダＢ社製のオペレーションシステム２Ｃを用いる必要があるので、オペレータは各ベンダのオペレーションシステムを習熟した上でＮＥへの設定入力等を行う必要がある。
また、一方でオペレーションシステムをマルチベンダ対応とする技術もある（非特許文献１参照）。例えば、オペレーションシステム４に、ベンダ非依存でオペレータからの設定入力を受け付けたり、各ＮＥからのイベント通知を出力したりする共通機能５と、Ａ社のＮＥ３Ａ，Ｂ社のＮＥ３Ｂ，Ｃ社製のＮＥ３Ｃとを接続するためのアダプタ６Ａ〜６Ｃを、各ベンダのＮＥごとに設ける技術がある（図１９参照）。このようなオペレーションシステムによれば、オペレータは、各ベンダのオペレーションシステムを習熟する必要がないので、各ベンダのＮＥへの設定入力等を容易に行うことができる。
【０００３】
近年、ネットワーク装置（ＮＥ）を小さい粒度に分離・部品化したディスアグリゲーション機器（dis-aggregated機器）(以下、ディスアグリ機器という)が登場し、伝送ＮＷをディスアグリ機器の組み合わせで構築する手法が導入されつつある（非特許文献２参照）。
なお、以下の説明において、ネットワーク装置（ＮＥ）とディスアグリ機器とを区別する場合、ネットワーク装置をオールインワン装置と呼ぶことがある。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ネットワークサービスを支えるサービスアクティベーション技術、ＮＴＴ技術ジャーナル２００５年８月１８〜２１頁 [online]、[平成29年6月5日検索]、インターネット<URL: http://www.ntt.co.jp/journal/0508/files/jn200508018.pdf>
【非特許文献２】Open ROADM overview,openroadm.org Multi-Source Agreement、[online]、[平成29年6月5日検索]、インターネット<URL: http://0201.nccdn.net/1_2/000/000/098/a85/Open-ROADM-whitepaper-v1-0.pdf>
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のオペレーションシステム技術には、下記の課題がある。個々のディスアグリ機器毎にネットワーク装置として管理する場合、（１）オペレータが意識するネットワーク装置数が膨大になる。（２）障害切り分け等により運用効率が低下する。（３）オペレータのミスオペレーションを誘発する。
【０００６】
このような背景を鑑みて本発明がなされたのであり、本発明は、オペレータ端末のミスオペレーションを削減しつつ、ネットワーク装置とディスアグリ機器を効率的に運用管理することができるオペレーションシステムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
前記した課題を解決するため、請求項１に記載の発明は、ネットワーク装置と、前記ネットワーク装置を小さい粒度に分離および部品化したディスアグリゲーション機器の監視および制御を行うためのオペレーションシステムであって、論理的なネットワーク装置の識別情報ごとに、当該ネットワーク装置のベンダ種別と、各前記ディスアグリゲーション機器の構成機器名とを示した情報であるベンダ種別・構成機器情報と、論理的なネットワーク装置に対する制御要求に対して、前記論理的なネットワーク装置を構成する各前記ディスアグリゲーション機器とその呼び出し順序を規定するマルチベンダ制御定義ファイルと、当該ベンダ種別および装置種別のネットワーク装置へのコマンド投入に用いるコマンドシーケンスを示したコマンドシーケンス定義ファイル、前記コマンドシーケンス定義ファイルの適用順を示した投入順序定義ファイル、および、前記コマンド投入時に用いる機能ごとに、当該機能の実現のために適用する前記投入順序定義ファイルの識別情報を示した投入順序選択定義ファイルを含む定義ファイルを記憶する記憶部と、前記ネットワーク装置への制御オーダの入力を受け付け、前記入力された制御オーダに含まれるコマンドの投入先の前記ネットワーク装置の識別情報をキーとして、前記ベンダ種別・装置種別情報を参照して、前記コマンドの投入先のネットワーク装置のベンダ種別および装置種別を特定する共通部と、前記ネットワーク装置と前記ディスアグリゲーション機器とを判別し、前記ディスアグリゲーション機器の場合は、前記マルチベンダ制御定義ファイルを参照して個々の前記ディスアグリゲーション機器に対するアクセス要求に分解して要求を送信する抽象化部と、前記特定したベンダ種別および装置種別の定義ファイルを参照して、当該ネットワーク装置または前記ディスアグリゲーション機器の投入順序選択定義ファイルを特定し、前記特定した投入順序選択定義ファイルと、前記入力された制御オーダに含まれるネットワーク装置へのコマンドの投入に必要な機能の識別情報とを参照して、前記機能を実現するために必要な前記投入順序定義ファイルを特定する要求受付部と、前記特定した投入順序定義ファイルを参照して、前記投入順序定義ファイルに示される順序で前記コマンドシーケンス定義ファイルを順次呼び出し、前記呼び出したコマンドシーケンス定義ファイルに基づき、前記ネットワーク装置または前記ディスアグリゲーション機器へコマンド投入を順次実行するコマンド変換部と、を備えることを特徴とするオペレーションシステムとした。
【０００８】
このようにすることで、オペレータ端末は個々のディスアグリ機器を意識しなくてよいため、効率的な運用、および、ミスオペレーションの削減が可能となる。これにより、オペレータのミスオペレーションを削減しつつ、ネットワーク装置とディスアグリ機器を効率的に運用管理することができる。
【０００９】
また、請求項２に記載の発明は、前記抽象化部は、オペレータ端末から、前記論理的なネットワーク装置を単一の前記ネットワーク装置として制御オーダを受付けるとともに、前記論理的なネットワーク装置を構成する個々の物理的なディスアグリゲーション機器を単一の前記ネットワーク装置として扱うように、前記論理的なネットワーク装置に対する要求を各物理的なディスアグリゲーション機器に対する個々の要求に分割し、かつ、前記マルチベンダ制御定義ファイルに記載された順序でその要求を実行することを特徴とするオペレーションシステムとした。
【００１０】
このようにすることで、論理的な単一のＮＥが複数ＩＰアドレスへ対応し、物理的なＮＥ：論理的なＮＥ＝Ｎ：１を実現することができる。オペレータ端末は個々のディスアグリ機器を、ＮＥとして管理しなくてよいので、効率的な運用、および、ミスオペレーションの削減が可能となる。
【００１１】
また、請求項３に記載の発明は、前記定義ファイルは、さらに、前記ネットワーク装置からのイベント通知を前記共通部で用いるデータへ変換するための定義情報を示した通知情報定義ファイル、および、前記イベント通知の種別ごとの前記通知情報定義ファイルを示した通知種別定義ファイルを、前記ネットワーク装置のベンダ種別および装置種別ごとに含んでおり、前記オペレーションシステムは、さらに、前記ネットワーク装置からのイベント通知を受信したとき、前記ベンダ種別・装置種別情報と前記イベント通知の送信元のネットワーク装置の識別情報とを参照して、前記ネットワーク装置のベンダ種別および装置種別を特定し、前記特定したベンダ種別および装置種別の定義ファイルにおける前記通知種別定義ファイルを参照して、当該ネットワーク装置からのイベント通知の種別に関する通知情報定義ファイルを特定し、前記特定した通知情報定義ファイルを参照して、前記ネットワーク装置からのイベント通知を、前記共通部で用いるデータへ変換して、前記共通部へ出力するイベント通知変換部をさらに備え、前記イベント通知変換部は、前記ネットワーク装置と前記ディスアグリゲーション機器とを判別し、前記ディスアグリゲーション機器の場合は、警報発生点情報を論理的なネットワーク装置を示す情報に変換して、前記共通部に出力することを特徴とする記載のオペレーションシステムとした。
【００１２】
このようにすることで、様々なベンダおよび機種のネットワーク装置または論理的なＮＥ（ディスアグリ機器の集合）からのイベント通知を受信した場合でも、このイベント通知の内容を、共通部で解釈したり、オペレーションシステムに接続される表示装置へ表示させたりすることができる。
【発明の効果】
【００１３】
本発明によれば、オペレータ端末のミスオペレーションを削減しつつ、ネットワーク装置とディスアグリ機器を効率的に運用管理することができるオペレーションシステムを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係るオペレーションシステムを示す構成図である。
【図２】本発明の実施形態に係るオペレーションシステムのベンダ種別・構成機器情報の例を示す図である。
【図３】本発明の実施形態に係るオペレーションシステムのマルチベンダ制御定義ファイルの例を示す図である。
【図４】本発明の実施形態に係るオペレーションシステムの制御系の機能ブロックを説明する図である。
【図５】本発明の実施形態に係るオペレーションシステムの抽象化部の処理を示すフローチャートである。
【図６】本発明の実施形態に係るオペレーションシステムの装置インタフェース部の処理を示すフローチャートである。
【図７】本発明の実施形態に係るオペレーションシステムの監視系の機能ブロックを説明する図である。
【図８】本発明の実施形態に係るオペレーションシステムの装置インタフェース部の警報／イベント通知変換部の動作を示すフローチャートである。
【図９】本発明の実施形態に係るオペレーションシステムのキー情報（装置登録）を説明する図である。
【図１０】本発明の実施形態に係るオペレーションシステムの装置登録時にオペレータ端末が入力する情報例を示す図であり、（ａ）はオールインワン装置の場合の例、ディスアグリ機器の場合の例である。
【図１１】本発明の実施形態に係るオペレーションシステムのキー情報（制御系）を説明する図である。
【図１２】本発明の実施形態に係るオペレーションシステムのパス登録時にオペレータ端末１が入力する情報例を示す図である。
【図１３】本発明の実施形態に係るオペレーションシステムの共通部から抽象化部への流通データ例を示す図である。
【図１４】本発明の実施形態に係るオペレーションシステムの抽象化部から装置インタフェース部への流通データ例を示す図である。
【図１５】本発明の実施形態に係るオペレーションシステムのキー情報（監視系）を説明する図である。
【図１６】本発明の実施形態に係るオペレーションシステムのネットワーク装置（ＮＥ）から通知される警報／イベント情報例を示す図である。
【図１７】本発明の実施形態に係るオペレーションシステムの装置インタフェース部から共通部への流通データ例を示す図である。
【図１８】従来の技術を説明するための図である。
【図１９】従来の技術を説明するための図である。
【図２０】従来のオペレーションシステムの概要を示すブロック構成図である。
【図２１】図２０の構成において、ディスアグリ機器が進展した場合の課題を説明する図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるオペレーションシステム等について説明する。
（背景説明）
図２０は、オペレータの負担を軽減するオペレーションシステムの概要を示すブロック構成図である。
図２０に示すように、システムには、オペレーションシステム１０と、ネットワークを構成するＮＥ３０（例えば、ＯＡＤＭ(Optical add-drop multiplexe)装置等）が複数台設置される。ＮＥ３０は、様々なベンダおよび機種（装置種別）のＮＥ３０であり、例えば、ＮＥ３０Ａ（ベンダＡ社製）、ＮＥ３０Ｂ（ベンダＢ社製）およびＮＥ３０Ｃ（ベンダＣ社製）の３種のＮＥ３０が設置される。
オペレーションシステム１０は、オペレータ端末１から、各ＮＥ３０への各種設定等を行うための制御オーダ２の入力を受け付けると、この制御オーダ２を各ベンダのＮＥ３０に適合した装置コマンドに変換して、ＮＥ３０へ投入する。また、オペレーションシステム１０は、各ＮＥ３０からのイベント通知３（例えば、ＮＥ３０からの警報等）を受信すると、このイベント通知の内容をオペレータ端末１で表示等が可能な形式へ変換して出力する。
【００１６】
オペレータ端末１経由でオペレーションシステム１０へ入力されたＮＥ３０への制御オーダ２は、オペレーションシステム１０の共通部１１（後記）で受け付ける。共通部１１は、ベンダ種別・装置種別情報ＤＢ１２を参照して、コマンドの投入先のネットワーク装置のベンダ種別および装置種別を特定する。共通部１１は、装置インタフェース部１３へＮＥアクセス要求１４（ＮＥ３０へのアクセス要求）を出力する。そして、装置インタフェース部１３は、ＮＥアクセス要求を受け付けると、このＮＥアクセス要求に含まれる当該ＮＥ３０のベンダ名および機種名から、このベンダ名および機種名のＮＥ３０へのコマンド投入に関する定義ファイル２０を読み込む。例えば、コマンド投入先がＮＥ３０Ａであった場合、装置インタフェース部１３はＡ社向け定義ファイル２０Ａを読み込む。そして、このＡ社向け定義ファイル２０Ａに基づき、ＮＥ３０Ａへ装置コマンド２１として投入を行う。
【００１７】
また、オペレーションシステム１０がＮＥ３０（例えば、ＮＥ３０Ｂ）からのイベント通知（例えば、警報等）を受信した場合、装置インタフェース部１３は、このＮＥ３０のベンダ名（ベンダ種別）および機種名を特定し、このベンダ名および機種名の定義ファイル２０Ｂ（例えば、Ｂ社向け定義ファイル）を読み出す。そして、装置インタフェース部１３は、読み出した定義ファイルに基づき、イベント通知２２を共通部１１で用いるデータへ変換して、共通部１１へ出力する。その後、共通部１１は、受信したイベント通知１５をオペレータ端末１へ出力する。同様に、オペレーションシステム１０がＮＥ３０Ｃからのイベント通知（例えば、警報等）を受信した場合、装置インタフェース部１３は、このＮＥ３０のベンダ名（ベンダ種別）および機種名を特定し、このベンダ名および機種名の定義ファイル２０Ｃ（例えば、Ｃ社向け定義ファイル）を読み出す。
【００１８】
ここで、共通部１１で入出力される情報はベンダや機種に依存しないので、オペレータがオペレーションシステム１０を操作するときの負荷を軽減することができる。また、オペレーションシステム１０は各ＮＥ３０のベンダおよび機種の組み合わせごとに、ＮＥ３０へのコマンドやＮＥ３０からのイベント通知の変換を行うための定義ファイルを備えており、この定義ファイルを参照することで、様々なベンダや機種のＮＥ３０へのコマンドやＮＥ３０からのイベント通知の変換を行うことができる。また、ＮＥ３０の仕様変更や新機種への変更があった場合は、この定義ファイルの改変を行えばいいので、共通部１１および装置インタフェース部１３のプログラム改変を行う必要がない。
【００１９】
このように、オペレーションシステム１０は、管理対象ベンダ差分を定義ファイル２０に局所化することで、オペレータの負担を軽減する。
【００２０】
図２１は、図２０の構成において、ディスアグリ機器が進展した場合の課題を説明する図である。
図２１の白抜き矢印に示すように、ディスアグリ機器３１が進展した場合の管理対象は、ディスアグリ機器３１ＡのＮＥ名は、“ａａ”であり機能１をサポートし、ベンダはＡ社である（以下、（ＮＥ名＝ａａ（機能１）（Ａ社）と表記）、ディスアグリ機器３１Ｂ（ＮＥ名＝ｂｂ（機能２）（Ｂ社））、ディスアグリ機器３１Ｃ（ＮＥ名＝ｃｃ（機能３）（Ｃ社））、…である。ディスアグリ機器３１におけるＮＥは、論理的なＮＥ３１０（例えばＮＥ名＝ＡＡである）（図２１破線囲み参照）。
【００２１】
従来のオペレーションシステム技術にあっては、ディスアグリ機器３１が進展した場合の管理対象が明らかではない。このため、（１）オペレータが意識するネットワーク装置数が膨大になる。（２）障害切り分け等により運用効率が低下する。（３）オペレータのミスオペレーションを誘発する。
【００２２】
（実施形態）
図１は、本発明の実施形態に係るオペレーションシステムを示す構成図である。図２１と同一構成部分には同一符号を付している。
オペレーションシステム１００は、ネットワーク装置（ＮＥ）と、ＮＥを小さい粒度に分離および部品化したディスアグリ機器の監視および制御を行うためのオペレーションシステム（オペレーションシステム）を備える装置である。
図１に示すように、システムには、オペレーションシステム１００と、ネットワークを構成するＮＥ３０（例えば、ＯＡＤＭ装置等）が複数台設置される。ＮＥ３０は、様々なベンダおよび機種（装置種別）のＮＥ３０であり、例えば、ＮＥ３０Ａ（ベンダＡ社製）、ＮＥ３０Ｂ（ベンダＢ社製）およびＮＥ３０Ｃ（ベンダＣ社製）の３種のＮＥ３０が設置される。また、ディスアグリ機器３１が進展した場合の管理対象は、ディスアグリ機器３１Ａ（ＮＥ名＝ａａ（機能１）（Ａ社））、ディスアグリ機器３１Ｂ（ＮＥ名＝ｂｂ（機能２）（Ｂ社））、ディスアグリ機器３１Ｃ（ＮＥ名＝ｃｃ（機能３）（Ｃ社））、…を備える。
【００２３】
オペレーションシステム１００は、共通部１１０と、ＥＭＳの記憶領域であるデータベース（ＤＢ）１２０（記憶部）と、抽象化部１３０と、マルチベンダ制御定義ファイル１４０と、定義ファイル２０と、装置インタフェース部１５０と、を備える。
【００２４】
<共通部１１０>
共通部１１０は、ＮＥ３０または論理的なＮＥ（ディスアグリ機器３１の集合）への制御オーダの入力を受け付け、入力された制御オーダに含まれるコマンドの投入先のＮＥ３０または論理的なＮＥ（ディスアグリ機器３１の集合）の識別情報をキーとして、ベンダ種別・構成機器情報を参照して、コマンドの投入先のネットワーク装置のベンダ種別および装置種別を特定する。
【００２５】
共通部１１０は、ＮＥ３０または論理的なＮＥ（ディスアグリ機器３１の集合）への制御オーダの入力を受け付ける。そして、共通部１１０は、入力された制御オーダに含まれるコマンドの投入先のＮＥ３０の識別情報をキーとして、このベンダ種別・構成機器情報を参照して、このコマンドの投入先のＮＥ３０のベンダ種別および構成機器を特定する。そして、共通部１１０はこの特定したベンダ種別および構成機器と、制御オーダに含まれる機能名（当該制御オーダにより実現する機能の識別情報）とを抽象化部１３０へ出力する。
共通部１１０は、装置インタフェース部１５０の警報／（以下、「／」は「および／または」を表記する）イベント通知変換部１５６（後記図７参照）経由でＮＥ３０からのイベント通知を受信したときには、この警報／イベント通知をオペレータ端末１へ出力する。
【００２６】
<ＤＢ１２０>
ＤＢ１２０は、論理的なＮＥ３１０の識別情報ごとに、当該ＮＥ３１０のベンダ種別と、各前記ディスアグリ機器の構成機器名と、ＩＰアドレスと、を示した情報であるベンダ種別・構成機器情報（後記図２参照）と、マルチベンダ制御定義ファイル（ＣＳＶ）１４０（後記図３参照）と、定義ファイル２０（後記図４参照）と、を格納する。なお、ＤＢ１２０は、共通部１１０の外部にあってもよい。なお、定義ファイル２０等は、特にデータベースに限定されるものではなく、どのような記憶部に記憶されるものでもよい。
【００２７】
<ベンダ種別・構成機器情報>
従来のＥＭＳでは、ＮＥ名と接続先のＮＥのＩＰアドレスの対応を１：１で管理していた。すなわち、従来のＥＭＳは、オールインワン装置での使用を想定しているので、ＮＥ名に毎に、ベンダ名と機種名と接続先ＩＰアドレスとを１：１で管理していた。これに対して、本実施形態では、ディスアグリ機器に対応する。このため、論理的なＮＥ名と接続先ＩＰアドレスを１：Ｎで管理する。
本ベンダ種別・構成機器情報は、装置登録時にＥＭＳの記憶領域であるＤＢ１２０に格納される。装置登録時、オペレータ端末１（図１参照）がＮＥ名／機種名／ＩＰアドレスを投入する。オペレーションシステム１００は、各制御時（パス登録等）には、本ベンダ種別・構成機器情報をもとに接続先ＩＰアドレスを特定する。
【００２８】
図２は、ベンダ種別・構成機器情報の例を示す図である。
図２に示すように、ベンダ種別・構成機器情報は、論理的なＮＥ名と、この論理的なＮＥ名に対応するベンダ名と、機種名と、構成機器名と、接続先ＩＰアドレスと、を有する。
図２に示すディスアグリ機器の場合、ＮＥ名は、論理的なＮＥ名「ＡＡ」「ＣＣ」を格納する。ベンダ名および機種名は、“mult”を格納する。構成機器名は、各ディスアグリ機器の名称（ａａ，ｂｂ，…）を格納する。接続先ＩＰアドレスは、「111. 111. 111. 111」「222. 222. 222. 222」…を格納する。このように、論理的なＮＥ名、例えばＮＥ名「ＡＡ」に対し、ベンダ名および機種名“mult”と、構成機器名（ａａ，ｂｂ，ｃｃ）と、接続先ＩＰアドレス「111. 111. 111. 111」「222. 222. 222. 222」「333. 333. 333. 333」とが、１：Ｎで管理される。
【００２９】
<抽象化部１３０>
抽象化部１３０は、オールインワン装置とディスアグリ機器とを判別し、ディスアグリ機器の場合は、マルチベンダ制御定義ファイル１４０を参照して個々のディスアグリ機器に対するアクセス要求に分解して順次、装置インタフェース部１５０へ要求を送信する。
抽象化部１３０は、共通部１１０（図１参照）から、論理的なＮＥ３１０を単一のＮＥとして制御オーダを受付けるとともに、個々の物理的なディスアグリ機器を単一のＮＥとして扱うように、論理的なＮＥ３１０と物理的なディスアグリ機器とを変換マッピングしたコマンドを送る。これにより、抽象化部１１０は、オペレータ端末１側である上位においては、論理的なＮＥ３１０を単一のＮＥとして扱うとともに、下位においては、個々の物理的なディスアグリ機器を単一のＮＥとして扱うようにする、論理的なＮＥと物理的なＮＥとの相互変換マッピングが実行される。
【００３０】
<マルチベンダ制御定義ファイル１４０>
マルチベンダ制御定義ファイル１４０は、単一の論理的なＮＥ３１０に対する制御要求に対して、呼び出す各ディスアグリ機器３１とその呼び出し順序を規定する。マルチベンダ制御定義ファイル１４０は、機能毎（装置登録、パス登録、等）にファイルを用意し、どのファイルを見るかのキーは機能名とする。
【００３１】
図３は、マルチベンダ制御定義ファイル１４０の例を示す図であり、ＤＢ１２０（記憶部）に保存される。
図３に示すように、マルチベンダ制御定義ファイル１４０は、＃ファイル名（setne.csv）毎に、＃ベンダ名（Ａ社、Ｂ社、Ｃ社…）とそれぞれの構成機器名（ａａ、ｂｂ、ｃｃ、…）を記憶する。抽象化部１３０は、このマルチベンダ制御定義ファイル１４０の若番から処理を実行する。この例では、１．Ａ社，ａａ、２．Ｂ社，ｂｂ、３．Ｃ社，ｃｃ…の順に処理を実行する。
【００３２】
<定義ファイル２０>
定義ファイル２０は、ベンダ種別・構成機器情報（図２参照）と、マルチベンダ制御定義ファイル（ＣＳＶ）１４０（図３参照）とともに、共通部１１０のＤＢ１２０に格納される。
定義ファイル２０は、装置インタフェース部１５０が、様々なベンダや機種のＮＥ３０へのコマンド投入や、ＮＥ３０からのイベント通知の変換を行う際に参照されるファイルである。この定義ファイル２０は、ＮＥ３０のベンダ種別および機種の組み合わせごとに用意され、投入順序選択定義ファイル（ＣＳＶ）１７１（図４参照）、投入順序定義ファイル（ＣＳＶ）１７２（図４参照）、投入順序定義ファイル（スクリプト）１７３（図４参照）、コマンドシーケンス定義ファイル（ＣＳＶ）１７４（図４参照）、パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５（図４参照）を含む。これらのファイルは、例えば、ＣＳＶ形式のファイルやスクリプトが記述されたファイルであり、入出力部（図示省略）経由で適宜書き換え可能である。このようにすることで、ＮＥ３０やディスアグリ機器３１の仕様変更や機種変更時において、オペレーションシステム１００に複雑な改変を行う必要がなくなる。
【００３３】
［機能ブロック（制御系）］
次に、オペレーションシステム１００の制御系の機能ブロックを説明する。
図４は、オペレーションシステム１００の制御系の機能ブロックを説明する図である。図１と同一構成部分には、同一符号を付している。
図４に示すように、オペレーションシステム１００は、抽象化部１３０と、マルチベンダ制御定義ファイル１４０と、装置インタフェース部１５０と、を備える。
【００３４】
<装置インタフェース部１５０>
装置インタフェース部１５０は、要求受付部１５１と、コマンド変換／シーケンス制御部１５２と、通信処理部１５３と、通信処理部１５４と、通信処理部１５５と、を備える。
【００３５】
<要求受付部１５１>
要求受付部１５１は、特定したベンダ種別および装置種別の定義ファイル２０を参照して、ネットワーク装置３０の投入順序選択定義ファイル（ＣＳＶ）１７１を特定し、特定した投入順序選択定義ファイル（ＣＳＶ）１７１と、入力された制御オーダに含まれるネットワーク装置またはディスアグリ機器３１へのコマンドの投入に必要な機能の識別情報とを参照して、機能を実現するために必要な投入順序定義ファイル（ＣＳＶ）１７２を特定する。
要求受付部１５１は、共通部１１０から出力されたベンダ名および機種名のＮＥ３０またはディスアグリ機器３１に関する定義ファイル２０における投入順序選択定義ファイル（ＣＳＶ）１７１と、オペレーションシステム１００に入力された制御オーダに含まれるＮＥ３０へのコマンドの投入に必要な機能の識別情報とを参照して、当該機能を実現するために必要な投入順序定義ファイル（ＣＳＶ）１７２を特定する。
【００３６】
<コマンド変換／シーケンス制御部１５２>
コマンド変換／シーケンス制御部１５２は、特定した投入順序定義ファイル（ＣＳＶ）１７２を参照して、投入順序定義ファイル（ＣＳＶ）１７２に示される順序でコマンドシーケンス定義ファイル（ＣＳＶ）１７４を順次呼び出し、呼び出したコマンドシーケンス定義ファイル（ＣＳＶ）１７４に基づき、ネットワーク装置３０またはディスアグリ機器３１へコマンド投入を順次実行する。
コマンド変換／シーケンス制御部１５２は、要求受付部１５１で特定された投入順序定義ファイル（ＣＳＶ）１７２を参照して、投入順序定義ファイル（ＣＳＶ）１７２に示される順序でコマンドシーケンス定義ファイル（ＣＳＶ）１７４を順次呼び出す。そして、コマンド変換／シーケンス制御部１５２は、呼び出したコマンドシーケンス定義ファイル（ＣＳＶ）１７４に基づき、通信処理部１５３〜１５５経由でＮＥ３０またはディスアグリ機器３１へコマンド投入を順次実行する。
【００３７】
<通信処理部１５３〜１５５>
通信処理部１５３〜１５５は、コマンド変換／シーケンス制御部１５２から発行されたコマンドをＮＥ３０へ投入したり、ＮＥ３０側からのイベント通知を受信したりするときのインタフェースである。この通信処理部１５３〜１５５は、例えば、ＮＥ３０とオペレーションシステム１０との通信に用いるプロトコルごとに用意される。例えば、ＮＥ３０とオペレーションシステム１０との通信に用いるプロトコルがＴＬ１（Transaction Language 1）、ＳＮＭＰ（Simple ＮＥtwork Management Protocol）およびＣＬＩ（Command LiＮＥ Interface）の３種の場合、各通信プロトコルごとに通信処理部１５３〜１５５を用意する。
【００３８】
<ＤＢ１２０>
ＤＢ１２０は、ベンダ種別・構成機器情報と、マルチベンダ制御定義ファイル（ＣＳＶ）１４０（図３参照）と、投入順序選択定義ファイル（ＣＳＶ）１７１と、投入順序定義ファイル（ＣＳＶ）１７２と、投入順序定義ファイル（スクリプト）１７３と、コマンドシーケンス定義ファイル（ＣＳＶ）１７４と、パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５と、を記憶する。
【００３９】
<投入順序選択定義ファイル（ＣＳＶ）１７１>
投入順序選択定義ファイル（ＣＳＶ）１７１は、ＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）へのコマンドの投入に必要な機能（例えば、ＮＥ３０の設定や、各ＮＥ３０間におけるパスの設定等）ごとに、当該機能の実現のために適用する投入順序定義ファイルの識別情報を示した情報である。例えば、投入順序選択定義ファイル（ＣＳＶ）１７１は、ＣＳＶ（Comma Separated Value）形式で記述され、ＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）へのコマンドの投入に必要な機能名および当該機能の実現のために適用する投入順序定義ファイル名の他に、投入順序定義ファイル１７２によるコマンド投入の投入順序決定方式や、コマンド投入の異常発生時におけるロールバックに適用するロールバック用投入順序定義ファイル名や、ロールバック用投入順序決定方式等を含んでいてもよい。
【００４０】
<投入順序定義ファイル（ＣＳＶ）１７２>
投入順序定義ファイル（ＣＳＶ）１７２は、適用すべきコマンドシーケンス定義ファイルと、そのコマンドシーケンス定義ファイル（ＣＳＶ）１７４の適用順とを示した情報である。この投入順序定義ファイルも、例えば、ＣＳＶ形式で記述される（図６参照）。
ここで、コマンド投入対象のＮＥ３０が１台、かつ、どのコマンドシーケンス定義ファイル（ＣＳＶ）１７４をどの順序で投入するかが定義ファイル２０（図１参照）の作成時に決定できる場合、投入順序定義ファイル（ＣＳＶ）１７２には、固定シーケンスとしてＣＳＶ形式のファイルを指定しておく。
【００４１】
<投入順序定義ファイル（スクリプト）１７３>
投入順序定義ファイル（スクリプト）１７３は、適用すべきコマンドシーケンス定義ファイル（ＣＳＶ）１７４と、そのコマンドシーケンス定義ファイル（ＣＳＶ）１７４の適用順とを示した情報であり、スクリプト形式で記述される。つまり、投入順序定義ファイル（スクリプト）１７３には、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の適用順を決定するためのスクリプトが記述されている。スクリプトの記述には、例えば、python等を用いる。このようにすることで、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の適用順序（呼び出し順序）が非固定シーケンスである場合、例えば、ＮＥ３０の装置状況やコマンド応答結果により、コマンドやコマンド投入シーケンスを動的に変更する必要がある場合でも、これに対応することができる。
【００４２】
一方で、投入対象のＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）が複数台、または、どの投入順序定義ファイル（ＣＳＶ）１７２をどの順序で実行するかが定義ファイル２０（図１参照）作成時に決定不可の場合は、投入順序定義ファイル（スクリプト）１７３には、動的（非固定）シーケンスとするようにスクリプト形式の投入順序定義ファイル（スクリプト）１７３を指定しておけばよい。例えば、このスクリプト形式の投入順序定義ファイル（スクリプト）１７３を参照した要求受付部１５１は、投入順序番号と、この投入順序番号それぞれに対応するコマンドシーケンス定義ファイル（ＣＳＶ）１７４とを示したリストを出力する。
【００４３】
<コマンドシーケンス定義ファイル（ＣＳＶ）１７４>
コマンドシーケンス定義ファイル（ＣＳＶ）１７４は、ＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）へのコマンド投入に用いるコマンドシーケンスを示した情報である。このコマンドシーケンス定義ファイル（ＣＳＶ）１７４も、例えば、ＣＳＶ形式で記述される。例えば、コマンドシーケンス定義ファイル（ＣＳＶ）１７４は、コマンドシーケンス定義ファイル（ＣＳＶ）１７４のファイル名と、コマンド投入を実行するときの実行判定をどのように行うか、コマンドのコマンドＩＤ、送信待ち時間、送信文字列、応答タイムアウト待ち時間、応答待ち文字列、応答正常性を判定どのように行うか（応答正常性判定）、コマンド投入において呼び出す関数名（シーケンス制御定義ファイル）等が記述される。
【００４４】
なお、このコマンドシーケンス定義ファイル（ＣＳＶ）１７４は、さらに、ＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）へのコマンドの投入に用いる通信プロトコルのプロトコル識別子を含んでいてもよい。そして、コマンド変換／シーケンス制御部１５２（後記）によるＮＥ３０へのコマンド投入時には、このコマンドシーケンス定義ファイル（ＣＳＶ）１７４に示されるプロトコル識別子の示すプロトコルモジュールでＮＥ３０へコマンド投入を実行する。
【００４５】
<パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５>
パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５は、コマンドシーケンス定義ファイル（ＣＳＶ）１７４に基づくコマンド投入の実行にあたり呼び出されるスクリプトを記述したファイルであり、例えば、ＴＬ１コマンドの送信前チェックや、ＴＬ１実行結果の判定処理等のスクリプトを記述したファイルである。このようにコマンドシーケンス定義ファイル（ＣＳＶ）１７４とは別に、シーケンス制御定義ファイルを用意しておくことで、コマンドシーケンス自体を非固定的なものとすることができる。
【００４６】
以下、上述のように構成されたオペレーションシステム１００の動作を説明する。
［オペレーションシステム１００の動作概要］
まず、オペレーションシステム１００の動作概要について説明する。
オペレーションシステム１００は、オペレータ端末１から、各ＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）への各種設定等を行うための制御オーダ２の入力を受け付けると、この制御オーダ２を各ベンダのＮＥ３０に適合した装置コマンドに変換して、ＮＥ３０へ投入する。また、オペレーションシステム１００は、各ＮＥ３０からのイベント通知３（例えば、ＮＥ３０からの警報等）を受信すると、このイベント通知の内容をオペレータ端末１で表示等が可能な形式へ変換して出力する。
【００４７】
オペレータ端末１経由でオペレーションシステム１００へ入力されたＮＥ３０または論理的なＮＥ３１０（ディスアグリ機器３１の集合）への制御オーダ２は、オペレーションシステム１０の共通部１１０で受け付ける。共通部１１０は、ベンダ種別・装置種別情報ＤＢを参照して、コマンドの投入先のネットワーク装置のベンダ種別および装置種別を特定する。
【００４８】
共通部１１０は、抽象化部１３０へＮＥアクセス要求（ＮＥ３０へのアクセス要求）を出力する。
図１の破線の上下矢印に示すように、オペレーションシステム１００は、抽象化部１３０より上位は論理的なＮＥ３１０（ディスアグリ機器３１の集合）を１ＮＥとして扱う。これにより、オペレータ端末１向けに従来通りのＶＩＥＷ（視点・見え方）を提供する。一方、オペレーションシステム１００は、抽象化部１３０より下位は個々の物理的なディスアグリ機器３１を単一のＮＥとして扱う。このために、抽象化部１３０は、マルチベンダ制御定義ファイル１４０（図３参照）参照して、論理的なＮＥ３１０と物理的なディスアグリ機器３１との変換・マッピングを行う。図２１のシステムは、１ＮＥ１ＩＰアドレスであったのに対し、本実施形態では、論理的な単一のＮＥが複数ＩＰアドレスへ対応する。個々のディスアグリ機器３１を意識しなくてよいので、効率的な運用、および、ミスオペレーションの削減が可能になる。
【００４９】
装置インタフェース部１５０は、ＮＥアクセス要求を受け付けると、このＮＥアクセス要求に含まれる当該ＮＥ３０またはディスアグリ機器３１のベンダ名および機種名から、このベンダ名および機種名のＮＥ３０へのコマンド投入に関する定義ファイル２０（図１参照）を読み込む。例えば、コマンド投入先がＮＥ３０Ａであった場合、装置インタフェース部１５０はＡ社向け定義ファイル２０Ａを読み込む。そして、この定義ファイル２０Ａに基づき、ＮＥ３０Ａへのコマンド投入を行う。
【００５０】
また、オペレーションシステム１００がＮＥ３０（例えば、ＮＥ３０Ｂ）からのイベント通知（例えば、警報等）を受信した場合（図７参照）、装置インタフェース部１５０は、このＮＥ３０のベンダ名（ベンダ種別）および機種名を特定し、このベンダ名および機種名の定義ファイル２０Ｂ（例えば、Ｂ社向け定義ファイル）を読み出す。そして、装置インタフェース部１５０は、読み出した定義ファイル２０Ｂに基づき、イベント通知を共通部１１０で用いるデータへ変換して、抽象化部１３０へ出力する。
その後、共通部１１０は、受信したイベント通知をオペレータ端末１（図１参照）へ出力する。
以上、オペレーションシステム１００の動作概要について説明した。以下、オペレーションシステム１００の抽象化部１３０および装置インタフェース部１５０の詳細動作について説明する。
【００５１】
［抽象化部１３０および装置インタフェース部１５０の動作］
<抽象化部１３０の動作>
まず、図４を参照して、抽象化部１３０が共通部１１０（図１参照）からＮＥアクセス要求の入力を受け付けたときの処理を説明する。
図４に示すように、抽象化部１３０は、共通部１１０（図１参照）からＮＥアクセス要求を受け付ける。ＮＥアクセス要求には、オールインワン装置へのＮＥアクセス要求とディスアグリ機器３１へのＮＥアクセス要求とがある。
抽象化部１３０は、ＮＥアクセス要求内のベンダ名から、ＮＥアクセス要求（オールインワン装置）とＮＥアクセス要求（ディスアグリ機器３１）を判定する。
ＮＥアクセス要求（オールインワン装置）の場合、抽象化部１３０は、装置インタフェース部１５０へ要求を送信する（図４の符号ａ参照）。
【００５２】
一方、ＮＥアクセス要求（ディスアグリ機器３１）の場合、抽象化部１３０は、マルチベンダ制御定義ファイル１４０を参照し、単一の論理ＮＥ３１０に対する制御要求に対して、呼び出す各ディスアグリ機器３１とその呼び出し順序を決定する（図４の符号ｂ参照）。
そして、抽象化部１３０は、個々のディスアグリ機器３１に対するＮＥアクセス要求に分解して順次、装置インタフェース部１５０へ要求を送信する（図４の符号ｃ参照）。
【００５３】
<装置インタフェース部１５０の動作>
次に、装置インタフェース部１５０の要求受付部１５１は、抽象化部１３０からオールインワン装置ＮＥ３０へのＮＥアクセス要求を受け付ける。要求受付部１５１は、ＮＥアクセス要求内のベンダ名、機種名から、呼び出す定義ファイル２０（図１参照）を特定する（図４の符号ｄ参照）。そして、要求受付部１５１は、特定した定義ファイル２０の投入順序選択定義ファイル（ＣＳＶ）１７１を読み込み、この投入順序選択定義ファイル（ＣＳＶ）１７１におけるＮＥアクセス要求内の機能名に対応する行から、参照すべき投入順序定義ファイル（ＣＳＶ）１７２を特定する。また、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の呼び出し順序が固定シーケンスか非固定シーケンスかを判断する（図４の符号ｅ参照）。
【００５４】
次に、要求受付部１５１は、特定した投入順序定義ファイル（ＣＳＶ）１７２を参照することで、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の呼び出し順序を決定する（図４の符号ｆ参照）。ここで、特定した投入順序定義ファイル（ＣＳＶ）１７２がＣＳＶ形式であれば、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の呼び出し順序は固定シーケンスとなる。一方、図４の「ＯＲ」で示すように、特定した投入順序定義ファイル（ＣＳＶ）１７３がスクリプト形式であればコマンドシーケンス定義ファイル（ＣＳＶ）１７４の呼び出し順序は非固定シーケンス（スクリプトにより動的に決定されるシーケンス）となる。
【００５５】
そして、コマンド変換／シーケンス制御部１５２は、要求受付部１５１により決定されたコマンドシーケンス定義ファイル（ＣＳＶ）１７４を順次呼び出す（図４の符号ｇ参照）。そして、コマンド変換／シーケンス制御部１５２は、呼び出したコマンドシーケンス定義ファイル（ＣＳＶ）１７４の内容を一行ずつ実行する。パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５は、コマンドシーケンス定義ファイル（ＣＳＶ）１７４により随時呼び出し可能である（図４の符号ｈ参照）。パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５は、用途としては、ＴＬ１コマンド送信前チェック、およびＴＬ１実行結果判定処理などに用いる。
コマンドシーケンス定義ファイル（ＣＳＶ）１７４に、シーケンス制御定義ファイル（ＣＳＶ）の記述があった場合、コマンド変換／シーケンス制御部１５２は、これに従い、パラメータ変換／シーケンス制御定義ファイル（スクリプト）１７５を呼び出し、この呼び出したファイルに記述されるスクリプトを実行する。
【００５６】
その後、コマンド変換／シーケンス制御部１５２は、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の実行結果（装置コマンド）を、通信処理部１５３〜１５５経由で所定の通信プロトコルによりＮＥ３０へ送信する。例えば、図４に例示するように、コマンド変換／シーケンス制御部１５２がＮＥ３０Ａへ装置コマンドを投入する場合において、このＮＥ３０Ａとの通信プロトコルがＴＬ１であった場合、このＴＬ１の通信プロトコルを実装した通信処理部１５３〜１５５経由で装置コマンド（コマンド）を投入する。このようにすることで、オペレーションシステム１００は様々なベンダ、様々な機種のＮＥ３０に対してコマンドを投入することができる。
【００５７】
次に、図４で説明したＮＥアクセス要求を受け付けた抽象化部１３０の処理の詳細を、図５のフローチャートを用いて説明する。また、図５のフローチャートで説明する抽象化部１３０からのＮＥアクセス要求を受け付けた装置インタフェース部１５０の処理の詳細を、図６のフローチャートを用いて説明する。
［抽象化部１３０の動作詳細］
図５および図６は、オペレーションシステム１００の動作を示すフローチャートであり、図５は、抽象化部１３０の処理を示すフローチャート、図６は、図５の連結子Ａ，Ｂで移行した装置インタフェース部１５０の処理を示すフローチャートである。
図５に示すように、抽象化部１３０は、共通部１１０（図１参照）からＮＥアクセス要求を受け付ける（ステップＳ１０）。
ステップＳ１１で抽象化部１３０は、ＮＥアクセス要求内のベンダ名からオールインワン型ＯＲディスアグリ型（オールインワン装置ＯＲディスアグリ機器）を判定する。
ベンダ名が“multi”以外の場合、オールインワン型であると判断して、装置インタフェース部１５０の処理（図６参照）に移行する。
【００５８】
ベンダ名が“multi”の場合、ディスアグリ型であると判断して、ステップＳ１２で抽象化部１３０は、ＮＥアクセス要求内の機能名から呼び出すマルチベンダ制御定義ファイル１４０（図３参照）を特定する。
ステップＳ１３で抽象化部１３０は、マルチベンダ制御定義ファイル１２０の実行状態が最終行か否かを判別する。なお、ステップＳ１３では、装置インタフェース部１５０の処理（図５参照）からの応答返却分についても判別する。
【００５９】
マルチベンダ制御定義ファイル１４０の実行状態が最終行の場合（ステップＳ１３：Ｙｅｓ）、ステップＳ１４で抽象化部１３０は、共通部１１０へ応答を返却する。
マルチベンダ制御定義ファイル１４０の実行状態が最終行でない場合（ステップＳ１３：Ｎｏ）、ステップＳ１５に進む。
【００６０】
ステップＳ１５で抽象化部１３０は、マルチベンダ制御定義ファイル１４０（図３参照）を特定について、未実行かつ若番の行から評価を実行する。具体的には、抽象化部１３０は、読み込んだ情報をもとにＮＥアクセス要求を再生成（ベンダ名、構成機器名を取得した値で上書き）し、装置インタフェース部１５０へ要求を送信する。構成機器名は、機種名に上書きする。
ステップＳ１５の処理後、図４の抽象化部１３０の処理を抜けて図５の装置インタフェース部１５０の処理に移行する。
【００６１】
［装置インタフェース部１５０の動作詳細］
次に、装置インタフェース部１５０の動作について詳細に説明する。
図５に示すように、装置インタフェース部１５０は、抽象化部１３０（図１参照）からＮＥアクセス要求受け付ける（ステップＳ２０）。
装置インタフェース部１５０の要求受付部１５１は、抽象化部１３０からＮＥ３０へのＮＥアクセス要求を受け付けると、ステップＳ２１でＮＥアクセス要求内のベンダ名および機種名から、呼び出す投入順序選択定義ファイル（ＣＳＶ）１７１（図２参照）を特定する。
【００６２】
ステップＳ２２で要求受付部１５１は、この特定した投入順序選択定義ファイル（ＣＳＶ）１７１を読み込み、ＮＥアクセス要求内の機能名に対応する行から、投入順序定義ファイル（ＣＳＶ）１７２（図２参照）を特定する。
ステップＳ２３で要求受付部１５１は、特定した投入順序選択定義ファイル（ＣＳＶ）１７１の内容からコマンドシーケンス定義ファイル（ＣＳＶ）１７４（図２参照）の投入順序が、固定か動的（非固定）かを判定する。
投入順序が固定と判定された場合（ステップＳ２３で「固定」）、ステップＳ２４で要求受付部１５１は、上記ステップＳ２１で特定された投入順序選択定義ファイル（ＣＳＶ）１７１に示されるＣＳＶ形式の投入順序定義ファイル（ＣＳＶ）１７２を読み込み、この投入順序定義ファイル（ＣＳＶ）１７２に基づきコマンドシーケンス定義ファイル（ＣＳＶ）１７４の実行手順を決定する。そして、ステップＳ２６へ進む。
【００６３】
一方、上記ステップＳ２３の判定において投入順序が固定ではないと判定された場合（ステップＳ２３で「動的」）、ステップＳ２５で要求受付部１５１は、投入順序選択定義ファイル（ＣＳＶ）１７１に示される、スクリプトが記述された投入順序定義ファイル（スクリプト）１７３（図２参照）を読み込み、この投入順序定義ファイル（スクリプト）１７３に基づきコマンドシーケンス定義ファイル（ＣＳＶ）１７４の実行手順を決定する（Ｓ２２）。そして、ステップＳ２６へ進む。
【００６４】
ステップＳ２６では、コマンド変換／シーケンス制御部１５２（図２参照）は、投入順序定義ファイル（ＣＳＶ）１７２に示されるコマンドシーケンス定義ファイル（ＣＳＶ）１７４のうち未実行のコマンドシーケンス定義ファイル（ＣＳＶ）１７４が存在するか否かを確認する。
未実行のコマンドシーケンス定義ファイル（ＣＳＶ）１７４が存在する場合（ステップＳ２６：Ｙｅｓ）、ステップＳ２７でコマンド変換／シーケンス制御部１５２は、未実行のコマンドシーケンス定義ファイル（ＣＳＶ）１７４の中から投入順序番号＝最若番のファイルを特定する。
【００６５】
そして、ステップＳ２８でコマンド変換／シーケンス制御部１５２は、特定した投入順序番号＝最若番のコマンドシーケンス定義ファイル（ＣＳＶ）１７４を読み込む。
ステップＳ２９でコマンド変換／シーケンス制御部１５２は、未実行の行について、上から１行実行する。
ステップＳ３０でコマンド変換／シーケンス制御部１５２は、コマンドシーケンス定義ファイル（ＣＳＶ）１７４の最終行まで到達したか否かを判別する。
ファイルの最終行まで到達している場合（ステップＳ３０：Ｙｅｓ）、上記ステップＳ２６へ戻る。ファイルの最終行まで到達していない場合（ステップＳ３０：Ｎｏ）、上記ステップＳ２９へ戻る。
【００６６】
一方、上記ステップＳ２６において、コマンド変換／シーケンス制御部１５２は、投入順序定義ファイル（ＣＳＶ）１７２に示されるコマンドシーケンス定義ファイル（ＣＳＶ）１７４をすべて実行した場合（ステップＳ２６：Ｎｏ）、ステップＳ３１でコマンド変換／シーケンス制御部１５２は、その旨の応答を抽象化部１３０へ返却する。この返却により抽象化部１３０の処理（図４参照）に移行する。
【００６７】
そして、コマンド変換／シーケンス制御部１５２は、このコマンドシーケンス定義ファイル（ＣＳＶ）１７４の実行結果に基づき、通信処理部１５３〜１５５経由でＮＥ３０または論理的なＮＥ（ディスアグリ機器３１の集合）への装置コマンドの投入を行う。
【００６８】
［機能ブロック（監視系）］
次に、オペレーションシステム１００の監視系の処理について説明する。
図７は、オペレーションシステム１００の監視系の機能ブロックを説明する図である。図１と同一構成部分には、同一符号を付している。
装置インタフェース部１５０がＮＥ３０Ａからイベント通知を受信した場合を例に説明する。なお、ここでは図１の共通部１１０、抽象化部１３０、装置インタフェース部１５０の要求受付部１５１およびコマンド変換／シーケンス制御部１５２は図示を省略している。
図７に示すように、オペレーションシステム１００の装置インタフェース部１５０は、警報／イベント通知変換部１５６と、通信処理部１５３〜１５５と、を備える。
また、ＤＢ１２０（記憶部）は、警報／イベント通知定義ファイル（ＣＳＶ）１８１と、警報／イベント通知定義ファイル（スクリプト）１８２と、警報／イベント通知種別定義ファイル（ＣＳＶ）１８３と、装置リストファイル１８４と、を記憶する。装置リストファイル１８４は、前記ベンダ種別・構成機器情報（図２参照）を記憶する。
警報／イベント通知種別定義ファイル（ＣＳＶ）１８３は、ＮＥ３０（例えばＮＥ３０Ａ）のベンダ名および機種名に関する定義ファイル２０（図２参照）の通知種別定義ファイルである。
【００６９】
警報／イベント通知変換部１５６は、オールインワン装置とディスアグリ機器とを判別し、警報発生点を以下の規則（１）（２）で組み立てる。すなわち、（１）オールインワン装置の場合、警報発生点は、ＮＥ名（物理）と警報発生部位情報である。（２）ディスアグリ構成の場合、警報発生点は、ＮＥ名（論理）と構成機器名と警報発生部位情報である。
【００７０】
以上の構成において、装置インタフェース部１５０の警報／イベント通知変換部１５６は、ＮＥ３０Ａからの警報／イベント通知を通信処理部１５３〜１５５経由で受け付ける。すると、警報／イベント通知変換部１５６は、装置リストファイル１８４を参照し、ＩＰアドレスをキーにして論理的なＮＥ名（例えばＡＡ）と機種名（例えばａａ）を取得する（図７の符号ｉ参照）。
次に、図７の符号ｊに示すように、警報／イベント通知変換部１５６は、ＮＥ名および機種名をキーにして、警報／イベント通知種別定義ファイル１８３を特定し、読み込む。
【００７１】
そして、図７の符号ｋに示すように、警報／イベント通知変換部１５６は、この警報／イベント通知種別定義ファイル１８３に示される、次に読み出す警報／イベント通知定義ファイル１８１を特定し、読み込む。警報／イベント通知変換部１５６は、警報／イベント通知定義ファイル（ＣＳＶ）１８１または警報／イベント通知定義ファイル（スクリプト）１８２を参照して、受信した警報／イベント通知を共通部１１０（図１参照）で処理可能なデータモデルへ変換し、出力する。つまり、警報／イベント通知変換部１５６は、ＮＥ３０のベンダや機種に非依存のイベント通知を、共通部１１０へ出力する。その後、共通部１１０は、この警報／イベント通知の内容をオペレータ端末１（図１参照）等へ出力する。
【００７２】
図７に示した、警報／イベント通知変換部１５６が、ＮＥ３０からの警報／イベント通知を受け付けたときの処理を、図８を用いて詳細に説明する。
［警報／イベント通知変換部１５６の動作詳細］
図８は、装置インタフェース部１５０の警報／イベント通知変換部１５６の動作を示すフローチャートである。
装置インタフェース部１５０の警報／イベント通知変換部１５６は、ＮＥ３０からの警報／イベント通知を通信処理部１５３〜１５５経由で受け付ける（ステップＳ４０）。
ステップＳ４１で警報／イベント通知変換部１５６は、このＮＥ３０が警報／イベント通知を受信したときの当該ＮＥ３０との間のセッション情報から、このＮＥ３０のベンダ名および機種名を特定し、この特定したベンダ名および機種名から、呼び出す警報／イベント通知種別定義ファイル１８３を特定する。
ステップＳ４２で警報／イベント通知変換部１５６は、この呼び出した警報／イベント通知種別定義ファイル１８３を読み込み、ＮＥ３０から受け付けた警報／イベント通知に関する警報／イベント通知定義ファイル（ＣＳＶ）１８１を特定する。
【００７３】
つまり、まず、警報／イベント通知変換部１５６は、セッション情報に含まれるイベント通知の送信元のＮＥ３０の識別情報と、装置リストファイル１８４（ベンダ種別・構成機器情報）とを参照して、警報／イベント通知の送信元のＮＥ３０のベンダ名および機種名を特定する。そして、警報／イベント通知変換部１５６は、この特定したベンダ名および機種名のＮＥ３０の警報／イベント通知種別定義ファイル１８３から、この警報／イベント通知の種別に関する警報／イベント通知定義ファイル（ＣＳＶ）１８１を特定する。
【００７４】
ステップＳ４３で警報／イベント通知変換部１５６は、特定した警報／イベント通知定義ファイル（ＣＳＶ）１８１を読み込み、ＮＥ３０からのイベント通知を、共通データモデル（共通部１１０で処理可能なデータモデル）へ変更する。
ここで、警報／イベント通知変換部１５６は、送信元がディスアグリ機器３１の場合には「警報発生点」情報を論理的なＮＥを示す情報に変換する。具体的には、警報／イベント通知変換部１５６は、送信元がディスアグリ機器３１の場合、“ＮＥ名”に論理的なＮＥ名を付与する。また、“rackNo”や“shelfNo”には、論理的なＮＥを構成する各ディスアグリ機器毎にルールを警報／イベント通知定義ファイル（ＣＳＶ）１８１に記述しておくことで、共通部１１０向けに論理的なＮＥの構成要素として通知する。
ステップＳ４４で警報／イベント通知変換部１５６は、共通部１１０へ応答（共通データモデルへ変更した警報／イベント通知）を返却する。
【００７５】
このようにすることで、装置インタフェース部１５０は、様々なベンダや機種のＮＥ３０からのイベント通知を受信したときでも、警報／イベント通知種別定義ファイル１８３および警報／イベント通知定義ファイル（ＣＳＶ）１８１を参照することで、この警報／イベント通知の内容を共通部１１０および入出力部２１０経由で、図１のオペレータ端末１へ出力することができる。
【００７６】
［キー情報（装置登録）］
次に、オペレーションシステム１００のキー情報（装置登録）の処理について説明する。
図９は、オペレーションシステム１００のキー情報（装置登録）を説明する図である。図１と同一構成部分には、同一符号を付している。
図９の符号ｌに示すように、オペレータ端末１は、管理対象装置をオペレーションシステム１００へ登録する装置登録処理を行う。
【００７７】
図１０は、装置登録時にオペレータ端末１が入力する情報例を示す図であり、図１０（ａ）はオールインワン装置の場合の例、図１０（ｂ）はディスアグリ機器の場合の例である。
まず、図９に示す装置登録では、図１０（ａ）に示すオールインワン装置の管理情報を登録する。例えば、オールインワン装置の場合、ＮＥ名＝ＢＢ、ベンダ名＝Ｘ社、機種名＝ｙｙ、ＩＰアドレス=444.444.444.444、構成機器名＝−、その他情報を登録する。
また、図１０（ｂ）に示すディスアグリ機器の管理情報を登録する。例えば、ディスアグリ機器の場合、ＮＥ名＝ＡＡ、ベンダ名＝multi、機種名＝multi、構成機器名として
・構成機器名＝ａａ、ＩＰアドレス＝111.111.111.111
・構成機器名＝ｂｂ、ＩＰアドレス＝222.222.222.222
・構成機器名＝ｃｃ、ＩＰアドレス＝333.333.333.333
、その他情報を登録する。
【００７８】
このように、ディスアグリ機器の装置登録では、装置名（論理）と、そこに含まれる各機器情報（名称、ＩＰアドレス）を投入する。
上記装置登録により、図９の共通部１１０のＤＢ１２０へオールインワン装置およびディスアグリ機器の管理情報が登録される。前記図２は、装置登録時に共通部１１０のＤＢ１２０へ登録するベンダ種別・構成機器情報である。
前記図２に示すように、ディスアグリ構成の場合、ＮＥ名は、論理的なＮＥ名「ＡＡ」「ＣＣ」を格納し、ベンダ名および機種名は、“mult”を格納する。構成機器名は、各ディスアグリ機器の名称（ａａ，ｂｂ，…）を格納し、接続先ＩＰアドレスは、「111. 111. 111. 111」「222. 222. 222. 222」…を格納する。
このように、論理的なＮＥ名に対し、ベンダ名および機種名“mult”と、構成機器名（ａａ，ｂｂ，ｃｃ）と、接続先ＩＰアドレス「111. 111. 111. 111」「222. 222. 222. 222」「333. 333. 333. 333」とが、１：Ｎで登録される。
【００７９】
［キー情報（制御系）］
次に、オペレーションシステム１００のキー情報（制御系）の処理について説明する。
図１１は、オペレーションシステム１００のキー情報（制御系）を説明する図である。図１と同一構成部分には、同一符号を付している。
図１１の符号ｍに示すように、オペレータ端末１は、オペレーションシステム１００へ制御オーダを登録するパス登録処理を行う。
ここで、制御オーダは、例えばパッケージ登録、パス登録、等の各種の登録・削除・参照・更新処理である。
【００８０】
図１２は、パス登録時にオペレータ端末１が入力する情報例を示す図である。
オペレータ端末１は、パス登録時に、制御対象の装置名（論理）と対象操作（機能名）、および付随する各種パラメータを投入する。
図１２の情報例では、ＮＥ名＝ＡＡ、機能名＝パス登録、その他情報として、パス登録処理に必要な各種パラメータが入力される。
【００８１】
図１３は、共通部１１０から抽象化部１３０への流通データ例を示す図である。
図１１の符号ｎに示すように、抽象化部１３０は、共通部１１０のＤＢ１２０からベンダ名・機種名を取得して下部へ流通させる。
図１３の流通データ例では、ＮＥ名＝ＡＡ、ベンダ名＝multi、機種名＝multi、機能名＝パス登録、その他情報として、パス登録処理に必要な各種パラメータを取得する。
図１３に示すように、ディスアグリ構成の場合は、ベンダ名・機種名ともに“multi”を登録する。
【００８２】
前記図３は、マルチベンダ制御定義ファイル１４０の例を示す図である。
前記図３に示すように、マルチベンダ制御定義ファイル１４０は、＃ファイル名（setne.csv）毎に、＃ベンダ名（Ａ社、Ｂ社、Ｃ社…）とそれぞれの構成機器名（ａａ、ｂｂ、ｃｃ、…）を記憶する。
図１１の符号ｏに示すように、抽象化部１３０は、ベンダ名＝“multi”の場合は機能名＝“パス登録（setne）”をキーにマルチベンダ制御定義ファイル１４０を特定する。
【００８３】
図１１は、抽象化部１３０から装置インタフェース部１５０への流通データ例を示す図である。
図１１の符号ｐに示すように、抽象化部１３０は、ベンダ名・機種名をマルチベンダ制御定義ファイル１４０から取得した値で上書きして装置インタフェース部１５０へ流通させる。
図１１の流通データ例では、ＮＥ名＝ＡＡ、ベンダ名＝Ａ社、機種名＝ａａ、機能名＝パス登録、その他情報として、パス登録処理に必要な各種パラメータを流通させる。
【００８４】
［キー情報（監視系）］
次に、オペレーションシステム１００のキー情報（監視系）の処理について説明する。
図１５は、オペレーションシステム１００のキー情報（監視系）を説明する図である。図１と同一構成部分には、同一符号を付している。なお、図１の抽象化部１３０、装置インタフェース部１５０の要求受付部１５１、コマンド変換／シーケンス制御部１５２および通信処理部１５３〜１５５は図示を省略している。
図１５の符号ｑに示すように、装置インタフェース部１５０は、ＮＥ３０Ａからの警報／イベント通知を受け付ける。
【００８５】
図１６は、ネットワーク装置（ＮＥ）３０Ａなどから通知される警報／イベント情報例を示す図である。
図１６に示すように、警報／イベント情報は、ＩＰレイヤと、ＳＮＭＰレイヤとを有する。ＩＰレイヤは、送信元ＩＰ、送信先ＩＰ等を有する。また、ＳＮＭＰレイヤは、各種ヘッダと、VariableBindingsと、を有し、VariableBindingsは、警報発生点（例えば、CONT）、時刻（例えば、2017:06:06）、トラップ種別（例えば、eqpt-arm）、障害レベル（例えば、sa）、感知重要度（例えば、critical）等を有する。
【００８６】
図１５の符号ｒに示すように、装置インタフェース部１５０（図７の警報／イベント通知変換部１５６）は、受信した警報／イベント情報（図１６参照）を共通部１１０（図１参照）で処理可能なデータモデルへ変換する。
その際にディスアグリ機器の場合には「警報発生点」情報を論理的なＮＥを示す情報に変換する。例えば、”ＮＥ名”に論理的なＮＥ名を付与する。また、”rackNo”や”shelfNo”には、論理的なＮＥを構成する各ディスアグリ機器毎にルールを定義ファイルに記述しておく。そして、共通部１１０向けに論理的なＮＥの構成要素として通知する。
【００８７】
図１７は、装置インタフェース部１５０から共通部１１０への流通データ例を示す図である。
図１７に示すように、共通部１１０へのデータは、共通部１１０で処理可能な各種ヘッダ、通知種別（例えば、AlarmNotification）、警報発生点（例えば、ＮＥ名／rackNo／shelfNo／slotNo）、時刻（例えば、2017:06:06）、トラップ種別（例えば、eqpt-arm）、障害レベル（例えば、sa）、感知重要度（例えば、critical）に書き換えられる。この例では、図１６に示す「警報発生点（CONT）」が、図１７に示す「警報発生点（ＮＥ名／rackNo／shelfNo／slotNo）」に書き換えられ、共通部１１０で処理可能なデータとなる。
【００８８】
以上説明したように、本実施形態に係るオペレーションシステム１００は、論理的なＮＥの識別情報ごとに、当該ＮＥのベンダ種別と、各ディスアグリ機器の構成機器名とを示した情報であるベンダ種別・構成機器情報と、論理的なＮＥに対する制御要求に対して、呼び出す各ディスアグリ機器とその呼び出し順序を規定するマルチベンダ制御定義ファイル１４０と、ＮＥとディスアグリ機器とを判別し、ディスアグリ機器の場合は、マルチベンダ制御定義ファイル１２０を参照して個々のディスアグリ機器に対するアクセス要求に分解して要求を送信する抽象化部１３０と、を備える。抽象化部１３０は、オペレータ端末１（図１参照）から、論理的なネットワーク装置を単一のＮＥとして制御オーダを受付けるとともに、個々の物理的なディスアグリ機器を単一のＮＥとして扱うように、論理的なＮＥと物理的なＮＥとを変換マッピングしたコマンドを送る。
【００８９】
この構成により、オペレータ端末１のオペレータは、個々のディスアグリ機器を意識しなくてよいため、効率的な運用、および、ミスオペレーションの削減が可能となる。これにより、オペレータ端末１のミスオペレーションを削減しつつ、ＮＥとディスアグリ機器を効率的に運用管理することができる。
【００９０】
なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００９１】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
【符号の説明】
【００９２】
１  オペレータ端末
２０  定義ファイル
３０  ネットワーク装置（ＮＥ）
３１  ディスアグリ機器（ディスアグリゲーション機器）
１００  オペレーションシステム
１１０  共通部
１２０  データベース（ＤＢ）（記憶部）
１３０  抽象化部
１４０  マルチベンダ制御定義ファイル
１５０  装置インタフェース部
１５１  要求受付部
１５２  コマンド変換／シーケンス制御部
１５３〜１５５  通信処理部
１５６  警報／イベント通知変換部
１７１  投入順序選択定義ファイル（ＣＳＶ）
１７２  投入順序定義ファイル（ＣＳＶ）
１７３  投入順序定義ファイル（スクリプト）
１７４  コマンドシーケンス定義ファイル（ＣＳＶ）
１７５  パラメータ変換／シーケンス制御定義ファイル（スクリプト）
１８１  警報／イベント通知定義ファイル（ＣＳＶ）
１８２  警報／イベント通知定義ファイル（スクリプト）
１８３  警報／イベント通知種別定義ファイル
１８４  装置リストファイル
３１０  論理的なＮＥ
【図１】
2019004433.tif 000003
【図２】
2019004433.tif 000004
【図３】
2019004433.tif 000005
【図４】
2019004433.tif 000006
【図５】
2019004433.tif 000007
【図６】
2019004433.tif 000008
【図７】
2019004433.tif 000009
【図８】
2019004433.tif 000010
【図９】
2019004433.tif 000011
【図１０】
2019004433.tif 000012
【図１１】
2019004433.tif 000013
【図１２】
2019004433.tif 000014
【図１３】
2019004433.tif 000015
【図１４】
2019004433.tif 000016
【図１５】
2019004433.tif 000017
【図１６】
2019004433.tif 000018
【図１７】
2019004433.tif 000019
【図１８】
2019004433.tif 000020
【図１９】
2019004433.tif 000021
【図２０】
2019004433.tif 000022
【図２１】
2019004433.tif 000023