特許 7251259 運用管理装置、運用管理システム、および運用管理方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-03-27

(45)【発行日】2023-04-04

(54)【発明の名称】運用管理装置、運用管理システム、および運用管理方法

(51)【国際特許分類】

   H04L 43/024 20220101AFI20230328BHJP

   G06F 11/30 20060101ALI20230328BHJP

   H04W 24/08 20090101ALI20230328BHJP

   H04W 24/10 20090101ALI20230328BHJP

【ＦＩ】

H04L43/024

G06F11/30 140A

G06F11/30 155

G06F11/30 196

H04W24/08

H04W24/10

【請求項の数】 12

(21)【出願番号】P 2019063280

(22)【出願日】2019-03-28

(65)【公開番号】P2020167442

(43)【公開日】2020-10-08

【審査請求日】2021-09-09

【国等の委託研究の成果に係る記載事項】（出願人による申告）平成３０年度、総務省、「ＩｏＴ共通基盤技術の確立・実証 ＩＩ効率的かつ安定的なＩｏＴデバイス接続・エリアネットワーク運用管理技術の確立」研究開発委託契約に基づく開発項目「エリアネットワーク運用管理技術に関する研究開発」委託研究、産業技術力強化法第１９条の適用を受ける特許出願

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】矢野 愛

(72)【発明者】

【氏名】大谷 武

【審査官】佐々木 洋

(56)【参考文献】

【文献】特開２０１８－０９７５２７（ＪＰ，Ａ）

【文献】国際公開第２０１８／０６６０４１（ＷＯ，Ａ１）

【文献】特開２０１９－０４７３７７（ＪＰ，Ａ）

【文献】特開２０１７－１２３１２４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－１２／６６

Ｈ０４Ｌ ４１／００－１０１／６９５

Ｈ０４Ｗ ２４／０８

Ｈ０４Ｗ ２４／１０

Ｇ０６Ｆ １１／３０

(57)【特許請求の範囲】

【請求項1】

１以上のデバイスとの間の通信における運用管理情報を取得する取得部と、
前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部と、
前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部と、
前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部と、を備え、
前記判定部は、前記状態監視用パケットの送受信時において、前記１以上のデバイスに設定された複数のプロトコルのうち、使用していないプロトコルでの前記運用管理情報の悪化の有無を判定し、
前記使用していないプロトコルでの前記運用管理情報が悪化していると判定された場合に、前記監視部は、前記１以上のデバイスの状態監視用パケットの送受信を停止することを特徴とする運用管理装置。

【請求項2】

前記決定部は、前記状態監視用パケットの送受信について、送信タイミングまたは送信間隔を変更することを特徴とする請求項１に記載の運用管理装置。

【請求項3】

前記運用管理情報は、前記１以上のデバイスの通信品質を示す運用管理情報を含み、
前記判定部は、前記状態監視用パケットの送受信時において、前記通信品質を示す運用管理情報の悪化の有無を判定し、
前記決定部は、前記通信品質を示す運用管理情報についての前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する、ことを特徴とする請求項１または請求項２に記載の運用管理装置。

【請求項4】

前記運用管理情報は、前記１以上のデバイスのそれぞれの端末品質を示す運用管理情報を含み、
前記判定部は、前記状態監視用パケットの送受信時において、前記端末品質を示す運用管理情報の悪化の有無を判定し、
前記決定部は、前記端末品質を示す運用管理情報についての前記判定部の判定結果に応じて、前記１以上のデバイスのそれぞれについて、前記状態監視用パケットの送受信の手法を決定することを特徴とする請求項１～３のいずれか一項に記載の運用管理装置。

【請求項5】

前記１以上のデバイスは、複数のセンサノードと、前記複数のセンサノードの計測値を中継して前記運用管理装置に送信する１以上の中継器とを備え、
前記判定部は、前記中継器ごとかつ前記状態監視用パケットの送受信のプロトコルごとに、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、
前記決定部は、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定することを特徴とする請求項１～４のいずれか一項に記載の運用管理装置。

【請求項6】

前記決定部は、前記状態監視用パケットの送受信の手法のそれぞれについて、端末品質の改善効果の有無を事前に保持しておき、前記端末品質の改善効果が有る手法を決定することを特徴とする請求項１～５のいずれか一項に記載の運用管理装置。

【請求項7】

前記取得部は、前記状態監視用パケットの送受信の間隔またはタイミングに応じて、前記運用管理情報を取得する間隔またはタイミングを調整することを特徴とする請求項１～６のいずれか一項に記載の運用管理装置。

【請求項8】

１以上のデバイスと、
前記１以上のデバイスと通信を行う運用管理装置と、を備え、
前記運用管理装置は、前記１以上のデバイスとの間の通信における運用管理情報を取得する取得部と、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部と、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部と、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部と、を備え、前記判定部は、前記状態監視用パケットの送受信時において、前記１以上のデバイスに設定された複数のプロトコルのうち、使用していないプロトコルでの前記運用管理情報の悪化の有無を判定し、前記使用していないプロトコルでの前記運用管理情報が悪化していると判定された場合に、前記監視部は、前記１以上のデバイスの状態監視用パケットの送受信を停止することを特徴とする運用管理システム。

【請求項9】

取得部が、１以上のデバイスとの間の通信における運用管理情報を取得し、
監視部が、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視し、
判定部が、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、
決定部が、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定し、
前記判定部は、前記状態監視用パケットの送受信時において、前記１以上のデバイスに設定された複数のプロトコルのうち、使用していないプロトコルでの前記運用管理情報の悪化の有無を判定し、
前記使用していないプロトコルでの前記運用管理情報が悪化していると判定された場合に、前記監視部は、前記１以上のデバイスの状態監視用パケットの送受信を停止することを特徴とする運用管理方法。

【請求項10】

１以上のデバイスとの間の通信における運用管理情報を取得する取得部と、
前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部と、
前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部と、
前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部と、を備え、
前記１以上のデバイスは、複数のセンサノードと、前記複数のセンサノードの計測値を中継して運用管理装置に送信する１以上の中継器とを備え、
前記判定部は、前記中継器ごとかつ前記状態監視用パケットの送受信のプロトコルごとに、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、
前記決定部は、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定することを特徴とする運用管理装置。

【請求項11】

