JP7010171B2 - 保守管理システムおよびデータ処理方法 - Google Patents

Description

本発明は、テレメトリ技術を利用してデータを定期的に配信する複数の管理対象を管理する保守管理システムおよびデータ処理方法に関する。

例えば、様々な通信サービスを提供するネットワーク内においては、絶え間なくサービスの提供を継続することが求められる。したがって、それぞれのサービスを提供するサーバ等の業務装置については、故障や性能の劣化などが発生しないように常時監視しておく必要がある。

そのため、通信事業者等においては、ネットワーク内で起きている状況のリアルタイム把握が必要とされる。このような状況のリアルタイム把握に関しては、管理される側の装置主導のプッシュ（Ｐｕｓｈ）型のデータ取得技術であるテレメトリが注目されている。テレメトリは、観測対象から離れた地点で観測対象のデータを取得して様々な観測を行うための技術であり、観測対象は外部からの要求がなくても定期的に繰り返しデータを送信することができる。

一方、通信事業者等においては、ネットワーク内に存在する多数の業務装置を共通の管理システムで一括して管理することが想定される。したがって、管理対象のそれぞれの業務装置から送信されるデータが管理システムに定期的に入力されることになり、業務装置の数が多いと、管理システムが受け取るデータ量も膨大になる。特に、各業務装置が短い時間周期でデータ送信を繰り返す場合には、管理システムが受け取るデータ量が管理システムの処理能力を超えて過負荷状態になってしまう可能性がある。

例えば、特許文献１の障害継続監視システムは、メッセージフラッシュ時でも、エージェントからのメッセージ流量を動的に制御し他のメッセージの監視業務に影響を与えずに継続した障害監視を行うための技術を示している。具体的には、上記の管理システムに相当する「障害監視マネージャ」の負荷を軽減するために、監視対象である「エージェント」側で一定期間データをためることを示している（特許文献１の図３参照）。

一方、非特許文献１に示されている「ＮｅｔＦｌｏｗ」の仕様では、フロー単位のデータを、ヘッダ情報などの条件でグルーピングすることが可能である。これにより、プッシュ型のデータ取得システムにおいて、フロー数を削減し、システムの負荷を軽減することが可能である。

特開２０１１－２１１５５５号公報

"フロー集約統計（ＮｅｔＦｌｏｗ Ｖｅｒｓｉｏｎ８）"、インターネット<URL:https://www.alaxala.com/jp/techinfo/archive/manual/AX5400S/HTML/10_10/_/APGUIDE2/0164.HTM>

しかしながら、特許文献１の技術では監視対象の各装置がデータをためる必要があるため、データを送信するタイミングが遅延することになり、管理システムが取得するデータのリアルタイム性が犠牲になる。

また、非特許文献１の技術では、グルーピングによりフロー数を削減できるが、管理対象のそれぞれの装置が複数種類のデータを送信する場合に、装置内のデータの種類をグルーピングすることはできない。例えば、サーバのような業務装置の場合には、ＣＰＵ（Central Processing Unit）使用率、メモリ使用率など様々な種類のデータを個別に監視する必要があるが、各データの重要度や監視すべき時間周期の長さについては状況に応じて大きく変化することが想定される。

例えば、光伝送装置の場合には、半導体であるレーザ増幅器の経年劣化によって徐々に光出力のパワーが低下する傾向がある。したがって、このような装置の故障発生を未然に防止するためには、光出力を監視する必要がある。しかし、光出力が十分に大きい状況では「検知できない障害」、すなわち「サイレント障害」が発生する可能性は非常に小さいので、このようなデータの重要度は低く、データ取得の時間周期を長くしても問題はない。しかし、光出力が一定値を下回った場合は、「サイレント障害」が発生する可能性が高くなるので、重要度は高く、データ取得の時間周期を短くする必要がある。

非特許文献１の技術では、同じ装置が送信する複数データの種類をグルーピングすることはできないので、装置単位でしかデータフローを削減できない。つまり、重要度や時間周期の条件が異なる複数種類のデータのフローを一括して制御することになるので、管理システムの負荷を削減するために、重要なデータまで間引いたり、短い時間周期で監視する必要のあるデータまで取得周期を大きくしなければならない。

本発明は、上記の状況に鑑みてなされたものであり、障害の可能性等に関する検出の遅延を防止可能にするとともに、管理対象の複数の装置がそれぞれ複数種類のデータを送信する場合に、データの種類毎の重要度や特性を考慮して適正化しつつ、管理側における負荷を削減することが可能な保守管理システムおよびデータ処理方法を提供することを目的とする。

（１）それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムであって、
前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データをデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了するデータ処理部と、
前記データ処理部のデータ処理にかかる負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する負荷レベル管理部、とを備え、
前記負荷レベル管理部は、前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、前記データ処理部が処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行する、
ことを特徴とする。

この保守管理システムによれば、前記負荷レベル管理部が前記処理を実行することにより、前記データ処理部の負荷に影響を及ぼす単位時間あたりのデータ処理量をデータ項目単位で変更できる。したがって、前記データ処理部のデータ処理にかかる負荷のレベルが大きい時には、負荷を削減し、過負荷になるのを避けることができる。しかも、データ項目単位で調整できるので、各データ項目の重要度や時間周期の特性に合わせて適正化した状態で負荷を削減できる。

更にこの保守管理システムによれば、前記データ処理部の負荷が大きくなった場合でも、高い優先度が割り当てられた各データ項目を確実に処理することができ、優先度が低い各データ項目の処理を間引く、すなわち省略することにより、前記データ処理部の負荷を減らすことができる。

（２）上記（１）に記載の保守管理システムにおいて、
前記負荷レベル管理部は、各データ項目のうち、装置故障との関連性が高い項目との相関性に応じて、該当するデータ項目の優先度、または各データ項目を処理する時間間隔を動的に調整する、
ことを特徴とする。

この保守管理システムによれば、各データ項目のそれぞれについて、必要性の変動を前記優先度、または時間間隔に動的に反映することにより、実際に処理するデータ項目を最適化できる。例えば、正常な範囲を外れたような異常値が現れている特定のデータ項目については、故障が発生しているか、または故障の原因になる可能性が高いので、通常は優先度の低いデータ項目であっても、高い頻度で監視することが望まれる。このような必要性の変動を、前記優先度、または時間間隔に動的に反映できる。

（３）上記（２）に記載の保守管理システムにおいて、
前記負荷レベル管理部は、少なくとも異常値が発生したデータ項目の優先度を上げる、または異常値が発生したデータ項目を処理する時間間隔を小さくする、
ことを特徴とする。

この保守管理システムによれば、異常値が発生したデータ項目の優先度を上げることにより、通常は優先度の低いデータ項目であっても優先的に処理できる。また、異常値が発生したデータ項目を処理する時間間隔を小さくすることにより、通常は時間間隔の大きいデータ項目であっても短い周期で繰り返し処理できる。

（４）上記（１）に記載の保守管理システムにおいて、
前記負荷レベル管理部は、各データ項目におけるデータの絶対値および時系列変化の傾向に基づき、前記データ処理部の処理対象のデータ項目の優先度またはデータ取得間隔にフィードバックする、
ことを特徴とする。

この保守管理システムによれば、各データ項目におけるデータの傾向を観察した結果を各データ項目の優先度などの属性にフィードバックできる。これにより、前記データ処理部の処理対象のデータ項目を適正化できる。例えば、一定時間に亘って数値がほとんど変化しなかったデータ項目について、優先度を下げるかまたは処理の時間周期を長い状態に変更することが想定される。これにより、管理状態の結果に大きな影響を及ぼすことなく、前記データ処理部のデータ処理にかかる負荷を削減できる。

