JP7037299B2 - 通信プラットフォームおよび通信処理方法 - Google Patents

Description

特許法第３０条第２項適用 平成２９年電気学会全国大会講演論文集、３－００９（平成２９年３月５日）一般社団法人電気学会発行で発表。Ａｎｎｕａｌ Ｒｅｐｏｒｔ ２０１６ ～２０１６年度 事業報告書・決算書～ 第３８頁～第３９頁（２０１７年６月）一般財団法人電力中央研究所発行で発表。

本発明は、通信プラットフォームおよび通信処理方法に関する。さらに詳述すると、本発明は、例えば、種類が異なるアプリケーション間で種々の情報やデータを交換するためのデータ伝送を行う通信の仕組みへと適用して好適な技術に関する。

複数の機序（別言すると、種類が異なるアプリケーション）によって収集・取得された複数種類の情報やデータを組み合わせて統合的に利用するために通信システムによって伝送しようとする際に、アプリケーション毎に規格が異なる通信技術／通信方式が用いられて通信システムが構築されている場合がある。

具体的には例えば電力に関連するアプリケーションについては、スマートグリッドに関係する配電自動化，スマートメータ，及びデマンドレスポンスの各アプリケーションは、配電系統と需要家とに関連することから、通信によってデータ交換を行うなどすることによって相互に連携する可能性を有している。

各アプリケーションで利用される通信方式の規格をみると、例えば、配電自動化の通信規格についてはＩＥＣ ６１８５０を適用することがＩＥＣ ＴＣ ５７ ＷＧ １７で検討されており、プロトコルスタックとしてはＩＥＣ ６１８５０－８－１で定められたＭＭＳ（Ｍanufacturing Ｍessage Ｓpecification の略）（非特許文献１，２）を用いる方法が主流である。

また、国内のスマートメータの通信規格としてはＩＥＣ ６２０５６が採用されており、ＩＥＣ ６２０５６では、計量用の情報モデル（ＣＯＳＥＭインタフェースオブジェクト）（非特許文献３）と、それにアクセスするためのアプリケーション層（ＤＬＭＳ／ＣＯＳＥＭアプリケーション層）（非特許文献４）とを利用する。

さらに、デマンドレスポンス用の通信プロトコルとしてはＪＳＣＡ（Ｊapan Ｓmart Ｃommunity Ａlliance の略）によってＯｐｅｎＡＤＲ ２．０の利用が推進されている（非特許文献５）。

このように、電力に関連する各アプリケーションで利用される通信方式の規格はアプリケーション毎に異なっている。

日本工業標準調査会「工業自動化システム－製造メッセージ仕様－サービス定義」，ＪＩＳＢ３６００，２００４年 日本工業標準調査会「工業自動化システム－製造メッセージ仕様－プロトコル仕様」，ＪＩＳＢ３６０１，２００４年 ＩＥＣ「Ｅｌｅｃｔｒｉｃｉｔｙ ｍｅｔｅｒｉｎｇ ｄａｔａ ｅｘｃｈａｎｇｅ － Ｔｈｅ ＤＬＭＳ／ＣＯＳＥＭ ｓｕｉｔｅ － Ｐａｒｔ ６－２：ＣＯＳＥＭ ｉｎｔｅｒｆａｃｅ ｃｌａｓｓｅｓ」，ＩＥＣ ６２０５６－６－２，ｅｄｉｔｉｏｎ ２．０，２０１６年 ＩＥＣ「Ｅｌｅｃｔｒｉｃｉｔｙ ｍｅｔｅｒｉｎｇ ｄａｔａ ｅｘｃｈａｎｇｅ － Ｔｈｅ ＤＬＭＳ／ＣＯＳＥＭ ｓｕｉｔｅ － Ｐａｒｔ ５－３：ＤＬＭＳ／ＣＯＳＥＭ ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ」，ＩＥＣ ６２０５６－５－３，ｅｄｉｔｉｏｎ ２．０，２０１６年 ＪＳＣＡスマートハウス・ビル標準・事業促進検討会「デマンドレスポンス・インタフェース仕様書 １．０版（案）」，２０１３年

しかしながら、アプリケーション毎に異なる規格の通信が利用される状況では、アプリケーション同士の相互連携が困難であったり多大な手間が掛かったりするという問題がある。

そこで、本発明は、規格が異なる通信を統合的に扱うことができる通信プラットフォームや通信処理方法を提供することを目的とする。

かかる目的を達成するため、本発明の通信プラットフォームは、アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられ、複数の通信方式の規格で規定された情報交換サービスが備えられ、アプリケーションプログラムから異なる通信方式の規格で規定された複数の情報モデルに基づいて生成されたデータが渡されたりアプリケーションプログラムへとデータを渡したりする各種通信方式の情報交換サービスと、各種通信方式で規定された情報交換サービスと各種通信方式の通信プロトコルの一元的な対応づけを担う共通的情報交換サービスを有する共通ＡＰＩ（Ａpplication Ｐrogramming Ｉnterface の略）を備え、アプリケーションプログラムから渡される情報交換サービスに関するデータを所定の通信方式の規格に従う形式へと共通ＡＰＩによって変換した上で共通ＡＰＩによって変換したデータをＸＭＰＰのスタンザに収容してＸＭＬ形式のメッセージにした上でＩＰパケットとして通信インターフェースへと渡し、また、通信インターフェースから渡されるデータをアプリケーションプログラムが利用する情報交換サービスに関するデータへと共通ＡＰＩによって変換した上でアプリケーションプログラムへと渡すようにしている。

また、本発明の通信処理方法は、アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられ、複数の通信方式の規格で規定された情報交換サービスが備えられ、アプリケーションプログラムから異なる通信方式の規格で規定された複数の情報モデルに基づいて生成されたデータが渡されたりアプリケーションプログラムへとデータを渡したりする各種通信方式の情報交換サービスと、各種通信方式で規定された情報交換サービスと各種通信方式の通信プロトコルの一元的な対応づけを担う共通的情報交換サービスを有する共通ＡＰＩを備える通信プラットフォームが行う通信処理方法であり、アプリケーションプログラムから渡される情報交換サービスに関するデータを所定の通信方式の規格に従う形式へと共通ＡＰＩによって変換した上で共通ＡＰＩによって変換したデータをＸＭＰＰのスタンザに収容してＸＭＬ形式のメッセージにした上でＩＰパケットとして通信インターフェースへと渡し、また、通信インターフェースから渡されるデータをアプリケーションプログラムが利用する情報交換サービスに関するデータへと共通ＡＰＩによって変換した上でアプリケーションプログラムへと渡すようにしている。

したがって、これらの通信プラットフォームや通信処理方法によると、アプリケーションレベルにおいては各アプリケーションプログラムが利用する情報交換サービスはそのままでありつつ送受信端間においては所定の通信方式の規格に合うデータが伝送されるので、各アプリケーションに関連する複数種類の情報やデータを共有して組み合わせて活用することが容易になり、種類が異なるアプリケーション同士の連携が容易になる。しかも、ＸＭＬ（Ｅxtensible Ｍarkup Ｌanguage のこと）形式に準拠すると共にＸＭＰＰ（Ｅxtensible Ｍessaging and Ｐresence Ｐrotocol のこと）に従って複数種類の情報やデータが伝送されて共有されるようになる。