１以上のデバイスと、
前記１以上のデバイスと通信を行う運用管理装置と、を備え、
前記運用管理装置は、前記１以上のデバイスとの間の通信における運用管理情報を取得する取得部と、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部と、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部と、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部と、を備え、前記１以上のデバイスは、複数のセンサノードと、前記複数のセンサノードの計測値を中継して前記運用管理装置に送信する１以上の中継器とを備え、前記判定部は、前記中継器ごとかつ前記状態監視用パケットの送受信のプロトコルごとに、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、前記決定部は、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定することを特徴とする運用管理システム。

【請求項12】

取得部が、１以上のデバイスとの間の通信における運用管理情報を取得し、
監視部が、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視し、
判定部が、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、
決定部が、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定し、
前記１以上のデバイスは、複数のセンサノードと、前記複数のセンサノードの計測値を中継して運用管理装置に送信する１以上の中継器とを備え、
前記判定部は、前記中継器ごとかつ前記状態監視用パケットの送受信のプロトコルごとに、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定し、
前記決定部は、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定することを特徴とする運用管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本件は、運用管理装置、運用管理システム、および運用管理方法に関する。

【背景技術】

【0002】

ＩｏＴ（Internet of Things）フィールドの拡大に伴い、多種多様なデバイスが、多種多様な通信方式で接続されるようになっている。このような状況において、設置デバイス、利用通信方式、周辺の無線状況、利用アプリ等により、発生する障害（デバイスのハードウェア／ソフトウェア障害、通信障害)が様々となる。そのため、時々刻々と変化するＩｏＴ環境において、運用管理技術が重要になっている（例えば、特許文献１，２参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－１６２４０６号公報

【文献】特開２００８－１５７２２号公報

【発明の概要】

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

【0004】

ＩｏＴの運用管理において、デバイスの状態を監視して異常検知を行うために、複数種類の中から選択された手法で状態監視用パケットが送受信されている。時々刻々と変化するＩｏＴ環境においては、通信負荷の変化に応じた手法で異常検知を行うことが望まれる。

【0005】

１つの側面では、本発明は、通信負荷の変化に応じた手法で異常検知を行うことができる運用管理装置、運用管理システム、および運用管理方法を提供することを目的とする。

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

【0006】

１つの態様では、運用管理装置は、１以上のデバイスとの間の通信における運用管理情報を取得する取得部と、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部と、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部と、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部と、を備え、前記判定部は、前記状態監視用パケットの送受信時において、前記１以上のデバイスに設定された複数のプロトコルのうち、使用していないプロトコルでの前記運用管理情報の悪化の有無を判定し、前記使用していないプロトコルでの前記運用管理情報が悪化していると判定された場合に、前記監視部は、前記１以上のデバイスの状態監視用パケットの送受信を停止する。

【発明の効果】

【0007】

通信負荷の変化に応じた手法で異常検知を行うことができる。

【図面の簡単な説明】

【0008】

【図1】ＩｏＴフィールド運用管理を例示する図である。

【図2】実施例１に係る運用管理システムの全体構成を例示する図である。

【図3】計測値データベースに格納されるセンサ計測値のテーブルを例示する図である。

【図4】運用管理情報データベースに格納される運用管理情報のテーブルを例示する図である。

【図5】（ａ）はセンサ計測値の取得に失敗した場合を例示し、（ｂ）はＲＳＳＩが閾値「－６０」を下回った場合を例示する図である。

【図6】監視管理データベースに格納される監視間隔のテーブルを例示する図である。

【図7】集約されたテーブルを例示する図である。

【図8】対応プロコルリストを例示する図である。

【図9】運用管理システムが実行するフローチャートを例示する図である。

【図10】運用管理システムが実行するフローチャートを例示する図である。

【図11】状態監視用パケットの送信間隔および送信タイミングが変更された場合の監視管理データベースのテーブルを例示する図である。

【図12】運用管理システムが実行するフローチャートを例示する図である。

【図13】集約されたテーブルを例示する図である。

【図14】運用管理システムが実行するフローチャートを例示する図である。

【図15】状態監視用パケットの送信間隔および送信タイミングが変更された場合の監視管理データベースのテーブルを例示する図である。

【図16】運用管理システムが実行するフローチャートを例示する図である。

【図17】中継器ごとかつプロトコルごとに集約された各デバイスの運用管理情報を例示する図である。

【図18】運用管理システムが実行するフローチャートを例示する図である。

【図19】監視管理データベースに登録された効果の有無を例示する図である。

【図20】ゲートウェイのハードウェア構成を例示するブロック図である。

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

【0009】

実施例の説明に先立って、ＩｏＴ（Internet of Things）フィールドの運用管理の概要について説明する。ＩｏＴの拡大に伴い、多種多様なデバイスが、多種多様な通信方式で接続されるようになっている。このような状況において、デバイス、利用通信方式、周辺の無線状況、利用アプリ等により、発生する障害(デバイスのハードウェア／ソフトウェア障害、通信障害)が様々となる。そのため、時々刻々と変化するＩｏＴ環境において、デバイスやネットワークの状態を監視し、異常発生を検知し、障害原因を特定し、運用管理者に通知するＩｏＴ運用管理技術が重要になっている。

【0010】

異常発生検知をリアルタイムに、かつ同時に障害原因を特定すべく、高頻度でセンサノードの詳細な状態情報の収集をすると、通信負荷が高くなるという問題がある。逆に、通信の負荷にならないように詳細な状態情報を収集せず、センサノードの死活監視のみにすると、リアルタイムに障害対応できない可能性がある。そのため、時々刻々と変化する通信負荷に応じて、収集するセンサノードの状態情報を最適化することにより、通信負荷上昇を抑制しつつ、かつリアルタイムな異常検知や障害原因特定の両立を実現する技術が重要となる。

【0011】

図１は、ＩｏＴフィールド運用管理を例示する図である。図１で例示するように、デバイスは、センサノード、中継器などを含む。ゲートウェイ（ＧＷ）は、フィールドエリアネットワークの各センサノードからデータを収集する。例えば、各センサノードは、有線で中継器等を介してゲートウェイにセンサ計測値を送信する。または、各センサノードは、無線で中継器等を介してゲートウェイにセンサ計測値を送信する。

【0012】

このようなＩｏＴフィールド運用管理においては、ゲートウェイは、各デバイスの状態を監視する。デバイスの状態の管理手法として、ゲートウェイから状態情報を要求するプロトコルと、デバイスから状態情報を送信するプロトコルとがある。ゲートウェイから状態情報を要求するプロトコルでは、プロトコルごとに指定された監視間隔で、指定されたデバイスに対して、状態監視用パケットが送信される。デバイスから状態情報を送信するプロトコルでは、ゲートウェイが、指定された監視間隔を、指定されたデバイスに対して通知する。当該監視間隔で、各デバイスはゲートウェイに状態監視用パケットを送信する。

