インテグレーターチェックリスト

このチェックリストについて

Tensor Cloud蓄電池最適化APIに接続するEMSインテグレーター向けの、自己申告型の適合チェックリストです。インテグレーションガイドと AsyncAPI仕様を補完するものとして、プロトコルの各構成要素について具体的な合格基準を提示します。本番運用への移行をリクエストする前に、各テストを自社ゲートウェイで検証することを想定しています。

チェックリストは独立した モジュール として構成されています。まず モジュールの選択を読み、プロジェクトタイプとサービス構成に応じて適用すべきモジュールを特定したうえで、該当する各モジュールを順に進めてください。接続、トピックアドレッシング、メッセージエンベロープ、蓄電池テレメトリ、エネルギーレポート、アラート、バックフィルの各モジュールは、すべてのインテグレーターに必須です。

本チェックリストは提出物ではありません。Tensor Energyへのご提出は不要です。結果は貴社の記録としてご記入いただき、本番運用への移行準備が整ったかどうかのご判断にご利用ください。テストIDはリビジョンをまたいで維持されるため、旧リビジョンで記録された結果はそのまま引き継げます。新しいリビジョンが公開された際は、追加された項目と合格基準に変更のあった項目のみをご確認いただければ十分です。項目の解釈にご不明な点がある場合、またはレビューをご希望の場合は、Tensor Energyの技術担当者までお問い合わせください。

ダウンロード

テスト実行を記録するためのスプレッドシート版をご利用いただけます: integrator-checklist-ja.xlsx。このページのモジュールとテストに対応した列構成に加え、各項目の検証手段を示す「検証方法」列を備えています。「結果」および「備考」列を記入してご使用ください。

モジュールの選択

まずプロジェクトタイプを選び、提供するサービスごとにモジュールを追加してください。

プロジェクトタイプ	接続、トピック、エンベロープ、蓄電池テレメトリ、エネルギー、アラート、バックフィル	太陽光	サイト需要家	制約モジュール
スタンドアロン蓄電池	必須	-	-	スタンドアロン
ACリンク蓄電池+ PV	必須	必須	条件付き	ACリンク
DCリンク蓄電池+ PV	必須	必須	条件付き	DCリンク

提供するサービス	追加するモジュール
エネルギーアービトラージ	アービトラージ
一次調整力 / 調整力サービス	一次調整力
サイト需要家(Load)テレメトリ	サイト需要家

任意機能	追加するモジュール
バッチテレメトリ（Tensor Cloudが当該サイトで有効化した場合）	バッチテレメトリ

すべての項目がTensor Cloudとの実接続で検証できるわけではありません

各項目には検証方法が設定されており、スプレッドシートでは列として表示されます。

• 実接続 — テストサーバーとの実接続で再現できます。項目に必要な応答やコマンドはTensor Cloud側から送信されます。
• インテグレーターテスト — Tensor Cloudとの実接続では再現できません。不正なコマンドまたは拒否されるコマンドの受信を前提とする項目（Tensor Cloudは正常なコマンドのみを送信し、貴社のゲートウェイ証明書には cmd/... へのパブリッシュ権限がないため、実ブローカー経由ではどちらの側からも送信できません）と、ハードウェア障害のようにTensor Cloud側で発生させられないサイト条件を前提とする項目が該当します。貴社側のユニット/インテグレーションテストの仕様としてご利用ください。コマンドに関する項目はモックMQTTブローカーを用いた実行を推奨します。サイト条件に関する項目は、試運転時の障害注入で確認いただくこともできます。
• 実接続＋インテグレーターテスト — 正常系は実接続で確認できますが、同一項目内の異常系は再現できないため、ユニットテストおよび/またはインテグレーションテストでの確認が必要です。

インテグレーターテスト の項目: A-6, AR-4, AR-6, AR-8, AR-9, AR-11, AR-15, AR-17, FC-3, FC-4, FC-10 実接続＋インテグレーターテスト の項目: E-4, AR-5, AR-10

コマンドの受信を前提とする項目を実接続で検証するには、対象の蓄電池がTensor Cloudのテスト用ワークスペースにプロジェクトとして登録され、貴社のゲートウェイと紐付けられている必要があります。Tensor Energy側でこの設定が完了するまで、貴社サイトにコマンドは配信されません。詳細はコマンド受信の前提条件をご参照ください。

モジュール: 接続

対象: すべてのインテグレーター。

C-1ブローカーエンドポイントへのTLS接続

ドキュメント記載のブローカーホスト名に対し、ポート 8883 でTLS接続を確立します。サーバー証明書をTensor CloudのCAチェーンで検証します。

合格基準: 接続が確立し、サーバー証明書が検証されること。:1883 でのプレーンテキスト接続が拒否されること。

C-2ゲートウェイごとのクライアント証明書の一意性

各ゲートウェイに固有のクライアント証明書がプロビジョニングされていることを確認します。異なるホストから同一証明書での二重接続を試行します - AWS IoT Coreにより古いセッションが切断されます。

合格基準: 各ゲートウェイが固有の証明書を持つこと。同一証明書で2つ目の同時接続を開くと、最初の接続が切断されること。

C-3CAチェーン検証

EMSはTensor Cloudのブローカー証明書を、ドキュメント記載のCAチェーンで検証します。チェーンが破損している、または期限切れの証明書は拒否します。

合格基準: 無効または自己署名のブローカー証明書が拒否されること。

C-7QoSとアプリケーションレベル確認応答

