एक एम्बेडेड अनुप्रयोग वास्तुकला डिजाइन करना

शुभ दोपहर मैं एम्बेडेड अनुप्रयोगों की वास्तुकला के बारे में बात करना चाहूंगा। दुर्भाग्य से, इस विषय पर बहुत कम किताबें हैं, और इस तथ्य के कारण कि, हाल ही में, एम्बेडेड और IoT में रुचि बढ़ रही है, मैं इस मुद्दे पर ध्यान देना चाहता हूं। इस लेख में, मैं ऐसे संभावित विकल्पों में से एक का वर्णन करना चाहूंगा कि इस तरह के अनुप्रयोगों को कैसे डिज़ाइन किया जा सकता है।

यह एक बहस का सवाल है! इसलिए, वे टिप्पणियों में अपनी दृष्टि साझा करने की पेशकश करते हैं!
शुरू करने के लिए, हम इस क्षेत्र को निर्धारित करेंगे: इस लेख के ढांचे के भीतर, एम्बेडेड विकास से हमारा मतलब है कि माइक्रोकंट्रोलर के लिए सॉफ्टवेयर विकास (इसके बाद एमके, उदाहरण के लिए STM32) C / Asm भाषा में।
एमके-आधारित सिस्टम के लिए परियोजनाओं को सशर्त रूप से उन लोगों में विभाजित किया जा सकता है जिन्हें मल्टीटास्किंग की आवश्यकता नहीं होती है और आवश्यकता होती है । पहले प्रकार के समाधानों के लिए, वे आम तौर पर बहुत जटिल नहीं हैं (संरचनात्मक दृष्टिकोण से)। उदाहरण के लिए, एक साधारण परियोजना, जिसमें सेंसर से डेटा को पढ़ना और स्क्रीन पर प्रदर्शित करना आवश्यक है, मल्टीटास्किंग नहीं करता है, यहां यह उपरोक्त कार्यों के अनुक्रमिक निष्पादन को लागू करने के लिए पर्याप्त है।



यदि एप्लिकेशन अधिक जटिल है: जिसके ढांचे के भीतर डिजिटल सेंसर और एनालॉग दोनों से डेटा पढ़ना आवश्यक है, प्राप्त मूल्यों को मेमोरी में सहेजें (उदाहरण के लिए, एसडी कार्ड के लिए), यूजर इंटरफेस (डिस्प्ले + कीबोर्ड) बनाए रखें, और डेटा तक पहुंच प्रदान करें एक डिजिटल इंटरफेस (उदाहरण के लिए, RS-485 / मोडबस या ईथरनेट / टीसीपी / आईपी) और सिस्टम में कुछ घटनाओं (आपातकालीन बटन आदि को दबाने) पर जितनी जल्दी हो सके प्रतिक्रिया करें, तो इस मामले में मल्टीटास्किंग के बिना करना मुश्किल होगा। मल्टीटास्किंग समस्या को हल करने के दो तरीके हैं: इसे स्वयं लागू करना, या किसी प्रकार के ऑपरेटिंग सिस्टम का उपयोग करना (बाद में इसे ओएस कहा जाता है)। आज, एम्बेडेड सिस्टम के लिए सबसे लोकप्रिय रीयल-टाइम ऑपरेटिंग सिस्टम में से एक FreeRTOS है।

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

हम कार्य को अधिक स्पष्ट रूप से सेट करते हैं, भले ही हमारे आवेदन के ढांचे के भीतर यह आवश्यक हो:

• RS-485 / मोडबस पर सेंसर से डेटा पढ़ें।
• I2C बस पर सेंसर से डेटा पढ़ें।
• डिजिटल इनपुट से डेटा पढ़ें।
• नियंत्रण रिले उत्पादन।
• उपयोगकर्ता इंटरफ़ेस (प्रदर्शन + कीबोर्ड) बनाए रखें।
• RS-485 / मोडबस के माध्यम से डेटा तक पहुंच प्रदान करें।
• डेटा को बाहरी मीडिया में सहेजें।

