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

1456

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

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

— कौआ
स्रोत

186

स्मृति में मान बदल रहे हैं या प्रोसेसर में मूल्य बदल रहे हैं? यदि हार्डवेयर पर्यावरण के लिए डिज़ाइन किया गया है, तो सॉफ्टवेयर को ऐसे चलना चाहिए जैसे कि गैर-रेडियोधर्मी वातावरण में चल रहा हो।

— थॉमस मैथ्यूज

3

यदि संभव हो, तो आपको एक लॉगिंग सिस्टम सेट करना चाहिए जो गैर-वाष्पशील मेमोरी में घटनाओं को संग्रहीत करता है जो विकिरण के लिए प्रतिरोधी है। पर्याप्त जानकारी संग्रहीत करें ताकि आप घटना का पता लगा सकें और आसानी से मूल कारण जान सकें।

— थॉमस मैथ्यूज

2

@ थोमस मैथ्यूज सभी मेमोरी में एक FIT त्रुटि दर है, और हार्डवेयर बनाती है बहुत सारे वादे करते हैं। अधिकांश मुद्दों की संभावना एसईयू द्वारा रनटाइम पर राम को संशोधित करने के कारण होती है।

— किश्ती

9

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

— mbrig

5

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

— jwdonahue

814

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

* ( अपने छोटे घटकों के कारण छोटे उपग्रहों की तुलना में छोटे उपग्रहों की तुलना में लघु-उपग्रहों में बहुत अधिक घटना होने की संभावना होती है )

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

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

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

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

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

— इयान
स्रोत

401

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

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

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

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

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

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

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

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

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

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

अपवाद
टेम्पलेट्स
Iostream (कोई कंसोल नहीं)
एकाधिक वंशानुक्रम
ऑपरेटर ओवरलोडिंग (के अलावा newऔर delete)
डायनेमिक एलोकेशन ( newसिस्टम हीप भ्रष्टाचार की संभावना से बचने के लिए एक समर्पित मेमोरी पूल और प्लेसमेंट का उपयोग किया जाता है )।

— rsjaffe
स्रोत

28

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

— PyRulez

20

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

— लुआण

67

@PyRulez: शुद्ध भाषा एक अमूर्तन है, हार्डवेयर शुद्ध नहीं है। कंपाइलर अंतर को छिपाने में काफी अच्छे हैं। यदि आपके प्रोग्राम का कोई ऐसा मान है जो चरण X के बाद तार्किक रूप से उपयोग नहीं करना चाहिए, तो कंपाइलर इसे मान के साथ अधिलेखित कर सकता है जिसकी गणना चरण X + 1 में की जाती है। लेकिन इसका मतलब यह है कि आप वापस नहीं जा सकते। अधिक औपचारिक रूप से, एक शुद्ध भाषा में एक कार्यक्रम के संभावित राज्य एक चक्रीय ग्राफ बनाते हैं, जिसका अर्थ है कि दो राज्य समान हैं और दोनों में से पहुंचने वाले राज्यों को बराबर होने पर विलय किया जा सकता है। यह विलय उन राज्यों में जाने वाले रास्तों के अंतर को नष्ट कर देता है।

— MSalters

2

@Vorac - प्रस्तुति के अनुसार C ++ टेम्प्लेट के साथ चिंता कोड ब्लोट है।

— jww

3

@DeerSpotter सटीक समस्या इससे कहीं अधिक बड़ी है। Ionization आपके रनिंग वॉचर प्रोग्राम के बिट्स को नुकसान पहुंचा सकता है। फिर आपको एक द्रष्टा के द्रष्टा की आवश्यकता होगी, फिर - एक द्रष्टा के द्रष्टा के द्रष्टा और इतने पर ...

— अग्निस वसीलियास्कस

116

यहाँ कुछ विचार और विचार दिए गए हैं:

ROM का अधिक रचनात्मक रूप से उपयोग करें।

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

स्टैक के लिए अपनी सर्वश्रेष्ठ रैम का उपयोग करें।

स्टैक में एसईयू संभवतः दुर्घटनाओं का सबसे संभावित स्रोत है, क्योंकि यह वह जगह है जहां सूचकांक चर, स्थिति चर, वापसी पते और विभिन्न प्रकार के संकेत आमतौर पर रहते हैं।