【0013】

ゲートウェイから状態情報を要求するプロトコルには、Ｐｉｎｇ（ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ））、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎｅｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などがある。Ｐｉｎｇ方式では、デバイスは、センサノードに対してｐｉｎｇパケットを送り、応答の有無に応じてデバイスの状態（死活など）を判断する。この方式は、短パケット送受信方式であるため、ネットワーク負荷は軽いが情報量が少なくなる。ＳＮＭＰ方式では、ＳＮＭＰマネージャ（ゲートウェイ）がＳＮＭＰエージェント（デバイス）に対してＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）（ＣＰＵ／メモリ使用率、トラフィック量等）を要求することで、デバイスの詳細な状態を判断する。この方式では、デバイスの詳細情報を送信することが可能であるが、パケットが長くなるためネットワーク負荷が大きくなる。

【0014】

デバイスから状態情報を送信するプロトコルには、ＬＬＤＰ（Ｌｉｎｋ Ｌａｙｅｒ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）などがある。ＬＬＤＰ方式では、デバイスがＬＬＤＰパケット（ネイバー（隣接する機器）情報）をマルチキャストアドレス宛に定期的に送信し、ゲートウェイがＬＬＤＰパケットを受信してデバイスの接続経路を含む状態を判断する。この方式では、デバイスの詳細情報を送信することが可能であるが、パケットが長くなるためネットワーク負荷が大きくなる。

【0015】

このように、デバイスの状態を監視する手法には、情報量が少なくて通信負荷の小さいもの、情報量が多くて通信負荷の大きいもの、などがある。通信負荷を抑制しつつ、デバイスの監視を行うことが望まれる。

【0016】

以下の実施例では、時々刻々と変化するＩｏＴ環境において、通信負荷の変化に応じた手法で異常検知を行うことができる運用管理装置、運用管理システム、および運用管理方法について説明する。

【実施例1】

【0017】

図２は、実施例１に係る運用管理システム１００の全体構成を例示する図である。図２で例示するように、運用管理システム１００は、１以上のデバイスとゲートウェイ３０とを備えている。１以上のデバイスには、センサノード１０、中継器２０などが含まれている。例えば、センサノード１０は、無線で中継器２０と通信する。または、センサノード１０は、有線で中継器２０と通信する。例えば、中継器２０は、有線でゲートウェイ３０と通信する。

【0018】

センサノード１０は、性能計測部１１、センサ計測部１２、通信部１３などを備える。性能計測部１１は、自身が備わるセンサノード１０の性能を計測する。センサノード１０の性能には、後述する運用管理情報、センサノード１０の状態監視情報などが含まれる。センサ計測部１２は、センサノード１０が備えるセンサの計測結果（センサ計測値）を取得する。通信部１３は、性能計測部１１が計測した性能、センサ計測部１２が取得したセンサ計測値などを中継器２０に送信する。また、通信部１３は、中継器２０を介して状態監視用パケットをゲートウェイ３０に送信するか、中継器２０を介して状態監視用パケットをゲートウェイ３０から受信する。

【0019】

中継器２０は、性能計測部２１、通信部２２などを備える。性能計測部２１は、自身が備わる中継器２０の性能を計測する。通信部２２は、性能計測部２１が計測した性能をゲートウェイ３０に送信する。また、通信部２２は、各センサノード１０から受信したデータをゲートウェイ３０に送信する。また、通信部２２は、状態監視用パケットをゲートウェイ３０に送信するか、状態監視用パケットをゲートウェイ３０から受信する。

【0020】

ゲートウェイ３０は、計測値取得部３１、計測値データベース３２、運用管理情報取得部３３、運用管理情報データベース３４、異常判定部３５、原因特定部３６、通知部３７、監視部３８、監視管理データベース３９、変化判定部４０、方式決定部４１、プロトコル管理データベース４２などを備える。

【0021】

計測値取得部３１は、各センサノード１０のセンサ計測部１２が計測したセンサ計測値を取得し、計測値データベース３２に格納する。計測値取得部３１は、計測値データベース３２にセンサ計測値を格納するたびに、異常判定部３５に計測値データベース３２の更新を通知する。図３は、計測値データベース３２に格納されるセンサ計測値のテーブルを例示する図である。図３で例示するように、各デバイスを特定するためのデバイスＩＤに関連付けて、計測された日時（タイムスタンプ）、各センサ計測値（温度、湿度、水位、ガス量）などが格納されている。図３の例では、センサノードのセンサ計測値が例示されている。

【0022】

運用管理情報取得部３３は、各センサノード１０の性能計測部１１が計測した運用管理情報、各中継器２０の性能計測部２１が計測した運用管理情報、およびゲートウェイ３０の運用管理情報を取得し、運用管理情報データベース３４に格納する。運用管理情報取得部３３は、ゲートウェイ３０の運用管理情報も計測して、運用管理情報データベース３４に格納する。センサノード１０が計測した運用管理情報には、当該センサノード１０の通信品質を示す運用管理情報、当該センサノード１０のハードウェアやソフトウェアの状況（端末品質）を示す運用管理情報などが含まれる。中継器２０が計測した運用管理情報には、当該中継器２０の端末品質を示す運用管理情報などが含まれる。運用管理情報取得部３３は、運用管理情報データベース３４に運用管理情報を格納するたびに、異常判定部３５に運用管理情報データベース３４の更新を通知する。ゲートウェイ３０が計測した運用管理情報には、当該ゲートウェイ３０の端末品質を示す運用管理情報などが含まれる。図４は、運用管理情報データベース３４に格納される運用管理情報のテーブルを例示する図である。図４で例示するように、デバイスＩＤに関連付けて、取得された日時（タイムスタンプ）、運用管理情報などが格納されている。通信品質を示す運用管理情報には、受信信号強度（ＲＳＳＩ）、リンク品質（ＬＱ：Ｌｉｎｋ Ｑｕａｌｉｔｙ）、応答時間、パケットエラー率（ＰＥＲ）、再送回数、チャネル利用率、アクティブノード数などのパラメータが含まれる。端末品質を示す運用管理情報には、バッテリ残量、ＣＰＵ使用率、メモリ使用率、ＨＤＤ使用率、デバイス内温度、内部処理時間などのパラメータが含まれる。なお、運用管理情報取得部３３は、さらに、中継器２０が観測できる通信品質を示す運用管理情報を取得してもよい。

