JP4671349B2

JP4671349B2 - パラメータ設定システム及び方法

Info

Publication number: JP4671349B2
Application number: JP2005295669A
Authority: JP
Inventors: 博幸遊佐; 舞木内
Original assignee: Central Research Institute of Electric Power Industry
Current assignee: Central Research Institute of Electric Power Industry
Priority date: 2005-10-07
Filing date: 2005-10-07
Publication date: 2011-04-13
Anticipated expiration: 2025-10-07
Also published as: JP2007104605A

Description

本発明は、パラメータ設定システム及び方法に関し、さらに詳しくは、ネットワークを介して接続された複数のコンピュータ間でデータの授受を円滑に行なわせるためのパラメータ設定システム及び方法に関する。

電力送電系統では、ＩＰルータ網、ＭＰＬＳ網、Ｅｔｈｅｒｎｅｔ（登録商標）網などのネットワークを介して多種多様のノード（サーバやＰＣなど）が相互に接続されている。また、このように多数のノードが混在したネットワーク環境下では様々なアプリケーションが動作している。ところで、これらのアプリケーションを用いて分散処理を行なう場合、ノードの通信制御手段がアプリケーション毎にデータ通信時の振る舞い、例えば１秒間あたりのデータ送信量、受信量などを制御する。この制御は通信制御手段に対して設定されたパラメータ、例えば１秒間あたりのデータ送信量、受信量などを指定するパラメータに基づいて実行される。例えば、２つのノード間でデータ通信を行なう場合、送信側のノードの通信制御手段によって送信される１秒間あたりのデータ量と受信側のノードの通信制御手段によって受信される１秒間あたりのデータ量とが一致するように各ノードの通信制御手段には同一のパラメータが設定されており、このパラメータに基づいて各ノードの通信制御手段はデータの送受信を実行する。また、各ノードに複数のアプリケーションが存在している場合、アプリケーション毎に通信遅延や信頼性への要求が異なるので、アプリケーション毎にパラメータの設定が必要になる。したがって、パラメータの管理は、アプリケーションの数が増加するほど複雑になる。

パラメータを管理する技術としては、例えば特許文献１に示す技術が知られている。特許文献１では、新規のアプリケーションをノードに追加してそのアプリケーションに対応したパラメータを設定する際、サブマネージャが予め蓄積しておいた既存のアプリケーションの情報を基にして新規のアプリケーションに対応したパラメータを決定するようにしている。
特開２００３−２１８９２８号公報

しかしながら、特許文献１の技術は、新規に追加したアプリケーションに対して現状に適したパラメータを設定することはできるが、既存のアプリケーションに対して状況の変化に応じたパラメータ変更を行なうことができないという欠点がある。

そこで、本発明は、状況に応じた柔軟なパラメータ設定を実現することができるパラメータ設定システム及び方法を提供することを目的とする。

かかる目的を達成するために、請求項１記載の発明にかかるパラメータ設定システムは、ネットワークを介して接続されている複数のノード間でのデータ通信の振る舞いを制御する通信制御手段を各ノードに備え、前記振る舞いを指定するパラメータを前記通信制御手段に対して設定するものであり、前記各ノードに、複数の単位のそれぞれに対応した前記パラメータが記述されていると共に順位が予め付与されているパラメータ設定ファイルを記憶する記憶手段と、前記パラメータの取得要求を示すパラメータ取得要求信号が前記通信制御手段から入力された場合に前記通信制御手段によって指定されたパラメータ設定ファイルから前記パラメータを抽出して前記通信制御手段に対して設定するパラメータ設定手段とを設け、前記通信制御手段は、通信データが入力されたことを契機として、前記パラメータ設定ファイルに予め付与されている順位の高い順に、前記通信データの属性のうち各順位のパラメータ設定ファイルに対応する属性に対応する前記パラメータ設定ファイルが前記記憶手段内に存在しているか否かを識別し、存在している場合には当該パラメータ設定ファイルを指定するものであり、さらに、前記単位がテンプレート単位，アプリケーション単位，アプリケーション優先度単位，ノード単位，システム単位であると共に、これら単位に対応するパラメータ設定ファイルの順位が、テンプレート用パラメータ設定ファイルの順位が１位、アプリケーション用パラメータ設定ファイルの順位が２位、アプリケーション優先度用パラメータ設定ファイルの順位が３位、ノード用パラメータ設定ファイルの順位が４位、システム全体用パラメータ設定ファイルの順位が５位であるようにしている。

また、請求項３記載の発明にかかるパラメータ設定方法は、ネットワークを介して接続されている複数のノード間でのデータ通信の振る舞いを制御する通信制御手段を各ノードに備え、前記振る舞いを指定するパラメータを前記通信制御手段に対して設定するものであり、複数の単位のそれぞれに対応した前記パラメータが記述されていると共に順位が予め付与されているパラメータ設定ファイルを前記各ノードに備えられた記憶手段に記憶するステップと、前記各ノードに備えられたパラメータ設定手段が前記パラメータの取得要求を示すパラメータ取得要求信号が前記通信制御手段から入力された場合に前記通信制御手段によって指定されたパラメータ設定ファイルから前記パラメータを抽出して前記通信制御手段に対して設定するステップとを備え、前記通信制御手段は、通信データが入力されたことを契機として、前記パラメータ設定ファイルに予め付与されている順位の高い順に、前記通信データの属性のうち各順位のパラメータ設定ファイルに対応する属性に対応する前記パラメータ設定ファイルが前記記憶手段内に存在しているか否かを識別し、存在している場合には当該パラメータ設定ファイルを指定し、さらに、前記単位がテンプレート単位，アプリケーション単位，アプリケーション優先度単位，ノード単位，システム単位であると共に、これら単位に対応するパラメータ設定ファイルの順位が、テンプレート用パラメータ設定ファイルの順位が１位、アプリケーション用パラメータ設定ファイルの順位が２位、アプリケーション優先度用パラメータ設定ファイルの順位が３位、ノード用パラメータ設定ファイルの順位が４位、システム全体用パラメータ設定ファイルの順位が５位であるようにしている。

したがって、ネットワーク単位やノード単位などの複数の単位に順位を付与しておき、記憶手段に記憶されているパラメータのうち、最高順位の単位に属するパラメータ、つまり、現状に最も適したパラメータを通信制御手段に対して設定する。そして、通信制御手段は、その設定されたパラメータに基づいてデータ通信の振る舞いを制御する。

また、請求項２記載の発明は、請求項１記載のパラメータ設定システムにおいて、特定の前記パラメータを複数のノード間で共有するようにしている。また、請求項４記載の発明は、請求項３記載のパラメータ設定方法において、特定の前記パラメータを複数のノード間で共有するようにしている。この場合、ノード単位のパラメータをノード毎に保持するようにし、ノード間で協働が必要なパラメータ、例えば、ネットワーク単位のパラメータを共有する。

以上のように、請求項１記載のパラメータ設定システム及び請求項３のパラメータ設定方法によれば、記憶手段に記憶されているパラメータのうち、最高順位の単位に属するパラメータ、つまり、現状に最も適したパラメータを通信制御手段に対して設定するようにしたので、ネットワークの状況やノードの状況などに応じてパラメータを柔軟に設定することができ、複数のノード間で行なわれるデータ通信の円滑化を図ることができる。例えば、複数のノード間での通信処理の競合を解消することができる。

請求項２記載のパラメータ設定システム及び請求項４記載のパラメータ設定方法によれば、ノード単位のパラメータをノード毎に保持するようにし、ノード間で協働が必要なパラメータを共有するようにしたので、ノード間で共有が必要なパラメータのみがネットワークを介して授受されるので、全てのパラメータを配布する場合に比べて、データ量を抑えることができる。

以下、本発明の構成を図面に示す最良の形態に基づいて詳細に説明する。

図１〜６に本発明のパラメータ設定システムの一実施形態を示す。この実施形態のパラメータ設定システム１は、ネットワークを介して接続されている処理要求ノード４と処理実行ノード５との間でのデータ通信の振る舞いを制御する通信制御手段として機能する送信制御部１７及び受信制御部１８を処理要求ノード４に、送信制御部３０及び受信制御部３１を処理実行ノード５にそれぞれ備え、データ通信の振る舞いを指定するパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定するものである。各ノードに予め設定されている順位が付与された複数の単位、具体的には、テンプレート単位、アプリケーション単位、アプリケーション優先度単位、ノード単位、システム単位のそれぞれに対応したパラメータを記憶する記憶手段として機能するメモリ２６と、パラメータの取得要求を示すパラメータ取得要求信号が入力されたことを契機にメモリ２６から最高順位の単位に属するパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定するパラメータ設定手段として機能するパラメータ管理部１６、３４とを備えている。

図１に示すように、パラメータ設定システム１は、伝送路２、３を介して相互に接続されている処理要求ノード４及び処理実行ノード５から構成されている。処理要求ノード４は、ＣＰＵ６及びハードディスク７を備えている。また、処理実行ノード５は、ＣＰＵ８及びハードディスク９を備えている。これらのノード間では分散処理が行なわれる。

処理要求ノード４、処理実行ノード５のそれぞれには複数種類のアプリケーションがハードディスク７、９にインストールされている。ＣＰＵ６、８のそれぞれには入力装置１０、１１が接続されており、上記のアプリケーションは、入力装置１０、１１から入力された信号に応答して起動する。

処理要求ノード４と処理実行ノード５との間で分散処理を行なう場合には、例えば、ＣＰＵ６上で動作するアプリケーション１２が処理要求を発し、その処理要求を受けたＣＰＵ８のアプリケーション１３が処理要求ノード４から送られてきた通信データに対して処理要求の内容に従って処理を実行する。そして、その処理が完了すると、アプリケーション１３はその処理結果をアプリケーション１２に送信する。なお、本実施形態では、処理要求ノード４のアプリケーション１２と処理実行ノード５のアプリケーション１３とで分散処理を行なう場合を例に挙げて説明するが、これに限ることなく、分散処理は、処理要求ノード４に存在する複数種類のアプリケーションと処理実行ノード５に存在する複数種類のアプリケーションとで行なうことも勿論可能であり、このような場合であっても本発明は言うまでもなく適用可能である。また、ネットワークを介して３つ以上のノードが相互に接続されており、これら全てのノードを用いて分散処理を行なうような場合であっても本発明は言うまでもなく適用可能である。

以下、処理要求ノード４の構成について説明する。ＣＰＵ６は、ハードディスク７などの大容量記憶手段に格納されたプログラムを実行することによってファイルシステム１４、入出力インターフェース１５、パラメータ管理部１６、送信制御部１７、受信制御部１８、送信実行部１９、受信実行部２０、及びＮＦＳサーバ２１として機能する。

