JP2011227595A - 監視制御システム及び監視制御プログラム - Google Patents

Abstract

【課題】監視制御システムにおいて、新たな機能を容易に追加することが可能な技術を提供する。
【解決手段】監視制御システムは、複数のデータ処理部２と、データ振分部３とを備える。複数のデータ処理部２は、所定の複数の数値データをカテゴリ７にグループ化して複数のカテゴリデータを生成し、カテゴリ７とカテゴリデータを含むレスポンスと、カテゴリ７を含むリクエストとを生成する。データ振分部３は、リクエスト送信元のデータ処理部２からインタフェース４を介して受信したリクエストに含まれるカテゴリ７と、レスポンス送信元のデータ処理部２からインタフェース４を介して受信したレスポンスに含まれるカテゴリ７とに基づいて、当該レスポンスをリクエスト送信元のデータ処理部に送信する。
【選択図】図２

Description

本発明は、複数のデバイスを監視制御する監視制御システム及び監視制御プラグラムに関するものである。

近年、プラントの機器、河川の流量計、ビルの空調や照明等に関する複数のデバイスを監視制御する監視制御システムに関して様々な技術が提案さている。このような監視制御システムにおいては、様々な要求仕様に柔軟に対応すべく、汎用的な監視制御プログラムと、複数のデバイスの入出力点を特定する情報及び当該入出力点でのデータの加工、画面構成等の設計を行うためのツールとが整備されている。監視制御システムは、起動の際に、監視制御プログラムに基づいて、ツールにより設計された設計情報を読込むことにより所望の監視制御を行う。

このような監視制御システムに対する要求仕様は年々複雑化しており、過去の監視制御プログラムでは対応できない機能を追加（拡張）することが要求されている。特許文献１及び特許文献２に記載には、監視制御プログラムに新たな機能を追加する技術が記載されている。

特許文献１では、プログラムコードを入力、修正、または再コンパイルせずに、プログラムを組立てるコンピュータシステムに関する技術が記載されている。再利用プログラムにおいては、例えば、f(arg1,…,argN)のように、同一の配列要素（引数）を有する関数が用いられ、再利用プログラム同士間において、配列要素ごとにデータがやり取りされる。この配列要素は、再利用プログラムの開発の際に使用者により事前に取り決められ、定義ファイル等に記憶される。そして、コンパイルしなくても、再利用プログラムを管理する実装部が、新たに追加された再利用プログラムに関する定義ファイル等を読込むだけで、新たなシステムやプログラムを作成することが可能となっている。

特許文献２では、プラント監視制御処理向けのモジュールの構成や動作がプログラム上において変更される監視制御システムに関する技術が記載されている。この技術では、監視制御対象となるプラントに応じて、使用する複数の入力プログラム、演算プログラム、表示プログラム及び出力プログラム等の再利用部品が選択されることにより、モジュールが構成される。その際、各再利用部品のパラメータを変えることにより、モジュールの動作を変えることが可能となっている。例えば、要求仕様に基づいて上限下限超過を示すエラーを通知するモジュールにおいて、画面上に出力するのか、それともメール等によって通知するのかを、出力プログラムの定義ファイルを変更することにより切換えることが可能となっている。

特許第３５９２９４４号公報 特開２００７−２３３９５７号公報

さて、特許文献１の技術においては、再利用プログラム同士間において引数が予め定められなければならないことから、使用者は、新たな機能を追加する際に、新たな機能の引数が受け渡されるように対象の関数に引数を追加するプログラミング、及び、その変更を全再利用プログラムに対して反映させるプログラミングを行う必要がある。また、再利用プログラム同士間を結合する設計においては、使用者は、各引数においてはどのようなデータが受け渡されるのか、あるいは、再利用プログラムはどのような引数を取り扱っているのかを意識しなければならない。

また、特許文献２の技術において新たな機能を追加する場合には、使用者は、データを管理している再利用部品を検索し、当該再利用部品同士間で受け渡しするデータ形式等を理解した上で、新たな機能の追加に伴い新たに受け渡されるデータ形式を確認しなければならない。そして、データ形式が仕様を満たしている場合には、使用者は、呼び出し側の再利用部品の形式に従い新規にプログラムを追加するプログラミングを行う必要があり、仕様を満たしていない場合には、該当するデータを取得できるように再利用部品を拡張するプログラミングを行う必要がある。

以上のように、監視制御システムにおいて新たな監視制御機能を追加するためには、既存の監視制御プログラムを拡張または変更しているが、その作業は複雑で、かつ、時間がかかるものとなっており、結果的にコストがかかるものとなっている。

そこで、本発明は、上記のような問題点を鑑みてなされたものであり、監視制御システム及び監視制御プログラムにおいて、新たな機能を容易に追加することが可能な技術を提供することを目的とする。

本発明に係る監視制御システムは、複数のデバイスの入出力点から収集する複数の数値データ及び複数種類のイベントデータを監視制御する監視制御システムであって、所定の複数の数値データ及び前記複数種類のイベントデータを複数のカテゴリにグループ化して複数のカテゴリデータを生成し、前記カテゴリ及びそれに対応する前記カテゴリデータを含むレスポンスと、前記カテゴリを含むリクエストとを生成する複数のデータ処理部と、インタフェースを介して前記複数のデータ処理部との間で前記レスポンスを送受信し、かつ、前記インタフェースを介して前記複数のデータ処理部から前記リクエストを受信するデータ振分部とを備える。前記複数のデータ処理部のそれぞれは、前記データ振分部からの前記レスポンスを受信した場合に、当該レスポンスに含まれる前記カテゴリデータを用いて所定の処理を行う。前記データ振分部は、リクエスト送信元の前記データ処理部から受信した前記リクエストに含まれる前記カテゴリと、レスポンス送信元の前記データ処理部から受信した前記レスポンスに含まれる前記カテゴリとに基づいて、当該レスポンスを前記リクエスト送信元のデータ処理部に送信する。

また、本発明に係る監視制御プログラムは、複数のデバイスの入出力点から収集する複数の数値データ及び複数種類のイベントデータを監視制御する監視制御システムを構成するコンピュータに（ａ）複数のデータ処理部が、所定の複数の数値データ及び前記複数種類のイベントデータを複数のカテゴリにグループ化して複数のカテゴリデータを生成し、前記カテゴリ及びそれに対応する前記カテゴリデータを含むレスポンスと、前記カテゴリを含むリクエストとを生成する工程を実行させる。そして、当該コンピュータに、（ｂ）データ振分部が、リクエスト送信元の前記データ処理部からインタフェースを介して受信した前記リクエストに含まれる前記カテゴリと、レスポンス送信元の前記データ処理部から前記インタフェースを介して受信した前記レスポンスに含まれる前記カテゴリとに基づいて、当該レスポンスを前記インタフェースを介して前記リクエスト送信元のデータ処理部に送信する工程と、（ｃ）前記リクエスト送信元のデータ処理部が、前記レスポンスを受信した場合に、当該レスポンスに含まれる前記カテゴリデータを用いて所定の処理を行う工程とを実行させる。

本発明によれば、データ振分部が、リクエストに含まれるカテゴリと、レスポンスに含まれるカテゴリに基づいて、リクエストを送信したデータ処理部に適切なレスポンスを送信する。したがって、新たな機能を有するデータ処理部を追加する際には、リクエスト及びレスポンスの形式を変更する必要がなく、インタフェースを変更、拡張しなくて済むことから、新たな機能を容易に追加することができる。

実施の形態１に係る監視制御システムのハードウェア構成を示すブロック図である。 実施の形態１に係る監視制御システムの構成を示すブロック図である。 実施の形態１に係る監視制御システムの構成を示す図である。 実施の形態１に係る監視制御システムの構成を示す図である。 実施の形態１に係る監視制御システムの構成を示す図である。 実施の形態１に係る監視制御システムの構成を示す図である。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態１に係る監視制御システムの動作を示すフローチャートである。 実施の形態２に係る監視制御システムの動作を示すフローチャートである。 実施の形態２に係る監視制御システムの動作を示すフローチャートである。 実施の形態３に係る監視制御システムの動作を示すフローチャートである。 実施の形態３に係る監視制御システムの動作を示すフローチャートである。 実施の形態４に係る監視制御システムの動作を示すフローチャートである。 実施の形態４に係る監視制御システムの動作を示すフローチャートである。 実施の形態５に係る監視制御システムの構成を示すブロック図である。 実施の形態５に係る監視制御システムの動作を示すフローチャートである。 実施の形態５に係る監視制御システムの動作を示すフローチャートである。 実施の形態６に係る監視制御システムの動作を示す図である。 実施の形態７に係る監視制御システムの構成を示すブロック図である。 実施の形態７に係る監視制御システムの構成を示す図である。 実施の形態７に係る監視制御システムの動作を示すフローチャートである。 実施の形態７に係る監視制御システムの動作を示す図である。 実施の形態７に係る監視制御システムの動作を示す図である。 実施の形態７に係る監視制御システムの動作を示す図である。 実施の形態７に係る監視制御システムの動作を示す図である。 実施の形態７に係る監視制御システムの動作を示すフローチャートである。

＜実施の形態１＞
図１は、本発明の実施の形態１に係る監視制御システム１を構成するハードウェア構成を示す図である。監視制御システム１は、例えばコンピュータによって実現される。この監視制御システム１は、ＣＰＵ（Central Processing Unit）１０と、ＲＯＭ（Read Only Memory）１１と、ＲＡＭ（Random Access Memory）１２と、記憶装置１３と、入力インタフェース１４と、入力装置１５と、出力インタフェース１６と、出力装置１７と、ネットワーク接続インタフェース１８と、ネットワーク接続装置１９と、バス２０とを備える。データバスであるバス２０は、監視制御システム１を構成する複数のハードウェアを互いに電気的に接続する。したがって、ハードウェア同士間では、バス２０を介して情報の送受信が可能となっている。本実施の形態では、このバス２０を介して、ＣＰＵ１０、ＲＯＭ１１、ＲＡＭ１２、記憶装置１３、入力インタフェース１４、出力インタフェース１６及びネットワーク送受信インタフェース１８が複数のハードウェアとして互いに電気的に接続されている。

この監視制御システム１は、監視制御システム１の利用者、管理者または運用者から起動の際に行われる操作を受け付けると、監視制御システム１を起動するためのブートプログラム、ＯＳ（Operating System）を読出して実行する。以下、監視制御システム１の各構成について詳細に説明する。

ＲＯＭ１１には、ブートプログラム等の制御プログラムが記憶されている。ＲＡＭ１２は、ＣＰＵ１０が記憶装置１３から読み出したデータが一時的に記憶される。記憶装置１３は、例えば、ＨＤＤ（Hard Disk Drive）であり、記憶装置１３には、ＯＳ、監視制御プログラム及び各種データが記憶されている。

ＣＰＵ１０は、ＲＯＭ１１に記憶されている制御プログラムを読込んで実行することにより、ＲＯＭ１１、ＲＡＭ１２、記憶装置１３、入力インタフェース１４及び出力インタフェースを制御する。また、ＣＰＵ１０は、記憶装置１３に記憶されているＯＳ及び監視制御プログラムを読出して実行することによって、監視制御プログラムで規定されている演算及び動作を行う。ＣＰＵ１０は、演算結果を記憶装置１３に与え、記憶装置１３は、ＣＰＵ１０から演算結果が与えられると、当該演算結果を記憶する。

入力装置１５は、キーボード及びマウス等を備えており、利用者等からの操作を受け付けると、当該操作に対応する指令を入力インタフェース１４に与える。入力インタフェース１４は、入力装置１５と電気的に接続されており、入力装置１５をバス２０に接続する。これにより、入力装置１５からの指令が、バス２０及び入力インタフェース１４を介してＣＰＵ１０に入力される。

