वेब UART रिमोट कंट्रोल

आइए लोहे से शुरू करें

मैंने एक बार एक कारखाने में काम किया था, जहाँ वे सभी प्रकार के इलेक्ट्रॉनिक्स को बनाते थे, बहुत जटिल नहीं थे, और कभी-कभी "इंटरनेट ऑफ़ थिंग्स" की परिभाषा के अंतर्गत आते थे। अधिकांश भाग के लिए, सुरक्षा प्रणालियों के लिए सभी प्रकार के सेंसर: धुआं, शोर, पैठ, आग, और बहुत कुछ। उत्पादों का वर्गीकरण विस्तृत था, बहुत से कभी-कभी 500 से कम टुकड़े होते थे, और लगभग प्रत्येक उत्पाद के लिए मुझे एक अलग टेस्ट फिक्सेचर बनाना पड़ता था - वास्तव में, बस एक टिन बॉक्स जिसमें उत्पाद को परीक्षणों पर रखा गया था, एक ढक्कन द्वारा दबाया गया था, और नीचे से संपर्क सुइयों को संपर्क बिंदुओं पर दबाया गया था। एक मुद्रित सर्किट बोर्ड पर, कुछ इस तरह:

इस प्रकार, डिवाइस के साथ शारीरिक रूप से संवाद करना संभव था। हमारे पास संचार प्रोटोकॉल उद्योग में काफी आम था - RS232 (COM-port, UART का एक प्रकार)। अंतिम उत्पाद के परीक्षण के लिए सभी प्रकार के सरल नियंत्रित उपकरणों को भी बॉक्स में रखा गया था। इन सभी सहायक उपकरण को उसी तरह नियंत्रित किया गया था। पूरी संरचना बहुत चुलबुली थी, और सभी प्रकार की समस्याएं दैनिक दिनचर्या का हिस्सा थीं।

समस्याओं की सीमा बहुत व्यापक थी - खराब संपर्क, स्थापना के दौरान ध्रुवीयता को उलट दिया, परीक्षण उत्पाद के साथ समस्याओं, नियंत्रण और माप उपकरणों के साथ, संपर्क सुइयों के साथ, परीक्षण कोड के साथ ... लेकिन आपको कभी पता नहीं है! लेकिन लगातार परीक्षण करना आवश्यक था, और अगर कहीं पर "रोल" करने के लिए परीक्षण शुरू हुआ, तो इंजीनियरों में से एक को लाइन पर स्टंप करना पड़ा और मैन्युअल रूप से सब कुछ जांचना शुरू कर दिया।

सबसे पहले, डॉकलाइट लॉन्च किया गया था - COM बंदरगाहों के माध्यम से "संचार" के लिए एक अच्छी उपयोगिता, लेकिन इसकी बहुत सी सीमाएं थीं। और यहाँ हम मामले के सार से संपर्क कर रहे हैं।

डॉकलाइट मुझे सूट क्यों नहीं करता?

अच्छा, चलिए।

• पहली समस्या यह है कि डॉकलाइट केवल विंडोज पर चलता है। तो, रास्पबेरीपी के रूप में "तंत्रिका केंद्र" की स्थापना, जो सभी उपकरणों, या ऐसा कुछ कनेक्ट करेगी, को भुलाया जा सकता है। मुझे इस स्थिति में सबसे सस्ता समाधान - NUC स्थापित करना था। भारी, बल्कि बड़ा, और सबसे सस्ता नहीं। वैसे, जब इन टेस्ट फिक्स्चर को एक स्थान से दूसरे स्थान पर घसीटा गया था, तो एनयूसी ने बहुत संघर्ष किया, हालांकि (मैं मानता हूं कि उनका डिज़ाइन काफी ठोस है)।
  
• दूसरा - रिमोट एक्सेस केवल डेस्कटॉप साझाकरण के माध्यम से किया जा सकता है - इसे स्थानीय नेटवर्क के माध्यम से भी धीमा कर दिया गया था, और यहां तक ​​कि इंटरनेट के माध्यम से यह पूरी तरह से लंगड़ा था।
  
