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

保守管理システムおよびデータ処理方法 Download PDF

Info

Publication number
JP7010171B2
JP7010171B2 JP2018151602A JP2018151602A JP7010171B2 JP 7010171 B2 JP7010171 B2 JP 7010171B2 JP 2018151602 A JP2018151602 A JP 2018151602A JP 2018151602 A JP2018151602 A JP 2018151602A JP 7010171 B2 JP7010171 B2 JP 7010171B2
Authority
JP
Japan
Prior art keywords
data
item
management system
items
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018151602A
Other languages
English (en)
Other versions
JP2020028005A (ja
Inventor
瑞人 中村
修 沖野
登志彦 関
浩之 大柳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2018151602A priority Critical patent/JP7010171B2/ja
Priority to US17/266,803 priority patent/US11720092B2/en
Priority to PCT/JP2019/030233 priority patent/WO2020031846A1/ja
Publication of JP2020028005A publication Critical patent/JP2020028005A/ja
Application granted granted Critical
Publication of JP7010171B2 publication Critical patent/JP7010171B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G05B23/0281Quantitative, e.g. mathematical distance; Clustering; Neural networks; Statistical analysis
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0224Process history based detection method, e.g. whereby history implies the availability of large amounts of data
    • G05B23/0227Qualitative history assessment, whereby the type of data acted upon, e.g. waveforms, images or patterns, is not relevant, e.g. rule based assessment; if-then decisions
    • G05B23/0232Qualitative history assessment, whereby the type of data acted upon, e.g. waveforms, images or patterns, is not relevant, e.g. rule based assessment; if-then decisions based on qualitative trend analysis, e.g. system evolution
    • GPHYSICS
    • G08SIGNALLING
    • G08CTRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
    • G08C15/00Arrangements characterised by the use of multiplexing for the transmission of a plurality of signals over a common path
    • GPHYSICS
    • G08SIGNALLING
    • G08CTRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
    • G08C15/00Arrangements characterised by the use of multiplexing for the transmission of a plurality of signals over a common path
    • G08C15/02Arrangements characterised by the use of multiplexing for the transmission of a plurality of signals over a common path simultaneously, i.e. using frequency division
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Landscapes

  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Probability & Statistics with Applications (AREA)
  • Algebra (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Description

本発明は、テレメトリ技術を利用してデータを定期的に配信する複数の管理対象を管理する保守管理システムおよびデータ処理方法に関する。
例えば、様々な通信サービスを提供するネットワーク内においては、絶え間なくサービスの提供を継続することが求められる。したがって、それぞれのサービスを提供するサーバ等の業務装置については、故障や性能の劣化などが発生しないように常時監視しておく必要がある。
そのため、通信事業者等においては、ネットワーク内で起きている状況のリアルタイム把握が必要とされる。このような状況のリアルタイム把握に関しては、管理される側の装置主導のプッシュ(Push)型のデータ取得技術であるテレメトリが注目されている。テレメトリは、観測対象から離れた地点で観測対象のデータを取得して様々な観測を行うための技術であり、観測対象は外部からの要求がなくても定期的に繰り返しデータを送信することができる。
一方、通信事業者等においては、ネットワーク内に存在する多数の業務装置を共通の管理システムで一括して管理することが想定される。したがって、管理対象のそれぞれの業務装置から送信されるデータが管理システムに定期的に入力されることになり、業務装置の数が多いと、管理システムが受け取るデータ量も膨大になる。特に、各業務装置が短い時間周期でデータ送信を繰り返す場合には、管理システムが受け取るデータ量が管理システムの処理能力を超えて過負荷状態になってしまう可能性がある。
例えば、特許文献1の障害継続監視システムは、メッセージフラッシュ時でも、エージェントからのメッセージ流量を動的に制御し他のメッセージの監視業務に影響を与えずに継続した障害監視を行うための技術を示している。具体的には、上記の管理システムに相当する「障害監視マネージャ」の負荷を軽減するために、監視対象である「エージェント」側で一定期間データをためることを示している(特許文献1の図3参照)。
一方、非特許文献1に示されている「NetFlow」の仕様では、フロー単位のデータを、ヘッダ情報などの条件でグルーピングすることが可能である。これにより、プッシュ型のデータ取得システムにおいて、フロー数を削減し、システムの負荷を軽減することが可能である。
特開2011-211555号公報
"フロー集約統計(NetFlow Version8)"、インターネット<URL:https://www.alaxala.com/jp/techinfo/archive/manual/AX5400S/HTML/10_10/_/APGUIDE2/0164.HTM>
しかしながら、特許文献1の技術では監視対象の各装置がデータをためる必要があるため、データを送信するタイミングが遅延することになり、管理システムが取得するデータのリアルタイム性が犠牲になる。
また、非特許文献1の技術では、グルーピングによりフロー数を削減できるが、管理対象のそれぞれの装置が複数種類のデータを送信する場合に、装置内のデータの種類をグルーピングすることはできない。例えば、サーバのような業務装置の場合には、CPU(Central Processing Unit)使用率、メモリ使用率など様々な種類のデータを個別に監視する必要があるが、各データの重要度や監視すべき時間周期の長さについては状況に応じて大きく変化することが想定される。
例えば、光伝送装置の場合には、半導体であるレーザ増幅器の経年劣化によって徐々に光出力のパワーが低下する傾向がある。したがって、このような装置の故障発生を未然に防止するためには、光出力を監視する必要がある。しかし、光出力が十分に大きい状況では「検知できない障害」、すなわち「サイレント障害」が発生する可能性は非常に小さいので、このようなデータの重要度は低く、データ取得の時間周期を長くしても問題はない。しかし、光出力が一定値を下回った場合は、「サイレント障害」が発生する可能性が高くなるので、重要度は高く、データ取得の時間周期を短くする必要がある。
非特許文献1の技術では、同じ装置が送信する複数データの種類をグルーピングすることはできないので、装置単位でしかデータフローを削減できない。つまり、重要度や時間周期の条件が異なる複数種類のデータのフローを一括して制御することになるので、管理システムの負荷を削減するために、重要なデータまで間引いたり、短い時間周期で監視する必要のあるデータまで取得周期を大きくしなければならない。
本発明は、上記の状況に鑑みてなされたものであり、障害の可能性等に関する検出の遅延を防止可能にするとともに、管理対象の複数の装置がそれぞれ複数種類のデータを送信する場合に、データの種類毎の重要度や特性を考慮して適正化しつつ、管理側における負荷を削減することが可能な保守管理システムおよびデータ処理方法を提供することを目的とする。
(1)それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムであって、
前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データをデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了するデータ処理部と、
前記データ処理部のデータ処理にかかる負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する負荷レベル管理部、とを備え、
前記負荷レベル管理部は、前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、前記データ処理部が処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行する、
ことを特徴とする。
この保守管理システムによれば、前記負荷レベル管理部が前記処理を実行することにより、前記データ処理部の負荷に影響を及ぼす単位時間あたりのデータ処理量をデータ項目単位で変更できる。したがって、前記データ処理部のデータ処理にかかる負荷のレベルが大きい時には、負荷を削減し、過負荷になるのを避けることができる。しかも、データ項目単位で調整できるので、各データ項目の重要度や時間周期の特性に合わせて適正化した状態で負荷を削減できる。
更にこの保守管理システムによれば、前記データ処理部の負荷が大きくなった場合でも、高い優先度が割り当てられた各データ項目を確実に処理することができ、優先度が低い各データ項目の処理を間引く、すなわち省略することにより、前記データ処理部の負荷を減らすことができる。
)上記(1)に記載の保守管理システムにおいて、
前記負荷レベル管理部は、各データ項目のうち、装置故障との関連性が高い項目との相関性に応じて、該当するデータ項目の優先度、または各データ項目を処理する時間間隔を動的に調整する、
ことを特徴とする。
この保守管理システムによれば、各データ項目のそれぞれについて、必要性の変動を前記優先度、または時間間隔に動的に反映することにより、実際に処理するデータ項目を最適化できる。例えば、正常な範囲を外れたような異常値が現れている特定のデータ項目については、故障が発生しているか、または故障の原因になる可能性が高いので、通常は優先度の低いデータ項目であっても、高い頻度で監視することが望まれる。このような必要性の変動を、前記優先度、または時間間隔に動的に反映できる。
)上記()に記載の保守管理システムにおいて、
前記負荷レベル管理部は、少なくとも異常値が発生したデータ項目の優先度を上げる、または異常値が発生したデータ項目を処理する時間間隔を小さくする、
ことを特徴とする。
この保守管理システムによれば、異常値が発生したデータ項目の優先度を上げることにより、通常は優先度の低いデータ項目であっても優先的に処理できる。また、異常値が発生したデータ項目を処理する時間間隔を小さくすることにより、通常は時間間隔の大きいデータ項目であっても短い周期で繰り返し処理できる。
)上記(1)に記載の保守管理システムにおいて、
前記負荷レベル管理部は、各データ項目におけるデータの絶対値および時系列変化の傾向に基づき、前記データ処理部の処理対象のデータ項目の優先度またはデータ取得間隔にフィードバックする、
ことを特徴とする。
この保守管理システムによれば、各データ項目におけるデータの傾向を観察した結果を各データ項目の優先度などの属性にフィードバックできる。これにより、前記データ処理部の処理対象のデータ項目を適正化できる。例えば、一定時間に亘って数値がほとんど変化しなかったデータ項目について、優先度を下げるかまたは処理の時間周期を長い状態に変更することが想定される。これにより、管理状態の結果に大きな影響を及ぼすことなく、前記データ処理部のデータ処理にかかる負荷を削減できる。
)上記()に記載の保守管理システムにおいて、
前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および/または一定期間に亘って変化しないデータ項目を処理対象から除外する、
ことを特徴とする。
この保守管理システムによれば、前記業務装置の故障との関係性が高いデータ項目との相関性が低いデータ項目や、一定期間変化しないデータ項目を処理対象から除外することにより、管理状態の結果に大きな影響を及ぼすことなく、前記データ処理部のデータ処理にかかる負荷を削減できる。
)上記()の保守管理システムにおいて、
前記負荷レベル管理部は、前記業務装置の故障との関係性が高い所定データ項目との相関性が低いデータ項目、および/または一定期間に亘って変化しないデータ項目を処理する時間間隔を倍にすることで、前記データ項目の処理を間引きする、
ことを特徴とする。
この保守管理システムによれば、間引きによりデータ項目毎に異なる取得周期で処理されるので、優先度の低いデータ項目の取得周期を大きくし、負荷を効率的に削減できる。また、複数のデータ項目の取得周期が規定の周期の倍数で割り当てられるので、この間引きが複数のデータ項目の間の相関性評価へ及ぼす影響を抑制できる。
) それぞれがテレメトリ技術を利用してデータを定期的に配信する機能を有する複数の業務装置、を管理する保守管理システムを制御するためのデータ処理方法であって、
前記複数の業務装置が定期的に配信するデータのそれぞれを取得して、前記データのデータ項目の優先度の高い順に処理すると共に、処理したデータ項目数が上限に達した時点で処理を終了し
前記保守管理システムのデータ処理にかかる負荷のレベルを監視し、
前記複数の業務装置がそれぞれ配信するデータに複数の項目が含まれている場合に、処理するデータ項目数を制限する処理、および、各データ項目を処理する時間間隔を間引く処理のうち少なくとも一方を実行し、
前記負荷のレベルに合わせて、データ項目毎に優先度を定めて前記負荷を軽減するためにデータ処理量を削減する、
ことを特徴とする。
このデータ処理方法によれば、前記処理を実行することにより、データ処理の負荷となる単位時間あたりのデータ処理量をデータ項目単位で変更できる。したがって、データ処理にかかる負荷のレベルが大きい時には、負荷を削減し、過負荷になるのを避けることができる。しかも、データ項目単位で調整できるので、各データ項目の重要度や時間周期の特性に合わせて適正化した状態で負荷を削減できる。更にこの保守管理システムによれば、前記データ処理部の負荷が大きくなった場合でも、高い優先度が割り当てられた各データ項目を確実に処理することができ、優先度が低い各データ項目の処理を間引く、すなわち省略することにより、前記データ処理部の負荷を減らすことができる。
本発明の保守管理システムおよびデータ処理方法によれば、管理対象側で送信前のデータを蓄積する必要がないので、障害の可能性等に関する検出の遅延を防止できる。また、管理対象の複数の装置がそれぞれ複数種類のデータを送信する場合に、データの種類毎の重要度や特性を考慮して適正化しつつ、管理側における負荷を削減し、過負荷になるのを防止できる。
本発明の実施形態における複数の管理対象と管理システムとの接続状態の例を示すブロック図である。 管理対象のテレメトリ送信データおよび管理システムのテレメトリ受信データの例を示す模式図である。 管理システムにおける機能上の構成例を示すブロック図である。 取得設定ファイルCf2の構成例を示す模式図である。 取得設定ファイルCf2の構成例を示す模式図である。 負荷レベル管理テーブルの構成例を示す模式図である。 管理システムのデータ受信部内のデータ処理概要を示すフローチャートである。 管理システムの負荷を制御するための処理概要を示すフローチャートである。 図8中のステップS13の詳細を示すフローチャートである。 図8中のステップS14の詳細を示すフローチャートである。 図8中のステップS17の詳細を示すフローチャートである。 管理対象のデータ配信の例を示す模式図である。 管理システムの負荷状況の変化傾向を示すグラフである。 管理対象および管理システムにおける経時変化と複数の状態との関係を表す状態遷移図である。 管理システムの負荷に応じてデータ取得項目を制御する場合の動作例を示すシーケンス図である。 管理システムの負荷に応じてデータ配信間隔を制御する場合の動作例の前半を示すシーケンス図である。 管理システムの負荷に応じてデータ配信間隔を制御する場合の動作例の後半を示すシーケンス図である。
本発明の実施形態について各図を参照しながら以下に説明する。
<複数の管理対象と管理システムとの接続状態の例>
本発明の実施形態における複数の管理対象と管理システムとの接続状態の例を図1に示す。
図1に示した例では、複数の業務装置G01~G07が通信ネットワークNWに接続されている。業務装置G01~G07のそれぞれは、例えば様々な通信サービスを提供するために利用されるサーバや、伝送装置であり、24時間絶え間なくサービスを継続する必要がある。業務装置G01~G07のそれぞれが、管理システム10の管理対象である。
管理システム10は、本発明の保守管理システムに相当する。また、管理システム10が本発明のデータ処理方法を実施する。この管理システム10は、次世代のキャリアネットワークを構成するネットワーク装置とサービス制御層サーバ群の装置レベル、およびネットワークレベルの保守、運用を支援するオペレーションシステム(OpS)に含まれる装置であり、通信ネットワークNW内で起きている状況をリアルタイム把握するための機能を有する。すなわち、各業務装置G01~G07の稼働状況や、故障などの不具合発生の可能性を検知するために利用される。
したがって、管理システム10は、各業務装置G01~G07からそれぞれの状態を表すデータを収集する必要がある。本実施形態では、業務装置G01~G07のそれぞれが、テレメトリのデータ配信機能を搭載している。すなわち、各業務装置G01~G07は、事前に決められた時間周期で、データを配信することができる。管理システム10は、テレメトリ通信経路22を経由して、業務装置G01~G07のそれぞれが配信するデータを受信し取得することができる。また、管理システム10は、業務装置G01~G07のそれぞれにおけるデータ配信頻度を設定することができる。
すなわち、テレメトリ技術を利用しているので、業務装置G01~G07のそれぞれの主導によりプッシュ型のデータ配信を実施する。テレメトリの場合は、業務装置G01~G07は、管理システム10からの要求を解釈したり、応答を返す必要がないため、業務装置G01~G07における通信の負荷が小さい。したがって、業務装置G01~G07は、リアルタイム性の高いデータを配信することができる。
管理システム10は、業務装置G01~G07が配信したデータをそれぞれ取得してデータ処理した結果をテレメトリデータベースDB1に登録する。したがって、テレメトリデータベースDB1にアクセス可能な各装置は、テレメトリデータベースDB1に登録されているデータに基づいて、業務装置G01~G07のそれぞれを含む通信ネットワークNWの状態をリアルタイムで把握できる。
通信ネットワークNWを管理している管理者等は、管理者端末21を利用して管理システム10に接続することができる。例えば、管理者は、管理者端末21からの入力操作により管理システム10に指示を与え、業務装置G01~G07のそれぞれのデータ配信頻度に関する初期状態を決定したり、必要に応じて設定変更を行うことができる。
一方、業務装置G01~G07のそれぞれは様々なデータを周期的に配信する。また、通信ネットワークNWに接続される業務装置G01~G07の数が増える可能性もある。そして、管理システム10が取得するデータのリアルタイム性を向上させるために、業務装置G01~G07のデータ配信周期を短くすると、管理システム10が受け取るデータ量が膨大になり、負荷増大状態や空き容量減少状態になる。
すなわち、管理システム10が受け取る1回あたりのデータ取得量DTは次式で計算される。
DT=Ng×Np×Ni×Ns
但し Ng:管理する業務装置の装置台数
Np:通信で使用するポート数
Ni:監視項目数
Ns:データサイズ[bit]
つまり、データ配信周期を短くすると、管理システム10内でデータ処理能力の限界に近づき、または限界を超えるため、管理システム10が受け取ったデータの全てを処理しきれなくなった場合が負荷増大状態である。また、管理システム10が大量のデータを受信すると、テレメトリデータベースDB1にも大量のデータが登録されるので、空き容量減少状態になる。後述するように、本実施形態の管理システム10は、これら負荷増大状態や空き容量減少状態を防止するための特別な機能を備えている。
<テレメトリ送信データ、テレメトリ受信データの例>
管理対象のテレメトリ送信データおよび管理システムのテレメトリ受信データの例を図2に示す。
図2に示すように、業務装置G01が配信するテレメトリ送信データD01の中には種類の異なる様々な項目のデータが含まれている。同様に、業務装置G02が配信するテレメトリ送信データD02の中にも種類の異なる様々な項目のデータが含まれている。そして、管理システム10が業務装置G01~G07から受け取るテレメトリ受信データDxの中にも、種類の異なる様々な項目のデータが含まれている。
ここで、管理システム10の負荷が増大し処理しきれない状態に近づいた場合、管理システム10はデータ処理量を削減する必要がある。一般的なデータ削減方法の場合、管理システム10はテレメトリ受信データDxの中から、業務装置G01~G07の単位で選択的にデータを削減するか、あるいは処理しきれない任意項目のデータを削減することになる。
しかし、テレメトリ受信データDxの項目の中には、短い周期で監視することが求められるデータ項目や、監視の周期を大きくしても問題のないデータ項目などがある。しかも、いずれのデータ項目を短い周期で監視すべきか否かは、状況に応じて動的に変化する。したがって、一般的なデータ削減方法の場合には、短い周期で監視すべき重要な項目のデータまで削減されることになり、このオペレーションシステム(OpS)が故障等を検知する際の性能低下に繋がる。本実施形態の管理システム10においては、後述するように、項目毎のデータの優先度などを考慮してデータ処理量を減らし、管理システム10の負荷を調整することができる。
<管理システムの構成>
管理システム10における機能上の構成例を図3に示す。なお、図3に示した業務装置Gxは、図1中の業務装置G01~G07のそれぞれに相当する。つまり、実際には複数台の業務装置Gxが管理システム10に接続されている。
図3に示したように、この管理システム10はデータ受信部11、取得設定ファイル管理部12、データ傾向測定部13、判断部14、OpS負荷レベル管理部15、および異常検知部16を備えている。また、取得設定ファイル管理部12の中には優先度管理部12a、データ取得間隔管理部12b、取得設定部12c、および重み設定テーブル管理部12dが含まれている。
なお、管理システム10の実体は、一般的なサーバなどと同様に、コンピュータのハードウェア、基本ソフトウェア(オペレーティングシステム)、および専用のアプリケーションソフトウェアにより構成される。勿論、管理システム10を仮想化したシステムとして構成することもできる。また、管理システム10を構成する各要素は、同じサーバ上に配置してもよいし、それぞれ独立した別のサーバに配置してもよい。
データ受信部11は、各業務装置Gxがテレメトリ通信経路22aを経由して配信したデータを受信し、予め定められたデータ処理を施してその処理結果のデータをテレメトリデータベースDB1に登録する。データ受信部11が業務装置Gxから受信したデータのうち未処理のデータは一時的にバッファ11aに保持される。
一方、業務装置Gxがテレメトリ通信経路22aにより配信するデータの配信頻度、すなわち配信を繰り返す時間周期の長さなどの配信条件は、業務装置Gxが読み取り可能な取得設定ファイルCf1に保持されたデータにより規定される。
また、管理システム10内のデータ受信部11が受信した内容をデータ処理する条件については、データ受信部11が読み取り可能な取得設定ファイルCf2に保持されたデータにより規定される。
取得設定ファイル管理部12は、取得設定ファイルCf1およびCf2の内容を管理している。取得設定ファイル管理部12内の優先度管理部12aは、取得設定ファイルCf2の内容のうちデータ受信部11がデータ処理する際のデータ項目の優先度を管理している。
また、データ取得間隔管理部12bは、取得設定ファイルCf1の内容のうち、業務装置Gxがデータを配信する際の間隔、すなわち配信を繰り返す時間周期をデータ項目毎に規定するデータを管理している。
また、取得設定部12cは、管理者端末21を操作する管理者の入力に従い、各取得設定ファイルCf1、Cf2の内容の初期値を定めたり、各取得設定ファイルCf1、Cf2の内容を必要に応じて更新するための処理を行う。取得設定部12cが取得設定ファイルCf1を変更する場合には、制御用通信経路18を経由して、管理システム10が業務装置Gxに指示を与える。
重み設定テーブル管理部12dは、取得設定ファイルCf2の内容のうち、データ受信部11がデータ処理する際のデータ項目毎の重みを個別に調整するために用意されたテーブルを管理している。
データ傾向測定部13は、データ受信部11が業務装置Gxから受信したデータ、またはテレメトリデータベースDB1に登録されたデータの絶対値および時系列変化の傾向をデータ項目毎にそれぞれ観察するための測定を実施する。
判断部14は、データ傾向測定部13が測定したデータ項目毎の傾向を、取得設定ファイル管理部12の制御にフィードバックし、管理システム10の制御を適正化するための判断を実施する。具体例としては、判断部14が人工知能(AI)やルールベースを利用して判断を実施する。例えば、複数のデータ項目の間の相関性や、特定のデータ項目と何らかの故障との相関性について、過去のデータ傾向から判明している各種ルールや、リアルタイムのデータ観察により新たに発見したルールなどを適用することにより、総合的に判断する。
OpS負荷レベル管理部15は、管理システム10のデータ受信部11におけるデータ処理の負荷レベルを管理する。OpS負荷レベル管理部15は、例えば、データ受信部11内のCPU使用率、メモリ使用率、テレメトリデータベースDB1を保持する記憶装置の使用率などの最新の値および変化の傾向から、データ処理にかかる負荷のレベルを管理している。また、負荷のレベルが大きくなった場合に、全てのデータを処理しきれなくなる前に、OpS負荷レベル管理部15は取得設定ファイル管理部12に対して負荷の適正化を指示する。
異常検知部16は、データ受信部11が各業務装置Gxから受信した項目毎の各々のデータについて、あるいは業務装置Gx側で生成された各データについて、異常値か否かを検知する。すなわち、通常とは異なる異常な値のデータが現れた場合に、その異常を異常検知部16が検知し、重み設定テーブル管理部12dに指示を与える。この指示に従い、データ受信部11が処理するデータのデータ項目毎の重み付けを変更する。
例えば、業務装置Gxが光伝送装置である場合には、業務装置Gx内のレーザ増幅器における光出力を表すデータ項目の値も、業務装置Gxが配信する。このような光出力の値は、半導体の劣化により徐々に低下する傾向があるが、この変動周期は非常に長い。つまり、通常の状態であれば光出力の値の変動は非常に小さい。したがって、通常は光出力の値を頻繁に監視する必要はなく、監視の重要度も比較的低いので該当する項目のデータを間引くことができる。
しかし、半導体が劣化して故障が発生する可能性が高い状態になると、光出力の値に、通常とは異なる急激な変化が現れる傾向がある。このような急激な変化が発生した際に、異常検知部16がそれを検知して警報を出力する。重み設定テーブル管理部12dは、異常検知部16の警報により、該当するデータ項目の重要度が高くなったことを反映するために、該当するデータ項目の重みを大きくする。その結果が取得設定ファイルCf1、Cf2の少なくとも一方の内容に反映される。
<取得設定ファイルCf2の構成例>
取得設定ファイルCf2の構成例を図4および図5に示す。
図4および図5に示した取得設定ファイルCf2は、優先度欄Cf2a、項目欄Cf2b、および重み欄Cf2cを含んでいる。また、図4および図5の例では、各業務装置Gxが配信するデータの中に、「メモリ使用率(メモリ)」、「CPU使用率(CPU)」、「システムログ(Syslog)」、・・・の各データ項目が含まれる場合を想定している。
優先度欄Cf2aの各番号は「1」、「2」、「3」、・・・の順にデータ処理の優先度が高いことを意味している。また、項目欄Cf2bはそれぞれの優先度に対応付けたデータ項目の並び順を表している。つまり、図4の例では優先度が「1」の「メモリ使用率」の項目を最優先で処理し、優先度が「2」の「CPU使用率」の項目を2番目の優先順で処理し、優先度が「3」の「システムログ」の項目を3番目の優先順で処理することを意味している。
例えば、取得設定ファイルCf2の内容が図4の状態である時に、「CPU使用率」の項目に関する異常値を異常検知部16が検知すると、異常検知部16がその警報を発生する。そして、重み設定テーブル管理部12dは、図4の取得設定ファイルCf2における「CPU使用率」の項目の重みを「1」から「2」に変更する。
その場合、優先度管理部12aは「CPU使用率」の項目の重みの変化を反映するように項目の優先度を変更する。その結果、図5に示したように取得設定ファイルCf2の内容が変更される。つまり、図4の例では「CPU使用率」の項目の優先度は「メモリ使用率」の項目よりも低いが、図5の例では「CPU使用率」の重みが通常の「1」よりも大きいことを反映して「CPU使用率」の項目の優先度を最上位に変更し、項目の並びを変更している。
<負荷レベル管理テーブルの構成例>
OpS負荷レベル管理部15が管理している負荷レベル管理テーブル15aの構成例を図6に示す。
図6に示した負荷レベル管理テーブル15aは、「負荷レベル(レベル)」と、「CPU使用率」と、「処理可能な項目計」との関係を表すデータを保持している。負荷レベル管理テーブル15aにおける「CPU使用率」は、図3に示したデータ受信部11がデータ処理するために用意されたCPUの使用率を表している。
図6に示した例では、「負荷レベル」は「1」~「4」の4種類存在する。「負荷レベル」の「1」は、「0~50%]」の「CPU使用率」に対応し、処理可能な項目計の内容が「全て:ALL」であり項目数の制限はない。
また、「負荷レベル」の「2」は、「51~70%」の「CPU使用率」に対応し、処理可能な項目計の内容により上限数が「15」に制限されている。「負荷レベル」の「3」は、「71~90%」の「CPU使用率」に対応し、処理可能な項目計の内容によりその上限数が「10」に制限されている。「負荷レベル」の「4」は、「91~100%」の「CPU使用率」に対応し、処理可能な項目計の内容によりその上限数が「5」に制限されている。なお、「CPU使用率」の小数点以下の数値は切り下げまたは切り上げとする。
図6に示した例では、管理システム10の負荷が高い事を表す指標として「CPU使用率」を採用した場合を想定しているが、他の指標を採用してもよい。例えば、メモリ使用率、ページング使用率、ディスクI/O使用率、スワッピング使用率のいずれかのように、様々なKPI(Key Performance Indicators)の中から必要に応じて選択できる。KPIは、実装したい目的をベースに測定可能な数値を意味する。また、複数の指標を組み合わせて使用してもよい。
<データ処理の概要>
管理システム10のデータ受信部11におけるデータ処理の概要を図7に示す。
すなわち、データ受信部11内でデータ処理を実行するために割り当てられたCPUが、図7の処理を実行する。
なお、図7の例では1つの業務装置Gxから配信された受信データのみを処理する場合を示しているが、実際には図1に示したように複数の業務装置G01~G07がそれぞれ配信したデータを、管理システム10がほぼ同時に受信して処理する。図7の処理について以下に説明する。
データ受信部11は、最初にステップS01で取得設定ファイルCf2を読み込み、その設定内容を把握する。データ受信部11は、例えば、図4、図5に示した取得設定ファイルCf2のように、処理対象の複数のデータ項目、各々のデータ項目に割り当てられた優先度、重みなどデータ処理対象に関する項目毎の取得条件を把握する。
データ受信部11は、ステップS02で、各業務装置Gxがテレメトリ通信経路22を経由して配信するデータを項目毎にそれぞれ受信する。データ受信部11が受信した各項目の内容は、データ受信部11がデータ処理を行うまでバッファ11aで一時的に保持される。
データ受信部11は、ステップS03で、取得設定ファイルCf2における優先度の高い項目から順番に受信データの項目を選択し、それぞれの項目のデータに対して順次にデータ処理を実行する。処理後のデータはテレメトリデータベースDB1に登録される。
例えば、図4に示した内容の取得設定ファイルCf2を読み込んだ場合には、データ受信部11は優先度の順番に従い、「メモリ使用率」、「CPU使用率」、「システムログ」、・・・の各項目をデータ処理する。
データ受信部11は、ステップS04で、送信元が同じ業務装置Gxのデータの中で、今回処理したデータ項目数Ntを把握する。実際には、優先度欄Cf2aの優先度順に従い優先度「1」のデータ項目、優先度「2」のデータ項目、優先度「3」のデータ項目を処理するので、今回処理したデータ項目数Ntは最後に処理したデータ項目の優先度と同じである。
データ受信部11は、ステップS05で、最新の項目数制限値Ntmaxを取得する。この項目数制限値Ntmaxは、図6に示した負荷レベル管理テーブル15a内の「処理可能な項目計」の値に相当し、負荷レベルの1~4に対してそれぞれ異なる値が採用される。例えばデータ受信部11の最新の負荷レベルが「1」であれば、項目数制限値Ntmaxは制限なしになり、負荷レベルが「2」であれば、項目数制限値Ntmaxは「15」になる。同様に、負荷レベルが「3」の場合の項目数制限値Ntmaxは「10」、負荷レベルが「4」の場合の項目数制限値Ntmaxは「5」になる。
データ受信部11は、次のステップS06でデータ項目数Ntと項目数制限値Ntmaxとを比較し、データ項目数Ntが項目数制限値Ntmax以上になるとステップS07に進む。データ項目数Ntが項目数制限値Ntmax未満の場合は、データ受信部11はステップS03に戻って上記と同様の処理を繰り返す。
データ受信部11は、ステップS07で、送信元が同じ業務装置Gxの受信データに対する今回のデータ処理を終了し、最初のデータ項目の位置に戻る。したがって、優先度が項目数制限値Ntmax以上の残りの未処理のデータ項目については、今回のデータ処理の対象外となり、不要なのでバッファ11aから破棄される。
つまり、データ受信部11がステップS03~S06で1回あたりデータ処理する項目数が項目数制限値Ntmaxに制限されるので、未処理のデータ項目分だけデータ受信部11における負荷が軽減される。しかも、優先度が高い順番に従って各項目を処理するので、比較的優先度の高い項目のデータが欠落するのを避けることができる。
データ受信部11は、ステップS08で設定変更の有無を識別し、変更ありの場合は次のステップS09に進み、更新された取得設定ファイルCf2の読み込みを実施する。例えば、管理者が管理者端末21から取得設定ファイルCf2の更新を指示した場合や、判断部14のフィードバック制御により取得設定ファイルCf2が更新されたような場合には、更新後の取得設定ファイルCf2の内容がステップS09でデータ受信部11の処理に反映される。
なお、異常値を示している項目データについては、負荷の大きさにかかわらず、できる限り頻繁に監視したいので、その変動傾向に基づいて重み付けを行い、状況に応じて動的に処理の優先度を変動させる。また、この重み付けに関し、該当データの傾向観察の結果をフィードバックするように制御してもよい。
なお、図7に示したデータ処理などにより間引きされ、欠落したデータ項目については、同じデータ項目に関する時系列変化の傾向に基づき、近似曲線を用いて推定値を計算しデータの補完を実施する。
<管理システムの負荷を制御するための処理>
管理システム10の負荷を制御するための処理の概要を図8に示す。なお、図8に示した各処理を実行する順番やタイミングは必要に応じて変更できる。
管理システム10の取得設定部12cは、ユーザ、すなわち管理者端末21に対する管理者の入力操作に従い、ステップS11で、事前に定めたデータ取得項目毎の優先度等を初期値に定め、更にユーザ入力も受け付ける。ここで決定された初期値または入力された値が、取得設定部12cにより各取得設定ファイルCf1、Cf2の内容に反映される。
また、管理システム10の動作開始後に、必要に応じて管理者端末21から入力されるユーザ入力があった場合には、取得設定部12cは、ステップS12でこの入力を受け付けて項目毎の優先度等を変更する。
ステップS13では、優先度管理部12aが「優先度の監視処理」を実行し、データ項目毎の優先度の割り当てを動的に変更する。この処理の詳細については後で説明する。
ステップS14では、OpS負荷レベル管理部15が「負荷レベルの監視処理」を実行し、データ受信部11のデータ処理に関する負荷レベル、およびその動的な変動を把握する。この処理の詳細については後で説明する。
ステップS15では、異常検知部16が異常値の検出により警報を出力したか否かを重み設定テーブル管理部12dが識別する。異常値を検出した場合、重み設定テーブル管理部12dは、次のステップS16を実行する。
ステップS16では、異常検知部16が異常値を検出したデータ項目について、重み設定テーブル管理部12dが重みを自動的に調整する。例えば、取得設定ファイルCf2の内容が図4に示した状態の時に、「CPU使用率」が異常値に変化した場合には、「CPU使用率」の項目に対する重みを「1」から「2」に変更する。これにより、図5に示したように「CPU使用率」の優先度が上がる。なお、図8には示されていないが、異常値が検出された項目について、データの値が正常な範囲に戻ったような場合は、重み設定テーブル管理部12dが該当する項目の重みを通常の値である「1」に戻す。
ステップS17では、データ取得間隔管理部12bが、「データ取得間隔の調整」処理を実行し、取得設定ファイルCf1の内容を更新する。この処理の詳細については後で説明する。
ステップS18では、データ傾向測定部13がデータ受信部11の受信したデータまたはテレメトリデータベースDB1に登録されたデータについて、データ項目毎の変化の傾向を測定する。
ステップS19では、判断部14が人工知能やルールベースを用いて、データ傾向測定部13の測定結果を分析し、複数のデータ項目間の相関性や、各データ項目と各業務装置Gxの故障との相関性などについて判断を実施する。その判断の結果が、取得設定ファイル管理部12にフィードバックされる。このフィードバックにより、取得設定ファイル管理部12は項目毎のデータの優先度、項目毎のデータ取得間隔、項目毎の重みなどを動的に調整する。
<「優先度の監視処理」の詳細>
図8中のステップS13の詳細を図9に示す。図9の処理について以下に説明する。
管理システム10のデータ受信部11は、ステップS21の処理を定期的に繰り返し実行する。すなわち、管理対象の複数の業務装置Gxがそれぞれ定期的に配信するデータを、データ受信部11が業務装置Gx毎に受信する。データ受信部11が1回の処理で受信するデータは、例えば図2に示したテレメトリ送信データD01のように複数項目のデータを含んでいる。
管理システム10の優先度管理部12aは、ステップS22で判断部14の出力や、管理者端末21からのユーザ入力を監視することにより、データ項目毎の優先度の変更要求の有無を識別する。優先度の変更要求があった場合は、優先度管理部12aは次のステップS23に進み、取得設定ファイルCf2における項目毎の優先度の順序を変更する。
例えば、図4に示した取得設定ファイルCf2の内容の状態で、各項目の重みとは無関係に、優先度を「CPU使用率」、「メモリ使用率」、「システムログ」の順番に変更する要求があった場合には、優先度管理部12aが図5に示した取得設定ファイルCf2のように、各項目の並び順を「CPU使用率」、「メモリ使用率」、「システムログ」に変更する。
<「負荷レベルの監視処理」の詳細>
図8中のステップS14の詳細を図10に示す。図10の処理について以下に説明する。
図9のステップS21と同様に、管理システム10のデータ受信部11は、図10のステップS31の処理を定期的に繰り返し実行し、管理対象の複数の業務装置Gxがそれぞれ定期的に配信するデータを受信する。
管理システム10のOpS負荷レベル管理部15は、データ受信部11のデータ処理に影響を及ぼす負荷についてその大きさおよび変動を常時監視している。そして、データ受信部11の負荷が急激に変化したか否かと、負荷の大きさが閾値を超えたか否かをステップS32で識別し、この条件を満たす場合に次のステップS33に進む。
ステップS33では、OpS負荷レベル管理部15は、データ受信部11における処理可能項目数を変更する。この処理可能項目数は、図6に示した負荷レベル管理テーブル15a中の「処理可能な項目計」、および図7に示したステップS05、S06中の項目数制限値Ntmaxに相当する。
例えば、OpS負荷レベル管理部15の検出した負荷レベルが、「2」から「3」に変化した場合には、負荷レベル管理テーブル15aから負荷レベル「3」の「処理可能な項目計」の「10」を取得して、項目数制限値Ntmaxを「10」に変更する。この変更により、データ受信部11が図7のステップS03~S06でデータ処理する1回あたりのデータ項目数が「10」に制限される。
<「データ取得間隔の調整」の詳細>
図8中のステップS17の詳細を図11に示す。図11の処理について以下に説明する。
図9のステップS21と同様に、管理システム10のデータ受信部11は、図11のステップS41の処理を定期的に繰り返し実行し、管理対象の複数の業務装置Gxがそれぞれ定期的に配信するデータを受信する。
管理システム10の判断部14は、データ受信部11が受信した各項目のデータについて、その変化の傾向をデータ傾向測定部13の出力で判断し、各項目データの値の変動が閾値以内かどうかをステップS42で識別する。変動が閾値以内であればステップS43に進み、閾値を超える場合はステップS48に進む。
また、判断部14は、各業務装置Gxの取得設定ファイルCf1の内容を制御するためのテーブルを備えている。このテーブルは、業務装置Gxがテレメトリ通信経路22で配信する複数のデータ項目の一覧と、データ項目毎の重みと、データ項目毎の送信時間の「間隔」を表す情報を保持している。
判断部14は、上記テーブルで該当項目の重みを参照し、この重みをステップS43で「1」と比較する。そして、重みが「1」と等しい場合はステップS44に進み、重みが「1」以外であればステップS49に進む。
判断部14は、データ項目毎に個別に用意したカウンタを管理している。また、判断部14は、該当する項目のカウンタの値をステップS44でインクリメント(+1)し、その結果をステップS45で判定する。そして、該当するカウンタの値が「10」または「20」の場合はステップS46に進み、該当するカウンタの値が「30」の場合はステップS47に進み、それ以外の値であればステップS41に戻る。
ステップS46では、判断部14は、上記テーブル上で該当する項目のデータに割り当てられている「間隔」をそれ以前の2倍に変更する。なお、この「間隔」については初期状態では標準値の1倍の値が割り当てられている。そして、上記カウンタが「10」になった時には、ステップS46で「間隔」が標準値の2倍の値に変更される。更に、上記カウンタが「20」になった時には、もう一度ステップS46が実行されるので、「間隔」が標準値の4倍の値に変更される。
また、上記カウンタが「30」になると、判断部14は、ステップS47で上記テーブルにおけるデータ項目の一覧から、該当する項目を削除する。また、この時に判断部14は、上記カウンタの値を「0」にクリアする。
ステップS48では、判断部14が上記テーブル上で該当する項目の「間隔」とその標準値の1倍とを比較する。そして、「間隔」がその標準値の1倍でなければ次のステップS49に進み、「間隔」がその標準値の1倍と一致する場合はステップS41に戻る。
ステップS49では、判断部14は、上記テーブルにおける該当する項目の「間隔」をその標準値の1倍にリセットする。
判断部14が管理している上記テーブルの内容については、例えばデータ取得間隔管理部12bが定期的に実行する処理により、各業務装置Gxの取得設定ファイルCf1の内容に反映される。その場合、各業務装置Gxは取得設定ファイルCf1の内容に従い、テレメトリ通信経路22で配信するデータ項目と、項目毎の配信間隔を変更することができる。
つまり、図11に示した処理を実行する場合には、値の変動が小さいデータ項目については、時間の経過につれて配信の間隔がステップS46で標準値の2倍、または4倍に変更される。但し、重みが「1」以外のデータ項目や、変動が大きくなったデータ項目については、配信の間隔がステップS49で標準値の1倍に戻される。また、値の変動が小さい時間が長くなると、その項目はステップS47で削除される。そして、業務装置Gxは削除された該当項目を次回の配信対象から除外する。
<負荷特性の変化例>
管理対象のデータ配信と管理システムの負荷特性との関係の例を図12Aと図12Bに示す。
図12Aに示した例では、業務装置Gxが各時刻「t=1」、「t=2」、「t=3」において、業務装置Gx内で生成したデータをテレメトリにより管理システム10に配信する場合を想定している。また、図12Aの例では、業務装置Gxが配信するデータの中に「CPU使用率」および「メモリ使用率」の項目が含まれている。
この場合、管理システム10内のデータ傾向測定部13の測定により、図12Bに示したような状況の変化傾向を観察することができる。図12Bの例では、CPU使用率L10aおよびメモリ使用率L10bが、時間の経過に伴って上昇している。
この場合、CPU使用率L10aおよびメモリ使用率L10bの絶対値や、一定時間内の変化量を所定の閾値と比較することにより、負荷増大状態Loa、Lobをそれぞれ検知することができる。
OpS負荷レベル管理部15が図12Bのような負荷増大状態Loa、Lobを検出した場合には、例えば図10に示したステップS32からS33に進むので、取得設定ファイルCf2における処理可能項目数、すなわち図7中の項目数制限値Ntmaxを減らすことができる。これにより、各業務装置Gxのデータ配信状況に変化が生じない場合であっても、管理システム10のデータ受信部11がデータ処理するデータ項目数が削減されるので、負荷を減らすことができる。
<状態遷移の例>
管理対象および管理システムにおける経時変化と複数の状態との関係の例を図13に示す。図13において、各状態Ct1、Ct2、Ctx、Cty、およびCtzは、それぞれ時刻「t=1」、「t=2」、「t=X」、「t=Y」、および「t=Z」における業務装置Gxから管理システム10へのデータ配信を表している。
例えば管理者端末21からのユーザ入力により、ステップS101として事前設定が行われる。これにより、取得設定ファイルCf1、Cf2の初期状態が確定する。
業務装置Gxは、取得設定ファイルCf1の内容に従い、時刻「t=1」の状態Ct1で、「項目A」、「項目B」、「項目C」、「項目D」、「項目E」、・・・の各データを一括して配信する。
また、時刻「t=2」の状態Ct2においても、業務装置Gxは「項目A」、「項目B」、「項目C」、「項目D」、「項目E」、・・・の各データを一括して配信する。但し、状態Ct2では管理システム10の負荷が上昇した場合を想定しているので、OpS負荷レベル管理部15の検知した負荷レベルに従い、負荷を減らすことができる。
例えば、負荷レベル管理テーブル15aにおける「処理可能な項目計」に基づき、データ受信部11がデータ処理する1回あたりのデータ項目数を削減することができる。従って、図13の状態Ct2ではデータ受信部11が優先度の高い「項目A」、「項目B」だけをデータ処理して、優先度の低い「項目C」、「項目D」、「項目E」、・・・の各データはデータ処理の対象から除外している。
これにより、データ受信部11におけるCPUのデータ処理の負荷が減るので、時間の経過に伴って状態CtxではCPUの状態が安定する。したがって、OpS負荷レベル管理部15の検出する負荷レベルが低くなり、「処理可能な項目計」を増やすことができる。そのため、図13の状態Ctxでは、データ受信部11が「項目A」、「項目B」、「項目C」、「項目D」、「項目E」の全てをデータ処理できる。
管理者端末21を操作する管理者は、管理システム10の稼働状況を観察し、ステップS102で必要に応じて取得設定ファイルCf1、Cf2を変更するための入力を行い、手動で現在の状況をフィードバックすることができる。例えば、図13の状態Ctzでは、優先度の低い「項目E」をデータ処理の対象から削除するための操作を管理者が行った場合を想定している。
一方、管理システム10のデータ傾向測定部13は、管理システム10が受信した「項目A」、「項目B」、「項目C」、「項目D」、「項目E」、・・・のそれぞれについて、データの時系列変化を監視して観測データDzを生成することができる。判断部14は、データ傾向測定部13が生成した観測データDzの内容から項目毎の傾向を観察し、人工知能、またはルールベースの処理を適用し、ステップS103で自動的なフィードバック制御を行うことができる。
なお、判断部14が観察する観測データDzについては、業務装置Gxが配信するデータのトラフィック情報の他に、管理システム10におけるCPUの電源電圧や、CPUの温度など様々な情報を利用することが想定される。
判断部14が人工知能を採用する場合には、把握している過去の故障パターンと、観測データDzとの関係などについて学習を実施しながら、今後発生するであろう故障の可能性について推定し、その結果をフィードバックする。また、判断部14がルールベースを採用する場合には、現在の知見で分かっている複数のデータ項目間の相関性や、各データ項目と各種の故障要因との相関性を規定したルールに基づいて、観測データDzの傾向を判断し、その結果をフィードバックする。例えば、管理システム10における温度上昇とそのCPU使用率との間には大きな相関があり、更にCPU使用率と装置故障との間にも相関がある。このような関係をルールベースなどで規定しておく。
ステップS103のフィードバック制御の結果、図13の状態Ctyにおいては、取得設定ファイルCf2における「項目D」の優先度が「項目C」よりも高くなった場合を想定している。その結果、前述の項目数制限値Ntmaxの影響を受けて、優先度の低い「項目C」が間引きされている。
また、図13に示した観測データDz中の「項目E」のように長時間に亘って値がほとんど変化しない項目や、装置故障との関連性が高い「CPU使用率」との相関性が低い項目については、監視する必要性がほとんどない。したがって、このようなデータ項目は判断部14の判断により業務装置Gxの配信対象から削除するように取得設定ファイルCf1の内容を変更する。または、監視する必要性がほとんどないデータ項目については、データ受信部11が間引きするように取得設定ファイルCf2の内容に反映する。
また、観測データDz中の「項目E」のように長時間に亘って値がほとんど変化しない項目や、装置故障との関連性が高い「CPU使用率」との相関性が低い項目については、図11に示した処理と同じように、業務装置Gxが配信する時間間隔を通常の倍にすることで間引きを実施するように、取得設定ファイルCf1の内容に反映する。なお、間引きにより欠落したデータ項目については、その変化の傾向から近似曲線を用いて推定した値を補完する。
なお、例えば判断部14の人工知能、またはルールベースを用いて業務装置Gxの装置種別毎に適正化されたデータ項目毎の取得間隔や優先度などのパターンを検出して保持し、このパターンを推奨内容として管理者端末21の画面に表示してもよい。これにより、ステップS102におけるユーザ入力を支援することができる。
なお、図7に示したデータ処理においては、データ受信部11が受信したデータをステップS03で処理する際に、優先度の高い順に各データ項目を選択して処理する場合を想定している。しかし、事前に優先度が高い順番に並んだ状態で項目データが入力される場合には、単純に項目数制限値Ntmaxと一致する項目数だけデータ処理すればよい。例えば、項目毎の優先度の内容が取得設定ファイルCf1に反映される場合には、各業務装置Gxは優先度の高いデータ項目から順番に並べた状態で順次に各データ項目を配信できる。その場合は、データ受信部11は図7のステップS03で受信した順番に従い、そのままの順番で各データ項目を処理することができる。
<負荷に応じてデータ取得項目を制御する場合の動作例>
管理システム10がその負荷に応じてデータ取得項目を制御する場合の動作例を図14に示す。図14に示した動作シーケンスについて以下に説明する。
管理システム10の取得設定部12cは、手順SE01で監視対象の業務装置Gxに対してデータ配信設定を行う。その結果が、図3に示した取得設定ファイルCf1の内容に反映される。
また、管理システム10のOpS負荷レベル管理部15は手順SE02で管理システム10における定常時の負荷レベルを業務装置Gxに設定する。その内容が取得設定ファイルCf1の内容に反映される。その結果、業務装置Gxがテレメトリ通信経路22でデータ配信する際の、すなわち手順SE03でデータ配信する際の定常時の配信周期が決定される。つまり、業務装置Gxは定期的にデータ配信を実行する。
管理システム10のデータ受信部11は、業務装置Gxからデータ配信されたデータを受信し、手順SE04で項目毎にデータ処理してその結果をテレメトリデータベースDB1に登録する。
一方、手順SE05においてデータ受信部11のデータ処理にかかる負荷が定常時に比べて上昇すると、OpS負荷レベル管理部15が変化した負荷レベルを考慮し、手順SE06で取得項目優先度判定を実施する。すなわち、図6に示した負荷レベル管理テーブル15aの「処理可能な項目計」が負荷レベルに応じて制限されるので、図7の項目数制限値Ntmaxが減少する。
その結果、手順SE07で管理システム10に配信されたデータをデータ受信部11が手順SE08でデータ処理する際に、取得設定ファイルCf2の内容、および項目数制限値Ntmaxに従い、優先度の高い項目だけが処理され、優先度が低い残りの項目のデータは間引きされる。
一方、手順SE09で管理システム10の負荷が高い状況が解消されると、再びOpS負荷レベル管理部15が最新の負荷レベルを考慮して、手順SE10で取得項目優先度判定を実施する。すなわち、負荷レベル管理テーブル15aの「処理可能な項目計」の制限が負荷レベルの減少に伴って緩和されるので、図7の項目数制限値Ntmaxが増大する。その結果、手順SE11で配信されたデータをデータ受信部11が手順SE12でデータ処理する際には、優先度の比較的低い項目のデータも処理対象になり、より多くのデータ項目がテレメトリデータベースDB1に登録される。
<負荷に応じてデータ配信間隔を制御する場合の動作例>
管理システム10がその負荷に応じてデータ配信間隔を制御する場合の動作例を図15および図16に示す。動作シーケンスの前半および後半が、それぞれ図15および図16に示されている。図15、図16に示した動作シーケンスについて以下に説明する。なお、図15に示した各手順SE21~SE24については、図14の手順SE01~SE04と同様であるのでこれらの説明は省略する。
図15の手順SE25において、管理システム10のデータ傾向測定部13は、テレメトリデータベースDB1に登録された内容に基づき、項目毎のデータの傾向を観察する。また、データ傾向測定部13が観察した結果を利用して、手順SE26で判断部14が判断を実施し、図11に示した処理を実行する。したがって、例えば長い間ほとんど値が変化しないデータ項目を見つけたような場合は、判断部14が手順SE27で取得間隔変更通知をデータ取得間隔管理部12bに送る。
この通知に従い、取得設定ファイル管理部12は、手順SE28で業務装置Gxの取得設定ファイルCf1に対する変更設定を実施する。これにより、業務装置Gxがデータ配信する際の配信対象項目が部分的に削除されたり、項目毎のデータ配信の間隔が変更される。その結果が、手順SE29のデータ配信に反映される。
管理システム10のデータ受信部11は、手順SE29で配信された各項目のデータを手順SE30でデータ処理してその結果をテレメトリデータベースDB1に登録する。この場合、手順SE29でデータ受信部11が受信するデータの項目数や受信間隔が変更されているので、手順SE30でデータ受信部11がデータ処理を実行する際の負荷の大きさは、手順SE28が実行される前と比べて削減される。
また、図16に示した例では、業務装置Gxがそれ自身におけるCPU使用率が上昇したことを手順SE31で検知した場合には、業務装置Gx自身が特別な制御を実施する。すなわち、取得設定ファイルCf1により配信対象になっている各項目について、項目毎の重みと、負荷レベルとを考慮して手順SE32で配信するデータ項目を削減する。例えば、重みが比較的大きい一部の項目のデータだけを手順SE32で配信する。
この場合、手順SE32でデータ受信部11が受信した項目を判断部14が手順SE33で監視して判断し、手順SE34で間引きリセット通知をデータ取得間隔管理部12bに送る。この通知に従い、取得設定ファイル管理部12は手順SE35で項目毎のデータ配信の間隔を変更するように取得設定ファイルCf1を設定する。
<保守管理システムおよびデータ処理方法の利点>
図3に示した管理システム10においては、データ受信部11がデータ処理を行う際に、取得設定ファイルCf2の内容に基づいて図7の処理を実行し、優先度の高いデータ項目だけに絞って処理することができる。したがって、複数の業務装置Gxからテレメトリにより大量のデータが配信される場合であっても、重要なデータの欠落をまねくことなく負荷を効率的に軽減できる。
また、管理システム10はデータ項目毎の必要性に応じた重みを制御に反映し、項目毎のデータ取得間隔や処理の優先度を動的に変化させることができる。そのため、業務装置Gxや管理システム10の稼働状況が変化した場合でも、重要なデータの欠落をまねくことなく負荷を効率的に軽減できる。
また、管理システム10は、図13のように判断部14が観測データDzの傾向を観察して管理システム10のデータ処理にフィードバックすることができる。そのため、様々な状況の変化に対して管理システム10が処理するデータ項目を適正化できる。
また、管理システム10は、図11に示した処理により、各項目のデータを配信する間隔を基準周期の倍数に従って変更するので、データの間引きが複数のデータ項目間の相関性に与える影響を抑制できる。
10 管理システム(保守管理システム)
11 データ受信部(データ処理部)
11a バッファ
12 取得設定ファイル管理部
12a 優先度管理部
12b データ取得間隔管理部
12c 取得設定部
12d 重み設定テーブル管理部
13 データ傾向測定部
14 判断部
15 OpS負荷レベル管理部(負荷レベル管理部)
15a 負荷レベル管理テーブル
16 異常検知部
18 制御用通信経路
21 管理者端末
22,22a テレメトリ通信経路
Cf1,Cf2 取得設定ファイル
Cf2a 優先度欄
Cf2b 項目欄
Cf2c 重み欄
Ct1,Ct2,Ctx,Cty,Ctz 状態
D01,D02 テレメトリ送信データ
Dx テレメトリ受信データ
Dz 観測データ
DB1 テレメトリデータベース
Gx,G01,G02,G03,G04,G05,G06,G07 業務装置
L10a CPU使用率
L10b メモリ使用率
Loa,Lob 負荷増大状態
NW 通信ネットワーク
Nt データ項目数
Ntmax 項目数制限値