क्योंकि हमें पर्याप्त रूप से बड़ी संख्या में विभिन्न उपकेंद्रों को लागू करने की आवश्यकता है, हम आधार के रूप में वास्तविक समय ऑपरेटिंग सिस्टम (उदाहरण के लिए, पहले से ही उल्लेख किए गए फ्रीआरटीओएस) का उपयोग करेंगे। OS में थ्रेड्स को कभी-कभी कार्य कहा जाएगा - FreeRTOS के समान। मैं आपको तुरंत चेतावनी देना चाहता हूं: लेख में कोई स्रोत कोड नहीं होगा, यह इस मुद्दे का वास्तुशिल्प पहलू है जो ब्याज का है।

यदि हम कार्य का विश्लेषण करते हैं, तो हम देख सकते हैं कि सिस्टम के विभिन्न घटक एक ही डेटा का उपयोग करते हैं। उदाहरण के लिए: सेंसर से डेटा प्राप्त किया जाना चाहिए, एक स्क्रीन पर प्रदर्शित किया जाना चाहिए, एक माध्यम को लिखा गया है और पढ़ने के लिए बाहरी प्रणालियों को प्रदान किया गया है। इससे पता चलता है कि विभिन्न उप-प्रणालियों को संग्रहीत करने और सबसे अधिक प्रासंगिक डेटा प्रदान करने के लिए कुछ प्रकार के रीयल-टाइम डेटाबेस (RTDB) की आवश्यकता होती है।

सिस्टम में किए गए कार्य (डेटा पढ़ना, लिखना, प्रदर्शित करना आदि) उनकी कॉल की आवृत्ति के लिए अलग-अलग आवश्यकताएं हो सकती हैं। यह प्रदर्शन पर डेटा को अपडेट करने का कोई मतलब नहीं है, प्रति 100 एमएस 1 बार की आवृत्ति के साथ, क्योंकि यह किसी व्यक्ति के लिए महत्वपूर्ण नहीं है, लेकिन अक्सर सेंसर से डेटा पढ़ना आवश्यक है (विशेषकर यदि उन पर नियंत्रण क्रिया देना आवश्यक है) (हालांकि यह टीके के आधार पर संभव नहीं हो सकता है)। एक और महत्वपूर्ण बिंदु पढ़ने और लिखने के लिए समान डेटा तक पहुंच की समस्या को हल करने से संबंधित है। उदाहरण के लिए: सेंसर से पूछताछ करने वाली एक धारा आरटीडीबी को प्राप्त मूल्यों को लिखती है, और इस समय प्रदर्शन पर जानकारी को अपडेट करने के लिए जिम्मेदार धारा उन्हें पढ़ती है। यहां, ऑपरेटिंग सिस्टम जो सिंक्रोनाइज़ेशन तंत्र प्रदान करता है वह हमारी मदद करेगा।

चलो हमारे आवेदन की वास्तुकला डिजाइन करना शुरू करते हैं!

वास्तविक समय डेटाबेस

फ़ील्ड या सरणी के आवश्यक सेट से युक्त एक साधारण संरचना ऐसे आधार के रूप में काम कर सकती है। "आरटीडीबी" का उपयोग करने के लिए हम एपीआई का उपयोग करेंगे, जो हमें डेटाबेस से डेटा लिखने और पढ़ने की अनुमति देगा। एपीआई फ़ंक्शन के अंदर डेटा एक्सेस सिंक्रनाइज़ेशन ओएस द्वारा प्रदान किए गए म्यूटेक्स पर बनाया जा सकता है (या कुछ अन्य तंत्र का उपयोग करें)।

टायरों पर सेंसर के साथ काम करना

सेंसर के साथ काम करने में निम्नलिखित शामिल हैं:

• डेटा पढ़ना;
• डेटा प्रोसेसिंग (यदि आवश्यक हो), जिसमें शामिल हैं:
  
  • सत्यापन की जांच;
  • स्केलिंग;
  • निस्पंदन;
  • वैध मूल्यों का सत्यापन;
  
  
• रिकॉर्डिंग आरटीडीबी में डेटा प्राप्त किया।

यह सब काम एक काम में किया जा सकता है।



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

"RTDB", संबंधित अनुभाग में ऊपर वर्णित वास्तविक समय डेटाबेस है।
कार्य के ऊपर "Pr: 1" शिलालेख का मतलब प्राथमिकता है, निचला रेखा यह है कि प्रत्येक कार्य में प्राथमिकता हो सकती है यदि प्रोसेसर समय की प्रतीक्षा कर रहे दो कार्यों में अलग-अलग प्राथमिकताएं हैं, तो संसाधन उच्च प्राथमिकता के साथ प्राप्त करेगा। यदि कार्यों में समान प्राथमिकता है, तो लंबे समय तक प्रतीक्षा के साथ लॉन्च किया जाएगा।

