नरक में जीवित रहने वाला कोड: रेडियोधर्मी वातावरण के लिए C++

प्रस्तावना: आपका कोड अंतरिक्ष में "पागल" क्यों हो सकता है?

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

यह आपके कोड में बग नहीं है। यह भौतिकी है। उच्च-ऊर्जा कण (प्रोटॉन, न्यूट्रॉन, भारी आयन) माइक्रोचिप के सिलिकॉन से गुज़रते हैं और इलेक्ट्रॉनों को बाहर निकाल देते हैं। एक एकल फोटॉन प्रोसेसर रजिस्टर या RAM सेल में एक बिट को पलट सकता है। इस घटना को Single Event Upset (SEU) कहा जाता है - एक एकल विफलता घटना। एम्बेडेड सिस्टम और अंतरिक्ष सॉफ्टवेयर डेवलपर्स के समुदाय में यह मुद्दा इतना लोकप्रिय है कि Stack Overflow पर चर्चा ने सैकड़ों हज़ारों व्यूज़ प्राप्त किए हैं। आज हम विश्लेषण करेंगे कि उच्च विकिरण की स्थितियों में काम करने के लिए C++ एप्लिकेशन कैसे संकलित और लिखें, और सामान्य तरीके यहाँ क्यों काम नहीं करते।

समस्या: विकिरण आपकी मेमोरी के "यादृच्छिक हैकर" के रूप में

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

ऐसी स्थितियों में कोड के लिए मुख्य खतरे:

\n
• CPU रजिस्टरों में SEU: एक कण सामान्य-उद्देश्य रजिस्टर में मान बदल सकता है, जिससे गलत गणनाएँ हो सकती हैं।
\n
• कैश में SEU: एक "खराब" निर्देश पूरी तरह से अलग ऑपरेशन के रूप में निष्पादित हो सकता है।
\n
• RAM में SEU: स्टैक या हीप में डेटा का परिवर्तन।
\n
• कॉन्फ़िगरेशन रजिस्टरों में SEU: सबसे बुरा - एक कण प्रोसेसर या परिधीय के ऑपरेटिंग मोड को नियंत्रित करने वाले बिट को बदल सकता है।
\n

वास्तविक अंतरिक्ष से एक क्लासिक उदाहरण: 2003 में, Mars Global Surveyor पर ब्रह्मांडीय विकिरण के कारण एक विफलता दर्ज की गई, जिसके परिणामस्वरूप फ्लैश मेमोरी को नुकसान और डेटा हानि हुई। और शक्तिशाली ट्रांसमीटरों के पास घरेलू माइक्रोवेव कितनी बार "खराब" हुए हैं? यही कारण है कि विकिरण से कोड सुरक्षा कोई विदेशी चीज़ नहीं, बल्कि एक कठोर आवश्यकता है।

दृष्टिकोण 1: "लोहे जैसा ठोस" कोड (Radiation Hardening by Software)

सबसे सुलभ तरीका कोड इस तरह लिखना है कि वह स्वयं की रक्षा करे। कंपाइलर यहाँ केवल एक उपकरण है, लेकिन हम इसे कॉन्फ़िगर कर सकते हैं।

1.1. Triple Modular Redundancy (TMR) — तिहरी अतिरेकता

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

एक पूर्णांक की सुरक्षा के लिए C++ में एक सरल टेम्पलेट लागू करते हैं:

#include <array>\n#include <cstdint>\n#include <algorithm>\n\ntemplate<typename T>\nclass RadiationHardenedValue {\nprivate:\n    std::array<T, 3> copies;\n\npublic:\n    explicit RadiationHardenedValue(T initial_value) {\n        copies.fill(initial_value);\n    }\n\n    // बहुमत के आधार पर "वोटिंग" फ़ंक्शन\n    T get() const {\n        // तीन मानों के लिए सबसे सरल माध्यिका फ़िल्टर\n        if (copies[0] == copies[1] || copies[0] == copies[2]) {\n            return copies[0];\n        }\n        if (copies[1] == copies[2]) {\n            return copies[1];\n        }\n        // यदि तीनों अलग-अलग हैं - गंभीर त्रुटि\n        // वास्तविक कोड में यहाँ आपातकालीन अलार्म होना चाहिए\n        return copies[0]; // कम से कम कुछ तो लौटाएँ\n    }\n\n    void set(const T& new_value) {\n        copies[0] = new_value;\n        copies[1] = new_value;\n        copies[2] = new_value;\n    }\n\n    // ऑपरेटर