本発明の通信プラットフォームや通信処理方法は、通信方式の規格としてＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲを用いるようにしても良い。この場合には、特にスマートグリッドに関係する各アプリケーションに関連する複数種類の情報やデータの共有が効率的に行われるようになる。

本発明の通信プラットフォームや通信処理方法は、共通ＡＰＩの共通的情報サービスとしてＩＥＣ ６１８５０のＡＣＳＩ（Ａbstract Ｃommunication Ｓervice Ｉnterface の略）を用いるようにしても良い。この場合には、既存の技術を活用することによって共通プラットフォームの構築が簡便になり、また、特にスマートグリッドに関係する各アプリケーションに関連する複数種類の情報やデータの共有のための仕組みの構築が簡便になる。

本発明の通信プラットフォームや通信処理方法によれば、各アプリケーションに関連する複数種類の情報やデータを共有して組み合わせて活用することを容易にすることができ、種類が異なるアプリケーション同士の連携を容易にすることができるので、アプリケーションシステムの構築や運用の簡易化や効率化を図ったり、アプリケーションの高度化を図ったりすることが可能になる。

本発明の通信プラットフォームや通信処理方法は、ＸＭＰＰに従って複数種類の情報やデータを伝送して共有することができるので、ＸＭＰＰを活用してアプリケーションシステムの構築や運用の簡易化や効率化を図ったり、アプリケーションの高度化を図ったりすることが可能になる。

本発明の通信プラットフォームや通信処理方法は、所定の通信方式の規格としてＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲを用いるようにした場合には、特にスマートグリッドに関係する各アプリケーションに関連する複数種類の情報やデータの共有を効率的に行うことができるので、特にスマートグリッドに関係するアプリケーションシステムの構築や運用の簡易化や効率化を図ったり、特にスマートグリッドに関係するアプリケーションの高度化を図ったりすることが可能になる。

本発明の通信プラットフォームや通信処理方法は、共通ＡＰＩの共通的情報サービスとしてＩＥＣ ６１８５０のＡＣＳＩを用いるようにした場合には、既存の技術を活用することによって共通プラットフォームの構築を簡便に行うことが可能になり、また、特にスマートグリッドに関係する各アプリケーションに関連する複数種類の情報やデータの共有のための仕組みの構築を簡便に行うことが可能になる。

本発明に係る通信プラットフォームや通信処理方法の処理手順を説明するフローチャートである。 実施形態の構成における通信の処理シーケンスの例を説明する図である。 実施形態の通信プラットフォームの階層構造を説明する概念図である。 実施形態の通信プラットフォームの構成要素の処理フローを示す図である。 実施形態の構成において送受信端が他の送受信端からデータを取得する場合の処理フローを示す図である。 実施形態の要求メッセージの構成を説明する図である。 実施形態の応答メッセージの構成を説明する図である。

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

図１乃至図７に、本発明に係る通信プラットフォームや通信処理方法の実施形態の一例を示す。

本実施形態の通信プラットフォームは、アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられ、アプリケーションプログラムからデータが渡されたりアプリケーションプログラムへとデータを渡したりする共通ＡＰＩを備え、アプリケーションプログラムから渡される情報交換サービスに関するデータを伝送通信規格に従う形式へと共通ＡＰＩによって変換した上で通信インターフェースへと渡し、また、通信インターフェースから渡されるデータをアプリケーションプログラムが利用する情報交換サービスに関するデータへと共通ＡＰＩによって変換した上でアプリケーションプログラムへと渡すようにしている。

また、本実施形態の通信処理方法は、アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられると共にアプリケーションプログラムからデータが渡されたりアプリケーションプログラムへとデータを渡したりする共通ＡＰＩを備える通信プラットフォームが行う通信処理方法であり、アプリケーションプログラムから渡される情報交換サービスに関するデータを伝送通信規格に従う形式へと共通ＡＰＩによって変換した上で通信インターフェースへと渡し、また、通信インターフェースから渡されるデータをアプリケーションプログラムが利用する情報交換サービスに関するデータへとＡＰＩによって変換した上でアプリケーションプログラムへと渡すようにしている。

本実施形態では、スマートグリッドに関係するアプリケーションである配電自動化，スマートメータ，及びデマンドレスポンス並びにシステム管理の各アプリケーションを相互に連携させる場合で、配電自動化，スマートメータ，及びデマンドレスポンスが利用する通信方式の規格がそれぞれＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲであるとしてこれら通信方式の規格が異なる通信を統合的に扱う場合を具体例として挙げて説明する。

上述の具体例に関する項目と汎用的／一般的な説明としての図面における表記とは以下のように対応するものとする。
－配電自動化に関係するプログラム ：「アプリケーションプログラムαc，αs」
－スマートメータに関係するプログラム ：「アプリケーションプログラムβc，βs」
－デマンドレスポンスに関係するプログラム：「アプリケーションプログラムγc，γs」
－システム管理に関係するプログラム ：「アプリケーションプログラムδc，δs」
－ＩＥＣ ６１８５０：「通信規格Ｉ」
－ＩＥＣ ６２０５６：「通信規格II」
－ＯｐｅｎＡＤＲ ：「通信規格III」

なお、「アプリケーションプログラムαc，βc，γc，及びδc」のことを「アプリケーションプログラムαc－δc」と表記すると共に「アプリケーションプログラムαs，βs，γs，及びδs」のことを「アプリケーションプログラムαs－δs」と表記し、また、「通信規格Ｉ，II，及びIII」のことを「通信規格Ｉ－III」と表記する。

本実施形態で想定する通信（具体的には、スマートグリッドに関係するアプリケーションで利用される通信）の送受信端としては例えば以下のものが挙げられる。

１）配電自動化親局（単に「親局」とも表記される）
配電自動化親局は、電力品質や系統構成の管理等の各種の配電自動化機能を実現するため、配電自動化子局などとの通信を行う。

２）配電自動化子局（単に「子局」とも表記される）
配電自動化子局は、配電系統上に設置されている各種機器（例えば、区分開閉器、計器用変成器等）の監視制御に関わる処理と通信とを担う。保護リレー（即ち、過電流リレー等）を搭載することもある。

３）ＤＲサーバ（ＤＲ：Ｄemand Ｒesponse の略）
ＤＲサーバは、電力供給側において、主に電力系統全体における需給運用に基づいてＤＲプログラム（例えば、ＣＰＰ（Ｃritical Ｐeak Ｐricing の略））を選択し、ＤＲプログラム参加者とのデマンドレスポンス信号の送受信を行う。

４）ＭＤＭＳ（Ｍeter Ｄata Ｍanagement Ｓystem の略）
ＭＤＭＳは、メータから収集した計量・計測データ及び需要家関連データを保存し、他のシステムに対して提供する。電力供給に直接関係する処理は担わない。

５）メータ
メータ（例えば、スマートメータ）は、需要家の電力量を方向別に計量する。加えて、有効・無効電力、電流、電圧などの計測を行うこともある。これらの計量・計測データは、それらを必要とするシステム（例えば、ＭＤＭＳ等）に送信される。

６）ｘＥＭＳ
「ｘＥＭＳ」は、需要家が所有する分散形電源，蓄電装置，及び負荷の監視制御を行い、必要に応じて系統側とのデータ連携を担うものを指す。ＢＥＭＳ（Ｂuilding Ｅnergy Ｍanagement Ｓystem の略）やＨＥＭＳ（Ｈome Ｅnergy Ｍanagement Ｓystem の略）などが該当する。