EMSは信頼性要件に応じてMQTT QoS 0または1を使用します（ブローカーは両方に対応しています）。選択したQoSによらず、EMSは受信した各コマンドに対して ack-cmd/{siteId} 上でアプリケーションレベルの CommandResponse を送信します。これは配信確認ではなくバリデーション結果を運ぶためです。

合格基準: EMSがQoS 0または1でパブリッシュすること。使用するMQTT QoSによらず、EMSは受信した各コマンドに対してアプリケーションレベルの CommandResponse を送ること。

C-8バックオフ付き再接続

ブローカー切断後、EMSは指数バックオフまたは制限付きバックオフポリシーで再接続します。

合格基準: 再接続ストームが回避されること。パブリッシュ再開前にサブスクリプションが再確立されること。

C-9テレメトリがパブリッシュできない場合の挙動

EMSがパブリッシュできない場合(ブローカー到達不能、TLSエラー)、テレメトリを暗黙に破棄せず、ローカルバッファに保持します。

合格基準: バッファされたテレメトリが バックフィルモジュール のポリシーに従って再生されること。BF-1 を参照。

モジュール: トピックアドレッシング・識別

対象: すべてのインテグレーター。

T-1siteIdのフォーマット

サイト識別子は si_ のプレフィックスに続けて、小文字英数6文字です(例: si_qcf9gn)。

合格基準: パブリッシュ・サブスクライブトピックで使用するすべての siteId が ^si_[a-z0-9]{6}$ に一致すること。

T-2gatewayIdのフォーマット

ゲートウェイ識別子は gw_ のプレフィックスに続けて、小文字英数6文字です。

合格基準: すべての gatewayId が ^gw_[a-z0-9]{6}$ に一致すること。

T-3チャネルごとのパブリッシュトピックパターン

EMSは以下のスキーマで定義されたトピックにのみパブリッシュします:

• dt/{siteId}/{gatewayId}/{metric}/lifetime
• dt/{siteId}/{gatewayId}/{metric}/energy/{window}
• dt/{siteId}/{gatewayId}/{metric}/power
• dt/{siteId}/{gatewayId}/{metric}/state
• dt/{siteId}/{gatewayId}/curtailment
• dt/{siteId}/{gatewayId}/irradiation
• dt/{siteId}/{gatewayId}/frequency
• dt/{siteId}/{gatewayId}/alert
• dt/{siteId}/{gatewayId}/alert/active
• ack-cmd/{siteId}

合格基準: このリスト外のトピックへのパブリッシュがないこと。

T-4チャネルごとのサブスクライブトピックパターン

EMSは以下のトピックにのみサブスクライブします:

• cmd/{siteId}/battery/power
• cmd/{siteId}/battery/fcr (一次調整力インテグレーターのみ)
• ack-dt/{siteId}/{gatewayId}

合格基準: 文書化されたサブスクリプションが上記リストに合致すること。ワイルドカード（例: cmd/{siteId}/battery/+）も完全一致トピックの代わりに許容されます。

T-5res_topicの名前空間

受信した各コマンドの res_topic フィールドはコマンドのトピックと同じサイトを指します。AWS IoT Coreはブローカー層でこれを強制します: ゲートウェイの証明書は自サイトの ack-cmd/{siteId} 名前空間へのパブリッシュのみを認可しているため、EMSが別サイトの res_topic にレスポンスをパブリッシュしようとしてもブローカーによって拒否されます。

合格基準: コマンドで返された res_topic 値への CommandResponse のパブリッシュが正当なコマンドに対して成功すること。別サイトの名前空間へのパブリッシュ試行はブローカーによって拒否されること。

T-6ack-cmdとack-dtの名前空間

コマンド応答は ack-cmd/{siteId} にパブリッシュされます。テレメトリフィードバックは ack-dt/{siteId}/{gatewayId} で受信します。

合格基準: EMSが各方向で正しい名前空間を使用すること。

T-7ack-dtトピックの形

テレメトリフィードバックは ack-dt/{siteId}/{gatewayId} 上に到着します。/telemetry サフィックスは付きません。

合格基準: EMSが ack-dt/{siteId}/{gatewayId} にサブスクライブすること。

T-8ホットスタンバイ時の確認応答

ホットスタンバイ構成では、アクティブなゲートウェイのみがコマンドの確認応答とスケジュールの実行を行います。スタンバイのゲートウェイはコマンドトピックにサブスクライブしますが、昇格するまで沈黙します。プライマリ/スタンバイの調整はEMSパートナーの責任です（インテグレーションガイド を参照）。

合格基準: ホットスタンバイ構成下で、コマンド1件につき正確に1件の CommandResponse が送信され、正確に1つのゲートウェイがスケジュールを実行すること。

モジュール: メッセージエンベロープ

対象: すべてのインテグレーター。

E-1すべてのメッセージにschema_versionが存在する

AlertEvent と AlertState を含むすべてのパブリッシュペイロードに schema_version を含めます。

合格基準: EMSが送信するすべてのメッセージに schema_version が存在すること。

E-2schema_versionの値

仕様リビジョン2.8.0の下で送信されるすべてのメッセージで、schema_version は "2.8.0" です。仕様のPATCHリビジョンは送信値を変更しないため、リリースによってはこの2つのバージョン番号が一致しないことがあります。Tensor Cloudは古い仕様リビジョンで送信されたメッセージとの後方互換性を維持します。

合格基準: 送信されるすべての schema_version が "2.8.0" であること。

E-3message_idのフォーマット

すべての message_id が ^msg_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ に一致します。

合格基準: 生成されるすべての message_id 値が正規表現を通過すること。

E-4command_idの相関

