चंद्र मिशन "बेरीशिट" - दुर्घटना की प्रारंभिक वजह की घोषणा की

बरेशिट तंत्र के चंद्र सतह पर गिरने के 6 दिन बाद, स्पेसिल टीम ने आधिकारिक तौर पर 11 अप्रैल, 2019 को चंद्रमा दुर्घटना के पेचीदा संस्करण की घोषणा की। और जो हुआ उसके बारे में और भी सवाल हैं।

04/18/2019 को दुर्घटना की अद्यतन जानकारी।

इस प्रकाशन को जारी रखने में।

बेरेशिट डिवाइस (चंद्र सतह से 15 किमी) की नवीनतम स्पेसल आधिकारिक तस्वीर:



इस फ़ोटो का स्थान संदर्भ यहां दिया गया है:



दुर्घटना की जांच के प्रारंभिक परिणाम: लैंडिंग की प्रक्रिया में, कमांड ऑन-बोर्ड कंप्यूटर द्वारा सक्रिय किया गया था, जिसके निष्पादन से मिशन के लिए घातक परिणाम हुआ



यहां बेरेसैट के लैंडिंग पैंतरेबाज़ी की प्रारंभिक जांच के निष्कर्ष हैं: ऐसा प्रतीत होता है कि लैंडिंग प्रक्रिया के दौरान एक कमांड दर्ज किया गया था, जिसके कारण एक श्रृंखला प्रतिक्रिया हुई, जिससे मुख्य इंजन बंद हो गया और इसे पुन: सक्रिय होने से रोका गया।

"ऐसा लगता है कि लैंडिंग प्रक्रिया के दौरान एक कमांड पेश किया गया था , जिसके कारण एक चेन रिएक्शन हुआ, जिसके कारण इंजन का मुख्य इंजन बंद हो गया और इसे आगे काम करना फिर से शुरू नहीं करने दिया।"

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

स्पेसिल द्वारा की गई प्रारंभिक जांच के अनुसार, एक कमांड ने बेरेसैट अंतरिक्ष यान की जड़त्वीय मापन इकाई में से एक में खराबी को ठीक करने का इरादा किया , जिससे लैंडिंग के दौरान इसके मुख्य इंजन को बंद कर दिया गया।

इस प्रकार, यह संभव है कि यह एक कार्यक्रम / मानव त्रुटि थी (आदेश एमसीसी में ऑपरेटर या इंजीनियरों द्वारा दर्ज किए गए थे) बर्शित तंत्र को उतारने की प्रक्रिया में।

आदेश और Bereshit डिवाइस के साथ ऑपरेटिंग मोड की सूची को केवल SpaceIL MCC से अनुमोदित और प्रेषित किया गया था। स्पेसिल इंजीनियरों ने डिवाइस के ऑन-बोर्ड कंप्यूटर के लिए पैच बनाए, उनकी संचालन क्षमता और कार्यक्षमता की जाँच की, और लैंडिंग प्रक्रिया के लिए कमांड भी तैयार किए।

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

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

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



यह आदेश जानबूझकर या गलती से पेश किया गया था, जिसके कारण दुर्घटना हुई - यह तथ्य बंद रहेगा, सबसे अधिक संभावना है, हालांकि हम निकट भविष्य में स्पेसिल से अंतिम परिणामों की प्रतीक्षा कर रहे हैं, जिसे उन्होंने प्रकाशित करने का वादा किया था।

बेरेशिट डिवाइस के हार्डवेयर और सॉफ्टवेयर घटकों के बारे में क्या जाना जाता है:

- ऑन-बोर्ड कंप्यूटर एक (1) है, डुप्लिकेट नहीं है (चंद्रमा पर उड़ान के दौरान कई कंप्यूटर रिबूट थे);

- नियंत्रण कार्यक्रम कोड, कमांड और ऑन-बोर्ड कंप्यूटर के साथ काम - सी भाषा में;

- इस तथ्य के कारण कि केवल एक कंप्यूटर है, पुनरारंभ करने पर सभी अपडेट (पैच) मिट जाते हैं और उन्हें सिस्टम में फिर से डाउनलोड करने की आवश्यकता होती है;

- कम डेटा ट्रांसफर गति: एक उच्च-रिज़ॉल्यूशन तस्वीर (एक 8 Mpx कैमरा से) 40 मिनट लोड होती है;

- डीएलआर (जर्मन एयरोस्पेस सेंटर) ने बेरेशिट वाहन के लैंडिंग तंत्र का परीक्षण किया;

