BMS, PCS ve EMS Ticari Bir BESS'te Nasıl İletişim Kurar? Arayüzler, Protokoller ve Entegrasyon Sorumlulukları

Üç Cihaz Aynı Protokolü Destekleyebilir ve Yine de İletişim Kuramayabilir

Ticari bir BESS'te, BMS batarya durumunu ve işletim sınırlarını raporlar, PCS gücü dönüştürür ve şarj/deşarj komutlarını yerine getirir, EMS ise bu gücün ne zaman hareket etmesi gerektiğine site hedeflerine göre karar verir. İletişim genellikle CAN, RS485, Modbus RTU/TCP veya Ethernet tabanlı arayüzler kullanır. Ancak bir protokol adını paylaşmak uyumluluğu kanıtlamaz - cihazların ayrıca veri haritaları, ölçeklendirme, adresler, zamanlama, kontrol yetkisi, alarm mantığı ve güvenli davranış üzerinde de anlaşmaları gerekir.

DOE'nin BESS mimarisi bunları farklı kontrol katmanları olarak gösterir: BMS batarya modüllerine yakın oturur, PCS güç dönüşümünü kontrol ederken, EMS saha kontrol seviyesinde çalışır.

Bu hiyerarşi, bir komutu takip edersek daha kolay anlaşılır.

EMS 100 kW Diyor. PCS Basitçe Uymuyor.

Fabrika talebinin zirve sınırına yaklaştığını hayal edin.

EMS hesaplar:

Gerekli BESS deşarjı = 100 kW

PCS'ye doğru bir güç talebi gönderir.

Ancak 100 kW sağlamadan önce, kontrol zincirinin başka bir görüşü vardır.

BMS şu anda şunu rapor edebilir:

SoC: %24

Maksimum izin verilen deşarj: 62 kW

belki de SoC, hücre voltajı, sıcaklık, akım veya başka bir batarya kısıtlaması nedeniyle.

Doğru sonuç şu değildir:

EMS komutu = 100 kW → PCS çıkışı = 100 kW

PCS, bataryanın izin verilen sınırları içinde çalışmalıdır.

Kavram olarak:

BMS → “Bataryanın yapmasına izin verilenler”

EMS → “Sahanın bataryadan istediği”

PCS → “Gerçekten yerine getirilebilecek güç dönüşümü”

Bu ayrım, güvenli BESS kontrolü için temeldir.

CAN ve Modbus Dilleridir, Anlaşmalar Değil

İşte burada tedarik spesifikasyonları genellikle çok iyimser hale gelir.

Tedarikçi A der ki:

BMS iletişimi: CAN.

Tedarikçi B der ki:

PCS CAN'ı destekler.

Alıcı yazar:

Uyumlu.

Henüz değil.

CAN, bir iletişim mekanizmasını tanımlar. Cihazların hala uyumlu mesaj tanımlarına ihtiyacı var.

Aynı sorun Modbus ile de ortaya çıkıyor.

İki cihaz Modbus RTU'yu destekleyebilirken, aşağıdaki konularda anlaşmazlık yaşayabilir:

kayıt adresleri

veri türü

bayt sırası

ölçekleme

okuma/yazma izinleri

cihaz kimlikleri

güncelleme oranları

alarm kodları

Bir kayıt değeri500herkesin bunun ne anlama geldiği konusunda hemfikir olana kadar anlamsızdır:

500 A

50.0 A

ya da tamamen başka bir şey.

Bu yüzden, devreye almadan önce gerçek iletişim protokolünü veya kayıt haritasını talep ediyorum.

DawniceÜrünlerArayüzün Sistem Sınırına Bağlı Olduğunu Gösterin

Her ticari pil ürünü aynı arayüzü sunmaz.

Dawnice'inBS09-225-D 225.07 kWh DC tarafı sistemi, örneğin, yayınlarCAN/RS485arayüzleri ve CAN'ı BMS iletişim yöntemi olarak tanımlar.

