特開 2023-17682 保守管理システム、保守管理方法、管理サーバ、連携サーバ及び保守管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023017682

(43)【公開日】2023-02-07

(54)【発明の名称】保守管理システム、保守管理方法、管理サーバ、連携サーバ及び保守管理プログラム

(51)【国際特許分類】

   H04L 41/022 20220101AFI20230131BHJP

【ＦＩ】

H04L41/022

【審査請求】未請求

【請求項の数】18

【出願形態】ＯＬ

(21)【出願番号】P 2021212253

(22)【出願日】2021-12-27

(31)【優先権主張番号】P 2021121465

(32)【優先日】2021-07-26

(33)【優先権主張国・地域又は機関】JP

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】000000295

【氏名又は名称】沖電気工業株式会社

(74)【代理人】

【識別番号】100180275

【弁理士】

【氏名又は名称】吉田 倫太郎

(74)【代理人】

【識別番号】100161861

【弁理士】

【氏名又は名称】若林 裕介

(72)【発明者】

【氏名】▲高▼木 洋平太

(72)【発明者】

【氏名】鈴木 友泰

(72)【発明者】

【氏名】橋本 香奈美

(57)【要約】

【課題】ネットワーク上の様々な装置が一般的に保有している定型保守作業を統合的にできるようにする。
【解決手段】本発明に係る保守管理システムは、保守端末に接続される第１のサーバと、複数の対象装置に接続される第２のサーバとを備え、第１のサーバが、保守端末からの複数の対象装置の各々に対する共通保守要求を第２のサーバに送信すると共に、第２のサーバを通じて取得した、共通保守要求に対する複数の対象装置の各々の応答結果を、保守端末に送信する、保守種別毎の共通要求部を有し、第２のサーバが、保守種別毎の共通要求部からの共通保守要求を、複数の対象装置の各々が対応可能な形式に変換して、対応する複数の対象装置の各々に送信すると共に、複数の対象装置の各々からの応答結果を、共通要求部の形式に変換して、対応する共通要求部に送信する、保守種別毎の応答部を有する。
【選択図】 図１

【特許請求の範囲】

【請求項1】

保守端末に接続される第１のサーバと、
複数の対象装置に接続される第２のサーバと
を備え、
前記第１のサーバが、
前記保守端末からの前記複数の対象装置の各々に対する共通保守要求を前記第２のサーバに送信すると共に、前記第２のサーバを通じて取得した、前記共通保守要求に対する前記複数の対象装置の各々の応答結果を、前記保守端末に送信する、保守種別毎の共通要求部を有し、
前記第２のサーバが、
前記保守種別毎の前記共通要求部からの前記共通保守要求を、前記複数の対象装置の各々が対応可能な形式に変換して、対応する前記複数の対象装置の各々に送信すると共に、前記複数の対象装置の各々からの応答結果を、前記共通要求部の形式に変換して、対応する前記共通要求部に送信する、保守種別毎の応答部を有する
ことを特徴とする保守管理システム。

【請求項2】

前記第２のサーバの前記保守種別毎の前記応答部が、前記複数の対象装置の各々のインタフェースと、前記保守種別毎の前記共通要求部のインタフェースとの相互変換する相互変換部を有することを特徴とする請求項１に記載の保守管理システム。

【請求項3】

前記共通保守要求に係る保守種別が、前記複数の対象装置の各々に対するコマンド投入を含み、
前記コマンド投入に係る前記応答部が、
対応する前記共通要求部から取得した、コマンド投入先とコマンド文字列を含む要求を、前記複数の対象装置の各々が依存するプロトコルに従ったコマンドに変換して前記複数の対象装置の各々に送信し、
前記複数の対象装置の各々から取得した、前記要求に対する応答結果を、所定形式のコマンド応答文字列に変換して、対応する前記共通要求部に送信し、
前記共通要求部が、前記複数の対象装置の各々からの応答結果を含む画面を前記保守端末に表示する
ことを特徴とする請求項１又は２に記載の保守管理システム。

【請求項4】

前記複数の対象装置の各々が依存しているコマンドと、前記共通保守要求に係るコマンドとを対応させた設定情報を有する設定情報記憶部を有し、
前記第１のサーバが、前記設定情報を参照して、前記複数の対象装置の各々からの応答結果を変換した画面を前記保守端末に表示させる
ことを特徴とする請求項３に記載の保守管理システム。

【請求項5】

前記第１のサーバが、
前記複数の対象装置を有する対象システム毎に、当該対象システムの前記複数の対象装置の各々に対して行なう前記複数の共通保守要求を設定した保守シナリオを記憶する保守シナリオ記憶部と、
前記対象システム毎の前記保守シナリオに設定されている実行時刻に、前記共通要求部に対して、当該保守シナリオに設定されている前記複数の共通保守要求を実行させる保守実行部と
を備えることを特徴とする請求項１～４のいずれかに記載の保守管理システム。

【請求項6】

前記第１のサーバが、
前記保守端末を通じて、前記対象システム毎に、前記対象システムが有する前記複数の対象装置の各々に対して行なう前記共通保守要求を順番に設定し、設定した前記複数の共通保守要求の各々に関する実行処理を設定して、当該対象システムの前記保守シナリオを登録する登録部を備えることを特徴とする請求項５に記載の保守管理システム。

【請求項7】

前記第１のサーバが、前記対象システムの障害発生を監視する障害監視部を備え、
前記保守実行部が、障害検知した前記障害監視部からの障害通知に関連付けられている前記保守シナリオに従って、前記共通要求部に対して前記複数の共通保守要求を実行させる
ことを特徴とする請求項５又は６に記載の保守管理システム。

【請求項8】

保守端末に接続される第１のサーバが、保守種別毎の共通要求部を有し、
複数の対象装置に接続される第２のサーバが、保守種別毎の応答部を有し、
前記共通要求部が、前記保守端末からの前記複数の対象装置の各々に対する共通保守要求を前記第２のサーバに送信し、
対応する前記応答部が、前記保守種別毎の前記共通要求部からの前記共通保守要求を、前記複数の対象装置の各々が対応可能な形式に変換して、対応する前記複数の対象装置の各々に送信し、
前記応答部が、前記複数の対象装置の各々からの応答結果を、前記共通要求部の形式に変換して、対応する前記共通要求部に送信し、
前記共通要求部が、前記応答部から取得した、前記共通保守要求に対する前記複数の対象装置の各々の応答結果を、前記保守端末に送信する
ことを特徴とする保守管理方法。

【請求項9】

複数の対象装置に接続される連携サーバと連携して、前記複数の対象装置の各々の保守情報を保守端末に与える管理サーバであって、
前記保守端末からの前記複数の対象装置の各々に対する共通保守要求を前記連携サーバに送信すると共に、前記連携サーバを通じて取得した、前記共通保守要求に対する前記複数の対象装置の各々の応答結果を、前記保守端末に送信する、保守種別毎の共通要求部
を有することを特徴とする管理サーバ。

【請求項10】

前記複数の対象装置を有する対象システム毎に、当該対象システムの前記複数の対象装置の各々に対して行なう前記複数の共通保守要求を設定した保守シナリオを記憶する保守シナリオ記憶部と、
前記対象システム毎の前記保守シナリオに設定されている実行時刻に、前記共通要求部に対して、当該保守シナリオに設定されている前記複数の共通保守要求を実行させる保守実行部と
を備えることを特徴とする請求項９に記載の管理サーバ。

【請求項11】

前記保守端末を通じて、前記対象システム毎に、前記対象システムが有する前記複数の対象装置の各々に対して行なう前記共通保守要求を順番に設定し、設定した前記複数の共通保守要求の各々に関する実行処理を設定して、当該対象システムの前記保守シナリオを登録する登録部を備えることを特徴とする請求項１０に記載の管理サーバ。

【請求項12】

前記対象システムの障害発生を監視する障害監視部を備え、
前記保守実行部が、障害検知した前記障害監視部からの障害通知に関連付けられている前記保守シナリオに従って、前記共通要求部に対して前記複数の共通保守要求を実行させる
ことを特徴とする請求項１０又は１１に記載の管理サーバ。

【請求項13】