出力装置１７は、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶表示ディスプレイ等の、外部に情報を出力する装置であり、出力インタフェース１６からの情報を表示する。出力インタフェース１６は、出力装置１７と電気的に接続されており、出力装置１７をバス２０に接続する。これにより、ＣＰＵ１０からの情報が、バス２０及び入力インタフェース１４を介して出力装置１７に出力される。出力装置１７は、例えば、ＣＰＵ１０からの情報を受けるとその情報を表示する。

ネットワーク接続装置１９は、イーサネット（登録商標）カード、シリアルポート等の、外部コンピュータや外部デバイスと接続する接続装置であり、外部コンピュータ等と情報を送受信する。ネットワーク接続インタフェース１８は、ネットワーク接続装置１９と電気的に接続されており、ネットワーク接続装置１９をバス２０に接続する。これにより、ＣＰＵ１０からの情報及び指令が、バス２０及びネットワーク接続インタフェース１８を介してネットワーク接続装置１９に出力される。ネットワーク接続装置１９は、ＣＰＵ１０からの情報及び指令を受けると、その指令に基づいて、ＣＰＵ１０からの情報を外部コンピュータ等に送信する。一方、ネットワーク接続装置１９は、外部コンピュータ等からの情報を受信すると、当該情報をバス２０及びネットワーク接続インタフェース１８を介してＣＰＵ１０に入力する。

＜監視制御システムにおける機能ブロック＞
図２は、図１に示されるＣＰＵ１０が主に記憶装置１３に記憶されている監視制御プログラムを読込んで起動することにより、監視制御システム１に形成される機能ブロックを示す図である。図２に示すように、監視制御システム１は、複数のデータ処理部２と、データ振分部３と、インタフェース４と、データ振分定義記憶部５と、リクエスト記憶部６とを備える。

監視制御システム１は、監視対象である複数のデバイス９及び他の監視制御システム１と、ネットワークやシリアル等により互いに電気的に接続されている。本実施の形態では、これらはネットワーク８により互いに接続されているものとする。

監視制御システム１に接続されている複数のデバイス９は、複数の数値データ、及び、複数種類のイベントデータを検出する。複数の数値データは、例えば、河川の流量のデータ、及び、ビルの温度のデータである。複数種類のイベントデータは、例えば、コンピュータ異常、数値データの異常、及び、他のシステムからの事象における異常を示すデータである。複数のデバイス９は、検出した複数の数値データ及び複数種類のイベントデータを入出力点に出力する。なお、データ処理部２にて収集して数値データの異常（上限値、下限値など）を検出し、イベントデータとして他のデータ処理部２へ通知することもある。

複数のデータ処理部２のそれぞれは、例えば、プログラム上のコンポーネントに相当するものであり、データに対して、加工・変換・蓄積・表示・送受信（収集）・管理等の各種処理（各種機能）の少なくともいずれか一つを行う。データ処理部２におけるデータの蓄積方法としては、データベース（例えばＲＤＢＭＳやＸＭＬＤＢ）、ファイル形式で保存することが可能である。図２においては、複数のデータ処理部２の一例として、外部からのデータを収集するデータ処理部２ａと、データを表示するデータ処理部２ｂと、データを管理するデータ処理部２ｃ、２ｄとから構成されている。なお、本実施の形態では、データ処理部２ａは、他の監視制御システム１上で動作しているデータ処理部２との間でデータを送受信するネットワーク送受信機能も備えている。監視制御システム１は、複数のデータ処理部２のそれぞれが各種処理（各種機能）を行うことにより、多様な制御監視を実現することができる。本実施の形態に係る監視制御システム１では、新たな機能、つまり、新たなデータ処理部２の追加が容易となっている。

複数のデータ処理部２のうちデータ収集の機能を有するデータ処理部２ａは、複数のデバイス９の入出力点から複数の数値データを収集し、収集した複数の数値データを加工する。以下、収集した数値データ、及び、加工した数値データを、総称して「収集・加工数値データ」と呼ぶ。

複数のデータ処理部２においては、複数の収集・加工数値データが、複数種類の周期、例えば、１分、１時間及び１日の周期ごとに更新されていく。ここでいう更新は、過去の収集・加工数値データに収集・加工数値データが上書きされてもよく、あるいは、過去の収集・加工数値データを残しつつ直近の収集・加工数値データが記憶されてもよい。いずれの動作にするかは、各データ処理部２においてどのような処理が行われるかに委ねられる。

複数のデータ処理部２のデータ処理部２ａは、このように更新される複数の収集・加工数値データを、更新周期の種類ごとにグループ化する。この結果、グループ化されたデータが更新周期の種類の数だけ形成される。例えば、１分、１時間及び１日の三種類の更新周期が用意されている場合には、三つのグループ化されたデータが形成される。以下、グループの単位を示す識別子をカテゴリ７と呼び、周期に係るカテゴリ７を「周期カテゴリ７ｐ」と呼ぶこともある。

このことを、図３を用いて詳細に説明する。図３は、複数の収集・加工数値データを複数種類の周期カテゴリ７ｐにグループ化したときの一例を示す図である。入出力点識別番号５１は、「Ａ０００１」及び「Ａ０００２」等のように複数のデバイス９の入出力点を一意に識別するための番号である。図に示されるように、複数の収集・加工数値データは、入出力点識別番号５１ごとに取得されるものであり、「名前」、「データ型」及び「カレント値」などのような属性５２ごとのデータ（属性値５３）を含んでいる。

周期カテゴリ７ｐの一種である１分カレント値カテゴリ７ｐｍにおいては、複数の収集・加工数値データのうち１分周期で更新される収集・加工数値データ（属性値５３）がグループ化される。また、周期カテゴリ７ｐの一種である１時間カテゴリ７ｐｈにおいては、複数の収集・加工データのうち１時間周期で更新される収集・加工数値データ（属性値５３）がグループ化される。

以下、周期カテゴリ７ｐごとにグループ化された複数の収集・加工数値データ（属性値５３）をカテゴリデータ５４と呼ぶ。図３に示されるように、一つの周期カテゴリ７ｐには、一つのカテゴリデータ５４が形成される。このカテゴリデータ５４は、データ処理部２同士間で送受信され、各データ処理部２は、カテゴリデータ５４に対して加工・変換・蓄積・表示・送受信（収集）・管理のいずれかの処理を行う。

なお、図３に示されるように、複数の収集・加工数値データを複数の周期カテゴリ７ｐにグループ化した際には、定義カテゴリ７ｄが副次的に生成される。この定義カテゴリ７ｄにおいては、カテゴリデータ５４に関する、入出力点識別番号５１などの入出力点の情報、名前及びデータ型のデータ（属性値５３）がグループ化されている。この定義カテゴリ７ｄのデータは、周期カテゴリ７ｐのカテゴリデータ５４に適宜付加される。

複数データ処理部２のデータ処理部２ａは、以上で説明した複数の収集・加工数値データと同様に、複数のデバイス９の入出力点から複数種類のイベントデータを収集する。データ処理部２ａは、複数種類のイベントデータをイベントの種類ごとにグループ化する。この結果、グループ化されたデータがイベントの種類の数だけ形成される。以下、イベントに係るカテゴリ７を「イベントカテゴリ７ｅ」と呼ぶ。

このことを、図４を用いて詳細に説明する。図４は、複数種類のイベントデータを複数種類のイベントにグループ７ｅにグループ化したときの一例を示す図である。図に示されるように、複数種類のイベントデータは、イベントデータごとに付与される「イベントＩＤ」、イベントが発生した時間を示す「タイムスタンプ」、イベントの現在の状態を示す「イベント状態」などのような属性５２ごとのデータ（属性値５３）から構成されている。

イベントカテゴリ７ｅの一種である気象イベントカテゴリ７ｅｗにおいては、複数種類のイベントデータのうち気象に関するイベントデータ（属性値５３）がグループ化される。また、イベントカテゴリ７ｅの一種であるシステムイベントカテゴリ７ｅｓにおいては、複数種類のイベントデータのうちシステムの故障に関するイベントデータ（属性値５３）がグループ化される。

以下、上述と同様に、イベントカテゴリ７ｅごとにグループ化された複数種類のイベントデータ（属性値５３）をカテゴリデータ５４と呼ぶ。図４に示されるように、一つのイベントカテゴリ７ｅには、一つのカテゴリデータ５４が形成される。イベントカテゴリ７ｅに係るカテゴリデータ５４は、周期カテゴリ７ｐに係るカテゴリデータ５４と同様にデータ処理部２同士間で送受信され、各データ処理部２は、カテゴリデータ５４に対して加工・変換・蓄積・表示・送受信（収集）・管理のいずれかの処理を行う。

以下の説明においては、周期カテゴリ７ｐ及びイベントカテゴリ７ｅのそれぞれを、総称して「カテゴリ７」と呼ぶこともある。上述の複数のデータ処理部２の動作を換言すれば、本実施の形態に係る複数のデータ処理部２は、データ処理部２ａにおいて、複数の収集・加工数値データ及び複数種類のイベントデータを複数のカテゴリ７にグループ化して、複数のカテゴリデータ５４を生成する。

データ処理部２は、他のデータ処理部２からカテゴリデータ５４を必要とする際には、カテゴリ７と後述の応答回数とを含む「リクエスト」を生成し、当該リクエストをインタフェース４を介してデータ振分部３に送信する。以下、リクエストをデータ振分部３に送信するデータ振分部２を「リクエスト送信元のデータ処理部２」と、リクエストに含められるカテゴリ７を「リクエスト対象カテゴリ」と呼ぶこともある。

一方、データ処理部２は、カテゴリ７に対応するカテゴリデータ５４を他のデータ処理部２に送信しようとする際には、当該カテゴリ７と、当該カテゴリデータ５４とを含む「レスポンス」を生成し、当該レスポンスをインタフェース４を介してデータ振分部３に送信する。以下、レスポンスをデータ振分部３に送信するデータ処理部２を「レスポンス送信元のデータ処理部２」、レスポンスに含められるカテゴリ７を「レスポンス対象カテゴリ」とそれぞれ呼ぶこともある。

データ振分部３は、リクエストを受信してから、当該リクエストと同一のカテゴリ７を含むレスポンスを受信した場合には、当該レスポンスを、当該リクエストを送信したリクエスト送信元のデータ処理部２に送信する。このようなデータ振分部３については後述する。

インタフェース４は、複数のデータ処理部２とデータ振分部３との間におけるレスポンスの送受信等を支援するものであり、全データ処理部２に実装されている。インタフェース４には、「初期化メソッド」、「終了メソッド」、「レスポンス受信メソッド」、「リクエスト送信メソッド」、及び、「レスポンス送信メソッド」という五つのメソッドが定義されている。

初期化メソッドは、全データ処理部２が実装するものであり、データ振分部３により実行される。一つのデータ処理部２の初期化メソッドがデータ振分部３によって実行されると、当該一つのデータ処理部２が初期化される。

終了メソッドは、全データ処理部２が実装するものであり、データ振分部３により実行される。一つのデータ処理部２の終了メソッドがデータ振分部３によって実行されると、当該一つのデータ処理部２が停止する。

レスポンス受信メソッドは、全データ処理部２が実装するものであり、データ振分部３により実行される。一つのデータ処理部２のレスポンス受信メソッドがデータ振分部３によって実行されると、当該一つのデータ処理部２は、データ振分部３から送信されるレスポンスを受信する。

リクエスト送信メソッドは、複数のデータ処理部２のうち少なくとも一つのデータ処理部２に利用される。当該少なくとも一つのデータ処理部２は、インタフェース４が提供するリクエスト送信メソッドを利用して、リクエストをデータ振分部３に送信する。

レスポンス送信メソッドは、複数のデータ処理部２のうち少なくとも一つのデータ処理部２により利用される。当該少なくとも一つのデータ処理部２は、インタフェース４が提供するレスポンス送信メソッドを利用して、レスポンスをデータ振分部３に送信する。

