🤪 🏇🏽 🤙🏼 कोड की 500 मिलियन डॉलर प्रति पंक्ति या अंतरिक्ष में सॉफ़्टवेयर त्रुटियों की लागत 🤾🏼 🏈 🌹

कुछ महीने पहले edx.org पर पाठ्यक्रम "स्पेस टेक्नोलॉजी का परिचय: एस्ट्रोनॉटिक्स एंड मैनड फ्लाइट्स (एंड टू एयरोस्पेस इंजीनियरिंग: एस्ट्रोनॉटिक्स एंड ह्यूमन स्पेसफ्लाइट)" समाप्त हुआ। पाठ्यक्रम को एक अमेरिकी अंतरिक्ष यात्री द्वारा पढ़ाया गया था, वर्तमान में एमआईटी प्रोफेसर - जेफरी एलन हॉफमैन। जैसा कि नाम से ही स्पष्ट है कि यह पाठ्यक्रम काफी सरल और सामान्य है, हालांकि, यह मुझे रोचक और ज्ञानवर्धक लगा।

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

मंगल ध्रुवीय लैंडर

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

नासा लैब में एमपीएल

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

नियोजित लैंडिंग पाठ्यक्रम

MPL ~ 7 किमी / सेकंड की गति से 100 किमी से अधिक की ऊंचाई पर मंगल के वातावरण में प्रवेश करती है। 3 मिनट में डिवाइस 8.8 किमी की ऊँचाई तक उतरता है और 0.5 किमी / सेकंड की गति तक धीमा हो जाता है, जिसके बाद यह पैराशूट को खोलने के लिए एक संकेत देता है, जो हीट शील्ड के अलग होने (हीट शील्ड) के तुरंत बाद आता है। जब पैराशूट का उपयोग करके डिवाइस की गति 85 मीटर / सेकंड तक कम हो जाती है, तो एक रडार काम करना शुरू कर देता है, जो संभावित लैंडिंग साइट को निर्धारित करने के लिए सतह सुविधाओं की निगरानी करता है।

MPL उड़ान मंच आरेख

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

घटनाओं का कोर्स

3 दिसंबर को, वंश वाहन को क्रूज़ स्टेज से उतारा गया और लैंडिंग पूरी होने तक, नियोजित रेडियो साइलेंस मोड में चला गया। वायुमंडल में प्रवेश करने से 6 मिनट पहले 20:04:00 यूटीसी पर, इंजन के प्रोग्राम्ड ऑपरेशन ने हीट स्क्रीन को ओरिएंट करते हुए, उपकरण की स्थिति को ठीक किया। एमपीएल ने 20:10:00 यूटीसी पर 6.9 किमी / सेकंड की गति से मंगल के वातावरण में प्रवेश किया। लैंडिंग के बाद 20:39:00 यूटीसी पर संचार की बहाली की उम्मीद थी। लेकिन कनेक्शन कभी स्थापित नहीं किया गया था, और डिवाइस को खो जाने की घोषणा की गई थी।

संचार के नुकसान का सटीक कारण अज्ञात है, लेकिन दुर्घटना जांच रिपोर्ट में यह निष्कर्ष है कि दुर्घटना का सबसे संभावित कारण एक सॉफ्टवेयर त्रुटि है जो लैंडिंग से कंपन के रूप में समर्थन के उद्घाटन के दौरान गलत तरीके से गणना की जाती है। नतीजतन, डिवाइस ने ब्रेक इंजन को 40 मीटर की ऊंचाई पर बंद कर दिया, इस तथ्य के बावजूद कि यह ज्ञात था कि समर्थन के प्रकटीकरण से झूठी सकारात्मकता पैदा हो सकती है। सॉफ्टवेयर के लिए संदर्भ की शर्तें इस मामले के लिए प्रदान नहीं की गईं।

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

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