保守端末に接続される管理サーバと連携して、接続する複数の対象装置の保守情報を取得する連携サーバであって、
前記管理サーバ上の保守種別毎の共通要求部から取得した、前記複数の対象装置の各々に対する共通保守要求を、前記複数の対象装置の各々が対応可能な形式に変換して、対応する前記複数の対象装置の各々に送信すると共に、前記複数の対象装置の各々からの応答結果を、前記共通要求部の形式に変換して、対応する前記共通要求部に送信する、保守種別毎の応答部
を有することを特徴とする連携サーバ。

【請求項14】

複数の対象装置に接続される連携サーバと連携して、前記複数の対象装置の各々の保守情報を保守端末に与える保守管理プログラムであって、
コンピュータを、
前記保守端末からの前記複数の対象装置の各々に対する共通保守要求を前記連携サーバに送信すると共に、前記連携サーバを通じて取得した、前記共通保守要求に対する前記複数の対象装置の各々の応答結果を、前記保守端末に送信する、保守種別毎の共通要求部として機能させることを特徴とする保守管理プログラム。

【請求項15】

コンピュータを、
前記複数の対象装置を有する対象システム毎に、当該対象システムの前記複数の対象装置の各々に対して行なう前記複数の共通保守要求を設定した保守シナリオを記憶する保守シナリオ記憶部と、
前記対象システム毎の前記保守シナリオに設定されている実行時刻に、前記共通要求部に対して、当該保守シナリオに設定されている前記複数の共通保守要求を実行させる保守実行部と
として機能させることを特徴とする請求項１４に記載の保守管理プログラム。

【請求項16】

コンピュータを
前記保守端末を通じて、前記対象システム毎に、前記対象システムが有する前記複数の対象装置の各々に対して行なう前記共通保守要求を順番に設定し、設定した前記複数の共通保守要求の各々に関する実行処理を設定して、当該対象システムの前記保守シナリオを登録する登録部として機能させることを特徴とする請求項１５に記載の保守管理プログラム。

【請求項17】

コンピュータを、
前記対象システムの障害発生を監視する障害監視部として機能させ、
前記保守実行部が、障害検知した前記障害監視部からの障害通知に関連付けられている前記保守シナリオに従って、前記共通要求部に対して前記複数の共通保守要求を実行させる
ことを特徴とする請求項１５又は１６に記載の保守管理プログラム。

【請求項18】

保守端末に接続される管理サーバと連携して、接続する複数の対象装置の保守情報を取得する保守管理プログラムであって、
コンピュータを、
前記管理サーバ上の保守種別毎の共通要求部から取得した、前記複数の対象装置の各々に対する共通保守要求を、前記複数の対象装置の各々が対応可能な形式に変換して、対応する前記複数の対象装置の各々に送信すると共に、前記複数の対象装置の各々からの応答結果を、前記共通要求部の形式に変換して、対応する前記共通要求部に送信する、保守種別毎の応答部として機能させることを特徴とする保守管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、保守管理システム、保守管理方法及び保守管理プログラムに関し、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続する様々な装置を、共通的なＷＥＢインタフェースで保守管理する保守管理システムに適用し得るものである。

【背景技術】

【0002】

例えば、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）装置、サーバ、ルータやスイッチ等のＩＰネットワーク機器、光伝送装置など様々な装置が、ＩＰネットワークに接続している。

【0003】

一般的に、装置の設定や装置状態の監視等の保守管理は、機種ごとの専用の機器インタフェースを使用しており、機種ごとの機器インタフェースを通じて、保守で得た情報を保守作業者に提示をしている。なお、ここでいう機器インタフェースは、保守作業に必要なインタフェースを意識しており、例えば、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、通信インタフェース等を含むものとする。

【0004】

しかし、機器インタフェースが装置の機種ごとに異なるため、保守作業者は機種ごとに異なる保守作業をする必要があり、保守作業者の負担が大きくなってしまう。したがって、複数機種の装置の保守管理を共通に行なえるようにすることが望まれている。

【0005】

従来、ＷＥＢによるＡＰＩで保守運用を提供する従来技術として、例えば特許文献１及び２等がある。

【0006】

特許文献１は、サーバが共通Ｗｅｂ ＡＰＩを端末装置に提供し、サーバが、端末装置から、現金処理機に関するオペレーションの要求を受け付け、その要求を現金処理機が受付可能なインタフェースに変換して、現金処理機に投入する。共通Ｗｅｂ ＡＰＩとは、現金処理機の機種の違いによるインタフェースの差分を吸収する役割を担う点で「共通」と定義している。

【0007】

特許文献２は、情報システムの保守業務において、情報システムの障害の原因分析の際に、原因箇所へのリードタイム短縮を図るため、Ｗｅｂシステムの履歴情報を可視化することにより保守業務を支援する保守業務支援システムが記載されている。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２０１８－１２８８３０号公報

【特許文献2】特開２０１１－１９２２３０号公報

【発明の概要】

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

【0009】

しかしながら、上述した特許文献１に記載されている技術は、保守対象を現金処理機に特定しているため、ＩＰネットワーク上の様々な装置のインタフェースを利用できないという課題がある。

【0010】

また、特許文献２の記載技術は、情報システムの障害に関する履歴情報を追記することに特化した保守運用のインタフェースであり、特許文献１と同様に、ＩＰネットワーク上の様々な装置のインタフェースとして利用できないという課題がある。

【0011】

本発明は、上述した課題を解決するために、ネットワーク上の様々な装置が一般的に保有している定型保守作業を統合的に保守運用することができる保守管理システム、保守管理方法及び保守管理プログラムが求められている。

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

【0012】

かかる課題を解決するために、第１の本発明に係る保守管理システムは、保守端末に接続される第１のサーバと、複数の対象装置に接続される第２のサーバとを備え、第１のサーバが、保守端末からの複数の対象装置の各々に対する共通保守要求を第２のサーバに送信すると共に、第２のサーバを通じて取得した、共通保守要求に対する複数の対象装置の各々の応答結果を、保守端末に送信する、保守種別毎の共通要求部を有し、第２のサーバが、保守種別毎の共通要求部からの共通保守要求を、複数の対象装置の各々が対応可能な形式に変換して、対応する複数の対象装置の各々に送信すると共に、複数の対象装置の各々からの応答結果を、共通要求部の形式に変換して、対応する共通要求部に送信する、保守種別毎の応答部を有することを特徴とする。

【0013】

第２の本発明に係る保守管理方法は、保守端末に接続される第１のサーバが、保守種別毎の共通要求部を有し、複数の対象装置に接続される第２のサーバが、保守種別毎の応答部を有し、共通要求部が、保守端末からの複数の対象装置の各々に対する共通保守要求を第２のサーバに送信し、対応する応答部が、保守種別毎の共通要求部からの共通保守要求を、複数の対象装置の各々が対応可能な形式に変換して、対応する複数の対象装置の各々に送信し、応答部が、複数の対象装置の各々からの応答結果を、共通要求部の形式に変換して、対応する共通要求部に送信し、共通要求部が、応答部から取得した、共通保守要求に対する複数の対象装置の各々の応答結果を、保守端末に送信することを特徴とする。

【0014】

第３の本発明は、複数の対象装置に接続される連携サーバと連携して、複数の対象装置の各々の保守情報を保守端末に与える管理サーバであって、保守端末からの複数の対象装置の各々に対する共通保守要求を連携サーバに送信すると共に、連携サーバを通じて取得した、共通保守要求に対する複数の対象装置の各々の応答結果を、保守端末に送信する、保守種別毎の共通要求部を有することを特徴とする。

【0015】

第４の本発明は、保守端末に接続される管理サーバと連携して、接続する複数の対象装置の保守情報を取得する連携サーバであって、管理サーバ上の保守種別毎の共通要求部から取得した、複数の対象装置の各々に対する共通保守要求を、複数の対象装置の各々が対応可能な形式に変換して、対応する複数の対象装置の各々に送信すると共に、複数の対象装置の各々からの応答結果を、共通要求部の形式に変換して、対応する共通要求部に送信する、保守種別毎の応答部を有することを特徴とする

【0016】