データ振分部３は、例えば、プログラム上のコンポーネントに相当するものであり、複数のデータ処理部２及びインタフェース４を介してレスポンスを送受信し、かつ、複数のデータ処理部２からインタフェース４を介してリクエストを受信する。データ振分部３は、リクエストを送信したリクエスト送信元のデータ処理部２に、当該リクエストと同じカテゴリ７を含むレスポンスを振り分ける。この際に、データ振分部３は、後述するデータ振分定義記憶部５に記憶されているデータ振分定義情報３０を参照したり、受信したリクエストをリクエスト記憶部６に一時的にキャッシュ（記憶）させたりする。この動作の詳細な説明は後述する。

データ振分部３は、レスポンス及びリクエストの送受信を行うだけでなく、インタフェース４を介して、複数のデータ処理部２の起動及び停止も行う。本実施の形態では、データ振分部３が起動及び停止すべき複数のデータ処理部２は、データ振分定義記憶部５に記憶されている。つまり、データ振分部３は、データ振分定義記憶部５に記憶されている複数のデータ処理部２を起動するとともに、これらをインタフェース４を介して初期化する。また、データ振分部３は、データ振分定義記憶部５において記憶されている複数のデータ処理部２をインタフェース４を介して停止する。なお、データ処理部２を起動させる方法としては、例えば、Ｃ＋＋のＤＬＬ読込み技術やＪａｖａ（登録商標）のｊａｒファイルをクラスローディングする技術等を活用する。

図２に示されるデータ振分定義記憶部５は、図１に示される記憶装置１３の機能ブロックであり、データ処理部２とカテゴリ７とを関連付けるデータ振分定義情報３０を記憶している。

図５は、データ振分定義情報３０の一例を示す図である。図に示されるように、データ振分定義情報３０は、ＩＤ３１、プログラムファイル３２、プログラムアドレス３３、レスポンス対象カテゴリ３４、リクエスト対象カテゴリ３５及び仮想プログラム３６という、六つの項目に関する情報から構成されている。

ＩＤ３１は、複数のデータ処理部２のそれぞれに付与される、データ処理部２を一意に識別するための番号を示す。プログラムファイル３２は、対応するデータ処理部２において実行されるプログラムファイルの名前を示す。プログラムアドレス３３は、監視制御システム１が起動する際に、データ処理部２に割り当てられる、自コンピュータ上での参照先のアドレスを示す。図５においては、Ｃプログラムによるアドレスを表記しているが、Ｃ＋＋プログラムやＪａｖａ（登録商標）プログラム等の言語によるアドレスで表記されていてもよい。

レスポンス対象カテゴリ３４は、ＩＤ３１により識別されるデータ処理部２が、データ振分部３に送信するレスポンスに含めることが可能なカテゴリ７を示す。つまり、ＩＤ３１により識別されるデータ処理部２は、レスポンス対象カテゴリ３４のカテゴリ７に属するカテゴリデータ５４を管理しており、当該カテゴリ７及び当該カテゴリデータ５４を含むレスポンスをデータ振分部３に送信することが可能である。例えば、図５においてＩＤ３１として「１」が付与されているデータ処理部２は、１分カレント値カテゴリを含むレスポンスをデータ振分部３に送信することが可能である。なお、このレスポンス対象カテゴリ３４は、本実施の形態では用いられず、後述の実施の形態において用いられる。したがって、本実施の形態においてレスポンス対象カテゴリ３４は必須ではない。

リクエスト対象カテゴリ３５は、ＩＤ３１により識別されるデータ処理部２が、データ振分部３に送信するリクエストに含めることが可能なカテゴリ７を示す。つまり、ＩＤ３１により識別されるデータ処理部２は、リクエスト対象カテゴリ３５に示されるカテゴリ７のカテゴリデータ５４が必要な場合には、当該カテゴリ７を含むリクエストをデータ振分部３に送信することが可能である。例えば、図５においてＩＤ３１として「２」が付与されているデータ処理部２は、１分カレント値カテゴリのカテゴリデータ５４を必要とするデータ処理部２であり、当該カテゴリデータ５４を必要とする場合に、１分カレント値カテゴリを含むリクエストをデータ振分部３に送信することが可能である。

図５に示されるように、本実施の形態に係るリクエスト対象カテゴリ３５においては、複数のカテゴリ７は互いに異なり、当該複数のカテゴリ７のそれぞれは、複数のデータ処理部２のいずれか一つに関連付けられている。つまり、一つのカテゴリ７が重複することなく、複数のカテゴリ７が複数のデータ処理部２に関連付けられている。

なお、図５に示される１分カレント値カテゴリは、図３に示される１分カレント値カテゴリ７ｐｍを示す。また、図５に示される１日カテゴリ、１月カテゴリ及び１年カテゴリのそれぞれは、周期カテゴリ７ｐの一種である。カレント値カテゴリは、複数の周期カテゴリ７ｐをまとめたものである。カレント値異常イベントカテゴリは、イベントカテゴリ７ｅの一種である。

仮想プログラム３６は、他の監視制御システム１に対してリクエストやレスポンスを送信する際に、経由すべきデータ処理部２のＩＤ３１を示す。本実施の形態では、仮想プログラム３６には、他の監視制御システム１とデータを送受信したりするデータ送受信（収集）のデータ処理部２ａのＩＤ３１が示されることになる。

図２に示されるリクエスト記憶部６は、図１に示される記憶装置１３の機能ブロックであり、データ振分部３が受信したリクエストの状況を示すリクエストキャッシュ情報を記憶している。

図６は、リクエストキャッシュ情報の一例を示す図である。図に示されるように、リクエストキャッシュ情報４０は、リクエスト対象カテゴリ４１、ＩＤ４２及び応答回数４３という、三つの項目に関する情報から構成されている。

リクエスト対象カテゴリ４１は、現在リクエスト中のカテゴリ７を示す。つまり、データ振分部３が、データ処理部２からリクエストを受信したが、それに対応するレスポンスを当該データ処理部２に送信することが完了していない場合に、当該リクエストに含まれるカテゴリ７が示されている。ＩＤ４２は、リクエスト対象カテゴリ４１のカテゴリ７を含むリクエストをデータ振分部３に送信したリクエスト送信元のデータ処理部２を一意に識別するための番号を示す。このＩＤ４２の番号は、図５に示されるデータ振分定義情報３０のＩＤ３１の番号と同じである。応答回数４３は、一回のリクエストに対してデータ振分部３からデータ処理部２に送信されるべきレスポンスの回数を示すものである。例えば、応答回数４３が「１」を示している場合にはレスポンスが１回のみ送信されるべきであることを示し、「２」を示している場合にはレスポンスが２回送信されるべきであることを示す。応答回数４３が「＊」を示している場合にはリクエストの停止が呼ばれるまでレスポンスが継続して送信されるべきであることを示す。

次に、ＣＰＵ１０が記憶装置１３に記憶されている監視制御プログラムを実行することにより行われる、本実施の形態に係る監視制御システム１の動作を図７〜１２を用いて説明する。

図７は、監視制御システム１の起動の際に行われる動作を示すフローチャートである。この動作では主に、データ振分部３が、起動後にデータ振分定義情報３０を読み込み、データ振分定義情報３０において特定されている複数のデータ処理部２を一つずつ順次に起動し初期化する。この動作の前には、データ振分部プログラムがＣＰＵ１０に読み出されることにより、データ振分部３が実行されているものとする。以下、この動作について、図７を用いて詳細に説明する。

まず、ステップｓ１にて、起動されたデータ振分部３は、データ振分定義記憶部５から、データ振分定義情報３０を構成している全データを読み込む。ステップｓ２にて、データ振分部３は、図５に示される全データを表の一行単位のデータ（行単位データ）のうち、一番上の行単位データを抜き出す。それから、ステップｓ３にて、データ振分部３は、抜き出した行単位データにおいて、仮想プログラム３６が無設定であるか否かを判定する。ステップｓ３において無設定であると判定された場合にはステップｓ４に進む。無設定でない、つまり設定済みであると判定された場合にはステップｓ６に進む。

ステップｓ４にて、データ振分部３は、行単位データから一つのデータ処理部２のプログラムファイル３２を取得し、当該一つのデータ処理部２を起動し、起動されたデータ処理部２のアドレスをプログラムファイル３３に格納する。プログラムアドレス３３を取得し、当該一つのデータ処理部２を起動する。そして、ステップｓ５にて、データ振分部３は、起動した一つのデータ処理部２に対し、インタフェース４にて定義されている初期化メソッドを実行する。これにより、起動した一つのデータ処理部２が初期化される。

ステップｓ６にて、データ振分部３は、データ振分定義情報３０において特定されている全データ処理部２に対して以上の動作が行われたかを判定する。ステップｓ６において当該全データ処理部２に対して動作が行われたと判定した場合には図７に示される工程が終了し、そうでない場合にはステップｓ２に進む。再度のステップｓ２においては、データ振分部３は、先に抜き出した行単位データから一つ下に位置する行単位データを抜き出す。

こうして、データ振分部３は、ステップｓ１で読み込んだデータ振分定義情報３０において特定されている全データ処理部２に対し、ステップｓ３〜ｓ５の動作を繰り返すループ動作を行うことにより、当該全データ処理部２を起動し初期化する。

図８は、一つのデータ処理部２がカテゴリデータ５４を必要とする際に行われる動作を示すフローチャートである。この動作では主に、当該一つのデータ振分部２が、データ振分部３にリクエストを送信する。なお、必要であれば、図８に示される工程は、上述の初期化（ステップｓ５）直後に行われてもよい。以下、この動作について、図８を用いて詳細に説明する。

まず、ステップｓ１０にて、データ処理部２は、自身が必要とするカテゴリデータ５４のカテゴリ７を特定し、当該カテゴリ７を含むリクエストを生成する。この際、データ処理部２は、１回のリクエストで何回のカテゴリデータ５４が送信されるべきかを示す応答回数もリクエストに含める。ステップｓ１１にて、当該データ処理部２は、インタフェース４にて定義されているリクエスト送信メソッドを利用して、生成したリクエストをデータ振分部３に送信する。ステップｓ１２にて、データ振分部３は、当該データ処理部２、つまり、リクエスト送信元のデータ処理部２から送信されたリクエストを受信する。

この時点では、データ振分部３は、自身が受信したリクエストがどのデータ処理部２から送信されたか、つまり、リクエスト送信元のデータ処理部２がどれかを特定できていない。

そこで、ステップｓ１３にて、データ振分部３は、受信したリクエストに含まれるカテゴリ７に基づいて、図５に示されるデータ振分定義情報３０から、リクエスト送信元のデータ処理部２のＩＤ３１を特定する。具体的には、データ振分部３は、データ振分定義情報３０のリクエスト対象カテゴリ３５のカテゴリ７のうち、受信したリクエストと同じカテゴリ７を特定し、当該カテゴリ７に関連付けられたデータ処理部２のＩＤ３１を取得する。

ここで、リクエスト対象カテゴリ３５は、データ処理部２がデータ振分部３に送信するリクエストに含めることが可能なカテゴリ７であることから、データ振分部３は、上述の動作を行うことにより、リクエスト送信元のデータ処理部２のＩＤ３１（以下、「リクエスト送信元のＩＤ３１」と略することもある）を取得することになる。そして、本実施の形態では、データ振分定義情報３０においては、同一のカテゴリ７が重複することなく、複数のカテゴリ７が複数のデータ処理部２に関連付けられていることから、リクエスト送信元のＩＤ３１が一意に取得される。以上により、データ振分部３は、カテゴリ７に基づいて、リクエストがどのデータ処理部２から送信されたのかを一意に特定することができる。

ステップｓ１３の後、ステップｓ１４にて、データ振分部３は、リクエスト送信元のＩＤ３１、ステップｓ１２にて受信したリクエストに含まれるカテゴリ７、及び、応答回数を、リクエストキャッシュ情報４０のＩＤ４２、リクエスト対象カテゴリ４１、及び、応答回数４３としてそれぞれ登録し、図８に示される工程が終了する。

