なぜ私のBMSは通信していないのか？商業用BESS通信障害のトラブルシューティング

バッテリーは正常でした。メッセージが通過していませんでした。

商業用BESSにおけるBMS通信の障害は、通常、BMSを交換するための十分な証拠とはなりません。まず、どの通信経路が失敗したのかを正確に特定し、その後、電力と動作状態、物理配線、インターフェースの種類、終端、ノード/アドレス設定、プロトコル選択、ファームウェアの互換性、実際のメッセージトラフィックを確認してください。通信アラームとバッテリー故障は、異なる診断問題です。

技術者がHMIが表示したために何時間も失うのを見たことがあります。BMS通信障害そして、皆がすぐにバッテリラックについて話し始めました。

私の最初の質問はもっと簡単です：

誰が誰との通信を停止しましたか？

C&I BESSでは、「BMS通信」はラックBMSからマスタBMS、BMSからPCS、BMSからEMS、またはエネルギー貯蔵システムからSCADA/クラウド監視への経路を説明することがあります。Dawniceの現在のC&I製品はその多様性を示しています：そのBS09-225-DはCAN/RS485通信を公開し、BS07-265-ES-XはModbus TCP/RTUおよびEMS/クラウドの準備状況を公開します。Dawnice BS09-225-D Dawnice BS07-265-ES-X

同じ広範な症状。

潜在的に非常に異なる故障。

08:17 — PCSが「BMSなし」と言いました

仮想の400 kWh商業バッテリーがPCSに接続されていると考えてみてください。

システムは金曜日に正しく委託されました。

月曜日の朝：

バッテリーHMI：正常
ラック電圧：存在
セル温度：妥当
PCS：BMS通信が失われました
EMS：バッテリーが利用できません
接触器：オープン

言いたい誘惑があります：

"BMSが故障しました。"

私はそうは言いません。

もしローカルバッテリーHMIがセルと温度を正しく読み取っているなら、BMSは明らかにその仕事の少なくとも一部を果たしています。故障した境界はBMSとPCSの間かもしれません。

それは調査をすぐに変えます。

何かに触れる前にアラームのタイムスタンプを記録し、それをBMS、PCS、EMSのイベントログと比較します。

もし三つの時計が6分ずれているなら、その問題も修正します。イベントの年代記が信頼できないと、根本原因分析は驚くほど厄介になります。

私はノートパソコンを開く前に退屈なことを確認します

交換用通信ケーブルは、洗練されたプロトコル分析よりも多くの故障を解決してきました。

ソフトウェアを変更する前に、知りたいことがあります：

BMSは電源が入っていて完全に起動していますか？

正しい通信ポートが使用されていますか？

コネクタは完全に接続されていますか？

ケーブルのピン配置はRJ45コネクタから仮定されたのではなく、確認されましたか？

CAN-H/CAN-LまたはRS485 A/Bは正しく接続されていますか？

シールド/接地は承認された設計と一致していますか？

ケーブルは損傷、圧縮、延長、または騒音の多い電力導体の横に再配線されていませんか？

RJ45は心理的に特に危険です。二つのデバイスが同じコネクタを使用し、全く異なるピン割り当てを持つことがあります。

例えば、Dawniceのバッテリーマニュアルは、一般的なネットワークケーブルが互換性があると暗示するのではなく、CANとRS485の通信ピンを別々に定義しています。Dawniceバッテリーマニュアル

コネクタの形状はプロトコルではありません。

それは配線定義ですらありません。

複数のラックが一度に消える場合、個々のラックを責めるのをやめます

故障パターンは私にどこを探すべきかを教えてくれます。

その表はシステムマニュアルの代わりにはなりません。

それは一つの共有通信リンクが故障したために、四つの健康なバッテリーモジュールを交換するのを避ける方法です。

CANとRS485は異なる方法で故障します

"通信ケーブル"を一つのカテゴリとして扱いません。

CANネットワークでは、トポロジー、CAN-H/CAN-Lの極性、ビットレート、ノード構成、終端、および期待されるフレームが実際に存在するかを確認したいです。