【0023】

異常判定部３５は、計測値取得部３１から計測値データベース３２の更新通知を受信すると、計測値データベース３２の直近データを取得し、異常の有無を判定する。それにより、異常判定部３５は、計測値取得部３１が取得する全てのセンサ計測値について、異常の有無を判定することができる。また、異常判定部３５は、運用管理情報取得部３３から運用管理情報データベース３４の更新通知を受信すると、運用管理情報データベース３４の直近データを取得し、異常の有無を判定する。それにより、異常判定部３５は、運用管理情報取得部３３が取得する全ての運用管理情報について、異常の有無を判定することができる。異常判定部３５は、異常発生を検知した場合、原因特定部３６に、異常発生を通知するとともに、異常と判定された元データ（センサ計測値または運用管理情報）を渡す。例えば、異常判定部３５は、原因特定部３６に、該当するデータのデバイスＩＤ、タイムスタンプ、データ名、データ値を渡す。

【0024】

異常発生の判定基準として、例えば、センサ計測値もしくは運用管理情報の取得に失敗したこと、運用管理情報が閾値を超えたこと、エラーメッセージを受信したことなどが挙げられる。また、計測値データベース３２または運用管理情報データベース３４から複数個の直近データを時系列で取得し、平均値や分散値等の特徴量を算出して、閾値を超えるか否か判定してもよい。図５（ａ）では、計測値データベース３２で、センサ計測値の取得に失敗している例が示されている。図５（ｂ）では、運用管理情報データベース３４で、ＲＳＳＩが閾値「－６０」を下回った例が示されている。

【0025】

原因特定部３６は、異常判定部３５から異常発生の通知を受信すると、異常と判定された元データのデバイスＩＤについて、運用管理情報データベース３４から１以上の直近データを取得し、分析し、異常発生の原因を特定する。原因特定部３６は、原因を特定できた場合には、通知部３７に障害内容（デバイスＩＤ、異常発生日時、異常発生の原因）を通知する。

【0026】

原因特定部３６が運用管理情報データベース３４から取得する直近データの個数は、異常発生と判定された元データのタイムスタンプから直前Ｘ個でもよいし、異常発生と判定された元データのタイムスタンプの前後Ｘ個でもよい。また、データ変化周期、データ変化量等に応じてＸを変更してもよい。例えば、通信品質を示す運用管理情報については、アトランダムに大きく変化するため、より多くの直近データ（例えば５０個）を取得することが好ましい。端末品質を示す運用管理情報については、線形に変化することが多いため、少ない直近データ（例えば１０個）を取得することが好ましい。分析手法は、既存手法（平均、中央値、分散値、特徴量の比較、閾値超え、クラスタ分析、トレンド分析、正常時の学習パターン、クラスタとの比較等)を利用してもよい。

【0027】

通知部３７は、原因特定部３６から受信した障害内容（デバイスＩＤ、異常発生日時、異常発生の原因)を通知先へ通知する。通知先は、システム運用アプリ、見える化アプリ、システム管理者、システム利用者等である。以上のことから、センサ計測値または運用管理情報に基づいて、障害内容を通知することができるようになる。

【0028】

監視部３８は、監視管理データベース３９からプロトコルごとにデバイス情報を取得し、プロトコルごとの監視間隔（送信間隔）を取得する。図６は、監視管理データベース３９に格納される監視間隔のテーブルを例示する図である。例えば、デバイスＩＤ＿００１のセンサノードは、状態監視パケット送信について、監視間隔が１０秒に設定されたＳＮＭＰプロトコル用いている。デバイスＩＤ＿０２１のセンサノードは、状態監視パケット送信について、監視間隔が１秒に設定されたＰｉｎプロトコルを用いている。

【0029】

ゲートウェイ３０がセンサノード１０に状態監視用パケットを送信する場合には、監視部３８は、プロトコルごとに、指定された監視間隔で、指定されたセンサノード１０に対して、状態監視用パケットを送信する。指定されたセンサノード１０は、状態監視用パケットを受信する。センサノード１０からゲートウェイ３０に状態監視用パケットを送信する場合は、監視部３８は、プロトコルごとに、指定されたセンサノード１０に対して、指定された監視間隔を通知する。センサノード１０は、指定された監視間隔で状態監視用パケットを送信する。監視部３８は、各センサノード１０に状態監視用パケットを送信するか、各センサノード１０から状態監視用パケットを受信する。監視部３８は、各センサノード１０に状態監視用パケットを送信したこと、または各センサノード１０から状態監視用パケットを受信したことを変化判定部４０に通知する。

【0030】

続いて、通信品質を示す運用管理情報の変化に応じて、状態監視パケットの送受信の手法を決定する例について説明する。監視部３８は、センサノード１０に対して状態監視用パケットを送信したこと、またはセンサノード１０から状態監視用パケットを受信したことを変化判定部４０に通知する。

【0031】

変化判定部４０は、監視部３８から、センサノード１０に対して状態監視用パケットを送信したこと、またはセンサノード１０から状態監視用パケットを受信したことを受信する。この受信タイミングにおいて、変化判定部４０は、この受信タイミングから以前に収集した該センサノード１０に関して、通信品質を示す運用管理情報を運用管理情報データベース３４から取得し、センサノード１０ごとに、通信品質を示す運用管理情報の変化（悪化、変化無し、良化）を判定する。また、変化判定部４０は、監視管理データベース３９から該センサノード１０のプロトコルを取得し、プロトコルごとに、センサノード１０の運用管理情報変化を集約する。図７は、集約されたテーブルを例示する図である。変化判定部４０は、状態監視時の運用管理情報の変化（悪化、変化無し、良化）を判定し、方式決定部４１に通知する。例えば、いずれか１つのパラメータでも悪化であれば「悪化」と判定してもよく、悪化／変化無し／良化のそれぞれの多数決でもよい。なお、図７で、「×」は悪化を表し、「‐」は変化無しを表し、「〇」は良化を表す。

【0032】

通信品質を示す運用管理情報変化の分析手法は、既存手法（平均、中央値、分散値、特徴量の比較、閾値超え、クラスタ分析、トレンド分析、近似直線の傾き等)を用いてもよい。例えば、ＲＳＳＩ、ＬＱなどについては、値が小さくなる傾向にあれば悪化していると判定することができる。応答時間、ＰＥＲ、再送回数、チャネル利用率、アクティブノード数などについては、値が大きくなる傾向にあれば悪化していると判定することができる。

