Mengapa BMS Saya Tidak Berkomunikasi? Memecahkan Masalah Kegagalan Komunikasi BESS Komersial

Baterai dalam kondisi baik. Pesan tidak sampai.

Kegagalan komunikasi BMS dalam BESS komersial biasanya tidak cukup bukti untuk mengganti BMS. Mulailah dengan mengidentifikasi jalur komunikasi mana yang telah gagal, kemudian verifikasi daya dan keadaan operasi, pengkabelan fisik, jenis antarmuka, terminasi, pengaturan node/alamat, pemilihan protokol, kompatibilitas firmware, dan lalu lintas pesan yang sebenarnya. Alarm komunikasi dan kesalahan baterai adalah dua masalah diagnostik yang berbeda.

Saya telah melihat teknisi menghabiskan berjam-jam karena HMI menunjukkanKesalahan Komunikasi BMSdan semua orang segera mulai membahas rak baterai.

Pertanyaan pertama saya lebih sederhana:

Siapa yang berhenti berbicara dengan siapa?

Dalam BESS C&I, "komunikasi BMS" dapat menggambarkan BMS rak ke BMS master, BMS ke PCS, BMS ke EMS, atau jalur dari sistem penyimpanan energi ke pemantauan SCADA/cloud. C&I saat ini milik DawniceProdukmengilustrasikan variasi: BS09-225-D-nya menerbitkanantarmuka CAN/RS485komunikasi, sementara BS07-265-ES-X-nya mencantumkanModbus TCP/RTUdan kesiapan EMS/cloud.Dawnice BS09-225-D Dawnice BS07-265-ES-X

Gejala yang sama secara umum.

Kesalahan yang mungkin sangat berbeda.

08:17 — PCS Mengatakan "Tidak Ada BMS"

Pertimbangkan baterai komersial hipotetis 400 kWh yang terhubung ke PCS.

Sistem diresmikan dengan benar pada hari Jumat.

Senin pagi:

HMI Baterai:normal
Tegangan rak:ada
Suhu sel:masuk akal
PCS:komunikasi BMS hilang
EMS:baterai tidak tersedia
Kontaktor:buka

Godaan untuk mengatakan:

"BMS telah gagal."

Saya tidak akan.

Jika HMI baterai lokal masih membaca sel dan suhu dengan benar, BMS jelas melakukan setidaknya sebagian dari tugasnya. Batas yang gagal mungkin berada antara BMS dan PCS.

Itu mengubah penyelidikan segera.

Saya akan mencatat cap waktu alarm sebelum menyentuh apa pun, kemudian membandingkannya dengan log kejadian BMS, PCS, dan EMS.

Jika ketiga jam tidak setuju selama enam menit, saya juga akan memperbaiki masalah itu. Analisis akar penyebab menjadi sangat rumit ketika kronologi kejadian tidak dapat diandalkan.

Saya Memeriksa Hal-Hal Membosankan Sebelum Membuka Laptop

Kabel komunikasi pengganti telah menyelesaikan lebih banyak kesalahan daripada analisis protokol yang elegan.

Sebelum mengubah perangkat lunak, saya ingin tahu:

Apakah BMS teraliri daya dan sepenuhnya aktif?

Apakah port komunikasi yang benar digunakan?

Apakah konektor terpasang dengan baik?

Apakah pinout kabel diverifikasi, bukan diasumsikan dari konektor RJ45?

Apakah CAN-H/CAN-L atau RS485 A/B terhubung dengan benar?

Apakah pelindung/peng grounding konsisten dengan desain yang disetujui?

Apakah kabel telah rusak, terjepit, diperpanjang, atau dialihkan di samping konduktor daya yang bising?

RJ45 sangat berbahaya secara psikologis. Dua perangkat dapat menggunakan konektor identik dan penugasan pin yang sama sekali berbeda.

Manual baterai Dawnice sendiri, misalnya, secara terpisah mendefinisikan pin komunikasi CAN dan RS485 daripada mengimplikasikan bahwa kabel jaringan biasa dapat dipertukarkan.Manual Baterai Dawnice

Bentuk konektor bukanlah protokol.

Ini bahkan bukan definisi pengkabelan.

Jika Beberapa Rak Menghilang Sekaligus, Saya Berhenti Menyalahkan Rak Individu

Pola kegagalan memberi tahu saya di mana harus mencari.

Tabel itu bukan pengganti manual sistem.

Ini adalah cara untuk menghindari mengganti empat modul baterai yang sehat karena satu tautan komunikasi bersama gagal.

CAN dan RS485 Gagal dengan Cara yang Berbeda

Saya tidak menganggap "kabel komunikasi" sebagai satu kategori.

