JP2014006573A - タスク実行順序制御機能を含む監視制御システム - Google Patents

Abstract

【課題】タスクの実行順序制御が必要な単位に処理順序を保証したマルチスレッドによる並列処理を行う。
【解決手段】複数のネットワーク機器を集中管理する監視制御システムは、システム内の全てのタスクを順次格納する単一のマスタスレッドプールと；タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと；前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にするように構成されるプロセッサと；を備える。
【選択図】図１

Description

本発明は、タスク実行順序制御機能を含む監視制御システムに関する。

ネットワーク構成要素である複数のネットワーク機器を集中管理する監視制御システムは、複数のネットワーク機器などから受信したタスク（task）対応のイベント処理をシングルスレッド（single threading）またはマルチスレッド（multi threading）で実行す
る。

この監視制御システムにおける動作主体であるハードウェアのプロセッサ、つまりＣＰＵ（Central Processing Unit）は、シングルコアからマルチコアに、更にはメニーコア
へと進歩しており、複数コアの性能を生かすためには、複数のスレッド（実行の脈絡：thread of execution）を同時に実行して並列に処理を進めるマルチスレッド処理が必須で
ある。

一方、監視制御システムが提供する機能において、処理の順序性を保証しなければならない機能がある。例えば、障害管理機能では、ネットワーク機器（ＮＥ）の障害を検出するために、次に示す処理（ａ），（ｂ），（ｃ）が行われる。
（ａ）ＮＥからの障害（ＡＬＭ）発生についての自律通知受信による障害発生処理。
（ｂ）ＮＥからのＡＬＭ回復（復旧）についての自律通知受信による障害復旧処理。
（ｃ）ＮＥへのＡＬＭ情報読出要求による監視制御システム内の障害情報の最新化処理（同期処理）。

しかし、これらの処理が輻輳し並列化することに起因して、処理順序が逆転してしまった場合、誤った障害情報をオペレータに表示する恐れがある。ＡＬＭ発生からＡＬＭ回復の瞬時警報を、ＡＬＭ回復からＡＬＭ発生の順に処理が逆転すると、誤って障害発生状態となることを免れない。

特表２００５−５０５８３３号公報 特開２０１０−７３２１４号公報

上述した監視制御システムでは、上記処理（ａ），（ｂ），（ｃ）の実行順序制御を保証するために、次に示す３つの対策を実施している。
（１）シングルスレッドで管理対象の全ＮＥの障害情報を逐次処理する。
（２）複数のスレッドプールを利用し、マルチスレッドで全ＮＥの障害情報を並列処理するが、実行順序制御が必要な箇所を排他制御する。
（３）ＮＥからの自律通知では障害情報を更新せずに、自律通知を契機に、ＮＥから障害情報を読み出して更新する。

しかし、これらの対策によると、次に示す問題が生じる。

対策（１）では、逐次処理であるので、性能劣化が起きやすい。

対策（２）では、並列処理は担保できているが、あるＮＥで障害情報が輻輳した場合、マルチスレッドが特定のＮＥの処理に占有されてしまう。このため、他のＮＥの障害情報が処理でキューイングされてしまい、輻輳が発生したＮＥもしくはネットワークの影響で、管理対象外のＮＥの処理が遅延してしまう。また、排他制御がボトルネックとなり、性能劣化が起きやすい。

対策（３）では、自律通知受信の都度、ＮＥから障害情報の読み出しを行うので、障害通知のリアルタイム性が保証できず、監視制御システムの性能要件が満たされない。

なお、上記先行技術文献には、マルチスレッドによる並列処理を行うことを開示するものがあるが、上述した全ての問題点を解決するものはない。

課題は、タスクの実行順序制御が必要な単位に処理順序を保証したマルチスレッドによる並列処理を行うことを可能にする技術を提供することにある。

上記課題を解決するために、複数のネットワーク機器を集中管理する監視制御システムは、システム内の全てのタスクを順次格納する単一のマスタスレッドプールと；タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと；前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にするように構成されるプロセッサと；を備える。

開示した監視制御システムによれば、タスクの実行順序制御が必要な単位に（例えば、ネットワーク機器単位に、またはネットワーク機器のグループ毎に）処理順序を保証したマルチスレッドによる並列処理を実現でき、ハードウェアのプロセッサ性能を最大限に活用することができる。

他の課題、特徴及び利点は、図面及び特許請求の範囲とともに取り上げられる際に、以下に記載される発明を実施するための形態を読むことにより明らかになるであろう。

第１〜第５の実施の形態における監視制御システムの構成を示すブロック図。 図１におけるマスタスレッドプール及びスレーブスレッドプールの詳細構成を示す図。 図１における振分管理テーブルの詳細構成を示す図。 第１の実施の形態における処理手順を説明するためのフローチャート。 第２の実施の形態における処理手順を説明するためのフローチャート。 第３の実施の形態における処理手順を説明するためのフローチャート。 第３の実施の形態における処理手順を説明するためのフローチャート。 第４の実施の形態における処理手順を説明するためのフローチャート。 第４の実施の形態における処理手順を説明するためのフローチャート。 第５の実施の形態における処理手順を説明するためのフローチャート。

以下、添付図面を参照して、さらに詳細に説明する。図面には好ましい実施形態が示されている。しかし、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されない。

