JP2005209048A - 監視制御システム - Google Patents
監視制御システム Download PDFInfo
- Publication number
- JP2005209048A JP2005209048A JP2004016456A JP2004016456A JP2005209048A JP 2005209048 A JP2005209048 A JP 2005209048A JP 2004016456 A JP2004016456 A JP 2004016456A JP 2004016456 A JP2004016456 A JP 2004016456A JP 2005209048 A JP2005209048 A JP 2005209048A
- Authority
- JP
- Japan
- Prior art keywords
- data
- cooperative
- communication
- file
- dedicated unit
- 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.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Selective Calling Equipment (AREA)
- Storage Device Security (AREA)
Abstract
【課題】専用線ネットワーク通信による現在の監視制御システム系の装置がもつ機能、処理方式を変更することなく、オープンネットワークを利用した通信・監視・制御システム系へ移行できる。
【解決手段】連携型専用ユニット６〜１０は、システムを構築する各装置１〜５とはそれぞれの構内ＬＡＮとオープンネットワークとの間に設ける。
連携型専用ユニットは、各装置との情報交換用にホワイトボードまたはプロキシを設け、各装置のアプリケーションは公開可能な情報をホワイトボード上に掲示または委譲し、他のアプリケーションが自由に参照可能とする。
さらに、連携型専用ユニットは、セキュリティ機能、アプリケーション連携機能、多重化システムへの対応機能をもつ。
【選択図】 図１
【解決手段】連携型専用ユニット６〜１０は、システムを構築する各装置１〜５とはそれぞれの構内ＬＡＮとオープンネットワークとの間に設ける。
連携型専用ユニットは、各装置との情報交換用にホワイトボードまたはプロキシを設け、各装置のアプリケーションは公開可能な情報をホワイトボード上に掲示または委譲し、他のアプリケーションが自由に参照可能とする。
さらに、連携型専用ユニットは、セキュリティ機能、アプリケーション連携機能、多重化システムへの対応機能をもつ。
【選択図】 図１
Description
本発明は、ネットワーク通信を利用した監視制御システム（電力送配電網、上水配水網、ガス供給網などの監視制御システム）に係り、特に既存ネットワーク通信による現在の監視制御システム系を、ＩＰ（Internet Protocol）ネットワークを利用した通信・監視・制御システム系へ移行するための監視制御システムに関する。
現在の監視制御システムは、図３５に例を示すように、コストダウンを目的とし、既存ネットワークによる監視制御情報の通信に加えて、ＩＰネットワークを通信媒体として、汎用品・汎用技術を採用した監視制御用システム、サーバ、コントローラを各地に分散配置するオープン分散システムとして構築されてきている。同時に、図３６に電力分野での例を示すように、監視制御システムには、基本的な監視制御機能の他に、情報開示・監視制御高度化など、従来にない新しいニーズが発生している。
近年では、パソコン等の普及により、関連する技術の進展が著しく、次世代システムにおいては、汎用品・汎用技術を大幅に採用したシステムとして構築されることが予想される。また、ネットワークの活用により、システムの大規模集約、分散配置および相互バックアップ等、技術的な制約のない自由なシステム構成が可能となっている。
このようなシステム構成を支援するため、インターネット等における異なるコンピュータ間をセキュリティを確保して自由に接続可能にした通信機能、コンピュータ間のデータ管理機能、目的とするシステムを構築するためのアプリケーション開発機能をもつシステムや手法が種々提案されている（例えば、非特許文献１、２、３参照）。
ＯＰＣ（OLE for Process Control）技術概要書、Version２、日本ＯＰＣ協議会技術部会、１９９９年１１月発行、 オペレーティングシステムのアクセスコントロール機能におけるセキュリティポリシーモデル、情報処理振興事業協会セキュリティセンター、 電気協同研究第５８巻、第４号「電力用通信網へのＩＰネットワークの適用性評価・システム設計技術、電力用ＩＰネットワーク技術専門委員会、社団法人電気協同研究会、平成１４年１１月２８日発行、
ＯＰＣ（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）アクセス（タイトコミュニケーション）と共有ファイルアクセス（ルーズコミュニケーション）
〇各装置１〜５のイベントコントロールサービス機能として、以下の機能を設ける。
・管理オブジェクト（構成制御）
・計測値オブジェクト（グループ化可能）
・ＧＵＩ（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)も用意する。
上記のＦａｃａｄｅのセキュリティポリシの主体（サブジェクト）となる対象は、以下の表に示す
上記の実行タスクサブジェクトについては、Ｆａｃａｄｅ内部にアーキテクチャを組み込み、データオブジェクトモデルからリンクされたコンポーネントにサブジェクトラベルをつけ、セキュリティポリシの確認に利用する。
図１１はＲＯＯＭアーキテクチャ（Real-time Object-Oriented Modeling:Bran Selic著）内でのサブジェクトアプリケーションタスクの取り扱い例を示す。
同図において、各ＲＯＯＭポートは相手先とプロトコルの組み合わせテーブルで構成し、必ずｉｎとｏｕｔのペアで構成する。同じプロトコルと引数を持つポートをクラス化して、モジュールを共通化する。
図１１におけるデータオブジェクトモデルは、ｉｎポートからの通信リクエストでそのハンドリングを行う。状態変化などでデータオブジェクトがイベントを発生させたとき、該当するデータオブジェクトやグループオブジェクトに指定されたＲＯＯＭポートにメッセージを出力する。
また、プロトコルやアプリケーションロジックのコンポーネント（入力と出力が明確に定義されたアプリケーション）は、ＲＯＯＭで言うアクターに相当する。
また、アプリケーション通信（既設システムとの交信を含む）はプロトコル変換（手順の変換）とデータ変換（パケット⇔データオブジェクト）を行う。
前記のＦａｃａｄｅのセキュリティポリシーのオブジェクト（対象物）は、以下の表に示す。
この表における各オブジェクトは、データオブジェクトモデルの構造を以下に説明するように定め、再利用性を高める。各オブジェクトはオブジェクトラベルが設定でき、セキュリティポリシの確認に利用する。
図１２は図５におけるＦａｃａｄｅのデータオブジェクトモデルのクラス関係を示す。
Ｆａｃａｄｅクラスは、システム管理情報の通信を行うオブジェクトであり、下記表に示すように、メンバ（データ）にはセキュリティのリファレンスモニタ、ノードリスト（登録されているノードごとにセキュリティラベルがアサインされている）、Ｕｓｅｒリスト（登録されているユーザごとにセキュリティラベルがアサインされている）、装置モードや状態の設定・指定、内部や外部クロックからの時刻同期を行う更新時刻をもつ。
ブラウザクラスは、Ｆａｃａｄｅ内の公開オブジェクトを管理し（図３に示す公開ディレクトリ構造）、オブジェクトのブラウジングを行う。１要求内の複数のデータオブジェクトへのアクセスは全て同じ順序となることを保証する。
グループクラスは、以下の表に示すメンバをもち、データオブジェクトの集合を管理し、データオブジェクトの単位でセキュリティラベルを与える。この一括処理で通信のスループット向上を図る。
データオブジェクトクラスは、以下の表に示すメンバ（計測値やイベントなどの個々のプロセスデータ）をもち、各データにセキュリティラベルを与える。状態変化や閾値チェック、パルス設定などで能動的にイベントを発生させることもできる。なお、Ｆａｃａｄｅへの通信をアプリケーションへのイベントに置き換えることも可能とする。
共有ディレクトリクラスは、Ｆａｃａｄｅ内の公開ディレクトリを管理する。以下の表に示すように、公開ディレクトリ単位にセキュリティラベルを与える。ファイルの変更があったとき、アプリケーションにそれを伝える役目を持つ。
（Ｅ）成りすまし防止
ユーザ名＋パスワード、ＩＣカード、指紋などでユーザ認証を行う。
ユーザ名＋パスワード、ＩＣカード、指紋などでユーザ認証を行う。
以上の機能構成になる装置間のデータ収集のセキュリティ機能によれば、段階的な移行のしやすさ（既設システムとの接続は、全てＦａｃａｄｅのプロトコルスタックコンポーネントで吸収可能）と高い可用性を保ちながら、侵入防止（Ｆａｃａｄｅで全てブロック）、盗聴防止（Ｆａｃａｄｅ間通信は全て暗号化）、改ざん防止（セキュアＯＳでデータ保護）、成りすまし防止（ユーザ認証）のような高いセキュリティ機能を容易に構築することができる。
（３）アプリケーション連携と通信機能
（Ａ）概要
前記のように、Ｆａｃａｄｅはその目的から汎用的なユニットでなければならないが、通信プロトコルとアプリケーションロジックの追加や変更は、頻繁に起こることが想定される。
（３）アプリケーション連携と通信機能
（Ａ）概要
前記のように、Ｆａｃａｄｅはその目的から汎用的なユニットでなければならないが、通信プロトコルとアプリケーションロジックの追加や変更は、頻繁に起こることが想定される。
（ａ）通信プロトコルを追加する場合の問題点は、以下の通りである。
・構内ＬＡＮ側のアプリケーションとの通信は、いろいろな形態が考えられる。従来は新しい通信方式が導入されると既設システム側にラッパーをかませてプロトコルの差異を吸収する方式が主にとられてきたが、これはたいへんコストのかかる方式である。ときには物理的に実現できないこともある。
・Ｆａｃａｄｅに通信プロトコルを追加する際は、プロトコルを呼び出すときの呼び出し引数、呼び出しタイミングなど、対象によって変更が生じ、プログラム全部を見渡さねばならず、複雑さを招き、コストだけでなく品質面でも悪化の原因となる。
・組み込む通信プロトコルが状態を持つとき、従来の作り方では、その状態を維持する状態変数の置き場所に制約がなく、自由にどこでも置けたため、プロトコルに変更があったとき、プログラムの修正が非常に困難でバグが発生し易い。
（ｂ）アプリケーションロジックを追加する場合の問題点は、以下の通りである。
・アプリケーションロジックを起動する方法と実装方法に制約がなく自由度が高いため、追加や変更の際、プログラムの影響範囲が広範囲となり複雑化を招いていた。結果的にコストと品質面での悪化を招く。
・アプリケーションロジックの実行は並列実行が望ましい。通常、アプリケーションロジックの並列実行の実装はスレッドを利用するが、スレッドの実装は難易度が高く、安定した品質のプログラムを確保するのが困難となる。また、スレッド間で共有するリソースの排他制御ロジックも必須であるにもかかわらず緻密な設計が必要でデッドロックなどの障害を引き起こす原因となったり、必要な排他制御が行われないのどの障害を引き起す。
以上のような不都合が起きないよう、Ｆａｃａｄｅは以下に説明するアプリケーション連携と通信機能をもつ構成とする。
（Ｂ）データオブジェクトモデルで発生するイベントとアプリケーションコンポーネントをＲＯＯＭポートで連携する。
図１３にＦａｃａｄｅのアプリケーションコンポーネントを示すように、グループオブジェクトおよびデータオブジェクトにはＲＯＯＭポートを設け、このＲＯＯＭポートが指定されるとそのポートをインタフェースとしてもつアプリケーションコンポーネントがコールされる。呼び出しはメッセージ送信で実行し、アプリケーションコンポーネントはスレッドで並列実行する。
ここで、アプリケーション機能には以下のようなものがある。
・アクセスポイント機能
外部のモバイル端末からのアクセスポイントとなるＦａｃａｄｅが持つ機能である。
外部のモバイル端末からのアクセスポイントとなるＦａｃａｄｅが持つ機能である。
・簡易ＳＣＡＤＡ（Supervisary Control and Data Acquisition）機能
ＳＣＡＤＡ機能の基本機能を担うＦａｃａｄｅが持つ機能である（状変監視機能、計測値監視機能、制御機能、自動制御機能、状態収集機能、メンテナンス機能（ＤＬＬ含む）の機能など）。
ＳＣＡＤＡ機能の基本機能を担うＦａｃａｄｅが持つ機能である（状変監視機能、計測値監視機能、制御機能、自動制御機能、状態収集機能、メンテナンス機能（ＤＬＬ含む）の機能など）。
これらアプリケーション機能を実行するアプリケーションコンポーネントは、できるだけステートレスで作成することが望ましい。また、ステートフルなデータオブジェクトモデルコンポーネントと役割を明確にすることで、ソフトウェアを開発しやすくするだけでなく、コンポーネントの再利用性を高めることができる。
そこで、図１１に示すように、ＲＯＯＭポートを利用することで、並列動作と再利用性・抽象度の向上（メッセージ通信によるデータに対する緩い結合で実現）を比較的容易に実現させる。以下、具体例を説明する。
（例１）
図１４にポート接続例を示すように、グループオブジェクトが持つデータオブジェクトにイベントが発生すると、エラーメッセージを監視制御サーバに送信するタスクが起動される。
図１４にポート接続例を示すように、グループオブジェクトが持つデータオブジェクトにイベントが発生すると、エラーメッセージを監視制御サーバに送信するタスクが起動される。
また、データオブジェクトのデータが変更すると、状態変化イベントが発生し、接続されているＴＣ（遠隔制御装置）に対してＣＢ（しゃ断器）の入り切り操作を指令するタスクが起動される。
（例２）
図１５に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣ（遠方監視装置）も新設のときのＦａｃａｄｅの使い方を示し、ＳＯＡＰ（またはＣＯＲＢＡ）インタフェースを使用して、目的Ｆａｃａｄｅの公開オブジェクトのメソッドの関数を呼び出す。
図１５に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣ（遠方監視装置）も新設のときのＦａｃａｄｅの使い方を示し、ＳＯＡＰ（またはＣＯＲＢＡ）インタフェースを使用して、目的Ｆａｃａｄｅの公開オブジェクトのメソッドの関数を呼び出す。
この例では、コントロールセンターのＳＣＡＤＡは、大崎変電所のTC02のしゃ断器CB03に入り命令を出力する。大崎サブステーションのTC02はしゃ断器CB03オブジェクトにイベント通知のリクエストを出しておくことで、命令イベントを受け取ることができる。
（例３）
図１６に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣも既設システムのときのＦａｃａｄｅの使い方を示し、ＳＣＡＤＡもＴＣも、既設のアプリケーションは変更を必要としない。
図１６に電力システムでの構内ＬＡＮ側のアプリケーションからの呼び出し方を示す。同図は、ＳＣＡＤＡもＴＣも既設システムのときのＦａｃａｄｅの使い方を示し、ＳＣＡＤＡもＴＣも、既設のアプリケーションは変更を必要としない。
プロトコルの変換はＦａｃａｄｅの既設システムとの通信を行うプロトコル変換コンポーネントが行う。ＴＣ側のＦａｃａｄｅは既設ＴＣにあわせて必要な数値計算や前処理を行うためのアプリケーションを登録しておくことで呼び出すことができる。
（例４）
図１７は構内ＬＡＮに接続される監視モニタや携帯端末にＨＭＩ部品を表示する場合を示し、例えば、監視モニタを画面編集モードに切り替え（Ｓ１）、ＨＭＩ部品を編集画面に配置し（Ｓ２）、Ｆａｃａｄｅとの通信により対象のグループオブジェクトを閲覧し（Ｓ３）、当該ＨＭＩ部品をドラッグ＆ドロップで画面編集し（Ｓ４）、実行モード切替で登録を完了する（Ｓ５）。
図１７は構内ＬＡＮに接続される監視モニタや携帯端末にＨＭＩ部品を表示する場合を示し、例えば、監視モニタを画面編集モードに切り替え（Ｓ１）、ＨＭＩ部品を編集画面に配置し（Ｓ２）、Ｆａｃａｄｅとの通信により対象のグループオブジェクトを閲覧し（Ｓ３）、当該ＨＭＩ部品をドラッグ＆ドロップで画面編集し（Ｓ４）、実行モード切替で登録を完了する（Ｓ５）。
（Ｃ）Ｆａｃａｄｅの公開ファイルを利用した通信
図１８にＦａｃａｄｅの公開ファイルを利用した通信例を示す。Ｆａｃａｄｅは公開ディレクトリを利用して、情報を共有する。ディレクトリに格納されたファイルはＦＴＰによる交換、またはＮＦＳによるファイル読み書きで実施する。公開したい情報は最寄のＦａｃａｄｅの自分のノード用に設けられたディレクトリのファイルに登録する。相手の情報を知りたいときは、相手Ｆａｃａｄｅの相手のノードに割り当てられたディレクトリのファイルを参照する。相手のデータオブジェクト情報をファイル形式でコピーまたは、読みたいときは相手Ｆａｃａｄｅのデータオブジェクトディレクトリの該当グループ名のファイルを読む。
図１８にＦａｃａｄｅの公開ファイルを利用した通信例を示す。Ｆａｃａｄｅは公開ディレクトリを利用して、情報を共有する。ディレクトリに格納されたファイルはＦＴＰによる交換、またはＮＦＳによるファイル読み書きで実施する。公開したい情報は最寄のＦａｃａｄｅの自分のノード用に設けられたディレクトリのファイルに登録する。相手の情報を知りたいときは、相手Ｆａｃａｄｅの相手のノードに割り当てられたディレクトリのファイルを参照する。相手のデータオブジェクト情報をファイル形式でコピーまたは、読みたいときは相手Ｆａｃａｄｅのデータオブジェクトディレクトリの該当グループ名のファイルを読む。
このための公開ディレクトリは、Ｆａｃａｄｅデータオブジェクトモデルに、プロパティ格納用のオブジェクト（名前、セキュリティラベル、更新イベントの有無、ＲＯＯＭポート）をもつ。各ディレクトリは自分の内容が書き換わったときに、更新イベントを送信する。公開ディレクトリのプロパティオブジェクトは、Ｆａｃａｄｅアプリケーション連携のＲＯＯＭポートをプロパティに持ち、その連携によって、別のノードにイベントを送信したり、任意の仕事をさせる。
Ｆａｃａｄｅの公開ディレクトリは、図１９に示すように、２つの公開ディレクトリパスを持ち、１つは運転用、他方は訓練用とする。それぞれの参照パスは、ログインしたときのユーザまたはアクセスノードのＩＤによって決定する。
この公開ディレクトリのファイルは、図３の場合と同様に、ＦＴＰまたはＮＦＳによって移動、読み書きをする。ＦＴＰを使用するときは作成途中に、他からのアクセスを防止するために、ファイルが完成するまでは仮のファイル名を用いる。ファイルが完成したら公開されているファイル名に切り替える。また、データオブジェクトディレクトリにはデータオブジェクトのファイル形式のものが格納され、３種類の形式とする（データオブジェクトモデルのグループクラスのファイルプロパティで設定する）。
１．データオブジェクトの全データをＸＭＬシリアライズしたもの。
２．データオブジェクトのデータ部分だけをＸＭＬシリアライズしたもの。
３．電力応用の場合、データオブジェクトのデータ部分をIEC61970の計測値クラスのスキーマで格納したもの。
また、構内LANの各ノードに割り当てたディレクトリ内のファイルの書式は、自由書式とするが、電力応用のときはIEC61970のクラス定義に準拠したスキーマを用意するので、それを利用すれば、汎用的な情報の交信が可能となる。
図２０は、公開ファイルを利用した簡単なマルチメディアデータ配信の応用例を示す。携帯電話で写真撮影し、メールサーバから静止画ファイルをＦａｃａｄｅの公開ディレクトリにコピーし、アクセスポイント用Ｆａｃａｄｅはファイル更新イベントをＳＣＡＤＡに送信する。ＳＣＡＤＡの静止画表示部品は、アクセスポイント用Ｆａｃａｄｅの公開ディレクトリのファイルを参照・表示する。
図２１は、公開ファイルを利用した簡単な日報・月報作成の応用例を示し、Ｆａｃａｄｅはテレコンが収集する日報・月報データをＸＭＬ書式で蓄積し（Ｓ１）、このデータをＳＣＡＤＡ側Ｆａｃａｄｅに読み込み、端末画面に日報・月報データを表示を得る。
（Ｄ）Ｆａｃａｄｅの公開データオブジェクトを利用した通信
Ｆａｃａｄｅのデータオブジェクトモデルは公開されており、ＳＯＡＰ（またはＣＯＲＢＡ）の通信リクエスト機能を利用して読み書きをする。
Ｆａｃａｄｅのデータオブジェクトモデルは公開されており、ＳＯＡＰ（またはＣＯＲＢＡ）の通信リクエスト機能を利用して読み書きをする。
図２２に示すように、公開するデータの更新は最寄のＦａｃａｄｅにデータをセットする。公開されたデータオブジェクトの情報を得るときは、相手側のＦａｃａｄｅからデータをゲットする。特定のノード（コンピュータ）にイベントや命令を通知したいときは、相手に最寄のＦａｃａｄｅの該当データオブジェクトのイベント通知用の状態変数をセットすることで、Ｆａｃａｄｅにイベントを通知させる。
この通信のためには、Ｆａｃａｄｅは図２３に示す５つの応用を前提とした通信プロトコルを用意する。１の周期計測は、定周期にＴＣ（遠方監視装置）から計測データをＳＣＡＤＡに送信する。２のデマンド計測は非周期計測で、ＳＣＡＤＡからの計測タイミングでＴＣの計測データをＳＣＡＤＡに送信する。リフレッシュ有りの時は、Ｆａｃａｄｅ（ＳＣＡＤＡ側、ＴＣ側両方）のキャッシュをキャンセルして、ＴＣから最新の計測データを送信する。リフレッシュ無しのときは最寄のＦａｃａｄｅのキャッシュにある計測データを送信する。３の制御命令はＳＣＡＤＡからＴＣに制御命令を送信する。返事のあるものとないものがある。４のイベント・アラームはＴＣからＳＣＡＤＡにイベントやメッセージを送信する。この送信には返事を要求しない。５のＦａｃａｄｅの制御は、Ｆａｃａｄｅに対する制御命令を送信する。この送信には返事が必要となる。
なお、Ｆａｃａｄｅはデータオブジェクトのプロパティの設定により、データオブジェクトに状態変化、閾値チェックによるイベント発行機能を持たせることができる。４のイベント、アラームメッセージの相手側への通知はこの機能を利用している。この機能を応用することで、Ｆａｃａｄｅから任意のコンピュータノードへのイベントやアラームの通知を送信することも可能である（状態変化通知や、Ｆａｃａｄｅ自身の異常通知に利用する）。
図２４は図２３の周期計測手順（定周期にＴＣから計測データをＳＣＡＤＡに送信する手順）を示し、これには独立した４つの非同期プロトコルを組み合わせて実行する。
（ａ）ＴＣからＴＣ寄りＦａｃａｄｅに定期的にｐｕｓｈ送信する。データはキャッシュに格納される。
（ｂ）ＴＣの最寄ＦａｃａｄｅからＴＣに定期的にｐｕｌｌ要求する。データはキャッシュに格納される。周期はデータオブジェクトモデルのグループオブジェクトの周期プロパティにセットする。
（ｃ）ＴＣ側のＦａｃａｄｅから自分のキャッシュに持っているデータオブジェクトをＳＣＡＤＡ最寄のＦａｃａｄｅのグループオブジェクトに定期的にｐｕｓｈ送信する。Ｆａｃａｄｅ間は暗号化される。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードしてＳＣＡＤＡに送信する。周期はデータオブジェクトモデルのグループオブジェクトのプロパティにセットする。データオブジェクトモデルのデータオブジェクトの閾値（上限値、下限値）プロパティをセットすることで、逸脱時のイベント送信が可能。
（ｄ）ＳＣＡＤＡからＴＣ側のＦａｃａｄｅのグループオブジェクトに定期的にｐｕｌｌ要求する。ＳＣＡＤＡからの要求はＳＣＡＤＡ側のＦａｃａｄｅで暗号化され、ＴＣ側のＦａｃａｄｅに送られる。ＴＣ側のＦａｃａｄｅのキャッシュにあるデータオブジェクトの内容を暗号化し、ＳＣＡＤＡ側のＦａｃａｄｅに転送する。ＳＣＡＤＡ側のＦａｃａｄｅはデコードしキャッシュに蓄える。その後、ＳＣＡＤＡからリクエストのあったデータプロパティだけをＳＣＡＤＡに送信する。連続する同じグループオブジェクトのデータオブジェクトへの定期参照は２回目以降はＳＣＡＤＡ側のＦａｃａｄｅのキャッシュのデータが使われる。ＳＣＡＤＡ側のキャッシュはＳＣＡＤＡからのリフレッシュ要求か、データオブジェクトモデル中のＦａｃａｄｅオブジェクトのキャッシュ有効時間プロパティの時間超過によってクリアされる。
図２５は図２３の２のデマンド計測手順を示し、リフレッシュを伴う計測要求と、リフレッシュを伴わない計測要求がある。
（ａ）リフレッシュ有りの計測要求はＴＣの最新の計測データを得る。ＳＣＡＤＡはＴＣ最寄のＦａｃａｄｅのグループオブジェクトまたはデータオブジェクトに計測要求を出す。ＳＣＡＤＡ最寄のＦａｃａｄｅはその要求を途中で受け取り、暗号化してＴＣ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅはデコードし、ＴＣから目的のデータを取り出しキャッシュに挿入する。ＴＣ側のＦａｃａｄｅは要求のあったグループオブジェクトまたはデータオブジェクトを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは受け取ったデータをデコードし、ＳＣＡＤＡに送信する。
（ｂ）リフレッシュ無しの計測要求はＦａｃａｄｅのキャッシュにある計測データを得る。ＳＣＡＤＡはＴＣ最寄のＦａｃａｄｅのグループオブジェクトまたはデータオブジェクトに計測要求を出す。キャッシュにデータがあるときは、それをそのまま返す。キャッシュにないときはＳＣＡＤＡ最寄のＦａｃａｄｅはその要求を途中で受け取り、暗号化してＴＣ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅはデコードし、キャッシュにあるときは、データを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードしＳＣＡＤＡに送信する。キャッシュにないときは、ＴＣから目的のデータを取り出しキャッシュに挿入する。ＴＣ側のＦａｃａｄｅは要求のあったグループオブジェクトまたはデータオブジェクトを暗号化し、ＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは受け取ったデータをデコードし、ＳＣＡＤＡに送信する。
図２６は図２３の３の制御命令手順を示し、ＳＣＡＤＡからＴＣへ制御命令を送信する。この制御命令は、ＴＣ側Ｆａｃａｄｅのデータオブジェクトモデルのイベント通知オブジェクトの制御値プロパティの変更リクエストで実現する。
ＳＣＡＤＡはＴＣ側Ｆａｃａｄｅのイベント通知オブジェクトの制御値プロパティをセットする要求を送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化してＴＣ側Ｆａｃａｄｅに送信する。ＴＣ側Ｆａｃａｄｅはデータをデコードする。イベント通知オブジェクトに対する要求なので、ＴＣに制御要求を出力する。
返事（ＡＣＫ）を必要とするときは、ＴＣからの返事をＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＴＣ側のＦａｃａｄｅは、その返事を途中で受け取り暗号化してＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードし、ＳＣＡＤＡに送信する。返事のあるなしは、ＴＣ側Ｆａｃａｄｅのイベント通知オブジェクトの返答プロパティにセットされる。 図２７は図２３の４のイベント・アラームメッセージの通知手順を示す。ＴＣからＳＣＡＤＡへイベントやアラームメッセージを送信する。イベント・アラームメッセージの通知は、ＳＣＡＤＡ側Ｆａｃａｄｅのデータオブジェクトモデルのイベント通知オブジェクトの制御値プロパティの変更リクエストで実現する。ＴＣはＳＣＡＤＡ側Ｆａｃａｄｅのイベント通知オブジェクトの制御値プロパティをセットする要求を送信する。ＴＣ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化してＳＣＡＤＡ側Ｆａｃａｄｅに送信する。ＳＣＡＤＡ側Ｆａｃａｄｅはデータをデコードする。イベント通知オブジェクトに対する要求なので、ＳＣＡＤＡにイベントやアラームメッセージを出力する。
図２８は、図２３の５のＦａｃａｄｅの制御手順を示し、ＳＣＡＤＡからＦａｃａｄｅへ制御命令を送信する。この制御命令送信は、対象のＦａｃａｄｅに対するデータオブジェクトモデルのＦａｃａｄｅオブジェクトの各プロパティの変更リクエストで実現する。
ＳＣＡＤＡは対象のＦａｃａｄｅにＦａｃａｄｅオブジェクトの各プロパティをセットする要求を送信する。ＳＣＡＤＡ側Ｆａｃａｄｅは、その要求を途中で受け取り暗号化して対象のＦａｃａｄｅに送信する。対象のＦａｃａｄｅはデータをデコードする。自分のＦａｃａｄｅオブジェクトのプロパティを変更し、それに伴う動作を実行する。
返事（ＡＣＫ）を必要とするときは、自分の返事を暗号化してＳＣＡＤＡ側のＦａｃａｄｅに送信する。ＳＣＡＤＡ側のＦａｃａｄｅはデータをデコードし、ＳＣＡＤＡに送信する。返事のあるなしは、対象Ｆａｃａｄｅの、Ｆａｃａｄｅオブジェクトの返答プロパティにセットされる。 本Ｆａｃａｄｅの制御には、運転モードの変更、シャットダウン、時刻同期、キャッシュの有効時間変更、自己診断などがある。本プロトコルを利用してＦａｃａｄｅの情報（稼働時間、運転モード、バージョン、機器状態など）を知ることもできる。
（Ｅ）イベントを発生させるデータオブジェクトモデルの構造
以下のようなデータオブジェクトモデルの各プロパティの変化により、アプリケーションが起動される。これは、宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
以下のようなデータオブジェクトモデルの各プロパティの変化により、アプリケーションが起動される。これは、宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
本例では、データオブジェクトモデルに、アプリケーションも含めた全ての状態を実装し、ステートフルにした。イベントから連携するアプリケーションコンポーネントは意図的にステートレスにすることが可能で、それにより、よりアプリケーションコンポーネントの再利用性を高めている。
なお、データオブジェクトモデルのクラス構成（Ｆａｃａｄｅクラス、グループクラス、データオブジェクトクラス、公開ディレクトリクラス）は、前記の表３〜６のものである。
以上の機能構成になるアプリケーションの連携と通信機能によれば、以下の効果がある。
（ａ）通信プロトコルコンポーネントの実装に対する効果
・構内ＬＡＮ側のアプリケーションとの通信は、いろいろな形態が考えられる。従来は新しい通信方式が導入されると既設システム側にラッパーをかませてプロトコルの差異を吸収する方式が主にとられてきたが、これはたいへんコストのかかる方式である。ときには物理的に実現できないこともあった。しかし、本方式を利用してＦａｃａｄｅに容易に通信プロトコルコンポーネントが実装できるようになる。
・構内ＬＡＮ側のアプリケーションとの通信は、いろいろな形態が考えられる。従来は新しい通信方式が導入されると既設システム側にラッパーをかませてプロトコルの差異を吸収する方式が主にとられてきたが、これはたいへんコストのかかる方式である。ときには物理的に実現できないこともあった。しかし、本方式を利用してＦａｃａｄｅに容易に通信プロトコルコンポーネントが実装できるようになる。
・Ｆａｃａｄｅに通信プロトコルを追加する際は、プロトコルを呼び出すときの呼び出し引数、呼び出しタイミングなど、対象によって変更が生じ、プログラム全部を見渡さねばならず、複雑さを招き、コストだけでなく品質面でも悪化の原因となる可能性が大きかったが、本方式を利用することで、アプリケーションは属性を変更するset_propaty などの同一のアプリケーションインタフェースで全ての操作をすることが可能となる。また、送信タイミングも任意におこなえるようになる（生産性の向上）。
・組み込む通信プロトコルが状態を持つとき、従来の作り方では、その状態を維持する状態変数の置き場所に制約がなく、自由にどこでも置けたため、プロトコルに変更があったとき、プログラムの修正が非常に困難でバグが発生しやすかった。しかし、本方式を利用することで状態を全てデータオブジェクトモデルに格納することが可能となり、通信プロトコルコンポーネントをステートレスに作成することが可能となる。これにより生産性と品質向上の効果が得られる。
（ｂ）アプリケーションロジックコンポーネントの実装に対する効果
本方式は、アプリケーションコンポーネントの宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
本方式は、アプリケーションコンポーネントの宣言的仕様を実現する。宣言的仕様は、プロパティ（メンバ）の値を設定することでシステムのプログラミングをおこなうことを意味している。これは一連の手続き（命令）によりシステムのプログラミングをおこなう命令的仕様と対照をなしている。宣言的プログラミングは、事前にプログラミングされた実証済みのロジックを再利用する別の形であると言えるが、生産性と品質を向上させる。
例えば、データオブジェクトモデルに、アプリケーションも含めた全ての状態を実装し、ステートフルにした。イベントから連携するアプリケーションコンポーネントは意図的にステートレスにすることが可能で、それにより、よりアプリケーションコンポーネントの再利用性を高めている。
また、イベントにより起動される全てのコンポーネントはスレッドで並列起動されるので、スレッド組み込みの機構をアプリケーションごとに設計する手間がなくなる。
アプリケーションコンポーネントがデータオブジェクトモデルを参照、変更する手順は、データオブジェクトをアクセスする順番も含めて、全て規則的におこなわれ、排他制御もその中に含まれる。そのことで不必要な実装や、不注意な実装によるデッドロックを避けることが可能である。
（４）Ｆａｃａｄｅの多重化機能
（Ａ）概要
監視制御システムは、そのシステムダウンやシステム更新の為に装置（テレコンなど）を停止した時に、その機能をバックアップする多重系の構成にすることが求められる。また、監視制御システムでは、運転員の訓練や、新機能の確認のため、オンライン制御を行っている常用モードと、制御信号を出力しない訓練モードの実装が求められる。
（Ａ）概要
監視制御システムは、そのシステムダウンやシステム更新の為に装置（テレコンなど）を停止した時に、その機能をバックアップする多重系の構成にすることが求められる。また、監視制御システムでは、運転員の訓練や、新機能の確認のため、オンライン制御を行っている常用モードと、制御信号を出力しない訓練モードの実装が求められる。
これらは構成管理機能と呼ばれるもので、アプリケーションの振る舞いと密接にかかわるので、従来の作り方（全ての系で制御用データを共有し、状態を共有することで切り替える方式）ではシステムごとに開発を繰り返す必要がある。すなわち、データを共有するだけでは、べき等性のないデータへのアクセスがあると違った振る舞いをしてしまうため、プログラムコンテキストで緻密な構成チェックをする必要がある。また、アプリケーションも含めた複雑な状態を維持するので、障害が発生しやすい機能だった。
ところで、Ｆａｃａｄｅは汎用的なユニットでなければならない。それには、多重化処理プログラムをアプリケーションから独立して、汎用化する必要がある。
以上のような不都合が起きないよう、Ｆａｃａｄｅは以下に説明する多重化処理機能をもつ構成とする。
（Ｂ）Ｆａｃａｄｅの多重化構成
図２９は、監視制御システムの多重系構成を示す。常用装置１１と待機・訓練用装置１２は構内ＬＡＮ接続で多重化し、同様に常用装置１３と待機・訓練用装置１４は構内ＬＡＮ接続で多重化したシステム構成において、これら装置間のネットワーク通信手段としてのＦａｃａｄｅは、Ｆａｃａｄｅ１５と１６で二重化して同じ構内ＬＡＮに接続し、Ｆａｃａｄｅ１７と１８で二重化して同じ構内ＬＡＮに接続する。この二重化構成による通信を可能とするＦａｃａｄｅとして、システムが制御命令通信の機能を含むか否かで、異なる構成制御とする。以下、詳細に説明する。
図２９は、監視制御システムの多重系構成を示す。常用装置１１と待機・訓練用装置１２は構内ＬＡＮ接続で多重化し、同様に常用装置１３と待機・訓練用装置１４は構内ＬＡＮ接続で多重化したシステム構成において、これら装置間のネットワーク通信手段としてのＦａｃａｄｅは、Ｆａｃａｄｅ１５と１６で二重化して同じ構内ＬＡＮに接続し、Ｆａｃａｄｅ１７と１８で二重化して同じ構内ＬＡＮに接続する。この二重化構成による通信を可能とするＦａｃａｄｅとして、システムが制御命令通信の機能を含むか否かで、異なる構成制御とする。以下、詳細に説明する。
（ａ）制御命令通信機能を持たないシステム用の基本Ｆａｃａｄｅ
この場合、基本Ｆａｃａｄｅは、以下の構成とする。
この場合、基本Ｆａｃａｄｅは、以下の構成とする。
・「常用」モードと「待機」モードの区別無し。
・常にデータ収集とデータ提供を行う。
・一系のみのＦａｃａｄｅは、基本Ｆａｃａｄｅで構成する。
・多重系で用いるＦａｃａｄｅも、データオブジェクトモデルのプロパティに、イベント駆動のアプリケーションがないとき、または、イベントタイプがIdenpotentのデータがひとつもないときは、この基本Ｆａｃａｄｅで構成することが可能である。
なお、Idempotentとは、べき等性（その操作を何回繰り返しても一回だけ実行したときと同じ結果になるもの） 〜オペレーションを複数実行しても安全かどうかを示す。
（ｂ）制御命令通信機能を持つシステム用の多重化用Ｆａｃａｄｅ
この場合、多重化用Ｆａｃａｄｅは、以下の構成とする。
この場合、多重化用Ｆａｃａｄｅは、以下の構成とする。
・「常用」モード゛のＦａｃａｄｅはデータ収集とデータ提供を行う。
・「待機」モードのＦａｃａｄｅはデータ収集のみ行う。
・「待機」モードのＦａｃａｄｅはフリーランデュアル方式で動作する。
・「待機」モードから「運転」モードへの切り替えは、相手局のライフビート観察による自動切り替え方式と、装置ユニットパネルでの手動切り替え方式を持つ。
（ｃ）基本Ｆａｃａｄｅと多重化用Ｆａｃａｄｅの共通の機能
これらＦａｃａｄｅの共通の機能は、以下の構成とする。
これらＦａｃａｄｅの共通の機能は、以下の構成とする。
・「訓練」モードのＦａｃａｄｅは訓練用のデータ収集（シミュレーション結果）と「訓練」モードのシステムあるいはＦａｃａｄｅにデータ提供を行う。
・「訓練」モード切り替えは、Ｆａｃａｄｅの管理オブジェクトに対する切り替えメッセージコマンド方式か、装置ユニットパネルでの手動切り替え方式を持つ。
（Ｃ）Ｆａｃａｄｅの状態の種類
図３０は、Ｆａｃａｄｅの構成管理（状態の種類）を示す。図中の運転モードはシステムが稼動している状態、運用モードは常用または訓練モードで稼動している状態、常用モードは運転データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。訓練モードは訓練データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。待機モードは、多重化用Ｆａｃａｄｅのみに設け、運転テ゛ータの収集、イベントの受信を行うモードであり、常用モードのＦａｃａｄｅの障害に備え、ホットスタンバイ状態で待機している。ready状態は、ＯＳは起動しているがＦａｃａｄｅ機能は停止している状態、ＯＳstop状態は、電源は入っているがＯＳが起動していない状態である。
図３０は、Ｆａｃａｄｅの構成管理（状態の種類）を示す。図中の運転モードはシステムが稼動している状態、運用モードは常用または訓練モードで稼動している状態、常用モードは運転データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。訓練モードは訓練データの収集と配信、イベントの送受信（多重化用Ｆａｃａｄｅのみ）を行うモードである。待機モードは、多重化用Ｆａｃａｄｅのみに設け、運転テ゛ータの収集、イベントの受信を行うモードであり、常用モードのＦａｃａｄｅの障害に備え、ホットスタンバイ状態で待機している。ready状態は、ＯＳは起動しているがＦａｃａｄｅ機能は停止している状態、ＯＳstop状態は、電源は入っているがＯＳが起動していない状態である。
（Ｄ）Ｆａｃａｄｅの状態遷移
図３１は、基本Ｆａｃａｄｅの状態遷移図を示し、多重化用Ｆａｃａｄｅとの違いは待機モードが存在しない。そのため、他系を監視する必要がない。
図３１は、基本Ｆａｃａｄｅの状態遷移図を示し、多重化用Ｆａｃａｄｅとの違いは待機モードが存在しない。そのため、他系を監視する必要がない。
図３２は、多重化用Ｆａｃａｄｅの状態遷移図を示し、Ｆａｃａｄｅは電源投入後、運転モード状態になり、ハードウェアの異常または停止操作があるまで状態を維持する。停止操作、手動によるモード切替はＦａｃａｄｅメンテナンス用のＷｅｂ画面、またはＦａｃａｄｅオブジェクトの稼動状態プロパティを強制変更することで操作する。
図３２におけるモード遷移の条件は、
・待機モード→常用モード遷移は、自系が待機モード、他系に常用モードのＦａｃａｄｅがない、他系に待機モードのＦａｃａｄｅがあるときは自系の連続待機時間が最長であること、連続待機時間が同じＦａｃａｄｅがあるときはそちらよりＩＰアドレスが大きいこととする。
・待機モード→常用モード遷移は、自系が待機モード、他系に常用モードのＦａｃａｄｅがない、他系に待機モードのＦａｃａｄｅがあるときは自系の連続待機時間が最長であること、連続待機時間が同じＦａｃａｄｅがあるときはそちらよりＩＰアドレスが大きいこととする。
・常用モード→待機モード遷移は、初期化を完全に行うため、再起動経由で待機モードに移るようにする。例えば、自系でソフトウェア障害やハードウェア障害が発生したとき、自系が常用モードにあるとき、他系に待機モードのＦａｃａｄｅがあるときとする。
・自系が常用モードで、他系にも常用モードのＦａｃａｄｅを発見したときの常用モード→待機モード遷移は、初期化を完全に行うため、再起動経由で待機モードに移るようにする。例えば、連続常用時間を比較し自系が短いとき、連続常用時間が同じで自系のＩＰアドレスが大きいときとする。
（Ｅ）Ｆａｃａｄｅのデータオブジェクト構成
図３３は、基本Ｆａｃａｄｅまたは多重化用Ｆａｃａｄｅのデータオブジェクトモデルを示し、図５と異なる部分は、常用グループオブジェクトと待機・訓練用グループオブジェクトをもち、それぞれにＡ系用とＢ系用と共用のグループオブジェクト群をもつ。常用系と待機・訓練系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのグループオブジェクト群をアクセスするか判断する。
図３３は、基本Ｆａｃａｄｅまたは多重化用Ｆａｃａｄｅのデータオブジェクトモデルを示し、図５と異なる部分は、常用グループオブジェクトと待機・訓練用グループオブジェクトをもち、それぞれにＡ系用とＢ系用と共用のグループオブジェクト群をもつ。常用系と待機・訓練系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのグループオブジェクト群をアクセスするか判断する。
多重化の考え方は以下のとおりである。
（ａ）処理
多重化された各Ｆａｃａｄｅは独立した処理を基本とする。ただし、Ｆａｃａｄｅ以外の装置（先着優先等の処理が実装されていない装置）との送受信には常用/待機などの運転モード管理が必要である。
多重化された各Ｆａｃａｄｅは独立した処理を基本とする。ただし、Ｆａｃａｄｅ以外の装置（先着優先等の処理が実装されていない装置）との送受信には常用/待機などの運転モード管理が必要である。
（ｂ）受信情報
多重化されたＦａｃａｄｅは同一の情報をおのおの受信する。送信元のＦａｃａｄｅも多重化されている場合は、多重化された送信元の各々のＦａｃａｄｅから同一の情報が複数受信することとなる。Ｆａｃａｄｅの共用グループオブジェクト群は先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
多重化されたＦａｃａｄｅは同一の情報をおのおの受信する。送信元のＦａｃａｄｅも多重化されている場合は、多重化された送信元の各々のＦａｃａｄｅから同一の情報が複数受信することとなる。Ｆａｃａｄｅの共用グループオブジェクト群は先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
（ｃ）送信情報
各Ｆａｃａｄｅは相手Ｆａｃａｄｅへ送信を行う。送信相手Ｆａｃａｄｅが多重化されている場合は、多重化されているすべてのＦａｃａｄｅに対して送信する。
各Ｆａｃａｄｅは相手Ｆａｃａｄｅへ送信を行う。送信相手Ｆａｃａｄｅが多重化されている場合は、多重化されているすべてのＦａｃａｄｅに対して送信する。
（Ｆ）多重系システムの共有（公開）ディレクトリ構成
図３４は、共有（公開）ディレクトリ構成を示し、常用と待機・訓練用は別系統とする。Ａ系、Ｂ系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのディレクトリをアクセスするかパスが割り振られる。共用データオブジェクトディレクトリは、先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
図３４は、共有（公開）ディレクトリ構成を示し、常用と待機・訓練用は別系統とする。Ａ系、Ｂ系のコンピュータは、それぞれ自分が常用モードか訓練モードかで、Ｆａｃａｄｅのどちらのディレクトリをアクセスするかパスが割り振られる。共用データオブジェクトディレクトリは、先着優先後着廃棄処理または、後着優先（上書き）処理（情報ごとの設定により可能）を行う。
以上の多重化機能によれば、以下の効果がある。
（ａ）Ｆａｃａｄｅはフリーランデュアル方式で動作するので、構成制御プログラムを汎用化できる。アプリケーションと独立しているのでプログラムをシンプルにすることが可能である。そのことにより生産性と品質を向上することが期待できる。また、制御信号に対してべき等性のないデータが、１つもないＦａｃａｄｅは、制御信号を出しても影響はないので、基本Ｆａｃａｄｅを使ってシステムを簡略化できる。すなわち、基本Ｆａｃａｄｅは他系を監視する必要がないのでさらにシンプルに構築が可能である。
（ｂ）Ｆａｃａｄｅは共用データオブジェクトモデルを持つが、その利用で、アプリケーションは多重系を気にせず監視制御データにアクセスできる。余分なプログラムを作成する必要がなくなる共有データオブジェクトファイルについても、同様にアプリケーションは多重系を気にせずファイル操作を行うことができるので、その分のプログラムを記述する必要がなくなり生産性を向上できる。
１、２ 発変電所用テレコン
３ Ｆａｃａｄｅ一体型テレコン
４ マンマシン装置
５ データメンテナンスサーバ
６〜１０ 連携型専用ユニット（Ｆａｃａｄｅ）
１１ サブステーション（常用）
１２ サブステーション（待機・訓練）
１３ コントロールセンタ（常用）
１４ コントロールセンタ（待機・訓練）
１５〜１８ 連携型専用ユニット（Ｆａｃａｄｅ）
３ Ｆａｃａｄｅ一体型テレコン
４ マンマシン装置
５ データメンテナンスサーバ
６〜１０ 連携型専用ユニット（Ｆａｃａｄｅ）
１１ サブステーション（常用）
１２ サブステーション（待機・訓練）
１３ コントロールセンタ（常用）
１４ コントロールセンタ（待機・訓練）
１５〜１８ 連携型専用ユニット（Ｆａｃａｄｅ）
Claims (17)
- システムを構築するテレコン、監視室用マンマシン装置、データメンテナンスサーバなどの各装置が分散配置され、各装置は既存ネットワークを介して互いの装置間で通信、監視、制御情報を送受信処理する手段を備えた監視制御システムにおいて、
各装置とはそれぞれ分離構成または一体構成で各装置の構内ＬＡＮとＩＰネットワークとの間に設けられ、各装置の互いの通信方式およびデータ処理方式の違いを吸収してＩＰネットワークを介して各装置間の通信、監視、制御情報を送受信処理する連携型専用ユニットを設けたことを特徴とする監視制御システム。 - 前記連携型専用ユニットは、
ホワイトボードモデルを該連携型専用ユニット上の共有ファイルアーキテクチャで実現する各装置間の情報交換用のホワイトボード（共有メモリ空間）をもつ構造とし、各装置のアプリケーションは公開してよい情報をホワイトボード（共有メモリ空間）上に掲示し、掲示された情報は他のアプリケーションから自由に参照可能とし、資源のセマフォ管理は全てホワイトボード用ミドルウェアが処理する通信処理手段を設けたことを特徴とする請求項１に記載の監視制御システム。 - 前記連携型専用ユニットは、前記ホワイトボードモデルを共有ファイルアーキテクチャで実現する公開ディレクトリをもつ構造とし、この公開ディレクトリのファイルはＦＴＰまたはＮＦＳによって移動、読み書きを可能とし、ＦＴＰを使用するときはファイルの作成途中については、他からのアクセスを防止するために、ファイルが完成するまでの間は仮のファイル名を用い、ファイルが完成した後に公開されているファイル名に切り替えることを特徴とする請求項２に記載の監視制御システム。
- 前記連携型専用ユニットは、
前記各装置とＩＰネットワークの境界に、各装置間のデータ交換を委譲するプロキシモデルを設け、各装置のアプリケーションは、公開可能な情報をプロキシモデルに委譲し、他の装置のアプリケーションに前記プロキシモデルに委譲された情報を直接送付またはイベント伝達、および他のアプリケーションから参照可能とし、資源のセマフォ管理は全てプロキシモデル用ミドルウェアが処理をする通信処理手段を設けたことを特徴とする請求項１に記載の監視制御システム。 - 前記連携型専用ユニットは、前記プロキシモデルを共有データオブジェクトモデルアーキテクチャで実現し、データオブジェクトモデルと共有ディレクトリに格納された共有ファイルのみを外部に公開し、データオブジェクトモデルには広域ロードシェアシステムに共通で必要なリソースを格納し、
連携型専用ユニット名とＩＰアドレスなどのネットワークリソースは全ての連携型専用ユニットがそれぞれ同じ情報を連携型専用ユニットオブジェクト内に持ち、ＩＰネットワークに公開を望む全てのデータを該オブジェクトに登録し、各アプリケーションとデータオブジェクトモデルとのやりとりは、ＳＯＡＰまたはＣＯＲＢＡもしくは個々に用意するアプリケーションコンポーネントで行うことを特徴とする請求項４に記載の監視制御システム。 - 前記連携型専用ユニットは、前記データオブジェクトモデルのうち、連携型専用ユニットオブジェクトとグループオブジェクトは、各オブジェクトごとにファイリング機能を持ち、
ファイル保存のタイミングは、各オブジェクトのプロパティに指定された周期、または各オブジェクトへのファイル保存リクエスト、あるいは連携型専用ユニットオブジェクトのファイル保存つきシャットダウンリクエストによって行い、
ファイル読み込みのタイミングは、各オブジェクトへのオブジェクト再構築リクエスト、または連携型専用ユニットの立ち上げ時に自動的に行い、
ファイルは指定のない限り特定の非共有ディレクトリに保存し、共有ディレクトリ指定で他のノードからファイルによる参照を可能としたことを特徴とする請求項１〜５のいずれか１項に記載の監視制御システム。 - 前記連携型専用ユニットは、各装置毎の通信方式およびデータ処理方式の違いを吸収する通信処理手段、システムへの侵入やデータ盗聴、改ざんの予防対策としてのセキュリティ手段、各装置での障害発生が他の装置へ影響するのを防止する手段、イベントコントロールサービス手段、ネットワーク通信の管理手段、各装置の運転モード切り替え手段を備えたことを特徴とする請求項１〜６のいずれか１項に記載の監視制御システム。
- 前記セキュリティ手段は、プロキシ、ファイアウォール、暗号化、認証の処理手段を設け、
前記通信方式の違いを吸収する通信処理手段は、プロトコル変換処理手段を設け、
前記データ処理方式の違いを吸収する通信処理手段は、データオブジェクトの種類、データ管理オブジェクト、計測値オブジェクト、ＧＵＩオブジェクト、マルチメディアオブジェクト、ネットワークサービスへのアクセスと共有ファイルアクセスオブジェクトを処理するデータオブジェクトサーバを設け、
前記イベントコントロールサービス手段は、操作オブジェクトプロパティ、メッセージオブジェクトプロパティ、ネットワークサービスによるアクセスの処理手段を設け、
前記ネットワーク通信の管理手段は、ノード管理、コンポーネント管理、データベース位置管理、ユーザ管理の手段を設け、
前記運転モード切替手段は、通常運転モード、運転待機モード、運転訓練モードの切り替え手段を設けたことを特徴とする請求項１〜７のいずれか１項に記載の監視制御システム。 - 前記連携型専用ユニットのセキュリティ手段は、構内ＬＡＮで接続される内部装置との通信は暗号化せず、他の連携型専用ユニット間の通信は暗号化したことを特徴とする請求項１〜８のいずれか１項に記載の監視制御システム。
- 前記セキュリティ手段は、多元的セキュリティポリシを用い、その実現はセキュアＯＳを用い、サブジェクト・オブジェクト管理は独自に対象を定めて管理することを特徴とする請求項９に記載の監視制御システム。
- 前記連携型専用ユニットのオブジェクトになるアプリケーションプログラムの単位は、ＲＯＯＭアーキテクチャのコンポーネントをベースとすることを特徴とする請求項９に記載の監視制御システム。
- 前記連携型専用ユニットのオブジェクトになるデータファイルとデータオブジェクトの管理は全てデータオブジェクトモデル内で行い、データファイルのオブジェクトラベルは共有ディレクトリクラスで定義し、データオブジェクトのオブジェクトラベルはデータオブジェクトクラスで定義し、複数のデータオブジェクトを一括アクセスする対象に対してのオブジェクトラベルはグループクラスで定義し、サブジェクトラベルとオブジェクトラベルのリファレンスモニタ（セキュリティテーブル）は連携型専用ユニットクラスで定義することを特徴とする請求項９に記載の監視制御システム。
- 前記連携型専用ユニット間は、ＲＯＯＭポート機構を利用して、データオブジェクトモデルで発生するイベントとアプリケーションコンポーネントを連携することを特徴とする請求項１〜８に記載の監視制御システム。
- 前記アプリケーションコンポーネントは、ファイル更新通知手段を設け、この手段によって共有ファイルを利用した通信を行い、ファイル更新イベントはデータオブジェクトモデル中にある共有ディレクトリクラスのメンバによって管理することを特徴とする請求項１３に記載の監視制御システム。
- 前記アプリケーションコンポーネントは、通信プロトコルコンポーネントを設け、このコンポーネントは、
定周期にテレコンから計測データをＳＣＡＤＡに送信する周期計測と、
非周期計測で、ＳＣＡＤＡからの計測タイミングでテレコンの計測データをＳＣＡＤＡに送信し、計測データがリフレッシュ有りのときはＳＣＡＤＡ側とテレコン側の両方のキャッシュをキャンセルしてテレコンから最新の計測データを送信し、リフレッシュ無しのときは最寄の連携型専用ユニットのキャッシュにある計測データを送信するデマンド計測と、
ＳＣＡＤＡからテレコンに返事を要求または要求しない制御命令を送信する制御命令と、
テレコンからＳＣＡＤＡに返事を要求しないイベントやメッセージを送信するイベント・アラームと、
連携型専用ユニットに対して返事を要求する制御命令を送信する連携型専用ユニット制御とを備えたことを特徴とする請求項１３に記載の監視制御システム。 - 前記連携型専用ユニットは、データオブジェクトクラスに宣言されたメンバの書き換えにより発生するイベントによりアプリケーションロジックを起動し、前記アプリケーションロジックには連携型専用ユニットに組み込みのものと、ユーザが自由に書き換え可能なものを設け、ユーザが書き換え可能なものはＲＯＯＭポートの宣言でアプリケーションコンポーネントと連携させることを特徴とする請求項１３に記載の監視制御システム。
- 前記装置が構内ＬＡＮ接続で常用装置と待機・訓練用装置を二重化した監視制御システム構成において、
前記連携型専用ユニットは、二重化して同じ構内ＬＡＮに接続し、フリーランデュアル方式で動作する構成とし、
前記各連携型専用ユニットは、
それぞれ系ごとにデータオブジェクトモデルを持つ場合と、１つだけもつ場合を選択可能とし、データオブジェクトモデルを１つだけもつ場合は共用グループオブジェクト群を先着優先後着廃棄処理または、後着優先処理を行う構成とし、
共有データオブジェクトディレクトリ構成として、それぞれ系ごとのディレクトリを持つ場合と、１つの共用データオブジェクトディレクトリを持つ場合を選択可能とし、前記常用装置と待機・訓練用装置に対してそれが常用モードか待機・訓練モードかによって、どちらのディレクトリをアクセスするかのパスを割り振り、前記共用データオブジェクトディレクトリを先着優先後着廃棄処理または、後着優先処理を行う構成としたことを特徴とする請求項１〜８に記載の監視制御システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004016456A JP2005209048A (ja) | 2004-01-26 | 2004-01-26 | 監視制御システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004016456A JP2005209048A (ja) | 2004-01-26 | 2004-01-26 | 監視制御システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005209048A true JP2005209048A (ja) | 2005-08-04 |
Family
ID=34901598
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004016456A Pending JP2005209048A (ja) | 2004-01-26 | 2004-01-26 | 監視制御システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005209048A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008109417A (ja) * | 2006-10-26 | 2008-05-08 | Meidensha Corp | 遠方監視制御システムの伝送情報変換方式 |
| JP2017108448A (ja) * | 2013-06-25 | 2017-06-15 | グーグル インコーポレイテッド | ファブリックネットワーク |
| US9851958B2 (en) | 2013-12-26 | 2017-12-26 | International Business Machines Corporation | Method, apparatus, and computer program for specializing serializer |
-
2004
- 2004-01-26 JP JP2004016456A patent/JP2005209048A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008109417A (ja) * | 2006-10-26 | 2008-05-08 | Meidensha Corp | 遠方監視制御システムの伝送情報変換方式 |
| JP2017108448A (ja) * | 2013-06-25 | 2017-06-15 | グーグル インコーポレイテッド | ファブリックネットワーク |
| US9851958B2 (en) | 2013-12-26 | 2017-12-26 | International Business Machines Corporation | Method, apparatus, and computer program for specializing serializer |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hou et al. | Internet of things cloud: Architecture and implementation | |
| EP2378741B1 (en) | Systems and Methods for Conducting Communications Among Components of Multidomain Industrial Automation System | |
| EP2812801B1 (en) | Application context transfer for distributed computing resources | |
| CN102377796B (zh) | 基于OSGi的异构服务集成系统及方法 | |
| Hughes et al. | LooCI: a loosely-coupled component infrastructure for networked embedded systems | |
| CN108293017A (zh) | 用于使用物联网边缘安全网关的装置和方法 | |
| CN105183452B (zh) | 一种用于配电设备监测基于Spring AOP的远程规约服务系统 | |
| CN104753817A (zh) | 一种云计算消息队列服务本地模拟方法和系统 | |
| CN103617255B (zh) | 一种用于电力信息系统的业务数据交换同步系统及方法 | |
| CN109478055A (zh) | 在通用、智能系统中使用智能节点用于监测工业过程 | |
| CN106850418A (zh) | 一种智能家居网络的网关 | |
| Ghosh et al. | Designing a decentralized fault-tolerant software framework for smart grids and its applications | |
| Jia et al. | A web service framework for astronomical remote observation in Antarctica by using satellite link | |
| JP2005209048A (ja) | 監視制御システム | |
| CN114885012B (zh) | 物联网平台的系统接入方法及系统 | |
| Gaitan et al. | An IoT middleware framework for industrial applications | |
| EP3719646B1 (en) | Method for communicating in a network-distributed process control system and network-distributed process control system | |
| Goyal | The virtual business services fabric: An integrated abstraction of services and computing infrastructure | |
| Khan | A distributed computing architecture to enable advances in field operations and management of distributed infrastructure | |
| Mehanovic et al. | Brume-a horizontally scalable and fault tolerant building operating system | |
| Duller et al. | A lightweight and extensible platform for processing personal information at global scale | |
| Luo et al. | Study on computing grid distributed middleware and its application | |
| Lalanda et al. | Service-oriented approach for analytics in industry 4.0 | |
| Huang et al. | Enterprise service bus based on OSGi | |
| US20220078096A1 (en) | Management portal with object proxy for monitoring and controlling remote sites and equipment |