JP2016062506A - 監視システム、監視装置及び監視方法 - Google Patents

Abstract

【課題】データ処理の実行順序関係に変更がある場合でも少ない労力でデータ処理の監視を継続する。
【解決手段】監視システムは、データを所定の規則に従って変換する変換部を備える。監視システムは、データが変換部によって変換されるとＳ２０２、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報とを作成しＳ２０７、データを変換した時刻である処理実行時刻を取得しＳ２０８、これらの情報を含むログ情報を生成する。
【選択図】図１３

Description

本発明の実施形態は、監視システム、監視装置及び監視方法に関する。

監視システムの一例として、ビルエネルギー管理システム（ＢＥＭＳ： Building Energy Management System）と呼ばれるシステムが存在する。これは、ビル内部に設置されている空調、照明などの設備機器や電力計などのセンサを統合的に監視及び制御し、設備機器の安定した運用や省エネなどを実現するシステムである。近年では、通信回線を用いて遠隔地にあるビルを監視するＢＥＭＳサービスや、複数のビルをまとめて統合的に監視するＢＥＭＳサービスなども存在する。

遠隔ＢＥＭＳサービスでは、数千におよぶ電力計の計測値を収集及び処理する必要があり、更に、それらに対してビル毎、フロア毎、部屋毎など、様々な単位での集計処理が実施される。これらの集計処理をどう行うかは収容するビルや顧客の都合で様々に異なる。また、遠隔ＢＥＭＳサービスは、一般に電力計データの他にも多様なデータ（例えば、設備機器の運転状況や温度計・湿度計の計測値）を収集及び管理する機能を備えており、それらのデータ処理の流れは電力計データに対するものとは異なっている。

ＢＥＭＳの運用者は、現状のシステムが仕様で定められた期限までに処理を完了しているか（例えば、消費電力データを画面に反映できているか）監視するデッドライン監視を行うことによって、現状のシステムが所望の性能を達成しているかを常時監視する。要求性能を達成しない場合、特に時間がかかっているデータ処理であるボトルネック箇所を検出するボトルネック検出を行う。そして、検出されたボトルネック箇所について適切なシステム増強を行うことによって、要求性能を満たすようにシステムを改善することが行われる。

従来の監視システムでは、監視システムで実施するデータ処理全体の実行順序関係（これを実行フローモデルという）を、予め監視システムに与えなければならない。このため、監視システムの処理内容が変化した場合、実行フローモデルも変更しなければならない。このために、運用者は、データ処理の実行順序関係に一部でも変更がある場合、実行フローモデルを書き換える労力がかかっていた。

特開２０１３−１６４７１２号公報 特開２００９−２７７０２３号公報

J. Tan, S. Kavulya, R. Gandhi and P. Narasimhan "Visual, Log-Based Causal Tracing for Performance Debugging of MapReduce Systems", pp. 795 - 806, In Proceedings of 2010 IEEE 30th International Conference on Distributed Computing Systems (ICDCS), 2010

そこで本発明の実施形態が解決しようとする課題は、データ処理の実行順序関係に変更がある場合でも少ない労力でデータ処理の監視を継続することが可能な監視システム、監視装置及び監視方法を提供することである。

一の実施形態によれば、監視システムは、データを所定の規則に従って変換する変換部を備える。データが前記変換部によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成する監視実行部を備える。

消費電力見える化機能で表示されるグラフの一例を示す図。 第１の実施形態におけるシステムの全体構成図。 第１の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図。 遠隔ＢＥＭＳ１の１周期分で行われる処理を示すフローチャート。 信号マスターＤＢ１６に保存される情報の例を示す図。 ファイルバッファ１１２に書き出されるファイルの例を示す図。 信号計測値ＤＢ１３に保存される情報の例を示す図。 集計マスターＤＢ１８に予め保存されている情報の例を示す図。 フローログＤＢ１７２に保存される情報の一例を示す図。 図９のフローログＤＢの情報をグラフ表現で表した図。 第１の実施形態における処理部５０と監視実行部６の構成を示す図。 プログラムそれぞれで各部が実行する処理を示す表。 第１の実施形態における監視実行部６の動作の一例を示すフローチャート 処理部５０から監視実行部６へ報告されるデータを示す表。 ノードＩＤの作成ルールを示す図。 ログ分析部１７３の詳細な構成を示す図。 デッドライン監視の処理の一例を示すフローチャート。 ボトルネック分析の処理の一例を示すフローチャート。 過程ノードにおける滞留時間の計算結果の例を示す図。 第２の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図。 第２の実施形態における監視実行部６ｂの構成を示す図。 第３の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図。 第３の実施形態における監視実行部６の構成を示す図。 第４の実施形態における遠隔ＢＥＭＳ１の内部構成を示す図。 第４の実施形態における報告データの具体例を示す図。 処理部５０−１が送信報告をしない場合のデータフローの例を示す図。 処理部５０−１が送信報告をする場合のデータフローの例を示す図。 本実施形態における処理部５０−１の送信イベント及び処理部５０−２の受信イベントに対するノードＩＤの作成ルールを示す図。

以下、図面を参照しながら、本発明の実施形態について説明する。

（第１の実施形態）
まず、第１の実施形態について説明する。第１の実施形態における遠隔ＢＥＭＳ（監視システム）１は、ＢＥＭＳの典型的な機能の一つである、消費電力を可視化する機能（以下、消費電力見える化機能という）を有する。これは、ビル内の電力計の計測値を収集、蓄積、及び集計し、グラフにまとめてユーザに提示する機能である。

図１は、消費電力見える化機能で表示されるグラフの一例を示す図である。このグラフでは、その日ビル全体で消費された電力量を３０分毎に集計して表示している。ビル全体の電力消費だけでなく、フロア毎、部屋毎、機器種別毎など、様々な基準で消費電力を集計、表示できるシステムも存在する。

消費電力見える化機能では、ビルで発生した消費電力をリアルタイムに画面へ反映することが求められる。例えば、図１に示す画面では、１６：００〜１６：３０のデータが示されていないが、これは画面閲覧時点でこの時間帯の計測値が得られていないからである。見える化機能の要求仕様としては、例えば「この時間帯の完全なデータは１６：４０（時間帯の終端から１０分後）までに表示する」といった項目が盛り込まれる。

図２は、第１の実施形態におけるシステムの全体構成図である。図２に示すように、本実施形態におけるシステムは、ビル２ａ、２ｂ、これらをネットワーク３を介して監視する遠隔ＢＥＭＳ（監視システム）１、情報（例えば、図１のグラフ）を表示するクライアント端末４とを備える。ビル２ａ及び２ｂと遠隔ＢＥＭＳ１はネットワーク３で接続されている。

遠隔ＢＥＭＳ１は、収集装置１１、差分計算装置１２、信号計測値ＤＢ（データベース）１３、集計装置１４、見える化装置１５、信号マスターＤＢ１６、監視装置１７、集計マスターＤＢ１８を備える。このように、遠隔ＢＥＭＳ１は、複数の計算機を備える。遠隔ＢＥＭＳ１において、これらの装置が連携し、ビル２ａ及び２ｂの消費電力を可視化した情報をクライアント端末４へ提供する。これにより、例えば、図１に示すグラフがクライアント端末４に表示され、クライアント端末４を使用するユーザは、ビル２ａ及び２ｂの消費電力を把握することができる。

収集装置１１は、ネットワーク３を通じてビル２ａ及び２ｂと通信し、ビル２ａ及び２ｂ内の電力計の計測値、設備機器の稼動情報、その他各種センサの計測値などを定期的に収集する。遠隔ＢＥＭＳ１が扱うこれらのデータをまとめて「信号データ」と呼ぶ。本実施形態では、収集装置１１は、３０分周期でビル２ａ及び２ｂと通信を行い、信号データを収集する。収集装置１１が収集した信号データは差分計算装置１２へ転送される。

差分計算装置１２は、収集装置１１が集めた信号データのうち、電力計データに対して差分演算を行う。これは、元の電力計データは単調増加する累積電力量を表しており、図１に示す３０分単位の消費電力量とは異なるためである。差分計算装置１１は前回のデータ収集で得られた電力計データと今回得られた電力計データの差分を計算し、その結果を新たな信号データとして生成する。その後、差分計算装置１２は、生成した信号データと収集された元の信号データを信号計測値ＤＢ１３へ書き込む。

信号計測値ＤＢ１３は信号データを保存するデータベースである。

集計装置１４は、信号計測値ＤＢ１３に格納された信号データの集計処理を行う。集計装置１４は、予め設定された集計グループに所属する信号データを合算集計し、その結果得られた合算信号データを、信号計測値ＤＢへ書き込む。この処理により、個々の電力計の３０分単位消費電力量データから、ビル毎やフロア毎の３０分単位消費電力量データが生成される。

見える化装置１５は、クライアント端末４が表示する情報をクライアント端末４へ出力する。例えば、見える化装置１５は、集計装置１４によって集計された消費電力量データを信号計測値ＤＢ１３から読み出し、読み出した消費電力量データから図１に示すグラフの画像データを生成し、この画像データをクライアント端末４へ出力する。これにより、クライアント端末４がこの画像データを表示することにより、図１に示すようなグラフが表示される。

信号マスターＤＢ１６は、遠隔ＢＥＭＳ１がビル２ａ及び２ｂから収集する信号に関する情報を保存するデータベースである。収集装置１１及び差分計算装置１２は信号マスターＤＢ１６の持つデータに基づいて、それぞれの処理を実施する。

監視装置１７は、遠隔ＢＥＭＳ１の動作を監視し、見える化装置１５が必要とする集計消費電力量データが、期限までに生成されているかを監視する。これをデッドライン監視という。また、必要に応じて、遠隔ＢＥＭＳ１の各処理のうち、どこで最も時間がかかっているかを分析する。これをボトルネック分析という。

集計マスターＤＢ１８は、信号データの集計処理を行うべき集計グループに関する情報を格納する。

図２に示すシステム内の各装置及びビルには固有のＩＰアドレスが割り当てられている。例えば、収集装置１１のＩＰアドレスは、１９２．１６８．０．１１で、差分計算装置１２は、１９２．１６８．０．１２で、信号計測値ＤＢ１３は１９２．１６８．０．１３で、集計装置１４は１９２．１６８．０．１４である。また、例えば、ビル２ａは１０．０．０．１、ビル２ｂは１０．０．０．２である。なお、他の装置もＩＰアドレスを持ってもよいが、本実施形態の説明には無関係であるため割愛する。