［第１の実施の形態］
第１の実施の形態におけるシステム構成を示す図１を参照すると、タスク実行順序制御機能を含む監視制御システムＯｐＳは、例えばサーバコンピュータに備えられ、ネットワーク構成要素である複数のネットワーク機器ＮＥ（ＮＥ＃０１，ＮＥ＃０２，・・・ＮＥ＃Ｎ）と、オペレータ端末ＯＰＴとにインタフェースする。これらのネットワーク機器（ネットワーク構成装置）ＮＥは、伝送対象データをパケット形態で伝送（転送及び交換を含む）するために、各通信局に配置された伝送装置である。

この監視制御システムＯｐＳは、ハードウェア構成として、次の要素を含んでいる。つまり、監視制御システムＯｐＳは、プロセッサとしての複数コアのＣＰＵ（Central Processing Unit）と、作業用メモリとしてのＲＡＭ（Random Access Memory）と、立ち上げ
のためのブートプログラムを格納したＲＯＭ（Read Only Memory）とを備える。

また、監視制御システムＯｐＳは、ＯＳ（Operating System）、各種アプリケーションプログラム、及び各種情報（データを含む）を書換え可能に格納する不揮発性のフラッシュメモリと、通信インタフェースなどとを備える。これらのハードウェア構成は、当業者が容易に理解でき、実施可能であるので、ここでは図示を省略している。

後に詳述するタスク実行順序制御機能を論理的に実現するには、監視制御システムＯｐＳにおいて、フラッシュメモリにタスク実行順序制御プログラムをアプリケーションプログラムとしてインストールしておく。そして、オペレータ端末ＯＰＴからの要求、及び複数のネットワーク機器ＮＥからの通知をそれぞれ契機に、ＣＰＵがこのタスク実行順序制御プログラムをＲＡＭに展開して実行する。

複数のネットワーク機器ＮＥを集中管理する監視制御システムＯｐＳは、オペレータ端末ＯＰＴ及び複数のネットワーク機器ＮＥから受信したタスク対応のイベント処理をマルチスレッドで実行する。ここで重要な事項は、後に詳述するように、タスクがネットワーク機器単位、または必要によりネットワーク機器のグループ毎に処理順序を保証したマルチスレッドで並列処理されることである。

監視制御システムＯｐＳは、このシステム内の全てのタスクを受け付ける１つ（単一）のマスタスレッドプール２と、タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプール（＃００１，＃００２，＃００３，・・・＃Ｎ）３とを備える。

マスタスレッドプール２及び各スレーブスレッドプール３は、ＲＡＭに論理的に構成され、図２に詳細を示すように、１つのワークキューと、１つのワーカースレッドとを含む。ここで、ワークキューは、処理依頼されたタスク、または振り分けられたタスクをＦＩＦＯ（First in First out）形式で蓄積する。ワーカースレッドは、最大１スレッドであり、ワークキューに蓄積されているタスクを順次に実行する。

また、監視制御システムＯｐＳは、オペレータ端末ＯＰＴのインタフェースＧＵＩ（Graphical User Interface）を介して、オペレータ操作による要求（例えば、障害（ＡＬＭ）情報読出）をタスクとして受信するＧＵＩ要求受信機能部４と、複数のネットワーク機器ＮＥからの通知（例えば、障害（ＡＬＭ）発生、障害（ＡＬＭ）復旧）をタスクとして受信するＮＥ通知受信機能部５と、ＧＵＩ要求受信機能部４及びＮＥ通知受信機能部５からのタスクを受け付けるタスク受付機能部６とを備える。

ここで、複数のネットワーク機器ＮＥからの通知には、オペレータ操作による要求に応じて通知される場合と、オペレータ操作による要求に関わりなく自律通知される場合がある。

タスク受付機能部６で受け付けられたタスクは、複数のネットワーク機器ＮＥのそれぞれを一意に識別可能な装置識別子として、ＩＰ（Internet Protocol）アドレス、または
ネットワーク機器ＮＥ毎に設定された個別識別子（ネットワーク機器ＩＤ（ＮＥ−ＩＤ））を含む。ここでは、オペレータ操作による要求時には、装置識別子として、ネットワーク機器ＩＤ（ＮＥ−ＩＤ）がオペレータ端末ＯＰＴから指定され、ネットワーク機器ＮＥからの通知時には、装置識別子として、ＩＰアドレスがネットワーク機器ＮＥからの送信パケットに含まれるものとする。

タスク受付機能部６には、タスクに実行順序制御を行うための処理識別子（処理ＩＤ）を付与する処理ＩＤ設定機能部７が付随する。この処理ＩＤ設定機能部７は、タスク受付機能部６で受け付けられたタスクに含まれている装置識別子としてのＩＰアドレスまたはネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、ＮＥ構成情報テーブル８を検索し、オペレータ端末ＯＰＴから予め指定された処理ＩＤとしてのネットワーク機器ＩＤ（ＮＥ−ＩＤ）またはグループ識別子（グループＩＤ）を取得する。そして、処理ＩＤ設定機能部７は、取得した処理ＩＤ（この第１の実施の形態では、ネットワーク機器ＩＤ（ＮＥ−ＩＤ））をタスクに設定した後に、このタスクをマスタスレッドプール２に処理依頼として登録する。

