図面 (/)

技術 通信確認装置、通信確認方法及びプログラム

出願人 富士通株式会社
発明者 池田知弘脇本浩一田中博幸竹内恵裕木瀬幸雄夏見徹
出願日 2010年4月21日 (9年10ヶ月経過) 出願番号 2010-098106
公開日 2011年11月10日 (8年4ヶ月経過) 公開番号 2011-227770
状態 特許登録済
技術分野 計算機・データ通信 デバッグ/監視
主要キーワード 解析状況 状態確認コマンド インターバル情報 閉塞処理 保守手順 警戒レベル 保守画面 エラー発生時刻
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年11月10日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

被監視装置に発生したエラー重要度が被監視装置の通信状態によって決まる場合に、その通信状態を精度よく確認できる通信確認装置通信確認方法及びプログラムを提供する。

解決手段

監視対象装置10が接続された上位サーバ装置20と接続してあり、上位サーバ装置20へ接続要求を送信し、接続要求を受信した上位サーバ装置20が監視対象装置10に送信させた応答を受信することで、監視対象装置10の通信状態を確認する情報処理装置1において、監視対象装置10にエラーが発生した場合、接続要求を上位サーバ装置20へ第1及び第2送信に分けて二回送信し、第2送信で送信した接続要求に対する応答を受信したか否かにより、監視対象装置10の通信状態を確認する。

概要

背景

ネットワーク機器障害が発生した場合、早急に障害を復旧するための保守システムがある。例えば、特許文献1は、ネットワーク機器の障害発生を自動的にサービスセンタで検知し、障害に応じた保守手順を自動的に編集して、保守手順を映像で示す保守画面を、ネットワーク機器のユーザに送信する保守システムが開示されている。特許文献1に記載の保守システムにより、ネットワーク機器のユーザは、コンピュータに詳しくない場合であっても、保守画面を見ながらエラー復旧作業を簡単に行うことができる。

概要

被監視装置に発生したエラーの重要度が被監視装置の通信状態によって決まる場合に、その通信状態を精度よく確認できる通信確認装置通信確認方法及びプログラムを提供する。監視対象装置10が接続された上位サーバ装置20と接続してあり、上位サーバ装置20へ接続要求を送信し、接続要求を受信した上位サーバ装置20が監視対象装置10に送信させた応答を受信することで、監視対象装置10の通信状態を確認する情報処理装置1において、監視対象装置10にエラーが発生した場合、接続要求を上位サーバ装置20へ第1及び第2送信に分けて二回送信し、第2送信で送信した接続要求に対する応答を受信したか否かにより、監視対象装置10の通信状態を確認する。

目的

本発明はかかる事情に鑑みてなされたものであり、その目的とするところは、被監視装置に発生したエラーの重要度が被監視装置の通信状態によって決まる場合に、その通信状態を精度よく確認できる通信確認装置、通信確認方法及びプログラムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信することで、前記被監視装置の通信状態を確認する通信確認装置において、前記被監視装置にエラーが発生したことを検知する検知部と、前記被監視装置、及び該被監視装置が接続される外部装置の接続先を記憶する通信先記憶部と、該検知部がエラーを検知した場合、前記通信先記憶部に記憶した接続先に基づいて接続要求信号を前記外部装置へ二回送信する送信部と、該送信部が二回目に送信した接続要求信号に対する応答信号を受信したか否かを判定する判定部とを備える通信確認装置。

請求項2

前記外部装置に接続されている被監視装置の数を記憶する数記憶部と、前記検知部がエラーを検知した場合、前記外部装置に接続されている被監視装置の数を、前記数記憶部の記憶内容から特定する特定部とをさらに備え、前記送信部は、前記特定部が特定した数を、一回目及び二回目それぞれの接続要求信号の送信回数として、接続要求信号を送信するようにしてある請求項1に記載の通信確認装置。

請求項3

前記送信部は、一回目の接続要求信号の送信終了後、所定時間経過後に、二回目の接続要求信号を送信するようにしてある請求項1又は2に記載の通信確認装置。

請求項4

複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信することで、前記被監視装置の通信状態を確認する通信確認方法において、前記被監視装置にエラーが発生したことを検知し、前記被監視装置、及び該被監視装置が接続される外部装置の接続先を記憶し、エラーを検知した場合、記憶した接続先に基づいて前記外部装置へ接続要求信号を二回送信し、二回目に送信した接続要求信号に対する応答信号を受信したか否かを判定する通信確認方法。

請求項5

複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信するコンピュータで実行されるプログラムにおいて、コンピュータを、前記被監視装置にエラーが発生したことを検知する検知部、該検知部がエラーを検知した場合、記憶された、前記被監視装置、及び該被監視装置が接続される外部装置の接続先に基づいて、接続要求信号を前記外部装置へ二回送信させる送信部、及び、該送信部が二回目に送信させた接続要求信号に対する応答信号を受信したか否かを判定する判定部として機能させるプログラム。

技術分野

0001

本発明は、複数の被監視装置が接続された外部装置と接続してあり、外部装置へ接続要求信号を送信し、接続要求信号を受信した外部装置が被監視装置に送信させた応答信号を受信することで、被監視装置の通信状態を確認する通信確認装置通信確認方法及びプログラムに関する。

背景技術

0002

ネットワーク機器障害が発生した場合、早急に障害を復旧するための保守システムがある。例えば、特許文献1は、ネットワーク機器の障害発生を自動的にサービスセンタで検知し、障害に応じた保守手順を自動的に編集して、保守手順を映像で示す保守画面を、ネットワーク機器のユーザに送信する保守システムが開示されている。特許文献1に記載の保守システムにより、ネットワーク機器のユーザは、コンピュータに詳しくない場合であっても、保守画面を見ながらエラー復旧作業を簡単に行うことができる。

先行技術

0003

特開2004−086719号公報

発明が解決しようとする課題

0004

しかしながら、特許文献1に記載の保守システムでは、障害の深刻度に関係なく、障害がユーザに通知されるため、発生した障害を早急に解決する必要があるかどうかを、ユーザには判断できない場合がある。

0005

本発明はかかる事情に鑑みてなされたものであり、その目的とするところは、被監視装置に発生したエラーの重要度が被監視装置の通信状態によって決まる場合に、その通信状態を精度よく確認できる通信確認装置、通信確認方法及びプログラムを提供することにある。

課題を解決するための手段

0006

