Bagaimana BMS, PCS, dan EMS Berkomunikasi dalam BESS Komersial? Antarmuka, Protokol, dan Tanggung Jawab Integrasi

Tiga Perangkat Dapat Mendukung Protokol yang Sama dan Masih Gagal Berkomunikasi

Dalam BESS komersial, BMS melaporkan status baterai dan batas operasional, PCS mengubah daya dan mengeksekusi perintah pengisian/pengosongan, dan EMS memutuskan kapan daya tersebut harus bergerak sesuai dengan tujuan situs. Komunikasi umumnya menggunakan antarmuka berbasis CAN, RS485, Modbus RTU/TCP, atau Ethernet. Namun, berbagi nama protokol tidak membuktikan kompatibilitas—perangkat juga harus sepakat tentang peta data, skala, alamat, waktu, otoritas kontrol, logika alarm, dan perilaku aman.

Arsitektur BESS DOE menggambarkan ini sebagai lapisan kontrol yang berbeda: BMS berada dekat dengan modul baterai, PCS mengontrol konversi daya, sementara EMS beroperasi di tingkat kontrol situs.

Hierarki itu lebih mudah dipahami jika kita mengikuti satu perintah.

EMS Mengatakan 100 kW. PCS Tidak Bisa Saja Mematuhi.

Bayangkan permintaan pabrik mendekati batas puncaknya.

EMS menghitung:

Pengosongan BESS yang Diperlukan = 100 kW

Ia mengirim permintaan daya ke arah PCS.

Namun sebelum mengirimkan 100 kW, rantai kontrol memiliki pendapat lain.

BMS mungkin saat ini melaporkan:

SoC: 24%

Pengosongan maksimum yang diizinkan: 62 kW

mungkin karena SoC, tegangan sel, suhu, arus, atau batasan baterai lainnya.

Hasil yang benar bukan:

Perintah EMS = 100 kW → Output PCS = 100 kW

PCS harus beroperasi dalam batas yang diizinkan oleh baterai.

Secara konseptual:

BMS → “Apa yang diizinkan baterai untuk dilakukan”

EMS → “Apa yang diinginkan situs agar baterai lakukan”

PCS → “Apa yang sebenarnya dapat dieksekusi dalam konversi daya”

Pemisahan itu mendasar untuk kontrol BESS yang aman.

CAN dan Modbus Adalah Bahasa, Bukan Kesepakatan

Inilah di mana spesifikasi pengadaan sering kali menjadi terlalu optimis.

Pemasok A mengatakan:

Komunikasi BMS: CAN.

Pemasok B mengatakan:

PCS mendukung CAN.

Pembeli menulis:

Kompatibel.

Belum.

CAN menggambarkan mekanisme komunikasi. Perangkat masih memerlukan definisi pesan yang kompatibel.

Masalah yang sama muncul dengan Modbus.

Dua perangkat mungkin sama-sama mendukung Modbus RTU tetapi tidak sepakat tentang:

alamat register

tipe data

urutan byte

skala

izin baca/tulis

ID perangkat

tingkat pembaruan

kode alarm

Nilai register dari500tidak berarti sampai semua orang sepakat apakah itu berarti:

500 A

50.0 A

atau sesuatu yang sama sekali berbeda.

Itulah mengapa saya akan meminta protokol komunikasi atau peta register yang sebenarnya sebelum commissioning.

DawniceProdukTunjukkan Mengapa Antarmuka Bergantung pada Batas Sistem

Tidak semua produk baterai komersial mengekspos antarmuka yang sama.

Dawnice'sBS09-225-D 225.07 kWh sistem sisi DC, misalnya, menerbitkanantarmuka CAN/RS485dan mengidentifikasi CAN sebagai metode komunikasi BMS.

Sistem terintegrasinyaBS07-265-ES-X 125 kW/265.3 kWhsebaliknya menerbitkanModbus TCP/RTUdan kesiapan EMS/cloud.

Spesifikasi kontainer 1 MW/2.089 MWh milik Dawnice mencantumkan komunikasi EMS melaluiRS485 dan TCP/IP.

Perbedaan tersebut masuk akal.

Baterai sisi DC memerlukan antarmuka ke PCS eksternal.

Sistem all-in-one sudah mengandung lebih banyak hubungan baterai–PCS secara internal.

Sebuah pabrik terkontainer kemudian memerlukan komunikasi tingkat lebih tinggi dengan EMS, pemantauan, meteran, dan kemungkinan SCADA lokasi.

Arsitektur komunikasi mengikutibatas sistem.

Meter Juga Bagian dari Percakapan

Pengurangan puncak memberikan contoh yang baik.

Meter lokasi melaporkan:

Impor jaringan = 680 kW

Target EMS adalah:

600 kW

EMS menghitung kira-kira:

80 kW pelepasan yang diperlukan

dan mengirimkan perintah.

PCS melaksanakannya.

Meter kemudian melaporkan kondisi jaringan yang baru, memungkinkan EMS untuk menyesuaikan lagi.

Jadi, loop yang sebenarnya lebih dekat ke:

Meter Lokasi → EMS → PCS ↔ BMS → PCS → Meter Lokasi

Inilah sebabnya mengapa CT terbalik atau skala meter yang tidak benar dapat membuat baterai yang sehat berperilaku tidak benar.

EMS membuat keputusan rasional dari informasi yang buruk.

