एम्बेडेड सिस्टम की विविध दुनिया और इसमें एमबॉक्स का स्थान

Embox प्रोजेक्ट पहले से ही 9 साल पुराना है, लेकिन बहुत से लोग यह नहीं समझते हैं कि यह क्या है और इसे क्या खाया जाता है और इसकी आवश्यकता क्यों है। जिन लोगों ने इस परियोजना के बारे में सुना है और जानते हैं कि यह एक ऑपरेटिंग सिस्टम है, उनका मानना ​​है कि Embox एक "घरेलू OS" है। दरअसल, Embox को "लाठी और नौकाओं" के साथ "उनके" OS बनाने के प्रयास के रूप में कल्पना की गई थी, लेकिन मुख्य बात "लाठी और नौकाओं" है। यही है, कुछ विशेषताओं या उनके संयोजन, जिनकी अन्य परियोजनाओं में कमी थी, उन्हें सबसे आगे रखा गया था।

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

सिंगल बोर्ड कंप्यूटर

औद्योगिक कंप्यूटर

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

उपभोक्ता एकल भुगतानकर्ता

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

एम्बेडेड उपकरणों में लिनक्स

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

योक्टो परियोजना

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

OpenWRT

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

वास्तविक समय प्रणाली

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

वास्तविक समय प्रणालियों में लिनक्स

स्वाभाविक रूप से, लिनक्स से बाहर एक वास्तविक समय प्रणाली बनाने का प्रयास किया गया है (और होगा)। सबसे प्रसिद्ध एक RTLinux है , मूल रूप से यह लिनक्स के लिए एक पैच था, मूल " पूरी तरह से ईमानदार अनुसूचक " की जगह, अधिक सटीक रूप से, अपने आप को सम्मिलित करना, जो कि लिनक्स अनुसूचक द्वारा निर्धारित कार्यों में से एक है। इस अनुसूचक ने स्थिर कार्य प्राथमिकताओं पर काम किया; तदनुसार, इसने बहुत अधिक अनुमानित रूप से काम किया। लेकिन यह अब लिनक्स नहीं था, या बल्कि, लिनक्स की कार्यक्षमता वास्तविक समय में नहीं थी।

ARINC-653

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

uClinux

एम्बेडेड सिस्टम में लिनक्स का उपयोग करने का प्रयास बहुत पहले शुरू हुआ था। पहले एक सिस्टम में लिनक्स का उपयोग करने का प्रयास था जहां वर्चुअल मेमोरी (MMU) के लिए कोई हार्डवेयर समर्थन नहीं है। इस परियोजना को uCLinux कहा जाता था और लिनक्स कर्नेल में इसका योगदान NOMMU या MMU- कम मोड था।

वास्तविक समय प्रणालियों में लिनक्स

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

एम्बेडेड उपकरणों में विंडोज

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

माइक्रोकंट्रोलर्स

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

RTOSes

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

माइक्रोकंट्रोलर्स के लिए काफी आरटीओएस हैं। इसलिए, उन सभी के बारे में बात करना असंभव है। मैं केवल कुछ ही को बाहर करूंगा, मेरी राय में, दिलचस्प प्रोजेक्ट और संक्षेप में उनकी विशेषताओं के बारे में बात करेंगे।

FreeRTOS

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

Contiki

Contiki - एडम डंकल्स द्वारा विकसित RTOS, lwIP और uIP जैसे प्रसिद्ध टीसीपी / आईपी स्टैक के निर्माता। मैं कहूंगा कि पूरे ओएस को नेटवर्क स्टैक के आसपास बनाया गया है। IPv6 समर्थन और छोटी संसाधन आवश्यकताओं की उपस्थिति इस परियोजना को विभिन्न प्रकार के वायरलेस डिवाइस बनाने के लिए दिलचस्प बनाती है।

RTEMS

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

ecos

eCos एंबेडेड कॉन्फ़िगर करने योग्य ऑपरेटिंग सिस्टम। इसके अलावा काफी पुरानी परियोजना, पहले से बहुत लोकप्रिय है। मुख्य विचार एक बहुत ही विन्यास योग्य ओएस बनाना है, अर्थात् कर्नेल में केवल वही शामिल करना है जिसकी आपको आवश्यकता है।

अन्य RTOSes