第５の本発明は、複数の対象装置に接続される連携サーバと連携して、複数の対象装置の各々の保守情報を保守端末に与える保守管理プログラムであって、コンピュータを、保守端末からの複数の対象装置の各々に対する共通保守要求を連携サーバに送信すると共に、連携サーバを通じて取得した、共通保守要求に対する複数の対象装置の各々の応答結果を、保守端末に送信する、保守種別毎の共通要求部として機能させることを特徴とする。

【0017】

第６の本発明は、保守端末に接続される管理サーバと連携して、接続する複数の対象装置の保守情報を取得する保守管理プログラムであって、コンピュータを、管理サーバ上の保守種別毎の共通要求部から取得した、複数の対象装置の各々に対する共通保守要求を、複数の対象装置の各々が対応可能な形式に変換して、対応する複数の対象装置の各々に送信すると共に、複数の対象装置の各々からの応答結果を、共通要求部の形式に変換して、対応する共通要求部に送信する、保守種別毎の応答部として機能させることを特徴とする。

【発明の効果】

【0018】

本発明によれば、ネットワーク上の様々な装置が一般的に保有している定型保守作業を統合的に保守運用することができる。

【図面の簡単な説明】

【0019】

【図1】実施形態に係る保守管理システムの全体構成を示す全体構成図である。

【図2】実施形態に係る定型保守作業用オープンＡＰＩの定義を説明する説明図である。

【図3】変形実施形態に係る保守管理システムの全体構成を示す全体構成図である。

【図4】第２の実施形態に係る保守管理システムの全体構成を示す全体構成図である。

【図5】第２の実施形態に係る保守シナリオの構成例を説明する説明図である。

【図6】第２の実施形態に係る保守シナリオの登録画面例を示す画面図である。

【発明を実施するための形態】

【0020】

（Ａ）第１の実施形態
以下では、本発明に係る保守管理システム、保守管理方法及び保守管理プログラムの第１の実施形態を、図面を参照しながら詳細に説明する。

【0021】

この実施形態では、例えばＨＴＴＰ若しくはＨＴＴＰＳ等の通信プロトコルで、ＩＰネットワーク上の様々な装置が一般的に保有する定型保守作業を、各装置から呼び出すＷｅｂ ＡＰＩ（アプリケーションプログラムインタフェース）を定義し、保守管理システムが、上述したＷｅｂ ＡＰＩを提供する。ここで、このＷｅｂ ＡＰＩを「定型保守作業用オープンＡＰＩ」と呼ぶ。

【0022】

保守管理システムが、定型保守作業用オープンＡＰＩを活用することにより、複数のシステムを構成する装置から保守作業に関する情報を呼び出すことができ、各装置を統合的に保守運用することが可能となる。

【0023】

（Ａ－１）第１の実施形態の構成
図１は、実施形態に係る保守管理システムの全体構成を示す全体構成図である。

【0024】

図１において、実施形態に係る保守管理システム１０は、保守端末１、管理サーバ２、連携サーバ３、装置４（４－１～４－Ｎ；Ｎは正の整数）、定型保守作業設定情報記憶部５を有する。図１に例示する保守管理システム１０は、ＩＰネットワークに接続可能なものである。

【0025】

装置４（４－１～４－Ｎ）は、保守制御対象となる装置であり、ＩＰネットワークに接続可能な装置である。装置４（４－１～４－Ｎ）は、例えば、ＶｏＩＰ装置、サーバ、ネットワーク機器、光伝送装置等の様々な種類の装置を適用できる。装置４－１～４－Ｎはそれぞれ、機種に応じた機器インタフェース４１を有しており、機器インタフェース４１は、例えば、ＳＳＨ（Ｓｅｃｕｒｅ Ｓｈｅｌｌ）やｔｅｌｎｅｔ等に代表されるように、機種に応じたコマンド等で動作する。

【0026】

保守端末１は、保守者により操作される端末であり、装置４（４－１～４－Ｎ）の設定や状態監視等の保守制御を行うものである。保守端末１は、例えば、パーソナルコンピュータ、スマートフォン、タブレット端末等の装置を適用でき、表示部、入力部、制御部、通信部等を有する端末装置である。

【0027】

例えば、保守端末１は、Ｗｅｂブラウザ機能で管理サーバ２との間で定型保守作業用オープンＡＰＩと1対１に対応するＷｅｂ情報を授受して、連携サーバ３が提供する定型保守作業用オープンＡＰＩを活用したり、又は事前にインストールした定型保守作業アプリケーションソフトウェア（「保守作業アプリ」とも呼ぶ。）を実施して、定型保守作業用オープンＡＰＩを活用したりする。管理サーバ２が保守端末１に対して提供する、定型保守作業用オープンＡＰＩと1対１に対応するＷｅｂ情報のＡＰＩを定型保守作業用オープンＧＵＩ－ＡＰＩと呼ぶ。つまり、保守端末１は、Ｗｅｂブラウザ又は保守作業アプリ等で、管理サーバ２が提供する定型保守作業用オープンＧＵＩ－ＡＰＩを利用できる。

【0028】

保守端末１は、管理サーバ２と接続して、定義保守作業用オープンＧＵＩ－ＡＰＩで定義された保守作業の画面を表示部に表示し、保守者により所望の保守作業が選択される。そして、保守端末１は、画面で選択された保守作業を示す保守識別情報（この実施形態では、一例として「ＡＰＩ番号」とする。）を含む要求を、定義保守作業用オープンＧＵＩ－ＡＰＩを介して管理サーバ２に送信する。また、保守端末１は、管理サーバ２から、要求した保守作業に関する各装置４－１～４－Ｎの保守情報を定義保守作業用オープンＧＵＩ－ＡＰＩを介して取得し、各装置４－１～４－Ｎの保守情報の画面を表示部に表示する。

【0029】

つまり、保守端末１は、表示部に表示されるコマンド画面で、管理サーバ２に対して複数の装置４の統合的な保守情報を要求したり、その要求した保守に関する各装置４の情報を取得して表示部に表示したりする。

【0030】

管理サーバ２は、例えばＨＴＴＰ又はＨＴＴＰＳ等で、連携サーバ３側のシステムを呼び出す側となるサーバである。つまり、管理サーバ２は、定型保守作業用オープンＡＰＩで定義されたＡＰＩ番号毎のクライアント２１～２３を実装する。なお、以下では、例えばＡＰＩ番号「１」のクライアントを、クライアント２１等のように表記して説明する。各クライアント２１～２３は、ＡＰＩ番号毎の保守作業を、保守端末１の表示部に表示する。

【0031】

連携サーバ３は、例えばＨＴＴＰ又はＨＴＴＰＳ等で、管理サーバ２から呼び出される側のサーバである。つまり、連携サーバ３は、ＡＰＩ番号毎のクライアントに対するＡＰＩ番号毎のサーバ３１～３３を実装する。なお、以下では、例えばＡＰＩ番号「１」のサーバをサーバ３１等のように表記して説明する。

【0032】

クライアント２１～２３とサーバ３１～３３とは、ＡＰＩ番号毎に対応付けられており、ＡＰＩ番号毎のクライアントとサーバがペアとなってデータの授受を行なう。すなわち、クライアント２１～２３とサーバ３１～３３とは、定型保守作業用オープンＡＰＩで定義された保守作業に特化したデータを送受信する。

【0033】

また、ＡＰＩ番号毎のサーバ３１～３３は、定型保守作業用オープンＡＰＩで定義した要求と、各装置４が依存する機器インタフェース４１に対する要求との間で相互に変換する相互変換部３５を有する。したがって、サーバ３１～３３は、対応するＡＰＩ番号毎のクライアント２１～２３から、ＡＰＩ番号に特化した保守作業用のインタフェースの要求を受け取ると、その要求を装置４毎に依存した機器インタフェース４１の要求に変換し、変換後の要求を、各装置４の機器インタフェース４１に送信する。

【0034】

相互変換部３５は、様々な構成を適用でき、例えば、定型保守作業用オープンＡＰＩで定義した要求（又は応答）と、各装置４が依存する機器インタフェース４１の要求（又は応答）とを、対応テーブルを参照して変換する。例えば、対応テーブルは、定型保守作業設定情報記憶部５に記憶されているものとする。なお、対応テーブルを別途独自に備えてもよい。

