【寄稿】株式会社アイ・グリッド・ラボの太陽光 PPA 事業から蓄電池・ EV サービスまでの幅広い GX ソリューションでの Amazon Timestream 活用 (Part1)

この投稿はタスデザイングループ代表取締役甲田将史氏から株式会社アイ・グリッド・ソリューションズの AWS IoT Greengrass V2 、 Amazon Timestream 、 Amazon SageMaker を利用した再生可能エネルギープラットフォームの構築の取り組みについて寄稿頂いたものです。

Amazon Timestream に格納するエネルギー関連データ

【寄稿】株式会社アイ・グリッド・ラボによる AI ・ IoT 技術で再生可能エネルギー活用を最適化する次世代エネルギープラットフォーム①では、グリーントランスフォーメーション（ GX ）の取り組みとして株式会社アイ・グリッド・ソリューションズ（以下「アイ・グリッド」）が運営する R.E.A.L. New Energy Platform® （以下「プラットフォーム」）構築までの経緯とそのアーキテクチャについて紹介しました。

ここからはプラットフォームを構成する主な AWS サービスの具体的な利用方法を数回に分けてご紹介します。初回となる今回は、 Amazon Timestream を取り上げます。

Amazon Timestream を採用した経緯は前回の記事に記載しておりますが、プラットフォームが管理するエネルギー関連データのなかで、 Amazon Timestream に格納されるデータは以下の 3 つに大別されます。

(1) サイト（店舗など）から直接収集する実績データ
(2) 他システムからサーバ連携で収集する実績や予測データ
(3) プラットフォームの予測 AI が生成する予測データ

(1) の実績データは、電力使用量 [kWh] 、太陽光発電量 [kWh] 、気温 [℃] 、日射強度 [W/㎡] 、蓄電池や EV （電気自動車）の充放電状況や電池残量 [kWh] など、様々な計測機やセンサーを利用して R.E.A.L. Box と呼ばれるエッジデバイスを介して多数のサイトから毎分プラットフォームに収集されてくるデータです。(2) は、送配電などの電力関係機関が運営するサーバから取得する電量使用量や発電量の確定値や、電力取引市場から提供される電力市場価格データ、気象情報提供サービスから提供を受ける天気や気温などの予実データです。(3) は (1) や (2) のデータを Amazon SageMaker で開発した予測 AI が生成する電力需要量などの予測データです。

これらのデータを Amazon Timestream で利用する際に実施した設定や利用上の考慮点についてご紹介します。

Amazon Timestream のテーブル定義とデータ格納方法

AWS IoT Greengrass の MQTT トピックとペイロード設定

プラットフォームのエッジデバイスには AWS IoT Greengrass を利用し、 MQTT トピックとペイロードの定義に準拠して、プラットフォームの AWS IoT Core に対して、電力計、スマートメータ―、センサー、蓄電池、 V2H などの機器毎に定義されたトピックに対してデータを毎分送信し、 AWS IoT Core から Amazon Timestream へのデータを格納する仕組みとなっています。AWS IoT Greengrass の MQTT トピックとペイロードの定義が、 Amazon Timestream にデータをどのように格納するか決めるキー情報となります。

MQTT トピックの定義（※実際の定義とは異なります）

タイプ / データ保有者 ID / サイト ID / 機器 / デバイス ID

MQTT トピックの例（※実際の定義とは異なります）

ingestion / owner001 / site1234 / smartmeter / 98765

MQTT ペイロードの例（※実際の定義とは異なります）

{
    "errorCode": "err001",
    "deviceStatus": 20,
    "gridPower": 1000,
    "solarPower": 2000,
    "timestamp": 1615363560
}

AWS IoT ルールによる Amazon Timestream へのデータ格納

エッジデバイスから MQTT 送信されたデータは、 AWS IoT ルールによる評価を介して Amazon Timestream のテーブルに書き込まれます。この設定の際に必要となるのが Amazon Timestream のテーブル定義ですが、時系列データに特化した Amazon Timestream は RDB とは設計の方法が異なり、ディメンション（属性情報）、タイムスタンプ、メジャー（測定値）の 3 つを設計することになります。まずディメンションは、どのようにデータを取り出したいか、どのような単位で集計を行いたいかを考慮して設定することになりますが、今回は下表のようにデータ保有者 ID 以降のトピックをすべて設定しました。

ディメンションの設定（※トピックの定義は、「タイプ / データ保有者 ID / サイト ID / 機器 / デバイス ID 」となっており、トピックの定義順が以下の topic 配列の番号に該当します）

ディメンション名	ディメンション値
owner	${topic(2)}
site	${topic(3)}
equipment	${topic(4)}
deviceId	${topic(5)}

次に、 AWS IoT Core から Amazon Timestream へデータを送信する場合、タイムスタンプを省略すると処理時刻が自動で登録されます。ただし今回はペイロードに含まれる各機器での計測時刻（ UnixTime ）を使用したかったため、下表のようにペイロードの timestamp を設定しました。