ＮＥ構成情報テーブル８は、フラッシュメモリに格納され、オペレータ端末ＯＰＴからの初期設定などにより、ネットワーク機器ＩＤ（ＮＥ−ＩＤ：＃Ｎ０１，＃Ｎ０２，・・・＃ＮＮ）、ＩＰアドレス（ｘｘｘ，ｙｙｙ，・・・ａｂｃ）、グループＩＤ（＃Ｇ０１，＃Ｇ０１，・・・＃Ｇ０５）、及びグループ名（新宿局，新宿局，・・・横浜局）がＮＥ構成情報として対応付けられている。

監視制御システムＯｐＳはスレーブスレッドプール振分機能部９を更に備える。このスレーブスレッドプール振分機能部９は、マスタスレッドプール２からタスクを取り出し、タスクに付与（設定）されている処理ＩＤ（ここでは、ネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、振分管理テーブル１０から予め対応付けされているスレーブスレッドプール識別子（スレーブスレッドプールＩＤ）を取得する。そして、スレーブスレッドプール振分機能部９は、スレーブスレッドプールＩＤに対応するスレーブスレッドプール３にタスクを振り分けて、タスクを実行可能にする。

振分管理テーブル１０は、フラッシュメモリに構成され、図３に詳細を示すように、スレーブスレッドプールＩＤ（＃００１，＃００２，＃００３，・・・＃Ｎ）及び処理ＩＤ（＃Ｎ０１，＃Ｎ０２，＃Ｎ０３，・・・＃ＮＮ）、更にスレーブスレッドプール振分機能部９がアクセスした時刻（最終アクセス時刻）をスレーブスレッドプールＩＤ毎に格納している。この振分管理テーブル１０におけるスレーブスレッドプールＩＤ及び処理ＩＤは、オペレータ端末ＯＰＴからの初期設定などにより、予め格納される。なお、後述するように、オペレータ端末ＯＰＴから予め指定された処理ＩＤがグループＩＤである場合、振分管理テーブル１０における処理ＩＤには、グループＩＤ対応の情報＃Ｇ０１，・・・＃Ｇ０５が予め格納される。この場合、処理ＩＤとしての同一グループＩＤの情報（例えば、＃Ｇ０１）は、１つのスレーブスレッドプールＩＤ（例えば、＃００１）に１：１の関係で対応付けられる。

続いて、第１の実施の形態の監視制御システムＯｐＳにおける動作例について、図４を
併せ参照して説明する。

例えば、ＩＰアドレス＝ｘｘｘのネットワーク機器ＮＥからＡＬＭ発生通知及びこれに続いてＡＬＭ復旧通知を受信した場合、これらの自律通知の受信毎に、ＮＥ通知受信機能部５は、タスク受付機能部６にタスク処理を依頼する。

タスク受付機能部６は、これらのタスク処理依頼を受け付け、受け付けた順番に処理ＩＤ設定機能部７を呼び出す（図４中の４０１）。

処理ＩＤ設定機能部７は、タスクに含まれている装置識別子としてのＩＰアドレスに基づいて、ＮＥ構成情報テーブル８を検索し、対応のネットワーク機器ＩＤ（ＮＥ−ＩＤ＝＃Ｎ０１）を取得し、タスクに処理ＩＤ（＃Ｎ０１）を設定した後、マスタスレッドプール２にタスクを登録する（４０２，４０３）。

スレーブスレッドプール振分機能部９は、マスタスレッドプール２のワークキュー及びワーカースレッドからＡＬＭ発生通知及びＡＬＭ復旧通知に対応するタスクを逐次処理で取り出し、タスクに設定されている処理ＩＤをそれぞれ取得する（４０４，４０５）。

スレーブスレッドプール振分機能部９は、取得した処理ＩＤ（＃Ｎ０１）に基づいて、振分管理テーブル１０を検索し、これらの処理ＩＤに対応するスレーブスレッドプールＩＤ（ここでは、＃００１）を取得する（４０６）。

スレーブスレッドプール振分機能部９は、取得したスレーブスレッドプールＩＤに対応するスレーブスレッドプール（＃００１）３に対してタスクを振り分ける（４０７）。

この結果、スレーブスレッドプール（＃００１）３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される（４０８）。

なお、ＩＰアドレス＝ｘｘｘのネットワーク機器ＮＥからＡＬＭ発生通知及びこれに続いてＡＬＭ復旧通知を受信することと別に、例えばＩＰアドレス＝ｙｙｙのネットワーク機器ＮＥからＡＬＭ発生通知及びこれに続いてＡＬＭ復旧通知を受信した場合、これらの自律通知の受信毎に、ＮＥ通知受信機能部５は、タスク受付機能部６にタスク処理を依頼することになる。

タスク受付機能部６、処理ＩＤ設定機能部７、及びスレーブスレッドプール振分機能部９における上述した同様の処理により、スレーブスレッドプール振分機能部９は、スレーブスレッドプールＩＤ（＃００２）に対応するスレーブスレッドプール（＃００２）３に対してタスクを振り分ける。

この結果、スレーブスレッドプール（＃００２）３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される。このとき、上述したスレーブスレッドプール（＃００１）３と、スレーブスレッドプール（＃００２）３とにおけるタスクは、ネットワーク機器（ＮＥ＃０１，ＮＥ＃０２）単位に処理順序を保証したマルチスレッドで並列処理される。