【0035】

ここで、ＡＰＩ番号毎のクライアント２１～２３と対応するサーバ３１～３３とは、例えばＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）を実装しており、ＲＥＳＴを用いてデータの送受信を行なう。

【0036】

また、この実施形態では、ＨＴＴＰ又はＨＴＴＰＳの通信プロトコルで、クライアント２１～２３とサーバ３１～３３とがデータ送受信を行なう場合を例示するが、ＩＰネットワーク上でデータ送受信が可能であれば、これらに限定されない。

【0037】

図２は、実施形態に係る定型保守作業用オープンＡＰＩの定義を説明する説明図である。

【0038】

図２において、定型保守作業用オープンＡＰＩは、一般的に装置４を保守運用するために必要な共通のインタフェースであり、ここでは、保守作業名称の一例として、コマンド投入、アラーム受信、ファイル転送等とする場合を例示している。「ＩＮ」と「ＯＵＴ」は、ＡＰＩ番号毎（又は保守作業毎）に、共通的なインタフェースのパラメータを定義する。

【0039】

定型保守作業用オープンＡＰＩは、「ＡＰＩ番号」、保守作業の名称を示す「名称」、保守作業の概要を示す「概要」、入力（受信）されたデータ種類を示す「ＩＮ」、出力（送信）するデータ種類を示す「ＯＵＴ」を項目として有する。なお、項目はこれらに限定されず、他の項目を追加してもよい。

【0040】

定型保守作業用オープンＡＰＩは、ＩＰネットワーク上の装置４で利用可能にするために、例えばＨＴＴＰ若しくはＨＴＴＰＳ等の通信プロトコルで利用する。また、呼び出し側であるクライアント２１～２３と、呼び出される側であるサーバ３１～３３とが容易に実装できるようにするため、定型保守作業用オープンＡＰＩは、ＲＥＳＴに準拠するものとする。すなわち、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）等のデータフォーマットで作成される。

【0041】

「ＡＰＩ番号：１」は、「名称：コマンド投入」の保守作業が定義されている。「名称：コマンド投入」の保守作業の概要は、「概要：指定のコマンドを実行し、応答を返却する」と定義されており、「ＩＮ」には「コマンド投入先、コマンド文字列」が定義され、「ＯＵＴ」には「コマンド応答文字列」の形式が定義されている。

【0042】

例えば、管理サーバ２において、ＡＰＩ番号「１」のクライアント２１が、連携サーバ３のＡＰＩ番号「１」のサーバ３１に対して、コマンド投入先とコマンド文字列を送信する。コマンド投入先は、各装置４における特定のポート番号等とすることができる。この場合、サーバ３１は、コマンド投入先の装置４の機器インタフェース４１が対応可能なコマンドに変換し、サーバ３１は、変換後のコマンドを機器インタフェース４１に送信する。サーバ３１は、装置４の機器インタフェース４１からコマンド応答を受信すると、そのコマンド応答を定型保守作業用オープンＡＰＩで定義したコマンド応答文字列の形式に変換する。そして、サーバ３１は、定型保守作業用オープンＡＰＩで定義したコマンド応答文字列の形式に変換したコマンド応答文字列を、クライアント２１に返信する。従って、１又は複数の装置４の機器インタフェース４１に対して、保守に係るコマンドを投入して、各装置４の設定や状態等の保守情報を呼び出すことができる。

【0043】

「ＡＰＩ番号：２」は、「名称：アラーム受信」の保守作業が定義されている。「名称：アラーム受信」の保守作業の概要は、「概要：指定の時刻でアラームジャーナルを検索し、該当のアラームを受信しているかどうかを返却する」と定義されており、「ＩＮ」には「検索開始時刻、検索終了時刻、発生装置、ＴｒａｐＩＤ、検索文字列」等が定義され、「ＯＵＴ」には「該当メッセージ情報のリスト」等が定義されている。

【0044】

例えば、管理サーバ２のＡＰＩ番号「２」のクライアント２２が、連携サーバ３のＡＰＩ番号「２」のサーバ３２に対して、検索開始時刻、検索終了時刻、発生装置、ＴｒａｐＩＤ、検索文字列を含むデータを送信する。サーバ３２は、対象とする装置４の機器インタフェース４１が対応可能な要求に変換して、検索開始時刻、検索終了時刻、発生装置、ＴｒａｐＩＤ、検索文字列を含むデータを、装置４の機器インタフェース４１に送信する。装置４は、検索開始時刻から検索終了時刻までのＴｒａｐＩＤのメッセージ情報のリストをサーバ３２に送信する。サーバ３２は、受信したメッセージ情報のリストをクライアント２２に出力する。これにより、例えば、１又は複数の装置４のうち、障害が発生した装置がある場合には、その装置４から障害メッセージ等を受信することができる。

【0045】

「ＡＰＩ番号：３」は、「名称：ファイル転送」の保守作業が定義されている。「名称：ファイル転送」の保守作業の概要は、「概要：指定のファイルを、指定のフォルダへ転送する」と定義されており、「ＩＮ」には「転送元ファイル、転送先ディレクトリ」が定義され、「ＯＵＴ」には「ＯＫ又はＮＧ」が定義されている。

【0046】

例えば、管理サーバ２のＡＰＩ番号「３」のクライアント２３が、連携サーバ３のＡＰＩ番号「３」のサーバ３３に対して、転送先ファイル、転送先ディレクトリを含むデータを送信する。サーバ３３は、対象とする装置４の機器インタフェース４１が対応可能な要求に変換して、転送先ファイルと、転送先ディレクトリを装置４の機器インタフェース４１に送信する。そして、装置４は、指定ファイルを指定フォルダへ転送し、そのファイル転送結果としてＯＫ又はＮＧをサーバ３３に応答する。サーバ３３は、装置４からのファイル転送結果ＯＫ又はＮＧを、クライアント２３に応答する。

【0047】

定型保守作業設定情報記憶部５は、定型保守作業用オープンＡＰＩで定義したコマンドと、各装置４の機器インタフェース４１が依存しているコマンドとを相互変換できる設定情報を記憶するものである。

【0048】

図１では、一例として、ある保守作業の要求又は応答で使用する定型保守作業用オープンＡＰＩのコマンドと、装置４が使用するコマンドとを対応付けている場合を例示している。例えば、ある保守作業について、図１の装置（装置Ａ）４－１が、「ｃｍｄ_ａａ_１」、「ｃｍｄ_ａａ_２」、「ｃｍｄ_ｂｂ_１」…等のコマンドを使用するものとする。その場合、「ｃｍｄ_ａａ_１」、「ｃｍｄ_ａａ_２」、「ｃｍｄ_ｂｂ_１」…等を、装置（装置Ａ）４－１が使用する「Ａコマンド」に設定している。

【0049】

なお、定型保守作業設定情報記憶部５の構成は、定型保守作業用オープンＡＰＩのコマンドと、各装置４のコマンドとを相互変換可能とする構成であればよく、図１の例に限定されない。

【0050】

（Ａ－２）第１の実施形態の動作
次に、実施形態に係る保守管理システム１０における処理動作を説明する。

【0051】

管理サーバ２は、ＡＰＩ番号毎の保守作業を保守端末１の表示画面に表示し、保守者は、保守端末１の表示画面上で、ＡＰＩ番号毎のクライアント２１～２３を起動させる。

【0052】

例えば、保守端末１には、定型保守作業用オープンＡＰＩの保守種別毎に対応する定型保守作業用オープンＧＵＩ－ＡＰＩに関する画面（例えば、Ｗｅｂ画面）が表示され、保守端末１の画面には、ＡＰＩ番号毎の保守作業が表示されている。保守端末１に表示される画面構成は、特に限定されない。例えば、画面には、ＡＰＩ番号及び又は保守作業の名称が表示されて、保守者がＡＰＩ番号又は保守作業の名称を選択することができるものとしてよい。いずれにしても、保守端末１の画面は、保守者が希望するＡＰＩ番号又は保守作業を選択できる。そして、保守者が保守端末１の画面上で選択することで、管理サーバ２において、対応するＡＰＩ番号毎のクライアント２１～２３が起動する。