ファイルシステム１４は、処理要求ノード４のＯＳに備えられている機能であり、ハードディクスク７から所定のデータを読み出し、パラメータ保持用ディレクトリ２２を形成する。パラメータ保持用ディレクトリ２２は、送信制御部１７、受信制御部１８に対して設定されるパラメータを記憶するための記憶領域であり、このパラメータ保持用ディレクトリ２２には、送信制御部１７及び受信制御部１８によって用いられるパラメータがディレクトリの階層構造によって段階的に記憶されている。なお、本実施形態では、上記の「ＯＳ」としては、ＪＡＶＡ（登録商標）を用いることができるＯＳ、例えばＬｉｎｕｘあるいはＷｉｎｄｏｗｓＸＰ（登録商標）などが使用可能である。

パラメータ保持用ディレクトリ２２は、例えば、図２に示すように、アプリケーションに対して設定されているテンプレートを示す「templateInfo」ディレクトリ２３、ノードを示す「nodeInfo」ディレクトリ２４、アプリケーションを示す「apInfo」ディレクトリ２５、及びシステム全体を示すシステムディレクトリ（図示省略）が最上位の階層に並列に配置され、「nodeInfo」ディレクトリ２４の１段階下の階層に、自身の代表ＩＰアドレスや他のノードの代表ＩＰアドレスを示した複数のノードＩＰアドレスディレクトリが並列に配置され、「templateInfo」ディレクトリ２３の１段階下の階層に、アプリケーションに対して設定されている複数のテンプレートのＩＤ番号で示した「１」ディレクトリ、「２」ディレクトリ、及び「３」ディレクトリなどの複数のテンプレートＩＤディレクトリが並列に配置され、「apInfo」ディレクトリ２５の１段階下の階層に、アプリケーションの優先度を数字で示した「１００」ディレクトリや「５００」ディレクトリなどの複数のアプリケーション優先度ディレクトリが並列に配置され、アプリケーション優先度ディレクトリの１段階下の階層に、その優先度に属するアプリケーションをアプリケーション名で示した「CountupAP」ディレクトリ、「MessageAP」ディレクトリ、及び「TestAP」ディレクトリなどのアプリケーション個別ディレクトリがツリー構造で配置されることによって構成されている。そして、システムディレクトリ、ノードＩＰアドレスディレクトリ、テンプレートＩＤディレクトリ、アプリケーション優先度ディレクトリ、及びアプリケーション個別ディレクトリのそれぞれのディレクトリの中には「#properties」というパラメータ設定ファイルが設けられており、このファイルには送信制御部１７、３０や受信制御部１８、３１に対して設定されるパラメータが記述されている。

具体的には、システムディレクトリのパラメータ設定ファイル（以下、「システム全体用パラメータ設定ファイル」と称する）には、システム全体、すなわち、ネットワークに接続されている全てのノードにおいてデータ通信の振る舞いを同一にするためのパラメータが記述されている。

各ノードＩＰアドレスディレクトリのパラメータ設定ファイル（以下、「ノード用パラメータ設定ファイル」と称する）には、個々のノードに対して設定されるパラメータが記述されている。例えば、ＩＰアドレスが「１９２．１６８．７．１１」のノードＩＰアドレスディレクトリに属するノード用パラメータ設定ファイルには、処理要求ノード４に対して設定されるパラメータが記述されている。

各テンプレートＩＤディレクトリのパラメータ設定ファイル（以下、「テンプレート用パラメータ設定ファイル」と称する）には、個々のテンプレートに対して設定されるパラメータが記述されている。例えば、「１」ディレクトリのテンプレート用パラメータ設定ファイルには、ＩＤ番号が「１」のテンプレートに対して設定されるパラメータが記述されている。

各アプリケーション優先度ディレクトリのパラメータ設定ファイル（以下、「アプリケーション優先度用パラメータ設定ファイル」と称する）には、その優先度に属するアプリケーションに対して設定されるパラメータが記述されている。例えば、「１００」ディレクトリのアプリケーション優先度用パラメータ設定ファイルには、優先度が「１００」のアプリケーション（「CountupAP」及び「MessageAP」）に対して設定されるパラメータが記述されている。

各アプリケーション個別ディレクトリのパラメータ設定ファイル（以下、「アプリケーション用パラメータ設定ファイル」と称する）には、個々のアプリケーションに対して設定されるパラメータが記述されている。例えば、「MessageAP」ディレクトリのアプリケーション用パラメータ設定ファイルには、「MessageAP」という名称のアプリケーションに対して設定されるパラメータが記述されている。

なお、上記の「アプリケーションに対して設定されている複数のテンプレート」とは、例えば、１つのアプリケーションが複数の処理実行ノードに対して分散処理を依頼する場合、その処理実行ノードの数だけ設定されたテンプレートのことを示す。また、上記の「アプリケーションの優先度」とは、アプリケーションがデータ伝送を行なう際に、それぞれのデータに対して与えるものである。また、テンプレート用パラメータ設定ファイル、アプリケーション用パラメータ設定ファイル、アプリケーション優先度用パラメータ設定ファイル、及びノード用パラメータ設定ファイルはいずれも任意で設定しなくても良いが、システム全体用パラメータ設定ファイルはＮＦＳサーバ２１やＮＦＳクライアント３６といったネットワーク共有機能によってネットワークを介して接続されている全ノードを通して必ず共通のものが設定される。また、本実施形態では、テンプレート用パラメータ設定ファイルには、例えば伝送路２、３の両方を使用してデータ通信を行なうこと（以下、これを「２ルート通信」と称する）を示すパラメータが記述されており、それ以外のパラメータ設定ファイルには、伝送路２のみを使用してデータ通信を行なうこと（以下、これを「片ルート通信」と称する）を示すパラメータが記述されている例を挙げて説明する。しかし、本発明は、２ルート通信に限られるものではなく、片ルート通信のみを行なう場合であっても適用することが可能であり、この場合には、例えば全てのパラメータ設定ファイルに片ルート通信を示すパラメータを記述しておけば良い。また、上記の２ルート通信を示すパラメータと、例えば通信データが送達した否かを確認する送達確認機能をノードに付与するパラメータや通信データが所定のノードに送達しなかった場合に通信データを再送する再送機能をノードに付与するパラメータなどを併用することによってデータ通信の高信頼化及びＱｏｓ保証を図ることもできる。

アプリケーション１２は、入力装置１０からＣＰＵ６に入力された分散処理開始信号を契機に、ハードディスク７に記憶されている所定のプログラムやデータに基づいて分散処理で用いる通信データを生成する。また、その通信データの本体部のメモリ領域に対して処理要求と処理実行ノード５の代表ＩＰアドレスとを付与する。なお、本実施形態では、アプリケーション１２が、通信データの本体部のメモリ領域に対して処理実行ノード５の代表ＩＰアドレスを付与するようにしているが、これに限ることなく、入出力インターフェース１５にて代表ＩＰアドレスを付与するようにしても良い。

アプリケーション１２は、通信データを入出力インターフェース１５を介して送信制御部１７に入力する。また、アプリケーション１２は、分散処理開始信号が入力されたことを契機に信号をパラメータ管理部１６に入力する。パラメータ管理部１６は、アプリケーション１２から信号が入力されたことを契機に、ファイルシステム１４のパラメータ保持用ディレクトリ２２から全てのパラメータ設定ファイルを読み出し、それらをディレクトリ２２の階層構造に従って段階的にメモリ２６上に保持する。

テンプレート用パラメータ設定ファイル、アプリケーション用パラメータ設定ファイル、アプリケーション優先度用パラメータ設定ファイル、ノード用パラメータ設定ファイル、及びシステム全体用パラメータ設定ファイルには予め順位が付与されている。換言すると、テンプレート単位、アプリケーション単位、アプリケーション優先度単位、ノード単位、システム単位のそれぞれに属するパラメータには予め順位が付与されている。具体的には、テンプレート用パラメータ設定ファイルの順位を１位とし、アプリケーション用パラメータ設定ファイルの順位を２位とし、アプリケーション優先度用パラメータ設定ファイルの順位を３位とし、ノード用パラメータ設定ファイルの順位を４位とし、システム全体用パラメータ設定ファイルの順位を５位として、パラメータ設定ファイルと順位との関係が記述された順位テーブル１７ａが送信制御部１７のメモリ領域に保持されている。

送信制御部１７は、通信データが入力されたことを契機に、メモリ領域から順位テーブル１７ａを読み出し、その順位テーブル１７ａに記述されている順位と、通信データの属性（例えば、テンプレートＩＤ、アプリケーション名、優先度、送信ＩＰアドレス、受信ＩＰアドレス）とに基づいてメモリ２６に保持されているパラメータ設定ファイルの中からパラメータ設定ファイルを指定するとともに、パラメータ取得要求信号をパラメータ管理部１６に入力する。

送信制御部１７がメモリ２６上のパラメータ設定ファイルを指定する場合、先ず、送信制御部１７は、通信データの属性のテンプレートＩＤに対応したテンプレート用パラメータ設定ファイルがメモリ２６内に存在しているか否かを識別する。存在していた場合には、そのテンプレート用パラメータ設定ファイルを指定する。存在していなかった場合には、通信データの属性のアプリケーション名に対応したアプリケーション用パラメータ設定ファイルがメモリ２６内に存在しているか否かを識別する。存在していた場合には、そのアプリケーション用パラメータ設定ファイルを指定する。存在していなかった場合には、通信データの属性の優先度に対応したアプリケーション優先度用パラメータ設定ファイルがメモリ２６内に存在しているか否かを識別する。存在していた場合には、そのアプリケーション優先度用パラメータ設定ファイルを指定する。存在していなかった場合には、送信ＩＰアドレス、受信ＩＰアドレスに対応したノード用パラメータ設定ファイルがメモリ２６内に存在しているか否かを識別する。存在していた場合には、そのノード用パラメータ設定ファイルを指定する。存在していなかった場合には、システム全体用パラメータ設定ファイルを指定する。