本願に開示する通信確認装置は、複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信することで、前記被監視装置の通信状態を確認する通信確認装置において、前記被監視装置にエラーが発生したことを検知する検知部と、前記被監視装置、及び該被監視装置が接続される外部装置の接続先を記憶する通信先記憶部と、該検知部がエラーを検知した場合、前記通信先記憶部に記憶した接続先に基づいて接続要求信号を前記外部装置へ二回送信する送信部と、該送信部が二回目に送信した接続要求信号に対する応答信号を受信したか否かを判定する判定部とを備える。

発明の効果

0007

本願に開示する通信確認装置の一観点によれば、エラーが発生した被監視装置の通信状態を、より精度よく確認することができる。また、通信異常が被監視装置の運用に問題を引き起こす場合、確実に通信状態を把握することで、専門の担当者復旧依頼を早急に通知することができ、短時間でのエラーの復旧が可能となる。

図面の簡単な説明

0008

実施の形態に係る保守システム全体の構成を示す模式図である。
保守システムの情報処理装置が有する構成を示すブロック図である。
情報処理装置で実現される機能を示すブロック図である。
プロトコルDBを模式的に示す図である。
通信先DBを模式的に示す図である。
設備情報DBを模式的に示す図である。
SIPを利用する場合に、シナリオ生成部が生成するシナリオの一例を示す図である。
HTTPを利用する場合に、シナリオ生成部が生成するシナリオの一例を示す図である。
SMTPを利用する場合に、シナリオ生成部が生成するシナリオの一例を示す図である。
管理サーバ装置で実現される機能を示すブロック図である。
重要度を決定する方法を説明するための模式図である。
携帯電話機エラー情報を確認する場合の模式図である。
監視装置の動作を示すフローチャートである。
監視装置の動作を示すフローチャートである。
情報処理装置の動作を示すフローチャートである。
情報処理装置の動作を示すフローチャートである。
上位サーバ装置の動作を示すフローチャートである。
管理サーバ装置の動作を示すフローチャートである。
管理サーバ装置の動作を示すフローチャートである。

実施例

0009

以下に、本願に開示する通信確認装置、通信確認方法及びプログラムについて、好適な実施の形態を、図面を参照しつつ詳述する。以下に説明する実施の形態では、本願に開示する通信確認装置を備える保守システムについて説明する。

0010

本実施の形態に係る保守システムは、呼制御サーバ装置WEBサーバ装置又はSimple Mail Transfer Protocol(SMTP)サーバ装置等のネットワーク装置に発生するエラーを監視し、発生したエラーの重要度に応じて、保守担当者へエラーを通知するシステムである。保守担当者への通知は、保守担当者が所有する携帯電話機又はパーソナルコンピュータ(以下、パソコンという)等へメールにて行われる。以下の説明では、監視するネットワーク装置を、監視対象装置という。

0011

図1は、実施の形態に係る保守システム全体の構成を示す模式図である。保守システムは、監視対象装置(被監視装置)10a,10b,10cを監視するための情報処理装置(通信確認装置)1、上位サーバ装置(外部装置)20、監視装置21及び管理サーバ装置22等を備えている。監視対象装置10a,10b,10cは、同じ構成及び機能を有し、かつ、同じ動作を行う装置であって、同じグループとして上位サーバ装置20に接続されている。以下の説明では、監視対象装置10a,10b,10cをまとめて監視対象装置10という。

0012

上位サーバ装置20は、例えば、Session Initiation Protocol(SIP)サーバ装置、Hypertext Transfer Protocol(HTTP)を利用するWEBサーバ装置、又はSMTPサーバ装置等である。上位サーバ装置20は、後述の情報処理装置1から接続要求を受信した場合、自身に接続されている監視対象装置10と情報処理装置1とを接続する。例えば、上位サーバ装置20がSIPサーバ装置の場合、上位サーバ装置20は、SIPを利用して、情報処理装置1及び監視対象装置10が有する電話機(図示せず)を、電話番号をもとに接続し、又は切断する呼制御を行う。また、WEBサーバ装置の場合、上位サーバ装置20は、HTTPを利用して、情報処理装置1及び監視対象装置10間で、画像等のコンテンツ送受を行う。SMTPサーバ装置の場合、上位サーバ装置20は、SMTPを利用して、情報処理装置1及び監視対象装置10間でメールの送受を行う。なお、上位サーバ装置20は、複数あってもよく、複数の場合には、SIPサーバ装置及びWEBサーバ装置等が混在していてもよい。

0013

本実施の形態では、上位サーバ装置20は、ラウンドロビン方式に従って、接続する監視対象装置10を選択し、通信を行う。例えば、上位サーバ装置20は、最初に接続要求を受信したとき、監視対象装置10aとの通信を行い、次に接続要求を受信したときには、監視対象装置10bとの通信を行う。続いて、接続要求を受信したときには、上位サーバ装置20は、監視対象装置10cとの通信を行う。また、上位サーバ装置20は、ラウンドロビン方式に従って監視対象装置10と通信した場合、監視対象装置10の一つが故障と判断したとき、その監視対象装置10に対して閉塞処理を実行する。閉塞処理を実行した場合、上位サーバ装置20は、接続要求を受信しても、閉塞処理を実行した監視対象装置10に対しては、通信をしなくなる。

0014