【0033】

また、状態監視時における、通信品質を示す運用管理情報変化の判定は、状態監視パケットを送信／受信したことを受信するたびに実施してもよく、複数回分をまとめて実施してもよい。また、状態監視時の運用管理情報変化の判定は、デバイスが１個でも「悪化」があれば「悪化」と判定してもよいし、悪化／変化無し／良化のそれぞれの多数決でもよい。

【0034】

方式決定部４１は、変化判定部４０から状態監視時の運用管理情報の変化を受信し、該変化が悪化している場合、監視管理データベース３９から、該プロトコルを利用して状態監視しているデバイスのリストを取得し、該デバイスの中で、複数プロトコルに対応しているデバイスがあるかどうか判定する。図８は、対応プロトコルリストを例示する図である。例えば、デバイスＩＤがノードＩＤ＿００１のセンサノード１０は、ＳＮＭＰプロトコルおよびＰｉｎｇプロトコルの２種類のプロトコルに対応している。方式決定部４１は、複数のプロトコルに対応しているデバイスがある場合、使用中以外のプロトコルについて、状態監視時における、通信品質を示す運用管理情報の変化を取得し、該変化が悪化以外の場合、該デバイスの状態監視用プロトコルを変更し、監視管理データベース３９に登録する。デバイスごとの対応プロトコルリストは、予め手動で登録しておいてもよく、新デバイス接続時に、ゲートウェイ３０からプロトコルコマンドを送信して応答のあるプロトコルを登録してもよい。

【0035】

図９は、運用管理システム１００が、通信品質を示す運用管理情報の変化に応じて、状態監視パケットの送受信の手法を決定する場合に実行するフローチャートを例示する図である。図９で例示するように、方式決定部４１は、変化判定部４０が通信品質を示す運用管理情報の変化を判定するごとに、当該判定結果を変化判定部４０から受信する（ステップＳ１）。次に、方式決定部４１は、当該判定結果が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ２）。判定結果が「変化無し」または「良化」であれば、ステップＳ１から再度実行される。

【0036】

判定結果が「悪化」であれば、方式決定部４１は、監視管理データベース３９から、該プロトコルを利用して状態監視しているデバイスのリストを取得する（ステップＳ３）。次に、方式決定部４１は、該デバイスの中で、他のプロトコルに対応しているデバイスがあるかどうか否かを判定する（ステップＳ４）。ステップＳ４で「Ｎｏ」と判定された場合、ステップＳ１から再度実行される。

【0037】

ステップＳ４で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該他のプロトコルについて、状態監視時における、通信品質を示す運用管理情報の変化を監視管理データベース３９から取得する。さらに、方式決定部４１は、当該変化が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ５）。ステップＳ５で「悪化」と判定された場合、ステップＳ１から再度実行される。ステップＳ５で「変化無し」または「良化」と判定された場合には、当該センサノード１０のプロトコルを当該他のプロトコルに変更し、監視管理データベース３９に登録する（ステップＳ６）。

【0038】

本実施例によれば、状態監視用パケットの送受信時において、通信品質を示す運用管理情報の悪化の有無が判定される。この判定の結果に応じて、状態監視用パケットの送受信の手法が決定される。通信品質を示す運用管理情報の悪化の有無を判定することで、通信負荷の変化を判定することができる。したがって、時々刻々と変化するＩｏＴ環境において、通信負荷の変化に応じた手法で異常検知を行うことができる。例えば、通信品質を示す運用管理情報が悪化する場合に状態監視用パケットの送受信の手法を変更することで、通信負荷が大きくなる場合に状態監視用パケットの送受信の手法を変更することができる。例えば、通信負荷が軽減されるプロトコルを選択することで、通信負荷を抑制することができる。

【実施例2】

【0039】

実施例２では、プロトコルを切り替える前に状態監視用パケットの送信間隔や送信タイミングを変更する例について説明する。図１０は、本実施例において運用管理システム１００が実行するフローチャートを例示する図である。図１０で例示するように、方式決定部４１は、変化判定部４０が通信品質を示す運用管理情報の変化を判定するごとに、当該判定結果を変化判定部４０から受信する（ステップＳ１１）。次に、方式決定部４１は、当該判定結果が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ１２）。判定結果が「変化無し」または「良化」であれば、ステップＳ１１から再度実行される。

【0040】

ステップＳ１２で「悪化」と判定された場合には、方式決定部４１は、使用中のプロトコルの監視間隔を所定時間（例えば、１秒）だけ長くした場合の値を算出する（ステップＳ１３）。次に、方式決定部４１は、算出された監視間隔が予め定められたリミットに達したか否かを判定する（ステップＳ１４）。ステップＳ１４で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベースの監視間隔を算出された監視間隔に変更する（ステップＳ１５）。その後、ステップＳ１１から再度実行される。

【0041】

ステップＳ１４で「Ｙｅｓ」と判定された場合、方式決定部４１は、ゲートウェイ３０からセンサノード１０に状態監視用パケットを送信するプロトコルを用いているか否かを判定する（ステップＳ１６）。ステップＳ１６で「Ｙｅｓ」と判定された場合、状態監視用パケットを送信するタイミングをシフトさせることで変更する（ステップＳ１７）。その後、ステップＳ１１から再度実行される。なお、図１１は、状態監視用パケットの送信間隔および送信タイミングが変更された場合の監視管理データベース３９のテーブルを例示する図である。

【0042】

ステップＳ１６で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９から、該プロトコルを利用して状態監視しているデバイスのリストを取得する（ステップＳ１８）。次に、方式決定部４１は、該デバイスの中で、他のプロトコルに対応しているデバイスがあるかどうか否かを判定する（ステップＳ１９）。ステップＳ１９で「Ｎｏ」と判定された場合、ステップＳ１１から再度実行される。

【0043】

ステップＳ１９で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該他のプロトコルについて、状態監視時の運用管理情報の変化を監視管理データベース３９から取得する。さらに、方式決定部４１は、当該変化が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ２０）。ステップＳ２０で「悪化」と判定された場合、ステップＳ１１から再度実行される。ステップＳ２０で「変化無し」または「良化」と判定された場合には、当該デバイスのプロトコルを当該他のプロトコルに変更し、監視管理データベース３９に登録する（ステップＳ２１）。

【0044】

