c++ कहत अत्यधिक रेडियोधर्मी वातावरण में उपयोग के लिए एक आवेदन संकलन




रेडियो एक्टिविटी की खोज किसने की (19)

सॉफ्टवेयर / फर्मवेयर विकास और लघु उपग्रहों के पर्यावरण परीक्षण * के साथ लगभग 4-5 वर्षों के लिए काम करना, मैं यहां अपना अनुभव साझा करना चाहूंगा।

* ( छोटे उपग्रहों को अपने इलेक्ट्रॉनिक घटकों के लिए अपेक्षाकृत छोटे, सीमित आकारों के कारण बड़े उपग्रहों की तुलना में एकल इवेंट अपसेट होने का खतरा अधिक होता है )

बहुत संक्षिप्त और प्रत्यक्ष होने के लिए: सॉफ़्टवेयर / फ़र्मवेयर द्वारा स्वयं के बिना पता लगाने योग्य, गलत स्थिति से उबरने के लिए कोई तंत्र नहीं है, कम से कम, सॉफ़्टवेयर / फ़र्मवेयर के न्यूनतम कार्यशील संस्करण की एक प्रति कहीं न कहीं वसूली के उद्देश्य से - और हार्डवेयर का समर्थन करने के साथ वसूली (कार्यात्मक)।

अब, इस स्थिति को सामान्य रूप से हार्डवेयर और सॉफ्टवेयर स्तर दोनों में नियंत्रित किया जाता है। यहाँ, आप अनुरोध के रूप में, मैं सॉफ्टवेयर स्तर में हम क्या कर सकते हैं साझा करेंगे।

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

  2. ... न्यूनतम कार्यशील संस्करण ... अपने कोड में उत्तरदायी, एकाधिक प्रतियां, सॉफ़्टवेयर / फ़र्मवेयर का न्यूनतम संस्करण रखें। यह विंडोज में सेफ मोड की तरह है। आपके सॉफ़्टवेयर का केवल एक ही, पूरी तरह कार्यात्मक संस्करण होने के बजाय, आपके सॉफ़्टवेयर / फर्मवेयर के न्यूनतम संस्करण की कई प्रतियां हैं। न्यूनतम प्रति आमतौर पर पूर्ण प्रति की तुलना में बहुत कम आकार की होती है और लगभग हमेशा केवल निम्नलिखित दो या तीन विशेषताएं होती हैं:

    1. बाहरी सिस्टम से कमांड सुनने में सक्षम,
    2. वर्तमान सॉफ्टवेयर / फर्मवेयर को अपडेट करने में सक्षम,
    3. बुनियादी ऑपरेशन के हाउसकीपिंग डेटा की निगरानी करने में सक्षम।
  3. ... कॉपी ... कहीं ... अनावश्यक सॉफ्टवेयर / फर्मवेयर कहीं है।

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

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

    2. लेकिन अगर आप ऐसा नहीं कर रहे हैं, तो आपके पास अपने बाहरी सिस्टम में कम से कम एक कॉपी होनी चाहिए जो डिवाइस के संपर्क में आ सकती है और सॉफ़्टवेयर / फ़र्मवेयर को अपडेट कर सकती है (सैटेलाइट केस में, यह फिर से मिशन कंट्रोल सेंटर है)।

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

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

एक घटना से परेशान फर्मवेयर की त्रुटि के लिए ऊपर दिए गए सुझाव के अलावा, एक घटना से परेशान होना चाहूंगा, मैं आपको सुझाव देना चाहूंगा:

  1. अंतर-सबसिस्टम संचार प्रोटोकॉल में त्रुटि का पता लगाने और / या त्रुटि सुधार एल्गोरिथ्म। अन्य प्रणाली से प्राप्त अपूर्ण / गलत संकेतों से बचने के लिए यह लगभग एक और होना चाहिए

  2. अपने एडीसी रीडिंग में फ़िल्टर करें। सीधे एडीसी पढ़ने का उपयोग करें। इसे माध्यिका फ़िल्टर, माध्य फ़िल्टर या किसी अन्य फ़िल्टर द्वारा फ़िल्टर करें - कभी भी एकल रीडिंग मान पर भरोसा न करें नमूना अधिक, कम नहीं - यथोचित।

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