（５）上記（４）に記載の保守管理システムにおいて、
前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および／または一定期間に亘って変化しないデータ項目を処理対象から除外する、
ことを特徴とする。

この保守管理システムによれば、前記業務装置の故障との関係性が高いデータ項目との相関性が低いデータ項目や、一定期間変化しないデータ項目を処理対象から除外することにより、管理状態の結果に大きな影響を及ぼすことなく、前記データ処理部のデータ処理にかかる負荷を削減できる。

（６）上記（４）の保守管理システムにおいて、
前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および／または一定期間に亘って変化しないデータ項目を処理する時間間隔を倍にすることで、前記データ項目の処理を間引きする、
ことを特徴とする。

この保守管理システムによれば、間引きによりデータ項目毎に異なる取得周期で処理されるので、優先度の低いデータ項目の取得周期を大きくし、負荷を効率的に削減できる。また、複数のデータ項目の取得周期が規定の周期の倍数で割り当てられるので、この間引きが複数のデータ項目の間の相関性評価へ及ぼす影響を抑制できる。

（７） それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムを制御するためのデータ処理方法であって、
前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データのデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了し、
前記保守管理システムのデータ処理にかかる負荷のレベルを監視し、
前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行し、
前記負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する、
ことを特徴とする。

このデータ処理方法によれば、前記処理を実行することにより、データ処理の負荷となる単位時間あたりのデータ処理量をデータ項目単位で変更できる。したがって、データ処理にかかる負荷のレベルが大きい時には、負荷を削減し、過負荷になるのを避けることができる。しかも、データ項目単位で調整できるので、各データ項目の重要度や時間周期の特性に合わせて適正化した状態で負荷を削減できる。更にこの保守管理システムによれば、前記データ処理部の負荷が大きくなった場合でも、高い優先度が割り当てられた各データ項目を確実に処理することができ、優先度が低い各データ項目の処理を間引く、すなわち省略することにより、前記データ処理部の負荷を減らすことができる。

本発明の保守管理システムおよびデータ処理方法によれば、管理対象側で送信前のデータを蓄積する必要がないので、障害の可能性等に関する検出の遅延を防止できる。また、管理対象の複数の装置がそれぞれ複数種類のデータを送信する場合に、データの種類毎の重要度や特性を考慮して適正化しつつ、管理側における負荷を削減し、過負荷になるのを防止できる。

本発明の実施形態における複数の管理対象と管理システムとの接続状態の例を示すブロック図である。 管理対象のテレメトリ送信データおよび管理システムのテレメトリ受信データの例を示す模式図である。 管理システムにおける機能上の構成例を示すブロック図である。 取得設定ファイルＣｆ２の構成例を示す模式図である。 取得設定ファイルＣｆ２の構成例を示す模式図である。 負荷レベル管理テーブルの構成例を示す模式図である。 管理システムのデータ受信部内のデータ処理概要を示すフローチャートである。 管理システムの負荷を制御するための処理概要を示すフローチャートである。 図８中のステップＳ１３の詳細を示すフローチャートである。 図８中のステップＳ１４の詳細を示すフローチャートである。 図８中のステップＳ１７の詳細を示すフローチャートである。 管理対象のデータ配信の例を示す模式図である。 管理システムの負荷状況の変化傾向を示すグラフである。 管理対象および管理システムにおける経時変化と複数の状態との関係を表す状態遷移図である。 管理システムの負荷に応じてデータ取得項目を制御する場合の動作例を示すシーケンス図である。 管理システムの負荷に応じてデータ配信間隔を制御する場合の動作例の前半を示すシーケンス図である。 管理システムの負荷に応じてデータ配信間隔を制御する場合の動作例の後半を示すシーケンス図である。

本発明の実施形態について各図を参照しながら以下に説明する。
＜複数の管理対象と管理システムとの接続状態の例＞
本発明の実施形態における複数の管理対象と管理システムとの接続状態の例を図１に示す。

図１に示した例では、複数の業務装置Ｇ０１～Ｇ０７が通信ネットワークＮＷに接続されている。業務装置Ｇ０１～Ｇ０７のそれぞれは、例えば様々な通信サービスを提供するために利用されるサーバや、伝送装置であり、２４時間絶え間なくサービスを継続する必要がある。業務装置Ｇ０１～Ｇ０７のそれぞれが、管理システム１０の管理対象である。

管理システム１０は、本発明の保守管理システムに相当する。また、管理システム１０が本発明のデータ処理方法を実施する。この管理システム１０は、次世代のキャリアネットワークを構成するネットワーク装置とサービス制御層サーバ群の装置レベル、およびネットワークレベルの保守、運用を支援するオペレーションシステム（ＯｐＳ）に含まれる装置であり、通信ネットワークＮＷ内で起きている状況をリアルタイム把握するための機能を有する。すなわち、各業務装置Ｇ０１～Ｇ０７の稼働状況や、故障などの不具合発生の可能性を検知するために利用される。

したがって、管理システム１０は、各業務装置Ｇ０１～Ｇ０７からそれぞれの状態を表すデータを収集する必要がある。本実施形態では、業務装置Ｇ０１～Ｇ０７のそれぞれが、テレメトリのデータ配信機能を搭載している。すなわち、各業務装置Ｇ０１～Ｇ０７は、事前に決められた時間周期で、データを配信することができる。管理システム１０は、テレメトリ通信経路２２を経由して、業務装置Ｇ０１～Ｇ０７のそれぞれが配信するデータを受信し取得することができる。また、管理システム１０は、業務装置Ｇ０１～Ｇ０７のそれぞれにおけるデータ配信頻度を設定することができる。

すなわち、テレメトリ技術を利用しているので、業務装置Ｇ０１～Ｇ０７のそれぞれの主導によりプッシュ型のデータ配信を実施する。テレメトリの場合は、業務装置Ｇ０１～Ｇ０７は、管理システム１０からの要求を解釈したり、応答を返す必要がないため、業務装置Ｇ０１～Ｇ０７における通信の負荷が小さい。したがって、業務装置Ｇ０１～Ｇ０７は、リアルタイム性の高いデータを配信することができる。

管理システム１０は、業務装置Ｇ０１～Ｇ０７が配信したデータをそれぞれ取得してデータ処理した結果をテレメトリデータベースＤＢ１に登録する。したがって、テレメトリデータベースＤＢ１にアクセス可能な各装置は、テレメトリデータベースＤＢ１に登録されているデータに基づいて、業務装置Ｇ０１～Ｇ０７のそれぞれを含む通信ネットワークＮＷの状態をリアルタイムで把握できる。

通信ネットワークＮＷを管理している管理者等は、管理者端末２１を利用して管理システム１０に接続することができる。例えば、管理者は、管理者端末２１からの入力操作により管理システム１０に指示を与え、業務装置Ｇ０１～Ｇ０７のそれぞれのデータ配信頻度に関する初期状態を決定したり、必要に応じて設定変更を行うことができる。

一方、業務装置Ｇ０１～Ｇ０７のそれぞれは様々なデータを周期的に配信する。また、通信ネットワークＮＷに接続される業務装置Ｇ０１～Ｇ０７の数が増える可能性もある。そして、管理システム１０が取得するデータのリアルタイム性を向上させるために、業務装置Ｇ０１～Ｇ０７のデータ配信周期を短くすると、管理システム１０が受け取るデータ量が膨大になり、負荷増大状態や空き容量減少状態になる。

すなわち、管理システム１０が受け取る１回あたりのデータ取得量ＤＴは次式で計算される。
ＤＴ＝Ｎｇ×Ｎｐ×Ｎｉ×Ｎｓ
但し Ｎｇ：管理する業務装置の装置台数
Ｎｐ：通信で使用するポート数
Ｎｉ：監視項目数
Ｎｓ：データサイズ［ｂｉｔ］