パラメータ管理部１６は、図３のフローチャートに示すように、アプリケーション１２が起動したことを契機に（Ｓ１）、ファイルシステム１４のパラメータ保持用ディレクトリ２２から全てのパラメータ設定ファイルを読み出し（Ｓ２）、そのファイルをメモリ２６に保持する（Ｓ３）。パラメータ管理部１６は、送信制御部１７から何らかの要求信号が入力されたか否かを常時監視しており（Ｓ４）、要求信号が入力されない間（Ｓ４；Ｎｏ）、待機状態となる（Ｓ５）。パラメータ管理部１６は、送信制御部１７から要求信号が入力された場合（Ｓ４；Ｙｅｓ）、その要求信号がパラメータの取得要求を示すパラメータ取得要求信号であるか否かの識別を行なう（Ｓ６）。そして、パラメータ管理部１６は、入力された要求信号がパラメータ取得要求信号であると識別した場合（Ｓ６；Ｙｅｓ）、パラメータ取得要求信号に基づいて送信制御手段によって指定されたパラメータ設定ファイルからパラメータを抽出し、それを送信制御部１７及び受信制御部１８に対して設定する（Ｓ７）。パラメータ管理部１６は、入力された要求信号がパラメータ取得要求信号ではないと識別した場合（Ｓ６；Ｎｏ）、その要求信号がパラメータの更新を指示する更新要求信号であるか否かの識別を行なう（Ｓ８）。そして、パラメータ管理部１６は、入力された要求信号が更新要求信号であると識別した場合（Ｓ８；Ｙｅｓ）、ファイルシステム１４のパラメータ保持用ディレクトリ２２から改めて全てのパラメータ設定ファイルを読み出し、その読み出したファイルをメモリ２６上に保持する（Ｓ２）。パラメータ管理部１６は、入力された要求信号が更新要求信号ではないと識別した場合（Ｓ８；Ｎｏ）、その要求信号がパラメータ設定システム１の終了を指示する終了要求信号であるか否かの識別を行なう（Ｓ９）。そして、パラメータ管理部１６は、入力された要求信号が終了要求信号であると識別した場合（Ｓ９；Ｙｅｓ）、全ての処理を終了する。入力された要求信号が終了要求信号ではないと識別した場合（Ｓ９；Ｎｏ）、送信制御部１７から何らかの要求信号が入力されたか否かの監視を続行する（Ｓ４）。

送信制御部１７は、図４のフローチャートに示すように、通信データが入力されると（Ｓ１０１）、先ず、その通信データに処理要求が付与されているか否かを識別する（Ｓ１０２）。処理要求が付与されていない場合（Ｓ１０２；Ｎｏ）、待機状態となる（Ｓ１０３）。処理要求が付与されていた場合（Ｓ１０２；Ｙｅｓ）、次に、新規の通信であるか否かを識別する（Ｓ１０３）。新規の通信ではなかった場合（Ｓ１０４；Ｎｏ）、送信制御部１７及び受信制御部１８は既存のパラメータを利用する（Ｓ１０５）。新規の通信の場合（Ｓ１０４；Ｙｅｓ）、送信制御部１７は、メモリ２６内の順位１位のパラメータ設定ファイルの存在を確認し（Ｓ１０６）、メモリ２６内に順位１位のパラメータ設定ファイルが存在しない場合には（Ｓ１０７；Ｎｏ）、次の順位のパラメータ設定ファイルの存在を確認する（Ｓ１０８）。パラメータ設定ファイルが存在する場合には（Ｓ１０７；Ｙｅｓ）、送信制御部１７及び受信制御部１８は、そのパラメータ設定ファイルに記述されているパラメータを通信で利用するパラメータとして取得する（Ｓ１０９）。送信制御部１７及び受信制御部１８は、その取得したパラメータに基づいて処理を実行する（Ｓ１１０）。送信制御部１７は、アプリケーション１２から入力される要求の種類を識別しており、アプリケーション１２から入力された要求が更新要求であった場合（Ｓ１１１；Ｙｅｓ）、現在設定されているパラメータを更新する（Ｓ１１２）。アプリケーション１２から入力された要求が更新要求ではなく（Ｓ１１１；Ｎｏ）、アプリケーション１２から入力された要求が終了要求であった場合（Ｓ１１３；Ｙｅｓ）、全ての処理を終了し、アプリケーション１２から入力された要求が終了要求でなかった場合（Ｓ１１３；Ｎｏ）、通信データに処理要求が付与されているか否かの識別を再び行なう（Ｓ１０２）。

送信制御部１７は、アドレステーブル２７をメモリ領域に保持している。アドレステーブル２７には、例えば処理実行ノード５に設定されている代表ＩＰアドレスとサブＩＰアドレスとが対応付けられた状態で記述されている。例えば代表ＩＰアドレスは伝送路２に対応しており、サブＩＰアドレスは伝送路３に対応している。送信制御部１７は、パラメータ管理部１６によってパラメータが設定されたことを契機にメモリ領域からアドレステーブル２７を読み出す。そして、このアドレステーブル２７に基づいて通信データを複製する。これにより伝送路の数だけ通信データが生成される。つまり、本実施形態では、２つの通信データが生成される。

送信制御部１７は、２つの通信データをパケット化し、通信データごとのパケットのヘッダにパケットの順序を示すシーケンス番号を付与する。さらに、一方の通信データの各パケットのヘッダに代表ＩＰアドレスを、他方の通信データの各パケットのヘッダにサブＩＰアドレスを付与する。

送信実行部１７は、代表ＩＰアドレスが付与されたパケットを通信プロトコル４０、例えば、ＴＣＰ／ＩＰに従って伝送路２を用いて処理実行ノード５に送信するとともに、サブＩＰアドレスが付与されたパケットを通信プロトコル４０に従って伝送路３を用いて処理実行ノード５に送信する。

受信制御部１８は、受信実行部２０で受信したパケットが後着したものであるか否かを判断する。すなわち、受信制御部１８は、先着パケットのシーケンス番号を記録するログファイル２８を有し、受信実行部２０が受信したパケットのヘッダ内のシーケンス番号を読み取って、シーケンス番号がログファイル２８に存在するか否かを確認する。ログファイル２８に存在しなければ、受信パケットは過去に受信したことにない先着パケットであると判断し、そのシーケンス番号をログファイル２８に書き込む。これにより、次回同一のパケットが受信された場合に、当該パケットが後着であることがログファイル２８により確認できる。一方、受信パケットのシーケンス番号が既にログファイル２８にある場合は、過去に受信されたパケットと同一の後着パケットであると判断し、廃棄する。さらに、受信制御部１８は、パケットのヘッダからＩＰアドレスを取り除き、シーケンス番号に従ってパケットを繋ぎ合わせて通信データを復元する。そして、その通信データを入出力インターフェース１５を介してアプリケーション１２に送る。なお、アプリケーション１２、入出力インターフェース１５及び受信制御部１８は、処理要求ノード４の代表ＩＰアドレスを認識しており、受信実行部２０で受信した通信データにおいて、通信データの本体部に代表ＩＰアドレスが付与されている通信データに対してのみ処理を実行するように構成されている。

ＮＦＳサーバ２１は、処理要求ノード４のＯＳの機能の一部あるいはプログラムとしてハードディスク７にインストールされており、ＣＰＵ６起動時にハードディスク７から読み出され、起動する。通信機能（図示省略）を用いることにより遠隔のＮＦＳクライアント３６に対してファイルシステム１４のパラメータ保持用ディレクトリ２２を公開する。

次に、処理実行ノード５の構成について説明する。ＣＰＵ８は、ハードディスク９などの大容量記憶手段に格納されたプログラムを実行することによって入出力インターフェース２９、送信制御部３０、受信制御部３１、送信実行部３２、受信実行部３３、パラメータ管理部３４、ファイルシステム３５、及びＮＦＳクライアント３６として機能する。なお、ＣＰＵ６及びＣＰＵ８は、入出力インターフェース２９、送信制御部３０、受信制御部３１、送信実行部３２、受信実行部３３、パラメータ管理部３４、及びファイルシステム３５は、ＣＰＵ６における入出力インターフェース１５、送信制御部１７、受信制御部１８、送信実行部１９、受信実行部２０、パラメータ管理部１６、及びファイルシステム１４と同一の機能を有しているので、以下、上記の説明と重複する部分の説明は省略し、上記で説明した機能と異なる機能についてのみ説明する。

ＮＦＳクライアント３６は、処理実行ノード５のＯＳの機能の一部あるいはプログラムとしてハードディスク９にインストールされており、ＣＰＵ８起動時にハードディスク９から読み出され、起動する。処理要求ノード４のＮＦＳサーバ２１と通信を行なうことにより、ＮＦＳサーバ２１が公開したパラメータ保持用ディレクトリ２２をファイルシステム３５のマウントポイントにマウントする。

パラメータ管理部３４は、アプリケーション１３から信号が入力されたことを契機に、ファイルシステム３５のパラメータ保持用ディレクトリ２２から全てのパラメータ設定ファイルを読み出し、それらをメモリ３７上に保持する。そして、パラメータ管理部３４は、入力装置１１からの入力された信号に応答して送信制御部３０及び受信制御部３１に対してパラメータを設定する。

受信制御部３１は、受信実行部３３で受信したパケットが後着したものであるか否かをログファイル３８を用いて判断し、後着したものについては廃棄し、先着したパケットを元の通信データに復元して、入出力インターフェース２９を介してアプリケーション１３に入力する。なお、アプリケーション１３、入出力インターフェース２９及び受信制御部３１は、処理実行ノード５の代表ＩＰアドレスを認識しており、受信実行部３１で受信した通信データにおいて、通信データの本体部に代表ＩＰアドレスが付与されている通信データに対してのみ処理を実行するように構成されている。

アプリケーション１３は、通信データに付与された処理要求の内容に従って処理を実行する。そして、その処理が完了すると、通信データを生成し、その通信データの本体部のメモリ領域に対して処理結果と処理要求ノード４の代表ＩＰアドレスとを付与する。アプリケーション１３は、通信データを入出力インターフェース２９を介して送信制御部３０に入力する。なお、本実施形態では、アプリケーション１３が、通信データの本体部のメモリ領域に対して処理要求ノード４の代表ＩＰアドレスを付与するようにしているが、これに限ることなく、入出力インターフェース２９にて代表ＩＰアドレスを付与するようにしても良い。

送信制御部３０は、アドレステーブル３９をメモリ領域に保持している。アドレステーブル３９には、例えば処理要求ノード４に設定されている代表ＩＰアドレスとサブＩＰアドレスとが対応付けられた状態で記述されている。代表ＩＰアドレスは伝送路２に対応しており、サブＩＰアドレスは伝送路３に対応している。送信制御部３０は、アプリケーション１３から通信データが入力されたことを契機にメモリ領域からアドレステーブル３９を読み出す。そして、このアドレステーブル３９に基づいて通信データを複製する。これにより伝送路の数だけ通信データが生成される。つまり、本実施形態では、同一の通信データが２つ生成される。