本実施例によれば、状態監視用パケットの送受信について、送信タイミングまたは送信間隔を変更することで、通信品質の悪化を抑制することができる。プロトコルの変更をしなくても通信品質の悪化を抑制できれば、プロトコルの変更に伴う情報量の減を抑制することができる。

【0045】

なお、監視間隔を延ばす間隔とリミットは、プロトコルごとに変えてもよい。また、状態監視時の運用管理情報の変化が良くなった場合は、逆に、間隔を短くしてもよい。

【実施例3】

【0046】

実施例３では、変更すべきプロトコルが無い場合に状態監視用パケットの送信を停止する場合について説明する。図１２は、本実施例において運用管理システム１００が実行するフローチャートを例示する図である。図１２で例示するように、ステップＳ１１～ステップＳ２１については図１０と同様の処理を行う。

【0047】

ステップＳ１９で「Ｎｏ」と判定された場合、またはステップＳ２０で「悪化」と判定された場合、監視部３８は、状態監視用パケットの送受信を停止する（ステップＳ２２）。次に、方式決定部４１は、計測値取得部３１および運用管理情報取得部３３に、それぞれのデータベース更新通知を、変化判定部４０にも通知するよう依頼通知する（ステップＳ２３）。その後、ステップＳ１１から再度実行される。

【0048】

本実施例によれば、通信品質を示す運用管理情報が悪化するプロトコルしか選択できなければ、状態監視用パケットの送受信が停止される。この場合、計測値取得部３１および運用管理情報取得部３３がデータベースの更新通知を変化判定部４０に通知することで、状態監視用パケットの代わりに、センサ計測値や運用管理情報を各デバイスの状態監視に用いることができる。

【実施例4】

【0049】

実施例４では、端末品質を示す運用管理情報の変化を考慮する例について説明する。本実施例においては、変化判定部４０は、監視部３８から、デバイスに対して状態監視パケットを送信したこと、またはデバイスから状態管理パケットを受信したことを受信する。この受信タイミングにおいて、変化判定部４０は、この受信タイミングから以前に収集した該デバイスに関して、端末品質を示す運用管理情報を運用管理情報データベース３４から取得し、デバイスごとに、端末品質を示す運用管理情報の変化（悪化、変化無し、良化）を判定する。また、変化判定部４０は、監視管理データベース３９から該デバイスのプロトコルを取得し、プロトコルごとに、デバイスの運用管理情報変化を集約する。変化判定部４０は、状態監視時の運用管理情報の変化（悪化、変化無し、良化）を判定し、方式決定部４１に通知する。図１３は、集約されたテーブルを例示する図である。変化判定部４０は、状態監視時の運用管理情報の変化（悪化、変化無し、良化）を判定し、方式決定部４１に通知する。

【0050】

図１４は、本実施例において運用管理システム１００が実行するフローチャートを例示する図である。図１４で例示するように、方式決定部４１は、変化判定部４０が中継器２０、センサノード１０、およびゲートウェイ３０について端末品質を示す運用管理情報の変化を判定するごとに、当該判定結果を変化判定部４０から受信する（ステップＳ３１）。方式決定部４１は、変化判定部４０が中継器２０について端末品質を示す運用管理情報の変化を判定した場合、当該判定結果が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ３２）。

【0051】

判定結果が「悪化」であれば、パケット長が長いプロトコルの監視間隔を所定時間（例えば１秒）だけ長くした場合の値を算出する（ステップＳ３３）。次に、方式決定部４１は、算出された監視間隔が予め定められたリミットに達したか否かを判定する（ステップＳ３４）。ステップＳ３４で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９の監視間隔を算出された監視間隔に変更する（ステップＳ３５）。その後、ステップＳ３１から再度実行される。

【0052】

ステップＳ３４で「Ｙｅｓ」と判定された場合、方式決定部４１は、ゲートウェイ３０からセンサノード１０に状態監視用パケットを送信するプロトコルを用いているか否かを判定する（ステップＳ３６）。ステップＳ３６で「Ｙｅｓ」と判定された場合、当該プロトコルについて、状態監視用パケットを送信するタイミングをシフトさせることで変更する（ステップＳ３７）。その後、ステップＳ３１から再度実行される。なお、図１５は、状態監視用パケットの送信間隔および送信タイミングが変更された場合の監視管理データベース３９のテーブルを例示する図である。

【0053】

ステップＳ３６で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９から、当該プロトコルを利用して状態監視しているデバイスのリストを取得する（ステップＳ３８）。次に、方式決定部４１は、当該デバイスの中で、他のプロトコルに対応しているデバイスがあるかどうか否かを判定する（ステップＳ３９）。ステップＳ３９で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該他のプロトコルについて、状態監視時における、通信品質を示す運用管理情報の変化を監視管理データベース３９から取得する。さらに、方式決定部４１は、当該変化が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ４０）。ステップＳ４０で「変化無し」または「良化」と判定された場合には、当該デバイスのプロトコルを当該他のプロトコルに変更し、監視管理データベース３９に登録する（ステップＳ４１）。その後、ステップＳ３１から再度実行される。

【0054】

ステップＳ３９で「Ｎｏ」と判定された場合、またはステップＳ４０で「悪化」と判定された場合、監視部３８は、状態監視用パケットの送受信を停止する（ステップＳ４２）。次に、方式決定部４１は、計測値取得部３１および運用管理情報取得部３３に、それぞれのデータベース更新通知を、変化判定部４０にも通知するよう依頼通知する（ステップＳ４３）。その後、ステップＳ３１から再度実行される。

【0055】

なお、ステップＳ３２で「変化無し」または「良化」と判定された場合、実施例１～実施例３のいずれかの処理が行われる。また、図１４の例では、ステップＳ３１で変化判定部４０が中継器２０について端末品質を示す運用管理情報の変化を判定した場合にステップＳ３２が実行されているが、変化判定部４０がセンサノード１０について端末品質を示す運用管理情報の変化を判定した場合には、他のフローチャート（図１６）が実行されてもよい。

【0056】

図１６は、本実施例において運用管理システム１００が実行する他のフローチャートを例示する図である。図１６で例示するように、方式決定部４１は、変化判定部４０がセンサノード１０について端末品質を示す運用管理情報の変化を判定するごとに、当該判定結果を変化判定部４０から受信する（ステップＳ５１）。次に、方式決定部４１は、当該判定結果が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ５２）。

【0057】