本発明では、データ交換の要求を送信しようとするアプリケーションプログラムαc－δc（のうちのいずれか）が関係しているアプリケーションの種類（又は、送受信端の種別）とデータ交換の要求の宛先の（即ち、データ交換の要求を受信して応答する）アプリケーションプログラムαs－δs（のうちのいずれか）が関係しているアプリケーションの種類（又は、送受信端の種別）との組み合わせに応じて（言い換えると、組み合わせ毎に）、送受信端間における〔サービスの要求〕や当該要求への〔応答〕の伝送に適用され利用される通信方式の規格（具体的には、通信規格Ｉ－IIIのうちのいずれか）が予め選定される。この予め選定される通信方式の規格のことを「伝送通信規格」と呼ぶ。

上記１）乃至６）に挙げた各種送受信端の組み合わせ毎の伝送通信規格の具体例を整理すると以下の表１のようになる。なお、表１に整理した通信区間（言い換えると、各種送受信端の組み合わせ）及び通信に利用する規格（即ち、伝送通信規格）はあくまでも例であり、本発明において対象になり得る送受信端の組み合わせの全てではない。

各種送受信端の組み合わせ毎の伝送通信規格は、例えば、あくまで一例として挙げると、以下のことが考慮されて決定される。
１）機器の制御や機器からの通知において高度な処理を要求する場合にはＩＥＣ ６１８５０を利用することが好ましい。
２）単純なデータの取得及び設定のみを利用する場合にはＩＥＣ ６２０５６を利用する。
３）相手の送受信端に他に選択肢が無い場合はＯｐｅｎＡＤＲを利用する。

また、通信プラットフォームが実装されていない送受信端と通信する状況では、通信プラットフォームが実装されていない送受信端が利用している方式に合わせる必要がある。

以下では、「（適用具体例）」との見出しの後に続けて、本発明の適用の具体例として配電自動化親局とスマートメータとの間で行われる〔サービスの要求〕及び〔応答〕に関する説明を記載する。

《通信の統合化とプラットフォーム》
本発明では、各種アプリケーションにおける処理の一部として行われる通信を統合化するために通信プラットフォームが利用される。

本発明に係る通信プラットフォームは、ＡＰＩ（Ａpplication Ｐrogramming Ｉnterface の略）を介することにより、さらに言えば、特有の考え方に基づいてＡＰＩを位置づけて利用することにより、異なるアプリケーション間の相互連携を可能にするように構成される。本発明に係る通信プラットフォームを構成する要素の一つとしてのＡＰＩのことを「共通ＡＰＩ」と呼ぶ

共通ＡＰＩは、送受信端のそれぞれに実装されている各種アプリケーション／これら各種アプリケーションの機能実現に関係する各種アプリケーションプログラムαc－δc，αs－δsと情報交換可能（言い換えると、データの授受可能）であるように構成されると共に、前記実装されている各種アプリケーションで利用される各種通信規格Ｉ－IIIで規定されている種々の情報交換サービスに対応するように構成され、各種通信規格Ｉ－III毎に異なる通信サービスを統一的方法によって利用可能とするものである。

（適用具体例）
共通ＡＰＩは、配電自動化，スマートメータ，及びデマンドレスポンス並びにシステム管理の各アプリケーション／これら各アプリケーションの機能実現に関係する各アプリケーションプログラムと情報交換可能であるように構成されると共に、配電自動化で利用されるＩＥＣ ６１８５０，スマートメータで利用されるＩＥＣ ６２０５６，及びデマンドレスポンスで利用されるＯｐｅｎＡＤＲで規定されている種々の情報交換サービスに対応するように構成され、ＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲ毎に異なる通信サービスを統一的方法によって利用可能にする。

通信プラットフォームは、また、各種通信規格Ｉ－IIIで定めたプロトコルの下位層に位置するプロトコルとしてＸＭＰＰ（Ｅxtensible Ｍessaging and Ｐresence Ｐrotocol のこと）を適用する。

そして、共通ＡＰＩを介してアプリケーションプログラムαc－δc，αs－δsから通信プラットフォームへと入力されたデータの形式がＸＭＬ（Ｅxtensible Ｍarkup Ｌanguage のこと）形式へと変換された上でＸＭＰＰを利用して伝送される。

ＸＭＰＰは、ＸＭＬ形式のデータの交換を行うことができ、また、機器の状態変化の伝送に適している点などが特徴として挙げられる。

送受信端の間で交換されるデータはメッセージに収容されて伝送される。メッセージは可変長であり、通信サービスによっては、一つのメッセージに複数のデータ項目が収容される場合がある。

これにより、例えば、送受信端それぞれのアプリケーションプログラムαc－δc，αs－δs同士がデータ交換を行う場合に、一方の送受信端（言わば、データ要求側の送受信端）において、伝送通信規格（具体的には、通信規格Ｉ－IIIのうちのいずれか）で規定される構造に従う〔サービスの要求〕を含むＸＭＬ形式の要求メッセージ（言い換えると、データ要求側の送受信端にとっての送信データ）が生成されると共に、ＸＭＰＰ層にデータ送信を依頼することによって相手端（言わば、データ提供側の送受信端）へと前記要求メッセージが伝送される。ここで、要求メッセージが生成される処理は、言い換えると、アプリケーションデータが通信データへと変換される処理である。

上記一方の送受信端においては、また、相手端（即ち、データ提供側の送受信端）から伝送されてきたＸＭＬ形式の応答メッセージ（言い換えると、データ要求側の送受信端にとっての受信データ）がＸＭＰＰ層で受け取られ、当該ＸＭＬ形式の応答メッセージが逆変換されて〔応答〕の内容が取り出されると共に、アプリケーションプログラムαc－δcへと〔応答〕の内容が渡される。ここで、応答メッセージが逆変換される処理は、言い換えると、通信データがアプリケーションデータへと変換される処理である。

また、他方の送受信端（即ち、データ提供側の送受信端）において、相手端（即ち、データ要求側の送受信端）から伝送されてきたＸＭＬ形式の要求メッセージ（言い換えると、データ提供側の送受信端にとっての受信データ）がＸＭＰＰ層で受け取られ、当該ＸＭＬ形式の要求メッセージが逆変換されて〔サービスの要求〕の内容が取り出されると共に、アプリケーションプログラムαs－δsへと〔サービスの要求〕の内容が渡される。ここで、要求メッセージが逆変換される処理は、言い換えると、通信データがアプリケーションデータへと変換される処理である。

上記他方の送受信端においては、また、相手端（即ち、データ要求側の送受信端）から伝送されてきた要求メッセージに対応して提供するデータを、伝送通信規格で規定される構造に従う〔応答〕として含むＸＭＬ形式の応答メッセージ（言い換えると、データ提供側の送受信端にとっての送信データ）が生成されると共に、ＸＭＰＰ層にデータ送信を依頼することによって相手端（即ち、データ要求側の送受信端）へと前記応答メッセージが伝送される。ここで、応答メッセージが生成される処理は、言い換えると、アプリケーションデータが通信データへと変換される処理である。

このようにＸＭＬ形式及びＸＭＰＰを利用・活用することにより、各種アプリケーション／各種アプリケーションプログラムαc－δc，αs－δsが相互にデータを活用する仕組みの構築が容易に実現され得る。