टाइमर-टिक और वॉचडॉग टाइमर दिनचर्या को लागू करें।

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

सॉफ़्टवेयर में त्रुटि-सुधार-कोड लागू करें ।

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

कैश को याद रखें।

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

पृष्ठ-दोष संचालकों का चतुराई से उपयोग करें।

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

महत्वपूर्ण चीजों (जो सब कुछ हो सकता है) के लिए विधानसभा भाषा का उपयोग करें।

असेंबली लैंग्वेज के साथ, आप जानते हैं कि रजिस्टर में क्या है और रैम में क्या है; आप जानते हैं कि CPU किस विशेष रैम तालिकाओं का उपयोग कर रहा है, और आप अपने जोखिम को कम रखने के लिए गोल चक्कर में चीजों को डिज़ाइन कर सकते हैं।

objdumpवास्तव में उत्पन्न असेंबली भाषा को देखने के लिए उपयोग करें , और यह निर्धारित करें कि आपकी प्रत्येक दिनचर्या में कितना कोड है।

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

याद रखें कि यह संभावनाओं का खेल है।

एक टिप्पणीकार ने कहा

त्रुटियों को पकड़ने के लिए आप जो भी दिनचर्या लिखते हैं, वह उसी कारण से स्वयं विफल हो जाएगी।

हालांकि यह सही है, चेक बाइट के लिए कोड और डेटा के 100 बाइट्स में त्रुटियों की संभावना सही ढंग से कार्य करने के लिए आवश्यक है, अन्यत्र त्रुटियों की संभावना से बहुत छोटा है। यदि आपकी ROM बहुत विश्वसनीय है और लगभग सभी कोड / डेटा वास्तव में ROM में हैं तो आपके अंतर और भी बेहतर हैं।

निरर्थक हार्डवेयर का उपयोग करें।

समान कोड वाले 2 या अधिक समान हार्डवेयर सेटअप का उपयोग करें। यदि परिणाम भिन्न होते हैं, तो एक रीसेट चालू होना चाहिए। 3 या अधिक उपकरणों के साथ आप "वोटिंग" प्रणाली का उपयोग करके यह पहचानने का प्रयास कर सकते हैं कि किसके साथ समझौता किया गया है।

— Artelius
स्रोत

14

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

— लंडिन

23

कहीं न कहीं मेरे दिमाग के पीछे एविओनिक्स (शायद स्पेस शटल?) फ्लाइट हार्डवेयर का संदर्भ है जहां निरर्थक आर्किटेक्चर को स्पष्ट रूप से समान (और विभिन्न टीमों द्वारा) नहीं होने के लिए डिज़ाइन किया गया था। ऐसा करना हार्डवेयर / सॉफ़्टवेयर डिज़ाइन में एक प्रणालीगत त्रुटि की संभावना को कम करता है, एक ही इनपुट के साथ सामना करने पर एक ही समय में सभी मतदान प्रणालियों के दुर्घटनाग्रस्त होने की संभावना को कम करता है।

— पीटर एम।

8

@PeterM: AFAIK ने बोइंग 777 के लिए उड़ान सॉफ्टवेयर के लिए भी दावा किया है: तीन प्रोग्रामिंग भाषाओं में तीन टीमों द्वारा तीन संस्करण।

— मोनिका को बहाल करना - एम। श्रोडर

7

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

— नानोफारड

7

@DanEsparza: कई प्रकार की ROM यादें हैं। यदि "ROM" का अनुकरण eeprom या फ़्लैश पर आसानी से-5v पर-प्रोग्राम करने योग्य at-10v से किया जाता है, तो वास्तव में "ROM" अभी भी आयनीकरण की संभावना है। शायद दूसरों से कम। हालांकि, अच्छे रोम के कट्टर चीजें हैं जैसे मास्क रोम या फ्यूज-आधारित PROM जो मुझे लगता है कि असफल होने के लिए विकिरण की वास्तव में गंभीर मात्रा की आवश्यकता होगी। मैं नहीं जानता कि क्या अभी भी निर्मित हैं।

— quetzalcoatl

105

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

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

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

— एरिक टावर्स
स्रोत

5

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

— किश्ती

40

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

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

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

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

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

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

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

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

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

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

— लुंडिन
स्रोत