また、監視制御システムＯｐＳのオペレータが、オペレータ端末ＯＰＴのインタフェースＧＵＩを通して、ＮＥ−ＩＤ＝＃Ｎ０１，＃Ｎ０２のネットワーク機器ＮＥに対するＡＬＭ情報読出を要求した場合、これらの要求の受信毎に、ＧＵＩ要求受信機能部４は、タスク受付機能部６にタスク処理を依頼することになる。

この場合、処理ＩＤ設定機能部７は、タスクに含まれている装置識別子としてのネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、ＮＥ構成情報テーブル８を存在確認のために検索し、対応のネットワーク機器ＩＤ（ＮＥ−ＩＤ＝＃Ｎ０１，＃Ｎ０２）を取得することが異なるだけである。

オペレータ操作による要求に応じて通知されるＩＰアドレス＝ｘｘｘ，ｙｙｙのネットワーク機器ＮＥからのＡＬＭ発生通知及びＡＬＭ復旧通知を受信した場合、これらの通知の受信毎に、ＮＥ通知受信機能部５が、タスク受付機能部６にタスク処理を依頼することにより、上記同様に処理される。

上述した第１の実施の形態の監視制御システムＯｐＳにおいては、処理ＩＤ単位に複数のスレーブスレッドプール３にタスクを振り分けることにより、処理ＩＤ毎のタスクが各スレーブスレッドプール３のワークキューにキューイングされ、１つのワーカースレッドで逐次処理されることにより、処理ＩＤ単位に処理順序、つまりタスク実行順序を保証することができる。

また、上述した第１の実施の形態の監視制御システムＯｐＳにおいては、オペレータ端末ＯＰＴからの要求及びネットワーク機器ＮＥからの通知は、タスク受付機能部６によって受信された順序を保証することができる。

さらに、上述した第１の実施の形態の監視制御システムＯｐＳにおいては、ある特定のネットワーク機器ＮＥの輻輳が管理対象の他のネットワーク機器ＮＥの処理に影響を与えることがないので、フェールセーフなシステムを構築することができる。

［第２の実施の形態］
図１に示す監視制御システムＯｐＳは、第２の実施の形態においては、スレーブスレッドプール生成機能部１１を更に備える。

この第２の実施の形態においては、スレーブスレッドプール振分機能部９は、タスクに設定された処理ＩＤ対応のスレーブスレッドプールＩＤが振分管理テーブル１０に存在しない場合、存在しないことをスレーブスレッドプール生成機能部１１に通知する。

この通知を受けたスレーブスレッドプール生成機能部１１は、対応するスレーブスレッドプール３を動的に新規生成すると共に、この処理ＩＤ対応のスレーブスレッドプールＩＤを振分管理テーブル１０に登録する。

つまり、図５を併せ参照すると、スレーブスレッドプール振分機能部９は、タスク受付機能部６及び処理ＩＤ設定機能部７における処理（図４中の４０１，４０２，４０３参照）に続いて、マスタスレッドプール２のワークキュー及びワーカースレッドからタスクを逐次処理で取り出し、タスクに設定されている処理ＩＤを取得する（図５中の５０１，５０２）。

スレーブスレッドプール振分機能部９は、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤが存在するか判定する（５０３）。

スレーブスレッドプール振分機能部９は、スレーブスレッドプールＩＤが存在しないことを判定した場合、存在しないことをスレーブスレッドプール生成機能部１１に通知する。

この通知を受けたスレーブスレッドプール生成機能部１１は、対応するスレーブスレッドプール３を生成すると共に、この処理ＩＤ対応のスレーブスレッドプールＩＤを振分管理テーブル１０に登録した後、スレーブスレッドプール振分機能部９を起動する（５０４，５０５）。

スレーブスレッドプール振分機能部９は、処理５０３においてスレーブスレッドプールＩＤが存在することを判定した場合、または処理５０５に続いてスレーブスレッドプール生成機能部１１から起動された場合、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤを取得する（５０６）。

スレーブスレッドプール振分機能部９は、取得したスレーブスレッドプールＩＤに対応するスレーブスレッドプール３に対してタスクを振り分ける（５０７）。

この結果、上述した第１の実施の形態と同様に、スレーブスレッドプール３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される（図４中の４０８参照）。

上述した第２の実施の形態においては、例えば、管理対象のネットワーク機器ＮＥが追加されて処理ＩＤが増加し、スレーブスレッドプールＩＤが登録されていない場合においても、動的にスレーブスレッドプールを生成すると共に、この処理ＩＤ対応のスレーブスレッドプールＩＤを振分管理テーブル１０に登録することができる。

［第３の実施の形態］
図１に示す監視制御システムＯｐＳは、第３の実施の形態においては、スレーブスレッドプール振分機能部９と連携するスレーブスレッドプール使用状況確認機能部１２及びスレーブスレッドプール削除機能部１３を更に備える。

この第３の実施の形態においては、スレーブスレッドプール振分機能部９は、マスタスレッドプール２からタスクを逐次処理で取り出し、タスクに設定された処理ＩＤに基づいて振分管理テーブル１０を検索する。

