3つのデバイスが同じプロトコルをサポートしていても、通信に失敗することがあります
商業用BESSでは、BMSがバッテリーの状態と運用限界を報告し、PCSが電力を変換し、充電/放電コマンドを実行し、EMSがその電力がサイトの目的に従って移動すべき時を決定します。通信は通常、CAN、RS485、Modbus RTU/TCP、またはEthernetベースのインターフェースを使用します。しかし、プロトコル名を共有することは互換性を証明するものではありません。デバイスはデータマップ、スケーリング、アドレス、タイミング、制御権限、アラームロジック、フェイルセーフ動作についても合意する必要があります。
DOEのBESSアーキテクチャは、これらを異なる制御層として示しています：BMSはバッテリーモジュールの近くに位置し、PCSは電力変換を制御し、EMSはサイト制御レベルで動作します。
その階層は、1つのコマンドに従うと理解しやすくなります。
EMSは100 kWと言います。PCSは単に従うことができません。
工場の需要がピーク限界に近づくと想像してください。
EMSは計算します：
必要なBESS放電 = 100 kW
それはPCSに向けて電力要求を送信します。
しかし、100 kWを提供する前に、制御チェーンには別の意見があります。
BMSは現在次のように報告するかもしれません：
SoC: 24%
最大許可放電：62 kW
おそらくSoC、セル電圧、温度、電流、または他のバッテリー制約のためです。
正しい結果は次のようにはなりません：
EMSコマンド = 100 kW → PCS出力 = 100 kW
PCSはバッテリーの許可された範囲内で動作しなければなりません。
概念的には：
BMS → “バッテリーが許可されていること”
EMS → “サイトがバッテリーにしてほしいこと”
PCS → “実際に実行可能な電力変換”
その分離は安全なBESS制御にとって基本的です。
CANとModbusは言語であり、合意ではありません
ここで調達仕様が過度に楽観的になることがよくあります。
サプライヤーAは言います：
BMS通信：CAN。
サプライヤーBは言います：
PCSはCANをサポートしています。
バイヤーは書きます：
互換性があります。
まだです。
CANは通信メカニズムを説明します。デバイスは依然として互換性のあるメッセージ定義が必要です。
同じ問題がModbusにも見られます。
2つのデバイスは両方ともModbus RTUをサポートしているかもしれませんが、次の点で意見が異なる場合があります：
レジスタアドレス
データ型
バイト順序
スケーリング
読み書き権限
デバイスID
更新レート
アラームコード
レジスタ値は500次のことに全員が同意するまで無意味です：
500 A
50.0 A
または全く別の何か。
そのため、運用開始前に実際の通信プロトコルまたはレジスタマップを要求します。
ドーニス製品インターフェースがシステムの境界に依存する理由を示す
すべての商業用バッテリー製品が同じインターフェースを公開しているわけではありません。
DawniceのBS09-225-D 225.07 kWh DC側システムは、例えば、CAN/RS485インターフェースを公開し、CANをBMS通信方法として特定します。
その統合されたBS07-265-ES-X 125 kW/265.3 kWhシステムは代わりにModbus TCP/RTUおよびEMS/クラウドの準備状況を公開します。
ダウニスの1 MW/2.089 MWhコンテナ仕様は、EMS通信を通じてRS485およびTCP/IPをリストしています。.
これらの違いは理解できます。
DC側のバッテリーは外部PCSとのインターフェースが必要です。
オールインワンシステムは、内部にバッテリーとPCSの関係をより多く含んでいます。
コンテナ化されたプラントは、EMS、監視、メーター、そして潜在的にはサイトSCADAとの高レベルの通信が必要です。
通信アーキテクチャはシステム境界に従います。.
メーターも会話の一部です
ピークシェービングは良い例を示します。
サイトメーターは次のように報告します：
グリッドインポート = 680 kW
EMSの目標は：
600 kWです。
EMSはおおよそ計算します：
80 kWの放電が必要です。
そしてコマンドを送信します。
PCSがそれを実行します。
その後、メーターは新しいグリッド条件を報告し、EMSが再調整できるようにします。
したがって、実際のループは次のように近づきます：
サイトメーター → EMS → PCS ↔ BMS → PCS → サイトメーター
これが、逆CTや不正確なメーターのスケーリングが完全に健康なバッテリーを不正に動作させる理由です。
EMSは悪い情報から合理的な決定を下しています。
DOEのBESS通信アーキテクチャも同様に、メーター、EMS、PCS、BMS、環境制御、HMI、火災システム、ネットワークインフラを含み、バッテリー通信を1本のCANケーブルとして扱いません。
通信の失敗には定義された安全な状態が必要です
今、EMSネットワークのプラグを抜いてください。
何が起こるべきですか？
その答えは設計仕様に属します。
アプリケーションと承認されたアーキテクチャに応じて、システムは：
定義された期間、最後の有効なコマンドを続行するか、
ローカルPCS制御に戻るか、
電力を削減するかもしれません。
充電/放電を停止する
アラームを上げる
または別の事前定義された安全状態に入る。
同じ質問が適用されるのは次のときです：
BMS–PCS通信が失敗したとき
メーターデータが消失したとき
クラウド接続が失われたとき
SCADAが利用できなくなったとき
これらの失敗は同等ではありません。
クラウドの障害は、安全なバッテリー運用に必要なBMSの制限を失うことと必ずしも同じ結果をもたらすわけではありません。
したがって、通信損失マトリックスは次のように定義する必要があります：
リンク喪失 → タイムアウト → フォールバックアクション → アラーム → 回復条件
SATの前に。
責任マトリックスはプロトコルリストよりも重要です
この表を技術契約に入れたいと思います：
| インターフェース | データ / 機能 | 責任者 |
|---|---|---|
| バッテリー ↔ PCS | 制限、SoC、アラーム、コマンド | 指定されたサプライヤー/インテグレーター |
| PCS ↔ EMS | 電力コマンド/ステータス | 指定されたサプライヤー/インテグレーター |
| メーター ↔ EMS | グリッド/負荷測定 | EPC / EMS 関係者 |
| EMS ↔ SCADA | 監視/制御 | EMS / サイトインテグレーター |
| リモートプラットフォーム | データ/サポートアクセス | 定義されたサプライヤー |
| ネットワークインフラ | IP/VLAN/ファイアウォール | サイト/EPCの責任 |
最後の列は、驚くほど一般的なコミッショニングの会話を防ぎます：
バッテリー供給者：
「私たちのCANは動作します。」
PCS供給者：
「私たちのCANは動作します。」
インテグレーター：
「それなら、なぜ通信しないのですか？」
Dawniceの技術サポートライブラリには、次のような組み合わせのための専用通信手順が含まれています：Solis 50 kW PCSとDawnice 100/143 kWhストレージおよびMegarevo 500 kW PCSとDawnice 860 kWh C&Iストレージこれは、実際のデバイスのペアリングには、データシートにプロトコルをリストする以上の構成と統合作業が必要であることを示しています。
インターフェースが完成したと呼ぶ前にテストすべきこと
すべてのデバイスが緑のアイコンを表示しているからといって、通信が委託されたとは考えません。
FAT/SATの間に、私は次を証明したいです：
SoCと温度の値が正しくスケーリングされていること
BMSの充電/放電制限がPCSに到達していること
EMSの電力コマンドが正しく実行されること
メーターの方向とスケーリングが正しい
アラームが意図したHMI/SCADAに伝播する
タイムスタンプが一致する
通信損失の動作が仕様に一致する
通信が復帰した後、システムが正しく回復する
Ruibit/Dawniceプロジェクトの場合、外部のPCS、EMS、メーター、またはSCADAシステムが関与する場合、出荷前にその責任を凍結すべきです。DawniceはそのC&Iを述べています製品標準インターフェースをサポートし、CAN、RS232、RS485を含み、より大規模なC&Iプロジェクトのためのシステム統合および commissioningサービスを提供します。
プロトコルリストは、どの会話が可能かを教えてくれます。
委託されたBESSは、デバイスが同じデータを理解し、同じ制御階層を尊重し、会話が停止したときに安全に失敗し、インターフェースを機能させる責任が誰にあるかについての曖昧さを残さないことを証明します。
よくある質問
1. 商業用BESSにおいてBMS、PCS、EMSはどのように通信しますか？
そのBMSはバッテリーの状態、SoC、アラーム、および運用限界を提供します、EMSは必要な充電または放電電力を決定します、そしてPCSはバッテリーおよびシステムの限界を尊重しながら電力変換コマンドを実行します.
2. 商業用BESSで一般的に使用される通信プロトコルは何ですか？
一般的なインターフェースにはCAN、RS485、Modbus RTU/TCP、およびEthernetベースの通信が含まれます。同じプロトコルをサポートすることは、デバイス間の互換性を自動的に保証するものではありません。
3. なぜ2つのBESSデバイスがCANまたはModbusをサポートしていても、通信に失敗することがあるのですか？
異なるメッセージ定義、レジスタアドレス、スケーリング、バイトオーダー、デバイスID、更新レート、アラームコード、または制御ロジックを使用する可能性があります。したがって、実際のプロトコル/レジスタマップは確認する必要があります。
4. BMS、PCS、またはEMSの通信が失われた場合、何が起こるべきですか？
システムは失敗したインターフェースに基づいて事前定義された状態に入るべきです。仕様はタイムアウト、フォールバックアクション、アラーム動作、および回復条件を定義する必要があります各通信障害について。
5. BMS–PCS–EMS統合の責任は誰ですか？
責任はプロジェクト文書で明示的に割り当てるべきです。購入者は、バッテリー、PCS、EMS、メーター、SCADA、リモートプラットフォーム、およびサイトネットワークの間の各インターフェースの所有者を定義する必要がありますFATおよびcommissioningの前に。