タイムスタンプの設定

値	単位
${timestamp}	SECONDS

最後にメジャーですが、こちらは設定された SQL ステートメントの結果の属性の名前が measure_name に設定される仕組みになっているので、以下のような SQL ステートメントを登録しました。計測値は measure_value::data-type に設定されますが、 cast() 関数を使用して別のデータ型にキャストすることも可能です。

SQL ステートメントによるメジャーの設定

SELECT
CAST( errorCode AS String ) as errorCode,
CAST( deviceStatus AS Int ) as deviceStatus,
CAST( gridPower AS Double ) as gridPower,
CAST( solarPower AS Double ) as solarPower
FROM 'ingestion/+/+/smartmeter/+'

これらディメンション、タイムスタンプ、メジャーの設定により、馴染みの深い RDB のスキーマ定義と同様に表現すると、下表のようなテーブルレイアウトになります。

列名	型	属性タイプ
owner	Varchar	DIMENSION
site	Varchar	DIMENSION
equipment	Varchar	DIMENSION
deviceId	Varchar	DIMENSION
measure_name	Varchar	MEASURE_NAME
measure_value::double	Double	MEASURE_VALUE
measure_value::varchar	Varchar	MEASURE_VALUE
measure_value::bigint	Bigint	MEASURE_VALUE
time	timestamp	TIMESTAMP

実際にテーブルに格納されるデータは以下のようなイメージです。

owner	site	equipment	deviceId	measure_name	measure_value::double	measure_value::varchar	measure_value::bigint	time
owner001	site1234	smartmeter	98765	errorCode	–	“”	–	2021-03-10 08:05:00.000000000
owner001	site1234	smartmeter	98765	deviceStatus	–	–	20	2021-03-10 08:05:00.000000000
owner001	site1234	smartmeter	98765	gridPower	1500	–	–	2021-03-10 08:05:00.000000000
owner001	site1234	smartmeter	98765	solarPower	3000	–	–	2021-03-10 08:05:00.000000000
owner001	site1234	smartmeter	98765	errorCode	–	“err001”	–	2021-03-10 08:06:00.000000000
owner001	site1234	smartmeter	98765	deviceStatus	–	–	20	2021-03-10 08:06:00.000000000
owner001	site1234	smartmeter	98765	gridPower	1000	–	–	2021-03-10 08:06:00.000000000
owner001	site1234	smartmeter	98765	solarPower	2000	–	–	2021-03-10 08:06:00.000000000

Amazon Timestream にデータ格納する際の留意点

Amazon Timestream へのデータ格納は、ここまで説明してきた AWS IoT ルールによる方法に限らず、 AWS SDK / Timestream API を利用することも可能ですが、いずれの場合も留意しなければならないことがあります。それは、過去や未来のタイムスタンプを持つデータの書き込みです。

本プラットフォームの Amazon Timestream で取り扱うデータには、前述した通りエッジデバイスでの計測データだけでなく、他システムからサーバ連携で収集したデータや予測 AI による予測データなどが含まれます。他システムから提供される電力データには、現在の速報値だけでなく、日次確報値や月次確報値のような数日前、数か月前の日付のデータが存在します。また、予測 AI による予測データは未来日のデータです。Amazon Timestream のストレージにはメモリストアとマグネティックストアがありますが、利用開始当時はマグネティックストアに過去データ（到着遅延データ）を直接書き込むことはできませんでした。現在は 2021 年 11 月のアップデートでマグネティックストアに過去データの直説書き込みが可能です。一方で、未来のタイムスタンプを持つデータは現在のシステム時刻より最大 15 分進んだデータを書き込むことはできますが、 15 分より進んだデータについてはストレージタイプに関係なく書き込みを許されていません。

この問題を回避するために、本プラットフォームでは、タイムスタンプ（ time カラム）以外に measure_datetime というディメンションを追加して、メモリストアの保持期間よりも過去や未来のタイムスタンプが想定されるデータは time カラムを使わずに measure_datetime カラムを使用することで回避しました。この際、 time カラムには当日の 00:00 を設定して、予測の更新時にも上書きによりデータ件数が増加しないようにしています。

time カラムではない measure_datetime カラムでも以下のような方法で時系列関数の ago() や bin() を使うことが可能です。

FROM_ISO8601_TIMESTAMP(measure_datetime) > ago(30m)
bin(FROM_ISO8601_TIMESTAMP(measure_datetime), 30m)

引き続き、【寄稿】株式会社アイ・グリッド・ラボの太陽光 PPA 事業から蓄電池・ EV サービスまでの幅広い GX ソリューションでの Amazon Timestream 活用 (Part2) では Amazon Timestream のコスト削減対策についてご紹介します。

AWS for Energy について詳細はこちらをご覧ください。

Amazon Web Services ブログ