すべての CommandResponse は、対応するコマンドの message_id と等しい command_id を持ちます。唯一の例外は解析不能なコマンド（MESSAGE_MALFORMED）で、その message_id は復元できないため、応答はセンチネル command_id: "unknown" を持ちます。

合格基準: テスト中に送信される代表的なコマンド群に対し、すべての応答の command_id がいずれかのコマンドの message_id に一致すること。また、意図的に不正形式（非JSON）としたコマンドに対しては、応答が command_id: "unknown" を持つこと。

検証方法: 正常系は実接続で再現できますが、異常系は再現できません。異常系はモックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

E-5タイムスタンプ

すべての *_ts フィールドはタイムゾーンオフセット付きのISO-8601タイムスタンプです(例: 2024-01-05T00:00:00.000+09:00)。

合格基準: 送信されるすべてのタイムスタンプがオフセット付きISO-8601として解釈可能であること。文書化された慣習がオフセット表記の場合は素の Z を使用しないこと。

E-6additionalPropertiesポリシー

スキーマは前方互換性のため、すべてのメッセージファミリーで未定義フィールドを許容します（additionalProperties: true）。EMSは引き続きスキーマで定義されたフィールドのみを送信すべきです。両側の受信側は将来のスキーマリビジョンで追加されるフィールドを許容する必要があります。

合格基準: 送信されるすべてのペイロードがスキーマで定義されたフィールドのみを含むこと。EMSパーサーが未定義フィールドを含むメッセージを受信してもクラッシュせず、暗黙に破棄しないこと。

E-7measurement_tsの整合

一定の期間を対象とする測定では、measurement_ts はその期間の開始時刻を表し、終了時刻や中間時刻は表しません。ウィンドウエネルギーでは measurement_value.start_ts と一致し、aggregation: "average" で送信する電力・系統周波数では aggregation_window の開始時刻となります。瞬時値のテレメトリでは測定した時点そのものを表します。測定値ではなくスケジュールである出力抑制では、一般送配電事業者（TSO）のデータに作成時刻が含まれる場合はその作成時刻を、含まれない場合はEMSがTSOからスケジュールを受信した時刻を表します。

合格基準: すべてのウィンドウエネルギーペイロードで measurement_ts が start_ts と一致すること。aggregation: "average" の電力・周波数ペイロードで measurement_ts が aggregation_window の開始時刻であること。出力抑制の measurement_ts がTSOのスケジュール作成時刻または受信時刻を反映していること。

モジュール: 蓄電池テレメトリ

対象: すべてのインテグレーター。

BT-1電力テレメトリの形

蓄電池の電力テレメトリは dt/{siteId}/{gatewayId}/{metric}/power に PowerInstant ペイロードでパブリッシュします。

合格基準: パブリッシュがスキーマに対して妥当であること。metric パラメーターがmetric enumの蓄電池サブセットに含まれること。

BT-2状態テレメトリの形

蓄電池の状態テレメトリ(SoCなど)は dt/{siteId}/{gatewayId}/{metric}/state に BatteryStateValue ペイロードでパブリッシュします。

合格基準: パブリッシュがスキーマに対して妥当であること。

BT-3テレメトリの送信頻度

テレメトリはTensorが文書化した頻度(通常はpowerとstateについて1分ごとの送信)でパブリッシュされます。

合格基準: 少なくとも1時間の連続稼働にわたる代表的な観測期間において、観測された送信頻度が文書化された期待値に一致すること。

BT-4再接続時のテレメトリ鮮度

切断後、パブリッシュを再開する際、EMSはバックフィルされた履歴より最新サンプルを優先します。

合格基準: 再接続後の最初のパブリッシュメッセージが最古のバッファ済みサンプルではなく、最新サンプルを搬送すること。バックフィルモジュール を参照。

BT-5テレメトリフィードバックの受信

EMSは ack-dt/{siteId}/{gatewayId} にサブスクライブし、TelemetryFeedback メッセージに対して反応します。

合格基準: EMSが status: "ok" と status: "error" フィードバックの両方を処理することを示すこと。

BT-6テレメトリフィードバックに対する再送挙動

EMSはテレメトリフィードバックのエラーに対する再送 / 破棄の文書化されたポリシーを持ちます。

合格基準: EMSの挙動が文書化されたポリシーに合致すること。

BT-7TelemetryFeedbackの条件付きフィールド

TelemetryFeedback は status が error のとき code と detail を含み、ok のときは code、detail、topic をいずれも省略します。スキーマは if/then/else でこれを強制します。

合格基準: EMS側のパーサーが両方の形を処理（クラッシュなし、暗黙の破棄なし）し、ok で code/detail/topic を受信した場合はプロトコル違反として扱うこと。

BT-8不正な形式のテレメトリフィードバック

Tensor Cloudはテレメトリメッセージを解析できない場合、code: "MESSAGE_MALFORMED"、correlation_id: "unknown"（元の message_id は復元不可）、およびメッセージがパブリッシュされたチャネルを示す topic フィールドを含むACKを返します。したがって correlation_id は msg_ UUIDパターンに制約されません。

合格基準: EMSのパーサーが correlation_id: "unknown" を拒否・破棄せずに受け入れ、どのパブリッシュしたメッセージが拒否されたか運用者が特定できるよう topic を提示すること。

モジュール: エネルギーレポート

対象: すべてのインテグレーター。

EN-1必須メトリックごとに少なくとも1つのエネルギー読み取りストリーム

インテグレーターのプロジェクトタイプで必須とされる各エネルギーフローメトリック(プロジェクトタイプ制約モジュールを参照)について、EMSはウィンドウエネルギーストリーム、ライフタイムカウンター、またはその両方のいずれかを送信します。