送信制御部３０は、２つの通信データをパケット化し、通信データごとのパケットのヘッダにパケットの順序を示すシーケンス番号を付与する。さらに、一方の通信データの各パケットのヘッダに代表ＩＰアドレスを、他方の通信データの各パケットのヘッダにサブＩＰアドレスを付与する。

送信実行部３２は、代表ＩＰアドレスが付与されたパケットを通信プロトコル（例えば、ＴＣＰ／ＩＰ）に従って伝送路２を用いて処理要求ノード４に送信するとともに、サブＩＰアドレスが付与されたパケットを通信プロトコルに従って伝送路３を用いて処理要求ノード４に送信する。

次に、処理要求ノード４での処理の流れを図５のフローチャートを参照しながら説明する。アプリケーション１２が通信データを生成する（Ｓ２０１）。アプリケーション１２は通信データのメモリ領域に処理要求を付与する（Ｓ２０２）。送信制御部１７は、通信データの属性を参照してパラメータを決定する（Ｓ２０３）。そのパラメータが２ルート通信を示すものである場合（Ｓ２０４；Ｙｅｓ）、通信データを複製する（Ｓ２０５）。各通信データをパケット化する（Ｓ２０６）。通信データ毎のパケットのヘッダにパケットの順序を示すシーケンス番号を付与する（Ｓ２０７）。アドレステーブル２７に基づいて一方の通信データの各パケットのヘッダに処理実行ノード５の代表ＩＰアドレスを付与し、他方の通信データの各パケットのヘッダに処理実行ノード５のサブＩＰアドレスを付与する（Ｓ２０８）。他方、パラメータが片ルート通信を示すものである場合（Ｓ２０４；Ｎｏ）、通信データをパケット化する（Ｓ２０９）。各パケットのヘッダにパケットの順序を示すシーケンス番号を付与する（Ｓ２１０）。各パケットのヘッダに処理実行ノード５の代表ＩＰアドレスを付与する（Ｓ２１１）。送信実行部１９は、各パケットのヘッダに付与された代表ＩＰアドレスあるいはサブＩＰアドレスに従ってデータ通信を行なう。具体的には、ヘッダに代表ＩＰアドレスが付与されたパケットは、伝送路２を経由して処理実行ノード５に送られ、ヘッダにサブＩＰアドレスが付与されたパケットは、伝送路３を経由して処理実行ノード５に送られる（Ｓ２１２）。受信制御部１８では、処理実行ノード５からの返信の通信データが受信実行部２０で受信されずに（Ｓ２１３；Ｎｏ）、予め定められた制限時間が経過していない場合（Ｓ２１４；Ｎｏ）、待機状態となる（Ｓ２１５）。処理実行ノード５から返信の通信データが受信実行部２０で受信されずに（Ｓ２１３；Ｎｏ）、予め定められた制限時間が経過した場合（Ｓ２１４；Ｙｅｓ）、エラー処理を行ない（Ｓ２１６）、全ての処理を終了する。他方、処理実行ノード５から返信の通信データを受信実行部２０で受信した場合（Ｓ２１３；Ｙｅｓ）、受信制御部１８は、受信実行部２０で受信したパケットが後着であるか否かをログファイル２８を用いて判断し、後着パケットである場合（Ｓ２１７；Ｙｅｓ）、パケットを廃棄する（Ｓ２１８）。先着パケットである場合（Ｓ２１７；Ｎｏ）、そのパケットのヘッダからＩＰアドレスを外す（Ｓ２１９）。そして、パケットをシーケンス番号に従って繋ぎ合わせて、処理実行ノード５のアプリケーション１３が生成した通信データに復元する（Ｓ２２０）。受信制御部１８は、その通信データを入出力インターフェース１６に入力する（Ｓ２２１）。入出力インターフェース１６は、通信データからアプリケーション１３での処理結果を抽出し（Ｓ２２２）、その処理結果をアプリケーション１２に送る（Ｓ２２３）。

次に、処理実行ノード５での処理の流れを図６のフローチャートを参照しながら説明する。受信制御部３１は、受信実行部３３でパケットを受信し（Ｓ３０１）、そのパケットが後着パケットであるか否かをログファイル３８を用いて判断し、後着パケットである場合（Ｓ３０２；Ｙｅｓ）、パケットを廃棄する（Ｓ３０３）。先着パケットである場合（Ｓ３０２；Ｎｏ）、そのパケットのヘッダからＩＰアドレスを外す（Ｓ３０４）。そして、パケットをシーケンス番号に従って繋ぎ合わせて、処理要求ノード４のアプリケーション１２が生成した通信データに復元する（Ｓ３０５）。受信制御部３１は、その通信データを入出力インターフェース２９に入力する（Ｓ３０６）。入出力インターフェース２９は、通信データからアプリケーション１２の処理要求を抽出し（Ｓ３０７）、その処理要求をアプリケーション１３に送る（Ｓ３０８）。アプリケーション１３は処理要求の内容に従って処理を実行する（Ｓ３０９）。処理が完了すると（Ｓ３１０）、アプリケーション１３は通信データを生成し（Ｓ３１１）、通信データのメモリ領域に処理結果を付与する（Ｓ３１２）。送信制御部３０は、通信データの属性を参照してパラメータを決定する（Ｓ３１３）。そのパラメータが２ルート通信を示すものである場合（Ｓ３１４；Ｙｅｓ）、通信データを複製する（Ｓ３１５）。各通信データをパケット化する（Ｓ３１６）。通信データ毎のパケットのヘッダにパケットの順序を示すシーケンス番号を付与する（Ｓ３１７）。アドレステーブルに基づいて一方の通信データの各パケットのヘッダに処理要求ノード４の代表ＩＰアドレスを付与し、他方の通信データの各パケットのヘッダに処理要求ノード４のサブＩＰアドレスを付与する（Ｓ３１８）。他方、パラメータが片ルート通信を示すものである場合（Ｓ３１４；Ｎｏ）、通信データをパケット化する（Ｓ３１９）。各パケットのヘッダにパケットの順序を示すシーケンス番号を付与する（Ｓ３２０）。各パケットのヘッダに処理要求ノード４の代表ＩＰアドレスを付与する（Ｓ３２１）。送信実行部１９は、各パケットのヘッダに付与された代表ＩＰアドレスあるいはサブＩＰアドレスに従ってデータ通信を行なう。具体的には、ヘッダに代表ＩＰアドレスが付与されたパケットは、伝送路２を経由して処理要求ノード４に送られ、ヘッダにサブＩＰアドレスが付与されたパケットは、伝送路３を経由して処理要求ノード４に送られる（Ｓ３２２）。

以上のように、本発明のパラメータ設定システム１によれば、複数種類のパラメータ設定ファイルのうち、最高順位のパラメータ設定ファイル属するパラメータが送信制御部１７、３０及び受信制御部１８、３１に対して設定されるので、送信制御部１７、３０及び受信制御部１８、３１によって行なわれるデータ通信の振る舞いを状況に応じて柔軟に制御することができる。つまり、テンプレート単位、アプリケーション単位、アプリケーション優先度単位、ノード単位、システム単位でのパラメータ設定が可能となるので、データ通信の振る舞いを精密に制御することができる。さらに詳しくは、各パラメータ設定ファイルの有無をテンプレート用パラメータ設定ファイル、アプリケーション用パラメータ設定ファイル、アプリケーション優先度用パラメータ設定ファイル、ノード用パラメータ設定ファイル、システム全体用パラメータ設定ファイルの順序で確認し、テンプレート用パラメータ設定ファイルが存在する場合には、テンプレート用パラメータ設定ファイルのパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定し、テンプレート用パラメータ設定ファイルが存在せずに、アプリケーション用パラメータ設定ファイルが存在する場合には、アプリケーション用パラメータ設定ファイルのパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定する。また、テンプレート用パラメータ設定ファイルとアプリケーション用パラメータ設定ファイルとが存在せず、アプリケーション優先度用パラメータ設定ファイルが存在する場合には、アプリケーション優先度用パラメータ設定ファイルのパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定する。更に、テンプレート用パラメータ設定ファイル、アプリケーション用パラメータ設定ファイル、及びアプリケーション優先度用パラメータ設定ファイルが存在せず、ノード用パラメータ設定ファイルが存在する場合には、ノード用パラメータ設定ファイルのパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定する。テンプレート用パラメータ設定ファイル、アプリケーション用パラメータ設定ファイル、アプリケーション優先度用パラメータ設定ファイル、及びノード用パラメータ設定ファイルが存在しない場合にはシステム全体用パラメータ設定ファイルのパラメータを送信制御部１７、３０及び受信制御部１８、３１に対して設定することができる。これにより、きめ細かいパラメータ設定を行なうことが可能となり、データ通信の高信頼化を図ることができる。

なお、上述の形態は本発明の好適な形態の一例ではあるがこれに限定されるものではなく本発明の要旨を逸脱しない範囲において種々変形実施可能である。例えば上記実施形態では、テンプレート用パラメータ設定ファイルには、２ルート通信を示すパラメータが記述されており、それ以外のパラメータ設定ファイルには、片ルート通信を示すパラメータが記述されている例を挙げて説明したが、これに限ることなく、「１」ディレクトリに属するテンプレート用パラメータ設定ファイルには、片ルート通信を示すパラメータが記述されており、「２」ディレクトリ及び「３」ディレクトリのそれぞれに属する各テンプレート用パラメータ設定ファイルには、２ルート通信を示すパラメータが記述されていても良い。この場合、例えば、「１」ディレクトリに属するテンプレート用パラメータ設定ファイルのパラメータが処理要求ノード４と第１の処理実行ノード（図示省略）との間で行なわれるデータ通信で用いられ、「２」ディレクトリに属するテンプレート用パラメータ設定ファイルのパラメータが処理要求ノード４と第２の処理実行ノード（図示省略）との間で行なわれるデータ通信で用いられ、「３」ディレクトリに属するテンプレート用パラメータ設定ファイルのパラメータが処理要求ノード４と第３の処理実行ノード図示省略）との間で行なわれるデータ通信で用いられるとすると、処理要求ノード４と第１の処理実行ノードとの間で行なわれるデータ通信は、片ルート通信で行なわれ、処理要求ノード４と第２の処理実行ノードとの間で行なわれるデータ通信、及び処理要求ノード４と第３の処理実行ノードとの間で行なわれるデータ通信は、２ルート通信で行なわれることになる。

以下に本発明のデータ伝送システムを電力送電系統での遠隔運用保守などに適用する例について説明する。

