ADEのフレームワーク 2

© Copyright Chris Shaw and licensed for reuse under this Creative Commons Licence.

OpenADE-その2で、UCAIug-OpenSGのOpenADEのホームページ、「SharedDocuments」の「Visionフォルダ」で公開されている資料「A Framework for Automated Data Exchange (ADE):ADEのフレームワーク」をご紹介しましたが、今回は、その続きです。

前回、「3.ADEアーキテクチャーの考察」部分は、翻訳してさらりと紹介するだけにとどめましたので、最初に何点かフォローしておきたいと思います。

「AMI-Enterprise SRSの参照」に関して

ポリモフィック、アトミックなど、専門的すぎるので深入りしませんでした。

まずは、AMI-Enterprise-TFでは、社内(あるいは関連する電力業界の会社)の独立していたシステム間の統合に焦点があてられていますが、OpenADE-TFではTPSP(第三者企業のサービスプロバイダー)のシステムと、消費者データを中心とした電力会社が保有する顧客情報を保有するシステムとの統合に焦点が当たっている-という点を理解していただければよいと思います。

下図は、AMI-Enterprise SRSに記載されていた「AMI Enterprise Landscape」の図に手を加えて、OpenADEの守備範囲を緑色で示したものです。

図の拡大

「B2B統合に関する考察」に関して

この部分も、さらりと翻訳して済ませてしまいましたが、ADEは、独立したシステム間で自動的にデータ交換をするためのB2B統合の1つである-という点を理解していただければよいと思います。

B2B統合のスタイルとして、EAI(Enterprise Application Integration)、EDI(Electronic Data Interchange)、SFTP(SSH File Transfer Protocol)、ESB(Enterprise Service Bus)やWEBサービスが挙げられていますが、この他に、日本では“電力CALS”も電力会社とメーカーのB2B統合と考えてよいと思います。

「セキュリティに関する考察」に関して

この部分は、原文でもADEで必要とされる一般的なセキュリティ要件を列挙しているだけだったので、特に補足はありません。

 

では、「ADEのフレームワーク」の後半のご紹介に移ります。

なお、全文翻訳ではないことと、例によって、超訳になっている部分があることを予めご了承ください。また、勝手に補足した部分は文字色=緑にしています。

 

4. ADEソリューション設計における考慮点

ADEソリューション設計における考慮点

ADEソリューションは、将来のスマートグリッド機能として必要なデータを考慮しておくことも大切だが、まず、エネルギー消費量と価格といったコアな消費者データを提供するという基本的な要件を満たさなければならない。
また、ADEは、電力会社とTPSP(Third Party Service Provider:消費者データなどをベースに何らかのサービスを提供する第三者企業)の(異機種の)システムのB2B統合を実現しなければならないので、オープンで相互運用性・スケーラビリティを備えた、標準に基づいたソリューションでなければならない。
下図はスマートグリッドにおけるADEのポジショニングを示したものである。


図の拡大

電力会社から見ると、
• ADEは、AMIを経由して収集したデータを顧客および料金表/市場価格/請求データと結びつけ、それを一日単位で外部に提供する手段を提供するものと捉えることができる。 それは、いわゆるデータウェアハウスのようなものであり、毎日更新されるAMIメーター・データ・ウェアハウスと考えることができる。
• また、顧客と電力消費データの集積場所として機能するので、ADEデータ・サーバーと捉えることもできる。
• どこからどのような間隔で消費者データのアクセスを行うか、TPSPの持つADE要件に基づいた、なるべくシンプルな実装とすることが望ましい。
• 取り扱うデータ形式(XSD)と情報モデルには、業界標準が利用可能である。すなわち、ADE情報モデルとしてIEC TC57の CIM、XSDにはIEC TC57 WG14 XML NDRがある。
• データファイルの転送では、安全でスケーラブルなSFTPが利用可能である。一定以上のサイズを超えるファイル転送では、SFTPによるデータ転送準備ができたらTPSP側に通知するような、より複雑な仕組みも考えられる。
• それ以上のインタラクションに関しては、サービスを定義・実装することになるが、B2B統合で必要なレベルのセキュリティ、信頼性および監査可能性を備えたWEBサービスがよいと思われる。

TPSPの立場からは、提供するサービスのタイプによって種々の要件が出てくる。
• まず、ADEデータ・サーバーからデータを取り出す基本的なADEインタフェースがある。
• 消費者/電力会社になり代わってエネルギー管理サービスを行うDRアグリゲーターとのシステム統合では、基本的なADEデータ交換以上のサービス・インタフェースが必要となる。なぜなら、消費者のエネルギー管理だけでなく、電力会社との間でエネルギー管理と制御の情報をやり取りするため、電力会社の運用プロセスとの統合が必要だからである。
• 電力小売事業者が存在する州では、基本的なエネルギー使用情報の他に、シナリオ分析に必要なADEデータが求められる。
• 一般市場(消費者)向けのソリューション(たとえば省エネソリューション)を提供しようとするTPSPは、顧客の電力消費データと価格、エネルギー管理オプションとシナリオ分析に必要なADEデータを求める。

問題は、彼らが提供しようというサービスに対して、どれほどリアルタイムでの情報提供が必要とされるか、また、処理を複雑にしないで、(また、膨大なコストをかけないで)いかにそれ(リアルタイムの情報提供)を実現できるかである。

