システム統合ガイド
構築を始める前に
このガイドについて
これは、物理的な蓄電池システムをTensor Cloudの蓄電池最適化サービスに接続するための技術ガイドです。以下を対象としています：
- システムインテグレーター - 蓄電池最適化ソリューションを実装する方
- EMS開発者 - Tensor Cloudへのゲートウェイ接続を構築する方
- 技術担当者 - 蓄電池の運用に責任を持つ方
このガイドは2つの部分で構成されています：ガイド本体と、AsyncAPI形式の通信プロトコル仕様です。ガイドは統合プロセス、技術要件、運用責任の概要を提供します。AsyncAPI仕様には、詳細なメッセージスキーマ、テレメトリ要件、コマンド構造が含まれています。
統合プロセスを開始する前に、AsyncAPI仕様に精通することを強く推奨します。これには通信プロトコルの詳細と、自動クライアントコード生成のガイダンスが含まれているためです。
:::important 重要 Tensor Cloudとの統合を構築する前に、詳細なガイダンスとTensor Cloud開発ワークスペースへのアクセスを得るために、必ず弊社の技術チームにご連絡ください。 :::
Tensor Cloudの仕組み
蓄電池最適化APIは、Tensor Cloudの最適化エンジンと現場のエネルギー管理システム（EMS）間のリアルタイム通信を通じて、蓄電池システムの自動化された高度な管理を可能にします。経済的に最適な充放電スケジュールを作成することで、蓄電池システムの価値を最大化することを目的としています。
これは、蓄電池システムおよびその他の現場のハードウェア（太陽光システム等）からの技術信号を集約し、それらを電力市場やその他のソースからの経済信号と組み合わせることで、経済的に最適化された蓄電池運用スケジュールに到達します。
蓄電池システムの物理制御とサイトテレメトリの収集については、Tensor Cloudは専門プロバイダーによって運用・提供されるEMSに依存しています。Tensor Energyは、あらゆる規模での物理的な統合に対応できる確立されたパートナーを多数有していますが、技術的に実現可能な範囲で、特定のEMS事業者に限定せず、どの事業者とも連携することができます。
システム概要
Tensor Cloudは現在、1系統連系点あたり、蓄電池1基、太陽光システム1基、需要家1つにのみ対応しています。
蓄電池システムの構成
Tensor Cloudは蓄電池最適化のための3つの主要な利用ケースを対応しています：ACリンク併設型、DCリンク併設型、および系統用蓄電池です。
:::important 重要 各利用ケースには、EMSが送信する必須テレメトリデータに関して異なる要件があります。詳細はテレメトリセクションをご参照ください。 :::
ACリンク併設型
これは、元の太陽光システム構成をFIT/FIP認定を失うことなく根本的に変更できない改修FIP変換プロジェクトでよく見られるケースです。蓄電池と太陽光システムはそれぞれのインバータを介して電力を交換し、場合によっては需要家もACを介して接続されます。
DCリンク併設型
DCリンク併設型では、蓄電池と太陽光発電がDC側で接続されており、より効率的な電力転送を可能にします。ACリンクと同様、需要家も対応しています。この利用ケースは、蓄電池統合を最適化するためにシステムをゼロから設計できる新規設置で一般的です。
系統用蓄電池
系統用蓄電池は、太陽光や需要家と併設されていません。電力市場への排他的参加のために商用システムとして運用されることが多いです。
役割と責任
Tensor Cloudは、パートナーおよび蓄電池システムオーナーとの共有責任モデルの下で動作します。各当事者は、蓄電池最適化サービスの統合と運用において特定の役割と責任を持ちます。
| 当事者 | 責任 |
|---|---|
| Tensor Energy | • 経済最適化とスケジュール生成 • 蓄電池システムオーナー設定（例：最小/最大SoE）のソフト保証 |
| インテグレーター/EMS | • 蓄電池オーナーとの連携によるEMSアップタイム管理と保証 • プロトコル仕様に従ったサイトハードウェアからの正確なテレメトリ読み取り • TSO制約（例：蓄電池ランプ率、出力制御、データログ要件）のローカル実行 • 蓄電池システムオーナー設定（例：最小/最大SoE）のハード保証 • 緊急対応とEMSハードウェア故障対応 |
| 蓄電池システムオーナー | • インバランス責任（契約条件により、Tensor Energyと共有される場合がある） • TSOおよびOCCTOなどの他のステークホルダーとの関係管理（契約条件により、Tensor Energyと共有される場合がある） |
| 蓄電池OEM | • ハードウェア保守とサポート（蓄電池システムオーナーとの契約条件による） • 蓄電池ファームウェアアップデートとバグ修正 |
Tensor Cloudへの接続
通信
Tensor Cloudが蓄電池最適化に使用する通信プロトコルは、TLS 1.2+上のMQTT（Message Queuing Telemetry Transport）3.1.1です。このプロトコルは、EMSとTensor Cloud間の軽量で信頼性の高いpub/sub情報交換のために設計されています。
エンドポイント
Tensor Cloudの蓄電池最適化サービスは、以下のMQTTブローカーエンドポイントを通じてアクセス可能です：
テスト環境: mqtt.staging.tensorenergy.jp:8883
本番環境: mqtt.tensorenergy.jp:8883
テスト環境は統合開発フェーズと統合後のテストで使用されます。本番環境は統合が完了し検証された後の運用で使用されます。
認証
Tensor CloudはMQTTブローカーとの安全な認証にX.509証明書を使用します。各EMSゲートウェイ端末またはソフトウェアアプリケーションは独自のユニークな証明書を持つ必要があります。Tensor Energyの技術担当者が、ご依頼から24時間以内に開発環境および本番環境の証明書を提供します。
証明書はMQTTブローカー上の特定のトピックにスコープされています。つまり、各証明書は認可されたトピックのみに発行（publish）および購読（subscribe）できます。これにより、EMSは設置された現場に関連するデータとコマンドのみとやり取りできることが保証されます。
Tensor が発行する証明書には有効期限がなく、定期的なローテーションも既定では必要ありません。定期ローテーションを必要とするインテグレーターまたはその顧客は、Tensor の技術チームに依頼できます。
各証明書は同時に1つのMQTT接続でのみ使用できます。これはAWS IoT Coreによって強制されます: 同じ証明書で2つ目の接続が開かれた場合、古いセッションが切断されます。
QoS（Quality of Service）
Tensor CloudはMQTT QoSレベル0と1に対応しています。QoS 0ではメッセージが最大1回、QoS 1では最低1回配信されます。QoS 1の場合、MQTTのトランスポート層でブローカーがメッセージ配信の確認応答を処理するため、クライアント側からブローカーレベルの確認応答メッセージを別途送る必要はありません。
これは、EMSが受信した各コマンドに対して ack-cmd/{siteId} 上で送信するアプリケーションレベルの確認応答とは別物です（コマンドのライフサイクルを参照）。これらの応答は配信確認ではなくバリデーション結果を運ぶため、QoSによらず常に必要です。
MQTTトピック
EMSとTensor Cloud間のすべての通信は、パブリッシュ・サブスクライブ方式でMQTTトピックを通じて行われます。トピック構造は直感的に設計されており、系統接続点および端末識別子に基づく階層形式に従います。
サイトIDとゲートウェイID
関係性の理解
- サイトID（
siteId）: 単一の物理的な設置場所（例：1つの蓄電池システム）を表します。コマンドはサイトレベルに送信されるため、この識別子はコマンドトピックで使用されます。 - ゲートウェイID（
gatewayId）: サイトのテレメトリを収集しコマンドを実行する特定のEMS端末またはソフトウェアインスタンスを表します。テレメトリトピックでどのゲートウェイ端末が報告しているかを区別するために使用されます。
一般的な構成
-
サイトごとに1つのゲートウェイ（標準的）: 1つの物理EMS端末が現場に設置される場合
- 例: サイト
si_qcf9gnにゲートウェイgw_0uv3tf - このサイトからのすべてのテレメトリは
dt/si_qcf9gn/gw_0uv3tf/...を使用 - コマンドは
cmd/si_qcf9gn/...に送信
- 例: サイト
-
ホットスタンバイ: プライマリとスタンバイの両方の端末がMQTTブローカーに接続
- 例: サイト
si_qcf9gnにゲートウェイgw_0uv3tf（プライマリ）とgw_dwj4n2（スタンバイ） - 両方の端末が
cmd/si_qcf9gn/...を購読 - アクティブなゲートウェイのみがテレメトリの配信、コマンドの確認応答、スケジュールの実行を行います。スタンバイのゲートウェイはコマンドを受信しますが、アクティブに昇格するまで ack も実行も行いません。これにより
ack-cmdメッセージの重複とスケジュールの二重実行を防ぎます。プライマリ/スタンバイの調整は EMS パートナーの責任です。 - 障害時、スタンバイが引き継ぎ、
dt/si_qcf9gn/gw_dwj4n2/.../ack-cmd/si_qcf9gnを使用してテレメトリ、ack、スケジュール実行を開始します。 - 各ゲートウェイは独自の証明書を持つ
- 例: サイト
-
コールドスタンバイ: プライマリ端末のみがMQTTブローカーに接続
- 例: サイト
si_qcf9gnにゲートウェイgw_0uv3tf（プライマリ）とgw_dwj4n2（スタンバイ） - プライマリが
dt/si_qcf9gn/gw_0uv3tf/...を使用してテレメトリを配信 - スタンバイ端末は現場に物理的に存在するが、ブローカーには接続されていない
- プライマリ障害時、スタンバイが接続し
dt/si_qcf9gn/gw_dwj4n2/...を使用して配信 - 各ゲートウェイは独自の証明書を持つ
- 例: サイト
重要な注意事項
- 各証明書は、認可されたサイトのトピックのみに発行・購読できます
- 冗長性設定の場合、各物理ゲートウェイ端末は独自の証明書を持つ必要があります
- 1つの証明書は、ブローカーへの1つの同時接続にのみ使用できます
トピック概要
メッセージ形式
MQTTブローカーに発行されるすべてのメッセージはJSON形式を使用します。ペイロード構造はプロトコルスキーマで定義されており、JSONスキーマで表現されたテレメトリメッセージとコマンド形式が含まれています。スキーマは、必須フィールド、データ型、検証ルールを含む各メッセージタイプの詳細な定義を提供します。
タイムスタンプ境界規則
プロトコルのすべての時間枠は、左閉右開の境界を使用します：[start_ts, end_ts)
この規則は以下に適用されます：
- ウィンドウエネルギーテレメトリ（
measurement_value.start_tsおよびmeasurement_value.end_ts） - 出力制御スケジュール（
start_tsおよびend_ts） - 蓄電池電力コマンドスケジュール（
control.schedule[].start_tsおよびcontrol.schedule[].end_ts） - 一次需給調整市場（オフライン）コマンドスケジュール（
control.schedule[].start_tsおよびcontrol.schedule[].end_ts）
例： end_ts が 2024-01-04T10:30:00.000+09:00 の時間枠は、10:30:00を含まないすべての時間を含みます。つまり、10:29:59.999... は含まれますが、10:30:00.000 は含まれません。
この規則により、隣接する時間枠がギャップや重複なくシームレスに接続されます：
- ウィンドウ1：
[10:00:00, 10:30:00)→ 10:00:00を含み、10:30:00を除外 - ウィンドウ2：
[10:30:00, 11:00:00)→ 10:30:00を含み、11:00:00を除外
Tensor Cloudへのテレメトリ送信
発行する内容
現場のテレメトリ（例：メーター放電、太陽光発電量、蓄電池SoE）は、EMSによって統一されたdt/トピックプレフィックスを使用して送信されます。その後にサイトID、ゲートウェイ端末ID、およびテレメトリの種類（ライフタイム、ウィンドウ、瞬時、状態）に特有の末尾が続き、以下の形式になります：
ライフタイムメトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/lifetime
ウィンドウメトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/energy/{window}
瞬時メトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/power
状態メトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/state
Site IDとGateway IDは、各系統接続点とそのEMSゲートウェイ端末に割り当てられた一意の識別子です。各証明書セットと共にTensor Energyの技術担当者から提供されます。
テレメトリの種類とその定義については、以下の表とプロトコルスキーマをご参照ください。
テレメトリデータタイプ
Tensor Cloudは各メトリックに対して4種類のテレメトリデータをサポートしています。以下の表は、データタイプ、MQTTトピックパターン、形式、および要件の関係を示しています：
| タイプ | MQTTトピックパターン | 単位 | 値のセマンティクス | 必須? |
|---|---|---|---|---|
dt/{siteId}/{gatewayId}/{metric}/power | kW | 測定時点の瞬時電力値。 すべての値 ≥ 0（方向はメトリック名でエンコード）。 | 高頻度（≤10分）で送信すると精度が向上しますが、エネルギー読み取り値の代替にはなりません。 | |
dt/{siteId}/{gatewayId}/{metric}/energy/{window} | kWh | 特定の時間枠（例：PT30M = 30分）で消費/生成されたエネルギー。 すべての値 ≥ 0。 | 最適化が機能するには、少なくとも1つのエネルギー読み取りタイプを送信する必要があります。 | |
dt/{siteId}/{gatewayId}/{metric}/lifetime | kWh | 設置以降の累積エネルギー（増加カウンター、電力メーターと同様）。 Tensor Cloudはカウンターリセットを処理します。 すべての値 ≥ 0。 | 最適化が機能するには、少なくとも1つのエネルギー読み取りタイプを送信する必要があります。 | |
dt/{siteId}/{gatewayId}/{metric}/state | kWh | 測定時点の瞬時状態値（例：蓄電池の充電エネルギー量 battery_soe）。すべての値 ≥ 0。 | 最適化が機能するには、蓄電池の充電エネルギー量（ battery_soe）を送信する必要があります。 |
:::important 重要 EMSは少なくとも1つのエネルギー読み取りタイプ（ウィンドウまたはライフタイム）を送信する必要があります。これはTensor Cloudの蓄電池最適化が正常に機能するために必須です。瞬時電力読み取り値は任意であり、頻繁に送信すると精度が向上しますが、エネルギー読み取り値の代替にはなりません。 :::
データが取得できない場合
このガイダンスは、measurement_value.value が単一の数値である数値系テレメトリ（瞬時電力、ウィンドウエネルギー、ライフタイムエネルギー、蓄電池状態、日射量）に適用されます。
EMS がある時刻に対してリソース（蓄電池、インバータ、メーター等）から数値を取得できない場合、該当メトリックのその時刻分のパブリッシュをスキップしてください。 データが取得できるようになり次第、パブリッシュを再開します。
value: nullは無効です:measurement_value.valueはnumber型として定義されているため、nullを送るとスキーマバリデーションに失敗します。value: 0も非推奨です: 本物のゼロ測定値と区別がつかず、最適化エンジンが実データとして扱ってしまいます。- リソース側の障害が長期間継続する場合は、
dt/{siteId}/{gatewayId}/alertトピックに適切なAlertCodeを付したAlertEventをパブリッシュし、上流の問題を Tensor Cloud に通知してください。
curtailment のような構造化テレメトリ（measurement_value がスカラーではなくスケジュール配列）は別のセマンティクスです。観測可能な情報をパブリッシュし、ソースデータの制約は Tensor チームへ別途共有してください。
すべての利用ケースに共通
| テレメトリ名 | 説明 | |
|---|---|---|
meter_export_ac | 系統接続メーターで測定された系統に輸出された電力量。 | |
meter_import_ac | 系統接続メーターで測定された系統から輸入された電力量。 | |
battery_soe | 蓄電池システムのState of Energy（SoE）（kWh）。 現在この瞬間に蓄電池に蓄積されている電力量（State of Chargeの kWh 相当）。 有効範囲：0 ≤ battery_soe ≤ battery_energy_remaining。 | |
battery_energy_remaining | セル劣化および故障セルを考慮した、定格温度（通常約25°C）における蓄電池システムの総利用可能エネルギー容量（kWh）。 これは蓄電池が保持できる最大エネルギーを表し、劣化や温度効果による容量変化時に更新する必要があります。 頻繁に変化する battery_soe とは異なり、この値は通常1日1回、または重要な容量変化が発生した際に更新されます。 | |
grid_to_load_ac | メーターからオンサイト電気負荷（例：工場）に送られる電力量。 オンサイト負荷が存在する場合は必須。 | |
load_demand_ac | オンサイト電気負荷（例：工場）によって消費されるエネルギーの総量。grid_to_load_acとAC連系の場合はbattery_to_load_ac、DC連系の場合はinverter_to_load_acの合計。オンサイト負荷が存在する場合は必須。 | |
curtailment | オンサイト出力制御装置からEMSによって捕捉されたTSOによる出力制御スケジュール。1回のパブリッシュで任意の期間（例: 当日+翌日）および任意の区間数を含めることができ、実質的な上限はMQTTペイロードサイズ（AWS IoT Coreでは128 KB）のみです。TSOから固定スケジュール（低優先）と更新スケジュール（高優先）の両方が提供される場合、EMSはこれらを統合・解決した実効スケジュールをパブリッシュしてください。各区間には start_ts、end_ts、limit_percent（0〜100、容量に対する許容出力の割合）が含まれます。 |
蓄電池容量メトリクスの理解
| メトリック | 説明 | Tensor Cloudへの送信 |
|---|---|---|
battery_energy_remaining | 劣化および故障セルを考慮した有効蓄電池容量(kWh) | 1日1回 |
battery_soe | 蓄電池に蓄積されている現在のエネルギー(kWh)。計算式: SoC% × battery_energy_remaining | 1〜10分ごと |
SoC パーセンテージから battery_soe を計算する際は、常に battery_energy_remaining(有効容量)で乗算し、定格容量では乗算しないでください。
例: 定格容量3,000 kWhの蓄電池が、有効容量2,800 kWhに劣化し、SoC 50%の場合:
- 正しい:
battery_soe = 50% × 2,800 kWh = 1,400 kWh - 誤り:
battery_soe = 50% × 3,000 kWh = 1,500 kWh(誤った最適化の原因となります)
AC連系蓄電池システム
| テレメトリ名 | 説明 | |
|---|---|---|
solar_net_generation_ac | 出力制御を差し引いた後の太陽光発電。solar_to_load_ac、solar_to_battery_ac、およびsolar_to_grid_acの合計。 | |
battery_charge_ac | 通常蓄電池メーターまたは監視システムで測定される、蓄電池システムに充電される電力量。grid_to_battery_acとsolar_to_battery_acの合計。 | |
battery_discharge_ac | 通常蓄電池メーターまたは監視システムで測定される、蓄電池システムから放電される電力量。battery_to_grid_acとbattery_to_load_acの合計。 | |
solar_to_grid_ac | 太陽光システムからメーターに直接送られる電力量。 | |
solar_to_battery_ac | 太陽光システムから蓄電池に送られる電力量。 | |
solar_to_load_ac | 太陽光システムからオンサイト電気負荷（例：工場）に送られる電力量。 | |
battery_to_grid_ac | 系統接続メーターで測定される、蓄電池から系統に送られる電力量。 | |
battery_to_load_ac | 蓄電池からオンサイト電気負荷（例：工場）に送られる電力量。 | |
grid_to_battery_ac | 系統接続メーターで測定される、系統から蓄電池に送られる電力量。蓄電池システムが系統から充電可能な場合は必須。 | |
irradiation | 発電所に設置された日射量センサーの測定値（kW/m2）。太陽光発電予測の精度向上と蓄電池充電の最適化に使用。 dt/{siteId}/{gatewayId}/irradiationに配信。 |
DC連系蓄電池システム
| テレメトリ名 | 説明 | |
|---|---|---|
solar_generation_dc | DC側で測定される太陽光システムによって発電される電力量。solar_to_battery_dcとsolar_to_inverter_dcの合計。 | |
battery_charge_dc | DC側で測定される、蓄電池システムに充電される電力量。solar_to_battery_dcとinverter_to_battery_dcの合計。 | |
battery_to_inverter_dc | 蓄電池からサイトインバータに送られる電力量。 DC側で測定。 | |
inverter_net_output_ac | サイトインバータのAC側出力の総量。inverter_to_load_acとinverter_to_grid_acの合計。AC側で測定。オンサイト電気負荷がある場合は必須。 | |
solar_to_battery_dc | 太陽光システムから蓄電池に送られる電力量。 DC側で測定。 | |
solar_to_inverter_dc | 太陽光システムからサイトインバータに送られる電力量。 DC側で測定。 | |
inverter_to_battery_dc | インバータから蓄電池に送られる電力量。 DC側で測定。 | |
inverter_to_load_ac | インバータからオンサイト電気負荷（例：工場）に送られる電力量。 AC側で測定。オンサイト負荷が存在する場合は必須。 | |
inverter_to_grid_ac | インバータから系統に送られる電力量。 AC側で測定。 | |
grid_to_inverter_ac | 系統からインバータに送られる電力量。 AC側で測定。蓄電池システムが系統から充電できる場合は必須。 | |
irradiation | 発電所に設置された日射量センサーの測定値（kW/m2）。太陽光発電予測の精度向上と蓄電池充電の最適化に使用。 dt/{siteId}/{gatewayId}/irradiationに配信。 |
系統用蓄電池システム
系統用蓄電池システムは、上記の「すべての利用ケースに共通」セクションに記載されたテレメトリのみが必要です。併設の太陽光発電がないため、日射量テレメトリは不要です。
発行要件とタイミング
テレメトリ発行要件
| メッセージタイプ | 最小頻度 | 推奨頻度 |
|---|---|---|
| エネルギーテレメトリ（ウィンドウ/ライフタイム） | 10分ごと | 1分ごと |
| 瞬時電力（利用可能な場合） | エネルギーと同じかそれ以上 | 1分以下 |
蓄電池状態（battery_soe） | 10分ごと | 1分ごと |
battery_energy_remaining | 1日1回 | 1日1回 |
アラートスナップショット（alertState） | 10分ごと | 5分ごと |
アラートイベント（alertEvent） | 状態変化時に即座 | N/A |
| 出力制御スケジュール | TSOからの更新時 | N/A |
一次調整力アセスメントⅡ用の1秒電力（*/power、一次調整力約定コマ） | 1秒ごと（一次調整力約定コマのみ） | 1秒ごと |
主要原則
- 異なるテレメトリタイプは、利用可能になり次第、相互に独立して発行する必要があります
- アラートイベントは、ハードウェアレジスタの状態が変化した際に即座に発行する必要があります
- アラーム状態や重要な状態変更は即座の発行をトリガーする必要があります
:::important 重要 EMSが必要なテレメトリを定期的に送信しない場合、Tensor Cloudは蓄電池充放電スケジュールの生成を停止します。 :::
イベントとアラート
アラートは、EMSからTensor Cloudへ障害および状態を通信します。 2つの補完的なチャネルが使用されます：
dt/{siteId}/{gatewayId}/alert(alertEvent) → アラートが状態を変更したときのデルタ更新（statusがactiveまたはclearedになったとき）。dt/{siteId}/{gatewayId}/alert/active(alertState) → 現在アクティブなすべてのアラートの定期的な完全スナップショット。
Tensor Cloudは両方のチャネルを使用します：
alertEventはアラートの変更に対する迅速な反応を可能にします。alertStateはイベントが失われた場合の堅牢性を保証し、完全なアクティブ状態の再構築を可能にします。
アラートメッセージのフロー
- ハードウェアレジスタが
0 → 1に遷移すると、EMSはmeasurement_value.status = activeでalertEventを発行します。 - 次のスナップショットで、EMSはこのアクティブなアラートを含む
alertStateを発行します（EMSは少なくとも10分ごとまたはシステム起動時のいずれか早い方でalertStateを発行する必要があります）。 - レジスタが
1 → 0に遷移すると、EMSはmeasurement_value.status = clearedでalertEventを発行します。 - アラートがアクティブなままの間、EMSはすべての
alertStateでそのアラートのlast_seen_tsを更新します。
アラートコードリファレンス
| コード | サブシステム | 説明 |
|---|---|---|
BATT_SOC_LOW | 蓄電池 | 蓄電池の充電状態が最小しきい値を下回り、運用に必要なエネルギー可用性が不足するリスクがあります。 |
BATT_SOH_DEGRADED | 蓄電池 | 蓄電池の健全性が期待される性能と比較して劣化しており、交換計画が必要な可能性のある老朽化または損傷を示しています。 |
BATT_OVERTEMP | 蓄電池 | 蓄電池の温度が安全な動作限界を超え、劣化の加速または熱損傷のリスクが増加しています。 |
BATT_COMM_FAIL | 蓄電池 | EMSがバッテリー管理システム（BMS）と通信できません。蓄電池は動作し続ける可能性がありますが、状態と制御は利用できません。 |
BATT_OTHER | 蓄電池 | 定義されたカテゴリに該当しないその他の蓄電池関連の障害。 |
PV_COMM_FAIL | 太陽光発電 | EMSがインバータと通信できません。インバータは動作し続ける可能性がありますが、監視および制御機能は利用できません。 |
PV_OTHER | 太陽光発電 | 定義されたカテゴリに該当しないその他の太陽光発電関連の障害。 |
CURT_COMM_FAIL | 系統/TSO | EMSが出力制御装置との通信を失い、TSOの出力制御スケジュールを取得できません。 |
UNKNOWN_FAULT | 不明 | 障害が報告されましたが、そのタイプが認識されないか、既存のアラートコードにマップされていません。開発段階でこのリストにアラートコードを含めることについて議論するために、Tensor Energyの技術チームにお問い合わせください。 |
テレメトリエラー
EMSがサイトテレメトリデータをTensor Cloudに送信できない場合（例：ネットワーク問題のため）、EMSアプリケーションロジックは以下のガイドラインに従う必要があります：
- テレメトリをローカルで最大7日間保持する。 これより古いバッファ済みデータは破棄するか要約する。
- 再生順序：ライブサンプルを優先する。 送信待ちのライブサンプルがなくなった場合に限り、EMSはバックフィル履歴の送信を再開する。
- サンプルを再送する場合は元の
message_idを再利用する。 Tensor Cloud はmessage_idで重複排除を行うため、同じテレメトリ読み取り値は再試行のたびに常に同じIDを持たなければならない。 - 遅延ウィンドウの締切なし。 Tensor Cloudは利用可能な最良のデータで動作する。ウィンドウエネルギーやライフタイムサンプルは、ウィンドウが閉じてからどれだけ時間が経過しても受け付けられる。
- 分析用にエラー詳細をログに記録する。
- MQTTブローカーのレート制限を避けるため、指数バックオフを実装する。
Tensor Cloudからのコマンドの受信
コマンドのトピックとフロー
コマンド（例：蓄電池の充放電スケジュールまたは一次調整力入札スケジュールを含む）は、Tensor Cloudによって統一されたcmd/トピックプレフィックスを使用して送信され、その後にサイトIDとコマンドタイプが続き、以下の形式になります：
蓄電池出力指令コマンド：
cmd/{siteId}/battery/power
蓄電池一次調整力入札コマンド：
cmd/{siteId}/battery/fcr
コマンドタイプとその定義のリストについては、プロトコルスキーマをご参照ください。
コマンドライフサイクルシーケンス
確認応答（ack-cmd）は、コマンドを受信して解析した直後に送信する必要があります。実行時ではありません。
EMS はコマンドペイロードに含まれる res_topic 値にレスポンスをパブリッシュします。AsyncAPI のチャネルアドレス（ack-cmd/{siteId}）は例示的なものであり、ペイロードの res_topic が正となります。
蓄電池出力指令スケジュール
蓄電池充放電スケジュールはcmd/{siteId}/battery/powerに2つの優先順位層で送信されます：
- 毎30分（15分および45分）に、30分ごとに1つのセットポイントを持つ今後48時間をカバーするスケジュールが優先度2で送信されます
- 毎週月曜日、水曜日、金曜日の日本時間午前6時に、1日あたり3つのセットポイントを持つ1年をカバーする簡略化された長期スケジュールが優先度1で送信されます
出力指令スケジュールは、簡易指令システムからの需給調整市場（一次オフライン以外）コマンドを各EMSに中継するためにも使用されます。これらのコマンドは、Tensor CloudがTSOから受信した際に送信されます。
蓄電池一次調整力入札スケジュールと基準出力の合成
一次調整力入札スケジュールはcmd/{siteId}/battery/fcrに送信され、周波数調整サービスに提供する容量を指定します。各スケジュール項目には以下が含まれます：
- 時間窓（3時間ブロックの開始/終了タイムスタンプ：6-9時、9-12時など）
- 入札する容量（kW）
一次調整力スケジュールは定期的な間隔では送信されず、通常フォールバックスケジュールも含まれません。調整力市場で入札が確定した場合にのみ送信されます。
一次調整力の基準出力
蓄電池が一次調整力モードで運用される場合、cmd/{siteId}/battery/powerに送信される通常の出力指令が基準出力を決定します。例えば、EMSが1500 kWの容量を持つ一次調整力スケジュールを受信し、同じ時間枠で-100 kWの通常の充放電コマンドを受信した場合、基準出力は-100 kWにシフトされます。
:::important 集約（VPP）リソースにおける動的更新
複数の蓄電池を1つの市場リソースとして集約するバーチャルパワープラント（VPP）リソースでは、スロットの進行中にTensor Cloudが蓄電池間で容量を再配分する必要が生じる場合があります。そのため、EMSはすでに開始しているFCRスロットに対して、更新後のFCR容量や出力基準を受信することがあり、他の進行中の区間と同様に即座に適用する必要があります。EMSは、運用中に出力基準（cmd/{siteId}/battery/power）とFCR容量（cmd/{siteId}/battery/fcr）の両方について、スロット境界だけでなくアドホックな変更に対応できる必要があります。
:::
一次調整力コマンドのキャンセル
一次調整力コマンドは、action: "cancel" を指定し、キャンセルする時間範囲を指定することでキャンセルできます。キャンセル：
- 優先度ルールを尊重：同等または低い優先度のコマンドのみキャンセル
- 任意の期間をキャンセル可能（単一の3時間ブロック、複数日、複数週など）
capacity_kwは省略しなければならない（時間範囲のみ指定。capacity_kwを含むキャンセル項目は拒否される）
キャンセルは市場入札がキャンセルされた場合に使用されます（例：必要なバッテリーSoCレベルに到達できない場合など）。入札は受渡の1時間前（ゲートクローズ）までキャンセル可能です。
スケジュール解釈ルール
すべてのコマンドスケジュール（出力指令および一次調整力）を解釈する際、EMSは以下のルールに従う必要があります：
- 優先度が勝つ。 低優先度スケジュールより高優先度スケジュールを実行する。
- 同じ優先度では
issue_tsでタイブレーク。 同じ時間帯をカバーするスケジュールが同じ優先度の場合、最新のissue_tsタイムスタンプを持つものを実行する。 - 完全なタイ → 後着が勝つ。
priorityとissue_tsの両方が同一の場合、最後に受信したコマンド（配線上で最後に到着したもの）が勝つ。 - 時間帯単位の置き換え。 新しいコマンドは、実際にカバーする時間帯についてのみ既存のスケジュールを置き換える。新しいコマンドの範囲外にある既存の区間は引き続き有効。
- コマンド内のギャップ。 単一コマンドのスケジュールが区間の間にギャップを残している場合、EMS はその時間帯をカバーする以前の有効なコマンドにフォールバックする。該当する以前のコマンドがない場合、EMS は
power_kw = 0（待機）を使用する。 - 出力指令のキャンセル機構なし。
BatteryPowerCommandにはaction: "cancel"が存在しない。実行中の出力スケジュールを「キャンセル」または上書きするには、Tensor Cloud は適切な優先度とpower_kw = 0（または別の置き換え）のスケジュールを該当時間帯に対して送信する。一次調整力コマンドは上記の明示的なaction: "cancel"機構を使用する。 - 進行中の区間は即座に実行する。 Tensor Cloud は、コマンドがカバーする時間帯がすでに開始した後（区間の途中であっても）にコマンドを発行することがある。区間の
start_tsが過去でend_tsが未来の場合、その区間は現在有効な区間であり、EMS は開始時刻を待たずに即座にそのセットポイントを適用する必要がある。（最後の区間のend_tsも過去にあるスケジュールのみが古いものとして拒否される。以下のバリデーションルールを参照。） - スケジュールが一切ない場合 → 停止する。 現在の時刻をカバーするコマンドがなく、現在の時刻に該当する以前の有効なコマンドもない場合、EMS は蓄電池を停止する。すなわち
power_kw = 0（待機）を保持し、現在の時刻をカバーするコマンドが到着するまで充放電を一切行わない。
すべてのコマンドメッセージには issue_ts フィールドが含まれており、これはTensor Cloudがコマンドを発行した時刻を示すISO-8601準拠のタイムスタンプです。このタイムスタンプは、同じ優先度で同じ時間帯をカバーする複数のコマンドがある場合に、どのコマンドを実行するかを決定するために不可欠です。
コマンドバリデーションルール
EMS は以下のコマンドを ack-cmd エラー応答で拒否する必要があります：
- 空のスケジュール —
control.scheduleが空配列。 - 単一コマンド内の重複区間 — 同じ
control.schedule内の 2 つ以上の区間が時間的に重複している。 - 古いスケジュール —
control.scheduleの最後の区間のend_tsが過去。（issue_ts自体はタイブレーク用であり、鮮度チェックには 使用しない。）
コマンド実行優先度ロジック
コマンドエラー
EMSが処理できないコマンドを受信した場合（例：不正なJSONまたはサポートされていないパラメータのため）：
ack-cmd/{siteId}トピックで適切なエラーメッセージで応答する- エラーが優先度と時間順で解決されるまで、前の有効なスケジュールを実行し続ける
EMSがコマンドスケジュールを受信しない場合（例：通信問題のため）は、前の有効なスケジュールを実行し続けてください。この場合は ack-cmd 応答を送信しません — Tensor Cloud が自身の側でコマンドの欠落を検出します。
アセスメントⅡ報告
蓄電池がオフラインリソース（監視方法がオフライン）として一次調整力市場に参入する場合、TSOはリアルタイムのテレメトリを受信しません。代わりに、1秒解像度の供出電力データから事後に応動を評価します（アセスメントⅡ）。このデータは、所定のExcel様式である様式35（一次調整力【オフラインリソース】供出電力提出用フォーマット【アセスメントⅡ用】）で提出します。
Tensor Cloudは、アグリゲーター（取引会員）に代わって様式35を作成し、属地TSOへメールで提出します（提出期限は、提供期間の翌月に属地TSOが通知した日の翌営業日）。そのために、Tensor Cloudはすべての一次調整力約定コマについて、EMSからの1 Hz電力テレメトリを必要とします。
この要件は一次調整力への参入に固有のものであり、最適化に必要なエネルギーテレメトリに追加されるものです。一次調整力に入札しないサイトには適用されません。
発行する内容
既存の瞬時電力トピック dt/{siteId}/{gatewayId}/{metric}/power に、1秒あたり1サンプル（1 Hz）を発行します。単位はkW、値は0以上です（向きは他のすべての電力テレメトリと同様にメトリック名で表現します）。各サンプルはちょうど1秒分とし、整数秒境界に揃えてください。前後の秒にまたがってはなりません。各値はその1秒間の1秒平均とし、ペイロードに aggregation: "average" と aggregation_window: "PT1S" を設定してください。また、measurement_ts にはその秒の開始時刻を設定してください（平均区間は [measurement_ts, measurement_ts + 1秒) であり、プロトコルの左閉右開 [start_ts, end_ts) 規則に準拠します）。計量器が瞬時値しか提供しない場合は、1 Hzでサンプリングしデフォルトの aggregation: "instant" のままでもかまいません。Tensor Cloudは各1 Hzサンプルをその秒の値として扱います。
運用するすべてのEMSゲートウェイ間でクロックを同期させ（フリート全体で時刻同期を徹底。例：NTP）、measurement_ts が正確かつJSTであることを確認してください。アセスメントⅡは各1秒サンプルをTSOの周波数および基準のタイムラインに対して固定の遅れ時間補正のみで突き合わせるため、わずかなタイムスタンプのずれでも、本来は適合するサンプルが許容範囲外となりコマが不適合になる可能性があります。
リソースのTSO登録方法に合致するメトリックを発行します：
| 登録 | 計測点 | 発行するメトリック（1 Hz） | Tensor Cloudが導出する正味計測電力 |
|---|---|---|---|
| サイトの受電点における正味電力 | meter_export_ac/power および meter_import_ac/power | meter_export_ac − meter_import_ac | |
| 蓄電池機器（機器点）における正味電力 | battery_discharge_ac/power および battery_charge_ac/power | battery_discharge_ac − battery_charge_ac |
どちらの登録が適用されるかは、リソースのTSO登録によって決まり、EMSが選択するものではありません。どちらのメトリック組を発行すべきか不明な場合は、運用開始前にTensorの技術担当者に確認してください。両方の計量値が利用可能な場合は両方を発行してもかまいません。Tensor Cloudは登録に合致する組を使用します。これらはAC側の計測値です。DCリンクシステムの場合は、Tensorの技術担当者にお問い合わせください。
発行するのは計測した生のAC電力のみです。Tensor Cloudが正味計測電力を導出し、送電端基準（系統損失補正を含む）に換算したうえで、登録された基準（発電計画／基準値）を差し引いて供出電力を算出し、様式35の形式に整えます。
対象コマと送信タイミング
TSOは毎月、当該リソースの一次調整力約定コマの中から最大8コマを無作為に選定し（その月の約定コマが8コマ以下の場合は約定コマ全て）、平常時のアセスメント対象とします。これに加えて系統事故等のコマ（異常時。例：電源脱落による周波数事象）が対象となります。様式35で提出するのは選定されたコマのみであり、その他の約定コマは提出されません。
選定は実需給の翌月以降に通知されるため、どのコマが選定されるかをお客様もTensor Cloudも事前に知ることはできません。1 Hzデータは、すべての一次調整力約定コマ（cmd/{siteId}/battery/fcr で一次調整力入札コマンドが送信された30分コマ。一次調整力入札スケジュールを参照）について発行してください。Tensor Cloudはこれを保持し、TSOが選定コマを通知した時点で該当コマのみを提出します。一次調整力スケジュールが一度も存在しなかったコマには1秒データは不要です。
各30分コマは、その1秒計測点の90%以上が許容範囲内に収まると要件適合と判定されるため、データ品質が重要です。欠測時のルールを適用し、読み取れないサンプルは 0 や null を送らずにスキップしてください。保持ウィンドウ内でのバックフィルは許容されますが、ライブサンプルが優先されます。
接続断と再送
ブローカーへの接続が切れた場合は、1秒サンプルをローカルにバッファし、接続が復旧したら再送してください。破棄しないでください。欠落した1秒ごとに「90%以上が許容範囲内」という基準に不利に働き、コマ全体が不適合となる可能性があり、そのコマがTSOにより後から選定される場合もあります。テレメトリのエラーハンドリングに従ってください。すなわち、再送時には各サンプルの元の message_id を再利用してTensor Cloudが重複排除できるようにし、ライブサンプルを先に送ってから欠落分をバックフィルします。
一次調整力約定コマの1秒データは、ローカルに60日間保持してください。これは一般のテレメトリに適用される7日間より長い期間です。アセスメントⅡの依頼は実需給の翌月に届くため、60日間のローカルコピーを保持しておくことで、データがまだTensor Cloudに届いていない場合や、コマが遅れて照会された場合でも再提出できます。データがTensor Cloudに届いた後は、そちらでも保持されます。
検証と本番移行
実装プロセス
1. 初期連絡
Tensor Cloudの蓄電池最適化サービスとの統合にご興味をお持ちの場合は、弊社ウェブサイトのお問い合わせフォームからお気軽にご連絡ください。弊社チームが統合プロジェクトの詳細を議論するための初回ミーティングのスケジュールをご返答いたします。利用ケースの複雑さによっては、この段階で複数のミーティングが必要な場合があります。
また、蓄電池システムオーナーの運用・経済要件、および統合プロセスに影響を与える可能性のある特定の制約を議論するため、Tensor Energyの代表者を含む早期の会話も推奨します。
2. 証明書設定
初回ミーティング後、弊社技術チームがステージングMQTTブローカーとの安全な認証のための初期開発X.509証明書セットを提供します。
3. 統合フェーズ
EMSソリューションの成熟度と柔軟性に応じて、統合プロセスには数日から数ヶ月かかることが予想されます。このプロセス中、弊社技術チームはMQTTブローカーへの初期接続の確立と通信プロトコルに関するご質問にサポートを提供できます。
弊社側でカスタマイズが必要な場合、弊社チームは可能な限りお客様の開発タイムラインとこの作業を同期させます。
テストと検証
EMSインテグレーターが実装を検証しやすくするため、Tensor Cloudはテスト環境を提供しています。本番環境とテスト環境の違いは以下のとおりです：
- 両環境間でのデータと操作の完全な分離
- テストでは、Tensor Cloudは
ack-dt/{siteId}/{gatewayId}トピックでEMSデバイスからのすべてのテレメトリメッセージにerror/okの明示的な応答を返します
初期統合が完了すると、統合テストを実行するため調整を行います。これには以下が含まれます：
- テレメトリデータ発行の検証
- コマンド処理と応答のテスト
- 適切なエラーハンドリングと復旧メカニズムの確保
テストプロセスの詳細については、Tensor Energyの技術担当者にお問い合わせください。
リファレンス
エラーコード
プロトコルはすべてのエラー面で標準化されたエラーコードを使用します：
MESSAGE_MALFORMED: メッセージは有効なJSONではないMISSING_FIELD: 必須フィールドが欠けているTYPE_MISMATCH: フィールドの型が正しくないFIELD_OUT_OF_RANGE: 数値が有効範囲外TIME_WINDOW_INVALID: 無効な時間ウィンドウまたはスケジュール。いずれかの区間でstart_ts >= end_ts、単一コマンド内の重複区間、空のschedule配列に使用する。DUPLICATE: 重複メッセージまたは識別子（例：同じIDのメッセージが2回送信される）EXPIRED: 検証時点でスケジュールの最後の区間のend_tsが過去である。RESOURCE_UNAVAILABLE: 必要なリソースが利用できない（例：EMSと蓄電池システム間の接続が切断）INTERNAL_ERROR: 他のエラータイプでカバーされない内部システムエラー
エラー面
- CommandResponse.errors[]: 機械実行可能なコマンド実行結果
- TelemetryFeedback.code: 検証エラーコード（ステージングのみ）
リソース
- AsyncAPIスキーマファイル: スキーマをダウンロード
- プロトコル仕様: オンラインドキュメント