【0053】

このとき、保守者は、保守端末１の画面上で、複数の装置４のうち、対象とする装置４の選択や、装置４に要求するデータ内容を入力するようにしてもよい。例えば、全ての装置４－１～４－Ｎを対象としてもよいし、一部の装置４を対象とすることもでき、後者の場合対象とする装置４を選択できるようにしてもよい。

【0054】

また、例えば保守者が「ＡＰＩ番号：１」の「名称：コマンド投入」を希望するとき、保守者は、コマンド投入先（例えば、対象とする装置４の識別情報、装置４の機器インタフェース４１のポート番号など）と、命令するコマンドのコマンド文字列とを画面上に入力できるようにしてもよい。また例えば、「ＡＰＩ番号：２」の場合であれば、検索開始時刻、検索終了時刻、ＴｒａｄＩＤ、検索文字列等を保守者は画面上に入力でき、「ＡＰＩ番号：３」であれば、転送元ファイル、転送先ディレクトリ等を保守者が画面上に入力できるようにしてもよい。

【0055】

起動したＡＰＩ番号毎のクライアント２１～２３は、ＲＥＳＴを通じて、連携サーバ３上の、対応するＡＰＩ番号毎のサーバ３１～３３を起動要求する。例えば、ＡＰＩ番号「１」のクライアント２１は、ＲＥＳＴを通じて、ＡＰＩ番号「１」のサーバ３１を起動するように要求する。

【0056】

連携サーバ３上で、起動したＡＰＩ番号毎のサーバ３１～３３は、対応するクライアント２１～２３から、定型保守作業用オープンＡＰＩで定義した要求を受信する。例えば、ＡＰＩ番号「１」のサーバ３１は、対応するＡＰＩ番号「１」のクライアント２１からの要求を受信する。

【0057】

そして、ＡＰＩ番号毎のサーバ３１～３３では、相互変換部３５が、定型保守作業用オープンＡＰＩの「ＩＮ」で定義された要求を、装置４が依存している要求に変換し、その変換後の要求を、対応する装置４の機器インタフェース４１に送信する。

【0058】

例えば、装置４の機器インタフェース４１がＳＳＨに依存するものであれば、相互変換部３５は、定型保守作業設定情報記憶部５を参照して、定型保守作業用オープンＡＰＩで定義した要求コマンドをＳＳＨのコマンドに変換して、対応する装置４の機器インタフェース４１に送信する。定型保守作業設定情報記憶部５は、対象とする装置４が依存するプロトコル（コマンド形式）への変換ができるように設定されている。つまり、機種ごとのプロトコル（コマンド形式）への変換が可能である。

【0059】

装置４は、ＡＰＩ番号毎のサーバ３１～３３のいずれかからの要求に対する結果を、対応するＡＰＩ番号毎のサーバ３１～３３に返信する。例えば、装置４の機器インタフェース４１は、依存しているコマンド形式で結果を、対応するサーバ３１～３３に送信する。

【0060】

装置４から結果を受けたＡＰＩ番号毎のサーバ３１～３３は、相互変換部３５が、装置４からの結果を、定型保守作業用オープンＡＰＩの「ＯＵＴ」で定義した応答形式に変換して、ＲＥＳＴを通じて、対応するクライアント２１～２３に返信する。例えば、相互変換部３５は、装置４からの結果を、定型保守作業用オープンＡＰＩで定義されたコマンド応答文字列の形式に変換して、対応するクライアント２１～２３に返信する。

【0061】

クライアント２１～２３は、対応するサーバ３１～３３から受け取った結果を、保守端末１の画面に出力する。

【0062】

保守者は、保守端末１の画面に表示されるＡＰＩ番号毎の結果を確認することで、要求した保守作業の結果を確認することができる。装置４が異なる機種であっても、各装置４の結果をＡＰＩ番号毎に呼び出して画面上に表示できる。

【0063】

（Ａ－３）第１の実施形態の効果
以上のように、第１の実施形態によれば、保守管理システムが、定型保守作業用オープンＡＰＩを活用することにより、ネットワーク上に存在する複数の装置を統合的に保守運用することができる。

【0064】

（Ｂ）第２の実施形態
次に、本発明に係る保守管理システム、保守管理方法及び保守管理プログラムの第２の実施形態を、図面を参照しながら詳細に説明する。

【0065】

（Ｂ－１）基本概念
第２の実施形態の保守管理システムの解決課題と、その課題を解決する手段の技術的な基本概念とを説明する。

【0066】

従来、定型保守作業が複数ある場合、保守者は全ての定型保守作業を行なう必要があり、作業量に応じて時間がかかるという課題（ここでは、「第１の課題」と呼ぶ。）がある。例えば、１つのシステムが複数の装置を使用しており、装置１台ずつに複数の定型保守作業が必要である場合を考える。この場合、従来、保守者は、装置毎に複数の定型保守作業を行ない、全ての装置の定型保守作業を行なっている。そうすると、保守者の作業負担が大きく、作業時間がかかってしまう。

【0067】

また、昼夜を問わず、装置には何かしらの問題が発生する恐れがある。そのため、障害が発生したときには、保守者は障害を特定するための保守作業を実施する必要があり、作業負担が大きいという課題（ここでは、「第２の課題」と呼ぶ。）もある。

【0068】

第２の実施形態は、上述したような課題に鑑み、複数の定型保守作業の実施を保守シナリオとして定義し、シナリオ単位で定型保守作業を実施できるようにすることで第１の課題を解決しようとする。また、第２の実施形態は、障害発生を監視して、障害発生時に、障害に応じた定型保守作業を実施できるようにすることで第２の課題を解決しようとする。

【0069】

（Ｂ－２）第２の実施形態の構成
第２の実施形態の保守管理システム１０Ｂの全体構成は、基本的には、第１の実施形態の保守管理システム１０のそれと同じであるが、第２の実施形態の管理サーバ２の機能が、第１の実施形態の管理サーバ２のそれと異なるので、第２の実施形態の特徴的な機能を中心に詳細に説明する。

【0070】

図４は、第２の実施形態に係る保守管理システムの全体構成を示す全体構成図である。

【0071】

図４において、第２の実施形態に係る保守管理システム１０Ｂは、保守端末１、管理サーバ２、連携サーバ３、保守対象とする装置４、定型保守作業設定情報記憶部５を有する。

【0072】

連携サーバ３側は、システム単位毎にシステム名を持ち、定型保守作業用オープンＡＰＩのＡＰＩ番号毎に呼び出されるサーバ３ｍ（Ｍは、ＡＰＩ番号を示す数字であり、１＜ｍ＜Ｍ）を実装する。

【0073】

例えば、図４において、装置Ａ、装置Ｂ、…、装置Ｎを用いて動作する「システムＡ」というシステム名（システム識別情報）のシステムがあるとする。連携サーバ３－１は、「システムＡ」で用いられる装置Ａ、装置Ｂ、…、装置Ｎの保守作業を実施するサーバである。連携サーバ３－１は、定型保守作業用オープンＡＰＩのＡＰＩ番号毎に呼び出されるサーバ３ｍを有する。

【0074】

ＡＰＩ番号毎のサーバ３ｍは、第１の実施形態と同様に、ＡＰＩ番号に特化した保守作業用のインターフェースの要求をクライアント２ｍから受け取り、その要求を、装置４毎に依存したインタフェースの要求に変換する処理を行なう。サーバ３ｍ及びクライアント２ｍは、第１の実施形態と同様にＲＥＳＴを実装する。なお、サーバ３ｍ及びクライアント２ｍの処理は、基本的には、第１の実施形態の処理と同様であり、重複説明となるため詳細な説明を省略する。

【0075】

なお、連携サーバ３－２及び３－Ｘは、連携サーバ３－１と同様に、連携サーバ３－２はシステムＢが用いる１又は複数の装置４の保守作業を行ない、又連携サーバ３－Ｘ（Ｘは整数）はシステムＸが用いる１又は複数の装置４の保守作業を行なうものである。また、システムＡ～Ｘが、使用する装置４の種類や台数、装置４の組み合わせ等については、システム毎に異なってもよい。したがって、連携サーバ３（３－１～３－Ｘ）は、対応するシステムＡ～Ｘで用いられる装置４の種類や台数や組み合せ等に応じたサーバ３１～３ｎを実装する。