図９は、一つのデータ処理部２がカテゴリデータ５４を送信する際に行われる動作を示すフローチャートである。この動作では主に、カテゴリデータ５４を送信しようとする一つのデータ処理部２が、当該カテゴリデータ５４を含むレスポンスをデータ振分部３に送信する。以下、この動作について、図９を用いて詳細に説明する。なお、ここでは、カテゴリデータ５４が生成される工程についても最初に説明する。

ステップｓ２０にて、データ処理部２ａは、ネットワーク８を介して複数のデバイス９からの複数の数値データ及び複数種類のイベントデータを受信する。ステップｓ２１にて、データ処理部２ａは、受信したこれらデータを必要に応じて加工・変換する。ステップｓ２２にて、データ処理部２ａは、複数の収集・加工数値データ及び複数種類のイベントデータを複数のデバイス９の入出力点ごとに蓄積する。そして、ステップｓ２３にて、データ処理部２ａは、複数の収集・加工数値データ及び複数種類のイベントデータを複数のカテゴリ７にグループ化して、複数のカテゴリデータ５４を生成する。

以上のステップｓ２０〜ｓ２３における複数のカテゴリデータ５４の生成は、データを送受信（収集）する機能を有するデータ処理部２ａにおいて少なくとも行われる。その一方で、以下に説明するステップｓ２４以降におけるレスポンスの送信は、データ処理部２ａに限ったものではなく、複数のデータ処理部２において適宜行われる。

ステップｓ２４にて、カテゴリデータ５４を送信しようとするデータ処理部２は、当該カテゴリデータ５４及びそのカテゴリ７を含むレスポンスを生成する。ステップｓ２５にて、当該データ処理部２は、インタフェース４に定義されているレスポンス送信メソッドを利用して、生成したレスポンスをデータ振分部３に送信する。ステップｓ２６にて、データ振分部３は、当該データ処理部２、つまり、レスポン送信元のデータ処理部２から送信されたレスポンスを受信する。

次に、ステップｓ２７にて、データ振分部３は、受信したレスポンスに含まれるカテゴリ７と一致するカテゴリ７が、リクエストキャッシュ情報４０のリクエスト対象カテゴリ４１におけるカテゴリ７と一致するかを判定する。換言すれば、データ振分部３は、リクエスト送信元のデータ処理部２から受信したリクエストに含まれるリクエスト対象カテゴリと、レスポンス送信元のデータ処理部２から受信したレスポンスに含まれるレスポンス対象カテゴリとが互いに一致するかを判定する。ステップｓ２７において、カテゴリ７が一致すると判定された場合には、ステップｓ２８に進み、そうでない場合には図９に示される工程が終了する。

ステップｓ２８にて、データ振分部３は、リクエストキャッシュ情報４０の応答回数４３を更新する。具体的には、応答回数４３が自然数を示している場合には、データ振分部３は、当該自然数から１を引き、応答回数４３が「０」となった段階でリクエストキャッシュ情報４０からそのリクエスト対象カテゴリ４１等のデータを削除する。応答回数４３が「＊」を示している場合には何もしない。

ステップｓ２９にて、データ振分部３は、リクエストキャッシュ情報４０からリクエスト送信元のＩＤ４２を取得する。そして、データ振分部３は、データ振分定義情報３０において、取得したＩＤ４２と同じ番号を示すＩＤ３１を特定し、当該ＩＤ３１に対応するプログラムアドレス３３を取得する。そして、ステップｓ３０にて、データ振分部３は、当該ＩＤ３１により識別されるリクエスト送信元のデータ処理部２に対し、インタフェース４に定義されているレスポンス受信メソッドを実行し、リクエスト送信元のデータ処理部２にレスポンスを送信する。こうして、リクエスト送信元のデータ処理部２は、所望のカテゴリデータ５４を含むレスポンスをデータ振分部３から受信することにより、当該所望のカテゴリデータ５４を取得することができる。その後、リクエスト送信元のデータ処理部２は、当該カテゴリデータ５４に対して、自身に割り当てられている加工等の処理を行う。そして、図９に示される工程が終了する。

以上においては、監視制御システム１内においてリクエスト及びレスポンスを送受信する際の動作について説明したが、以下においては、監視制御システム１が他の監視制御システムとリクエスト及びレスポンスを送受信する際の動作について説明する。

図１０は、監視制御システム１のデータ処理部２が他の監視制御システム１からリクエストを受信する際に行われる動作を示すフローチャートであり、図１１は、監視制御システム１のデータ処理部２ａが他の監視制御システム１にレスポンスを送信する際に行われる動作を示すフローチャートである。以下、この動作について、図１０，１１を用いて説明する。

図１０に示されるステップｓ４０にて、他の監視制御システム１とデータを送受信する機能を有するデータ処理部２ａは、他の監視制御システム１のデータ処理部２から上述と同じリクエストと、当該監視制御システム１を一意に識別するＩＰアドレスとを受信する。ステップｓ４１にて、データ処理部２ａは、受信したリクエストに含まれるカテゴリ７などの情報と、リクエスト送信元の監視制御システム１のＩＰアドレスとを互いに関連付けて一時的にキャッシュする。ステップｓ４２にて、データ処理部２ａは、インタフェース４に定義されているリクエスト送信メソッドを利用して、ステップｓ４１にて受信したリクエストをデータ振分部３に送信する。それ以降は、ステップｓ１３〜ｓ１４、及び、ステップｓ２０〜ｓ２９と同様の工程が行われる。

そして、図１１に示されるステップｓ４３にて、ステップｓ３０と同様に、データ振分部３は、リクエスト送信元のデータ処理部２ａがレスポンスを受信するように、当該データ処理部２ａに対してレスポンス受信メソッドを実行し、リクエスト送信元のデータ処理部２ａにレスポンスを送信する。これにより、データ処理部２ａは、データ振分部３に送信したリクエストと同じカテゴリ７を含むレスポンスをデータ振分部３から受信する。

ステップｓ４４にて、データ処理部２ａは、ステップｓ４３にて受信したレスポンスに含まれるカテゴリ７に基づいて、ステップｓ４１においてキャッシュしている情報から、リクエスト送信元の監視制御システム１のＩＰアドレスを取得する。この際、複数のＩＰアドレスを取得してもよい。それから、ステップｓ４５にて、データ処理部２ａは、取得したＩＰアドレスで識別される、他の監視制御システム１にレスポンスを送信する。

以上により、監視制御システム１は、他の監視制御システム１からリクエストを受信した場合に、当該リクエストと同一のカテゴリを含むレスポンスを他の監視制御システム１に送信することができる。

次に、監視制御システム１のデータ処理部２ａが他の監視制御システム１にリクエストを送信する際に行う動作を簡単に説明し、その後、監視制御システム１のデータ処理部２ａが他の監視制御システム１からレスポンスを受信した際に行う動作を簡単に説明する。

まず、監視制御システム１のデータ処理部２ａが他の監視制御システム１にリクエストを送信する際に行う動作について説明する。データ処理部２ａは、必要とするカテゴリデータ５４のカテゴリ７を特定し、当該カテゴリ７を含むリクエストを生成する。この際、データ処理部２ａは、１回のリクエストで何回のカテゴリデータ５４が送信されるべきかを示す応答回数もリクエストに含める。そして、データ処理部２ａは、生成したリクエストを他の監視制御システム１に送信する。

次に、監視制御システム１のデータ処理部２ａが他の監視制御システム１からレスポンスを受信した際に行う動作について説明する。データ処理部２ａは、他の監視制御システム１からレスポンスを受信した場合には、ステップｓ２５〜ステップｓ３０の動作を行う。これにより、リクエスト送信元のデータ処理部２は、他の監視制御システム１から、所望のカテゴリデータ５４を含むレスポンスを受信することができる。

図１２は、監視制御システム１の停止の際に行われる動作を示すフローチャートである。この動作では主に、データ振分部３が、データ振分定義情報３０を読み込み、データ振分定義情報３０において特定されている複数のデータ処理部２を一つずつ順次に停止する。以下、この動作について、図１２を用いて詳細に説明する。

まず、ステップｓ５０にて、データ振分部３は、データ振分定義記憶部５から、データ振分定義情報３０を構成している全データを読み込む。ステップｓ５１にて、データ振分部３は、図５に示される全データを表の一行単位のデータ（行単位データ）のうち、一番上の行単位データを抜き出す。それから、ステップｓ５２にて、データ振分部３は、抜き出した行単位データにおいて、仮想プログラム３６が無設定であるか否かを判定する。ステップｓ５２において無設定であると判定された場合にはステップｓ５３に進む。無設定でない、つまり設定済みであると判定された場合にはステップｓ５５に進む。

ステップｓ５３にて、データ振分部３は、行単位データから一つのデータ処理部２を取得する。そして、ステップｓ５４にて、データ振分部３は、当該一つのデータ処理部２に対し、インタフェース４にて定義されている終了メソッドを実行する。これにより、当該一つのデータ処理部２が停止する。

ステップｓ５５にて、データ振分部３は、データ振分定義情報３０において特定されている全データ処理部２に対して以上の動作が行われたかを判定する。ステップｓ５５において当該全データ処理部２に対して動作が行われたと判定した場合には図１２に示される工程が終了し、そうでない場合にはステップｓ５１に進む。再度のステップｓ５１においては、データ振分部３は、先に抜き出した行単位データから一つ下に位置する行単位データを抜き出す。

こうして、データ振分部３は、ステップｓ５０で読み込んだデータ振分定義情報３０において特定されている全データ処理部２に対し、ステップｓ５２〜ｓ５４の動作を繰り返すループ動作を行うことにより、当該全データ処理部２を停止する。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、データ振分部３が、リクエストに含まれるカテゴリ７と、レスポンスに含まれるカテゴリ７とに基づいて、リクエストを送信したデータ処理部２に適切なレスポンスを送信する。したがって、新たな機能を有するデータ処理部２を追加する際には、カテゴリ７及びカテゴリデータ５４の種類が増減することになるが、リクエスト及びレスポンスの形式を変更する必要がないことから、インタフェース４を変更、拡張しなくて済む。よって、新たな機能を容易に追加することができる。

また、データ振分部３は、追加した新しいデータ処理部２をデータ振分定義記憶部５に記憶すれば、既存のデータ処理部２と同様に、起動及び停止することができることから、新たな機能を容易に追加することができる。

また、本実施の形態では、データ振分定義記憶部５において、複数のデータ処理部２に関連付けられる複数のカテゴリ７は互いに異なっていることから、データ振分部３は、レスポンスに含まれるカテゴリ７と、リクエストに含まれるカテゴリ７に基づいて、レスポンス（カテゴリデータ５４）を必要とするリクエスト送信元のデータ処理部２を一意に特定することができる。したがって、データ処理部２を追加する際に、そのデータ処理部２のレスポンスを、複数のデータ処理部２のうちどのデータ処理部２に対して送信すべきかについて意識しなくても、当該レスポンスを適切に送信することができる。よって、新たな機能を容易に追加することができる。

なお、本実施の形態では、互いに異なる複数のカテゴリ７のそれぞれが、複数のデータ処理部２のいずれか一つに関連付けられたものとした。しかし、これに限ったものではなく、同一のカテゴリ７が複数のデータ処理部２に重複するように、複数のカテゴリ７と複数のデータ処理部２とを関連付けるものであってもよい。ただし、この場合には、レスポンスを必要とする一つのデータ処理部２、つまり、リクエスト送信元のデータ処理部２が一意に特定されない。そこで、この場合には次の二つの方法のいずれかを行うことにより、データ振分部３がリクエスト送信元のデータ処理部２を一意に特定することが可能となる。