क्या हम अपने कोड में बदलाव कर सकते हैं, या एकल घटना अपघटन के कारण होने वाली नरम त्रुटियों और स्मृति-भ्रष्टाचार की पहचान करने के लिए किए जाने वाले संकलन-समय में सुधार कर सकते हैं? क्या किसी अन्य डेवलपर्स को लंबे समय से चल रहे एप्लिकेशन पर नरम त्रुटियों के हानिकारक प्रभावों को कम करने में सफलता मिली?


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

उत्तर आमतौर पर स्वचालित इकाई परीक्षण है। परीक्षण हार्नेस लिखें जो विकास प्रणाली पर कोड का उपयोग करते हैं, फिर लक्ष्य प्रणाली पर समान परीक्षण हार्नेस चलाते हैं। मतभेदों के लिए देखो!

अपने एम्बेडेड डिवाइस पर इरेटा के लिए भी जाँच करें। आपको लग सकता है कि "ऐसा न करें क्योंकि यह दुर्घटनाग्रस्त हो जाएगा, इसलिए कंपाइलर विकल्प और कंपाइलर इसके आसपास काम करेंगे"।

संक्षेप में, आपके कोड में क्रैश का सबसे संभावित स्रोत बग है। जब तक आप यह सुनिश्चित नहीं कर लेते हैं कि यह मामला नहीं है, तब तक चिंता न करें (अभी तक) अधिक गूढ़ विफलता मोड के बारे में।


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


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


आप जो पूछते हैं वह काफी जटिल विषय है - आसानी से जवाबदेह नहीं है। अन्य उत्तर ठीक हैं, लेकिन उन्होंने उन सभी चीजों का एक छोटा सा हिस्सा कवर किया है जो आपको करने की ज़रूरत है।

जैसा कि टिप्पणियों में देखा गया है , हार्डवेयर समस्याओं को 100% ठीक करना संभव नहीं है, हालांकि उच्च प्रोबिली के साथ संभव है कि वे अपनी तकनीकों का उपयोग करके उन्हें कम या पकड़ सकें।

यदि मैं आप होता, तो मैं उच्चतम सुरक्षा अखंडता स्तर स्तर (एसआईएल -4) का सॉफ्टवेयर बनाता । IEC 61513 दस्तावेज़ (परमाणु उद्योग के लिए) प्राप्त करें और इसका पालन करें।


रेडियोधर्मी वातावरण के लिए कोड लिखना वास्तव में किसी भी मिशन-महत्वपूर्ण एप्लिकेशन के लिए कोड लिखने से अलग नहीं है।

