図1は、実施形態に係るネットワークシステムの一例を示すシステム図である。このシステムは、監視システム100Aと、作業管理システム100Zとを備える。監視システム100Aおよび作業管理システム100Zは、有線または無線のネットワーク1000で接続され、相互に通信が可能である。
監視システム100Aは、監視ネットワークANetを介して複数の装置A1〜Anに接続され、これらの装置A1〜Anを配下としてその監視および制御を行う。監視/制御に係わるプロトコルとしてはSNMP(Simple Network Management Protocol)が代表的である。
また、ディスプレイを有し、表示装置としての機能を備えるクライアント端末T1〜Tmが、監視ネットワークANet経由で監視システム100Aにアクセスできる。クライアント端末T1〜Tmは、装置A1〜Anの警報状態等をリモートから確認することができる。
装置A1〜Anは、例えば光中継システムにおける光伝送装置(親機)、光伝送装置(子機)、あるいは電源装置などの各種のデバイスであり、局として理解される。実施形態では、レピータシステムにおける局を想定する。
作業管理システム100Zは、装置交換やユニット交換、装置点検、再起動等の作業を管理するために設けられる。また、ディスプレイを有し表示装置としての機能を備えるクライアント端末Z1〜Zpは、作業管理ネットワークZNetを介して作業管理システム100Zにアクセスすることが可能である。
以下の説明で、装置A1〜Anを区別する必要が無ければ、装置Aと表記する。また、クライアント端末T1〜Tmを区別する必要が無ければ、クライアント端末Tと表記し、クライアント端末Z1〜Zpを区別する必要が無ければ、クライアント端末Zと表記する。
図2は、実施形態に係る監視システムおよび作業管理システムの一例を示す機能ブロック図である。図2において、装置Aは、各種のデバイス1と、デバイス1に生じた警報を検知する警報検知部2と、検知された警報を監視システム100Aに通知する警報送信部3とを備える。
装置A1の警報送信部3から発報された警報(例えばSNMP-Trapメッセージ)は、監視システム100Aの警報受信部11で受信される。警報は、例えば[局ID]、[送信時刻]、[警報ID]等の情報を含む。受信された警報に含まれる各種の情報は、警報情報データベース(DB)12に追加登録され、蓄積される。
図3に、警報情報DB12に登録される情報の一例を示す。警報情報は、警報情報DB12において、例えば[管理番号]、[局ID]、[イベント発生日時]、[イベントクリア日時]、[警報ID]、[警報状態]、[警報名称]、[コメント]、および、[表示種別]を含むデータ構造で管理されることができる。なお[表示種別]は、クライアント端末TAにおけるグレーアウト、非表示などを指定するための項目である。
監視システム100A(図2)は、さらに、表示装置としてのクライアント端末Tに接続可能な画面インタフェース(IF)17、局情報データベース(DB)16、局情報登録部15、作業管理システム連携部13、マスク処理部14、および、マスク情報データベース(DB)18を備える。このうち画面IF17は、表示制御部としての機能を備え、取得した警報情報をクライアント端末Tの画面上に、例えばリスト表示する。
局情報DB16には、例えばクライアント端末Tからの要求に従い、局情報登録部15により、配下の局(装置A)の局情報が予め登録される。局情報は、例えば装置A1〜Anを識別するためのID(IDentification)、IP(Internet Protocol)アドレス、基板情報、設定状態などの情報を含む。
図4に、局情報DB16に登録される情報の一例を示す。局情報は、例えば[管理番号]、[グループ]、[局名]、[局ID]、[装置区分]、および[装置IPアドレス]を含むデータ構造で管理されることができる。
送信部としての作業管理システム連携部13(図2)は、装置Aからの警報が警報受信部11において受信されると、その警報に応じた作業依頼メッセージを作業管理システム100Zに送信する。この作業依頼メッセージは、作業管理システム100Zの監視システム連携部21(メッセージ受信部として機能する)で受信される。
作業依頼メッセージが受信されると、登録処理部としての画面インタフェース(IF)23は、表示装置としてのクライアント端末Zにプロンプトウインドウを表示し、作業依頼メッセージに基づく作業情報の登録をユーザに促す。ユーザにより登録された作業情報等は作業管理データベース(DB)22に記録される。
図5は、作業管理DB22に登録される情報の一例を示す図である。作業情報は、作業管理DB22において、例えば[管理番号]、[グループ]、[局名]、[局ID]、[作業時間(開始)]、[作業時間(終了)]、[工事内容]、および、[担当者]を含むデータ構造で管理されることができる。例えば、[作業時間(開始)]は、[工事内容]で示される作業の開始時刻であり、その工事は[作業時間(終了)]の時刻において終了する予定であることがわかる。
クライアント端末Z(図2)を用いて登録された作業情報は、監視システム連携部21を経由して、監視システム100Aのマスク処理部14に通知される。マスク処理部14は、クライアント端末Zにおいて登録された作業情報に基づいて、マスク属性を警報情報ごとに選択的に設定する。設定された情報(マスク情報)はマスク情報DB18に登録される。
図6は、マスク情報DB18に登録される情報の一例を示す図である。マスク情報は、マスク情報DB18において、例えば[管理番号]、[マスク種別]、[マスク期間(開始)]、[マスク期間(終了)]、[ユーザID]、および、[コメント]を含むデータ構造で管理されることができる。個々の警報ごとに、このような情報を含む属性を設定することが可能である。
例えば[工事内容]として基板の交換が指定されたならば、[基板取り外し]に係わるアラートが対象の装置から発報されることになる。このことは、当然、予測できる事項であるから、改めて対処する必要性は低い。そこで、その工事の期間(作業時間の開始から終了まで)を指定してマスク設定することで、ユーザ(システム管理者など)にとっての便宜を図ることが可能になる。
表示制御部としての画面IF17(図2)は、クライアント端末Tに表示される警報を、図6のマスク情報DB18に記録されたマスク情報に従ってマスクする。つまり、マスク属性を設定された警報の表示色を変更したり、網掛け表示したりすることで、マスク属性の無い警報とは区別できるようにする。あるいは、マスク属性を設定された警報を表示しない、といった態様もありうる。
次に、上記構成における作用を説明する。以下では、処理の主体として装置A1、クライアント端末T1、およびクライアント端末Z1に代表させるが、他の装置およびクライアント端末でも同様である。
図7は、実施形態に係わるメッセージの授受の一例を示すシーケンス図である。図7において、装置A1に警報事象が発生すると(ステップS1)、そのことが自らの警報検知部2により検知され、事象に応じた警報が発報される(ステップS2)。警報は一つとは限らず、複数の警報がほぼ同時に発生することもある。
発報された警報は、監視システム100Aにより受信され(ステップS3)、警報情報が警報情報DB12に記録され、蓄積される。また、警報情報DB12から参照された警報情報が、例えば図8のように、クライアント端末T1のディスプレイにリストアップして(帳票形式で)表示される(ステップS4)。
図8のGUI(Graphical User Interface)ウインドウの[発生時刻]カラムを参照すると、2019/1/2 15:00に、2つの警報が生じている。[システム名(ベンダ)]カラムを参照すると、この警報はベンダ(X社)の装置Aであることがわかる。
図8のウインドウには、ユーザが業者などへの作業を依頼するための[作業依頼]ボタンが設けられている。作業を依頼したいユーザは、工事を依頼したい警報を選択し、[作業依頼]ボタンをクリックする(ステップS5でYes)。そうすると、図9のようなウインドウがオープンする。
図9のウインドウは、図8のウインドウで選択された警報の詳細な情報に加えて、依頼したい作業(MU交換など)を記載する欄、あるいは保守会社を指定するためのドロップダウンリストなどを含む。所定事項を記入して[登録]ボタンがクリックされると、監視システム100Aから作業管理システム100Zに宛てて作業依頼メッセージが送信される(ステップS6)。作業依頼メッセージは、対象局、警報情報、作業内容などの情報を含む。
作業管理システム100Zで作業依頼メッセージが受信されると(ステップS7)、作業管理DB22に作業情報が記録され、蓄積される。そして、例えば保守業者のクライアント端末Z1のディスプレイに、図10のようなウインドウが表示される。
図10のウインドウに、依頼された作業の一覧がリスト表示される(ステップS8)。作業依頼メッセージが受信されるたびに、依頼された作業の情報が例えば一番下の行に追記される。[ステータス]に[新規]と示された行を選択し、[新規登録]ボタンがクリックされると、図11のウインドウが表示される。図10、図11のウインドウにより、作業依頼メッセージに基づく作業情報の登録がユーザに促される。
図11は、作業情報の登録をユーザに促すプロンプト画面の一例を示す図である。このウインドウには、対象となる警報の詳細な情報が表示されており、作業を行う業者は、クライアント端末Z1のディスプレイから作業依頼状況を確認することができる。業者は、[編集]ボタンをクリックして、図12のように、作業に関する詳細情報を入力する(ステップS9)。詳細情報のうち重要なものは、例えば作業時間であり、図12を参照すると、2019/1/4 7:00〜2019/1/4 10:00が指定されていることがわかる。図12の[登録]ボタンがクリックされると、作業詳細が受け付けられ(ステップS10)、入力された情報が作業管理DB22に登録される。さらに、監視システム連携部21を介して、監視システム100Aに作業情報が送信される。これを取得した監視システム100Aは、マスク処理部14により、作業対象の局情報や作業時間などに基づくマスク情報をマスク情報DB18登録する(ステップS11)。登録が完了すると、クライアント端末Z1のディスプレイの表示内容は、図10に示される内容から図13に示される内容のようになり、対象の警報の[ステータス]は[登録済み]となる。
図14は、マスク設定された警報が発生した場合の処理手順の一例を示すシーケンス図である。図14において、装置A1に警報事象が発生すると(ステップS21)、事象に応じた警報が発報される(ステップS22)。発報された警報は、監視システム100Aにより受信され(ステップS23)、クライアント端末T1のディスプレイにリストアップして(帳票形式で)表示される(ステップS24)。ただしこのとき、対象の警報はマスク設定されているので、図15に示されるように、クライアント端末T1のディスプレイ上でマスク処理される。図15の斜線のハッチングは、当該警報が例えば色分け、ぼかし、網掛けなどの態様でマスク表示されていることを示す。
以上説明したようにこの実施形態では、監視システム100Aと作業管理システム100Zとを連携させ、監視システム100Aで受信した警報に基づいて作業管理システム100Zに作業依頼メッセージを送信するようにした。このようにすることで、警報の発生からメンテナンス作業に至るまでの一連の手順を効率化することが可能になる。また、実施形態によれば、登録された作業情報に応じて、クライアント端末Aに表示される警報情報が自動的にマスクされる。これにより、不要な警報を監視者が認識することを防止でき、ひいては、監視業務の負荷を軽減することができる。これらのことから、作業効率を向上させ得るネットワークシステム、監視システム、作業管理システム、および作業管理方法を提供することが可能となる。
なお、この発明は上記実施の形態に限定されるものではない。例えば図9のウインドウで、複数の警報を選択できるようにし、1回のクリックで一括して作業依頼メッセージを送信できるようにしてもよい。これには、例えば複数タブを備えるウインドウで、タブの指定により一つの警報を選択するなどのユーザインタフェースが考えられる。つまり作業依頼メッセージに、複数の警報に係わる情報を含めるようにしてもよい。
さらに、実施形態に係わるネットワークシステムは、レピータシステムに対する監視/制御に留まらず、システムの監視と作業の管理とを分業する、あらゆるシステムにも適用可能である。
本発明の実施形態を説明したが、この実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。