電力自由化の進展に伴い、様々な電力機器間やアプリケーション間、さらには電力会社間の連携（相互接続性）の重要性が増してくるものと考えられる。このような連携を実現するには、情報通信アーキテクチャ（プラットフォーム）の標準化（統一）が必要である。また、分散型電源のような多数の機器が系統に接続されると、集中的な制御に比べ、自律的な分散制御（参照；C. Rehtanz, Autonomous Systems and Intelligent Agents in Power System Control and Protection, Springer, 2003）が有効となる場合も考えられる。そこで、相互接続性を実現するため、電力機器の国際標準情報モデルや汎用インターネット技術を適用するとともに、自律分散型処理の可能なモバイルエージェント技術などを適用した情報通信アーキテクチャである、分散リアルタイムネットワークアーキテクチャ（DRNA：Distributed Real-time computer Network Architecture）の開発を進めている（参照；「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その1) −アーキテクチャの要件と機能概要−」，電力中央研究所研究報告R02013，2003年3月）。DRNAは，図７に示すような4つの要素からなる構造となっており，各構成要素は，それぞれ次のような機能を持つ。

１．応用プログラムおよび情報モデル層: 電力系統機器のオブジェクトモデル，及び監視制御に用いるアプリケーションプログラム。
２．高度通信機能層: 一般の上位プロトコルにおいて、状況の変化に対応して自律的に動作し，様々な通信形態の基盤を提供する．高度通信機能は、通信機能を主として担う「高度通信機能ミドルウェア」と、エージェントによる情報処理を担う「エージェントプラットフォーム」から構成される。本実施例では、高度通信機能ミドルウェアについて述べる。
３．伝達通信機能層: 一般の下位プロコルにおいて、IP (Internet Protocol) 技術に基づいて基本的な通信と通信品質 (QoS: Quality of Service) の制御を行う。
４．通信管理・セキュリティ機能: DRNAの各要素が正常に動作するための支援を行う。

現在の電力通信網では，系統監視や給電運用などの設備運用・保全システムのアプリケーション毎に通信網が構成されているが，効率的な通信網の活用やコスト低減の観点から，将来は各種の監視制御システム（すなわちアプリケーション）のデータ伝送を統合する，すなわち統合IP網を構築することが望ましい（参照；「電力自由化時代における電力通信網の将来展望」電力中央研究所研究報告R02003, 2002年12月）（参照；「電力自由化が及ぼす電力通信網への影響と課題」電力中央研究所調査報告R02002, 2003年1月）。この際，IP網を利用する場合には通信品質の確保のためにQoS制御が必要となる。DRNAではIPレベルのQoS制御は伝達通信機能で行うが，一度設定したものをアプリケーションや通信網の状況に応じて頻繁に変更することは難しい。高度通信機能ミドルウェアはこれを補完し，状況に適応するQoS保証機能が動作する。

高度通信機能ミドルウェアでは，上位のアプリケーションの要求に応じて適切な機能要素を組み合わせて提供する。このため，アプリケーションは基本的なパラメータのみを設定するだけでよく，QoS保証のためにどのような機能を使用するかについては設定する必要がない。これまで、送受信端末においてモバイルエージェントとオブジェクト間通信について自律的な優先制御を用いたリアルタイム通信を実現した（参照；分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その7)−高度通信機能の詳細設計と実装−、電力中央研究所報告研究報告R03007、2004年3月）。しかし、統合IP網（参照；分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その5)−伝達通信機能におけるIPルータ/MPLS/広域Ethernetの適用の考え方−、電力中央研究所報告研究報告R02010、2003年3月）では複数のアプリケーションが混在することから、
a) 同一優先度のアプリケーション間の干渉
b) 少数のアプリケーションによる通信資源の占有
c) 通信網上の負荷への対策
が課題であった。また、下記の電力系統の設備運用・保全システム特有の要求への対応が課題であった。
d) 高信頼化への対応
そのために、高度通信機能ミドルウェアへ下記の機能を追加した（図８参照）。なお、図８の通信方式としてはＴＣＰ／ＩＰを採用しているが、ＵＤＰ／ＩＰでも実行可能である。
・QoS保証機能（追加分）：上記の項目aとbへの対応
・伝達通信機能との連携：上記の項目cへの対応
・高信頼化機能：上記の項目dへの対応

次に、統合IP網に求められるQoS保証、リアルタイム通信、高度通信機能ミドルウェアの概要、関連研究と課題について述べる。

統合IP網は、以下の特徴を有する。
・多数のアプリケーション混在：アプリケーションが混在することにより、様々な情報フローが発生し、各アプリケーションの通信を制御する重要性が増す。
・大規模：基幹系網、支店系網、地域系の網が相互接続され、さらに様々な端末（サーバやPCなど）が接続され、統一的な端末を含めた網の管理の重要性が増す。
・異種技術混在網：IPルータ網、MPLS網、Ethernet網が混在し、統一的なQoS制御が求められる。

網の統合化が進み複雑になるほど、様々な負荷や障害が想定されるため、アプリケーションが要求する品質（QoS：通信サービス品質）や高信頼化の要求は多様化する。
QoSについては、これまで通信装置のみにおいてQoSの制御（QoS制御）を行うことで、アプリケーションに対してQoSを保証（QoS保証）している。例えば、DiffServ (Differentiate Services) （参照；K.Nichols, S.Blake, F.Baker and D.Black:”Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC2474, 1998 ）（参照；「DiffServの遅延特性と電力通信網への適用」、電中研研究報告R00026、2001年4月）によるQoS保証である。QoSとして、以下の項目を挙げることが出来る。
・遅延
・遅延ゆらぎ（ジッタ）
・帯域
・ロス率
このようにアプリケーションが要求するQoSは多様である。アプリケーションが通信を行うためには、サーバなどの端末とIP網が必要である。
QoS制御は、優先すべき通信に対して優先度や回線帯域、バッファなどの資源を割り当てる。資源割り当てのタイミングに着目すると、QoS制御方式は以下の２つに分類できる。
・プロビジョニング方式：事前にトラヒックの状況を想定して、事前に割り当てる方式である。
・シグナリング方式：アプリケーションからの個別要求毎に資源を割り当てる方式である。

ネットワークプロトコル層における主要なQoS制御方式として、以下の3方式がある。
・ ST2 (Internet Stream Protocol Version 2)（参照；L. Delgrossi and L. Berger(Editors):” Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+”, RFC1819, 1995 August）:シグナリング方式で行うEnd-to-Endで実時間品質保証を行うためのプロトコルである。
・ IntServ(Integrated Service)（参照； R. Braden, D. Clark and S. Shenker : “Integrated Services in the Internet Architecture: an Overview “, RFC1633, June 1994）：シグナリング方式であり、IPプロトコルのフローについてQoS制御できる点で優れている。
・ DiffServ:シグナリング方式でもプロビジョニング方式の何れでも実現できる方式である。上記2つの方式に比べて、フロー集合単位で制御する点が異なる。

ST2とIntServは、通信経路上の全ての通信装置の対応が必要となるために、広く普及していない。DiffServは、他２つの方式に比べフロー集合で制御を行うという点で劣っているが、実現が容易である。現在、通信網側ではプロビジョニング方式で、IPレベルの優先度であるDSCP値を基にQoS制御行う方式が主流である。DiffServでは、エッジノードでDSCPを指定する。これを発展させ、端末のアプリケーション層でDSCP値の指定し、シグナリング方式の代わる、状況に応じた自律的QoS保証を行えば、パケット単位で高品質な通信を実現することが期待できる。

端末における高信頼化については、アプリケーションから要求としては、以下の項目を挙げることができる。
・ 2ルート伝送
・連続送信
・再送信
・送達確認
これらを満足する機能は、QoS保証のための機能と併用できる必要がある。

自律的なQoS保証を実現する際には、優先制御が最も重要である。高度通信機能ミドルウェアの開発では、独自の優先制御を開発し、その有効性を確認している。しかし、占有帯域が多すぎれば、優先制御に影響が生じる。これは、DiffServでも同様のことが発生する。DiffServでは、これを補うために、Bandwidth Brokerと呼ばれるサブシステムを導入する研究が行われている。これは、シグナリング方式に該当するため、自律性を損なわないためには、これに代わる端末でのプロビジョニング方式の機能が必要となる。その機能はシェーピングやポリシングであり、IP網で適用可能な方式としてはUDP、TCPといったネットワーク層の研究があるが、アプリケーション層での研究は途上である。資源割当については、グリッド分野でのSUN Gridやglobusの研究をあげることができることが出来るが、通信技術よりも情報処理技術が中心である。
この他に、OS (Operating System) 面からの研究開発も進められており、シェーピング／ポリシング機能についてはネットワーク層に関するものがある（参照；Raj Rajkumar, Kanaka Juvva, Anastasio Molano and Shui Oikawa , Resource Kernels: A Resource-Centric Approach to Real-Time Systems, In Proceedings of the SPIE/ACM Conference on Multimedia Computing and Networking,1998.January）（参照；Takashi Okumura, Daniel Mosse, Virtualizing Network I/O on End-Host Operating System: Operating System Support for Network Control and Resource Protection , Trans. on Computer, IEEE, Vol. 53, No. 10, pp. 1303-1316 ,2004.October）。OSの変更や拡張を必要とする。
ネットワーク層での制御機能を実現する際には、OSに依存することが多いため、監視制御システムに要求されているマルチベンダによるシステム構築を行うには、アプリケーション層で実現する方式が望ましい。

電力系統の設備運用・保全の通信においては、QoSだけではなく、高い信頼性が要求される。電力以外の分野では、電力分野で要求される高信頼化技術への取り組みは少ない。電力分野においては、中央電力協議会で開発されたRNA (Real-time computer Network Architecture)がある。RNAは2ルート送信、送達確認、再送、後着廃棄の機能を提供する。しかし、QoS保証に関わる優先制御の機能は提供されていない。また、エージェント通信には対応していない。詳細については後述する。

End-to-Endの通信で、QoS保証と高信頼化の要求を満足するためには、端末に搭載する通信ミドルウェアを開発し、端末側に以下の機能を具備する必要がある。
・優先制御（送信／受信）
・シェーピング／ポリシング
・集約／展開
・高信頼化

これらを実現する際、通信ミドルウェアは、伝達通信網を構成する通信装置のQoS制御機能との連携が必要となる。そのためには、通信ドルウェアには、以下の機能が必要となる。
・伝達通信機能との連携機能
優先制御は、通信の混雑への対応するためのものであり、狭義のQoS保証機能といえる。シェーピングやポリシング、集約は、送受信に関わる情報量の通信タイミングを制御し、同一優先度のアプリケーション間の干渉、少数のアプリケーションによる通信処理能力の占有などを防止するためのものである。高信頼化は、2ルート伝送や再送など通信路途絶やパケット損失に対応するためのものである。伝達通信との連携は、通信装置のQoS制御と協調するための重要な機能である。

