システム統合ガイド
このガイドについて
これは、物理的な蓄電池システムをTensor Cloudの蓄電池最適化サービスに接続するための技術ガイドです。以下を対象としています：
- システムインテグレーター - 蓄電池最適化ソリューションを実装する方
- EMS開発者 - Tensor Cloudへのゲートウェイ接続を構築する方
- 技術担当者 - 蓄電池の運用に責任を持つ方
このガイドは2つの部分で構成されています：ガイド本体と、AsyncAPI形式の通信プロトコル仕様です。ガイドは統合プロセス、技術要件、運用責任の概要を提供します。AsyncAPI仕様には、詳細なメッセージスキーマ、テレメトリ要件、コマンド構造が含まれています。
統合プロセスを開始する前に、AsyncAPI仕様に精通することを強く推奨します。これには通信プロトコルの詳細と、自動クライアントコード生成のガイダンスが含まれているためです。
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リンク併設型、および系統用蓄電池です。
各利用ケースには、EMSが送信する必須テレメトリデータに関して異なる要件があります。詳細はテレメトリセクションをご参照ください。
ACリンク併設型
これは、元の太陽光システム構成をFIT/FIP認定を失うことなく根本的に変更できない改修FIP変換プロジェクトでよく見られるケースです。蓄電池と太陽光システムはそれぞれのインバータを介して電力を交換し、場合によっては需要家もACを介して接続されます。
DCリンク併設型
DCリンク併設型では、蓄電池と太陽光発電がDC側で接続されており、より効率的な電力転送を可能にします。ACリンクと同様、需要家も対応しています。この利用ケースは、蓄電池統合を最適化するためにシステムをゼロから設計できる新規設置で一般的です。
系統用蓄電池
系統用蓄電池は、太陽光や需要家と併設されていません。電力市場への排他的参加のために商用システムとして運用されることが多いです。
技術要件
通信
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は設置された現場に関連するデータとコマンドのみとやり取りできることが保証されます。
QoS（Quality of Service）
Tensor Cloudはメッセージ配信にMQTT QoSレベル0と1を対応しています。これは、メッセージが最大1回（QoS 0）または最低1回（QoS 1）配信されることを意味します。クライアントライブラリがQoS 1をサポートしている場合、MQTTプロトコルがメッセージ配信保証を処理するため、明示的な確認応答メッセージは不要です。
MQTTトピック
EMSとTensor Cloud間のすべての通信は、パブリッシュ・サブスクライブ方式でMQTTトピックを通じて行われます。トピック構造は直感的に設計されており、系統接続点および端末識別子に基づく階層形式に従います。
概要
テレメトリ
現場のテレメトリ（例：メーター放電、太陽光発電量、蓄電池SoE）は、EMSによって統一されたdt/トピックプレフィックスを使用して送信されます。その後にサイトID、ゲートウェイ端末ID、およびテレメトリの種類（ライフタイム、ウィンドウ、瞬時）に特有の末尾が続き、以下の形式になります：
ライフタイムメトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/lifetime
ウィンドウメトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/energy/{window}
瞬時メトリックのトピック構造:
dt/{siteId}/{gatewayId}/{metric}/power
Site IDとGateway IDは、各系統接続点とそのEMSゲートウェイ端末に割り当てられた一意の識別子です。各証明書セットと共にTensor Energyの技術担当者から提供されます。
テレメトリの種類とその定義については、以下の表とプロトコルスキーマをご参照ください。
単位
以下の表のすべてのエネルギー単位は次のように表現できます：
- 固定ウィンドウ（例：30分）におけるkWhでの時間当たり電力量
- kWhでの総計の増加合計（電力メーターと類似）
- kWでの瞬時電力
Tensor Cloudの蓄電池最適化エンジンが正常に動作するためには、いずれかのEMSが(1)または(2)を送信することが必要です。瞬時電力(3)は一部の利用ケースで最適化の経済的結果をさらに向上させるために(1)または(2)に追加して送信できますが、代替として送信することはできません。
すべての利用ケースに共通
| テレメトリ名 | 必須/任意 | 説明 |
|---|---|---|
meter_export_ac | 🔴 必須 | 系統接続メーターで測定された系統に輸出された電力量。 |
meter_import_ac | 🔴 必須 | 系統接続メーターで測定された系統から輸入された電力量。 |
battery_soe | 🔴 必須 | 蓄電池システムのState of Energy（SoE）（kWh）。現在蓄電池に蓄積されている電力量。 |
battery_energy_remaining | 🔴 必須 | セル劣化および故障セルを含む、定格温度（通常約25°C）における蓄電池システムの残存エネルギー容量（kWh）。蓄電池が最大で保持できる電力量。 |
grid_to_load_ac | ⚪️ 任意 | メーターからオンサイト電気負荷（例：工場）に送られる電力量。オンサイト負荷が存在する場合は必須。 |
load_demand_ac | ⚪️ 任意 | オンサイト電気負荷（例：工場）によって消費されるエネルギーの総量。grid_to_load_acとAC連系の場合はbattery_to_load_ac、DC連系の場合はinverter_to_load_kwhの合計。オンサイト負荷が存在する場合は必須。 |
curtailment | ⚪️ 任意 | オンサイト出力制御装置からEMSによって捕捉されたTSOによる出力制御スケジュール。 |
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 | ⚪️ オプション | 系統接続メーターで測定される、系統から蓄電池に送られる電力量。 |
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の合計。オンサイト電気負荷がある場合は必須。 |
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側で測定。蓄電池システムが系統から充電できる場合は必須。 |
独立型蓄電池システム
独立型蓄電池システムは、上記の「すべての利用ケースに共通」セクションに記載されたテレメトリのみが必要です。
コマンド
コマンド（例：蓄電池の充放電スケジュールを含む）は、Tensor Cloudによって統一されたcmd/トピックプレフィックスを使用して送信され、その後にサイトIDとコマンドタイプが続き、以下の形式になります：
cmd/{siteId}/battery/power
コマンドタイプとその定義のリストについては、プロトコルスキーマをご参照ください。
ペイロード形式
MQTTブローカーに発行されるすべてのメッセージはJSON形式を使用します。ペイロード構造はプロトコルスキーマで定義されており、JSONスキーマで表現されたテレメトリメッセージとコマンド形式が含まれています。スキーマは、必須フィールド、データ型、検証ルールを含む各メッセージタイプの詳細な定義を提供します。
スケジュール優先順位
Tensor Cloudは蓄電池充放電スケジュールを複数の層または優先度で送信します：30分ごとに今後3時間をカバーするスケジュールが最高優先度（2）で送信されます。6時間ごとに今後48時間をカバーするスケジュールが中間優先度（1）で送信されます。週次ベースで、今後1年をカバーするフォールバックスケジュールが最低優先度（0）で送信されます。
スケジュールを解釈する際、EMSは以下のルールに従う必要があります：
- 低優先度スケジュールより高優先度スケジュールを実行する
- 同じ時間帯をカバーするスケジュールが同じ優先度の場合、最新のものを実行する
メッセージタイミング
EMSは少なくとも10分ごと、できればより頻繁に新しいテレメトリデータを発行する必要があります。異なる種類のテレメトリは、利用可能になり次第、相互に独立して発行されるべきです。
より低頻度で発行できるテレメトリタイプはbattery_energy_remainingとcurtailmentの2つのみです。出力制御スケジュールはTSOから利用可能になり次第発行されるべきであり、battery_energy_remainingは少なくとも1日1回発行されるべきです。
- アラーム状態や重要な状態変更の際は即座に発行
エラーハンドリング
テレメトリエラー
EMSがサイトテレメトリデータをTensor Cloudに送信できない場合（例：不正なコマンドや通信問題のため）、EMSアプリケーションロジックは以下のガイドラインに従う必要があります：
- テレメトリデータをローカルで保持し、ネットワークが利用可能になったら再送信を試みる
- 分析用のエラー詳細をログに記録する
- MQTTブローカーのレート制限を避けるため、指数バックオフ戦略を実装する
- 保持されたデータを一括送信するより、最新のテレメトリデータを優先する
コマンドエラー
EMSが処理できないコマンドを受信した場合（例：不正なJSONまたはサポートされていないパラメータのため）、またはコマンドスケジュールを受信しない場合（例：通信問題のため）：
res/{siteId}/commandトピックで適切なエラーメッセージで応答する- エラーが優先度と時間順で解決されるまで、前の有効なスケジュールを実行し続ける
エラーコード
プロトコルはすべてのエラー面で標準化されたエラーコードを使用します：
MESSAGE_MALFORMED: メッセージは有効なJSONではないMISSING_FIELD: 必須フィールドが欠けているTYPE_MISMATCH: フィールドの型が正しくないFIELD_OUT_OF_RANGE: 数値が有効範囲外TIME_WINDOW_INVALID: 無効な時間ウィンドウまたはスケジュール（例：開始時間が終了時間より後）DUPLICATE: 重複メッセージまたは識別子（例：同じIDのメッセージが2回送信される）EXPIRED: メッセージまたはコマンドが期限切れ（例：スケジュールの開始・終了が過去）RESOURCE_UNAVAILABLE: 必要なリソースが利用できない（例：EMSと蓄電池システム間の接続が切断）INTERNAL_ERROR: 他のエラータイプでカバーされない内部システムエラー
エラー面
- CommandResponse.errors[]: 機械実行可能なコマンド実行結果
- TelemetryFeedback.code: 検証エラーコード（ステージングのみ）
テスト環境
EMSインテグレーターが実装を検証しやすくするため、Tensor Cloudはテスト環境を提供しています。本番環境とテスト環境の違いは以下のとおりです：
- 両環境間でのデータと操作の完全な分離
- テストでは、Tensor Cloudは
res/{siteId}/{gatewayId}/telemetryトピックでEMSデバイスからのすべてのテレメトリメッセージにerror/okの明示的な応答を返します
責任モデル
Tensor Cloudは、パートナーおよび蓄電池システムオーナーとの共有責任モデルの下で動作します。各当事者は、蓄電池最適化サービスの統合と運用において特定の役割と責任を持ちます。
| 当事者 | 責任 |
|---|---|
| Tensor Energy | • 経済最適化とスケジュール生成 • 蓄電池システムオーナー設定（例：最小/最大SoE）のソフト保証 |
| インテグレーター/EMS | • 蓄電池オーナーとの連携によるEMSアップタイム管理と保証 • プロトコル仕様に従ったサイトハードウェアからの正確なテレメトリ読み取り • TSO制約（例：蓄電池ランプ率、出力制御、データログ要件）のローカル実行 • 蓄電池システムオーナー設定（例：最小/最大SoE）のハード保証 • 緊急対応とEMSハードウェア故障対応 |
| 蓄電池システムオーナー | • インバランス責任（契約条件により、Tensor Energyと共有される場合がある） • TSOおよびOCCTOなどの他のステークホルダーとの関係管理（契約条件により、Tensor Energyと共有される場合がある） |
| 蓄電池OEM | • ハードウェア保守とサポート（蓄電池システムオーナーとの契約条件による） • 蓄電池ファームウェアアップデートとバグ修正 |
実装プロセス
1. 初期連絡
Tensor Cloudの蓄電池最適化サービスとの統合にご興味をお持ちの場合は、弊社ウェブサイトのお問い合わせフォームからお気軽にご連絡ください。弊社チームが統合プロジェクトの詳細を議論するための初回ミーティングのスケジュールをご返答いたします。利用ケースの複雑さによっては、この段階で複数のミーティングが必要な場合があります。
また、蓄電池システムオーナーの運用・経済要件、および統合プロセスに影響を与える可能性のある特定の制約を議論するため、Tensor Energyの代表者を含む早期の会話も推奨します。
2. 証明書設定
初回ミーティング後、弊社技術チームがステージングMQTTブローカーとの安全な認証のための初期開発X.509証明書セットを提供します。
3. 統合フェーズ
EMSソリューションの成熟度と柔軟性に応じて、統合プロセスには数日から数ヶ月かかることが予想されます。このプロセス中、弊社技術チームはMQTTブローカーへの初期接続の確立と通信プロトコルに関するご質問にサポートを提供できます。
弊社側でカスタマイズが必要な場合、弊社チームは可能な限りお客様の開発タイムラインとこの作業を同期させます。
4. テストと検証
初期統合が完了すると、統合テストを実行するため調整を行います。これには以下が含まれます：
- テレメトリデータ発行の検証
- コマンド処理と応答のテスト
- 適切なエラーハンドリングと復旧メカニズムの確保
テストプロセスの詳細については、Tensor Energyの技術担当者にお問い合わせください。
リソース
- AsyncAPIスキーマファイル: スキーマをダウンロード
- プロトコル仕様: オンラインドキュメント