《ＸＭＰＰの構成要素》
通信プラットフォームがＸＭＰＰを利用するためには、送受信端がＸＭＰＰクライアントとなり、また、少なくとも一つのＸＭＰＰサーバが設置される。そして、ＸＭＰＰクライアント同士が、ＸＭＰＰサーバを介して通信（別言すれば、データ交換）を行う。

ＸＭＰＰサーバはＸＭＰＰクライアント同士の通信（別言すれば、データ交換）を仲介する。ＸＭＰＰクライアント同士の間でＸＭＰＰサーバを介して交換されるメッセージは「スタンザ」と呼ばれる。

送受信端は、当該の送受信端が関連するアプリケーションの機能実現に関係するアプリケーションプログラムαc－δc，αs－δsが実装されると共に通信プラットフォームが提供され、また、ＸＭＰＰにおけるクライアントとして機能・作動するように構成される。

送受信端は、必要に応じ、当該の送受信端が関連するアプリケーションの機能実現に関係するアプリケーションプログラムαc－δc，αs－δs及び共通ＡＰＩ並びに各種プログラム／ミドルウェアを記憶するための記憶部（具体的には例えば、ハードディスク）やメモリを有したり、前記アプリケーションプログラムαc－δc，αs－δs及び共通ＡＰＩ並びに各種プログラム／ミドルウェアの処理を実行するための制御部（具体的には例えば、ＣＰＵ（即ち、中央演算処理装置））を有したりするものとして構成される。

送受信端は、ＸＭＰＰにおけるクライアントとして機能・作動するように、ＸＭＰＰサーバとの間で通信を行うための通信部を有する。

通信部は、通信網・通信線へと接続するための通信インターフェースであり、例えば無線通信を行う無線モジュールや有線通信を行う有線モジュールを備え、通信ネットワークへと接続してＸＭＰＰサーバを介して他の送受信端との間でメッセージ（即ち、スタンザ）の交換を行う機能を備える。

《通信プラットフォームの構成要素》
通信プラットフォームは、共通ＡＰＩを通じて一方の送受信端内のアプリケーションプログラムαc－δcと他方の送受信端内のアプリケーションプログラムαs－δsとの間で通信を行う機能（具体的には例えば、各種アプリケーションに纏わる情報通知やデータ交換などのやりとりを行う機能）を提供する。

（適用具体例）
通信プラットフォームは、共通ＡＰＩを通じて一方の送受信端である配電自動化親局の機能実現に関係する（言い換えると、配電自動化の機能実現に関係する）アプリケーションプログラムαcと他方の送受信端であるスマートメータの機能実現に関係するアプリケーションプログラムβsとの間で通信を行う機能を提供する。

通信プラットフォームは、ソフトウェアのうちミドルウェアとして位置づけられる。通信プラットフォームを構成する主な要素は以下のとおりである。
（１）共通ＡＰＩ
（２）ＸＭＰＰラッパ ～通信プロトコルの上位層を構成する
（３）ＸＭＰＰクライアントライブラリ ～通信プロトコルの下位層を構成する

本実施形態では、Ｊａｖａ（登録商標）が用いられて通信プラットフォームが実装（言い換えると、プログラミング）される。

（１）共通ＡＰＩ
共通ＡＰＩは、各種アプリケーションの機能実現に関係するものであって送受信端のそれぞれに実装されている各種アプリケーションプログラムαc－δc，αs－δsと情報交換可能（言い換えると、データの授受可能）であるように構成されると共に、前記実装されている各種アプリケーションで利用される各種通信規格Ｉ－IIIで規定されている種々の情報交換サービスに対応するように構成される。

（適用具体例）
共通ＡＰＩは、配電自動化，スマートメータ，及びデマンドレスポンス並びにシステム管理の機能実現に関係するものであって送受信端のそれぞれに実装されている各種アプリケーションプログラムと情報交換可能であるように構成されると共に、配電自動化で利用されるＩＥＣ ６１８５０，スマートメータで利用されるＩＥＣ ６２０５６，及びデマンドレスポンスで利用されるＯｐｅｎＡＤＲで規定されている種々の情報交換サービスに対応するように構成される。

共通ＡＰＩは、通信における役割／位置づけとしては、データ要求側の送受信端であるＸＭＰＰクライアントとしての送信・受信機能を用いた情報交換サービス／通信サービスに利用され、また、データ提供側の送受信端であるＸＭＰＰクライアントとしての送信・受信機能を用いた情報交換サービス／通信サービスに利用される。

そして、共通ＡＰＩは、情報交換サービス／通信サービスをアプリケーションプログラムαc－δc，αs－δsへと提供する機能として、データを送信する機能とデータを受信する機能とを備える。

共通ＡＰＩが対応する（そして、送受信端において利用される）情報交換サービス／通信サービスの種類・分類の例として以下のものが挙げられる。
－通信の初期化サービス：通信のセッションを開始する場合に利用する。
－通信の終了サービス：通信のセッションを終了する場合に利用する。
－データ取得サービス：機器やセンサなどの種々のデータを取得する場合に利用する。
－データ設定サービス：機器等の整定値を設定・更新する場合などに利用する。
－選択・制御サービス：機器を制御する場合に利用する。
－通知サービス ：機器等に状態変化が発生した際に利用する。
－ファイル転送サービス：ソフトウェアを更新する場合に利用する。

（適用具体例）
配電自動化，スマートメータ，及びデマンドレスポンスで利用される情報交換サービスの具体例であって、共通ＡＰＩが対応する情報交換サービスの具体例として以下のものが挙げられる。なお、以下の具体例は、ＩＥＣ ６１８５０のＡＣＳＩ（Ａbstract Ｃommunication Ｓervice Ｉnterface の略）に規定されている情報交換サービスの例である。
－通信の初期化サービス：Associate
－通信の終了サービス ：Release
－データ取得サービス ：GetDataValues，GetDataSetValues，QueryLogByTime
－データ設定サービス ：SetDataValues，SetDataSetValues
－選択・制御サービス ：SelectWithValue，Operate
－通知サービス ：SetURCBValues，Report，CommandTermination
－ファイル転送サービス：SetFile

そして、共通ＡＰＩは、アプリケーションプログラムαc－δc，αs－δsから指定される（言い換えると、渡される）情報交換サービスＡについての〔サービスの要求〕や〔応答〕の内容を各種通信規格Ｉ－III固有の通信サービスａの要求や応答へと変換すると共に、当該変換した通信サービスａついての〔サービスの要求〕や〔応答〕をＸＭＰＰラッパへと渡す。

（適用具体例）
共通ＡＰＩは、配電自動化に関係するアプリケーションプログラムαcから指定される、或いは、スマートメータに関係するアプリケーションプログラムβsから指定される、情報交換サービスの要求である「GetDataSetValuesRequest」（尚、ＡＣＳＩ用変数としてのＪａｖａクラスである）やその応答である「GetDataSetValuesResponse」を内容とする〔サービスの要求〕や〔応答〕の内容をＩＥＣ ６２０５６固有の通信サービスの要求である「GetRequestNormal」やその応答である「GetResponseNormal」（尚、ＣＯＳＥＭ用のＪａｖａクラスである）へと変換すると共に、当該「GetRequestNormal」を内容とする〔サービスの要求〕や当該「GetResponseNormal」を内容とする〔応答〕をＸＭＰＰラッパへと渡す。