Arsitektur komunikasi BESS DOE juga mencakup meteran, EMS, PCS, BMS, kontrol lingkungan, HMI, sistem kebakaran, dan infrastruktur jaringan daripada memperlakukan komunikasi baterai sebagai satu kabel CAN.

Kegagalan Komunikasi Membutuhkan Status Aman yang Didefinisikan

Sekarang cabut jaringan EMS.

Apa yang seharusnya terjadi?

Jawaban itu termasuk dalam spesifikasi desain.

Tergantung pada aplikasi dan arsitektur yang disetujui, sistem mungkin:

melanjutkan perintah valid terakhir untuk periode tertentu

kembali ke kontrol PCS lokal

mengurangi daya

hentikan pengisian/pengosongan

naikkan alarm

atau masuk ke keadaan aman yang telah ditentukan lainnya.

Pertanyaan yang sama berlaku ketika:

komunikasi BMS–PCS gagal

data meter menghilang

koneksi cloud hilang

SCADA menjadi tidak tersedia

Kegagalan ini tidak setara.

Pemadaman cloud tidak seharusnya memiliki konsekuensi yang sama dengan kehilangan batas BMS yang diperlukan untuk operasi baterai yang aman.

Matriks kehilangan komunikasi harus mendefinisikan:

tautan hilang → waktu habis → tindakan cadangan → alarm → kondisi pemulihan

sebelum SAT.

Matriks Tanggung Jawab Lebih Penting daripada Daftar Protokol

Saya akan menempatkan tabel ini ke dalam perjanjian teknis:

Kolom terakhir mencegah percakapan commissioning yang mengejutkan umum:

Pemasok baterai:

“CAN kami berfungsi.”

Pemasok PCS:

“CAN kami berfungsi.”

Integrator:

“Lalu mengapa mereka tidak berkomunikasi?”

Perpustakaan dukungan teknis Dawnice berisi prosedur komunikasi khusus untuk kombinasi sepertiSolis 50 kW PCS dengan penyimpanan Dawnice 100/143 kWhdanMegarevo 500 kW PCS dengan penyimpanan C&I Dawnice 860 kWh, yang menggambarkan bahwa pasangan perangkat yang sebenarnya memerlukan konfigurasi dan pekerjaan integrasi di luar sekadar mencantumkan protokol di lembar data.

Apa yang Akan Saya Uji Sebelum Menganggap Antarmuka Sudah Lengkap

Saya tidak menganggap komunikasi telah dikomisioning karena setiap perangkat menunjukkan ikon hijau.

Selama FAT/SAT, saya ingin membuktikan:

nilai SoC dan suhu terukur dengan benar

batas pengisian/pengosongan BMS mencapai PCS

perintah daya EMS dieksekusi dengan benar

arah meter dan skala sudah benar

alarm menyebar ke HMI/SCADA yang dimaksud

stempel waktu sesuai

perilaku kehilangan komunikasi sesuai dengan spesifikasi

sistem pulih dengan benar setelah komunikasi kembali

Untuk proyek Ruibit/Dawnice, tanggung jawab tersebut harus dibekukan sebelum pengiriman kapan pun PCS eksternal, EMS, meter, atau sistem SCADA terlibat. Dawnice menyatakan bahwa C&I-nyaProdukmendukung antarmuka standar termasuk CAN, RS232, dan RS485 serta menyediakan layanan integrasi sistem dan commissioning untuk proyek C&I yang lebih besar.

Daftar protokol memberi tahu saya percakapan mana yang mungkin terjadi.

BESS yang sudah ditugaskan membuktikan bahwa perangkat memahami data yang sama, menghormati hierarki kontrol yang sama, gagal dengan aman ketika percakapan berhenti, dan tidak meninggalkan ambiguitas tentang siapa yang bertanggung jawab untuk membuat antarmuka berfungsi.

FAQ

1. Bagaimana BMS, PCS, dan EMS berkomunikasi dalam BESS komersial?

YangBMS menyediakan status baterai, SoC, alarm, dan batas operasi,EMS menentukan daya pengisian atau pengosongan yang diperlukan, danPCS mengeksekusi perintah konversi daya sambil menghormati batas baterai dan sistem.

2. Protokol komunikasi apa yang umum digunakan dalam BESS komersial?

Antarmuka umum termasukCAN, RS485, Modbus RTU/TCP, dan komunikasi berbasis Ethernet. Mendukung protokol yang sama tidak secara otomatis menjamin kompatibilitas antar perangkat.

3. Mengapa dua perangkat BESS dapat mendukung CAN atau Modbus tetapi tetap gagal berkomunikasi?

Mereka mungkin menggunakandefinisi pesan yang berbeda, alamat register, skala, urutan byte, ID perangkat, laju pembaruan, kode alarm, atau logika kontrol. Peta protokol/register yang sebenarnya harus diverifikasi.

4. Apa yang harus terjadi jika komunikasi BMS, PCS, atau EMS hilang?

Sistem harus memasuki keadaan yang telah ditentukan berdasarkan antarmuka yang gagal. Spesifikasi harus mendefinisikanwaktu tunggu, tindakan cadangan, perilaku alarm, dan kondisi pemulihanuntuk setiap kegagalan komunikasi.

5. Siapa yang bertanggung jawab atas integrasi BMS–PCS–EMS?

Tanggung jawab harus secara eksplisit ditugaskan dalam dokumen proyek. Pembeli harus mendefinisikan siapa yang memiliki setiap antarmuka antarabaterai, PCS, EMS, meter, SCADA, platform jarak jauh, dan jaringan situssebelum FAT dan commissioning.