असतत इनपुट के साथ काम करें

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



एक विशिष्ट इनपुट की स्थिति को बदलने के लिए त्वरित प्रतिक्रिया के अलावा, आप असतत इनपुट की स्थिति को पढ़ने के लिए "DI रीडर" कार्य को अतिरिक्त रूप से सेट कर सकते हैं। यह कार्य या तो स्वतंत्र हो सकता है या टाइमर द्वारा बुलाया जा सकता है।

डायग्राम के रूप में "इंटरप्ट हैंडलर" और "रिले कंट्रोलर" का काम नीचे प्रस्तुत किया गया है।

बाहरी मीडिया को डेटा लिखना

बाहरी माध्यम में डेटा लिखना वैचारिक रूप से डिजिटल सेंसर से डेटा पढ़ने के समान है, केवल विपरीत दिशा में डेटा की आवाजाही होती है।



हम "आरटीडीबी" से पढ़ते हैं और "स्टोर ड्राइवर" के माध्यम से बाहरी माध्यम से लिखते हैं - यह एक एसडी कार्ड, एक यूएसबी फ्लैश ड्राइव या कुछ और हो सकता है। फिर से, इंटरफ़ेस फ़ंक्शन में म्यूटेक्स रैपर (या संसाधन तक पहुंच को व्यवस्थित करने के लिए कोई अन्य उपकरण) डालना न भूलें!

वास्तविक समय डेटा तक पहुंच प्रदान करना

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



"डेटा अपडेटर" किसी दिए गए फ़्रीक्वेंसी पर "RTDB" से डेटा पढ़ता है और "प्रोटोकॉल कैश" में पढ़ी गई सामग्री को जोड़ता है, जिससे "प्रोटोकॉल हैंडलर" डेटा उठाएगा। इस मामले में, प्रोटोकॉल कैश स्तर पर अवरुद्ध होने की समस्या है, इसे हल करने के लिए, आप एक और कैश बना सकते हैं जिसमें "प्रोटोकॉल हैंडलर" डेटा संग्रहीत करेगा यदि यह अवरुद्ध "प्रोटोकॉल कैश" से नहीं पढ़ सकता है, तो आप इसके अतिरिक्त कर सकते हैं:
- "प्रोटोकॉल हैंडलर" को एक उच्च प्राथमिकता दें;
- "डेटा अपडेटर" (जो एक बहुत ही समाधान है) के लिए "RTDB" से पढ़ने की अवधि बढ़ाएं।

यूजर इंटरफेस के साथ काम करें

उपयोगकर्ता इंटरफ़ेस के साथ काम करने से स्क्रीन पर डेटा को अपडेट करना और कीबोर्ड के साथ काम करना शामिल है। इस उपतंत्र की वास्तुकला इस तरह दिख सकती है।



यूआई कार्यकर्ता कीस्ट्रोक पढ़ने, "आरटीडीबी" से डेटा लेने और उपयोगकर्ता द्वारा देखे जाने वाले डिस्प्ले को अपडेट करने के लिए जिम्मेदार है।

सामान्य प्रणाली संरचना

अब एक नज़र डालिए कि आखिर हुआ क्या था।



लोड को संतुलित करने के लिए, आप अतिरिक्त कैश सेट कर सकते हैं, जैसा कि हमने इन बाहरी प्रणालियों तक पहुंच प्रदान करने के लिए जिम्मेदार उपतंत्र में किया था। डेटा ट्रांसफर के कुछ कार्यों को कतारों का उपयोग करके हल किया जा सकता है, क्योंकि वे आमतौर पर रीयल-टाइम ऑपरेटिंग सिस्टम (निश्चित रूप से, FreeROSOS में) द्वारा समर्थित हैं।
यह सब, मुझे आशा है कि यह दिलचस्प था।

पुनश्च
एक साहित्य के रूप में, मैं "एंबेडेड सिस्टम बनाना: महान सॉफ्टवेयर के लिए डिज़ाइन पैटर्न" की सिफारिश करूंगा। एलेरिया कोर्निट्स द्वारा फ्रीसिया व्हाइट और लेख "फ्रीट्रॉस - माइक्रोकंट्रोलर्स के लिए एक ऑपरेटिंग सिस्टम"।