そして、スレーブスレッドプール振分機能部９は、処理ＩＤに対応するスレーブスレッドプールＩＤを単独またはスレーブスレッドプール生成機能部１１との協働により取得した際に、振分管理テーブル１０にアクセスした時刻を最終アクセス時刻としてスレーブスレッドプールＩＤ毎に記録することによって更新する。

例えば、図３に示す振分管理テーブル１０においては、各スレーブスレッドプールＩＤに対応して、次のような最終アクセス時刻が記録されている。

スレーブスレッドプールＩＤ＝＃００１への最終アクセス時刻は、２０１１／９／９ １３：００：０１。

スレーブスレッドプールＩＤ＝＃００２への最終アクセス時刻は、２０１１／９／９ １３：００：３０。

スレーブスレッドプールＩＤ＝＃００３への最終アクセス時刻は、２０１１／９／８ ２０：３０：０２。

スレーブスレッドプールＩＤ＝＃Ｎへの最終アクセス時刻は、２０１１／９／９ １３
：０２：１２。

図６を併せ参照すると、スレーブスレッドプール振分機能部９は、タスク受付機能部６及び処理ＩＤ設定機能部７における処理（図４中の４０１，４０２，４０３参照）に続いて、マスタスレッドプール２のワークキュー及びワーカースレッドからタスクを逐次処理で取り出し、タスクに設定されている処理ＩＤを取得する（図６中の６０１，６０２）。

スレーブスレッドプール振分機能部９は、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤが存在するか判定する（６０３）。

スレーブスレッドプール振分機能部９は、スレーブスレッドプールＩＤが存在しないことを判定した場合、存在しないことをスレーブスレッドプール生成機能部１１に通知する。

この通知を受けたスレーブスレッドプール生成機能部１１は、対応するスレーブスレッドプール３を生成すると共に、この処理ＩＤ対応のスレーブスレッドプールＩＤを振分管理テーブル１０に登録した後、スレーブスレッドプール振分機能部９を起動する（６０４，６０５）。

スレーブスレッドプール振分機能部９は、処理６０３においてスレーブスレッドプールＩＤが存在することを判定した場合、または処理６０５に続いてスレーブスレッドプール生成機能部１１から起動された場合、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤを取得する（６０６）。

スレーブスレッドプール振分機能部９は、振分管理テーブル１０において、取得したスレーブスレッドプールＩＤ対応の最終アクセス時刻を更新する（６０７）。

スレーブスレッドプール振分機能部９は、取得したスレーブスレッドプールＩＤに対応するスレーブスレッドプール３に対してタスクを振り分ける（６０８）。

この結果、上述した第１及び第２の実施の形態と同様に、スレーブスレッドプール３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される（図４中の４０８参照）。

この第３の実施の形態においては、スレーブスレッドプール使用状況確認機能部１２は、振分管理テーブル１０を周期的に参照し、スレーブスレッドプール振分機能部９によって更新される最終アクセス時刻に基づいて、各スレーブスレッドプール３の使用状況及び未使用状況を把握する。

また、スレーブスレッドプール削除機能部１３は、スレーブスレッドプール使用状況確認機能部１２で把握した未使用状況が予め設定された閾値を超過した場合には、対応のスレーブスレッドプール３を動的に削除する。

スレーブスレッドプール削除機能部１３は、常駐処理にて、図７に示すループ処理を周期実行している。スレーブスレッドプール削除機能部１３は、スレーブスレッドプール３の未使用時間（＝現在時刻−最終アクセス時刻）が予め設定された閾値を超過しているかどうか判定する（７０１）。

スレーブスレッドプール削除機能部１３は、未使用時間がこの閾値を超過している場合には、該当のスレーブスレッドプール３を削除した後（７０２）、振分管理テーブル１０から該当のスレーブスレッドプール３に関するスレーブスレッドプールＩＤを削除する（７０３）。

具体的には、例えば、現在時刻が２０１１／９／９ １４：００：００であり、かつ閾値が１２Ｈ（時間）である場合、図３に示す振分管理テーブル１０においては、スレーブスレッドプールＩＤ＝＃００３が削除対象であり、対応のスレーブスレッドプール（＃００３）３と、振分管理テーブル１０からの該当情報（スレーブスレッドプールＩＤ）とが削除される。

上述した第３の実施の形態においては、例えば、管理対象のネットワーク機器ＮＥが削除されて処理ＩＤが減少した場合、スレーブスレッドプール削除機能部１３は、スレーブスレッドプール３を動的に削除すると共に、削除したスレーブスレッドプール３に対応するスレーブスレッドプールＩＤを振分管理テーブル１０から削除することができる。

［第４の実施の形態］
図１に示す監視制御システムＯｐＳは、第４の実施の形態においては、スレーブスレッドプール振分機能部９と連携するスレーブスレッドプール使用状況確認機能部１２及びスレーブスレッドプール待機機能部１４を更に備える。

この第４の実施の形態においては、スレーブスレッドプール待機機能部１４は、スレーブスレッドプール使用状況確認機能部１２と協働し、予め定められた時間、未使用であったスレーブスレッドプール３を削除することなく、再利用するために対象スレーブスレッドプール３を待機させる。

スレーブスレードプール待機機能部１４は、待機状態となったスレーブスレッドプール３に対応するスレーブスレッドプールＩＤを振分管理テーブル１０から削除し、削除したスレーブスレッドプールＩＤをＲＡＭ上の待機スレーブスレッドプールリスト１５に登録する。