पहले से ही उल्लेख किया गया है के अलावा, यहाँ कुछ विविध सुझाव दिए गए हैं:

  • हर रोज़ "रोटी और मक्खन" सुरक्षा उपायों का उपयोग करें जो किसी भी अर्ध-पेशेवर एम्बेडेड सिस्टम पर मौजूद होना चाहिए: आंतरिक प्रहरी, आंतरिक कम वोल्टेज का पता लगाने, आंतरिक घड़ी की निगरानी। वर्ष 2016 में इन बातों का उल्लेख भी नहीं किया जाना चाहिए और वे हर आधुनिक माइक्रोकंट्रोलर पर बहुत अधिक मानक हैं।
  • यदि आपके पास एक सुरक्षा और / या मोटर वाहन-उन्मुख MCU है, तो इसमें कुछ वॉचडॉग विशेषताएं होंगी, जैसे कि एक निश्चित समय विंडो, जिसके अंदर आपको वॉचडॉग को ताज़ा करने की आवश्यकता है। यह पसंद किया जाता है यदि आपके पास एक मिशन-महत्वपूर्ण वास्तविक समय प्रणाली है।
  • सामान्य तौर पर, इस तरह के सिस्टम के लिए उपयुक्त MCU का उपयोग करें, न कि कॉर्न फ़्लेक्स के पैकेट में प्राप्त कुछ सामान्य मुख्यधारा फ़्लॉफ़। लगभग हर MCU निर्माता आजकल विशिष्ट अनुप्रयोगों (TI, Freescale, Renesas, ST, Infineon आदि) के लिए डिज़ाइन किए गए MCUs हैं। इनमें बहुत सारी अंतर्निहित सुरक्षा विशेषताएं हैं, जिनमें लॉक-स्टेप कोर शामिल हैं: जिसका अर्थ है कि एक ही कोड को निष्पादित करने वाले 2 सीपीयू कोर हैं, और उन्हें एक दूसरे के साथ सहमत होना चाहिए।
  • महत्वपूर्ण: आपको आंतरिक MCU रजिस्टरों की अखंडता सुनिश्चित करनी चाहिए। हार्डवेयर बाह्य उपकरणों के सभी नियंत्रण और स्थिति रजिस्टर जो कि रैम करने योग्य हैं, रैम मेमोरी में स्थित हो सकते हैं, और इसलिए कमजोर होते हैं।

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

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

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

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

    उच्च गुणवत्ता वाला मिशन-क्रिटिकल फ़र्मवेयर, यथासंभव त्रुटियों का पता लगाता है, और फिर उन्हें सुरक्षित तरीके से अनदेखा करता है।

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

    व्यवहार में इसका मतलब यह है कि यदि फ़ाइल चर पर या static रूप में एक चर घोषित किया जाता है, तो आपको इसे आरंभ करने के लिए = का उपयोग कभी नहीं करना चाहिए (या आप कर सकते हैं, लेकिन यह व्यर्थ है, क्योंकि आप किसी भी तरह से मूल्य पर भरोसा नहीं कर सकते हैं)। हमेशा इस्तेमाल से पहले इसे रन-टाइम में सेट करें। यदि एनवीएम से ऐसे चर को बार-बार अपडेट करना संभव है, तो ऐसा करें।

    सी ++ में इसी तरह, स्थिर भंडारण अवधि चर के लिए कंस्ट्रक्टरों पर भरोसा न करें। कंस्ट्रक्टर (ओं) को एक सार्वजनिक "सेट-अप" दिनचर्या कहें, जिसे आप कॉल-अप एप्लिकेशन से सीधे रन-टाइम में भी कॉल कर सकते हैं।

    यदि संभव हो, तो "कॉपी-डाउन" स्टार्ट-अप कोड को हटा दें जो कि .bss और .bss (और C ++ कंस्ट्रक्टर्स को कॉल करता है) को पूरी तरह से इनिशियलाइज़ करता है, ताकि अगर आप कोड को ऐसे लिखते हैं, तो आपको लिंकर एरर मिलते हैं। कई कंपाइलरों के पास इसे छोड़ने का विकल्प होता है, जिसे आमतौर पर "न्यूनतम / तेज़ स्टार्ट-अप" या समान कहा जाता है।

    इसका मतलब यह है कि किसी भी बाहरी पुस्तकालयों की जाँच की जानी चाहिए ताकि उनमें ऐसी कोई निर्भरता न हो।

  • कार्यक्रम के लिए एक सुरक्षित स्थिति को लागू करें और परिभाषित करें, जहां आप महत्वपूर्ण त्रुटियों के मामले में वापस आ जाएंगे।

  • त्रुटि रिपोर्ट / त्रुटि लॉग सिस्टम को लागू करना हमेशा मददगार होता है।

नासा के पास विकिरण-कठोर सॉफ़्टवेयर पर एक पेपर है । यह तीन मुख्य कार्यों का वर्णन करता है:

  1. त्रुटियों के लिए स्मृति की नियमित निगरानी करना और फिर उन त्रुटियों को साफ़ करना,
  2. मजबूत त्रुटि वसूली तंत्र, और
  3. अगर कुछ अब काम नहीं करता है तो पुन: कॉन्फ़िगर करने की क्षमता।