つまり、データ配信周期を短くすると、管理システム１０内でデータ処理能力の限界に近づき、または限界を超えるため、管理システム１０が受け取ったデータの全てを処理しきれなくなった場合が負荷増大状態である。また、管理システム１０が大量のデータを受信すると、テレメトリデータベースＤＢ１にも大量のデータが登録されるので、空き容量減少状態になる。後述するように、本実施形態の管理システム１０は、これら負荷増大状態や空き容量減少状態を防止するための特別な機能を備えている。

＜テレメトリ送信データ、テレメトリ受信データの例＞
管理対象のテレメトリ送信データおよび管理システムのテレメトリ受信データの例を図２に示す。

図２に示すように、業務装置Ｇ０１が配信するテレメトリ送信データＤ０１の中には種類の異なる様々な項目のデータが含まれている。同様に、業務装置Ｇ０２が配信するテレメトリ送信データＤ０２の中にも種類の異なる様々な項目のデータが含まれている。そして、管理システム１０が業務装置Ｇ０１～Ｇ０７から受け取るテレメトリ受信データＤｘの中にも、種類の異なる様々な項目のデータが含まれている。

ここで、管理システム１０の負荷が増大し処理しきれない状態に近づいた場合、管理システム１０はデータ処理量を削減する必要がある。一般的なデータ削減方法の場合、管理システム１０はテレメトリ受信データＤｘの中から、業務装置Ｇ０１～Ｇ０７の単位で選択的にデータを削減するか、あるいは処理しきれない任意項目のデータを削減することになる。

しかし、テレメトリ受信データＤｘの項目の中には、短い周期で監視することが求められるデータ項目や、監視の周期を大きくしても問題のないデータ項目などがある。しかも、いずれのデータ項目を短い周期で監視すべきか否かは、状況に応じて動的に変化する。したがって、一般的なデータ削減方法の場合には、短い周期で監視すべき重要な項目のデータまで削減されることになり、このオペレーションシステム（ＯｐＳ）が故障等を検知する際の性能低下に繋がる。本実施形態の管理システム１０においては、後述するように、項目毎のデータの優先度などを考慮してデータ処理量を減らし、管理システム１０の負荷を調整することができる。

＜管理システムの構成＞
管理システム１０における機能上の構成例を図３に示す。なお、図３に示した業務装置Ｇｘは、図１中の業務装置Ｇ０１～Ｇ０７のそれぞれに相当する。つまり、実際には複数台の業務装置Ｇｘが管理システム１０に接続されている。

図３に示したように、この管理システム１０はデータ受信部１１、取得設定ファイル管理部１２、データ傾向測定部１３、判断部１４、ＯｐＳ負荷レベル管理部１５、および異常検知部１６を備えている。また、取得設定ファイル管理部１２の中には優先度管理部１２ａ、データ取得間隔管理部１２ｂ、取得設定部１２ｃ、および重み設定テーブル管理部１２ｄが含まれている。

なお、管理システム１０の実体は、一般的なサーバなどと同様に、コンピュータのハードウェア、基本ソフトウェア（オペレーティングシステム）、および専用のアプリケーションソフトウェアにより構成される。勿論、管理システム１０を仮想化したシステムとして構成することもできる。また、管理システム１０を構成する各要素は、同じサーバ上に配置してもよいし、それぞれ独立した別のサーバに配置してもよい。

データ受信部１１は、各業務装置Ｇｘがテレメトリ通信経路２２ａを経由して配信したデータを受信し、予め定められたデータ処理を施してその処理結果のデータをテレメトリデータベースＤＢ１に登録する。データ受信部１１が業務装置Ｇｘから受信したデータのうち未処理のデータは一時的にバッファ１１ａに保持される。

一方、業務装置Ｇｘがテレメトリ通信経路２２ａにより配信するデータの配信頻度、すなわち配信を繰り返す時間周期の長さなどの配信条件は、業務装置Ｇｘが読み取り可能な取得設定ファイルＣｆ１に保持されたデータにより規定される。

また、管理システム１０内のデータ受信部１１が受信した内容をデータ処理する条件については、データ受信部１１が読み取り可能な取得設定ファイルＣｆ２に保持されたデータにより規定される。

取得設定ファイル管理部１２は、取得設定ファイルＣｆ１およびＣｆ２の内容を管理している。取得設定ファイル管理部１２内の優先度管理部１２ａは、取得設定ファイルＣｆ２の内容のうちデータ受信部１１がデータ処理する際のデータ項目の優先度を管理している。

また、データ取得間隔管理部１２ｂは、取得設定ファイルＣｆ１の内容のうち、業務装置Ｇｘがデータを配信する際の間隔、すなわち配信を繰り返す時間周期をデータ項目毎に規定するデータを管理している。

また、取得設定部１２ｃは、管理者端末２１を操作する管理者の入力に従い、各取得設定ファイルＣｆ１、Ｃｆ２の内容の初期値を定めたり、各取得設定ファイルＣｆ１、Ｃｆ２の内容を必要に応じて更新するための処理を行う。取得設定部１２ｃが取得設定ファイルＣｆ１を変更する場合には、制御用通信経路１８を経由して、管理システム１０が業務装置Ｇｘに指示を与える。

重み設定テーブル管理部１２ｄは、取得設定ファイルＣｆ２の内容のうち、データ受信部１１がデータ処理する際のデータ項目毎の重みを個別に調整するために用意されたテーブルを管理している。

データ傾向測定部１３は、データ受信部１１が業務装置Ｇｘから受信したデータ、またはテレメトリデータベースＤＢ１に登録されたデータの絶対値および時系列変化の傾向をデータ項目毎にそれぞれ観察するための測定を実施する。

判断部１４は、データ傾向測定部１３が測定したデータ項目毎の傾向を、取得設定ファイル管理部１２の制御にフィードバックし、管理システム１０の制御を適正化するための判断を実施する。具体例としては、判断部１４が人工知能（ＡＩ）やルールベースを利用して判断を実施する。例えば、複数のデータ項目の間の相関性や、特定のデータ項目と何らかの故障との相関性について、過去のデータ傾向から判明している各種ルールや、リアルタイムのデータ観察により新たに発見したルールなどを適用することにより、総合的に判断する。

ＯｐＳ負荷レベル管理部１５は、管理システム１０のデータ受信部１１におけるデータ処理の負荷レベルを管理する。ＯｐＳ負荷レベル管理部１５は、例えば、データ受信部１１内のＣＰＵ使用率、メモリ使用率、テレメトリデータベースＤＢ１を保持する記憶装置の使用率などの最新の値および変化の傾向から、データ処理にかかる負荷のレベルを管理している。また、負荷のレベルが大きくなった場合に、全てのデータを処理しきれなくなる前に、ＯｐＳ負荷レベル管理部１５は取得設定ファイル管理部１２に対して負荷の適正化を指示する。

異常検知部１６は、データ受信部１１が各業務装置Ｇｘから受信した項目毎の各々のデータについて、あるいは業務装置Ｇｘ側で生成された各データについて、異常値か否かを検知する。すなわち、通常とは異なる異常な値のデータが現れた場合に、その異常を異常検知部１６が検知し、重み設定テーブル管理部１２ｄに指示を与える。この指示に従い、データ受信部１１が処理するデータのデータ項目毎の重み付けを変更する。

例えば、業務装置Ｇｘが光伝送装置である場合には、業務装置Ｇｘ内のレーザ増幅器における光出力を表すデータ項目の値も、業務装置Ｇｘが配信する。このような光出力の値は、半導体の劣化により徐々に低下する傾向があるが、この変動周期は非常に長い。つまり、通常の状態であれば光出力の値の変動は非常に小さい。したがって、通常は光出力の値を頻繁に監視する必要はなく、監視の重要度も比較的低いので該当する項目のデータを間引くことができる。

