デマンドレスポンス－その５

－　OpenADR　－

© Copyright William Metcalfe and licensed for reuse under this Creative Commons Licence.

前回は、2003年から2007年まで、米国カリフォルニア州でデマンドレスポンス研究所（DRRC：Demand Response Research Center）が中心となって進めてきたデマンドレスポンス（以降、DRと略）の発展と商用化の流れを追い、自動デマンドレスポンスのインフラが出来上がるまでを見てきました。ご紹介した資料『Design and Implementation of an Open, Interoperable Automated Demand Response Infrastructure：オープンで相互運用可能な自動デマンドレスポンス・インフラの設計と実装』の最後の章「次のステップと今後の方向性」で、「今後DRを普及させるためには、一般家庭だけでなく商業ビルの需要制御も有望で、そのための通信とDRシグナル・システムの標準化、更には、ADRを視野に入れた建築基準・標準の整備（原文）」を行うことが示唆されていました。そこで、今回はDRの標準化に焦点を当て、OpenADRとしての、DRのその後の発展を見てみたいと思います。

では、はじめます。　なお、文中の文字色＝青の部分は原文、緑の部分はコメントです。

DRRCによるADR技術開発の足跡

以下は、DRRCが所属する米国ローレンスバークレイ国立研究所（LBNR）の2009年4月の資料『OpenADR Technology Demonstration in the Northwest』の中にあった、DRRCによるADR技術開発の足跡です。

DRRCは、2002年からDRに関するリサーチを開始し、以下のとおり、ADRの設計･開発・フィールドテストを進めてきました。

• 2003年からADRのフィールドテストを開始
• 毎年テスト内容に応じたADRサーバ（DRAS：DR Automation Server）の開発を行っていますが、2005年からは、ベンチャー企業のAkuacom社（2010年5月、ハネウエル社が買収）が開発したADRサーバを採用
• 同じく、2005年から電力会社と共同でのテストとなった（2005年はPG&E：Pacific Gas and Electric Company、2006年はPG&EとSDG&E：San Diego Gas & Electric、2007年からはSCE：Southern California Edisonも加わり、カリフォルニア州の3大電力会社すべてが参加）
• 2007年、フィールドテストがカリフォルニア州大に広がり、テストサイト数も１桁多くなって、商用化に向けて発展
• 2009年には、北西隣のワシントン州シアトル（Bonneville Power Administration/ Seattle City Light）にもフィールドテストが広がり、
• 同じく2009年に、PG&E社と共同で、DRが生み出す電力削減量を発電所の発電量に見立ててカリフォルニア州の卸売電力取引市場（一日前市場）で売買するリアルタイム市場に利用する試み（PLP：Participating Load Pilot）を実施

OpenADRとは

DRRCの資料『Open Automated Demand Response (OpenADR) Communication Specification』によると、DRRCは2007-2008年のADRフィールドテストで使われた技術（WEBサービスを用いてDRシグナルの授受を行うことで、需要家側のエネルギー管理制御システムに依存しないオープンで相互運用可能な通信の仕様）をドキュメント化し、2009年4月、『OPEN AUTOMATED DEMAND RESPONSE COMMUNICATIONS SPECIFICATION (Version 1.0)』として、LBNRとAkuacomの連名でカリフォルニア州エネルギー委員会（CEC：California Energy Commission）に提出しています。

※ この仕様書の表紙に、ADRフィールドテストに参加したPG&E、SDG&E、SCEといった並み居る大企業を差し置き、ベンチャー企業であるAkuacomの社名が米国ローレンスバークレイ国立研究所名と併記されているところから、ADRサーバの設計・実装からテストまで、Akuacom社が相当重要な役割を果たしたことが窺えます。
参考：仕様書の表紙