監視対象装置10は、Local Area Network(LAN)又はWide Area Network(WAN)等の通信網を介して監視装置21と接続している。監視装置21は、監視対象装置10にエラーが発生したことを検知する装置である。なお、図中は、監視対象装置10aのみが監視装置21と接続しているが、監視対象装置10b,10cも監視装置21と接続している。監視対象装置10は、監視装置21に対して、Simple Network Management Protocol(SNMPトラップを送信する。監視装置21は、監視対象装置10から送信されたSNMPトラップに基づいて、監視対象装置10にエラーが発生したことを検知する。以下では、監視対象装置10aにエラーが発生し、監視対象装置10b,10cは正常に動作するものとして説明する。

0015

監視装置21は、検知したエラーに対応するエラー番号を特定し、エラー番号を監視対象装置10aへ通知する。エラー番号が通知された監視対象装置10aは、エラー番号をもとに、発生したエラーの解析に必要なログを抽出して、エラーログとして監視装置21へ送信する。エラーログには、監視対象装置10aが状態確認コマンド投入することで得られる自身の動作状態を含む。

0016

上位サーバ装置20及び監視装置21は、通信網を介して情報処理装置1と接続している。情報処理装置1は、監視対象装置10aに発生したエラーの重要度を決定するために、監視対象装置10aの通信状態を確認するための装置である。エラーの重要度は、後述の管理サーバ装置22で決定され、監視対象装置10aを含む他の監視対象装置10b,10cとの通信ができない場合には、高く決定される。情報処理装置1は、監視装置21から、エラーが発生した監視対象装置10aを特定する情報として、Internet Protocol(IP)アドレスを受信する。情報処理装置1は、そのIPアドレスから監視対象装置10a、及び、監視対象装置10aの運用に必要なプロトコルを特定する。情報処理装置1は、特定したプロトコルにより、特定した監視対象装置10aの通信状態の確認を上位サーバ装置20を介して行う。より具体的には、情報処理装置1は、監視対象装置10aを含めて、上位サーバ装置20に接続している監視対象装置10b,10cの通信状態を確認する。通信状態は、上位サーバ装置20に送信した接続要求に対して、監視対象装置10から応答を受信したか否かにより確認される。そして、情報処理装置1は、確認結果を監視装置21へ送信する。

0017

監視装置21は、通信網を介して管理サーバ装置22と接続している。管理サーバ装置22は、発生したエラーを管理し、エラーの重要度を決定する装置である。管理サーバ装置22は、上述したエラー番号、通信状態の確認結果、及びエラーログを監視装置21から受信する。管理サーバ装置22は、受信したエラー番号、及びエラーログをもとに、エラー名、及びエラー発生時刻等のエラー情報をWEB表示可能にする。管理サーバ装置22は、SMTPサーバ装置23と接続しており、WEB表示可能にしたエラー情報へのリンクを含めたメールを、保守担当者が所有する携帯電話機100又はパソコン101,102等へ送信する。これにより、保守担当者は、携帯電話機100又はパソコン101,102等から管理サーバ装置22へアクセスすることで、エラー情報を確認することが可能となる。なお、本実施の形態では、保守担当者は、システムを運用する運用者、及び、システムに発生したエラーを解析する解析者を含む。そして、携帯電話機100及びパソコン101は解析者が所有し、パソコン102は運用者が所有するものとする。

0018

管理サーバ装置22は、受信したエラー番号、及び通信状態の確認結果から、監視対象装置10aに発生したエラーの重要度を決定し、重要度に応じて、メール送信先を決定する。例えば、エラーが発生した監視対象装置10aの通信状態が異常の場合には、管理サーバ装置22は、エラーの重要度を高く決定し、メール送信先を携帯電話機100に決定する。携帯電話機100は、解析者が常時携帯している可能性が高いため、メールを携帯電話機100へ送信することで、早急なエラー対策を行うことができる。監視対象装置10aの通信状態が正常であるため早急なエラー対策は必要ないが、解析者にしか解決できないエラーの場合、管理サーバ装置22は、エラーの重要度を低く決定し、メール送信先を解析者のパソコン101に決定する。また、運用者にでも解決できるエラーの場合、管理サーバ装置22は、エラーの重要度を低く決定し、メール送信先を運用者のパソコン102に決定する。

0019

なお、図1では、3つの監視対象装置を示しているが、監視対象装置の数はこれに限定されない。また、図1では、保守システムは、一つの上位サーバ装置20を介して監視対象装置10を監視する構成としているが、複数の上位サーバ装置を有し、それぞれの上位サーバ装置に接続される監視対象装置を監視する構成としてもよい。さらに、保守システムを構成する各装置は、キーボード及びマウス等を備えるパソコンで実現するようにしてもよい。

0020

以下、保守システムの各装置の具体的な構成及び動作について説明する。

0021

図2は、保守システムの情報処理装置1が有する構成を示すブロック図である。情報処理装置1は、Central Processing Unit(CPU)2、Read Only Memory(ROM)3、Random Access Memory(RAM)4、大容量記憶装置5、及び、通信網を介して、上位サーバ装置20及び監視装置21等との通信を可能にする通信部6等のハードウェア各部を備える。これらのハードウェア各部はバスを介して相互に接続されている。なお、図2では省略しているが、監視対象装置10、上位サーバ装置20、監視装置21及び管理サーバ装置22は、情報処理装置1と同様に、CPU、ROM、RAM、大容量記憶装置、及び通信部等のハードウェア各部等を備えている。

0022

CPU2は、ROM3又は大容量記憶装置5に予め格納されているプログラムを適宜RAM4に読み出して実行すると共に、上述したハードウェア各部の動作を制御する。ROM3は、情報処理装置1に必要な動作をさせるためのプログラム3aを予め格納している。RAM4は、例えばStatic RAM(SRAM)、Dynamic RAM(DRAM)、フラッシュメモリ等である。RAM4は、CPU2による制御プログラムの実行時に発生する種々のデータを一時的に記憶する。

0023

大容量記憶装置5は、例えばハードディスクドライブであって、後述する必要なデータベース(DB)を記憶している。なお、ROM3が記憶するプログラム3aは、大容量記憶装置5に記憶されていてもよい。また、プログラム3aは、Compact Disc-ROM(CD−ROM)、Digital Versatile Disc-ROM(DVD−ROM)、又はMagneto-Optical disk(MO)等の記録媒体7により大容量記憶装置5にインストールし、又はネットワークからダウンロードして使用する形態でもよい。

0024

次に、CPU2が上述のROM3に格納されているプログラム3aを実行することで、情報処理装置1で実現される機能について説明する。

0025

図3は、情報処理装置1で実現される機能を示すブロック図である。情報処理装置1は、IPアドレス受信部31、プロトコル特定部32、通信先特定部33、設備情報取得部34、通信回数決定部35、シナリオ生成部36、シナリオ実行部37、及び結果通知部38等の機能を備えている。また、情報処理装置1は、プロトコルDB41、通信先DB(通信先記憶部)42及び設備情報DB(数記憶部)43等を備えている。

0026

IPアドレス受信部31(検知部)は、監視装置21からIPアドレスを受信する。監視装置21は、監視対象装置10それぞれからSNMPトラップを受信し、SNMPトラップに基づいて、監視対象装置10aにエラーが発生したことを検知する。このとき、監視装置21は、監視対象装置10aのIPアドレスを情報処理装置1へ送信する。IPアドレス受信部31は、そのIPアドレスを受信する。すなわち、IPアドレス受信部31がIPアドレスを受信することで、情報処理装置1は、エラーを検知する。

0027

プロトコル特定部32は、IPアドレス受信部31が受信したIPアドレスに基づいて、エラーが発生した監視対象装置10aの運用に必要なプロトコル、及びそのプロトコルのフォーマットを特定する。プロトコルのフォーマットは、予め情報処理装置1の大容量記憶装置5に複数パターンが格納されている。プロトコル特定部32は、大容量記憶装置5に格納されているプロトコルDB41から、プロトコル及びフォーマットを特定する。

0028

図4は、プロトコルDB41を模式的に示す図である。プロトコルDB41は、IPアドレス欄、SIP欄、HTTP欄、及びSMTP欄等を有している。IPアドレス欄には、監視対象装置10のIPアドレスが格納される。SIP欄には、IPアドレスに対応する監視対象装置10が利用するSIPの情報を格納している。例えば、SIP欄に「1」が格納されている場合、対応する監視対象装置10は、フォーマット番号が「1」のプロトコルを用いることを示す。SIP欄に「0」が格納されている場合、対応する監視対象装置10は、SIPを利用しないことを示す。同様に、HTTP欄及びSMTP欄には、IPアドレスに対応する監視対象装置10が利用するHTTP及びSMTPの情報を格納している。なお、プロトコルDB41は、SIP、HTTP及びSMTP以外のプロトコル情報を格納していてもよい。

0029

通信先特定部33は、IPアドレス受信部31が受信したIPアドレス、及びプロトコル特定部32が特定したプロトコルに基づいて、通信先を特定する。通信先とは、エラーが発生した監視対象装置10aと通信するためにアクセスする宛先である。例えば、監視対象装置10aがSIPを利用する場合には、通信先は、上位サーバ装置20の電話番号となり、HTTPを利用する場合には、上位サーバ装置20のUniform Resource Locator(URL)となる。また、SMTPを利用する場合には、通信先は、上位サーバ装置20のメールアドレスとなる。通信先特定部33は、大容量記憶装置5に格納されている通信先DB42から、通信先を特定する。

0030

図5は、通信先DB42を模式的に示す図である。通信先DB42は、IPアドレス欄、プロトコル欄、電話番号欄、URL欄及びメールアドレス欄等を有している。IPアドレス欄には、監視対象装置10のIPアドレスが格納される。プロトコル欄には、監視対象装置10が利用するプロトコルが格納される。例えば、プロトコル欄に「1」が格納された場合、対応する監視対象装置10は、SIPを利用し、「2」が格納された場合、HTTPを利用することを示し、「3」が格納された場合、SMTPを利用することを示している。電話番号欄には、対応する監視対象装置10の上位サーバ装置20が有する電話番号が格納される。URL欄には、対応する監視対象装置10の上位サーバ装置20へのパス名が格納される。メールアドレス欄には、対応する監視対象装置10の上位サーバ装置20が有するメールアドレスが格納される。なお、該当する情報がない場合には、各欄には「null」が格納される。例えば、IPアドレス受信部31が「10.95.88.6」のIPアドレスを受信し、プロトコル特定部32がSIPのプロトコルを特定した場合、通信先特定部33は、通信先として、上位サーバ装置20の電話番号「0600000001」を特定する。

0031

設備情報取得部34は、IPアドレス受信部31が受信したIPアドレス、及びプロトコル特定部32が特定したプロトコルに基づいて、設備情報を取得する。設備情報は、エラーが発生した監視対象装置10aが接続する上位サーバ装置20がラウンドロビンしている数、及び、上位サーバ装置20に対して接続要求を送信した場合に、応答がないときのタイムアウトとして判断する秒数である。設備情報取得部34は、大容量記憶装置5に格納されている設備情報DB43から、設備情報を取得する。

0032

図6は、設備情報DB43を模式的に示す図である。設備情報DB43は、IPアドレス欄、プロトコル欄、ラウンドロビン数欄及び通信インターバル情報欄等を有している。IPアドレス欄には、監視対象装置10のIPアドレスが格納される。プロトコル欄には、通信先DB42と同様に、対応する監視対象装置10が利用するプロトコルの情報が格納される。ラウンドロビン数欄には、対応する監視対象装置10が接続する上位サーバ装置20がラウンドロビンしている数が格納される。通信インターバル情報欄には、情報処理装置1が上位サーバ装置20に対して接続要求を送信した場合に、接続要求に対する応答がないときのタイムアウトとして判断する秒数が格納される。秒数は、上位サーバ装置20及び上位サーバ装置20に接続される監視対象装置10等の機能又は通信速度等に応じて、適宜決定される。

0033

通信回数決定部(特定部)35は、設備情報取得部34が取得したラウンドロビン数に基づいて、通信回数を決定する。通信回数とは、情報処理装置1が、エラーが発生した監視対象装置10aの上位サーバ装置20へ接続要求を送信する回数である。通信回数決定部35は、取得したラウンドロビン数に「2」を乗算した値を、通信回数として決定する。例えば、図1の場合、上位サーバ装置20がラウンドロビンしている数は「3」であるため、通信回数は、「6」となる。この場合、情報処理装置1は、上位サーバ装置20に対して、接続要求を6回送信する。

0034

シナリオ生成部36は、プロトコル特定部32が特定したプロトコルのフォーマット、及び、通信先特定部33が特定した通信先に基づいて、エラーが発生した監視対象装置10aの通信状態を確認する処理を行うためのシナリオを生成する。例えば、監視対象装置10aがSIPを利用する場合には、シナリオ生成部36は、INVITEメッセージを生成する。シナリオ生成部36は、予め記憶された複数のシナリオのフォーマットから、プロトコル特定部32が特定したプロトコルのフォーマットを取得する。そして、シナリオ生成部36は、取得したフォーマットにおける該当箇所を設定(変更)する。

0035

図7は、SIPを利用する場合に、シナリオ生成部36が生成するシナリオの一例を示す図である。図7において、シナリオ生成部36は、着呼先(図中「To」の行)に、通信先特定部33が特定した上位サーバ装置20の電話番号を設定し、発呼元(図中「From」の行)に、情報処理装置1の電話番号を設定する。図7に示すINVITEメッセージを受信した上位サーバ装置20は、発呼元の情報処理装置1に対する応答を送信するように、監視対象装置10へ指示する。なお、監視対象装置10aがHTTP又はSMTPを利用する場合には、シナリオ生成部36は、それぞれ対応するシナリオを生成する。図8は、HTTPを利用する場合に、シナリオ生成部36が生成するシナリオの一例を示す図である。図9は、SMTPを利用する場合に、シナリオ生成部36が生成するシナリオの一例を示す図である。図8の場合、シナリオ生成部36は、通信先(図中「GET」の行)に、通信先特定部33が特定したURLを設定する。上位サーバ装置20は、URLに基づいて、情報処理装置1へアクセスするように、監視対象装置10へ指示する。また図9の場合、シナリオ生成部36は、通信先(図中「RCPT TO」の行)に、通信先特定部33が特定したメールアドレスを設定する。上位サーバ装置20は、メールアドレスに基づいて、情報処理装置1へメールを送信するように、監視対象装置10へ指示する。なお、図7図8及び図9に示すシナリオは、一般的なフォーマットであり、適宜変更可能である。

0036

シナリオ実行部(送信部)37は、シナリオ生成部36が生成したシナリオに従って、通信状態の確認を実行する。具体的には、シナリオ実行部37は、シナリオ生成部36が生成したシナリオに従って、通信回数決定部35が決定した通信回数、上位サーバ装置20へ接続要求を送信する。このとき、シナリオ実行部37は、決定した通信回数の半分の回数、すなわち、ラウンドロビン数の回数、接続要求を送信する。送信時に、ラウンドロビン数の回数、接続要求を送信することで、情報処理装置1は、上位サーバ装置20に接続される全ての監視対象装置10との通信状態を確認できる。そして、シナリオ実行部37は、設備情報取得部34が取得した通信インターバル情報の秒数だけ待機し、通信回数の残りの回数、すなわち、ラウンドロビン数の回数、接続要求を送信する。以下の説明では、最初に通信回数の半分の回数、接続要求を送信することを、第1送信といい、残りの回数、接続要求を送信することを、第2送信という。また、第1送信時に接続要求を送信する回数を、第1送信回数といい、第2送信時に接続要求を送信する回数を、第2送信回数という。

0037

結果通知部(判定部)38は、シナリオ実行部37による実行の結果を、監視装置21へ通知する。詳しくは、結果通知部38は、接続要求の第1送信の結果を破棄して、第2送信の結果を採用し、監視装置21へ結果を通知する。上位サーバ装置20は、故障と判断した監視対象装置10aに対して閉塞処理を行うため、以降の通信には、監視対象装置10b,10cのみと通信をする。接続要求の第1送信時に閉塞処理を行った場合、第2送信時には通信の影響がなくなることがあるため、結果通知部38は、第1送信の結果を破棄し、第2送信の結果を採用する。第2送信において、接続要求を送信した第2送信回数分の応答があった場合には、結果通知部38は、監視対象装置10の通信は正常として監視装置21へ通知する。一方、第2送信回数分の応答がない場合には、結果通知部38は、監視対象装置10の通信は異常として監視装置21へ通知する。

0038

上述のように、上位サーバ装置20は、エラーが発生した監視対象装置10aに対して閉塞処理を行い、監視対象装置10aとの通信を回避する。このため、第1送信で監視対象装置10aとの通信ができなくても、第2送信では他の監視対象装置10b,10cと通信できるため、結果通知部38は、第2送信で接続要求を送信した第2送信回数分の応答を受信できる。この場合、結果通知部38は、監視対象装置10の通信状態が異常として通知しない。一方、上位サーバ装置20が閉塞処理を行わない場合には、上位サーバ装置20は、第2送信時でも監視対象装置10aとの通信を行なうため、情報処理装置1は、第2送信で接続要求を送信した第2送信回数分の応答を受信できない。この場合、結果通知部38は、監視対象装置10の通信は異常として監視装置21へ通知する。このように、上位サーバ装置20の機能に関係なく、常に同じ処理で、信頼性のある監視対象装置10の通信状態の確認を行える。

0039

次に、管理サーバ装置22で実現される機能について説明する。図10は、管理サーバ装置22で実現される機能を示すブロック図である。図10に示す各機能は、管理サーバ装置22のCPUがROMに記憶されたプログラムを実行することで実現される。管理サーバ装置22は、結果受信部51、WEB表示処理部52、重要度決定部53、送信先決定部54、及びメール送信部55等の機能を有している。

0040

結果受信部51は、監視装置21からの通信状態の確認結果、及びエラーログを受信する。WEB表示処理部52は、結果受信部51が受信したエラーログに基づいて、エラー名、及びエラー発生時刻等のエラー情報をWEB表示可能にする。

0041

重要度決定部53は、結果受信部51が受信する通信状態の確認結果、及びエラーログに基づいて、発生したエラーの重要度を決定する。エラーの重要度は、降順に、重要度A、重要度B、重要度C及び重要度Dの4段階に分類されている。図11は、重要度を決定する方法を説明するための模式図である。エラーの重要度は、監視対象装置10との通信状態、発生したエラーの警戒レベル、発生したエラーの解析状況に基づいて決定される。なお、警戒レベルは、監視装置21においてエラー番号に基づいて特定され、特定された結果、所定レベル以上であるか否かが監視装置21からエラーログと共に通知される。また、エラーの解析状況は、例えば、受信したエラーログに、監視対象装置10aが状態確認コマンドを投入することで得られる動作状態を含んでいるかにより判定される。

0042

監視対象装置10との通信が異常の場合、重要度決定部53は、重要度Aに決定する。監視対象装置10との通信が正常であるが、発生したエラーの解析が未だの場合、重要度決定部53は、重要度Bに決定する。監視対象装置10との通信が正常で、エラーの解析が済んでおり、さらに、警戒レベルが所定レベル以上の場合、重要度決定部53は、重要度Cに決定する。監視対象装置10との通信が正常で、エラーの解析が済んでおり、さらに、警戒レベルが所定レベル以下の場合、重要度決定部53は、重要度Dに決定する。

0043

送信先決定部54は、重要度決定部53が決定した重要度に応じて、メール送信先を決定する。具体的には、重要度Aの場合、送信先決定部54は、メール送信先を、解析者の携帯電話機100に決定する。重要度Bの場合、送信先決定部54は、メール送信先を、解析者のパソコン101に決定する。重要度C,Dの場合、送信先決定部54は、メール送信先を、運用者のパソコン102に決定する。

0044

メール送信部55は、送信先決定部54が決定した送信先へ、WEB表示処理部52がWEB表示可能にしたエラー情報へのリンクを含めたメールを送信する。保守担当者は、携帯電話機100又はパソコン101,102が受信したメールのリンクから、WEB表示処理部52がWEB表示可能にしたエラー情報を確認することができる。

0045

以下に、WEB表示可能にしたエラー情報を携帯電話機100で確認する場合について説明する。図12は、携帯電話機100でエラー情報を確認した場合の模式図である。管理サーバ装置22が受信したエラーログ(図12上段左側)は、アクセスしてきた携帯電話機100で視認しやすいように、図中の四角で囲ってある必要な部分が抜き出される。アクセスしてきた携帯電話機100の画面には、その抜き出された部分、及び、監視対象装置10aに投入すべきコマンドの候補が表示される(図12の上段右側)。コマンドの候補は、選択可能に表示される。携帯電話機100でコマンドが選択された場合、管理サーバ装置22から監視対象装置10aへ選択されたコマンドが送信される。監視対象装置10aでは、選択されたコマンドが投入され、投入結果がエラーログ(図12下段左側)として監視対象装置10aから管理サーバ装置22へ送信される。管理サーバ装置22では、再度、必要な部分が抜き出され、携帯電話機100の画面に表示される(図12の下段右側)。

0046

以下に、保守システムにおける動作について説明する。

0047

監視対象装置10に発生するエラーを検知する監視装置21における動作を説明する。図13及び図14は、監視装置21の動作を示すフローチャートである。なお、図13及び図14では、監視装置21における動作と並列して、監視対象装置10の動作を示している。

0048

監視対象装置10では、CPUがSNMPトラップを監視装置21へ送信する(S1)。監視装置21では、CPUがSNMPトラップを監視対象装置10aから受信したか否かを判定する(S10)。SNMPトラップを受信していない場合(S10:NO)、CPUは、受信するまで待機する。SNMPトラップを受信した場合(S10:YES)、CPUは、受信したSNMPトラップに基づいてエラーを検知し、そのSNMPトラップを送信した監視対象装置10aのIPアドレスを取得する(S11)。そして、CPUは、取得したIPアドレスを、情報処理装置1へ送信する(S12)。IPアドレスを受信した情報処理装置1では、監視対象装置10の通信状態を確認する後述の処理が行われる。

0049

監視装置21では、CPUが、情報処理装置1から通信状態の確認結果を受信したか否かを判定する(S13)。受信していない場合(S13:NO)、CPUは、受信するまで待機する。受信した場合(S13:YES)、監視対象装置10aで発生したエラーに対応するエラー番号を取得し、エラーが発生した監視対象装置10aへ、エラー番号を送信する(S14)。

0050

監視対象装置10では、監視装置21からエラー番号を受信したか否かを判定する(S2)。監視対象装置10でエラーが発生していない場合には、監視装置21からエラー番号が送信されることはないため、エラー番号を受信していない場合(S2:NO)、監視対象装置10では、処理が終了する。監視装置21からエラー番号を受信した場合(S2:YES)、監視対象装置10のCPUは、受信したエラー番号に基づいて、発生したエラーの解析に必要なログを抽出する(S3)。具体的には、CPUは、状態確認コマンドを投入し、その結果得られる自身の動作状態を取得する。CPUは、抽出したログをエラーログとして監視装置21へ送信する(S4)。その後、監視対象装置10では、処理が終了する。

0051

監視装置21では、エラー番号を送信した後、CPUが、エラーログを監視対象装置10から受信したか否かを判定する(S15)。エラーログを受信していない場合(S15:NO)、CPUは、エラー番号を送信してから所定時間が経過したか否かを判定する(S16)。所定時間が経過していない場合(S16:NO)、CPUは、S15の処理に戻る。所定時間が経過した場合(S16:YES)、CPUは、S14で取得したエラー番号、及び通信状態の確認結果を管理サーバ装置22へ送信し(S17)、本処理を終了する。エラーログを監視対象装置10から受信した場合(S15:YES)、CPUは、エラー番号、受信したエラーログ及び通信状態の確認結果を管理サーバ装置22へ送信し(S18)、本処理を終了する。

0052

次に、監視対象装置10aにエラーが発生した場合、エラーの重要度を決定するために監視対象装置10aの通信状態を確認する情報処理装置1における動作について説明する。図15及び図16は、情報処理装置1の動作を示すフローチャートである。

0053

情報処理装置1のCPU2は、エラーの発生を検知した監視装置21からIPアドレスを受信したか否かを判定する(S21)。IPアドレスを受信していない場合(S21:NO)、CPU2は、受信するまで待機する。IPアドレスを受信した場合(S21:YES)、CPU2は、IPアドレスとプロトコルDB41とに基づいて、エラーが発生した監視対象装置10aの運用に必要なプロトコル、及びそのプロトコルのフォーマットを特定する(S22)。

0054

次に、CPU2は、受信したIPアドレス及び特定したプロトコルに基づいて、通信先を特定する(S23)。例えば、エラーが発生した監視対象装置10aがSIPを利用する場合、CPU2は、通信先DB42から、監視対象装置10aの上位サーバ装置20の電話番号を特定する。続いて、CPU2は、受信したIPアドレス、及び、特定したプロトコルに基づいて、エラーが発生した監視対象装置10aが接続している上位サーバ装置20のラウンドロビン数を取得する(S24)。また、CPU2は、その上位サーバ装置20の通信インターバル情報を取得する(S25)。CPU2は、取得したラウンドロビン数に「2」を乗算した値を、通信回数として決定する(S26)。

0055

次に、CPU2は、エラーが発生した監視対象装置10aの上位サーバ装置20へ接続要求を送信するためのシナリオを生成する(S27)。例えば、上位サーバ装置20がSIPサーバ装置の場合には、CPU2は、図7に示すINVITEメッセージを生成する。CPU2は、生成したシナリオに従って、接続要求を上位サーバ装置20へ送信し(S28)、第1送信回数、接続要求を送信したか否かを判定する(S29)。第1送信回数は、決定した通信回数の半分の回数、すなわち、ラウンドロビン数である。ラウンドロビン数の回数、接続要求を送信することで、上位サーバ装置20に接続される全ての監視対象装置10との通信状態を確認できる。第1送信回数、接続要求を送信していない場合(S29:NO)、CPU2は、S28の処理を実行し、接続要求を送信し続ける。第1送信回数、接続要求を送信した場合(S29:YES)、CPU2は、S25で取得した通信インターバル情報の秒数だけ待機する(S30)。インターバルを設定して、待機することで、タイムアウトか否かを判定する処理を行うために、情報処理装置1が監視対象装置10からの応答を受信できなくなることを回避することができる。

0056

その後、CPU2は、第2送信を開始し、接続要求を上位サーバ装置20へ送信する(S31)。CPU2は、第2送信回数、接続要求を送信したか否かを判定する(S32)。第2送信回数、接続要求を送信していない場合(S32:NO)、CPU2は、S31の処理に戻り、接続要求を送信し続ける。第2送信回数、接続要求を送信した場合(S32:YES)、CPU2は、監視対象装置10の通信状態が正常か否かを判定する(S33)。具体的には、CPU2は、第1送信における応答結果を破棄し、第2送信において、第2送信回数と同じ回数、応答を受信したか否かを判定する。上位サーバ装置20が上述の閉塞処理を行う場合には、第2送信時で接続要求を送信した第2送信回数と同じ回数、応答を受信する。このため、CPU2は、監視対象装置10aとは通信できなくても、他の監視対象装置10b,10cと通信できるため、通信状態は正常と判定する。一方、上位サーバ装置20が閉塞処理を行わない場合には、第2送信時で接続要求を送信した第2送信回数と同じ回数、応答を受信しない。このため、CPU2は、監視対象装置10aとは通信できないとして、通信状態は正常と判定する。

0057

監視対象装置10の通信状態が正常の場合(S33:YES)、CPU2は、通信状態は「正常」であることを監視装置21へ通知し(S34)、本処理を終了する。監視対象装置10の通信状態が正常でない場合(S33:NO)、CPU2は、通信状態は「異常」であることを監視装置21へ通知し(S35)、本処理を終了する。

0058

次に、接続要求を受信し、情報処理装置1と監視対象装置10とを接続する上位サーバ装置20における動作について説明する。図17は、上位サーバ装置20の動作を示すフローチャートである。

0059

上位サーバ装置20では、CPUが情報処理装置1から接続要求を受信したか否かを判定する(S41)。受信していない場合(S41:NO)、CPUは本処理を終了する。受信した場合(S41:YES)、CPUは、ラウンドロビン方式に従って、接続されている監視対象装置10へ、接続要求を送信する(S42)。次に、CPUは、接続要求を送信した監視対象装置10から応答を受信したか否かを判定する(S43)。受信した場合(S43:YES)、CPUは、受信した応答を、情報処理装置1へ送信し(S44)、本処理を終了する。

0060

応答を受信していない場合(S43:NO)、CPUは、監視対象装置10へ接続要求を送信してから、所定時間経過したか否かを判定する(S45)。所定時間経過していない場合(S45:NO)、CPUは、S43の処理を実行する。所定時間経過した場合(S45:YES)、CPUは、応答を送信しない監視対象装置10に対して、閉塞処理を実行する(S46)。これにより、以降の処理では、上位サーバ装置20は、閉塞処理を実行した監視対象装置10に対しては、接続要求を送信しなくなる。

0061

次に、発生したエラーの重要度を決定する管理サーバ装置22における動作について説明する。図18及び図19は、管理サーバ装置22の動作を示すフローチャートである。

0062

管理サーバ装置22のCPUは、監視装置21から各情報を受信したか否かを判定する(S51)。具体的には、受信する情報とは、エラー番号、通信状態の確認結果、及びエラーログ等である。なお、エラーが発生した監視対象装置10aから監視装置21へエラーログが送信されない場合、CPUは、エラー番号、及び通信状態の確認結果を受信したか否かを判定する。受信していない場合(S51:NO)、CPUは、受信するまで待機する。受信した場合(S51:YES)、エラー番号及びエラーログに基づいて、エラー名、及びエラー発生時刻等のエラー情報をWEB表示可能にする処理を行う(S52)。

0063

次に、CPUは、図11で説明したように、発生したエラーの重要度を決定する(S53)。CPUは、決定した重要度が、「重要度A」であるか否かを判定する(S54)。決定した重要度が「重要度A」である場合(S54:YES)、CPUは、解析者の携帯電話機100へメールを送信し(S55)、S59の処理へ移る。送信するメールには、S52でWEB表示可能にしたエラー情報へのアクセス先リンク情報)が含まれている。決定した重要度が「重要度A」でない場合(S54:NO)、CPUは、決定した重要度が「重要度B」であるか否かを判定する(S56)。決定した重要度が「重要度B」である場合(S56:YES)、CPUは、解析者のパソコン101へメールを送信し(S57)、S59の処理へ移る。決定した重要度が「重要度B」でない場合(S56:NO)、すなわち、重要度が「重要度C」又は「重要度D」の場合、CPUは、運用者のパソコン102へメールを送信する(S58)。そして、CPUは、S59の処理へ移る。