図３は、第１の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図である。以下、この図を用い、まず遠隔ＢＥＭＳ１の消費電力見える化機能に関わるデータ処理の詳細を解説する。

収集装置１１は、処理部５０−１、ファイルバッファ１１２、及び監視実行部６−１を備える。

処理部５０−１は、収集プログラム５−１を記憶しており、この収集プログラム５−１を実行することによって、データを収集する。具体的には、処理部５０−１は、ビル２ａ及び２ｂと通信し、信号データを収集する。

ファイルバッファ１１２は、収集装置１１の管理するファイルシステム上に設けられたデータバッファ領域である。収集プログラム１１１は、収集した信号データをファイルバッファ１１２上にファイルとして書き出す。ファイルバッファ１１２は、規定のファイル共有機能により、差分計算装置１２からもアクセス可能となっている。

差分計算装置１２は、処理部５０−２と監視実行部６−２とを備える。

処理部５０−２は、差分計算プログラム５−２を記憶しており、この差分計算プログラム５−２を実行することによって、信号データの差分計算を実行する。具体的には、処理部５０−２は、ファイルバッファ１１２から直近の信号データを、信号計測値ＤＢ１３から直近から一つ前の信号データを読み出し、読み出した二つの信号データの差分を計算し、計算して得られた差分信号データを、信号計測値ＤＢ１３へ書き込む。

集計装置１４は、処理部５０−３と監視実行部６−３とを備える。

処理部５０−３は、集計プログラム５−３を記憶しており、この集計プログラム５−３を実行することによって、信号データを合算集計する。具体的には、処理部５０−３は、信号計測値ＤＢ１３から信号データを読み出し、集計マスターＤＢ１８に定義された集計グループに従って合算集計を行い、その結果得られる合算信号データを信号計測値ＤＢ１３へ書き込む。

監視実行部６−１、６−２、６−３は、監視対象とする処理部５０−１、５０−２、５０−３毎に存在する。監視実行部６−１、６−２、６−３は、それぞれ処理部５０−１、５０−２、５０−３のデータ処理を監視し、特定のデータ処理が行われたときに、その情報をログ情報として監視装置１７へ送信する。

監視装置１７は、ログ保存部１７１と、フローログＤＢ１７２と、ログ分析部１７３とを備える。

ログ保存部１７１は、監視実行部６−１、６−２、６−３からログ情報を受け付け、受け付けたこれらの情報をフローログＤＢ１７２へ保存する。なお、これに限らず、ログ保存部１７１は、監視実行部６−１、６−２、６−３から受け付けたログ情報の少なくとも一つをフローログＤＢ１７２へ保存してもよい。

フローログＤＢ１７２はログ情報を保存するデータベースである。

ログ分析部１７３は、フローログＤＢ１７２に保存されたログ情報を分析し、デッドライン監視とボトルネック分析を行う。

遠隔ＢＥＭＳ１は、３０分周期で信号データを収集して処理する。続いて、図５〜図８を参照しつつ図４を用いて、遠隔ＢＥＭＳ１がその１周期分で行われる処理を説明する。図４は、遠隔ＢＥＭＳ１の１周期分で行われる処理を示すフローチャートである。

（ステップＳ１０１）まず、遠隔ＢＥＭＳ１は、各ビルから信号を収集することから始まる。具体的には処理部５０−１が信号マスターＤＢ１６（図５参照）を参照して収集すべき信号のリストを取得し、ビル２ａ及び２ｂからその時点での信号データを収集する。例えば、収集すべき信号のリストは、信号マスターＤＢ１６に含まれる全ての信号ＩＤを含む。

ここで、図５は、信号マスターＤＢ１６に保存される情報の例を示す図である。遠隔ＢＥＭＳ１で管理される信号データには、信号ＩＤという固有の識別子が設定されている。信号マスターＤＢ１６には、収集すべき信号を識別する信号ＩＤ、その信号を保持するビルを識別するビルＩＤ、ビル内におけるその信号を識別するビル内信号ＩＤ、及びその信号と対応する一周期前の信号との差分計算結果を示す差分信号を識別する差分信号ＩＤが格納される。

本実施形態における信号データは、ビル毎に独立して管理されている。そこで、処理部５０−１は、信号マスターＤＢ１６に示されるビル内信号ＩＤをビルへ送り、信号データを問い合わせる。処理部５０−１は、信号データをビルから受信すると、受信した信号データにタイムスタンプを付与する。このタイムスタンプとしては、一例として、処理部５０−１が、その周期における収集を開始した時刻が一律に用いられる。以降の処理において、信号データは信号ＩＤとタイムスタンプの組によって管理される。

（ステップＳ１０２）次に、ビルから信号データを収集した処理部５０−１は、それらのデータをファイルバッファ１１２へ書き出す。ここでは便宜上、処理部５０−１は収集したデータをビル毎、タイムスタンプ毎に異なるファイルへ書き出す。

図６は、ファイルバッファ１１２に書き出されるファイルの例を示す図である。この図６では、２０１４年５月２２日午前１０時ちょうどにデータ収集を開始した際に出力されるファイルＤ１とＤ２が示されている。ファイルＤ１のファイル名は、「ａ＿２０１４−０５−２２＿１０：００」であり、ファイルＤ２のファイル名は、「ｂ＿２０１４−０５−２２＿１０：００」である。

このファイルＤ１はビル２ａから収集した信号データを、ファイルＤ２はビル２ｂから収集した信号データを含んでいる。それぞれのファイルはＣＳＶ（Comma-Separated Values）形式であり、各行は、信号ＩＤ、タイムスタンプ、信号データの値をカンマで区切った文字列となっている。

（ステップＳ１０３）図４のステップＳ１０３において、処理部５０−２は、ファイルバッファ１１２を監視しており、処理部５０−１が信号データをファイルバッファ１１２に書き出すと、それらのファイルを読み出す

（ステップＳ１０４）処理部５０−２は、ファイルから読み出した信号データのうち、電力計データについて、差分計算を実施する。電力計データは、信号マスターＤＢ１６において差分信号ＩＤカラムがＮＵＬＬではない文字列（ここでは、番号）が割り当てられた信号ＩＤのデータである。処理部５０−２は、読み出した各信号データの信号ＩＤに対応する差分信号ＩＤを信号マスターＤＢ１６から取得する。その際、処理部５０−２は、差分信号ＩＤがＮＵＬＬでないか否か判断する。これにより、信号データが差分計算の対象であるか否か判断する。

（ステップＳ１０５）ステップＳ１０４で差分信号ＩＤがＮＵＬＬでないと判定された場合、処理部５０−２は、その信号について今回取得された値から前回収集時に取得された値を差し引いた差分信号データを生成し、生成した差分信号データと差分信号ＩＤを関連づけて、信号計測値ＤＢに記憶させる。ここで、前回収集時に取得された値は、信号計測値ＤＢ１３のうち、今回対象となっている信号ＩＤのレコードのうち、最新のタイムススタンプを有するレコードに含まれる「値」を抽出することで得られる。これにより、図７に示すように、例えば、差分信号ＩＤ「１０１」と、差分信号データの値「１．１７」とを含むレコードが信号計測値ＤＢに追記される。

図７は、信号計測値ＤＢ１３に保存される情報の例を示す図である。信号計測値ＤＢ１３は、信号ＩＤ、タイムスタンプ、値のカラムを有し、収集された信号データ、差分計算で得られた差分信号データ、または合算集計で得られた合算信号データの各時刻における値を保存する。ここで、この信号ＩＤのカラムには、信号データを識別するＩＤ、差分信号データを識別する差分信号ＩＤ、合算信号データを識別するＩＤが格納される。

また、処理部５０−２は、今回収集された値を保存し、次回の差分計算に備える。なお、差分信号データのタイムスタンプとしては、今回収集された信号データのタイムスタンプを用いる。

（ステップＳ１０６）次に、処理部５０−２は、差分計算を全て終えると、収集された信号データと差分計算によって生成された差分信号データとを全て信号計測値ＤＢ１３へ書き込む。信号計測値ＤＢ１３への書き込みが全て正常に完了すると、処理部５０−２は先に読み込んだファイルバッファ１１２中のファイルを削除する。

（ステップＳ１０７）次に、処理部５０−３は、信号計測値ＤＢ１３を監視しており、信号計測値ＤＢ１３内に合算集計を実施可能な複数の信号データがあれば、それを読み出す。合算集計を実施する信号データは、集計マスターＤＢ１８に定義されている。

図８は、集計マスターＤＢ１８に予め保存されている情報の例を示す図である。図８に示すように、集計マスターＤＢ１８は集計先信号ＩＤと集計元信号ＩＤのカラムを持つ。同一の集計先信号ＩＤを持つ集計元信号ＩＤの集合が一つの集計グループをなしており、これらの集計元信号ＩＤに対応するデータが合算されることにより合算信号データが生成される。

処理部５０−３は、集計マスターＤＢ１８を参照し、信号計測値ＤＢ１３から以下の三つの条件を全て満たす複数の集計元信号データを読み出す。

第１の条件は、集計マスターＤＢ１８で定義されるいずれかの集計グループに完全に合致する集計元信号であることである。すなわち、信号計測値ＤＢ１３の「信号ＩＤ」のカラムの値が集計マスターＤＢ１８の「集計元信号ＩＤ」のカラムの値と同じＩＤのレコードであることである。

第２の条件は、読み出す複数の集計元信号データに含まれるタイムスタンプが全て等しいことである。すなわち、信号計測値ＤＢ１３の「タイムスタンプ」のカラムの値が互いに同じタイムスタンプであることである。

第３の条件は、集計元信号データのタイムスタンプと同一のタイムスタンプを持つ集計先信号データが信号計測値ＤＢ１３内に存在しないことである。すなわち、信号計測値ＤＢ１３の「信号ＩＤ」のカラムの値が、集計マスターＤＢ１８において当該「集計元信号ＩＤ」と関連づけられた「集計先信号ＩＤ」であり、且つ信号計測値ＤＢ１３の「タイムスタンプ」のカラムの値が集計元信号データのタイムスタンプと同じレコードが存在しないことである。

以上の条件を満たす信号データは、合算集計が可能であるがまだ実施されていない信号データである。