RS485/Modbus RTUネットワークでは、A/Bの極性、スレーブアドレス、ボーレート、パリティ、ストップビット、レジスタマッピング、終端について考え始めます。

そのModbus Organizationは現在のプロトコルとシリアルラインの実装仕様を維持しています。そのシリアルラインガイダンスは、終端と極性をネットワーク設計の特性として扱い、通信が不安定になるたびに追加する任意の抵抗器ではありません。

ここで私は馴染みのあるものに対して慎重になります：

"60オームを測定すれば完了です。"

二つの120オームの終端が並列に接続されていると、無電源のバス上でおおよそ60オームを生成できますが、その読み取りはそのように設計されたトポロジーで、適切な条件下で測定された場合にのみ意味があります。

それはアドレス、ボーレート、プロトコル、またはデータマッピングが正しいことを証明するものではありません。

有用な数字の一つ。診断ではありません。

緑の通信LEDはまだあなたに嘘をついている可能性があります

物理リンクが正常に見えると仮定します。

フレームが移動しています。

PCSはまだ動作を拒否しています。

今、私はスタックを上に移動します。

BMSとPCSは電気信号以上のことに合意する必要があります。アーキテクチャによっては、次のために互換性のある定義が必要になる場合があります：

SoC

SoH

パック電圧/電流

最大充電電流

最大放電電流

充電/放電有効

アラーム状態

接触器状態

温度制限

ハートビート/ウォッチドッグ

CANバスは電気的に完璧である一方、PCSは異なるメッセージセットを待機している場合があります。

同様に、Modbusマスターは間違ったレジスタを読みながらスレーブと正常に通信できます。

だからこそ、「CANをサポート」または「Modbusをサポート」は互換性の声明ではありません。

それは私に言語ファミリーを教えてくれます。

二つのデバイスが同じ会話を理解しているかどうかではありません。

プロトコル選択は実際の故障であり、設定の詳細ではありません

これが私がハードウェアを交換する前に設定を確認するのが好きな理由の一つです。

例えば、Dawniceインバーターマニュアルは、BMS通信障害 [58]と記載し、技術者に通信ケーブルと設定されたリチウムバッテリー通信プロトコルがバッテリーに対応しているかを確認するよう指示します。Dawniceインバーターマニュアル

そのトラブルシューティングロジックは一つの製品を超えてスケールします。

委託エンジニアが選択したと仮定します：

バッテリープロトコル03

代わりに：

バッテリープロトコル08

ケーブルは完璧です。

BMSは正常です。

PCSは正常です。

システムはまだ動作しません。

何も「壊れていません」。

構成が間違っています。

Ruibit/Dawniceの商業プロジェクトの場合、承認されたBMS–PCS通信の組み合わせを電気BOMとともに凍結します：正確なバッテリー/BMSバージョン、PCSモデル、プロトコル、インターフェース、パラメータセット、ファームウェアバージョン。

ファームウェアの変更は、ドライバーがキャビネットに触れなくてもコンポーネントの変更になることがあります。

間欠的な通信は、私がより真剣に受け止める故障です

完全に死んだリンクはしばしば簡単です。

間欠的なリンクはFATを通過し、委託を生き延び、その後現場が熱く、過負荷になったり、電気的にノイズが多くなると失敗することがあります。

PCSが80％の電力を超えるときだけ通信が途切れると想像してください。

そのタイミングが重要です。

ランダムなソフトウェアを非難する前に、ルーティングと電磁干渉を調査します。

問題が電力に関係なく20秒ごとに現れる場合、ハートビート/ウォッチドッグのタイミングを確認するかもしれません。

5つ目のラックを追加した後に現れる場合、トポロジー、アドレッシング、終端を見直します。

ファームウェアの改訂3.12の直後に始まる場合、誰かが別の更新を行う前に前のバージョン番号を知りたいです。

故障が現れる条件は証拠です。

最初にすべてを再起動して消去しないでください。

私の診断順序は高価な推測を防ぐように設計されています