【0076】

図４において、管理サーバ２は、ＡＰＩ番号毎のクライアント２１～２Ｍ、トラップ監視部２０１、保守シナリオ登録・実行部２０２，定型保守作業実行部２０３、保守シナリオ記憶部２０４を有する。

【0077】

トラップ監視部２０１は、装置４を用いて動作しているシステムＡ、Ｂ又はＸで、何かしらの障害が発生し、その発生した障害に関する情報を取得する。例えば、トラップ監視部２０１は、ＳＮＭＰ－Ｔｒａｐ監視を適用できる。ここで、障害は、例えば、音声やデータ等のセッション制御のような高信頼性のある処理を行なうサーバの故障・再起動や、サーバや光伝送装置等のハードウェアの故障、インターネット回線や電話回線にアクセスが集中して生じた輻輳等を例示できる。勿論、障害はこれに限らず、ネットワーク装置としての装置４に生じ得る障害が考えられる。

【0078】

例えば、トラップ監視部２０１は、システムＡ等の各システムで運用している管理システムや障害検知システム等から、システム毎の障害情報を取得可能であり、各システムで生じた障害に関する情報を監視する。また別の方法として、トラップ監視部２０１は、ＣＤＲ等の呼の詳細レコード情報をシステム毎に収集し、収集データを用いて独自で機械学習を行ない、異常と判断できるときに障害が発生したと判断できるようにしてもよい。つまり、トラップ監視部２０１は、各システムの管理システムのように外部システムから障害情報を取得してもよいし、独自の機械学習等の処理により異常（すなわち通常と異なる状態）を判定して障害又はその前兆を監視するようにしてもよい。

【0079】

トラップ監視部２０１は、監視対象とするシステムから監視対象の状態を示す情報を受信すると、事前設定された監視条件に一致するか否かを判断して、一致する項目を示すアラーム契機ＩＤ（例えばＳＮＭＰ-ＴｒａｐのＯＩＤ（オブジェクトＩＤ））を含むアラートを保守シナリオ登録・実行部２０２に与える。これは、トラップ監視部２０１が、あるシステムで障害が発生した情報を取得・検知したときに、監視契機ＩＤが対応付けられた保守シナリオを、保守シナリオ登録・実行部２０２側で読み出せるようにするためである。これにより、障害発生したシステムの保守シナリオ（すなわち監視契機ＩＤが対応付けられた保守シナリオ）に従って、当該障害発生したシステムの各装置４に対して、定型保守作業を自動的に実行できる。

【0080】

保守シナリオ登録・実行部２０２は、複数の定型保守作業を有して、これら複数の定型保守作業を行なわせるための保守シナリオをシステム毎に登録する登録部２２１と、システム毎の保守シナリオを実行する実行部２２２とを有する。つまり、保守シナリオ登録・実行部２０２は、システムが用いている１又は複数の装置４に対して実行する、定型保守作業の種類や作業順番を決めた保守シナリオを登録し、各システムの保守シナリオをシステム毎に実行する。

【0081】

保守シナリオ記憶部２０４は、各システムの保守シナリオを記憶する。保守シナリオ記憶部２０４が記憶する保守シナリオの構成については後述するが、保守シナリオ記憶部２０４は、シナリオ毎に、シナリオコンフィグと定型保守作業コンフィグとを有する保守シナリオを記憶している。シナリオコンフィグは、この保守シナリオを適用するシステムのシステム名や、実行する定型保守作業や、いつ実行するか等のシナリオの設定情報である。定型保守作業コンフィグは、シナリオコンフィグで設定されている定型保守作業に関する詳細な設定情報である。このような保守シナリオの構成は、動作の項で詳細に説明する。

【0082】

定型保守作業実行部２０３は、保守シナリオ記憶部２０４を参照して、各システムの保守シナリオに従って、定型保守作業用オープンＡＰＩで定義されたＡＰＩ番号のクライアント２１～２Ｍに対して、ＡＰＩ番号毎の保守作業の実行指示を行なう。定型保守作業実行部２０３が、クライアント２１～２Ｍに保守作業の実行指示をすることで、各システムの連携サーバ３のサーバ３１～３Ｍに、定型保守作業用オープンＡＰＩで保守作業を要求でき、対応する装置４の保守作業を自動的に行なえる。

【0083】

（Ｂ－３）第２の実施形態の動作
次に、第２の実施形態に係る保守管理システム１０Ｂにおける処理動作を、図面を参照しながら説明する。

【0084】

（Ｂ－３－１）全体的な処理
まず、保守管理システム１０Ｂにおける定型保守作業の実行に関する全体的な処理の流れを説明する。

【0085】

保守端末１は、保守者の入力指示によって、保守シナリオを登録するために、保守シナリオ画面１２を管理サーバ２の保守シナリオ登録・実行部２０２に要求する。

【0086】

保守シナリオ登録・実行部２０２は、登録部２２１と実行部２２２を有する。登録部２２１は、保守端末１に、保守シナリオを登録させるために保守シナリオ画面１２を提供する。登録部２２１は、保守端末１に提供した保守シナリオ画面１２を通じて、作成された保守シナリオを取得する。そして、登録部２２１は、この保守シナリオを保守シナリオ記憶部２０４に登録する。

【0087】

保守シナリオには、後述するように、複数の定型保守作業が定義（設定）されている。また、シナリオ毎の保守シナリオには、保守シナリオを実行する条件として、手動実行、アラーム契機自動実行、予約自動実行のいずれかが設定されている。

【0088】

手動実行が設定されているときには、保守者の操作により保守端末が実行部２２２を起動させ、実行部２２２が保守シナリオを読み出して、その保守シナリオに応じた定型保守作業実行部２０３を実行部２２２は起動させる。

【0089】

アラーム契機自動実行が設定されているとき、トラップ監視部２０１がアラームを検知して実行部２２２を起動させ、実行部２２２がトラップ監視部２０１からのアラームに含まれるアラーム契機ＩＤに対応する保守シナリオを読み出し、その保守シナリオに応じた定型保守作業実行部２０３を実行部２２２は起動させる。

【0090】

予約自動実行が設定されているときには、同時に開始年月日（時刻を含んでもよい）が設定されている。保守シナリオ記憶部２０４の保守シナリオの実行開始時刻になると、その保守シナリオを実行部２２２は読み出して、その保守シナリオに応じた定型保守作業実行部２０３を実行部２２２は起動させる。

【0091】

さらに、実行部２２２によって起動された定型保守作業実行部２０３は、クライアント２ｍ（２１～２Ｍ）を起動する。

【0092】

ここで、システム毎の保守シナリオには、後述するように複数の定型保守作業が定義（設定）されている。さらに、保守シナリオには、それぞれの定型保守作業のＡＰＩ番号と、対象装置とする装置４のホスト名も設定されている。

【0093】

定型保守作業実行部２０３は、保守シナリオに定義されている複数の定型保守作業を順番に読み出す。そして、今回実行する定型保守作業のＡＰＩ番号に対応するクライアント２ｍを、定型保守作業実行部２０３は起動させる。ＡＰＩ番号に対応するクライアント２ｍの起動は、保守シナリオに設定されている定型保守作業のＡＰＩ番号に従って順番に行われる。

【0094】

クライアント２ｍは、ＲＥＳＴを通じて、連携サーバ３－１～３－Ｘにおける対応するサーバ３ｍに起動を要求する。クライアント２ｍによりサーバ３ｍは起動する。サーバ３ｍは、起動時に受け取った定型保守作業用オープンＡＰＩで定義された要求を、装置依存した保守作業用インタフェースに変換し、変換した要求を装置４に送信する。

【0095】

装置４から返却される要求の結果をサーバ３ｍは受け取り、その結果を定型保守作業用オープンＡＰＩの「ＯＵＴ」に変換する。サーバ３ｍは、変換した結果を、クライアント２ｍにＲＥＳＴで返却する。

【0096】