例えば、タイムスタンプが「２０１４−０５−２２ １０：３０」であるデータについて合算集計する場合、図８に示すように集計先信号ＩＤが「２０１」である集計元信号ＩＤは「１０１」、「１０２」、「１０３」であるので、これら集計元信号ＩＤが「１０１」、「１０２」、「１０３」で且つタイムスタンプが「２０１４−０５−２２ １０：３０」を有するレコードに含まれる値「１．１７」、「０．８９」、「１．２７」が合算される。この合算により合算値３．３３が得られる。そして、処理部５０−３は、集計先信号ＩＤが「２０１」で、タイムスタンプが「２０１４−０５−２２ １０：３０」で、且つ値が「３．３３」であるレコードを信号計測値ＤＢ１３に追加する。

（ステップＳ１０８）処理部５０−３は、読み出した複数の信号データに含まれる値を全て足し合わせて、合算値を得る。処理部５０−３は、集計先信号ＩＤとステップＳ１０７で読み出した集計元信号データに含まれるタイムスタンプと、得られた合算値とを関連づけた集計先信号データを生成する。

（ステップＳ１０９）そして、処理部５０−３は、ステップＳ１０８で生成された集計先信号データを信号計測値ＤＢ１３に追記する。

以上のようにして、遠隔ＢＥＭＳ１は、ビル２ａ及び２ｂの電力計からデータを集め、３０分毎の消費電力量を計算し、ビル毎やフロア毎など様々な集計グループで合算処理し、その結果を信号計測値ＤＢ１３へ保存する。見える化装置１５は、クライアント４からの要求に応じて、信号計測値ＤＢ１３から適切な集計済み信号データを読み出し、この集計済み信号データから図１に示すようなグラフを生成し、生成したグラフを示す情報をクライアント端末４へ送信する。これにより、クライアント端末４に図１に示すようなグラフが表示される。

次に、以上で述べた遠隔ＢＥＭＳ１のデータ処理を監視し、デッドライン監視とボトルネック分析を実現する手法を解説する。

本実施形態の遠隔ＢＥＭＳ（監視システム）１は、遠隔ＢＥＭＳ（監視システム）１内のデータ処理を監視し、データの処理の流れを示すグラフ構造を生成するためのデータをフローログＤＢ１７２に記録する。

ここで、遠隔ＢＥＭＳ（監視システム）１は、収集装置１１、集計装置１２、集計装置１３、及び監視装置１７を備える。

監視実行部６−１、６−２、６−３は、それぞれ処理部５０−１、５０−２、５０−３がデータの受信、変換または送信を行うたびに、そのデータ処理を表現する１ホップのデータフローエッジを表すデータをログ保存部１７１に送信する。ここで、データフローエッジは、データの「始点ノード」と「終点ノード」、及び「処理実行時刻」の組である。

監視装置１７は、ログ保存部１７１、フローログＤＢ１７２、及びログ分析部１７３を備える。

ログ保存部１７１は、監視実行部６−ｉが生成したログ情報を記憶装置に記憶させる。具体的には例えば、ログ保存部１７１は、受信したデータフローエッジをフローログＤＢ１７２へ追加する。

図９は、フローログＤＢ１７２に保存される情報の一例を示す図である。図９に示すように、フローログＤＢ１７２は、ノード間の繋がりを表すエッジを識別するエッジＩＤ、始点ノードを識別する始点ノードＩＤ、終点ノードを識別する終点ノードＩＤ、及び処理実行時刻のカラムを有する。処理実行時刻はそのデータ処理が実行された時刻である。始点ノードＩＤ、終点ノードＩＤはそれぞれデータ処理の実行前及び実行後のデータを識別するデータ識別子を少なくとも含む。

本実施形態における始点ノードＩＤ及び終点ノードＩＤは、「（装置アドレス），（プログラムＩＤ）；（信号ＩＤ），（タイムスタンプ）」という形式をとる。

装置アドレスは、そのイベントでデータを扱う装置のＩＰアドレスである。プログラムＩＤはその装置内でデータを扱う処理部が実行するプログラムを識別するＩＤである。ここでは一例として、プログラムＩＤは、データを扱うプログラムの名前である。信号ＩＤは、そのイベントで扱われる信号データのＩＤで、タイムスタンプはそのイベントが実行されるタイムスタンプである。

上記ノードＩＤ形式のうち、前半の「（装置アドレス），（プログラムＩＤ）」の部分は、データを扱う主体を識別するＩＤであり、これをデータハンドラＩＤと呼ぶ。

一方、後半の「（信号ＩＤ），（タイムスタンプ）」の部分は、扱われるデータを一意に識別するＩＤであり、これをデータ識別子と呼ぶ。ノードＩＤはデータハンドラＩＤとデータ識別子の組み合わせから構成される。

図９に示すフローログＤＢ１７２の各レコード内の始点ノードＩＤで特定される始点ノードと終点ノードＩＤで特定される終点ノードとを繋いでエッジとすることにより、ログ分析部１７３は、フローログＤＢ１７２に記録されたログをグラフ構造として解釈することができる。

なお、一つの装置でデータの変換だけを行うシステムを監視する場合、データを扱う主体を識別する必要がないので、ノードＩＤに、データハンドラＩＤが含まれず、後半のデータ識別子だけが含まれる場合がある。

図１０は、図９のフローログＤＢの情報をグラフ表現で表した図である。簡単のため、この図ではノードＩＤとしてプログラムＩＤと信号ＩＤのみを示し、エッジの持つ処理実行時刻は「分：秒」という形式で示している。また、大括弧内の数字はエッジＩＤである。

図１０に示すように、フローログＤＢ１７２のログをグラフ構造として分析することで、集計済み信号（例えば、信号ＩＤが信号２０１）がどのような処理を経て生成されたのかを知ることができる。図１０の場合では、信号ＩＤ２０１は信号ＩＤ１０１、１０２、１０３の合算集計によって生成され、信号ＩＤ１０１は信号ＩＤ１から差分計算によって生成され、そして信号ＩＤ１はビルから収集されている。

なお、図１０には示されていないが、信号ＩＤ１０２及び１０３も信号ＩＤ１０１と同様にビルからのデータ収集、差分計算を経て生成されており、その記録がフローログＤＢ１７２に保存されているものとする。

ここで、図９に示すようなログを記録するためには、監視実行部６−１、６−２、６−３が適切なタイミングでデータフローエッジを作成し、ログ保存部１７１に送信しなければならない。以下、この方法について説明する。

監視実行部６−１、６−２、６−３は、それぞれ処理部５０−１、５０−２、５０−３の動作を監視するが、これらは共通した構造を持つ。図１１を用いて、これらの処理部５０−１、５０−２、５０−３と監視実行部６−１、６−２、６−３の共通構造を説明する。ここで、処理部５０−１、５０−２、５０−３を総称して処理部５０という。監視実行部６−１、６−２、６−３を総称して監視実行部という。

図１１は、第１の実施形態における処理部５０と監視実行部６の構成を示す図である。図１１に示すように、処理部５０は、保持するプログラムを読み出して実行することにより、受信部５１、変換部５２、及び送信部５３として機能する。受信部５１は、データを受信する。変換部５２は、受信部５１によって受信されたデータを所定の規則に従って変換する。なお、変換部５２は、受信部５１によって受信されたデータを変換するだけでなく、変換部５２を備える装置内部に保持されたデータを変換する場合もある。送信部５３は、変換部５２によって変換されたデータを送信する。なお、送信部５３は、変換部５２によって変換されたデータを送信するだけでなく、受信部５１で受信されたデータをそのまま送信する場合または予め保持されたデータを送信する場合もある。

続いて、図１２を用いて、プログラムそれぞれの場合に、受信部５１、変換部５２、送信部５３が実行する具体的な処理について説明する。図１２は、プログラムそれぞれで、各部が実行する処理を示す表である。図１２に示すように、収集プログラム５−１を実行する処理部５０−１は、データの変換を行わない。

図１２に示すように、収集プログラム５−１を実行する処理部５０−１において、受信部５１は、ビルから信号データを収集し、送信部５３は、ファイルバッファへ信号データを書き出す。

同様に、差分計算プログラム５−２を実行する処理部５０−２において、受信部５１は、ファイルバッファから信号データを読み込み、変換部５２は差分計算を行い、送信部５３は信号計測値ＤＢへ信号データを書き出す。

同様に、集計プログラム５−３を実行する処理部５０−３において、受信部５１は、信号計測値ＤＢから信号データを読み込み、変換部５２は合算集計を行い、送信部５３は信号計測値ＤＢへ信号データを書き出す。

監視実行部６は、処理部５０から報告を受け、データフローエッジを作成する。監視実行部６は、受信報告受付部６０１、変換報告受付部６０２、送信報告受付部６０３、ノードＩＤ導出部６０４、自プログラムＩＤ保持部６０５、自ＩＰアドレス保持部６０６、データフローエッジ作成部６０７、計時部６０８、及びデータフローエッジ送信部６０９を備える。

受信報告受付部６０１は、受信部５１からその動作に関する報告を示す報告データを受ける。

同様に、変換報告受付部６０２は、変換部５２からその動作に関する報告を示す報告データを受ける。

同様に、送信報告受付部６０３は、送信部５３からその動作に関する報告を示す報告データを受ける。

自プログラムＩＤ保持部６０５は、監視実行部６が監視する処理部５０−１〜５０−３が実行するプログラム５−１〜５−３毎に、プログラム５−１〜５−３それぞれを識別するプログラムＩＤを保持する。

自ＩＰアドレス保持部６０６は、監視実行部６−１〜６−３と処理部５０−１〜５−３が搭載されている装置のＩＰアドレスを保持する。

ノードＩＤ導出部６０４は、受信報告受付部６０１、変換報告受付部６０２または送信報告受付部６０３から受け付けた報告データと、自プログラムＩＤ保持部６０５が保持するプログラムＩＤと、自ＩＰアドレス保持部６０６が保持するＩＰアドレスと、に基づいてデータフローエッジの始点ノードＩＤと終点ノードＩＤを作成する。

計時部６０８は、計時機能を有し、データフローエッジ作成部６０７に現在時刻の情報を提供する。

データフローエッジ作成部６０７は、ノードＩＤ導出部６０４から受け付けた始点ノードＩＤと終点ノードＩＤに、処理実行時刻の情報として現在時刻を付与し、データフローエッジを作成する。

