OpenADE　―その６

OpenADE1.0 － その1 

© Copyright Andrew Hill and licensed for reuse under this Creative Commons Licence.

いよいよOpenADE1.0のご紹介です。

OpenADE 1.0 System Requirements Specification （以降、SRSと略）の改定履歴（Document History）を見ると、
• Rev0.1：2009/10/16　著者：Steve Van Ausdall、初版　SRSの構造定義
• Rev0.2：2009/10/29　著者：Steve Van Ausdall、データ要素追加
• Rev0.4：2010/01/20 著者：Steve Van Ausdall、Arthur Salwinのコメント反映
• Rev0.5：2010/02/02　著者：Steve Van Ausdall、OpenADE-TFレビュー版
• Rev0.6：2010/02/04　著者：OpenADE-TF、OpenADE-TFレビューコメント反映版
• Rev0.7：2010/02/15　著者：OpenADE-TF、ログイン方法に関する仕様記述の削除、FTPオプション・SLAとの関係性の明確化、監査に関する要求レベルの低減、その他補足訂正
• Rev1.0：2010/02/19　著者：OpenADE-TF、（Rev0.7の）変更・削除コメントなどの承認と、残された課題の記述（Open Issue Log）
となっています。
なお、Rev0.5までの作成を手掛けているSteve Van Ausdall氏は、SNSの１つであるLinkedIn情報によると、Xtensible Solutionsというコンサル会社の社員であるとともに、電力会社のSCE（Southern California Edison）の契約社員のようです。

SRS作成に貢献した顔ぶれ（SRSのAcknowledgements）は、Steve氏を含め、SCEからの3名、PG&E（Pacific Gas & Electric）からの2名、SDG&E（San Diego Gas & Electric）からの1名、計6名がカリフォルニア州にある電力会社からOpenADE-TFに参加しています。その他の電力会社としては、OncorおよびReliant Energy（テキサス州）4名、FP&L（フロリダ州）1名、Citizens Utility Board（イリノイ州）1名、Consumers Energy（インディアナ州）1名で、TFメンバー29名中13名が電力会社からの参加となっています。あとは、AMI・スマートグリッド関連の会社（Silver Spring Networks、E:SO、Tendril Networks、Comverge、Ecologic Analytics、IntellEnergyUtil、Sensus）7名、IT関連会社（Noblis、Microsoft、Google、Saker Systems）4名、コンサル会社（Sonoma Innovation、CIMple Integrations、Xtensible Solutions）3名、研究所（EPRI：Electric Power Research Institute）1名、その他、消費者団体のUtility Consumer’s Action Networkからも1名参加しています。

以上のメンバー構成を見てもわかる通り、OpenADE-TFは、電力業界主導の「業界標準」作りのタスクフォースであることがわかります。
また、OpenADE-TFには、SRS作成担当のチームの他に、ユースケースチームとサービス定義チームがあり、「OpenADE 1.0」と題された成果物をネットで探したところ、SRSの他に、以下のドキュメントが見つかりました。
• OpenADE 1.0 Service Definition – Core Draft v0.8
• OpenADE 1.0 Service Definition – Common v0.97
• OpenADE 1.0 Service Definition – REST Extension Draft v0.93
• OpenADE 1.0 Service Definition – Web Service Extension Draft v0.9
※これらのサービス定義書の中にユースケースチームの成果も入っているようです。

具体的な中身の紹介に入る前に、SRSで使われている用語の定義（Acronyms and Abbreviations）を見ておきます。
• ADE：Automatic Data Exchange
• AMI：Advanced Metering Infrastructure
• CIM：IEC TC57 Common Information Model
• EMS：Energy Management System
• ESI：Energy System Interface; Energy Services Interface
• HAN：Home Area Network
• IETF：Internet Engineering Task Force
• IHD：In-Home Display
• PHEV：Plug-In Hybrid Electric Vehicle
• SDO：Standards Development Organization
• SEP 2.0：Smart Energy Profile
• SLA：Service Level Agreement
• SRS：System Requirements Specification
• TOGAF：The Open Group Architecture Framework
※ほとんどの用語は、一度は本ブログのどこかで出てきていますが、初出のものだけ、参考となるサイトへのリンクを張ってあります。

最後のTOGAFですが、上記のハイパーリンク先であるオープン・グループ・ジャパンのホームページによると、

•TOGAFでは最初に、エンタープライズのゴールや戦略、ビジネス・ドライバを識別し、経営者層の指導力と参画を得てITシステムの課題・要求事項を踏まえてITシステムのあるべき姿を策定し、そのゴールに向けてITシステムを実装・開発・運用・管理して行く
•TOGAFは今や、すべてのエンタープライズに求められているITアーキテクチャー策定のための手法（エンタープライズ・アーキテクチャー・フレームワーク）のグローバル標準