しかし、半導体が劣化して故障が発生する可能性が高い状態になると、光出力の値に、通常とは異なる急激な変化が現れる傾向がある。このような急激な変化が発生した際に、異常検知部１６がそれを検知して警報を出力する。重み設定テーブル管理部１２ｄは、異常検知部１６の警報により、該当するデータ項目の重要度が高くなったことを反映するために、該当するデータ項目の重みを大きくする。その結果が取得設定ファイルＣｆ１、Ｃｆ２の少なくとも一方の内容に反映される。

＜取得設定ファイルＣｆ２の構成例＞
取得設定ファイルＣｆ２の構成例を図４および図５に示す。
図４および図５に示した取得設定ファイルＣｆ２は、優先度欄Ｃｆ２ａ、項目欄Ｃｆ２ｂ、および重み欄Ｃｆ２ｃを含んでいる。また、図４および図５の例では、各業務装置Ｇｘが配信するデータの中に、「メモリ使用率（メモリ）」、「ＣＰＵ使用率（ＣＰＵ）」、「システムログ（Syslog）」、・・・の各データ項目が含まれる場合を想定している。

優先度欄Ｃｆ２ａの各番号は「１」、「２」、「３」、・・・の順にデータ処理の優先度が高いことを意味している。また、項目欄Ｃｆ２ｂはそれぞれの優先度に対応付けたデータ項目の並び順を表している。つまり、図４の例では優先度が「１」の「メモリ使用率」の項目を最優先で処理し、優先度が「２」の「ＣＰＵ使用率」の項目を２番目の優先順で処理し、優先度が「３」の「システムログ」の項目を３番目の優先順で処理することを意味している。

例えば、取得設定ファイルＣｆ２の内容が図４の状態である時に、「ＣＰＵ使用率」の項目に関する異常値を異常検知部１６が検知すると、異常検知部１６がその警報を発生する。そして、重み設定テーブル管理部１２ｄは、図４の取得設定ファイルＣｆ２における「ＣＰＵ使用率」の項目の重みを「１」から「２」に変更する。

その場合、優先度管理部１２ａは「ＣＰＵ使用率」の項目の重みの変化を反映するように項目の優先度を変更する。その結果、図５に示したように取得設定ファイルＣｆ２の内容が変更される。つまり、図４の例では「ＣＰＵ使用率」の項目の優先度は「メモリ使用率」の項目よりも低いが、図５の例では「ＣＰＵ使用率」の重みが通常の「１」よりも大きいことを反映して「ＣＰＵ使用率」の項目の優先度を最上位に変更し、項目の並びを変更している。

＜負荷レベル管理テーブルの構成例＞
ＯｐＳ負荷レベル管理部１５が管理している負荷レベル管理テーブル１５ａの構成例を図６に示す。

図６に示した負荷レベル管理テーブル１５ａは、「負荷レベル（レベル）」と、「ＣＰＵ使用率」と、「処理可能な項目計」との関係を表すデータを保持している。負荷レベル管理テーブル１５ａにおける「ＣＰＵ使用率」は、図３に示したデータ受信部１１がデータ処理するために用意されたＣＰＵの使用率を表している。

図６に示した例では、「負荷レベル」は「１」～「４」の４種類存在する。「負荷レベル」の「１」は、「０～５０％］」の「ＣＰＵ使用率」に対応し、処理可能な項目計の内容が「全て：ＡＬＬ」であり項目数の制限はない。

また、「負荷レベル」の「２」は、「５１～７０％」の「ＣＰＵ使用率」に対応し、処理可能な項目計の内容により上限数が「１５」に制限されている。「負荷レベル」の「３」は、「７１～９０％」の「ＣＰＵ使用率」に対応し、処理可能な項目計の内容によりその上限数が「１０」に制限されている。「負荷レベル」の「４」は、「９１～１００％」の「ＣＰＵ使用率」に対応し、処理可能な項目計の内容によりその上限数が「５」に制限されている。なお、「ＣＰＵ使用率」の小数点以下の数値は切り下げまたは切り上げとする。

図６に示した例では、管理システム１０の負荷が高い事を表す指標として「ＣＰＵ使用率」を採用した場合を想定しているが、他の指標を採用してもよい。例えば、メモリ使用率、ページング使用率、ディスクＩ／Ｏ使用率、スワッピング使用率のいずれかのように、様々なＫＰＩ（Key Performance Indicators）の中から必要に応じて選択できる。ＫＰＩは、実装したい目的をベースに測定可能な数値を意味する。また、複数の指標を組み合わせて使用してもよい。

＜データ処理の概要＞
管理システム１０のデータ受信部１１におけるデータ処理の概要を図７に示す。
すなわち、データ受信部１１内でデータ処理を実行するために割り当てられたＣＰＵが、図７の処理を実行する。

なお、図７の例では１つの業務装置Ｇｘから配信された受信データのみを処理する場合を示しているが、実際には図１に示したように複数の業務装置Ｇ０１～Ｇ０７がそれぞれ配信したデータを、管理システム１０がほぼ同時に受信して処理する。図７の処理について以下に説明する。

データ受信部１１は、最初にステップＳ０１で取得設定ファイルＣｆ２を読み込み、その設定内容を把握する。データ受信部１１は、例えば、図４、図５に示した取得設定ファイルＣｆ２のように、処理対象の複数のデータ項目、各々のデータ項目に割り当てられた優先度、重みなどデータ処理対象に関する項目毎の取得条件を把握する。

データ受信部１１は、ステップＳ０２で、各業務装置Ｇｘがテレメトリ通信経路２２を経由して配信するデータを項目毎にそれぞれ受信する。データ受信部１１が受信した各項目の内容は、データ受信部１１がデータ処理を行うまでバッファ１１ａで一時的に保持される。

データ受信部１１は、ステップＳ０３で、取得設定ファイルＣｆ２における優先度の高い項目から順番に受信データの項目を選択し、それぞれの項目のデータに対して順次にデータ処理を実行する。処理後のデータはテレメトリデータベースＤＢ１に登録される。

例えば、図４に示した内容の取得設定ファイルＣｆ２を読み込んだ場合には、データ受信部１１は優先度の順番に従い、「メモリ使用率」、「ＣＰＵ使用率」、「システムログ」、・・・の各項目をデータ処理する。

データ受信部１１は、ステップＳ０４で、送信元が同じ業務装置Ｇｘのデータの中で、今回処理したデータ項目数Ｎｔを把握する。実際には、優先度欄Ｃｆ２ａの優先度順に従い優先度「１」のデータ項目、優先度「２」のデータ項目、優先度「３」のデータ項目を処理するので、今回処理したデータ項目数Ｎｔは最後に処理したデータ項目の優先度と同じである。

データ受信部１１は、ステップＳ０５で、最新の項目数制限値Ｎｔｍａｘを取得する。この項目数制限値Ｎｔｍａｘは、図６に示した負荷レベル管理テーブル１５ａ内の「処理可能な項目計」の値に相当し、負荷レベルの１～４に対してそれぞれ異なる値が採用される。例えばデータ受信部１１の最新の負荷レベルが「１」であれば、項目数制限値Ｎｔｍａｘは制限なしになり、負荷レベルが「２」であれば、項目数制限値Ｎｔｍａｘは「１５」になる。同様に、負荷レベルが「３」の場合の項目数制限値Ｎｔｍａｘは「１０」、負荷レベルが「４」の場合の項目数制限値Ｎｔｍａｘは「５」になる。