電力系統の監視制御システムでは、確実な監視制御を実現するために、通信遅延の保証が重要である。ここで、本実施例では、遅延が保証される通信を「リアルタイム通信」と呼ぶこととする。
DRNAでは、自律分散型処理の可能なモバイルエージェント技術やその基礎技術となる分散オブジェクト技術を適用でき、これらの技術の活用による、監視制御業務の高度化・効率化が期待できる。分散オブジェクト技術は、RPCが発展したものである。分散オブジェクト技術を用いることで、アプリケーションが自端末内で授受する情報形式で、他の端末との情報授受においても同様の形式での通信が行うことが可能となり、分散処理を行うアプリケーションの開発効率を図ることができる。分散処理を行うアプリケーションで適用される主要な方式としては、CORBA (Common Object Request Broker Architecture)（参照；http://www.omg.org）やJava RMI (Remote Method Invocation) （http://www.sun.com ）を挙げることができる。CORBAやJava RMIはアプリケーション層のプロトコルを用いて実現されている。しかし、これらでは、リアルタイム通信を実現することは考慮していない。DRNAの開発では、リアルタイム通信の実現を目指した、アプリケーション層に位置する高度通信機能ミドルウェアの検討を行っている。

高度通信機能ミドルウェアは、従来の監視情報の伝送方式であったストリーミングだけではなく、非定型データなど高度な情報を伝送可能なオブジェクト間通信やエージェント通信が可能である。エージェント通信は、データだけでなく、プログラム自身を各監視制御装置へ移動させながら処理を行う、すなわち自律的に処理を行うプログラムを実現する。これにより、アプリケーションは、エージェント通信を活用することで、自律的な分散制御を容易に実現できる。また、高度通信機能ミドルウェアは、下位プロトコルとしてTCP、Java RMI、UDPを用いることができる。これまでにプロトタイプ実装した高度通信機能ミドルウェアでは、下記に示す2種類の通信方式、自律的QoS保証機能として「3種類の優先制御と情報共有」を実装している。

・通信方式：エージェント通信、オブジェクト間通信。
・自律的QoS保証機能：優先制御（静的優先処理、動的優先処理、プロセス起動順制御）、情報共有。

優先制御を利用した際のオブジェクト間通信の処理手順は以下の通りである。ただし、QoS保証要求は、処理期限と受信側での期待処理時間を含む。

1) アプリケーションがデータ送信を行う際に高度通信機能ミドルウェアに渡す情報は、アプリケーションの名称、QoS保証要求および実際に送信するデータのみでよい。
2) 高度通信機能ミドルウェアは、QoS保証要求に応じて必要な機能を自動的に設定する。送信時と受信時には、優先度が高いものや終了期限までの時間が短いものを優先して処理する（静的優先処理、動的優先処理）。
3) データ受信時には高度通信機能ミドルウェアがアプリケーションを呼び出し、データを受け渡す（プロセス起動順序制御）。

この結果、低優先の通信は処理数が多くなると処理時間が大きくなるが、処理期限が保証される高優先の通信はほぼ一定の時間で処理を完了でき、通信のリアルタイム性を確保できる。
優先制御は、エージェント通信、オブジェクト間通信、ストリーミング通信に対応する。QoS保証要求を基に、送信・受信処理を制御することで、通信のリアルタイム性を保証する。

図９にエージェント通信を例とした送信用優先制御の概要を示す。送信用優先制御には、静的優先処理と動的優先処理がある。例えば、急行型処理と確実型処理のためのエージェントには静的優先処理を適用し、ベストエフォート（BE）型処理のエージェントには動的優先処理を用いる方法がある。確実型処理は処理期限があるリアルタイム性を有した処理を、急行型処理は、確実型処理の中で、常に最優先の処理を要求するものである。
静的優先処理は、優先順位調節器と送信サブコンポーネントから構成される。同時に複数のデータが渡された場合、優先順位調節器が処理期限を参照して、送信サブコンポーネントに渡すデータの順序を調整する。次に、送信サブコンポーネントがデータの送信を実行する。

動的優先処理は、優先度弁別器と送信サブコンポーネントから構成される。優先度毎に送信サブコンポーネントを設置している。送信サブコンポーネント自体はスケジューリングを行わない。また、動的優先処理は、各サブコンポーネントを並行動作させ、サブコンポーネントに滞在しているデータの処理期限に対する余裕を見て、サブコンポーネントの動作時間割当を調整する。この調整は、余裕がないサブコンポーネントの動作時間割当を長くする、あるいは、その逆を行うことで実施する。静的優先処理と動的優先処理は、文献「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その7)−高度通信機能の詳細設計と実装−、電力中央研究所報告研究報告R03007、2004年3月」と文献「分散制御用モバイルエージェントの優先処理方式、電力中央研究所研究報告、R01010、2002年4月」の方式を、高度通信機能ミドルウェアの対応させるために、優先度の取り扱いなどを拡張している。

図１０にエージェント通信を例に、受信用優先制御機能であるプロセス起動順序制御の概要を示す。プロセス起動順序制御は、エージェント通信、オブジェクト間通信、ストリーミング通信に対応する。プロセス起動順序制御へデータが渡されると、プロセス起動順序制御は、QoS保証パラメータの優先度、処理期限、受信側での期待処理時間を用いて、各データの処理期限の余裕と優先度のバランスを考慮した効率的なスケジューリングを行う。ただし、急行型処理のエージェントについては、常に最優先で起動する。また、プロセス起動順序制御は、エージェントの起動を逐次的に行う。なお、プロセス起動順序制御の詳細は、文献「分散処理のリアルタイム性を保証するための動的スケジューリング機能の提案、電力中央研究所報告研究報告R01021、2002年4月」の方式をベースに、単一エージェントによる端末のCPU占有を防止するための拡張を行っている。

高度通信機能ミドルウェアの研究では、全体構成（参照；「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その2) −高度通信機能の構成と外部インタフェース仕様の設計−」，電力中央研究所研究報告R02005，2003年3月）、リアルタイム通信を実現するための優先制御（参照；「電力用IP通信網における適応的プロトコル層に関する検討」，電力中央研究所研究報告R99006，2000年4月）（参照；「分散処理のリアルタイム性を保証するための動的スケジューリング機能の提案」、電力中央研究所報告研究報告R01021、2002年4月）や情報共有（参照；「分散リアルタイムネットワークアーキテクチャ (DRNA) の開発 (その3) −高度通信機能における情報共有方式とキャッシュの適用検討−」，電力中央研究所研究報告R02009，2003年3月）の検討を行い、実装を進めてきた（参照；分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その7)−高度通信機能の詳細設計と実装−、電力中央研究所報告研究報告R03007、2004年3月）。これまでの検討は、1:1の端末間で、優先度が異なるアプリケーションそれぞれが通信する場合を対象としており、統合IP網での複数のアプリケーションが混在した状況で、それぞれの通信を保証することが困難であった。
上述したように、高度通信機能ミドルウェアに、シェーピングなどの機能、高信頼化機能、通信装置との連携する機能、を追加することで、End-to-EndでのQoS保証が可能となる。そのためには、これまでの議論より、QoS保証機能や高信頼化には、以下の特徴を有する必要がある。
・シェーピングなどの機能は、優先制御と同様に自律的な制御を行う。
・高信頼化は、RNAで提供している機能を有し、エージェント通信に対応する。
通信装置との連携を実現するためには、以下の処理が要求される。
・通信装置との連携は、ToS値やポート番号を指定できる。ToS値は、上位3ビットにDSCP (DiffServ Code Point)を収容する。

高度通信機能ミドルウェアに、シェーピングなどの機能と高信頼化機能、伝達通信機能との連携機能を追加した。追加機能は、図１１（図中の太枠が追加機能を示す）に示すようにアプリケーション層に位置するものであり、データの処理期限や優先度に応じた通信制御を行う。この結果、アプリケーション層には、以下の機能が配置されることになる。なお、品質・高信頼化に関わる機能以外にも、遠隔処理呼出機能を追加している。遠隔処理呼出機能は、エージェントプラットフォームと接続に利用できる。
・通信方式（エージェント通信、オブジェクト間通信、ストリーミング通信）
・ QoS保証機能
・高信頼化機能
・伝達通信機能との連携機能
・遠隔処理呼出機能（高度通信RPC）
アプリケーションが通信する際には、アプリケーション層にデータと共に処理期限などを与え、各機能が下記の処理を行うことで、End-to-EndのQoS・高信頼化要求が保証された通信を実現する。
・監視情報の伝送などリアルタイム処理に適した優先制御や、シェーピング、集約を行う。
・ 2ルート伝送や片ルート伝送の選択など電力特有の高信頼化伝送を行う。
・通信装置のQoS制御機能と連携するためのQoS制御パラメータの指定を行う。
・アプリケーション層から渡されたストリーミング、オブジェクト、エージェントを伝送する。プロトタイプでは、下位プロトコルとして、TCP、UDP、Java RMIを利用することができるものとした。

統合IP網を構成する通信装置と端末上の高度通信機能ミドルウェアが連携するためには、以下の項目の実現が必要である。
・異種技術網の混在への対応：MPLSやEthernetなどの技術に依存せずに、QoS制御できる。
・通信装置の改造が不要：連携機能を端末機能で実現することができる。
・統一的な連携制御：各端末の制御情報を共通化し、通信装置が個別の端末への対応を不要できる。

本連携機能では、各装置が参照できるIPヘッダに着目し、IPヘッダのToS値を利用する。送信端末でToS値を指定することにより、通信装置の改造が不要で、かつアプリケーションの追加の度に通信装置の設定することが不要となる。詳細なQoS制御を可能とするために、ToS値の他に、連携機能はトランスポート層のポート番号を指定する。これにより、例えば、セキュリティ機能であるSSHとの連携が可能である。

図１２に連携機能を用いた通信処理の概要を示す。連携機能は、優先度とポート番号・ToS値との変換テーブルを保持する。送信側では、変換テープルを基にToSとポート番号を指定した送信処理を行う。受信側では、変換テーブルに記載されたポート番号からの受信を可能とする。