0064

CPUは、メールを送信した携帯電話機100又はパソコン101,102からアクセスされたか否かを判定する(S59)。アクセスされていない場合(S59:NO)、CPUは、アクセスされるまで待機する。なお、所定時間アクセスされない場合には、CPUは、処理を終了するようにしてもよい。アクセスされた場合(S59:YES)、CPUは、HTTPにより、S52の処理でWEB表示可能にした情報を、アクセス元へ送信する(S60)。これにより、アクセス元の携帯電話機100又はパソコン101,102の画面には、図12で説明したように、エラー情報が表示され、投入コマンドが選択可能に表示される。

0065

CPUは、アクセス元の携帯電話機100又はパソコン101,102でコマンドが選択され、そのコマンドを受け付けたか否かを判定する(S61)。コマンドを受け付けていない場合(S61:NO)、CPUは、受け付けるまで待機する。コマンドを受け付けた場合(S61:YES)、CPUは、受け付けたコマンドが完了コマンドであるか否かを判定する(S62)。完了コマンドは、保守管理者が、エラーが解消したと判断した場合に、選択される。受け付けたコマンドが完了コマンドである場合(S62:YES)、CPUは、本処理を終了する。受け付けたコマンドが完了コマンドでない場合(S62:NO)、CPUは、対応するコマンドを、エラーが発生した監視対象装置10aへ送信する(S63)。そして、CPUは、そのコマンドに対する結果を受信したか否かを判定する(S64)。受信していない場合(S64:NO)、CPUは、受信するまで待機する。受信した場合(S64:YES)、CPUは、受信した結果を、WEB表示可能に処理する(S65)。その後、CPUは、S61の処理を実行し、再びコマンドを受け付けたか否かを判定する。