データフローエッジ送信部６０９は、データフローエッジ作成部６０７が作成したデータフローエッジをログ保存部１７１に送信する。

なお、監視実行部６は、例えば、以下に示すような三つの形態のいずれかで実現することができる。第１の形態は、監視実行部６の処理をソフトウェアライブラリの形式で実装し、プログラム５−１、５−２、５−３それぞれに組み込む形態である。

第２の形態は、監視実行部６の処理をプログラム５とは別のプログラムとして実装し、この別のプログラムが実行されることによって監視実行部６として機能する形態である。この場合処理部５０はプロセス間通信機構や共有メモリ機構を用いて監視実行部６へ報告データを送信する。なお、監視実行部６は常駐プロセスとしてもよいし、処理部５０が必要に応じて起動するようにしてもよい。

第３の形態は、監視実行部６の処理を処理部５０とは別の装置で動作するプログラムとして実装し、別の装置でこのプログラムが実行されることによって監視実行部６として機能する形態である。この場合、処理部５０はネットワークを通じて監視実行部６へ報告データを送信する。

続いて、図１３を用いて、監視実行部６の動作を説明する。図１３は、第１の実施形態における監視実行部６の動作の一例を示すフローチャートである。監視実行部６の動作は処理部５によるデータの受信、変換、送信のいずれかをきっかけにして始まる。

処理部５の受信部５１がデータを受信すると（ステップＳ２０１）、受信部５１はそのイベントを受信報告受付部６０１に報告する（ステップＳ２０４）。報告された情報はノードＩＤ導出部６０４へ送られる。

同様に、処理部５の変換部５２がデータを変換すると（ステップＳ２０２）、変換部５２はそのイベントを受信報告受付部６０１に報告する（ステップＳ２０５）。報告された情報はノードＩＤ導出部６０４へ送られる。

同様に、処理部５の送信部５３がデータを送信すると（ステップＳ２０３）、送信部５３はそのイベントを受信報告受付部６０１に報告する（ステップＳ２０６）。報告された情報はノードＩＤ導出部６０４へ送られる。

ノードＩＤ導出部６０４は、ステップＳ２０４〜Ｓ２０６のいずれかで報告された情報と、自プログラムＩＤと、自ＩＰアドレスとを用い、データフローエッジの始点ノードＩＤと終点ノードＩＤを作成する（ステップＳ２０７）。作成された始点ノードＩＤと終点ノードＩＤはデータフローエッジ作成部６０７へ送られる。データフローログエッジ作成部６０７は、計時部６０８から現在時刻を取得し（ステップＳ２０８）、作成された始点ノードＩＤと終点ノードＩＤと現在時刻とを用いて、データフローエッジを作成する（ステップＳ２０９）。作成されたデータフローエッジはデータフローエッジ送信部６０９へ送られる。データフローエッジ送信部６０９がデータフローエッジを監視装置６のログ保存部１７１へ送信する（ステップＳ２１０）。

続いて、図１４を用いて、データ受信時（図１３のステップＳ２０４）、データ変換時（図１３のステップＳ２０５）、データ送信時（図１３のステップＳ２０６）にそれぞれ処理部５０から監視実行部６へ報告されるデータについて説明する。図１４は、処理部５０から監視実行部６へ報告されるデータを示す表である。

図１４に示すように、データ受信時は、データ送信者のＩＰアドレスとプログラムＩＤ、及び受信したデータの信号ＩＤとタイムスタンプが報告される。データ変換時は変換元となる信号データのＩＤとタイムスタンプ、及び変換先となる信号データのＩＤとタイムスタンプが報告される。変換元や変換先の信号データが複数存在する場合、両者の全ての組み合わせが報告される。データ送信時は、データ受信者のＩＰアドレスとプログラムＩＤ、及び送信したデータの信号ＩＤとタイムスタンプが報告される。

また、図１４には、収集プログラム５−１、差分計算プログラム５−２、集計プログラム５−３が実行された場合に、データの受信、変換及び送信時に報告される具体例についても示されている。

各処理部５０が報告する情報のうち、データ送信者ＩＰアドレス及びデータ受信者ＩＰアドレスは、各処理部が通信を行う際に通信相手となる装置の情報を調べ、取得する。

データ送信者プログラムＩＤ及びデータ受信者プログラムＩＤは原則的に文字列定数として各処理部が保持し、報告する。これは、本実施形態のシステムの場合、各処理部がデータをやり取りする相手はほとんど決まっているからである。ただし、ファイルバッファ１２１と信号データをやり取りする場合は例外であり、この場合はファイル名をプログラムＩＤに含めるようにしている。このようにすることで、フローログＤＢ１７２の記録から、処理部５０−１及び処理部５０−２が具体的にどのファイルにアクセスしたかを調べられるようになっている。

受信の際に報告する信号ＩＤ及びタイムスタンプについては、処理部５０−１の場合は自身がビル２ａ及び２ｂへ問い合わせた信号ＩＤ及び収集を開始した時刻を用いる。

一方、処理部５０−２は、ファイルバッファ１１２から読み込んだファイルに記載される信号ＩＤ及びタイムスタンプを報告する。一方、処理部５０−３は、信号計測値ＤＢ１３内に記録されている信号ＩＤ及びタイムスタンプを報告する。ここでのタイムスタンプは、データ識別子の一部としてのタイムスタンプであり、図９の「処理実行時刻」とは異なる。データ識別子の一部であるタイムスタンプは、信号ＩＤとともにファイルバッファや信号計測値ＤＢ１３に記録されており、処理部５０−２及び処理部５０−３はそれを用いる。

なお、処理部５０−３は、合算集計処理において複数の集計元信号から一つの集計先信号を生成するため、集計元信号の数だけデータ変換の報告を行う。

以上のようにすれば、処理部５０−１、５−２、５−３はデータ受信、変換、送信時それぞれのイベントで監視実行部６が必要とする情報を報告できる。そして、監視実行部６は、報告された情報に基づいて、ノードＩＤ導出部６０４が始点ノードＩＤと終点ノードＩＤを作成する。

このことから、監視実行部６−ｉ（ｉは１から３までの整数）は、受信部５１によってデータが受信されるときに、受信されたデータの送信元を識別する情報を含む始点ノード識別情報（始点ノードＩＤ）と、前記データの受信を行う主体を識別する情報（例えば、差分計算プログラム５−２に対応するデータハンドラＩＤ）を含む終点ノード識別情報（終点ノードＩＤ）と、前記データを受信した時刻である処理実行時刻とを含むログ情報を生成する。ここで、本実施形態では、一例として、このログ情報に含まれる始点ノード識別情報（始点ノードＩＤ）及び終点ノード識別情報（終点ノードＩＤ）には、更に前記受信されたデータを識別する情報が含まれる。

そして、監視実行部６−ｉは、受信部５１によって受信されたデータが変換部５２によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報（始点ノードＩＤ）と、変換後のデータを識別する情報を含む終点ノード識別情報（終点ノードＩＤ）と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成する。ここで、本実施形態では、一例として、このログ情報に含まれる始点ノード識別情報（始点ノードＩＤ）及び終点ノード識別情報には、更に前記データの変換を行う主体を識別する情報（例えば、差分計算プログラム５−２に対応するデータハンドラＩＤ）が含まれる。

また、監視実行部６−ｉは、変換部５２によって変換されたデータが送信部５３によって送信されるときに、このデータの送信を行う主体を識別する情報（例えば、差分計算プログラム５−２に対応するデータハンドラＩＤ）を含む始点ノード識別情報（始点ノードＩＤ）と、前記送信されたデータの送信先を識別する情報を含む終点ノード識別情報（終点ノードＩＤ）と、前記データを送信した時刻である処理実行時刻とを含むログ情報を生成する。ここで、本実施形態では、一例として、このログ情報に含まれる始点ノード識別情報及び終点ノード識別情報には、更に送信されたデータを識別する情報が含まれる。

また、監視実行部６は、処理部５０がデータを受信したときに処理部５０からデータ受信報告情報を取得し、このデータ送信報告情報を取得する毎にログ情報を生成する。ここで、データ受信報告情報は、受信されたデータの送信元を識別する情報（例えば図１４のデータ送信者ＩＰアドレスとデータ送信者プログラムＩＤの組）と、この受信されたデータを識別する情報（例えば図１４の受信データの信号ＩＤと受信データのタイムスタンプの組）とを含む。

また、監視実行部６は、処理部５０がデータを変換したときに処理部５０からデータ変換報告情報を取得し、このデータ変換報告情報を取得する毎にログ情報を生成する。ここで、データ変換報告情報は、変換前のデータを識別する情報（例えば図１４の変換元信号ＩＤと変換元信号タイムスタンプの組）と、変換後のデータを識別する情報（例えば図１４の変換先信号ＩＤと変換先信号タイムスタンプの組）とを含む。

また、監視実行部６は、処理部５０がデータを送信したときに処理部５０からデータ送信報告情報を取得し、このデータ送信報告情報を取得する毎に第３のログ情報を生成する。ここで、データ送信報告情報は、送信されたデータの送信先を識別する情報（例えば図１４のデータ受信者ＩＰアドレスとデータ受信者プログラムＩＤの組）と、送信されたデータを識別する情報（例えば図１４の送信データの信号ＩＤと送信データのタイムスタンプの組）とを含む。

続いて、図１５を用いてノードＩＤの作成規則について説明する。図１５は、ノードＩＤの作成規則を示す図である。ノードＩＤ導出部６０４は、図１５に示す作成規則に従い、データ受信、変換、送信それぞれのイベントに相当する始点ノードＩＤと終点ノードＩＤを作成する。

ノードＩＤを作成する際は、データの受信及び送信時は、始点と終点でデータＩＤ部が共通であり、データの変換時は始点と終点でデータハンドラＩＤ部が共通である。このようにすることで、複雑なデータフローを確実に記録及び追跡できるようになる。

このように、処理部５０の処理がデータの送信の場合、監視実行部６は、処理部５０がデータを送信する毎に、ログ情報を生成する。このときの第１の識別情報（ここでは始点ノードＩＤ）は、このデータを送信した主体を識別するデータ送信主体識別子（図１５の自ＩＰアドレスと自プログラムＩＤの組）とこのデータを識別するデータ識別子（図１５の送信データの信号ＩＤと送信データのタイムスタンプの組）とを含む。また、このときの第２の識別情報（ここでは終点ノードＩＤ）は、データを受信する主体を識別するデータ受信主体識別子（例えば図１５のデータ受信者ＩＰアドレスとデータ受信者プログラムＩＤの組）とデータを識別するデータ識別子（例えば図１５の送信データの信号ＩＤと送信データのタイムスタンプの組）とを含む。