私は通常外側から内側に向かって作業します：

1. 失敗した通信の境界を定義します

BMS–ラック？ BMS–PCS？ PCS–EMS？ EMS–SCADA？

2. 証拠を保存します

アラームコード、タイムスタンプ、スクリーンショット、ファームウェアバージョン、最近の変更。

3. 動作状態を確認します

電源、BMS状態、接触器、ローカルアラーム。

4. 物理層を確認します

ケーブル、ピン配置、極性、コネクタ、トポロジー、終端、シールド。

5. 通信設定の確認

インターフェース、ノードID、ボーレート、ビットレート、パリティおよびプロトコルの選択。

6. データ層の確認

フレーム、レジスタマップ、スケーリング、ハートビートおよびコマンド/ステータスの交換。

7. 変更履歴の確認

ファームウェア、交換部品、パラメータ変更およびネットワークの変更。

プロトコル分析では緩んだコネクタを修理できないため、ステップ6に直接飛びません。

連続性が互換性を証明するわけではないため、ステップ4で止まりません。

システムの動作が修正されたとき、故障は修正されます

通信アラームを消すことは私の受け入れ基準ではありません。

修理後、PCSが妥当なバッテリーデータを受信し、BMSの制限を尊重することを確認したいです。

バッテリー温度が上昇したためにBMSが許容充電電流を減少させた場合、PCSはそれに従いますか？

放電許可が取り消された場合、実際に電力は停止しますか？

SoCはEMSに正しく到達しますか？

アラームはリモートで表示されますか？

制御された再起動後、通信は正しく回復しますか？

タイムスタンプは整列していますか？

Dawniceは現在、C&IシステムがCAN、RS485および関連する監視プラットフォームを通じてリモート監視および診断をサポートしていると述べており、C&Iバッテリー/PCSの組み合わせに対する特定の通信接続チュートリアルを公開しています。ドーニスFAQ Dawniceテクニカルサポート

B2Bバイヤーにとって、その最後のポイントは思っている以上に重要です。

バッテリーとPCSだけを購入しないでください。

購入するのは、確認された通信関係それらの間で、バージョン、設定、サポート責任が記録されているものです。

BESSが「BMS通信失敗」と言うとき、高価な間違いはアラームで最初に名前が挙がったコンポーネントが故障したコンポーネントだと仮定することです。

まず壊れた会話を見つけてください。次にハードウェアを交換します。

よくある質問

1. なぜ私のBMSはPCSと通信していないのか？

一般的な原因には、不適切な配線またはピン配置、CAN/RS485の極性、誤ったプロトコル選択、アドレス設定、終端、ファームウェアの互換性の問題、損傷したケーブル、または通信ポートの設定が含まれます。.

2. BMS通信アラームはBMSが故障していることを意味しますか？

いいえ。BMSはセルを正しく監視している可能性がありますが、BMSとPCS、EMS、マスタBMS、またはSCADA間の通信が失敗している場合があります。ハードウェアを交換する前に、失敗した通信境界を特定してください。

3. 2つのデバイスがCANまたはRS485をサポートしていても、互換性がないことはありますか？

はい。同じ物理インターフェースを共有しても互換性が保証されるわけではありません。デバイスはまた、プロトコル、ビットレートまたはボーレート、メッセージ/レジスタ定義、アドレッシング、データスケーリング、および制御ロジック.

4. なぜBMS通信が間欠的に失敗するのか？

間欠的な故障は、緩んだコネクタ、不適切な終端、電気ノイズ、ケーブルルーティング、不安定な電源、ネットワークトポロジー、ウォッチドッグタイミング、またはファームウェアの問題から生じる可能性があります。システムを再起動する前に故障が発生した時刻を記録してください。

5. BMS通信の故障を修正した後に確認すべきことは何ですか？

PCSが正しい情報を受信していることを確認しますSoC、電圧、電流、温度、アラーム、および充電/放電制限、BMS保護コマンドに従い、EMSに正しく報告し、制御された再起動後に通信を回復します。