- स्पेसिल एमसीसी में एक टीम: अधिकांश अंतरिक्ष इंजीनियर और भौतिक विज्ञानी हैं, कई युवा वैज्ञानिक और इंजीनियर जो सिर्फ उपग्रह नियंत्रण प्रणालियों का अध्ययन कर रहे हैं।

इस घातक आदेश के साथ कोड कब लागू किया जा सकता है? सबसे अधिक संभावना है, जब लैंडिंग प्रक्रिया के लिए तैयारी कर रहे हैं।

लेकिन ऑन-बोर्ड कंप्यूटर में कमांड तब काम करता है जब उपकरण "नो रिटर्न ऑफ पॉइंट" पास कर चुका होता है, जब केवल ऑन-बोर्ड कंप्यूटर द्वारा नियंत्रित स्वचालित लैंडिंग प्रक्रिया शुरू होती है।

हालांकि स्पेसिल एमसीसी लैंडिंग के दौरान डिवाइस के साथ स्थिति को प्रभावित करने के लिए मैनुअल कंट्रोल मोड में एक प्रयास था।

लैंडिंग साइट से 800 किमी की दूरी पर, रोपण प्रक्रियाएं शुरू होती हैं:



बेर्किट डिवाइस को MCC से कई आदेश प्राप्त होंगे:



लैंडिंग सेंसर (प्राथमिक और बैकअप) सक्रिय हो जाएंगे:



बेरेशिट तंत्र की स्थिति (अभिविन्यास) को बदलने की प्रक्रिया शुरू की जाएगी:



बोर्डिंग से पहले प्रारंभिक प्रक्रिया पूरी करने के बाद, बेरीसिट ऑन-बोर्ड कंप्यूटर और एमसीसी के पास सिस्टम की स्थिति और बोर्डिंग के लिए उनकी तत्परता का आकलन करने का अवसर होगा; यदि कुछ सही ढंग से काम नहीं करता है, तो बोर्डिंग प्रक्रिया को रद्द कर दिया जाएगा, अगर सब कुछ सामान्य होता है, तो अगले चरण के बाद शुरू होता है; लैंडिंग अब रद्द नहीं होगी:



यदि सब कुछ ठीक से काम कर रहा है, तो बेर्सेट तंत्र अपनी कक्षीय गति को कम करना शुरू कर देगा और मुख्य और सहायक इंजनों का उपयोग करते हुए चंद्र की सतह तक दूरी कम करेगा, इस प्रक्रिया में 15 मिनट लगेंगे:



लैंडिंग वीडियो:



लैंडिंग वीडियो के अनुसार, डिवाइस के साथ क्या हुआ (समय वीडियो से संकेत मिलता है):

23:03 टेलीमेट्री संकेतक हरा हो गया। मोड: अभिविन्यास।
25:04 मोड: ब्रेक लगाना।
25:20 पारित किया "कोई वापसी नहीं की बात।"
25:26 बिना किसी रिटर्न के बिंदु का सूचक काला हो गया है।
25:52 वर्टिकल स्पीड इंडिकेटर हरा है।
28:16 टेलीमेट्री सूचक हरा होना बंद हो गया है।
28:20 टेलीमेट्री सूचक एक पल के लिए हरा हो गया, फिर हरा हो गया।
29.37 दूरी: 210 किमी।
29:50 दूरी 385 किमी में बदलती है।
30:03 दूरी 370 किमी में बदलती है।
30:40 टेलीमेट्री संकेतक हरा हो गया।
30:51 314 किमी की दूरी में परिवर्तन।
31:33 चंद्रमा के साथ दिखाया गया सेल्फी चित्र। 22 किमी के बारे में ऊंचाई? टेलीमेट्री संकेतक हरा हो गया।
31:50 टेलीमेट्री संकेतक हरा होना बंद हो गया है।
31:55 से 32:29 "[अश्राव्य] उसे मार डालो (प्रक्रिया?)।" "[यहां तक ​​कि अश्रव्य] व्यस्त"
(इमरजेंसी स्थिति से निपटने के लिए इंजीनियर पहले से ही मैनुअल कंट्रोल में हैं)
32:48 टेलीमेट्री स्क्रीन प्रदर्शित की गई है। टेलीमेट्री सूचक पीला है। ऊंचाई 14095 मीटर। क्षैतिज गति 955.5 मीटर / सेकेंड। लंबवत गति 24.8 मी। / से। मुख्य इंजन चालू है। क्षैतिज गति सेल पीला है। टेलीमेटरी इंडिकेटर को छोड़कर अन्य मापदंडों को हरे रंग में दिखाया गया है।
32:49 सभी इंजन चालू हैं।
32:51 सभी इंजन बंद हैं।
32:55 मुख्य इंजन चालू है।
32:57 सभी इंजन चालू हैं।
32:59 मुख्य इंजन चालू है। दूरी: 183.8 किमी
33:01 - 33:03 "IMU सेंसर आदेश से बाहर है"
33:02 सभी इंजन चालू हैं।
33:05 मुख्य इंजन चालू है।
33:07 सभी इंजन चालू हैं।
33:09 मुख्य इंजन चालू है।
33:11 सभी इंजन चालू हैं।
33:13 मुख्य इंजन चालू है।
33:16 सभी इंजन चालू हैं।
33:20 टेलीमेट्री संकेतक हरा हो गया। सभी इंजन बंद हैं। सभी तस्वीरें जम गईं (रीडिंग में कोई बदलाव नहीं)।
33:32 टेलीमेट्री सूचक हरा होना बंद हो गया है। सभी इंजन बंद हैं। सभी तस्वीरें जम गईं (रीडिंग में कोई बदलाव नहीं)।
34:24 टेलीमेट्री संकेतक हरा हो गया। सभी इंजन बंद हैं।
36:25 - 36:33 "मुख्य इंजन के साथ समस्याएं।" हम इंजन चालू करने के लिए ऑन-बोर्ड कंप्यूटर को पुनरारंभ करते हैं। ”