とのことです。

出典：オープン・グループ・ジャパン

図．１　TOGAFの特徴

本SRSでも、TOGAFに則り、OpenADEとしてあるべきITアーキテクチャーを導出しようとしています。具体的には、上図中のA～Dの順でSRSが構成されています。

Ａ．　アーキテクチャー・ビジョン

Ｂ～Ｄのアーキテクチャーを矛盾なく開発できるフレームワークとなるようなビジョン（ガイドライン、アーキテクチャー上の考慮点、OpenADE参照モデル等）の定義

Ｂ．　ビジネス・アーキテクチャー

この部分は、基本的に、OpenADE-TFのユースケースチーム、およびサービス定義チームが並行して作成している、機能レベルでのユースケース図、統合要求仕様およびサービス定義に関する成果物を参照

Ｃ．　情報システム・アーキテクチャー

データ・アーキテクチャー：すべての統合サービスにわたって、意味的なレベルで一貫して相互運用性を保証するためには、どのようにOpenADEのデータをモデル化すべきかに関する技術レベルの要件の洗い出し
アプリケーション・アーキテクチャー:アプリケーションを論理的なコンポーネントとしてどのようにモデル化するかと、個々の論理的なコンポーネントがどのようなサービスを提供／利用するかに関する技術レベルの要件の洗い出し

Ｄ．　テクノロジー・アーキテクチャー

エンドツーエンドのAMIビジネスプロセスを支援するため、サービス同士がどのように対話すべきかに関する技術レベルの要件の洗い出し

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

目的

本書の目的は、相互運用性を達成するために、メッセージング並びにデータ交換のための“交信規則”の役割を担う機能的・技術的な手引きと、要件を明らかにすることである。

機能要件選定に当たってはビジネスプロセスを、技術要件選定に当たっては、実際のベストプラクティスを参考にし、OpenADEと名づけられた“交信規則”に従う限り、異なるベンダーの製品・ソリューションで構成された複合システムがうまく機能する理想的なアーキテクチャーを導出する。また、そのように機能するためのオープンで相互運用可能なコンポーネントの振る舞いを明らかにする。

スコープ

OpenADE 1.0 SRSが規定するのは、顧客の消費情報提供の認可と、その情報の転送の仕方についてである。将来のバージョンでは、その他に、価格や請求関連情報提供を含む可能性がある。
多くの電力会社とTPSP（第三者サービスプロバイダー企業）が異なるシステム実装を行っていても、相互運用が可能となるようなインターフェースを明らかにするために、OpenADEの論理的なコンポーネントとビジネス機能を定義するが、策定に当たっては、情報モデルその他の仕様を含め、電力業界のベストプラクティス、標準並びにユースケースを用いた。

図．２　OpenADEのアクターとコンポーネント  図の拡大

ただし、通常ソリューション・アーキテクチャーの一部を構成する以下の４つのアイテムはカバーしていない。それは、OpenSGの他のイニシアチブで取り上げられているか、あるいは、実装の仕方にかかわるようなものだからである。
• ネットワーク･およびハードウェアのインフラ・アーキテクチャー
• 運用上のアーキテクチャー
• テストに関する方法論とアーキテクチャー
• 内部的なアプリケーション・アーキテクチャー

OpenADEのアーキテクチャー・ビジョン

次図は、OpenADEの主要ステイクホルダーを表している。
この図で明らかなように、OpenADEの問題は、データ交換に当たって、当事者である3者（電力会社、消費者、TPSP）の間での承認が必要であり、電力会社とTPSPの間で多対多（many-to-many ）のデータ転送を取り扱わなければならない点である。

図．３　OpenADEのステイクホルダー

OpenADEアーキテクチャーの目標と指針

以下は、OpenADEにかかわるステイクホルダーと議論し、合意に至ったOpenADEアーキテクチャーの目標と指針である。

１） 企業をまたがるデータ交換に関する指針

• 業界のベストプラクティスに従うこと
• さまざまな開発・運用プラットフォームで使えるように、もっとも相互運用性が高く、広く採用されている技術を使用すること
• 採用する技術は、キッチリ規定されたもので、その技術の利用に関連した活動的なコミュニティー（例：WS-I：http://www.ws-i.org/）やツール（例：GDataスタイルのAtomPubをサポートする「AtomServer」：http://www.moongift.jp/r/2008/07/atomserver/）、フレームワーク（例：RESTful Webサービス開発フレームワーク：http://www.syboos.jp/oss/doc/jersey.html）が利用可能であること
• 採用する技術は、HEMS等、HAN資源へのアクセスのために規定された技術と互換性をもち相互運用可能であること
• 公衆通信網が使われる可能性が高く。取り扱い上注意を要する顧客情報が企業をまたがって交換されるかもしれないので、顧客情報のセキュリティおよびプライバシーに関して十分考慮されていること