बूलियंस को दूषित होने से निपटने का एक तरीका (जैसा आपके उदाहरण लिंक में है) एक सीमा के साथ उपयोग TRUEकरने के बराबर हो सकता है । 0xffffffffPOPCNT

— wizzwizz4

@ wizzwizz4 यह देखते हुए कि मान 0x गैर-प्रोग्राम फ्लैश सेल का डिफ़ॉल्ट मान है, जो एक बुरे विचार की तरह लगता है।

— लंडिन

%01010101010101010101010101010101, XOR फिर POPCNT?

— wizzwizz4

1

@ wizzwizz4 या केवल मान 0x1, जैसा कि सी मानक द्वारा आवश्यक है।

— लंडिन

1

@ wizzwizz4 आप उपर्युक्त विधियों (ईसीसी, सीआरसी आदि) में से कुछ या सभी का उपयोग क्यों करते हैं। अन्यथा कॉस्मिक किरण आपके .textसेक्शन में एक समान कोड या समान कोड को बदलने के साथ-साथ सिंगल बिट को भी फ्लिप कर सकती है ।

— लुंडिन

34

ऐसे परिवेशों में दृढ़ता से व्यवहार करने वाले कार्यक्रमों को लिखने के लिए सी का उपयोग करना संभव हो सकता है, लेकिन केवल अगर कंपाइलर अनुकूलन के अधिकांश रूप अक्षम हैं। ऑप्टिमाइज़िंग कंपाइलर को कई अधिक प्रतीत होने वाले-निरूपण कोडिंग पैटर्न को "अधिक कुशल" लोगों के साथ बदलने के लिए डिज़ाइन किया गया है, और ऐसा कोई सुराग नहीं हो सकता है कि 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()अनुचित तरीके से कोड तक पहुंचने का कारण बनता है , लेकिन बाद में कोई गड़बड़ घटना नहीं होती है, तो कोड के लिए कोई तरीका नहीं होगा, जिसके बाद trigger_activation()सत्यापन सत्यापन के माध्यम से पारित किए बिना या रद्द करने के लिए कॉल किया जाएगा। तुरंत पहलेtrigger_activation()उस संदर्भ के बाद जिसे prepare_for_activation()रिटर्न कहा जाता है, लेकिन कॉल के cancel_preparations()बीच कॉल होने की संभावना होती है , इस प्रकार बाद की कॉल हानिरहित होती है।prepare_for_activation() औरtrigger_activation()

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

— supercat
स्रोत

6

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

— लेउशेंको

24

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

— मसलक

27

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

— MSalters 14

15

फिर भी -O0एक बुरा विचार क्यों एक और कारण है: यह एक रजिस्टर में मेमोरी में वेरिएबल्स को स्टोर करने के लिए जाता है। अब यह निश्चित नहीं है कि मेमोरी एसईयू के लिए अतिसंवेदनशील है, लेकिन उड़ान में डेटा बाकी डेटा की तुलना में अधिक अतिसंवेदनशील है। बेकार डेटा आंदोलन से बचा जाना चाहिए, और -O2वहां मदद करता है।

— मसलक

9