ध्यान दें कि मेमोरी स्कैन की दर लगातार पर्याप्त होनी चाहिए कि बहु-बिट त्रुटियां शायद ही कभी होती हैं, क्योंकि अधिकांश ECC मेमोरी एकल-बिट त्रुटियों से उबर सकती है, न कि बहु-बिट त्रुटियां।

मजबूत त्रुटि रिकवरी में नियंत्रण प्रवाह स्थानांतरण (आमतौर पर त्रुटि से पहले एक बिंदु पर प्रक्रिया को पुनरारंभ करना), संसाधन जारी करना और डेटा बहाली शामिल है।

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

वे C ++ जैसी ऑब्जेक्ट-ओरिएंटेड भाषाओं के लिए विशेष रूप से उपयुक्त तकनीकों पर चर्चा करते हैं। उदाहरण के लिए

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

और, यह सिर्फ इतना होता है, नासा ने मंगल रोवर जैसी बड़ी परियोजनाओं के लिए C ++ का उपयोग किया है।

C ++ क्लास एब्स्ट्रक्शन और इनकैप्सुलेशन ने कई प्रोजेक्ट्स और डेवलपर्स के बीच तेजी से विकास और परीक्षण को सक्षम किया।

उन्होंने कुछ सी ++ सुविधाओं से परहेज किया जो समस्याएं पैदा कर सकते हैं:

  1. अपवाद
  2. टेम्पलेट्स
  3. Iostream (कोई कंसोल नहीं)
  4. एकाधिक वंशानुक्रम
  5. ऑपरेटर ओवरलोडिंग ( new और delete )
  6. डायनेमिक एलोकेशन (सिस्टम हीप भ्रष्टाचार की संभावना से बचने के लिए एक समर्पित मेमोरी पूल और प्लेसमेंट new इस्तेमाल किया गया)।

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

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

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

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

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


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

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

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


शायद यह जानने में मदद मिलेगी कि हार्डवेयर का अर्थ "इस वातावरण के लिए डिज़ाइन किया गया" है। यह SEU त्रुटियों की उपस्थिति को कैसे सही और / या इंगित करता है?

एक अंतरिक्ष अन्वेषण से संबंधित परियोजना में, हमारे पास एक कस्टम MCU था, जो SEU त्रुटियों पर एक अपवाद / रुकावट को बढ़ाएगा, लेकिन कुछ देरी के साथ, यानी एक cn अपवाद का कारण बनने वाले एक इंसुलेशन के बाद कुछ चक्र बीत सकते हैं / निर्देश निष्पादित किए जा सकते हैं।

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

हमने खतरनाक (पुनः आरंभ करने योग्य नहीं) अनुक्रमों की पहचान की (जैसे lw $3, 0x0($2) , एक इन्सान द्वारा अनुसरण किया जाता है, जो संशोधित होता है $2 और डेटा-निर्भर नहीं होता है $3 ), और मैंने जीसीसी में संशोधन किए हैं, इसलिए इस तरह के अनुक्रम नहीं होते हैं (जैसे कि अंतिम उपाय के रूप में, अलग करना दो इंसां द्वारा a nop )।

बस कुछ विचार करने के लिए ...


कैसे अपने आवेदन के कई उदाहरणों को चलाने के बारे में। यदि क्रैश यादृच्छिक मेमोरी बिट परिवर्तनों के कारण होते हैं, तो संभावना है कि आपके कुछ ऐप इंस्टेंसेस इसे सटीक परिणाम देंगे। यह संभवतः काफी आसान है (सांख्यिकीय पृष्ठभूमि वाले किसी व्यक्ति के लिए) यह गणना करने के लिए कि आपको अपनी इच्छा के अनुसार छोटे समग्र त्रुटि प्राप्त करने के लिए कितने फ्लॉप संभावना की आवश्यकता है।


