Pil Sağlıklıydı. Mesaj Geçemiyordu.
Ticari BESS'teki bir BMS iletişim hatası genellikle BMS'i değiştirmek için yeterli kanıt değildir. Hangi iletişim yolunun başarısız olduğunu tam olarak belirleyerek başlayın, ardından güç ve çalışma durumunu, fiziksel kablolamayı, arayüz türünü, sonlandırmayı, düğüm/adres ayarlarını, protokol seçimlerini, yazılım uyumluluğunu ve gerçek mesaj trafiğini doğrulayın. Bir iletişim alarmı ve bir pil arızası iki farklı tanı problemi.
Teknisyenlerin saatler kaybettiğini gördüm çünkü HMI gösterdiBMS İletişim Hatasıve herkes hemen pil rafını tartışmaya başladı.
İlk sorum daha basit:
Kim kiminle konuşmayı kesti?
Bir C&I BESS'te, "BMS iletişimi" raf BMS'inin ana BMS ile, BMS'in PCS ile, BMS'in EMS ile veya enerji depolama sisteminin SCADA/bulut izleme ile olan yolu tanımlayabilir. Dawnice'in mevcut C&IÜrünlerçeşitliliği gösteriyor: BS09-225-D'si yayınlıyorCAN/RS485iletişim, BS07-265-ES-X ise listeliyorModbus TCP/RTUve EMS/cloud uyumluluğunu yayınlar.Dawnice BS09-225-D Dawnice BS07-265-ES-X
Aynı geniş semptom.
Potansiyel olarak çok farklı bir arıza.
08:17 — PCS "BMS Yok" Dedi
Bir PCS'e bağlı varsayımsal 400 kWh ticari pili düşünün.
Sistem Cuma günü doğru bir şekilde devreye alındı.
Pazartesi sabahı:
Pil HMI:normal
Raf voltajları:mevcut
Hücre sıcaklıkları:makul
PCS:BMS iletişimi kayboldu
EMS:pil kullanılamıyor
Kontak:açık
Demek istemenin cazibesi:
"BMS başarısız oldu."
Ben bunu yapmam.
Eğer yerel batarya HMI hücreleri ve sıcaklıkları doğru bir şekilde okumaya devam ediyorsa, BMS açıkça işinin en azından bir kısmını yapıyor demektir. Başarısız sınır BMS ile PCS arasında olabilir.
Bu, soruşturmayı hemen değiştirir.
Hiçbir şeye dokunmadan önce alarm zaman damgasını kaydederim, ardından bunu BMS, PCS ve EMS olay günlükleriyle karşılaştırırım.
Eğer üç saat altı dakika farklıysa, o sorunu da çözerim. Olay kronolojisi güvenilir olmadığında kök neden analizi şaşırtıcı derecede çirkinleşir.
Bir Dizüstü Bilgisayar Açmadan Önce Sıkıcı Şeyleri Kontrol Ediyorum
Bir yedek iletişim kablosu, zarif bir protokol analizinden daha fazla arızayı çözmüştür.
Yazılımı değiştirmeden önce şunu bilmek istiyorum:
BMS enerji alıyor ve tamamen uyanık mı?
Doğru iletişim portu mu kullanılıyor?
Bağlantı elemanı tam oturmuş mu?
Kablo pin çıkışı doğrulandı mı, RJ45 konektöründen varsayılmadı mı?
CAN-H/CAN-L veya RS485 A/B doğru şekilde mi bağlandı?
Kalkanlama/topraklama onaylı tasarımla tutarlı mı?
Kablo hasar görmüş, ezilmiş, uzatılmış veya gürültülü güç iletkenlerinin yanına yönlendirilmiş mi?
RJ45 psikolojik olarak özellikle tehlikelidir. İki cihaz aynı konektörleri kullanabilir ve tamamen farklı pin atamaları olabilir.
Örneğin, Dawnice'in kendi batarya kılavuzu, herhangi bir sıradan ağ kablosunun değiştirilebilir olduğunu ima etmek yerine CAN ve RS485 iletişim pinlerini ayrı ayrı tanımlar.Dawnice Batarya Kılavuzu
Bir konektör şekli bir protokol değildir.
Bu, hatta bir kablolama tanımı bile değildir.
Birden Fazla Raf Kaybolursa, Bireysel Rafları Suçlamayı Bırakıyorum
Arıza modeli bana nerede bakmam gerektiğini söyler.
| Belirti | Araştıracağım İlk Alan |
|---|---|
| Bir raf kayboluyor | Raf gücü, kablo, adres, yerel BMS |
| Tüm raflar kayboluyor | Ana BMS, ortak veri yolu, güç kaynağı |
| BMS HMI çalışıyor ama PCS bataryayı kaybediyor | BMS–PCS bağlantısı / protokolü |
| PCS bataryayı görüyor ama EMS görmüyor | PCS/EMS ağı veya kayıt haritalaması |
| İletişim aralıklı olarak kesiliyor | Sonlandırma, gürültü, konektör, topoloji |
| Arıza, yazılım güncellemesini takip ediyor | Protokol/yazılım/konfigürasyon |
| Yanlış değerler ama bağlantı çevrimiçi kalıyor | Kayıt haritası, ölçekleme, bayt sırası, eşleme |
O tablo sistem kılavuzunun yerini tutmaz.
Bu, bir paylaşılan iletişim bağlantısı başarısız olduğu için dört sağlıklı batarya modülünü değiştirmekten kaçınmanın bir yoludur.
CAN ve RS485 Farklı Şekilde Hata Verir
"İletişim kablosu" kategorisini tek bir grup olarak ele almıyorum.
Bir CAN ağında topolojiyi, CAN-H/CAN-L polaritesini, bit hızını, düğüm yapılandırmasını, sonlandırmayı ve beklenen çerçevelerin gerçekten mevcut olup olmadığını doğrulamak istiyorum.
Bir RS485/Modbus RTU ağında, A/B polaritesi, köle adresleri, baud hızı, parite, dur bitleri, kayıt eşlemesi ve sonlandırma hakkında düşünmeye başlarım.
Sıvı SoğutmalıModbus Organizasyonumevcut protokol ve seri hat uygulama spesifikasyonlarını sürdürmektedir. Seri hat rehberi, sonlandırma ve polarizasyonu ağ tasarımının özellikleri olarak ele alır, iletişim güvenilmez hale geldiğinde eklenmesi gereken keyfi dirençler olarak değil.
Bu, tanıdık olanla ilgili dikkatli olmaya başladığım yer:
"60 ohm ölç ve işin bitti."
İki 120 ohmluk sonlandırma paralel bağlandığında, güç verilmemiş bir veri yolunda yaklaşık 60 ohm üretebilir, ancak bu okuma yalnızca bu şekilde tasarlanmış bir topoloji için anlamlıdır ve uygun koşullar altında ölçülmelidir.
Bu, adreslerin, baud hızının, protokolün veya veri eşlemenin doğru olduğunu kanıtlamaz.
Bir faydalı sayı. Bir teşhis değil.
Yeşil Bir İletişim LED'i Hala Size Yalan Söyleyebilir
Fiziksel bağlantının sağlıklı göründüğünü varsayalım.
Çerçeveler hareket ediyor.
PCS hâlâ çalışmayı reddediyor.
Şimdi yığın boyunca yukarı doğru ilerliyorum.
Bir BMS ve PCS, elektriksel sinyalizasyonun ötesinde anlaşmalıdır. Mimariliğe bağlı olarak, aşağıdaki konularda uyumlu tanımlara ihtiyaç duyabilirler:
SoC
SoH
paket voltajı/akımı
maksimum şarj akımı
maksimum deşarj akımı
şarj/deşarj etkinleştirme
alarm durumları
kontak durumu
sıcaklık sınırları
kalp atışı/gözlemci
Bir CAN veri yolu elektriksel olarak mükemmel olabilirken, PCS farklı bir mesaj setini dinliyor olabilir.
Benzer şekilde, bir Modbus ana cihazı yanlış kayıtları okurken bir köle ile başarılı bir şekilde iletişim kurabilir.
Bu nedenle "CAN destekler" veya "Modbus destekler" bir uyumluluk ifadesi değildir.
Bu, bana dil ailesini söyler.
İki cihazın aynı konuşmayı anlayıp anlamadığını değil.
Protokol Seçimi Gerçek Bir Hata, Bir Kurulum Detayı Değil
Bu, donanımı değiştirmeden önce yapılandırmayı kontrol etmeyi sevmemin bir nedenidir.
Örneğin, bir Dawnice inverter kılavuzu,BMS iletişim hatası [58]ve teknisyenin hem iletişim kablosunu kontrol etmesini hem de yapılandırılan lityum-batarya iletişim protokolünün bataryaya uygun olup olmadığını kontrol etmesini yönlendirir.Dawnice İnverter Kılavuzu
Bu sorun giderme mantığı bir ürünün ötesine ölçeklenir.
Varsayalım ki bir commissioning mühendisi şunu seçiyor:
Pil Protokolü 03
şunun yerine:
Pil Protokolü 08
Kablo mükemmel.
BMS sağlıklı.
PCS sağlıklı.
Sistem hâlâ çalışmıyor.
Hiçbir şey "bozuk" değil.
Konfigürasyon yanlış.
Ruibit/Dawnice ticari projeleri için, onaylı BMS–PCS iletişim kombinasyonunu elektrik BOM'u ile birlikte dondururdum: tam pil/BMS versiyonu, PCS modeli, protokol, arayüz, parametre seti ve yazılım versiyonları.
Yazılımı değiştirmek, tornavida kabine dokunmadan bile bir bileşen değişikliği olabilir.
Ara sıra iletişim, daha ciddi aldığım bir hatadır
Tamamen ölü bir bağlantı genellikle daha kolaydır.
Kesintili bir bağlantı FAT'ı geçebilir, devreye alma sürecini atlatabilir ve ardından saha sıcak, yoğun yük altında veya elektriksel gürültülü olduğunda arızalanabilir.
PCS'in %80 güç aştığında iletişim kopmalarının göründüğünü hayal edin.
O zamanlama önemlidir.
Rastgele yazılımları suçlamadan önce yönlendirme ve elektromanyetik parazitleri araştırırdım.
Sorun her 20 saniyede bir güçten bağımsız olarak görünüyorsa, kalp atışı/gözetleme zamanlamasına bakabilirim.
Eğer beşinci raf eklendikten sonra görünüyorsa, topolojiyi, adreslemeyi ve sonlandırmayı gözden geçirirdim.
Eğer yazılım revizyonu 3.12'den hemen sonra başlıyorsa, kimse başka bir güncelleme yapmadan önce önceki versiyon numarasını isterim.
Hatanın görünmesini sağlayan durum kanıttır.
Her şeyi yeniden başlatarak silmeyin.
Tanı siparişim, pahalı tahminleri önlemek için tasarlanmıştır
Genellikle dışarıdan içeriye doğru çalışırım:
1. Başarısız iletişim sınırını tanımlayın
BMS–raf mı? BMS–PCS mi? PCS–EMS mi? EMS–SCADA mı?
2. Kanıtları koruyun
Alarm kodları, zaman damgaları, ekran görüntüleri, yazılım versiyonları ve son değişiklikler.
3. Çalışma durumunu doğrulayın
Güç kaynakları, BMS durumu, kontaktörler, yerel alarmlar.
4. Fiziksel katmanı doğrulayın
Kablo, pin düzeni, polarite, konektörler, topoloji, sonlandırma, koruma.
5. İletişim ayarlarını doğrulayın
Arayüz, düğüm kimliği, baud hızı, bit hızı, parite ve protokol seçimi.
6. Veri katmanını doğrulayın
Kareler, kayıt haritası, ölçekleme, kalp atışı ve komut/durum değişimi.
7. Değişiklik geçmişini gözden geçirin
Yazılım, yedek bileşenler, parametre değişiklikleri ve ağ modifikasyonları.
Protokol analizi gevşek bir konektörü onaramayacağı için doğrudan 6. Adıma geçmiyorum.
Devamlılık, uyumluluğu kanıtlamadığı için 4. Adımda durmuyorum.
Sistem davranışı düzeldiğinde hata düzelir
İletişim alarmının kaybolmasını sağlamak benim kabul kriterim değil.
Onarımdan sonra, PCS'nin makul pil verilerini aldığını ve BMS sınırlarına saygı gösterdiğini doğrulamak istiyorum.
Eğer BMS, pil sıcaklığı yükseldiği için izin verilen şarj akımını azaltıyorsa, PCS bunu takip ediyor mu?
Eğer deşarj izni kaldırılırsa, güç gerçekten duruyor mu?
SoC, EMS'ye doğru bir şekilde ulaşıyor mu?
Alarmlar uzaktan görünüyor mu?
Kontrollü bir yeniden başlatmadan sonra iletişim doğru bir şekilde geri geliyor mu?
Zaman damgaları hizalanmış mı?
Dawnice şu anda C&I sistemlerinin CAN, RS485 ve ilgili izleme platformları dahil olmak üzere uzaktan izleme ve tanılama desteği sunduğunu belirtmektedir ve C&I pil/PCS kombinasyonları için belirli iletişim-bağlantı kılavuzları yayınlamaktadır.Dawnice SSS Dawnice Teknik Destek
Bir B2B alıcısı için, son nokta göründüğünden daha önemlidir.
Sadece bir pil ve bir PCS satın almayın.
Birdoğrulanmış iletişim ilişkisiaralarında, sürümler, ayarlar ve destek sorumluluğu kaydedilmiş olarak satın alın.
Çünkü bir BESS "BMS iletişim hatası" dediğinde, pahalı hata, alarmda adı geçen ilk bileşenin arızalanan bileşen olduğunu varsaymaktır.
Önce bozuk iletişimi bulun. İkinci olarak donanımı değiştirin.
SSS
1. BMS'im PCS ile neden iletişim kurmuyor?
Yaygın nedenler arasındayanlış kablolama veya pin düzeni, CAN/RS485 polaritesi, yanlış protokol seçimi, adres ayarları, sonlandırma, yazılım uyumsuzluğu, hasarlı kablolar veya iletişim-portu yapılandırması bulunmaktadır..
2. BMS iletişim alarmı, BMS'in arızalandığı anlamına mı geliyor?
Hayır. BMS, hücreleri doğru bir şekilde izlemeye devam edebilirken, BMS ile PCS, EMS, ana BMS veya SCADA arasındaki iletişim başarısız olabilir. Donanımı değiştirmeden önce başarısız iletişim sınırını belirleyin.
3. İki cihaz CAN veya RS485'i destekleyebilir mi ve yine de uyumsuz olabilir mi?
Evet. Aynı fiziksel arayüzü paylaşmak uyumluluğu garanti etmez. Cihazların ayrıcaprotokol, bit hızı veya baud hızı, mesaj/kayıt tanımları, adresleme, veri ölçeklendirme ve kontrol mantığı.
4. BMS iletişimi neden ara sıra başarısız oluyor?
Ara sıra meydana gelen arızalar, gevşek bağlantılardan, kötü sonlandırmadan, elektrik gürültüsünden, kablo yönlendirmesinden, dengesiz güç kaynaklarından, ağ topolojisinden, izleme zamanlamasından veya yazılım sorunlarından kaynaklanabilir. Sistemi yeniden başlatmadan önce arızanın ne zaman meydana geldiğini kaydedin.
5. BMS iletişim hatası düzeltildikten sonra ne doğrulanmalıdır?
PCS'nin doğru aldığını doğrulayınSoC, voltaj, akım, sıcaklık, alarmlar ve şarj/boşaltma limitleri, BMS koruma komutlarına uyar, EMS'ye doğru rapor verir ve kontrollü bir yeniden başlatmadan sonra iletişimi geri kazanır.