また、処理部５０の処理がデータの受信の場合、監視実行部６は、処理部５０がデータを受信する毎に、ログ情報を生成する。このときの第１の識別情報（ここでは始点ノードＩＤ）は、このデータを送信した主体を識別するデータ送信主体識別子（例えば図１５のデータ送信者ＩＰアドレスとデータ送信者プログラムＩＤとの組）とこのデータを識別するデータ識別子（例えば図１５の受信データの信号ＩＤと受信データのタイムスタンプとの組）とを含む。また、このときの第２の識別情報（ここでは終点ノードＩＤ）は、このデータを受信した主体を識別するデータ受信主体識別子（例えば図１５の自ＩＰアドレスと自プログラムＩＤとの組）とこのデータを識別するデータ識別子（例えば図１５の受信データの信号ＩＤと受信データのタイムスタンプとの組）とを含む。

また、処理部５０の処理がデータの変換の場合、監視実行部６は、処理部５０がデータを変換する毎に、ログ情報を生成する。このときの第１の識別情報（ここでは始点ノードＩＤ）は、このデータを変換する主体を識別するデータ変換主体識別子（例えば図１５の自ＩＰアドレスと自プログラムＩＤの組）と変換前のデータを識別するデータ識別子（例えば図１５の変換元信号ＩＤと変換元信号タイムスタンプとの組）とを含む。また、このときの第２の識別情報（ここでは終点ノードＩＤ）は、このデータを変換する主体を識別するデータ変換主体識別子（例えば図１５の自ＩＰアドレスと自プログラムＩＤとの組）と変換後の前記データを識別するデータ識別子（例えば図１５の変換先信号ＩＤと変換先信号タイムスタンプとの組）とを含む。

以上で説明した監視実行部６の動作によって、遠隔ＢＥＭＳ１の動作に応じてデータフローエッジが作成され、監視装置１７のログ保存部１７１へ送られる。データフローエッジはフローログＤＢ１７２に格納され、図９に示すようなログが記録される。

次に、これまで説明した仕組みによってフローログＤＢ１７２へ記録されたログを分析し、デッドライン監視とボトルネック分析を行う方法について説明する。

図１６は、ログ分析部１７３の詳細な構成を示す図である。図１６に示すように、ログ分析部１７３は、デッドライン監視部１７３１、ボトルネック分析部１７３２、計時部１７３３、及び分析報告部（報告部）１７３４を備える。デッドライン監視部１７３１とボトルネック分析部１７３２は、フローログＤＢ１７２及び集計マスターＤＢ１８と接続されている。

デッドライン監視部１７３１は、現在時刻が予め決められたデッドライン時刻に到達した場合、デッドライン時刻までに処理が完了している必要がある完了必要データそれぞれについて、第２の識別情報（ここでは終点ノードＩＤ）に当該データを識別する情報が含まれ且つ処理実行時刻がデッドライン時刻以前の時刻であるログ情報が記憶装置であるフローログＤＢ１７２に記憶されているか否かを判定する。

分析報告部１７３４は、デッドライン監視部１７３１により、完了必要データのうち少なくとも一つについて、終点ノード識別情報（終点ノードＩＤ）に当該データを識別する情報が含まれ且つ処理実行時刻がデッドライン時刻以前の時刻であるログ情報が記憶装置であるフローログＤＢ１７２に記憶されていないと判定された場合、デッドライン違反を通知する処理を実行する。

ボトルネック分析部１７３２は、記憶装置であるフローログＤＢ１７２に記憶されたログ情報の集合のうち、ある対象のログ情報に含まれる終点ノード識別情報（終点ノードＩＤ）と別のログ情報に含まれる始点ノード識別情報（始点ノードＩＤ）とが同じであるようなログ情報の組について、前記対象のログ情報に含まれる処理実行時刻と、前記別のログ情報に含まれる処理実行時刻との差分を、前記終点ノード識別情報（終点ノードＩＤ）または前記始点ノード識別情報（始点ノードＩＤ）によって特定されるデータの滞留時間として算出し、この滞留時間を用いてボトルネックとなっているデータ処理を特定する。

また、分析方向部１７３４は、ボトルネック分析部１７３２が特定した、ボトルネックとなっている処理を通知する処理を実行する。

続いて、図１７を用いてデッドライン監視部１７３１の動作について説明する。図１７は、デッドライン監視の処理の一例を示すフローチャートである。本実施形態の遠隔ＢＥＭＳ１は、データの収集及び集計は３０分周期で実施するため、デッドライン監視部１７３１も３０分おきに動作する。ここでは、集計消費電力量データは信号データの収集開始から５分後までに生成されていなければならないとする。つまり、信号データの収集開始時刻が１０：００、１０：３０、１１：００、…であるとするなら、デッドラインはそれぞれ１０：０５、１０：３５、１１：０５、…である。

（ステップＳ３０１）デッドライン監視の動作は、デッドライン監視部１７３１が、現在時刻が次のデッドラインに到達したことを検出したことをきっかけとして始まる。ここでは、現在時刻が２０１４−０５−２２ １０：０５であるとする。

（ステップＳ３０２）現在時刻がデッドラインに到達すると、デッドライン監視部１７３１は、監視対象のタイムスタンプを持つ集計済み信号ノードを識別するＩＤを終点ノードＩＤとするエントリをフリーログＤＢ１７２から検索する。

ここで、現在時刻が１０：０５だとすると、監視対象のタイムスタンプは１０：００である。また、集計済み信号の信号ＩＤのリストは、集計マスターＤＢ１８の集計先信号ＩＤカラムのデータを重複しないように抽出したものである。図８の例では、集計済み信号ノードのリストは「２０１，２０２，２０３，２１０」である。

具体的には、デッドライン監視部１７３１は、フローログＤＢ１７２内の集計済み信号ノードを、終点ノードＩＤが「１９２．１６８．０．１３， ＤＢ；（集計先信号ＩＤ）， ２０１４−０５−２２ １０：００」であるノードとして検索できる。

ここで、デッドライン監視部１７３１は、集計マスターＤＢ１８から得られたそれぞれの集計先信号ＩＤを、上記の「（集計先信号ＩＤ）」の部分に当てはめることにより、今回デッドラインをチェックすべきノードＩＤのリストを得ることができる。図８の例では、「（集計先信号ＩＤ）」は、「２０１，２０２，２０３，２１０」に含まれるいずれかの値である。

上記のノードは、集計済み信号データが信号計測値ＤＢ１３に存在することを示すノードである。そこで、デッドライン監視部１７３１は、上記のフローログＤＢ１７２の中から、上記のノードＩＤのリストに含まれる各ノードＩＤを終点ノードＩＤとして持つエントリを検索する（図９参照）。

（ステップＳ３０３）そして、デッドライン監視部１７３１は、検索した全てのノードＩＤについてフローログＤＢ１７２内にエントリが存在するか否か判定する。

（ステップＳ３０４）ステップＳ３０３で検索したノードＩＤのうちフローログＤＢ１７２内にエントリが存在しないノードＩＤがある場合、デッドライン監視部１７３１はデッドライン違反が発生した旨を分析報告部１７３４に伝える。この際、デッドライン違反が発生した信号ＩＤの情報なども分析報告部１７３４へ伝えられる。

分析報告部１７３４は、デッドライン監視部１７３１から受け取った情報を基に、デッドライン違反が発生したことを遠隔ＢＥＭＳ１の管理者へ報告する。これには、電子メールの発送、監視センターの画面表示、あるいは警報やパトランプ点灯などの方法を用いることができる。

（ステップＳ３０５）ステップＳ３０３で検索した全てのノードＩＤについてフローログＤＢ１７２内にエントリが存在すると判定された場合、全ての集計済み信号データがデッドラインまでに生成できたということであるため、デッドライン監視部１７３１は何も報告せずに次のデッドラインまで待機する。

なお、上記のフローログＤＢ１７２の検索処理（ステップＳ３０２）及びエントリの存在確認処理（ステップＳ３０３）は、本質的には「フローログＤＢ１７２内に所定のノードＩＤを持つノードが存在し、かつ、そのノードに入力エッジが存在する」という複合的な条件を満たしているか判定している。この判定は上記のように一度の検索処理で実施してもよいし、段階的に実施してもよい。すなわち、デッドライン監視部１７３１は、まず所定のノードＩＤが始点ノードＩＤもしくは終点ノードＩＤとしてフローログＤＢ１７２に含まれているかを検査し、含まれている場合には、そのノードに入力エッジが存在するかどうかを検査する、という方法をとってもよい。

以上のように、デッドライン監視部１７３１は、フローログＤＢ１７２内で、集計先信号ＩＤを終点ノードＩＤに含むエントリを検索することによって、ある時点で所望のデータが存在しているかどうかを検証し、デッドライン監視を行うことができる。

続いて、図１８を用いて、ボトルネック分析部１７３２の動作について説明する。図１８は、ボトルネック分析の処理の一例を示すフローチャートである。ボトルネック分析は任意のタイミングで実行すればよい。ボトルネック分析の実行タイミングとしては、１日に１回バッチ処理として実行する場合、遠隔ＢＥＭＳの管理者が明示的に指示して実行する場合、デッドライン違反をきっかけとして実行する場合、などがある。

（ステップＳ４０１）ボトルネック分析が開始すると、まず、ボトルネック分析部１７３２は、一例として、信号計測値ＤＢ１３内の信号を表す終点ノードＩＤをフローログＤＢ１７２から検索する。これには、終点ノードＩＤが「１９２．１６８．０．１３，ＤＢ；（＊）」であるエントリをフローログＤＢ１７２から検索すればよい。ただし、上記ノードＩＤにおいて（＊）は任意の文字列を表すワイルドカードである。この検索によって得られたノードを検索結果ノードと呼ぶ。

