RTOS या नहीं RTOS सवाल है

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

OS RV (RTOS) शब्द मार्केटिंग के क्षेत्र को दर्शाता है!

मैंने एक वैज्ञानिक तरीके से शुरू करने के लिए सोचा था, शर्तों की शुरूआत के साथ, लेकिन फैसला किया कि इस उत्तेजक थीसिस का सबसे अधिक स्वागत होगा। तो, मैं क्यों तर्क करता हूं कि RTOS (वास्तविक समय ऑपरेटिंग सिस्टम) शब्द मार्केटिंग को संदर्भित करता है, अधिक सटीक रूप से, एक विपणन (विज्ञापन) नारा है? सब कुछ सरल है। जब किसी उत्पाद का उत्पादन किया जाता है, तो उसे बेचा जाना चाहिए। लेकिन अगर आप सिर्फ ऑपरेटिंग सिस्टम को बेचने की कोशिश करेंगे, तो मुश्किलें पैदा होंगी। यह वह जगह है जहां बाजार की स्थिति बचाव के लिए आती है। उदाहरण के लिए, आप कह सकते हैं "हम उनसे तेज हैं।"


लेकिन आप इसके लिए अदालत जा सकते हैं! और वहां आपको सबूत देने की आवश्यकता होगी। लेकिन यह कैसे साबित करें कि आप सभी मामलों में तेज हैं? यह दौड़ने की प्रतियोगिता नहीं है। लेकिन निश्चित रूप से, इस तरह की पूरी तरह से सही प्रतियोगिता सामान्य बाजार की स्थिति से थोड़ा बाहर है।

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

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

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

वे कैसे प्राप्त होते हैं? इस प्रक्रिया का ईमानदारी से वर्णन किया गया है! यहां हम इस तरह के एक मॉडल समस्या, इस तरह के और एक हार्डवेयर प्लेटफॉर्म लेते हैं, और इसलिए प्रभाव लागू करते हैं। ठीक है, विपणन, ज़ाहिर है, सरल कर सकता है और बस बाहर दे सकता है, 1 μs का प्रतिक्रिया समय। लेकिन हम इसे ध्यान में नहीं रखते हैं, हम मानते हैं कि सब कुछ ईमानदारी से वर्णित है।

लेकिन मुझे माफ करना, अगर कोई और काम हो तो क्या होगा? 10 कार्य, 100 कार्य? और अगर एक नशे में प्रोग्रामर ताले को बाधित करता है? और अगर सिस्टम में प्रोग्रामर ने कार्यों को सही ढंग से प्राथमिकता नहीं दी है?

एक मामला था जब Embox ने वास्तविक समय के लिए परीक्षण पास किए। हमने बैठकर सोचा कि यह कैसे साबित किया जाए कि यह एक रियल-टाइम ऑपरेटिंग सिस्टम है। एक प्रयोगशाला है, एक ग्राहक है जो ऐसा चाहता है। हमें पता चलता है कि ग्राहक के लिए वास्तविक समय का मतलब सिस्टम का प्रतिक्रिया समय 1 μs है। मैं पूछता हूं कि क्या निम्नलिखित प्रयोग साक्ष्य होंगे:

• हम एक निश्चित हार्डवेयर प्लेटफ़ॉर्म लेते हैं
• GPIO इनपुट में से किसी एक पर सिग्नल लागू करें
• प्रोग्रामेटिक रूप से किसी ईवेंट को पकड़ें
• GPIO के आउटपुट पर, हम प्रोग्रामेटिक रूप से सिग्नल देते हैं
• माप एक आस्टसीलस्कप का उपयोग करके किया जाता है, प्रतिक्रिया समय इनपुट और आउटपुट मोर्चों के बीच का अंतर होगा।

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

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

"वास्तविक समय ऑपरेटिंग सिस्टम" शब्द की परिभाषा

अब मैं "रियल-टाइम ऑपरेटिंग सिस्टम" शब्द को पेश करूंगा। नहीं, मैं नहीं जीता। तथ्य यह है कि इस शब्द की बहुत सारी परिभाषाएँ हैं। मूल लेख पर कम से कम टिप्पणी लें:

वास्तविक समय प्रणालियों में, एक व्यक्ति आम तौर पर बहुत ही कमतर होता है और, तदनुसार, एक वास्तविक समय प्रणाली की गति की तुलना उन प्रक्रियाओं से की जानी चाहिए जो इसे नियंत्रित करती है, चाहे वह एक स्वायत्त कार हो या एक कारखाने में एक प्रक्रिया नियंत्रण प्रणाली।

SRV / RTOS - यह केवल महत्वपूर्ण घटनाओं की प्रतिक्रिया की भविष्यवाणी पर एक रैंकिंग है।

आरटीओएस एक ऐसा ओएस है जिसमें किसी कार्य की शुद्धता को न केवल तार्किक शुद्धता की विशेषता है, बल्कि उस समय तक यह कार्य पूरा हो जाता है।

किसी भी कार्य के संदर्भ को 1 μs प्रति 100 MHz प्रोसेसर पर स्विच करने के लिए मानदंड सेट करें जिसमें 0.1 μs के निर्धारण के साथ एक फ्लोट-पॉइंट कोप्रोसेसर होता है और सब कुछ जगह में गिर जाएगा।
आप स्पष्ट रूप से देखेंगे कि आरटीओएस कहां है और कहां नहीं।