図１３に連携機能の有無について、広域Ethernet網とMPLS網が統合されたIP網を介して、変電所サーバと制御所サーバが通信を行う際の、通信装置のQoS制御パラメータの設定処理の概要を示す。
同図 (a)は連携機能が無い場合であり、それぞれの網の初段の通信装置は、IPアドレスを元に、QoS制御パラメータEthernetのVLAN-tagやMPLSのラベルに優先度を設定する。最終段の装置は、VLAN-tagやMPLSのラベルを除去する。通信装置は、IPアドレス単位でしか制御できず、かつその設定が必要となる。
同図(b)は連携機能がある場合であり、送信端末から指定することで、各網では、このToS値に基づいて、通信装置がEthernetのVLAN-tagやMPLSラベルを設定することができ、送信端末から指定されたQoSをアプリケーションに対して提供できる。この場合、各通信装置はToS値毎にQoS制御の設定をするだけで済み、端末やアプリケーションの追加毎の設定追加・変更は不要となる。

QoS保証機能(追加分)は、アプリケーション層において通信タイミングを制御することで、同一優先度のアプリケーションの干渉や、通信資源の占有防止を図る。

シェーピングは、データの送信に対して制約を設けることで、送信先へのパケットのバースト到着を抑制する。高度通信機能ミドルウェアレベルのウィンドウ制御を実現することが出来る。
シェーピングでは、処理期限を用いて、独自のマーキング方式を行い、この結果に基づき整形と廃棄を行っている。データの処理期限と制御パラメータの許容超過時間を用いて、廃棄することが出来る。
シェーピングは、アプリケーション、送信先（ノード名＋アプリケーション名）、送信元アプリケーションの優先度（特定の優先度）の単位で制御可能である。

ポリシングは、受信時に単位時間当たりのデータの受信数を制限することにより、アプリケーションの過負荷を予防する。また、プロセス起動順序制御と組み合わせることにより、プロセス起動順序制御によるリアルタイム保証率を向上させることが出来る。
受信アプリケーション、送信元（ノード名＋アプリケーション名）、送信元アプリケーションの優先度（特定の優先度）の単位で制御可能である。

データが多く、その伝送処理のオーバヘッドが大きい際に、このオーバヘッドを削減するため、集約機能はデータを集約し、伝送する。
制御方法として、以下の条件を満たすとき、集約したデータを送信する。集約上限数および単位時間は制御単位毎に設定する。
・集約上限数に達したとき
・単位時間を経過したとき
送信アプリケーション、送信先ノード名（代表ＩＰアドレス）、優先度単位で制御可能とす。各レベルでの優先度を制御単位とする。

展開機能は受信側に配置され、送信側で集約機能により集約したデータを受信した際に、展開して、本来のデータに復元する。制御パラメータは必要とせず、受信した順に、逐次展開する。

送達確認機能は、送信データが順序と連続性を保ちながら受信端末に渡ったことを確認する。受信側はデータ受信時に送達確認を送り返す。送達確認が一定時間だけ送信側端末に戻ってこない場合、再度送信を行う。
各パケットには識別のために送達確認用のシーケンス番号を付与する。

再送機能は、送信データが受信端末に渡ったことが確認できなかった場合に、同一データを再度送信する。送信端末側から送達確認を要求することは行わない。各パケットには識別のために再送用シーケンス番号を付与する。
再送要求を行うまでの受信側端末の待ち時間、及び再送要求回数を指定できる。

連続送信機能は、2つの端末間で、1経路に対して同一データを複製して連続して送信する。各パケットには識別のために多重化データシーケンス番号を付与する。
複製するデータの個数、データ送信間隔を指定できる。

2ルート送信機能は、2つの端末間で、通信経路が物理的に2経路ある場合に、以下のいずれかのデータ送信方法が選択できるものとする。
・受信側端末とのコネクションを2経路確立し、両方の経路に対して同一データを同一タイミングで送信する。各パケットには識別のために多重化データシーケンス番号を付与する。
・受信側端末とのコネクションは1経路のみ確立し、その経路にデータを送信する。コネクションが切断された場合は、もう一方の経路を選択する。
・受信側端末とのコネクションは1経路のみ確立し、その経路にデータを送信する。
2ルートのデータ送信方法についての概念図を図１４に示した。なお、図中の「ＡＰ」とは、「Application」の略語であり、「ＮＩＣ」は「Network Interface Card」の略語である。

後着廃棄機能は、送信側端末において、データに多重化データシーケンス番号を付与してあれば、受信側端末において、受信した複数の同一データのうち、先に受信したデータをアプリケーションに渡し、後着のデータを廃棄する。各パケットの識別には多重化データシーケンス番号と、送受信それぞれのアプリケーション名を使用する。

受信側端末が同一データを複数個受信するケースは以下の場合である。
・ 2ルート送信機能を用いて2経路にデータ送信された場合
・連続送信機能を用いて複数データが送信された場合

追加機能を既開発の高度通信機能ミドルウェアのプロトタイプ（参照；分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その7)−高度通信機能の詳細設計と実装−、電力中央研究所報告研究報告R03007、2004年3月）に実装し、評価した結果を以下に示す。

図１５に評価システムの構成を示す。変電所構内監視制御サーバ(変電所サーバ)と制御所監視制御サーバ(以下、制御所サーバ)、負荷発生源とする設備保全サーバそれぞれを模擬するPC3台を、IP網を介して接続した。PC3台の仕様は同一で、その仕様は以下の通り。
・ CPU；Pentium（登録商標）4 2.8GHz
・メモリ；1GB
・ネットワークインタフェースカード；10/100/1000BASE-TX×２枚（IP網へは100BASE-TXで接続した。）

IP網の構成は、CISCO社製Ethernetスイッチ2950 2台を用いて、2系列網とした。物理的に、制御所サーバと変電所サーバは両系に、設備保全サーバは片系（プライマリ）に接続する。
各種サーバには、高度通信機能ミドルウェアを搭載する。なお、本プロトタイプは、当所開発のソフトウェアである。Java言語を用いて開発した。また、OSには、Linuxを用いた。各ソフトウェアの詳細は以下の通りである。
・ Java: SUN Java Standard Edition 1.4.2（登録商標）
・ OS: Novel SuSE Linux 9.1(カーネルのバージョンは2.6)（登録商標）

評価システムでは、以下の3種類のアプリケーションによる通信を模擬する。

・監視制御アプリケーション（A）
・保全（業務支援アプリケーション）（B）
・保全（ITVアプリケーション）（C）

アプリケーションには、表１に示す遅延、帯域、可用性についてのQoS要求があると想定した。これに基づき、表２と表３にプロパティとプロファイルを決定した結果を示す。遅延要求、帯域割当、高信頼化の要求に基づき、優遇の違いが出るようにパラメータを決定した。この設定の基で、通信時に、各アプリケーションが要求する処理期限を指定することで、リアルタイム通信が実行できる。表１はアプリケーションの要求を示し、表２はプロファイルとプロパティの設定結果を示し、表３は通信装置との連携のためのプロファイルを示す。

性能評価では、上記で示した3種類アプリケーションが変電所から制御所への監視情報の周期伝送処理を行わせた。伝送する情報量は、IEC61850の情報モデルに含まれる遮断器オブジェクトの定義を参考にし、これを128量分のデータとした。高度通信機能ミドルウェアプロトタイプでは、データベース上にIEC61850の情報モデルを一部実装している。この実装における、遮断器オブジェクトが保持するデータを表４に示す。このデータサイズの合計は145バイトであり、これに128量を乗算すると、145×128＝18560バイト≒20,000バイトとなることから、20,000バイトを伝送するデータ量とした。なお、表４は、想定する遮断器オブジェクトの構成を示す。

提案方式の処理オーバヘッドを測定する実験を行った。表５は、通信基本特性（処理オーバーヘッド）を示す。表５(a)に示す優先制御、シェーピング、ポリシング、高信頼化機能を用いた場合、優先制御機能のみを用いた場合、何れの機能も用いない場合の3種類の設定をしたアプリケーションを用いて、送信開始から受信終了までの処理時間を測定した。通信方式として、TCPを用いたオブジェクト間通信を利用した。その結果、表５(b)を得た。オブジェクト間通信に対してQoS保証機能と高信頼化の適用有無（アプリケーションAとアプリケーションB）の場合の処理時間の比は、8.1:12.2[ms]≒2:3である。この差は、QoS保証および高信頼化機能に要する処理時間であり、オブジェクト間通信自体の処理時間に比べて、小さいといえる。よって、QoS保証および高信頼化機能は、１秒程度の遅延保証を要求する通信への適用可能であることを確認した。

高度通信機能ミドルウェアによるQoS保証の効果について評価した結果について述べる。表 6(a)に示す変電所から制御所に方向に2種類のアプリケーションA、Bのそれぞれが通信している際に、アプリケーションCが通信網の片系（プライマリ）に負荷を発生させた。アプリケーションAとBの違いを明確とするために、通信方式として、TCPを用いたオブジェクト間通信を利用した。その結果、表 6（Ｑｏｓ保証・高信頼化の評価を示す）を得た。通信網の負荷となるアプリケーションC自体は、他の2種類が通信中は100Mbps以上のデータの送信を継続した結果、処理時間が増加し、処理期限を超過する。アプリケーションCの影響により、同一優先度のアプリケーションBの遅延は増加するが、優先度の高いAへの影響は小さい。また、アプリケーションBは、平常時に比べて遅延が増加するが、処理期限を超過することは無かった。
通信装置との連携については、表３に示すようにプロファイルの指定どおりに、アプリケーションの優先度に応じて、連携機能が制御所サーバのポート番号とDSCP (DiffServ Code Point：ToS値の上位3ビット)値を指定して、通信していることを確認した。
アプリケーションAは、高度通信機能ミドルウェアの2ルート伝送機能と後着廃棄を適用しており、可用性の向上を図っている。片系の伝送路に障害を発せさせても、アプリケーションAは通信を継続でき、可用性の要求を満足できることを確認した。
以上の結果から、QoS保証および高信頼化機能の有効性を確認した。

高度通信機能ミドルウェアとRNA (Real-time computer Network Architecture)との比較結果を表７に示す。高度通信機能ミドルウェアは、RNAで提供している高信頼化機能だけではなく、IP網特有の通信遅延対策に必要な優先制御、さらに通信装置との連携、エージェント通信・オブジェクト間通信へ対応しているなどの点で優れている。RNAは監視制御アプリケーションへ実導入されている。これに対し、高度通信機能ミドルウェアのプロトタイプは、高度通信機能ミドルウェアの検証を目的として開発したものであり、実用化に当たっては、フィールド検証や実導入に向けての改良を行いつつ、保全アプリケーションなどから適用していくものと思われる。

次に、様々なアプリケーションのQoSや高信頼化要求に応じた高度通信機能ミドルウェアの利用法を示す。これにより、高度通信機能ミドルウェアが提供する様々な機能を効率的に利用することが可能となる。