なお、長期間に渡ってシステムを運用した場合、上記パターンに合致するノードは非常に多くなる。そのため、ノードを検索する際には取得するノード数に上限を設けてもよい。また、検索する信号ＩＤや処理実行時刻の範囲が指定されてもよい。また、信号ＩＤとタイムスタンプ毎にボトルネック分析が実施済みかどうかを示す情報を保持し、未分析の信号データに相当するノードのみを検索するようにしてもよい。

（ステップＳ４０２）次に、ボトルネック分析部１７３２は、フローログＤＢ１７２の検索の結果得られたそれぞれのノードについて、エッジを逆方向にたどることによって、そのノードに至る過程に存在するノードを見つけ出す。これらのノードを過程ノードと呼ぶ。

（ステップＳ４０３）そして、各過程ノードについて、その過程ノード上でシステムの処理に要した時間を計算する。この要した時間を、過程ノードにおける滞留時間と呼ぶ。

図１９は、過程ノードにおける滞留時間の計算結果の例を示す図である。この図は、図１０の例において、ノードＩＤ「１９２．１６８．０．１３，ＤＢ；信号２０１，２０１４−０５−２２ １０：００」がフローログＤＢ１７２の検索で得られたとして滞留時間を計算したものである。

図１９において、「ＤＢ，信号２０１」と記した検索結果ノードと、そこからエッジを逆方向にたどって得られる過程ノードとが示されている。この例では、ノード「ＤＢ，信号１」を除く全てのノードが過程ノードとなる。

各過程ノードの滞留時間は、楕円内の秒数で示している。ここで、過程ノードの滞留時間は、滞留時間＝（当該ノードの出力エッジの処理実行時刻）−（当該ノードの入力エッジの処理実行時刻）で計算される。

なお、当該ノードに出力エッジが複数ある場合、デッドライン監視部１７３１は、例えば、過程ノードを見つける際に辿ったエッジを滞留時間の計算に用いるエッジにする。当該ノードに入力エッジが複数ある場合、デッドライン監視部１７３１は、それらの処理実行時刻の最小値、最大値、中央値、その他適当な代表値を「当該ノードの入力エッジの処理実行時刻」として用いてもよいし、または非決定的に滞留時間を複数計算してもよい。

（ステップＳ４０４）以上のようにして滞留時間の計算を完了すると、ボトルネック分析部１７３２は、次にそれらの滞留時間を集計する。これには様々な方法がある。

滞留時間の集計方法として、過程ノードをグループ化し、グループ毎に滞留時間を集計する方法がある。フローログＤＢ１７２中のノードをデータハンドラＩＤ（ノードＩＤの前半部分）毎にグループ化すれば、各ノードを装置単位、プログラム単位でグループ化できる。全ての検索結果ノードと過程ノードについて計算した滞留時間を上記グループ毎に集計することによって、各プログラムの処理時間の平均値、最小値、最大値、分散などの知見を得ることができる。この分析により、ボトルネック分析部１７３２は、特に処理時間が大きくなっているプログラムをボトルネックとして特定できる。

もう一つの滞留時間の集計方法として、検索結果ノード毎に最も滞留時間の大きい過程ノードを求める方法がある。図１９の場合、「ファイル，信号１」のノードの滞留時間が最も長くなっており、ここがボトルネックになっていると考えられる。このように、ボトルネック分析部１７３２は、滞留時間が最大となる過程ノードを、検索結果ノード毎に求める。その後、前述したグループ毎に滞留時間が最大となった回数を集計する。滞留時間が最大となった回数が特に大きくなっているグループがあれば、そのグループの処理がシステムのボトルネックである。このように、ボトルネック分析部１７３２は、グループ毎に滞留時間が最大となった回数を集計し、集計した回数に応じて、ボトルネックとなっているグループの処理を特定してもよい。

ボトルネック分析部１７３２は、滞留時間の集計が完了した場合、この集計結果を分析報告部１７３４へ渡し、分析報告部１７３４がこの集計結果を遠隔ＢＥＭＳの管理者へ報告する。ここで、集計結果には、特定されたボトルネックとなっている処理に関する情報が含まれていてもよい。また、報告の手段としては、デッドライン監視の場合（図１７のステップＳ３０４参照）と同様の手段を用いることができる。

以上、第１の実施形態における遠隔ＢＥＭＳ（監視システム）１は、ログ情報を用いてデータ処理を監視するシステムであって、データを受信する受信部５１と、受信部５１によって受信されたデータを変換する変換部５２と、監視実行部６と、を備える。

監視実行部６は、受信部５１によって受信されたデータが変換部５２によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成する。ログ保存部１７１は、このログ情報を記憶装置であるフローログＤＢ１７２に記憶させる。また、監視実行部６は、受信部５１によってデータが受信されるときに、受信されたデータの送信元を識別する情報を含む始点ノード識別情報と、このデータの受信を行う主体を識別する情報を含む終点ノード識別情報と、前記データを受信した時刻である処理実行時刻とを含むログ情報を生成する。そして、ログ保存部１７１は、このログ情報を記憶装置であるフローログＤＢ１７２に記憶させる。

また、遠隔ＢＥＭＳ（監視システム）１は、変換部５２によって変換されたデータを送信する送信部５３を更に備える。そして、監視実行部６は、変換部５２によって変換されたデータが送信部５３によって送信されるときに、このデータの送信を行う主体を識別する情報を含む始点ノード識別情報と、この送信されたデータの送信先を識別する情報を含む終点ノード識別情報と、前記データを送信した時刻である処理実行時刻とを含むログ情報を生成する。そして、ログ保存部１７１は、このログ情報を記憶装置であるフローログＤＢ１７２に記憶させる。

これにより、本実施形態の監視実行部６は、データの受信、変換、送信といった個別のデータ処理それぞれについてログ情報を生成し、ログ保存部１７１は、生成されたログ情報を順次、フローログＤＢ１７２に蓄積する。このため、これらの記憶されたログ情報から、対象のログ情報に含まれる始点ノードＩＤと別のログ情報に含まれる終点ノードＩＤが同じである二つのログ情報を検出する毎に、対象のログ情報を入力側に別のログ情報を出力側にしてつなぎ合わせることにより、データ処理の流れをグラフ構造で表すことができる。その結果、データ処理の流れを監視することができる。

また、本実施形態の監視実行部６は、データ処理の実行順序関係に変更があった場合でも、構成及び設定を変更することなく、変更前と同じようにログ情報を生成し、フローログＤＢ１７２に蓄積することによって、変更後の処理の流れをグラフ構造で表すことができる。このことから、データ処理の実行順序関係を変更した場合に人手を介した遠隔ＢＥＭＳ（監視システム）１の変更がいらないので、データ処理の実行順序関係に変更がある場合でも少ない労力でデータ処理の監視を継続することができる。

また、本実施形態の遠隔ＢＥＭＳ（監視システム）１は、データ処理のフローが複雑で流動的である場合でも、それぞれのフローに即したログ情報を生成でき、常に現状を正しく反映した分析を行うことができる。

更に、ログ情報には処理実行時刻が含まれるため、グラフ構造と処理実行時刻を合わせて分析することで、デッドライン監視とボトルネック分析を行うことができる。

（第２の実施形態）
続いて、第２の実施形態について説明する。第１の実施形態では、監視実行部６は監視対象とする処理部５０−ｉ毎に存在した。それに対し、第２の実施形態では、一つの監視実行部６ｂが複数の処理部５０を監視する。

図２０は、第２の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図である。図２０に示すように、第２の実施形態における遠隔ＢＥＭＳ１の構成は図３に示す第１の実施形態における遠隔ＢＥＭＳ１の詳細構成とほぼ同じであるが、監視実行部６ｂが独立した監視実行装置１９内に位置し、処理部５０−１、５０−２、５０−３を全て監視している点が異なる。なお、監視実行装置１９は、他の装置（例えば、監視装置１７）と一体の装置として構成されてもよい。

図２１は、第２の実施形態における監視実行部６ｂの構成を示す図である。第２の実施形態における監視実行部６ｂの構成は図１１に示す第１の実施形態における監視実行部６の構成とほぼ同じであるが、自プログラムＩＤ保持部６０５と自ＩＰアドレス保持部６０６がなく、報告者導出部６１０が加わっている点が異なる。

第１の実施形態では、ノードＩＤ導出部６０４は図１５に示すルールに基づいて、データフローエッジの始点ノードＩＤと終点ノードＩＤを定めた。しかし、本実施形態の監視実行部６ｂは、複数のプログラムの動作を監視するため、図１５で必要となる「自ＩＰアドレス」と「自プログラムＩＤ」を予め保持しておくことができない。

そこで、報告者導出部６１０は、報告を行った監視対象の処理部５０を有する装置に割り当てられたＩＰアドレス（以下、報告処理部のＩＰアドレスという）と、当該処理部５０が実行するプログラムを識別するプログラムＩＤ（以下、報告処理部のプログラムＩＤという）を導出し、ノードＩＤ導出部６０４へ渡す。このように、報告者導出部６１０は、データ処理の報告を行った処理部５０を識別する報告主体識別情報を取得する。ここでは、報告主体識別情報は一例として、報告処理部のＩＰアドレスと報告処理部のプログラムＩＤの組である。

報告処理部のＩＰアドレスは、受信報告受付部６０１、変換報告受付部６０２、及び送信報告受付部６０３のいずれかが、処理部５０−１〜５０−３のいずれかから報告データを受け付けた際に取得してもよいし、処理部５０−１〜５０−３が自身のＩＰアドレスを報告データに含めて送信してもよい。

また、報告処理部のプログラムＩＤは、報告処理部ＩＰアドレスや報告データの内容から推定しても良いし、処理部５０−１〜５０−３が、自身が実行するプログラムを識別するプログラムＩＤを報告データに含めて送信してもよい。

このように、第２の実施形態における遠隔ＢＥＭＳ（監視システム）１において、監視実行部６ｂは、データ処理の報告を行った処理部５０を識別する報告主体識別情報を取得する報告者導出部６１０を備える。これにより、一つの監視実行部６ｂが複数のプログラム５を監視する場合であっても始点ノードＩＤ、終点ノードＩＤを導出でき、第１の実施形態と同様にシステムの動作を監視することができる。

（第３の実施形態）
続いて、第３の実施形態について説明する。第１の実施形態においては、監視実行部６は、処理部５０の能動的な報告に基づいてデータフローエッジを作成していた。しかし、処理部５０のデータ受信とデータ送信は外部からそのイベントを捕捉できることが多く、その場合、監視実行部６は処理部５０からの能動的な報告を必要としない。そこで、本実施形態では、監視実行部６が処理部５０の通信を外部から捕捉してデータフローエッジを作成する。

