テクニカルノート（仮）～DER活用の小径（こみち）～
東京大学 生産技術研究所
想定対象＝アグリゲーター／事務系／営業部門従業者
１.はじめに
街を歩いていると屋根の上に太陽光発電装置を設置した家を多く見かけます。また、列車やクルマの車窓からは、大規模な太陽光発電所や大きなプロペラをつけた風力発電所も度々目にします。既に我が国では、年間の電力需要総量の一割以上が太陽光発電や風力発電によって賄われています。これらは再生可能エネルギーといわれ、電力を発電する際に、地球温暖化の原因と言われている二酸化炭素（CO2）を発生しません。各国政府はこのような再生可能エネルギーの利用割合を増やそうと考えています。
一方、太陽光発電や風力発電には短所もあります。それは、人間の社会経済活動に合せて発電をしてくれるというわけではないことです。我が国の電力供給は130年以上の歴史がありますが、一貫して電力供給は使う量に合せて発電する、すなわち電力需要と供給（併せて、電力需給といいます）の一致という仕組みの上に成り立ってきました。しかし、再生可能エネルギーの主役級である太陽光発電や風力発電の発電量は、まさにお天気任せ・風任せで原理的に人間がコントロールできません。このため、これらは特別な呼び名があり、自然変動電源と呼ばれています。使う量に合せて発電するという基本的な構造にあてはまらないこれらを、今後は何とか今までの仕組みの中に納める必要があります。
電力は発電量がコントロールできる火力発電所や水力発電所でも発電されています。部屋のコンセントから出てくる電気は、太陽光発電や風力発電に加え、火力発電所や水力発電所からの電気が混ざって出てきます。電力供給は使う量に合せて発電する必要があるのなら、太陽光発電や風力発電の発電量が増えてしまった場合、火力発電所や水力発電所の発電量を絞ることで、全体的には使う量に合せるという仕組みで自然変動電源の増加に対応してきました（図－０上図）。
|
|||
|
図－０ 需給バランス制御方法
しかし、その方法も限界に近づいてきています。理由は火力発電所や水力発電所の対応能力には限りがあるからです。一方、脱炭素社会を構築するためにも、自然変動電源の利用割合を増やす必要があります。ではどうしたらいいのでしょうか。
電力は使う量に合せて発電する必要があると申し上げました。発電する量をコントロールできる範囲が限界なら、使う量を変えるという考えもありそうです（図－０下図）。具体的には、自然変動電源の発電量が多すぎるなら電気自動車などのバッテリーに蓄える。一方、雨や曇りで足りないのなら、使う量を減らしたり、貯めておいた電力を放出する、という仕組みを導入するのです。このドキュメントでは、これをDER活用と呼びます。DERについは後で説明します。
使う量を変化させるには電力の利用者の協力が必要です。しかし、利用者自身がスイッチの横に四六時中付いているわけにもいきません。そこで、後ほど説明するアグリゲーターと呼ばれる事業者が、インターネットなど情報通信技術を使って利用者が所有する電力使用機器をON / OFFする仕掛けが必要になります。このような技術をIoT （Internet of Things）と言います。もちろんON /OFFには利用者との契約も必要です。このような仕掛けは今まで一般的にはありませんでした。そのため、この仕掛けの構築を産業的にスムースに進めるには、多くの関係者の理解が必要です。
このドキュメントは、アグリゲーターが電力の利用者と協議しながら、そのような仕掛けを構築するまでを筆者らが行った四つの実験例から必要部分を適宜紹介しながら説明します。
さぁ、DER活用の小径（こみち）を一緒に歩いてみましょう。
２.DER活用の5W1H
この章では、DER活用について、先ずは基礎的な理解をするために5W1Hの枠組みを使って説明します。
WHAT（なにを）
まず、DERとは何なのでしょうか。DERはDistributed Energy Resourcesの略で、日本語では、「分散エネルギー資源」と呼びます。具体例としては、太陽光発電設備、電力の利用者（需要家といいます）に設置される蓄電池設備、今後普及が期待されている電気自動車（EV）の充放電設備、ヒートポンプ式給湯機などがその代表格です。太陽光発電は自然変動電源の一種ですからこのドキュメントでは議論の対象から外します。表－１に代表的なDERの例を、図－１~２に実物例の写真を示します。
表－１ DERの例
| 1 | 発電設備 | 太陽光発電設備／風力発電設備 （再生可能エネルギー） |
| 自家発電設備 | 2 | デマンドレスポンス（DR)・負荷制御 | 工場：電炉／各種生産ライン |
| 事務所：蓄熱式空調設備／送水ポンプ／自動販売機 | ||
| 家庭：ヒートポンプ給湯機 | ||
| 3 | エネルギー貯蔵設備 | 蓄電池 |
| 水素製造装置 | ||
| 4 | 電気自動車充放電設備 | 電気自動車＋充放電設備 |
図－１ ヒートポンプ式給湯機の例
|
図－２ 蓄電池の例
|
図－３ 電気自動車(EV)の例
|
図－４ EV充放電機の例
|
WHEN（いつ）
自然変動電源、中でも太陽光発電は我が国では大変な勢いで増えています（図－５）。第1章で火力発電所による電力需給を一致させる能力（専門的には火力発電の「調整力」といいます）を紹介しましたが、既にそれでは追いつかないタイミングも頻繁に現れています。このため、「出力制御」と呼ばれる制度が施行されており、市中の電力需要に加え、揚水発電所 の動力使用や、他の地域への送電でも使い切れない場合は、太陽光発電や風力発電はその出力を抑制されることとなっています。
2018年以降、東京地域以外では、このような出力制御が頻繁に実施されており、火力発電所の調整力供給は限界に来ていることが判ります。電力の利用者側による需要増加（需要創出といいます）が出来れば、このような出力制御の頻度を低減させることが期待できます。このようにDER活用は喫緊の課題として考えて頂いていいでしょう。
WHERE（どこで）
では、DER活用はどこで行われるのでしょう。インターネットなども使用しますからサイバー空間もその範疇には入りますが、電力の利用者の自宅という現実空間が蓄電池設備、EVの充放電設備、ヒートポンプ給湯機などのDER活用の現場として判り易いイメージです。これらは法人が所有する場合もありますから、法人の事務所や工場なども想定できますね。但し、必ずしも人が傍にいる場所とは限りません。無人の倉庫の空きスペースやDERのために確保した場所などもあり得ます。無人の場所では、何らかの現地作業をするまでに何日も間が空いてしまう可能性もありますから、考慮が必要となりそうです。
WHO（だれが）
第1章では、アグリゲーターと呼ばれる事業者と、DERを設置する電力の利用者の二者を挙げました。インターネットの事業者なども関係するでしょうが、やはりDER活用の主役は、アグリゲーターと、DERを設置する電力の利用者の二者と考えてよさそうです。DERを設置する電力の利用者は、このドキュメントでは、DER所有者と呼ぶことにします。
では、アグリゲーターとは一体どんな事業者なんでしょうか。英語のaggregate（アグリゲート）とは、集める、集約する、という意味ですから、アグリゲーター（aggregator）とは、集める人（事業者）という意味です。では、何を集めるのでしょうか。第1章で、「使う量を変える」と書きました。電力システム全体は巨大ですし、個々のユーザーが使う量は、それに比べれば大変小さなものです。いわんや使う量を変える＝変化量は微々たるものでしょう。しかし、塵も積もれば山となるの諺通り、その変化量を集めれば火力発電所が担っている役割の一部をバトンタッチできそうです。その集める役割を担う事業者をアグリゲーターと言います。
さて、アグリゲーターとDERを設置する電力利用者という二人の主役はどのようにして出会うのでしょう。もっともシンプルなケースは、アグリゲーターの社員が街を歩いていて、DER活用をお願いしたくなるようなDERを見つけるというものです。ただ、そのようなケースはむしろ少数派かもしれません。DER活用も商業活動の一種ですから、代理店とかエージェントという立場の存在も大いにあると考えられます。
その一つのケースは、DER所有者が電力の供給契約を結んだ電力会社自身がアグリゲーターでもあったというスタイルです。供給契約の一部にDER活用が組み込まれているというケースです。
もう一つは、DERメーカーが客先にDERを販売・設置する際に、アグリゲーターの代理店としても振舞うというスタイルです。DERというシナモノを売ると同時に、サービス販売も仲立ちをするというケースですね。この場合、代理店であるDERメーカーはアグリゲーターから成功報酬型の手数料を受け取るというビジネスモデルにすることで商業活動として成り立ちます。
それ以外にも、EPC（Engineering，Procurement，Construction）事業者や、節電コンサルなどを業務とするESCO（Energy Service Company）事業者が、アグリゲーターとDER所有者の仲立ちをするというビジネスモデルも想定されます。その他にも事業者の創意工夫で様々なビジネスモデルが期待されます。先に述べた代表的な想定ビジネスモデルを図－６に示します。
WHY（どんな理由で）
大きな理由は第1章で述べたとおり自然変動電源の増加による電力需給不一致の解消です。需要と供給のギャップの穴埋めと考えてもいいかもしれません。では、電力需給の一致が崩れると何が不都合なのでしょうか。
我が国では歴史的な経緯から東日本が50Hz、西日本が60Hzという周波数で電力が供給されています。この周波数は極力一定であることが必要で、それぞれの周波数を基準として、火力発電所のタービンの回転数や変電所の変圧器の放熱能力などが設計されています。また、電気を沢山使う工場にあるモーターなどには、この周波数に同期して一定速度で回転するものも多くあります。
この電力需給の一致が崩れると、周波数が変動します。需要過多なら周波数が低下、供給過多なら周波数が上がってしまいます。周波数と電力需給の関係は、図－７に示すように上皿天秤を例に説明されます。一定の周波数を基準に設計されている前述の機器類には支障がでることがお分かりいただけますね。工場のモーターの回転数が狂えば、製品にシワが出るなどの不都合が生じる可能性もあります。これは、東京、関西、九州など昔の電力会社の地域単位それぞれで起きていると考えて下さい。
それ以外にも、自然変動電源の過剰発電が町くらいの単位をカバーする変電所や電柱の配電線に、設計とは逆向きの電流を流すことによる支障が心配されるなど、生ずる不都合はいくつかの種類に分類できることが判っています。
第１章では、火力発電所に電力需給を一致させる能力「調整力」の供給能力があると述べました。DER活用も同様の効果がありますから、調整力と呼ぶことができます。では、火力発電による調整力とDER活用による調整力は、だれがどのような優先順位で利用順序を決めるのでしょうか。これについては、まだ議論の最中で確実な決まりはありません。ただ、市場原理、すなわち、安くて良いものから使われる、という基本的な考えは貫かれると考えられます。
HOW（どのように）／HOW MANY（いくつ）
DER活用は、アグリゲーターが契約に基づいてDER所有者のDERをインターネットなど情報通信技術（ICT（Info-Communication Technology）技術）を用いて遠方操作して行います。具体的には、アグリゲーターのコンピューターシステム（RAシステムとよびます）とDERをインターネットや携帯電話網などを使って相互接続し、契約によって双方が了解した範囲でDERをコントロールします。コントロールする内容は、DERのON / OFFであったり、蓄電池やEVの充電電力を増減させたり、ヒートポンプ給湯機の運転計画を変更したりなどです。
アグリゲーターは、東京、関西、九州など各地域全体の需給調整を担う事業者とアグリゲーターとを仲立ちする事業者（アグリゲーション・コーディネーター（AC）といいます）から、電力需要の創出や抑制の要請を受けます。それを自社の顧客のDERを遠方操作することによって満足できるよう要請を配賦する計画（専門的ですが、これをディスパッチ計画といいます）を立てて、これを実行することにより、ACからの要請を満たします。図－８にDER活用に関わる主体の関係図を示します。
あとさきになってしまいましたが、このドキュメントに出てくるアグリゲーターは、正しくはリソース・アグリゲーター（RA）といいます。そのため、彼らのシステムをRAシステムと呼ぶんですね。
もう一つのHOWには、HOW MANY（いくつ）があります。先に火力発電所が担っている調整力の提供をDERに一部担って貰う必要を述べました。火力発電所というのは大変大きな設備で、最大級のものは出力が100万kW（1,000,000kW）くらいあります。一方、DERは法人所有のもの、個人所有のもので規模に幅はあると想定されますが、桁としては一台あたり1kWから10kW程度でしょう。
100万kWの火力発電所出力のうち10%程度を調整力として活用するとすると、1,000,000kW×10%=100,000kW [A]です。10kWのDERの同じく10%程度を調整力とすると、10kW×10%＝1kW [B]となります。[A]と[B]を比べるとなんと100,000（10万）倍です。すなわち、単純計算では100万kWの火力発電所と同等の調整力を10kWのDERで得ようとすると10万台が必要になるということになります。
このような大量のDERを電力システムの状況に合せて能動的にコントロールするのは容易なことではありません。情報通信技術なしでは実現しえないことがお分かりいただけると思います。そして上記の計算は一箇所の火力発電所に関するものです。全国規模でDER活用システムを作ることを想定すると、10万台どころではすまないことも想像頂けると思います。DER活用の第一線を担うアグリゲーターは、僅かな数ではなかなか難しそうですね。そのため、図－８に示すような事業者の階層構造が必要になると想定されているわけです。
なお、DERを速く制御したい時には動くまでの（応動時間）を考慮する必要がありますし、長い時間需要を作るにはある需要の持ち替えが必要になります（付録）。
３.DER活用の小径（こみち）
さて、いよいよ本題に入りましょう。これ以降は、読者であるあなたの立場は、アグリゲーターと仮置きします。そして、DER所有者に直接DER活用を働きかけるいわば第一線の若手営業マンとしましょう。勤務先のアグリゲーターとぜひ契約して欲しいDERを見つけたあなたは、電力の利用者でもあるDER所有者を訪ね、協議をお願いするところからこの小径は始まります。アグリゲーターのRAシステムと意中のDERが無事にICT的に相互接続され、調整力としての役割が期待できる状態になったところがゴールです。
DER所有者と協議し、必要な事項について情報提供頂くにしてもある程度の専門的な知識や、相手に提示する選択肢等は必要です。また、DERのICT接続は今まで随分と手間のかかる仕事として認識されています。しかし、膨大な数が必要なことは先に述べた通りです。協議はなるべく手際よく片付けて、どんどん仕事を進める必要もあります。
あなたの勤務先であるアグリゲーターの事情や、相手先のDERの状況によって協議の内容が変わる場合もあります。このような対処のために、このドキュメントでは、協議のステップ上に「チェックポイント」をいくつか設けました。そこでは「小径」を歩く上で注意が必要な地点です。必要な場合だけを読んで頂ければ結構です。このドキュメントは、極力平易かつ実用的になるように記述内容を削減していますが、より深い理解のために、専門的な内容は巻末に参考として添付しましたので、適宜活用して下さい。
相手との協議を進めるためには、相手とある程度の道筋を共有しながら進める方が信頼感も醸成されるでしょうし、なによりスムースです。何回も同じことをしなくても済むでしょう。そのため、このドキュメントでは、先ず協議のステップを下記のとおり仮説として置きます。この道筋が「DER活用の小径」です。そのイメージを図－９に示します。もちろん、協議は相手のあることですから紆余曲折はつきものです。必ずしもこのドキュメントのようになるとは限りません。一つの例として理解して下さい。
【協議のステップ例（DER活用の小径）】
- (1)相互接続の協議開始
- (ア) 相互接続打診・想定エネルギーサービス概要紹介
- (イ) 秘密保持契約書（以下、NDA）取り交わし
- (ウ) 対象DERの技術情報開示要請
- (2)相互接続詳細仕様の協議
- (ア) 想定エネルギーサービスに必要な情報説明
- (イ) 相互接続をお願いする項目(SoCなど）
- (3)相互接続実務
- (ア) IoT-HUBドライバー製作
- (イ) 相互接続工事
- (4)相互接続確認試験
- (ア) 相互接続確認試験／関係者による合格確認作
- (イ) 相互接続システム運用開始
上記の小径の各ステップを以下に概説しましょう。
(1)相互接続の協議開始
- (ア) 相互接続打診・想定エネルギーサービス概要紹介
- (イ) 秘密保持契約書（以下、NDA）取り交わし
- (ウ) 対象DERの技術情報開示要請
ここでは、あなたはDER所有者をドアノックしたレベルです。ようやく自己紹介が終わったくらいの段階をイメージして下さい。まずあなたは第1章に述べた電力システムの現状などの背景を説明し、相手方に相互接続の協議に乗って欲しい旨を相談します。第1章で述べたとおり、DER活用はアグリゲーターとDER所有者間の契約によって行われます。DER活用の契約もエネルギーサービスの一部を成すものと考えられますので、その契約の概要を示すのが、（ア）の想定エネルギーサービスの概要紹介です。
DER活用に至るには、DERの技術情報を開示してもらう必要もあります。相手が個人であれ法人であれ、DERはその所有者が自らのために設置したものです。それを活用させて欲しい、情報も開示して欲しい、というのですから、相手方の秘密は確実に守る必要があります。そのためには一般的に、秘密保持契約書（Non-Disclosure Agreement／NDA）というものを取り交わします。NDAは、企業であればそのひな形を持っている場合も多いのですが、このドキュメントではそのひな形の一例を用意しましたので活用して下さい（付録）。
NDAの取り交わしが済みましたら、意中のDERの技術情報を開示して下さるようお願いしましょう。とはいえ、そのためにDER所有者に多くの手間が発生するというのは、協議を進めるには支障となる可能性があります。それを回避するためには、既にあるものをできるだけ活用することも一案です。DERを設置する際にメーカーやシステムインテグレーターから納められた資料などがそれにあたります。もちろん、NDA規定の通り、他の目的に使用したり、外部に漏洩させてはいけません。お願いする資料の例を下記に記します。
- i. システム概要図並びに仕様書
- ii. 使用機器類の型式番号並びに取扱い説明書（取説はメーカーのURLでも可）
- iii. DERの通信インターフェイス仕様書（APIリスト、Modbusアドレス表など）
- iv. DER側インジケーター等リスト（写真等でも可）
これらのうち、一つでも足りなければ協議が進まない、というものでもありません。まずは、DERがどんな仕様なのかざっくり教えて頂くことが重要です。
(2)相互接続詳細仕様の協議
- (ア) 想定エネルギーサービスに必要な情報説明
- (イ) 相互接続をお願いする項目(SoCなど）
(1)で頂けた資料は、勤務先のアグリゲーターに持ち帰り、技術部門などと共有して、想定しているエネルギーサービスの対象となり得るかを検討しましょう。もちろん、秘密保持の義務があることを忘れてはなりません。
対象となり得るとなったら、相手方には、改めて想定しているエネルギーサービスを説明して、そのために必要な情報、例えば、蓄電池であるなら、定格容量[kWh]であるとか、SoC[%]（State of Charge／充電率）など、RAシステムとの相互接続を検討するために、アクセスさせて頂きたい情報を提示し、相互接続をお願いしましょう。
ここで、もう一つ気をつけなければならないことがあります。先に述べたとおりDERは、その所有者が何らかの目的をもって自らのために設置したものです。個人であればその人の生活の様子が判ってしまったり、法人であれば事業活動に直結する情報もあるかもしれません。これらはプライバシーや機密情報と呼ぶべきものと考えられます。ですから、当該DERの情報全てにアクセスさせてほしいというのは、控えるべきと考えられます。想定しているエネルギーサービス提供に真に必要不可欠な情報のみを、合理的に説明してアクセスの許諾を頂く必要があります。
(3)相互接続実務
- (ア) IoT-HUBドライバー製作
- (イ) 相互接続工事
(2)までの協議が無事に完了したら、DERのICT的な相互接続の実務に移ることができます。DERのICT接続は、DERが使用している通信プロトコルが何種類もあり、また、同じ通信プロトコルでもDERメーカーによってそのモノづくりポリシーとの兼ね合いから、必ずしも全く同じ動作をするわけでもない、という問題を抱えています。RAシステムを相手先のDERの通信仕様に合わせて改修する、ということも勿論可能です。但し、これはかなりの手間と費用がかかる仕事となりがちです。
もう一つの手は、様々な通信方式に対していわばプロトコルフリーに相互接続を成り立たせる通信サービスを利用することです。このようなサービスを提供している事業者が電気通信事業者であれば、電気通信事業法により通信秘密は侵されませんので、データを盗み見られる危険があるのではないか、という心配は不要です。
このドキュメントでは、このような通信サービスを提供している電気通信事業者を活用することをユースケースとして紹介します。具体的な実務については後述します。なお、RAシステムを直接改修する方法を選ぶ場合は、巻末の技術資料等を活用して、改修仕様を検討して下さい。
(4)相互接続確認試験
- (ア) 相互接続確認試験／関係者による合格確認作
- (イ) 相互接続システム運用開始
(3)のRAシステムとDERの接続が済んだら、いよいよ相互接続確認の試験を行います。基本的な試験内容は、アグリゲーターがDER所有者にアクセスの許諾を要請した情報が正しく取得できているか、ということとなります。これには、RAシステム側で読み取った値とDER本体が表示している値が一致しているかを確認します。また、充電開始などRAシステムから遠方操作する項目はそのとおりの動作をDERがするかを確認します。
これらの項目は、RAシステム側、DER側の両方で同時に行う必要がありますが、当然、この両者は離隔した場所にあるのが普通ですし、試験のためにDERを移設することも非現実的です。これを効率よく実施するには、事前に試験手順書を作りアグリゲーターとDER所有者の両者で共有しておくことと、オンライン会議システムの活用がとても効果的です。RAシステム側、DER側の画面などを共有しながら、関係者が手順書に沿って進めれば、確認試験はさほど難しいものではありません。このドキュメントでは、自由に書き換えて頂くことを想定して、実際の実験で試用した手順書を付録として提供します。
日常的にDER活用を実施するには、アグリゲーターとDER所有者が運用開始に際して「運用申し合わせ書」を締結しておくことが望ましいと考えられます。エネルギーサービス契約書にその条項も含まれていれば、それに沿って実際のDER活用を行いましょう。
次章以下では、実際にありえそうなDER活用のスタイルについて実験した例を見ながら、小径を歩いてみましょう。注意点はチェックポイントとして設定してありますので、実際のお仕事の現場で出会うケースに合いそうな場合に読んでいただければ結構です。
４.相互接続の協議開始
(1) 相互接続打診・想定エネルギーサービス概要紹介
ここでは、太陽光発電が過剰に発電した場合、その余剰分をDERに吸収してもらうエネルギーサービスを想定例とした実験を紹介します。当該エネルギーサービスの概念としては、図－１０のようなものです。また、ここで言う余剰というのは一軒の家の屋根上の太陽光発電がその家の電力需要を上回るというミクロな事象ではなく、図－１１に示すような東京、関西、九州などそれぞれの地域内での余剰分をその地域内に所在する需要家のDERが使用することによって、電力需給を一致させるというマクロな仕組みです。
図－１０ 想定エネルギーサービス概要(1)
|
図－１１ 想定エネルギーサービス概要(2)
|
実験は、DERとして蓄電池と送水ポンプを設置した需要家（この例では企業）に相互接続を打診し、地域での余剰電力を使用してもらうサービス契約を締結するというイメージで行いました。簡単のため、以下では蓄電池についてのみ説明することとします。アグリゲーターであるあなたは、DER所有者にこれらの図を提示してこのサービス概要や再生可能エネルギー利用への貢献など社会的意義を伝え、また、その協力への対価がどのようなものになるかを説明しましょう。但し、対価については個々の事業者が創意工夫する領域であるので、このドキュメントでは省略します。
その結果として、DER所有者からサービス契約締結を検討する旨が得られた場合、(2)のNDA締結に進むこととなります。
(2) 秘密保持契約書（NDA）取り交わし
NDAについては、多くの社会経済活動に於いて一般的に取り交わされていますので、ここでの詳しい説明は省きます。付録のNDAは、DER活用を念頭に置いた文言の使用になっていますので活用して下さい。
(3) 対象DERの技術情報開示要請
多くの場合、DER所有者はそのDERの技術仕様に詳しいわけではありません。DER製造企業や外部の事業者に、システム設計や据付工事をアウトソースしていることが殆どです。DERの納品や据付・調整の際に、様々な書類がDER所有者に納められていることが多いのも事実です。技術情報開示の開示に際しては、これらの書類例を提示を相談してみるのも一案です。また、DERのメーカー・型番・製造番号等は、インターネット検索すると、取扱い説明書や機器仕様などが判る場合が多いですから、とても重要な情報です。
さらに相互接続確認試験の際には、DERの稼働状況を把握することが必要となります。このため、どのような表示が可能なのかDERに備えられたインジケーター等の情報も大切です。了解が得られるなら写真を撮らせて頂くのも良い方法です。図１２－１４に情報の例を示します。
図－１２ DERシステムの納入時書類例
|
図－１３ 機器の取扱い説明書例
|
図－１４ DERの表示パネル例
|
図－１５ DERの銘板の例
|
５.相互接続詳細仕様の協議
(1) 想定エネルギーサービスに必要な情報説明
想定しているエネルギーサービスを契約するには、DERの情報の一部にアクセスする必要があることをDER所有者に説明しましょう。DERへの情報アクセスには、DERの状態をアグリゲーターが取得する「モニタ」と、アグリゲーターがDERを遠方操作する「操作」があります。簡単のため、ここでは「モニタ」に限定した実験例を紹介します。
DER所有者に対して、アクセスを希望する情報の種類について説明しましょう。DERの稼働情報はDER所有者にとってとても機微なものですから、説明に際しては、なぜその情報が必要なのか図表などを使って合理的に説明し、納得して頂く必要があります。実験で使用した説明書面を例として図－１６、１７に示します。
なお、繰り返しになりますが、エネルギーサービス契約に必要な情報を超えてアクセスの許諾を求めないことも大切です。
図－１６ 説明用書類例(1)
|
図－１７ 説明用書類例(2)
|
(2) 相互接続をお願いする項目(SoCなど）
前節で説明した情報へのアクセス許諾をDER所有者に求めます。一般にDERの情報には、定格容量などの仕様の値、SoCや電流値など変動する数字の現在値、ブレーカーの容量など運用上の設定値があります。ここでは、蓄電池のSoCと定格容量等を取得するお願い例を図－１８に示します。この実験で使用した蓄電池は、アグリゲーターに対して定格容量を送信する機能はありませんでしたが、後述する仕組みにより、送信する機能を後付けできる場合もあります。
チェックポイント－１
DERにICT接続する数は２以上（複数）ありますか？
《関係なければ読み飛ばしていただいて結構です》(3) アグリゲーターとDER所有者の２者が一つのDERにICT接続する場合
DERをDER所有者が起居する事務所等から離隔した無人の場所に設置している場合などは、アグリゲーター以外に、そもそものDER所有者もICT接続を必要としている場合があります。この場合、一つのDERに２者がICT接続することとなるため、アグリゲーターとDERが1:1にICT接続する場合とは異なる留意点などが発生します。このような接続形態を、このドキュメントでは「マルチユーザー接続」と呼ぶこととします。
① マルチユーザー接続のサービス例
紹介する実験例は、図－１９に示すように蓄電池の容量をアグリゲーターとDER所有者が分け合って使用する、というユースケースです。例えばアグリゲーターが比較的安価に蓄電池をDER所有者に設置してもらう代わりに、ある程度の容量を専用的に使用させて貰うといったことが想定されます。
② ICT接続に際しての留意事項
この実験例では、アグリゲーターとDERが1:1接続するに伴って、次に示す事柄が留意事項として挙げられました。
(ア) 遠方操作指令の衝突処理
複数のユーザーが関係する以上、遠方操作指令が衝突（極めて短時間に連続する場合を含む）する可能性は否定できないこととなります。これは、DERの稼働をバタつかせるなどの副作用を生じさせる危険性もあり、避けなければなりません。この実験では、対応策の一例として、遠方操作指令を受けてから10秒間は他方の指令を受け付けないという仕組みを相互接続に使用するドライバー（後述）に実装しました。
(イ) 優先操作権限の付与（劣後ユーザーの操作拒否）
DER所有者は文字通り自身でDERを所有する者ですが、アグリゲーターは、契約により何らかの報酬を支払うなどしてDERを借りる立場であると想定されます。契約にもよりますが、直感的には所有者よりも劣後したDER使用権限を有していると解されてもいいでしょう。それを踏まえ、この実験では、アグリゲーターがDERを使用中でも、DER所有者はDERの使用権を奪取、すなわち、指令を上書きできる権限を実装しました。
(ウ) 占有ユーザーの表示
優先ユーザー、劣後ユーザーが存在するにしても、できれば指令が交錯しないに越したことはありません。このような事態を軽減するため、DERが現在どのユーザーに占有されているのかをインディケートする信号を表示する機能をドライバーに実装しました。
(エ) 機微情報のアクセス権限制御
DER所有者はメーカー専用のメンテナンス機能用を除いて、自身の所有するDERの情報全てにアクセスできると理解されます。一方、アグリゲーターはDER所有者にとってはあくまでも他人であり、DER所有者の電力の使い方など企業秘密的な機微情報へのアクセスは禁止されていると考えることが一般的と考えられます。
このため、この実験では、DERがある建物の電力使用状態を示す情報へは、DER所有者のみがアクセスでき、アグリゲーターにはアクセスさせないというアクセス制御機能をドライバーに実装しました。
６.相互接続実務
(1) IoT-HUBドライバー製作
このドキュメントの筆者である東京大学生産技術研究所の研究チームは、2015年頃からのスマートハウス研究の一環として、様々なIoTデバイスをプロトコルフリーに接続するIoT-HUBという技術を開発しました。現在この技術は東大との産学連携先である民間企業によって電気通信法に於ける通信事業として社会実装されており、一般の方々が使用できる状態になっています。
図－２０ プロトコルフリー接続の原理
|
図－２１ 接続スタイルのバリエーション
|
IoT-HUBの詳細は巻末の参考に添付しますが、ごく簡単に言えば、対象となるIoTデバイスの通信プロトコルに合せた“ドライバー”と呼ぶ小さなソフトウェアを背中合わせにして、事実上のプロトコルフリーを実現するものです（図－２０／２１）。
DERが使用している通信プロトコルにもいくつもの種類があることは述べました。まさしくIoT-HUBが想定している状態ですので、DER活用にもIoT-HUBの利用は可能です。
DERが使用している通信方式の代表例を以下に示します。
① IPプロトコルによるEthernet（イーサネット）
② RS-485などのシリアル通信（Modbus RTU））
③ インターネット上にあるサーバーに対する通信（クラウド））
④ 携帯電話などの通信事業者閉域網（LPWA））
また、DERの通信プロトコルにEchonet Liteという名前を聞くことが多いと思います。これは一種の言語と理解すると分かり易いでしょう。多くの場合、①のイーサネットという情報運搬手段を使用して、このEchonet Liteという言葉を運んでDERを遠方操作などするものです。
チェックポイント－2
EV充電などのように、複数のDERによって一つの仕事が成立するケースはありませんか？
《関係なければ読み飛ばしていただいて結構です》(2) 複数のDERによるDER活用のケース
今後、電力システムとの連携が期待されるEVの充電などでは、充電器とEVという二つのDERが関係し、それぞれから別な情報を取得したり、遠方操作する必要がある場合があります。
仮にEV充電によって、太陽光発電の余剰を吸収するエネルギーサービスを考えてみましょう。アグリゲーターは、まず、EVの電池に追加的に電力を蓄えられる空き容量があるかをEVのSoCを取得することにより確認する必要があります。次に確認する必要があることは、充電ケーブルがEVに接続されているか、ということです。他のDERにはあまり起きないことですが、EVは、充電ケーブルが接続されている／されていないという二つの状態があります。もちろん、充電ケーブルが接続されていなければ、いくら蓄電池に空き容量があったとしても追加充電はできません。更にEVには、充電を受け入れられる状態とそうでない状態の二つの状態があります。残念ながら、現時点ではEVのメーカーや年式などにより設計思想が異なるようで、車種毎に確認して合せなければなりません。
EV充電と電力システムの連携には、上記の「空き容量確認」「充電ケーブル接続確認」「充電受け入れ可能状態確認」の三点を確認しなければなりません。この三点は、充電器側だけ、EV側だけへのアクセスでは揃えることができないという問題があります。すなわち、充電器側へのアクセス、EV側へのアクセスの両方を実装しないと、EV充電と電力システムの連携はできないのです（図－２２）。このような接続をこのドキュメントでは、マルチデバイス接続と呼びます。
このような場合、当然二つのDER（EVと充電器）に対してアクセスを実装します。図－２３に示したのは、その一例の実験システム構成です。この実験では二つのDERともクラウドへのアクセスでアクセスが実現できる構造でしたが、二つのクラウドに対するドライバーを製作し、アクセスを実現しました。
図－２２ マルチデバイス接続
|
図－２３ マルチデバイス接続の実装
|
チェックポイント－3
有人事業所から離隔した無人の場所にDERを設置しますか？
《関係なければ読み飛ばしていただいて結構です》(3) 無人拠点に於ける留意点
このようなケースでは、セキュリティーパッチをインストールするなどサイバーセキュリティ維持などの作業のため現地に赴くまでにある程度の期間を要するなどを想定されます。DERの適切な維持・管理のためには、このような現実に起こり得る脆弱性に対しても、ICT接続に於けるサイバーセキュリティなどに関し、可能な範囲でロバスト性を確保しておくことは大切です。
同時に、個々のDER活用による経済的メリットはさほど大きくないことも知られていることに鑑み、ICT接続に要するコストも可能な限り低減できる必要があります。さらに、昨今DERのみならず多くの屋外設置設備の電線等の部材が盗難に遭うことが社会問題化しており、遠隔監視の必要性も再認識されつつあります。
問題は山積みですが、通信事業者閉域網の利用は、サイバーセキュリティの確保の手間などが相当程度軽減できることが経験的に知られています。詳しいことは巻末の参考に譲りますが、一般的なインターネットアクセスばかりでなく、通信事業者閉域網の利用も考える価値がありそうです。
通信事業者閉域網には、DERの遠方操作などに向く双方向通信と、定常的なモニタなどに向く単方向通信があり、料金も低廉なサービスも多いので選択肢となり得ます。また、IoT-HUBを活用して、これらを並列接続することもできます（図－２４）。
(4) 相互接続工事
ここでは、先に述べたIoT-HUBを社会実装し運用している電気通信事業者（以下、電気通信事業者）の協力を得て、相互接続を実現する実験例を紹介します。
アグリゲーターやDER所有者は、図－２５に示す “ Driver ”をDERが使用している通信プロトコルに合った仕様で製作することにより、互いのシステムのインターフェイスの擦り合わせを大幅に軽減して相互接続することが可能となります。
先に述べたように、DERによっては、蓄電池定格容量やポンプ定格電力といったDERそのものの仕様を示す数値をアグリゲーターに送信する機能がない場合もあります。この実験では、ドライバーに図－１８の情報のうち、DERが送信できない情報をDERに代わって送信する機能を盛り込みました。このように、ドライバーはDERがそもそもは具備していない機能を追加的に拡張付加する機能もあります。
更に、複数種類のDERを活用する場合、一方と他方の送信する情報の単位が異なっている場合があります。RAシステムを改修してこの差異を吸収する方法もありますが、ここで紹介する実験では、ドライバーで数値を演算し、必要な変換を行いました。
このような相互接続実務段階では、図－２６に示すようなドライバーの製作に必要な事項をNDA規定の手続きを経て電気通信事業者に提示すればドライバーを発注できるように簡単化しました。電気通信事業者は、IoT-HUBの張り出し装置であるIoT-Routerへのドライバー実装などのキッティングを行いますので、DER所有者はそれを自社サイトに設置すれば、DERのネット接続を完了できます。冒頭にDER活用は喫緊の課題といいましたが、このような方法でアグリゲーターやDER所有者といった必ずしもICTに詳しくない立場の方でも、IoT-HUBの社会実装に際しては、この一連の手続きによって相互接続の土台が出来上がるようにしてあります。
７.相互接続確認試験
(1) 相互接続確認試験／関係者による合格確認
前章までの協議や作業を進め、ようやくここまで来ました。あとは、相互接続確認試験によりシステム構成が適切に動作することを確認すれば、ゴールです。
第3章で相互接続確認試験を円滑に進めるには、適切な手順書を用意し、それを関係者で共有、手順書に沿った試験を進めることが大切と述べました。また、オンライン会議システムの使用により、RAシステムの画面やDERの表示などを、互いに離れた場所にいる関係者間で適切に共有することで、試験のさらなる円滑化が期待できます。
手順書は、基本的に次の項目を試験する順序に並べたものです。
- DER所有者にアクセスをお願いし了解された情報へのアクセス確認
- DERにはその機能がなく、ドライバーに後付けした情報伝達機能の動作確認
- 検討した留意点などが適切に実装されていることの確認
- DER所有者からアクセスを禁止された情報へアクセスできないことの確認
- EVに於ける充電ケーブル引き抜きなど、通常起こり得る異常状態の発生の際の情報伝達の確認
- その他
このドキュメントで紹介したマルチユーザー実験での手順書例を図－２７として紹介します。またこれを付録として添付しますので、ご自由にお使いください。また、オンライン会議システムを使用した試験の様子を図－２８／２９に紹介します。
相互接続確認試験は、互いに離れた場所にいるアグリゲーター側、DER側で要員を配置して行います。どちらが進行役を務めるかを決めておくとスムースです（図－３０）。このドキュメントで紹介した実験では、相互接続を実現しているIoT-HUBを運用する電気通信事業者が進行役を務めるという役割分担も試しました。このため、試験手順書には、IoT-HUBのNOC（Network Operation Center）の記載スペースも入れてあります。この役割分担で、とても円滑に試験が進みましたので、おススメと思われます。
手順書にある試験項目を全て確認し、全部が適切に動作していれば試験は合格です。
図－２８ オンライン会議システムの活用
|
図－２９ DER側での試験の様子
|
(2) 相互接続システム運用開始
ついにゴールまで来ました。あなたの働きにより意中のDERをアグリゲーターが自らのエネルギーサービスに組み込むことができました。いよいよ運用開始です。先に述べた通り、通常時に加えて、異常発生時の連絡ルートや、対処体制などの運用を申し合わせをしておくことが適切です。
８.おわりに
このドキュメントでは、アグリゲーターがDER所有者を訪ね、再生可能エネルギー利用を拡大するためにはDERの活用が不可欠であることを認識して頂き、NDAの締結を経て必要な情報開示を受けることから始まり、IoT-HUBの活用により通信方式の種別にあまり煩わされないようにして、DERとRAシステムを相互に接続し、最終の確認試験を済ませるまでのプロセスを実験例を交えながら紹介しました。
自然変動電源の大規模な拡大導入のためには、膨大な数のDER活用が必要であることは既に述べました。DER活用については、今まで多くの技術的トライアルが実施されていますが、今後はそれをだれでもできるようにして産業的にスケールさせる必要があります。このドキュメントはその取り組みに貢献することを念頭に置いて試作されました。具体的には、極力難解な技術的説明を省き、どのように行動すればDERの相互接続に辿り着けるかに重きを置いた、いわば旅行ガイドブック的な存在を目指しました。
今後このドキュメントが活用され、数多くの素敵なエネルギーサービスが提供されることを願ってやみません。
以上
付録
NDAひな形
1.技術解説
本文で言及した通信方式と通信プロトコルについて、以下に技術を平易に解説するので、参考にして頂ければ幸いです。
通信プロトコルとは、様々なメーカーの様々な機器同士が接続されて相互に通信するための手順や約束事のことで、具体的には機器と機器の間でデータを送る場合、データを送る側も、受け取る側も解釈できる受け渡し方法をどうするか、どれだけのデータをどこに送るのか、データを送る際にどんなフォーマットで送れば良いか、エラーが発生時したらどう対処すれば良いか等を決めたルールのことです。通信プロトコルには用途、機器に応じて様々な種類があり、それぞれの概要を以下に説明します。
1. IPプロトコルによるEthernet（イーサネット）
IP 通信とは、IP（インターネットプロトコル）を使ってネットワーク（たとえば、イーサネット）上で通信することです。各機器には通信ネットワークにおける宛先（住所番地のようなものと考えて下さい）を表すIPアドレスが割り振られ、たとえばA地点からB地点にデータを送る際には、A地点の送信元IPアドレスからB地点の送信先IPアドレスを識別して通信します。IP通信では情報はパケットと呼ばれる「かたまり」に分割されて送られます。パケットは小包という意味です。各パケットの先頭にはIPヘッダーと呼ばれるIPアドレスを入れる部分があり、これを読み取ってA地点からB地点の間でどの中継点を通ってパケットを送り届けるか、通信経路（ルート）が決められます。この処理をルーティングと呼びます。IPパケットは企業において一般に用いられているLAN（Local Area Network）と同様、イーサネットのフレームにのせて伝送されます。イーサネットのフレームとは、パケットを送る宛先や、送信元を表すMACアドレス（Media Access Control address）などの制御情報や、誤り訂正符号が付けられた入れ物のことで、イーサネット通信はこのフレーム単位で処理されます。
IPネットワーク上でパケットを送る際には、パケットの送受信（トランスポートと言います）するためのプロトコルが用いられ、TCP（トランスミッション・コントロール・プロトコル）またはUDP（ユーザー・データ・プロトコル）と呼ばれます。２つのプロトコルTCPとUDPの違いは、送ったパケットが正しく送信先に届いたかどうかを確認する機能があるか、ないかの違いです。ネットワーク上でパケットを送信する際に、なんらかの理由でパケットが壊れたり、無くなったり、重複したり、遅延したり、送信先に到着する順序が違ったりすることがあります。TCPを用いると、受信側でこれらのエラーを検出した際には、再送要求を送信側に出すことで、送るデータが正しく先方に受け取られことを確実にします。この伝達信頼性を確保するために、データを送る前に送信元と受信側の間で接続を確立する手順が必要で、具体的には①要求を出す、②応答する、③確認応答するという３回のメッセージのやり取りを行います。
一方、たとえばオンラインゲームや音楽や映画のストリーミング配信のようなサービスでは、送ったデータが相手に確実に届いたかどうかよりも、データが早く相手に届く方が求められます。このときに用いられるプロトコルがUDPです。
Modbus TCPは、工場における生産工程の自動化を図るFA（ファクトリーオートメーション）業界で広く用いられているModbus（モドバスと読みます）プロトコル（マスター／スレーブ方式）をイーサネット（TCP/IP）上で使えるように拡張したもので、いわば産業用イーサネットとも呼ばれます。ModbusメッセージはTCPパケットに先ずカプセル化され、次にIPパケットにカプセル化されて、最終的にイーサネット上で送信されます。
Modbus TCPにおける通信速度は10Mbps/100Mbpsです。
Modbusはクライアント／サーバー型のプロトコルで、マスター機器１台が最大３１台のスレーブ機器に対して、要求を送りたいスレーブ機器を指定してリクエストを送り、指定されたスレーブ機器はそれに反応してレスポンスをマスターに返すというマスター／スレーブ方式の制御を行います。丁度、オーケストラを指揮する指揮者（マスター）からの指示に基づき、指示された楽器（スレーブ）が音を出すのに似ています。
2. RS-485などのシリアル通信（Modbus RTU）
シリアル通信
シリアル通信に使用するインターフェイス規格はRS-485が広く用いられています。RS-485規格は２種類の信号の電圧レベルの差（差動信号と呼びます）でデータを送ります。この差動信号の入力電圧範囲は-7V～+12Vと大きな幅があります。工場などは様々な機器が動作し電気的なノイズも多く、また通信には静電気放電への耐性も要るような環境である場合があります。シリアル方式はこのような環境での通信に適しています。
RS-485規格を用いて通信するには、送受信を同じペア線上で共用する２線式と、送信と受信にそれぞれ別のペア線を使う４線式があります。２線式は半二重通信用で、送信と受信を交互に切り替えながらデータを送ることで双方向通信を行うので、たとえるとトランシーバーによる通話のようなものです。４線式は一方、全二重通信用で、送信と受信が同時に行える双方向通信です。
RS-485規格はバス型のマルチポイント接続（マルチドロップ接続と呼びます）に対応しており、２線式ペア線上に最大32台まで機器を接続できます。RS-485規格の伝送速度は最高10Mbps、ケーブル長は最大1200mです。
RS485規格のシリアル通信を用いて、産業用機器で使用されるアプリケーションをサポートするプロトコルModbus RTUが広く用いられています。RTU（リモート・ターミナル・ユニット）とは、設備の状態をデジタル情報に変換し、監視制御システムに伝送する遠隔デジタル信号変換器のことを言います。
3. インターネット上にあるサーバーに対する通信（クラウド）
3.１ クラウド
クラウドとは、クラウド・コンピューティングのことで、インターネットの向こう側でユーザーには見えない場所にあるコンピュータがネットワーク経由でサービスを提供するというイメージを表すためクラウド＝雲と名づけられました。具体的にはインターネットに接続されたサーバーやストレージ（これも一塊のリアルな装置ではなく、一以上の装置が組み合わされた仮想的な機能です）に保存されているデータ、アプリケーション、ファイル等を、インターネット経由でユーザーがどこからでもアクセスすることができる仕組みのことです。
これに対して、従来から企業オフィス内に実際にサーバーやストレージ等の設備を設置して自らの端末からデータ、アプリケーション、ファイル等にアクセスする仕組みは、企業内設置サーバー型（オンプレミス型）と呼ばれます。具体的には、企業が所有するサーバーをデータセンター事業者と契約して、場所が明らかなデータセンターにラックスペースを借りて設置してもらうケース（ハウジングやコロケーションと呼びます）や、データセンターが所有するサーバーを企業が利用するホスティングサービスなどの形態がありまするす。更に企業が自社に専用のサーバーを使用しないで、たとえばAWS（Amazon Web Service）のようなサービス提供事業者から提供される仮想サーバーを利用する場合をパブリッククラウドサービスと呼びます。
クラウドサービスの使い方例として、ユーザーは自らのPCやスマホ等にソフトウェアやデータをインストールせず、ユーザーはどこにいても、自分のPCやスマホ等ではない端末を使っても、クラウド上に保存されているデータやアプリケーション、ファイルにアクセスして利用することを可能にできます。
3.2 クラウドサービス例
主に企業の皆様が通常利用するパブリッククラウドサービスの代表例がAWSや、Microsoft Azureや、Google Cloud等です。また、個人の皆様が広く利用しているクラウドサービスの代表例には次のようなものがあげられます。
| Web メール | Gmail、Yahooメール |
|---|---|
| ソーシャルネットワーキングサービス（SNS） | X（旧Twitter）、Facebook、YouTube、TikTok、LINE、Instagram |
| オンラインストレージ | iCloud、Dropbox、Google Cloud |
3.3 クラウドの運用上の分類
パブリッククラウドは、たとえばAWSやAzureのようにクラウドサービス提供事業者が用意したサーバーやストレージ等IT資源によるクラウドサービスを、一般企業ユーザーや個人ユーザー等、誰でも契約すれば利用することができるようになっているサービスのことです。
プライベートクラウドとは、たとえば自動車メーカーが自社EV及び搭載する蓄電池に関する情報を自社クラウドサーバーにのみ蓄積して、技術蓄積、品質管理、顧客サポート等に活かす場合を指します。プライベートクラウドは、企業が自らのために専用のクラウド環境を構築、運用するので、企業内システムのように強固なセキュリティ対策を確保することができることが特徴です。
ハイブリッドクラウドとは、企業ユーザーが社外のパブリッククラウドサービスを使いながら、その企業にとってパブリックでは実現できない機能や、企業独自の機能等を社内のプライベートクラウドで構築して、両者の良いところを組み合わせて運用することで、強固なセキュリティを確保しながら、カスタマイズされた独自の機能を実現することが可能になります。企業にとって重要なデータを外部からのサイバー攻撃から守るために、サーバーやストレージを複数個所に分散配置することも可能になります。
3.4 Web API
API（Application Programming Interface）とは、Webサービスを製作する際に、世の中に利用できるソフトウェアやプログラムがある場合、そのアプリケーションプログラムが提供されているインターフェイス条件や接続ルールを満たせば、２つの異なるプログラムを連携して利用できるようにする仕組みのことを指します。
APIを使って２つのアプリケーションを連携させるメリットは、次の２つのことがあげられます。
① 新しいWebサービスを創り出したい開発者は、世の中に提供されているAPIを利用することにより、新しいアプリケーションを自ら一から開発する必要がなくなり、開発時間、開発工数、開発者人数、開発費用を削減することができる。
② APIを提供する企業は、自社サービスのAPIを公開することで、自社だけではリーチできない領域にも広く使ってもらうことを期待できる。
Web APIはhttpやhttps等Web技術を使って実現されるAPIの一種で、インターネット経由で利用できるので、開発知識がなくても２つのWebサービスを混ぜ合わせて新しいサービスを創り出す（“マッシュアップ”と呼びます）際に利用し易いです。
Web APIが実際に活用されている例は、たとえばレストランや宿泊ホテルの予約サイトで、提供されている地図アプリGoogle MapのWeb APIを利用すれば、レストランのオーナーや宿泊ホテルのオーナーが地図情報を持っていなくても、それぞれのWebサイトの中でそのレストランや宿泊ホテルの場所を示す地図が表示されます。
もう一つ、別の例を見てみましょう。ネットショッピングのWebサイトでは、モノを購入する際、ユーザーがクレジットカードを利用して支払う場合、ユーザーはそのサイトで自分のクレジットカード情報を入力しますが、本人確認や認証はその事業者のサイトではなくて、連携するクレジットカード会社のサイトで行われます。これもWeb API連携の具体例です。
もう一つ別の例では、何らかのサービスを提供するWebサイトにログインする際に、そのサービス提供者のログインページを使わないで、「Googleアカウントでログイン」や「Facebookアカウントでログイン」というボタンを押すと、そのサイトの運用者にWeb API連携しているGoogleやFacebookに登録されている当該ユーザーのプロフィール情報を取得して、ユーザー認証することが可能となります。この結果、Webサイト毎にユーザーIDとパスワードを入力する手間を省くことができます。
4. 携帯電話などの通信事業者閉域網（LPWA）
4.1 事業者閉域網
事業者閉域網とは、ユーザーが誰でも利用できるパブリックにオープンなインターネットではなくて、通信事業者が契約したユーザーのみが利用できる閉じたネットワークのことです。外部から直接アクセスすることもできないので、高いセキュリティが担保されています。事業者閉域網として、ここでは携帯通信事業者の携帯電話網と、通信事業者が提供するLPWA(Low Power Wide Area Network)網を取り上げます。
通信事業者の専用線網を利用すると最も高いセキュリティを確保できますが、通信容量が多い場合などサービスによっては料金が高い場合もあります。次善の策として通信事業者がサービス品質を管理してIPネットワーク上で仮想的に専用線網VPN（Virtual Private Network）サービス（IP-VPN）を利用するという選択肢もあります。
4.2 携帯電話網
携帯電話網は無線アクセスネットワーク（RAN; Radio Access Network）とコアネットワークと携帯電話端末から構成されます。RANは携帯電話端末を使って、離れた場所にいる人との会話や、またPCやタブレット等端末を使ってデータを送受信する際に、基地局と呼ばれる装置を介してコアネットワークとの間を中継します。
コアネットワークは送信者と受信者の間で携帯電話端末から、話したい相手の携帯電話番号に発信すると、携帯電話網のコア機能は加入者管理データベースで発信者の電話番号、契約料金プラン、携帯電話機の現在値位置情報、相手の携帯電話機の登録情報等を調べて、その位置の基地局に回線を繋ぎ、相手の携帯電話機を呼び出します。ある事業者の移動通信網に加入している移動加入者が他事業者の移動通信網においても途切れないで、連続的にサービスを受けられる“ローミングサービス”も提供されます。ユーザーは携帯電話機で相手と会話していなくても、自分がいるセル（基地局が送出する電波がカバーするエリアのことで、4G/LTEではエリア半径が数100m～数kmまでをカバーする場合、これをマクロセルと呼びます）から、他のセルに移動すると、電波を送出して自分の端末がどこのセルにいるのかをコアネットワーク内のホームロケーションレジスタに登録します。
携帯電話の通信方式は３GPPと呼ばれる国際標準化の中で検討されてきており、現在は主に４G/LTE（第４世代、Long Term Evolution）が使われていますが、一部都市部では５Ｇも利用できるように整備されつつあります。
一方、WiFiをアクセス系として用いる光ブロードバンド固定網では、WiFiアクセスポイントはユーザーが所有し、ユーザーが宅内に設置します。WiFiアクセスポイントからの信号はLANケーブルを介してFTTH（Fiber To The Home）を構成する光終端装置ONU(Optical Network Unit)に接続されます。通信事業者のブロードバンド固定網を経由して、インターネットに繋がります。
4.3 LPWA通信
IoT（Internet of Things；モノのインターネット）は、「あらゆるモノがインターネットに繋がる」ことを表す言葉で、「モノ」＝デバイスとの通信に用いられる無線通信方式がLPWA（Low Power Wide Area）です。LPWAは人と人が会話するような双方向の通信方式ではなく、単方向（上り方向）のみか、または上り方向がメインながら、時々下り方向も通信するようなサービスを提供するものもあります。これにより、モノに実装する通信モジュール用の電気回路の消費電力を下げて、電池の寿命を延ばすことができます。上り方向のみの場合、モニタには使えますが、操作には使えません。
LPWAには、本文の実験で使用したELTRES™をはじめ、LoRaWAN、Wi-SUN等の通信方式が含まれ、データ転送速度、通信距離、双方向／単方向等の違いがありますので、用途に応じて適切な方式を選択します。
ELTRES™はソニーネットワークコミュニケーションズ（株）が開発した独自規格です。特徴は上り単方向の通信であること、送信無線周波数は923.6MHz～928.0MHzを使用して、ユーザーは最大128ビット（16バイト）までの情報容量（ペイロードと呼びます）を暗号化して、長距離（見通しが良ければ100km以上）に伝送できること等です。
ユーザーは、同社と契約してこのサービスを利用します。同社は携帯電話通信事業者と同様にサービス提供エリアで無線基地局を設置しており、ユーザーは月額100円前後の低料金で同サービスを利用することが可能です。
実験では、ELTRESサービスを監視に、また携帯電話勇信事業者によるLTE-Mを操作に用いましたが、その両者共に通信事業者閉域網であることから、DERとアグリゲーターの接続においてサイバーセキュリティ等に対するロバスト性が確保されます。
5. ECHONET Lite
ECHONET Liteは今後、スマートハウスにおいて、エアコンや冷蔵庫のような白物家電をインターネット接続（IoT化）し、またセンサー類を利用して照明等を制御することで省エネ等エネルギーマネジメントやリモートメンテナンス等サービスを実現する際に、異なるメーカーの様々な機器同士がお互いに通信＝お話しできるように、共通の通信プロトコルや制御コマンド等の共通の約束を規格、通信仕様として一般社団法人エコネットコンソーシアムにより決められました。
ECHONET Liteを実装する対象となる機器は、省エネ機器、蓄エネ機器、創エネ機器、計測機器、業務用機器等が含まれます。
以下に、家庭内でコントローラがホームネットワークを介して電気器具（ECHONET Liteを実装する）を制御する手順を簡単に説明します。
① 先ず、コントローラからホームネットワークに接続されているECHONET Liteに準拠した電気器具を探します。
② コントローラはコマンドを出して、当該電気器具の状態を取得します。たとえば、電源がOFFになっているとします。
③ 次に、コントローラから当該電気器具を制御します。ここでは電源をONにするコマンドを送ります。
④ 電気器具の状態が変化したことをコントローラに知らせます。
6. Open ADR
電力会社が需給ひっ迫時に需要家側で需給調整をしてもらうように、需要家側に節電要請や電力消費する時間をシフトしてもらう場合、デマンドレスポンス（Demand Response）サービスを契約している需要家には、従来は電力会社が電話等により、需要家に電力消費を抑制するように連絡し、また時間帯別料金を設定して、需要がピークの時には電力料金を高くして需要家に電力消費を抑制しもらい、料金の安い時間帯に需要をシフトしてもらった結果削減してもらった電力量に応じてインセンティブを需要家に支払う等のサービスを提供するなどしていました。
この人手を介した複雑なやり取りを自動化する仕組みがOpen ADR（Open Automated DR）です。Open ADRが適用される箇所を図６．１に示します。Open ADRでは電力会社とアグリゲーターと需要家の間で通信モデルや通信プロトコルを規定しています。モデルとしては、電力会社のサーバー（VTN、 Virtual Top Nodeと呼びます）と需要家側クライアント（VEN、 Virtual End Nodeと呼びます）と、その両者の間に位置するアグリゲーター（VEN/VTHと呼びます）の３者間で、拡張可能なマークアップ言語XML形式のメッセージ交換を行うことで、デマンドレスポンスの要請及び応答を行います。
7. 階層（レイヤ）とは
本ドキュメントの本文中では、ネットワークの説明の際に階層（レイヤ）構造について触れてきませんでしたが、ご関心のある方にはご参考までに以下に補足説明致します。
ネットワークの階層は、OSI (Open Systems Interconnection)参照モデルとTCP/IP階層モデルの２種類があります。前者は国際標準として厳格に決められた構造であるのに対して、後者はインターネットの登場と共に実用的に定義されたものです。ここでは説明のためにきっちりと定義されたOSIモデルをベースに説明致します。OSI参照モデルは第１層から第７層まで７つの層（レイヤ）から構成されているので、７レイヤと呼ばれます。
物理層としてケーブルや無線等の伝送媒体とデバイス（コネクタ等）を規定します。データ信号（ビット列）を送信するための電気信号や光信号等の仕様、物理的な要件を規定します。
データリンク層は、物理層で送信されるビット列からフレームに構成します。またMACアドレスを付けてエラーチェック。フロー制御等を可能にします。
ネットワーク層は、送信するデータをセグメントに区切り、送信先のIPアドレスを付けて、宛先までの通信経路（ル―ティング）を決定して、データ転送を行います。
トランスポート層はエンド－エンドの通信ステータスを管理し、シーケンス番号、確認応答、再送制御等の機能を提供して、データの分割や再結合を行います。
セッション層は、送信・受信間の通信手順を定義し、データの転送開始と終了の管理、データの同期や復旧、異常時の回復手順等を管理します。
プレゼンテーション層は、受信側で理解できるように、送信する文字コードの変換、データの圧縮、暗号化等により、データの形式を変換します。
アプリケーション層は、ユーザーが利用するアプリケーションに連携します。具体的にはユーザーインターフェイス、メール等が含まれます。
2. IoT-HUB解説
本章では、IoT-HUBの解説として東京大学生産技術研究所の紀要である「生産研究」から、馬場博幸／野城智也共著「相互接続基盤としてのIoT-HUBの活用方策」（生産研究、74巻2号、pp.175-179、2022.5）を常体のまま再掲します。IoT-HUBは、DER活用専用に開発されたものではありませんが、DERもIoTデバイスの一種のため下記に記した課題や解決策は、殆どそのままDER活用にも適用でき、エネルギー分野専門の事業としても社会実装されています（2024年現在）。
1. はじめに
筆者らはデジタルトランスフォーメーション（DX）の 重要な要素となる IoT（Internet of Things）に注目し、産学連携の許、課題整理とその解決策について生産技術研究所内の実験ハウス（通称：COMMA ハウス、図1）にて様々な試験実装等を続けて来た。その結果、異なるConnected な機器やアプリ（以下、IoT システム）を相互に接続するIoT-HUB と呼ぶインフラの開発に至り、産学連携先によってそれが社会実装されて、現在実際のユーザーに使用され始めている。実ユーザーに使用されるには技術問題だけではなくビジネス上の問題も解消する必要があり、本稿はそれらへの対応を纏めた報告である。
2. IoTの課題
IoT は、あらゆるものがネット（一般的にはインターネット）に繋るという概念である。ネットを単に通信用パイプとして捉え、センサーやスマートフォンアプリなど自社 の製品群から成るクローズドなシステムを構築する方法もあるが、あらゆるものがネットに繋がるのであれば、他社の製品やアプリとも相互接続して新たな価値を創出する考えもある。当然のことながら、他社との相互接続戦略は短期間で多種多様なシステムを実現して、飛躍的に多様な価値が創出できる期待がある一方、以下に述べる四つの大きな課題もある。
まずは、IoT システム相互の整合性の問題である。筆者の一人は、過去に建築分野に於いて異なるメーカー等のシステムの相互接続の経験があるが、そこでは個々の IoT システムが既にサイロ化（後述）しており、これらを統合的に制御するシステム構築は、通信プロトコルなどに関する技術協議に加え利害調整も必要となるなど極めて煩雑な問題が横たわっていることを経験している。
この旧くて新しい問題に対する一般的な解決策は標準化である。標準化は異なるシステムの一部を関係者が統一するのであるから、本来は協業領域であるはずであるが、実際には自社が推す仕様がビジネス上優位になることを狙って、主導権争いともいえる競争領域になってしまうことが多い。結果的に、標準化は多大な時間を要することが多く、その間に強い競争力を有する、例えばビッグテックと呼ばれる世界的巨大 IT 企業などは独自路線を進め、寡占状態が進んでしまう懸念も生ずる。
また、IoT は“あらゆるもの（以下、モノとも記す）がネットに繋がる”という概念であるから、2千円の扇風機や、100 万円の玄関ドアなどモノの価額帯にも大きな幅がある。モノをConnected にするには、当然何らかの増分コストが発生するが、本体価額に大きな開きがあることに起因してConnected 化コストの負担能力にも自ずと開きが生ずる。すなわち、相互接続のための標準として単一の通信 プロトコルを決めたとしても、このコスト負担能力に適合しないケースも発生することとなる。このような実情に鑑み、標準化という方法に依らず、多大な労力なしに異なるIoT システムを相互接続する方法への関心が本研究の背景である。
次なる課題は、システム全体が上手く動作しない場合の対応についてである。これは、障害発生の際の初動を誰が行うのか、という“障害切り分け”問題とも言える。異なるメーカーやサービス提供事業者の機器やアプリを複合的に相互接続したシステムに於いて、全体として不具合が発生した場合、故障探索を関係事業者が一斉に行うことは当然効率的ではない。特にIoTの場合、モノがエンドユーザー宅などのいわば現場にあるため、障害対応にフィールドエンジニアの現場出向が必要になるなど、コスト増の要因を抱えている。 まずは、どの事業者の責任範囲に不具合の原因がありそうか見当をつけ、当該責任範囲を受け持つ事業者が初期応動をすることが肝要である。具体的には、相互接続されている IoT システム間に明確な責任分界点を設定できるようなアーキテクチャーを採用し、責任分界点を意識した障害切り分けをすることが大変重要である。
IoTシステムの相互接続には、さらに問題がある。データ利活用社会構築が提唱されるなか、「第三者に自分のシステムの稼働データを勝手に使われるのではないか」という不安問題が存在する。これには明示的、暗示的なケース両方があるが、この懸念は大変根強いものであり、IoTシステム相互接続の課題として、前述の「システム間の整合性」「責任分界点と障害切り分け機能」に加え、三点目としてこの「データ流通に関する不安」を挙げたい。
ビジネス上の問題はさらにある。第一の問題と逆説的になるが、相互接続がやりにくい（一般的にはこれをサイロ化という）ということは一種の差別化方策の結果であり、 これが競争力の源泉にもなっているということである。他社の機器やアプリと自社のそれらを組み合わせて新しい価値創造ができることは既に述べたとおりであるが、他社と自由自在に相互接続できる環境は、競合する第三者も同様の環境を手にできることを意味し、競争力の点からはたして歓迎すべきなのか、という問題意識が存在するのも事実である。筆者らはこれを四番目の課題として捉え「協調領域に於ける公正競争環境の維持問題」と呼んでいる。以上の四大問題を表1に纏める。
3. 個別課題に対する解決策
3.1 システム間の整合性に対する解決策
筆者らは標準化に依らない方法として、身近にあるパソコンとプリンターの関係に注目した。我々は、自宅や職場でいろいろなパソコンやプリンターを使っているが、A 社のプリンターと B 社のプリンターの通信プロトコルは統一されていない。しかし、ユーザーである我々は、なんの不自由もなく、実際にそれらを使いこなしている。筆者らは このような例をヒントに、IoTシステム間の相互接続にも同じような構造をインターネット上に大規模に構築すれば、 相互接続問題は大幅に軽減できるのではないかと考えた。
産学連携先と様々な検討と実証を進めた結果、筆者らはIoT-HUB と名付けたインフラを開発1）2）3）した。アプリやIoT デバイスなどどのような IoT システムであろうとも、 その通信プロトコルに対応した“ドライバー”と呼ぶ小さ なソフトウェアを用意し、原理的にはそれを背中合わせに接続すれば相互接続できることになる。背中合わせの接続を成り立たせる基盤が IoT-HUB である。
原理は簡単だが、ここに工夫を要する課題が存在する。 Connected 機能を備えた機器（以下、IoT デバイス）は通常二種類あり、当該機器のメーカーが運営するプライベー トクラウドに収容されているか、IoTデバイスが Wi-Fi などの通信機能を有し、何らかの通信プロトコルに対応できる機能を有しているか、のどちらかである。筆者らは、前 者をクラウド収容タイプ、後者をローカル接続タイプと通称している。使い易い相互接続基盤を構築するには、このどちらのスタイルにも“ドライバーの背中合わせ”原理が適用できるようにする必要がある。このため、ローカル接続タイプの IoT デバイスには、エンドユーザー宅などの現場に設置でき、ドライバーを支える IoT-HUB の張り出し装置的な機能を用意した。使用する具体的な機器としては、 PC やタブレット PC など汎用的な機器がコスト等の面から適切である。
IoT-HUB 本体と張り出し装置の両方で“ドライバー”が同じように扱えるようにするため、R-Edge と名付けた構造を開発した。インターネット上の IoT-HUB 本体上であれ、IoT ルーターと名付けた張り出し装置上であれ、このR-Edgeはドライバーのソケットのように機能する。こうすることで、クラウド収容タイプ、ローカル接続タイプ両方が同じようにドライバーによって接続されることを可能とした。なお、IoT-HUB 本体は、Function as a Service と呼ばれるパブリッククラウドサービスによって構築したバーチャルインフラとして社会実装されている。これによりインフラ構築コストを変動費化することができる。
IoT ルーターは、あくまでも IoT-HUB の出入り口機能を現場に登場させる張り出し装置であり、IoT-HUB の一部である。ホームオートメーションなどでは、ホームゲートウ ェイ（以下、HGW）などと呼ぶローカルコントローラー的な端末を設置するアーキテクチャーを見かけるが、IoT ルーターの位置づけはこの HGW とは根本的に異なっている。
アプリケーションは、一般に Web API と呼ぶインターフェイスを相手にすることが多く、特別なドライバーが必要なケースは少ない。しかし、相互接続先が多岐にわたり、それぞれの相手先に届けるコマンド書式等が多数になってしまう場合等には、“アプリケーション・ドライバー”と 名付けたドライバーでこれらの差異を吸収してしまう方法も実装可能4）である。この考えは、アプリや機器本体からドライバーに至るまでの“自分の責任範囲は自分の自由にできる”という一種の理想状態を保証する。以上の説明を総合したインフラ概要を図2 に示す。
ドライバーは、IoTシステムの通信プロトコルに合わせたコマンドを送受信するように作る小さなソフトウェアであり、ソフトウェアエンジニア一人週程度の工数で製作可能である。IoTデバイスとのインターフェイス条件は、当該デバイスによって異なるが、① Web サイトなどで公開されている、② NDA 締結を条件に提供されるよう準備されている、③個別協議を要する、であり、筆者らの実験経験では Connected デバイスは①、②のタイプが多いようである。
3.2 障害切り分け機能の実装
ドライバーによる相互接続という概念を持ち込んだこと により、障害切り分け機能も比較的容易に構築できるようになった。生活に於ける PC ユーザーの誰もが常識的なこととして、プリンターとプリンタードライバーは当該メーカーが一体として提供するものであり、プリンタードライバー以降プリンターまでは当該メーカーの責任範囲、と認識している。もちろん PC とプリンターを接続する USB ケーブルなどはその責任範囲外であることも共通認識となっている。
先のIoT デバイスとドライバーも同様でドライバー以降IoTデバイスまでがメーカーの責任範囲である、という責任分界点の在り方は上記の生活感的常識と整合性がよい。筆者らの実証実験では、ドライバーの背面（R-Edgeとの接合面）を責任分解点とすることは合理的である、と解してくれる関係者は多かった。このため、IoT-HUBではドライバーの背面を責任分界点と規定している。
IoT デバイスメーカーがドライバーを添付して製品を出荷するという機運に至るまではまだ時間を要するし、それまでドライバーはサードパーティー製のものとなることは必至である。しかし、前述の生活的な IT 常識に立脚した関係者間の認識合わせにより、ドライバー背面を運用上の責任分界点とすることは可能である。
このようにドライバー背面を責任分界点とすることで、 障害発生時の初動を誰が担うか、という問題はかなり判りや易くなった。さらに、これを可能とする機能も IoT-HUB には実装できることを確認している。図3 にその原理を示す。情報伝達ルートを切り替えて試験することにより、障害が発生している区間の推定が可能になる。
具体的にはユーザーからの不具合申告を受けたサービス提供事業者は自身に許されIoT-HUB の操作コマンドにより、障害発生の情報ルートを通常のBから、Aルートに切り替える。A ルートの先には、IoT デバイスからの応答をエミュレートする「仮想デバイス」が設置されている。
「仮想デバイス」は応答をエミュレートするだけなので、 実質的にはドライバーとさして変わらないソフトウェアである。このB ルートとA ルートの応答の違いから図3内の表のように障害区間が推定される。これをドライバー背面と規定した責任分界点と照らし合わせれば、初動すべき事業者が決まる。初動を担うのは、「サービス提供事業者」「IoT-HUB 運営事業者」「IoT デバイスメーカー」の三者が候補である。実際には、前二者が一つのグループとして対応することとなろう。もし、障害がIoTデバイスメーカーの責任範囲であれば、当該メーカーはまず自身のトラブルシューティングツールを使って、自社の責任範囲内での故障探索をすると予想される。
なお、社会実装された IoT-HUB ではさらに先進的な機能を既に実装しており、提供するSDKによって製作したドライバーであれば、ドライバー等が命令に対して応答を返す機構が組み込まれるため、上記の原理的な切り替え方法に依らずとも、障害区間の推定が可能である。
3.3 データ流通に関する不安解消方策
IoTシステムの相互接続には、自身の機器等の稼働データがIoT-HUBの運営事業者によって覗き見られ貯められて、不当に利用されるのではないか、という拭いきれない不安がユーザー事業者側に存在する。この不安は、IoT- HUBのような結節点の機能的メリットを帳消しにするほど強いもので、納得感のある合理的な解決策が必要である。
そこで筆者らは、法規制を活用することを考案した。電気通信事業は、「他人の通信を媒介する」ものと規定5）され IoT-HUB もその範疇に入る。電気通信事業法は、その第四条で（秘密の保護）電気通信事業者の取扱中に係る通信の秘密は、侵してはならない、と規定している。
IoT-HUB の運営者が電気通信事業者になれば、IoT-HUB 利用者が抱えるデータ流通に関して不安視する行為自体が法令によって禁止されるため、この方策は明解な解決メッ セージとなる。
3.4 協調領域に於ける公正競争環境の維持方策
IoT-HUBは、様々な IoTシステムの責任範囲を明確にした上で、相手と対等な立場で相互接続できる機能（以下、 フラットな相互接続）と呼ぶことができる。この環境下では、競合他社も同様のメリットを得られるため、結局は自社の競争力を削がれることになるのではないか、という見方もある。この課題については、IoT-HUBの運営事業者が次のようなビジネススキームを採用することによって解決できる。
図4によって、クラウド収容スタイルを例に説明する。IoT デバイスの操作は、API（Application Program Interface） に信号を送ることによって行う。一般に一種類のIoT デバイスに対して複数のAPIが用意され、それぞれが機器の個別動作に対応したり、また、メーカーのトラブルシューティング専用などとなっている。
簡単のためZ社の同じモデルの IoT デバイスに対してA社、B社二社のサービス提供事業者が相互接続を希望しているものとする。Z 社は、ビジネス上の損得勘定や相手の技術的レベルなどによって、A社、B社にアクセスを許すAPI の範囲を個別に決定すれば、フラットに繋がるIoT- HUB 経由であっても、Z社 -A社によるシステムと、Z社-B社によるシステムは差別化が可能となる。これは技術的マターではなくビジネススキームと呼ぶべき事柄であり、これを筆者らは協調領域に於ける公正競争環境の維持方策と呼んでいる。IoT-HUB 運用者が、Web などを活用してこれらの協議の仲立ちもすれば相互接続のワンストップサービスが実現する。この方策の社会実装は今後である。
4. 活用事例
4.1 基幹システムの柔軟性確保方策として
本インフラは、産学連携先によって2019年に社会実装され、現在実際の顧客によって活用されている。図5はいわゆるゼネコン企業による活用例である。この企業は、建設したビルのエネルギー管理や情報通信システムなど付帯 設備の統合管理運用を建物OSと呼ぶ基幹システムによって積極的に進めている。付帯設備には、どのテナントも利用する基礎的なものに加え、テナントの好みによって選ばれる千差万別的なものもある。これらバラつきの多い案件に対応するために、基幹システムである建物 OSを一々改修していたのでは、長い対応時間やコスト増を招くことは明白である。この応用事例では、このように柔軟に対応すべき付帯システム対応部分を一部 IoT-HUB 経由にすることによって、基幹システムの改修をせずに実現することを可能にしている。
4.2 既存経営リソースの活用ツールとして
図6は、リース会社での活用事例である。リース会社は顧客企業に於いて使用されているリース機材の把握のため 移動体通信端末を多く利用している。LPWA（Low Power Wide Area network）など近年の技術進展による低廉な通信システムの登場によって、上記の通信コストを低減できる機会が訪れている。しかし、これを利用するためには、既存の管理システム全体を作り直す必要などをシステムベンダーから提案されることも多く、結果として却ってコスト高になってしまう悩みを抱えていた。
結果的にこの企業は、既存の管理システムはそのままにして、携帯電話システム（4G）からLPWAシステムの接続部分にIoT-HUBを介在させてプロトコルを変換し、システム改修コストを極小化しつつ、かつ、通信コストも低減することに成功した。いわばこれは BPR（Business Process Reengineering）の成功事例である。
5. おわりに
本インフラの相互接続対象には制限は特にない。カーボンニュートラルに寄与できる分散エネルギー資源なども対象とすべき重要なIoTシステムであろう。これには、ミクロなカーボンクレジット取引なども付随させるなどすれば7）、エネルギー領域に留まらない複合的なサービスの実現も可能となろう。
本研究は、2015 年に設置したIoT 特別研究会のメンバー企業のお力添え、また、同研究会と協業協定を締結し様々な実証試験を行って下さった団体さまのご助力によって実現できた。改めてここに謝意を表明する。さらに、研究成果を社会実装して下さった IoT-EX 株式会社の小畑至弘、 松村淳両代表取締役には格段のお力添えを頂いた。改めてお礼申し上げたい。
参考文献
- 馬場博幸他、電力取引システム活用による離隔地点間における個人の余剰電力利用スキームの試験実装、電気学会論文誌C、Vol.141、No.3（2021）、pp383-393
- 馬場博幸他、IoT 向け多種システム相互接続インフラの開発、2021 電子情報通信学会総合大会、D-23-11
- 馬場博幸他、IoT 向け相互接続インフラの他網接続機能の追加、2022 電子情報通信学会総合大会、D-23-3
- 馬場博幸他、DER の情報多様性要求への対応策検討、2022 電気学会全国大会、4-164
- 電気通信事業法第二条
- 生産技術研究奨励会 IoT 特別研究会（RC-88）パンフレット（2021）
- 野城智也、建築分野におけるカーボン・トレーディング導入の道筋・意義、生産研究、73、4（2021）、pp247-251
3. 応答時間・応動時間と需要の持ち替え解説
本章では、アグリゲーターが特に速く（例：１分以内）DERを動かす必要がある時に話題となる、DERがレスポンスするまでの時間（応答時間）、実際に動作するまでの時間（応動時間）について説明します。また、応動時間を活用する例として、長時間の需要創出に対してDERを入れ替える、需要の「持ち替え」についても紹介します。なお、応答時間・応動時間の解説には東京大学生産技術研究所の紀要である「生産研究」から、今中政輝／馬場博幸著「通信システムとエネルギー機器の複合的挙動の参照モデル構築の試み」（生産研究、75巻4号、pp.333-341、2023.11）を参考にしています。
1. 通信の”応答”と実際の機器の”応動”
DERに何か遠隔から指令を出すと、OKとかNGとか何らかの応答が返ってきます。ここではこれを”応答”と呼びます。これは、命令を受け付けたことを意味する場合も多く、特に操作の場合は実際に動いたりする前に出されることも多くあります。他方、実際に指令を受けたDERは、例えば充電開始せよという指令なら通常は実際に充電が始まります。これを”応動”と呼びます。応答結果と応動結果は時間ズレなどによって食い違うことがあるので、機器が実際に応動したかを確認するには、別に消費電力をモニタリングするなどして確認する必要があります。
2. 応答時間と応動時間
図1に応答時間と応動時間のイメージを示します。上のRAシステムと書いてあるのが、DERを制御したいアグリゲータのシステムだと思って下さい。横軸が経過時間です。応答時間は、RAシステムからの指令がインターネットなどを経由してDERに届き、DERから返信がRAシステムに戻ってくるまでの時間です。他方、応動時間はRAシステムからDERに指令を送信した時点から、DERが実際に消費電力を変化させ終わるまでの時間を言います。応答時間と応動時間は区別して考えることが大切です。
応答時間は一般的には数秒ですが、通信頻度が低い（例えば1分に1回）場合などはずっと時間がかかることが多くあります。応動時間はDERの種類や操作の内容によって大きく異なります。それは、DERの種類や操作によって、DERそのものの応動時間が大きく変わるためです。蓄電池や電気自動車の充電停止や消費電力の変更では数秒以下の場合もあります。他方、ヒートポンプ給湯機の起動となると、一般的には数分かかります。応答時間や応動時間にはバラつきもあります。
応答時間や応動時間の数値の例を紹介します。RAシステムからIoT-HUBを経由してEV充放電器を制御した例ですが、充電開始の時は応答時間が平均5.2秒に対し、応動時間は平均17.6秒でした。他方、充電停止の時は応答時間が平均で5.1秒と充電開始時とほとんど差が無かったのに対し、応動時間はたったの3.4秒！応答がRAシステムに戻る前には、充電は既に終わっていたのです。
3. 電力需要の「持ち替え」と応動時間
応動時間の応用例として、ここでは電力需要の「持ち替え」に着目します。例えば太陽光発電の余剰電力の消費を考える場合、余剰電力が出る時間は9時から15時の6時間といった長い時間になります。他方、ヒートポンプ給湯機は1～2時間でお湯が沸き終わってしまいますし、電気自動車も普段の通勤なら1～2時間で充電が終わってしまうことも少なくありません。こうしたDERを多数用いて6時間といった長時間の需要を生み出すには、あるDERの電力消費が終わるタイミングで次のDERを起動する必要があります。これをここでは、電力需要の「持ち替え」と呼びます。
電力需要の持ち替えにはいくつかのパターンが考えられます。EVの充電を例にとると、計画的にある時刻で充電を別のEVに切り替えることもあるでしょう。あるEVが満充電(付近)になったのを検知して別のEVの充電を開始する方が多いかもしれません。EVのユーザが突然ケーブルを抜いて充電を終了したため、アグリゲーターは急いで別のEVの充電を開始する場合もあるでしょう。
ここでは例として、あらかじめ予定した時刻に、図2のような2台のEVの充電需要を持ち替えることを考えます。充電器はPit-2GとEV Power Station (EVPS)の二種類を使っています。
この時、充電開始と充電停止を同時に指令すると、図3のように充電需要が止まる方が早いため、結果として10秒程度充電需要がない時間が生じてしまいます。これは、充電開始と充電停止で応動時間が異なるためです。応動時間の違いを考慮して、充電開始を10秒先に指令したのが図4です。この時は、充電需要のない時間がほとんどなく、合計値で見るとほぼフラットな充電需要ができています。
4. おわりに
実際問題として、応答時間や応動時間が本当にボトルネックになるケースは限られているかもしれません。しかし、需要創出量や需要抑制量の品質管理も担うアグリゲータからすると応答時間や応動時間は常に気になるものです。まずはどの程度の応答時間や応動時間になっているかのオーダーを把握しておくと、自分たちのDER活用において応答時間や応動時間を考慮するかどうかを判断する材料になります。
このドキュメントで紹介した実験報告論文
馬場博幸，今中政輝，「DER活用に於ける通信事業者閉域網利用実験報告」，電気学会システム・スマートファシリティ合同研究会，《番号待ち》，2024.10
馬場博幸，今中政輝，「DER活用に於けるマルチデバイス接続実験報告」，電気学会モータードライブ・回転機・自動車 合同研究会，MD-24-076 / RM-24-045 / VT-24-013，2024.7
馬場博幸，今中政輝，「DERユーザー接続に関する模擬社会実験報告」，電気学会電力技術／電力系統技術／半導体電力変換 合同研究会，PE-24-011 / PSE-24-023 / SPC-24-065，2024.3.
馬場博幸，今中政輝，「DER相互接続の模擬社実験報告」，電気学会家電・民生研究会，HCA-23-030，2023.5
以上
謝辞
この成果は、国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）の委託業務（JPNP22004）の結果得られたものである。