एरियन 5 की उड़ान 501 का ऐतिहासिक प्रभाव क्या था?


9

एरियन 5 रॉकेट 37 सेकंड के विघटन के बाद उसकी पहली यात्रा पर उड़ान ( 501 उड़ान ) को आमतौर पर इतिहास के सबसे महंगे सॉफ्टवेयर बग में से एक के रूप में जाना जाता है। 1 :

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

यह सब पिछले जून में अपनी पहली यात्रा में एक मिनट से भी कम समय तक रॉकेट में विस्फोट करने के लिए लिया गया था, फ्रेंच गुयाना के मैंग्रोव दलदलों के पार उग्र मलबे को बिखेरना, एक छोटा कंप्यूटर प्रोग्राम था जो 64-बिट संख्या को 16-बिट स्पेस में सामान करने की कोशिश कर रहा था।

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

फ्लाइट की 501 विफलता और उसके बाद की जांच में कौन से बड़े बदलाव सुरक्षा महत्वपूर्ण प्रणालियों और सॉफ्टवेयर परीक्षण के अनुसंधान के लिए प्रेरित करते हैं?

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

हमने स्थैतिक विश्लेषण का उपयोग किया है:

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

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

इसी तरह, यह कागज (पीडीएफ) नोट:

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

मुझे इस एकल घटना के सॉफ़्टवेयर परीक्षण दृष्टिकोण और उपकरणों पर पड़ने वाले प्रभाव की पूरी तरह से व्याख्या करना अच्छा लगेगा।

1 $ 7 बिलियन का आंकड़ा संभवतः एरियन 5 परियोजना की कुल लागत को संदर्भित करता है, विकिपीडिया रिपोर्ट करता है कि विफलता के कारण 370 मिलियन डॉलर से अधिक का नुकसान हुआ। अभी भी एक काफी महंगी विफलता है लेकिन कहीं भी $ 7 बिलियन के आंकड़े के पास नहीं है।


5
"सबसे खराब" परिभाषित करें ... सबसे खराब क्योंकि यह महंगा था? मुझे नहीं पता ... मुझे लगता है कि यदि आप कैंसर के उपचार के दौरान विकिरण के बड़े पैमाने पर ओवरडोज के शिकार लोगों में से एक थे तो थेरैक -25 बहुत खराब बग होगा। users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html ; courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html ; en.wikipedia.org/wiki/Therac-25
FrustratedWithFormsDesigner

2
@FrustratedWithFormsDesigner आपके स्वयं के प्रश्न का उत्तर देना पूरी तरह से स्वीकार्य है , हमें हाल ही में एक सुविधा मिली है जो स्वयं के उत्तर को प्रोत्साहित करती है। मैं इस सवाल के लिए इसे ड्राइव करने जा रहा था, हालांकि यह देखते हुए कि यह एक प्रतियोगिता का सवाल है (यह नहीं कि यह एक मौका है) मैंने किसी और को इसका जवाब देने का फैसला किया।
यनीस

3
क्या हम वास्तव में यह स्थापित करना चाहते हैं कि उपदेशात्मक प्रश्न दायरे में हैं? अगर ऐसा है, तो मुझे हल्के-फुल्के कष्टप्रद सवालों की एक लहर दिखाई दे सकती है, जिसका मतलब है कि हमें कहीं न कहीं ले जाना और हमें ओपी के बिना कुछ सिखाना। आपके ऊपर, लेकिन यह जोखिम भरा लगता है।
कॉर्बिन मार्च

4
@gnat ने कभी नहीं कहा कि यह एकमात्र उत्तर था, सिर्फ एक संकेत था कि इस सवाल का जवाब है कि मतदाताओं को खुश करना है। लेकिन यहां आप जाएं: articles.adsabs.harvard.edu//full/1998ESASP.422..201L/…… और dl.acm.org/citation.cfm?id=263750 (ACM paywall
yannis