図２２は、第３の実施形態における遠隔ＢＥＭＳ１の内部構成の詳細を示す図である。図２２に示すように、第３の実施形態における遠隔ＢＥＭＳ１の構成は図３に示す第１の実施形態における遠隔ＢＥＭＳ１の詳細構成と比べて、受信捕捉部７−１、７−２、７−３と送信捕捉部８−１、８−２、８−３とが追加されたものになっている。

処理部５０−１とネットワーク３との間に受信捕捉部７−１が設けられ、処理部５０−１とファイルバッファ１１２との間に送信捕捉部８−１が設けられている。また、処理部５０−２とファイルバッファ１１２との間に受信捕捉部７−２が設けられ、処理部５０−２と信号計測値ＤＢ１３との間に送信捕捉部８−２が設けられている。また、処理部５０−３と信号計測値ＤＢ１３との間に受信捕捉部７−３が設けられ、処理部５０−３と集計マスターＤＢ１８との間に送信捕捉部８−３が設けられている。

受信捕捉部７−ｉ（ｉは１から３までの整数）は、処理部５０−ｉへ転送されてくるデータを全て捕捉し、その内容を分析し、監視実行部６の後述する受信報告受付部６０１へ報告データを送る。受信捕捉部６１１が送る報告データは第１の実施形態でデータ受信部５１が送るデータ（図１４参照）と同じである。以下、受信捕捉部７−１、７−２、７−３を総称して、受信捕捉部７という。

送信捕捉部８−ｉは、処理部５０−ｉから転送されていくデータを全て捕捉し、その内容を分析し、監視実行部６の後述する送信報告受付部６０３へ報告データを送る。送信捕捉部６１２が送る報告データは、第１の実施形態でデータ送信部５３が送るデータ（図１４参照）と同じである。以下、送信捕捉部８−１、８−２、８−３を送信捕捉部８という。

図２３は、第３の実施形態における監視実行部６の構成を示す図である。この構成は、図１１に示す第１の実施形態における監視実行部６の構成とほぼ同じであるが、受信報告受付部６０１が受信捕捉部７から報告を受け、送信報告受付部６０３が送信捕捉部８から報告を受ける点が異なる。

本実施形態を実装するには、受信捕捉部７や送信捕捉部６１２が適切に転送データを捕捉できなければいけない。受信捕捉部７や送信捕捉部６１２は、以下に示すような、第１〜第４のいずれかの通信の捕捉方法を使用してもよい。

第１の捕捉方法は、ＯＳ（Operating System）が提供するパケットキャプチャ機能を利用し、装置のネットワークインタフェースに出入りするデータを捕捉する方法である。この方法はデータの転送が装置間で実施される場合に有効である。

第２の捕捉方法は、システムのネットワークにリピータを導入し、ネットワークを流れるデータを捕捉する方法である。この方法はデータの転送が装置間で実施される場合に有効である。

第３の捕捉方法は、データ転送を仲介するミドルウェアのデータ捕捉機能を活用するか、ミドルウェアを改造してデータを捕捉する方法である。

第４の捕捉方法は、データ転送の際に利用されるＯＳのシステムコールを捕捉する方法である。

いずれの方法においても、通信が暗号化されていなければ、捕捉した通信内容から信号ＩＤ等を抽出し、報告データを作成することができる。なお、受信捕捉部６１１及び送信捕捉部６１２は通信の捕捉が可能であれば、処理部５０と同じ装置に搭載してもよいし、異なる装置であってもよい。

以上、第３の実施形態において、遠隔ＢＥＭＳ（監視システム）１は、受信部５１に入力されるデータを捕捉する受信捕捉部７を更に備える。そして、監視実行部６は、受信捕捉部７が捕捉したデータを用いて、ログ情報を生成する。また、遠隔ＢＥＭＳ（監視システム）１は、送信部５３から出力されるデータを捕捉する送信捕捉部８を更に備える。監視実行部６は、送信捕捉部８が捕捉したデータを用いて、ログ情報を生成する。

第３の実施形態における遠隔ＢＥＭＳ（監視システム）１の構成によれば、システム監視を実現するために必要となるプログラム５の変更及び改造を最小限に押さえることができる。特に、収集プログラム５のようにデータの変換を行わないプログラムを実行する処理部５０−１を監視する場合、遠隔ＢＥＭＳ（監視システム）１は、外部からデータ転送を捕捉するだけで監視を行うことができる。

（第４の実施形態）
続いて、第４の実施形態について説明する。第１の実施形態において、処理部５０−１、５０−２、５０−３はファイルバッファ１１２、信号計測値ＤＢ１３というデータストレージを介してデータを転送していた。多くの場合、これらのデータストレージはアプリケーションレベルの監視機能（例えば、信号ＩＤやタイムスタンプの報告機能）を組み込むことが困難であるため、第１の実施形態ではデータストレージを扱う処理部５０を監視することで、データフロー全体の監視を実現していた。

しかし、データフローを構成する連続した機能要素に監視機能を組み込むことができる場合、監視箇所を削減することができる。あるいは、データ転送に要する時間の監視が可能となる。

そこで、本実施形態では、処理部５０−１、５０−２がファイルバッファ１１２を介さずに直接データをやり取りする場合におけるシステム監視の方法について説明する。

図２４は、第４の実施形態における遠隔ＢＥＭＳ１の内部構成を示す図である。第４の実施形態における遠隔ＢＥＭＳ１の構成は、図３に示す第１の実施形態における遠隔ＢＥＭＳ１の構成とほぼ同じであるが、ファイルバッファ１１２が存在しない点が異なる。

本実施形態においては、処理部５０−１は、ビル２ａ及び２ｂから収集したデータをシステム内ネットワーク経由で処理部５０−２に転送する。処理部５０−２はそのようにして受信したデータに対し、第１の実施形態と同様の差分計算処理を実施して、差分計算結果を信号計測値ＤＢ１３へ書き込む。

図２５は、第４の実施形態における報告データの具体例を示す図である。本実施形態においては、収集プログラムによる報告データは二通り考えられるため、図２５ではそれら両方を示している。なお、集計プログラムを実行する処理部５０−３の報告データは第１の実施形態と同様である。

本実施形態においては、図２５の収集プログラムの場合（Ａ）に示すように、収集プログラムを実行する処理部５０−１は、送信時における報告を省略することができる。これは、データの転送を差分計算プログラムを実行する処理部５０−２の受信イベントで報告できるからである。この場合、監視実行部６におけるノードＩＤの生成ルールは、第１の実施形態のもの（図１５参照）をそのまま使うことができる。

図２６Ａは、処理部５０−１が送信報告をしない場合のデータフローの例を示す図である。図１０と比較すれば分かるように、このグラフ表現は、第１の実施形態におけるグラフから「ファイル」に相当するノードが抜け、「収集」のノードと、「差分」のノードが直接接続されている。

このように、監視対象であるプログラムが直接通信する場合、受信イベントのみを記録すればデータフローを問題なく記録することができる。なお、送信イベントのみを記録しても同様のデータフローを記録することができるが、一般に、データの送信時点ではそのデータが正常に送信先に届くかどうかは分からないため、受信イベントを記録するのが望ましい。

一方、図２５の収集プログラムの場合（Ｂ）に示すように、本実施形態においても、データの送信時と受信時両方でイベントを報告させることができる。この場合、収集プログラム５−１を実行する処理部５０−１と、差分計算プログラム５−２を実行する処理部５０−２についてのノードＩＤ作成ルールを、図２７に示すように改める必要がある。

図２７は、本実施形態における処理部５０−１の送信イベント及び処理部５０−２の受信イベントに対するノードＩＤの作成ルールを示す図である。図２７に示すように、この場合では、処理部５０−１と処理部５０−２の中間に、「収集装置１１のＩＰアドレス，収集−差分計算装置１２のＩＰアドレス，差分」（具体的には、「１９２．１６８．０．１１，収集−１９２．１６８．０．１２，差分」）というデータハンドラＩＤを持つ仮想的なノードを想定する。そして、この仮想的なノードを経由してデータが転送されるものとして、データフローを記録する。

図２７に示すノードＩＤ作成ルールを用いて、監視実行部６は、データを送信する処理部（第１の処理部）５０−１と、データを受信する処理部（第２の処理部）５０−２とを監視する。具体的には、監視実行部６は、処理部（第１の処理部）５０−１が処理部（第２の処理部）５０−２へデータを送信する毎に、第１の識別子と第２の識別子と前記送信した時刻とを含むログ情報を生成する。

ここで、第１の識別子は、データを送信する主体を識別するデータ送信主体識別子（図２７の例では、自ＩＰアドレスと自プログラムＩＤの組）と送信されたデータを識別するデータ識別子（図２７の例では、送信データの信号ＩＤと送信データのタイムスタンプの組）とを含む。

第２の識別子は、データを送信する主体を識別するデータ送信主体識別子（図２７の例では、自ＩＰアドレスと自プログラムＩＤの組）と、データを受信する主体を識別するデータ受信主体識別子（図２７の例では、データ受信者ＩＰアドレスとデータ受信者プログラムＩＤの組）と、前記送信されたデータを識別するデータ識別子（図２７の例では、受信データの信号ＩＤと受信データのタイムスタンプの組）とを含む。

また、監視実行部６は、処理部（第２の処理部）５０−２が処理部（第１の処理部）５０−１からデータを受信する毎に第３の識別子と第４の識別子と前記受信した時刻とを含むログ情報を生成する。

ここで、第３の識別子は、データを送信する主体を識別するデータ送信主体識別子（図２７の例では、データ送信者ＩＰアドレスとデータ送信者プログラムＩＤ）と、データを受信する主体を識別するデータ受信主体識別子（図２７の例では、自ＩＰアドレスと自プログラムＩＤ）と、前記受信されたデータを識別するデータ識別子（図２７の例では、受信データの信号ＩＤと受信データのタイムスタンプの組）とを含む。

第４の識別子は、データを受信する主体を識別するデータ受信主体識別子（図２７の例では、自ＩＰアドレスと自プログラムＩＤの組）と、受信されたデータを識別するデータ識別子（図２７の例では、受信データの信号ＩＤと受信データのタイムスタンプの組）とを含む。