一つ目の方法として、データ振分部３は、データ処理部２に対し、そのデータ処理部２のＩＤ３１を予め与えておく。そして、リクエスト送信元のデータ処理部２は、データが必要となった場合に、自身のＩＤ３１をリクエストに付与してデータ振分部３に送信する。データ振分部３は、このＩＤ３１をリクエストキャッシュ情報４０に登録する。これにより、データ振分部３はリクエスト送信元のデータ処理部２を一意に特定することができる。

二つ目の方法として、データ振分部３は、データ処理部２に対し、そのデータ処理部２のプログラムアドレス３２を予め与えておく。そして、リクエスト送信元のデータ処理部２は、データが必要となった場合に、自身のプログラムアドレス３２をリクエストに付与してデータ振分部３に送信する。データ振分部３は、このプログラムアドレス３２をリクエストキャッシュ情報４０に登録する。これにより、データ振分部３はリクエスト送信元のデータ処理部２を一意に特定することができる。

また、上述したレスポンス送信方法以外の送信方法として、データ振分部３は、受信したレスポンスに含まれるカテゴリ７に関連するすべてのＩＤ３１をリクエストキャッシュ情報４０から収集することにより、当該カテゴリ７に該当するすべてのデータ処理部２にレスポンスを送信するようにしてもよい。

＜実施の形態２＞
本実施の形態に係る監視制御システム１のハードウェア構成及び機能ブロック構成は、実施の形態１に係る監視制御システム１のハードウェア構成及び機能ブロック構成とそれぞれ同じである。以下、本実施の形態に係る監視制御システム１のハードウェア構成、及び、機能ブロック構成において、実施の形態１と同一の部分には同一符号を付与し、以下においては実施の形態１と異なる部分を中心に説明する。

本実施の形態に係る監視制御システム１及び監視制御プログラムにおいては、データ振分部３は、受信したリクエストと同じカテゴリ７を含むレスポンスのみを複数のデータ処理部２から受信するようになっている。以下、このような本実施の形態に係る監視制御システム１及び監視制御プログラムについて説明する。

本実施の形態に係るインタフェース４には、上述のメソッドに加えて、「リクエスト受信メソッド」が定義されている。このリクエスト受信メソッドは、全データ処理部２が実装するものであり、データ振分部３により実行される。一つのデータ処理部２のリクエスト受信メソッドがデータ振分部３によって実行されると、当該一つのデータ処理部２は、データ振分部３からリクエストを受信する。したがって、本実施の形態に係るデータ振分部３は、インタフェース４を介して、複数のデータ処理部２との間でレスポンスだけでなく、リクエストも送受信するようになっている。

本実施の形態に係るデータ振分部３は、一つのデータ処理部２からリクエストを受信した場合に、データ処理部２に対して当該リクエストを送信する。そして、複数のデータ処理部２のそれぞれは、データ振分部３からリクエストを受信した場合に、当該リクエストと同じカテゴリ７を含むレスポンスのみをデータ振分部３に送信する。これにより、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信することができるようになっている。

次に、本実施の形態に係る監視制御システム１の動作について図１３，１４を用いて説明する。

図１３は、一つのデータ処理部２がカテゴリデータ５４を必要とする際に行われる動作を示すフローチャートである。まず、実施の形態１で説明したステップｓ１０〜ｓ１４（図８）が行われる。そして、ステップｓ１５Ａにて、データ振分部３は、全データ処理部２に対し、インタフェース４に定義されているリクエスト受信メソッドを実行し、ステップｓ１２において受信したリクエストを全データ処理部２に対して送信する。これにより、全データ処理部２は、リクエストをデータ振分部３から受信する。なお、ここでは、データ振分部３が全データ処理部２にリクエストを送信するものとしたが、データ振分部３は、レスポンス対象カテゴリ３４を参照して、リクエストと同じカテゴリ７を含むレスポンスを送信可能なデータ処理部２を特定し、特定した当該データ処理部２にのみリクエストを送信するものであってもよい。それから、ステップｓ１６Ａにて、各データ処理部２は、受信したリクエストに含まれるカテゴリ７を一時的にキャッシュする。そして、図１３に示される工程が終了する。

図１４は、一つのデータ処理部２がカテゴリデータ５４を送信する際に行われる動作を示すフローチャートである。まず、実施の形態１で説明したステップｓ２０〜ｓ２３（図９）が行われる。そして、ステップｓ２４Ａにて、カテゴリデータ５４を送信しようとするデータ処理部２は、レスポンスに含めようとするカテゴリ７と、ステップｓ１６Ａでキャッシュされたカテゴリ７とが互いに合致するかを判定する。ステップｓ２４Ａにおいて合致すると判定された場合にはステップｓ２４に進み、それ以降、実施の形態１で説明した工程と同じ工程が行われる。ステップｓ２４Ａにおいて合致しないと判定された場合には、各データ処理部２がレスポンスの生成及び送信を行わずに、図１４に示される工程が終了する。この動作により、全データ処理部２は、データ振分部３から受信したリクエストと同じカテゴリ７を含むレスポンスのみを、データ振分部３に送信することになる。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、実施の形態１と同様の効果を得ることができるとともに、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信することができる。したがって、データ振分部３において不要な処理を削減することができるため、データ振分部３の負荷軽減及び高速処理化を実現することができる。

＜実施の形態３＞
本実施の形態に係る監視制御システム１のハードウェア構成及び機能ブロック構成は、実施の形態２に係る監視制御システム１のハードウェア構成及び機能ブロック構成とそれぞれ同じである。以下、本実施の形態に係る監視制御システム１のハードウェア構成、及び、機能ブロック構成において、実施の形態２と同一の部分には同一符号を付与し、以下においては実施の形態２と異なる部分を中心に説明する。

本実施の形態に係る監視制御システム１及び監視制御プログラムにおいても、実施の形態２と同様、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信するようになっている。以下、このような本実施の形態に係る監視制御システム１及び監視制御プログラムについて説明する。

本実施の形態に係る複数のデータ処理部２は、入出力点識別番号５１をリクエスト及びレスポンスに含める。入出力点識別番号５１をリクエスト及びレスポンスに含める際には、例えば、入出力点識別番号５１を含む、図３に示される定義カテゴリ７ｄのデータをリクエスト及びレスポンスに含めてもよい。

本実施の形態に係るデータ振分部３は、実施の形態２と同様、一つのデータ処理部２からリクエストを受信した場合に、全データ処理部２に対して当該リクエストを送信する。そして、複数のデータ処理部２のそれぞれは、データ振分部３からリクエストを受信した場合には、当該リクエストと同じカテゴリ７及び入出力点識別番号５１を含むレスポンスのみをデータ振分部３に送信する。これにより、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信することができるようになる。

次に、本実施の形態に係る監視制御システム１の動作について図１５，１６を用いて説明する。

図１５は、一つのデータ処理部２がカテゴリデータ５４を必要とする際に行われる動作を示すフローチャートである。まず、実施の形態２で説明したステップｓ１０〜ｓ１５Ａ（図１３）が行われる。ただし、本実施の形態に係るステップｓ１０においては、当該一つのデータ処理部２は、カテゴリ７、応答回数、及び、入出力点識別番号５１を含むリクエストを生成する。そして、ステップｓ１６Ｂにて、各データ処理部２は、受信したリクエストに含まれるカテゴリ７及び入出力点識別番号５１を一時的にキャッシュし、図１５に示される工程が終了する。

図１６は、一つのデータ処理部２がカテゴリデータ５４を送信する際に行われる動作を示すフローチャートである。まず、実施の形態２で説明したステップｓ２０〜ｓ２３（図１４）が行われる。そして、ステップｓ２４Ｂにて、カテゴリデータ５４を送信しようとするデータ処理部２は、レスポンスに含めようとするカテゴリ７及び入出力点識別番号５１と、ステップｓ１６Ｂでキャッシュされたカテゴリ７及び入出力点識別番号５１とが互いに合致するかを判定する。ステップｓ２４Ｂにおいて合致すると判定された場合には、ステップｓ２４に進み、それ以降、実施の形態１で説明した工程と同じ工程が行われる。ステップｓ２４Ｂにおいて合致しないと判定された場合には、各データ処理部２がレスポンスの生成及び送信を行わずに、図１６に示される工程が終了する。この動作により、全データ処理部２は、データ振分部３から受信したリクエストと同じカテゴリ７及び入出力点識別番号５１を含むレスポンスのみを、データ振分部３に送信することになる。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、実施の形態２と同様の効果を得ることができる。特に本実施の形態では、データ振分部３は、入出力点識別番号５１を用いることによってより限定されたレスポンスのみをデータ処理部２から受信することができるため、データ振分部３において不要な処理をより削減することができる。したがって、データ振分部３の負荷軽減及び高速処理化を高めることができる。

＜実施の形態４＞
本実施の形態に係る監視制御システム１のハードウェア構成及び機能ブロック構成は、実施の形態２に係る監視制御システム１のハードウェア構成及び機能ブロック構成とそれぞれ同じである。以下、本実施の形態に係る監視制御システム１のハードウェア構成、及び、機能ブロック構成において、実施の形態２と同一の部分には同一符号を付与し、以下においては実施の形態２と異なる部分を中心に説明する。

本実施の形態に係る監視制御システム１及び監視制御プログラムにおいても、実施の形態２と同様、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信するようになっている。以下、このような本実施の形態に係る監視制御システム１及び監視制御プログラムについて説明する。

本実施の形態に係るデータ振分部３は、実施の形態２と同様、データ処理部２からリクエストを受信した場合に、全データ処理部２に対して当該リクエストを送信する。

本実施の形態に係る複数のデータ処理部２は、カテゴリ７及び応答回数に加えて、カテゴリデータ５４を絞り込むことを可能にする後述する絞込条件をリクエストに含める。そして、複数のデータ処理部２のそれぞれは、データ振分部３からリクエストを受信した場合には、当該リクエストと同じカテゴリ７と、当該リクエストに含まれる絞込条件に合致するカテゴリデータ５４とを含むレスポンスのみをデータ振分部３に送信する。これにより、データ振分部３は、必要なレスポンスのみを複数のデータ処理部２から受信することができるようになる。

次に、絞込条件について説明する。絞込条件とは、図３及び図４に示される、カテゴリデータ５４の属性５２に対して‘＜’、‘＜＝’、‘＝’、‘！＝’、‘＝＞’、‘＞’といったオペランドと閾値などの値とを組み合わせた絞込項目同士を、‘ＡＮＤ’または‘ＯＲ’によって組み合わせた絞込項目集合から構成した検索文である。図３において「イベント種別」と示される属性５２において、「軽故障」と示される属性値５３であるカテゴリデータ５４を絞り込むための絞込条件は、ＸＭＬ形式では次のように記述される。

なお、監視制御システム１に共通な絞込条件は、予め属性値５３の型やフォーマットを定めておくことも可能である。例えば、属性値取得開始時刻や取得個数などといったトレンドグラフや帳票等でよく使用されるものなどが挙げられる。その絞込条件の一例は、ＸＭＬ形式では次のように記述される。

次に、本実施の形態に係る監視制御システム１の動作について図１７，１８を用いて説明する。

図１７は、一つのデータ処理部２がカテゴリデータ５４を必要とする際に行われる動作を示すフローチャートである。まず、実施の形態２で説明したステップｓ１０〜ｓ１５Ａ（図１３）が行われる。ただし、本実施の形態に係るステップｓ１０においては、当該一つのデータ処理部２は、カテゴリ７、応答回数、及び、絞込条件を含むリクエストを生成する。そして、ステップｓ１６Ｃにて、各データ処理部２は、受信したリクエストに含まれるカテゴリ７及び絞込条件を一時的にキャッシュし、図１７に示される工程が終了する。

図１８は、一つのデータ処理部２がカテゴリデータ５４を送信する際に行われる動作を示すフローチャートである。まず、実施の形態２で説明したステップｓ２０〜ｓ２４Ａ（図１４）が行われる。その一連のステップの最後のステップに当たるステップｓ２４Ａにおいて、レスポンスに含めようとするカテゴリ７と、ステップｓ１６Ｃでキャッシュされたカテゴリ７とが合致すると判定された場合にはステップｓ２４Ｃに進む。一方、ステップｓ２４Ａにおいて合致しないと判定された場合には、各データ処理部２がレスポンスの生成及び送信を行わずに、図１８に示される工程が終了する。