लैंडिंग प्रक्रिया के दौरान उद्घोषक और इंजीनियरों के शब्दों को लिखने का प्रयास (समय अलग है, लेकिन सार और सेकंड समान हैं):

7:37:37 - IMU2 ठीक नहीं है
7:37:50 - [स्पष्ट नहीं] इसे सक्षम करने का प्रयास करेंगे।
7:37:57 - कोई यह पूछ रहा है कि क्या यह [अस्पष्ट है 'यह' है) हमें 2 के लिए स्वाथ करेगा [कुछ]
7:38:10 - JPL से खोया हुआ कनेक्शन
7:38:34 - हमने एक IMU खो दिया और हमने JPL से संबंध खो दिया, दोनों को संबंधित नहीं होना चाहिए।
[पृष्ठभूमि में कोई व्यक्ति IMU को पुनः आरंभ करने के बारे में कुछ कहता है]
7:38:39 - IMU2 को सक्षम न करें
7:38:52 - आप स्क्रीन पर जो देख रहे हैं वह सही नहीं है, वर्तमान में कोई टेलीमेट्री नहीं है
7:39:06 - [अंग्रेजी में] हमने टेलीमेट्री खो दी, लेकिन हमारे पास अब टेलीमेट्री है।
7:39:23 - हमने 10 किमी की ऊँचाई को पार किया
7:39:29 - 900 मीटर / सेकंड से नीचे का वेग
7:39:34 - याद दिलाएं कि हमें 0 के वेग तक पहुंचने की आवश्यकता है
7:39:47 - इंजन चल रहा है दबाव में वृद्धि [अस्पष्ट] से 5 बार [?], "दिलचस्प"?
7:39:52 - दूसरी छवि डाउनलोड की गई।
7:40:06 - [अनाउंसर ने लेजर लैंडिंग सेंसर के बारे में कुछ कहना शुरू किया]। [पृष्ठभूमि में - अस्पष्ट लेकिन ऐसा लगता है जैसे उन्होंने कहा कि इंजन नहीं चल रहा है]
7:40:13 - हमें मुख्य इंजन के साथ समस्या हो सकती है।
7:40:17 - एक रीसेट करें [उन्होंने प्रसारण में पहले उल्लेख किया था कि वे लैंडिंग प्रक्रिया के दौरान अंतरिक्ष यान को कमांड भेज सकते हैं]
7:40:24 - आप क्या चाहते हैं?
7:40:28 - स्थिति अच्छी नहीं लगती है, कोई मुख्य इंजन नहीं है।
7:40:33 - दूसरी छवि प्राप्त की।
7:40:40 - ऊंचाई खोना
7:41:07 - [अंग्रेजी में] हमें लगता है कि मुख्य इंजन के साथ एक समस्या है, हम इंजन को सक्षम करने के लिए अंतरिक्ष यान को रीसेट कर रहे हैं।
7:41:10 - क्या [अस्पष्ट] भेजने की मंजूरी है?
7:41:15 - मुख्य इंजन अब चल रहा है, [दबाव माप] पर आधारित
7:41:19 - मुख्य इंजन वापस। [और फिर से अंग्रेजी में]
7:41:27 - ऊंचाई की खोई हुई स्थिति, स्थिति अस्पष्ट।
7:41:32 - जेपीएल के साथ खोया हुआ संबंध
7:41:45 - अब हमारे पास केवल ssc [??] नासा के माध्यम से कनेक्शन नहीं है, लेकिन हमारे पास अंतरिक्ष यान के साथ एक संबंध है।
7:41:49 - लॉस्ट टेलीमेट्री
7:41:52 - अब हम बिना टेलीमेट्री के हैं
7:41:57 - [अंग्रेजी] मुख्य इंजन चालू है लेकिन हमने संचार खो दिया है
7:42:10 - हम [अस्पष्ट] से [उद्भव] के लिए एक पल इंतजार करेंगे
7:42:17 - हमें संदेह है कि हम अभी भी मूल्यांकन नहीं कर रहे हैं
7:42:56 - हम बिना टेलीमैट्री के हैं और शक है कि हमने अंतरिक्ष यान खो दिया।
7:43:16 - सभी संकेत हैं कि दुर्भाग्य से हम चंद्रमा पर उतरने वाले चौथे राष्ट्र नहीं होंगे।
7:43:33 - हम चाँद पर हैं, लेकिन कोई रास्ता नहीं है जो हम बनना चाहते थे।