• तीसरा, प्रत्येक डिवाइस के पास आदेशों का अपना सेट था, और डॉकलाइट कमांड की सूची के साथ एक फ़ाइल लोड कर सकता है। यदि, कहते हैं, आपको विभाग में किसी के साथ एक समान सूची साझा करनी थी, तो या तो फ़ाइल के साथ एक ईमेल भेजें, या ... साझा किए गए फ़ोल्डर में फ़ाइल का लिंक भेजें! स्वाभाविक रूप से, प्रत्येक डॉकलाइट स्थापना को स्थानीय रूप से ऐसी फ़ाइलों की आवश्यकता होती है, और यह सब दर्जनों (यदि सैकड़ों बार नहीं) मैन्युअल रूप से किया जाना था - प्रत्येक एनयूसी के लिए, प्रत्येक इंजीनियर ने अपनी पसंदीदा और सुविधाजनक कमांड सूचियों को खींच लिया। और यार्ड 2019 में, मुझे आपको याद दिलाने की ...
  
• चौथा, डॉकलाइट आपको डिवाइस नाम के साथ COM पोर्ट को स्वचालित रूप से संबद्ध करने की अनुमति नहीं देता है: उदाहरण के लिए, विंडोज, जब आप पावर सप्लाई कनेक्ट करते हैं, तो COM12 के माध्यम से डिवाइस के साथ संचार करेगा। यदि आप मैन्युअल रूप से "स्ट्रिंग्स खींचना" चाहते हैं, तो डॉकलाइट में आपको COM12 खोलने की आवश्यकता है। हम यह कैसे पता लगा सकते हैं कि यह सिर्फ Power Supply के बारे में है, और नहीं, कहें कि, SwitchBoard के बारे में? ठीक है, आप हर बार डिवाइस मैनेजर में देख सकते हैं, और यह न भूलें कि कौन सा डिवाइस किस पोर्ट से जुड़ा है। उसी समय, कोई भी गारंटी नहीं देता है कि यदि आप बस डिवाइस को बाहर निकालते हैं और फिर इसे फिर से प्लग करते हैं, तो पिछले पोर्ट इस डिवाइस के साथ रहेगा। संक्षेप में, हर बार आपको इसे मैन्युअल रूप से करना होगा। और मेरा विश्वास करो, दिन के अंत तक मेरा सिर इस से घूम रहा था।
  
• पांचवें, प्रत्येक बंदरगाह को कार्यक्रम की एक अलग प्रतिलिपि की आवश्यकता थी, और निश्चित रूप से, सभी कार्यों को प्रत्येक डिवाइस के लिए व्यक्तिगत रूप से किया जाना था, और हालांकि डॉकलाइट स्क्रिप्टिंग का समर्थन करता है, व्यक्तिगत उदाहरणों के बीच कोई बातचीत नहीं है।
  
  अगला। किसी भी अन्य उत्पाद के साथ कोई एकीकरण प्रदान नहीं किया गया था। यह एक तिपहिया लगता है, लेकिन यहां एक ऐसी स्थिति है जहां यह सफेद गर्मी में लाया गया: परीक्षण गिर गया, और हमें यह पता लगाने की आवश्यकता है कि क्यों। सबसे पहले, आपको उपकरणों से कनेक्ट करने और यह देखने की आवश्यकता है कि क्या वे बिल्कुल मृत हैं। हम डिवाइस मैनेजर पर जाते हैं, देखते हैं कि हमारा डिवाइस किस पोर्ट पर बैठता है, डॉकलाइट खोलें, हमारे पोर्ट के साथ संचार आरंभ करें ... त्रुटि। धिक्कार है! मैं उस सेवा को रोकना भूल गया जो NUC पर स्थापित है और सभी बंदरगाहों को रखती है। अनन्य, आप जानते हैं। ठीक है, हम सेवा को धीमा कर देते हैं, पोर्ट खोलते हैं, डिवाइस के कमांड के साथ फाइल लोड करते हैं, कमांड भेजते हैं, हमें जवाब मिलता है (या नहीं मिलता है), हम समस्या का समाधान करते हैं। हम फिर से परीक्षण चलाते हैं, यह फिर से दुर्घटनाग्रस्त हो जाता है ... ओह, यह लानत है, मैं डॉकलाइट बंद करना भूल गया और सेवा को फिर से शुरू कर दिया। लगता है सब कुछ कोई त्रुटि नहीं है। लेकिन यह अगले कुछ घंटों के लिए है, जब तक कि कुछ फिर से गलत न हो जाए। और मेरा विश्वास करो, इस तरह की समस्याओं को हल करना आवश्यक था जितना हम चाहते हैं उससे अधिक बार।
  