@MSalters: क्या महत्वपूर्ण है कि डेटा विघटन के लिए प्रतिरक्षा नहीं है, बल्कि यह है कि प्रणाली एक तरह से बैठक आवश्यकताओं में व्यवधानों को संभालने में सक्षम हो। सभी ऑप्टिमाइज़ेशन को अक्षम करने वाले कई कंपाइलरों पर अधिक-से-अधिक रजिस्टर-टू-रजिस्टर मूव्स करने वाले कोड मिलते हैं, जो कि खराब है, लेकिन मेमोरी में वेरिएबल को स्टोर करना, उन्हें रजिस्टर में रखने के बजाय रिकवरी के दृष्टिकोण से सुरक्षित होता है। यदि किसी की स्मृति में दो चर होते हैं, जो किसी शर्त का पालन करने वाले होते हैं (जैसे v1=v2+0xCAFEBABEऔर दो चर के सभी अद्यतन किए जाते हैं ...

— सुपरकैट

28

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

चेकसम निरंतर डेटा । यदि आपके पास कोई कॉन्फ़िगरेशन डेटा है जो लंबे समय तक स्थिर रहता है (हार्डवेयर रजिस्टर जिसमें आपने कॉन्फ़िगर किया है सहित), इसके चेकसम को प्रारंभ पर गणना करें और इसे समय-समय पर सत्यापित करें। जब आप एक बेमेल देखते हैं, तो यह फिर से शुरू करने या रीसेट करने का समय है।
अतिरेक के साथ वैरिएबल स्टोर करें । आप एक महत्वपूर्ण चर है x, में अपने मूल्य लिखना x1, x2और x3और के रूप में पढ़ (x1 == x2) ? x2 : x3।
कार्यक्रम प्रवाह निगरानी लागू करें । मुख्य पाश से बुलाए गए महत्वपूर्ण कार्यों / शाखाओं में एक अद्वितीय मूल्य के साथ एक वैश्विक ध्वज XOR। लगभग 100% परीक्षण कवरेज के साथ विकिरण रहित वातावरण में कार्यक्रम चलाना आपको चक्र के अंत में ध्वज के स्वीकार्य मूल्यों की सूची प्रदान करना चाहिए। यदि आप विचलन देखते हैं तो रीसेट करें।
स्टैक पॉइंटर की निगरानी करें । मुख्य लूप की शुरुआत में, स्टैक पॉइंटर की उसके अपेक्षित मूल्य के साथ तुलना करें। विचलन पर रीसेट करें।

— दिमित्री ग्रिगोरीव
स्रोत

27

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

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

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

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

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

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

— OldFrank
स्रोत

9

टीटीएल मानक आईसीएस के साथ बाइनरी काउंटर वॉचडॉग वास्तव में 1980 का समाधान है। ऐसा मत करो। आज, निर्मित वॉचडॉग सर्किटरी के बिना बाजार पर एक भी एमसीयू मौजूद नहीं है। यदि आपको अंतर्निहित वॉचडॉग में एक व्यक्ति घड़ी स्रोत (अच्छा है, तो सबसे अधिक संभावना है) या अगर यह सिस्टम घड़ी (खराब) से अपनी घड़ी विरासत में मिली है, तो आपको जांचना होगा।

— लुंडिन

1

या पहरेदार को

— nos

2

अभी भी बड़े पैमाने पर एम्बेडेड प्रोसेसर में, संयोग से उपयोग किया जाता है।

— ग्राहम

5

@Peter Mortensen कृपया इस प्रश्न के हर उत्तर पर अपने संपादन की होड़ को रोकें। यह विकिपीडिया नहीं है, और वे लिंक सहायक नहीं हैं (और मुझे यकीन है कि हर कोई जानता है कि विकिपीडिया को किसी भी तरह कैसे ढूंढा जाए ...)। आपके कई संपादन गलत हैं क्योंकि आप इस विषय को नहीं जानते हैं। मैं आपके गलत संपादन पर रोल-बैक कर रहा हूं क्योंकि मैं उनके पार आता हूं। आप इस धागे को बेहतर नहीं बदल रहे हैं, लेकिन बदतर हैं। संपादन बंद करो।

— लुंडिन

जैक गन्सल का वॉचडॉग पर एक अच्छा लेख है: ganssle.com/watchdogs.htm

— इगोर

23

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

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

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

सुनिश्चित करें कि आपके पूरे हार्डवेयर को nबार दोहराया गया है (जहां n2 से अधिक है, और अधिमानतः विषम है), और यह कि प्रत्येक हार्डवेयर तत्व एक दूसरे हार्डवेयर तत्व के साथ संवाद कर सकते हैं। ईथरनेट ऐसा करने का एक स्पष्ट तरीका है, लेकिन कई अन्य सरल मार्ग हैं जो बेहतर सुरक्षा देंगे (उदाहरण के लिए CAN)। सामान्य घटकों (यहां तक कि बिजली की आपूर्ति) को कम से कम करें। इसका मतलब हो सकता है कि उदाहरण के लिए कई स्थानों पर एडीसी इनपुट का नमूना लिया जाए।
सुनिश्चित करें कि आपका आवेदन राज्य एक ही स्थान पर है, उदाहरण के लिए एक परिमित राज्य मशीन में। यह पूरी तरह से रैम आधारित हो सकता है, हालांकि स्थिर भंडारण को रोकता नहीं है। इस प्रकार यह कई जगह संग्रहीत किया जाएगा।
राज्य के परिवर्तनों के लिए एक कोरम प्रोटोकॉल को अपनाएं। उदाहरण के लिए RAFT देखें । जैसा कि आप C ++ में काम कर रहे हैं, इसके लिए अच्छी तरह से ज्ञात लाइब्रेरी हैं। FSM में परिवर्तन केवल तभी किया जाएगा जब अधिकांश नोड्स सहमत हों। प्रोटोकॉल स्टैक और कोरम प्रोटोकॉल के लिए अपने आप को रोल करने के बजाय एक ज्ञात अच्छी लाइब्रेरी का उपयोग करें, या अतिरेक पर आपके सभी अच्छे काम तब बर्बाद हो जाएंगे जब कोरम प्रोटोकॉल लटका हुआ हो।
सुनिश्चित करें कि आप अपने FSM को चेकसम (जैसे CRC / SHA), और FSM में ही CRC / SHA को संग्रहीत करें (साथ ही संदेश को प्रेषित करने, और संदेशों को स्वयं जाँच कर)। इन चेकसम, चेकसम आने वाले संदेशों के खिलाफ नियमित रूप से अपने एफएसएम की जांच करने के लिए नोड्स प्राप्त करें और उनके चेकसम को कोरम के चेकसम से मेल खाते हैं।
संभव के रूप में अपने सिस्टम में कई अन्य आंतरिक जांचों का निर्माण करें, जिससे नोड्स का पता चलता है जो उनकी स्वयं की विफलता रिबूट का पता लगाता है (यह आधे काम करने से बेहतर है बशर्ते आपके पास पर्याप्त नोड्स हों)। यदि वे फिर से नहीं आते हैं, तो उन्हें रिबूट करने के दौरान खुद को कोरम से दूर करने का प्रयास करें। रिबूट पर उन्हें सॉफ्टवेयर छवि (और कुछ भी वे लोड करते हैं) का चेकसम है और खुद को कोरम में फिर से प्रस्तुत करने से पहले एक पूर्ण रैम परीक्षण करें।
आप का समर्थन करने के लिए हार्डवेयर का उपयोग करें, लेकिन इतनी सावधानी से करें। उदाहरण के लिए, आप ईसीसी रैम प्राप्त कर सकते हैं, और ईसीसी त्रुटियों को ठीक करने के लिए इसके माध्यम से नियमित रूप से पढ़ / लिख सकते हैं (और यदि त्रुटि ठीक नहीं है तो घबराएं)। हालाँकि (मेमोरी से) स्टैटिक रैम DRAM की तुलना में आयनीकृत विकिरण के लिए अधिक सहिष्णु होता है, इसलिए इसके बजाय स्टैटिक DRAM का उपयोग करना बेहतर हो सकता है। 'मैं जो कुछ नहीं करूँगा' के तहत पहला बिंदु देखें।

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

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

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

— abligh
स्रोत

2

मिशन-महत्वपूर्ण अनुप्रयोगों में उपयोग करने के लिए ईथरनेट शायद एक महान विचार नहीं है। पीसीबी के बाहर न तो I2C है। कैन जैसा बीहड़ कुछ अधिक उपयुक्त होगा।

— लुंडिन

1

@ लुंडिन मेला बिंदु, हालांकि कुछ भी वैकल्पिक रूप से जुड़ा हुआ है (incl। ईथरनेट) ठीक होना चाहिए।

— अब्लीग

1

भौतिक मीडिया इतना अधिक कारण नहीं है कि ईथरनेट अनुपयुक्त क्यों है, लेकिन निर्धारक वास्तविक समय व्यवहार की कमी है। हालांकि मुझे लगता है कि आजकल कुछ हद तक विश्वसनीय ईथरनेट प्रदान करने के तरीके हैं, मैं इसे पुरानी आदत से बाहर वाणिज्यिक / खिलौना इलेक्ट्रॉनिक्स के साथ मिलकर समूह बनाता हूं।

— लुंडिन

1

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

— abligh

1

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

— सुपरैट

23

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

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

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

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

— jkflying
स्रोत

1

इन सुझावों में से कुछ, भ्रष्टाचार का पता लगाने के लिए एक समान 'बहु-सा मानसिक स्वास्थ्य की जांच' मानसिकता के साथ कुछ है मैं वास्तव में सुरक्षा-महत्वपूर्ण कस्टम डेटाटाइप्स के सुझाव सबसे हालांकि के साथ इस तरह

— WearyWanderer

2

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

— jwdonahue

16

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

मेरी राय में रेडियोधर्मिता के साथ मुख्य समस्या यह है कि रेडियोधर्मिता बिट्स को स्विच कर सकती है, इस प्रकार रेडियोधर्मिता किसी भी डिजिटल मेमोरी को तोड़ / सकती है । इन त्रुटियों को आमतौर पर सॉफ्ट एरर कहा जाता है , बिट रोट आदि ।

सवाल यह है: जब आपकी मेमोरी अविश्वसनीय है तो मज़बूती से गणना कैसे करें?

नरम त्रुटियों की दर को कम करने के लिए (कम्प्यूटेशनल ओवरहेड की कीमत पर क्योंकि यह ज्यादातर सॉफ्टवेयर-आधारित समाधान होगा), आप यह कर सकते हैं:

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

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

Giuseppe F.Italiano, यूनिवर्सिटा डी रोमा "टोर वेरटाटा" द्वारा लचीला एल्गोरिदम डेटा संरचनाएं
क्रिस्टियानो, पी।, डेमनी, ईडी, और किशोर, एस (2011)। Additive ओवरहेड के साथ दोषरहित दोष-सहिष्णु डेटा संरचनाएं। एल्गोरिदम और डेटा संरचनाओं में (पीपी। 243-254)। स्प्रिंगर बर्लिन हीडलबर्ग।
फेरारो-पेट्रिलो, यू।, ग्रैंडोनी, एफ।, और इटैलिक, जीएफ (2013)। डेटा संरचनाएं मेमोरी दोषों के लिए लचीली होती हैं: शब्दकोशों का एक प्रायोगिक अध्ययन। जर्नल ऑफ़ एक्सपेरिमेंटल एल्गोरिथम (JEA), 18, 1-6।
Italiano, GF (2010)। लचीला एल्गोरिदम और डेटा संरचनाएं। एल्गोरिदम और जटिलता में (पीपी। 13-24)। स्प्रिंगर बर्लिन हीडलबर्ग।

यदि आप लचीले डेटा संरचनाओं के क्षेत्र के बारे में अधिक जानने में रुचि रखते हैं, तो आप Giuseppe F. Italiano के कार्यों की जांच कर सकते हैं (और रेफरी के माध्यम से अपना काम कर सकते हैं) और फ़ॉल्टी-रैम मॉडल (फिनोच्ची एट अल। 2005 में शुरू किया गया)। और नोकिया 2008)।

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