क्या आप एक watchdog है मदद कर सकता है। 1980 के दशक में औद्योगिक कंप्यूटिंग में वॉचडॉग का बड़े पैमाने पर उपयोग किया गया था। हार्डवेयर विफलताएं तब बहुत अधिक सामान्य थीं - एक अन्य उत्तर भी उस अवधि को संदर्भित करता है।

एक वॉचडॉग एक संयुक्त हार्डवेयर / सॉफ्टवेयर सुविधा है। हार्डवेयर एक साधारण काउंटर है जो एक संख्या (1023) को शून्य से नीचे गिना जाता है। TTL या अन्य तर्क का उपयोग किया जा सकता है।

सॉफ्टवेयर को इस तरह से डिजाइन किया गया है कि एक रूटीन सभी आवश्यक प्रणालियों के सही संचालन की निगरानी करता है। यदि यह रूटीन सही तरीके से पूरा होता है = कंप्यूटर ठीक चलता है, तो यह काउंटर को 1023 पर सेट करता है।

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

यह वॉचडॉग सुनिश्चित करता है कि संलग्न कंप्यूटर को विफलता के कई मामलों में पुनः आरंभ किया गया है। मुझे यह स्वीकार करना चाहिए कि मैं हार्डवेयर से परिचित नहीं हूं जो कि आज के कंप्यूटरों पर इस तरह के कार्य को करने में सक्षम है। बाहरी हार्डवेयर के लिए इंटरफेस अब एक बहुत अधिक जटिल है जितना वे हुआ करते थे।

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


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

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

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


यह उत्तर मानता है कि आप एक ऐसी प्रणाली के साथ संबंध रखते हैं जो एक ऐसी प्रणाली है जो न्यूनतम लागत या तेज है; रेडियोधर्मी चीजों के साथ खेलने वाले अधिकांश लोग गति / लागत पर शुद्धता / सुरक्षा को महत्व देते हैं

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

यहाँ कुछ विचार हैं:

  • सुनिश्चित करें कि आपका पूरा हार्डवेयर n बार दोहराया गया है (जहाँ n 2 से अधिक है, और अधिमानतः विषम है), और यह कि प्रत्येक हार्डवेयर तत्व एक दूसरे हार्डवेयर तत्व के साथ संचार कर सकता है। ईथरनेट ऐसा करने का एक स्पष्ट तरीका है, लेकिन कई अन्य सरल मार्ग हैं जो बेहतर सुरक्षा देंगे (उदाहरण के लिए CAN)। सामान्य घटकों (यहां तक ​​कि बिजली की आपूर्ति) को कम से कम करें। इसका मतलब हो सकता है कि उदाहरण के लिए कई स्थानों पर एडीसी इनपुट का नमूना लिया जाए।

  • सुनिश्चित करें कि आपका आवेदन राज्य एक ही स्थान पर है, उदाहरण के लिए एक परिमित राज्य मशीन में। यह पूरी तरह से रैम आधारित हो सकता है, हालांकि स्थिर भंडारण को रोकता नहीं है। इस प्रकार यह कई जगह संग्रहीत किया जाएगा।

  • राज्य के परिवर्तनों के लिए एक कोरम प्रोटोकॉल को अपनाएं। उदाहरण के लिए RAFT देखें। जैसा कि आप C ++ में काम कर रहे हैं, इसके लिए अच्छी तरह से ज्ञात लाइब्रेरी हैं। FSM में परिवर्तन केवल तभी किया जाएगा जब अधिकांश नोड्स सहमत हों। प्रोटोकॉल स्टैक और कोरम प्रोटोकॉल के लिए अपने आप को रोल करने के बजाय एक ज्ञात अच्छे पुस्तकालय का उपयोग करें, या अतिरेक पर आपके सभी अच्छे काम तब बर्बाद हो जाएंगे जब कोरम प्रोटोकॉल लटका हुआ है।

  • सुनिश्चित करें कि आप अपने FSM को चेकसम (जैसे CRC / SHA), और FSM में ही CRC / SHA को स्टोर करें (साथ ही मैसेज को ट्रांसमिट करने के साथ-साथ मैसेजेस को खुद भी चेक करें)। नियमित रूप से इन चेकसम, चेकसम आने वाले संदेशों के खिलाफ अपने एफएसएम की जांच करने के लिए नोड्स प्राप्त करें, और उनके चेकसम को कोरम के चेकसम से मेल खाते हैं।

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

  • आप का समर्थन करने के लिए हार्डवेयर का उपयोग करें, लेकिन इतनी सावधानी से करें। उदाहरण के लिए, आप ईसीसी रैम प्राप्त कर सकते हैं, और ईसीसी त्रुटियों को ठीक करने के लिए इसके माध्यम से नियमित रूप से पढ़ / लिख सकते हैं (और यदि त्रुटि ठीक नहीं है तो घबराएं)। हालाँकि (मेमोरी से) स्टैटिक रैम DRAM की तुलना में आयनीकृत विकिरण के लिए अधिक सहिष्णु होता है, इसलिए इसके बजाय स्टैटिक DRAM का उपयोग करना बेहतर हो सकता है। 'मैं जो कुछ नहीं करूँगा' के तहत पहला बिंदु देखें।

