- SpaceX का Starship 36 static fire परीक्षण से ठीक पहले विस्फोट जैसी स्थिति का शिकार हुआ
- इस घटना को SpaceX Masseys में रियल-टाइम में देखा गया
- आग बुझाने के लिए दमकल विभाग को भेजा गया, जिससे आपात स्थिति बन गई
- इस असामान्य घटना का टेस्ट शेड्यूल और आगे की डेवलपमेंट प्रक्रिया पर असर पड़ने की संभावना है
- रियल-टाइम वीडियो YouTube और X (Twitter) के जरिए साझा किया गया
SpaceX Starship 36 असामान्य घटना का सार
- SpaceX Starship 36 में static fire परीक्षण से ठीक पहले SpaceX Masseys सुविधा में अप्रत्याशित विस्फोट हुआ
- यह असामान्य घटना live streaming (YouTube और X) के जरिए दुनिया भर के दर्शकों तक रियल-टाइम में पहुँची
- विस्फोट के तुरंत बाद दमकल विभाग तुरंत मौके पर पहुँचा, जिससे गंभीर आपात स्थिति पैदा हुई
- इस घटना का डेवलपमेंट शेड्यूल, आगे के टेस्ट प्लान, सुरक्षा प्रोटोकॉल समेत SpaceX की पूरी डेवलपमेंट प्रक्रिया पर असर पड़ सकता है
- SpaceX के लिए कारण की जाँच और सुरक्षा सुनिश्चित करने के कदम उठाने की आवश्यकता सामने आई
1 टिप्पणियां
Hacker News राय
SpaceX की सफलताओं और विफलताओं को देखना वाकई बेहद रोमांचक अनुभव है; यह संभावना भी उठाई गई कि हाल में SpaceX जिन समस्याओं से जूझ रहा है, उनका एक कारण यह हो सकता है कि टीम के सदस्य मिशन के प्रति अपना जुनून धीरे-धीरे खो रहे हैं। पहले SpaceX में ज़रूर शामिल होना चाहता था, लेकिन अब बहुत पैसे मिलें तब भी प्रेरणा नहीं होती। अगर मुख्य प्रतिभाएँ इस संगठन को दुनिया बदलने के मौके के बजाय सिर्फ एक नौकरी की तरह देखने लगें, तो तेज़ और नवोन्मेषी डेवलपमेंट साइकल भी बिगड़कर "यह बेवकूफ़ी है, जितना कम हो सके उतना समय निकालो और तनख्वाह लो" जैसी मानसिकता में बदलने का जोखिम है.
एक वैकल्पिक दृष्टिकोण रखा गया: "लोग मिशन के प्रति जुनून नहीं खो रहे, बल्कि मिशन के प्रति जुनूनी लोग ही बाहर निकल रहे हैं।"
यह राय भी आई कि Elon Musk की लगातार अधिक तेज़ गति और ज़्यादा नतीजों की मांग के दबाव में SpaceX इंजीनियरों की शारीरिक और मानसिक ऊर्जा खत्म हो रही है; चाहे टीम कितनी भी मजबूत हो, यदि गति पर बहुत अधिक ज़ोर हो तो कभी न कभी कठिन मोड़ आता ही है.
इस बात पर ज़ोर दिया गया कि SpaceX वास्तव में बेहद कठिन काम कर रहा है और उसने लक्ष्य स्तर भी बहुत ऊँचा रखा है। जब इंजीनियरिंग की अनिश्चित सीमाओं को चुनौती दी जाती है, तो विफलता स्वाभाविक है; लेकिन कहीं न कहीं "Starship तो ज़रूर सफल होगा" जैसी धारणा बहुत सहज रूप से बन गई है, इस पर सवाल उठाया गया। सफल होने पर भी यह कठिन यात्रा होगी, और अब तक SpaceX का भाग्य भी अच्छा रहा है, तो यह सिर्फ औसत की ओर वापसी हो सकती है.
यह विश्वास जताया गया कि रॉकेट डेवलपरों में बुनियादी पेशेवर क्षमता और आत्म-विकास की प्रेरणा होती ही है; वे ऐसे लोग नहीं हैं जिनका प्रदर्शन सिर्फ दृष्टि की कमी से गिर जाए। वे बस कंपनी छोड़कर कहीं बेहतर जगह काम करेंगे.
संक्षेप में यह भी कहा गया कि ऐसा Google में भी हुआ था.
इस SpaceX हादसे की तुलना सोवियत N1 प्रोग्राम से की गई, खासकर उसके पैमाने, टेस्टिंग तरीके और बार-बार होने वाली खराबियों के संदर्भ में। कहा गया कि तब Korolyov भी चंद्रमा पर उतरने के लक्ष्य के दबाव में वास्तविक उड़ान चरण में ही सब कुछ जोड़कर परीक्षण करना चाहते थे, और अंततः 4 असफलताओं के बाद प्रोग्राम बंद हो गया। R7 में यह तरीका काम कर गया था, लेकिन बड़े रॉकेटों में यदि हिस्सों का अलग-अलग परीक्षण न हो सके तो समस्याएँ आसानी से पैदा होती हैं.
समझाया गया कि दोनों प्रोग्रामों में कुछ स्पष्ट समानताएँ हैं, लेकिन कई मायनों में वे अलग भी हैं। N1 में Glushko के विरोध के कारण इंजन चयन सीमित था, और NK-15 जैसे उस समय के कम विश्वसनीय इंजनों की बहुत बड़ी संख्या की आवश्यकता थी। Super Heavy और Starship को चरणवार अलग-अलग टेस्ट किया जा सकता है, जबकि N1 में यह संभव नहीं था; वहाँ एक टेस्ट फेल होने पर लॉन्च पैड तक नष्ट हो सकता था, जबकि आज की SpaceX अलग-अलग कंपोनेंट स्तर पर प्रयोग कर सकती है.
रॉकेट इंजीनियरिंग के उस scaling नियम पर ध्यान दिलाया गया कि रॉकेट जितना बड़ा होता है, उतना ही अनुपातिक रूप से बड़े safety margin रखना आसान होता है। लेकिन अनुमान लगाया गया कि Musk की हर चरण को reusable बनाने की ज़िद ने यह अतिरिक्त margin कम कर दिया होगा। व्यक्तिगत राय के तौर पर कहा गया कि शुरुआत में सिर्फ first-stage booster को reusable रखने की रणनीति अपनाकर विकास के अधिक हिस्से parallel में चलाना बेहतर हो सकता था.
इस बात पर ज़ोर दिया गया कि आज statistical failure analysis क्षमता और computing power के कारण काम अंधाधुंध प्रयोगों से नहीं चल रहा। इंजन टेस्ट, pressure test, static fire, sensor-based data collection flights जैसे कई परीक्षण वास्तव में मौजूद हैं, और hardware भी launch cadence से तेज़ बन रहा है; इसलिए SpaceX और N1 मूल रूप से अलग हैं.
यह तर्क दिया गया कि दोनों रॉकेटों में समानता सिर्फ इतनी है कि वे अपने-अपने समय के सबसे बड़े रॉकेट हैं; बाकी सब अलग है—सरकारी संचालन बनाम निजी (आंशिक सरकारी समर्थन सहित), expendable बनाम fully reusable, चंद्रमा बनाम मंगल, और पारंपरिक विकास बनाम iterative hardware-centric development। यह ऐतिहासिक व्याख्या भी सामने आई कि N1 की विफलता के लिए Korolev की अपनी गलतियों से अधिक उनके निधन को जिम्मेदार माना जा सकता है.
कहा गया कि N1 के विपरीत SpaceX बहुत बार परीक्षण करता है, जबकि N1 के मामले में ऐसे इंजन थे जिन्हें ground test नहीं किया जा सकता था, इसलिए पूरी stack को एक साथ उड़ाना पड़ता था। यह भी आकलन किया गया कि Starship v2 में payload बढ़ाने की कोशिश करते हुए कई सीमाओं से टकराया गया होगा, और समस्या इंजन (Raptor v2) से अधिक fuel feed plumbing में हुई लगती है.
हाई-क्वालिटी slow-motion वीडियो लिंक साझा किया गया: [https://x.com/dwisecinema/status/1935552171912655045]
इस वीडियो को देखकर कहा गया कि स्पष्ट रूप से fuel tank में से एक overpressure के कारण फटा हुआ दिखता है.
YouTube पर pause की स्थिति में frame-by-frame आगे बढ़ने के लिए
[.]और[,]keys इस्तेमाल करने की टिप भी साझा की गई.SpaceX टीम की live stream लिंक भी दी गई: [https://youtu.be/WKwWclAKYa0?t=6989]
Starship की बार-बार आने वाली समस्याओं को देखते हुए यह राय आई कि Saturn V और STS program (Space Shuttle) की उपलब्धियाँ कितनी प्रभावशाली थीं, यह फिर से महसूस होता है। rocket equation के स्वभाव के कारण यदि एक ही बड़े रॉकेट से भारी payload भेजना हो, तो आकार ज्यामितीय रूप से बहुत बढ़ता जाता है; ऐसे में कई मध्यम या छोटे रॉकेट अधिक कुशल लगते हैं। Soyuz, Atlas, Ariane, Falcon 9 को इसके अच्छे उदाहरण माना गया.
समझाया गया कि बड़े रॉकेट वास्तव में rocket equation के प्रभाव को कम करते हैं। यदि fuel mass बनाम dry mass का अनुपात एक निश्चित सीमा से ऊपर हो, तो गणितीय रूप से वे उल्टा अधिक payload ले जा सकते हैं.
इससे भी ज़्यादा आश्चर्य की बात यह बताई गई कि Saturn V ने 1969 की तकनीक से एक ही launch में सफलता हासिल की, जबकि अब Apollo जैसी mission capability पाने के लिए 10~15 Starship launches और SLS तक की जरूरत पड़ सकती है। 1958 में अमेरिका के पहले artificial satellite launch के सिर्फ 8 साल बाद चंद्रमा तक पहुँचना भी चकित करने वाला बताया गया। यह टिप्पणी भी आई कि मुश्किल सिर्फ web development ही नहीं हुई; रॉकेट डेवलपमेंट भी समय के साथ और जटिल तथा विशाल होती जा रही है.
इस पर ज़ोर दिया गया कि Starship के बड़े payload का मूल उद्देश्य "मंगल पर कब्ज़ा" जैसी महत्वाकांक्षा से जुड़ा है, और संदर्भ के लिए यह लेख जोड़ा गया: [https://in.mashable.com/science/85790/…]
STS (Space Shuttle) को एक खतरनाक सिस्टम बताया गया, जिसमें emergency escape mode कमजोर था और हर launch पर thermal protection tiles को बार-बार नुकसान पहुँचता था। इसे 'normalization of deviance' का उदाहरण माना गया, और यह अंतर्दृष्टि दी गई कि सिर्फ दो बार विस्फोट होना ही शायद किस्मत थी। साथ में संबंधित कॉलम भी साझा किया गया: [https://danluu.com/wat/]
यह भी समझाया गया कि बड़े रॉकेट का तर्क operational cost के दृष्टिकोण से SpaceX/Musk की रणनीति है; आकार बढ़ने पर प्रति payload unit लागत कम की जा सकती है.
SpaceX द्वारा methane-based full-flow staged combustion engine विकसित करने में आ रही कठिनाइयों को दिलचस्प बताया गया। सोवियत अनुभव से पहले से ही पता था कि ऐसे इंजन बेहद कठिन होते हैं, लेकिन हाल तक यह सब अच्छा चलता दिख रहा था, इसलिए उम्मीदें ऊँची थीं। अब लगता है कि SpaceX की तेज़ी से iterate करके विफलताओं से सीखने वाली विशिष्ट संस्कृति शायद अपनी सीमाओं के करीब पहुँच रही है.
यह राय दी गई कि अभी पर्याप्त प्रमाण नहीं हैं कि समस्या Raptor इंजन में ही है। चूँकि यह static fire से ठीक पहले की स्थिति भी नहीं थी, इसलिए इंजन के अलावा अन्य कारणों की संभावना अधिक मानी गई। SpaceX की परीक्षण शैली को हमेशा रोमांचक बताया गया.
यह जानकारी दी गई कि SpaceX subreddit में अफवाहें चल रही हैं कि मुख्य इंजीनियर leadership और organizational culture की समस्याओं के कारण लगातार जा रहे हैं। हाल की असफलताओं की अधिकता कुछ संदेह ज़रूर पैदा करती है, लेकिन इन अफवाहों की विश्वसनीयता अस्पष्ट मानी गई.
ऊपर दिए गए हाई-क्वालिटी slow-motion वीडियो [https://x.com/dwisecinema/status/1935552171912655045] के आधार पर कहा गया कि समस्या का कारण लगभग निश्चित रूप से pressure tank defect दिखता है, न कि इंजन की मूल खराबी.
यह अनुभव साझा किया गया कि Starship testing में v1 आशाजनक था, लेकिन v2 पर आते-आते गंभीर समस्याएँ तेज़ी से बढ़ गईं। hardware-centric development approach अच्छी है, लेकिन शायद बहुत तेज़ प्रगति या ज़रूरत से ज़्यादा बदलाव उल्टा नुकसानदेह रहे.
यह भी कहा गया कि समस्या इंजन से अधिक उस plumbing system में रही है जिसे अलग-अलग attitude changes के दौरान भी fuel सही तरह से पहुँचाना होता है.
यह दृष्टिकोण सामने आया कि यह बात बहुत अशुभ और गंभीर लगती है कि विस्फोट किसी तयशुदा टेस्ट के दौरान नहीं, बल्कि टेस्ट शुरू होने से पहले ही हो गया। टेस्टिंग प्रक्रिया में विफलता समझी जा सकती है, लेकिन शुरुआत से पहले ही पूरा सिस्टम नष्ट हो जाना खतरे का संकेत है.
इस पर ज़ोर दिया गया कि fuel loading शुरू होते ही बड़े विस्फोट का जोखिम शुरू हो जाता है; जोखिम सिर्फ इंजन ignition के क्षण में नहीं होता, उससे पहले भी electrical fire या structural defect जैसे खतरे मौजूद रहते हैं.
याद दिलाया गया कि ऐसा कुछ Falcon 9 के साथ भी पहले हो चुका है.
कई साल पहले lunch break के दौरान संयोग से शोरगुल करते हुए बात कर रहे SpaceX इंजीनियरों की बातें सुन लेने का अनुभव साझा किया गया। कहा गया कि वे कंपनी के मिशन या जुनून की नहीं, बल्कि TikTok पर "day in the life" followers बढ़ाने, पैसे की शेखी बघारने और Las Vegas में तेज़ रफ्तार ड्राइविंग जैसी निजी बातों पर चर्चा कर रहे थे; यह सुनकर झटका लगा। यह महसूस किया गया कि जब कर्मचारियों में काम के गर्व या मिशन से ज़्यादा self-promotion और निजी जीवन केंद्र में आ जाए, तो यह red flag है, और शायद ऐसे रवैये का हाल की घटनाओं से भी संबंध हो सकता है.
यह जिज्ञासा जताई गई कि भले ही पूरे vehicle का नुकसान हुआ हो, लेकिन चूँकि कोई घायल नहीं हुआ, तो क्या यह वास्तव में SpaceX के लिए बड़ा झटका है, या फिर विकास प्रक्रिया में सीमाओं तक धकेलते हुए सीखने वाला एक सामान्य setback—यानी "यह कितना गंभीर है" यह जानने की इच्छा व्यक्त की गई.
कहा गया कि सामान्य project में यह काफी बड़ी घटना मानी जाती, और root cause analysis व follow-up action में काफी resources लगते; लेकिन SpaceX की engineering culture में परिणाम का अनुमान लगाना कठिन है.
एक राय यह भी थी that यह वास्तव में बड़ी failure है और साइट recovery व पुनर्सज्जा के कारण आगे के launches में बड़ा delay आएगा। इंजन ignition से पहले ही ऐसा घातक defect सामने आना गंभीर design flaw का संकेत माना गया.
दूसरी ओर यह विश्लेषण भी था कि pad repair का समय मुख्य मुद्दा है, इसलिए यह अपेक्षाकृत छोटा setback हो सकता है। संदर्भ दिया गया कि Starship अभी भी development में है और विस्फोट असामान्य नहीं हैं। AMOS-6 हादसे की तरह यदि राजनीतिक माहौल जुड़ जाए तो मामला बड़ा बन सकता है; AMOS-6 static fire से पहले फटा था, जिसके बाद static fire के समय payload के बिना परीक्षण की प्रथा बनी। Starship में अभी payload नहीं था, और इस बार भी कारण-परिणाम संबंध अपेक्षाकृत जल्दी स्पष्ट हो सकता है.
यह भी आकलन किया गया कि सिर्फ एक development vehicle का खोना घातक नहीं है; अधिक समय तो शायद ground equipment की मरम्मत में लगेगा। अगला टेस्ट करने से पहले कारण पता करना ज़रूरी है, लेकिन इसे बहुत बड़ा setback नहीं माना गया.
फिर भी इस बात को लेकर जोखिम स्तर ऊँचा माना गया कि सिस्टम टेस्ट तक पहुँचने से पहले ही टूट गया; टेस्ट के दौरान नहीं, तैयारी चरण में दुर्घटना होना और भी ज्यादा खतरनाक माना गया.
इसे अस्थिर और लंबे समय तक न चल सकने वाली failure rate बताया गया। यह अटकल भी लगाई गई कि लागत के दबाव में SpaceX फंड जुटाने के लिए public हो सकता है, और यदि ऐसा हुआ तो सफलता के प्रति जवाबदेही बढ़ जाएगी। तकनीकी उपलब्धियाँ प्रभावशाली मानी गईं और Falcon program की सफलता भी प्रमाणित बताई गई, लेकिन एक Starship stack की अनुमानित लागत लगभग 100 million dollars है या नहीं, यह पूछा गया.
इसके जवाब में कहा गया कि public होने की खास जरूरत नहीं है; Musk जरूरत पड़ने पर निजी तौर पर कई billions dollars जुटाते रहे हैं। Starlink और Falcon 9 की वजह से कंपनी-स्तर पर cash flow अच्छा और profitability पर्याप्त मानी गई। वर्तमान R&D funding भी मजबूत track record के आधार पर संभव मानी गई। यह भी कहा गया कि public होने पर Tesla के शुरुआती दिनों जैसी स्थिति दोहर सकती है, जब समग्र profitability सुनिश्चित न होने से शुरुआती अनिश्चितता अधिक थी.
एक मत में पूरे Starship set की लागत 100 million dollars मानी गई, लेकिन साथ ही कहा गया कि SLS की प्रति launch लागत 4 billion dollars है, इसलिए Starship का प्रति-प्रयास failure तुलनात्मक रूप से बहुत सस्ता और टिकाऊ है। इसे इस साल की पहली स्पष्ट विफलता कहा गया; पहले के कुछ परीक्षण पूर्ण सफलता नहीं थे, लेकिन चरणवार reusability साबित करने के लिहाज़ से अर्थपूर्ण थे। सकारात्मक विश्लेषण यह था कि आगे और कई असफलताएँ भी SLS से सस्ती पड़ेंगी.
यह सवाल उठाया गया कि SpaceX तीन-चरणीय रॉकेट के बजाय सिर्फ दो-चरणीय reusable architecture पर इतना अड़ा क्यों है। पूरी reusability पाने की कोशिश में thermal protection tiles, fuel margin आदि के रूप में भारी weight penalty जुड़ गई है, जबकि multi-stage separation वाला ढाँचा payload के लिहाज़ से बेहतर हो सकता था; इसलिए इसे रणनीतिक गलती माना गया। कहा गया कि हर नया version आखिरकार बड़े fuel tanks और छोटे payload की दिशा में जा रहा है.
इसके जवाब में कहा गया कि Mars landing और return mission या बड़े payload transport के लिए 3-stage उल्टा कम उपयुक्त है। 3-stage संरचना GEO जैसी one-off missions या छोटे payload के लिए ठीक है, जबकि Starship ऐसे उपयोगों के लिए डिज़ाइन किया गया रॉकेट नहीं है.
यह भी कहा गया कि ultimate goal पूरी और तेज़ reusability है, और यदि रॉकेट launch विमानों की तरह बार-बार होने लगें तो औद्योगिक क्रांति जैसी बदलाहट आ सकती है। Falcon 9 की market share ही दिखाती है कि reusability कितनी disruptive है, और विश्वास जताया गया कि Starship सफल हुआ तो खेल बदल देगा.
एक समस्या यह बताई गई कि second stage पृथ्वी के दूसरी ओर उतर सकती है, जिससे उसे वापस लाना कठिन हो जाता है। हालांकि सैद्धांतिक रूप से sea-level engines लगाए जाएँ और fuel refill हो सके, तो उसे फिर से उड़ाना संभव हो सकता है.
रॉकेट इंजीनियरिंग के दृष्टिकोण से कहा गया कि यदि अच्छा specific impulse और ठीक-ठाक mass ratio मिल जाए, तो LEO transport के लिए two-stage सबसे उपयुक्त हो सकता है; stage बढ़ने पर वजन, system complexity और failure points भी बढ़ते हैं.
यह भी समझाया गया कि 3-stage rocket को reusable बनाना हो तो second stage पर भी heat shield चाहिए होगा, जिससे upper stage का आकार और payload दोनों काफ़ी कम हो जाएँगे, इसलिए यह कम लाभकारी है.