電力会社向けのAMIソリューションには、すでに一般家庭や中小ビジネス顧客のエネルギー使用形態を分析しWEBで表示する機能を備えたものが存在する。消費者は、TPSPおよび電力会社が提供するエネルギー管理機能のどちらを使うか選択権を持つが、どちらのビジネスモデルが消費者に好まれるか現時点では不明である。

消費者の観点からは、次のことが考えられる。
• 商業・産業の大口顧客には、既にDSMとして電力需給逼迫時に需要削減に協力しているところも多いが、AMIの実装は、需要削減プログラムの機能強化になる。
※DSMでは、電力会社から需要を削減するよう電話連絡するなど、人間が介在している事例が多い
• 大口需要家は、今後、電力会社とDSM契約を取り交わす代わりに、新しいDR(デマンドレスポンス)アグリゲーターとのADEインタフェースによる全自動の需要削減が主流になる可能性がある。
• 中小ビジネス顧客の場合も、DRアグリゲーターと契約する可能性があるが、(DRに協力できるほど使用電力に余裕がなければ)他のTPSPが提供するEMSツールを使ってエネルギー消費を管理・制御することが考えられる。
• 一般家庭では、将来、IHD(In-Home Display:宅内表示装置)がスマートメーターおよびスマート家電へのゲートウェイ/コントローラーとなり、WEBブラウザーを立ち上げなくても、消費者のエネルギー管理には十分な情報提供および制御機能を果たす可能性がある。ただし、アカウント情報をアクセスしたり、エネルギーの使い方のシナリオ分析などを実行したりするためには、WEBブラウザーを使用すると思われる。

ADEソリューション設計における考慮点

ADE情報モデル

次の図は、ADEに関連するCIM情報モデルで、オーソライゼーションを除いて、ADEサービスに必要なデータ要素をカバーしている。


図の拡大

ADE統合サービスのユースケース・ダイアグラム

次図は、ADEが提供する3つの統合サービス、および電力会社(Utility)とTPSP(3rd Party)がそれをどのように使用するかを示している。


図の拡大

顧客の管理とオーソライゼーション

このサービスは、TPSPが保持する消費者のIDと、電力会社が保持する消費者のIDを対応付けし、TPSPに消費者データのアクセスを認可するものである。以降、TPSPは、自分が保持する消費者IDを用いて、各消費者に関して、ADEシステムと対話することができるようになる。

ここで2つのオプションがある。

1) 消費者が、最初TPSPに消費者データへのアクセスを認可するケース


図の拡大

2) 消費者が、最初に電力会社に消費者データへのアクセスを認可する


図の拡大

いずれの場合も、消費者が「他方」のシステム上でまだ登録されていなければ、まずアカウントを作成する必要がある。
また、図には示さないが、もう1つの「顧客の管理とオーソライゼーション」のシナリオとして、TPSPが個人の消費者データを受け取れないよう、関連を断ち切る処理がある。

消費者データの提供

このサービスは、電力会社が、ADEシステムで管理している消費者データ(電力消費データ)の追加、更新、削除するためのものである。さらに、データの変更をTPSPに通知するので、TPSPは、そのデータを取得することができる。


図の拡大

TPSPからのデータ取得要求には、HTTPSよりFTPSが使用されるだろう。
なお、TPSPは、前日のデータを要求することもできる。
また、毎日定常的に行われる消費者データ追加の他に、(AMI側の計測エラーの事後訂正など)にもこのサービスが使われるだろう。

以上、「ADEのフレームワーク」をご紹介しました。

「A Framework for Automated Data Exchange (ADE)」は2009年5月26日に作成されたものですが、OpenSGのOpenADE-TFでは、これをたたき台として、2010年2月19日、OpenADE1.0の要求仕様書を完成させ、現在はOpenADE2.0が議論されているようです。
OpenADEをご紹介するにあたって、OpenADE1.0から入ることもできたのですが、まずは、「ADEのフレームワーク」をご紹介した方が、ADEの意味・意義を把握していただきやすいのではないかと考え、このような形をとりました。

スマートグリッドのとらえ方はいろいろありますが、技術的な側面ではなく、スマートグリッドがもたらす恩恵に注目した、フーバーダム建設以来の電力に関係した大規模雇用創出ツールであるというとらえ方があります。再生可能エネルギー関連のビジネスがその1つ。もう1つは、従来料金計算にのみ使われていた消費者データを用いたTPSPによる新規ビジネスです。新規ビジネスとして、「ADEのフレームワーク」では、
• 消費者/電力会社に代わってエネルギー管理サービスを行うDRアグリゲーター
• 一般市場(消費者)向けのソリューションを提供するTPSP
などが挙げられていますが、TPSPとして、単にグロスの消費電力だけではなく、部屋別、家電機器別などのデータがわかれば、いろいろなビジネスインテリジェンス(BI)系のサービスが考えられそうです。
BIのサービスを提供するTPSPにとって、ADEは、分析に必要なデータを吸い上げるETL(Extract Transformation and Load)ツールと捉えることができます。
※そして、リアルタイムでの消費データを提供するかどうかの結論は出されていませんでしたが、そこまでできるようになれば、ADEが電力系のリアルタイムBI(参考)のインフラとなり、さらに広範な新規ビジネスが出てくるものと考えられます。

次回は、(少し時間をいただくかもしれませんが)、OpenADE1.0のご紹介に入ろうと思います。

終わり