管理サーバ２では、サーバ３ｍから受け取る保守結果を、クライアント２ｍが保守端末１に送信して、保守端末１は画面上に結果を出力する。保守者は、保守端末１の画面上で、結果を確認できる。これにより、保守者は、要求した保守シナリオの結果を確認することができる。

【0097】

なお、ここでは、保守端末１が、リアルタイムに保守結果を画面表示する場合を例示したが、保守シナリオ登録・実行部２０２は、保守結果を、保守シナリオに対応付けて保守シナリオ記憶部２０４に保存することも可能である。したがって、リアルタイムに表示する場合に限らず、後日保守結果を検索することもできる。

【0098】

ここで、システム毎の保守シナリオにアラーム契機自動実行が設定されている場合の動作を説明する。システム障害が発生したときに、そのシステムに対して、保守シナリオに従った定型保守作業を実行させる。障害発生時の処理である。

【0099】

ここで、アラーム契機自動実行は、トラップ監視部２０１がシステム障害を検出したときに、障害に応じた保守シナリオ（アラーム契機ＩＤが対応付けられた保守シナリオ）に定義された定型保守作業を、障害発生したシステムに対して実行する動作モードである。

【0100】

保守シナリオにおいてアラーム契機自動実行が設定されているとき、アラーム契機ＩＤも同時に設定される。アラーム契機ＩＤは、例えばＳＮＭＰ－Ｔｒａｐ監視のＯＩＤ（オブジェクトＩＤ）等のように障害（監視）に関する項目を特定する識別情報を適用できる。そして、トラップ監視部２０１からのアラームに含まれるアラーム契機ＩＤが設定された保守シナリオを実行部２２２が読み出して、そのアラーム契機ＩＤが設定された保守シナリオに応じた定型保守作業実行部２０３を実行部２２２は起動させる。

【0101】

このように、システムでセッション制御や回線輻輳等の障害が発生したときには、原因特定のために、当該システムの各装置４に保守作業を行なう必要がある。また障害は昼夜問わず発生する可能性があり、人材不足が叫ばれる昨今においてもこれまでと同様に保守を行なうことが要求される。このような背景に鑑みても、この実施形態によれば、効率的な監視や保守作業の効率的な実行が可能となる。

【0102】

（Ｂ－３－２）保守シナリオの登録
次に、システム毎の保守シナリオの作成及び登録の動作を説明する。

【0103】

図５は、第２の実施形態に係る保守シナリオの構成例を説明する説明図である。図６は、第２の実施形態に係る保守シナリオの登録画面例を示す画面図である。

【0104】

図５に例示するように、保守シナリオは、シナリオコンフィグと、定型保守作業コンフィグとを有する。保守者が、保守端末１の表示部に表示される図６の保守シナリオ登録画面を通じて、システム毎の保守シナリオを作成することができる。

【0105】

シナリオコンフィグは、保守シナリオの設定情報である。図５に例示するように、シナリオコンフィグは、「シナリオ名」、「システム名」、「定型保守作業情報」、「対象装置」、「実行開始時刻」、「実行終了時刻」、「実行結果」を項目として有する。このように、シナリオコンフィグは、この保守シナリオを、どのシステムに、どの定型保守作業をどの装置４に実行するか等の設定情報が定義されている。また、シナリオコンフィグは、装置４に対して実行した保守結果も保持する。この保守結果は、いつ実行した保守結果であるかを特定するため、システム名、装置、実行開始時刻及び実行終了時刻、実行した定型保守作業の番号等に対応付けるようにする。なお、シナリオコンフィグの項目は、図５に例示するものに限定されない。

【0106】

「シナリオ名」は、保守シナリオの登録・変更・複製時に画面で設定した値である。つまり、シナリオ名は、保守シナリオを特定するための識別情報ともいえる。

【0107】

「システム名」は、保守シナリオの登録・変更・複製時に画面で選択した監視システムの名称である。つまり、「システム名」は、保守システムを適用するシステムの名称である。システム名（システムの名称）に限らず、システムを特定できるのであれば、システムの番号、ＩＤ等のようなシステム識別情報としてもよい。

【0108】

「定型保守作業情報」は、保守シナリオに組み込まれる定型保守作業に関する情報である。「定型保守作業情報」は、保守シナリオの登録・変更・複製時に画面で設定した定型保守作業数分だけ配列される。「定型保守作業情報」は、設定する複数の定型保守作業のそれぞれのＡＰＩ番号を含む「定型保守作業番号リスト」を有する。この「定型保守作業番号リスト」については、定型保守作業コンフィグの説明のときに詳細に説明する。

【0109】

「対象装置」は、この保守シナリオ実行対象装置のホスト名である。

【0110】

「実行開始時刻」は、この保守シナリオを実行開始した実行開始時刻であり、「実行終了時刻」は、この保守シナリオを実行終了した実行終了時刻である。「実行結果」は、保守シナリオに従って実行した保守結果である。実行結果は、定型保守作業毎に、各装置の保守結果とする。

【0111】

次に、図５に例示する定型保守作業コンフィグを説明する。定型保守作業コンフィグは、保守シナリオのシナリオコンフィグで設定されている定型保守作業に関する詳細な設定情報である。図５に例示するように、定型保守作業コンフィグは、「作業番号」、「ＡＰＩ番号」、「実行処理」を項目に有する。このように、定型保守作業コンフィグは、装置４に実行する定型保守作業のＡＰＩ番号と、保守作業で装置４側（サーバ３ｍ側）に要求するコマンド、データ、情報等を設定する。定型保守作業が複数ある場合、定型保守作業毎に、定型保守作業コンフィグが作成・登録される。

【0112】

「作業番号」は、定型保守作業毎に事前に設定した番号である。「作業番号」は、定型保守作業用オープンＡＰＩで定義されたＡＰＩ番号とは異なり、定型保守作業番号を特定するために設定された番号である。

【0113】

「ＡＰＩ番号」は、定型保守作業用オープンＡＰＩで定義された番号である。例えば、「ＡＰＩ番号：１」は「コマンド投入（単発）」、「ＡＰＩ番号：２」は「アラーム受信」、「ＡＰＩ番号：３」は「ファイル転送」とする。

【0114】

「実行処理」は、定型保守作業用オープンＡＰＩで要求する情報である。

【0115】

例えば、「ＡＰＩ番号：１」で、装置４（サーバ３ｍ）側にコマンドを投入するときには、そのコマンドの文字列を事前に設定する。この他に、コマンドの投入先を設定するようにしてもよい。このコマンドの文字列の設定は、登録画面を通じて保守者により設定可能である。

【0116】

また例えば「ＡＰＩ番号：２」で、装置４（サーバ３ｍ）側に、特定のアラームを受信したか否かを確認するときには、そのアラームを特定するＩＤを設定する。この他に、アラームの検索開始時刻、検索終了時刻、発生装置、検索文字列等を設定するようにしてもよい。

【0117】

さらに例えば、「ＡＰＩ番号：３」で、装置４（サーバ３ｍ）側に、ファイル転送するときには、転送先ディレクトリをフルパスで指定する。この他に、転送元ファイルを設定するようにしてもよい。

【0118】

上述したように、保守シナリオは、シナリオコンフィグと定型保守作業コンフィグとを有しており、保守シナリオは、保守端末１に提供される図６の保守シナリオ登録画面を通じて設定される。

【0119】

図６に例示するように、保守シナリオの登録画面５００は、シナリオ名入力部５０１、システム名入力部５０２、定型保守作業設定部５０３、シナリオ実行条件設定部５０４、対象装置入力部５０５、定型保守作業設定一覧表示部５０６、登録ボタン５０７、キャンセルボタン５０８、変更ボタン５４０を有する。なお、登録画面５００は図６に限定されず、また登録画面５００に表示させる入力部は図６のものに限定されない。

【0120】

シナリオ名入力部５０１及びシステム名入力部５０２は、例えば、テキスト入力で、シナリオ名及びシステム名を入力できる。

【0121】

定型保守作業設定部５０３は、保守シナリオに定義付ける定型保守作業を設定する部分である。例えば、図６の例では、プルダウンで選択可能な定型保守作業がリスト５１０で表示され、そのリスト５１０から定型保守作業を選択する。なお、定型保守作業を選択・設定が可能であれば、定型保守作業設定部５０３はプルダウンに限定されない。