0066

以上説明したように、本実施の形態では、情報処理装置1は、エラーが発生した監視対象装置10との通信状態を確認する場合、接続要求の送信を第1送信及び第2送信に分けて行なう。そして、第1送信に対する応答を破棄して、第2送信に対する応答に基づいて、監視対象装置10との通信状態を確認する。上位サーバ装置20によっては、エラーが発生した監視対象装置10に対して閉塞処理を行い、以降、その監視対象装置10との通信を避ける機能を有している。このため、第1送信では応答を受信しなくても、第2送信で応答を受信する場合がある。そこで、第2送信に対する応答に基づいて、監視対象装置10の通信状態を確認することで、上位サーバ装置20が有する機能に関係なく、同じ処理で、より精度の高い通信状態の確認を行うことができる。その結果、通信異常が監視対象装置10の運用に問題を引き起こす場合、通信状態を確実に把握することで、通信状態に応じたエラーの重要度を決定することが可能となり、最適なエラー対策を行なえる。

0067

本発明の実施形態について、具体的に説明したが、各構成及び動作等は適宜変更可能であって、上述の実施形態に限定されることはない。例えば、監視装置21及び管理サーバ装置22の機能は、一つの装置で実現するように構成してもよい。また、エラー発生時には、メールにて保守担当者に通知しているが、携帯電話機に電話をかけて、自動音声で通知するようにしてもよい。