データ受信部１１は、次のステップＳ０６でデータ項目数Ｎｔと項目数制限値Ｎｔｍａｘとを比較し、データ項目数Ｎｔが項目数制限値Ｎｔｍａｘ以上になるとステップＳ０７に進む。データ項目数Ｎｔが項目数制限値Ｎｔｍａｘ未満の場合は、データ受信部１１はステップＳ０３に戻って上記と同様の処理を繰り返す。

データ受信部１１は、ステップＳ０７で、送信元が同じ業務装置Ｇｘの受信データに対する今回のデータ処理を終了し、最初のデータ項目の位置に戻る。したがって、優先度が項目数制限値Ｎｔｍａｘ以上の残りの未処理のデータ項目については、今回のデータ処理の対象外となり、不要なのでバッファ１１ａから破棄される。

つまり、データ受信部１１がステップＳ０３～Ｓ０６で１回あたりデータ処理する項目数が項目数制限値Ｎｔｍａｘに制限されるので、未処理のデータ項目分だけデータ受信部１１における負荷が軽減される。しかも、優先度が高い順番に従って各項目を処理するので、比較的優先度の高い項目のデータが欠落するのを避けることができる。

データ受信部１１は、ステップＳ０８で設定変更の有無を識別し、変更ありの場合は次のステップＳ０９に進み、更新された取得設定ファイルＣｆ２の読み込みを実施する。例えば、管理者が管理者端末２１から取得設定ファイルＣｆ２の更新を指示した場合や、判断部１４のフィードバック制御により取得設定ファイルＣｆ２が更新されたような場合には、更新後の取得設定ファイルＣｆ２の内容がステップＳ０９でデータ受信部１１の処理に反映される。

なお、異常値を示している項目データについては、負荷の大きさにかかわらず、できる限り頻繁に監視したいので、その変動傾向に基づいて重み付けを行い、状況に応じて動的に処理の優先度を変動させる。また、この重み付けに関し、該当データの傾向観察の結果をフィードバックするように制御してもよい。

なお、図７に示したデータ処理などにより間引きされ、欠落したデータ項目については、同じデータ項目に関する時系列変化の傾向に基づき、近似曲線を用いて推定値を計算しデータの補完を実施する。

＜管理システムの負荷を制御するための処理＞
管理システム１０の負荷を制御するための処理の概要を図８に示す。なお、図８に示した各処理を実行する順番やタイミングは必要に応じて変更できる。

管理システム１０の取得設定部１２ｃは、ユーザ、すなわち管理者端末２１に対する管理者の入力操作に従い、ステップＳ１１で、事前に定めたデータ取得項目毎の優先度等を初期値に定め、更にユーザ入力も受け付ける。ここで決定された初期値または入力された値が、取得設定部１２ｃにより各取得設定ファイルＣｆ１、Ｃｆ２の内容に反映される。

また、管理システム１０の動作開始後に、必要に応じて管理者端末２１から入力されるユーザ入力があった場合には、取得設定部１２ｃは、ステップＳ１２でこの入力を受け付けて項目毎の優先度等を変更する。

ステップＳ１３では、優先度管理部１２ａが「優先度の監視処理」を実行し、データ項目毎の優先度の割り当てを動的に変更する。この処理の詳細については後で説明する。
ステップＳ１４では、ＯｐＳ負荷レベル管理部１５が「負荷レベルの監視処理」を実行し、データ受信部１１のデータ処理に関する負荷レベル、およびその動的な変動を把握する。この処理の詳細については後で説明する。

ステップＳ１５では、異常検知部１６が異常値の検出により警報を出力したか否かを重み設定テーブル管理部１２ｄが識別する。異常値を検出した場合、重み設定テーブル管理部１２ｄは、次のステップＳ１６を実行する。

ステップＳ１６では、異常検知部１６が異常値を検出したデータ項目について、重み設定テーブル管理部１２ｄが重みを自動的に調整する。例えば、取得設定ファイルＣｆ２の内容が図４に示した状態の時に、「ＣＰＵ使用率」が異常値に変化した場合には、「ＣＰＵ使用率」の項目に対する重みを「１」から「２」に変更する。これにより、図５に示したように「ＣＰＵ使用率」の優先度が上がる。なお、図８には示されていないが、異常値が検出された項目について、データの値が正常な範囲に戻ったような場合は、重み設定テーブル管理部１２ｄが該当する項目の重みを通常の値である「１」に戻す。

ステップＳ１７では、データ取得間隔管理部１２ｂが、「データ取得間隔の調整」処理を実行し、取得設定ファイルＣｆ１の内容を更新する。この処理の詳細については後で説明する。

ステップＳ１８では、データ傾向測定部１３がデータ受信部１１の受信したデータまたはテレメトリデータベースＤＢ１に登録されたデータについて、データ項目毎の変化の傾向を測定する。

ステップＳ１９では、判断部１４が人工知能やルールベースを用いて、データ傾向測定部１３の測定結果を分析し、複数のデータ項目間の相関性や、各データ項目と各業務装置Ｇｘの故障との相関性などについて判断を実施する。その判断の結果が、取得設定ファイル管理部１２にフィードバックされる。このフィードバックにより、取得設定ファイル管理部１２は項目毎のデータの優先度、項目毎のデータ取得間隔、項目毎の重みなどを動的に調整する。

＜「優先度の監視処理」の詳細＞
図８中のステップＳ１３の詳細を図９に示す。図９の処理について以下に説明する。
管理システム１０のデータ受信部１１は、ステップＳ２１の処理を定期的に繰り返し実行する。すなわち、管理対象の複数の業務装置Ｇｘがそれぞれ定期的に配信するデータを、データ受信部１１が業務装置Ｇｘ毎に受信する。データ受信部１１が１回の処理で受信するデータは、例えば図２に示したテレメトリ送信データＤ０１のように複数項目のデータを含んでいる。

管理システム１０の優先度管理部１２ａは、ステップＳ２２で判断部１４の出力や、管理者端末２１からのユーザ入力を監視することにより、データ項目毎の優先度の変更要求の有無を識別する。優先度の変更要求があった場合は、優先度管理部１２ａは次のステップＳ２３に進み、取得設定ファイルＣｆ２における項目毎の優先度の順序を変更する。

例えば、図４に示した取得設定ファイルＣｆ２の内容の状態で、各項目の重みとは無関係に、優先度を「ＣＰＵ使用率」、「メモリ使用率」、「システムログ」の順番に変更する要求があった場合には、優先度管理部１２ａが図５に示した取得設定ファイルＣｆ２のように、各項目の並び順を「ＣＰＵ使用率」、「メモリ使用率」、「システムログ」に変更する。

＜「負荷レベルの監視処理」の詳細＞
図８中のステップＳ１４の詳細を図１０に示す。図１０の処理について以下に説明する。
図９のステップＳ２１と同様に、管理システム１０のデータ受信部１１は、図１０のステップＳ３１の処理を定期的に繰り返し実行し、管理対象の複数の業務装置Ｇｘがそれぞれ定期的に配信するデータを受信する。

管理システム１０のＯｐＳ負荷レベル管理部１５は、データ受信部１１のデータ処理に影響を及ぼす負荷についてその大きさおよび変動を常時監視している。そして、データ受信部１１の負荷が急激に変化したか否かと、負荷の大きさが閾値を超えたか否かをステップＳ３２で識別し、この条件を満たす場合に次のステップＳ３３に進む。

ステップＳ３３では、ＯｐＳ負荷レベル管理部１５は、データ受信部１１における処理可能項目数を変更する。この処理可能項目数は、図６に示した負荷レベル管理テーブル１５ａ中の「処理可能な項目計」、および図７に示したステップＳ０５、Ｓ０６中の項目数制限値Ｎｔｍａｘに相当する。