सूची में कुछ समय के लिए चला जाता है। मैं नीचे एक और NuttX परियोजना का उल्लेख करूंगा । और जो लोग अधिक विस्तृत सूची में रुचि रखते हैं, उनके लिए मैं आपको विकिपीडिया देखने की सलाह देता हूं। माइक्रोकंट्रोलर्स के लिए, मैं ChibiOS / RT , MicroC / OS (rollC / OS) , नट / OS , RIOT का भी उल्लेख करूंगा । लेकिन निश्चित रूप से, यह सब कार्य पर निर्भर करता है।

Arduino

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

microkernel

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

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

एम्बेडेड सिस्टम की दुनिया में Embox का स्थान है

मैंने पहले से ही एम्बेडेड दुनिया के विभिन्न पहलुओं के बारे में काफी बात की थी, लेकिन मुझे कभी भी इसमें Embox की जगह नहीं मिली। खैर, मैं कह सकता हूं कि ऊपर वर्णित उदाहरणों में, Embox का उपयोग करने की आवश्यकता नहीं हो सकती है। इसके अलावा, हम आमतौर पर उपयोगकर्ताओं से पूछते हैं कि उन्हें Embox की आवश्यकता क्यों है? यदि Embox का उपयोग कोई लाभ नहीं देता है, तो हम ऊपर दी गई सूची या कुछ और (उदाहरण के लिए, Android) से कुछ आज़माने की सलाह देते हैं। लेकिन ऐसे कई मामले हैं जिनमें Embox का उपयोग एक ठोस लाभ देता है।

उपकरण विकास प्रणाली

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

लिनक्स प्रमाणित है

पहले तीसरे पक्ष के अनुप्रयोगों में से एक कोड प्रमाणन के लिए एक विशिष्ट आवश्यकता थी। सीमित कार्यक्षमता के साथ एक निश्चित उपकरण था, जिसमें शामिल हैं: सॉकेट्स (यूडीपी), फ़ाइल सिस्टम और कुछ और कार्यक्षमता के साथ काम करना। सभी कार्यक्षमता को ग्राहक द्वारा लिनक्स-आधारित सॉफ़्टवेयर के रूप में लागू किया गया था। यह डिवाइस x86 नहीं था और ARM नहीं थे। इसकी परिधि थी। डिवाइस में उपयोग किए जाने वाले कोड को प्रमाणित करना आवश्यक था, क्योंकि प्रमाणित वितरण का वहां उपयोग नहीं किया जा सकता था। लिनक्स कर्नेल को काटने का प्रयास कोड की लगभग 500 हजार लाइनों के परिणामस्वरूप हुआ, साथ ही #ifdef और अन्य मैक्रोज़ के साथ भी समस्याएं थीं। और ग्राहक ने इस उत्पाद के प्रमाणीकरण की लागत का मूल्यांकन करते हुए अन्य विकल्पों पर विचार करने के लिए कहा। उस समय Embox में पहले से ही एक नेटवर्क स्टैक था,फ़ाइल सिस्टम और इसे खाते की प्रमाणीकरण आवश्यकताओं को ध्यान में रखते हुए संशोधित करने का निर्णय लिया गया। इसलिए हमें Mybuild मॉड्यूल विवरण भाषा मिली, कुछ हद तक हमने मैक्रोज़ के साथ समस्या को हल किया, कुछ अन्य समस्याएं। नतीजतन, हमने यह हासिल किया है कि अंतिम छवि में हमने केवल (कॉन्फ़िगरेशन में घोषित) कोड का उपयोग किया है, और आमतौर पर किसी विशिष्ट कार्य के लिए इसकी बहुत आवश्यकता नहीं होती है।

लिनक्स के बिना लिनक्स

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

कुछ संसाधनों के साथ सिस्टम पर POSIX एप्लिकेशन चलाने का विचार एक अन्य ओपन सोर्स प्रोजेक्ट के लिए मुख्य है - NuttX। कुछ बिंदुओं पर, यह परियोजना Embox से बेहतर है, कुछ बिंदुओं पर - इसके विपरीत। Qt और SIP फ़ोन उदाहरण, जहाँ तक मुझे पता है, NuttX बहुत कठिन है। लेकिन परियोजना वास्तव में बहुत दिलचस्प है।

यह भी ध्यान देने योग्य है कि RTOS का एक हिस्सा POSIX परत भी जोड़ता है। उदाहरण के लिए, FreeRTOS या RTEMS, जो आज POSIX प्रोफाइल 52 के साथ पूरी तरह से अनुरूप है, जिसका अर्थ है "एक प्रक्रिया, कई थ्रेड्स, फ़ाइल सिस्टम । " आरटीईएमएस भी क्यूटी को माइक्रोकंट्रोलर पर लॉन्च करने के लिए सफल प्रयोग करता है