मान लीजिए कि आपके पास एक दिन के भीतर किसी भी दिए गए नोड की विफलता का 1% मौका है, और आइए दिखाते हैं कि आप विफलताओं को पूरी तरह से स्वतंत्र बना सकते हैं। 5 नोड्स के साथ, आपको एक दिन में विफल होने के लिए तीन की आवश्यकता होगी, जो कि .00001% मौका है। अधिक, अच्छी तरह से, आप विचार प्राप्त करते हैं।

चीजें जो मैं नहीं करूंगा:

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

  • अपने स्वयं के एल्गोरिदम को रोल करें । लोग यह सामान पहले भी कर चुके हैं। उनके काम का उपयोग करें। दोष सहिष्णुता और वितरित एल्गोरिदम कठिन हैं। जहां संभव हो, अन्य लोगों के काम का उपयोग करें।

  • भोली आशा में जटिल संकलक सेटिंग्स का उपयोग करें आप अधिक विफलताओं का पता लगाते हैं। यदि आप भाग्यशाली हैं, तो आप अधिक विफलताओं का पता लगा सकते हैं। अधिक संभावना है, आप संकलक के भीतर एक कोड-पथ का उपयोग करेंगे, जिसे कम परीक्षण किया गया है, खासकर यदि आपने इसे स्वयं रोल किया है।

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


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

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

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


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

उपयोग करने के बजाय uint32_t (और double , int64_t आदि), अपना खुद का बनाएं SAFE_uint32_t जिसमें uint32_t का एक बहु (न्यूनतम 3) होता है। उन सभी ऑपरेशनों को ओवरलोड करें जो आप चाहते हैं (* + - / << >> = ==! = आदि), प्रदर्शन करने के लिए, और प्रत्येक आंतरिक मूल्य पर ओवरलोड किए गए संचालन को स्वतंत्र रूप से करें, अर्थात एक बार ऐसा न करें और परिणाम की प्रतिलिपि बनाएँ। पहले और बाद में, दोनों देखें कि सभी आंतरिक मान मेल खाते हैं। यदि मान मेल नहीं खाते हैं, तो आप गलत को सबसे आम के साथ मान में अपडेट कर सकते हैं। यदि कोई सबसे आम मूल्य नहीं है, तो आप सुरक्षित रूप से सूचित कर सकते हैं कि कोई त्रुटि है।

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

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


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

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

  • अतिरेक के साथ वैरिएबल स्टोर करें । यदि आपके पास एक महत्वपूर्ण चर x , तो इसका मान x1 , x2 और x3 में लिखें और इसे (x1 == x2) ? x2 : x3 रूप में पढ़ें (x1 == x2) ? x2 : x3 (x1 == x2) ? x2 : x3

  • कार्यक्रम प्रवाह निगरानी लागू करें। मुख्य पाश से बुलाए गए महत्वपूर्ण कार्यों / शाखाओं में एक अद्वितीय मूल्य के साथ एक वैश्विक ध्वज XOR। लगभग 100% परीक्षण कवरेज के साथ विकिरण रहित वातावरण में कार्यक्रम चलाना आपको चक्र के अंत में ध्वज के स्वीकार्य मूल्यों की सूची प्रदान करना चाहिए। यदि आप विचलन देखते हैं तो रीसेट करें।

  • स्टैक पॉइंटर की निगरानी करें । मुख्य लूप की शुरुआत में, स्टैक पॉइंटर की उसके अपेक्षित मूल्य के साथ तुलना करें। विचलन पर रीसेट करें।


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