0068

また、本実施の形態では、上位サーバ装置20は、エラーがある監視対象装置10に対して閉塞処理を行うものとしているが、上位サーバ装置20を複数設ける場合、全ての上位サーバ装置20を、閉塞処理を行う装置とする必要はない。異なる機能を有する上位サーバ装置20が混在している場合であっても、第1送信で送信した接続要求に対する結果を破棄することで、情報処理装置1は、上位サーバ装置20の種類を把握することなく、一様に同じ処理で通信状態を確認することができる。

0069

本実施の形態では、上位サーバ装置20のラウンドロビンの数の回数、接続要求を送信する第1及び第2送信を行なっているが、送信回数は、上位サーバ装置20が有する機能に応じて適宜変更可能である。例として、情報処理装置1は、第1送信において、接続要求の送信先にエラーが発生した監視対象装置10aを指定する。上位サーバ装置20は、エラーが発生した監視対象装置10aとの通信を行い、故障と判断した場合、監視対象装置10aに閉塞処理を行う。続いて、第2送信で接続要求を受信した上位サーバ装置20は、自動的に、他の監視対象装置10b,10cとの通信を行なう。このような場合、第1及び第2送信回数は、1回でよくなり、第2送信における応答を受信すれば、情報処理装置1は、通信状態を「正常」と判定する。