例えば、ＯｐＳ負荷レベル管理部１５の検出した負荷レベルが、「２」から「３」に変化した場合には、負荷レベル管理テーブル１５ａから負荷レベル「３」の「処理可能な項目計」の「１０」を取得して、項目数制限値Ｎｔｍａｘを「１０」に変更する。この変更により、データ受信部１１が図７のステップＳ０３～Ｓ０６でデータ処理する１回あたりのデータ項目数が「１０」に制限される。

＜「データ取得間隔の調整」の詳細＞
図８中のステップＳ１７の詳細を図１１に示す。図１１の処理について以下に説明する。
図９のステップＳ２１と同様に、管理システム１０のデータ受信部１１は、図１１のステップＳ４１の処理を定期的に繰り返し実行し、管理対象の複数の業務装置Ｇｘがそれぞれ定期的に配信するデータを受信する。

管理システム１０の判断部１４は、データ受信部１１が受信した各項目のデータについて、その変化の傾向をデータ傾向測定部１３の出力で判断し、各項目データの値の変動が閾値以内かどうかをステップＳ４２で識別する。変動が閾値以内であればステップＳ４３に進み、閾値を超える場合はステップＳ４８に進む。

また、判断部１４は、各業務装置Ｇｘの取得設定ファイルＣｆ１の内容を制御するためのテーブルを備えている。このテーブルは、業務装置Ｇｘがテレメトリ通信経路２２で配信する複数のデータ項目の一覧と、データ項目毎の重みと、データ項目毎の送信時間の「間隔」を表す情報を保持している。

判断部１４は、上記テーブルで該当項目の重みを参照し、この重みをステップＳ４３で「１」と比較する。そして、重みが「１」と等しい場合はステップＳ４４に進み、重みが「１」以外であればステップＳ４９に進む。

判断部１４は、データ項目毎に個別に用意したカウンタを管理している。また、判断部１４は、該当する項目のカウンタの値をステップＳ４４でインクリメント（＋１）し、その結果をステップＳ４５で判定する。そして、該当するカウンタの値が「１０」または「２０」の場合はステップＳ４６に進み、該当するカウンタの値が「３０」の場合はステップＳ４７に進み、それ以外の値であればステップＳ４１に戻る。

ステップＳ４６では、判断部１４は、上記テーブル上で該当する項目のデータに割り当てられている「間隔」をそれ以前の２倍に変更する。なお、この「間隔」については初期状態では標準値の１倍の値が割り当てられている。そして、上記カウンタが「１０」になった時には、ステップＳ４６で「間隔」が標準値の２倍の値に変更される。更に、上記カウンタが「２０」になった時には、もう一度ステップＳ４６が実行されるので、「間隔」が標準値の４倍の値に変更される。

また、上記カウンタが「３０」になると、判断部１４は、ステップＳ４７で上記テーブルにおけるデータ項目の一覧から、該当する項目を削除する。また、この時に判断部１４は、上記カウンタの値を「０」にクリアする。

ステップＳ４８では、判断部１４が上記テーブル上で該当する項目の「間隔」とその標準値の１倍とを比較する。そして、「間隔」がその標準値の１倍でなければ次のステップＳ４９に進み、「間隔」がその標準値の１倍と一致する場合はステップＳ４１に戻る。

ステップＳ４９では、判断部１４は、上記テーブルにおける該当する項目の「間隔」をその標準値の１倍にリセットする。
判断部１４が管理している上記テーブルの内容については、例えばデータ取得間隔管理部１２ｂが定期的に実行する処理により、各業務装置Ｇｘの取得設定ファイルＣｆ１の内容に反映される。その場合、各業務装置Ｇｘは取得設定ファイルＣｆ１の内容に従い、テレメトリ通信経路２２で配信するデータ項目と、項目毎の配信間隔を変更することができる。

つまり、図１１に示した処理を実行する場合には、値の変動が小さいデータ項目については、時間の経過につれて配信の間隔がステップＳ４６で標準値の２倍、または４倍に変更される。但し、重みが「１」以外のデータ項目や、変動が大きくなったデータ項目については、配信の間隔がステップＳ４９で標準値の１倍に戻される。また、値の変動が小さい時間が長くなると、その項目はステップＳ４７で削除される。そして、業務装置Ｇｘは削除された該当項目を次回の配信対象から除外する。

＜負荷特性の変化例＞
管理対象のデータ配信と管理システムの負荷特性との関係の例を図１２Ａと図１２Ｂに示す。
図１２Ａに示した例では、業務装置Ｇｘが各時刻「ｔ＝１」、「ｔ＝２」、「ｔ＝３」において、業務装置Ｇｘ内で生成したデータをテレメトリにより管理システム１０に配信する場合を想定している。また、図１２Ａの例では、業務装置Ｇｘが配信するデータの中に「ＣＰＵ使用率」および「メモリ使用率」の項目が含まれている。

この場合、管理システム１０内のデータ傾向測定部１３の測定により、図１２Ｂに示したような状況の変化傾向を観察することができる。図１２Ｂの例では、ＣＰＵ使用率Ｌ１０ａおよびメモリ使用率Ｌ１０ｂが、時間の経過に伴って上昇している。

この場合、ＣＰＵ使用率Ｌ１０ａおよびメモリ使用率Ｌ１０ｂの絶対値や、一定時間内の変化量を所定の閾値と比較することにより、負荷増大状態Ｌｏａ、Ｌｏｂをそれぞれ検知することができる。

ＯｐＳ負荷レベル管理部１５が図１２Ｂのような負荷増大状態Ｌｏａ、Ｌｏｂを検出した場合には、例えば図１０に示したステップＳ３２からＳ３３に進むので、取得設定ファイルＣｆ２における処理可能項目数、すなわち図７中の項目数制限値Ｎｔｍａｘを減らすことができる。これにより、各業務装置Ｇｘのデータ配信状況に変化が生じない場合であっても、管理システム１０のデータ受信部１１がデータ処理するデータ項目数が削減されるので、負荷を減らすことができる。

＜状態遷移の例＞
管理対象および管理システムにおける経時変化と複数の状態との関係の例を図１３に示す。図１３において、各状態Ｃｔ１、Ｃｔ２、Ｃｔｘ、Ｃｔｙ、およびＣｔｚは、それぞれ時刻「ｔ＝１」、「ｔ＝２」、「ｔ＝Ｘ」、「ｔ＝Ｙ」、および「ｔ＝Ｚ」における業務装置Ｇｘから管理システム１０へのデータ配信を表している。

例えば管理者端末２１からのユーザ入力により、ステップＳ１０１として事前設定が行われる。これにより、取得設定ファイルＣｆ１、Ｃｆ２の初期状態が確定する。
業務装置Ｇｘは、取得設定ファイルＣｆ１の内容に従い、時刻「ｔ＝１」の状態Ｃｔ１で、「項目Ａ」、「項目Ｂ」、「項目Ｃ」、「項目Ｄ」、「項目Ｅ」、・・・の各データを一括して配信する。

また、時刻「ｔ＝２」の状態Ｃｔ２においても、業務装置Ｇｘは「項目Ａ」、「項目Ｂ」、「項目Ｃ」、「項目Ｄ」、「項目Ｅ」、・・・の各データを一括して配信する。但し、状態Ｃｔ２では管理システム１０の負荷が上昇した場合を想定しているので、ＯｐＳ負荷レベル管理部１５の検知した負荷レベルに従い、負荷を減らすことができる。