判定結果が「悪化」であれば、当該デバイスが使用しているプロトコルの監視間隔を所定時間（例えば１秒）だけ長くした場合の値を算出する（ステップＳ５３）。次に、方式決定部４１は、算出された監視間隔が予め定められたリミットに達したか否かを判定する（ステップＳ５４）。ステップＳ５４で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９の監視間隔を算出された監視間隔に変更する（ステップＳ５５）。その後、ステップＳ５１から再度実行される。

【0058】

ステップＳ５４で「Ｙｅｓ」と判定された場合、方式決定部４１は、ゲートウェイ３０からセンサノード１０に状態監視用パケットを送信するプロトコルを用いているか否かを判定する（ステップＳ５６）。ステップＳ５６で「Ｙｅｓ」と判定された場合、状態監視用パケットを送信するタイミングをシフトさせることで変更する（ステップＳ５７）。その後、ステップＳ５１から再度実行される。

【0059】

ステップＳ５６で「Ｎｏ」と判定された場合、方式決定部４１は、当該デバイスの中で、他のプロトコルに対応しているデバイスがあるかどうか否かを判定する（ステップＳ５８）。ステップＳ５８で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該他のプロトコルについて、状態監視時における、通信品質を示す運用管理情報の変化を監視管理データベース３９から取得する。さらに、方式決定部４１は、当該変化が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ５９）。ステップＳ５９で「変化無し」または「良化」と判定された場合には、当該デバイスのプロトコルを当該他のプロトコルに変更し、監視管理データベース３９に登録する（ステップＳ６０）。その後、ステップＳ５１から再度実行される。

【0060】

ステップＳ５８で「Ｎｏ」と判定された場合、またはステップＳ５９で「悪化」と判定された場合、監視部３８は、状態監視用パケットの送受信を停止する（ステップＳ６１）。次に、方式決定部４１は、計測値取得部３１および運用管理情報取得部３３に、それぞれのデータベース更新通知を、変化判定部４０にも通知するよう依頼通知する（ステップＳ６２）。その後、ステップＳ５１から再度実行される。

【0061】

なお、ステップＳ５２で「変化無し」または「良化」と判定された場合、実施例１～実施例３のいずれかの処理が行われる。

【0062】

本実施例によれば、状態監視用パケットの送受信時において、端末品質を示す運用管理情報の悪化の有無が判定される。この判定の結果に応じて、状態監視用パケットの送受信の手法が決定される。端末品質を示す運用管理情報の悪化の有無を判定することで、端末負荷の変化を判定することができる。したがって、時々刻々と変化するＩｏＴ環境において、端末負荷の変化に応じた手法で異常検知を行うことができる。例えば、端末品質を示す運用管理情報が悪化する場合に状態監視用パケットの送受信の手法を変更することで、端末負荷が大きくなる場合に状態監視用パケットの送受信の手法を変更することができる。例えば、端末負荷が軽減されるプロトコルを選択することで、端末負荷を抑制することができる。

【実施例5】

【0063】

実施例５では、中継器ごとかつプロトコルごとにデバイスの運用管理情報の変化を集約する例について説明する。本実施例においては、変化判定部４０は、中継器ごとかつプロトコルごとにデバイスの運用管理情報を集約し、状態監視時の運用管理情報の変化を判定し、方式決定部４１に通知する。図１７は、中継器ごとかつプロトコルごとに集約された各デバイスの運用管理情報を例示する図である。

【0064】

図１８は、本実施例において運用管理システム１００が実行するフローチャートを例示する図である。図１８で例示するように、方式決定部４１は、変化判定部４０が端末品質を示す運用管理情報の変化を判定するごとに、当該判定結果を変化判定部４０から受信する（ステップＳ７１）。次に、方式決定部４１は、当該判定結果が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ７２）。判定結果が「変化無し」または「良化」であれば、ステップＳ７１から再度実行される。

【0065】

ステップＳ７２で「悪化」と判定された場合には、方式決定部４１は、悪化と判定されたプロトコルが複数であるか否かを判定する（ステップＳ７３）。ステップＳ７３で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該複数のプロトコルのうち、対応デバイス数の多いプロトコルを選択する（ステップＳ７４）。ステップＳ７３で「Ｎｏ」と判定された場合またはステップＳ７４の実行後、悪化と判定された１つのプロトコルまたはステップＳ７４で選択されたプロトコルの監視間隔を所定時間（例えば、１秒）だけ長くした場合の値を算出する（ステップＳ７５）。次に、方式決定部４１は、算出された監視間隔が予め定められたリミットに達したか否かを判定する（ステップＳ７６）。ステップＳ７６で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９の監視間隔を算出された監視間隔に変更する（ステップＳ７７）。その後、ステップＳ７１から再度実行される。

【0066】

ステップＳ７６で「Ｙｅｓ」と判定された場合、方式決定部４１は、ゲートウェイ３０からセンサノード１０に状態監視用パケットを送信するプロトコルを用いているか否かを判定する（ステップＳ７８）。ステップＳ７８で「Ｙｅｓ」と判定された場合、状態監視用パケットを送信するタイミングをシフトさせることで変更する（ステップＳ７９）。その後、ステップＳ７１から再度実行される。

【0067】

ステップＳ７８で「Ｎｏ」と判定された場合、方式決定部４１は、監視管理データベース３９から、該プロトコルを利用して状態監視しているデバイスのリストを取得する（ステップＳ８０）。次に、方式決定部４１は、該デバイスの中で、他のプロトコルに対応しているデバイスがあるかどうか否かを判定する（ステップＳ８１）。

【0068】

ステップＳ８１で「Ｙｅｓ」と判定された場合、方式決定部４１は、当該他のプロトコルについて、状態監視時における、通信品質を示す運用管理情報の変化を監視管理データベース３９から取得する。さらに、方式決定部４１は、当該変化が悪化であるか、変化無しであるか、良化であるかを判定する（ステップＳ８２）。ステップＳ８２で「変化無し」または「良化」と判定された場合には、当該デバイスのプロトコルを当該他のプロトコルに変更し、監視管理データベース３９に登録する（ステップＳ８３）。その後、ステップＳ７１から再度実行される。

【0069】

ステップＳ８１で「Ｎｏ」と判定された場合またはステップＳ８２で「悪化」と判定された場合には、方式決定部４１は、ステップＳ７４で選択しなかったプロトコルが有るか否かを判定する（ステップＳ８４）。ステップＳ８４で「Ｙｅｓ」と判定された場合、方式決定部４１は、ステップＳ７４で選択しなかったプロトコルのいずれかを選択する（ステップＳ８５）。その後、ステップＳ７５から再度実行される。