0070

また、本実施の形態では、上位サーバ装置20がラウンドロビン方式に従って、監視対象装置10と通信するようにしているが、情報処理装置1と監視対象装置10との通信方式は、これに限定されることはない。例えば、第1送信において、情報処理装置1は、エラーが発生した監視対象装置10aを送信先に指定した接続要求を上位サーバ装置20へ送信する。監視対象装置10aが故障と判断した場合、上位サーバ装置20は、監視対象装置10aに対して閉塞処理を行い、以降、監視対象装置10aを送信先に指定した接続要求を受信した場合であっても、上位サーバ装置20は、監視対象装置10aと通信を行わないようにする。この場合、情報処理装置1は、第1送信で接続要求に対する応答がなくても、第2送信で応答を受信することができる。すなわち、情報処理装置1は、第1及び第2送信で、一回のみ接続要求を送信することで、監視対象装置10の通信状態を確認することができる。

0071

以下に、上述の実施形態を含む実施形態に関し、更に付記を開示する。

0072

(付記1)
複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信することで、前記被監視装置の通信状態を確認する通信確認装置において、
前記被監視装置にエラーが発生したことを検知する検知部と、
前記被監視装置、及び該被監視装置が接続される外部装置の接続先を記憶する通信先記憶部と、
該検知部がエラーを検知した場合、前記通信先記憶部に記憶した接続先に基づいて接続要求信号を前記外部装置へ二回送信する送信部と、
該送信部が二回目に送信した接続要求信号に対する応答信号を受信したか否かを判定する判定部と
を備える通信確認装置。