合格基準: 少なくとも1時間の連続稼働にわたって、必須の各エネルギーフローメトリックに対し、少なくとも1つのアクティブなストリームが存在すること。

EN-2ライフタイムカウンターの単調性

dt/{siteId}/{gatewayId}/{metric}/lifetime 上の値は、メッセージ間で減少しません(文書化されたカウンターリセットイベントを除く)。

合格基準: 代表的な観測期間にわたって単調非減少であること。

EN-3ライフタイムカウンターの単位

ライフタイムペイロードは EnergyLifetime スキーマに従いkWhを使用します。

合格基準: すべてのライフタイム値がkWhであること。

EN-4ウィンドウの境界

dt/{siteId}/{gatewayId}/{metric}/energy/{window} について、ペイロード内の start_ts と end_ts の境界が {window} パラメーター（ISO-8601の期間。PT5M、PT30M、PT1H など）と一致します。

合格基準: すべてのウィンドウペイロードの start_ts/end_ts がトピックから示唆されるウィンドウ長と一致すること。

EN-5遅延到着のポリシー

EMSはウィンドウが閉じた後にのみウィンドウエネルギー値をパブリッシュします。Tensor Cloudに遅延到着の締切はなく、ウィンドウが閉じてからどれだけ時間が経過してもサンプルは受け付けられます。

合格基準: EMSがウィンドウ閉鎖後にのみウィンドウ値をパブリッシュすること。バックフィルや復旧からの遅延サンプルは破棄せず必ずパブリッシュされること。

モジュール: アラート

対象: すべてのインテグレーター。

A-1alertEventの送信

過渡的なアラートイベントは、AlertEvent に従って dt/{siteId}/{gatewayId}/alert にパブリッシュされます。

合格基準: 送信されるすべてのコードが AlertCode のメンバーであること。

A-2alertStateのクリア処理

アラートが解消したとき、次の alertState スナップショットには当該アラートが含まれません。alertState は周期的なフルスナップショット(少なくとも10分ごと、および起動時)であり、再サブスクライブするコンシューマーや欠落したイベントからの復旧はリテインメッセージではなく次のスナップショットに依存します。

合格基準: アラート解消後、次の alertState に当該アラートが含まれないこと。

A-4AlertCode列挙の網羅

EMSが送信するすべてのコードがスキーマの AlertCode enumに含まれます。

合格基準: これらのトピックで独自のアラートコードが送信されないこと。

A-5アクティブなアラートがない場合のalertStateスナップショット

アラートが1件も発報していない期間にわたって alertState トピックを観測します。スナップショットは、アクティブなアラートの有無にかかわらず通常の周期で発行されます。

合格基準: alertState が少なくとも10分ごとに、measurement_value を空配列として発行され続けること。報告すべき内容がないことを理由にEMSが発行を省略しないこと。

A-6共有ハードウェア障害での全該当コードの発報

太陽光と蓄電池を併設するサイトが対象です。DCリンクのシステムでは、太陽光アレイと蓄電池が共有するハードウェア（ハイブリッドインバータ、共通のパワーコンディショニング設備、共通の制御・集約装置）の障害を模擬します。構成を問わず、EMSが両サブシステムに単一の集約装置を介して接続している場合は、その集約装置との通信途絶を模擬します。

合格基準: 共有ハードウェアの障害で PV_OTHER と BATT_OTHER の両方が発報され、解消時には両方について cleared の alertEvent が送信されること。BMS単位・PVPCS単位の通信状態を把握できないEMSでは、集約装置との通信途絶で BATT_COMM_FAIL と PV_COMM_FAIL の両方を発報しても合格とすること。装置単位の可視性がある場合は、実際に到達不能な装置のコードのみが発報されること。

検証方法: Tensor Cloudはサイト側の障害を発生させないため、実接続では再現できません。貴社側のユニット/インテグレーションテスト、または試運転時のサイト側障害注入で確認してください。

モジュール: バックフィル・オフライン復旧

対象: すべてのインテグレーター。

BF-1再接続時の再生順序

ネットワーク障害後、EMSは ライブサンプルを優先して再開 します。送信待ちのライブサンプルがなくなったときのみ、バッファ済み履歴の再生を開始します。

合格基準: 再接続後の観測トラフィックで、ライブサンプルがバックフィルより先に送信されること。新しいライブサンプルが到着するたびに、バックフィルがそれに道を譲ること。

BF-2バックログの最大保持期間

EMSはテレメトリをローカルで最大 7日間 保持します。7日より古いバッファ済みサンプルは破棄または要約します。

合格基準: EMSが7日より古いバッファ済みサンプルを破棄または要約すること。7日以内のサンプルは再生されること。

BF-3再接続時の重複処理

すでに配信されている可能性のあるサンプルをEMSが再送する場合、元のパブリッシュと 同じ message_id を再利用します。Tensor Cloudは message_id で重複排除を行います。

合格基準: あるサンプルを再送するたびに、最初のパブリッシュ試行と同じ message_id を持つこと。EMSは再試行のために新しい message_id を生成しないこと。

モジュール: バッチテレメトリ

対象: 任意のバッチトピックを利用するインテグレーター。EMSが単一メッセージのみを送信する場合、このモジュールは対象外です。

BA-1バッチ送信モードの遵守

バッチ送信はTensor Cloudがサイトごとに有効化し、既定ではバックフィルのみが対象です。EMSがライブの計測値をバッチ化するのは、当該サイトにライブのバッチ送信が許可されている場合に限られ、その場合も1つのライブバッチが対象とする期間は最大60秒です。VPP構成の低圧蓄電池のようにライブテレメトリが毎秒到着する必要があるサイトでは、ライブの計測値を単一メッセージで送信します。