3
@FrustratedWithFormsDesigner: कभी-कभी मेरे पास ऐसे प्रश्न होते हैं जिनके बारे में मुझे लगता है कि मुझे उत्तर पता है, लेकिन मुझे यकीन नहीं है। इसलिए मैं उनसे पूछना चाहता हूं कि मेरी थीसिस की पुष्टि नहीं हुई है, बल्कि सभी तरह के जवाबों के लिए खुला हूं जो मुझे मिलने वाला है। इसलिए, सामान्य तौर पर, मुझे लगता है कि यह एक प्रश्न पूछने के लिए समझ में आता है, भले ही मेरे पास संभावित उत्तरों के बारे में पहले से ही कुछ विचार हों।
जियोर्जियो

जवाबों:


5

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

दुर्भाग्य से, किसी ने परीक्षण को परेशान नहीं किया कि ऑपरेटिंग वातावरण में परिवर्तन का क्या प्रभाव पड़ेगा, या यदि उन्होंने ऐसा नहीं किया तो उन्होंने कहा कि परीक्षण पर्याप्त रूप से पूरी तरह से मानक नहीं है।

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

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

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

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

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

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


6
संदर्भ ....?
FrustratedWithFormsDesigner

2
विश्वविद्यालय में कंप्यूटर विज्ञान का अध्ययन करते समय इंजीनियरिंग नैतिकता की मेरी अपनी यादें :)
गॉर्डन

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

1

यह ज्यादातर पुन: उपयोग की समस्या और प्रबंधन समस्या थी और कोडिंग नहीं थी। रिपोर्ट से मेरी यादों (मैं संभावित रूप से कुछ गलत हो रही है) से।

  • एरियन IV के लिए एक सबसिस्टम डिजाइन किया गया था। एरियन IV के प्रक्षेपवक्र अतिप्रवाह में परिणत नहीं हो सके और फिर जानबूझकर यह निर्णय लिया गया कि अगर यह हुआ, तो यह एक हार्डवेयर समस्या थी और सबसिस्टम को बंद करना और स्पेयर पर जाना सही काम था।

  • एरियन वी के लिए, उस सबसिस्टम का पुन: उपयोग करने और मान्यताओं और कोड की समीक्षा नहीं करने का निर्णय लिया गया था, लेकिन परीक्षण पर भरोसा किया गया था।

  • इसके अलावा पूर्ण परीक्षण को छोड़ने का निर्णय लिया गया।

एरियन वी के विभिन्न उड़ान मापदंडों ने अतिप्रवाह किया। प्राइमरी बंद करो। बन्द कर दो। Autodestruction।

अतिरिक्त चीजें जो मुझे याद हैं:

  • अतिप्रवाह के समय सबसिस्टम अधिक उपयोगी नहीं था। कोई यह तर्क दे सकता है कि इसकी विफलता के कारण ऑटोडेस्ट्रेशन नहीं होना चाहिए। (दूसरी ओर, जोड़ा गया जटिलता ही समस्याओं का एक स्रोत हो सकता है)।

  • डिबग डेटा को बस में भेजा जाना चाहिए जब वह नहीं होना चाहिए। मैं विशिष्ट याद नहीं है।


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


ISTR विफलता के पीछे का तंत्र यह था कि कोड ने एक अतिप्रवाह अपवाद फेंक दिया, जिसे कॉलर ने नहीं पकड़ा। अपवाद को तब तक प्रचारित किया जाता था जब तक कि उसे डिफ़ॉल्ट अपवाद हैंडलर द्वारा पकड़ नहीं लिया जाता था, जो आक्रामक मॉड्यूल को निरस्त कर देता था। हालाँकि, चूंकि अपवाद इतने सारे स्तर से ऊपर उठ चुका था, इसलिए उस बिंदु पर "अपमानजनक मॉड्यूल" संपूर्ण आरएसआई (जड़त्वीय संदर्भ प्रणाली) था।
टीएमएन

0

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


2
संदर्भ कृपया ...
यानिस

1
ज्यादातर पुराने ACM लेख से आधे-याद किए जाते हैं, लेकिन कुछ और जानकारी यहाँ है
टीएमएन

अलग-अलग टीमों के अलग-अलग कंप्यूटरों के विचारों को स्पेस शटल प्रोग्राम द्वारा विकसित किया गया था, और शायद पहले भी।
mhoran_psprep

@mhoran_psprep: एटी एंड टी एक्सचेंज विफलता पर पढ़ें और इसके परिणाम हैं। क्षमा करें - कोई संदर्भ नहीं, इसे स्मृति से जानें।
मटनज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.