この仕様書は、本文120ページ、全214ページの大作で、とてもすべてをご紹介できません（自分でもまだ読み通せていません）。
目次構成は以下のとおりで、6章：通信仕様本体、7章：機能仕様、8章：データモデルとスキーマの詳細、9章：API仕様となっています。また、Appendix A、Bからは、実際に利用できるXSDスキーマファイルやWSDLインタフェースファイルへのハイパーリンクが張られており、「通信仕様書」兼「開発成果物報告書」の様相を呈しています。

Abstract
Executive Summary
Patents
Participants Technical Advisory Group
1.0 Introduction
2.0 Scope
3.0 Normative References
4.0 Use of This Specification
5.0 Demand Response Automation Server Requirements
6.0 Specifications
7.0 Functional Specifications
8.0 Detailed Data Models and Schemas
9.0 Detailed Application Programming Interface Specifications
10.0 Security Policy
11.0 Future Developments
12.0 Definitions, Acronyms and Abbreviations
Appendix A: XSD Schema Files
Appendix B: WSDL Interface Files
Appendix C: Security Analysis and Requirements
Appendix D: DR Program Use Cases

OpenADRの定義に相当する部分をまとめると、以下のとおりです。

• OpenADRは、電力会社またはISOと需要家の間でDRシグナルを授受するための通信データモデルである
• DRシグナルには、「電力価格シグナル」、「系統信頼性シグナル」、および「DR対策（電力需要削減策）起動シグナル」がある
• OpenADRは、（DRシグナルの内容によって自動的に実施する電力需要削減策を予め設定しておけるような）ビル・工場施設などのエネルギー管理・制御システム（BEMS、FEMS相当）と対話し、人手を介さずに全自動でDRイベントに対応すること（すなわち、系統電力の需要逼迫時に自動的に電力需要を削減するためのM2Mインフラ構築）を目的としている
• OpenADRの通信仕様は公開するので、誰でもその仕様に基づいて、OpenADRに準拠したADRサーバおよび、ADRクライアントを実装することができる（電力会社あるいは、TenDril､EnerNOCのようなパワーアグリゲーターが、自社顧客にDRサービスを提供するために自前のADRサーバを開発したり、ビルやプラント管理システムのメーカーが、自社製品を自分でOpenADR準拠のクライアントとしたりすることができる）

大体のイメージとしては、下図の情報モデルの通信仕様と捉えればよいと思います。

また、OpenADRに基づいたシステム構成例は、以下のような感じになります。

図の拡大
出典：http://www.psc.utah.gov/utilities/misc/08docs/0899905/SmartGridWorkshopPresentations/Levy_Roger-UtahSmartGridPresentationVersion-050809.ppt

OpenADRは、基本的に商業／産業顧客のBEMS/FEMSとDRシグナル授受を行うことになりますが、上図のように、DRシグナル受信時の対応を事前設定でき、かつFM放送などから直接DRシグナルを受信できるスマート家電機器や、TenDrilのような一般家庭向けにDRサービスを提供するアグリゲーターを経由すれば、一般家庭や低圧顧客の家電機器もOpenADRの世界に加わることができます。
例えば、2009年1月、TenDril社は、自社のDRサービスソリューションをOpenADRに準拠したプラットフォームに改造したとアナウンスしています。

これ以上OpenADR通信仕様version1.0の内容に立ち入ると長くなるので、ここでは2009年4月この通信仕様が発表された以降のOpenADRの経緯を追うことにします。

OpenADRのその後

OpenADRは、オープンスタンダードを目指してはいるものの、あくまでカリフォルニア州とシアトルなどその周辺で採用されてきたものです。

• 電力価格のデータ交換や、DRシグナル授受に関するデータモデルとしては、先行する国際標準であるIEC61968/CIMがありますが、それらとの整合性はあるのか？
• また、一方では、今をときめくZigBeeアライアンスが策定したSmart Energy Profileでも、デマンドレスポンスが考慮されていますが、それとOpenADRとは相容れあうのか？