सुरक्षित लिनेक्स

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

लिनक्स वास्तविक समय

मैंने लिनक्स को वास्तविक समय प्रणाली के रूप में उपयोग करने के लिए काफी समर्पित किया है। समझाया कि यह क्यों हासिल करना मुश्किल है, साथ ही प्रयास क्यों किए जाते हैं। तो, OpenCV लाइन मान्यता रोबोट पर पहले से ही उद्धृत लेख पर वापस जाएं । यदि आपने लिंक को देखा, तो आपने देखा कि OpenCV RaPi पर घूम रहा है, और मोटर्स को एक अलग Arduino बोर्ड पर नियंत्रित किया जाता है। इसके कुछ कारण हैं: पहला शेड्यूलर है, दूसरा यह है कि प्रबंधन उपयोगकर्ता मोड से आता है, और लिनक्स में हार्डवेयर तक पहुंच नहीं है। जैसा कि आपने शायद अनुमान लगाया था, Embox में दोनों समस्याओं को लिनक्स की तुलना में बहुत आसान हल किया जा सकता है। और पर्याप्त संसाधनों के साथ एक ही बोर्ड पर, आप ओपनसीवी चला सकते हैं और मोटर्स को नियंत्रित कर सकते हैं।

कई उपकरण थे जो लिनक्स की कार्यक्षमता और वास्तविक समय में संयुक्त काम करते थे। एक उदाहरण एक वेब इंटरफेस द्वारा नियंत्रित सीएनसी मशीन है, जिसे मेरे द्वारा एक लेख में संक्षेप में वर्णित किया गया था । ठीक है, अगर हम कई बोर्डों पर रोबोट बनाते हैं, तो ये मल्टी-एजेंट सिस्टम हैं ।

चीजों का इंटरनेट

लगभग सभी RTOS माइक्रोकंट्रोलर की तरह Embox में संसाधन की कम आवश्यकताएं हैं। यहांstm32vl- खोज पर खिलौना उदाहरण पहले से ही हब्र पर वर्णित है Embox 16-बिट MSP-430 पर भी 512 बाइट्स रैम के साथ लॉन्च किया गया था। लेकिन अगर आप देखते हैं, उदाहरण के लिए, खिलौने के साथ लेख के कोड में, आप देखेंगे कि यह मानक POSIX धाराओं का उपयोग नहीं करता है, लेकिन स्टैकलेस स्ट्रीम (हल्के धागे) के अपने स्वयं के कार्यान्वयन। स्वाभाविक रूप से, यदि आप आगे बढ़ते हैं और सभी कोड स्वयं लागू करते हैं, तो मुझे यकीन है कि आप स्मृति लागत के मामले में बेहतर परिणाम प्राप्त कर सकते हैं। लेकिन स्मार्ट सेंसर IoT का सिर्फ एक हिस्सा हैं। वे कुछ और शक्तिशाली नोड्स में डेटा संचारित करते हैं। और वे इसे कुछ प्रोटोकॉल के अनुसार करते हैं। लेकिन अगर इस नोड पर Embox भी लॉन्च किया जाएगा, और लाइब्रेरी कोड जो संचार प्रोटोकॉल को लागू करता है, तो यह सामान्य होगा, यह विकास को सरल करेगा। सब के बाद, सबसे पहले, कोड आम है, और यहां तक ​​कि अगर प्रोटोकॉल के कार्यान्वयन में कोई त्रुटि है, तो इसे बाहर समतल किया जाता हैएक ही कोड बातचीत के दोनों किनारों पर काम करेगा। और दूसरी बात, कोड को बड़े संसाधनों के साथ एक प्लेटफ़ॉर्म पर डीबग किया जा सकता है, जो बहुत अधिक परिचित और सरल है।

आप कोडफ्रीज पर हमारे पहले पहले प्रदर्शनों में से एक वीडियो देखकर परियोजना के कठिन भाग्य के बारे में थोड़ा और जान सकते हैं ।

निष्कर्ष

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

PS खैर, हाँ, Embox न केवल "एम्बेडेड" है, बल्कि " ओपनसोर्स " भी है । तो, हम आपको इसमें भाग लेने के लिए परियोजना और पाठ्यक्रम का उपयोग करने के लिए आमंत्रित करते हैं!