JP4299928B2 - 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体 - Google Patents

分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体 Download PDF

Info

Publication number
JP4299928B2
JP4299928B2 JP24375999A JP24375999A JP4299928B2 JP 4299928 B2 JP4299928 B2 JP 4299928B2 JP 24375999 A JP24375999 A JP 24375999A JP 24375999 A JP24375999 A JP 24375999A JP 4299928 B2 JP4299928 B2 JP 4299928B2
Authority
JP
Japan
Prior art keywords
processing unit
function processing
transmission path
information transmission
function
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.)
Expired - Lifetime
Application number
JP24375999A
Other languages
English (en)
Other versions
JP2001067334A (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.)
Toshiba Corp
Original Assignee
Toshiba 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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP24375999A priority Critical patent/JP4299928B2/ja
Publication of JP2001067334A publication Critical patent/JP2001067334A/ja
Application granted granted Critical
Publication of JP4299928B2 publication Critical patent/JP4299928B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Testing And Monitoring For Control Systems (AREA)
  • Hardware Redundancy (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は、プラントなどの対象に関する監視・制御を、ネットワーク接続した複数の構成機器で行う分散監視制御の技術の改良に関するもので、特に、全体を停止させる事なく構成変更に柔軟に対応するものである。
【0002】
【従来の技術】
従来から、発電プラントや浄水プラントなど各種のプラントにおいては、非常に多数の計測点を設け、各計測点におけるプロセスの状態量、例えば冷却水給水温度や冷却水排水温度、タービン回転数、ボイラ蒸気温度等を計測している。これらのプロセス状態量は、集中監視制御室に備えられた監視制御盤、或いは監視制御卓などで常時監視される一方、制御装置によるプロセス制御にも使用される。
【0003】
特に近年では、計装制御のディジタル化が進展するのに伴い、制御装置、監視装置といった個々に独立していた装置は、ネットワーク接続される共に統合化され、プラントに設置するセンサから得られる状態量を共有する一方、プラントの規模に応じた拡張性と柔軟性を兼ね備えた分散監視制御システムへと変貌を遂げている。
【0004】
一方、コンピュータシステムの基盤となるネットワーク通信技術においては、インターネットプロトコル(IP/Internet Protocol )が事実上の標準として定着し、ハードウェアではイーサネットを中心に高速化が図られる一方、ソフトウェアにおいてはTCP(Transmission Control Protocol )/IPプロトコルを用いたクライアント/サーバ型の分散システムが大勢を占めている。
【0005】
このクライアント/サーバ型のシステムは、サービスを受ける側(クライアントと呼ぶ)と提供する側(サーバと呼ぶ)という関係を複数組合せる事により成立つシステムであり、サーバの配置によって柔軟なシステム構成を採れるという特徴を有する一方、利用しているサービスのひとつでも機能を停止するとクライアント全体の機能が喪失する可能性もある。このため、サーバが稼動するホストでは、サービスの重要度に応じて、信頼性を確保する為にクラスタシステム等を用いた冗長化・多重化による耐障害性の向上が図られている。
【0006】
ここで、クラスタシステムとは、サーバなどのシステムを複数組み合わせて1つのシステムとして扱うものであり、例えば、あるサーバで何からの問題が発生した場合、そのサーバをシステムから切り離し、実行中のプロセスやトランザクションは残った他のサーバ上で実行することができる。
【0007】
特に、プラントの監視制御を目的とするようなシステムでは、一部機能の喪失によって、プロセス制御はもちろんのこと、プロセス監視においても、全体機能の喪失を招く事態は許容されるものではなく、プラントの運転を継続する為の必要最低限の機能は使用出来なければならない。
【0008】
ここで、図52は、従来の分散監視制御システムの構成例を示す機能ブロック図である。すなわち、この例では、21はプロセス制御を行う制御装置、22aはプロセス監視を行う監視サーバ装置、22bはプロセス監視を行う監視クライアント装置である。なお、これら監視サーバ装置22aと監視クライアント装置22bとをあわせて監視装置22(a,b)と呼ぶ。また、30は、これら制御装置21と監視装置を接続する通信ネットワークである。
【0009】
この例において、各制御装置21は、ハードウェア障害発生時の影響を限定する目的で系統毎に分割した構成を採り、計測点からの状態量入力、プロセス制御に必要な演算と制御量のプロセス出力は各々の装置が独立して行う様になっている。すなわち、各制御装置21に入力された計測点の状態量と、演算によって求められた値の一部は監視点となり、一定値以上の変化が認められた場合は、通信ネットワーク30などのネットワーク伝送装置を経て監視サーバ装置22aと監視クライアント装置22bに最新状態が送信される。なお、監視点とは監視対象として選択された状態量などの属性である。
【0010】
また、各監視装置22は、監視点の最新状態を独立して保持し、監視装置22(a,b)の一部に障害が発生しても、状態の把握とプラント構成機器の操作には影響が無い様になっている。
【0011】
このように、分散監視制御システムを構成する機器はネットワーク接続されてはいるものの、ネットワーク上の装置に対して疎結合となる目的でUDP/IPプロトコルを用いるのが一般的となっている。このUDP/IPプロトコルは、ネットワーク層プロトコルであるIP(Internet Protocol) に、トランスポート層プロトコルとしてUDP(User Datagram Protocol)を組み合わせたもので、通信先との接続を確立しない状態で送信を行う方式である。
【0012】
このようなUDP/IPプロトコルでは、TCP/IPプロトコルの様に通信先との確立にかかる伝送が不要という利点がある反面、プロトコルの性質として送信した内容が送信先に着信する保証が無いという問題があるが、この問題に対しては、状態量の変化が発生しなくても、制御装置が定期的に全ての状態量を監視装置に送信する事で解決するのが一般的となっている。
【0013】
【発明が解決しようとする課題】
ところで、上記のような従来技術では、プラントの規模に応じて必要な制御装置と監視装置の規模は変化するのに加えて、信頼性を向上させる目的で監視サーバ装置を冗長化したり、監視サーバ装置としての機能を複数のサーバに分散するため、TCP/IPプロトコルによる通信においては、サービスを提供している監視サーバ装置を監視クライアント装置がサービス毎に認識できる仕組みが必要であり、実装が煩雑という問題があった。
【0014】
また、上記のような従来技術で使われていたTCP/IPプロトコルによる通信では、本来送受信したいデータ本体のほかに、接続の確立、着信の確認といった操作のためにサーバ/クライアント間で情報の伝送が必要となるため、伝送路が持つ帯域幅を最大限に活用できないという問題もあり、通信の効率改善が潜在的に求められていた。
【0015】
加えて、上記のような従来技術では、監視サーバ装置は監視クライアント装置に対してサービス状況を伝える必要があった。このため、監視制御対象の規模や範囲などを拡大するために、監視クライアント装置の追加等による分散制御装置の構成変更を行う場合は、装置全体を一旦停止させて監視サーバ装置内の設定変更を必要とするなど影響が大きいという問題があった。
【0016】
本発明は、上記のような従来技術の問題点を解決するために提案されたもので、その目的は、実装が容易な分散監視制御の技術すなわち分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体を提供することである。また、本発明の他の目的は、優れた効率で通信を行う分散監視制御の技術を提供することである。また、本発明の他の目的は、全体を停止させる事なく監視制御対象の拡大に対応できる分散監視制御の技術を提供することである。
【0017】
【課題を解決するための手段】
上記の目的を達成するため、請求項1の発明は、互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御システムにおいて、前記ネットワークは複数の情報伝達路を備え、前記各装置は、前記監視及び制御に関する処理を行うための少なくとも1つの機能処理部と、前記通信に関する処理を行うための配信処理部と、を備え、前記配信処理部は、前記情報伝達路と前記機能処理部との対応関係を登録するための配信データベースと、前記対応関係を前記データベースに登録するための配信登録手段と、登録された前記対応関係に基づいて、前記通信を制御するための配信制御手段と、を備え、前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、を備え、前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を備えたことを特徴とする。請求項15の発明は、請求項1の発明を方法という観点から把握したもので、互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御方法において、前記ネットワークにおいて複数の情報伝達路を用い、前記各装置に、前記監視及び制御に関する処理を行うためのプロセスとして、少なくとも1つの機能処理部と、前記通信に関する処理を行うためのプロセスとして配信処理部と、を設け、前記配信処理部が、前記情報伝達路と前記機能処理部との対応関係を、配信データベースに登録するためのステップと、前記配信処理部が、登録された前記対応関係に基づいて、前記通信を制御するためのステップと、を含み、前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、有し、前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を有することを特徴とする。請求項23の発明は、請求項1,15の発明を、コンピュータを用いて、互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御用ソフトウェアを記録した記録媒体において、そのソフトウェアは前記コンピュータに、前記ネットワークにおいて複数の情報伝達路を用いさせ、前記各装置に、前記監視及び制御に関する処理を行うためのプロセスとして、少なくとも1つの機能処理部と、前記通信に関する処理を行うためのプロセスとして配信処理部と、を設けさせ、前記配信処理部に、前記情報伝達路と前記機能処理部との対応関係を、配信データベースに登録する配信登録処理と、前記配信処理部に、登録された前記対応関係に基づいて、前記通信を制御する配信制御処理と、を実行させ、前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、有し、前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を有することを特徴とする。請求項1,15,23の発明では、システムの構成単位となる制御装置や監視装置といった各装置をネットワーク接続し、ネットワーク上に用意した複数の情報伝達路ごとにどのような情報をやりとりするか定めておく。また、各装置上の配信処理部は、どの機能処理部がどの情報伝達路についてデータを送受信するかの情報を配信データベースに登録し、通信を制御したりそのような情報を互いに交換する。これにより、各装置上の配信処理部は、情報の種類に応じた情報伝達路を使い分け、送出側も受信側を相手方をIPアドレスといった物理的なネットワークアドレスで認識するまでもなく、メッセージの配信先を特定するなど、必要な送受信を行うことが可能となる。この結果、システムの規模に応じて柔軟な構成をとる事が出来るので、拡張性と応答性に優れた分散監視制御システムを得る事ができ、装置や機能処理部の新設・除去・移動・変更・停止・メンテナンスといった構成変更の場合も、ネットワークや情報伝達路の構成自体やプロトコルには変化を与えず、該当する装置内で情報伝達路と機能処理部との接続関係を変更するだけで足りるので、システム全体の停止も不要となる。特に、監視サーバ装置などによって特定の種類の情報を提供するようなサービスが行われるような場合、監視制御対象の規模や範囲などを拡大するために、監視サーバ装置の冗長化や分散、それを利用する監視クライアント装置の追加などを行っても、ある情報伝達路にリクエストを送ればサービスのデータが返されるといった事情は変化しない。すなわち、監視サーバ装置を監視クライアント装置がサービス毎に認識できる仕組みも不要になるので実装も容易になる。また、監視サーバ装置が監視クライアント装置に対してサービス状況を伝える必要もなくなる。さらに、上記のような装置の追加等による構成変更を行う場合も、システム全体を一旦停止させて監視サーバ装置内の設定変更を必要とするなどの影響は生じない。具体例としては、UDP/IPプロトコルによるマルチキャスト伝送を用いて論理的な情報伝達路を複数用意し、各情報伝達路上でどのようなメッセージを交換するか予め定義しておく。また、システム上の各機能処理部と、その機能を果たす上で入出力の対象とする情報伝達路とについて、両者の対応関係を配信データベースに登録することで接続する。この場合、各情報伝達路は例えばマルチキャスト伝送におけるマルチキャストアドレスに対応する。また、各機能処理部と情報伝達路との接続は、各機能処理部を実現するプロセスのために確保したIPポート番号に、情報伝達路に対応するマルチキャストアドレスを対応付けてメッセージを送受信する事に相当する。このようなUDP/IPプロトコルでは、従来技術で使われていたTCP/IPプロトコルと比べ、接続の確立や着信の確認などのためのオーバーヘッドは生じないので、サーバ/クライアント間などでの伝送路が持つ帯域幅を最大限に活用でき、通信の効率も改善される。さらに、配信データベースでは、1つの情報伝達路と1つの機能処理部の対応関係を1つのブロックで表し、同じ情報伝達路に関わるブロック同士と、同じ機能処理部に関わるブロック同士が、それぞれ双方向リンクを順次接続した二重連結リストの構造をとり、さらに、各情報伝達路と各機能処理部のリストからは、対応するブロックの列の先頭や末尾へのリンクが設定されている。このため、例えばある機能処理部が受信する情報伝達路は、その機能処理部に対応するどのブロックからでも双方向リンクを辿ることで容易に全て特定することができる。同様に、例えばある情報伝達路からの受信データをどれとどの機能処理部へ渡すべきかは、その情報伝達路に対応するどのブロックからでも双方向リンクを辿ることで容易にすべて特定することができる。そして、各機能処理部ごとに対応するメッセージは、その機能処理部の指標が示す格納領域に格納すればよい。また、二重連結リストの構造をとることで、どのブロックからでもブロックすなわち接続の追加や削除といった変更を効率よく行うことができる。以上により、各機能処理部が接続されている情報伝達路に係る送受信や、接続や解除などを、確実に効率よく行うことができる。
【0018】
請求項2の発明は、請求項1記載の分散監視制御システムにおいて、少なくとも1つの前記装置において、複数の前記機能処理部のうち予め決められた代表機能処理部が、前記通信における送受信データについて、他の各機能処理部を代表して前記配信処理部との間で受け渡しするとともに前記各機能処理部に対して受け渡しするように構成されたことを特徴とする。請求項16の発明は、請求項2の発明を方法という観点から把握したもので、請求項15記載の分散監視制御方法において、少なくとも1つの前記装置において、複数の前記機能処理部のうち予め決められた代表機能処理部が、前記通信における送受信データについて、他の各機能処理部を代表して前記配信処理部との間で受け渡しするとともに前記各機能処理部に対して受け渡しすることを特徴とする。請求項2,16の発明では、ある装置上の複数の機能処理部のうち1つの代表機能処理部が他の機能処理部を代表し、配信処理部を通じて通信ネットワークからのメッセージ受信などを行い、他の機能処理部にソフトウェアバスなどを通じて受信メッセージをコピーして渡す。このため、配信処理部における送受信データのやり取りについて、対象が代表機能処理部に一本化され、負荷が軽減される。
【0019】
請求項3の発明は、請求項1又は2記載の分散監視制御システムにおいて、前記各機能処理部は、前記監視制御対象から得られる状態量を第1の情報伝達路に送信するための第1の機能処理部と、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信するための第2の機能処理部と、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力するための第3の機能処理部と、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信するための第4の機能処理部と、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力するための第5の機能処理部と、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信するための第6の機能処理部と、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力すると共に、前記監視制御対象に対する運転操作を入力するための第7の機能処理部と、を含むことを特徴とする。請求項17の発明は、請求項3の発明を方法という観点から把握したもので、請求項15又は16記載の分散監視制御方法において、前記各機能処理部のうち、第1の機能処理部が、前記監視制御対象から得られる状態量を第1の情報伝達路に送信するためのステップと、第2の機能処理部が、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信するためのステップと、第3の機能処理部が、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力するためのステップと、第4の機能処理部が、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信するためのステップと、第5の機能処理部が、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力するためのステップと、第6の機能処理部が、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信するためのステップと、第7の機能処理部が、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力すると共に、前記監視制御対象に対する運転操作を入力するステップと、を含むことを特徴とする。請求項24の発明は、請求項3,17の発明を、コンピュータのソフトウェアを記録したコンピュータ読み取り可能な記録媒体という観点から把握したもので、請求項23記載の分散監視制御用ソフトウェアを記録した記録媒体において、前記ソフトウェアは前記コンピュータに、前記各機能処理部のうち、第1の機能処理部に、前記監視制御対象から得られる状態量を第1の情報伝達路に送信させ、第2の機能処理部に、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信させ、第3の機能処理部に、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力させ、第4の機能処理部に、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信させ、第5の機能処理部に、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力させ、第6の機能処理部に、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信させ、第7の機能処理部に、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力させると共に、前記監視制御対象に対する運転操作の入力を受け付けさせることを特徴とする。請求項3,17,24の発明では、第1の情報伝達路は状態量やその変動通知など定常的情報、第2の情報伝達路は警報に関する情報、第3の情報伝達路は履歴に関する情報のやりとりに使い分ける。このような使い分けにより、各機能処理部は、該当する情報伝達路に接続するだけで、自ら担当する処理に必要な情報だけを容易に送受信することができる。また、前記のような使い分けにより、一部の情報伝達路や機能処理部に障害が起きた場合でも、それ以外の情報については他の情報伝達路でやり取りを続けることができるので、影響を最小限に抑制することができる。なお、分散監視制御システムの具体例としては次のようなものが考えられる。例えば、プラント各部に分散配置した制御装置と、1つ又は複数の監視サーバ装置と、監視部門ごとの監視クライアント装置と、で分散監視制御システムを構成する。そして、まず、制御装置には、第1から第4の機能処理部を設け、状態量とその変動の送信や状態量の最新値の蓄積、状態量や運転操作の監視制御対象への出力など、監視制御対象寄りの処理を担当させる。また、監視クライアント装置には、監視者とのやり取りを担当させ、具体的には、警報を扱う第5の機能処理部や、監視者との間で情報出力や運転操作を扱う第7の機能処理部を設け、必要ならば状態量の最新値を蓄積する第4の機能処理部を制御装置と同様に設ける。また、このような監視クライアント装置からの履歴照会に応じさせるため、監視サーバ装置には、履歴を扱う第6の機能処理部を設ける。
【0020】
請求項4の発明は、請求項3記載の分散監視制御システムにおいて、前記各機能処理部は、当該機能処理部の稼動状況を判断して第4の情報伝達路に出力するための構成制御手段を備え、前記各装置は、各装置又は各機能処理部のうち少なくとも一方に関する稼動状態を予め決められた情報伝達路に送信するための構成処理部を備えたことを特徴とする。請求項18の発明は、請求項4の発明を方法という観点から把握したもので、請求項17記載の分散監視制御方法において、前記各機能処理部が、当該機能処理部の稼動状況を判断して第4の情報伝達路に出力するための構成制御ステップと、前記各装置が、各装置又は各機能処理部のうち少なくとも一方に関する稼動状態を予め決められた情報伝達路に送信するための構成処理ステップと、を含むことを特徴とする。請求項4,18の発明では、各機能処理部が構成制御手段などにより、自己診断といった手法で判断した稼動状況を、第1から第3の情報伝達路とは異なる第4の情報伝達路に送信する。このため、本来の監視や制御に必要な情報のやり取りと、各機能処理部の稼動状態に関する情報のやり取りが相互に独立し、一方に障害があっても他方に波及しないので、システム全体の信頼性が向上する。また、各装置上の構成処理部などが、当該装置全体の稼動状態や個々の機能処理部の稼動状況を把握して他の装置へ通知したり、各装置が他の装置上の機能処理部の稼動状況を第4の情報伝達路を通じて把握することが容易になるのでシステム全体の運用が容易になる。なお、構成処理部は機能処理部の一種として構成することができる。
【0022】
請求項の発明は、請求項1からのいずれか1つに記載の分散監視制御システムにおいて、少なくとも1つの前記装置は、前記各機能処理部から参照されるための共有メモリを備え、前記情報伝達路に係るメッセージについて、前記共有メモリに格納するとともに、そのメッセージを受信すべき全ての機能処理部からの参照を受けたときに廃棄することを特徴とする。請求項19の発明は、請求項の発明を方法という観点から把握したもので、請求項15から18のいずれか1つに記載の分散監視制御方法において、少なくとも1つの前記装置において、前記各機能処理部から参照されるための共有メモリを用い、前記情報伝達路に係るメッセージについて、前記共有メモリに格納するためのステップと、前記共有メモリに格納された各メッセージを、そのメッセージを受信すべき全ての機能処理部からの参照を受けたときに廃棄するためのステップと、を含むことを特徴とする。請求項5,19の発明では、複数の機能処理部によって受信されるメッセージも、機能処理部ごとに重複格納されず、各機能処理部から参照される共有メモリに格納されるので、記憶領域が有効活用される。また、共有メモリに格納されたメッセージは、そのメッセージを受信すべき全ての機能処理部からの参照を受けた後で廃棄されるので、そのメッセージを必要とする全ての機能処理部に確実に渡される。この結果、特に、分散監視制御システムに含まれる各機能処理部間において大量のメッセージが発生したとしても、必要最低限の物理的メモリしか消費しないので、残メモリを活かした良好な性能を得ることが可能となる。
【0023】
請求項の発明は、請求項1からのいずれか1つに記載の分散監視制御システムにおいて、前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部が、前記配信処理部との受け渡しを前記各機能処理部を代表して行うと共に、他の前記各機能処理部に対して受け渡しするように構成され、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせるための手段を備えたことを特徴とする。請求項20の発明は、請求項の発明を方法という観点から把握したもので、請求項15から19のいずれか1つに記載の分散監視制御方法において、前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部が、前記配信処理部との受け渡しを前記各機能処理部を代表して行うと共に、他の前記各機能処理部に対して受け渡しするためのステップと、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせるためのステップと、を含むことを特徴とする。請求項25の発明は、請求項6,20の発明を、コンピュータのソフトウェアを記録したコンピュータ読み取り可能な記録媒体という観点から把握したもので、請求項25又は26記載の分散監視制御用ソフトウェアを記録した記録媒体において、前記ソフトウェアは前記コンピュータに、前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部に、前記配信処理部との受け渡しを前記各機能処理部を代表して行わせると共に、他の前記各機能処理部に対して受け渡しさせ、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせることを特徴とする。請求項6,20,25の発明では、各機能処理部を代表して送受信データを配信処理部との間で仲介していた代表機能処理部に障害が発生しても、その役割を他の機能処理部が引き継ぐ。これにより障害の影響が他の機能処理部に及ぶことがなく、連鎖的な機能喪失が防止できるので、装置全体の可用性(availability)が向上する。
【0024】
請求項の発明は、請求項4からのいずれか1つに記載の分散監視制御システムにおいて、前記構成処理部は、障害が発生した機能処理部を他の機能処理部に対して知らせるように構成され、前記各機能処理部は、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択するように構成されたことを特徴とする。請求項21の発明は、請求項の発明を方法という観点から把握したもので、請求項15から20のいずれか1つに記載の分散監視制御方法において、障害が発生した機能処理部を他の機能処理部に対して知らせるためのステップと、前記各機能処理部が、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択するためのステップと、を含むことを特徴とする。請求項26の発明は、請求項7,21の発明を、コンピュータのソフトウェアを記録したコンピュータ読み取り可能な記録媒体という観点から把握したもので、請求項23から25のいずれか1つに記載の分散監視制御用ソフトウェアを記録した記録媒体において、前記ソフトウェアは前記コンピュータに、障害が発生した機能処理部を他の機能処理部に対して通知させ、前記各機能処理部には、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択させることを特徴とする。請求項7,21,26の発明では、機能処理部で障害が発生したとき、他の各機能処理部は、障害の内容や、障害が発生した機能処理部への依存度に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止といった対応が可能となるので、障害の波及範囲が限定され、分散監視制御システムの可用性が向上する。例えば、障害が発生した機能処理部が発するメッセージを必要とする機能処理部は、自発的に機能停止するなどが考えられる。
【0025】
請求項の発明は、請求項1からのいずれか1つに記載の分散監視制御システムにおいて、前記配信登録手段は、各機能処理部が受信するメッセージのカテゴリを予め前記配信データベースに登録するように構成され、前記配信制御手段は、送信メッセージにカテゴリを設定し、受信メッセージはその受信メッセージに設定されているカテゴリに対応する各機能処理部にのみ配信するように構成されたことを特徴とする。請求項の発明では、各機能処理部について受信対象とするメッセージのカテゴリを予め登録しておき、受信側で受信された各メッセージは、送出側でそのメッセージに設定されたカテゴリに対応する機能処理部にのみ配信される。これにより、各機能処理部が関係するメッセージだけを選択的に受信すること、すなわちメッセージ受信のフィルタリングが容易に実現される。このため、機能処理部が受信対象としていた情報伝達路において、例えば何らかの機能拡張を意図した新たなカテゴリのメッセージが送受信対象に追加されたような場合においても、このように追加されたメッセージを必要としない各機能処理部については、カテゴリを違えておくことで影響を避け、それ以前と同様に動作を継続することが出来る。なお、このようなカテゴリは、1つの情報伝達路だけに適用してもよいし、複数又は全ての情報伝達路に適用してもよい。
【0026】
請求項の発明は、請求項1からのいずれか1つに記載の分散監視制御システムにおいて、前記各装置の前記各配信処理部は、各装置においてどの情報伝達路にどの機能処理部が対応付けられているかを表す接続状況を交換することにより、分散監視制御システム全体における接続状況を作成し、前記システム全体における接続状況に基づいて、メッセージを送信しようとする情報伝達路からメッセージを受信する機能処理部が分散監視制御システム内に存在するかどうかを判断し、メッセージを送信しようとする情報伝達路からメッセージを受信する機能処理部が分散監視制御システム内に存在しない場合は、当該メッセージを情報伝達路に送出しないように構成されたことを特徴とする。請求項の発明では、受信する機能処理部が存在しない情報伝達路へはメッセージを送出しないことで、不要な伝送を削減し、ネットワークが持つ帯域幅を最大限生かした分散監視制御システムの運用が可能となる。
【0027】
請求項10の発明は、請求項1からのいずれか1つに記載の分散監視制御システムにおいて、複数の系統に冗長化された情報伝達路を備え、前記各装置の各配信処理部は、同一の情報伝達路の複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加し、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信するように構成されたことを特徴とする。請求項22の発明は、請求項10の発明を方法という観点から把握したもので、請求項15から21のいずれか1つに記載の分散監視制御方法において、複数の系統に冗長化された情報伝達路を用い、前記各装置の各配信処理部が、同一の情報伝達路の複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加するためのステップと、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信するためのステップと、を含むことを特徴とする。請求項27の発明は、請求項10,22の発明を、コンピュータのソフトウェアを記録したコンピュータ読み取り可能な記録媒体という観点から把握したもので、請求項23から26のいずれか1つに記載の分散監視制御用ソフトウェアを記録した記録媒体において、前記ソフトウェアは前記コンピュータに、前記各装置の各配信処理部が、同一の情報伝達路について冗長化された複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加させ、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信させることを特徴とする。請求項10,22,27の発明では、多重化された情報伝達路の各系統に同一のメッセージを送信するとき、送信元と、系統ごとに例えばメッセージ送出の都度増加する一連番号のような識別情報を付加する。そして、受信側の代表機能処理部などが配信処理部を介してメッセージを受信する場合、同じ送信元及び識別情報のメッセージは、先着優先で受信し、後着は廃棄する。このようにすれば、情報伝達路を物理的に冗長化することで信頼性が向上し、情報伝達路を通過する時点でコリージョン等による消滅やそれによる欠落部分の再送が減少し、ネットワークが持つ帯域幅を最大限生かした運転操作が行える様になる。
【0028】
請求項11の発明は、請求項4から10のいずれか1つに記載の分散監視制御システムにおいて、装置上の機能処理部が、他の機能処理部で発生した障害に基づいて停止した結果、前記装置上で配信処理部と構成処理部のみが稼動しており、機能処理部が稼動していない状態となった場合に、当該装置をリセットするための手段を備えたことを特徴とする。請求項11の発明では、障害の影響が大きく配信処理部と構成処理部しか稼動していない状態となった装置については、本来の監視及び制御に対する貢献がなくなることから自動的にリセットし、所定の機能処理部を再起動することで機能の早期復旧を図りシステム全体の可用性を向上させる事が出来る。特に、機能障害の発生を装置内の各機能処理部に対して情報伝達路を介して通知し、各機能処理部ごとに対応を独自に判断させ、その結果に基づいて装置単位のリセットの判断をすることで、構成処理部は、全体への影響度を判断するための知識などを予め持っていることが不要となる。
【0029】
請求項12の発明は、請求項1から11のいずれか1つに記載の分散監視制御システムにおいて、同じ機能を果たす複数の機能処理部が、互いに異なった装置上に設けられ、そのうち1つが実際に前記機能を果たす常用系となり、他が、前記常用系の障害時に代替するための待機系となるように構成され、前記複数の機能処理部のうち、各装置のハードウェア各部について検出された状態から予め決められた基準で計算された各装置ごとの健全度が、最高の装置上の機能処理部が常用系となるように構成されたことを特徴とする。請求項12の発明によれば、同じ機能を果たすことができる機能処理部を持つ装置が複数存在する場合、健全度の最も高い装置上の機能処理部が常用系となることで、システム全体の可用性を向上させることができる。特に、常用系となっていた機能処理部が障害を発生した場合でも、待機系である各機能処理部のうち健全度が最高の装置上のものが取って代わることにより、分散監視制御システムの安定運用が可能となる。
【0030】
請求項13の発明は、請求項1から12のいずれか1つに記載の分散監視制御システムにおいて、情報伝達路から受信すべきメッセージの欠落分の検出と、そのメッセージの送出側に対する再送要求とを行うように構成されたことを特徴とする。請求項13の発明では、送信元毎の最新メッセージの一連番号を順次データベースに登録し、その後届いたメッセージの送信元や一連番号と照合するなどして、メッセージの欠落を検出すると送出側に欠落分の再送を要求する。これにより、装置を接続する情報伝達路の性質、或いはメッセージ受信を行う代表機能処理部の障害などによって、受信されるべきメッセージが欠落した場合でも、欠落部分が復旧され、通信の信頼性が維持される。特に、メッセージの受信に関わる配信処理部や機能処理部の判断で、メッセージの欠落がどの情報伝達路で発生したかに応じて異なった適切な復旧手順をとることが望ましい。
【0031】
請求項14の発明は、請求項3から13のいずれか1つに記載の分散監視制御システムにおいて、前記第7の機能処理部は、第6の機能処理部が蓄積した履歴を、指定された期間内の最大値と最小値を予め決められた形式で示すグラフとして表示するように構成されたことを特徴とする。請求項14の発明では、監視サーバ装置などから提供される状態量などの履歴をグラフ表示する際、指定された期間内の最大値と最小値を予め決められた形式で示すことにより、履歴の理解を容易にすることができる。
【0032】
【発明の実施の形態】
以下、本発明の複数の実施の形態(以下「実施形態」という)について図面を参照しながら説明する。なお、本発明や実施形態は、周辺装置を持つコンピュータをソフトウェアで制御することで実現されることが一般的と考えられる。
【0033】
この場合のソフトウェアは、この明細書に記載された動作を実現するためのプログラムコードと必要なデータとを含み、上記従来技術と共通の部分には従来技術で説明した手法も使われる。また、そのソフトウェアは、コンピュータを構成するCPUなどの処理装置、メインメモリやHDDといった記憶装置、キーボードやマウスといった入力装置、ディスプレイやプリンタといった出力装置などの物理的資源を活用することで本発明や実施形態の作用効果を実現する。
【0034】
但し、本発明や実施形態を実現するための具体的なソフトウェアやハードウェアの構成は各種考えられる。例えば、プログラミングに使うOS・形式・手法・言語は多様であり、上記のようなソフトウェアを記録したCD−ROMのような記録媒体は単独でも本発明の一態様である。
【0035】
また、本発明や実施形態の機能の一部をLSIなどの物理的な電子回路で実現することも考えられる。以上のように、コンピュータを使って本発明や実施形態を実現する具体的態様は各種考えられるので、以下では、本発明や実施形態に含まれる個々の機能を実現する仮想的回路ブロックを使って、本発明と実施形態とを説明する。
【0036】
なお、各図において、それ以前に登場又は説明した部材と同一又は同種の部材については同じ符号を付け、説明は省略する。また、手順のステップ番号と実行順序は無関係である。
【0037】
〔1.第1実施形態〕
第1実施形態は、互いにネットワークで接続された複数の装置間で通信を行うことで、監視制御対象であるプラントを監視及び制御するための分散監視制御システムであり、請求項1〜5,16〜20,25,26に対応するものである。
【0038】
具体的には、前記ネットワークは複数の情報伝達路を備え、前記各装置は、データの種類ごとに予め定められた複数の情報伝達路に他の機能処理部から送出されるデータのうち、動作上必要とする情報伝達路からのデータを受信するとともに、処理結果を所定の情報伝達路に再び送出する事により、互いに協調動作するものである。
【0039】
〔1−1.第1実施形態の構成〕
〔1−1−1.全体構成〕
まず、図1は、第1実施形態の構成を示す機能ブロック図である。第1実施形態は、この図に示すように、制御装置Pと、監視クライアント装置Cと、監視サーバ装置Sと、を通信ネットワーク3で接続したものである。なお、制御装置Pと、監視クライアント装置Cと、監視サーバ装置Sと、を「装置」(P,C,S)と総称する。また、図1は、単純化した例として、制御装置Pと、監視クライアント装置Cと、監視サーバ装置Sとをそれぞれ1つずつ示しているが、これらはそれぞれプラントや分散監視制御システムの構成に応じて複数存在するものである。
【0040】
具体的には、この分散監視制御システムは、プラント各部に分散配置した制御装置Pと、1つ又は複数の監視サーバ装置Sと、監視部門ごとの監視クライアント装置Cと、を備えている。そして、まず、制御装置Pに設けた機能処理部で、状態量とその変動の送信や状態量の最新値の蓄積、状態量や運転操作の監視制御対象への出力など、監視制御対象寄りの処理を担当する。
【0041】
また、監視クライアント装置Cは、監視者とのやり取りを担当し、具体的には、警報を扱う機能処理部や、監視者との間で情報出力や運転操作を扱う機能処理部を設け、状態量の最新値を蓄積する機能処理部も制御装置Pと同様に設ける。また、このような監視クライアント装置Cからの履歴照会に応じるため、監視サーバ装置Sには、履歴を扱う機能処理部を設ける。また、いずれの装置P,C,Sにも、通信のための配信処理部と、稼動状態に関する処理を行う構成処理部を設ける。
【0042】
つまり制御装置Pは、監視制御対象である図示しないプラントの各部分について、状態量の入力や制御量の出力といった入出力を行うための装置である。また、監視クライアント装置Cは、クライアントとして、監視サーバ装置Sによるデータ提供などのサービスを利用しながら、プラントの監視制御のための処理を行うための装置である。また、監視サーバ装置Sは、プラントの監視制御のためのサービスを、各監視クライアント装置Cに対してサーバとして提供するための装置である。
【0043】
〔1−1−2.情報伝達路と配信処理部の構成〕
また、通信ネットワーク3は、4つの情報伝達路TAG,ALM,HSD,RASを備えている。このうち第1の情報伝達路TAGは、計測された状態量など定常的なデータをやり取りするための情報伝達路であり、定常用伝達路TAGとも呼ぶこととする。また、第2の情報伝達路ALMは、警報関係のデータをやり取りするための情報伝達路であり、警報用伝達路ALMとも呼ぶこととする。
【0044】
また、第3の情報伝達路HSDは、サーバに蓄積された状態量の履歴など、サーバ・クライアント間のデータをやり取りするための履歴用の情報伝達路であり、履歴用伝達路HSDとも呼ぶこととする。また、第4の情報伝達路RASは、第1実施形態の分散監視制御システムを構成する各装置や、各装置を構成する各機能処理部の稼動状態に関するデータをやり取りするための情報伝達路であり、構成用伝達路RASとも呼ぶこととする。
【0045】
また、各装置P,C,Sの構成のうち、どの装置でも共通であるのは通信に関する構成であり、具体的には、伝送装置2と、配信処理部18である。
【0046】
このうち各伝送装置2は、通信ネットワーク3に含まれる4つの情報伝達路TAG,ALM,HSD,RASのうち所望の情報伝達路との間で情報伝送を行うための装置であり、具体的にはネットワークカードなどから構成される。また、各配信処理部18は、伝送装置2を介して、個々の情報伝達路TAG,ALM,HSD,RASと、それらに対応付けられた各機能処理部との間でメッセージのやり取りを仲介するための部分である。
【0047】
具体的には、各配信処理部18は、情報伝達路と機能処理部との対応関係を登録するための配信データベース18aと、対応関係をデータベース18aに登録するための配信登録手段18bと、登録された対応関係に基づいて、通信を制御するための配信制御手段18cと、を備えている。
【0048】
すなわち、各情報伝達路TAG,ALM,HSD,RASは、伝送装置2及び配信処理部18を介してデータの送受信を行うもので、以下、各機能処理部によるデータ送受信の対象として単に情報伝達路というときは、伝送装置2及び配信処理部18を介することが前提であるものとする。
【0049】
また、構成処理部17は、各装置の稼動状態を他の装置に知らせるための部分であり、各装置ごとのハードウェアなどの正常異常といった稼動状態を判断したり、同じ装置内の各機能処理部から構成用伝達路RASに送信される稼動状態を監視し、検出した異常を定常用伝達路TAGに出力するように構成されている。
【0050】
また、監視及び制御に関する処理を行うための各機能処理部については、装置ごとにどのような機能処理部が設けられているかが異なり、以下に各装置ごとに説明する。
【0051】
〔1−1−3.制御装置の構成〕
まず、制御装置Pは、伝送装置2、配信処理部18、構成処理部17の他に、機能処理部として、入力処理部4と、計算処理部5と、出力処理部6と、データベース処理部7と、を備えている。
【0052】
このうち入力処理部4は、監視制御対象から得られる状態量を定常用伝達路TAGに送信するための第1の機能処理部である。具体的には、第1実施形態における入力処理部4は、監視制御対象とするプラントに設けた計測点からプロセス入出力装置1を通じて状態量を入力すると共に、その状態量について、通信トラフィック節約のために、前回定常用伝達路TAGに送出した時の状態量と予め定めた値以上の偏差がある場合、定常用伝達路TAGに対して通知メッセージNMを送出するように構成されている。
【0053】
また、プロセス入出力装置1は、入力処理部4及び出力処理部6からの指令にしたがって、監視制御対象とするプラントに設けた計測点からの状態量の入力や、決定された制御量などをプラント各部に出力するといった入出力を行うための手段である。
【0054】
また、計算処理部5は、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を定常用伝達路TAGに送信するための第2の機能処理部であり、入力処理部4が定常用伝達路TAGに出力する状態量に基づいて、予め用意した数値・論理演算式により計算値を求めると共に、前回定常用伝達路TAGに送出した時の計算値と予め定めた値以上の偏差がある場合に、そのことを知らせるための通知メッセージNMを定常用伝達路TAGに対して送出するように構成されている。
【0055】
また、出力処理部6は、入力処理部4や計算処理部5が定常用伝達路TAGに出力する通知メッセージNMに含まれる状態量の値を、監視・制御盤上の表示器、或いはプロセスに対して、プロセス入出力装置1を介して出力するための第3の機能処理部である。
【0056】
また、データベース処理部7は、定常用伝達路TAGに送信された情報の少なくとも一部について、最新の値を蓄積するとともに問合せに対して定常用伝達路TAGに送信するための第4の機能処理部である。具体的には、このデータベース処理部7は、入力処理部4や計算処理部5が定常用伝達路TAGに送出した通知メッセージNMに含まれる状態量のうち、監視点として予め設定された値でデータベース8を更新するように構成されている。
【0057】
また、このデータベース処理部7は、定常用伝達路TAGを介した状態量の問合せメッセージQMに対しては、データベース8に格納されている状態値の最新値を応答メッセージRMとして定常用伝達路TAGに再出力するように構成されている。
【0058】
〔1−1−4.監視装置の構成〕
また、監視クライアント装置C及び監視サーバ装置Sをまとめて監視装置と呼ぶが、このうち監視クライアント装置Cは、制御装置Pと同様に、伝送装置2と、配信処理部18と、構成処理部17と、データベース処理部7と、を備えている他、対話処理部16と、警報処理部9と、を備えている。また、監視サーバ装置Sは、制御装置Pと同様に、伝送装置2と、配信処理部18と、構成処理部17と、を備えている他、履歴処理部11を備えている。
【0059】
このうち警報処理部9は、前記状態量に基づく警報に関する情報を警報用伝達路ALMに出力するための第5の機能処理部である。具体的には、この警報処理部9は、次のような警報に関する処理を行うように構成されている。すなわち、この警報処理部9は、定常用伝達路TAGに出力される監視点の状態量と予め用意した設定値との比較により警報状態すなわち警報を出すべき数値変化が検出されたかどうかを判断し、新しく警報を出すべきと判断されたような場合は、検出時刻を警報リスト10として記憶・管理し、警報リスト10の変化分を通信ネットワーク3の警報用伝達路ALMに通知メッセージNMとして送出すると共に、警報用伝達路ALMを介した警報状態の問合せメッセージQMに対しては、警報リスト10を応答メッセージRMとして再出力するように構成されている。
【0060】
また、履歴処理部11は、前記状態量の履歴を蓄積し及び少なくとも問合せに対して履歴用伝達路HSDに送信するための第6の機能処理部である。具体的には、この履歴処理部11は、定常用伝達路TAGを通じ、制御装置Pや監視クライアント装置Cのデータベース処理部7に監視点の状態量の問合せメッセージQMを定期的に出力し、これに対する応答として獲得した応答メッセージRMを履歴データ12として一定期間蓄積すると共に、履歴用伝達路HSDを介した履歴データの問合せメッセージQMに対しては、指定された期間と監視点に関する状態量の変化を応答メッセージRMとして出力するように構成されている。
【0061】
また、対話処理部16は、状態量の最新の値や前記履歴、前記警報に関する情報のうち少なくとも1つを出力すると共に、前記監視制御対象に対する運転操作を入力するための第7の機能処理部である。具体的には、この対話処理部16は、データベース処理部7がデータベース8の更新によって提供する監視点の状態量、警報処理部9が出力する警報リスト10、履歴処理部11が蓄積する履歴データ12を、通信ネットワーク3の情報伝達路に問合せメッセージQMを出力して獲得し、対話装置13を構成する表示装置14に表示すると共に、対話装置13の入力装置14を介した対話による運転操作を情報伝達路TAGを介して出力処理部6に出力するように構成されている。
【0062】
ここで、対話装置13は、制御盤やコンピュータコンソールなど対話的情報入出力を行うための装置であり、対話装置13を構成する表示装置14としてはCRTや液晶表示装置などが考えられ、また、対話装置13を構成する入力装置15としてはマウスやキーボードなどが考えられる。
【0063】
〔1−1−5.稼動状態に関する構成〕
また、各機能処理部は、当該機能処理部の稼動状況を判断して定期的に構成用伝達路RASに出力するための構成制御手段を備えている。例えば、警報処理部9は、警報処理手段9aと構成制御手段9bを備え、このうち警報処理手段9aは、上記のような警報に関する処理を行うための部分であり、一方、構成制御手段9bは、警報処理部9の稼動状況を判断して構成用伝達路RASに出力するための部分である。
【0064】
なお、構成制御手段は各機能処理部に応じて構成すればよく、例えば、入力処理部4の構成制御手段4bは、入力処理手段4aが定常用伝達路TAGに対して状態量を出力するために接続するたびに起動し自己診断によって入力処理部4の稼動状況を得ることで、入力処理部4の稼動状況を通知メッセージNMとして定期的に構成用伝達路RASに対して出力するように構成することが考えられる。
【0065】
また、各装置上の構成処理部17は、各機能処理部を起動すると共に、起動した各機能処理部から定期的に情報伝達路RASに通知メッセージNMとして出力される稼動状態と、各機能処理部が実装されている制御装置、監視装置等の装置の稼動状態を監視し、検出した異常を情報伝達路TAGに出力するための手段である。
【0066】
〔1−1−6.代表機能処理部〕
また、第1実施形態における各装置は、ネットワーク機器すなわちネットワーク3及び伝送装置2と同様の動作を行うソフトウェアバスを備え、各情報伝達路と接続された各機能処理部のうち1つが、代表してその情報伝達路や配信処理部18と送受信データを直接やり取りするとともに、その情報伝達路と接続された他の各機能処理部にはその複製を前記ソフトウェアバスを経て渡すように構成されている。また、実装上は、配信処理部18を代表機能処理部の一部として構成してもよい。
【0067】
ここで、ソフトウェアバスとしては、例えば分散アーキテクチャを規定するCORBA (Common Object Request Broker Architecture )によるものを用いることが考えられ、このバスを通して、各種のオブジェクトが各種のオペレーティング・システム上で動作したり、互いに協力して動作することが容易になる。
【0068】
〔1−1−7.配信データベースの構成〕
次に、図2は、第1実施形態において、配信処理部18及び各情報伝達路TAG,ALM,HSD,RASを経て各機能処理部間でやりとり、すなわち配信されるメッセージの構成例を示す図であり、図3は、このようなメッセージの配信に使われる配信データベース18aの構成例を示す図である。まず、図2に示すメッセージの例は、メッセージの発信日時を示すタイムスタンプと、発信元と、発信元が情報伝達路毎に独立して管理する発信メッセージの一連番号と、メッセージの種類を示すカテゴリと、本文となるメッセージデータと、を含んでいる。
【0069】
また、図3に示す配信データベースの例は、各情報伝達路と各機能処理部に先頭と末尾を用意した二重連結リストの構造により、各情報伝達路と各機能処理部について、相互に対応付けると共に、受信バッファの役割を果たすメッセージキューとも対応づけるものである。なお、機能処理部を単に「機能」とも呼ぶ。
【0070】
すなわち、情報伝達路と機能とはそれぞれ複数存在するが、ある1つの情報伝達路についてみれば、1つ又は複数の機能が送受信するメッセージを伝達し、また、ある1つの機能についてみれば、1つ又は複数の情報伝達路についてメッセージを送受信する。このような対応関係は、「1つ又は複数」というように要素の数が変化するデータであり、このような対応関係をどの情報伝達路からでも、どの機能からでも、どの対応関係からでも、リンクを辿って検索し、かつ、どの部分からでもその追加や削除といった変更を効率よく行えるように、二重連結リストの構造をとったものである。
【0071】
具体的には、この配信データベースは、1つ以上のブロックBと、伝達路リストRLと、機能リストFLと、メッセージキューQ又はメッセージキューを指す指標と、を備えている。このうちブロックBは、1つの情報伝達路と1つの機能処理部とを対応付けるもので、メモリブロックとも呼ぶ。また、伝達路リストRLは、各情報伝達路ごとに対応する少なくとも1つのブロックBを指すポインタを、各情報伝達路#1〜#nについてリストしたものである。また、機能リストFLは、各機能処理部ごとに対応する少なくとも1つのブロックを指すポインタを、各機能#1〜#mについてリストしたものである。また、メッセージキューQは、各機能処理部宛てのメッセージが格納される格納領域である。
【0072】
このうち伝達路リストRLは、個々の情報伝達路#1〜#nごとのレコードを持ち、各レコードごとのフィールドは、その情報伝達路に対応する先頭のブロックを指すポインタと、末尾のブロックを指すポインタと、その情報伝達路を使う機能の数(接続数と呼ぶ)と、をそれぞれ格納する。このような各レコードに対応する#1〜#nの情報伝達路番号は、図3のブロック中では「伝達路No.」と表すが、マルチキャストIPアドレスと直接的に対応付けられているものである。
【0073】
また、機能リストは、個々の機能#1〜#mごとのレコードを持ち、各レコードごとのフィールドは、その機能に対応する先頭のブロックを指すポインタと、末尾のブロックを指すポインタと、をそれぞれ格納する。このような各レコードに対応する#1〜#mの機能番号は、図3のブロック中では「機能No.」と表すが、IPポート番号と直接的に対応するものである。
【0074】
また、各ブロックは、情報伝達路と機能とを対応づけるレコードであり、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンク(伝達路リンクとも呼ぶ)と、同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンク(機能リンクとも呼ぶ)と、を持つ。
【0075】
すなわち、伝達路リンクは、図3では各ブロックの上方に示すように、そのブロックと、同じ伝達路に関する他のブロックとを前後に接続しているポインタで、このリンクを辿ることで同じ伝達路を他の機能処理部に対応付けている他のブロックを検索することが可能となる情報である。各ブロックのこのような伝達路リンクは、情報伝達路番号(伝達路No.)に対応して、前方のブロックを指すポインタと、後方のブロックを指すポインタを格納する各フィールドを持つ。
【0076】
また、機能リンクは、各ブロックと、同じ機能に関する他のブロックとを前後に接続しているポインタであり、このリンクを辿ることで同じ機能に関する他のブロックを検索することが可能となる情報である。この機能リンクは、各機能番号(機能No.)に対応して、前方のブロックを指すポインタと、後方のブロックを指すポインタを格納する各フィールドを持つ。
【0077】
なお、ポインタの指す前方や後方といった方向と、伝達路リストや機能リストで使われる先頭や末尾といった方向は一致している必要はなく、一定の規則性に基づいて前後を辿ることにより、ブロックを並べた列の一方の終端から他方の終端まで行き着ければ十分である。このため、図3の例は、例えば、ある情報伝達路について、「先頭」の指すブロックから「前方」を辿るとその情報伝達路の「末尾」に行き着くように構成されており、機能処理部についても同様である。
【0078】
また、伝達路リスト及び機能リストからブロックにリンクする「先頭」と「末尾」の各ポインタは、それぞれ、伝達路リンク及び機能リンクに含めて呼ぶこととする。
【0079】
また、以上のような情報伝達路と機能との交点に関しては、メッセージキューを示す指標を用意しておく。なお、より具体的には、ここでいう交点とはブロックで表され、各ブロックに、又は同じ機能に対応する少なくとも1つのブロックに、その機能宛てのメッセージを格納するためのメッセージキューを指すインデックス、ポインタ、オフセットなどを格納しておけばよい。第1実施形態では、メッセージキューを示す指標としては、各メッセージキュー固有のキュー識別番号を用いるものとする。
【0080】
上記のような配信データベースを用いる場合、情報伝達路側からメッセージを受信した場合は、まず、情報伝達路リストを参照して、その情報伝達路に対応する先頭又は末尾のブロックを指すポインタを取り出す。このポインタの表すリンクの先にあるブロックを参照すれば、その情報伝達路を利用する機能を1つ知ることができ、さらに、そのブロックのうち伝達路に関する部分にある前方や後方のポインタを辿れば、同じ伝達路を使う他の機能を順次特定することができる。そして、受信したメッセージを、該当する各々のメッセージキューに蓄積すればよい。
【0081】
一方、各機能の側では、機能リストを参照することで、この二重連結リストの先頭、末尾と共に記憶しているメッセージキューを示す指標を用いて、自分のために蓄積されたメッセージをそのメッセージキューから順次取り出すことができる。
【0082】
そして、配信処理部18の配信制御手段18cは、各機能処理部から情報伝達路に対する送受信要求を受けると、例えば、送信データについては、伝送装置2を介して通信ネットワーク3の情報伝達路に送信するとともに、配信データベースの内容に従って、同じ装置内でその情報伝達路についてデータの受信を要求している機能に対応するメッセージキューにも蓄積する。
【0083】
また、伝送装置2を介した通信ネットワーク3からの受信データについても、配信データベースの内容に従って、受信データとして、装置内でその情報伝達路からの受信を要求している機能に対応するメッセージキューに蓄積する。これにより、各機能処理部は、キューに蓄積されたメッセージを順次読み出すことで、選択した情報伝送路に同じ装置及び他の装置から送出されたメッセージを得ることができる。
【0084】
〔1−2.第1実施形態の作用〕
上記のように構成された第1実施形態は、次のように作用する。なお、第1実施形態における処理は、大まかに、
(1)監視と制御のための処理
(2)メッセージの配信に関する処理
に分けることができる。
【0085】
このうち監視と制御のための処理は、第1実施形態における分散監視制御システムの本来の用途すなわち監視制御対象であるプラントに対する監視と制御に直接関わる処理である。この処理は、各装置P,C,S上に分散配置された各機能処理部4〜7,9,11と、制御装置Pに設けられたプロセス入出力装置1及び監視クライアント装置Cに設けられた対話装置13によって実行される。
【0086】
また、メッセージの配信に関する処理は、各装置P,C,S上に分散配置された各機能処理部4〜7,9,11,17と、ネットワーク3に含まれる各情報伝達路TAG,ALM,HSD,RASとの間で、各種データを含むメッセージをやりとりするための処理であり、各装置上に設けられた配信処理部18によって実行される。
【0087】
〔1−2−1.監視と制御のための処理〕
〔1−2−1−1.状態量の変動に関する処理〕
監視と制御のための処理として、まず、プロセス入出力装置1が、プランとの各計測点に設けたセンサから得られる電気信号をディジタル化して入力処理部4に渡したり、出力処理部6から渡されるプロセス制御量などのディジタル量を電気信号化し、プラントのバルブなど該当部分に出力する処理が考えられる。なお、このようなプロセス入出力装置1を介したプロセス状態量の入力やプロセス制御量の出力は、数ミリ秒から数百ミリ秒間隔で行われる。
【0088】
そして、入力処理部4の入力処理手段4aは、構成処理部17から起動され、プロセス入出力装置1から入力された状態量を、各計測点毎に予め決められた計算手順にしたがって工学単位化し、このように得られた状態量の最新値について、前回定常用伝達路TAGに対して送出した時の状態量と予め定めた値以上の偏差があると、配信処理部18の配信制御手段18cを介して定常用伝達路TAGに対して、図2に示す形式のメッセージを通知メッセージNMとして送出する。
【0089】
また、計算処理部5の計算処理手段5aは、構成処理部17から起動され、入力処理部4の入力手段4aが定常用伝達路TAGに出力する状態量を受信し、このように得た状態量をもとに、予め用意した数値・論理演算式により所定の計算値を求めると共に、前回定常用伝達路TAGに送出した時の計算値と予め定めた値以上の偏差があった場合に入力処理部4の入力手段4aと同様に定常用伝達路TAGに対して、図2に示す形式のメッセージを通知メッセージNMとして送出する。
【0090】
出力処理部6の出力処理手段6aは、構成処理部17から起動され、入力処理部4の入力処理手段4aと、計算処理部5の計算処理手段5aと、構成処理部17と、が情報を出力する定常用伝達路TAGからデータを受信する。これにより、出力処理部6の出力処理手段6aは、状態量の変動など定常用伝達路TAGを流れるデータの内容のうち、監視・制御盤上の表示器に表示すべきデータをプロセス入出力装置1を介してそのような表示器に表示したり、プラントを構成するプロセスのうち所定の部分にフィードバックなどのために出力すべきデータを、プロセス入出力装置1を介して出力する。
【0091】
すなわち、各機能処理部による以上の処理によって、定常用伝達路TAGには、状態量の変動があるたびに、その内容を表すメッセージが流れると共に、その内容が、プラントにフィードバックされたり、監視・制御盤上の表示器に表示されることになる。
【0092】
〔1−2−1−2.データベースと履歴に関する処理〕
また、制御装置P及び監視クライアント装置Cに設けられたデータベース処理部7のDB処理手段7aは、構成処理部17から起動され、入力処理部4の入力処理手段4aと、計算処理部5の計算処理手段5aと、が情報を出力する定常用伝達路TAGを流れるデータを、配信処理部18の配信制御手段18cを介して受信する。これにより、データベース処理部7のDB処理手段7aは、監視対象となる状態量の最新値によってデータベース8に更新する。また、データベース処理部7のDB処理手段7aは、定常用伝達路TAGを介した状態量の問合せメッセージQMに対してデータベース8の状態量を応答メッセージRMとして再出力する。
【0093】
また、監視サーバ装置Sに設けられた履歴処理部11の履歴処理手段11aは、構成処理部17から起動され、制御装置Pや監視クライアント装置Cに設けられたデータベース8に格納された状態量の最新値について問合せを行い、その結果を履歴データ12として一定期間蓄積する。また、履歴処理手段11aは、情報伝達路HSDを介した履歴データの問合せメッセージQMに対しては、指定された期間と指定された監視点における状態量の変化を、応答メッセージRMとして配信処理部18の配信制御手段18cを介して出力する。
【0094】
以上のようなデータベース処理部7及び履歴処理部11による処理の結果、状態量の最新値と、過去一定期間の履歴は、どの装置上のどの機能処理部からでも、得られることになる。
【0095】
〔1−2−1−3.対話による運転操作に関する処理〕
本システムでは、対話処理部16や対話装置13を備えた監視クライアント装置Cにおいて、上記のように得られる各情報を利用しながらプラントの運転操作を行うことができるが、プラントの正常な機能を維持するのに特に役立つ処理は、警報処理部9による警報に関する処理である。
【0096】
すなわち、警報処理部9は、定常用伝達路TAGに出力される監視点の状態量と予め用意した設定値との比較により警報状態すなわち警報を出すべき数値変化が検出されたかどうかを判断する。そして、新しく警報を出すべきと判断されたような場合は、検出時刻を警報リスト10として記憶・管理し、警報リスト10の変化分を通信ネットワーク3の警報用伝達路ALMに通知メッセージNMとして送出すると共に、警報用伝達路ALMを介した警報状態の問合せメッセージQMに対しては、警報リスト10を応答メッセージRMとして再出力するように構成されている。
【0097】
そして、監視クライアント装置Cに設けられた対話処理部16の対話処理手段16aは、構成処理部17から起動され、上記のように発生する各種の情報を、対話装置13の表示装置14に出力する。すなわち、対話処理手段16aは、データベース処理部7がデータベース8の更新によって保持している監視点の状態量の最新値や、警報処理部9が提供する警報リスト10や、履歴処理部11が蓄積している履歴データ12を、配信処理部18の配信制御手段18cを介して定常用伝達路TAG、警報用伝達路ALM、履歴用伝達路HSDに、それぞれ問合せメッセージQMを出力することによって獲得する。
【0098】
そして、対話処理手段16aは、このように獲得した情報を、対話装置13を構成する表示装置14に表示することで監視部門の監視者といった担当者に提供すると共に、対話装置13の入力装置14を介した対話的入出力などにより、プラント各部に対する運転操作やその制御量を前記のような担当者から受け取り、その運転操作や制御量などの情報を、定常用伝達路TAGを介して、制御装置Pに設けられた出力処理部6の出力処理手段6aに出力する。
【0099】
以上のような警報処理部9、対話処理手段16aなどによる処理の結果、プラントに異常があればその旨の警報を発したり、担当者が必要な情報を本システム各部から取り寄せて判断し、その判断結果として運転操作などをプラントに対して反映させることができる。
【0100】
〔1−2−2.メッセージの配信に関する処理〕
また、上記のような各機能処理部同士のメッセージの伝達すなわち配信は、配信処理部18によって行われる。ここで、各装置の各機能処理部のうち、どの機能処理部がどの情報伝達路について接続されているか、すなわち送受信の対象とするかは、起動された各機能処理部から情報伝達路に対する最初の送信要求や受信要求を受けた場合などに、配信処理部18の配信登録手段18bによって予め配信データベース18aに登録され、メッセージの配信は、この配信データベース18aに基づいて、配信制御手段18cによって行われる。
【0101】
そして、ある装置のある機能処理部が配信処理部18に対して、対象となる情報伝達路を指定して渡したメッセージは、どの装置でも、その情報伝達路に接続されている全ての機能処理部に渡される。このため、ある装置のある機能処理部が配信処理部18に対して、対象となる情報伝達路を指定して渡したメッセージは、情報伝達路を経由して他の装置へ送信され、受信側の配信処理部18によって、その情報伝達路に接続されている各機能処理部に渡されるだけでなく、送信側の装置内でも、配信処理部18により、その情報伝達路に接続されている各機能処理部に対して、受信メッセージとして渡される。
【0102】
〔1−2−2−1.接続の登録と解除の全体的手順〕
このようなメッセージの配信に関する処理のうち、図4は、配信登録手段18bが予め、どの情報伝達路をどの機能処理部が送受信対象とするかという対応関係を、配信データベース18aに登録したり削除したりする処理手順を示すフローチャートであり、このような処理手順によって図2に示したような内容の配信データベース18aが生成される。なお、情報伝達路と機能処理部との「接続」は、両者の対応関係を登録することであり、そのような対応関係を削除する処理を「接続」の「解除」と呼ぶ。
【0103】
そして、図4の手順は、接続を登録する操作か解除する操作かの指定と、操作対象とする情報伝達路iと、機能処理部(機能と呼ぶ)jと、を指定して呼び出される。ここで、1つの機能処理部jに対して、操作対象とする情報伝達路iは複数指定することもできる。
【0104】
そして、呼び出された図4の手順では、接続を登録する登録操作の場合は(ステップ401)、機能処理部jについて送受信バッファとなるメッセージキューが生成済みであればステップ405に進むが(ステップ402)、生成済みでなければ、その機能処理部jについてメッセージキューを生成すると共に、キュー識別子を機能別ベクタに登録し(ステップ403)、機能別ベクタの先頭と末尾を0クリアする(ステップ404)。
【0105】
ここで、キュー識別子は、そのキューを指すポインタである。また、機能別ベクタは、図3に示した配信データベースの機能リストのうち、各機能処理部に対応する記憶領域であり、1つの機能別ベクタには、キュー識別子と、その機能処理部に対応する先頭のブロックを指すポインタと、その機能処理部に対応する末尾のブロックを指すポインタと、が格納される。また、ステップ404において、機能別ベクタの先頭と末尾を0クリアするのは、その機能処理部についてまだ情報伝達路が1つも登録されていない状態に初期化するためである。
【0106】
続いて、情報伝達路iと機能処理部jとを接続するが(ステップ405)、その具体的な処理手順は後に示す。そして、機能処理部jに接続する次の情報伝達路iが指定されているかを調べ(ステップ406)、指定された全ての情報伝達路iに対する接続要求を処理した状態になっていれば処理を終了し、そうでなければステップ405に戻る(ステップ407)。
【0107】
また、接続を解除する場合は(ステップ401)、まず、情報伝達路iと機能処理部jとの接続を解除するが(ステップ408)、その具体的な処理手順は後に示す。続いて、機能処理部jと接続解除する次の情報伝達路iが指定されているかを調べ(ステップ409)、指定された全ての情報伝達路iに対する解除要求を処理した状態になっていればステップ411に進むが、そうでなければステップ405に戻る(ステップ410)。
【0108】
ステップ411では、接続解除後の状態でもまだその機能処理部jが受信する情報伝達路が有れば、メッセージキューは削除しないまま処理を終了するが(ステップ411)、受信する情報伝達路がなければ、不要になったメッセージキューを削除し、機能処理部jの機能別ベクタのキュー識別子も0クリアして処理を終了する。
【0109】
〔1−2−2−2.接続の具体的手順〕
次に、ステップ405に示した、情報伝達路iと機能処理部jとを接続する具体的な手順を、図5のフローチャートに定義済処理(サブルーチン)の形式で示す。すなわち、この手順では、まず、接続の対象とする情報伝達路iに対応する先頭のブロックについてその位置を得る(ステップ501)。
【0110】
そして、ブロックに設定された情報伝達路に関する「前方」のリンクを(ステップ503)、リンク終端に達するまで辿る(ステップ502)。なお、この途中で、接続しようとしている機能処理部jと一致する機能番号すなわち機能No.があった場合は(ステップ503,504)、登録しようとしている情報伝達路iと機能処理部j との組合せは既に登録されているので、図4に示したメインルーチンに戻る。
【0111】
ステップ502でリンク終端に達すると、機能処理部j と情報伝達路iとの接続用メモリブロックを確保し、その機能リンクと伝達路リンクそれぞれの「前方」を0クリアする(ステップ505)。また、確保したメモリブロックに接続する情報伝達路iの伝送路番号と、機能処理部jの機能番号と、キュー識別番号と、を設定する(ステップ506)。続いて、確保したメモリブロックを、機能リンクに加入する処理(ステップ507〜511)と、伝達路リンクに加入する処理(ステップ512〜517)を行う。
【0112】
すなわち、まず、現在行っている接続が、機能処理部jの機能リンクにとって初回の登録の場合は(ステップ507)、機能処理部jの機能リストの「先頭」に、確保したメモリブロックの位置を設定することで(ステップ508)、確保したメモリブロックを機能処理部jの機能リストを構成する唯一のブロックとする。
【0113】
一方、現在行っている接続が、機能処理部jの機能リンクにとって初回の登録でない場合は(ステップ507)、機能処理部jの機能リストの「末尾」が指すメモリブロックの機能リンクの「前方」に、確保したメモリブロックの位置を設定することで、新しいメモリブロックを既存のブロック列の前方、すなわち末尾側に挿入する(ステップ509)。
【0114】
その後、それまでの機能リストの「末尾」が指していた内容を、確保したメモリブロックの機能リンクの「後方」として設定する(ステップ510)。これは、初回登録でない場合は、挿入した新しいメモリブロックの後方に、挿入で1つ後方にずれたブロックを機能リンクで接続することを意味し、初回登録の場合は、挿入した新しいメモリブロックの機能リンクの「後方」は空となり、機能リンクの終端を表すことを意味する。
【0115】
続いて、機能リストの「末尾」に、確保したメモリブロックの位置を設定することで(ステップ511)、新しいメモリブロックを含む機能リンクが完成する。
【0116】
続いて、確保したメモリブロックを、伝達路リンクに加入する処理を行う。すなわち、まず、現在行っている接続が、情報伝達路iの伝達路リンクにとって初回の登録の場合は(ステップ512)、まず、情報伝達路iの伝達路リンクの「先頭」に、確保したメモリブロックの位置を設定することで(ステップ514)、確保したメモリブロックを情報伝達路iの伝達路リンクを構成する唯一のブロックとする。また、この場合は、情報伝達路iについて最初に登録される機能処理部jが持つ情報伝達路iに対する受信手段を起動することにより、機能処理部jを情報伝達路iについての代表機能処理部とする(ステップ515)。
【0117】
一方、現在行っている接続が、情報伝達路iの伝達路リンクにとって初回の登録でない場合は(ステップ512)、情報伝達路iの伝達路リストの「末尾」が指すメモリブロックの伝達路リンクの「前方」に、確保したメモリブロックの位置を設定することで、新しいメモリブロックを既存のブロック列の前方、すなわち末尾側に挿入する(ステップ513)。このように、伝達路リンクへのメモリブロックの追加は、順次末尾側へ行われる。
【0118】
その後、それまでの伝達路リストの「末尾」が指していた内容を、確保したメモリブロックの伝達路リンクの「後方」として設定する(ステップ516)。これは、初回登録でない場合は、挿入した新しいメモリブロックの後方に、挿入で1つ後方にずれたブロックを伝達路リンクで接続することを意味し、初回登録の場合は、挿入した新しいメモリブロックの伝達路リンクの「後方」は空となり、伝達路リンクの終端を表すことを意味する。
【0119】
続いて、伝達路リストの「末尾」に、確保したメモリブロックの位置を設定することで(ステップ517)、新しいメモリブロックを含む機能リンクが完成し、図4に示したメインルーチンに戻る。
【0120】
以上のような手順により、例えば、ある情報伝達路に対する最初の受信を要求した機能処理部に対して、伝送装置2を介した通信ネットワーク3からのメッセージ受信を行うような設定が行われる。
【0121】
〔1−2−2−3.接続解除の具体的手順〕
次に、図4のステップ408に示した、情報伝達路iと機能処理部jとの接続を解除する具体的な手順を、図6のフローチャートに定義済処理(サブルーチン)の形式で示す。すなわち、この手順では、まず、接続解除の対象とする機能処理部jの機能リンクに含まれるブロック列のうち、先頭のブロックの位置を機能リンクを参照するなどして得る(ステップ601)。
【0122】
そして、この先頭ブロックから始めて、ブロックに設定された機能に関する「前方」のリンクを(ステップ603)、リンク終端に達するまで辿る(ステップ602)。この途中で、接続解除しようとしている情報伝達路iと一致する伝達路番号すなわち伝達路No.を持つブロックがあった場合は(ステップ603,604)、接続解除しようとしている情報伝達路iと機能処理部j との組合せはまだ登録されている状態であるから、ステップ605以降の手順に進む。
【0123】
一方、接続解除しようとしている情報伝達路iと一致する伝達路No.が見つからないままリンク終端に達した場合は(ステップ602)、接続解除しようとしている情報伝達路iと機能処理部j との組合せは既に削除済の状態であるから、図4に示したメインルーチンに戻る。
【0124】
ステップ605以降では、情報伝達路iと一致する伝達路No.を持つブロック(当該メモリブロックと呼ぶ)を機能リンクから取り除く処理と(ステップ605〜610)、当該メモリブロックを伝達路リンクから取り除く処理と(ステップ611〜616)と、その他の必要な処理を行う。
【0125】
すなわち、当該メモリブロックを機能リンクから取り除くには、まず、先頭側からのリンクを処理するため、当該メモリブロックが機能処理部jの機能リンクの先頭の場合は(ステップ605)、機能処理部jの機能リストの「先頭」に、当該メモリブロックの機能リンクの「前方」の内容を設定する(ステップ606)。一方、当該メモリブロックが機能処理部jの機能リンクの先頭でない場合は(ステップ605)、機能リンクについて、当該メモリブロックの「後方」が指す先頭側の後方ブロックの「前方」に、当該メモリブロックの「前方」の内容を設定する(ステップ607)。
【0126】
次に、末尾側からのリンクを処理するために、当該メモリブロックが機能処理部jの機能リンクの末尾の場合は(ステップ608)、機能処理部jの機能リストの「末尾」に、当該メモリブロックの機能リンクの「後方」の内容を設定する(ステップ609)。一方、当該メモリブロックが機能処理部jの機能リンクの末尾でない場合は(ステップ608)、機能リンクについて、当該メモリブロックの「前方」が指す末尾側の前方ブロックの「後方」に、当該メモリブロックの「後方」の内容を設定する(ステップ610)。
【0127】
続いて、当該メモリブロックを伝達路リンクから取り除くには、まず、末尾側からのリンクを処理するため、当該メモリブロックが情報伝達路iの伝達路リンクの末尾の場合は(ステップ611)、情報伝達路iの伝達路リストの「末尾」に、当該メモリブロックの伝達路リンクの「後方」の内容を設定する(ステップ612)。一方、当該メモリブロックが情報伝達路iの伝達路リンクの末尾でない場合は(ステップ611)、伝達路リンクについて、当該メモリブロックの「前方」が指す末尾側の前方ブロックの「後方」に、当該メモリブロックの「後方」の内容を設定する(ステップ613)。
【0128】
次に、先頭側からのリンクを処理するため、当該メモリブロックが情報伝達路iの伝達路リンクの先頭の場合は(ステップ614)、情報伝達路iの伝達路リンクの「先頭」に、当該メモリブロックの伝達路リンクの「前方」の内容を設定する(ステップ616)。一方、当該メモリブロックが情報伝達路iの伝達路リンクの先頭でない場合は(ステップ614)、伝達路リンクについて、当該メモリブロックの「後方」が指す先頭側の後方ブロックの「前方」に、当該メモリブロックの「前方」の内容を設定する(ステップ615)。
【0129】
また、取り除かれた当該メモリブロックが情報伝達路iの伝達路リンクの先頭の場合、当該メモリブロックに対応していた機能処理部jは代表機能処理部であるから、その代表機能処理部が情報伝達路iに対して実行していた受信手順を停止する(ステップ617)。
【0130】
そして、以上のような処理によって、情報伝達路iとの接続用に使われていた当該メモリブロックは、機能リンク及び伝達路リンクから取り除かれるので、当該メモリブロックを解放することで(ステップ618)、接続の解除は終了し、図4のメインルーチンに戻る。
【0131】
〔1−2−2−4.メッセージ受信の手順〕
以上のように配信データベース18aに登録された確情報伝達路と各機能処理部との対応関係に基づいて、配信制御手段18cと代表機能処理部は、各情報伝達路との間でメッセージの送受信を行う。このうち、図7は、メッセージの受信について受信側の装置内で行われる処理手順を示すフローチャートである。
【0132】
すなわち、この手順では、まず、メッセージを送信する機能処理部によって指定された情報伝達路と接続し(ステップ701)、その情報伝達路に対して受信を要求する(ステップ702)。そして、代表機能処理部の接続解除などによって受信の停止指示がなければ(ステップ703)、配信データベース18aを参照することで、当該情報伝達路に対してメッセージを受信するものとして接続されている先頭のブロック(受信先頭と呼ぶ)を得る(ステップ704)。
【0133】
この受信先頭のブロックは、図5に示した接続の手順において、情報伝達路について最初に登録された代表機能処理部を示しており、この情報伝達路からメッセージを受信する他の機能処理部が存在する場合は、それらの各機能処理部は、受信先頭に設定された伝達路リンクのうち「前方」リンクの指しているブロックにそれぞれ記録されている。
【0134】
このため、情報伝達路リンクの終端に至るまで(ステップ705)、情報伝達路からの受信データを、各ブロックに対応するメッセージキューに書き込みながら(ステップ706)、各ブロックの伝達路リンクのうち「前方」リンクを辿っていけばよい(ステップ707)。なお、代表機能処理部以外の各機能処理部に対応するメッセージキューへの受信データ書き込みは、代表機能処理部が前記ソフトウェアバスを通じて行えばよい。
【0135】
そして、情報伝達路リンクの終端に至った場合は、ステップ702に戻る。このような手順を繰り返し実行することにより、いずれかの装置から各情報伝達路に送信されたメッセージは、他の全ての装置上の各機能処理部のうちその情報伝達路に接続されている機能処理部に配信されることになる。なお、ある装置上の機能処理部から情報伝達路に送信されたメッセージは、以下に示すような送信の処理手順により、同じ装置上にあってその情報伝達路に接続されている各機能処理部にも配信される。
【0136】
ここで、図8は、メッセージの情報伝達路への送信及び各機能処理部によるメッセージキューからの読み込みの処理手順を示すフローチャートである。送受信について送信側の装置内で行われる処理手順を示すフローチャートである。なお、この手順は、メッセージを受信する各機能処理部による受信操作(ステップ801)を含み、この場合は、そのような各機能処理部は、メッセージキューに書き込まれた受信データを読み込むだけでよい(ステップ808)。
【0137】
一方、上記のような機能処理部による受信操作ではなく(ステップ801)、配信制御手段18c及び代表機能処理部が各機能処理部から送信依頼されたメッセージを送信する場合は、メッセージを渡す先は、情報伝達路と(ステップ803)、送信側装置内のメッセージキューの両方となる(ステップ806)。
【0138】
すなわち、配信制御手段18c及び代表機能処理部は、まず、指定された情報伝達路と接続し(ステップ802)、その情報伝達路に対してメッセージの送信を要求することで(ステップ803)、メッセージをまず他の装置宛てに送出する。
【0139】
また、配信制御手段18c及び代表機能処理部は、配信データベース18aを参照することで、送信側の装置内でその情報伝達路に各機能処理部を接続しているブロックのうち先頭のブロックすなわち受信先頭を得る。
【0140】
この受信先頭のブロックは、その情報伝達路について最初に登録された代表機能処理部を示しており、この情報伝達路からメッセージを受信する他の機能処理部が存在する場合は、それらの各機能処理部は、受信先頭に設定された伝達路リンクのうち「前方」リンクの指しているブロックにそれぞれ記録されている。
【0141】
このため、情報伝達路リンクの終端に至るまで(ステップ805)、情報伝達路に送出したものと同じ送信データを、各ブロックに対応するメッセージキューに書き込みながら(ステップ806)、各ブロックの伝達路リンクのうち「前方」リンクを辿っていけばよい(ステップ807)。この場合も、代表機能処理部以外の各機能処理部に対応するメッセージキューへの受信データ書き込みは、代表機能処理部が前記ソフトウェアバスを通じて行えばよい。
【0142】
〔1−3.第1実施形態の効果〕
以上のように、第1実施形態によれば、分散監視制御システムを構成する各機能処理部4〜7,9,11,16,17を、配信処理部18が用意するネットワーク透過なメッセージの配信手段によって結合することで、システム規模に応じた柔軟な機能配置が可能となる。
【0143】
具体的には、上記のような第1実施形態では、システムの構成単位となる制御装置Pや監視装置C,Sといった各装置をネットワーク接続し、ネットワーク3上に用意した複数の情報伝達路ごとにどのような情報をやりとりするか定めておき、各装置上の配信処理部18は、どの機能処理部がどの情報伝達路についてデータを送受信するかの情報を配信データベース18aに登録し、通信を制御したりそのような情報を互いに交換する。
【0144】
これにより、各装置上の配信処理部18は、情報の種類に応じた情報伝達路を使い分け、送出側も受信側を相手方をIPアドレスといった物理的なネットワークアドレスで認識するまでもなく、メッセージの配信先を特定するなど、必要な送受信を行うことが可能となる。
【0145】
この結果、システムの規模に応じて柔軟な構成をとる事が出来るので、拡張性と応答性に優れた分散監視制御システムを得る事ができ、装置や機能処理部の新設・除去・移動・変更・停止・メンテナンスといった構成変更の場合も、ネットワークや情報伝達路の構成自体やプロトコルには変化を与えず、該当する装置内で情報伝達路と機能処理部との接続関係を変更するだけで足りるので、システム全体の停止も不要となる。
【0146】
特に、監視サーバ装置Sなどによって特定の種類の情報を提供するようなサービスが行われるような場合、監視制御対象の規模や範囲などを拡大するために、監視サーバ装置Sの冗長化や分散、それを利用する監視クライアント装置Cの追加などを行っても、ある情報伝達路にリクエストを送ればサービスのデータが返されるといった事情は変化しない。
【0147】
すなわち、監視サーバ装置Sを監視クライアント装置Cがサービス毎に認識できる仕組みも不要になるので実装も容易になる。また、監視サーバ装置Sが監視クライアント装置Cに対してサービス状況を伝える必要もなくなる。さらに、上記のような装置の追加等による構成変更を行う場合も、システム全体を一旦停止させて監視サーバ装置S内の設定変更を必要とするなどの影響は生じない。
【0148】
特に、第1実施形態では、UDP/IPプロトコルを用いることで、従来技術で使われていたTCP/IPプロトコルと比べ、接続の確立や着信の確認などのためのオーバーヘッドは生じないので、サーバ/クライアント間などでの伝送路が持つ帯域幅を最大限に活用でき、通信の効率も改善される。
【0149】
また、第1実施形態では、ある装置上の複数の機能処理部のうち1つの代表機能処理部が他の機能処理部を代表し、配信処理部18を通じて通信ネットワークからのメッセージ受信などを行い、他の機能処理部にソフトウェアバスなどを通じて受信メッセージをコピーして渡す。このため、配信処理部における送受信データのやり取りについて、対象が代表機能処理部に一本化され、負荷が軽減される。
【0150】
また、第1実施形態では、第1の情報伝達路である定常用伝達路TAGは状態量やその変動通知など定常的情報、第2の情報伝達路である警報用伝達路ALMは警報に関する情報、第3の情報伝達路である履歴用伝達路HSDは履歴に関する情報のやりとりに使い分ける。このような使い分けにより、各機能処理部4〜7,9,11,16,17は、該当する情報伝達路に接続するだけで、自ら担当する処理に必要な情報だけを容易に送受信することができる。また、前記のような使い分けにより、一部の情報伝達路や機能処理部に障害が起きた場合でも、それ以外の情報については他の情報伝達路でやり取りを続けることができるので、影響を最小限に抑制することができる。
【0151】
また、第1実施形態では、各機能処理部4〜7,9,11,16,17が構成制御手段などにより、自己診断といった手法で判断した稼動状況を、第1から第3の情報伝達路TAG,ALM,HSDとは異なる第4の情報伝達路RASに送信する。このため、本来の監視や制御に必要な情報のやり取りと、各機能処理部の稼動状態に関する情報のやり取りが相互に独立し、一方に障害があっても他方に波及しないので、システム全体の信頼性が向上する。また、各装置上の構成処理部17などが、当該装置全体の稼動状態や個々の機能処理部の稼動状況を把握して他の装置へ通知したり、各装置が他の装置上の機能処理部の稼動状況を第4の情報伝達路を通じて把握することが容易になるのでシステム全体の運用が容易になる。なお、構成処理部17は機能処理部の一種として構成することができる。
【0152】
また、第1実施形態における配信データベースでは、1つの情報伝達路と1つの機能処理部の対応関係を1つのブロックBで表し、同じ情報伝達路に関わるブロックB同士と、同じ機能処理部に関わるブロックB同士が、それぞれ双方向リンクを順次接続した二重連結リストの構造をとり、さらに、各情報伝達路と各機能処理部のリストRL,FLからは、対応するブロックBの列の先頭や末尾へのリンクが設定されている。
このため、例えばある機能処理部が受信する情報伝達路は、その機能処理部に対応するどのブロックからでも双方向リンクを辿ることで容易に全て特定することができる。同様に、例えばある情報伝達路からの受信データをどれとどの機能処理部へ渡すべきかは、その情報伝達路に対応するどのブロックからでも双方向リンクを辿ることで容易にすべて特定することができる。そして、各機能処理部ごとに対応するメッセージは、その機能処理部の指標が示す格納領域に格納すればよい。また、二重連結リストの構造をとることで、どのブロックからでもブロックすなわち接続の追加や削除といった変更を効率よく行うことができる。以上により、各機能処理部が接続されている情報伝達路に係る送受信や、接続や解除などを、確実に効率よく行うことができる。
【0153】
〔2.第2実施形態〕
第2実施形態は、請求項2,17に対応するもので、全体的な構成及び作用は第1実施形態に準じるが、メッセージを共有メモリに格納することで、メモリを有効活用するようにした例である。
【0154】
〔2−1.第2実施形態の構成〕
この第2実施形態の構成を図9の機能ブロック図に示す。すなわち、第2実施形態における各配信処理部18は、メッセージキューの代わりに、各機能処理部4〜7,9,11,16,17から参照されるための共有メモリMを備えている。また、各配信処理部18の配信制御手段18cは、情報伝達路に係るメッセージを、メッセージキューに代えて共有メモリMに格納するとともに、各メッセージについて、そのメッセージを受信すべき各機能処理部からの参照を受けたかどうかを判断するための残参照指標を設定するように構成されている。図10は、第2実施形態における上記のような共有メモリMと配信データベース18aとの関係を示す概念図である。
【0155】
また、第2実施形態における各機能処理部4〜7,9,11,16,17は、第1実施形態におけるそれらと略同様に構成されているが、共有メモリMに蓄積されたメッセージを参照する度に残参照指標をリセットし、そのメッセージを受信すべき全ての機能処理部からの参照を受けて残参照が無くなったメッセージを廃棄することで、そのメッセージの保管に使用していた共有メモリを解放するように構成されている。
【0156】
〔2−2.第2実施形態の作用〕
上記のように構成された第2実施形態は、次のように作用する。まず、大まかには、配信処理部18の配信制御手段18cは、各機能処理部4〜7,9,11,16,17からの情報伝達路に対する送信要求及び受信要求を受け、送信データSMSGについては、配信データベース18aの内容に従って装置内の共有メモリに蓄積すると共に、伝送装置2を介して通信ネットワーク3にも送信する。また、伝送装置2を介した通信ネットワーク3からの受信データRMSGについても、配信データベース18a(DDB)の内容に従って装置内の共有メモリに蓄積する。以下、第2実施形態の作用について、具体的に説明する。
【0157】
〔2−2−1.接続の手順〕
まず、図11は、配信登録手段18bが、情報伝達路と機能処理部とを接続するなどして、図10に示したような構成の配信データベースを生成及び更新する処理手順を示すフローチャートである。
【0158】
この図11の手順では、第1実施形態について図4に示した同様の手順と比べ、情報伝達路と機能処理部との接続に先立ってメッセージキューなどを生成したり(ステップ402〜404)、接続解除に続いてメッセージキューなどを削除する処理(ステップ411,412)がない。すなわち、第2実施形態におけるメッセージの格納領域は、第1実施形態のように機能処理部ごとに常時確保されるのではなく、以下に説明するように、送受信の際に確保され、必要な各機能処理部による参照が済むと解放される。
【0159】
なお、図11に示す定義済処理のうち、情報伝達路と機能処理部との接続解除(ステップ1108)の具体的手順は、メッセージの残参照に関する処理が入る点で図6の手順とは異なるが、この点については後述する。
【0160】
〔2−2−2.配信制御手段によるメッセージ受信の手順〕
また、上記のような接続が反映された配信データベース18aに基づいて、各配信処理部18の配信制御手段18cが情報伝達路からメッセージを受信する処理手順を示すフローチャートを、図12に示す。この手順では、配信制御手段18cは、情報伝達路から受信した受信メッセージを、共有メモリMに格納するとともに、各メッセージについて、そのメッセージを受信すべき各機能処理部からの参照を受けたかどうかを判断するための残参照指標を設定する。
【0161】
すなわち、配信制御手段18cは、まず、指定された情報伝達路と接続し(ステップ1201)、受信メッセージの格納領域を共有メモリMに確保し(ステップ1202)、情報伝達路に対して受信を要求し(ステップ1203)、この要求に対して情報伝達路から受け取られた受信メッセージは共有メモリMに確保された前記格納領域に格納される。そして、配信制御手段18cは、接続解除などによって受信の停止指示を受け取らない限り(ステップ1204)、ステップ1205以降の手順に進む。
【0162】
すなわち、配信制御手段18cは、まず、受信の要求に対して情報伝達路から受け取った情報のなかに、まだこれから受信すべき受信メッセージ(残受信メッセージと呼ぶ)があれば(ステップ1205)、最終メッセージの前方リンク格納位置に、受信メッセージの格納位置を設定する(ステップ1206)。
【0163】
ここで、前方リンク格納位置とは、共有メモリM上に確保される格納領域の一部で、同じ情報伝達路から順に受信したメッセージをそれぞれ格納する格納領域同士をリンクするポインタ(前方リンクと呼ぶ)を格納するための位置であり、「空」を意味するような所定のデータを格納しておくことで、その格納領域が其の情報伝達路から受信した受信した最後のメッセージ(最終メッセージ)を格納していることを表すことができる。
【0164】
このような前方リンク格納位置に格納された前方リンクを辿ることで、各機能処理部は、自分が受信すべき情報伝達路からの受信メッセージを順次読み出し、最終メッセージについてはそれが最終メッセージであることを認識することができる。
【0165】
そして、配信制御手段18c は、情報伝達路リスト中の情報伝達路に対応させて、共有メモリM上における上記のような受信メッセージの格納位置を設定する(ステップ1207)。これにより、情報伝達路から受信したメッセージを共有メモリMから読み出そうとする各機能処理部は、情報伝達路リストを参照することで、その情報伝達路から受信されたメッセージが格納されている最初の格納領域の位置を知ることができる。
【0166】
続いて、配信制御手段18cは、当該情報伝達路に対応する最初のブロック(受信先頭)を得て(ステップ1208)、この受信先頭から始まる情報伝達路リンクの終端に至るまで(ステップ1209)、次のような手順を繰り返す。
【0167】
すなわち、まず、受信先頭から始まる情報伝達路リンク中の各ブロックが示す機能処理部(受信機能と呼ぶ)に対応した残参照指標を、未参照の状態にセットする(ステップ1210)。また、各機能処理部について、共有メモリMからまだ読み出していない残受信メッセージがなければ(ステップ1211)、そのブロックに対応する未受信メッセージの位置を最終メッセージの格納位置に設定する(ステップ1212)。
【0168】
つまり、1つの情報伝達路について順番に送受信されたメッセージは、共有メモリM中にそれぞれ確保された格納領域に順番に確保され、各格納領域は図10に示すようにメッセージ用のリンクで接続される。そして、このような各メッセージのうちどこまで共有メモリMから読み出し済すなわち受信済で、どこから未受信かは、機能処理部によって異なる。このため、情報伝達路と機能処理部との組み合わせごとに設定されている各ブロックごとに未受信メッセージの位置を記録しているものである。
【0169】
そして、ブロックに設定されている伝達路リンクの「前方」リンクを辿ることで、伝達路リンクに含まれる次のブロックに処理を進める(ステップ1213)。なお、ステップ1209において、情報伝達路リンクの終端に至ると、ステップ1202に戻る。以上のような処理を繰り返すことにより、情報伝達路に流れるメッセージは共有メモリMに格納されてゆくことになる。
【0170】
〔2−2−3.残参照指標の具体例〕
ここで、残参照指標の具体的な構成やどのようにセットやリセットを行うかは自由であるが、一例として、ある装置上の残参照指標を、その装置上の機能処理部の数と同じ幅のビット列として構成するなどが考えられる。例えばこの場合、1つの情報伝達路から得た受信データを共有メモリのある領域に格納するとき、その情報伝達路に接続されている機能処理部の番号に対応するビットだけを「1」にセットして残参照指標とすることが考えられる。
【0171】
具体的には、ある情報伝達路に接続されている機能処理部の番号が例えば5,2,1の場合、「10011」のようにビットを立てれば、立っているビットが残参照すなわち未参照の機能処理部を表すことになる。そして、各機能処理部がその領域を参照したときに、自己の番号に対応する残参照すなわちビットを「0」にリセットしていけば、領域に対応する残参照指標のビット列が全て0かどうかを調べるという単純な処理によって、残参照の有無を容易に確認することができる。
【0172】
〔2−2−4. 送信及び共有メモリからの読み出し〕
次に、図13に、配信制御手段18cがメッセージを送信する手順と(左側)、各機能処理部4〜7,9,11,16,17が共有メモリMからメッセージを読み出して受信する受信操作(右側)を示す。
【0173】
すなわち、各機能処理部4〜7,9,11,16,17がメッセージを共有メモリMから読み出す受信操作でない場合は、配信制御手段18cが、指定された情報伝達路と接続し(ステップ1302)、情報伝達路に対して送信を要求することで、送信メッセージの送信を実行する(ステップ1303)。この時点で、情報伝達路について受信が有れば、例えば図12に示した処理手順を実行するために一旦手順を終了するが、そうでなければ、送信メッセージの格納領域を共有メモリMに確保する(ステップ1305)。この格納領域には、送信メッセージのコピーが、送信側装置内の各機能処理部4〜7,9,11,16,17にのための受信メッセージとして格納される。
【0174】
その後、図12のステップ1208〜1213と同様に、メッセージ送信に係る情報伝達路からメッセージを受信すべき各機能処理部に対応した残受信指標をセットする(ステップ1306〜1311)。この場合、情報伝達路リンクの終端に達すると(ステップ1307)、手順を終了する。
【0175】
また、各機能処理部4〜7,9,11,16,17がメッセージを共有メモリMから読み出す受信操作の場合(ステップ1301)、各機能処理部4〜7,9,11,16,17は、共有メモリMに蓄積されたメッセージを参照する度に残参照指標をリセットし、そのメッセージを受信すべき全ての機能処理部からの参照を受けて残参照が無くなったメッセージを廃棄することで、そのメッセージの保管に使用していた共有メモリを解放する。
【0176】
具体的には、メッセージを共有メモリMから読み出す機能処理部は、まず、配信データベース18aを参照することで、当該機能に対する先頭情報伝達路を得る(ステップ1312)。すなわち、機能処理部は、自分を各情報伝達路に接続しているブロックで構成された機能リンクのなかから先頭のブロックに対応する情報伝達路を得る。
【0177】
そして、機能リンク中の「前方」リンクを辿ることで(ステップ1315)、その機能処理部がメッセージを受信すべき各情報伝達路について、共有メモリMから読み出すべき残受信メッセージがあるかどうかを確認してゆき(ステップ1314)、機能リンクの終端に至ると手順を終了する(ステップ1313)。
【0178】
すなわち、情報伝達路について残受信メッセージがある場合は(ステップ1314)、そのメッセージを格納している共有メモリM中の格納領域について、当該機能に対応する残参照をリセットし(ステップ1316)、これにより、例えば残参照指標が「00000」になった場合のように、メッセージの残参照がなくなると(ステップ1317)、メッセージ格納に確保していた共有メモリの領域を解放する(ステップ1318)。
【0179】
続いて、同じ情報伝達路に関する送受信メッセージ同士を接続しているリンクのリンク先を未受信メッセージに設定する(ステップ1319)。この結果、共有メモリMから廃棄されたメッセージがその情報伝達路から受信された最終メッセージだった場合は(ステップ1320)、その情報伝達路から受信されたメッセージのうち未読込のものは存在しないことになるので、その情報伝達路の最終メッセージ格納位置をクリアし(ステップ1321)、手順を終了する。
【0180】
なお、1つの機能処理部に対応する複数の情報伝達路からの受信メッセージは、図13右側の手順を繰り返すことによって全て読み出すことができる。
【0181】
〔2−2−5.接続解除の具体的処理手順〕
また、第2実施形態において、図11に示した接続解除(ステップ1108)の処理手順は、図6に示した手順のうちメモリブロックの解放(ステップ618)を、図14に示す処理手順に置き換えたものとなる。
【0182】
この図14に示すフローチャートは、図6に示した手順のうちメモリブロックの解放(ステップ618)と置き換える処理手順を定義済処理(サブルーチン)の形式で示したものである。すなわち、この手順では、まず、共有メモリMに格納されている情報伝達路iに関する未読込メッセージについて、メッセージ間のリンクを辿りながら(ステップ1405)、終端に至るまで(ステップ1401)、次のような処理を繰り返す。つまり、未読込メッセージに設定されている残参照指標のうち、接続解除する機能処理部jに対応する残参照をリセットし(ステップ1402)、メッセージへの残参照が無くなっていれば(ステップ1403)、そのメッセージ格納に確保した共有メモリMの領域を解放してゆく(ステップ1404)。
【0183】
このような処理を各未読込メッセージについて繰り返し、未受信メッセージの終端に到達すると(ステップ1401)、メッセージへの残参照がなければ(ステップ1406)、情報伝達路iの最終メッセージ各位置をクリアし(ステップ1407)、情報伝達路iとの接続用の当該メモリブロックを解放し、図6の手順の最後に戻る。
【0184】
〔2−3.第2実施形態の効果〕
以上のように、第2実施形態では、複数の機能処理部によって受信されるメッセージも、機能処理部ごとに重複格納されず、各機能処理部から参照される共有メモリMに格納されるので、記憶領域が有効活用される。また、共有メモリMに格納されたメッセージは、そのメッセージを受信すべき全ての機能処理部からの参照を受けた後で廃棄されるので、そのメッセージを必要とする全ての機能処理部に確実に渡される。この結果、特に、分散監視制御システムに含まれる各機能処理部間において大量のメッセージが発生したとしても、必要最低限の物理的メモリしか消費しないので、残メモリを活かした良好な性能を得ることが可能となる。
【0185】
〔3.第3実施形態〕
第3実施形態は、請求項7,22,27に対応するもので、各機能処理部を代表して送受信データを配信処理部との間で仲介していた代表機能処理部に障害が発生しても、その役割を他の機能処理部が引き継ぐことで、システム全体の可用性を向上させた例である。
【0186】
〔3−1.第3実施形態の構成〕
図15は、第3実施形態の構成を示す機能ブロック図である。この第3実施形態における各装置は、第1実施形態と同様に、情報伝達路ごとに、送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部が、配信処理部との受け渡しを各機能処理部を代表して行うと共に、他の各機能処理部に対して受け渡しするように構成されている。具体的には、装置が起動された後、最初に情報伝達路に対する送受信を依頼してきた機能処理部がその情報伝達路に関する代表機能処理部となる。
【0187】
また、第3実施形態における各機能処理部4〜7,9,11,16は、それぞれ、当該機能処理部の稼動状況を判断して定期的に構成用伝達路RASに出力するための構成制御手段を備えている。また、第3実施形態における各装置は、それぞれ、構成処理部17を備えている他、構成データベースを備えている。
【0188】
ここで、構成処理部17は、各装置の稼動状態を他の装置に知らせるための部分であり、各装置ごとのハードウェアなどの正常異常といった稼動状態を判断したり、同じ装置内の各機能処理部から構成用伝達路RASに送信される稼動状態を監視し、検出した異常を定常用伝達路TAGに出力するように構成されている。
【0189】
一方、構成データベースは、同じ装置上の各機能処理部から受信した稼動状態を記録するための手段であり、図16は、構成データベースの構造の一例を示す図である。
【0190】
また、第3実施形態における配信処理部18は、配信切離手段18dを備えている。この配信切離手段18dは、上記のような代表機能処理部に障害が発生したことが前記構成処理部17によって検出された場合に、それまで代表機能処理部が行っていた受け渡しを、他の各機能処理部のいずれかに引継がせるための手段である。
【0191】
〔3−2.第3実施形態の作用〕
以上のように構成された第3実施形態は、以下のように作用する。まず、図17は、第3実施形態における構成処理部の動作手順を示すフローチャートである。この手順は、装置起動時の初期化の他に(ステップ1701)、一定時間ごとに(ステップ1704)、装置のハードウェアの診断及びその稼動状態の送出と(ステップ1702)、装置上の各機能処理部の診断とその稼動状態の送出と(ステップ1703)を行うものである。
【0192】
ここで、ステップ1701,1702,1703のより具体的な処理手順を、それぞれ定義済処理(サブルーチン)形式で、図18、図19、図20に示す。
【0193】
〔3−2−1.装置起動時の初期化〕
このうち図18の手順は、装置起動時の初期化を行うもので、この手順では、構成処理部17は、まず、構成データベースのアクセス位置を先頭に設定し(ステップ1801)、全機能の起動を完了するまで(ステップ1805)、装置上に設定された機能すなわち機能処理部を起動してゆく(ステップ1802)。
【0194】
このように起動される各機能処理部4〜7,9,11,16に対しては、予め定めた情報伝達路RASに対して稼動状態を示す通知メッセージNMを定期的に送出する事が義務づけられる。これは具体的には、例えば構成処理部17が、各機能処理部4〜7,9,11,16の各構成制御手段に、稼動状況を情報伝達路へ定期的に出力するように指示することを意味する。
【0195】
また、構成処理部17は各機能処理部について、起動時の現在位置時を、構成データベースのうちその機能処理部に関する稼動状態受信日時すなわち稼動状態を最後に受信した日時として設定したうえ(ステップ1803)、構成データベースへのアクセス位置を更新してゆく(ステップ1804)。これにより、構成データベース中の全ての機能処理部に関する稼動状態受信日時が、起動時の現在日時となる。
【0196】
その後、構成処理部17は、稼動状態の情報伝達路すなわち各機能処理部が稼動状態を出力する情報伝達路に対する受信手段を起動し、図17の手順に戻る。
【0197】
〔3−2−2.稼動状態の受信に関する手順〕
ここで、この受信手段は構成処理部17の一部であり、図21は、受信手段が情報伝達路から各機能処理部の稼動状態を受信して構成データベースを更新したり、外部からの問合せに対して回答する処理手順を示すフローチャートである。
すなわち、この手順では、受信手段は、各機能処理部の稼動状態を受信する情報伝達路と接続し(ステップ2101)、情報伝達路からのメッセージを受信するたびに(ステップ2102)、メッセージの種類に応じた次の処理を行う。
【0198】
すなわち、メッセージが機能処理部に関する稼動状態の通知であれば(ステップ2103)、構成データベースのうちその機能処理部についての受信日時を更新する(ステップ2104)。また、メッセージが他の装置などからの稼動状態の問合せであれば(ステップ2105)、構成データベースの内容を構成用伝達路RASに再送出する(ステップ2106)。以上のような手順を繰り返すことで、構成データベース内では、各機能処理部について前回稼動状態を受信した日時が更新され、また、他の装置などからその情報を照会することも可能となる。
【0199】
〔3−2−3.装置のハードウェアの診断及びその稼動状態の送出〕
また、図19の手順は、装置のハードウェアの診断及びその稼動状態の送出を行うもので、この手順では、構成処理部17は、まず、RAS基板の出力やエラーログにより装置のハードウェアの診断を行う(ステップ1901)。ここで、RAS基板とは、伝送装置2のうち、各機能処理部が稼動状態を出力する構成用伝達路RASとの送受信を制御する基板であり、エラーログは、その装置で発生したエラーの履歴であり、ハードウェアの異常なども記録されている。
【0200】
この結果、ハードウェアが正常の場合は(ステップ1902)、ハードウェア状態を表すフラグなどの情報を「正常」に設定し(ステップ1903)、ハードウェアが正常でない場合は(ステップ1902)、ハードウェア状態を表すフラグなどの情報を「異常」に設定する(ステップ1904)。これにより、ハードウェア状態すなわち正常か異常かがそれ以前と変化した場合は(ステップ1905)、新しいハードウェア状態を監視点として情報伝達路に送出し(ステップ1906)、図17の手順に戻る。
【0201】
〔3−2−4.各機能処理部の診断とその稼動状態の送出〕
また、図20の手順は、装置上の各機能処理部の診断とその稼動状態の送出を行うもので、この手順では、構成処理部17は、起動した装置内の機能処理部から、定期的な稼動状態の通知メッセージNMの送信が、許容時間以上途絶えた場合、その機能が異常になったと判断し、対応している情報伝達路からの切離しを配信処理部18に対して指示する。
【0202】
すなわち、構成処理部17は、まず、構成データベースのアクセス位置を先頭に設定し(ステップ2001)、この先頭に対応する機能処理部から始め、構成データベースへのアクセス位置を更新してゆき(ステップ2008)、全機能すなわち全ての機能処理について(ステップ2009)、次のような稼動状態の調査(稼動調査と呼ぶ)を行う。
【0203】
すなわち、その機能処理部について前回稼動状態を受信した日時からの経過時間を求める(ステップ2002)。ここで、各機能処理部の構成制御手段は、一定時間ごとに稼動状態を送出するので、一定時間以上その送出が途絶えた場合、その機能処理部は異常と判断することができる。ここでは、ステップ2002で求めた経過時間が許容範囲内であれば(ステップ2003)、当該機能の稼動状態を「正常」に設定する(ステップ2004)。
【0204】
一方、ステップ2002で求めた経過時間許容範囲内でなければ(ステップ2003)、当該機能の稼動状態を「異常」に設定に設定するとともに、配信切離し手段を起動することで、当該機能を情報伝達路から切離す(ステップ2005)。なお、この切り離しの具体的な手順は後述する。
【0205】
続いて、構成処理部17は、上記のように判断した機能の稼動状態について、それ以前と比べて変化があった場合は(ステップ2006)、その機能の稼動状態を監視点として情報伝達路に送出する(ステップ2007)。以上のような稼動調査を全機能について完了すると、図17の手順に戻る。
【0206】
〔3−2−5.異常な機能処理部の切離し〕
次に、図22及び図23は、配信処理部18による処理手順を示すフローチャートであり、結合子221,222,223によって相互に一体に結合されている。この手順では、配信処理部18の配信登録手段18bが、異常が起きたとして指定された機能を配信データベース19から削除すると共に、配信処理部18の配信切離手段18dが、削除された機能が代表機能処理部の役割を果たしていた情報伝達路について、受信を必要とする次の機能処理部がある場合は、その中のいずれかに代表機能処理部の役割を引き継がせる。
【0207】
すなわち、まず、配信処理部18の配信登録手段18bは、切離す機能の機能リンクの先頭から(ステップ2201)終端に至る(ステップ2202)に含まれる全てのブロックについて、図6のステップ605〜616と同様の手順で、機能リンク及び情報伝達路リンクから切離す(ステップ2205〜2216)。
【0208】
ここで、切離された機能のブロックが、情報伝達路リンクの先頭に登録されていたのであれば(ステップ2214)、その機能は代表機能処理部であるが、この場合、そのブロックに前方リンクが有る場合は(ステップ2217)、同じ情報伝達路に接続された他のブロックが存在することを意味する。このような他のブロックは1つであっても複数であっても、少なくとも前方リンクが指している末尾側のブロック(後続ブロックと呼ぶ)が存在する。
【0209】
この場合、配信切離手段18d は、その情報伝達路について代表機能処理部になることを要請する通知メッセージNM(情報伝達路に対する受信処理起動要請メッセージと呼ぶ)を、後続ブロックに対応するメッセージキューに登録することによって(ステップ2218)、後続ブロックに対応する機能処理部に受信手段の起動を促し、それまで代表機能処理部が行っていた処理を引継がせる。
【0210】
すなわち、後続ブロックに対応する機能処理部は、図24に示すように、メッセージキューから読み込んだデータが(ステップ2408)、受信手段の起動要請の場合は(ステップ2409)、情報伝達路に対する受信手段を起動ことによって(ステップ2410)、代表機能処理部の役割を引き継ぐ。
【0211】
〔3−3.第3実施形態の効果〕
以上のように、第3実施形態では、各機能処理部を代表して送受信データを配信処理部との間で仲介していた代表機能処理部に障害が発生しても、その役割を他の機能処理部が引き継ぐ。これにより障害の影響が他の機能処理部に及ぶことがなく、連鎖的な機能喪失が防止できるので、装置全体の可用性(availability)が向上する。
【0212】
〔4.第4実施形態〕
第4実施形態は、請求項8,23,28に対応するもので、機能処理部が障害を発生したとき、各機能処理部が、障害の内容や、障害が発生した機能処理部への依存度に基づいて、機能縮退などの対応を選択することで、可用性を向上させる例である。
【0213】
〔4−1.第4実施形態の構成〕
図25は、第4実施形態の構成を示す機能ブロック図である。この第4実施形態は、第3実施形態に示した構成に加え、次のように構成されている。まず、構成処理部17は、障害が発生した機能処理部を他の機能処理部に対して知らせるように構成されている。また、第4実施形態における各機能処理部4〜7,9,11,16は、その障害の内容又はその障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択するように構成されている。
【0214】
このうち、「他の装置上で待機する機能処理部の起動」を実現するために、第4実施形態は、同じ役割を果たす機能処理部を予め複数用意し、そのうち1つを実際に処理を行う常用系とし、他は、常用系の障害時に代替させるための待機系とするように構成されている。
【0215】
このような常用・待機の設定は情報伝達路に対する排他的な送信権の獲得として行われ、常用系は、必要な入力データを所定の情報伝達路から受信するだけでなく、処理結果を所定の情報伝達路に送信するが、待機系は、受信だけを行い、送信は行わない。
【0216】
そして、第4実施形態における各機能処理部4〜7,9,11,16は、第1実施形態から第3実施形態で説明したものと略同様であるが、相違点として、上記のような常用系と待機系の区別を可能にするため、情報伝達路との接続を受ける際、「受信」だけするのか、「送信」だけするのか、「送受信」両方するのか、というアクセス形態を、配信処理部18の配信登録手段18bに与えるように構成されている。
【0217】
また、このようなアクセス形態を与えられる配信処理部18の配信登録手段18bも、与えられたアクセス形態で情報伝達路と機能処理部とを接続するように構成されている。図26は、このように更新される配信データベース18aの一例を示す図である。
【0218】
〔4−2.第4実施形態の作用〕
上記のように構成された第4実施形態で、まず、構成処理部17は、各機能処理部の稼動状態について、変化があったときに情報伝達路RASに出力するだけでなく、一定時間間隔で調査するごとに、構成データベースの内容として情報伝達路RASに送出する。
【0219】
すなわち、まず、第4実施形態において、構成処理部17の動作手順は、第3実施形態について図17に示した手順と大まかには共通するが、次の点で異なっている。すなわち、第4実施形態では、第3実施形態における図20に対応する図27において、図20のステップ2001〜2009に対応するステップ2701〜2709に加え、構成データベースの内容が情報伝達路RASに出力される(ステップ2710)。
【0220】
このように出力される情報には、図28に示すように、伝達路と機能組み合わせごとに上記のようなアクセス形態(送受信と表す)が含まれる。これにより、装置上の全機能の稼動調査が完了するたびに、機能の稼動状態に変化がなくても、各機能処理部の接続状態が全ての装置上の全ての機能処理部に通知される。
【0221】
また、図29は、第4実施形態における配信処理部18の配信登録手段18bの動作手順を示すフローチャートである。すなわち、この手順では、第1実施形態について図4で示したステップ401〜412に対応するステップ2901〜2912に加え、情報伝達路と機能処理部との接続や接続解除の後、各機能処理部ごとの情報伝達路への接続状態を情報伝達路RASへ送出する(ステップ2913)。この接続状態には、どの装置上のどの機能処理部が、どのようなアクセス形態でどの情報伝達路を接続対象としているかが含まれる。
【0222】
また、第3実施形態について図18で示した(ステップ1806)と同様に起動される送受信手段の動作手順を図30に示す。この手順では、第3実施形態について図21に示した手順に加え、情報伝達路への接続状態通知を受け取ったときに(ステップ3003)、各機能処理部の情報伝達路への接続状態を更新する(ステップ3006)。
【0223】
以上のように提供される各機能処理部に関する稼動状況や、情報伝達路への接続状態は、以下のような処理に利用される。まず、第4実施形態では、構成処理部17から情報伝達路RASに出力された稼動状態変化の通知メッセージNMにより、ある機能に障害が発生したことが判明すると、各機能処理部の構成制御手段は、障害を発生した機能への依存度に応じて、機能縮退、異なる構成ハードウェアに配置した待機機能の起動、或いは自発的な機能停止を独自に判断・選択する。
【0224】
具体的には、例えば、図25に示した第4実施形態の構成において、履歴処理部11が異なる互いに装置を用いて複数に冗長化されており、いずれかの履歴処理部11を常用系とし、残りの履歴処理部11を待機系とする場合を考える。このような場合、常用側の情報伝達路HSDに対するアクセス形態は送受信、待機側は情報伝達路HSDに対してアクセス形態を受信とする。
【0225】
そして、情報伝達路RASを通して、常用系の履歴処理部11に機能障害が発生した事を検出すると、待機系だった履歴処理部11は、構成制御手段の働きにより、アクセス形態を「受信」から「送受信」に切り換えることで常用系となり、それまで履歴処理部11が行っていたサービスの提供を継続することができる。
【0226】
この場合、履歴処理部11は、待機系として動作していた間、処理結果などの送信はしていなかったが、必要なデータなどの受信はしていたので、常用系となってすぐに、それまで常用系だった履歴処理部11が持っていた情報と同じ情報に基づいて、継続性あるサービスを提供することができる。
【0227】
次に、上記のような常用系と待機系とを構成制御手段が切り換える処理手順を図31及び図32にまたがるフローチャートに示す。なお、この図31及び図32のフローチャートは、結合子311によって一体に結合されている。この手順では、各機能処理部の構成制御手段は、起動すると一旦アクセス形態「送受信」で情報伝達路RASに接続し(ステップ3101)、受信メッセージとして(ステップ3103)稼動状態の通知が返ってくるまで(ステップ3104)、稼動状態の問合せメッセージを情報伝達路RASに送出する(ステップ3102)。ある機能処理部がここで得るべき稼動状態は、互いに同じ機能処理部の常用系や待機系になる関係にある、他の機能処理部の稼動状態である。
【0228】
そして、情報伝達路RASから受信メッセージとして(ステップ3103)稼動状態を獲得すると(ステップ3104)、その稼動状態を保存し(ステップ3105)、図32に示す以下のような処理を行う。すなわち、まず、図30のステップ3006で更新される接続状態すなわちアクセス形態を参照し、上記のような他の機能処理部から情報伝達路への送信機能が稼動しているかどうかを確認する(ステップ3201)。
【0229】
このとき、情報伝達路への送信機能が稼働中であれば(ステップ3201)、処理結果などの情報を出力する情報伝達路(出力情報伝達路と呼ぶ)に対してアクセス形態「受信」で接続し(ステップ3214)、待機系として初期化し、その機能処理部ごとの役割を果たす履歴処理部や警報処理部といった部分(機能手段と呼ぶ)を起動する(ステップ3215)。
【0230】
一方、他の機能処理部から情報伝達路への送信機能が稼働中でないときは(ステップ3201)、送信権調停メッセージを情報伝達路RASに送出する(ステップ3202)。ここで、送信権調停メッセージは、同じ機能処理部の常用系になろうとする個々の機能処理部が発するメッセージであり、このメッセージを発した機能処理部が、自分の発したものでない同じメッセージを受信した場合は、同じ機能処理部の常用系になろうとする機能処理部が自分以外にも存在することになる。
【0231】
すなわち、複数の機能がこの送信権調停メッセージを一定期間内に送出している場合は、各機能処理部は、同じ送信権調停メッセージを互いに受信することで、送信権の調停が必要である事を認識し、次のように乱数を用いて送信権調停メッセージの送出タイミングを互いにずらす事によって、唯一の機能が送信権を獲得できるようにしている。
【0232】
つまり、送信権調停メッセージを送出した後で(ステップ3202)、予め決められた許容待ち時間が経過するまで(ステップ3205)の間に受信したメッセージが(ステップ3203)、送信権調停メッセージの場合、各機能処理部は、乱数を元に発生した時間に許容待ち時間を加えた時間の間だけ、実行を中断したうえ(ステップ3213)、ステップ3201からの手順を繰り返すことで、唯一の機能処理部が送信権を獲得して常用系となる。
【0233】
なお、この送信権の獲得においては、例えば、各機能が動作するホストが持つユニークな識別番号、例えばユニキャストアドレス、イーサネットアドレスといったものの大小関係で、常用系となる方を決定することも可能である。
【0234】
以上のように常用系又は待機系となった各機能処理部は、その後受け取った受信メッセージが(ステップ3208)、稼動状態の通知で(ステップ3209)、かつ、常用系の異常通知の場合は、ステップ3201からの手順を繰り替えすことで、新たな常用系を決定する。
【0235】
このような第4実施形態では、配信処理部18の配信制御手段18cは、各機能処理部のアクセス形態に応じた送信や受信などの処理を行えばよい。例えば、図33は、情報伝達路からデータを受信する処理手順を示すフローチャートである。この手順は、第1実施形態について示した図7と略同様であるが、受信データをメッセージキューに書き込むのは、機能処理部についてアクセス形態が「送受信」である場合など、受信要求があったときだけである(ステップ3315)。
【0236】
なお、第4実施形態におけるメッセージの送信やメッセージキューからの読み込みは、第1実施形態について図8に示したフローチャートと同様の処理手順で行えばよい。
【0237】
〔4−3.第4実施形態の効果〕
以上のように、第4実施形態では、機能処理部で障害が発生したとき、他の各機能処理部は、障害の内容や、障害が発生した機能処理部への依存度に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止といった対応が可能となるので、障害の波及範囲が限定され、分散監視制御システムの可用性が向上する。例えば、障害が発生した機能処理部が発するメッセージを必要とする機能処理部は、自発的に機能停止するなどが考えられる。
【0238】
〔5.第5実施形態〕
第5実施形態は、請求項9に対応するもので、メッセージごとにカテゴリを設定することで、カテゴリが追加されても、それと無関係な機能処理部が影響を受けないようにした例である。
【0239】
〔5−1.第5実施形態の構成〕
第5実施形態の全体構成は、第1実施形態について図1に示した構成と略同様であるが、まず、第5実施形態における各機能処理部4〜7,9,11,16は、接続する情報伝達路に対して受信対象とするカテゴリを指定するように構成されている。また、これに対応して、第5実施形態における配信登録手段は、各機能処理部が受信するメッセージのカテゴリを予め配信データベースに登録するように構成されている。
【0240】
また、配信制御手段は、送信メッセージにカテゴリを設定し、各メッセージを、設定されているカテゴリに対応する各機能処理部にのみ配信するように構成されている。
【0241】
〔5−2.第5実施形態の作用〕
以上のように構成された第5実施形態では、配信処理部18の配信登録手段18bが、各機能処理部を配信データベース18aに登録する際、図34に示すフローチャートのステップ3406下線部に示すように、各機能処理部が接続する情報伝達路に対して受信対象とするカテゴリを配信データベース19に設定する。図35は、このようなカテゴリがブロックごとに登録された配信データベースの内容例を示す概念図である。
【0242】
また、配信処理部18の配信制御手段18cは、送信メッセージにカテゴリを設定し、各メッセージを、設定されているカテゴリに対応する各機能処理部にのみ配信する。すなわち、例えば、図36のフローチャートに示すように、ある情報伝達路からの受信メッセージについて、メッセージに含まれるカテゴリをフィルタ指標として参照し(ステップ3615)、その情報伝達路に接続された機能処理部のうち、メッセージに設定されているカテゴリを受信対象とする機能処理部のメッセージキューにだけ書き込まれる(ステップ3606)。
【0243】
この結果、各機能処理部は、接続を要求した各情報伝達路について、情報伝達路ごとに指定したカテゴリに相当するメッセージのみを受信する事が可能になる。なお、第5実施形態におけるメッセージの送信やメッセージキューからの読み込みは、第1実施形態について図8に示したフローチャートと同様の処理手順で行えばよい。
【0244】
〔5−3.第5実施形態の効果〕
以上のように、第5実施形態によれば、各機能処理部について受信対象とするメッセージのカテゴリを予め登録しておき、受信側で受信された各メッセージは、送出側でそのメッセージに設定されたカテゴリに対応する機能処理部にのみ配信される。これにより、各機能処理部が関係するメッセージだけを選択的に受信すること、すなわちメッセージ受信のフィルタリングが容易に実現される。
【0245】
このため、機能処理部が受信対象としていた情報伝達路において、例えば何らかの機能拡張を意図した新たなカテゴリのメッセージが送受信対象に追加されたような場合においても、このように追加されたメッセージを必要としない各機能処理部については、カテゴリを違えておくことで影響を避け、それ以前と同様に動作を継続することが出来る。なお、このようなカテゴリは、1つの情報伝達路だけに適用してもよいし、複数又は全ての情報伝達路に適用してもよい。
【0246】
〔6.第6実施形態〕
第6実施形態は、請求項10に対応するもので、受信する機能処理部が存在しない情報伝達路へはメッセージを送出しないことで、不要な伝送を削減する例を示すものである。
【0247】
〔6−1.第6実施形態の構成〕
第6実施形態における全体構成や各機能処理部4〜7,9,11,16の構成などは、第3実施形態(図15)と略同様であるが、各装置の各配信処理部は、各装置においてどの情報伝達路にどの機能処理部が対応付けられているかを表す接続状況を交換することにより、分散監視制御システム全体における接続状況を作成し、それに基づいて、メッセージを送信しようとする情報伝達路からメッセージを受信する機能処理部が分散監視制御システム内に存在しない場合は、そのメッセージを情報伝達路に送出しないように構成されている。
【0248】
〔6−2.第6実施形態の作用〕
上記のように構成された第6実施形態では、各配信処理部18の配信登録手段18bが、配信データベースに対する登録・削除などの際、各機能処理部と情報伝達路との接続状況を、図28に例示したのと同様な表形式にして情報伝達路RASに送出する。また、構成処理部17の動作手順は、第3実施形態について図17に示したものと略同様であるが、第6実施形態では図37に示すように、装置上の各機能処理部の稼動調査が完了すると(ステップ3709)、構成データベースと、各機能処理部ごとの情報伝達路への接続状況を、情報伝達路RASに送出する(ステップ3710)。
【0249】
また、各装置において、配信処理部18の配信制御手段18cは、図38に示すように、上記のように送信される接続状態通知などの接続状況を、他の装置から受信した場合は、自装置内の接続状況とマージする事により分散監視制御システム全体の接続状況を作成する(ステップ3806)。このようなシステム全体の接続状況を表すデータを接続状態データベースと呼ぶ。
【0250】
配信制御手段18cは、機能処理部などから情報伝達路への送信が要求された場合、上記のような接続状況データベースを参照することにより、その情報伝達路からメッセージ受信を行う機能処理部がどの装置上にも存在しない場合、そのような情報伝達路に対するメッセージの送出要求を無視する。
【0251】
すなわち、第6実施形態において、配信制御手段18cがメッセージを送信する処理手順を図39のフローチャートに示す。ここで、この手順のうちステップ3901,3902〜3908は、第1実施形態で示した図8の手順のうちステップ801〜808と略同様である。
【0252】
この手順では、情報伝達路へのメッセージ送信(ステップ3902〜3907)に先立って、その情報伝達路からメッセージを受信する機能処理部が存在するかどうかを判断する(ステップ3911〜3914)。具体的には、情報伝達路への各機能処理部の接続状況は、接続状態データベースに格納されているので、そのアクセス位置を初期化し(ステップ3911)、アクセス位置を更新しながら(ステップ3914)、接続状態データベースのうち少なくともその情報伝達路に関する全項目を調査し(ステップ3913)、その情報伝達路からメッセージを受信する機能処理部(受信機能と呼ぶ)があればステップ3902以降の手順に進むが、受信機能がなければ手順を終了する。
【0253】
なお、情報伝達路からのメッセージ受信は、図33に示したフローチャートと同様の処理手順にしたがって行われる。
【0254】
〔6−3.第6実施形態の効果〕
以上のように、第6実施形態では、受信する機能処理部が存在しない情報伝達路へはメッセージを送出しないことで、不要な伝送を削減し、ネットワーク3が持つ帯域幅を最大限生かした分散監視制御システムの運用が可能となる。
【0255】
〔7.第7実施形態〕
第7実施形態は、請求項11,24,29に対応するもので、多重化された情報伝達路の各系統に送信する同一のメッセージに送信元と識別情報を付加し、同じ送信元及び識別情報のメッセージは、先着優先で受信し、後着は廃棄することで、情報伝達路を物理的に冗長化し信頼性を向上させた例である。
【0256】
〔7−1.第7実施形態の構成〕
まず、図40は、第7実施形態の構成を示す機能ブロック図である。すなわち、第7実施形態では、各機能処理部4〜7,9,11,16,17などの構成は第1実施形態と略同様であるが、情報伝達路は複数の系統に冗長化されており、各装置の各配信処理部18は、同一の情報伝達路の複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加し、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信するように構成されている。
【0257】
〔7−2.第7実施形態の作用〕
上記のように構成された第7実施形態における配信処理部18の配信制御手段18cは、情報伝達路へのメッセージ送出に対し、伝送装置2とネットワーク装置3が複数の系統(以下経路という)に冗長化されている場合、送信元と、送信元毎の識別情報である一連番号を付した同一内容のメッセージを経路毎に送出する。
【0258】
また、配信制御手段18cは、送信元ごとに、受信した最新メッセージの一連番号を記憶・管理し、同じ送信元すなわち発信元から同じ一連番号を持つメッセージを受信した場合は、先着優先で、異なる経路を経て到着した後着のメッセージを廃棄する。
【0259】
例えば、図41は、配信制御手段18cが情報伝達路からメッセージを受信する処理手順を示すフローチャートであり、図42は、この処理において、同じ発信元から情報伝達路を経て受信された最新のメッセージの一連番号を記憶するデータベース(着信データベースと呼ぶ)の構成例を示す図である。
【0260】
ここで、図41の手順のうちステップ4101〜4103は、第1実施形態で示した図7のステップ701〜703と同様に、情報伝達路に接続して受信を要求している。また、図41のステップ4109〜4112は、第1実施形態で示した図7のステップ704〜707と同様に、各機能処理部に対応するメッセージキューに受信データを書き込んでいる。
【0261】
そして、図41の手順では、ステップ4103とステップ4109との間で、次のような処理を行っている。すなわち、情報伝達路からメッセージを受け取った配信制御手段18cは、その情報伝達路について同じ発信元からのメッセージ関する情報を探して(ステップ4105)、着信データベースのアクセス位置を更新していく(ステップ4106)。
【0262】
そして、同じ発信元に関する情報が見付かった場合(ステップ4105)、受け取ったメッセージの一連番号が、同じ発信元からの最新一連番号(単に最新とも呼ぶ)以下の場合(ステップ4113)、同じメッセージを過去に情報伝達路から受け取り済であるから、ステップ4102からの処理に移る。一方、一連番号が最新以下でない場合は(ステップ4113)、受け取ったのは新しいメッセージであるから、着信データベースの一連番号を、受信メッセージの一連番号で更新する(ステップ4116)。
【0263】
なお、着信データベース中の情報の全てについて調査を完了しても、受け取ったメッセージと発言元が一致する情報が見付からない場合は(ステップ4107)、その発言元から受け取った初めてのメッセージであるから、着信データベースにその発言元と、情報伝達路と、一連番号と、を新しく登録する(ステップ4108)。
【0264】
なお、第7実施形態におけるメッセージの送信やメッセージキューからの読み込みは、第1実施形態について図8に示したフローチャートと同様の処理手順で行えばよい。
【0265】
〔7−3.第7実施形態の効果〕
以上のように、第7実施形態では、多重化された情報伝達路の各系統に同一のメッセージを送信するとき、送信元と、系統ごとに例えばメッセージ送出の都度増加する一連番号のような識別情報を付加する。そして、受信側の代表機能処理部などが配信処理部を介してメッセージを受信する場合、同じ送信元及び識別情報のメッセージは、先着優先で受信し、後着は廃棄する。
【0266】
このようにすれば、情報伝達路を物理的に冗長化することで信頼性が向上し、情報伝達路を通過する時点でコリージョン等による消滅やそれによる欠落部分の再送が減少し、ネットワークが持つ帯域幅を最大限生かした運転操作が行える様になる。
【0267】
〔8.第8実施形態〕
第8実施形態は、請求項12に対応するもので、障害で配信処理部と構成処理部しか稼動しなくなった装置を自動リセットなどで再起動させ、機能の早期復旧を図るようにした例である。
【0268】
〔8−1.第8実施形態の構成〕
この第8実施形態における全体構成や各機能処理部4〜7,9,11,16,17の構成は、第4実施形態(図25)と略同様であるが、第8実施形態における各装置は、第4実施形態で説明したような自発的な機能停止などにより、装置上で配信処理部と構成処理部のみが稼動しており、機能処理部が1つも稼動していない状態となった場合に、その装置をリセットするように構成されている。
【0269】
〔8−2.第8実施形態の作用〕
この第8実施形態において、構成処理部17は、機能処理部の機能障害を検出するとそれを、装置内の各機能処理部に情報伝達路RASを介して通知する。この場合、各機能処理部が、発生した機能障害からの影響度に応じて、自発的な機能終了を繰り返した結果、その装置上で稼動している部分が配信処理部と構成処理部のみとなるような場合も考えられる。
【0270】
図43は、構成処理部17について、このような場合に装置を単位としてリセットを行う処理を含む動作手順を示すフローチャートである。すなわち、第8実施形態における構成処理部17の動作手順は、全体的には、図17に示した処理手順と略同様であるが、第8実施形態では、図17における各機能処理部の診断と稼動状態の送出(ステップ1703)の具体的な手順が、図43に示す手順となる。
【0271】
この手順では、全機能の稼動調査を完了した後で(ステップ4309)、構成処理部17は、その装置上の全ての機能が稼動停止しているかどうかを判断し(ステップ4311)、配信処理部と構成処理部の他に、機能処理部が1つも稼動していない場合に、その装置をリセットする。
【0272】
〔8−3.第8実施形態の効果〕
以上のように、第8実施形態では、障害の影響が大きく配信処理部と構成処理部しか稼動していない状態となった装置については、本来の監視及び制御に対する貢献がなくなることから自動的にリセットし、所定の機能処理部を再起動することで機能の早期復旧を図りシステム全体の可用性を向上させる事が出来る。
【0273】
特に、機能障害の発生を装置内の各機能処理部に対して情報伝達路RASを介して通知し、各機能処理部ごとに対応を独自に判断させ、その結果に基づいて装置単位のリセットの判断をすることで、構成処理部は、全体への影響度を判断するための知識などを予め持っていることが不要となる。
【0274】
〔9.第9実施形態〕
第9実施形態は、請求項13に対応するもので、同じ機能の機能処理部のうち、健全度が最高の装置上のものを常用系とすることで、安定運用を可能にする例である。
【0275】
〔9−1.第9実施形態の構成〕
この第9実施形態では、各機能処理部4〜7,9,11,16や配信処理部18の構成などを含む全体的な構成及び作用は、図25などで示した第4実施形態に準じるが、第9実施形態における各機能処理部については、まず、機能処理部の障害に対応するため、同じ機能を果たす複数の機能処理部が、互いに異なった装置上に設けられ、そのうち1つが実際に前記機能を果たす常用系となり、他が、前記常用系の障害時に代替するための待機系となるように構成されている。
【0276】
また、第9実施形態では、そのような複数の機能処理部のうち、健全度が最高の装置上の機能処理部が常用系となるように構成されている。ここで健全度とは、各装置ごとの健全さや信頼度を表す指標であり、具体的には各装置のハードウェア各部について検出された状態から予め決められた基準で計算されたものである。
【0277】
具体的には、第9実施形態における構成処理部17は、各装置の健全度を計算するように構成され、各機能処理部4〜7,9,11,16は、このように計算された健全度に基づいて、複数の機能処理部のうち、健全度が最高の装置上の機能処理部が常用系となるように構成されている。
【0278】
〔9−2.第9実施形態の作用〕
上記のように構成された第9実施形態において、各構成処理部17の動作手順は、第4実施形態の図17に準じるが、ハードウェアの診断と稼動状態の送出(図17のステップ1702)では、第4実施形態における図19と異なり、図44に示すように、全ハードウェアを調査するまで(ステップ4407)、各ハードウェアについて正常かどうかの診断を続ける(ステップ4402)。
【0279】
また、第9実施形態における構成処理部17は、各機能処理部の診断と稼動状態の送出(ステップ1703)において、第4実施形態における図20と異なり、図45に示すように、計算した健全度を情報伝達路RASに送出する(ステップ4510)。
【0280】
ここで、構成処理部17における健全度の計算について説明する。すなわち構成処理部17は装置内の各種ハードウェアの稼動状態に基づいて、健全度という無次元化した数値を計算し、情報伝達路RASを介して各機能処理部に通知する。一方、各機能処理部は、同じ機能についてどれか1つが常用となり他の一つ以上が待機となるように複数の機能処理部がそれぞれ別々の装置に配置された場合、お互いの健全度を交換することで、装置における健全度の高い方が常用となる様に調整する。
【0281】
すなわち、分散監視制御システムを構成する複数の各装置は、それぞれ、電源装置、演算装置、伝送装置等を冗長化出来る様に設計されており、冗長化された部分の一部に障害が発生していても、装置としては機能するように構成されている。構成処理部17は、このように冗長化された部分の稼動状態を調査し、障害の有無、或いは冗長化の有無、各装置のMTBF等から、装置としての健全度を算出する。
【0282】
例えば、図46に示す例では、装置の各部分についてMTBF(Mean Time Between Failures:平均故障間隔)に基づいた重み付けを行い、それに実装数すなわち稼動数を乗じた合計によって健全度を表現している例である。この図で(a)は健全度計算の元となる情報を表し、(b)は、装置の状態に応じて健全が変化することを示す概念図である。
【0283】
例えば、電源装置のMTBFが伝送装置に比較して短い場合、同一構成であっても電源装置が片系故障している装置と伝送装置が片系故障している装置では、後者の装置のほうが健全度は高くなる。
【0284】
また、履歴処理部のように、唯一の位置で稼動するものが、複数の装置に配置した場合、たとえハードウェアに障害がなくとも冗長化された装置と冗長化されていない装置とでは、冗長化された方を常用にする事が可用性を高める事が出来る。そして、各機能処理部の構成制御手段は常用権の獲得の際、この健全度をお互いが交換する事により、より健全度の高い方が、常用となる様に調整する。
【0285】
すなわち、図47は、第9実施形態において、各機能処理部が常用系と待機系の切り換えを行う場合の処理手順のうち、第4実施形態における図32に対応する部分を示すフローチャートである。この図に示すように、第9実施形態における機能処理部の構成制御手段は、同時に常用系になろうとしている他の装置上の機能処理部と比べても、自らが最大の健全度を持つと認識している場合だけ(ステップ4721)、送信権調停メッセージの再送を繰り返すが(ステップ4713,4701,4702)、そうでない場合は(ステップ4721)、待機系となる(ステップ4714,4715)。なお、送信権の獲得に関する他の事項は第4実施形態と同様である。
【0286】
〔9−3.第9実施形態の効果〕
以上のように、第9実施形態では、同じ機能を果たすことができる機能処理部を持つ装置が複数存在する場合、健全度の最も高い装置上の機能処理部が常用系となることで、システム全体の可用性を向上させることができる。特に、常用系となっていた機能処理部が障害を発生した場合でも、待機系である各機能処理部のうち健全度が最高の装置上のものが取って代わることにより、分散監視制御システムの安定運用が可能となる。
【0287】
〔10.第10実施形態〕
第10実施形態は、請求項14に対応するもので、メッセージの欠落を検出し送出側に欠落分の再送を要求することで、欠落部分を復旧され、通信の信頼性を維持する例である。
【0288】
〔10−1.第10実施形態の構成〕
この第10実施形態における全体構成や各機能処理部4〜7,9,11,16などの各部は、図40などで示した第7実施形態と略同様であるが、第10実施形態における配信処理部18は、情報伝達路から受信すべきメッセージの欠落分の検出と、そのメッセージの送出側に対する再送要求とを行うように構成されている。
【0289】
〔10−2.第10実施形態の作用〕
図48は、上記のように構成された第10実施形態における配信処理部18の配信制御手段18cが、情報伝達路からメッセージを受信する手順を示すフローチャートである。すなわち、配信処理部18の配信制御手段18cは、この手順では、各機能処理部が接続した情報伝達路について、第7実施形態について図42に示したと同様の着信データベースを用いて、送信元毎に受信した最新メッセージの一連番号を記憶・管理する。
【0290】
そして、非連続な一連番号を持つメッセージを受信すると(ステップ4814)、装置を接続する情報伝達路の性質、或いはメッセージ受信を行う代表機能処理部などの障害によって欠落が発生した事を検出し、受信メッセージの欠落を記録し(ステップ4815)、その情報伝達路からのメッセージを受信している各機能処理部に通知する。
【0291】
この場合、各機能処理部は、図49に示すように、受信メッセージの欠落が発生すると(ステップ4908)、欠落が発生したことを捜査結果の終了ステータスに設定するなどして(ステップ4910)、これに対する処理を行う。具体的には、欠落した部分を復旧する為の問合せメッセージQMを、情報伝達路への送出側に対して送出する。なお、例えば、情報伝達路TAGにおいて欠落が検出されると、欠落したものの内容は不明であるので情報伝達路TAGに対して、全情報の再送出を要求する事になる。
【0292】
〔10−3.第10実施形態の効果〕
以上のように、第10実施形態では、送信元毎の最新メッセージの一連番号を順次データベースに登録し、その後届いたメッセージの送信元や一連番号と照合するなどして、メッセージの欠落を検出すると送出側に欠落分の再送を要求する。これにより、装置を接続する情報伝達路の性質、或いはメッセージ受信を行う代表機能処理部の障害などによって、受信されるべきメッセージが欠落した場合でも、欠落部分が復旧され、通信の信頼性が維持される。特に、メッセージの受信に関わる配信処理部や機能処理部の判断で、メッセージの欠落がどの情報伝達路で発生したかに応じて異なった適切な復旧手順をとることが望ましい。
【0293】
〔11.第11実施形態〕
第11実施形態は、請求項15に対応するもので、監視サーバ装置などから提供される状態量などの履歴をグラフ表示する際、指定された期間内の最大値と最小値を予め決められた形式で示すことにより、履歴の理解を容易にする例を示すものである。
【0294】
〔11−1.第11実施形態の構成〕
この第11実施形態における各機能処理部4〜7,9,11,16などの各部分は、第1実施形態と略同様に構成されているが、第11実施形態における履歴処理部11は、情報伝達路HSDを介して、期間と監視点を指定して履歴データを問合せるメッセージQMを受け取ると、これに対して、状態量の変化を期間内の最大値と最小値にして応答メッセージRMとして出力するように構成されている。
【0295】
また、対話処理部16は、履歴処理部11が蓄積した履歴を、指定された期間内の最大値と最小値を予め決められた形式で示すグラフとして表示するように構成されている。
【0296】
〔11−2.第11実施形態の作用〕
以上のように構成された第11実施形態において、対話処理部16によって表示されるグラフの例を図50(a)に示す。すなわち、対話処理部16は、対話装置13を構成する表示装置14にグラフ表示する際、この図に示すように、過去の部分を履歴処理部11が蓄積した履歴データ12を表示装置の解像度に応じた期間内の最大値と最小値を用いて表示する。また、画面表示後の監視点の状態量の変化については、例えば、情報伝達路TAGからの通知メッセージNMに基づいて、同様に表示すればよい。
【0297】
上記のように表示する情報のうち過去の分は、履歴処理部11へ問い合わせて入手する。ここで、図50(b)は履歴データ処理部への問合せメッセージ、図51は、そのような問合せメッセージに対する履歴処理部11からの応答メッセージの構成例である。すなわち、履歴処理部11は、図1などに示した履歴データ12から、開始日時を基点として、指定された間隔毎に状態変化が記録されている場合はその最大値と最小値を求め、記録が無い場合はそれ以前の期間における最終値を最大値、及び最小値とする事によって、応答メッセージを生成し、返信する。
【0298】
特に、過去の期間における監視点の状態量の変化を再現するには、表示期間内の全ての履歴データ12を得るよりも、表示装置上での1画素に対応する期間を単位とし、その期間内の最大値と最小値を履歴処理部11から得て、最小値と最大値を結ぶ線を描く事により、効率的に再生する事が可能となる。
【0299】
これにより、例えば、1時間幅で表示するグラフ表示画面の画素数が200であれば18秒毎、1日間幅であれば432秒毎の最大値と最小値を用いて再生する事になり、表示期間が長くなる程、効率を高める事が出来る。
【0300】
〔11−3.第11実施形態の効果〕
以上のように、第11実施形態では、監視サーバ装置などから提供される状態量などの履歴をグラフ表示する際、指定された期間内の最大値と最小値を予め決められた形式で示すことにより、履歴の理解を容易にすることができる。
【0301】
〔12.他の実施の形態〕
なお、本発明は、上記格実施形態に限定されるものではなく、次に例示するような他の実施形態も含むものである。例えば、上記各実施形態に示した各装置や各機能処理部4〜7,9,11,16,17などの構成や、各種データの構成や、フローチャートで示した各種手順は例示にすぎず、実際にはそれらを適宜変更して実施できることはもちろんである。例えば、システム全体をいくつの装置によって構成するかは自由であり、特に、どの機能処理部をどの装置上に設けるかは自由に選択することができる。
【0302】
また、各装置を接続するネットワークの種類やネットワーク形態その他の具体的構成は自由であり、例えばFDDIやEthernetなどから自由に選択することができる。また、情報伝達路の数は4つには限定されず、3つ以内でも5つ以上でもよい。また、複数の情報伝達路を実現する具体的な態様も自由であり、例えば、ツイストペアケーブルや光ファイバケーブルなどの伝送媒体を実際に複数敷設してもよいし、周波数分割多重や時分割多重などによって実現することも考えられる。
【0303】
【発明の効果】
以上説明したように、本発明によれば、全体を停止させる事なく構成変更に柔軟に対応する分散監視制御の技術すなわち分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体を提供することができる。
【図面の簡単な説明】
【図1】本発明の第1実施形態における分散監視制御システムの構成を示す機能ブロック図。
【図2】本発明の第1実施形態において配信されるメッセージの構成例を示す概念図。
【図3】本発明の第1実施形態における配信データベースの構成例を示す概念図。
【図4】本発明の第1実施形態における配信登録手段の動作手順を示すフローチャート。
【図5】本発明の第1実施形態における配信登録手段が、情報伝達路と機能処理部とを接続する手順を示すフローチャート。
【図6】本発明の第1実施形態における配信登録手段が、情報伝達路と機能処理部とを接続解除する手順を示すフローチャート。
【図7】本発明の第1実施形態における配信制御手段が、情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図8】本発明の第1実施形態において、配信制御手段によるメッセージ送信及び機能処理部によるメッセージ読み込みの処理手順を示すフローチャート。
【図9】本発明の第2実施形態における分散監視制御システムの構成を示す機能ブロック図。
【図10】本発明の第2実施形態における配信データベースの構成例を示す概念図。
【図11】本発明の第2実施形態における配信登録手段の動作手順を示すフローチャート。
【図12】本発明の第2実施形態において、配信制御手段が情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図13】本発明の第2実施形態において、配信制御手段によるメッセージ送信及び機能処理部によるメッセージ読み込みの処理手順を示すフローチャート。
【図14】本発明の第2実施形態において、配信登録手段による接続解除の処理手順の一部を示すフローチャート。
【図15】本発明の第3実施形態における分散監視制御システムの構成を示す機能ブロック図。
【図16】本発明の第3実施形態における構成データベースの構造例を示す概念図。
【図17】本発明の第3実施形態における構成処理部の動作手順を示すフローチャート。
【図18】本発明の第3実施形態における構成処理部の動作手順のうち、初期化を行う部分を示すフローチャート。
【図19】本発明の第3実施形態における構成処理部の動作手順のうち、ハードウェアの診断と稼動状態の送出を行う部分を示すフローチャート。
【図20】本発明の第3実施形態における構成処理部の動作手順のうち、各機能処理部の診断と稼動状態の送出を行う部分を示すフローチャート。
【図21】本発明の第3実施形態における構成処理部の受信手段が、情報伝達路から各機能処理部の稼動状態を受信して構成データベースを更新したり、外部からの問合せに対して回答する処理手順を示すフローチャート。
【図22】本発明の第3実施形態における配信処理部による処理手順を示すフローチャート(前半)。
【図23】本発明の第3実施形態における配信処理部による処理手順を示すフローチャート(後半)。
【図24】本発明の第3実施形態における配信処理部について、情報伝達路にメッセージを送信する処理手順を示すフローチャート。
【図25】本発明の第4実施形態における分散監視制御システムの構成を示す機能ブロック図。
【図26】本発明の第4実施形態における配信データベースの構成例を示す概念図。
【図27】本発明の第4実施形態における構成処理部の動作手順を示すフローチャート。
【図28】本発明の第4実施形態における接続状態を表すメッセージの構成を示す概念図。
【図29】本発明の第4実施形態における配信登録手段の動作手順を示すフローチャート。
【図30】本発明の第4実施形態における送受信手段が稼動状態の通知や問合せ及び接続状態通知に関する処理を行う手順を示すフローチャート。
【図31】本発明の第4実施形態において、各機能処理部が常用系又は待機系に切り替わる処理手順を示すフローチャート(前半)。
【図32】本発明の第4実施形態において、各機能処理部が常用系又は待機系に切り替わる処理手順を示すフローチャート(後半)。
【図33】本発明の第4実施形態において、配信制御手段が情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図34】本発明の第4実施形態における配信登録手段が、情報伝達路と機能処理部とを接続する処理手順を示すフローチャート。
【図35】本発明の第5実施形態における配信データベースの構成例を示す概念図。
【図36】本発明の第5実施形態において、配信制御手段が情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図37】本発明の第6実施形態において、構成処理部の動作手順の一部を示すフローチャート。
【図38】本発明の第6実施形態における配信制御手段について、接続状態通知などの接続状況を他の装置から受信した場合に、自装置内の接続状況とマージする事により分散監視制御システム全体の接続状況を作成するなどの動作手順を示すフローチャート。
【図39】本発明の第6実施形態において、配信制御手段によるメッセージ送信及び機能処理部によるメッセージ読み込みの処理手順を示すフローチャート。
【図40】本発明の第7実施形態における分散監視制御システムの構成を示す機能ブロック図。
【図41】本発明の第7実施形態において、配信制御手段が情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図42】本発明の第7実施形態における着信データベースの構成例を示す概念図。
【図43】本発明の第8実施形態における構成処理部の動作手順の一部を示すフローチャート。
【図44】本発明の第9実施形態における構成処理部の動作手順の一部を示すフローチャート。
【図45】本発明の第9実施形態における構成処理部の動作手順の一部を示すフローチャート。
【図46】本発明の第9実施形態における健全度について、計算の基礎となるデータの例(a)及び健全度の概念を示す図(b)。
【図47】本発明の第9実施形態において、各機能処理部が常用系又は待機系に切り替わる処理手順の一部を示すフローチャート。
【図48】本発明の第10実施形態において、配信制御手段が情報伝達路からメッセージを受信する処理手順を示すフローチャート。
【図49】本発明の第10実施形態において、機能処理部がメッセージキューから受信データを読み込む処理手順を示すフローチャート。
【図50】本発明の第11実施形態におけるグラフの表示例(a)及びそのもとになるメッセージの構成を示す概念図(b)。
【図51】本発明の第11実施形態において、問合せメッセージに対する履歴処理部11からの応答メッセージの構成例。
【図52】従来技術に関する分散監視制御システムの一例を示す機能ブロック図。
【符号の説明】
1…プロセス入出力装置
2…伝送装置
3…通信ネットワーク
4…入力処理部
4a…入力処理手段
4b…入力処理部の構成制御手段
5…計算処理部
5a…計算処理手段
5b…計算処理部の構成制御手段
6…出力処理部
6a…出力処理手段
6b…出力処理部の構成制御手段
7…データベース処理部
7a…DB処理手段
7b…データベース処理部の構成制御手段
8…データベース
9…警報処理部
9a…警報処理手段
9b…警報処理部の構成制御手段
10…警報リスト
11…履歴処理部
11a…履歴処理手段
11b…履歴処理部の構成制御手段
12…履歴データ
13…対話装置
14…表示装置
15…入力装置
16…対話処理部
16a…対話処理手段
16b…対話処理部の構成制御手段
17…構成処理部
18…配信処理部
18a…配信データベース
18b…配信登録手段
18c…配信制御手段
18d…配信切離手段
19…構成データベース
21,P…制御装置
22…監視装置
22a,S…監視サーバ装置
22b,C…監視クライアント装置
TAG…監視・操作点の状態量の情報伝達路
ALM…警報点の情報伝達路
HSD…履歴データの情報伝達路
RAS…構成管理の情報伝達路

Claims (27)

  1. 互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御システムにおいて、
    前記ネットワークは複数の情報伝達路を備え、
    前記各装置は、前記監視及び制御に関する処理を行うための少なくとも1つの機能処理部と、前記通信に関する処理を行うための配信処理部と、を備え、
    前記配信処理部は、前記情報伝達路と前記機能処理部との対応関係を登録するための配信データベースと、
    前記対応関係を前記データベースに登録するための配信登録手段と、
    登録された前記対応関係に基づいて、前記通信を制御するための配信制御手段と、を備え
    前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、
    前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、を備え、
    前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、
    同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を備えたことを特徴とする分散監視制御システム。
  2. 少なくとも1つの前記装置において、複数の前記機能処理部のうち予め決められた代表機能処理部が、前記通信における送受信データについて、他の各機能処理部を代表して前記配信処理部との間で受け渡しするとともに前記各機能処理部に対して受け渡しするように構成されたことを特徴とする請求項1記載の分散監視制御システム。
  3. 前記各機能処理部は、前記監視制御対象から得られる状態量を第1の情報伝達路に送信するための第1の機能処理部と、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信するための第2の機能処理部と、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力するための第3の機能処理部と、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信するための第4の機能処理部と、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力するための第5の機能処理部と、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信するための第6の機能処理部と、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力すると共に、前記監視制御対象に対する運転操作を入力するための第7の機能処理部と、を含むことを特徴とする請求項1又は2記載の分散監視制御システム。
  4. 前記各機能処理部は、当該機能処理部の稼動状況を判断して第4の情報伝達路に出力するための構成制御手段を備え、前記各装置は、各装置又は各機能処理部のうち少なくとも一方に関する稼動状態を予め決められた情報伝達路に送信するための構成処理部を備えたことを特徴とする請求項3記載の分散監視制御システム。
  5. 少なくとも1つの前記装置は、前記各機能処理部から参照されるための共有メモリを備え、前記情報伝達路に係るメッセージについて、前記共有メモリに格納するとともに、そのメッセージを受信すべき全ての機能処理部からの参照を受けたときに廃棄することを特徴とする請求項1からのいずれか1つに記載の分散監視制御システム。
  6. 前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部が、前記配信処理部との受け渡しを前記各機能処理部を代表して行うと共に、他の前記各機能処理部に対して受け渡しするように構成され、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせるための手段を備えたことを特徴とする請求項1からのいずれか1つに記載の分散監視制御システム。
  7. 前記構成処理部は、障害が発生した機能処理部を他の機能処理部に対して知らせるように構成され、前記各機能処理部は、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択するように構成されたことを特徴とする請求項4からのいずれか1つに記載の分散監視制御システム。
  8. 前記配信登録手段は、各機能処理部が受信するメッセージのカテゴリを予め前記配信データベースに登録するように構成され、前記配信制御手段は、送信メッセージにカテゴリを設定し、受信メッセージはその受信メッセージに設定されているカテゴリに対応する各機能処理部にのみ配信するように構成されたことを特徴とする請求項1からのいずれか1つに記載の分散監視制御システム。
  9. 前記各装置の前記各配信処理部は、各装置においてどの情報伝達路にどの機能処理部が対応付けられているかを表す接続状況を交換することにより、分散監視制御システム全体における接続状況を作成し、前記システム全体における接続状況に基づいて、メッセージを送信しようとする情報伝達路からメッセージを受信する機能処理部が分散監視制御システム内に存在するかどうかを判断し、メッセージを送信しようとする情報伝達路からメッセージを受信する機能処理部が分散監視制御システム内に存在しない場合は、当該メッセージを情報伝達路に送出しないように構成されたことを特徴とする請求項1からのいずれか1つに記載の分散監視制御システム。
  10. 複数の系統に冗長化された情報伝達路を備え、前記各装置の各配信処理部は、同一の情報伝達路の複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加し、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信するように構成されたことを特徴とする請求項1からのいずれか1つに記載の分散監視制御システム。
  11. 装置上の機能処理部が、他の機能処理部で発生した障害に基づいて停止した結果、前記装置上で配信処理部と構成処理部のみが稼動しており、機能処理部が稼動していない状態となった場合に、当該装置をリセットするための手段を備えたことを特徴とする請求項4から10のいずれか1つに記載の分散監視制御システム。
  12. 同じ機能を果たす複数の機能処理部が、互いに異なった装置上に設けられ、そのうち1つが実際に前記機能を果たす常用系となり、他が、前記常用系の障害時に代替するための待機系となるように構成され、前記複数の機能処理部のうち、各装置のハードウェア各部について検出された状態から予め決められた基準で計算された各装置ごとの健全度が、最高の装置上の機能処理部が常用系となるように構成されたことを特徴とする請求項1から11のいずれか1つに記載の分散監視制御システム。
  13. 情報伝達路から受信すべきメッセージの欠落分の検出と、そのメッセージの送出側に対する再送要求とを行うように構成されたことを特徴とする請求項1から12のいずれか1つに記載の分散監視制御システム。
  14. 前記第7の機能処理部は、第6の機能処理部が蓄積した履歴を、指定された期間内の最大値と最小値を予め決められた形式で示すグラフとして表示するように構成されたことを特徴とする請求項3から13のいずれか1つに記載の分散監視制御システム。
  15. 互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御方法において、前記ネットワークにおいて複数の情報伝達路を用い、前記各装置に、前記監視及び制御に関する処理を行うためのプロセスとして、少なくとも1つの機能処理部と、前記通信に関する処理を行うためのプロセスとして配信処理部と、を設け、前記配信処理部が、前記情報伝達路と前記機能処理部との対応関係を、配信データベースに登録するためのステップと、前記配信処理部が、登録された前記対応関係に基づいて、前記通信を制御するためのステップと、を含み、
    前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、
    前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、有し、
    前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、
    同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を有することを特徴とする分散監視制御方法。
  16. 少なくとも1つの前記装置において、複数の前記機能処理部のうち予め決められた代表機能処理部が、前記通信における送受信データについて、他の各機能処理部を代表して前記配信処理部との間で受け渡しするとともに前記各機能処理部に対して受け渡しすることを特徴とする請求項15記載の分散監視制御方法。
  17. 前記各機能処理部のうち、第1の機能処理部が、前記監視制御対象から得られる状態量を第1の情報伝達路に送信するためのステップと、第2の機能処理部が、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信するためのステップと、第3の機能処理部が、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力するためのステップと、第4の機能処理部が、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信するためのステップと、第5の機能処理部が、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力するためのステップと、第6の機能処理部が、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信するためのステップと、第7の機能処理部が、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力すると共に、前記監視制御対象に対する運転操作を入力するステップと、を含むことを特徴とする請求項15又は16記載の分散監視制御方法。
  18. 前記各機能処理部が、当該機能処理部の稼動状況を判断して第4の情報伝達路に出力するための構成制御ステップと、前記各装置が、各装置又は各機能処理部のうち少なくとも一方に関する稼動状態を予め決められた情報伝達路に送信するための構成処理ステップと、を含むことを特徴とする請求項17記載の分散監視制御方法。
  19. 少なくとも1つの前記装置において、前記各機能処理部から参照されるための共有メモリを用い、前記情報伝達路に係るメッセージについて、前記共有メモリに格納するためのステップと、前記共有メモリに格納された各メッセージを、そのメッセージを受信すべき全ての機能処理部からの参照を受けたときに廃棄するためのステップと、を含むことを特徴とする請求項16から18のいずれか1つに記載の分散監視制御方法。
  20. 前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部が、前記配信処理部との受け渡しを前記各機能処理部を代表して行うと共に、他の前記各機能処理部に対して受け渡しするためのステップと、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせるためのステップと、を含むことを特徴とする請求項16から19のいずれか1つに記載の分散監視制御方法。
  21. 障害が発生した機能処理部を他の機能処理部に対して知らせるためのステップと、前記各機能処理部が、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択するためのステップと、を含むことを特徴とする請求項16から20のいずれか1つに記載の分散監視制御方法。
  22. 複数の系統に冗長化された情報伝達路を用い、前記各装置の各配信処理部が、同一の情報伝達路の複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加するためのステップと、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信するためのステップと、を含むことを特徴とする請求項16から21のいずれか1つに記載の分散監視制御方法。
  23. コンピュータを用いて、互いにネットワーク接続された複数の装置間で通信を行うことで、監視制御対象を監視及び制御するための分散監視制御用ソフトウェアを記録した記録媒体において、そのソフトウェアは前記コンピュータに、前記ネットワークにおいて複数の情報伝達路を用いさせ、前記各装置に、前記監視及び制御に関する処理を行うためのプロセスとして、少なくとも1つの機能処理部と、前記通信に関する処理を行うためのプロセスとして配信処理部と、を設けさせ、
    前記配信処理部に、前記情報伝達路と前記機能処理部との対応関係を、配信データベースに登録する配信登録処理と、
    前記配信処理部に、登録された前記対応関係に基づいて、前記通信を制御する配信制御処理と、を実行させ、
    前記配信データベースは、1つの情報伝達路と1つの機能処理部とをそれぞれ対応付けるブロックと、
    前記各情報伝達路ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応する少なくとも1つの前記ブロックを指すポインタのリストと、
    前記各機能処理部ごとに対応するメッセージの格納領域を示す指標と、有し、
    前記各ブロックは、同じ情報伝達路をいずれかの機能処理部に対応付けている各ブロック同士を順次接続するための第1の双方向リンクと、
    同じ機能処理部をいずれかの情報伝達路に対応付けている各ブロック同士を順次接続するための第2の双方向リンクと、を有することを特徴とする分散監視制御用ソフトウェアを記録した記録媒体。
  24. 前記ソフトウェアは前記コンピュータに、前記各機能処理部のうち、第1の機能処理部に、前記監視制御対象から得られる状態量を第1の情報伝達路に送信させ、第2の機能処理部に、前記状態量が予め決められた基準を超えて変動したときにその旨の通知を第1の情報伝達路に送信させ、第3の機能処理部に、前記状態量を前記監視制御対象又は予め決められた対象のうち少なくとも一方に対して出力させ、第4の機能処理部に、前記第1の情報伝達路に送信された情報の少なくとも一部について、最新の値を蓄積し及び少なくとも問合せに対して第1の情報伝達路に送信させ、第5の機能処理部に、前記状態量に基づく警報に関する情報を第2の情報伝達路に出力させ、第6の機能処理部に、前記状態量の履歴を蓄積し及び少なくとも問合せに対して第3の情報伝達路に送信させ、第7の機能処理部に、前記最新の値、前記履歴又は前記警報に関する情報のうち少なくとも1つを出力させると共に、前記監視制御対象に対する運転操作の入力を受け付けさせることを特徴とする請求項23記載の分散監視制御用ソフトウェアを記録した記録媒体。
  25. 前記ソフトウェアは前記コンピュータに、前記情報伝達路について送受信されるデータについて、その情報伝達路に対応する複数の機能処理部から選択される代表機能処理部に、前記配信処理部との受け渡しを前記各機能処理部を代表して行わせると共に、他の前記各機能処理部に対して受け渡しさせ、前記代表機能処理部に障害が発生した場合に、当該代表機能処理部が行っていた前記受け渡しを、他の前記各機能処理部のいずれかに引継がせることを特徴とする請求項23又は24記載の分散監視制御用ソフトウェアを記録した記録媒体。
  26. 前記ソフトウェアは前記コンピュータに障害が発生した機能処理部を他の機能処理部に対して通知させ、前記各機能処理部には、前記障害の内容又は前記障害が発生した機能処理部への依存度のうち少なくとも一方に基づいて、機能縮退、他の装置上で待機する機能処理部の起動、又は自発的な機能停止のうち少なくとも1つを選択させることを特徴とする請求項23から25のいずれか1つに記載の分散監視制御用ソフトウェアを記録した記録媒体。
  27. 前記ソフトウェアは前記コンピュータに、前記各装置の各配信処理部が、同一の情報伝達路について冗長化された複数の系統に同一のメッセージを送出するとき、送信元及び当該送信元におけるメッセージの識別情報をメッセージに付加させ、同一の送信元及び識別情報を持つ複数のメッセージは先着優先で受信させることを特徴とする請求項23から26のいずれか1つに記載の分散監視制御用ソフトウェアを記録した記録媒体。
JP24375999A 1999-08-30 1999-08-30 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体 Expired - Lifetime JP4299928B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP24375999A JP4299928B2 (ja) 1999-08-30 1999-08-30 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP24375999A JP4299928B2 (ja) 1999-08-30 1999-08-30 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体

Publications (2)

Publication Number Publication Date
JP2001067334A JP2001067334A (ja) 2001-03-16
JP4299928B2 true JP4299928B2 (ja) 2009-07-22

Family

ID=17108573

Family Applications (1)

Application Number Title Priority Date Filing Date
JP24375999A Expired - Lifetime JP4299928B2 (ja) 1999-08-30 1999-08-30 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体

Country Status (1)

Country Link
JP (1) JP4299928B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253391A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003162305A (ja) * 2001-11-27 2003-06-06 Toshiba Corp 制御システム
JP4506520B2 (ja) * 2005-03-16 2010-07-21 日本電気株式会社 管理サーバ、メッセージの抽出方法、及び、プログラム
JP4672684B2 (ja) * 2007-02-09 2011-04-20 株式会社東芝 電力系統監視制御サービス提供システム
FR2925190B1 (fr) * 2007-12-18 2009-11-20 Alcatel Lucent Procede et dispositif de communication entre plusieurs interfaces de connexion
JP5682502B2 (ja) 2011-08-11 2015-03-11 富士通株式会社 情報処理プログラムおよび情報処理装置
CN104809932B (zh) * 2015-04-22 2017-09-01 北京广利核***工程有限公司 一种核电厂数字化安全级控制***模拟装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011253391A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム

Also Published As

Publication number Publication date
JP2001067334A (ja) 2001-03-16

Similar Documents

Publication Publication Date Title
CN1980192B (zh) 多机架路由器中的不间断转发
EP1110148B1 (en) Fault tolerant computer system
US7518983B2 (en) Proxy response apparatus
US20030005350A1 (en) Failover management system
JP5982842B2 (ja) コンピュータ障害監視プログラム、方法、及び装置
JP5486793B2 (ja) リモートコピー管理システム、方法及び装置
JP2004519024A (ja) 多数のノードを含むクラスタを管理するためのシステム及び方法
CN100394394C (zh) 容错双工计算机***及其控制方法
JPH086910A (ja) クラスタ型計算機システム
JP4299928B2 (ja) 分散監視制御システム及び方法並びに分散監視制御用ソフトウェアを記録した記録媒体
JPH08212095A (ja) クライアントサーバ制御システム
JPH0660000A (ja) 情報処理システムおよび情報処理方法
US5894547A (en) Virtual route synchronization
JP2011203941A (ja) 情報処理装置、監視方法、および監視プログラム
JP6134720B2 (ja) 接続方法
JP3121487B2 (ja) プロセッサモジュール間接続通信システム
KR100832543B1 (ko) 계층적 다중 백업 구조를 갖는 고가용성 클러스터 시스템및 이를 이용한 고가용성 구현 방법
JPH1127266A (ja) 網管理装置の構成情報管理方式および管理対象装置
JP4848979B2 (ja) 監視システムおよび監視方法ならびにプログラム
JP2002132535A (ja) 分散型計算機システムにおける計算機診断方式
JP2001101108A (ja) 分散型監視システム
JP2829040B2 (ja) 情報集配信システム
JPH05304528A (ja) 多重化通信ノード
JP2009211279A (ja) 操業データ管理サーバシステム
JP3176945B2 (ja) 情報処理装置、待機冗長型システムおよび待機冗長型システムの主系と待機系との間でチェックポイントをとる方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070320

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071106

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080107

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: 20090331

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090420

R151 Written notification of patent or utility model registration

Ref document number: 4299928

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120424

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130424

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140424

Year of fee payment: 5

EXPY Cancellation because of completion of term