एक DIN-रेल मॉड्यूल जो क्लाउड के लिए MQTT, इमारत के लिए BACnet, और मशीनों के लिए Modbus TCP बोलता है। यह वाक्य गेटवे से भरे एक पैनल का वर्णन करने के लिए उपयोग किया जाता था। अब यह एक एकल ईथरनेट-सक्षम कॉम्पैक्ट CPU का वर्णन करता है, और xLogic प्लेटफॉर्म पर मल्टी-प्रोटोकॉल कहानी कोई मार्केटिंग स्लाइड नहीं है - यह फर्मवेयर में है, मैनुअल संशोधनों में दस्तावेजीकृत: V1.04 से MQTT, V1.57 से BACnet, पहले दिन से Modbus।
यहाँ बिना रखरखाव का दुःस्वप्न बनाए इसका उपयोग कैसे करें।
प्रोटोकॉल मानचित्र
प्रत्येक प्रोटोकॉल का अपना स्वाभाविक दर्शक होता है, और चाल उन्हें अलग रखना है:
- Modbus TCP— मशीन का फ़्लोर: VFDs, HMIs, SCADA, अन्य PLCs। निश्चित, रजिस्टर-आधारित, सार्वभौमिक औद्योगिक हैंडशेक
- MQTT— क्लाउड: एक ब्रोकर को टेलीमेट्री प्रकाशित करें, डैशबोर्ड सब्सक्राइब करें। इवेंट-चालित, NAT-फ्रेंडली, अस्थिर नेटवर्क के लिए बनाया गया
- BACnet— बिल्डिंग: प्लांट रूम, AHUs, BMS हेड-एंड। संपत्ति उद्योग की मातृभाषा
एक CPU सभी तीन दर्शकों की सेवा करता है जिसका मतलब है कि मशीन निर्माता, सुविधाओं का प्रबंधक और क्लाउड डैशबोर्ड एक ही डिवाइस देखते हैं - प्रत्येक अपनी अपनी भाषा में, उनमें से किसी को भी एक कनवर्टर बॉक्स की आवश्यकता नहीं है।
वास्तविक इमारत: छोटा प्लांट रूम
एक प्लांट रूम जिसमें एक AHU, दो फैन-कॉइल समूह और एक हीट पंप है: स्थानीय HMI और VFDs के लिए Modbus TCP, शेड्यूलिंग और अलार्म के लिए इमारत BMS के लिए BACnet, दूरस्थ ट्रेंडिंग के लिए क्लाउड सेवा के लिए MQTT। तीन प्रोटोकॉल, एक नियंत्रक, एक प्रोग्राम। BMS इंजीनियर ने पूछा कि गेटवे किसने बनाया। उत्तर - "कोई गेटवे नहीं है" - ने एक पूर्ण पांच सेकंड का मौन अर्जित किया।
वह मौन उत्पाद का काम करना है।
क्या अलग रखना है
प्रोटोकॉल CPU को साझा कर सकते हैं, लेकिन उन्हें डेटा योजना साझा नहीं करनी चाहिए। बिंदुओं को एक बार, जानबूझकर मैप करें: कौन से रजिस्टर Modbus-दृश्यमान हैं, कौन से ऑब्जेक्ट BACnet हैं, कौन से विषय MQTT हैं। एक एकल बिंदु मानचित्र, एक स्प्रेडशीट में बनाए रखा गया, क्लासिक विफलता को रोकता है - एक रजिस्टर संख्या बदलना और तीन सिस्टम चुपचाप पुराना हो जाना।
और मॉडल सीमाओं को याद रखें: BACnet/IP और MQTT को ईथरनेट-सक्षम CPUs की आवश्यकता होती है। केवल सीरियल मॉडल Modbus RTU और BACnet/MSTP रखते हैं। वादा करने से पहले आवश्यकता के खिलाफ मॉडल की जांच करें, खरीद आदेश के बाद नहीं।
समर्थन कोण जिसकी कोई कीमत नहीं लगाता
मल्टी-प्रोटोकॉल केवल एक विशेषता नहीं है; यह एक बिक्री दरवाजा है। निविदाएँ अब मानक के रूप में BMS एकीकरण, क्लाउड कनेक्टिविटी को चेकलिस्ट आइटम के रूप में मांगती हैं। एक नियंत्रक जो बिना ऐड-ऑन के दोनों का उत्तर देता है, पूर्व-योग्यता फ़िल्टर को पार करता है। एकल-प्रोटोकॉल और मल्टी-प्रोटोकॉल संस्करणों के बीच मूल्य का अंतर छोटा है; जिस परियोजनाओं पर आप बोली लगाने की अनुमति है, उसमें अंतर नहीं है।
बिंदु मानचित्र अनुशासन
मल्टी-प्रोटोकॉल एक आशीर्वाद और एक जाल है। आशीर्वाद: एक CPU तीन सिस्टम की सेवा करता है। जाल: तीन सिस्टम सत्य के थोड़े अलग संस्करण पढ़ रहे हैं। समाधान उबाऊ और गैर-परक्राम्य है - एक एकल बिंदु मानचित्र जो हर मान को एक बार सूचीबद्ध करता है, इसके रजिस्टर, इसके BACnet ऑब्जेक्ट, और इसके MQTT विषय के साथ एक ही पंक्ति में।
स्प्रेडशीट को पहले दिन शुरू करें, पहले ब्लॉक के वायरिंग से पहले। कॉलम: मान नाम, Modbus रजिस्टर, BACnet ऑब्जेक्ट प्रकार और उदाहरण, MQTT विषय, डेटा प्रकार, स्केलिंग, अपडेट दर, और कौन सा सिस्टम लेखन के लिए अधिकृत है। अंतिम कॉलम लोगों की सोच से अधिक महत्वपूर्ण है - जब BMS और क्लाउड डैशबोर्ड दोनों एक सेटपॉइंट को बदलना चाहते हैं, तो किसी को जीतना होता है, और मानचित्र बताता है कि कौन। इसके बिना, दो सिस्टम एक मान के लिए लड़ते हैं और मशीन 3 AM पर अप्रत्याशित रूप से व्यवहार करती है।
मानचित्र को प्रोग्राम के साथ संस्करणित करें। हर फर्मवेयर परिवर्तन, हर जोड़ा गया बिंदु, हर पुनःसंख्यांकन - मानचित्र उसी कमिट में अपडेट होता है। मैंने ऐसे प्रोजेक्ट विरासत में लिए हैं जहाँ मानचित्र दो साल पुराना था और तीन लोगों के पास अलग-अलग प्रतियाँ थीं। इसे फिर से बनाना एक सप्ताह तक रजिस्टर तालिकाओं को घूरने में लगा। एक सप्ताह। उस प्रोजेक्ट न बनें।
और जानबूझकर क्रॉस-प्रोटोकॉल पथों का परीक्षण करें: BMS से एक सेटपॉइंट लिखें, सत्यापित करें कि मशीन प्रतिक्रिया देती है, सत्यापित करें कि क्लाउड डैशबोर्ड परिवर्तन दिखाता है। प्रत्येक बिंदु के लिए एक एंड-टू-एंड परीक्षण, कमीशनिंग पर, मानचित्रण त्रुटियों को पकड़ता है जबकि उन्हें ठीक करना सस्ता है।
फर्मवेयर और संस्करण वास्तविकता
प्रोटोकॉल सुविधाएँ लहरों में आईं, और मैनुअल संशोधन इतिहास कहानी बताता है: 4.2 में MQTT, 4.5 में वेब सर्वर, 6.0 में वाईफाई निर्देश, 6.2 में BACnet, 6.2.1 में SR-22 समर्थन। यदि आप एक मल्टी-प्रोटोकॉल प्रोजेक्ट की योजना बना रहे हैं, तो फर्मवेयर संस्करण कोई विवरण नहीं है - यह एक आवश्यकता है। एक CPU जो दो साल पहले शिप हुआ था, उसे BACnet बोलने से पहले एक अपडेट की आवश्यकता हो सकती है, और अपडेट पथ मॉडल पर निर्भर करता है।
फर्मवेयर चेक को प्री-सेल्स चेकलिस्ट का हिस्सा बनाएं। आदेश पर संस्करण नोट करें, डिलीवरी पर इसकी पुष्टि करें, और कमीशनिंग शीट पर इसे दस्तावेजीकृत करें। इस व्यवसाय में सबसे महंगा बातचीत "यह इसका समर्थन करना चाहिए" के बाद "यह ऐसा नहीं करता" है।
और प्रोटोकॉल को उनकी ताकत के बारे में ईमानदार रखें। इमारत के लिए BACnet, मशीनों के लिए Modbus, क्लाउड के लिए MQTT - प्रत्येक उस वायर प्रकार पर जिसके लिए इसे डिज़ाइन किया गया था। ईथरनेट CPU सभी तीन को एक साथ संभालता है; यह उन्हें एक प्रोटोकॉल नहीं बनाता है, और इसे ऐसा नहीं करना चाहिए। अलगाव वही है जो प्लांट को चलाता है जब क्लाउड लिंक गिरता है - स्थानीय Modbus और BACnet ट्रैफ़िक इंटरनेट के लिए इंतजार नहीं करता।
प्रोटोकॉल दस्तावेज़ीकरण की आदत
बिना प्रोटोकॉल मानचित्र के एक तीन-प्रोटोकॉल नियंत्रक एक संग्रहालय प्रदर्शनी है। अनुशासन कमीशनिंग पर एक घंटे की लागत है और हर बार जब इमारत बदलती है तो एक सप्ताह बचाता है: एक शीट जो हर बिंदु, इसके Modbus रजिस्टर, इसके BACnet ऑब्जेक्ट, और इसके MQTT विषय को सूचीबद्ध करती है - लेखन प्राधिकरण के साथ चिह्नित। शीट पैनल ड्रॉइंग के साथ रहती है, प्रोग्राम के साथ संस्करणित होती है। जब BMS इंजीनियर पूछता है "सप्लाई तापमान कौन सा मान है?" उत्तर एक पंक्ति है, न कि रजिस्टर पुरातत्व का एक दोपहर।
प्रोटोकॉल के साथ संस्करण खरीदें। परियोजनाएँ अनुसरण करेंगी।