0073

(付記2)
前記外部装置に接続されている被監視装置の数を記憶する数記憶部と、
前記検知部がエラーを検知した場合、前記外部装置に接続されている被監視装置の数を、前記数記憶部の記憶内容から特定する数特定部と
をさらに備え、
前記送信部は、
前記数特定部が特定した数を、一回目及び二回目それぞれの接続要求信号の送信回数として、接続要求信号を送信するようにしてある
付記1に記載の通信確認装置。

0074

(付記3)
前記送信部は、
一回目の接続要求信号の送信終了後、所定時間経過後に、二回目の接続要求信号を送信するようにしてある
付記1又は2に記載の通信確認装置。

0075

(付記4)
前記検知部がエラーを検知した場合、エラーが発生した被監視装置を特定する装置特定
をさらに備え、
前記送信部は、
一回目の送信で、前記装置特定部が特定した被監視装置を送信先に指定し、前記外部装置へ接続要求を送信するようにしてある
付記1から3の何れか一つに記載の通信確認装置。

0076

(付記5)
複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信することで、前記被監視装置の通信状態を確認する通信確認方法において、
前記被監視装置にエラーが発生したことを検知し、
前記被監視装置、及び該被監視装置が接続される外部装置の接続先を記憶し、
エラーを検知した場合、記憶した接続先に基づいて前記外部装置へ接続要求信号を二回送信し、
二回目に送信した接続要求信号に対する応答信号を受信したか否かを判定する
通信確認方法。

0077

(付記6)
複数の被監視装置が接続され、接続要求信号を前記被監視装置に分配する外部装置に、接続要求信号を送信するコンピュータで実行されるプログラムにおいて、
コンピュータを、
前記被監視装置にエラーが発生したことを検知する検知部、
該検知部がエラーを検知した場合、記憶された、前記被監視装置、及び該被監視装置が接続される外部装置の接続先に基づいて、接続要求信号を前記外部装置へ二回送信させる送信部、及び、
該送信部が二回目に送信させた接続要求信号に対する応答信号を受信したか否かを判定する判定部
として機能させるプログラム。

0078

(付記7)
付記6に記載のプログラムが記録されており、コンピュータでの読取り可能な記録媒体。

0079

1情報処理装置
5大容量記憶装置(数記憶部、通信先記憶部)
10監視対象装置(被監視装置)
20上位サーバ装置(外部装置)
21監視装置
22管理サーバ装置
31IPアドレス受信部(検知部)
34設備情報取得部(特定部)
37シナリオ実行部(送信部)
38結果通知部(判定部)
41プロトコルDB
42 通信先DB(通信先記憶部)
43 設備情報DB(数記憶部)
100携帯電話機
101,102 パソコン

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • キヤノン株式会社の「 情報処理装置及びその制御方法、並びにプログラム」が 公開されました。( 2019/09/12)

    【課題】情報処理装置内でイベントログを効率的にバッファリングしながら、サーバ装置に適合したデータ形式でイベントログを送信する技術を提供する。【解決手段】構造化モジュール403,405,421は、MFP... 詳細

  • 株式会社東芝の「 通信制御装置および通信制御方法」が 公開されました。( 2019/09/12)

    【課題】VPPにおける機器へのアクセス許可設定を可能とすること。【解決手段】実施形態に係る通信制御装置は、機器、かかる機器を制御するアグリゲータ、および、かかるアグリゲータの機器へのアクセス許可を設定... 詳細

  • 株式会社東芝の「 通信装置、通信方法およびプログラム」が 公開されました。( 2019/09/12)

    【課題】相互に異なる複数の制御方式による通信が混在する通信システムを効率的に構築可能な通信装置、通信方法およびプログラムを提供する。【解決手段】通信装置は、複数の通信制御部と、選択部と、を備える。複数... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