【0122】

定型保守作業設定部５０３で定型保守作業が設定されると（例えば「追加」ボタンが選択されることで、そのとき選んだ定型保守作業を設定できる。）、当該定型保守作業の名称（すなわち、定型保守作業名）及び作業番号が読み出されて、後述する定型保守作業設定一覧表示部５０６に表示される。

【0123】

定型保守作業設定部５０３は、リスト５１０で定型保守作業を１個ずつ順番に設定していくことで、複数の定型保守作業を設定できる。つまり、複数の定型保守作業からなる保守シナリオを登録することができる。

【0124】

なお、複数の定型保守作業を設定したとき、その設定した順が、定型保守作業の実行する順となる。保守シナリオの定型保守作業を順番に実行する際、その順番に何かしらの問題があるときには、定型保守作業設定部５０３のリスト５１０で定型保守作業の設定順を変更することで、実行順を修正（変更）することもできる。

【0125】

シナリオ実行条件設定部５０４は、当該保守シナリオを実行する条件を設定できる。シナリオ実行条件設定部５０４は、手動実行、アラーム契機自動実行、予約自動実行のいずれかを設定できる。

【0126】

シナリオ実行条件設定部５０４で、アラーム契機自動実行を設定するときには、アラーム契機ＩＤも設定する。これにより、トラップ監視部２０１からアラームが検知されたときに、アラーム契機ＩＤが設定されている保守シナリオを読み出せるようにすることができる。なお、トラップ監視部２０１は、監視対象の状態を示す情報を受信して、事前設定された監視条件と一致する項目（アラーム契機ＩＤ）を入れたアラームを検知し保守シナリオ登録実行部２０２を起動するが、複数の項目で一致するときには、シナリオ実行部２０２へ複数の保守シナリオの実行を指示する。１つのシステムに対する保守シナリオは１種類だけではなく、複数のアラーム契機ＩＤの各々に応じた複数種類の保守シナリオを登録することができる。

【0127】

対象装置入力部５０５は、指定した定型保守作業を行なう対象装置を入力する。対象装置入力部５０５は、テキスト入力で、装置４のホスト名を入力する。また、別の方法として、システムに存在する各装置４と、各装置４のホスト名とを対応付けたデータベースと連携可能であるなら、対象装置入力部５０５は、そのデータベースと連携して、システム毎の装置４を選択できるようにしてもよい。

【0128】

定型保守作業設定一覧表示部５０６は、指定した定型保守作業の一覧情報を表示する部分である。図６では、例えば、定型保守作業の作業番号を示す「Ｎｏ」、「定型保守作業名」、実行開始時刻を示す「開始時刻」、実行終了時刻を示す「終了時刻」、その他の設定情報を参照可能とするための「詳細情報参照」等を項目とする。なお、定型保守作業設定一覧表示部５０６に表示させる項目は、これに限定されない。

【0129】

定型保守作業設定一覧表示部５０６は、定型保守作業設定部５０３で選択した定型保守作業の作業番号及び定型保守作業名が表示される。定型保守作業設定部５０３で複数の定型保守作業が選択されたときには、複数の定型保守作業が定型保守作業設定一覧表示部５０６に表示される。また、表示される順番は、定型保守作業設定部５０３で選択した順である。

【0130】

つまり、システム毎の保守シナリオを実行するとき、定型保守作業設定部５０３で選択された順で、定型保守作業を順番に定型保守作業実行部２０３が実行することになる。

【0131】

また、定型保守作業設定一覧表示部５０６において、項目「詳細情報参照」には、定型保守作業毎に「参照」ボタンがある。定型保守作業毎の「参照」を保守者が選択すると、定型保守作業の詳細な設定情報を設定する画面５２０が表示される。この画面５２０上で、定型保守作業コンフィグの「ＡＰＩ番号」、「実行処理」に関する情報を設定することができる。

【0132】

登録ボタン５０７が保守者に選択されると、入力された保守シナリオが登録される。変更ボタン５４０が保守者に選択されると、変更された保守シナリオが変更登録される。キャンセルボタン５０８が選択されると、保守シナリオが削除される。

【0133】

（Ｂ－４）第２の実施形態の効果
以上のように、第２の実施形態によれば、定型保守作業用オープンＡＰＩの自動実行方式により、複数の保守定型作業を一度に実行することで保守者の負担を減らすことができる。

【0134】

また、第２の実施形態によれば、保守シナリオにアラームを関連付けることで障害発生時に定型保守作業を実行し、夜間作業の負担を減らす保守運用が可能となる。

【0135】

（Ｃ）他の実施形態
上述した実施形態においても種々の変形実施形態を言及したが、本発明は、以下の変形実施形態にも適用できる。

【0136】

（Ｃ－１）上述した実施形態では、説明便宜上、ＡＰＩ番号毎に、クライアント２１～２３とサーバ３１～３３とが起動する場合を例示した。しかし、クライアント・サーバは、ＡＰＩ番号毎に区分することに限定されない。

【0137】

例えば、保守者が、保守端末１の画面上で装置４の設定や状態監視等の保守運用をする際に、保守識別子等の保守識別情報、保守種類毎若しくは保守作業名称毎に、各装置４の結果を表示できればよい。したがって、保守種類毎又は保守作業名称毎に、クライアント・サーバを区分するようにしてもよい。

【0138】

（Ｃ－２）上述した実施形態では、連携サーバ３上のＡＰＩ番号毎のサーバ３１～３３が、定型保守作業用オープンＡＰＩで定義した「ＩＮ」又は「ＯＵＴ」と、装置４が依存しているコマンド形式の要求又は応答とを変換する場合を例示したが、これに限らない。

【0139】

例えば、管理サーバ２上のクライアント２１～２３が、定型保守作業設定情報記憶部５にアクセス可能であり、定型保守作業用オープンＡＰＩの「ＩＮ」及び「ＯＵＴ」のうち、「ＯＵＴ」を変換して保守端末１の画面に表示するようにしてもよい。なお、「ＩＮ」の変換についてもクライアント２１～２３が行なってもよいが、装置４の機種ごとの変換が必要となるので、サーバ３１～３３側で行う方が望ましい。

【0140】

また例えば、クライアント２１～２３が、定型保守作業設定情報記憶部５に記憶されている定型保守作業設定情報を保守端末１に与えて保持させて、保守端末１が、「ＯＵＴ」定義のパラメータを、各装置４のコマンド形式の応答に変換して画面表示するようにしてもよい。また逆に、保守端末１が、各装置４のコマンド形式の応答を、「ＯＵＴ」定義のパラメータに変換して画面表示してもよい。

【0141】

（Ｃ－３）図３に例示するように、連携サーバ３上のＡＰＩ番号毎のサーバ３１～３３が、複数の装置４の保守状態を監視する統合監視システム６と接続して、統合監視システム６が監視する装置７の保守管理も可能である。

【0142】

この場合も、上述した実施形態で説明した定型保守作業用オープンＡＰＩを用いることにより、統合監視システム６が監視する各装置７の保守情報（結果）を呼び出して、保守端末１の画面の表示させることができる。

【0143】

（Ｃ－４）上述した第２の実施形態では、管理サーバ２が、トラップ監視部２０１、保守シナリオ登録・実行部２０２，定型保守作業実行部２０３、クライアント２ｍの各種機能を実行する場合を例示した。しかし、管理サーバ２が実行する各種機能は、物理的に同一のサーバが実装しなくてもよく、物理的に異なる複数のサーバ上に分散配置されてもよい。

【符号の説明】

【0144】

１…保守端末、２…管理サーバ、３…連携サーバ、４（４－１～４－Ｎ）装置、５…定型保守作業設定情報記憶部、６…統合監視システム、７…装置、１０及び１０Ａ及び１０Ｂ…保守管理システム、２１～２３…クライアント、３１～３３…サーバ、３５…相互変換部、４１…機器インタフェース、２０１…トラップ監視部、２０２…保守シナリオ登録・実行部、２０３…定型保守作業実行部、２０４…保守シナリオ記憶部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】