विचार यह है कि आप बस प्रत्येक गणना के लिए एक ही गणना करने के लिए x गुणा करते हैं, और परिणाम को x भिन्न चर (x> = 3 के साथ) में संग्रहीत करते हैं। फिर आप अपने एक्स चर की तुलना कर सकते हैं :

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

यह अतिरेक योजना ECC (व्यावहारिक रूप से O (1)) की तुलना में बहुत तेज़ है और यह आपको एक स्पष्ट संकेत प्रदान करती है जब आपको असफल होने की आवश्यकता होती है । बहुसंख्यक वोट भी (लगभग) दूषित उत्पादन न करने की गारंटी देता है और मामूली संगणना त्रुटियों से उबरने की गारंटी देता है , क्योंकि x संगणना को समान उत्पादन देने की संभावना असीम है (क्योंकि संभावित आउटपुट की एक बड़ी मात्रा है, यह लगभग असंभव है। बेतरतीब ढंग से 3 बार एक ही मिलता है, और भी कम संभावना है अगर x> 3)।

इसलिए बहुमत वाले वोट से आप दूषित आउटपुट से सुरक्षित हैं, और अतिरेक x == 3 के साथ, आप 1 त्रुटि को पुनर्प्राप्त कर सकते हैं (x == 4 के साथ यह 2 त्रुटियों को पुनर्प्राप्त करने योग्य होगा, आदि - सटीक समीकरण वह है nb_error_recoverable == (x-2)जहां x संख्या है गणना की पुनरावृत्ति क्योंकि आपको बहुमत के मत का उपयोग करने के लिए कम से कम 2 सहमत गणनाओं की आवश्यकता होती है)।

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

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