合格基準: バックフィルのみのサイトでは、すべてのライブ計測値が単一メッセージで送信され、バッチトピックはバックフィルにのみ使用されること。ライブが許可されたサイトでは、いずれのライブバッチも60秒を超えないこと。

BA-2バッチペイロードの形式と並び順

各バッチは unit、aggregation、aggregation_window、pre_qualification をメッセージ全体に対して一度だけ指定し、measurements の各要素は自身の message_id、measurement_ts、value を保持します。要素は measurement_ts の昇順に厳密に並び、同一のタイムスタンプおよび同一の message_id を含まず、いずれの要素の message_id もバッチ自身の message_id と一致しません。信頼できる値が得られなかった秒は、0 や null として送信せず、配列から省略します。

合格基準: 送信されるすべてのバッチが PowerInstantBatch または GridFrequencyBatch に適合すること。タイムスタンプが厳密な昇順かつ一意であり、message_id がバッチ内で一意かつエンベロープのものと異なること。欠測が要素の省略として表れること。

BA-3ヘッダー変更時の分割

unit、aggregation、aggregation_window、pre_qualification はすべての要素に適用されるため、EMSはこれらのいずれかが変わるたびに新しいバッチを開始します。特に、運用者が事前審査の試験モードに入る／出る瞬間をバッチがまたぐことはありません。

合格基準: 異なるヘッダー値の下で取得された計測値が同一バッチに含まれないこと。事前審査モードへの出入りが常に新しいバッチの開始となること。

BA-4バッチのサイズ上限

1つのバッチが運ぶ要素は最大900件であり、エンコード後のUTF-8ペイロードは最大122,880バイトです。EMSは要素数だけに頼らず、シリアライズ後のペイロードを計測したうえで送信前に分割します。

合格基準: 送信されるいずれのバッチも900要素および122,880バイトを超えないこと。いずれかの上限を超える系列が複数のバッチに分割されること。

BA-5バッチトピックのQoSとRETAIN

バッチトピックはQoS 1で送信し、MQTTのRETAINフラグを設定しません。

合格基準: バッチトピックへのすべての送信がQoS 1かつRETAIN未設定であること。

BA-6重複排除と全体拒否時の再送

重複排除はバッチではなく各要素の message_id をキーとして行われます。再送時、EMSは各計測値の元の message_id を再利用し、異なる大きさのバッチへ組み直すことも、単一メッセージ形式で再送することもできます。バッチは全体が受理されるか全体が拒否されるかのいずれかであるため、バッチに対してエラーを受け取ったEMSは、そのバッチ内のすべての計測値が保存されていないものとして扱い、修正のうえバッチ全体を再送します。

合格基準: 再送された計測値が、いずれの形式であっても最初のパブリッシュ試行と同じ message_id を持つこと。同じ計測値を異なるバッチに組み直しても重複した値が保存されないこと。バッチが拒否された後、EMSが問題のあった要素だけでなくすべての計測値を再送すること。

モジュール: アービトラージ (BatteryPowerCommand)

対象: エネルギーアービトラージサービスを提供するインテグレーター。

AR-1出力指令の受信

EMSは cmd/{siteId}/battery/power で代表的な BatteryPowerCommand を受信します。

合格基準: メッセージが配信され、エラーなく解析されること。

AR-2スキーマに従ったコマンドの形

ペイロードは schema_version、message_id、issue_ts、res_topic、および priority(任意)と schedule(必須)を含む control オブジェクトを含みます。

合格基準: ペイロードが BatteryPowerCommand に対して妥当であること。

AR-3ack-cmd成功応答

コマンドを受理した際、EMSは ack-cmd/{siteId} に status: "ok"、コマンドの message_id と等しい command_id、schema_version: "2.8.0" をパブリッシュします。

合格基準: 応答が CommandResponse に対して妥当であること。errors が存在しないこと。

AR-4ack-cmdエラー応答の形

コマンドを拒否する際、EMSは status: "error" と errors 配列をパブリッシュします。各エラーは code(ErrorCode から)と detail を持ちます。該当する場合は field_path を使用します。

合格基準: 各エラー項目が detail を使用すること。すべての code が ErrorCode から選ばれること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-5statusに応じたerrorsの条件付き必須

status が error の場合、errors 配列が存在し少なくとも1件の項目を含みます。status が ok の場合、errors フィールドは存在しません。スキーマは if/then/else 制約でこれを強制するため、スキーマバリデーションのチェックでもあります。

合格基準: status: "error" のとき errors が存在（≥ 1件）し、status: "ok" のとき errors が存在しないこと。

検証方法: 正常系は実接続で再現できますが、異常系は再現できません。異常系はモックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-6ErrorCodeマッピング

EMSはインテグレーションガイドに記載された ErrorCode 値を各クラスのバリデーション失敗に対して使用します: 解析不能JSONには MESSAGE_MALFORMED、必須フィールド欠落には MISSING_FIELD、型不一致には TYPE_MISMATCH、範囲外の数値には FIELD_OUT_OF_RANGE、空のスケジュール・重複区間・反転した start_ts/end_ts には TIME_WINDOW_INVALID、過去終了スケジュールには EXPIRED、message_id 衝突には DUPLICATE、機器の利用不可には RESOURCE_UNAVAILABLE、その他には INTERNAL_ERROR。

合格基準: 上記の各失敗クラスについて、EMSが文書化された ErrorCode を発出すること。同一の失敗クラスが実行をまたいで常に同じコードを生成すること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-7スケジュールギャップ

時間ギャップを含むスケジュールを送信します。

合格基準: ギャップ中、EMSはその時間帯をカバーする以前の有効なコマンドにフォールバックすること。該当する以前のコマンドがない場合、EMSは power_kw = 0（待機）を使用すること。

AR-8コマンド内の重複

互いに重複する区間を持つスケジュールを送信します。

合格基準: EMSが文書化された ErrorCode と field_path: "control.schedule" でコマンドを拒否すること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-9空のスケジュール

空の schedule 配列を持つコマンドを送信します。

合格基準: EMSが文書化された ErrorCode と field_path: "control.schedule" で拒否すること。スキーマも schedule に対して minItems: 1 を強制するため、スキーマバリデーションのチェックでもあります。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-10priorityとissue_tsのタイブレーク

重複する2つのコマンドを送信します。priority が異なる場合は高い方が勝ちます。priority が同一の場合はより新しい issue_ts が勝ちます。priority と issue_ts が両方同一の場合は、最後に受信したコマンド（配線上で最後に到着したもの）が勝ちます。

合格基準: EMSが各タイブレークシナリオで勝者のコマンドを実行し、すべてのコマンドに確認応答すること。

検証方法: 正常系は実接続で再現できますが、異常系は再現できません。異常系はモックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-11古いスケジュールの拒否

スケジュールの最後の区間の end_ts が過去になっているコマンドを送信します。

合格基準: EMSが文書化された ErrorCode で拒否すること。（古い issue_ts 単独は拒否理由になりません - issue_ts はタイブレーク用です。）

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

AR-12時間帯単位の置き換え

実行中のスケジュールの一部分とだけ重なるコマンドを送信します。新しいコマンドは 重複する時間帯についてのみ 既存のスケジュールを置き換え、重複しない区間は以前のコマンドが引き続き有効である必要があります。

合格基準: 実行時、EMSは重複時間帯について新しいコマンドの設定値を使用し、重複しない時間帯については以前のコマンドの設定値を継続すること。出力指令には明示的なキャンセル機構は存在せず、出力スケジュールを上書きするにはTensor Cloudが新しいコマンド（power_kw = 0 またはその他の値、適切な優先度で）を送信する。

AR-13スロット途中のコマンド（即時実行）

最初の区間の start_ts が過去で end_ts が未来のコマンド、つまりカバーする時間帯がすでに開始しているコマンドを送信します。

合格基準: EMSはコマンドを受理し、開始時刻を待たずに有効な区間の設定値を即座に適用すること。最後の区間の end_ts も過去にあるスケジュールのみが古いものとして拒否される（AR-11を参照）。

AR-14スケジュールなし（待機フォールバック）

どのコマンドもカバーせず、該当する以前の有効なコマンドも存在しない時刻に到達します。

合格基準: EMSは蓄電池を停止し、その時刻をカバーするコマンドが到着するまで power_kw = 0（待機）を保持し、充放電を一切行わないこと。

AR-15妥当な項目と不正な項目が混在するスケジュール

control.schedule に、正しい形式の項目と、少なくとも1件の不正な項目が混在する BatteryPowerCommand を送信します（例: 項目0は power_kw が範囲外、項目1は end_ts が start_ts より前、項目2と3は完全に妥当）。一次調整力のインテグレーターは、一次調整力コマンドについて同等のテストを FC-10 として実施してください。

合格基準: EMSがそのコマンドの項目を、妥当だったものも含めていずれも適用せず、直前まで有効だったスケジュールの実行を継続すること。応答は status: "error" で、最初の失敗で打ち切らず、不正な項目ごとに固有の field_path を持つ errors[] を1件ずつ含むこと。拒否後にEMSの保持するスケジュールを確認しても、当該コマンドの痕跡がないこと。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーに対する貴社側のユニット/インテグレーションテストで確認してください。

AR-16reference_pointの解釈

reference_point の値が混在するスケジュールを、併設の発電がある時間帯に実行します。"battery" の区間、"grid" の区間、およびフィールドを省略した区間を含めます。

合格基準: "battery" の区間では蓄電池自体が power_kw に追従し、発電はそのまま送電されること。したがって 0 の区間では蓄電池が待機したままサイトは送電を継続すること。"grid" の区間では受電点が power_kw に追従し、0 の区間では受電点をゼロに保ち、蓄電池がその時点の発電量を吸収すること。フィールドを省略した区間は "battery" と同一に振る舞うこと。DC連系のシステムでは、EMSが power_kw をそのまま渡すのではなく、実測の太陽光出力に基づきインバータ設定値を補正して "battery" の区間を実現すること。

AR-17到達できない設定値のクランプと発報

EMSが実現できない設定値を与えます。"battery" の区間で、値と同時発電量の合計がインバータ定格を超えるケース、または "grid" の区間で、満充電の蓄電池にさらに充電するか、空の蓄電池からさらに放電することが必要になるケースを用います。

合格基準: EMSが物理的に到達可能な最も近い値を適用し、スケジュールの実行を継続したうえで、到達を妨げた制限を示す SETPOINT_UNREACHABLE を発報すること。コマンドを拒否せず、status: "error" で応答せず、蓄電池を停止しないこと。指令値への追従が回復した時点でアラートが解消すること。

検証方法: Tensor Cloudは到達できない設定値を意図的に送信しないため、実接続では再現できません。貴社側のユニット/インテグレーションテスト、または試運転時に確認してください。

モジュール: 一次調整力 (BatteryFcrCommand)

対象: 一次調整力または調整力サービスを提供するインテグレーター。

FC-1一次調整力コマンドの受信

EMSは cmd/{siteId}/battery/fcr で代表的な BatteryFcrCommand を受信します。

合格基準: メッセージが配信され、エラーなく解析されること。

FC-2actionのデフォルトはexecute

スケジュール項目で action フィールドが存在しない場合、EMSはこれを execute として扱います。

合格基準: スキーマのデフォルトに一致すること。

FC-3executeではcapacity_kwが必須

action: "execute"（デフォルト）のスケジュール項目について、EMSは capacity_kw を必須とし、欠落している項目を拒否します。スキーマは control.action 上の if/then/else でこれを強制します。

合格基準: EMSが文書化された ErrorCode と該当項目を指す field_path で拒否すること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

FC-4cancelではcapacity_kwを禁止

action: "cancel" の場合、スケジュール項目で capacity_kw は禁止されます。スキーマは同じ control.action 上の if/then/else でこれを強制します。

合格基準: capacity_kw を含むキャンセルコマンドをEMSが文書化された ErrorCode で拒否すること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーを用いた貴社側のユニット/インテグレーションテストでご確認ください。

FC-5一次調整力アセスメントⅡ用電力テレメトリ

すべての一次調整力約定コマ（cmd/{siteId}/battery/fcr で一次調整力入札コマンドが送信された各30分コマ）について、EMSは1秒解像度の供出電力を瞬時電力トピック dt/{siteId}/{gatewayId}/{metric}/power（PowerInstant メッセージ）に1 Hz、単位kW、0以上で、各整数秒の開始を measurement_ts とする1秒平均（aggregation: "average"、aggregation_window: "PT1S"）として発行します。メトリクスの組はTSO登録に一致させます: 受電点参入では meter_export_ac/meter_import_ac、機器点参入では battery_discharge_ac/battery_charge_ac。インテグレーションガイドを参照してください。

合格基準: 代表的な一次調整力約定コマにおいて、電力サンプルが登録メトリクスで1 Hzで届き、aggregation: "average" と aggregation_window: "PT1S" および整数秒の measurement_ts を持ち、FC-8の周波数サンプルと同じ measurement_ts 境界を共有すること。

FC-7アービトラージとの一次調整力ベースライン合成

アービトラージと一次調整力のコマンドはスーパーシードではなく合成されます。一次調整力コマンドは周波数応答のために提供される容量を設定し、同じ時間帯の BatteryPowerCommand がベースラインを動かします。EMSが1500 kWの一次調整力スケジュールを保持しており、同じ時間帯に -100 kWの出力指令を受信した場合、ベースラインは -100 kWにシフトします（インテグレーションガイド を参照）。

合格基準: 一次調整力スケジュールとアービトラージスケジュールが同じ時間帯をカバーする場合、EMSはアービトラージ値をベースラインとして適用し、その上に一次調整力の容量を周波数応答に使用すること。

FC-8系統周波数テレメトリ

すべての一次調整力約定コマについて、EMSは系統周波数を dt/{siteId}/{gatewayId}/frequency（GridFrequency メッセージ）に1 Hz、単位Hzで、系統接続ポイントで実際のAC波形から0.0001 Hz以上の分解能で測定し、1 Hzの電力サンプルと時刻を揃えた1秒平均（aggregation: "average"、aggregation_window: "PT1S"）として発行します。インテグレーションガイドを参照してください。

合格基準: 代表的な一次調整力約定コマにおいて、周波数サンプルが1 Hzで届き、unit: "Hz" と現実的な値を持ち、電力サンプルと同じ measurement_ts 境界を共有すること。

FC-9事前審査フラグ

EMS運用者がサイトを一次調整力の事前審査（プレクオリフィケーション）試験モードにしている間、EMSはすべての瞬時電力（*/power）および系統周波数（*/frequency）メッセージに pre_qualification: true を設定し、通常運用時は省略（または false）します。

合格基準: 模擬的な事前審査の実行において、試験期間中のすべての */power および */frequency メッセージに pre_qualification: true が存在し、通常運用時には存在しないこと。

FC-10妥当な項目と不正な項目が混在するスケジュール（一次調整力）

control.schedule に、正しい形式の項目と少なくとも1件の不正な項目が混在する BatteryFcrCommand を、2回に分けて送信します。action: "execute" の回では、項目0を capacity_kw が範囲外、項目1を end_ts が start_ts より前として不正にし、項目2と3は妥当なまま（いずれも capacity_kw を持つ）とします。action: "cancel" の回ではすべての項目で capacity_kw が禁止されるため、項目0は capacity_kw を含めること自体で不正とし、項目1は end_ts が start_ts より前として不正にし、項目2と3は capacity_kw を持たない妥当な時間範囲とします。これは AR-15 の一次調整力版です。検証の全件一括はアービトラージ固有の規則ではなく、プロトコル全体の規則です。

合格基準: EMSがそのコマンドの項目を、妥当だったものも含めていずれも適用せず、直前まで有効だった一次調整力スケジュールの実行を継続すること。応答は status: "error" で、不正な項目ごとに固有の field_path を持つ errors[] を1件ずつ含むこと。キャンセルの場合は何もキャンセルされず、当該コマンドが指定したオファーがすべて有効なまま残ること。

検証方法: Tensor Cloudは正常なコマンドのみを送信するため、実接続では再現できません。モックMQTTブローカーに対する貴社側のユニット/インテグレーションテストで確認してください。

モジュール: 太陽光

対象: PVを持つACリンクおよびDCリンクのインテグレーター。

SO-1日射量テレメトリ

EMSは dt/{siteId}/{gatewayId}/irradiation に Irradiation に従ってパブリッシュします。

合格基準: パブリッシュがスキーマに対して妥当であること。

SO-2日射量の送信頻度

EMSは日射量を文書化された頻度(通常は日中は連続、夜間は停止または0)でパブリッシュします。

合格基準: 少なくとも1時間の連続する日中稼働にわたって、観測された送信頻度が文書化された期待値に合致すること。

SO-3出力抑制の報告

EMSは dt/{siteId}/{gatewayId}/curtailment に Curtailment に従ってパブリッシュします。

合格基準: パブリッシュがスキーマに対して妥当であること。インバーターが利用可能な日射量を下回って動作しているとき、出力抑制が報告されること。

SO-4太陽光発電の電力テレメトリメトリック

metric enumのPV関連メトリック（solar_to_grid_ac、solar_to_battery_ac など）が電力トピックにパブリッシュされます。

合格基準: EMSがサポートするすべてのPVメトリックが dt/{siteId}/{gatewayId}/{metric}/power に送信されること。

SO-5inverter_net_output_acの定義

EMSは inverter_net_output_ac を、インバータのAC側出力の総量(inverter_to_load_ac と inverter_to_grid_ac の合計)として送信します。値は非負です。

合格基準: 送信される値が ≥ 0であり、inverter_to_load_ac + inverter_to_grid_ac に等しいこと。

SO-6太陽光DC電圧・電流(DCリンク)

DCリンクのインテグレーターは、太陽光アレイのDC電圧・電流を dt/{siteId}/{gatewayId}/solar に SolarDcElectrical 準拠でパブリッシュします。measurement_value は voltage(V)と current(A)を含み、それぞれ {value, unit} オブジェクトで値は ≥ 0、インバータより上流のDCリンクでアレイ全体を集約した単一の値です。電圧と電流は同一の measurement_ts を共有し(同一時刻にサンプリング)、1分間隔でパブリッシュします。

合格基準: パブリッシュがスキーマに対して妥当であること。各メッセージが単一の measurement_ts で voltage と current の両方を含み、日中は1分に1回以上の頻度であること。ACリンクおよびスタンドアロンのインテグレーターはこのチャネルを送信しません。

モジュール: サイト需要家 (Load)

対象: 需要家(Load)テレメトリを報告するインテグレーター(通常はオンサイト需要家のあるACリンク)。

SL-1需要家の電力テレメトリ

EMSは需要家側の電力メトリックを dt/{siteId}/{gatewayId}/{metric}/power にパブリッシュします。

合格基準: パブリッシュが PowerInstant に対して妥当であること。

SL-2需要家メトリックの命名

EMSは inverter_to_load_kwh ではなく inverter_to_load_ac を使用します。

合格基準: すべての需要家関連メトリックがmetric enumの正準名であること。

SL-3系統充電メトリック(DCリンク)

系統充電が可能なDCリンクサイトでは、EMSは grid_to_inverter_ac を送信します。

合格基準: サイトが系統から充電可能なときに当該メトリックが送信されること。

SL-4系統充電メトリック(ACリンク)

系統充電が可能なACリンクサイトでは、EMSは grid_to_battery_ac を送信します。

合格基準: サイトが系統から充電可能なときに grid_to_battery_ac が送信されること。

モジュール: プロジェクトタイプ制約

対象: すべてのインテグレーター(自社のプロジェクトタイプに合致するサブモジュールを実施)。

PT-Sスタンドアロンのメトリックセット

• 必須メトリック: metric enumの蓄電池関連メトリックのみ。
• 禁止メトリック: 太陽光メトリック、需要家メトリック、DCリンク専用メトリック。
• 引き続き必須: dt/{siteId}/{gatewayId}/curtailment への出力抑制。太陽光を併設しない系統用蓄電池であってもTSOの出力抑制の対象となる場合があるため、すべての構成で必須です。太陽光に紐づくチャネルのうち、実際に対象外となるのは日射量のみです。

EMSはスタンドアロン蓄電池の必須+許容セットからのみメトリックをパブリッシュします。AWS IoT Coreはゲートウェイの証明書に基づきブローカー層でトピックスコープを強制するため、許可されていないメトリックトピックへのパブリッシュは接続時に拒否され、Tensor Cloudには到達しません。

合格基準: AWS IoT Coreがゲートウェイの証明書に基づきブローカー層でトピックスコープを強制し、許可されていないメトリックトピックが接続時に拒否されること。

PT-ACACリンクのメトリックセット

• 必須メトリック: インテグレーションガイドに従うACリンクの蓄電池および太陽光メトリック。
• 条件付きメトリック: 該当する場合の需要家および系統充電メトリック。
• 禁止メトリック: DCリンク専用メトリック。

EMSはACリンクの必須+許容メトリックのみをパブリッシュし、DCリンク専用メトリックは送信しません。

合格基準: ACリンクの必須および許容メトリックのみが、いかなるテレメトリトピックにも現れること。

PT-DCDCリンクのメトリックセット

• 必須メトリック: インテグレーションガイドに従うDCリンクの蓄電池および太陽光メトリック(系統充電が可能な場合は grid_to_inverter_ac を含む)。
• 条件付きメトリック: 該当する場合の需要家メトリック。
• 禁止メトリック: ACリンク専用メトリック。

EMSはDCリンクの必須+許容メトリックのみをパブリッシュし、ACリンク専用メトリックは送信しません。系統充電が可能な場合は grid_to_inverter_ac を含みます。

合格基準: DCリンクの必須および許容メトリックのみが、いかなるテレメトリトピックにも現れること。