【0070】

ステップＳ８４で「Ｎｏ」と判定された場合、監視部３８は、状態監視用パケットの送受信を停止する（ステップＳ８６）。次に、方式決定部４１は、計測値取得部３１および運用管理情報取得部３３に、それぞれのデータベース更新通知を、変化判定部４０にも通知するよう依頼通知する（ステップＳ８７）。その後、ステップＳ７１から再度実行される。

【0071】

本実施例によれば、中継器ごと、かつプロトコルごとに、デバイスの運用管理情報変化が集約され、状態監視時の運用管理情報の変化が判定される。この構成では、状態監視時に取得できる情報をなるべく減らさず、効率的に通信負荷を軽減することが可能となる。

【実施例6】

【0072】

実施例６においては、実施例１～５において、状態監視用パケットの送受信の手法の変更後における、運用管理情報変化を学習する例について説明する。本実施例においては、例えば、監視間隔の変更、監視タイミングの変更、プロトコルの変更、監視パケット送受信停止、それぞれの対処後の運用管理情報変化を学習する。

【0073】

本実施例においては、方式決定部４１は、変化判定部４０から、状態監視時の端末品質を示す運用管理情報の変化を受信し、監視方式を変更したデバイスに関して、状態監視時の端末品質を示す運用管理情報の変化(悪化／変化無し／良化)が変わったか否かを判定し、監視管理データベース３９に登録する。例えば、「悪化→良化」または「悪化→変化無し」の場合に、効果「有」とする。方式決定部４１は、プロトコルごと、かつデバイスごとに、効果の有無を管理する。

【0074】

次に、方式決定部４１は、登録済のデバイスの状態監視時の端末品質を示す運用管理情報の変化が悪化の場合、監視管理データベース３９に登録された、効果有の方式に変更する。登録されていないデバイスの状態監視時の端末品質を示す運用管理情報の変化が悪化した場合、同じ中継器／プロトコルの他デバイスと同じ方式に変更してもよい。

【0075】

図１９は、監視管理データベース３９に登録された効果の有無を例示する図である。図１９で例示するように、プロトコルごと、かつデバイスごとに、効果の有無を予め登録しておく。

【0076】

本実施例によれば、状態監視用パケットの送受信の手法のそれぞれについて、端末品質の改善効果の有無が事前に保持されている。したがって、端末品質の改善効果が有る手法を決定することができる。

【実施例7】

【0077】

実施例７では、状態監視用パケットの送信間隔または送信タイミングに応じて、運用管理情報収集の間隔またはタイミングを調整する例について説明する。本実施例においては、運用管理情報取得部３３は、監視管理データベース３９に登録された、デバイスごとの監視間隔および監視タイミング情報を取得する。運用管理情報取得部３３は、監視タイミング時と、監視間隔中に複数回、センサノード１０とゲートウェイ３０との間の通信品質を示す運用管理情報を取得し、運用管理情報データベース３４に格納し、異常判定部３５に運用管理情報データベース３４の更新を通知する。

【0078】

状態監視タイミングと、運用管理情報取得タイミングを同一にすると、通信負荷が上昇する可能性が高いので、状態監視タイミングより若干遅らせて運用管理情報を取得することが望ましい。運用管理情報取得タイミングが、他デバイスの状態監視のタイミングおよび運用管理情報取得タイミングと同一にならないように調整することが望ましい。

【0079】

本実施例においては、変化判定部４０は、監視部３８から、状態監視パケットを送信したことまたは受信したことを受信する。変化判定部４０は、監視管理データベース３９に登録された、デバイスごとの監視間隔および監視タイミング情報を取得する。変化判定部４０は、状態態監視用パケットを送受信したタイミングから、以前に状態監視パケットを送受信したタイミングまでの間に、収集した該デバイスに関する運用管理情報を複数個、運用管理情報データベース３４から取得する。変化判定部４０は、該デバイス毎に、運用管理情報の変化（悪化／変化無し／良化)を判定する。

【0080】

本実施例によれば、状態監視用パケットの送受信の間隔またはタイミングに応じて、運用管理情報を取得する間隔またはタイミングが調整される。それにより、通信負荷の上昇を抑制することができる。

【0081】

（ゲートウェイの装置構成）
図２０は、ゲートウェイ３０のハードウェア構成を例示するブロック図である。図２０で例示するようにゲートウェイ３０は、ＣＰＵ１０１、ＲＡＭ１０２、記憶装置１０３、インタフェース１０４等を備える。

【0082】

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、中央演算処理装置である。ＣＰＵ１０１は、１以上のコアを含む。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２は、ＣＰＵ１０１が実行するプログラム、ＣＰＵ１０１が処理するデータなどを一時的に記憶する揮発性メモリである。記憶装置１０３は、不揮発性記憶装置である。記憶装置１０３として、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリなどのソリッド・ステート・ドライブ（ＳＳＤ）、ハードディスクドライブに駆動されるハードディスクなどを用いることができる。記憶装置１０３は、プログラムを記憶している。インタフェース１０４は、中継器２０との通信装置である。なお、ゲートウェイ３０の各部は、プログラムの実行によって実現されてもよく、専用の回路などのハードウェアであってもよい。また、ゲートウェイ３０の機能がクラウド上で実現されてもよい。

【0083】

上記各例において、運用管理情報取得部３３が、１以上のデバイスとの間の通信における運用管理情報を取得する取得部の一例として機能する。監視部３８が、前記１以上のデバイスとの間で、状態監視用パケットの送受信を行うことで前記１以上のデバイスの状態を監視する監視部の一例として機能する。変化判定部４０が、前記状態監視用パケットの送受信時において、前記運用管理情報の悪化の有無を判定する判定部の一例として機能する。方式決定部４１が、前記判定部の判定結果に応じて、前記状態監視用パケットの送受信の手法を決定する決定部の一例として機能する。ゲートウェイ３０が、運用管理装置の一例として機能する。

【0084】

以上、本発明の実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0085】

１０ センサノード
１１ 性能計測部
１２ センサ計測部
１３ 通信部
２０ 中継器
２１ 性能計測部
２２ 通信部
３０ ゲートウェイ
３１ 計測値取得部
３２ 計測値データベース
３３ 運用管理情報取得部
３４ 運用管理情報データベース
３５ 異常判定部
３６ 原因特定部
３７ 通知部
３８ 監視部
３９ 監視管理データベース
４０ 変化判定部
４１ 方式決定部
１００ 運用管理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】