— gaborous
स्रोत

9

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

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

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

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

— ग्राहम
स्रोत

1

दरअसल, सवाल के परीक्षण में कहीं भी लेखक का उल्लेख नहीं है कि आवेदन रेडियोधर्मी वातावरण के ठीक बाहर चलाने के लिए पाया गया था।

— मार्क .377

9

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

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

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

— जोनास बिस्ट्रॉम
स्रोत

7

मैं एक परिदृश्य की थाह लेने की कोशिश कर रहा हूं, जहां आपके पास विकिरण पर्यावरण के बाहर एक मास्टर हो सकता है, विकिरण वातावरण के अंदर दासों के साथ मज़बूती से संवाद करने में सक्षम है, जहां आप सिर्फ विकिरण पर्यावरण के बाहर दासों को नहीं रख सकते।

— फॉस्टंडी

1

@ फ़ॉस्टंडी: दास या तो उन उपकरणों का उपयोग करके मापते हैं या नियंत्रित करते हैं जिन्हें नियंत्रक की आवश्यकता होती है। एक जाइगर काउंटर कहो। गुलाम अतिरेक के कारण मास्टर को विश्वसनीय संचार की आवश्यकता नहीं होती है।

— जोनास बिस्ट्रॉम

4

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

— लुंडिन