例えば、負荷レベル管理テーブル１５ａにおける「処理可能な項目計」に基づき、データ受信部１１がデータ処理する１回あたりのデータ項目数を削減することができる。従って、図１３の状態Ｃｔ２ではデータ受信部１１が優先度の高い「項目Ａ」、「項目Ｂ」だけをデータ処理して、優先度の低い「項目Ｃ」、「項目Ｄ」、「項目Ｅ」、・・・の各データはデータ処理の対象から除外している。

これにより、データ受信部１１におけるＣＰＵのデータ処理の負荷が減るので、時間の経過に伴って状態ＣｔｘではＣＰＵの状態が安定する。したがって、ＯｐＳ負荷レベル管理部１５の検出する負荷レベルが低くなり、「処理可能な項目計」を増やすことができる。そのため、図１３の状態Ｃｔｘでは、データ受信部１１が「項目Ａ」、「項目Ｂ」、「項目Ｃ」、「項目Ｄ」、「項目Ｅ」の全てをデータ処理できる。

管理者端末２１を操作する管理者は、管理システム１０の稼働状況を観察し、ステップＳ１０２で必要に応じて取得設定ファイルＣｆ１、Ｃｆ２を変更するための入力を行い、手動で現在の状況をフィードバックすることができる。例えば、図１３の状態Ｃｔｚでは、優先度の低い「項目Ｅ」をデータ処理の対象から削除するための操作を管理者が行った場合を想定している。

一方、管理システム１０のデータ傾向測定部１３は、管理システム１０が受信した「項目Ａ」、「項目Ｂ」、「項目Ｃ」、「項目Ｄ」、「項目Ｅ」、・・・のそれぞれについて、データの時系列変化を監視して観測データＤｚを生成することができる。判断部１４は、データ傾向測定部１３が生成した観測データＤｚの内容から項目毎の傾向を観察し、人工知能、またはルールベースの処理を適用し、ステップＳ１０３で自動的なフィードバック制御を行うことができる。

なお、判断部１４が観察する観測データＤｚについては、業務装置Ｇｘが配信するデータのトラフィック情報の他に、管理システム１０におけるＣＰＵの電源電圧や、ＣＰＵの温度など様々な情報を利用することが想定される。

判断部１４が人工知能を採用する場合には、把握している過去の故障パターンと、観測データＤｚとの関係などについて学習を実施しながら、今後発生するであろう故障の可能性について推定し、その結果をフィードバックする。また、判断部１４がルールベースを採用する場合には、現在の知見で分かっている複数のデータ項目間の相関性や、各データ項目と各種の故障要因との相関性を規定したルールに基づいて、観測データＤｚの傾向を判断し、その結果をフィードバックする。例えば、管理システム１０における温度上昇とそのＣＰＵ使用率との間には大きな相関があり、更にＣＰＵ使用率と装置故障との間にも相関がある。このような関係をルールベースなどで規定しておく。

ステップＳ１０３のフィードバック制御の結果、図１３の状態Ｃｔｙにおいては、取得設定ファイルＣｆ２における「項目Ｄ」の優先度が「項目Ｃ」よりも高くなった場合を想定している。その結果、前述の項目数制限値Ｎｔｍａｘの影響を受けて、優先度の低い「項目Ｃ」が間引きされている。

また、図１３に示した観測データＤｚ中の「項目Ｅ」のように長時間に亘って値がほとんど変化しない項目や、装置故障との関連性が高い「ＣＰＵ使用率」との相関性が低い項目については、監視する必要性がほとんどない。したがって、このようなデータ項目は判断部１４の判断により業務装置Ｇｘの配信対象から削除するように取得設定ファイルＣｆ１の内容を変更する。または、監視する必要性がほとんどないデータ項目については、データ受信部１１が間引きするように取得設定ファイルＣｆ２の内容に反映する。
また、観測データＤｚ中の「項目Ｅ」のように長時間に亘って値がほとんど変化しない項目や、装置故障との関連性が高い「ＣＰＵ使用率」との相関性が低い項目については、図１１に示した処理と同じように、業務装置Ｇｘが配信する時間間隔を通常の倍にすることで間引きを実施するように、取得設定ファイルＣｆ１の内容に反映する。なお、間引きにより欠落したデータ項目については、その変化の傾向から近似曲線を用いて推定した値を補完する。

なお、例えば判断部１４の人工知能、またはルールベースを用いて業務装置Ｇｘの装置種別毎に適正化されたデータ項目毎の取得間隔や優先度などのパターンを検出して保持し、このパターンを推奨内容として管理者端末２１の画面に表示してもよい。これにより、ステップＳ１０２におけるユーザ入力を支援することができる。
なお、図７に示したデータ処理においては、データ受信部１１が受信したデータをステップＳ０３で処理する際に、優先度の高い順に各データ項目を選択して処理する場合を想定している。しかし、事前に優先度が高い順番に並んだ状態で項目データが入力される場合には、単純に項目数制限値Ｎｔｍａｘと一致する項目数だけデータ処理すればよい。例えば、項目毎の優先度の内容が取得設定ファイルＣｆ１に反映される場合には、各業務装置Ｇｘは優先度の高いデータ項目から順番に並べた状態で順次に各データ項目を配信できる。その場合は、データ受信部１１は図７のステップＳ０３で受信した順番に従い、そのままの順番で各データ項目を処理することができる。

＜負荷に応じてデータ取得項目を制御する場合の動作例＞
管理システム１０がその負荷に応じてデータ取得項目を制御する場合の動作例を図１４に示す。図１４に示した動作シーケンスについて以下に説明する。

管理システム１０の取得設定部１２ｃは、手順ＳＥ０１で監視対象の業務装置Ｇｘに対してデータ配信設定を行う。その結果が、図３に示した取得設定ファイルＣｆ１の内容に反映される。

また、管理システム１０のＯｐＳ負荷レベル管理部１５は手順ＳＥ０２で管理システム１０における定常時の負荷レベルを業務装置Ｇｘに設定する。その内容が取得設定ファイルＣｆ１の内容に反映される。その結果、業務装置Ｇｘがテレメトリ通信経路２２でデータ配信する際の、すなわち手順ＳＥ０３でデータ配信する際の定常時の配信周期が決定される。つまり、業務装置Ｇｘは定期的にデータ配信を実行する。

管理システム１０のデータ受信部１１は、業務装置Ｇｘからデータ配信されたデータを受信し、手順ＳＥ０４で項目毎にデータ処理してその結果をテレメトリデータベースＤＢ１に登録する。

一方、手順ＳＥ０５においてデータ受信部１１のデータ処理にかかる負荷が定常時に比べて上昇すると、ＯｐＳ負荷レベル管理部１５が変化した負荷レベルを考慮し、手順ＳＥ０６で取得項目優先度判定を実施する。すなわち、図６に示した負荷レベル管理テーブル１５ａの「処理可能な項目計」が負荷レベルに応じて制限されるので、図７の項目数制限値Ｎｔｍａｘが減少する。

その結果、手順ＳＥ０７で管理システム１０に配信されたデータをデータ受信部１１が手順ＳＥ０８でデータ処理する際に、取得設定ファイルＣｆ２の内容、および項目数制限値Ｎｔｍａｘに従い、優先度の高い項目だけが処理され、優先度が低い残りの項目のデータは間引きされる。

一方、手順ＳＥ０９で管理システム１０の負荷が高い状況が解消されると、再びＯｐＳ負荷レベル管理部１５が最新の負荷レベルを考慮して、手順ＳＥ１０で取得項目優先度判定を実施する。すなわち、負荷レベル管理テーブル１５ａの「処理可能な項目計」の制限が負荷レベルの減少に伴って緩和されるので、図７の項目数制限値Ｎｔｍａｘが増大する。その結果、手順ＳＥ１１で配信されたデータをデータ受信部１１が手順ＳＥ１２でデータ処理する際には、優先度の比較的低い項目のデータも処理対象になり、より多くのデータ項目がテレメトリデータベースＤＢ１に登録される。