Claims (7)

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

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018151602A JP7010171B2 (ja) 2018-08-10 2018-08-10 保守管理システムおよびデータ処理方法
US17/266,803 US11720092B2 (en) 2018-08-10 2019-08-01 Maintenance management system and data processing method
PCT/JP2019/030233 WO2020031846A1 (ja) 2018-08-10 2019-08-01 保守管理システムおよびデータ処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018151602A JP7010171B2 (ja) 2018-08-10 2018-08-10 保守管理システムおよびデータ処理方法

Publications (2)

Publication Number Publication Date
JP2020028005A JP2020028005A (ja) 2020-02-20
JP7010171B2 true JP7010171B2 (ja) 2022-01-26

Family

ID=69415240

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018151602A Active JP7010171B2 (ja) 2018-08-10 2018-08-10 保守管理システムおよびデータ処理方法

Country Status (3)

Country Link
US (1) US11720092B2 (ja)
JP (1) JP7010171B2 (ja)
WO (1) WO2020031846A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011114495A (ja) 2009-11-25 2011-06-09 Panasonic Electric Works Co Ltd ネットワーク監視制御装置
JP2014191697A (ja) 2013-03-28 2014-10-06 Advics Co Ltd 車載電子制御装置
JP6350770B1 (ja) 2017-03-31 2018-07-04 ダイキン工業株式会社 管理装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7917625B1 (en) * 2005-01-14 2011-03-29 Sprint Communications Company L.P. Predictive processing resource level control
JP5509994B2 (ja) 2010-03-30 2014-06-04 日本電気株式会社 障害継続監視システム、障害継続監視方法、及びその監視制御プログラム
CN102595497B (zh) * 2012-03-22 2016-03-30 中兴通讯股份有限公司 自动缓解处理器过载的cdma数据业务系统及其方法
JP6689412B2 (ja) * 2016-12-22 2020-04-28 日本電信電話株式会社 データ処理システムおよび方法
CN107124445B (zh) * 2017-03-31 2019-12-13 北京奇艺世纪科技有限公司 一种数据采集方法及装置
EP3709173B1 (en) * 2017-11-06 2023-12-06 Nippon Telegraph and Telephone Corporation Distributed information memory system, method, and program
CN112292839B (zh) * 2018-06-15 2024-09-03 日本电信电话株式会社 网络管理系统、管理装置、中继装置、方法以及程序介质
JP7176373B2 (ja) * 2018-11-27 2022-11-22 日本電信電話株式会社 光伝送システムおよび光伝送システムの故障診断方法
CN110035055B (zh) * 2019-02-19 2022-02-01 中国铁建重工集团股份有限公司 工业装备远程数据的传输方法
US11431169B1 (en) * 2021-08-20 2022-08-30 8Me Nova, Llc Systems and methods for microgrid metering and energy allocation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011114495A (ja) 2009-11-25 2011-06-09 Panasonic Electric Works Co Ltd ネットワーク監視制御装置
JP2014191697A (ja) 2013-03-28 2014-10-06 Advics Co Ltd 車載電子制御装置
JP6350770B1 (ja) 2017-03-31 2018-07-04 ダイキン工業株式会社 管理装置