40 मीटर की ऊंचाई पर, वाहन की वंश दर लगभग 13 m / s (47 किमी / घंटा) थी, जो ब्रेक इंजन के जोर के बिना, मंगल के गुरुत्वाकर्षण के प्रभाव में सतह के पास 22 m / s (80 किमी / घंटा) तक बढ़ गई, घटने की अनुमानित गति 2.4 मीटर थी। / s (9 किमी / घंटा)। सतह से टकराने की ऐसी गति पर, उपकरण जीवित नहीं रह सकता है। ”

यदि आप कार्यक्रम के एल्गोरिथ्म को देखते हैं, तो आप देख सकते हैं कि प्रारंभिक FALSE के संकेतक संकेतक चर की स्थिति को रीसेट करने की एक पंक्ति डिवाइस को बचा सकती है, जिसकी कीमत NASA $ 328 मिलियन है।

सॉफ्टवेयर फ़्लोचार्ट

एरियन 5

4 जून, 1996 को यूरोपीय अंतरिक्ष एजेंसी (ESA) द्वारा विकसित नए एरियन 5 लॉन्च वाहन का पहला प्रक्षेपण किया गया था। प्रक्षेपण असफलता में समाप्त हुआ - रॉकेट ऑन-बोर्ड सॉफ्टवेयर के गलत संचालन के कारण उड़ान के 39 वें सेकंड में दुर्घटनाग्रस्त हो गया।

पहला एरियन 5

एरियन 5 का प्रक्षेपण एरियन परिवार का यूरोपीय प्रक्षेपण वाहन है। फ्रेंच गुएना में कौरो कोस्मोड्रोम में लॉन्च हुए। एरियन 5 के विकास में 10 साल लगे, लागत 7 बिलियन डॉलर थी और इसका उद्देश्य एरियन 4 लॉन्च वाहन को बदलना था।

1996 में लॉन्च किया गया था, 720 टन के द्रव्यमान वाला एक प्रक्षेपण यान, चार उपग्रहों को 1.2 टन के द्रव्यमान के साथ प्रक्षेपित करना था। प्रत्येक को अपनी कक्षा में घुमाते हुए, ये उपग्रह एक टेट्राहेड्रॉन बनाते हैं, और एक समूह में काम करते हैं, यह पृथ्वी के चुंबकीय क्षेत्र का अध्ययन करने के लिए यूरोपीय क्लस्टर परियोजना थी (बाद में 2000 में, क्लस्टर -2 कार्यक्रम के लिए चार नए उपग्रहों को सफलतापूर्वक दो सोयूज लॉन्च वाहनों द्वारा कक्षा में रखा गया था) ।

घटनाओं का कोर्स

घटना का वर्णन करने से पहले, यह ध्यान दिया जाना चाहिए कि एरियन 5 के लिए नेविगेशन सिस्टम (इनरटियल रेफरेंस सिस्टम - एसआरआई) का डिज़ाइन विशेष रूप से सॉफ्टवेयर के संबंध में एरियन 4 के लिए डिज़ाइन के समान है।

प्रारंभ का क्षण H0 द्वारा चिह्नित किया जाता है। प्रारंभ से पहले के संचालन सामान्य मोड में H0 - 7 मिनट तक हुए, जब "दृश्यता मानदंड" का उल्लंघन दर्ज किया गया था। इसलिए, शुरुआत को एक घंटे के लिए स्थगित कर दिया गया था।
H0 = 12:33:59 UTC पर, एक प्रक्षेपण किया गया, जो सामान्य रूप से H0 + 37 सेकंड के क्षण तक हुआ। निम्नलिखित सेकंड में, एक दिए गए रास्ते से रॉकेट का तेज विचलन हुआ, और फिर एक विस्फोट हुआ।

पहले लॉन्च के दौरान एरियन 5 ब्लास्ट

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

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

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

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

एक सफल लॉन्च से पहले लॉन्च पैड पर एरियन 5, फ्रेंच गयाना 2002।

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

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

अंतरिक्ष शटल

12 अप्रैल, 1981 को स्पेस शटल कार्यक्रम के तहत पुन: प्रयोज्य कोलंबिया अंतरिक्ष यान ने केप कैनवरल में कोस्मोड्रोम से अपनी पहली परीक्षण उड़ान भरी।