ステップｓ２４Ｃにて、カテゴリデータ５４を送信しようとする複数のデータ処理部２のそれぞれは、レスポンスに含めようとするカテゴリデータ５４が、ステップｓ１６Ｃでキャッシュされた絞込条件に合致するかを判定する。ステップｓ２４Ｃにおいて合致すると判定された場合には、ステップｓ２４に進み、それ以降、実施の形態１で説明した工程と同じ工程が行われる。ステップｓ２４Ｃにおいて合致しないと判定された場合には、各データ処理部２がレスポンスの生成及び送信を行わずに、図１６に示される工程が終了する。この動作により、全データ処理部２は、データ振分部３から受信したリクエストと同じカテゴリ７と、当該リクエストに合致するカテゴリデータ５４とを含むレスポンスのみを、データ振分部３に送信することになる。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、実施の形態２と同様の効果を得ることができる。特に本実施の形態では、データ振分部３は、絞込条件を用いることによってより限定されたレスポンスのみを受信することができるため、データ振分部３において不要な処理をより削減することができる。したがって、データ振分部３の負荷軽減及び高速処理化を高めることができる。

なお、本実施の形態は一例であり、様々な形式にて検索条件を記述することができる。また、監視制御システム１に検索条件をあらかじめ決めておくことにより、不要な文字列解析等を省く方法を取ることも可能である。

また、以上では、本実施の形態に係る監視制御システム１を、本実施の形態２に適用して説明したが、これに限ったものではなく、実施の形態３に適用してもよい。

＜実施の形態５＞
本実施の形態に係る監視制御システム１のハードウェア構成は、実施の形態２と同じであるが、本実施の形態に係る監視制御システム１の機能ブロック構成は、実施の形態２と異なる。以下、本実施の形態に係る監視制御システム１の機能ブロック構成において、実施の形態２と同一の部分には同一符号を付与し、以下においては実施の形態２と異なる部分を中心に説明する。

本実施の形態に係る監視制御システム１及び監視制御プログラムにおいては、カテゴリデータ５４の更新のタイミングに関わらず、データ振分部３は、指定時刻においてカテゴリデータ５４を取得し、リクエスト送信元のデータ処理部２に当該カテゴリデータ５４を送信するようになっている。以下、このような本実施の形態に係る監視制御システム１及び監視制御プログラムについて説明する。

図１９は、本実施の形態に係る監視制御システム１の機能ブロックを示す図である。図に示すように、本実施の形態に係る監視制御システム１は、実施の形態１に係る監視制御システム１に、タイマー実行部５０を加えたものである。そして、本実施の形態に係る監視制御システム１にけるインタフェース４、リクエスト、データ振分部３及びデータ振分定義情報３０は、実施の形態２のそられに一部機能が加わったものとなっている。

本実施の形態においては、インタフェース４には、実施の形態１で説明した五つのメソッドに加えて、「送信指示リクエスト受信メソッド」が定義されている。この送信指示リクエスト受信メソッドは、全データ処理部２が実装するものであり、データ振分部３によって実行される。一つのデータ処理部２の送信指示リクエスト受信メソッドがデータ振分部３によって実行されると、当該一つのデータ処理部２は、データ振分部３から送信されるリクエストと実質的に同じ振分部生成リクエストを受信する。その直後に、当該一つのデータ処理部２は、当該振分部生成リクエストと同じカテゴリ７を含むレスポンスをデータ振分部３に送信する。

このように、送信指示リクエスト受信メソッドは、データ処理部２において、リクエストの受信と、レスポンスの送信とがほぼ同時に行われる同期型のメソッドである。なお、説明を簡単にするため、送信指示リクエスト受信メソッドが実行されて、レスポンスをデータ振分部３に送信するように指示されるデータ処理部２を、「レスポンス送信指示対象のデータ処理部２」と、以下呼ぶこともある。

本実施の形態に係る複数のデータ処理部２は、カテゴリ７及び応答回数を含む上述のリクエストだけでなく、カテゴリ７及び応答回数に加えて指定時刻の情報を含むリクエストも生成する。

本実施の形態に係るデータ振分部３は、これまで説明した動作に加え、指定時刻の情報を含むリクエストを受信した場合に、図５に示されるレスポンス対象カテゴリ３４のうち、当該リクエストと同じカテゴリ７を特定する。そして、データ振分部３は、特定したカテゴリ７に関連付けられたデータ処理部２のＩＤ３１を、レスポンス送信指示対象のデータ処理部２のＩＤ３１（以下、略して「レスポンス送信指示対象のＩＤ３１」と呼ぶこともある）を取得する。

データ振分部３は、受信したリクエストに含まれるカテゴリ７と、取得したレスポンス送信指示対象のＩＤ３１とをタイマー実行部５０に付与するとともに、当該リクエストに含まれる指定時刻に起動するようにタイマー実行部５０に指示する。

タイマー実行部５０は、データ振分部３から付与されたカテゴリ７及びレスポンス送信指示対象のＩＤ３１を保持した状態で、指定時刻までスリープする。そして、タイマー実行部５０は、指定時刻に達した場合に、保持しているカテゴリ７及びレスポンス送信指示対象のＩＤ３１をデータ振分部３に付与する。

データ振分部３は、タイマー実行部５０からカテゴリ７及びレスポンス送信指示対象のＩＤ３１を受けた場合には、当該カテゴリ７を含む「振分部生成リクエスト」を生成する。そして、データ振分部３は、振分部生成リクエストを、レスポンス送信指示対象のＩＤ３１で識別されるデータ処理部２に送信する。データ振分部３は、その後に当該データ処理部２から送信されるレスポンスを、リクエスト送信元のデータ処理部２に送信する。

図２０は、一つのデータ処理部２がカテゴリデータ５４を必要とする際に行われる動作を示すフローチャートである。まず、実施の形態１で説明したステップｓ１０〜ｓ１４（図８）が行われる。ただし、本実施の形態に係るステップｓ１０においては、当該一つのデータ処理部２は、指定時刻を含まないリクエストと、指定時刻を含むリクエストとを選択的に生成する。

ステップｓ１４後のステップｓ１７にて、データ振分部３は、ステップｓ１２において受信したリクエストに指定時刻の情報が含まれているかを判定する。ステップｓ１７にて、指定時刻の情報が含まれていると判定された場合にはステップｓ１８に進み、そうでない場合には、図２０に示される工程が終了する。

ステップｓ１８にて、データ振分部３は、ステップｓ１２にて受信したリクエストに含まれるカテゴリ７に基づいて、データ振分定義情報３０からレスポンス送信指示対象のＩＤ３１を取得する。具体的には、データ振分部３は、図５に示されるレスポンス対象カテゴリ３４のうち、ステップｓ１２にて受信したリクエストと同じカテゴリ７を特定し、当該カテゴリ７に関連付けられたデータ処理部２のＩＤ１を、レスポンス送信指示対象のＩＤ３１として取得する。

そして、データ振分部３は、ステップｓ１２にて受信したリクエストのカテゴリ７及びレスポンス送信指示対象のＩＤ３１をタイマー実行部５０に付与するとともに、指定時刻に起動するようにタイマー実行部５０に指示する。タイマー実行部５０は、データ振分部３から付与されたカテゴリ７及びレスポンス送信指示対象のＩＤ３１を保持する。そして、図２０に示される工程が終了する。

図２１は、指定時刻にタイマー実行部５０が起動する際に行われる動作を示すフローチャートである。ステップｓ６０にて、タイマー実行部５０は指定時刻までスリープしている。ステップｓ６１にて、タイマー実行部５０は指定時刻に起動する。そして、ステップｓ６２にて、タイマー実行部５０は、保持しているカテゴリ７及びレスポンス送信指示対象のＩＤ３１をデータ振分部３に付与する。

ステップｓ６３にて、データ振分部３は、タイマー実行部５０から、保持していたカテゴリ７（データ振分部３がステップｓ１２において受信したリクエストと同じカテゴリ７）を受けると、当該カテゴリ７を含む振分部生成リクエストを生成する。

そして、ステップｓ６４にて、データ振分部３は、レスポンス送信指示対象のＩＤ３１により識別されるレスポンス送信指示対象のデータ処理部２に対し、インタフェース４に定義されている送信指示リクエスト受信メソッドを実行し、生成した振分部生成リクエストを当該データ処理部２に送信する。

これにより、ステップｓ６４では、以下のステップｓ６４ａ〜ｓ６４ｄが行われる。まず、ステップｓ６４ａにて、レスポンス送信指示対象のデータ処理部２は、データ振分部３から、振分部生成リクエストを受信する。ステップｓ６４ｂにて、レスポンス送信指示対象のデータ処理部２は、振分部生成リクエストに含まれるカテゴリ７を特定する。そして、レスポンス送信指示対象のデータ処理部２は、特定したカテゴリ７のカテゴリデータ５４を、実施の形態１で説明したステップｓ２０〜ｓ２３（図９）と同じ工程を行うことにより、デバイス９の各種データから生成する。ステップｓ６４ｃにて、レスポンス送信指示対象のデータ処理部２は、当該カテゴリ７と、生成したカテゴリデータ５４とを含むレスポンスを生成し、当該レスポンスをデータ振分部３に送信する。そして、ステップｓ６４ｄにて、データ振分部３は、レスポンス送信指示対象のデータ処理部２からレスポンスを受信する。なお、以上のステップｓ６４ａ〜ｓ６４ｄは、データ振分部３が振分部生成リクエストをレスポンス送信指示対象のデータ処理部２に送信してからすぐに行われる。

ステップｓ６５にて、データ振分部３は、実施の形態１と同様に、リクエストキャッシュ情報４０のリクエスト送信元のＩＤ４２からＩＤ３１を取得し、当該ＩＤ３１に対応するプログラムアドレス３３を取得する。そして、ステップｓ６６にて、データ振分部３は、リクエスト送信元のデータ処理部２に対してレスポンス受信メソッドを実行し、リクエスト送信元のデータ処理部２に、ステップｓ６４ｄにて受信したレスポンスを送信する。これにより、リクエスト送信元のデータ処理部２は、ほぼ指定時刻において、所望のカテゴリデータ５４を含むレスポンスをデータ振分部３から受信し、当該所望のカテゴリデータ５４を取得することができる。

ステップｓ６７にて、実施の形態１のステップｓ２８と同様に、データ振分部３は、リクエストキャッシュ情報４０の応答回数４３を更新する。そして、ステップｓ６８にて、データ振分部３は、応答回数４３が、「１」以上、または、「＊」であるかを判定する。ステップｓ６８において、応答回数４３が「１」以上または「＊」であると判定した場合にはステップｓ６９に進み、そうでない場合には、図２１に示される工程が終了する。ステップｓ６９にて、データ振分部３は、図２０に示されるステップｓ１８と同様に、カテゴリ７及びレスポンス送信指示対象のＩＤ３１をタイマー実行部５０に付与するとともに、指定時刻に起動するようにタイマー実行部５０に指示する。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、リクエストを送信したデータ処理部２は、カテゴリデータ５４の更新のタイミングに関わらず、ほぼ指定時刻にカテゴリデータ５４を受信することができる。したがって、指定時刻が、当該データ処理部２がカテゴリデータ５４を処理する少し前に設定されている場合には、データ処理部２は、入出力点から収集されて間もないデータを処理することができる。

＜実施の形態６＞
本実施の形態に係る監視制御システム１のハードウェア構成及び機能ブロック構成は、実施の形態１に係る監視制御システム１のハードウェア構成及び機能ブロック構成とそれぞれ同じである。以下、本実施の形態に係る監視制御システム１のハードウェア構成、及び、機能ブロック構成において、実施の形態１と同一の部分には同一符号を付与し、以下においては実施の形態１と異なる部分を中心に説明する。