खैर, और निश्चित रूप से, किसी भी एक्सटेंशन के बारे में, जोड़ें। कोई विशेषता या ऐसा नहीं हो सकता है - उत्पाद बंद है, लंबे समय तक लिखा है (ऐसा लगता है कि वे अब विशेष रूप से विकसित नहीं हुए हैं), कोई अनुकूलन नहीं है।

खैर, मैंने कुछ मेरा करने का फैसला किया, लेकिन वर्णित समस्याओं के साथ स्थिति को सुधारना (या सुधारना)।
यह ज़ाबिक्स की तरह कुछ निकला, लेकिन एक विशिष्ट स्थिति के लिए तेज करने के साथ।

तो अंतर क्या है?

शायद यह वास्तुकला के एक सामान्य विवरण के साथ शुरू करने के लिए समझ में आता है, और फिर विवरण में जाता है।

योजना इस प्रकार है:



हमारे पास एक एजेंट है जो उस स्टेशन पर चलता है जिससे हमारे उपकरण शारीरिक रूप से जुड़े हुए हैं। एजेंट पायथन में लिखा गया था, इसलिए यह विंडोज, लिनक्स पर समस्याओं के बिना काम करता है, और आप इसे रास्पबेरीपी और इसी तरह के उपकरणों पर उपयोग के लिए सुरक्षित रूप से समाप्त कर सकते हैं। यह कार्यक्रम संसाधनों के लिए अत्यंत निंदनीय है, और बहुत स्थिर है। एजेंट वेबसैट के माध्यम से सर्वर (बैक एंड) से लगातार जुड़ा रहता है, और सभी पोर्ट सेटिंग्स और उनके मापदंडों को प्राप्त करता है, दोनों आरंभीकरण के दौरान और अपडेट के दौरान। एजेंट के पास सेटिंग्स और मॉनिटरिंग के लिए अपना GUI होता है जिस स्थिति में (शायद कनेक्शन खो गया था, शायद लाइसेंस समाप्त हो गया है)।



अगला। सर्वर (उर्फ बैक एंड) डूकर से उठता है (और इसलिए केवल अमेज़ॅन या Google क्लाउड में नहीं चलता है, बल्कि बोर्ड पर लिनक्स के साथ लैन पर किसी भी गैर-शक्तिशाली मशीन पर भी नहीं चलता है)। यह Django में Redis के साथ संयोजन में (वेबसोकेट का समर्थन करने के लिए) लिखा गया है। यह सभी सेटिंग्स को संग्रहीत करता है, और उपयोगकर्ता GUI (सिर्फ ReactJS में लिखा गया एक पृष्ठ) और एजेंट के माध्यम से - हमारे उपकरणों के बीच संचार प्रदान करता है। दो-तरफ़ा संचार, पूरी तरह से अतुल्यकालिक। सभी सेटिंग्स Postgres और Mongo में संग्रहीत हैं।

खैर, और, शायद, सिस्टम का सबसे महत्वपूर्ण हिस्सा क्लाइंट खुद है (बस, एक ब्राउज़र में एक पृष्ठ, अधिक गतिशीलता के लिए ReactJS के लिए लिखा गया है)।



हां, दृश्य डिजाइन एकदम सही है, लेकिन यह निश्चित है।

खैर, यह गोल किया जा सकता है, मैं परियोजना की स्थिति और डेमो के बारे में केवल कुछ शब्द जोड़ूंगा।

1. यह बहुत शुरुआती अल्फा है, जो संभावित संभावनाओं को प्रदर्शित करने और रुचि के स्तर की जांच करने के लिए डिज़ाइन किया गया है।
   
2. एक डेमो खेलते हैं - यहाँ
   लॉग इन करने के लिए
   उपयोगकर्ता नाम: ऑपरेटर_0
   पासवर्ड: 123456789
   हम QA_Test और किसी भी स्टेशन का चयन करते हैं (यह केवल उद्यम की संरचना का अनुकरण करने का प्रयास है - पोर्ट स्टेशनों से जुड़े हैं, वे विभागों में विभाजित हैं, और प्रत्येक कार्यालय की अपनी संरचना है)
   

सिद्धांत रूप में, यदि रुचि है, तो मैं https के लिए समर्थन जोड़ूंगा, और मैं विभिन्न प्लेटफार्मों के लिए एजेंट की असेंबलियों का निर्माण करूंगा, साथ ही साथ अन्य सभी सुविधाओं को भी जोड़ूंगा।

मुझे किसी भी प्रतिक्रिया और सुझाव पर खुशी होगी। आलोचना का स्वागत है!