共通ＡＰＩは、また、ＸＭＰＰラッパから渡される各種通信規格Ｉ－III固有の通信サービスａを介して〔サービスの要求〕や〔応答〕の内容を情報交換サービスＡへと変換・渡すと共に、当該変換した情報交換サービスＡついての〔サービスの要求〕や〔応答〕をアプリケーションプログラムαc－δc，αs－δsへと渡す。

（適用具体例）
共通ＡＰＩは、ＸＭＰＰラッパから渡されるＩＥＣ ６２０５６固有の通信サービスの要求である「GetRequestNormal」やその応答である「GetResponsetNormal」を情報交換サービスの要求である「GetDataSetValuesRequest」やその応答である「GetDataSetValuesResponse」へとそれぞれ変換すると共に、当該「GetDataSetValuesResponse」を配電自動化に関係するアプリケーションプログラムαcへと渡し、或いは、応答側では当該「GetDataSetValuesRequest」をスマートメータに関係するアプリケーションプログラムβsへと渡す。

（２）ＸＭＰＰラッパ
ＸＭＰＰラッパは、通信規格Ｉ－III相互間の違いを吸収するために、各種通信規格Ｉ－IIIのそれぞれに対応した変換モジュールを有し、各種通信規格Ｉ－IIIそれぞれの通信サービスを提供する。

（適用具体例）
ＸＭＰＰラッパは、ＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲのそれぞれに対応した変換モジュールを有し、これら通信規格それぞれの通信サービスを提供する。

ＸＭＰＰラッパは、共通ＡＰＩに対して、通信規格Ｉ－III固有の通信サービスａを提供するため、当該通信サービスａに関する内容をＸＭＰＰのスタンザへと収容してＸＭＬ形式のメッセージを生成すると共に、ＸＭＰＰクライアントライブラリに対してデータ送信を依頼する。

（適用具体例）
ＸＭＰＰラッパは、共通ＡＰＩから渡されるＩＥＣ ６２０５６固有の通信サービスの要求である「GetRequestNormal」に対応するため、当該「GetRequestNormal」に関する内容をＸＭＰＰのスタンザへと収容してＸＭＬ形式のメッセージを生成すると共に、ＸＭＰＰクライアントライブラリに対してデータ送信を依頼する。

ＸＭＰＰラッパは、また、ＸＭＰＰクライアントライブラリからＸＭＰＰのスタンザ（ＸＭＬ形式のメッセージ）が渡されると、当該ＸＭＰＰのスタンザに収容されている通信サービスａの要求や応答を共通ＡＰＩへと渡す。

（適用具体例）
ＸＭＰＰラッパは、ＸＭＰＰクライアントライブラリからＸＭＰＰのスタンザ（ＸＭＬ形式のメッセージ）が渡されると、当該ＸＭＰＰのスタンザに収容されているＩＥＣ ６２０５６固有の通信サービスの要求である「GetRequestNormal」に関する内容を共通ＡＰＩへと渡す。

（３）ＸＭＰＰクライアントライブラリ
ＸＭＰＰクライアントライブラリは、ＸＭＰＰラッパから依頼されて、ＸＭＬ形式のメッセージを送信データとしてＩＰパケットへと収容してＸＭＰＰサーバへと送信する機能を提供する。

ＸＭＰＰクライアントライブラリは、また、ＸＭＰＰサーバから送信されたＩＰパケットを受信し、当該ＩＰパケットを展開して当該ＩＰパケットに収容されているＸＭＬ形式のメッセージを取り出して受信データとしてＸＭＰＰラッパへと渡す機能を提供する。

上述のような機能を提供するため、送受信端それぞれのＸＭＰＰクライアントライブラリは、ＸＭＰＰサーバを介して連携する。

《構成要素の連携》
ＸＭＰＰクライアントとしての一方の送受信端（位置づけとしては、データ要求側の送受信端）がＸＭＰＰクライアントとしての他方の送受信端（位置づけとしては、データ提供側の送受信端）からデータを取得する場合の処理手順を説明する。なお、データ要求側の送受信端には配電自動化に関係するアプリケーションプログラムαcが実装されており、また、データ提供側の送受信端にはスマートメータに関係するアプリケーションプログラムβsが実装されているものとする。

（適用具体例）
ＸＭＰＰクライアントとしての配電自動化親局がＸＭＰＰクライアントとしてのスマートメータからデータを取得する場合の処理手順を説明する。なお、配電自動化親局には配電自動化に関係するアプリケーションプログラムαcが実装されており、スマートメータにはスマートメータに関係するアプリケーションプログラムβsが実装されている。

まず、データ要求側の送受信端とデータ提供側の送受信端とのそれぞれにおいて通信プラットフォームが起動する（図１のＳ１）。

続いて、通信プラットフォームの初期化処理が行われる（図１のＳ２）。具体的には例えば、情報交換サービスを通信サービスへと変換する際に利用される作業領域（具体的には例えば、メモリ）などがクリアされて初期化され、また、情報交換サービスの要求や応答の構造情報，通信サービスの要求や応答の構造情報，及び情報交換サービスの要求や応答を通信サービスの要求や応答へと変換する際に用いられる規則が例えば記憶部やメモリに保持される。さらに、データ要求側のアプリケーションの種類（又は、送受信端の種別）とデータ提供側のアプリケーションの種類（又は、送受信端の種別）との組み合わせに対して割り当てられた伝送通信規格の対応づけデータが記憶部やメモリに保持される。

上記Ｓ２の処理の後に、通信プラットフォームは通信処理待ち（即ち、〔サービスの要求〕や〔応答〕に係る処理待ち）の状態になる（図１のＳ３）。具体的には、アプリケーションプログラムαc，βsからの送信処理の要求や、ＸＭＰＰクライアントライブラリからの受信処理の要求の待機状態になる。

そして、データ要求側の送受信端に実装されているアプリケーションプログラムαcにおいて送信処理の要求が生起すると（図１及び図２のＳ４：Ｙｅｓ）、アプリケーションプログラムαcによって指定された情報交換サービスＡを対象とする〔サービスの要求〕が共通ＡＰＩへと渡される（図４及び図５の丸１）。

（適用具体例）
配電自動化親局に実装されている配電自動化に関係するアプリケーションプログラムαcにおいて送信処理の要求が生起すると、当該アプリケーションプログラムαcによって指定された情報交換サービスを利用するための「GetDataSetValuesRequest」を内容とする〔サービスの要求〕が共通ＡＰＩへと渡される。ここで、アプリケーションプログラムαcから共通ＡＰＩへと渡される〔サービスの要求〕の形式はＪａｖａである。また、共通ＡＰＩは、ＩＥＣ ６１８５０のＡＣＳＩをベースとした構造であり、具体的には、ＡＣＳＩで定義されている情報交換サービスの一部若しくは全部に対応するように構成され（尚、共通ＡＰＩとしてＡＣＳＩがそのまま用いられるようにしても良い）、さらに、必要に応じ、ＡＣＳＩでは定義されていないもののアプリケーションプログラムαc－δc，αs－δsで利用される情報交換サービスにも対応するように構成される。そして、「GetDataSetValuesRequest」はＡＣＳＩ用変数としてのＪａｖａクラスである。