Di jaringan CAN saya ingin memverifikasi topologi, polaritas CAN-H/CAN-L, bitrate, konfigurasi node, terminasi dan apakah frame yang diharapkan benar-benar ada.

Di jaringan RS485/Modbus RTU, saya mulai memikirkan polaritas A/B, alamat slave, baud rate, paritas, bit berhenti, pemetaan register, dan terminasi.

YangOrganisasi Modbusmempertahankan spesifikasi implementasi protokol dan jalur serial saat ini. Panduan jalur serialnya memperlakukan terminasi dan polaritas sebagai properti desain jaringan, bukan resistor sewenang-wenang yang ditambahkan kapan pun komunikasi menjadi tidak dapat diandalkan.

Ini adalah saat saya menjadi berhati-hati tentang yang sudah dikenal:

"Ukur 60 ohm dan Anda selesai."

Dua terminasi 120-ohm secara paralel dapat menghasilkan sekitar 60 ohm pada bus yang tidak diberdayakan, tetapi pembacaan itu hanya berarti untuk topologi yang dirancang seperti itu dan diukur dalam kondisi yang sesuai.

Ini tidak membuktikan bahwa alamat, baud rate, protokol, atau pemetaan data benar.

Satu angka yang berguna. Bukan diagnosis.

LED Komunikasi Hijau Masih Bisa Berbohong kepada Anda

Misalkan tautan fisik terlihat sehat.

Frame sedang bergerak.

PCS masih menolak untuk beroperasi.

Sekarang saya bergerak ke atas melalui tumpukan.

BMS dan PCS harus sepakat tentang lebih dari sekadar sinyal listrik. Tergantung pada arsitektur, mereka mungkin memerlukan definisi yang kompatibel untuk:

SoC

SoH

tegangan/arus paket

arus pengisian maksimum

arus pengosongan maksimum

pengisian/pengosongan aktif

status alarm

status kontak

batas suhu

denyut jantung/watchdog

Bus CAN dapat secara elektrik sempurna sementara PCS mendengarkan untuk set pesan yang berbeda.

Demikian pula, master Modbus dapat berhasil berkomunikasi dengan slave sambil membaca register yang salah.

Itulah mengapa "mendukung CAN" atau "mendukung Modbus" bukan pernyataan kompatibilitas.

Ini memberi tahu saya keluarga bahasa.

Bukan apakah kedua perangkat memahami percakapan yang sama.

Pemilihan Protokol adalah Kesalahan Nyata, Bukan Detail Pengaturan

Ini adalah salah satu alasan saya suka memeriksa konfigurasi sebelum mengganti perangkat keras.

Manual inverter Dawnice, misalnya, mengidentifikasikesalahan komunikasi BMS [58]dan mengarahkan teknisi untuk memeriksa kabel komunikasi dan apakah protokol komunikasi baterai lithium yang dikonfigurasi sesuai dengan baterai.Manual Inverter Dawnice

Logika pemecahan masalah ini dapat diterapkan di luar satu produk.

Misalkan seorang insinyur commissioning memilih:

Protokol Baterai 03

daripada:

Protokol Baterai 08

Kabelnya sempurna.

BMS dalam kondisi baik.

PCS dalam kondisi baik.

Sistem masih tidak berfungsi.

Tidak ada yang "rusak."

Konfigurasi salah.

Untuk proyek komersial Ruibit/Dawnice, saya akan membekukan kombinasi komunikasi BMS–PCS yang disetujui bersama dengan BOM listrik: versi baterai/BMS yang tepat, model PCS, protokol, antarmuka, set parameter, dan versi firmware.

Mengganti firmware bisa menjadi perubahan komponen meskipun tidak ada obeng yang menyentuh kabinet.

Komunikasi Sementara adalah Kesalahan yang Saya Anggap Lebih Serius

Tautan yang benar-benar mati seringkali lebih mudah.

Tautan yang tidak stabil dapat lulus FAT, bertahan saat commissioning, dan kemudian gagal ketika lokasi panas, terbebani berat, atau bising secara elektrik.

Bayangkan penurunan komunikasi hanya muncul ketika PCS melebihi 80% daya.

Waktu itu penting.

Saya akan menyelidiki routing dan gangguan elektromagnetik sebelum menyalahkan perangkat lunak acak.

Jika masalah muncul setiap 20 detik terlepas dari daya, saya mungkin akan melihat waktu heartbeat/watchdog.

Jika muncul setelah menambahkan rak kelima, saya akan meninjau topologi, alamat, dan terminasi.

Jika mulai segera setelah revisi firmware 3.12, saya ingin nomor versi sebelumnya sebelum siapa pun melakukan pembaruan lain.

Kondisi yang membuat kesalahan muncul adalah bukti.

Jangan menghapusnya dengan me-reboot semuanya terlebih dahulu.