MCC के डेटा के अनुसार डिवाइस के जीवन के अंतिम 4 सेकंड (678 से 149 मीटर की कमी):









19:23 बजे टेलीमेट्री डेटा पूरी तरह से आना बंद हो गया।

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

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

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

वैसे, बेरेशिट तंत्र चंद्रमा की कक्षा में था और लैंडिंग के दौरान ऑनबोर्ड मैग्नेटोमीटर का इस्तेमाल किया और चंद्रमा के चुंबकीय क्षेत्र पर स्पेसिल एमसीसी से कुछ वैज्ञानिक डेटा प्रसारित किया।

इस प्रकार, उन्होंने फिर भी अपने वैज्ञानिक छोटे कार्यक्रम का हिस्सा पूरा किया!

दुर्घटना के मामले में गलती से अपडेट किया गया डेटा :

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

जांच के दौरान, यह पाया गया कि उड़ान नियंत्रण केंद्र से भेजे गए आदेशों में से एक को निष्पादित नहीं किया गया था, जिसके कारण बाद की विफलताओं की एक श्रृंखला हुई: इंजन ने काम करना बंद कर दिया और डिवाइस सतह पर गिर गया।

एक्सेलेरोमीटर सेंसर के संचालन में खराबी का पता चला था, जिसे यूएमआई (त्वरण के लिए जिम्मेदार) कहा जाता है। यह अभी तक ठीक से स्थापित नहीं किया गया है कि विफलता का पालन क्यों किया गया, जिसके कारण बाद में सिस्टम की नकारात्मक प्रतिक्रियाएं हुईं।

एक्सीलरेशन सेंसर को सक्रिय करने की कमान स्पेसिल एमसीसी से भेजी गई थी।

विफलता के बाद, वैकल्पिक तरीकों से इंजन को फिर से शुरू करने का प्रयास किया गया, लेकिन वे असफल रहे।

सब कुछ सबसे गंभीर अस्थायी समय के दबाव में हुआ: मिशन के अंतिम सेकंड में एक विफलता हुई, जो अंत में पूरी नहीं हो सकी।

बेरेशिट तंत्र के ऑन-बोर्ड कंप्यूटर ने भी इंजन को स्वायत्तता से फिर से चालू करने की कोशिश की - इस तरह के 5-6 प्रयास थे। लेकिन वे सभी असफल थे।

संभवतः, स्पेयर मॉड्यूल (IMU2) पर स्विच करने के लिए उपकरण पर इंजीनियरों के बीच आदेशों का एक असंगत निष्पादन हुआ, जिसने नई समस्याओं और दुर्घटनाओं को आगे बढ़ाया।

अंतरिक्ष यान IMU 1 का उपयोग कर रहा था और शुरू में IMU 2 की विफलता से प्रभावित नहीं था।

एक इंजीनियर पूछता है कि क्या उन्हें IMU 2 को सक्षम करने का प्रयास करना चाहिए और दूसरा इंजीनियर पूछता है 'क्या इससे सिस्टम को स्विच करने का कारण होगा (संभवतः' इसका अर्थ है IMU 2)।

शायद 2 वें इंजीनियर से सावधानी के शब्द के बावजूद किसी ने IMU 2 को फिर से शुरू करने के प्रयास के लिए एक आदेश भेजा और शायद यही कारण है कि वे एक खराब कमांड द्वारा घटनाओं की श्रृंखला शुरू करते हैं ...