図２２は、一つのカテゴリデータ５４を示す図である。この図２２には、図３に示されていた１時間カテゴリ７ｐｈのカテゴリデータ５４が示されている。図２２に示すように、当該一つのカテゴリデータ５４は複数の属性値５３から構成されており、１時間カテゴリ７ｐｈは複数の属性５２から構成されている。

本実施の形態では、カテゴリデータ５４において、周期カテゴリ７ｐを構成する複数の属性５２のいくつかを「仮想カテゴリ７ｖ」とし、仮想カテゴリ７ｖに対応する属性値５３を「仮想カテゴリデータ５４ｖ」としている。そして、本実施の形態に係る複数のデータ処理部２は、一つのカテゴリデータ５４を複数の仮想カテゴリ７ｐにグループ化して複数の仮想カテゴリデータ５４ｖを生成する。ここでは、周期カテゴリ７ｐについて説明しているが、イベントカテゴリ７ｅについても同様である。なお、仮想カテゴリ７ｖは、図２２に示されるように、一つの属性５２であってもよく、属性５２の一部であってもよい。また、仮想カテゴリデータ５４ｖとする属性値５３は、例えば、通常のカテゴリ７が管理している属性値５３をデプリケートして取得されてもよいし、必要に応じてカテゴリ７が管理している属性値５３から取得されてもよい。

そして、複数のデータ処理部２は、仮想カテゴリ７ｖ及び当該仮想カテゴリ７ｖに対応する仮想カテゴリデータ５４ｖを含む仮想レスポンスと、仮想カテゴリ７ｖを含む仮想リクエストとを、それぞれ、上述のレスポンスと、上述のリクエストとして生成する。つまり、仮想レスポンス及び仮想リクエストが、これまで説明してきたレスポンス及びリクエストと同等に扱われる。

以上のような本実施の形態に係る監視制御システム１及び監視制御プログラムによれば、カテゴリデータ５４のうち必要なデータを、仮想カテゴリデータ５４ｖとして抜き出すことができる。したがって、送受信すべきレスポンス及びリクエストのデータ量を減らすことができるので高速処理化が可能となる。

＜実施の形態７＞
本実施の形態に係る監視制御システム１のハードウェア構成は、実施の形態５と同じであるが、本実施の形態に係る監視制御システム１の機能ブロック構成は、実施の形態５と異なる。以下、本実施の形態に係る監視制御システム１の機能ブロック構成において、実施の形態５と同一の部分には同一符号を付与し、以下においては実施の形態５と異なる部分を中心に説明する。

本実施の形態に係る監視制御システム１及び監視制御プログラムにおいては、データ振分部３とレスポンス等を送受信するデータ処理部２を別のデータ処理部２に変更したり、複数のデータ処理部２にデータ処理部２を追加したりすることが可能となっている。以下、このような本実施の形態に係る監視制御システム１及び監視制御プログラムについて説明する。

図２３は、本実施の形態に係る監視制御システム１の機能ブロックを示す図である。図に示すように、本実施の形態に係る監視制御システム１は、実施の形態５に係る監視制御システム１に、候補データ処理組合設計部６０と、候補データ処理記憶部６１と、候補データ処理組合検証部６２とを加えたものである。

候補データ処理組合設計部６０は、複数のデータ処理部２として使用される複数の候補データ処理部６８の組合せを行う設計ツールである。具体的には、利用者等は、候補データ処理組合設計部６０においてＧＵＩ（Graphical User Interface）を用いて、組合わされた複数の候補データ処理部６８のうちの一つの候補データ処理部６８を別の候補データ処理部６８に変更したり、当該複数の候補データ処理部６８に新たな候補データ処理部６８を追加したりする。そして、候補データ処理組合設計部６０において登録操作が行われた場合には、複数の候補データ処理部６８の組合に基づいて新たなデータ振分定義情報３０が生成され、当該新たなデータ振分定義情報３０がデータ振分定義記憶部５に記憶される。

新たなデータ振分定義情報３０がデータ振分定義記憶部５に記憶されることから、候補データ処理組合設計部６０で組合わされた複数の候補データ処理部６８が、複数のデータ処理部２として使用される。本実施の形態では、以上のように候補データ処理部６８の変更及び追加を行うことにより、データ処理部２の変更及び追加が可能となっている。

候補データ処理組合検証部６２は、候補データ処理組合設計部６０での複数の候補データ処理部６８の組合せが正しいか否かを検証する機能を有する。

候補データ処理記憶部６１は、候補データ処理組合設計部６０の組合せを行う際に用いられる候補データ処理定義情報６３を記憶している。候補データ処理定義情報６３は、複数の候補データ処理部６８と複数のカテゴリ７とを関連付けた情報を含む。図２４は、候補データ処理定義情報６３の一例を示す図である。図に示されるように、候補データ処理定義情報６３は、ＩＤ６４、データ処理名６５、レスポンス対象カテゴリ６６及びリクエスト対象カテゴリ６７とから構成されている。ＩＤ６４は、複数の候補データ処理部６８のそれぞれを候補データ処理組合設計部６０にて一意に識別するための番号を示す。データ処理名６５は、候補データ処理組合設計部６１の画面上において、候補データ処理部６８として表示される名称を示す。レスポンス対象カテゴリ６６は、一つの候補データ処理部６８がデータ振分部３に送信するレスポンスに含めることが可能なカテゴリ７を示す。リクエスト対象カテゴリ６７は、一つの候補データ処理部６８がデータ振分部３に送信するリクエストに含めることが可能なカテゴリ７を示す。

次に、本実施の形態に係る監視制御システム１の動作について説明する。図２５は、候補データ処理組合設計部６０において、候補データ処理部６８の変更が行われる際の動作を示すフローチャートである。

まず、ステップｓ８０にて、候補データ処理組合設計部６０は起動すると、図２６に示されるように、複数の候補データ処理部６８の組合せを表示する編集領域７１と、複数の候補データ処理部６８から一つの候補データ処理部６８を選択するための選択領域７２と、検索ボタン７３と、一覧ボタン７４と、設定ボタン７５と、登録ボタン７６とを画面７０に表示する。

ステップｓ８１にて、候補データ処理組合設計部６０は、候補データ処理記憶部６１に記憶されている候補データ処理定義情報６３を読込む。ステップｓ８２にて、候補データ処理組合設計部６０は、データ振分定義記憶部５に記憶されているデータ振分定義情報３０を読込む。そして、図２７に示されるように、候補データ処理組合設計部６０は、複数のデータ処理部２として使用されている複数の候補データ処理部６８の組合せを編集領域７１に表示する。

ここで、例えば、図２４において、「データ収集データ処理」の候補データ処理部６８には、レスポンス対象カテゴリ６６として「カレント値カテゴリ」のカテゴリ７が関連付けられている。これは、「データ収集データ処理」の候補データ処理部６８は、「カレント値カテゴリ」のカテゴリ７を含むレスポンスを生成可能であることを意味している。一方、「カレント値管理データ処理」の候補データ処理部６８には、リクエスト対象カテゴリ６７として「カレント値カテゴリ」が関連付けられている。これは、「カレント値管理データ処理」の候補データ処理部６８は、「カレント値カテゴリ」のカテゴリ７を含むリクエストを生成可能であることを意味している。

したがって、これら候補データ処理部６８がデータ処理部２として使用される場合には、データ振分部３の動作により、「カレント値カテゴリ」のカテゴリ７を含むレスポンスが、「データ収集データ処理」のデータ処理部２から、「カレント値管理データ処理」のデータ処理部２に送信されることになる。図２７に示される矢印７８は、候補データ処理部６８同士においてレスポンスが送信される方向を示す。他の候補データ処理部６８同士の間においても、矢印７７が同様に表示されている。

ステップｓ８３にて、編集領域７１に表示された複数の候補データ処理部６８のうち、編集対象の候補データ処理部６８が選択される。選択後、編集領域７１において、編集対象の候補データ処理部６８が、他の候補データ処理部６８と区別可能となるように、そのブロックにはハッチングなどが施される。

ステップｓ８４にて検索ボタン７３が押下げられると、候補データ処理組合設計部６０は、レスポンス対象カテゴリ６６から、編集対象の候補データ処理部６８と同等のカテゴリ７が関連付けられた候補データ処理部６８を取得する。例えば、図２８においては、編集対象の候補データ処理部６８として、「カレント値管理データ処理」の候補データ処理部６８が選択されている。図２４において、この「カレント値管理データ処理」の候補データ処理部６８に関連付けられている、レスポンス対象カテゴリ６６のカテゴリ７は、「１分カレント値カテゴリ」である。そして、同図において、「カレント値管理データ処理」の候補データ処理部６８以外に、「１分カレント値カテゴリ」と関連付けられているのは、「スタブカレント値管理データ処理」の候補データ処理部６８である。したがって、この場合にステップｓ８４が行われる場合には、候補データ処理組合設計部６０は、「スタブカレント値管理データ処理」を取得する。なお、スタブカレント値管理データ処理の候補データ処理部６８は、データ処理部２として使用されると、模擬的な試験を行うことを可能にする。

ステップｓ８５にて、候補データ処理組合設計部６０は、編集対象の候補データ処理部６８、及び、取得された候補データ処理部６８を選択領域７２に表示する。例えば、図２８においては、編集対象の候補データ処理部６８として「カレント値管理データ処理」が選択領域７２に表示され、取得された候補データ処理部６８として「スタブカレント値管理データ処理」が選択領域７２に表示されている。

ステップｓ８６にて、選択領域７２に表示されている、編集対象の候補データ処理部６８と別の候補データ処理部６８が選択されてから設定ボタン７５が押下げられると、候補データ処理組合設計部６０は、編集対象の候補データ処理部６８に代えて、選択された別の候補データ処理部６８を編集領域７１に表示する。例えば、図２９には、図２８に示される「カレント値管理データ処理」の候補データ処理部６８に代えて、「スタブカレント値管理データ処理」の候補データ処理部６８が編集領域７１に表示される。

この変更に伴い、候補データ処理組合設計部６０は、候補データ処理部６８同士の間におけるレスポンスの送信方向を示す矢印７７も変更する。例えば、図２４に示されるリクエスト対象カテゴリ６６において、「スタブカレント値データ処理」の候補データ処理部６８にはカテゴリ７が登録されていない。つまり、当該候補データ処理部６８がデータ処理部２として使用される場合には、当該データ処理部２は他のデータ処理部２からのレスポンスを必要としない。したがって、図２８において「データ収集データ処理」の候補データ処理部６８と、「カレント値管理データ処理」の候補データ処理６８との間を接続していた矢印７７が、図２９に示される編集領域７１においては消滅する。

ステップｓ８６後のステップｓ８７にて、候補データ処理組合検証部６２が、編集領域７１における複数の候補データ処理部６８の組合せが正しいかを検証する。本実施の形態では、候補データ処理組合検証部６２は、編集領域７１に表示される複数の候補データ処理部６８が管理するレスポンスにおいて、カテゴリ７が重複しているかを検証する。つまり、候補データ処理組合検証部６２は、編集領域７１に表示される複数の候補データ処理部６８に関して、図２４に示されるレスポンス対象カテゴリ６６のカテゴリ７が重複しているかを検証する。なお、実施の形態１のようなシステム構成に対応するため、リクエスト対象カテゴリ６７のカテゴリ７が重複しているかを合わせて検証することもできる。

本実施の形態に係る候補データ処理組合検証部６２は、この検証に加えて、編集領域７１に表示される複数の候補データ処理部６８が生成するリクエストに対し、それと同じカテゴリ７を含むレスポンスが生成されるかを検証する。つまり、候補データ処理組合検証部６２は、編集領域７１に表示される複数の候補データ処理部６８において、図２４に示されるレスポンス対象カテゴリ６６のカテゴリ７が、リクエスト対象カテゴリ６７のカテゴリ７を含んでいるかを検証する。これにより、組合せ後の複数の候補データ処理部６８が複数のデータ処理部２として使用される場合に、データ処理部２は、リクエストと同じカテゴリ７を含むレスポンスを確実に受信することができる。