スレーブスレードプール待機機能部１４は、後に処理ＩＤが増加した場合、スレーブスレッドプール３を新たに生成することなく、待機状態のスレーブスレッドプール３を再利用する。

この第４の実施の形態においては、スレーブスレッドプール使用状況確認機能部１２は、振分管理テーブル１０を周期的に参照し、スレーブスレッドプール振分機能部９によって更新される最終アクセス時刻に基づいて、各スレーブスレッドプール３の使用状況及び未使用状況を把握する。

また、スレーブスレッドプール待機機能部１４は、スレーブスレッドプール使用状況確認機能部１２で把握した未使用状況が予め設定された閾値を超過した場合には、対応のスレーブスレッドプール３を削除することなく、待機スレーブスレッドプールリスト１５に登録する。

この待機スレーブスレッドプールリスト１５はスレーブスレッドプール３の待機リスト情報として作成され、初期リストのレングスは０である。このリスト１５には、待機対象としてのスレーブスレッドプール３が追加可能である。

スレーブスレッドプール待機機能部１４は、常駐処理にて、図８に示すループ処理を周
期実行している。スレーブスレッドプール待機機能部１４は、スレーブスレッドプール３の未使用時間（＝現在時刻−最終アクセス時刻）が予め設定された閾値を超過しているかどうか判定する（８０１）。

スレーブスレッドプール待機機能部１４は、未使用時間が閾値を超過している場合には、該当のスレーブスレッドプール３を待機スレーブスレッドプールリスト１５に登録する（８０２）。

そして、スレーブスレッドプール待機機能部１４は、振分管理テーブル１０から該当のスレーブスレッドプール３に関するスレーブスレッドプールＩＤを削除する（８０３）。

具体的には、例えば、現在時刻が２０１１／９／９ １４：００：００であり、かつ閾値が１２Ｈ（時間）である場合、図３に示す振分管理テーブル１０においては、スレーブスレッドプールＩＤ＝＃００３が削除対象であるので、振分管理テーブル１０から該当情報（スレーブスレッドプールＩＤ）が削除される。しかし、対応のスレーブスレッドプール（＃００３）３は待機登録される。

その後、処理ＩＤが増加した場合は、図９に示す処理により、待機状態のスレーブスレッドプール３が再利用される。

図９を併せ参照すると、スレーブスレッドプール振分機能部９は、タスク受付機能部６及び処理ＩＤ設定機能部７における処理（図４中の４０１，４０２，４０３参照）に続いて、マスタスレッドプール２のワークキュー及びワーカースレッドからタスクを逐次処理で取り出し、タスクに設定されている処理ＩＤを取得する（図９中の９０１，９０２）。

スレーブスレッドプール振分機能部９は、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤが存在するか判定する（９０３）。

スレーブスレッドプール振分機能部９は、スレーブスレッドプールＩＤが存在しないことを判定した場合、存在しないことをスレーブスレッドプール生成機能部１１に通知する。

この通知を受けたスレーブスレッドプール生成機能部１１は、待機スレーブスレッドプールリスト１５を参照して、待機スレーブスレッドプールに対応するスレーブスレッドプールＩＤが存在するか判定する（９０４）。

スレーブスレッドプール生成機能部１１は、待機スレーブスレッドプールが存在することを判定した場合、リスト１５から取得した待機スレーブスレッドプールＩＤを振分管理テーブル１０に登録した後、スレーブスレッドプール振分機能部９を起動する（９０５）。

なお、スレーブスレッドプール生成機能部１１は、処理９０４において待機スレーブスレッドプールが存在しないことを判定した場合、対応するスレーブスレッドプール３を生成すると共に、処理ＩＤ対応のスレーブスレッドプールＩＤを振分管理テーブル１０に登録した後、スレーブスレッドプール振分機能部９を起動することになる（９０６，９０７）。

スレーブスレッドプール振分機能部９は、処理９０３においてスレーブスレッドプールＩＤが存在することを判定した場合、または処理９０５，９０７に続いてスレーブスレッ
ドプール生成機能部１１から起動された場合、取得した処理ＩＤに基づいて、振分管理テーブル１０を検索し、この処理ＩＤに対応するスレーブスレッドプールＩＤを取得する（９０８）。

スレーブスレッドプール振分機能部９は、振分管理テーブル１０において、取得したスレーブスレッドプールＩＤ対応の最終アクセス時刻を更新する（９０９）。

スレーブスレッドプール振分機能部９は、取得したスレーブスレッドプールＩＤに対応するスレーブスレッドプール３に対してタスクを振り分ける（９１０）。

この結果、上述した第１、第２及び第３の実施の形態と同様に、スレーブスレッドプール３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される（図４中の４０８参照）。

上述した第４の実施の形態においては、例えば、管理対象のネットワーク機器ＮＥが追加されて処理ＩＤが増加した場合、待機状態のスレーブスレッドプール３を再利用することにより、スレーブスレッドプール３の削除処理及び新規生成処理が抑制されるので、ＣＰＵリソースの効率的使用が可能になる。

［第５の実施の形態］
図１に示す監視制御システムＯｐＳは、第５の実施の形態においては、各ネットワーク機器ＮＥが属するグループ毎に付与（設定）されたグループ識別子（グループＩＤ）を処理ＩＤとして含むＮＥ構成情報テーブル８を管理する。