そして、データ要求側の送受信端の共通ＡＰＩにより、データ提供側（別言すると、応答側）の情報交換サービスＡを対象とする〔サービスの要求〕の内容が伝送通信規格で規定されている構造へとマッピングされて伝送通信規格固有の通信サービスａの要求へと変換される（図１及び図２のＳ６）。この際、処理対象の〔サービスの要求〕に関係する送信元（即ち、データ要求側の送受信端，アプリケーションプログラムαc）と最終的な宛先（即ち、データ提供側の送受信端，アプリケーションプログラムβs）との組み合わせに対して予め割り当てられた通信規格Ｉ－III（のうちのいずれか）が伝送通信規格として選択される。

（適用具体例）
共通ＡＰＩにより、情報交換サービスの要求である「GetDataSetValuesRequest」を内容とする〔サービスの要求〕の内容がＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造へとマッピングされてＩＥＣ ６２０５６固有の通信サービスの要求である「GetRequestNormal」へと変換される。この際、「GetDataSetValuesRequest」を内容とする〔サービスの要求〕の送信元（即ち、配電自動化親局，アプリケーションプログラムαc）と最終的な宛先（即ち、スマートメータ，アプリケーションプログラムβs）との組み合わせに対して予め割り当てられた通信規格であるＩＥＣ ６２０５６が伝送通信規格として選択される。そして、「GetRequestNormal」はＣＯＳＥＭ（ＩＥＣ ６２０５６）用のＪａｖａクラスである。

共通ＡＰＩによって変換された、具体的には情報交換サービスＡがマッピングされた、伝送通信規格固有の通信サービスａの要求を内容とする〔サービスの要求〕は、ＸＭＰＰラッパへと渡される（図４及び図５の丸２）。

（適用具体例）
共通ＡＰＩによって変換された、具体的には情報交換サービスの要求「GetDataSetValuesRequest」がマッピングされたＩＥＣ ６２０５６（ＣＯＳＥＭ）固有の通信サービスの要求「GetRequestNormal」を内容とする〔サービスの要求〕は、ＸＭＰＰラッパへと渡される。

次に、データ要求側の送受信端のＸＭＰＰラッパにより、共通ＡＰＩから渡された通信サービスａの要求を内容とする〔サービスの要求〕の内容がＸＭＰＰのスタンザへと収容され、ＸＭＬ形式のメッセージが生成される（図１及び図２のＳ７）。

（適用具体例）
ＸＭＰＰラッパにより、共通ＡＰＩから渡された「GetRequestNormal」を内容とする〔サービスの要求〕の内容がＸＭＰＰのスタンザへと収容され、ＸＭＬ形式のメッセージが生成される。なお、図６及び図７における「ＰＤＵ」は Ｐrotocol Ｄata Ｕnit の略である。

ＸＭＰＰラッパによって生成されるメッセージは、伝送通信規格で規定されている構造へとマッピングされた〔サービスの要求〕の内容を項目／要素として含む、ＸＭＰＰのスタンザである。

さらに、ＸＭＰＰラッパが、生成したＸＭＬ形式のメッセージ（ＸＭＰＰのスタンザ）をデータ提供側の送受信端へと伝送する処理をＸＭＰＰクライアントライブラリへと依頼する（図４及び図５の丸３）。

そして、データ要求側の送受信端のＸＭＰＰクライアントライブラリにより、ＸＭＬ形式のメッセージの送信処理が行われる（図１及び図２のＳ８）。

具体的には、データ要求側の送受信端のＸＭＰＰクライアントライブラリにより、ＸＭＰＰラッパによって生成されたＸＭＬ形式のメッセージ（ＸＭＰＰのスタンザ）がＩＰパケットへと収容される（言い換えると、ＸＭＰＰに従う構造へとマッピングされる）。

以上により、共通ＡＰＩを介して渡された〔サービスの要求〕が埋め込まれたＸＭＰＰのスタンザを含むＩＰパケットとして要求メッセージが作成されて伝送される。

要求メッセージは、データ要求側の送受信端の通信部（通信インターフェース）を介してＸＭＰＰサーバへと送信される（図４及び図５の丸４）。

ＸＭＰＰサーバは、受信した要求メッセージをデータ提供側の送受信端へと転送する（図４の丸５）。なお、ＸＭＰＰのスタンザの中には最終的な宛先（即ち、データ提供側の送受信端）のアドレスが含まれている。

ＸＭＰＰサーバによって転送された要求メッセージは、データ提供側の送受信端の通信部（通信インターフェース）を介して当該データ提供側の送受信端によって受信される。

そして、要求メッセージを受信することを契機として、データ提供側の送受信端のＸＭＰＰクライアントライブラリにおいて受信処理の要求が生起し（図１及び図２のＳ５：Ｙｅｓ）、当該ＸＭＰＰクライアントライブラリによって要求メッセージの受信処理が行われる（図１及び図２のＳ９）。

具体的には、データ提供側の送受信端のＸＭＰＰクライアントライブラリにより、要求メッセージであるＩＰパケットが展開され、ＸＭＰＰに従う構造が参照されつつ、ＸＭＰＰのスタンザ（言い換えると、ＸＭＬ形式のメッセージ）が取り出される。

ＸＭＰＰクライアントライブラリによって取り出されたＸＭＰＰのスタンザは、ＸＭＰＰラッパへと渡される（図４の丸６）。

そして、データ提供側の送受信端のＸＭＰＰラッパにより、ＸＭＰＰクライアントライブラリから渡されたＸＭＰＰのスタンザに収容されている、伝送通信規格で規定されている構造に相当する部分（即ち、伝送通信規格固有の通信サービスａを利用するための〔サービスの要求〕の内容）が取り出される（図１及び図２のＳ１０）。

（適用具体例）
ＸＭＰＰラッパにより、ＸＭＰＰのスタンザに収容されている、ＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造に相当する部分（即ち、ＩＥＣ ６２０５６（ＣＯＳＥＭ）固有の通信サービスの要求「GetRequestNormal」を内容とする〔サービスの要求〕の内容）が取り出される。

ＸＭＰＰラッパによって取り出された、伝送通信規格で規定されている構造に相当する部分は、共通ＡＰＩを介して、データ提供側の送受信端に実装されているアプリケーションプログラムβsへと渡される（図４の丸７，丸８）。

（適用具体例）
ＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造に相当する部分は、共通ＡＰＩを介して、スマートメータに実装されているアプリケーションプログラムβsへと渡される。

この際、データ提供側の送受信端の共通ＡＰＩにより、伝送通信規格固有の通信サービスａの要求を内容とする〔サービスの要求〕の内容が情報交換サービスＡの要求へと変換される（図１及び図２のＳ１１）。

（適用具体例）
共通ＡＰＩにより、ＩＥＣ ６２０５６固有の通信サービスの要求「GetRequestNormal」を内容とする〔サービスの要求〕の内容が情報交換サービス「GetDataSetValuesRequest」へと変換される。

そして、共通ＡＰＩを介して〔サービスの要求〕が渡されることを契機として、当該〔サービスの要求〕に対して応答する（具体的には、要求されたデータを応答にて返信する）ため、データ提供側の送受信端に実装されているアプリケーションプログラムβsにおいて送信処理の要求が生起する（図１及び図２のＳ４：Ｙｅｓ）。

（適用具体例）
共通ＡＰＩを介して〔サービスの要求〕が渡されることを契機として、当該〔サービスの要求〕に対して応答するため、スマートメータに実装されているスマートメータに関係するアプリケーションプログラムβsにおいて送信処理の要求が生起する。