２） 相互運用性の促進に関する目標・指針

OpenADEは、数多くの電力会社とTPSPのシステム間での相互運用を可能にしなければならないので、要件定義は明確・規範的で、実施・テスト可能なものでなければならない。

３） 複数の異なるタイプのステイクホルダーの目標を達成するための指針

本SRSの提言に関する議論／ネゴシエーションが可能な、開かれたプロセスが望まれる

４） 新規／旧バージョン互換性に関する指針

今後機能拡張されても、既存の実稼動システムに影響を与ないこと

長くなってきましたので、SRS後半のご紹介は次回行いたいと思います。
また、OpenADE1.0と銘打った成果物には、SRSだけでなく、OpenADE-TFのユースケースチームおよびサービス定義チームで作成されたものが存在し、それらをあわせてOpenADE 1.0 が出来上がっていることがわかりましたので、SRSをご紹介した後、引き続き、これらのチームの成果物も紹介する予定にしています。

 

ところで、つい先日、菅首相が、エネルギー基本計画の抜本的な見直しの話をされていました。
「2020年型日本版スマートグリッドの大枠を、『2020年代の可能な限り早い時期に、＜中略＞原則すべての電源や需要家と双方向通信が可能な世界最先端の次世代型送配電ネットワークを構築』という期限付きのエネルギー基本計画を実現することに重きを置き、貧弱な機能のスマートメーターを設置するよう定めるのはいかがなものか？」と常日頃このブログで言い続けてきた者として、エネルギー基本計画の見直しには大賛成です。

ただ、『この機会に再生可能エネルギーを中心としたスマートグリッドを早めるべき』という最近の世論の高まりは、ここ数年、スマートメーター／スマートグリッドを追い続けてきた者にとって非常にうれしい反面、ある種の違和感を覚えています。

たとえて言うなら、大けがをして早く止血しなければならない患者を前にして、『あなたは成人病予備軍でこのまま放置しておくと大変なことになる。今の食生活を抜本的に変更しましょう』と言っている感じがするのです。

まずは止血（放射能漏れを止める）し、その次に化膿しないような処置（夏のピーク需要対策）。成人病対策の処置は、（もちろん並行して手を付けてもいいですが）順序としては、その後でも良いのではないかと思います。（スマートメーター導入に関しては、実施期限を優先した拙速な解決を図るのではなく、じっくり将来を見据えて対応して欲しいと願っています）

また、原子力関係については門外漢なので、効果的な「止血」に関し、良いアイデアは浮かばないのですが、「化膿止め（この夏のピーク需要対応）」に関しては、1つ考えついたことがあります。

今すぐ原子力発電に代えて太陽光発電・風力発電を増やすこともできないし、ましてやデマンドレスポンスで需要削減するために、あと1、2ヶ月で東京電力管内すべての一般家庭の電力計を、家電機器制御可能なスマートメーターに置き換えるのは現実問題として不可能です。
予備電源のフル稼働と、大口需要家の需給調整契約、それと一般家庭への節電のお願いで、この夏の計画停電は回避できそうだとのことですが、この一般家庭の節電をより確実に実施してもらうため、以下のように電気料金制度を変更すればどうでしょうか？

（原発事故に関連する補償費用捻出も含めて）電気料金を基本料金、従量料金とも現行の3倍にする。
ただし、契約アンペア数を10A小さくするか、6～9月の電力使用量（kWh）が昨年同月比で30%節電できた家庭は、現行の電気料金（基本料金、従量料金）に基づいて電気代を請求する。

3倍、10A、30%というのは、思いつきの極端な数字（風評被害の補償まで含めると、これでも足りない？）ですが、これだと、電力料金計算プログラムを変更するだけで、その他には大きな対策費用が発生せず、この夏の節電対策としてすぐ実施できます。また、節電目標（30％）を達成した家庭は（使用電力量が減るので）電気代が安くなるので、一律に電気料金を値上げするより国民の納得が得られやすいのではないでしょうか。

※これは、系統電力のひっ迫状況に応じて無条件に家電機器の利用／停止を遠隔制御するのではなく、個々の需要家のエネルギー消費志向を踏まえた上で、経済的なインセンティブにより需要抑制を図る第2世代のデマンドレスポンスと同じ考え方です。

エネルギー基本計画を見直すにあたって、今回の大震災を契機とした需要家の節電が続くものと仮定して需要予測をやり直せば、自ずと違った展開が見えてくるのではないでしょうか。

終わり