EntegreBS07-265-ES-X 125 kW/265.3 kWhsistemi iseModbus TCP/RTUve EMS/cloud uyumluluğunu yayınlar.

Ve Dawnice'in 1 MW/2.089 MWh konteyner spesifikasyonu, EMS iletişiminiRS485 ve TCP/IP üzerinden listeliyor..

Bu farklılıklar mantıklı.

DC tarafındaki bir bataryanın dış bir PCS ile bir arayüze ihtiyacı var.

Hepsi bir arada sistem, zaten batarya–PCS ilişkisini dahili olarak daha fazla içeriyor.

Konteynerleştirilmiş bir tesis, o zaman EMS, izleme, sayaçlar ve potansiyel olarak yer SCADA ile daha yüksek seviyede iletişim gerektirir.

İletişim mimarisisistem sınırını.

Sayaç da Konuşmanın Bir Parçası

Zirve kesme, bize iyi bir örnek veriyor.

Yer sayaçı rapor ediyor:

Şebeke ithalatı = 680 kW

EMS hedefi:

600 kW

EMS yaklaşık olarak hesaplıyor:

80 kW deşarj gerekli

ve komutu gönderiyor.

PCS bunu gerçekleştiriyor.

Sayaç daha sonra yeni şebeke koşulunu rapor ediyor, bu da EMS'in tekrar ayarlama yapmasına olanak tanıyor.

Yani gerçek döngü daha çok şuna yakın:

Yer Sayaçı → EMS → PCS ↔ BMS → PCS → Yer Sayaçı

Bu yüzden ters CT veya yanlış sayaç ölçeklendirmesi, tamamen sağlıklı bir bataryanın yanlış davranmasına neden olabilir.

EMS, kötü bilgilerden mantıklı kararlar alıyor.

DOE'nin BESS iletişim mimarisi benzer şekilde sayaçlar, EMS, PCS, BMS, çevresel kontrol sistemleri, HMI, yangın sistemleri ve ağ altyapısını içeriyor ve batarya iletişimini tek bir CAN kablosu olarak ele almıyor.

İletişim Hatası Tanımlı Bir Güvenli Durum Gerektirir

Şimdi EMS ağını çıkarın.

Ne olmalı?

Bu cevap tasarım spesifikasyonuna aittir.

Uygulamaya ve onaylı mimariye bağlı olarak, sistem:

belirli bir süre için son geçerli komutu sürdürebilir

yerel PCS kontrolüne geri dönebilir

gücü azaltabilir

şarj/deşarjı durdur

bir alarm yükselt

veya başka bir önceden tanımlanmış güvenli duruma geç.

Aynı soru şu durumlarda geçerlidir:

BMS–PCS iletişimi başarısız olduğunda

ölçüm verileri kaybolduğunda

bulut bağlantısı kaybolduğunda

SCADA kullanılamaz hale geldiğinde

Bu arızalar eşdeğer değildir.

Bir bulut kesintisi, güvenli pil çalışması için gereken BMS sınırlarını kaybetmekle aynı sonucu doğurmak zorunda değildir.

Bu nedenle, iletişim kaybı matrisinin tanımlaması gerekir:

kayıp bağlantı → zaman aşımı → geri dönüş eylemi → alarm → iyileşme durumu

SAT'tan önce.

Sorumluluk Matrisi Protokol Listesinden Daha Önemlidir

Bu tabloyu teknik anlaşmaya eklemek isterim:

Son sütun, şaşırtıcı derecede yaygın bir devreye alma konuşmasını engeller:

Pil tedarikçisi:

“Bizim CAN çalışıyor.”

PCS tedarikçisi:

“Bizim CAN çalışıyor.”

Entegratör:

“O zaman neden iletişim kurmuyorlar?”

