システム統合ガイド
このガイドについて
これは、物理的な蓄電池システムを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トピックを通じて行われます。トピック構造は直感的に設計されており、系統接続点および端末識別子に基づく階層形式に従います。
サイトIDとゲートウェイIDについて
関係性の理解
- サイトID（
siteId）: 単一の物理的な設置場所（例：1つの蓄電池システム）を表します。コマンドはサイトレベルに送信されるため、この識別子はコマンドトピックで使用されます。 - ゲートウェイID（
gatewayId）: サイトのテレメトリを収集しコマンドを実行する特定のEMS端末またはソフトウェアインスタンスを表します。テレメトリトピックでどのゲートウェイ端末が報告しているかを区別するために使用されます。
一般的な構成
-
サイトごとに1つのゲートウェイ（標準的）: 1つの物理EMS端末が現場に設置される場合
- 例: サイト
ABC123にゲートウェイGW001 - このサイトからのすべてのテレメトリは
dt/ABC123/GW001/...を使用 - コマンドは
cmd/ABC123/...に送信
- 例: サイト
-
ホットスタンバイ: プライマリとスタンバイの両方の端末がMQTTブローカーに接続
- 例: サイト
ABC123にゲートウェイGW001（プライマリ）とGW002（スタンバイ） - 両方の端末が
cmd/ABC123/...を購読 - アクティブな端末のみが
dt/ABC123/GW001/...を使用してテレメトリを配信 - 障害時、スタンバイが引き継ぎ
dt/ABC123/GW002/...を使用して配信 - 各ゲートウェイは独自の証明書を持つ
- 例: サイト
-
コールドスタンバイ: プライマリ端末のみがMQTTブローカーに接続
- 例: サイト
ABC123にゲートウェイGW001（プライマリ）とGW002（スタンバイ） - プライマリが
dt/ABC123/GW001/...を使用してテレメトリを配信 - スタンバイ端末は現場に物理的に存在するが、ブローカーには接続されていない
- プライマリ障害時、スタンバイが接続し
dt/ABC123/GW002/...を使用して配信 - 各ゲートウェイは独自の証明書を持つ
- 例: サイト
重要な注意事項
- 各証明書は、認可されたサイトのトピックのみに発行・購読できます
- 冗長性設定の場合、各物理ゲートウェイ端末は独自の証明書を持つ必要があります
- 1つの証明書は、ブローカーへの1つの同時接続にのみ使用できます
概要
テレメトリ
現場のテレメトリ（例：メーター放電、太陽光発電量、蓄電池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の技術担当者から提供されます。
テレメトリの種類とその定義については、以下の表とプロトコルスキーマをご参照ください。
テレメトリデータタイプ
Tensor Cloudは各メトリックに対して3種類のテレメトリデータをサポートしています。以下の表は、データタイプ、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つのエネルギー読み取りタイプを送信する必要があります。 |
EMSは少なくとも1つのエネルギー読み取りタイプ（ウィンドウまたはライフタイム）を送信する必要があります。これはTensor Cloudの蓄電池最適化が正常に機能するために必須です。瞬時電力読み取り値は任意であり、頻繁に送信すると精度が向上しますが、エネルギー読み取り値の代替にはなりません。
すべての利用ケースに共通
| テレメトリ名 | 必須/任意 | 説明 |
|---|---|---|
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_kwhの合計。オンサイト負荷が存在する場合は必須。 |
curtailment | ⚪️ 任意 | オンサイト出力制御装置からEMSによって捕捉されたTSOによる出力制御スケジュール。 |
蓄電池容量メトリクスの理解
| メトリック | 説明 | 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 | ⚪️ オプション | 系統接続メーターで測定される、系統から蓄電池に送られる電力量。 |
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
蓄電池一次調整力入札コマンド：
cmd/{siteId}/battery/fcr
コマンドタイプとその定義のリストについては、プロトコルスキーマをご参照ください。
コマンドライフサイクルシーケンス
確認応答（ack-cmd）は、コマンドを受信して解析した直後に送信する必要があります。実行時ではありません。
アラート
アラートは、EMSからTensor Cloudへ障害および状態を通信します。 2つの補完的なチャネルが使用されます：
dt/{siteId}/{gatewayId}/alert(alertEvent) → アラートが状態を変更したときのデルタ更新（inactive → activeまたはactive → inactive）。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の技術チームにお問い合わせください。 |
ペイロード形式
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は蓄電池制御コマンドを2種類送信します：
蓄電池出力指令スケジュール
蓄電池充放電スケジュールは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、最小1000 kW）
一次調整力スケジュールは定期的な間隔では送信されず、通常フォールバックスケジュールも含まれません。調整力市場で入札が確定した場合にのみ送信されます。
一次調整力コマンドのキャンセル
一次調整力コマンドは、action: "cancel" を指定し、キャンセルする時間範囲を指定することでキャンセルできます。キャンセル：
- 優先度ルールを尊重：同等または低い優先度のコマンドのみキャンセル
- 任意の期間をキャンセル可能（単一の3時間ブロック、複数日、複数週など）
capacity_kwフィールドは不要（時間範囲のみ必要）
キャンセルは市場入札がキャンセルされた場合に使用されます（例：必要なバッテリーSoCレベルに到達できない場合など）。入札は受渡の1時間前（ゲートクローズ）までキャンセル可能です。
スケジュール解釈ルール
すべてのコマンドスケジュール（出力指令および一次調整力）を解釈する際、EMSは以下のルールに従う必要があります：
- 低優先度スケジュールより高優先度スケジュールを実行する
- 同じ時間帯をカバーするスケジュールが同じ優先度の場合、最新の
issue_tsタイムスタンプを持つものを実行する
すべてのコマンドメッセージには issue_ts フィールドが含まれており、これはTensor Cloudがコマンドを発行した時刻を示すISO-8601準拠のタイムスタンプです。このタイムスタンプは、同じ優先度で同じ時間帯をカバーする複数のコマンドがある場合に、どのコマンドを実行するかを決定するために不可欠です。
コマンド実行優先度ロジック
EMSが必要なテレメトリを定期的に送信しない場合、Tensor Cloudは蓄電池充放電スケジュールの生成を停止します。
メッセージタイミング
テレメトリ発行要件
| メッセージタイプ | 最小頻度 | 推奨頻度 |
|---|---|---|
| エネルギーテレメトリ（ウィンドウ/ライフタイム） | 10分ごと | 1分ごと |
| 瞬時電力（利用可能な場合） | エネルギーと同じかそれ以上 | 1分以下 |
蓄電池状態（battery_soe） | 10分ごと | 1分ごと |
battery_energy_remaining | 1日1回 | 1日1回 |
アラートスナップショット（alertState） | 10分ごと | 5分ごと |
アラートイベント（alertEvent） | 状態変化時に即座 | N/A |
| 出力制御スケジュール | TSOからの更新時 | N/A |
主要原則
- 異なるテレメトリタイプは、利用可能になり次第、相互に独立して発行する必要があります
- アラートイベントは、ハードウェアレジスタの状態が変化した際に即座に発行する必要があります
- アラーム状態や重要な状態変更は即座の発行をトリガーする必要があります
エラーハンドリング
テレメトリエラー
EMSがサイトテレメトリデータをTensor Cloudに送信できない場合（例：不正なコマンドや通信問題のため）、EMSアプリケーションロジックは以下のガイドラインに従う必要があります：
- テレメトリデータをローカルで保持し、ネットワークが利用可能になったら再送信を試みる
- 分析用のエラー詳細をログに記録する
- MQTTブローカーのレート制限を避けるため、指数バックオフ戦略を実装する
- 保持されたデータを一括送信するより、最新のテレメトリデータを優先する
コマンドエラー
EMSが処理できないコマンドを受信した場合（例：不正なJSONまたはサポートされていないパラメータのため）、またはコマンドスケジュールを受信しない場合（例：通信問題のため）：
ack-cmd/{siteId}トピックで適切なエラーメッセージで応答する- エラーが優先度と時間順で解決されるまで、前の有効なスケジュールを実行し続ける
エラーコード
プロトコルはすべてのエラー面で標準化されたエラーコードを使用します：
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は
ack-dt/{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スキーマファイル: スキーマをダウンロード
- プロトコル仕様: オンラインドキュメント