ここで、各ネットワーク機器ＮＥが属するグループについては、局情報（例えば、新宿局、横浜局）及びネットワーク形態情報（例えば、スター型やリング型などのトポロジ）などの少なくとも１つに基づいて、オペレータ端末ＯＰＴのオペレータが予め決定してＮＥ構成情報テーブル８に設定可能である。

タスク受付機能部６に付随する処理ＩＤ設定機能部７は、タスク受付機能部６で受け付けられたタスクに含まれている装置識別子としてのＩＰアドレスまたはネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、ＮＥ構成情報テーブル８を検索し、オペレータ端末ＯＰＴから予め指定された処理ＩＤとしてのグループＩＤを取得する。そして、処理ＩＤ設定機能部７は、取得した処理ＩＤ（グループＩＤ）をタスクに設定した後に、このタスクをマスタスレッドプール２に処理依頼として登録する。

つまり、図１０を併せ参照すると、タスク受付機能部６は、ＧＵＩ要求受信機能部４及びＮＥ通知受信機能部５からのタスク処理依頼を受け付ける（図４中の４０１参照）。

処理ＩＤ設定機能部７は、オペレータ端末ＯＰＴからタスク受付機能部６に対して予め指定されている処理ＩＤがグループＩＤか判定する（図１０中の１００１）。

タスクに実行順序制御を行うための処理ＩＤを設定する処理ＩＤ設定機能部７は、処理ＩＤがグループＩＤであると判定した場合、タスク受付機能部６で受け付けられたタスクに含まれている装置識別子としてのＩＰアドレスまたはネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、ＮＥ構成情報テーブル８から、処理ＩＤとしてグループＩＤを取得する（１００２）。

そして、処理ＩＤ設定機能部７は、取得した処理ＩＤ（グループＩＤ）をタスクに設定した後に、このタスクをマスタスレッドプール２に処理依頼として登録する（１００３）
。

なお、処理ＩＤ設定機能部７は、処理ＩＤがグループＩＤではないと判定した場合、タスク受付機能部６で受け付けられたタスクに含まれている装置識別子としてのＩＰアドレスまたはネットワーク機器ＩＤ（ＮＥ−ＩＤ）に基づいて、ＮＥ構成情報テーブル８から、処理ＩＤとしてネットワーク機器ＩＤ（ＮＥ−ＩＤ）を取得する（１００４）。

そして、処理ＩＤ設定機能部７は、取得した処理ＩＤ（ネットワーク機器ＩＤ）をタスクに設定した後に、このタスクをマスタスレッドプール２に処理依頼として登録する（１００５）。

上記処理１００３，１００５の後、スレーブスレッドプール振分機能部９が、図４中の４０４〜４０７と同様な処理を実施することにより、各スレーブスレッドプール３においては、ワークキューからのタスクがワーカースレッドを割り当てられて逐次実行処理される（図４中の４０８参照）。

ただし、この第５の実施の形態においては、スレーブスレッドプール振分機能部９によって検索される振分管理テーブル１０の処理ＩＤには、ＮＥ−ＩＤ＝＃Ｎ０１，＃Ｎ０２，＃Ｎ０３，・・・＃ＮＮに代替して、グループＩＤ＝＃Ｇ０１，＃Ｇ０２，＃Ｇ０３，・・・＃Ｇ０５が予め格納される。

各ネットワーク機器ＮＥ対応のネットワーク機器ＩＤ（ＮＥ−ＩＤ）をタスクの処理ＩＤとした場合、管理対象のネットワーク機器ＮＥの数に比例して、スレーブスレッドプール３の数が増加する。この結果、ＲＡＭのメモリリソースを大量に消費する可能性がある場合には、タスクの処理ＩＤとして、グループＩＤを設定することが望ましい。

このように、グループＩＤ単位にスレーブスレッドプール３を割当てた場合には、グループＩＤ単位にタスク実行の順序性を保証することができ、かつメモリリソースを必要最小限に抑えることができる。

［変形例］
上述した各実施の形態における処理はコンピュータで実行可能なプログラムとして提供され、ＣＤ−ＲＯＭやフレキシブルディスクなどの非一時的コンピュータ可読記憶媒体、更には通信回線を経て提供可能である。

また、上述した各実施の形態における各処理はその任意の複数または全てを選択し組合せて実施することもできる。

［その他］
上述した各実施の形態及び変形例に関し、更に以下の付記を開示する。

（付記１）
複数のネットワーク機器を集中管理する監視制御システムであって；
システム内の全てのタスクを順次格納する単一のマスタスレッドプールと；
タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと；
前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、
前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、
前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、
前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にするように構成されるプロセッサと；
を備える監視制御システム。

（付記２）
前記装置識別子は、ＩＰアドレス及び前記ネットワーク機器毎に設定された個別識別子を含み、
前記処理識別子は、前記個別識別子及び前記ネットワーク機器が属するグループ毎に設定されたグループ識別子を含む
付記１記載の監視制御システム。

（付記３）
前記単一のマスタスレッドプール及び前記複数のスレーブスレッドプールのそれぞれは、１つのワークキュー及び１つのワーカースレッドを含み、
各スレーブスレッドプールのワーカースレッドは、最大１スレッドであり、ワークキューにＦＩＦＯ形式で蓄積されている振り分けられたタスクを逐次に実行可能にする
付記１記載の監視制御システム。