Also Published As

Publication number Publication date
US11720092B2 (en) 2023-08-08
JP2020028005A (ja) 2020-02-20
WO2020031846A1 (ja) 2020-02-13
US20210311467A1 (en) 2021-10-07

Similar Documents

Publication Publication Date Title
EP1966712B1 (en) Load balancing mechanism using resource availability profiles
KR100840129B1 (ko) 통계적인 분석을 이용한 성능장애 관리시스템 및 그 방법
EP2656218B1 (en) Load shedding in a data stream management system
EP2874064B1 (en) Adaptive metric collection, storage, and alert thresholds
US10623482B2 (en) Server load management for data migration
KR20130083032A (ko) 클라우드 환경에서 서비스품질 보장을 위한 서비스수준협약 관리방법
JP2010238051A (ja) 負荷分散プログラム及び負荷分散装置
US11656609B2 (en) Detecting component degradation in industrial process plants based on loop component responsiveness
CN114938376B (zh) 基于优先级处理数据的工业物联网及其控制方法
JP7010171B2 (ja) 保守管理システムおよびデータ処理方法
JP2007249829A (ja) 内部ネットワーク間通信システム及び情報処理装置及び中継情報処理装置及び通信制御プログラム及び内部ネットワーク間における通信制御方法及び遠隔障害管理システム及び被管理装置及び管理装置
CN110336884B (zh) 服务器集群更新方法和装置
CN112948104B (zh) 负载均衡的数据采集方法及装置
US12074807B2 (en) Detecting shortfalls in an agreement between a publisher and a subscriber
JP5364600B2 (ja) 監視制御システム、被監視制御装置およびサーバ
JP7359222B2 (ja) 通信管理装置及び通信管理方法
JP6163474B2 (ja) ストレージ管理装置、ストレージ管理システム、制御方法及びプログラム
CN109831385B (zh) 一种消息处理方法、装置及电子设备
Almhanna et al. Dynamic Weight Assignment with Least Connection Approach for Enhanced Load Balancing in Distributed Systems
US11822979B2 (en) Computer system and data transmission control method
JP7493658B2 (ja) ネットワークデバイスを監視するシステムおよび方法
JP6288714B2 (ja) コンピュータネットワークシステム、コンピュータネットワークシステムでの負荷の移動要否の判定方法
US20220382747A1 (en) Source-adapted data retrieval for multi-tenant system
KR101015251B1 (ko) 통신망시스템의 관리시스템 및 그 관리방법
Cheng et al. Design and Implement for Reducing the Temporary High Load of Device in Industrial Networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201204

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211005

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20211214

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211227

R150 Certificate of patent or registration of utility model

Ref document number: 7010171

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150