एसटीएस -1 मिशन के लिए तैयारी - पहली अंतरिक्ष शटल उड़ान

घटनाओं का कोर्स

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

कुख्यात कॉमिक को कैसे याद नहीं किया जाए

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

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

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

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

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

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

पहले से ही दोपहर की शुरुआत में, सभी विशेषज्ञों को इकट्ठा करके, नासा समस्या की प्रकृति को स्पष्ट करने में सक्षम था। चरणबद्ध करने में त्रुटि को पुराने दादा विधि द्वारा ठीक किया जा सकता है: यदि कुछ काम नहीं करता है, तो इसे बंद करें और फिर से चालू करें।

लेकिन यह दृष्टिकोण पूरी तरह से लोड और अंतरिक्ष यान को लॉन्च करने के लिए तैयार होने के लिए काम नहीं करता है - ऑन-बोर्ड कंप्यूटर अंतरिक्ष लॉन्च तैयारी प्रणाली "से" और "आने वाली" जानकारी को संसाधित करने में महत्वपूर्ण भूमिका निभाते हैं।

विशेषज्ञों द्वारा एकत्र की गई जानकारी और तथ्य यह है कि शुक्रवार की रात को ऑन-बोर्ड कंप्यूटरों को फिर से शुरू करने ने इस समस्या को ठीक कर दिया, रविवार सुबह एक कार्यक्रम को शुरू करने के लिए नासा प्रबंधन को पर्याप्त जानकारी दी। लेकिन लॉन्च के 8 घंटे बाद रविवार शाम को त्रुटि के वास्तविक कारणों का पता चला।

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

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

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

और फिर भी, जिस दिन पहला ऑन-बोर्ड कंप्यूटर चालू किया गया था, निर्धारित लॉन्च से 30 घंटे पहले, समस्या ने खुद को महसूस किया।

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

सूखे रोजर्स झील

की सतह पर उतरने वाला शटल सॉफ्टवेयर में इस त्रुटि की लागत $ 0 है (बेशक, लॉन्च को स्थानांतरित करने की लागत संभवतः काफी थी, लेकिन पिछली दुर्घटनाओं को देखते हुए, जब अंतरिक्ष यान पूरी तरह से खो गया था, तो यह अपने नियोजित मिशन को पूरा करने के बाद, लॉन्च को फिर से शुरू करने की लागत आई। उपेक्षित, खासकर जब से मुझे उपयुक्त डेटा नहीं मिला)।

लेकिन मैं यह नोट करना चाहूंगा कि इस त्रुटि को लॉन्च का समय दो दिनों के लिए स्थगित कर दिया गया है: 10 अप्रैल से 12 अप्रैल तक, और, मेरी राय में, शटल के पहले लॉन्च के लिए बेहतर तारीख चुनना असंभव था, क्योंकि उसी दिन, ठीक 20 दिन पहले यूरी गगारिन ने अंतरिक्ष में अपनी उड़ान भरी। एक कछुए के शब्दों को कोई कैसे याद नहीं कर सकता है कि "यादृच्छिकता आकस्मिक नहीं है।"

संदर्भ

www.youtube.com/watch?v=Sc0emcwdyyA
www.youtube.com/watch?v=21o7IZhSvFs
en.wikipedia.org/wiki/Mars_Polar_Lander
en.wikipedia.org/wiki/Ariane_5
ru.wikipedia.org/wiki/STS-1
sunnyday.mit.edu/accidents/mpl_report_4.pdf
nssdc.gsfc.nasa.gov/nmc/spacecraftDisplay.do?id=1999-001A
www.osp.ru/os/1998/06/179592
klabs.org/DEI/Processor/shuttle/garman_bug_81.pdf

कोड की 500 मिलियन डॉलर प्रति पंक्ति या अंतरिक्ष में सॉफ़्टवेयर त्रुटियों की लागत

मंगल ध्रुवीय लैंडर

नियोजित लैंडिंग पाठ्यक्रम

घटनाओं का कोर्स

एरियन 5

घटनाओं का कोर्स

अंतरिक्ष शटल

घटनाओं का कोर्स

More articles: