メインコンテンツへ

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

ダウンロード

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

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

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

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

モジュールの選択​

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

プロジェクトタイプ接続、トピック、エンベロープ、蓄電池テレメトリ、エネルギー、アラート、バックフィル太陽光サイト需要家制約モジュール
スタンドアロン蓄電池必須--スタンドアロン
AC リンク蓄電池+ PV必須必須条件付きAC リンク
DC リンク蓄電池+ PV必須必須条件付きDC リンク
提供するサービス追加するモジュール
エネルギーアービトラージアービトラージ
FCR / 調整力サービスFCR
サイト需要家(Load)テレメトリサイト需要家

モジュール: 接続​

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

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

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

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

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

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

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

C-3 - CA チェーン検証​

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

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

C-7 - トピッククラスごとの QoS ポリシー​

EMS はコマンドトピック、テレメトリトピック、確認応答トピックに対し、ドキュメント記載の QoS 値を使用します。ack-cmd/{siteId} 上のアプリケーションレベル確認応答は、MQTT QoS によらず常に必須です。

合格基準: トピッククラスごとのパブリッシュ QoS が文書化されたポリシーに合致すること。ブローカー QoS の設定がアプリケーション ack を不要に見せる場合でも、EMS は各コマンドに対し CommandResponse を必ず送ること。

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

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

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

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

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

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

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

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

T-1 - siteId のフォーマット​

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

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

T-2 - gatewayId のフォーマット​

ゲートウェイ識別子は 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}/alert
  • dt/{siteId}/{gatewayId}/alert/active
  • ack-cmd/{siteId}

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

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

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

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

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

T-5 - res_topic の名前空間​

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

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

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

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

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

T-7 - ack-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-2 - schema_version の値​

本リビジョンの仕様下で送信されるすべてのメッセージで、schema_version は "2.2.0" です。Tensor Cloud は古い仕様リビジョンで送信されたメッセージとの後方互換性を維持します。

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

E-3 - message_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-4 - command_id の相関​

すべての CommandResponse は、対応するコマンドの message_id と等しい command_id を持ちます。

合格基準: テスト中に送信される代表的なコマンド群に対し、すべての応答の command_id がいずれかのコマンドの message_id に一致すること。

E-5 - タイムスタンプ​

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

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

E-6 - additionalProperties ポリシー​

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

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

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

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

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 分未満の連続的な送信)でパブリッシュされます。

合格基準: 代表的な観測期間にわたって、観測された送信頻度が文書化された期待値に一致すること。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

合格基準: 必須の各エネルギーフローメトリックに対し、少なくとも 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} パラメーター(5min、30min、60min など)と一致します。

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

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

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

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

モジュール: アラート​

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

A-1 - alertEvent の送信​

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

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

A-2 - alertState のクリア処理​

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

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

A-4 - AlertCode 列挙の網羅​

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

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

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

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

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 を生成しないこと。

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

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

AR-1 - 出力指令の受信​

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

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

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

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

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

AR-3 - ack-cmd 成功応答​

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

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

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

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

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

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

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

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

AR-6 - ErrorCode マッピング​

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 を発出すること。同一の失敗クラスが実行をまたいで常に同じコードを生成すること。

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

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

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

AR-8 - コマンド内の重複​

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

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

AR-9 - 空のスケジュール​

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

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

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

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

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

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

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

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

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

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

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

モジュール: FCR (BatteryFcrCommand)​

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

FC-1 - FCR コマンドの受信​

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

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

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

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

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

FC-3 - execute では capacity_kw が必須​

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

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

FC-4 - cancel では capacity_kw を禁止​

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

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

FC-7 - アービトラージとの FCR ベースライン合成​

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

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

モジュール: 太陽光​

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

SO-1 - 日射量テレメトリ​

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

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

SO-2 - 日射量の送信頻度​

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

合格基準: 観測された送信頻度が文書化された期待値に合致すること。

SO-3 - 出力抑制(カーテイルメント)の報告​

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

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

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

metric enum の PV 関連メトリック(pv_to_inverter_ac など)が電力トピックにパブリッシュされます。

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

SO-5 - inverter_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 に等しいこと。

モジュール: サイト需要家 (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 が送信されること。

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

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

スタンドアロン​

  • 必須メトリック: metric enum の蓄電池関連メトリックのみ。
  • 禁止メトリック: 太陽光メトリック、需要家メトリック、DC リンク専用メトリック。

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

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

Test PT-AC - AC リンクのメトリックセット。 EMS は AC リンクの必須+許容メトリックのみをパブリッシュします。DC リンク専用メトリックがいかなるテレメトリトピックにも現れません。

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

Test PT-DC - DC リンクのメトリックセット。 EMS は DC リンクの必須+許容メトリックのみをパブリッシュします。AC リンク専用メトリックがいかなるテレメトリトピックにも現れません。