スマートグリッド

東京電力の仕様見直しと「新プロトコル群」「デマンドレスポンス」 ─後編─

─スマートメーター「入札延期」の真相と新戦略─

2012/12/01

(土)

SmartGridニューズレター編集部

【インプレスSmartGridニューズレター 2012年12月号掲載記事】前編（2012 年11 月号：創刊号）では、東京電力（以下、東電）を支援する原子力損害賠償支援機構（以下、原賠支援機構）参与の1 人として活躍されている、東京大学大学院情報理工学系研究科教授　浅見徹（あさみとおる）氏に、東電のスマートメーターの入札延期の真相から今後の戦略について、とくに原賠支援機構参与によって作成され電力業界のオープン化を拓いた歴史的提言から、心臓部となるスマートメーター網（AMI）の技術やその通信方式を中心にお聞きし紹介した。後編では、東電の具体的な仕様見直しの内容と新プロトコル群、ZigBee IP、デマンドレスポンスなどを中心に紹介する。

第1部　仕様見直しの真相と新プロトコル群の検討

◆真相：482件（RFC）の分析と3つの資料の公表

Asami Tohru

─前編では、東電のスマートメーターに関する仕様や戦略が大局的に理解できました。ところで、ここに至るまで、内外の多くの企業からのスマートメーターの仕様に対する幅広い意見募集（RFC）^注1が行われたとのことですが、その状況はいかがだったのでしょうか。

浅見：前編でお話ししたように、東電と原賠支援機構では、導入を予定しているスマートメーターの東電仕様をゼロベースで見直し、必要に応じて改善することを目的として意見募集を実施しました。これは、

（1）計器RFCとして、計量部の仕様に関する意見募集（2012年3月13日〜4月13日）を実施

（2）通信RFCとして、通信機能基本仕様等に関する意見募集（2012年3月21日〜4月20日）を実施

（3）この内容を分析し、アドバイスし、提言をまとめるため、5名の委員を2012年4月9日に「東京電力のスマートメーター仕様検討に係る参与（アドバイザー）」として任命^注2

の手順で、考え方や提言がまとめられました。

この意見募集（RFC）には、合計で延べ88の企業や団体、個人の方々から482件の意見を受け付けました^注3。このような経緯を踏まえて、2012年7月12日に、次の3つの資料が公表^注4されたのです。

（1）通信RFCの結果（東京電力）

（2）RFCを踏まえたスマートメーター仕様の基本的な考え方（東京電力）

（3）機構参与による「東京電力のスマートメーターの仕様に関する提言」（原子力損害賠償支援機構）

─かなり多くの応募があったのですね。

浅見：はい。今回のRFC（意見募集）では、計器RFC（メーター本体部分の意見：160件）と通信RFC（通信部分の意見：322件）では、通信のほうがはるかに多くのコメントがきたというのが実態です。通信部分では国際標準的な仕様や、PLC、無線マルチホップなどについて広範なコメントが返ってきました。

3つの視座を設定して新たな考え方を打ち出す

浅見：このRFCの結果を踏まえて仕様の見直しを行うにあたり、次の3つの視座を設定し、RFCにおける主な意見に対する新たな考え方が打ち出されました。

■視座① 徹底したコストカットの実現

他事業者のインフラの活用し、国内外からの入札を行い、オープンな通信プロトコルの仕様とすること。

■視座② 外部接続性の担保

サービス提供事業者が、メーターデータに容易にアクセスできること、セキュリティを確保すること。

■視座③ 技術的拡張可能性の担保

将来のサービスに備えた技術的な拡張可能性の確保、多様な通信インフラを適材適所に活用できること。

この中で、とくに今後、エネルギー関連サービスを提供しようとするいろいろな事業者や、一般家庭においてメーターデータを有効に利用する視点やコスト抑制の観点から、

（1）オープンな国際標準のインタフェースを採用する。

（2）Aルートは基本的にIPで通信できるようにする（IPの実装）。

（3）やり取りする情報の形式は、例えばオープンな国際標準のデータフォーマットを採用する。

ことなどが決められています。

─Aルートは基本的にIPで通信することが決められたのですね。

浅見：そうです。Aルートの通信プロトコルは次のような構成となりました（図1）。

（1）上位層：データフォーマット／データ送受信手順等

（2）中間層：TCP・UDP/IP

（3）下位層：各通信方式ごとの仕様

図1 スマートメーター網（AMI、Aルート）における通信プロトコルの構成

〔出所　東京電力「RFCを踏まえたスマートメーター仕様に関する基本的な考え方」、平成24（2012）年7月12日、http://www.tepco.co.jp/cc/press/betu12_j/images/120712j0101.pdf〕

図1のように、原則としてIPを実装することによって、下位の通信仕様部分（無線の各種方式等）と、上位のデータ送受手順方式^注5との分離が容易になり、将来的な変更や機能拡張に柔軟に対応することができるようになっています。

▼ 注1
RFC：Request for Comment。コメントを求む（意見募集ということ）。この「RFC」という名称はIETF（インターネット技術標準委員会）の標準技術文書として有名で、2012年11月15日現在、RFCは6791個になっている。例えばIPで有名な「RFC 791：Internet Protocol」などが発行され、広く使用されている。東電のRFCの‘C’は、「Comments」（IETF）と複数ではなく「Comment」と単数の表現であることに注意。

▼ 注2
2012年11月号（創刊号）掲載の前編（13ページ）の表2を参照。

▼ 注3
東京電力「RFCを踏まえたスマートメーター仕様に関する基本的な考え方」、平成24（2012）年7月12日
http://www.tepco.co.jp/cc/press/betu12_j/images/120712j0101.pdf

▼ 注4
http://www.tepco.co.jp/corporateinfo/procure/rfc/repl/rfc-com_re-j.html#tenpu1

▼ 注5
IECやANSI標準のメーターデータに関するフォーマットや送受信手順規格等。