Dawnice'in teknik destek kütüphanesi, şu gibi kombinasyonlar için özel iletişim prosedürleri içerir:Dawnice 100/143 kWh depolama ile Solis 50 kW PCSkompakt hücre aralığıDawnice 860 kWh C&I depolama ile Megarevo 500 kW PCS, bu da gerçek cihaz eşleştirmenin, bir veri sayfasında bir protokol listelemekten daha fazla yapılandırma ve entegrasyon çalışması gerektirdiğini göstermektedir.

Arayüzü Tamamlanmış Olarak Çağırmadan Önce Ne Test Ederdim

Her cihaz yeşil bir simge gösterdiği için iletişimin devreye alındığını düşünmüyorum.

FAT/SAT sırasında kanıtlamak istiyorum:

SoC ve sıcaklık değerlerinin doğru ölçeklendiği

BMS şarj/deşarj sınırlarının PCS'ye ulaştığı

EMS güç komutlarının doğru bir şekilde uygulandığı

ölçüm yönü ve ölçeklendirme doğrudur

alarm sistemleri hedef HMI/SCADA'ya iletilir

zaman damgaları uyumludur

iletişim kaybı davranışı spesifikasyona uygundur

sistem iletişim geri döndüğünde doğru bir şekilde toparlanır

Bir Ruibit/Dawnice projesi için, bu sorumluluk, harici PCS, EMS, ölçüm cihazları veya SCADA sistemleri dahil olduğunda sevkiyattan önce dondurulmalıdır. Dawnice, C&IÜrünlerCAN, RS232 ve RS485 gibi standart arayüzleri destekler ve daha büyük C&I projeleri için sistem entegrasyonu ve devreye alma hizmetleri sunar.

Bir protokol listesi, hangi iletişimlerin mümkün olabileceğini bana söyler.

Devreye alınmış bir BESS, cihazların aynı verileri anladığını, aynı kontrol hiyerarşisine saygı gösterdiğini, iletişim durduğunda güvenli bir şekilde başarısız olduğunu ve arayüzlerin çalışmasından kimin sorumlu olduğu konusunda hiçbir belirsizlik bırakmadığını kanıtlar.

SSS

1. Ticari BESS'te BMS, PCS ve EMS nasıl iletişim kurar?

Sıvı SoğutmalıBMS, batarya durumu, SoC, alarmlar ve çalışma sınırları sağlar,EMS gerekli şarj veya deşarj gücünü belirler, vePCS, batarya ve sistem sınırlarına saygı göstererek güç dönüşüm komutlarını yerine getirir.

2. Ticari BESS'te yaygın olarak hangi iletişim protokolleri kullanılır?

Ortak arayüzler şunları içerirCAN, RS485, Modbus RTU/TCP ve Ethernet tabanlı iletişim. Aynı protokolü desteklemek, cihazlar arasında otomatik olarak uyumluluğu garanti etmez.

3. Neden iki BESS cihazı CAN veya Modbus'ı destekleyebilir ama yine de iletişim kuramaz?

Farklımesaj tanımları, kayıt adresleri, ölçeklendirme, bayt sırası, cihaz kimlikleri, güncelleme oranları, alarm kodları veya kontrol mantığı kullanabilirler. Gerçek protokol/kayıt haritası bu nedenle doğrulanmalıdır.

4. BMS, PCS veya EMS iletişimi kaybolursa ne olmalıdır?

Sistem, başarısız arayüze dayalı olarak önceden tanımlanmış bir duruma girmelidir. Spesifikasyon,zaman aşımı, geri dönüş eylemi, alarm davranışı ve kurtarma koşullarınıher iletişim hatası için tanımlamalıdır.

5. BMS–PCS–EMS entegrasyonundan kim sorumludur?

Sorumluluk proje belgelerinde açıkça atanmalıdır. Alıcılar,batarya, PCS, EMS, ölçüm cihazı, SCADA, uzaktan platform ve saha ağı arasındaki her arayüzün kimin sahibi olduğunu tanımlamalıdırFAT ve devreye almadan önce.