Urutan Diagnostik Saya Dirancang untuk Mencegah Tebakan yang Mahal

Saya biasanya bekerja dari luar ke dalam:

1. Tentukan batas komunikasi yang gagal

BMS–rak? BMS–PCS? PCS–EMS? EMS–SCADA?

2. Pelihara bukti

Kode alarm, cap waktu, tangkapan layar, versi firmware, dan perubahan terbaru.

3. Verifikasi keadaan operasi

Catu daya, keadaan BMS, kontaktor, alarm lokal.

4. Verifikasi lapisan fisik

Kabel, pinout, polaritas, konektor, topologi, terminasi, pelindung.

5. Verifikasi pengaturan komunikasi

Antarmuka, ID node, laju baud, bitrate, paritas, dan pemilihan protokol.

6. Verifikasi lapisan data

Frame, peta register, skala, heartbeat, dan pertukaran perintah/status.

7. Tinjau riwayat perubahan

Firmware, komponen pengganti, perubahan parameter, dan modifikasi jaringan.

Saya tidak melompat langsung ke Langkah 6 karena analisis protokol tidak dapat memperbaiki konektor yang longgar.

Saya tidak berhenti di Langkah 4 karena kontinuitas tidak membuktikan kompatibilitas.

Kesalahan Diperbaiki Ketika Perilaku Sistem Diperbaiki

Menghilangkan alarm komunikasi bukanlah kriteria penerimaan saya.

Setelah perbaikan, saya ingin memastikan bahwa PCS menerima data baterai yang masuk akal dan menghormati batas BMS.

Jika BMS mengurangi arus pengisian yang diizinkan karena suhu baterai meningkat, apakah PCS mengikutinya?

Jika izin pengosongan dicabut, apakah daya benar-benar berhenti?

Apakah SoC mencapai EMS dengan benar?

Apakah alarm muncul dari jarak jauh?

Apakah komunikasi pulih dengan benar setelah restart terkontrol?

Apakah cap waktu selaras?

Dawnice saat ini menyatakan bahwa sistem C&I-nya mendukung pemantauan dan diagnostik jarak jauh melalui antarmuka termasuk CAN, RS485, dan platform pemantauan terkait, dan menerbitkan tutorial koneksi komunikasi spesifik untuk kombinasi baterai/PCS C&I.FAQ Dawnice Dukungan Teknis Dawnice

Bagi pembeli B2B, poin terakhir itu lebih penting daripada yang terlihat.

Jangan hanya membeli baterai dan PCS.

Beli sebuahhubungan komunikasi yang terverifikasiantara keduanya, dengan versi, pengaturan, dan tanggung jawab dukungan yang tercatat.

Karena ketika BESS mengatakan "kegagalan komunikasi BMS," kesalahan mahal adalah menganggap komponen pertama yang disebutkan dalam alarm adalah komponen yang gagal.

Temukan percakapan yang rusak terlebih dahulu. Ganti perangkat keras kedua.

FAQ

1. Mengapa BMS saya tidak berkomunikasi dengan PCS?

Penyebab umum termasukpengkabelan atau pinout yang salah, polaritas CAN/RS485, pemilihan protokol yang salah, pengaturan alamat, terminasi, ketidakcocokan firmware, kabel yang rusak, atau konfigurasi port komunikasi..

2. Apakah alarm komunikasi BMS berarti BMS telah gagal?

Tidak. BMS mungkin masih memantau sel dengan benar sementara komunikasi gagal antara BMS dan PCS, EMS, BMS utama, atau SCADA. Identifikasi batas komunikasi yang gagal sebelum mengganti perangkat keras.

3. Dapatkah dua perangkat mendukung CAN atau RS485 dan tetap tidak kompatibel?

Ya. Berbagi antarmuka fisik yang sama tidak menjamin kompatibilitas. Perangkat juga harus sepakat tentangprotokol, bitrate atau baud rate, definisi pesan/registrasi, pengalamatan, skala data, dan logika kontrol.

4. Mengapa komunikasi BMS gagal secara sementara?

Kesalahan sementara dapat disebabkan oleh konektor yang longgar, terminasi yang buruk, gangguan listrik, pengaturan kabel, pasokan daya yang tidak stabil, topologi jaringan, waktu watchdog, atau masalah firmware. Catat kapan kesalahan terjadi sebelum merestart sistem.

5. Apa yang harus diverifikasi setelah memperbaiki kesalahan komunikasi BMS?

Konfirmasi bahwa PCS menerima dengan benarSoC, tegangan, arus, suhu, alarm, dan batas pengisian/pengosongan, mengikuti perintah perlindungan BMS, melaporkan dengan benar ke EMS, dan memulihkan komunikasi setelah restart yang terkendali.