खैर, मैं उस विचार को नजरअंदाज नहीं कर सकता, जिसके बारे में मैंने एक लेख में बात की थी, जिसे OSDAY सम्मेलनों में से एक में आवाज़ दी गई थी:

एक प्रणाली को एक वास्तविक वास्तविक समय प्रणाली माना जा सकता है यदि इसमें कोई स्थान नहीं है, जहां बंद रुकावटों के साथ, अज्ञात संख्या के पुनरावृत्तियों के साथ चक्र हैं।

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

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

एक अन्य प्रकार की वास्तविक समय प्रणाली एक नरम वास्तविक समय प्रणाली है, जिसमें एक सामयिक समय सीमा गायब है, जबकि वांछनीय नहीं है, स्वीकार्य है और किसी भी स्थायी नुकसान का कारण नहीं है। डिजिटल ऑडियो या मल्टीमीडिया सिस्टम इस श्रेणी में आते हैं। डिजिटल टेलीफोन भी सॉफ्ट-रियल-टाइम सिस्टम हैं।

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

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

लेकिन इस विवरण से यह केवल इस प्रकार है कि सिस्टम उन प्रणालियों में उपयोग किया जा सकता है जहां एक निश्चित अवधि के भीतर प्रतिक्रिया की अनुपस्थिति विनाशकारी परिणाम पैदा कर सकती है। खैर, एक प्रमुख पैरामीटर (प्रतिक्रिया समय से अधिक नहीं) प्राप्त करने के लिए, ओएस एक पुस्तकालय, ईकोस का उदाहरण हो सकता है।

वास्तविक समय की विशेषताओं को कैसे प्राप्त करें

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

आइए इस बारे में सोचें कि इसे कैसे प्राप्त किया जाए।

यह महत्वपूर्ण प्रणाली से सभी अनावश्यक को हटाने के लिए स्पष्ट होगा। एक सार्वभौमिक प्रणाली के स्थिर होने की संभावना नहीं है। यहां तक ​​कि कॉमरेड तेनबाम ने भी इस बारे में बात की, मेरा मतलब है, जब उन्होंने ईकोस के बारे में बात की।

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

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

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

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

भविष्यवाणी को बढ़ाने के तरीकों पर चर्चा जारी रखते हुए, मैं एक और टिप्पणी देना चाहता हूं

"आप एक रास्पबेरी पर वास्तविक समय प्राप्त कर सकते हैं, लेकिन आरटीओएस के साथ नहीं, बल्कि एक छोटी राज्य मशीन को अपने कैश में तोड़कर।"

यहां मैं निम्नलिखित बातों पर ध्यान देना चाहता हूं:

• सिस्टम से किसी भी आरटीओएस के बहिष्करण के कारण बढ़ी हुई भविष्यवाणी (वास्तविक समय गुण)
• एक राज्य मशीन द्वारा एक कार्यक्रम का प्रतिनिधित्व
• ठीक है, न केवल सॉफ्टवेयर के गुणों पर, बल्कि हार्डवेयर पर भी वास्तविक समय प्रणालियों की निर्भरता।

कोड की लाइनों की संख्या में कमी के मामले में अप्रत्याशितता की मात्रा में कमी के साथ, मुझे लगता है कि हर कोई इससे सहमत है। हालांकि, हमेशा की तरह, मैं सहमत नहीं हूं, लेकिन बाद में उस पर और अधिक।

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

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

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

क्या आरटीओएस बिल्कुल मौजूद है?

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

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

लेकिन हमें इसमें कोई संदेह नहीं है कि वास्तविक समय प्रणाली मौजूद है। और हां, आरटीओएस भी। यदि ऐसा नहीं होता, तो पहले उड़ने वाले कठफोड़वा सभ्यता को नष्ट कर देते, फिर एविओनिक्स, अंतरिक्ष यात्री, रोबोटिक्स, एसीएस-टीपी और बहुत कुछ नहीं होता।

कैसे स्थिति से बाहर निकलना है। यह बहुत सरल है, हालांकि सामान्य रूप से समस्या सबसे अधिक संभावना नहीं है, लेकिन एक विशिष्ट समस्या के लिए, प्रतिबंधों को लागू करना संभव है, जो किसी प्रकार की त्रुटि की संभावित संभावना के साथ इसे हल कर सकते हैं।

उदाहरण के लिए, मानकों को पेश किया जाता है: रीयलटाइम POSIX , ARINC-653 , ITRON । ये मानक, वास्तव में, उन कार्यों के एक वर्ग को अलग करते हैं जो इस मानक का पालन करने पर हल किए जा सकते हैं। या अध्ययन स्वतंत्र प्रयोगशालाओं द्वारा किया जाता है जो अध्ययन करते हैं कि क्या किसी विशेष ओएस के गुण लक्ष्य समस्या को हल करने के लिए उपयुक्त हैं।

तो Embox RTOS या RTOS नहीं?

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

PS इस लेखन के समय, कोई भी RTOS प्रभावित नहीं हुआ है।