アプリケーションが要求するQoS保証と高信頼化の種別に応じて、適用すべき機能が異なる。要求の種別と適用すべき機能は以下の通りである。
・遅延：優先制御
・遅延揺らぎ：優先制御とシェーピング、ポリシング
・帯域：シェーピング、ポリシング、集約・展開
・ロス率：シェーピング、ポリシング、集約・展開、2ルート伝送、連続送信、再送信
・高信頼化：2ルート伝送、連続送信、再送信、送達確認
伝送路のQoSが要求される際は、通信装置との連携機能を利用する。
高度通信機能ミドルウェアに与えるパラメータは、プロファイルとプロパティ、通信パラメータである。プロファイルとプロパティは、事前に決定しておく必要がある。ただし、アプリケーション利用者ではなく、ネットワーク管理・セキュリティ機能を通じて、システム全体の運用管理者が設定する必要がある。QoS保証パラメータは、アプリケーションが、通信要求時に指定する必要がある。
・プロファイル：アプリケーションに割り当てる優先度とアプリケーションが利用すべき機能を指定する。
・プロパティ：機能毎の振る舞いを指定する。
・ QoS保証パラメータ：通信処理期限、受信側で処理時間

各機能は、通信網と端末の混雑度・品質に応じて、柔軟に組み合わせることが出来る。組み合わせは、プロファイルを用いて指定する。図１６に想定する各種機能の使用順序を示す。ただし、同じ機能は2度利用することは出来ない。状況に応じて利用しない機能もある。表８にプロパティの一覧を示す。高度通信機能ミドルウェアはプロパティを、下記のプロパティ指定の優先度に基づきパラメータとして採用する。図１７に示すように、優先度が大きいほど、高優先である。
・テンプレート用プロパティ：優先度5
・アプリケーション用プロパティ：優先度4
・アプリケーション優先度用プロパティ：優先度3
・ノード用プロパティ：優先度2

シェーピング、ポリシング、集約・展開機能では、上記の優先度3や2の場合、アプリケーション優先度単位やノード単位というように複数のアプリケーションをグループ化して制御でき、全てのアプリケーションに対して、容易にこれら機能を適用することが出来る。
高信頼化機能では、再送間隔や再送回数をアプリケーション毎に設定が可能であり、ノード単位で制御するTCPに比べ、詳細な設定が可能である。

アプリケーションが要求するQoSを保証するために、下記の手順が必要となる（図１８参照）。

1. アプリケーションの優先度を設定する。
2. 伝送路のQoS要求がある場合は、通信装置によるQoS制御の設定と比較する。設定の追加が必要となる場合、高度通信機能ミドルウェアの優先度およびToS値やポート番号の割当を追加する。なお、通信装置の設定については、文献「分散リアルタイムネットワークアーキテクチャ(DRNA)の開発 (その5)−伝達通信機能におけるIPルータ/MPLS/広域Ethernetの適用の考え方−、電力中央研究所報告研究報告R02010、2003年3月」に記載されている。
3. 必要な機能を選択し、動作時に通信のボトルネックが発生しないよう順序を決定し、プロファイルで指定する。
4. 各種機能の振る舞いを指定するプロパティを指定する。
5. 通信時に、アプリケーションはQoS保証パラメータとなる遅延を、高度通信機能ミドルウェアに指定する。

各機能の詳細な手順は、以下の通りである。
(1)遅延
優先制御を用いて、自アプリケーションより優先度の低いものの影響を防止する。プロファイルには、アプリケーションに割り当てる優先度と優先制御機能の利用を指定する。アプリケーションの優先度は、アプリケーションの種別に応じて設定する。アプリケーション全てに対して優先制御機能を適用する。これと並行して、QoS保証パラメータには、アプリケーションは処理期限を指定する。
(2)ジッタ
シェーピングとポリシングを用いて、送信タイミングと受信タイミングを周期化し、アプリケーション単位でのゆらぎを抑制する。
優先度が低いアプリケーションの影響を抑制する場合、その低優先度グループ単位のシェーピング、ポリシング、優先制御を利用して対応することができる。
(3)帯域
シェーピング、ポリシング、集約・展開を用いて、単位時間当たりに授受するデータ数を帯域の単位として制御する。アプリケーションが要求する帯域に基づいて、プロパティを設定する。
(4)ロス率
再送を許容できる程度に処理期限の余裕がある場合は、再送機能を利用する。この他に、通信方式の下位プロトコルとして、TCPやJava RMIを用いることも可能であるが、再送回数を端末単位でのみの指定となる。
(5)高信頼化
高信頼化要求に応じて、高信頼化機能の適用の有無、および利用する機能を指定する。さらに、IP網の構成に応じて、伝送路の構成(2ルート（1+1）、2ルート（1:1）、1ルート構成)を選択する。
2ルート(1:1)については、伝達通信機能が提供する経路切替機能でも実現が可能である。
(6)伝送路のQoS
プロファイルにおいて、要求品質に応じて、アプリケーション優先度毎に通信品質クラスを指定する。通信品質クラスとして、送受信ポート番号とToS値を指定する。これにより、通信装置では、これらの値を基に、あらかじめ通信装置に設定された内容に従い、優先制御やシェーピング、ポリシング、経路切替を行う。

以上のように、本実施例では、アプリケーション層においてQoSおよび高信頼化要求を保証する高度通信機能ミドルウェアとその利用法について示した。高度通信機能ミドルウェアは、QoS保証、高信頼化、伝達通信機能との連携を主な機能要素としている。これらにより、メッセージ通信、エージェント通信、ストリーミング通信に対して、送信端末、通信網、受信端末が協調してQoS保証および高信頼化を行うことが可能となり、統合IP網において、End-to-End通信のQoS保証および高信頼化要求を満足することができる。

本発明のパラメータ設定システムの要部を示す機能ブロック図である。パラメータ保持用ディレクトリの構造を示す図である。パラメータ管理部での処理の流れを示すフローチャートである。通信制御部での処理の流れを示すフローチャートである。処理要求ノードでの処理の流れを示すフローチャートである。処理実行ノードでの処理の流れを示すフローチャートである。ＤＲＮＡに基づく電力系統監視制御システムの機能ブロック図である。高度通信機能の構成を示す図である。送信側のＱｏｓ保証のための優先処理の流れを示す図である。受信側のＱｏｓ保証のための優先処理の流れを示す図である。高度通信機能ミドルウェアの構成を示す図である。伝達通信機能との連携機能の概要を示す図である。伝達通信機能の振る舞いを示す図であり、（ａ）は連携機能が無い場合の伝達通信機能の振る舞いを示す図あり、（ｂ）は連携機能がある場合の伝達通信機能の振る舞いを示す図である。２ルート送信の概念図である。評価に用いた模擬システムの構成を示す図である。各種機能の使用順序を示す図である。プロパティの階層関係を示す図である。制御パラメータの設定手順を示すフローチャートである。

符号の説明

１パラメータ設定システム
２、３伝送路
４処理要求ノード
５処理実行ノード
６、８ＣＰＵ
７ハードディスク
１２、１３アプリケーション
１６、３４パラメータ管理部
１７、３０送信制御部
１７ａ順位テーブル
１８、３１受信制御部
１９、３２送信実行部
２０、３３受信実行部
１４ファイルシステム
２２パラメータ保持用ディレクトリ
２６メモリ
２７、３９アドレステーブル

Claims

ネットワークを介して接続されている複数のノード間でのデータ通信の振る舞いを制御する通信制御手段を各ノードに備え、前記振る舞いを指定するパラメータを前記通信制御手段に対して設定するパラメータ設定システムにおいて、前記各ノードに、複数の単位のそれぞれに対応した前記パラメータが記述されていると共に順位が予め付与されているパラメータ設定ファイルを記憶する記憶手段と、前記パラメータの取得要求を示すパラメータ取得要求信号が前記通信制御手段から入力された場合に前記通信制御手段によって指定されたパラメータ設定ファイルから前記パラメータを抽出して前記通信制御手段に対して設定するパラメータ設定手段とを設け、前記通信制御手段は、通信データが入力されたことを契機として、前記パラメータ設定ファイルに予め付与されている順位の高い順に、前記通信データの属性のうち各順位のパラメータ設定ファイルに対応する属性に対応する前記パラメータ設定ファイルが前記記憶手段内に存在しているか否かを識別し、存在している場合には当該パラメータ設定ファイルを指定するものであり、さらに、前記単位がテンプレート単位，アプリケーション単位，アプリケーション優先度単位，ノード単位，システム単位であると共に、これら単位に対応するパラメータ設定ファイルの順位が、テンプレート用パラメータ設定ファイルの順位が１位、アプリケーション用パラメータ設定ファイルの順位が２位、アプリケーション優先度用パラメータ設定ファイルの順位が３位、ノード用パラメータ設定ファイルの順位が４位、システム全体用パラメータ設定ファイルの順位が５位であることを特徴とするパラメータ設定システム。
特定の前記パラメータを複数のノード間で共有することを特徴とする請求項１記載のパラメータ設定システム。
ネットワークを介して接続されている複数のノード間でのデータ通信の振る舞いを制御する通信制御手段を各ノードに備え、前記振る舞いを指定するパラメータを前記通信制御手段に対して設定するパラメータ設定方法において、複数の単位のそれぞれに対応した前記パラメータが記述されていると共に順位が予め付与されているパラメータ設定ファイルを前記各ノードに備えられた記憶手段に記憶するステップと、前記各ノードに備えられたパラメータ設定手段が前記パラメータの取得要求を示すパラメータ取得要求信号が前記通信制御手段から入力された場合に前記通信制御手段によって指定されたパラメータ設定ファイルから前記パラメータを抽出して前記通信制御手段に対して設定するステップとを備え、前記通信制御手段は、通信データが入力されたことを契機として、前記パラメータ設定ファイルに予め付与されている順位の高い順に、前記通信データの属性のうち各順位のパラメータ設定ファイルに対応する属性に対応する前記パラメータ設定ファイルが前記記憶手段内に存在しているか否かを識別し、存在している場合には当該パラメータ設定ファイルを指定し、さらに、前記単位がテンプレート単位，アプリケーション単位，アプリケーション優先度単位，ノード単位，システム単位であると共に、これら単位に対応するパラメータ設定ファイルの順位が、テンプレート用パラメータ設定ファイルの順位が１位、アプリケーション用パラメータ設定ファイルの順位が２位、アプリケーション優先度用パラメータ設定ファイルの順位が３位、ノード用パラメータ設定ファイルの順位が４位、システム全体用パラメータ設定ファイルの順位が５位であることを特徴とするパラメータ設定方法。
特定の前記パラメータを複数のノード間で共有することを特徴とする請求項３記載のパラメータ設定方法。