(57)【要約】【課題】専用線ネットワーク通信による現在の監視制御システム系の装置がもつ機能、処理方式を変更することなく、オープンネットワークを利用した通信・監視・制御システム系へ移行できる。【解決手段】連携型専用ユニット６〜１０は、システムを構築する各装置１〜５とはそれぞれの構内ＬＡＮとオープンネットワークとの間に設ける。  連携型専用ユニットは、各装置との情報交換用にホワイトボードまたはプロキシを設け、各装置のアプリケーションは公開可能な情報をホワイトボード上に掲示または委譲し、他のアプリケーションが自由に参照可能とする。  さらに、連携型専用ユニットは、セキュリティ機能、アプリケーション連携機能、多重化システムへの対応機能をもつ。【選択図】  図１
2005209048.tif 000002
【特許請求の範囲】
【請求項１】
システムを構築するテレコン、監視室用マンマシン装置、データメンテナンスサーバなどの各装置が分散配置され、各装置は既存ネットワークを介して互いの装置間で通信、監視、制御情報を送受信処理する手段を備えた監視制御システムにおいて、
各装置とはそれぞれ分離構成または一体構成で各装置の構内ＬＡＮとＩＰネットワークとの間に設けられ、各装置の互いの通信方式およびデータ処理方式の違いを吸収してＩＰネットワークを介して各装置間の通信、監視、制御情報を送受信処理する連携型専用ユニットを設けたことを特徴とする監視制御システム。
【請求項２】
前記連携型専用ユニットは、
ホワイトボードモデルを該連携型専用ユニット上の共有ファイルアーキテクチャで実現する各装置間の情報交換用のホワイトボード（共有メモリ空間）をもつ構造とし、各装置のアプリケーションは公開してよい情報をホワイトボード（共有メモリ空間）上に掲示し、掲示された情報は他のアプリケーションから自由に参照可能とし、資源のセマフォ管理は全てホワイトボード用ミドルウェアが処理する通信処理手段を設けたことを特徴とする請求項１に記載の監視制御システム。
【請求項３】
前記連携型専用ユニットは、前記ホワイトボードモデルを共有ファイルアーキテクチャで実現する公開ディレクトリをもつ構造とし、この公開ディレクトリのファイルはＦＴＰまたはＮＦＳによって移動、読み書きを可能とし、ＦＴＰを使用するときはファイルの作成途中については、他からのアクセスを防止するために、ファイルが完成するまでの間は仮のファイル名を用い、ファイルが完成した後に公開されているファイル名に切り替えることを特徴とする請求項２に記載の監視制御システム。
【請求項４】
前記連携型専用ユニットは、
前記各装置とＩＰネットワークの境界に、各装置間のデータ交換を委譲するプロキシモデルを設け、各装置のアプリケーションは、公開可能な情報をプロキシモデルに委譲し、他の装置のアプリケーションに前記プロキシモデルに委譲された情報を直接送付またはイベント伝達、および他のアプリケーションから参照可能とし、資源のセマフォ管理は全てプロキシモデル用ミドルウェアが処理をする通信処理手段を設けたことを特徴とする請求項１に記載の監視制御システム。
【請求項５】
前記連携型専用ユニットは、前記プロキシモデルを共有データオブジェクトモデルアーキテクチャで実現し、データオブジェクトモデルと共有ディレクトリに格納された共有ファイルのみを外部に公開し、データオブジェクトモデルには広域ロードシェアシステムに共通で必要なリソースを格納し、
連携型専用ユニット名とＩＰアドレスなどのネットワークリソースは全ての連携型専用ユニットがそれぞれ同じ情報を連携型専用ユニットオブジェクト内に持ち、ＩＰネットワークに公開を望む全てのデータを該オブジェクトに登録し、各アプリケーションとデータオブジェクトモデルとのやりとりは、ＳＯＡＰまたはＣＯＲＢＡもしくは個々に用意するアプリケーションコンポーネントで行うことを特徴とする請求項４に記載の監視制御システム。
【請求項６】
前記連携型専用ユニットは、前記データオブジェクトモデルのうち、連携型専用ユニットオブジェクトとグループオブジェクトは、各オブジェクトごとにファイリング機能を持ち、
ファイル保存のタイミングは、各オブジェクトのプロパティに指定された周期、または各オブジェクトへのファイル保存リクエスト、あるいは連携型専用ユニットオブジェクトのファイル保存つきシャットダウンリクエストによって行い、
ファイル読み込みのタイミングは、各オブジェクトへのオブジェクト再構築リクエスト、または連携型専用ユニットの立ち上げ時に自動的に行い、
ファイルは指定のない限り特定の非共有ディレクトリに保存し、共有ディレクトリ指定で他のノードからファイルによる参照を可能としたことを特徴とする請求項１〜５のいずれか１項に記載の監視制御システム。
【請求項７】
前記連携型専用ユニットは、各装置毎の通信方式およびデータ処理方式の違いを吸収する通信処理手段、システムへの侵入やデータ盗聴、改ざんの予防対策としてのセキュリティ手段、各装置での障害発生が他の装置へ影響するのを防止する手段、イベントコントロールサービス手段、ネットワーク通信の管理手段、各装置の運転モード切り替え手段を備えたことを特徴とする請求項１〜６のいずれか１項に記載の監視制御システム。
【請求項８】
前記セキュリティ手段は、プロキシ、ファイアウォール、暗号化、認証の処理手段を設け、
前記通信方式の違いを吸収する通信処理手段は、プロトコル変換処理手段を設け、
前記データ処理方式の違いを吸収する通信処理手段は、データオブジェクトの種類、データ管理オブジェクト、計測値オブジェクト、ＧＵＩオブジェクト、マルチメディアオブジェクト、ネットワークサービスへのアクセスと共有ファイルアクセスオブジェクトを処理するデータオブジェクトサーバを設け、
前記イベントコントロールサービス手段は、操作オブジェクトプロパティ、メッセージオブジェクトプロパティ、ネットワークサービスによるアクセスの処理手段を設け、
前記ネットワーク通信の管理手段は、ノード管理、コンポーネント管理、データベース位置管理、ユーザ管理の手段を設け、
前記運転モード切替手段は、通常運転モード、運転待機モード、運転訓練モードの切り替え手段を設けたことを特徴とする請求項１〜７のいずれか１項に記載の監視制御システム。
【請求項９】
前記連携型専用ユニットのセキュリティ手段は、構内ＬＡＮで接続される内部装置との通信は暗号化せず、他の連携型専用ユニット間の通信は暗号化したことを特徴とする請求項１〜８のいずれか１項に記載の監視制御システム。
【請求項１０】
前記セキュリティ手段は、多元的セキュリティポリシを用い、その実現はセキュアＯＳを用い、サブジェクト・オブジェクト管理は独自に対象を定めて管理することを特徴とする請求項９に記載の監視制御システム。
【請求項１１】
前記連携型専用ユニットのオブジェクトになるアプリケーションプログラムの単位は、ＲＯＯＭアーキテクチャのコンポーネントをベースとすることを特徴とする請求項９に記載の監視制御システム。
【請求項１２】
前記連携型専用ユニットのオブジェクトになるデータファイルとデータオブジェクトの管理は全てデータオブジェクトモデル内で行い、データファイルのオブジェクトラベルは共有ディレクトリクラスで定義し、データオブジェクトのオブジェクトラベルはデータオブジェクトクラスで定義し、複数のデータオブジェクトを一括アクセスする対象に対してのオブジェクトラベルはグループクラスで定義し、サブジェクトラベルとオブジェクトラベルのリファレンスモニタ（セキュリティテーブル）は連携型専用ユニットクラスで定義することを特徴とする請求項９に記載の監視制御システム。
【請求項１３】
前記連携型専用ユニット間は、ＲＯＯＭポート機構を利用して、データオブジェクトモデルで発生するイベントとアプリケーションコンポーネントを連携することを特徴とする請求項１〜８に記載の監視制御システム。
【請求項１４】
前記アプリケーションコンポーネントは、ファイル更新通知手段を設け、この手段によって共有ファイルを利用した通信を行い、ファイル更新イベントはデータオブジェクトモデル中にある共有ディレクトリクラスのメンバによって管理することを特徴とする請求項１３に記載の監視制御システム。
【請求項１５】
前記アプリケーションコンポーネントは、通信プロトコルコンポーネントを設け、このコンポーネントは、
定周期にテレコンから計測データをＳＣＡＤＡに送信する周期計測と、
非周期計測で、ＳＣＡＤＡからの計測タイミングでテレコンの計測データをＳＣＡＤＡに送信し、計測データがリフレッシュ有りのときはＳＣＡＤＡ側とテレコン側の両方のキャッシュをキャンセルしてテレコンから最新の計測データを送信し、リフレッシュ無しのときは最寄の連携型専用ユニットのキャッシュにある計測データを送信するデマンド計測と、
ＳＣＡＤＡからテレコンに返事を要求または要求しない制御命令を送信する制御命令と、
テレコンからＳＣＡＤＡに返事を要求しないイベントやメッセージを送信するイベント・アラームと、
連携型専用ユニットに対して返事を要求する制御命令を送信する連携型専用ユニット制御とを備えたことを特徴とする請求項１３に記載の監視制御システム。
【請求項１６】
前記連携型専用ユニットは、データオブジェクトクラスに宣言されたメンバの書き換えにより発生するイベントによりアプリケーションロジックを起動し、前記アプリケーションロジックには連携型専用ユニットに組み込みのものと、ユーザが自由に書き換え可能なものを設け、ユーザが書き換え可能なものはＲＯＯＭポートの宣言でアプリケーションコンポーネントと連携させることを特徴とする請求項１３に記載の監視制御システム。
【請求項１７】
前記装置が構内ＬＡＮ接続で常用装置と待機・訓練用装置を二重化した監視制御システム構成において、
前記連携型専用ユニットは、二重化して同じ構内ＬＡＮに接続し、フリーランデュアル方式で動作する構成とし、
前記各連携型専用ユニットは、
それぞれ系ごとにデータオブジェクトモデルを持つ場合と、１つだけもつ場合を選択可能とし、データオブジェクトモデルを１つだけもつ場合は共用グループオブジェクト群を先着優先後着廃棄処理または、後着優先処理を行う構成とし、
共有データオブジェクトディレクトリ構成として、それぞれ系ごとのディレクトリを持つ場合と、１つの共用データオブジェクトディレクトリを持つ場合を選択可能とし、前記常用装置と待機・訓練用装置に対してそれが常用モードか待機・訓練モードかによって、どちらのディレクトリをアクセスするかのパスを割り振り、前記共用データオブジェクトディレクトリを先着優先後着廃棄処理または、後着優先処理を行う構成としたことを特徴とする請求項１〜８に記載の監視制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信を利用した監視制御システム（電力送配電網、上水配水網、ガス供給網などの監視制御システム）に係り、特に既存ネットワーク通信による現在の監視制御システム系を、ＩＰ（Internet Protocol）ネットワークを利用した通信・監視・制御システム系へ移行するための監視制御システムに関する。
【背景技術】
【０００２】
現在の監視制御システムは、図３５に例を示すように、コストダウンを目的とし、既存ネットワークによる監視制御情報の通信に加えて、ＩＰネットワークを通信媒体として、汎用品・汎用技術を採用した監視制御用システム、サーバ、コントローラを各地に分散配置するオープン分散システムとして構築されてきている。同時に、図３６に電力分野での例を示すように、監視制御システムには、基本的な監視制御機能の他に、情報開示・監視制御高度化など、従来にない新しいニーズが発生している。
【０００３】
近年では、パソコン等の普及により、関連する技術の進展が著しく、次世代システムにおいては、汎用品・汎用技術を大幅に採用したシステムとして構築されることが予想される。また、ネットワークの活用により、システムの大規模集約、分散配置および相互バックアップ等、技術的な制約のない自由なシステム構成が可能となっている。
【０００４】
このようなシステム構成を支援するため、インターネット等における異なるコンピュータ間をセキュリティを確保して自由に接続可能にした通信機能、コンピュータ間のデータ管理機能、目的とするシステムを構築するためのアプリケーション開発機能をもつシステムや手法が種々提案されている（例えば、非特許文献１、２、３参照）。
【非特許文献１】ＯＰＣ（OLE  for  Process  Control）技術概要書、Version２、日本ＯＰＣ協議会技術部会、１９９９年１１月発行、
【非特許文献２】オペレーティングシステムのアクセスコントロール機能におけるセキュリティポリシーモデル、情報処理振興事業協会セキュリティセンター、
【非特許文献３】電気協同研究第５８巻、第４号「電力用通信網へのＩＰネットワークの適用性評価・システム設計技術、電力用ＩＰネットワーク技術専門委員会、社団法人電気協同研究会、平成１４年１１月２８日発行、
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前記の次世代システムが、ネットワークによる広域分散システムとして構成されることを想定した場合、従来システムでの既存ネットワークを利用したテレコン（遠方監視制御装置）との通信から、どのようにＩＰネットワーク通信へ移行していくかについて、以下のような課題が想定される。
【０００６】
（１）図３７に既存ネットワークをそのままＩＰネットワーク化した場合の問題例を示すように、次世代システムとテレコンとを再び既存ネットワークで接続することは、通信回線の構築コストやシステムインターフェースの新規開発費用等、コストの増大要因であるため現実的ではないし、種々の不都合が生じることが予想される。
【０００７】
だからといって、既存ネットワークをなくし、単純に既設ＩＰ網を利用しても、複数の通信網からの侵入や盗聴、改ざんの危険度が増すので、各構内ＬＡＮ（Local Area Network）あるいはコンピュータ毎のセキュリティ確保が必要となり、投資とＣＰＵ負荷の２重のコストアップにつながる。
【０００８】
（２）障害時のトラブルの影響が広がりやすい弱点もある。
【０００９】
（３）監視制御システムに業務支援システムなどから直接に情報交換要求が許される事になり、それに答えるため監視制御システムの運転に必要な安定したスループットが保証できなくなる可能性がある。
【００１０】
また、この構成では、図３８に監視制御ネットワークと業務用ネットワークの一元化の問題例を示すように、制御所・電気所（発変電所）のＩＰ化への移行も段階的に行うことが困難である。
【００１１】
本発明の目的は、既存ネットワーク通信による現在の監視制御システム系の装置がもつ機能、処理方式を変更することなく、ＩＰネットワークを利用した通信・監視・制御システム系へ移行できる監視制御システムを提供することにある。
【課題を解決するための手段】
【００１２】
前記の課題を解決するための本発明は、以下の構成を特徴とする。
【００１３】
（連携型専用ユニットの基本構成）
（１）システムを構築するテレコン、監視室用マンマシン装置、データメンテナンスサーバなどの各装置が分散配置され、各装置は既存ネットワークを介して互いの装置間で通信、監視、制御情報を送受信処理する手段を備えた監視制御システムにおいて、
各装置とはそれぞれ分離構成または一体構成で各装置の構内ＬＡＮとＩＰネットワークとの間に設けられ、各装置の互いの通信方式およびデータ処理方式の違いを吸収してＩＰネットワークを介して各装置間の通信、監視、制御情報を送受信処理する連携型専用ユニットを設けたことを特徴とする。
【００１４】
（２）前記連携型専用ユニットは、
ホワイトボードモデルを該連携型専用ユニット上の共有ファイルアーキテクチャで実現する各装置間の情報交換用のホワイトボード（共有メモリ空間）をもつ構造とし、各装置のアプリケーションは公開してよい情報をホワイトボード（共有メモリ空間）上に掲示し、掲示された情報は他のアプリケーションから自由に参照可能とし、資源のセマフォ管理は全てホワイトボード用ミドルウェアが処理する通信処理手段を設けたことを特徴とする。
【００１５】
（３）前記連携型専用ユニットは、前記ホワイトボードモデルを共有ファイルアーキテクチャで実現する公開ディレクトリをもつ構造とし、この公開ディレクトリのファイルはＦＴＰまたはＮＦＳによって移動、読み書きを可能とし、ＦＴＰを使用するときはファイルの作成途中については、他からのアクセスを防止するために、ファイルが完成するまでの間は仮のファイル名を用い、ファイルが完成した後に公開されているファイル名に切り替えることを特徴とする。
【００１６】
（４）前記連携型専用ユニットは、
前記各装置とＩＰネットワークの境界に、各装置間のデータ交換を委譲するプロキシモデルを設け、各装置のアプリケーションは、公開可能な情報をプロキシモデルに委譲し、他の装置のアプリケーションに前記プロキシモデルに委譲された情報を直接送付またはイベント伝達、および他のアプリケーションから参照可能とし、資源のセマフォ管理は全てプロキシモデル用ミドルウェアが処理をする通信処理手段を設けたことを特徴とする。
【００１７】
（５）前記連携型専用ユニットは、前記プロキシモデルを共有データオブジェクトモデルアーキテクチャで実現し、データオブジェクトモデルと共有ディレクトリに格納された共有ファイルのみを外部に公開し、データオブジェクトモデルには広域ロードシェアシステムに共通で必要なリソースを格納し、
連携型専用ユニット名とＩＰアドレスなどのネットワークリソースは全ての連携型専用ユニットがそれぞれ同じ情報を連携型専用ユニットオブジェクト内に持ち、ＩＰネットワークに公開を望む全てのデータを該オブジェクトに登録し、各アプリケーションとデータオブジェクトモデルとのやりとりは、ＳＯＡＰまたはＣＯＲＢＡもしくは個々に用意するアプリケーションコンポーネントで行うことを特徴とする。
【００１８】
（６）前記連携型専用ユニットは、前記データオブジェクトモデルのうち、連携型専用ユニットオブジェクトとグループオブジェクトは、各オブジェクトごとにファイリング機能を持ち、
ファイル保存のタイミングは、各オブジェクトのプロパティに指定された周期、または各オブジェクトへのファイル保存リクエスト、あるいは連携型専用ユニットオブジェクトのファイル保存つきシャットダウンリクエストによって行い、
ファイル読み込みのタイミングは、各オブジェクトへのオブジェクト再構築リクエスト、または連携型専用ユニットの立ち上げ時に自動的に行い、
ファイルは指定のない限り特定の非共有ディレクトリに保存し、共有ディレクトリ指定で他のノードからファイルによる参照を可能としたことを特徴とする。
【００１９】
（７）前記連携型専用ユニットは、各装置毎の通信方式およびデータ処理方式の違いを吸収する通信処理手段、システムへの侵入やデータ盗聴、改ざんの予防対策としてのセキュリティ手段、各装置での障害発生が他の装置へ影響するのを防止する手段、イベントコントロールサービス手段、ネットワーク通信の管理手段、各装置の運転モード切り替え手段を備えたことを特徴とする。
【００２０】
（８）前記セキュリティ手段は、プロキシ、ファイアウォール、暗号化、認証の処理手段を設け、
前記通信方式の違いを吸収する通信処理手段は、プロトコル変換処理手段を設け、
前記データ処理方式の違いを吸収する通信処理手段は、データオブジェクトの種類、データ管理オブジェクト、計測値オブジェクト、ＧＵＩオブジェクト、マルチメディアオブジェクト、ネットワークサービスへのアクセスと共有ファイルアクセスオブジェクトを処理するデータオブジェクトサーバを設け、
前記イベントコントロールサービス手段は、操作オブジェクトプロパティ、メッセージオブジェクトプロパティ、ネットワークサービスによるアクセスの処理手段を設け、
前記ネットワーク通信の管理手段は、ノード管理、コンポーネント管理、データベース位置管理、ユーザ管理の手段を設け、
前記運転モード切替手段は、通常運転モード、運転待機モード、運転訓練モードの切り替え手段を設けたことを特徴とする。
【００２１】
（連携型専用ユニットのセキュリティ機能）
（９）前記連携型専用ユニットのセキュリティ手段は、構内ＬＡＮで接続される内部装置との通信は暗号化せず、他の連携型専用ユニット間の通信は暗号化したことを特徴とする。
【００２２】
（１０）前記セキュリティ手段は、多元的セキュリティポリシを用い、その実現はセキュアＯＳを用い、サブジェクト・オブジェクト管理は独自に対象を定めて管理することを特徴とする。
【００２３】
（１１）前記連携型専用ユニットのオブジェクトになるアプリケーションプログラムの単位は、ＲＯＯＭアーキテクチャのコンポーネントをベースとすることを特徴とする。
【００２４】
（１２）前記連携型専用ユニットのオブジェクトになるデータファイルとデータオブジェクトの管理は全てデータオブジェクトモデル内で行い、データファイルのオブジェクトラベルは共有ディレクトリクラスで定義し、データオブジェクトのオブジェクトラベルはデータオブジェクトクラスで定義し、複数のデータオブジェクトを一括アクセスする対象に対してのオブジェクトラベルはグループクラスで定義し、サブジェクトラベルとオブジェクトラベルのリファレンスモニタ（セキュリティテーブル）は連携型専用ユニットクラスで定義することを特徴とする。
【００２５】
（連携型専用ユニットのアプリケーション連携機能）
（１３）前記連携型専用ユニット間は、ＲＯＯＭポート機構を利用して、データオブジェクトモデルで発生するイベントとアプリケーションコンポーネントを連携することを特徴とする。
【００２６】
（１４）前記アプリケーションコンポーネントは、ファイル更新通知手段を設け、この手段によって共有ファイルを利用した通信を行い、ファイル更新イベントはデータオブジェクトモデル中にある共有ディレクトリクラスのメンバによって管理することを特徴とする。
【００２７】
（１５）前記アプリケーションコンポーネントは、通信プロトコルコンポーネントを設け、このコンポーネントは、
定周期にテレコンから計測データをＳＣＡＤＡに送信する周期計測と、
非周期計測で、ＳＣＡＤＡからの計測タイミングでテレコンの計測データをＳＣＡＤＡに送信し、計測データがリフレッシュ有りのときはＳＣＡＤＡ側とテレコン側の両方のキャッシュをキャンセルしてテレコンから最新の計測データを送信し、リフレッシュ無しのときは最寄の連携型専用ユニットのキャッシュにある計測データを送信するデマンド計測と、
ＳＣＡＤＡからテレコンに返事を要求または要求しない制御命令を送信する制御命令と、
テレコンからＳＣＡＤＡに返事を要求しないイベントやメッセージを送信するイベント・アラームと、
連携型専用ユニットに対して返事を要求する制御命令を送信する連携型専用ユニット制御とを備えたことを特徴とする。
【００２８】
（１６）前記連携型専用ユニットは、データオブジェクトクラスに宣言されたメンバの書き換えにより発生するイベントによりアプリケーションロジックを起動し、前記アプリケーションロジックには連携型専用ユニットに組み込みのものと、ユーザが自由に書き換え可能なものを設け、ユーザが書き換え可能なものはＲＯＯＭポートの宣言でアプリケーションコンポーネントと連携させることを特徴とする。
【００２９】
（連携型専用ユニットの多重化機能）
（１７）前記装置が構内ＬＡＮ接続で常用装置と待機・訓練用装置を二重化した監視制御システム構成において、
前記連携型専用ユニットは、二重化して同じ構内ＬＡＮに接続し、フリーランデュアル方式で動作する構成とし、
前記各連携型専用ユニットは、
それぞれ系ごとにデータオブジェクトモデルを持つ場合と、１つだけもつ場合を選択可能とし、データオブジェクトモデルを１つだけもつ場合は共用グループオブジェクト群を先着優先後着廃棄処理または、後着優先処理を行う構成とし、
共有データオブジェクトディレクトリ構成として、それぞれ系ごとのディレクトリを持つ場合と、１つの共用データオブジェクトディレクトリを持つ場合を選択可能とし、前記常用装置と待機・訓練用装置に対してそれが常用モードか待機・訓練モードかによって、どちらのディレクトリをアクセスするかのパスを割り振り、前記共用データオブジェクトディレクトリを先着優先後着廃棄処理または、後着優先処理を行う構成としたことを特徴とする。
【発明の効果】
【００３０】
以上のとおり、本発明によれば、既存ネットワーク通信による現在の監視制御システム系の装置がもつ機能、処理方式を変更することなく、ＩＰネットワークを利用した通信・監視・制御システム系へ移行できる。
【００３１】
具体的には、システム構築には、ＩＰネットワーク統合化が可能、ネットワーク構成の変化に柔軟に対応可能、構内ＬＡＮ保護が可能、情報共有化を容易に実現可能、段階的移行が可能、障害発生時の影響範囲を小さくすることができるなどの効果が期待できる。
【００３２】
また、セキュリティ面では、段階的な移行のしやすさと高い可用性を保ちながら、侵入防止、盗聴防止、改ざん防止、成りすまし防止のような高いセキュリティ機能を容易に構築することができる。
【００３３】
また、アプリケーションの連携のうち、通信プロトコルコンポーネントの実装面では、連携型専用ユニットに容易に通信プロトコルコンポーネントが実装できるようになる。さらに、連携型専用ユニットに通信プロトコルを追加する際は、アプリケーションは属性を変更するｓｅｔ＿ｐｒｏｐａｔｙなどの同一のアプリケーションインタフェースで全ての操作をすることが可能となる。また、送信タイミングも任意におこなえるようになる。また、組み込む通信プロトコルが状態を持つとき、状態を全てデータオブジェクトモデルに格納することが可能となり、通信プロトコルコンポーネントをステートレスに作成することが可能となった。これにより生産性と品質向上の効果が得られる。
【００３４】
また、アプリケーションの連携のうち、アプリケーションロジックコンポーネントの実装面では、アプリケーションコンポーネントの宣言的仕様を実現することで、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上できる。
【００３５】
また、多重化システムには、連携型専用ユニットはフリーランデュアル方式で動作するので、構成制御プログラムを汎用化できる。アプリケーションと独立しているのでプログラムをシンプルにすることが可能である。そのことにより生産性と品質を向上することが期待できる。また、制御信号に対してべき等性のないデータが、ひとつもない連携型専用ユニットは、制御信号を出しても影響はないので、基本連携型専用ユニットを使ってシステムを簡略化できる。
【００３６】
また、連携型専用ユニットは共用データオブジェクトモデルを持つが、その利用で、アプリケーションは多重系を気にせず監視制御データにアクセスできる。
【発明を実施するための最良の形態】
【００３７】
図１は、本発明における監視制御システムの基本構成を示す。分散配置されてシステムを構築する各装置（図示では、電力用監視制御システムを構築するための発変電所用などの電気所用テレコン１、２、３、監視室用マンマシン装置４、データメンテナンスサーバ５などで示すが、上水道網やガス供給網の場合も同様になる）は、それらの間の通信、監視、制御情報をオープンネットワークになるＩＰネットワーク（例えば、電力ＩＰネットワーク）を介して送受信するシステム構成とする。各装置１〜５は、ＩＰネットワークを介して他の装置との通信及びデータ収集を行う手段として連携型専用ユニット（Ｆａｃａｄｅ：Federate  Appliance  unit  to  Communication  and  data  Acquisition  with  Distributed  Equipments）６〜１０をそれぞれ分離構成または一体構成でＩＰネットワークとの接続を可能にする。
【００３８】
各Ｆａｃａｄｅ６〜１０は、各装置１〜５をその通信方式およびデータ処理方式を変更することなく、そのまま、電力ＩＰネットワークによる通信を可能とする。このＩＰネットワークによる通信を可能とするため、Ｆａｃａｄｅ６〜１０は、各装置毎の通信方式およびデータ処理方式の違いを吸収する機能、システムへの侵入やデータ盗聴、改ざんの予防対策としてのセキュリティ確保機能、および各装置での障害発生が他の装置へ影響するのを防止する機能などを備える。
【００３９】
これら機能を実現するため、Ｆａｃａｄｅ６〜１０は、以下の基本機能を搭載する。
【００４０】
〇各装置１〜５のセキュリティ確保（外部からの各装置へのアクセスを遮断する）には、以下の機能を設ける。
【００４１】
・プロキシ
・ファイアウォール
・暗号化
・認証
〇各装置１〜５の通信方式の違いを吸収するため、例えば、以下のプロトコル変換機能を設ける。
【００４２】
・Ｇａｔｅｗａｙの役割（例えば、ＨＤＬＣ（High-level Data Link Control procedure)⇔ＩＰ）
〇各装置１〜５のデータ処理方式の違いを吸収するためのデータオブジェクトサーバを設け、以下のデータ処理機能を設ける（モバイルエージェントによるキャッシング機能とファイリング機能付）。
【００４３】
・データオブジェクトの種類
・管理オブジェクト（構成制御）
・計測値オブジェクト（グループ化可能）
・ＧＵＩ（Graphical User Interface）オブジェクト（グループ化可能）
・マルチメディアオブジェクト
・Ｗｅｂサービス（またはＣＯＲＢＡ：Common Object Request Broker Architecture）アクセス（タイトコミュニケーション）と共有ファイルアクセス（ルーズコミュニケーション）
〇各装置１〜５のイベントコントロールサービス機能として、以下の機能を設ける。
【００４４】
・操作オブジェクトプロパティ
・メッセージオブジェクトプロパティ
・Ｗｅｂサービスによるアクセス
〇各装置１〜５間のネットワーク通信のために、以下のネットワーク管理機能を設ける。
【００４５】
・ノード管理
・コンポーネント管理
・データベース位置管理
・ユーザ管理（認証サーバ、運転モードとの連携）
〇各装置１〜５の運転モードを切替可能とするために、以下の管理機能を設ける。
【００４６】
・通常運転モード
・運転待機モード
・運転訓練モード
以上のような基本機能をソフトウェア構成で搭載するＦａｃａｄｅについて、以下、機能別に説明する。
【００４７】
（１）分散配置される装置間の通信およびデータ収集機能
（Ａ）ホワイトボードモデルによる情報公開
Ｆａｃａｄｅは、ホワイトボードモデルをＦａｃａｄｅ上の共有ファイルアーキテクチャで実現し、図２に示すように、公開してよい情報をホワイトボード（共有メモリ空間）に提示する。提示された情報はＩＰネットワークを介して他のどの装置からも読むことができる。
【００４８】
ホワイトボードモデルは、一般的にはエキスパートシステムで、自律的な機能を持つソフトウェアのコンポーネント（デーモン）が、知識を共有するために利用する共有メモリ空間をホワイトボード（ブラックボードを用いることもある）いうメタファーで呼んだものである。
【００４９】
ホワイトボードは物理的にはＦａｃａｄｅに接続される装置（テレコンなど）の構内ＬＡＮと１対１に対応しているが、構内ＬＡＮの各端末からは論理的には全部が結合しているように見える。各端末は、接続された構内ＬＡＮに接続した専用のホワイトボードに他から参照を許すデータを登録することを可能にする。このデータには、そのデータに対するアクセス権の制限を登録することもできる。
【００５０】
各端末は、接続された構内ＬＡＮに接続した専用のホワイトボードへ自分が登録したデータに、いつでも書き込むことができる（それ以外のデータに書き込みはできない）。各端末は、ホワイトボード上の自分がアクセスする権限を持ったデータはすべて、いつでも参照ができる。
【００５１】
以上のホワイトボードモデルにより情報公開することで、以下の作用効果を得ることができる。
【００５２】
・１つのＩＰネットワークで、各構内ＬＡＮのセキュリティを保ちながら情報を共有できる。
【００５３】
・構内ＬＡＮとＩＰネットワークが疎結合なので、システムの段階的な移行が可能となり、変化に対応しやすい。特に、データ書式にＸＭＬ（eXtensible Markup Language）を用いれば、データの授受に対して内容の自動変換も容易に組み込むことが可能となる。
【００５４】
・障害発生時のトラブルの影響範囲を小さくすることができる。
【００５５】
・ホワイトボードに対する書き込みと読み出しが非同期なので、プログラムが単純になる。
【００５６】
（Ｂ）Ｆａｃａｄｅの公開ディレクトリ
Ｆａｃａｄｅは、上記のホワイトボードモデルを実装するためのデータ処理機能として、以下の手段をもつ。
【００５７】
図３に示すように、公開ディレクトリをもち、公開情報のファイルはＦＴＰ（File Transfer Protocol)またはＮＦＳ(Network File System)によって移動、読み書きをする。ＦＴＰを使用するときは作成途中に、他からのアクセスを防止するために、ファイルが完成するまでは仮のファイル名を用いる。ファイルが完成したら公開されているファイル名に切り替える。
【００５８】
また、データオブジェクトディレクトリにはデータオブジェクトのファイル形式のものが格納される。これには３種類の形式を採用し、データオブジェクトモデルのグループクラスのファイルプロパティで設定する。
【００５９】
１．データオブジェクトの全データをＸＭＬシリアライズしたもの。
【００６０】
２．データオブジェクトのデータ部分だけをＸＭＬシリアライズしたもの。
【００６１】
３．電力向けのときは、データオブジェクトのデータ部分をIEC61970の計測値クラスのスキーマで格納したもの。
【００６２】
構内ＬＡＮの各ノードに割り当てたディレクトリ内のファイルの書式は、自由書式とするが、電力向けの応用の場合はIEC61970のクラス定義に準拠したスキーマを用意するので、それを利用すれば、汎用的な情報の交信が可能となる。
【００６３】
（Ｃ）プロキシモデルによる情報公開
上記のホワイトボードモデルによる情報公開には、以下の欠点がある。
【００６４】
・書き込みと読み出しの同期が取れていないので、全体のスループットが悪くなる。また、リアルタイムイベントの通知や、制御命令の通知ができない。
【００６５】
・トランザクション（アプリケーション失敗時にロールバックを可能にする）込みの通信サービスに対応ができない。
【００６６】
このホワイトボードモデルの短所を補うために、プロキシモデルをＦａｃａｄｅ上の共有データオブジェクトモデルアーキテクチャで実現し、図４に示すように、公開してよい情報をプロキシモデルで提供する。
【００６７】
一般的にプロキシは、ＩＰネットワークでローカルノードに、インターネット上の目的のコンテンツ（ファイルやＷｅｂページ等）をユーザのコンピュータの代わりに取って来てくれる機能を提供するサーバに使われる名称である。ここでは、データ委譲したものどおしで互いのデータを代役としてやり取りをさせることから、この名称を用いた。
【００６８】
Ｆａｃａｄｅは、ＩＰネットワーク上にプロキシエージェント（委譲代理人）を設ける。プロキシエージェントは、構内ＬＡＮから公開するデータの委譲を受け、管理を行う。プロキシエージェントは、プロキシエージェント間で直接、暗号を用いたコミュニケーションを行い、リアルタイム性を必要とするデータの送受信や、イベントメッセージや制御命令の通知を行う。
【００６９】
構内ＬＡＮに接続される各端末は、プロキシエージェントに委譲したデータに、いつでも書き込むことができる（それ以外のデータに書き込みはできない）。他の端末が委譲したデータでも、自分がアクセスする権限を持ったデータはすべて、いつでも参照ができる。また、各端末は、他の構内ＬＡＮの端末にイベントや命令を通知することができる。
【００７０】
以上のプロキシモデルにより情報公開することで、以下の作用効果を得ることができる。
【００７１】
・委譲するデータは定形なので、ホワイトボードモデルよりも高速な通信・アクセスが可能である。
【００７２】
・リアルタイム性を必要とするデータの送受信や、イベントメッセージや制御命令を通知できる。
【００７３】
・アプリケーション失敗時にロールバックを可能にするトランザクションのような、複雑なプロトコルにも対応が可能となる。ただし、通信のセンターにそういったステートフルなプロトコルを組み込むことはシステム全体の信頼性を低下させるので、組み込むことは必要最小限に抑えるべきである。
【００７４】
・１つのＩＰネットワークで、各構内ＬＡＮのセキュリティを保ちながら情報を共有できる。
【００７５】
・構内ＬＡＮとＩＰネットワークが疎結合なので、段階的な移行が可能となり、変化に対応しやすい。
【００７６】
・障害時のトラブルの影響範囲を小さくすることができる。
【００７７】
・書き込みと読み出しが非同期で済むアプリケーションの場合は、プログラムが単純になる。
【００７８】
しかし、プロキシモデルによる情報公開には、以下の欠点があるため、プロキシモデルとホワイトボードモデルは、互いに短所を補完するので併用することが望ましい。
【００７９】
・機能が多いぶん、ホワイトボードモデルよりも制限が多く、自由度が低くなる。
【００８０】
・制御所のように、非常に多くの電気所（発電所・変電所）から情報が集中する場所では、スループットに対する対策が必要となる。
【００８１】
（Ｄ）Ｆａｃａｄｅのデータオブジェクトモデル
Ｆａｃａｄｅは、図５に示すクラス関係のデータオブジェクトモデルをもち、データオブジェクトモデルと共有ディレクトリに格納された共有ファイルのみを外部に公開する。
【００８２】
このデータオブジェクトモデルは、ＯＰＣ（Ole  for  Process  Control）の構造に似せてある。これはＯＰＣ対応の端末製品やＯＰＣサーバとの接続を容易にするためである。また、データオブジェクトモデルには、ＩＰネットワークで分散された広域ロードシェアシステムに共通で必要なリソースが格納される。また、Ｆａｃａｄｅの名前とＩＰアドレスなどのネットワークリソースは全Ｆａｃａｄｅがそれぞれ同じ情報をＦａｃａｄｅオブジェクト内に持つ。また、ＦａｃａｄｅはＩＰネットワークに接続するＬＡＮの接点に位置するが、ＬＡＮ内でＩＰネットワークに公開を望む全てのデータを、ここに登録する。
【００８３】
ＬＡＮ内の各アプリケーションとデータオブジェクトモデルとのやりとりは、ＳＯＡＰ（Simple Object Access Protocol)またはＣＯＲＢＡ、または個々に用意するアプリケーションコンポーネントで行う。構内ＬＡＮ内のアプリケーションプログラムから、ＳＯＡＰ（またはＣＯＲＢＡ）でアクセスするためのインタフェース定義に、ＷＳＤＬ（Web Service Description Language)またはＩＤＬ(Interface Definition Language）モジュールを用意する。例えば、図６にＦａｃａｄｅのアプリケーションコンポーネントアーキテクチャを示すように、Ｆａｃａｄｅとテレコン（クライアント）との間の通信にＷｅｂサービスを利用する場合、ＷＳＤＬ仕様のデータオブジェクトモデルをＷｅｂサービスコンバータで変換し、Ｆａｃａｄｅとクライアント間はＳＯＡＰ（Simple  Object  AccessProtocol)を利用してメッセージ交換や監視制御データを交換する。
【００８４】
図５におけるデータオブジェクトモデルのＦａｃａｄｅオブジェクトとグループオブジェクトは、各オブジェクトごとにファイリング機能（ＸＭＬシリアライズ＋ファイル読み書き）を持つ。ファイル保存のタイミングは、各オブジェクトのプロパティに指定された周期、または各オブジェクトへのファイル保存リクエスト、あるいはＦａｃａｄｅオブジェクトのファイル保存つきシャットダウンリクエストによって行う。ファイル読み込みのタイミングは、各オブジェクトへのオブジェクト再構築リクエスト、あるいはＦａｃａｄｅ立ち上げ時に自動的に行う。特に指定のない限り、特定の非共有ディレクトリに保存する。共有ディレクトリを指定すると、他のノードからファイルによる参照が可能となる。
【００８５】
公開ディレクトリのアクセス権とイベント通知用の情報も、このモデル内に納められる。
【００８６】
以上の機能構成になる分散配置される装置間の通信およびデータ収集機能によれば、システムを統合化、ネットワーク構成の変化に柔軟に対応可能、構内ＬＡＮ保護が可能、情報共有化を容易に実現可能、段階的移行が可能、障害発生時の影響範囲を小さくすることができるなどの効果が期待できる。
【００８７】
（２）装置間のデータ収集のセキュリティ機能
（Ａ）セキュリティの概要
図７にセキュリティ模式図を示すように、Ｆａｃａｄｅが守る対象はＩＰネットワークに接続された各種サーバシステムとデータ、および遠方監視装置に代表される各種制御端末機器とそのデータである。Ｆａｃａｄｅのセキュリティ機能は、これらに対する不正な侵入、盗聴、改ざん、破壊を防止する。
【００８８】
Ｆａｃａｄｅシステムが設置される監視制御センターや発変電所や営業所は、セキュアな環境で運用されている。特定のオペレータのみがアクセスを許されているのが現状である。
【００８９】
セキュリティを考えると、電力ＩＰネットワーク構築の際は、外部から一切アクセスのできないイントラネットで構成するのが望ましい。接続するコンピュータも、特定のＩＰを持つ計算機のみしかアクセスできないようにすることが望ましい。
【００９０】
しかし、外部からの情報開示要求や、サービス向上、業務支援システムとの連携、基幹システムとの連携などのニーズによる外部接続の増大が見込まれる。そこで、Ｆａｃａｄｅは、以下に説明するように、ＬＡＮ、無線ＬＡＮ、ＷＡＮ（Wide Area Network)、その他通信網からの侵入や盗聴、改ざんを防止する。
【００９１】
（Ｂ）侵入防止
図８に例を示すように、Ｆａｃａｄｅは外部から構内ＬＡＮへの直接のアクセスは全て拒絶（ブロック）する。一方、構内ＬＡＮから外部へのアクセスは基本的に制限しない。
【００９２】
（Ｃ）盗聴防止
図９に例を示すように、Ｆａｃａｄｅ間の通信（データオブジェクト、ファイル）は全て暗号化する。
【００９３】
Ｆａｃａｄｅは互いにデータオブジェクトと公開ファイルデータの交信を行う。盗聴をさけるためにＦａｃａｄｅ間の全ての通信は暗号化する。暗号化はイントラネットにおいてはＩＰｓｅｃ(Security Architecture for Internet Protocol)で行う。
【００９４】
Ｆａｃａｄｅと電力ＩＰネットワーク間に別のファイアウォールがあるときは、データオブジェクト通信はＳＯＡＰを使用し、インターネットにおいてはＷＳＳＥＣ(WS-Security)で暗号化する。また、ファイルもＸＭＬ化し同様にＷＳＳＥＣセキュリティで暗号化し、セキュリティをかける。
【００９５】
構内ＬＡＮについては、セキュアな環境と、ランニング時のスループットの確保と、可用性を考慮して、無暗号で送受信を行う。
【００９６】
（Ｄ）改ざん防止
Ｆａｃａｄｅ内部のセキュリティポリシーモデルは図１０に示すように、全てのデータへのアクセスを正しく監視するために、リファレンスモニタという考えを導入する。
【００９７】
リファレンスモニタとはコンピュータ上に存在する全データに対するアクセスをコントロールするためのものであり、リファレンスモニタは悪意のあるプロセスによって修正されたり回避されたりしてはならない。
【００９８】
プロセスの正確な振る舞いの可能性はプログラムの数、サイズ、および複雑さにつれて減少する。したがって、正確なポリシー強化の最良の保障は、小さく単純で認識可能なリファレンスモニタを用意する。
【００９９】
ＦａｃａｄｅはセキュアＯＳの多元的なセキュリティポリシーモデルを利用しセキュリティを確保する。リファレンスモニタはＦａｃａｄｅ固有のものを用意し、オブジェクト（対象物）とサブジェクト（主体）を管理する。編集可能なＷｅｂ対応のＨＭＩ(Human Mashine Interface)も用意する。
【０１００】
上記のＦａｃａｄｅのセキュリティポリシの主体（サブジェクト）となる対象は、以下の表に示す
【０１０１】
【表１】
2005209048.tif 000003
【０１０２】
上記の実行タスクサブジェクトについては、Ｆａｃａｄｅ内部にアーキテクチャを組み込み、データオブジェクトモデルからリンクされたコンポーネントにサブジェクトラベルをつけ、セキュリティポリシの確認に利用する。
【０１０３】
図１１はＲＯＯＭアーキテクチャ（Real-time Object-Oriented Modeling:Bran Selic著）内でのサブジェクトアプリケーションタスクの取り扱い例を示す。
【０１０４】
同図において、各ＲＯＯＭポートは相手先とプロトコルの組み合わせテーブルで構成し、必ずｉｎとｏｕｔのペアで構成する。同じプロトコルと引数を持つポートをクラス化して、モジュールを共通化する。
【０１０５】
図１１におけるデータオブジェクトモデルは、ｉｎポートからの通信リクエストでそのハンドリングを行う。状態変化などでデータオブジェクトがイベントを発生させたとき、該当するデータオブジェクトやグループオブジェクトに指定されたＲＯＯＭポートにメッセージを出力する。
【０１０６】
また、プロトコルやアプリケーションロジックのコンポーネント（入力と出力が明確に定義されたアプリケーション）は、ＲＯＯＭで言うアクターに相当する。
【０１０７】
また、アプリケーション通信（既設システムとの交信を含む）はプロトコル変換（手順の変換）とデータ変換（パケット⇔データオブジェクト）を行う。
【０１０８】
前記のＦａｃａｄｅのセキュリティポリシーのオブジェクト（対象物）は、以下の表に示す。
【０１０９】
【表２】
2005209048.tif 000004
【０１１０】
この表における各オブジェクトは、データオブジェクトモデルの構造を以下に説明するように定め、再利用性を高める。各オブジェクトはオブジェクトラベルが設定でき、セキュリティポリシの確認に利用する。
【０１１１】
図１２は図５におけるＦａｃａｄｅのデータオブジェクトモデルのクラス関係を示す。
【０１１２】
Ｆａｃａｄｅクラスは、システム管理情報の通信を行うオブジェクトであり、下記表に示すように、メンバ（データ）にはセキュリティのリファレンスモニタ、ノードリスト（登録されているノードごとにセキュリティラベルがアサインされている）、Ｕｓｅｒリスト（登録されているユーザごとにセキュリティラベルがアサインされている）、装置モードや状態の設定・指定、内部や外部クロックからの時刻同期を行う更新時刻をもつ。
【０１１３】
【表３】
2005209048.tif 000005
【０１１４】
ブラウザクラスは、Ｆａｃａｄｅ内の公開オブジェクトを管理し（図３に示す公開ディレクトリ構造）、オブジェクトのブラウジングを行う。１要求内の複数のデータオブジェクトへのアクセスは全て同じ順序となることを保証する。
【０１１５】
グループクラスは、以下の表に示すメンバをもち、データオブジェクトの集合を管理し、データオブジェクトの単位でセキュリティラベルを与える。この一括処理で通信のスループット向上を図る。
【０１１６】
【表４】
2005209048.tif 000006
【０１１７】
データオブジェクトクラスは、以下の表に示すメンバ（計測値やイベントなどの個々のプロセスデータ）をもち、各データにセキュリティラベルを与える。状態変化や閾値チェック、パルス設定などで能動的にイベントを発生させることもできる。なお、Ｆａｃａｄｅへの通信をアプリケーションへのイベントに置き換えることも可能とする。
【０１１８】
【表５】
2005209048.tif 000007
【０１１９】
共有ディレクトリクラスは、Ｆａｃａｄｅ内の公開ディレクトリを管理する。以下の表に示すように、公開ディレクトリ単位にセキュリティラベルを与える。ファイルの変更があったとき、アプリケーションにそれを伝える役目を持つ。
【０１２０】
【表６】
2005209048.tif 000008
【０１２１】
（Ｅ）成りすまし防止
ユーザ名＋パスワード、ＩＣカード、指紋などでユーザ認証を行う。
【０１２２】
以上の機能構成になる装置間のデータ収集のセキュリティ機能によれば、段階的な移行のしやすさ（既設システムとの接続は、全てＦａｃａｄｅのプロトコルスタックコンポーネントで吸収可能）と高い可用性を保ちながら、侵入防止（Ｆａｃａｄｅで全てブロック）、盗聴防止（Ｆａｃａｄｅ間通信は全て暗号化）、改ざん防止（セキュアＯＳでデータ保護）、成りすまし防止（ユーザ認証）のような高いセキュリティ機能を容易に構築することができる。
（３）アプリケーション連携と通信機能
（Ａ）概要
前記のように、Ｆａｃａｄｅはその目的から汎用的なユニットでなければならないが、通信プロトコルとアプリケーションロジックの追加や変更は、頻繁に起こることが想定される。
【０１２３】
（ａ）通信プロトコルを追加する場合の問題点は、以下の通りである。
【０１２４】
・構内ＬＡＮ側のアプリケーションとの通信は、いろいろな形態が考えられる。従来は新しい通信方式が導入されると既設システム側にラッパーをかませてプロトコルの差異を吸収する方式が主にとられてきたが、これはたいへんコストのかかる方式である。ときには物理的に実現できないこともある。
【０１２５】
・Ｆａｃａｄｅに通信プロトコルを追加する際は、プロトコルを呼び出すときの呼び出し引数、呼び出しタイミングなど、対象によって変更が生じ、プログラム全部を見渡さねばならず、複雑さを招き、コストだけでなく品質面でも悪化の原因となる。
【０１２６】
・組み込む通信プロトコルが状態を持つとき、従来の作り方では、その状態を維持する状態変数の置き場所に制約がなく、自由にどこでも置けたため、プロトコルに変更があったとき、プログラムの修正が非常に困難でバグが発生し易い。
【０１２７】
（ｂ）アプリケーションロジックを追加する場合の問題点は、以下の通りである。
【０１２８】
・アプリケーションロジックを起動する方法と実装方法に制約がなく自由度が高いため、追加や変更の際、プログラムの影響範囲が広範囲となり複雑化を招いていた。結果的にコストと品質面での悪化を招く。
【０１２９】
・アプリケーションロジックの実行は並列実行が望ましい。通常、アプリケーションロジックの並列実行の実装はスレッドを利用するが、スレッドの実装は難易度が高く、安定した品質のプログラムを確保するのが困難となる。また、スレッド間で共有するリソースの排他制御ロジックも必須であるにもかかわらず緻密な設計が必要でデッドロックなどの障害を引き起こす原因となったり、必要な排他制御が行われないのどの障害を引き起す。
【０１３０】
以上のような不都合が起きないよう、Ｆａｃａｄｅは以下に説明するアプリケーション連携と通信機能をもつ構成とする。
【０１３１】
（Ｂ）データオブジェクトモデルで発生するイベントとアプリケーションコンポーネントをＲＯＯＭポートで連携する。
【０１３２】
図１３にＦａｃａｄｅのアプリケーションコンポーネントを示すように、グループオブジェクトおよびデータオブジェクトにはＲＯＯＭポートを設け、このＲＯＯＭポートが指定されるとそのポートをインタフェースとしてもつアプリケーションコンポーネントがコールされる。呼び出しはメッセージ送信で実行し、アプリケーションコンポーネントはスレッドで並列実行する。
【０１３３】
ここで、アプリケーション機能には以下のようなものがある。
【０１３４】
・アクセスポイント機能
外部のモバイル端末からのアクセスポイントとなるＦａｃａｄｅが持つ機能である。
【０１３５】
・簡易ＳＣＡＤＡ（Supervisary  Control  and  Data  Acquisition）機能
ＳＣＡＤＡ機能の基本機能を担うＦａｃａｄｅが持つ機能である（状変監視機能、計測値監視機能、制御機能、自動制御機能、状態収集機能、メンテナンス機能（ＤＬＬ含む）の機能など）。
【０１３６】
これらアプリケーション機能を実行するアプリケーションコンポーネントは、できるだけステートレスで作成することが望ましい。また、ステートフルなデータオブジェクトモデルコンポーネントと役割を明確にすることで、ソフトウェアを開発しやすくするだけでなく、コンポーネントの再利用性を高めることができる。
【０１３７】
そこで、図１１に示すように、ＲＯＯＭポートを利用することで、並列動作と再利用性・抽象度の向上（メッセージ通信によるデータに対する緩い結合で実現）を比較的容易に実現させる。以下、具体例を説明する。
【０１３８】
（例１）
図１４にポート接続例を示すように、グループオブジェクトが持つデータオブジェクトにイベントが発生すると、エラーメッセージを監視制御サーバに送信するタスクが起動される。
【０１３９】
また、データオブジェクトのデータが変更すると、状態変化イベントが発生し、接続されているＴＣ（遠隔制御装置）に対してＣＢ（しゃ断器）の入り切り操作を指令するタスクが起動される。
【０１４０】
（例２）
図１５に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣ（遠方監視装置）も新設のときのＦａｃａｄｅの使い方を示し、ＳＯＡＰ（またはＣＯＲＢＡ）インタフェースを使用して、目的Ｆａｃａｄｅの公開オブジェクトのメソッドの関数を呼び出す。
【０１４１】
この例では、コントロールセンターのＳＣＡＤＡは、大崎変電所のTC02のしゃ断器CB03に入り命令を出力する。大崎サブステーションのTC02はしゃ断器CB03オブジェクトにイベント通知のリクエストを出しておくことで、命令イベントを受け取ることができる。
【０１４２】
（例３）
図１６に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣも既設システムのときのＦａｃａｄｅの使い方を示し、ＳＣＡＤＡもＴＣも、既設のアプリケーションは変更を必要としない。
【０１４３】
プロトコルの変換はＦａｃａｄｅの既設システムとの通信を行うプロトコル変換コンポーネントが行う。ＴＣ側のＦａｃａｄｅは既設ＴＣにあわせて必要な数値計算や前処理を行うためのアプリケーションを登録しておくことで呼び出すことができる。
【０１４４】
（例４）
図１７は構内ＬＡＮに接続される監視モニタや携帯端末にＨＭＩ部品を表示する場合を示し、例えば、監視モニタを画面編集モードに切り替え（Ｓ１）、ＨＭＩ部品を編集画面に配置し（Ｓ２）、Ｆａｃａｄｅとの通信により対象のグループオブジェクトを閲覧し（Ｓ３）、当該ＨＭＩ部品をドラッグ＆ドロップで画面編集し（Ｓ４）、実行モード切替で登録を完了する（Ｓ５）。
【０１４５】
（Ｃ）Ｆａｃａｄｅの公開ファイルを利用した通信
図１８にＦａｃａｄｅの公開ファイルを利用した通信例を示す。Ｆａｃａｄｅは公開ディレクトリを利用して、情報を共有する。ディレクトリに格納されたファイルはＦＴＰによる交換、またはＮＦＳによるファイル読み書きで実施する。公開したい情報は最寄のＦａｃａｄｅの自分のノード用に設けられたディレクトリのファイルに登録する。相手の情報を知りたいときは、相手Ｆａｃａｄｅの相手のノードに割り当てられたディレクトリのファイルを参照する。相手のデータオブジェクト情報をファイル形式でコピーまたは、読みたいときは相手Ｆａｃａｄｅのデータオブジェクトディレクトリの該当グループ名のファイルを読む。
【０１４６】
このための公開ディレクトリは、Ｆａｃａｄｅデータオブジェクトモデルに、プロパティ格納用のオブジェクト（名前、セキュリティラベル、更新イベントの有無、ＲＯＯＭポート）をもつ。各ディレクトリは自分の内容が書き換わったときに、更新イベントを送信する。公開ディレクトリのプロパティオブジェクトは、Ｆａｃａｄｅアプリケーション連携のＲＯＯＭポートをプロパティに持ち、その連携によって、別のノードにイベントを送信したり、任意の仕事をさせる。
【０１４７】
Ｆａｃａｄｅの公開ディレクトリは、図１９に示すように、２つの公開ディレクトリパスを持ち、１つは運転用、他方は訓練用とする。それぞれの参照パスは、ログインしたときのユーザまたはアクセスノードのＩＤによって決定する。
【０１４８】
この公開ディレクトリのファイルは、図３の場合と同様に、ＦＴＰまたはＮＦＳによって移動、読み書きをする。ＦＴＰを使用するときは作成途中に、他からのアクセスを防止するために、ファイルが完成するまでは仮のファイル名を用いる。ファイルが完成したら公開されているファイル名に切り替える。また、データオブジェクトディレクトリにはデータオブジェクトのファイル形式のものが格納され、３種類の形式とする（データオブジェクトモデルのグループクラスのファイルプロパティで設定する）。
【０１４９】
１．データオブジェクトの全データをＸＭＬシリアライズしたもの。
【０１５０】
２．データオブジェクトのデータ部分だけをＸＭＬシリアライズしたもの。
【０１５１】
３．電力応用の場合、データオブジェクトのデータ部分をIEC61970の計測値クラスのスキーマで格納したもの。
【０１５２】
また、構内LANの各ノードに割り当てたディレクトリ内のファイルの書式は、自由書式とするが、電力応用のときはIEC61970のクラス定義に準拠したスキーマを用意するので、それを利用すれば、汎用的な情報の交信が可能となる。
【０１５３】
図２０は、公開ファイルを利用した簡単なマルチメディアデータ配信の応用例を示す。携帯電話で写真撮影し、メールサーバから静止画ファイルをＦａｃａｄｅの公開ディレクトリにコピーし、アクセスポイント用Ｆａｃａｄｅはファイル更新イベントをＳＣＡＤＡに送信する。ＳＣＡＤＡの静止画表示部品は、アクセスポイント用Ｆａｃａｄｅの公開ディレクトリのファイルを参照・表示する。
【０１５４】
図２１は、公開ファイルを利用した簡単な日報・月報作成の応用例を示し、Ｆａｃａｄｅはテレコンが収集する日報・月報データをＸＭＬ書式で蓄積し（Ｓ１）、このデータをＳＣＡＤＡ側Ｆａｃａｄｅに読み込み、端末画面に日報・月報データを表示を得る。
【０１５５】
（Ｄ）Ｆａｃａｄｅの公開データオブジェクトを利用した通信
Ｆａｃａｄｅのデータオブジェクトモデルは公開されており、ＳＯＡＰ（またはＣＯＲＢＡ）の通信リクエスト機能を利用して読み書きをする。
【０１５６】
図２２に示すように、公開するデータの更新は最寄のＦａｃａｄｅにデータをセットする。公開されたデータオブジェクトの情報を得るときは、相手側のＦａｃａｄｅからデータをゲットする。特定のノード（コンピュータ）にイベントや命令を通知したいときは、相手に最寄のＦａｃａｄｅの該当データオブジェクトのイベント通知用の状態変数をセットすることで、Ｆａｃａｄｅにイベントを通知させる。
【０１５７】
この通信のためには、Ｆａｃａｄｅは図２３に示す５つの応用を前提とした通信プロトコルを用意する。１の周期計測は、定周期にＴＣ（遠方監視装置）から計測データをＳＣＡＤＡに送信する。２のデマンド計測は非周期計測で、ＳＣＡＤＡからの計測タイミングでＴＣの計測データをＳＣＡＤＡに送信する。リフレッシュ有りの時は、Ｆａｃａｄｅ（ＳＣＡＤＡ側、ＴＣ側両方）のキャッシュをキャンセルして、ＴＣから最新の計測データを送信する。リフレッシュ無しのときは最寄のＦａｃａｄｅのキャッシュにある計測データを送信する。３の制御命令はＳＣＡＤＡからＴＣに制御命令を送信する。返事のあるものとないものがある。４のイベント・アラームはＴＣからＳＣＡＤＡにイベントやメッセージを送信する。この送信には返事を要求しない。５のＦａｃａｄｅの制御は、Ｆａｃａｄｅに対する制御命令を送信する。この送信には返事が必要となる。
【０１５８】
なお、Ｆａｃａｄｅはデータオブジェクトのプロパティの設定により、データオブジェクトに状態変化、閾値チェックによるイベント発行機能を持たせることができる。４のイベント、アラームメッセージの相手側への通知はこの機能を利用している。この機能を応用することで、Ｆａｃａｄｅから任意のコンピュータノードへのイベントやアラームの通知を送信することも可能である（状態変化通知や、Ｆａｃａｄｅ自身の異常通知に利用する）。
【０１５９】
図２４は図２３の周期計測手順（定周期にＴＣから計測データをＳＣＡＤＡに送信する手順）を示し、これには独立した４つの非同期プロトコルを組み合わせて実行する。
【０１６０】
（ａ）ＴＣからＴＣ寄りＦａｃａｄｅに定期的にｐｕｓｈ送信する。データはキャッシュに格納される。
【０１６１】
（ｂ）ＴＣの最寄ＦａｃａｄｅからＴＣに定期的にｐｕｌｌ要求する。データはキャッシュに格納される。周期はデータオブジェクトモデルのグループオブジェクトの周期プロパティにセットする。
【０１６２】
（ｃ）ＴＣ側のＦａｃａｄｅから自分のキャッシュに持っているデータオブジェクトをＳＣＡＤＡ最寄のＦａｃａｄｅのグループオブジェクトに定期的にｐｕｓｈ送信する。Ｆａｃａｄｅ間は暗号化される。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードしてＳＣＡＤＡに送信する。周期はデータオブジェクトモデルのグループオブジェクトのプロパティにセットする。データオブジェクトモデルのデータオブジェクトの閾値（上限値、下限値）プロパティをセットすることで、逸脱時のイベント送信が可能。
【０１６３】
（ｄ）ＳＣＡＤＡからＴＣ側のＦａｃａｄｅのグループオブジェクトに定期的にｐｕｌｌ要求する。ＳＣＡＤＡからの要求はＳＣＡＤＡ側のＦａｃａｄｅで暗号化され、ＴＣ側のＦａｃａｄｅに送られる。ＴＣ側のＦａｃａｄｅのキャッシュにあるデータオブジェクトの内容を暗号化し、ＳＣＡＤＡ側のＦａｃａｄｅに転送する。ＳＣＡＤＡ側のＦａｃａｄｅはデコードしキャッシュに蓄える。その後、ＳＣＡＤＡからリクエストのあったデータプロパティだけをＳＣＡＤＡに送信する。連続する同じグループオブジェクトのデータオブジェクトへの定期参照は２回目以降はＳＣＡＤＡ側のＦａｃａｄｅのキャッシュのデータが使われる。ＳＣＡＤＡ側のキャッシュはＳＣＡＤＡからのリフレッシュ要求か、データオブジェクトモデル中のＦａｃａｄｅオブジェクトのキャッシュ有効時間プロパティの時間超過によってクリアされる。
【０１６４】
図２５は図２３の２のデマンド計測手順を示し、リフレッシュを伴う計測要求と、リフレッシュを伴わない計測要求がある。
【０１６５】
（ａ）リフレッシュ有りの計測要求はＴＣの最新の計測データを得る。ＳＣＡＤＡはＴＣ最寄のＦａｃａｄｅのグループオブジェクトまたはデータオブジェクトに計測要求を出す。ＳＣＡＤＡ最寄のＦａｃａｄｅはその要求を途中で受け取り、暗号化してＴＣ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅはデコードし、ＴＣから目的のデータを取り出しキャッシュに挿入する。ＴＣ側のＦａｃａｄｅは要求のあったグループオブジェクトまたはデータオブジェクトを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは受け取ったデータをデコードし、ＳＣＡＤＡに送信する。
【０１６６】
（ｂ）リフレッシュ無しの計測要求はＦａｃａｄｅのキャッシュにある計測データを得る。ＳＣＡＤＡはＴＣ最寄のＦａｃａｄｅのグループオブジェクトまたはデータオブジェクトに計測要求を出す。キャッシュにデータがあるときは、それをそのまま返す。キャッシュにないときはＳＣＡＤＡ最寄のＦａｃａｄｅはその要求を途中で受け取り、暗号化してＴＣ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅはデコードし、キャッシュにあるときは、データを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードしＳＣＡＤＡに送信する。キャッシュにないときは、ＴＣから目的のデータを取り出しキャッシュに挿入する。ＴＣ側のＦａｃａｄｅは要求のあったグループオブジェクトまたはデータオブジェクトを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは受け取ったデータをデコードし、ＳＣＡＤＡに送信する。
【０１６７】
図２６は図２３の３の制御命令手順を示し、ＳＣＡＤＡからＴＣへ制御命令を送信する。この制御命令は、ＴＣ側Ｆａｃａｄｅのデータオブジェクトモデルのイベント通知オブジェクトの制御値プロパティの変更リクエストで実現する。
【０１６８】
ＳＣＡＤＡはＴＣ側Ｆａｃａｄｅのイベント通知オブジェクトの制御値プロパティをセットする要求を送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化してＴＣ側Ｆａｃａｄｅに送信する。ＴＣ側Ｆａｃａｄｅはデータをデコードする。イベント通知オブジェクトに対する要求なので、ＴＣに制御要求を出力する。
【０１６９】
返事（ＡＣＫ）を必要とするときは、ＴＣからの返事をＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅは、その返事を途中で受け取り暗号化してＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードし、ＳＣＡＤＡに送信する。返事のあるなしは、ＴＣ側Ｆａｃａｄｅのイベント通知オブジェクトの返答プロパティにセットされる。  図２７は図２３の４のイベント・アラームメッセージの通知手順を示す。ＴＣからＳＣＡＤＡへイベントやアラームメッセージを送信する。イベント・アラームメッセージの通知は、ＳＣＡＤＡ側Ｆａｃａｄｅのデータオブジェクトモデルのイベント通知オブジェクトの制御値プロパティの変更リクエストで実現する。ＴＣはＳＣＡＤＡ側Ｆａｃａｄｅのイベント通知オブジェクトの制御値プロパティをセットする要求を送信する。ＴＣ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化してＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅはデータをデコードする。イベント通知オブジェクトに対する要求なので、ＳＣＡＤＡにイベントやアラームメッセージを出力する。
【０１７０】
図２８は、図２３の５のＦａｃａｄｅの制御手順を示し、ＳＣＡＤＡからＦａｃａｄｅへ制御命令を送信する。この制御命令送信は、対象のＦａｃａｄｅに対するデータオブジェクトモデルのＦａｃａｄｅオブジェクトの各プロパティの変更リクエストで実現する。
【０１７１】
ＳＣＡＤＡは対象のＦａｃａｄｅにＦａｃａｄｅオブジェクトの各プロパティをセットする要求を送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化して対象のＦａｃａｄｅに送信する。対象のＦａｃａｄｅはデータをデコードする。自分のＦａｃａｄｅオブジェクトのプロパティを変更し、それに伴う動作を実行する。
【０１７２】
返事（ＡＣＫ）を必要とするときは、自分の返事を暗号化してＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードし、ＳＣＡＤＡに送信する。返事のあるなしは、対象Ｆａｃａｄｅの、Ｆａｃａｄｅオブジェクトの返答プロパティにセットされる。  本Ｆａｃａｄｅの制御には、運転モードの変更、シャットダウン、時刻同期、キャッシュの有効時間変更、自己診断などがある。本プロトコルを利用してＦａｃａｄｅの情報（稼働時間、運転モード、バージョン、機器状態など）を知ることもできる。
【０１７３】
（Ｅ）イベントを発生させるデータオブジェクトモデルの構造
以下のようなデータオブジェクトモデルの各プロパティの変化により、アプリケーションが起動される。これは、宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
【０１７４】
本例では、データオブジェクトモデルに、アプリケーションも含めた全ての状態を実装し、ステートフルにした。イベントから連携するアプリケーションコンポーネントは意図的にステートレスにすることが可能で、それにより、よりアプリケーションコンポーネントの再利用性を高めている。
【０１７５】
なお、データオブジェクトモデルのクラス構成（Ｆａｃａｄｅクラス、グループクラス、データオブジェクトクラス、公開ディレクトリクラス）は、前記の表３〜６のものである。
【０１７６】
以上の機能構成になるアプリケーションの連携と通信機能によれば、以下の効果がある。
【０１７７】
（ａ）通信プロトコルコンポーネントの実装に対する効果
・構内ＬＡＮ側のアプリケーションとの通信は、いろいろな形態が考えられる。従来は新しい通信方式が導入されると既設システム側にラッパーをかませてプロトコルの差異を吸収する方式が主にとられてきたが、これはたいへんコストのかかる方式である。ときには物理的に実現できないこともあった。しかし、本方式を利用してＦａｃａｄｅに容易に通信プロトコルコンポーネントが実装できるようになる。
【０１７８】
・Ｆａｃａｄｅに通信プロトコルを追加する際は、プロトコルを呼び出すときの呼び出し引数、呼び出しタイミングなど、対象によって変更が生じ、プログラム全部を見渡さねばならず、複雑さを招き、コストだけでなく品質面でも悪化の原因となる可能性が大きかったが、本方式を利用することで、アプリケーションは属性を変更するset_propaty  などの同一のアプリケーションインタフェースで全ての操作をすることが可能となる。また、送信タイミングも任意におこなえるようになる（生産性の向上）。
【０１７９】
・組み込む通信プロトコルが状態を持つとき、従来の作り方では、その状態を維持する状態変数の置き場所に制約がなく、自由にどこでも置けたため、プロトコルに変更があったとき、プログラムの修正が非常に困難でバグが発生しやすかった。しかし、本方式を利用することで状態を全てデータオブジェクトモデルに格納することが可能となり、通信プロトコルコンポーネントをステートレスに作成することが可能となる。これにより生産性と品質向上の効果が得られる。
【０１８０】
（ｂ）アプリケーションロジックコンポーネントの実装に対する効果
本方式は、アプリケーションコンポーネントの宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
【０１８１】
例えば、データオブジェクトモデルに、アプリケーションも含めた全ての状態を実装し、ステートフルにした。イベントから連携するアプリケーションコンポーネントは意図的にステートレスにすることが可能で、それにより、よりアプリケーションコンポーネントの再利用性を高めている。
【０１８２】
また、イベントにより起動される全てのコンポーネントはスレッドで並列起動されるので、スレッド組み込みの機構をアプリケーションごとに設計する手間がなくなる。
【０１８３】
アプリケーションコンポーネントがデータオブジェクトモデルを参照、変更する手順は、データオブジェクトをアクセスする順番も含めて、全て規則的におこなわれ、排他制御もその中に含まれる。そのことで不必要な実装や、不注意な実装によるデッドロックを避けることが可能である。
【０１８４】
（４）Ｆａｃａｄｅの多重化機能
（Ａ）概要
監視制御システムは、そのシステムダウンやシステム更新の為に装置（テレコンなど）を停止した時に、その機能をバックアップする多重系の構成にすることが求められる。また、監視制御システムでは、運転員の訓練や、新機能の確認のため、オンライン制御を行っている常用モードと、制御信号を出力しない訓練モードの実装が求められる。
【０１８５】
これらは構成管理機能と呼ばれるもので、アプリケーションの振る舞いと密接にかかわるので、従来の作り方（全ての系で制御用データを共有し、状態を共有することで切り替える方式）ではシステムごとに開発を繰り返す必要がある。すなわち、データを共有するだけでは、べき等性のないデータへのアクセスがあると違った振る舞いをしてしまうため、プログラムコンテキストで緻密な構成チェックをする必要がある。また、アプリケーションも含めた複雑な状態を維持するので、障害が発生しやすい機能だった。
【０１８６】
ところで、Ｆａｃａｄｅは汎用的なユニットでなければならない。それには、多重化処理プログラムをアプリケーションから独立して、汎用化する必要がある。
【０１８７】
以上のような不都合が起きないよう、Ｆａｃａｄｅは以下に説明する多重化処理機能をもつ構成とする。
【０１８８】
（Ｂ）Ｆａｃａｄｅの多重化構成
図２９は、監視制御システムの多重系構成を示す。常用装置１１と待機・訓練用装置１２は構内ＬＡＮ接続で多重化し、同様に常用装置１３と待機・訓練用装置１４は構内ＬＡＮ接続で多重化したシステム構成において、これら装置間のネットワーク通信手段としてのＦａｃａｄｅは、Ｆａｃａｄｅ１５と１６で二重化して同じ構内ＬＡＮに接続し、Ｆａｃａｄｅ１７と１８で二重化して同じ構内ＬＡＮに接続する。この二重化構成による通信を可能とするＦａｃａｄｅとして、システムが制御命令通信の機能を含むか否かで、異なる構成制御とする。以下、詳細に説明する。
【０１８９】
（ａ）制御命令通信機能を持たないシステム用の基本Ｆａｃａｄｅ
この場合、基本Ｆａｃａｄｅは、以下の構成とする。
【０１９０】
・「常用」モードと「待機」モードの区別無し。
【０１９１】
・常にデータ収集とデータ提供を行う。
【０１９２】
・一系のみのＦａｃａｄｅは、基本Ｆａｃａｄｅで構成する。
【０１９３】
・多重系で用いるＦａｃａｄｅも、データオブジェクトモデルのプロパティに、イベント駆動のアプリケーションがないとき、または、イベントタイプがIdenpotentのデータがひとつもないときは、この基本Ｆａｃａｄｅで構成することが可能である。
【０１９４】
なお、Idempotentとは、べき等性（その操作を何回繰り返しても一回だけ実行したときと同じ結果になるもの） 〜オペレーションを複数実行しても安全かどうかを示す。
【０１９５】
（ｂ）制御命令通信機能を持つシステム用の多重化用Ｆａｃａｄｅ
この場合、多重化用Ｆａｃａｄｅは、以下の構成とする。
【０１９６】
・「常用」モード゛のＦａｃａｄｅはデータ収集とデータ提供を行う。
【０１９７】
・「待機」モードのＦａｃａｄｅはデータ収集のみ行う。
【０１９８】
・「待機」モードのＦａｃａｄｅはフリーランデュアル方式で動作する。
【０１９９】
・「待機」モードから「運転」モードへの切り替えは、相手局のライフビート観察による自動切り替え方式と、装置ユニットパネルでの手動切り替え方式を持つ。
【０２００】
（ｃ）基本Ｆａｃａｄｅと多重化用Ｆａｃａｄｅの共通の機能
これらＦａｃａｄｅの共通の機能は、以下の構成とする。
【０２０１】
・「訓練」モードのＦａｃａｄｅは訓練用のデータ収集（シミュレーション結果）と「訓練」モードのシステムあるいはＦａｃａｄｅにデータ提供を行う。
【０２０２】
・「訓練」モード切り替えは、Ｆａｃａｄｅの管理オブジェクトに対する切り替えメッセージコマンド方式か、装置ユニットパネルでの手動切り替え方式を持つ。
【０２０３】
（Ｃ）Ｆａｃａｄｅの状態の種類
図３０は、Ｆａｃａｄｅの構成管理（状態の種類）を示す。図中の運転モードはシステムが稼動している状態、運用モードは常用または訓練モードで稼動している状態、常用モードは運転データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。訓練モードは訓練データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。待機モードは、多重化用Ｆａｃａｄｅのみに設け、運転テ゛ータの収集、イベントの受信を行うモードであり、常用モードのＦａｃａｄｅの障害に備え、ホットスタンバイ状態で待機している。ready状態は、ＯＳは起動しているがＦａｃａｄｅ機能は停止している状態、ＯＳstop状態は、電源は入っているがＯＳが起動していない状態である。
【０２０４】
（Ｄ）Ｆａｃａｄｅの状態遷移
図３１は、基本Ｆａｃａｄｅの状態遷移図を示し、多重化用Ｆａｃａｄｅとの違いは待機モードが存在しない。そのため、他系を監視する必要がない。
【０２０５】
図３２は、多重化用Ｆａｃａｄｅの状態遷移図を示し、Ｆａｃａｄｅは電源投入後、運転モード状態になり、ハードウェアの異常または停止操作があるまで状態を維持する。停止操作、手動によるモード切替はＦａｃａｄｅメンテナンス用のＷｅｂ画面、またはＦａｃａｄｅオブジェクトの稼動状態プロパティを強制変更することで操作する。
【０２０６】
図３２におけるモード遷移の条件は、
・待機モード→常用モード遷移は、自系が待機モード、他系に常用モードのＦａｃａｄｅがない、他系に待機モードのＦａｃａｄｅがあるときは自系の連続待機時間が最長であること、連続待機時間が同じＦａｃａｄｅがあるときはそちらよりＩＰアドレスが大きいこととする。
【０２０７】
・常用モード→待機モード遷移は、初期化を完全に行うため、再起動経由で待機モードに移るようにする。例えば、自系でソフトウェア障害やハードウェア障害が発生したとき、自系が常用モードにあるとき、他系に待機モードのＦａｃａｄｅがあるときとする。
【０２０８】
・自系が常用モードで、他系にも常用モードのＦａｃａｄｅを発見したときの常用モード→待機モード遷移は、初期化を完全に行うため、再起動経由で待機モードに移るようにする。例えば、連続常用時間を比較し自系が短いとき、連続常用時間が同じで自系のＩＰアドレスが大きいときとする。
【０２０９】
（Ｅ）Ｆａｃａｄｅのデータオブジェクト構成
図３３は、基本Ｆａｃａｄｅまたは多重化用Ｆａｃａｄｅのデータオブジェクトモデルを示し、図５と異なる部分は、常用グループオブジェクトと待機・訓練用グループオブジェクトをもち、それぞれにＡ系用とＢ系用と共用のグループオブジェクト群をもつ。常用系と待機・訓練系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのグループオブジェクト群をアクセスするか判断する。
【０２１０】
多重化の考え方は以下のとおりである。
【０２１１】
（ａ）処理
多重化された各Ｆａｃａｄｅは独立した処理を基本とする。ただし、Ｆａｃａｄｅ以外の装置（先着優先等の処理が実装されていない装置）との送受信には常用/待機などの運転モード管理が必要である。
【０２１２】
（ｂ）受信情報
多重化されたＦａｃａｄｅは同一の情報をおのおの受信する。送信元のＦａｃａｄｅも多重化されている場合は、多重化された送信元の各々のＦａｃａｄｅから同一の情報が複数受信することとなる。Ｆａｃａｄｅの共用グループオブジェクト群は先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
【０２１３】
（ｃ）送信情報
各Ｆａｃａｄｅは相手Ｆａｃａｄｅへ送信を行う。送信相手Ｆａｃａｄｅが多重化されている場合は、多重化されているすべてのＦａｃａｄｅに対して送信する。
【０２１４】
（Ｆ）多重系システムの共有（公開）ディレクトリ構成
図３４は、共有（公開）ディレクトリ構成を示し、常用と待機・訓練用は別系統とする。Ａ系、Ｂ系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのディレクトリをアクセスするかパスが割り振られる。共用データオブジェクトディレクトリは、先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
【０２１５】
以上の多重化機能によれば、以下の効果がある。
【０２１６】
（ａ）Ｆａｃａｄｅはフリーランデュアル方式で動作するので、構成制御プログラムを汎用化できる。アプリケーションと独立しているのでプログラムをシンプルにすることが可能である。そのことにより生産性と品質を向上することが期待できる。また、制御信号に対してべき等性のないデータが、１つもないＦａｃａｄｅは、制御信号を出しても影響はないので、基本Ｆａｃａｄｅを使ってシステムを簡略化できる。すなわち、基本Ｆａｃａｄｅは他系を監視する必要がないのでさらにシンプルに構築が可能である。
【０２１７】
（ｂ）Ｆａｃａｄｅは共用データオブジェクトモデルを持つが、その利用で、アプリケーションは多重系を気にせず監視制御データにアクセスできる。余分なプログラムを作成する必要がなくなる共有データオブジェクトファイルについても、同様にアプリケーションは多重系を気にせずファイル操作を行うことができるので、その分のプログラムを記述する必要がなくなり生産性を向上できる。
【図面の簡単な説明】
【０２１８】
【図１】本発明の実施形態を示す監視制御システムの基本構成図。
【図２】実施形態におけるホワイトボードモデルによる情報公開例。
【図３】実施形態におけるＦａｃａｄｅの公開ディレクトリ構造。
【図４】実施形態におけるプロキシモデルによる情報公開例。
【図５】実施形態におけるデータオブジェクトモデル。
【図６】実施形態におけるＦａｃａｄｅのアプリケーション・コンポーネントアーキテクチャ。
【図７】実施形態におけるＦａｃａｄｅによるセキュリティ模式図。
【図８】実施形態によるＦａｃａｄｅによる侵入防止の例。
【図９】実施形態によるＦａｃａｄｅによる盗聴防止の例。
【図１０】実施形態におけるＦａｃａｄｅのセキュリティモデル。
【図１１】実施形態におけるＲＯＯＭアーキテクチャ内でのサブジェクト・アプリケーションタスクの扱い例。
【図１２】実施形態におけるデータオブジェクトモデルのクラス関係。
【図１３】実施形態におけるＦａｃａｄｅのアプリケーション・コンポーネント。
【図１４】実施形態におけるアプリケーション・コンポーネントのポート接続例。
【図１５】実施形態における構内ＬＡＮ側のアプリケーションからお呼び出しの例。
【図１６】実施形態における構内ＬＡＮ側のアプリケーションからお呼び出しの例。
【図１７】実施形態におけるＨＭＩ部品とデータオブジェクトモデルとの連携の例。
【図１８】実施形態におけるＦａｃａｄｅの公開ファイルを利用した通信の例。
【図１９】実施形態におけるＦａｃａｄｅの公開ディレクトリ構造。
【図２０】実施形態におけるＦａｃａｄｅの公開ファイルを利用した簡単なマルチメディアデータ通信の応用例。
【図２１】実施形態におけるＦａｃａｄｅの公開ファイルを利用した簡単な日報・月報作成の応用例。
【図２２】実施形態におけるＦａｃａｄｅの公開データオブジェクトを利用した通信の例。
【図２３】実施形態におけるＦａｃａｄｅの通信形態。
【図２４】実施形態におけるＦａｃａｄｅの通信（１）周期計測。
【図２５】実施形態におけるＦａｃａｄｅの通信（２）デマンド計測。
【図２６】実施形態におけるＦａｃａｄｅの通信（３）制御命令。
【図２７】実施形態におけるＦａｃａｄｅの通信（４）イベントアラームメッセージの通知。
【図２８】実施形態におけるＦａｃａｄｅの通信（５）Ｆａｃａｄｅの制御。
【図２９】実施形態におけるＦａｃａｄｅ（多重系システムの構成）。
【図３０】実施形態におけるＦａｃａｄｅの構成管理（状態の種類）。
【図３１】実施形態における基本Ｆａｃａｄｅの構成管理（状態の遷移）。
【図３２】実施形態における多重化用Ｆａｃａｄｅの構成管理（状態の遷移）。
【図３３】実施形態における多重系システムのデータオブジェクトモデル。
【図３４】実施形態における多重系システムの共有ディレクトリ構造。
【図３５】現状のシステム構成例。
【図３６】現状システムでの利用者の期待（電力分野での例）。
【図３７】現状システムでの専用線をそのままＩＰ化した場合の問題例。
【図３８】監視制御ネットワークと業務用ネットワークの一元化の問題例。
【符号の説明】
【０２１９】
１、２  発変電所用テレコン
３  Ｆａｃａｄｅ一体型テレコン
４  マンマシン装置
５  データメンテナンスサーバ
６〜１０  連携型専用ユニット（Ｆａｃａｄｅ）
１１  サブステーション（常用）
１２  サブステーション（待機・訓練）
１３  コントロールセンタ（常用）
１４  コントロールセンタ（待機・訓練）
１５〜１８  連携型専用ユニット（Ｆａｃａｄｅ）
【図１】
2005209048.tif 000009
【図２】
2005209048.tif 000010
【図３】
2005209048.tif 000011
【図４】
2005209048.tif 000012
【図５】
2005209048.tif 000013
【図６】
2005209048.tif 000014
【図７】
2005209048.tif 000015
【図８】
2005209048.tif 000016
【図９】
2005209048.tif 000017
【図１０】
2005209048.tif 000018
【図１１】
2005209048.tif 000019
【図１２】
2005209048.tif 000020
【図１３】
2005209048.tif 000021
【図１４】
2005209048.tif 000022
【図１５】
2005209048.tif 000023
【図１６】
2005209048.tif 000024
【図１７】
2005209048.tif 000025
【図１８】
2005209048.tif 000026
【図１９】
2005209048.tif 000027
【図２１】
2005209048.tif 000028
【図２２】
2005209048.tif 000029
【図２３】
2005209048.tif 000030
【図２４】
2005209048.tif 000031
【図２５】
2005209048.tif 000032
【図２６】
2005209048.tif 000033
【図２７】
2005209048.tif 000034
【図２８】
2005209048.tif 000035
【図２９】
2005209048.tif 000036
【図３０】
2005209048.tif 000037
【図３１】
2005209048.tif 000038
【図３２】
2005209048.tif 000039
【図３３】
2005209048.tif 000040
【図３４】
2005209048.tif 000041
【図３５】
2005209048.tif 000042
【図３６】
2005209048.tif 000043
【図３７】
2005209048.tif 000044
【図３８】
2005209048.tif 000045
【図２０】
2005209048.tif 000046