データ提供側の送受信端に実装されているアプリケーションプログラムβsは、〔サービスの要求〕に係る情報交換サービスＡに関連して伝送依頼されたデータを情報交換サービスＡの〔応答〕にて返信するため、情報交換サービスＡの応答として伝送依頼に対応するデータ項目とを内容とする〔応答〕を共通ＡＰＩへと渡す（図４の丸９）。

（適用具体例）
スマートメータに実装されているアプリケーションプログラムβsは、〔サービスの要求〕に係る情報交換サービスの要求「GetDataSetValuesRequest」に関連して伝送依頼されたデータを情報交換サービス「GetDataSetValues」の応答にて返信するため、情報交換サービス「GetDataSetValues」の応答として伝送依頼に対応するデータ項目を内容とする〔応答〕を共通ＡＰＩへと渡す。

そして、データ提供側の送受信端の共通ＡＰＩにより、情報交換サービスＡの応答として、伝送依頼に対応するデータ項目を内容とする〔応答〕の内容が伝送通信規格で規定されている構造へとマッピングされて伝送通信規格固有の通信サービスａ（応答）へと変換される（図１及び図２のＳ６）。この際、処理対象の〔応答〕に関係する送信元（即ち、データ提供側の送受信端，アプリケーションプログラムβs）と最終的な宛先（即ち、データ要求側の送受信端，アプリケーションプログラムαc）との組み合わせに対して予め割り当てられた通信規格Ｉ－III（のうちのいずれか）が伝送通信規格として選択される。

（適用具体例）
共通ＡＰＩにより、情報交換サービスの応答である「GetDataSetValuesResponse」として、伝送依頼に対応するデータ項目の内容がＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造へと変換されてＩＥＣ ６２０５６固有の通信サービスの応答である「GetResponseNormal」へと変換される。この際、「GetDataSetValuesResponse」を内容とする〔応答〕の送信元（即ち、スマートメータ，アプリケーションプログラムβs）と最終的な宛先（即ち、配電自動化親局，アプリケーションプログラムαc）との組み合わせに対して予め割り当てられた通信規格であるＩＥＣ ６２０５６が伝送通信規格として選択される。そして、「GetResponseNormal」はＣＯＳＥＭ（ＩＥＣ ６２０５６）用のＪａｖａクラスである。

共通ＡＰＩによって変換された、具体的には情報交換サービスＡがマッピングされた、伝送通信規格固有の通信サービスａ（応答）から、伝送依頼に対応するデータ項目とを内容とする〔応答〕が、ＸＭＰＰラッパへと渡される（図４の丸１０）。

（適用具体例）
共通ＡＰＩによって変換された、具体的には情報交換サービスの応答「GetDataSetValuesResponse」がマッピングされた、ＩＥＣ ６２０５６（ＣＯＳＥＭ）固有の通信サービス「GetResponseNormal」と、伝送依頼に対応するデータ項目とを内容とする〔応答〕が、ＸＭＰＰラッパへと渡される。

次に、データ提供側の送受信端のＸＭＰＰラッパにより、共通ＡＰＩから渡された通信サービスａ（応答）とデータ項目とを内容とする〔応答〕の内容がＸＭＰＰのスタンザへと収容され、ＸＭＬ形式のメッセージが生成される（図１及び図２のＳ７）。

（適用具体例）
ＸＭＰＰラッパにより、共通ＡＰＩから渡された「GetResponseNormal」とデータ項目を内容とする〔応答〕の内容がＸＭＰＰのスタンザへと収容され、ＸＭＬ形式のメッセージが生成される。

ＸＭＰＰラッパによって生成されるメッセージは、伝送通信規格で規定されている構造へとマッピングされた〔応答〕の内容を項目／要素として含む、ＸＭＰＰのスタンザである。

さらに、ＸＭＰＰラッパが、生成したＸＭＬ形式のメッセージ（ＸＭＰＰのスタンザ）をデータ要求側の送受信端へと伝送する処理をＸＭＰＰクライアントライブラリへと依頼する（図４及び図５の丸１１）。

そして、データ提供側の送受信端のＸＭＰＰクライアントライブラリにより、ＸＭＬ形式のメッセージの送信処理が行われる（図１及び図２のＳ８）。

具体的には、データ提供側の送受信端のＸＭＰＰクライアントライブラリにより、ＸＭＰＰラッパによって生成されたＸＭＬ形式のメッセージ（ＸＭＰＰのスタンザ）がＩＰパケットへと収容される（言い換えると、ＸＭＰＰに従う構造へとマッピングされる）。

以上により、共通ＡＰＩを介して渡された〔応答〕が埋め込まれたＸＭＰＰのスタンザを含むＩＰパケットとして応答メッセージが作成されて伝送される。

応答メッセージは、データ提供側の送受信端の通信部（通信インターフェース）を介してＸＭＰＰサーバへと送信される（図４及び図５の丸１２）。

ＸＭＰＰサーバは、受信した応答メッセージをデータ要求側の送受信端へと転送する（図４及び図５の丸１３）。なお、ＸＭＰＰのスタンザの中には最終的な宛先（即ち、データ要求側の送受信端）のアドレスが含まれている。

ＸＭＰＰサーバによって転送された応答メッセージは、データ要求側の送受信端の通信部（通信インターフェース）を介して当該データ要求側の送受信端によって受信される。

そして、応答メッセージを受信することを契機として、データ要求側の送受信端のＸＭＰＰクライアントライブラリにおいて受信処理の要求が生起し（図１及び図２のＳ５：Ｙｅｓ）、当該ＸＭＰＰクライアントライブラリによって応答メッセージの受信処理が行われる（図１及び図２のＳ９）。

具体的には、データ要求側の送受信端のＸＭＰＰクライアントライブラリにより、応答メッセージであるＩＰパケットが展開され、ＸＭＰＰに従う構造が参照されつつ、ＸＭＰＰのスタンザ（言い換えると、ＸＭＬ形式のメッセージ）が取り出される。

ＸＭＰＰクライアントライブラリによって取り出されたＸＭＰＰのスタンザは、ＸＭＰＰラッパへと渡される（図４及び図５の丸１４）。

そして、データ要求側の送受信端のＸＭＰＰラッパにより、ＸＭＰＰクライアントライブラリから渡されたＸＭＰＰのスタンザに収容されている、伝送通信規格で規定されている構造に相当する部分（即ち、伝送通信規格固有の通信サービスａ（応答）とデータ項目とを内容とする〔応答〕の内容）が取り出される（図１及び図２のＳ１０）。

（適用具体例）
ＸＭＰＰラッパにより、ＸＭＰＰのスタンザに収容されている、ＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造に相当する部分（即ち、ＩＥＣ ６２０５６（ＣＯＳＥＭ）固有の通信サービスの応答「GetResponseNormal」とデータ項目とを内容とする〔応答〕の内容）が取り出される。

ＸＭＰＰラッパによって取り出された、伝送通信規格で規定されている構造に相当する部分は、共通ＡＰＩを介して、データ要求側の送受信端に実装されているアプリケーションプログラムαcへと渡される（図４及び図５の丸１５，丸１６）。

（適用具体例）
ＣＯＳＥＭ（ＩＥＣ ６２０５６）に従う構造に相当する部分は、共通ＡＰＩを介して、配電自動化親局に実装されているアプリケーションプログラムαcへと渡される。

この際、データ要求側の送受信端の共通ＡＰＩにより、伝送通信規格固有の通信サービスａ（応答）を内容とする〔応答〕の内容が情報交換サービスＡへと変換される（図１及び図２のＳ１１）。