図２６Ｂは、処理部５０−１が送信報告をする場合のデータフローの例を示す図である。

図２６Ａと図２６Ｂは同一のデータフローを記録したものである。図２６Ａを見ると、信号１と信号２の両方とも「収集」ノードで３秒間データが滞留しているものとして記録されている。ここで示される滞留時間には、収集プログラム６−１を実行する処理部５０−１がデータを保持している時間と、データが差分計算プログラム６−２を実行する処理部５０−２へ伝送される時間の両方が含まれる。

一方、図２６Ｂに示すデータフローでは、信号１については、処理部５０−１が、信号１を送信する前にデータを保持する時間に３秒かかっており、信号２は処理部５０−１による送信から処理部５０−２による受信までにかかる伝送遅延として３秒かかっている。

このように、データ転送イベントを記録する際に仮想的な中間ノードを仮定することによって、データ転送そのものにかかった時間を記録することができる。

以上、第４の実施形態における遠隔ＢＥＭＳ（監視システム）１において、監視実行部６は、データを送信する処理部（第１の処理部）５０−１と、前記データを受信する処理部（第２の処理部）５０−２とを監視し、処理部（第１の処理部）５０−１が処理部（第２の処理部）５０−２へデータを送信する毎に、第１の識別子と第２の識別子と送信した時刻とを含むログ情報を生成し、処理部（第２の処理部）５０−２が処理部（第１の処理部）５０−１からデータを受信する毎に第３の識別子と第４の識別子と受信した時刻とを含むログ情報を生成する。

以上のように、データフロー上で隣接する処理部を両方とも監視する場合、データ転送イベントを記録する際に仮想的な中間ノードを仮定することによって、伝送遅延を評価することができる。

また、本実施形態では、処理部５０−１と処理部５０−２との間のデータの受け渡しにファイルバッファを用いることなく、直接、処理部５０−１から処理部５０−２へデータを転送するようにしたので、第１の実施形態と比べて、監視するイベントを削減することができる。

また、各実施形態の監視実行部６、６ｂ及び／または監視装置１７の各処理を実行するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、プロセッサが実行することにより、各実施形態の監視実行部６、６ｂ及び／または監視装置１７に係る上述した種々の処理を行ってもよい。

以上、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に渡る構成要素を適宜組み合わせてもよい。

１ 遠隔ＢＥＭＳ（監視システム）
２ａ、２ｂ ビル
３ ネットワーク
４ クライアント端末
１０ 監視システム
１１ 収集装置
１２ 差分計算装置
１３ 信号計測値ＤＢ
１４ 集計装置
１５ 見える化装置
１６ 信号マスターＤＢ
１７ 監視装置
１８ 集計マスターＤＢ
５０、５０−１、５０−２、５０−３ 処理部
５１ 受信部
５２ 変換部
５３ 送信部
１１２ ファイルバッファ
６、６−１、６−２、６−３、６ｂ 監視実行部
１７１ ログ保存部
１７２ フローログＤＢ
１７３ ログ分析部
６０１ 受信報告受付部
６０２ 変換報告受付部
６０３ 送信報告受付部
６０４ ノードＩＤ導出部
６０５ 自プログラムＩＤ保持部
６０６ 自ＩＰアドレス保持部
６０７ データフローエッジ作成部
６０８ 計時部
６０９ データフローエッジ送信部
１７３１ デッドライン監視部
１７３２ ボトルネック分析部
１７３３ 計時部
１７３４ 分析報告部（報告部）

Claims (18)

1. ログ情報を用いてデータ処理を監視する監視システムであって、
   データを所定の規則に従って変換する変換部と、
   前記データが前記変換部によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成する監視実行部と、
   を備える監視システム。
2. 前記ログ情報に含まれる前記始点ノード識別情報及び前記終点ノード識別情報には、更に前記データの変換を行う主体を識別する情報が含まれる
   請求項１に記載の監視システム。
3. データを受信する受信部を更に備え、
   前記監視実行部は、前記受信部によって前記データが受信されるときに、前記受信されたデータの送信元を識別する情報を含む始点ノード識別情報と、前記データの受信を行う主体を識別する情報を含む終点ノード識別情報と、前記データを受信した時刻である処理実行時刻とを含む第２のログ情報を生成する
   請求項１または２に記載の監視システム。
4. 前記第２のログ情報に含まれる前記始点ノード識別情報及び前記終点ノード識別情報には、更に前記受信されたデータを識別する情報が含まれる
   請求項３に記載の監視システム。
5. データを送信する送信部を更に備え、
   前記監視実行部は、前記データが送信部によって送信されるときに、前記データの送信を行う主体を識別する情報を含む始点ノード識別情報と、前記送信されたデータの送信先を識別する情報を含む終点ノード識別情報と、前記データを送信した時刻である処理実行時刻とを含む第３のログ情報を生成する
   請求項１から４のいずれか一項に記載の監視システム。
6. 前記第３のログ情報に含まれる前記始点ノード識別情報及び前記終点ノード識別情報には、更に前記送信されたデータを識別する情報が含まれる
   請求項５に記載の監視システム。
7. 前記ログ情報と前記第２のログ情報と前記第３のログ情報の少なくとも一つを記憶装置に記憶させるログ保存部
   を更に備える請求項５または６に記載の監視システム。
8. 現在時刻が予め決められたデッドライン時刻に到達した場合、前記デッドライン時刻までに処理が完了している必要がある完了必要データそれぞれについて、前記終点ノード識別情報に当該データを識別する情報が含まれ且つ前記処理実行時刻が前記デッドライン時刻以前の時刻であるログ情報が前記記憶装置に記憶されているか否かを判定するデッドライン監視部と、
   前記デッドライン監視部により、前記完了必要データのうち少なくとも一つについて、前記終点ノード識別情報に当該データを識別する情報が含まれ且つ前記処理実行時刻が前記デッドライン時刻以前の時刻であるログ情報が前記記憶装置に記憶されていないと判定された場合、デッドライン違反を通知する処理を実行する報告部と、
   を更に備える請求項７に記載の監視システム。
9. 前記記憶装置に記憶されたログ情報の集合のうち、ある対象のログ情報に含まれる前記終点ノード識別情報と別のログ情報に含まれる前記始点ノード識別情報とが同じであるようなログ情報の組について、前記対象のログ情報に含まれる処理実行時刻と、前記別のログ情報に含まれる処理実行時刻との差分を、前記終点ノード識別情報または前記始点ノード識別情報によって特定されるデータの滞留時間として算出し、前記滞留時間を用いてボトルネックとなっているデータ処理を特定するボトルネック分析部を更に備える
   請求項７に記載の監視システム。
10. 前記監視実行部は、前記受信部がデータを受信したときに前記受信部からデータ受信報告情報を取得し、前記データ受信報告情報を取得する毎に前記第２のログ情報を生成し、
    前記データ受信報告情報は、前記受信されたデータの送信元を識別する情報と、前記受信されたデータを識別する情報とを含む
    請求項３または４に記載の監視システム。
11. 前記監視実行部は、前記変換部がデータを変換したときに前記変換部からデータ変換報告情報を取得し、前記データ変換報告情報を取得する毎に前記ログ情報を生成し、
    前記データ変換報告情報は、前記変換前のデータを識別する情報と、前記変換後のデータを識別する情報とを含む
    請求項１から９のいずれか一項に記載の監視システム。
12. 前記監視実行部は、前記送信部がデータを送信したときに前記送信部からデータ送信報告情報を取得し、前記データ送信報告情報を取得する毎に前記第３のログ情報を生成し、
    前記データ送信報告情報は、前記送信されたデータの送信先を識別する情報と、前記送信されたデータを識別する情報とを含む
    請求項５から７のいずれか一項に記載の監視システム。
13. 前記受信部に入力されるデータを捕捉する受信捕捉部を更に備え、
    前記監視実行部は、前記受信捕捉部が捕捉したデータを用いて、前記第２のログ情報を生成する
    請求項３または４に記載の監視システム。
14. 前記送信部から出力されるデータを捕捉する送信捕捉部を更に備え、
    前記監視実行部は、前記送信捕捉部が捕捉したデータを用いて、前記第３のログ情報を生成する
    請求項５から７のいずれか一項に記載の監視システム。
15. 前記監視実行部は、データを送信する第１の処理部と、前記データを受信する第２の処理部とを監視し、前記第１の処理部が前記第２の処理部へデータを送信する毎に第１の識別子と第２の識別子と前記送信した時刻とを含むログ情報を生成し、前記第２の処理部が前記第１の処理部からデータを受信する毎に第３の識別子と第４の識別子と前記受信した時刻とを含むログ情報を生成し、
    前記第１の識別子は、前記データを送信する主体を識別するデータ送信主体識別子と前記送信されたデータを識別するデータ識別子とを含み、
    前記第２の識別子は、前記データを送信する主体を識別するデータ送信主体識別子と、前記データを受信する主体を識別するデータ受信主体識別子と、前記送信されたデータを識別するデータ識別子とを含み、
    前記第３の識別子は、前記データを送信する主体を識別するデータ送信主体識別子と、前記データを受信する主体を識別するデータ受信主体識別子と、前記受信されたデータを識別するデータ識別子とを含み、
    前記第４の識別子は、前記データを受信する主体を識別するデータ受信主体識別子と、前記受信されたデータを識別するデータ識別子とを含む
    請求項１から１４のいずれか一項に記載の監視システム。
16. ログ情報を用いてデータ処理を監視する監視装置であって、
    データが変換部によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成する監視実行部を備える監視装置。
17. ログ情報を用いてデータ処理を監視する監視方法であって、
    監視実行部が、データが変換部によって変換されるときに、変換前のデータを識別する情報を含む始点ノード識別情報と、変換後のデータを識別する情報を含む終点ノード識別情報と、前記データを変換した時刻である処理実行時刻とを含むログ情報を生成するステップを有する監視方法。
18. ログ情報を用いてデータ処理を監視する監視システムであって、
    データを受信する受信部と、
    前記受信部によってデータが受信されるときに、前記受信されたデータの送信元を識別する情報を含む始点ノード識別情報と、前記データの受信を行う主体を識別する情報を含む終点ノード識別情報と、前記データを受信した時刻である処理実行時刻とを含むログ情報を生成する監視実行部と、
    を備える監視システム。

Images