बैटरी स्वस्थ थी। संदेश नहीं पहुँच रहा था।
एक व्यावसायिक BESS में BMS संचार विफलता आमतौर पर BMS को बदलने के लिए पर्याप्त सबूत नहीं होती है। सबसे पहले यह पहचानें कि कौन सा संचार पथ विफल हुआ है, फिर शक्ति और संचालन की स्थिति, भौतिक वायरिंग, इंटरफ़ेस प्रकार, समाप्ति, नोड/पता सेटिंग्स, प्रोटोकॉल चयन, फर्मवेयर संगतता, और वास्तविक संदेश ट्रैफ़िक की पुष्टि करें। एक संचार अलार्म और एक बैटरी दोष दो अलग-अलग निदान समस्याएँ हैं।
मैंने देखा है कि तकनीशियन घंटे बर्बाद कर देते हैं क्योंकि HMI ने दिखायाBMS संचार दोषऔर सभी ने तुरंत बैटरी रैक पर चर्चा करना शुरू कर दिया।
मेरा पहला सवाल सरल है:
किसने किससे बात करना बंद कर दिया?
एक C&I BESS में, "BMS संचार" रैक BMS से मास्टर BMS, BMS से PCS, BMS से EMS, या ऊर्जा-भंडारण प्रणाली से SCADA/क्लाउड मॉनिटरिंग तक के पथ का वर्णन कर सकता है। डॉनिस का वर्तमान C&Iउत्पादविविधता को दर्शाता है: इसका BS09-225-D प्रकाशित करता हैCAN/RS485संचार, जबकि BS07-265-ES-X सूचीबद्ध करता हैमोदबस TCP/RTUऔर EMS/क्लाउड तत्परता।डॉनिस BS09-225-D डॉनिस BS07-265-ES-X
समान व्यापक लक्षण।
संभावित रूप से बहुत अलग दोष।
08:17 — PCS ने कहा "कोई BMS नहीं"
एक काल्पनिक 400 kWh व्यावसायिक बैटरी पर विचार करें जो PCS से जुड़ी हुई है।
सिस्टम ने शुक्रवार को सही ढंग से कमीशन किया।
सोमवार की सुबह:
बैटरी HMI:सामान्य
रैक वोल्टेज:उपस्थित
सेल तापमान:संभाव्य
PCS:BMS संचार खो गया
ईएमएस:बैटरी उपलब्ध नहीं है
कॉन्टैक्टर:खुला
कहने की प्रलोभन है:
"बीएमएस विफल हो गया है।"
मैं ऐसा नहीं कहूंगा।
यदि स्थानीय बैटरी एचएमआई अभी भी सेल और तापमान को सही ढंग से पढ़ रहा है, तो बीएमएस स्पष्ट रूप से अपने काम का कम से कम एक हिस्सा कर रहा है। विफल सीमा बीएमएस और पीसीएस के बीच हो सकती है।
यह तुरंत जांच को बदल देता है।
मैं कुछ भी छूने से पहले अलार्म टाइमस्टैम्प रिकॉर्ड करूंगा, फिर इसे बीएमएस, पीसीएस और ईएमएस इवेंट लॉग के साथ तुलना करूंगा।
यदि तीनों घड़ियाँ छह मिनट में असहमत हैं, तो मैं उस समस्या को भी ठीक करूंगा। जब इवेंट क्रोनोलॉजी अप्रत्याशित होती है, तो मूल कारण विश्लेषण आश्चर्यजनक रूप से भद्दा हो जाता है।
मैं लैपटॉप खोलने से पहले बोरिंग चीजें चेक करता हूँ
एक प्रतिस्थापन संचार केबल ने अधिक दोषों को हल किया है जितना कि एक सुरुचिपूर्ण प्रोटोकॉल विश्लेषण कभी करेगा।
सॉफ़्टवेयर बदलने से पहले, मैं जानना चाहता हूँ:
क्या बीएमएस पावर में है और पूरी तरह से जागृत है?
क्या सही संचार पोर्ट का उपयोग किया जा रहा है?
क्या कनेक्टर पूरी तरह से बैठा है?
क्या केबल पिनआउट की पुष्टि की गई थी, आरजे45 कनेक्टर से अनुमानित नहीं?
क्या CAN-H/CAN-L या RS485 A/B सही तरीके से जुड़े हुए हैं?
क्या शील्डिंग/ग्राउंडिंग स्वीकृत डिज़ाइन के अनुरूप है?
क्या केबल को नुकसान हुआ है, कुचला गया है, बढ़ाया गया है, या शोर वाले पावर कंडक्टरों के बगल में पुनः मार्गित किया गया है?
आरजे45 मनोवैज्ञानिक रूप से विशेष रूप से खतरनाक है। दो उपकरण समान कनेक्टर्स का उपयोग कर सकते हैं और पूरी तरह से अलग पिन असाइनमेंट हो सकते हैं।
उदाहरण के लिए, डॉनिस का अपना बैटरी मैनुअल, CAN और RS485 संचार पिनों को अलग से परिभाषित करता है न कि यह सुझाव देता है कि कोई सामान्य नेटवर्क केबल इंटरचेंजेबल है।डॉनिस बैटरी मैनुअल
एक कनेक्टर आकार प्रोटोकॉल नहीं है।
यह तो एक वायरिंग परिभाषा भी नहीं है।
यदि कई रैक एक साथ गायब हो जाते हैं, तो मैं व्यक्तिगत रैक को दोष देना बंद कर देता हूँ
विफलता पैटर्न मुझे बताता है कि कहाँ देखना है।
| लक्षण | पहला क्षेत्र जिसे मैं जांचूंगा |
|---|---|
| एक रैक गायब हो जाता है | रैक पावर, केबल, पता, स्थानीय BMS |
| सभी रैक गायब हो जाते हैं | मास्टर BMS, सामान्य बस, पावर सप्लाई |
| BMS HMI काम करता है लेकिन PCS बैटरी खो देता है | BMS–PCS लिंक / प्रोटोकॉल |
| PCS बैटरी देखता है लेकिन EMS नहीं देखता | PCS/EMS नेटवर्क या रजिस्टर मैपिंग |
| संचार कभी-कभी विफल होता है | समापन, शोर, कनेक्टर, टोपोलॉजी |
| विफलता फर्मवेयर अपडेट के बाद होती है | प्रोटोकॉल/फर्मवेयर/कॉन्फ़िगरेशन |
| गलत मान लेकिन लिंक ऑनलाइन रहता है | रजिस्टर मैप, स्केलिंग, बाइट क्रम, मैपिंग |
यह तालिका प्रणाली मैनुअल का विकल्प नहीं है।
यह चार स्वस्थ बैटरी मॉड्यूल को बदलने से बचने का एक तरीका है क्योंकि एक साझा संचार लिंक विफल हो गया।
CAN और RS485 अलग-अलग विफल होते हैं
मैं "संचार केबल" को एक श्रेणी के रूप में नहीं मानता।
CAN नेटवर्क पर मैं टोपोलॉजी, CAN-H/CAN-L ध्रुवता, बिटरेट, नोड कॉन्फ़िगरेशन, टर्मिनेशन और यह सत्यापित करना चाहता हूँ कि अपेक्षित फ़्रेम वास्तव में मौजूद हैं।
RS485/Modbus RTU नेटवर्क पर, मैं A/B ध्रुवता, दास पते, बौड दर, पैरीटी, स्टॉप बिट्स, रजिस्टर मैपिंग और टर्मिनेशन के बारे में सोचने लगता हूँ।
यहModbus संगठनवर्तमान प्रोटोकॉल और सीरियल-लाइन कार्यान्वयन विनिर्देशों को बनाए रखता है। इसका सीरियल-लाइन मार्गदर्शन टर्मिनेशन और ध्रुवीकरण को नेटवर्क डिज़ाइन के गुणों के रूप में मानता है, न कि संचार अस्थिर होने पर जोड़ने के लिए मनमाने प्रतिरोधकों के रूप में।
यही वह जगह है जहाँ मैं परिचित के बारे में सतर्क हो जाता हूँ:
"60 ओम मापें और आप तैयार हैं।"
दो 120-ओम टर्मिनेशन समानांतर में एक अनपावर्ड बस पर लगभग 60 ओम उत्पन्न कर सकते हैं, लेकिन वह रीडिंग केवल उस प्रकार की टोपोलॉजी के लिए अर्थपूर्ण है और उचित परिस्थितियों में मापी गई है।
यह साबित नहीं करता कि पते, बौड दर, प्रोटोकॉल या डेटा मैपिंग सही हैं।
एक उपयोगी संख्या। एक निदान नहीं।
एक हरा संचार LED अभी भी आपको झूठा बता सकता है
मान लीजिए कि भौतिक लिंक स्वस्थ दिखता है।
फ्रेम चल रहे हैं।
PCS अभी भी काम करने से इनकार कर रहा है।
अब मैं स्टैक के माध्यम से ऊपर की ओर बढ़ता हूँ।
BMS और PCS को विद्युत संकेतों से अधिक पर सहमत होना चाहिए। आर्किटेक्चर के आधार पर, उन्हें निम्नलिखित के लिए संगत परिभाषाओं की आवश्यकता हो सकती है:
SoC
SoH
पैक वोल्टेज/करंट
अधिकतम चार्ज करंट
अधिकतम डिस्चार्ज करंट
चार्ज/डिस्चार्ज सक्षम
अलार्म स्थितियाँ
कॉन्टैक्टर स्थिति
तापमान सीमाएँ
हार्टबीट/वॉचडॉग
एक CAN बस विद्युत रूप से सही हो सकती है जबकि PCS एक अलग संदेश सेट के लिए सुन रहा है।
इसी तरह, एक Modbus मास्टर गलत रजिस्टर पढ़ते हुए एक दास के साथ सफलतापूर्वक संवाद कर सकता है।
यही कारण है कि "CAN का समर्थन करता है" या "Modbus का समर्थन करता है" एक संगतता कथन नहीं है।
यह मुझे भाषा परिवार बताता है।
नहीं कि दोनों उपकरण एक ही बातचीत को समझते हैं।
प्रोटोकॉल चयन एक वास्तविक दोष है, सेटअप विवरण नहीं
यह एक कारण है कि मुझे हार्डवेयर बदलने से पहले कॉन्फ़िगरेशन की जांच करना पसंद है।
एक Dawnice इन्वर्टर मैनुअल, उदाहरण के लिए, पहचानता हैBMS संचार दोष [58]और तकनीशियन को संचार केबल और यह जांचने के लिए निर्देशित करता है कि क्या कॉन्फ़िगर की गई लिथियम-बैटरी संचार प्रोटोकॉल बैटरी के अनुरूप है।डॉनिस इनवर्टर मैनुअल
यह समस्या निवारण तर्क एक उत्पाद से परे बढ़ता है।
मान लीजिए कि एक कमीशनिंग इंजीनियर चयन करता है:
बैटरी प्रोटोकॉल 03
इसके बजाय:
बैटरी प्रोटोकॉल 08
केबल सही है।
BMS स्वस्थ है।
PCS स्वस्थ है।
सिस्टम फिर भी काम नहीं करता।
कुछ भी "टुटा" नहीं है।
कॉन्फ़िगरेशन गलत है।
रुइबिट/डॉनिस व्यावसायिक परियोजनाओं के लिए, मैं इसलिए स्वीकृत BMS–PCS संचार संयोजन को इलेक्ट्रिकल BOM के साथ स्थिर कर दूंगा: सटीक बैटरी/BMS संस्करण, PCS मॉडल, प्रोटोकॉल, इंटरफेस, पैरामीटर सेट और फर्मवेयर संस्करण।
फर्मवेयर बदलना एक घटक परिवर्तन हो सकता है, भले ही कोई स्क्रूड्राइवर कैबिनेट को छूता न हो।
अवधि-समय संचार वह दोष है जिसे मैं अधिक गंभीरता से लेता हूँ
एक पूरी तरह से मृत लिंक अक्सर आसान होता है।
एक अंतराल लिंक FAT पास कर सकता है, कमीशनिंग को सहन कर सकता है और फिर जब साइट गर्म, भारी लोडेड या विद्युत शोर में हो, तब विफल हो सकता है।
कल्पना करें कि संचार ड्रॉप केवल तब दिखाई देते हैं जब PCS 80% शक्ति से अधिक हो।
वह समय महत्वपूर्ण है।
मैं यादृच्छिक सॉफ़्टवेयर को दोष देने से पहले रूटिंग और विद्युत चुम्बकीय हस्तक्षेप की जांच करूंगा।
यदि समस्या हर 20 सेकंड में शक्ति के बावजूद प्रकट होती है, तो मैं हार्टबीट/वॉचडॉग समय पर देख सकता हूं।
यदि यह पांचवें रैक को जोड़ने के बाद प्रकट होता है, तो मैं टोपोलॉजी, पते और समाप्ति की समीक्षा करूंगा।
यदि यह फर्मवेयर संशोधन 3.12 के तुरंत बाद शुरू होता है, तो मैं चाहता हूं कि कोई भी अन्य अपडेट करने से पहले पिछले संस्करण संख्या हो।
जो स्थिति दोष को प्रकट करती है वह सबूत है।
पहले सब कुछ रीबूट करके इसे न मिटाएं।
मेरा निदान आदेश महंगे अनुमान को रोकने के लिए डिज़ाइन किया गया है
मैं सामान्यतः बाहर से अंदर की ओर काम करता हूं:
1. असफल संचार सीमा को परिभाषित करें
BMS–रैक? BMS–PCS? PCS–EMS? EMS–SCADA?
2. सबूत को संरक्षित करें
अलार्म कोड, टाइमस्टैम्प, स्क्रीनशॉट, फर्मवेयर संस्करण और हाल के परिवर्तन।
3. संचालन की स्थिति की पुष्टि करें
पावर सप्लाई, BMS स्थिति, संपर्ककर्ता, स्थानीय अलार्म।
4. भौतिक परत की पुष्टि करें
केबल, पिनआउट, ध्रुवता, कनेक्टर्स, टोपोलॉजी, समाप्ति, शील्डिंग।
5. संचार सेटिंग्स की पुष्टि करें
इंटरफेस, नोड आईडी, बौड दर, बिटरेट, पैरिटी और प्रोटोकॉल चयन।
6. डेटा परत की पुष्टि करें
फ्रेम, रजिस्टर मैप, स्केलिंग, हार्टबीट और कमांड/स्थिति विनिमय।
7. परिवर्तन इतिहास की समीक्षा करें
फर्मवेयर, प्रतिस्थापन घटक, पैरामीटर परिवर्तन और नेटवर्क संशोधन।
मैं सीधे चरण 6 पर नहीं जाता क्योंकि प्रोटोकॉल विश्लेषण एक ढीले कनेक्टर को ठीक नहीं कर सकता।
मैं चरण 4 पर नहीं रुकता क्योंकि निरंतरता संगतता को साबित नहीं करती।
जब सिस्टम व्यवहार ठीक होता है, तो दोष ठीक होता है
संचार अलार्म को गायब करना मेरा स्वीकृति मानदंड नहीं है।
मरम्मत के बाद, मैं यह पुष्टि करना चाहता हूं कि PCS संभावित बैटरी डेटा प्राप्त करता है और BMS सीमाओं का सम्मान करता है।
यदि BMS अनुमति योग्य चार्ज करंट को कम करता है क्योंकि बैटरी का तापमान बढ़ता है, तो क्या PCS इसका पालन करता है?
यदि डिस्चार्ज अनुमति हटा दी जाती है, तो क्या पावर वास्तव में रुकता है?
क्या SoC सही तरीके से EMS तक पहुंचता है?
क्या अलार्म दूर से दिखाई देते हैं?
क्या नियंत्रित पुनरारंभ के बाद संचार सही तरीके से पुनर्प्राप्त होता है?
क्या टाइमस्टैम्प संरेखित हैं?
Dawnice वर्तमान में बताता है कि इसके C&I सिस्टम दूरस्थ निगरानी और इंटरफेस के माध्यम से निदान का समर्थन करते हैं, जिसमें CAN, RS485 और संबंधित निगरानी प्लेटफार्म शामिल हैं, और यह C&I बैटरी/PCS संयोजनों के लिए विशिष्ट संचार-कनेक्शन ट्यूटोरियल प्रकाशित करता है।Dawnice FAQ Dawnice तकनीकी सहायता
एक B2B खरीदार के लिए, वह अंतिम बिंदु उतना महत्वपूर्ण है जितना यह लगता है।
केवल एक बैटरी और एक PCS न खरीदें।
एक खरीदेंसत्यापित संचार संबंधउनके बीच, संस्करणों, सेटिंग्स और समर्थन जिम्मेदारी के साथ रिकॉर्ड किया गया।
क्योंकि जब एक BESS कहता है "BMS संचार विफलता," तो महंगी गलती यह मान लेना है कि अलार्म में नामित पहला घटक वह घटक है जो विफल हुआ।
पहले टूटी हुई बातचीत खोजें। दूसरे हार्डवेयर को बदलें।
अक्सर पूछे जाने वाले प्रश्न
1. मेरी BMS PCS के साथ संचार क्यों नहीं कर रही है?
सामान्य कारणों में शामिल हैंगलत वायरिंग या पिनआउट, CAN/RS485 ध्रुवता, गलत प्रोटोकॉल चयन, पता सेटिंग्स, समाप्ति, फर्मवेयर असंगति, क्षतिग्रस्त केबल, या संचार-पोर्ट कॉन्फ़िगरेशन.
2. क्या BMS संचार अलार्म का मतलब है कि BMS विफल हो गया है?
नहीं। BMS अभी भी कोशिकाओं की निगरानी कर सकता है जबकि BMS और PCS, EMS, मास्टर BMS, या SCADA के बीच संचार विफल हो जाता है। हार्डवेयर बदलने से पहले विफल संचार सीमा की पहचान करें।
3. क्या दो उपकरण CAN या RS485 का समर्थन कर सकते हैं और फिर भी असंगत हो सकते हैं?
हाँ। एक ही भौतिक इंटरफेस साझा करना संगतता की गारंटी नहीं देता। उपकरणों को भी इस पर सहमत होना चाहिएप्रोटोकॉल, बिटरेट या बौड दर, संदेश/रजिस्टर परिभाषाएँ, पता लगाने, डेटा स्केलिंग, और नियंत्रण तर्क.
4. BMS संचार क्यों अव्यवस्थित रूप से विफल होता है?
अवधि-समय दोष ढीले कनेक्टर्स, खराब समाप्ति, विद्युत शोर, केबल रूटिंग, अस्थिर पावर सप्लाई, नेटवर्क टोपोलॉजी, वॉचडॉग टाइमिंग, या फर्मवेयर मुद्दों के कारण हो सकते हैं। सिस्टम को पुनः आरंभ करने से पहले जब दोष होता है, उसे रिकॉर्ड करें।
5. BMS संचार दोष को ठीक करने के बाद क्या सत्यापित किया जाना चाहिए?
यह पुष्टि करें कि PCS सही प्राप्त करता हैSoC, वोल्टेज, करंट, तापमान, अलार्म, और चार्ज/डिस्चार्ज सीमाएँ, BMS सुरक्षा आदेशों का पालन करता है, EMS को सही रिपोर्ट करता है, और नियंत्रित पुनः आरंभ के बाद संचार को पुनः प्राप्त करता है।