オープンスタンダードを目指すならば、ここは避けて通れません。

2009年8月25日付けのOASISニュースによると、国際オープン標準コンソーシアムOASISは、ダイナミックな価格設定、信頼性、および緊急信号の交換向けにWebサービス・ベースの情報および通信モデルを開発するべく、新たにOASISエネルギー相互運用技術委員会（OASIS Energy Interoperation Technical Committee）を発足させています。
この新規OASIS委員会はLawrence Berkeley 国立研究所の 需要応答研究センター(DRRC)より寄付されたthe Open Automated Demand Response Communication Standards (OpenADR)に基づきその活動作業を進める－　ということで、OpenADRの強力な支持団体が現れました。

そして、極め付きが2009年9月、米国国立標準技術研究所（NIST）が公開した『NIST Framework and Roadmap for Smart Grid Interoperability Standards Release 1.0 (Draft)』です。
スマートグリッドに関連する既存標準規格の1つ（34ページ、項番１４）としてOpenADRが選ばれたばかりか、NISTによるスマートグリッド標準化に関する優先行動計画（PAP：Priority Action Plan）の対象（NIST PAP 09：Standard DR and DER Signals）となりました。

これを受け、UCAIugの中にOpenADRタスクフォースが組織されて、10社20名以上の専門家が、OpenADR通信仕様version1.0をベースに半年以上をかけて、『OpenADR 1.0 System Requirements Specification』（以降、OpenADR SRSと略）にまとめ上げました。
※UCAIug（UCA International Users Group）は、46カ国155社の電力会社・機器ベンダ等で構成され、公益企業の通信アーキテクチャ（UCA：Utility Communication Architecture）を検討する国際ユーザー・グループ

2010年10月19日付けのRedOrbitNews「UCAIug Releases Open Automated Demand Response (OpenADR) System Requirements Specification」によると、OpenADR SRSでは、相互運用性を確保すべく、CIM、SEPを考慮しつつ、DRサービスを実施する上で必要な関連システム／機器間のDRメッセージの授受／データ交換の機能要件が定義されています。また、DR関連シグナルだけでなく、DER（分散電源）も同時に扱う要求仕様になっています。
本要件仕様書は、全文63ページ。目次構成は以下のとおりです。

1 Introduction
1.1 Purpose
1.2 Scope
1.2.1 Scope of This Release
1.2.2 Scope of Subsequent Releases
1.3 Acronyms and Abbreviations
1.4 External Considerations and References
1.4.1 RFC 2119 Keyword interpretation
1.5 Document Overview
2 Architecture Vision
2.1 Architectural Goals and Guiding Principles
2.2 Architectural Considerations
3 OpenADR Systems Architecture
3.1 OpenADR Business Architecture View
3.2 Integration Requirements Specification
3.2.1 Functional Requirements – Business Processes
3.2.2 Functional Requirements – Integration Services
3.2.3 Technical Requirements – Integration Services
3.3 OpenADR Application Architecture View
3.4 OpenADR Data Architecture View
3.4.1 Temporal Model of a DR Event
3.4.2 DR Event – Data Requirements
3.4.3 Notify DR Event – Data Requirements
3.4.4 Asset / Resource Status (State) – Data Requirements
3.4.5 DR Resource – Data Requirements
3.4.6 DR Asset – Data Requirements
3.4.7 Demand Response Customer Enrollment – Data Requirements
3.5 OpenADR Technical Architecture View
3.5.1 Networking Standards
3.5.2 Security Standards
3.5.3 Service / Resource Patterns
3.6 Governance
4 Appendices
4.1 Terms and Definitions

以上、今回は、OpenADRの歴史を紐解きました。

最後、唐突に終わってしまいましたが、まだOpenADR SRSには目が通せていませんので、今回は、ADRから現在のOpenADRへ至る流れのご紹介にとどめ、できれば、次回OpenADR SRSをご紹介をしたいと思います。

終わり