ステップｓ８７において、上述の二つの検証の結果、いずれも正しいと判定された場合には図２５に示される工程が終了し、二つの検証のうちいずれか一つでも正しくないと判定された場合にはステップｓ８８に進む。ステップｓ８８にて、候補データ処理組合設計部６０は、組合せが正しくない旨を画面７０に表示した後、ステップｓ８２に進んで上述と同じ工程が行われる。

以上、候補データ処理部６８の変更について詳細に説明したが、新たな候補データ処理部２の追加は変更とほぼ同様であるため、簡単に以下説明する。

候補データ処理組合設計部６０は、検索ボタン７３または一覧ボタン７４が押下げられた際に、候補データ処理定義情報６３に登録されている候補データ処理部６８の全てを選択領域７２に表示する。そして、選択領域７２に表示されている全候補データ処理部６８のうち一つの候補データ処理部６８が選択されてから設定ボタン７５が押下げられると、候補データ処理組合設計部６０は、選択された候補データ処理部６８を編集領域７１の空白部分に追加して表示する。この追加に伴い、候補データ処理組合設計部６０は、候補データ処理部６８同士の間におけるレスポンスの送信が新たに生じた場合には、当該送信方向を示す矢印７７も追加する。そして、ステップｓ８６以降の工程と同様の工程を行い、候補データ処理組合検証部６２により検証が行われる。

図３０は、候補データ処理組合設計部６０が、以上の工程により行われた設計情報を、データ振分定義記憶部５にデータ振分定義情報３０として記憶する動作を示すフローチャートである。この動作は、候補データ処理組合設計部６０における候補データ処理部６８の組合せ後に行われる。

ステップｓ９０にて、画面７０に表示されている登録ボタン７６が押下げられると、ステップｓ９１にて、候補データ処理組合設計部６０は、データ振分定義記憶部５に記憶される新たなデータ振分定義情報３０の生成を開始する。具体的には、まず、ステップｓ９２にて、候補データ処理組合設計部６０は、編集領域７１に表示されている複数の候補データ処理部６８の一覧を取得する。ステップｓ９３にて、候補データ処理組合設計部６０は、取得した全候補データ処理部６８に対してＩＤ３１となるＩＤを付与する。

ステップｓ９０前において候補データ処理部６８を変更する設計が行われた場合には、ステップｓ９４にて、候補データ処理組合設計部６０は、プログラムファイル３２となる情報を変更する。ステップｓ９０前において、候補データ処理部６８を追加する設計が行われた場合には、同ステップｓ９４にて、候補データ処理組合設計部６０は、プログラムファイル３２、レスポンス対象カテゴリ３４、及び、リクエスト対象カテゴリカテゴリ３５となる情報を新たなデータ振分定義情報３０に追加する。これにより、データ振分定義情報３０が新規に生成される。

ステップｓ９５にて、候補データ処理組合設計部６０は、新規に生成された新たなデータ振分定義情報３０を、データ振分定義情報３０としてデータ振分定義部５に保存する。こうして、候補データ処理部６８を変更する設計が行われて、登録ボタン７６が押下された場合には、データ処理部２が変更される。

以上のような本実施の形態に係る監視制御システム１によれば、互いにデータを送受信するデータ処理部２を、当該データ処理部２と同等のデータ処理部２に容易に代えることができる。特に、別のデータ処理部２が、スタブデータ値管理データ処理の機能を有する場合には、デバイス９などのハードウェアがなくても監視制御システム１を試験することができるので有効である。

また、本実施の形態では、候補データ処理組合設計部６０が追加及び変更した複数のデータ処理部２に関して、当該複数のデータ処理部２が生成するレスポンスに含まれるカテゴリ７が重複しているかが検証されることから、一つのリクエストが、二つ以上のデータ処理部２に送信されるのを防ぐことができる。また、候補データ処理組合設計部６０が追加及び変更した複数のデータ処理部２に関して、当該複数のデータ処理部２が生成するレスポンスに含まれるカテゴリ７が、リクエストに含まれるカテゴリ７を含んでいるかを検証する。これにより、データ処理部２がリクエストを送信すれば、当該データ処理部２は、当該リクエストと同じカテゴリ７を含むレスポンスを確実に受信することができる。

以上、本発明の実施の形態を詳細に開示し記述したが、以上の記述は本発明の適用可能な局面を例示したものにすぎず、本発明はこれに限定されるものではない。すなわち、記述した局面に対応する様々な例を、この発明の範囲から逸脱すること無い範囲内で考えることが可能となる。

１ 監視制御システム、２ データ処理部、３ データ振分部、４ インタフェース、５ データ振分定義記憶部、７ カテゴリ、７ｖ 仮想カテゴリ、９ デバイス、５０ タイマー実行部、５４ カテゴリデータ、５４ｖ 仮想カテゴリデータ、６０ 候補データ処理組合設計部、６１ データ処理機億部、６２ 候補データ処理組合検証部、６８ 候補データ処理部。

Claims (10)

1. 複数のデバイスの入出力点から収集する複数の数値データ及び複数種類のイベントデータを監視制御する監視制御システムであって、
   所定の複数の数値データ及び前記複数種類のイベントデータを複数のカテゴリにグループ化して複数のカテゴリデータを生成し、前記カテゴリ及びそれに対応する前記カテゴリデータを含むレスポンスと、前記カテゴリを含むリクエストとを生成する複数のデータ処理部と、
   インタフェースを介して前記複数のデータ処理部との間で前記レスポンスを送受信し、かつ、前記インタフェースを介して前記複数のデータ処理部から前記リクエストを受信するデータ振分部と
   を備え、
   前記複数のデータ処理部のそれぞれは、前記データ振分部からの前記レスポンスを受信した場合に、当該レスポンスに含まれる前記カテゴリデータを用いて所定の処理を行い、
   前記データ振分部は、
   リクエスト送信元の前記データ処理部から受信した前記リクエストに含まれる前記カテゴリと、レスポンス送信元の前記データ処理部から受信した前記レスポンスに含まれる前記カテゴリとに基づいて、当該レスポンスを前記リクエスト送信元のデータ処理部に送信する、監視制御システム。
2. 請求項１に記載の監視制御システムであって、
   前記複数のデータ処理部は、前記入出力点から収集された前記数値データを加工し、
   前記所定の複数の数値データは、収集された前記数値データ及び加工された前記数値データを含み、
   前記複数のカテゴリは、複数種類の周期と、複数種類のイベントとを含み、
   前記複数のデータ処理部は、
   前記複数の所定の数値データを前記周期の種類ごとにグループ化して前記複数のカテゴリデータをそれぞれ生成するとともに、前記複数種類のイベントデータを前記イベントの種類ごとにグループ化して前記複数のカテゴリデータを生成する、監視制御システム。
3. 請求項１または請求項２に記載の監視制御システムであって、
   前記複数のデータ処理を記憶するデータ振分定義記憶部
   をさらに備え、
   前記データ振分部は、前記データ振分定義記憶部に記憶されている前記複数のデータ処理部を、前記インタフェースを介して起動及び停止する、監視制御システム。
4. 請求項１乃至請求項３のいずれかに記載の監視制御システムであって、
   前記複数のデータ処理部が生成する前記リクエストに含まれる前記複数のカテゴリは、互いに異なり、
   前記複数のデータ処理部と、前記複数のカテゴリとを関連付けて記憶するデータ振分定義記憶部
   をさらに備え、
   前記データ振分部は、
   前記リクエスト送信元のデータ処理部からの前記リクエストを受信し、かつ、前記レスポンス送信元のデータ処理部からの前記レスポンスを受信した場合に、当該リクエストに含まれる前記複数のカテゴリと当該レスポンスに含まれる前記カテゴリとが互いに一致するかを判定し、これらが一致すると判定した際に、当該レスポンスを、当該カテゴリに関連付けられた一つの前記データ処理部に送信する、監視制御システム。
5. 請求項１乃至請求項４のいずれかに記載の監視制御システムであって、
   前記データ振分部は、
   前記リクエスト送信元のデータ処理部から前記リクエストを受信した場合に、当該リクエストを前記複数のデータ処理部に送信し、
   前記複数のデータ処理部は、前記インタフェースのリクエスト受信メソッドによって前記データ振分部から前記リクエストを受信した場合に、当該リクエストと同じ前記カテゴリを含む前記レスポンスのみを前記データ振分部に送信する、監視制御システム。
6. 請求項１乃至請求項５のいずれかに記載の監視制御システムであって、
   前記リクエスト送信元のデータ処理部から送信された前記リクエストに含まれる前記カテゴリを、指定時刻に前記データ振分部に付与するタイマー実行部
   をさらに備え、
   前記データ振分部は、
   前記タイマー実行部から前記カテゴリを付与された場合に、当該カテゴリと同じ前記カテゴリを含む前記レスポンスを前記リクエスト送信元のデータ処理部を除く前記複数のデータ処理部から取得し、当該レスポンスを前記リクエスト送信元のデータ処理部に送信する、監視制御システム。
7. 請求項１乃至請求項６のいずれかに記載の監視制御システムであって、
   前記複数のデータ処理部は、
   一つの前記カテゴリデータを複数の仮想カテゴリにグループ化して複数の仮想カテゴリデータを生成し、前記仮想カテゴリ及びそれに対応する前記仮想カテゴリデータを含む仮想レスポンスを前記レスポンスとして生成するとともに、前記仮想カテゴリを含む仮想リクエストを前記リクエストとして生成する、監視制御システム。
8. 請求項１乃至請求項７のいずれかに記載の監視制御システムであって、
   前記複数のデータ処理部として使用される複数の候補データ処理部と、当該複数の候補データ処理部により生成される前記レスポンスに含まれる前記カテゴリとを関連付けて記憶する候補データ処理記憶部と、
   前記複数の候補データ処理部の組合せが行われる候補データ処理組合設計部と
   をさらに備え、
   前記候補データ処理組合設計部は、
   組合わされた前記複数の候補データ処理部のうちの一つの候補データ処理部を、当該一の候補データ処理部と同じ前記カテゴリと関連付けられた別の前記候補データ処理部に代えることが可能な、監視制御システム。
9. 請求項８に記載の監視制御システムであって、
   前記複数の候補データ処理部の組合せにおいて、当該複数の候補データ処理部が生成する前記レスポンスまたは前記リクエストに含まれる前記カテゴリに重複があるかを検証するとともに、当該リクエストと同じ前記カテゴリを含む前記レスポンスが生成されるかを検証する候補データ処理組合検証部
   をさらに備える、監視制御システム。
10. 複数のデバイスの入出力点から収集する複数の数値データ及び複数種類のイベントデータを監視制御する監視制御システムを構成するコンピュータに
    （ａ）複数のデータ処理部が、所定の複数の数値データ及び前記複数種類のイベントデータを複数のカテゴリにグループ化して複数のカテゴリデータを生成し、前記カテゴリ及びそれに対応する前記カテゴリデータを含むレスポンスと、前記カテゴリを含むリクエストとを生成する工程と、
    （ｂ）データ振分部が、リクエスト送信元の前記データ処理部からインタフェースを介して受信した前記リクエストに含まれる前記カテゴリと、レスポンス送信元の前記データ処理部から前記インタフェースを介して受信した前記レスポンスに含まれる前記カテゴリとに基づいて、当該レスポンスを前記インタフェースを介して前記リクエスト送信元のデータ処理部に送信する工程と、
    （ｃ）前記リクエスト送信元のデータ処理部が、前記レスポンスを受信した場合に、当該レスポンスに含まれる前記カテゴリデータを用いて所定の処理を行う工程と
    を実行させる、監視制御プログラム。

Images