एक PLC salesman से MQTT के बारे में पूछें और आपको एक रोडमैप मिलता है: "अगले साल, शायद, प्रीमियम मॉडल पर।" फिर आप छोटे प्रिंट को देखते हैं और एक गेटवे, एक कनवर्टर, या एक क्लाउड सब्सक्रिप्शन पाते हैं जो फीचर के पीछे छिपा है। xLogic ईथरनेट CPUs पर MQTT समर्थन में इनमें से कोई भी नहीं है - यह 1.04 संशोधन से फर्मवेयर में है, और यह सीधे कंट्रोलर से प्रकाशित करता है।
यह बजट मशीन की क्षमताओं को बदलता है, और अधिकांश इंटीग्रेटर्स ने इसे नोटिस नहीं किया है।
क्यों MQTT एकMicro PLC
MQTT बिल्कुल इसी स्थिति के लिए बनाया गया है: एक अविश्वसनीय नेटवर्क पर एक डिवाइस, एक ब्रोकर को छोटे संदेश प्रकाशित करना, जिसमें सब्सक्राइबर आते और जाते हैं। एक फैक्ट्री में एक मशीन, एक खेत में एक पंप स्टेशन, एक ग्रीनहाउस जो कार्यालय से दो घंटे दूर है - प्रत्येक अपनी स्थिति प्रकाशित करता है; क्लाउड डैशबोर्ड, फोन ऐप और इंजीनियर का लैपटॉप सभी एक ही विषय की सदस्यता लेते हैं। कोई पोलिंग नहीं, प्लांट में कोई ओपन पोर्ट नहीं, कोई SCADA सर्वर कनेक्शन की देखरेख नहीं कर रहा है।
ब्रोकर अराजकता को संभालता है। PLC बस प्रकाशित करता है।
आप वास्तव में क्या कॉन्फ़िगर करते हैं
कनेक्शन ब्लॉक्स प्रोग्राम में रहते हैं: ब्रोकर का पता सेट करें, विषय, प्रकाशित अंतराल, और मैप करें कि कौन से मान पेलोड में जाएं। CPU कनेक्शन जीवनचक्र को संभालता है - एक ड्रॉप के बाद पुनः कनेक्ट करें, एक गैप के बाद पुनः प्रकाशित करें - जो हाथ से बनाए गए कार्यान्वयनों को खत्म करता है।
इसे वेब सर्वर और अलार्म SMS के साथ जोड़ें और आपके पास एक कंट्रोलर पर तीन स्वतंत्र दूरस्थ चैनल हैं। कार्यालय के लिए क्लाउड डैशबोर्ड, ऑपरेटर के लिए ब्राउज़र पृष्ठ, ड्यूटी इंजीनियर के लिए SMS। अपने दर्शकों के अनुसार अपना चैनल चुनें।
वास्तविक मामला: दूरस्थ ग्रीनहाउस निगरानी
चार बे के साथ एक नर्सरी ने साइट नेटवर्क को फिर से बनाए बिना क्लाउड दृश्यता चाही। प्रत्येक बे कंट्रोलर ने एक किराए के VPS पर एक ब्रोकर को तापमान, आर्द्रता और वाल्व स्थिति प्रकाशित की; एक सरल डैशबोर्ड ने सदस्यता ली और एक स्क्रीन पर सभी चार बे दिखाए। जब इंटरनेट एक दोपहर के लिए बंद हो गया, तो कंट्रोलर्स ने एक स्थानीय कतार में प्रकाशित करना जारी रखा और पुनः कनेक्ट होने पर मान मिल गए।
उगाने वाले का सारांश, उत्साही से अनुवादित: "मैंने छुट्टी पर रहते हुए अपने फोन से तापमान ग्राफ देखा। यह वहां होने से बेहतर था।"
जहां MQTT गलत उत्तर है
सीमाओं के बारे में ईमानदार रहें। MQTT इवेंट और टेलीमेट्री उन्मुख है - यह एक निश्चित नियंत्रण लूप नहीं है। यदि आपको गारंटीकृत डिलीवरी और मिलीसेकंड प्रतिक्रिया की आवश्यकता है, तो स्थानीय रूप से Modbus TCP का उपयोग करें। MQTT निगरानी और रिपोर्टिंग के लिए है, सुरक्षा इंटरलॉकिंग के लिए नहीं। इसे इस तरह से डिज़ाइन करें और यह आपको वर्षों तक सेवा देगा।
और ब्रोकर क्रेडेंशियल्स को सही रखें। एक PLC जो एक सार्वजनिक विषय पर प्रकाशित करता है, वह अपने व्यवसाय का प्रसारण कर रहा है। निजी विषय, एक स्थानीय ब्रोकर, या न्यूनतम TLS ब्रोकर पर - सेटअप लागत मिनटों में होती है, और बची हुई शर्म वास्तविक होती है।
चोरी करने लायक पैटर्न
विषय डिज़ाइन जो स्केल करता है
MQTT केवल आपकी विषय संरचना के रूप में साफ है, और विषय संरचना वह जगह है जहां छोटे प्रोजेक्ट चुपचाप असंगठित हो जाते हैं। नासमझ दृष्टिकोण - प्रत्येक डिवाइस के लिए एक विषय, एक पेलोड जिसमें सब कुछ है - एक मशीन के लिए काम करता है और दस पर गिर जाता है। प्रत्येक सब्सक्राइबर प्रत्येक पेलोड को फिर से पार्स करता है, पेलोड में प्रत्येक परिवर्तन हर डैशबोर्ड को तोड़ता है, और डिबगिंग एक विषय-प्रति-विषय शिकार बन जाती है।
पहले प्रकाशित करने से पहले पदानुक्रम को डिज़ाइन करें। एक पैटर्न जिसने मुझे अच्छी तरह से सेवा दी:site/device/category/value. तोplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. वाइल्डकार्ड सब्सक्राइबर - plant1 के लिए एक डैशबोर्ड, pump1 के लिए एक पृष्ठ, हर चीज के लिए एक अलार्म श्रोता - प्रत्येक ठीक उसी स्लाइस की सदस्यता लेते हैं जिसकी उन्हें आवश्यकता होती है। नए उपकरण पुराने विषयों को छुए बिना स्लॉट में आते हैं, और पेलोड छोटे और टाइप किए जाते हैं।
पेलोड को सरल रखें: एक मान और एक टाइमस्टैम्प। ग्यारह फ़ील्ड रखने वाले नेस्टेड JSON ब्लॉब्स नहीं, जब तक कि आपको वास्तव में उनकी आवश्यकता न हो। सरल पेलोड डिबग करने योग्य होते हैं - आप ब्रोकर कंसोल में एक पढ़ सकते हैं और तुरंत जान सकते हैं कि यह सही है या नहीं। और स्थिति विषयों पर रिटेन फ्लैग सेट करें ताकि एक नया सब्सक्राइबर तुरंत अंतिम ज्ञात स्थिति देख सके, अगली प्रकाशित होने की प्रतीक्षा करने के बजाय। रिटेन की गई स्थिति एक डैशबोर्ड के बीच का अंतर है जो तुरंत खुलता है और एक जो मिनटों तक खाली देखता है।
अंतिम नियम वह है जिसका लोग विरोध करते हैं: जब पेलोड प्रारूप बदलता है तो विषय का संस्करण बनाएं।plant1/pump1/status/v2. यह बदसूरत है। यह आपको एक परिवर्तन के साथ उत्पादन में पांच सब्सक्राइबर को तोड़ने से बचाता है। काम करने वाले बदसूरत विषय साफ विषयों से बेहतर होते हैं जो फट जाते हैं।
प्रकाशित करने लायक डेटा
सब कुछ प्रकाशित करना कुछ भी प्रकाशित करने के समान बुरा है - यह ब्रोकर को बाढ़ करता है, लॉग को बड़ा करता है, और महत्वपूर्ण मानों को दफन करता है। उस प्रश्न से शुरू करें जो सब्सक्राइबर पूछेगा, न कि रजिस्टरों की सूची से। एक ऑपरेटर स्थिति, अलार्म और चलने वाले कुल चाहता है। एक इंजीनियर प्रवृत्तियों को चाहता है: तापमान, दबाव, रन घंटे। एक प्रबंधक अपटाइम और गिनती चाहता है। इन्हें प्रकाशित करें, और केवल इन्हें।
दरें भी मायने रखती हैं। अलार्म संक्रमण: तुरंत प्रकाशित करें, हमेशा। स्थिति: परिवर्तन पर और एक हार्टबीट। एनालॉग मान: उस अंतराल पर जो वास्तव में प्रक्रिया को दिखाता है - धीमी ग्रीनहाउस तापमान के लिए दस सेकंड, मशीन टूल के लिए एक सेकंड। हर तेज़ विषय जिसकी आपको आवश्यकता नहीं है, वह ब्रोकर लोड और वायरलेस मॉडलों पर बर्बाद हुआ सिम डेटा है।
और महत्वपूर्ण लोगों को स्थानीय रूप से भी लॉग करें। CPU का डेटा लॉगिंग और ब्रोकर के रिटेन किए गए संदेश आपको महत्वपूर्ण इतिहास की दो प्रतियां देता है। जब ब्रोकर का खराब दिन होता है - वे सभी होते हैं - मशीन-साइड लॉग सत्य का स्रोत होता है, और पुनर्प्राप्ति वार्तालाप संक्षिप्त होता है।
CPU पर स्थानीय नियंत्रण, MQTT के माध्यम से क्लाउड दृश्यता, और दोनों कभी हस्तक्षेप नहीं करते। यह विभाजन आधुनिक छोटे ऑटोमेशन की आर्किटेक्चर है, और यह DIN रेल पर फिट बैठता है। सेल्समैन का रोडमैप नहीं आया। फर्मवेयर पहले से ही भेजा गया था।