（付記４）
前記処理識別子と、スレーブスレッドプールの識別子とを前記スレーブスレッドプールの識別子毎に格納する振分管理テーブルを更に備え、
前記プロセッサは、前記マスタスレッドプールから取り出したタスク中の前記処理識別子に対応する前記スレーブスレッドプールの識別子が前記振分管理テーブルに存在しないとき、前記スレーブスレッドプールを動的に新規生成し、生成したスレーブスレッドプールにタスクを振り分ける
付記１記載の監視制御システム。

（付記５）
前記処理識別子と、スレーブスレッドプールの識別子と、テーブルへの最終アクセス時刻とを前記スレーブスレッドプールの識別子毎に格納する振分管理テーブルを更に備え、
前記プロセッサは、前記振分管理テーブルにおいて、前記マスタスレッドプールから取り出したタスク中の前記処理識別子に対応する前記スレーブスレッドプールの識別子を取得したとき、このスレーブスレッドプールの識別子対応の最終アクセス時刻を更新し、
前記プロセッサは、更に、前記振分管理テーブルを周期的に参照し、更新した最終アクセス時刻に基づいて、各スレーブスレッドプールの未使用時間を把握し、把握した未使用時間が予め設定された閾値を超過したとき、対応のスレーブスレッドプールを動的に削除する
付記１記載の監視制御システム。

（付記６）
前記処理識別子と、スレーブスレッドプールの識別子と、テーブルへの最終アクセス時刻とを前記スレーブスレッドプールの識別子毎に格納する振分管理テーブルを更に備え、
前記プロセッサは、前記振分管理テーブルにおいて、前記マスタスレッドプールから取り出したタスク中の前記処理識別子に対応する前記スレーブスレッドプールの識別子を取得したとき、このスレーブスレッドプールの識別子対応の最終アクセス時刻を更新し、
前記プロセッサは、更に、前記振分管理テーブルを周期的に参照し、更新した最終アクセス時刻に基づいて、各スレーブスレッドプールの未使用時間を把握し、把握した未使用時間が予め設定された閾値を超過したとき、対応のスレーブスレッドプールを削除することなく、再利用のために待機スレーブスレッドプールとする
付記１記載の監視制御システム。

（付記７）
複数のネットワーク機器を集中管理する監視制御システムにより実行されるプログラムであって、
前記監視制御システムは、
システム内の全てのタスクを順次格納する単一のマスタスレッドプールと、
タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと、
プロセッサとを備え、
前記プロセッサに、
前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、
前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、
前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、
前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にする、
処理を実行させるプログラム。

ＯｐＳ 監視制御システム
ＯＰＴ オペレータ端末
ＮＥ ネットワーク機器
２ マスタスレッドプール
３ スレーブスレッドプール
４ ＧＵＩ要求受信機能部
５ ＮＥ通知受信機能部
６ タスク受付機能部
７ 処理ＩＤ設定機能部
８ ＮＥ構成情報テーブル
９ スレーブスレッドプール振分機能部
１０ 振分管理テーブル
１１ スレーブスレッドプール生成機能部
１２ スレーブスレッドプール使用状況確認機能部
１３ スレーブスレッドプール削除機能部
１４ スレーブスレッドプール待機機能部
１５ 待機スレーブスレッドプールリスト

Claims (4)

1. 複数のネットワーク機器を集中管理する監視制御システムであって；
   システム内の全てのタスクを順次格納する単一のマスタスレッドプールと；
   タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと；
   前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、
   前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、
   前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、
   前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にするように構成されるプロセッサと；
   を備える監視制御システム。
2. 前記装置識別子は、ＩＰアドレス及び前記ネットワーク機器毎に設定された個別識別子を含み、
   前記処理識別子は、前記個別識別子及び前記ネットワーク機器が属するグループ毎に設定されたグループ識別子を含む
   請求項１記載の監視制御システム。
3. 前記単一のマスタスレッドプール及び前記複数のスレーブスレッドプールのそれぞれは、１つのワークキュー及び１つのワーカースレッドを含み、
   各スレーブスレッドプールのワーカースレッドは、最大１スレッドであり、ワークキューにＦＩＦＯ形式で蓄積されている振り分けられたタスクを逐次に実行可能にする
   請求項１記載の監視制御システム。
4. 複数のネットワーク機器を集中管理する監視制御システムにより実行されるプログラムであって、
   前記監視制御システムは、
   システム内の全てのタスクを順次格納する単一のマスタスレッドプールと、
   タスクの実行順序制御が必要な単位に構成される複数のスレーブスレッドプールと、
   プロセッサとを備え、
   前記プロセッサに、
   前記複数のネットワーク機器のそれぞれを一意に識別可能な装置識別子を含む受付タスクに対して実行順序制御が必要な単位に処理識別子を設定し、
   前記処理識別子を設定したタスクを前記マスタスレッドプールに登録し、
   前記マスタスレッドプールから取り出したタスク中の前記処理識別子に基づいて、予め対応付けされている前記複数のスレーブスレッドプールのいずれかを特定し、
   前記特定したスレーブスレッドプールにタスクを振り分けて、タスクをマルチスレッドで実行可能にする、
   処理を実行させるプログラム。

Images