5

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

— लुंडिन

7

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

— ren
स्रोत

2

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

— झुकें,

7

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

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

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

— BЈовић
स्रोत

11

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

— लुंडिन

7

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

— एलेक्स सी
स्रोत

7

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

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

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

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

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

— सर्द
स्रोत

7

यदि आपका हार्डवेयर विफल हो जाता है तो आप इसे पुनर्प्राप्त करने के लिए मैकेनिकल स्टोरेज का उपयोग कर सकते हैं। यदि आपका कोड आधार छोटा है और कुछ भौतिक स्थान हैं तो आप एक यांत्रिक डेटा स्टोर का उपयोग कर सकते हैं।

सामग्री की एक सतह होगी जो विकिरण से प्रभावित नहीं होगी। मल्टीपल गियर होंगे। एक यांत्रिक रीडर सभी गियर पर चलेगा और ऊपर और नीचे जाने के लिए लचीला होगा। डाउन का मतलब है कि यह 0 है और इसका मतलब है कि यह 1. है। 0 और 1 से आप अपना कोड आधार बना सकते हैं।

— Hitul
स्रोत

2

शायद एक ऑप्टिकल माध्यम जैसे कि CD-ROM इस परिभाषा को पूरा करेगा। इसमें बड़ी क्षमता का अतिरिक्त बोनस होगा।

— वोसनेम

2

हां यह समान होगा लेकिन सीडी रोम कम उपयोग करेगा लेकिन यह पूरी तरह से यांत्रिक प्रणाली होगी।

— हितुल

7

मुझे आश्चर्य है कि अगर वहाँ एक कारण है कि वे अंतरिक्ष में पंच-कार्ड पाठकों का उपयोग क्यों नहीं करते हैं।

— सोरेन

3

@ शोर गति और भौतिक स्थान एक कारण हो सकता है।

— हितुल

5

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

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

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

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

— गेरहार्ड
स्रोत

4

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

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

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

— MrBigglesworth
स्रोत

3

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

— यहोशू
स्रोत

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

— पीटर कॉर्ड्स

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

— जोशुआ

1

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

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

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

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

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

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

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

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

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

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

— TarmoPikaro
स्रोत

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

— जेब

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

— TarmoPikaro

0

मैंने वास्तव में बहुत सारे शानदार उत्तर पढ़े हैं!

यहाँ मेरा 2 प्रतिशत है: मेमोरी की जांच के लिए या लगातार रजिस्टर तुलना करने के लिए एक सॉफ्टवेयर लिखकर, मेमोरी / रजिस्टर असामान्यता का एक सांख्यिकीय मॉडल बनाएं। इसके अलावा, एक वर्चुअल मशीन की शैली में एक एमुलेटर बनाएं, जहां आप मुद्दे के साथ प्रयोग कर सकते हैं। मुझे लगता है कि यदि आप जंक्शन आकार, घड़ी आवृत्ति, विक्रेता, आवरण आदि को बदलते हैं, तो एक अलग व्यवहार होगा।

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