वॉचडॉग अवधारणा के समान ही समय सीमा है। किसी फ़ंक्शन को कॉल करने से पहले एक हार्डवेयर टाइमर प्रारंभ करें। यदि फ़ंक्शन समय सीमा टाइमर से पहले वापस नहीं आता है, तो स्टैक को फिर से लोड करें और फिर से प्रयास करें। यदि यह 3/5 के बाद भी विफल रहता है, तो आपको ROM से पुनः लोड करने की आवश्यकता है।

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

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


यहां बड़ी मात्रा में उत्तर दिए गए हैं, लेकिन मैं इस बारे में अपने विचारों को समेटने की कोशिश करूंगा।

कुछ क्रैश या सही तरीके से काम नहीं करना आपकी अपनी गलतियों का परिणाम हो सकता है - तब समस्या का पता लगाने पर इसे आसानी से ठीक करना चाहिए। लेकिन हार्डवेयर के विफल होने की भी संभावना है - और यह मुश्किल है अगर समग्र रूप से ठीक करना असंभव नहीं है।

मैं पहले समस्याग्रस्त स्थिति को लॉग (स्टैक, रजिस्टर, फंक्शन कॉल) द्वारा पकड़ने की कोशिश करने की सलाह दूंगा - या तो उन्हें फ़ाइल में कहीं लॉग इन करके, या उन्हें किसी तरह सीधे ट्रांसमिट करके ("अरे नहीं - मैं क्रैश हो रहा हूं")।

ऐसी त्रुटि स्थिति से पुनर्प्राप्ति या तो रिबूट है (यदि सॉफ़्टवेयर अभी भी जीवित है और किकिंग कर रहा है) या हार्डवेयर रीसेट (जैसे hw watchdogs)। पहले से शुरू करना आसान।

यदि समस्या हार्डवेयर से संबंधित है - तो लॉगिंग से आपको यह पहचानने में मदद मिलेगी कि कौन सी फ़ंक्शन कॉल समस्या होती है और यह आपको जानकारी दे सकती है कि क्या काम नहीं कर रहा है और कहां है।

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

यदि समस्या कुछ समय बाद होती है - तो स्टैक ओवरफ्लो पर संदेह किया जा सकता है - फिर स्टैक पॉइंट रजिस्टरों की निगरानी करना बेहतर होता है - अगर वे लगातार बढ़ते हैं।

और यदि आप "हैलो वर्ल्ड" एप्लिकेशन के प्रकार तक अपने कोड को पूरी तरह से कम करने का प्रबंधन करते हैं - और यह अभी भी बेतरतीब ढंग से विफल हो रहा है - तो हार्डवेयर समस्याओं की उम्मीद की जाती है - और "हार्डवेयर अपग्रेड" होने की आवश्यकता है - मतलब ऐसे सीपीयू / रैम का आविष्कार करें / ... -हार्डवेयर संयोजन जो विकिरण को बेहतर ढंग से सहन करेगा।

सबसे महत्वपूर्ण बात यह है कि अगर मशीन पूरी तरह से बंद / रीसेट हो जाती है या काम नहीं करती है तो आप अपने लॉग को कैसे प्राप्त कर सकते हैं - शायद पहली बात बूटस्टैप को करना चाहिए - समस्याग्रस्त स्थिति में प्रवेश करने पर एक हेड बैक होम है।

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





fault-tolerance