＜負荷に応じてデータ配信間隔を制御する場合の動作例＞
管理システム１０がその負荷に応じてデータ配信間隔を制御する場合の動作例を図１５および図１６に示す。動作シーケンスの前半および後半が、それぞれ図１５および図１６に示されている。図１５、図１６に示した動作シーケンスについて以下に説明する。なお、図１５に示した各手順ＳＥ２１～ＳＥ２４については、図１４の手順ＳＥ０１～ＳＥ０４と同様であるのでこれらの説明は省略する。

図１５の手順ＳＥ２５において、管理システム１０のデータ傾向測定部１３は、テレメトリデータベースＤＢ１に登録された内容に基づき、項目毎のデータの傾向を観察する。また、データ傾向測定部１３が観察した結果を利用して、手順ＳＥ２６で判断部１４が判断を実施し、図１１に示した処理を実行する。したがって、例えば長い間ほとんど値が変化しないデータ項目を見つけたような場合は、判断部１４が手順ＳＥ２７で取得間隔変更通知をデータ取得間隔管理部１２ｂに送る。

この通知に従い、取得設定ファイル管理部１２は、手順ＳＥ２８で業務装置Ｇｘの取得設定ファイルＣｆ１に対する変更設定を実施する。これにより、業務装置Ｇｘがデータ配信する際の配信対象項目が部分的に削除されたり、項目毎のデータ配信の間隔が変更される。その結果が、手順ＳＥ２９のデータ配信に反映される。

管理システム１０のデータ受信部１１は、手順ＳＥ２９で配信された各項目のデータを手順ＳＥ３０でデータ処理してその結果をテレメトリデータベースＤＢ１に登録する。この場合、手順ＳＥ２９でデータ受信部１１が受信するデータの項目数や受信間隔が変更されているので、手順ＳＥ３０でデータ受信部１１がデータ処理を実行する際の負荷の大きさは、手順ＳＥ２８が実行される前と比べて削減される。

また、図１６に示した例では、業務装置Ｇｘがそれ自身におけるＣＰＵ使用率が上昇したことを手順ＳＥ３１で検知した場合には、業務装置Ｇｘ自身が特別な制御を実施する。すなわち、取得設定ファイルＣｆ１により配信対象になっている各項目について、項目毎の重みと、負荷レベルとを考慮して手順ＳＥ３２で配信するデータ項目を削減する。例えば、重みが比較的大きい一部の項目のデータだけを手順ＳＥ３２で配信する。

この場合、手順ＳＥ３２でデータ受信部１１が受信した項目を判断部１４が手順ＳＥ３３で監視して判断し、手順ＳＥ３４で間引きリセット通知をデータ取得間隔管理部１２ｂに送る。この通知に従い、取得設定ファイル管理部１２は手順ＳＥ３５で項目毎のデータ配信の間隔を変更するように取得設定ファイルＣｆ１を設定する。

＜保守管理システムおよびデータ処理方法の利点＞
図３に示した管理システム１０においては、データ受信部１１がデータ処理を行う際に、取得設定ファイルＣｆ２の内容に基づいて図７の処理を実行し、優先度の高いデータ項目だけに絞って処理することができる。したがって、複数の業務装置Ｇｘからテレメトリにより大量のデータが配信される場合であっても、重要なデータの欠落をまねくことなく負荷を効率的に軽減できる。

また、管理システム１０はデータ項目毎の必要性に応じた重みを制御に反映し、項目毎のデータ取得間隔や処理の優先度を動的に変化させることができる。そのため、業務装置Ｇｘや管理システム１０の稼働状況が変化した場合でも、重要なデータの欠落をまねくことなく負荷を効率的に軽減できる。

また、管理システム１０は、図１３のように判断部１４が観測データＤｚの傾向を観察して管理システム１０のデータ処理にフィードバックすることができる。そのため、様々な状況の変化に対して管理システム１０が処理するデータ項目を適正化できる。

また、管理システム１０は、図１１に示した処理により、各項目のデータを配信する間隔を基準周期の倍数に従って変更するので、データの間引きが複数のデータ項目間の相関性に与える影響を抑制できる。

１０ 管理システム（保守管理システム）
１１ データ受信部（データ処理部）
１１ａ バッファ
１２ 取得設定ファイル管理部
１２ａ 優先度管理部
１２ｂ データ取得間隔管理部
１２ｃ 取得設定部
１２ｄ 重み設定テーブル管理部
１３ データ傾向測定部
１４ 判断部
１５ ＯｐＳ負荷レベル管理部（負荷レベル管理部）
１５ａ 負荷レベル管理テーブル
１６ 異常検知部
１８ 制御用通信経路
２１ 管理者端末
２２，２２ａ テレメトリ通信経路
Ｃｆ１，Ｃｆ２ 取得設定ファイル
Ｃｆ２ａ 優先度欄
Ｃｆ２ｂ 項目欄
Ｃｆ２ｃ 重み欄
Ｃｔ１，Ｃｔ２，Ｃｔｘ，Ｃｔｙ，Ｃｔｚ 状態
Ｄ０１，Ｄ０２ テレメトリ送信データ
Ｄｘ テレメトリ受信データ
Ｄｚ 観測データ
ＤＢ１ テレメトリデータベース
Ｇｘ，Ｇ０１，Ｇ０２，Ｇ０３，Ｇ０４，Ｇ０５，Ｇ０６，Ｇ０７ 業務装置
Ｌ１０ａ ＣＰＵ使用率
Ｌ１０ｂ メモリ使用率
Ｌｏａ，Ｌｏｂ 負荷増大状態
ＮＷ 通信ネットワーク
Ｎｔ データ項目数
Ｎｔｍａｘ 項目数制限値

Claims (7)

1. それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムであって、
   前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データをデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了するデータ処理部と、
   前記データ処理部のデータ処理にかかる負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する負荷レベル管理部、とを備え、
   前記負荷レベル管理部は、前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、前記データ処理部が処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行する、
   ことを特徴とする保守管理システム。
2. 請求項１に記載の保守管理システムにおいて、
   前記負荷レベル管理部は、各データ項目のうち、装置故障との関連性が高い項目との相関性に応じて、該当するデータ項目の優先度、または各データ項目を処理する時間間隔を動的に調整する、
   ことを特徴とする保守管理システム。
3. 請求項２に記載の保守管理システムにおいて、
   前記負荷レベル管理部は、異常値が発生したデータ項目の優先度を上げるか、または異常値が発生したデータ項目を処理する時間間隔を小さくする、
   ことを特徴とする保守管理システム。
4. 請求項１に記載の保守管理システムにおいて、
   前記負荷レベル管理部は、各データ項目におけるデータの絶対値および時系列変化の傾向に基づき、前記データ処理部の処理対象のデータ項目の優先度またはデータ取得間隔にフィードバックする、
   ことを特徴とする保守管理システム。
5. 請求項４に記載の保守管理システムにおいて、
   前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および／または一定期間に亘って変化しないデータ項目を処理対象から除外する、
   ことを特徴とする保守管理システム。
6. 請求項４に記載の保守管理システムにおいて、
   前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および／または一定期間に亘って変化しないデータ項目を処理する時間間隔を倍にすることで、前記データ項目の処理を間引きする、
   ことを特徴とする保守管理システム。
7. それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムを制御するためのデータ処理方法であって、
   前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データのデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了し、
   前記保守管理システムのデータ処理にかかる負荷のレベルを監視し、
   前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行し、
   前記負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する、
   ことを特徴とするデータ処理方法。

Images