（適用具体例）
共通ＡＰＩにより、ＩＥＣ ６２０５６固有の通信サービスの応答「GetResponseNormal」を内容とする〔応答〕の内容が情報交換サービスの応答「GetDataSetValuesResponse）」へと変換される。

以上により、データ要求側の送受信端が、自らが送信した要求メッセージの内容に対応するデータを、データ提供側の送受信端から取得する。

以上のように構成された通信プラットフォームや通信処理方法によれば、アプリケーションレベルにおいては各アプリケーションプログラムαc－δc，αs－δsが利用する情報交換サービスＡはそのままでありつつデータ要求側の送受信端とデータ提供側の送受信端との間においては伝送通信規格の形式のデータが伝送されるので、各アプリケーションに関連する複数種類の情報やデータを共有して組み合わせて活用することを容易にすることができる。このため、アプリケーションシステムの構築や運用の簡易化や効率化を図ったり、アプリケーションの高度化を図ったりすることが可能になる。

共通ＡＰＩ（具体的には例えば、ＩＥＣ ６１８５０のＡＣＳＩをベースとして構成されるもの）と各通信方式の通信メッセージとの対応は静的であることから、ＸＭＰＰラッパが利用する変換用データ（具体的には、「情報交換サービスの要求や応答の構造情報」や「通信サービスの要求や応答の構造情報」としてのＪａｖａクラスとＸＭＬデータとの対応づけ）がデータベースではなくメモリに予め読み込まれるようにすると共に各送受信端において同じ内容の変換用データが用いられるようにすることにより、通信処理の高速化及び効率化を両立させることが可能になる。

各送受信端において同じ内容の変換用データが用いられるようにすることにより、さらに、送信端と受信端とが利用する変換用データの内容に違いがあると受信端においてメッセージを受信した際に当該受信端のＸＭＰＰラッパにおいてメッセージの変換を行うことができないのに対し、送信端と受信端とにおいてＸＭＰＰラッパが共通の変換用データを利用してメッセージの変換が確実に行われるようにすることが可能になる。

また、メッセージを構成する要素毎に変換用データを参照（言い換えると、検索）してその結果に基づいてメッセージの変換を行うため、検索にかかる処理量を減らすことが望ましいところ、メッセージを構成する要素のみを変換用データに含めるようにすることにより、検索の処理の無駄を低減させることが可能になる。

なお、上述の実施形態は本発明を実施する際の好適な形態の一例ではあるものの本発明の実施の形態が上述のものに限定されるものではなく、本発明の要旨を逸脱しない範囲において本発明は種々変形実施可能である。

例えば、上述の実施形態ではスマートグリッドに関係する各アプリケーションを相互に連携させる場合を具体例として挙げて説明したが、本発明の適用対象はスマートグリッドに関係するアプリケーションが利用する通信の仕組みに限定されるものではなく、スマートグリッドとは関係が無い通信の仕組みに適用されるようにしても良く、さらに言えば、電力設備とは関係が無い通信の仕組みに適用されるようにしても良い。

また、上述の実施形態では共通ＡＰＩがＡＣＳＩをベースとして構成されるようにしているが、場合によっては、アプリケーションプログラムαc－δc，αs－δsで利用される情報交換サービスに対応し得るものとして独自に構成されるようにしても良い。

また、上述の実施形態においては送受信端が関係している各種アプリケーションで利用されている通信規格Ｉ－IIIのうちのいずれかが伝送通信規格として選定されるようにしているが、送受信端が関係している各種アプリケーションで利用されている通信規格Ｉ－IIIではない通信規格が伝送通信規格として選定されるようにしても良い。

また、上述の実施形態ではデータ要求側の送受信端とデータ提供側の送受信端との両方に本発明に係る通信プラットフォームが実装されるようにしているが、本発明に係る通信プラットフォームが利用されて行われる通信の態様は通信プラットフォームが実装された送受信端同士の通信には限定されない。すなわち、通信相手の送受信端が、本発明に係る通信プラットフォームに対応していない場合でも、ＸＭＰＰを利用したＩＥＣ ６１８５０，ＩＥＣ ６２０５６，又はＯｐｅｎＡＤＲの通信が可能であれば、本発明に係る通信プラットフォームが実装された送受信端と通信を行うことが可能である。

αc 配電自動化に関係するアプリケーションプログラム
βs スマートメータに関係するアプリケーションプログラム

Claims (6)

1. アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられ、複数の通信方式の規格で規定された情報交換サービスが備えられ、前記アプリケーションプログラムから異なる通信方式の規格で規定された複数の情報モデルに基づいて生成されたデータが渡されたり前記アプリケーションプログラムへとデータを渡したりする各種通信方式の情報交換サービスと、各種通信方式で規定された情報交換サービスと各種通信方式の通信プロトコルの一元的な対応づけを担う共通的情報交換サービスを有する共通ＡＰＩを備え、前記アプリケーションプログラムから渡される情報交換サービスに関するデータを所定の通信方式の規格に従う形式へと前記共通ＡＰＩによって変換した上で前記共通ＡＰＩによって変換したデータをＸＭＰＰのスタンザに収容してＸＭＬ形式のメッセージにした上でＩＰパケットとして前記通信インターフェースへと渡し、また、前記通信インターフェースから渡されるデータを前記アプリケーションプログラムが利用する前記情報交換サービスに関するデータへと前記共通ＡＰＩによって変換した上で前記アプリケーションプログラムへと渡すことを特徴とする通信プラットフォーム。
2. 前記通信方式の規格がＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲであることを特徴とする請求項１記載の通信プラットフォーム。
3. 前記共通ＡＰＩの前記共通的情報交換サービスがＩＥＣ ６１８５０のＡＣＳＩであることを特徴とする請求項１または２に記載の通信プラットフォーム。
4. アプリケーションプログラムが実装されると共に通信インターフェースを有する送受信端に備えられ、複数の通信方式の規格で規定された情報交換サービスが備えられ、前記アプリケーションプログラムから異なる通信方式の規格で規定された複数の情報モデルに基づいて生成されたデータが渡されたり前記アプリケーションプログラムへとデータを渡したりする各種通信方式の情報交換サービスと、各種通信方式で規定された情報交換サービスと各種通信方式の通信プロトコルの一元的な対応づけを担う共通的情報交換サービスを有する共通ＡＰＩを備える通信プラットフォームが行う通信処理方法であり、前記アプリケーションプログラムから渡される情報交換サービスに関するデータを所定の通信方式の規格に従う形式へと前記共通ＡＰＩによって変換した上で前記共通ＡＰＩによって変換したデータをＸＭＰＰのスタンザに収容してＸＭＬ形式のメッセージにした上でＩＰパケットとして前記通信インターフェースへと渡し、また、前記通信インターフェースから渡されるデータを前記アプリケーションプログラムが利用する前記情報交換サービスに関するデータへと前記共通ＡＰＩによって変換した上で前記アプリケーションプログラムへと渡すことを特徴とする通信処理方法。
5. 前記通信方式の規格としてＩＥＣ ６１８５０，ＩＥＣ ６２０５６，及びＯｐｅｎＡＤＲを用いることを特徴とする請求項４載の通信処理方法。
6. 前記共通ＡＰＩの前記共通的情報交換サービスとしてＩＥＣ ６１８５０のＡＣＳＩを用いることを特徴とする請求項４または５に記載の通信処理方法。

Images