चंद्र कंप्यूटर की कहानियां। भाग २

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

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

हाल की वास्तुकला ने एक ऑपरेटिंग सिस्टम के नुकसान से बचा था जिसमें गणनाओं को समय अवधि के बीच स्पष्ट रूप से विभाजित किया जाना चाहिए। ऐसी प्रणालियों को लागू करना काफी कठिन है, क्योंकि कार्य मनमाने ढंग से बदल सकते हैं। जब विकास प्रक्रिया के दौरान कार्यों को जोड़ा या बदला जाता है, तो कार्य योजना में बदलाव की आवश्यकता हो सकती है। सबसे बुरी बात यह है कि ऑन-बोर्ड कंप्यूटर का मौजूदा ऑपरेटिंग सिस्टम बहुत नाजुक है, इस अर्थ में कि यह पूरी तरह से विफल हो जाता है अगर कार्य आवंटित होने में अधिक समय लगता है।

इसके बजाय, लेनिंग ने एक प्रणाली विकसित की जिसमें कार्यक्रम कार्यों को "कार्यों" के रूप में वितरित किया जाता है, जो किसी भी आकार का हो सकता है जो इन कार्यों को करने के लिए आवश्यक होगा। प्रत्येक कार्य को प्राथमिकता दी जाती है। ऑपरेटिंग सिस्टम हमेशा सर्वोच्च प्राथमिकता के साथ कार्य करता है। यदि कम प्राथमिकता वाला कार्य किया जाता है, और उच्च प्राथमिकता वाला कार्य इस समय सौंपा जाता है, तो कम प्राथमिकता वाले कार्य को तब तक निलंबित रखा जाएगा जब तक कि उच्च प्राथमिकता वाला कार्य पूरा नहीं हो जाता। इस तरह की प्रणाली हमें यह भ्रम देती है कि कार्यों को एक साथ किया जाता है, हालांकि वास्तव में, कार्यों को बदले में किया जाता है। ऐसी प्रणाली नियतात्मक नहीं है, लेकिन इसके कार्यों को समझा जा सकता है और इसे सत्यापित किया जा सकता है, और यह विश्वसनीयता, सुरक्षा, उपयोग में लचीलापन और, विशेष रूप से, विकास में आसानी को बढ़ाता है।

कार्यकारी ( वास्तविक समय ऑपरेटिंग सिस्टम एजीसी और एलजीसी। अप्रोच। ट्रांसलेशन। ) कार्यों के निष्पादन को इस तरह से व्यवस्थित करता है कि प्रत्येक कार्य अपने राज्य को रजिस्टरों के सेट के रूप में बनाए रखता है, और राज्य को बनाए रखा गया था, जबकि कार्य उच्च प्राथमिकता के साथ किया जा रहा था। एलजीसी में 12 रजिस्टरों के आठ सेटों की एक सरणी होती है, प्रति रजिस्टर 15 बिट्स। इस आकार के रजिस्टरों का एक सेट कई कार्यों को करने के लिए पर्याप्त है, लेकिन वे कार्य जो दुभाषिया का उपयोग करते हैं ( दोहरे सटीक संख्याओं के साथ काम करने वाले कार्यों के लिए एक अंतर्निहित इंटरप्रिटिंग भाषा। Approx। Transl। ) वेक्टर और मैट्रिक्स गणना करने के लिए अधिक स्थान की आवश्यकता होती है। ऐसे कार्यों के लिए, 43 रजिस्टरों का एक अलग सरणी आवंटित किया जाता है। एलजीसी में पांच ऐसे ऐरे (वेक्टर एक्युमुलेटर, वीएसी) शामिल हैं।

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

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

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

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

कार्यक्रम में उपयुक्त बिंदुओं पर "वेपॉइंट्स" दर्ज करके सुरक्षा को फिर से शुरू किया गया था, इस तरह से व्यवस्थित किया गया था कि अंतिम "वेपॉइंट" पर लौटने से त्रुटि नहीं हुई, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

NEW_X = X + 1

X = NEW_X

जाहिर है, वेपॉइंट को पंजीकृत किए बिना, इस कोड को दूसरी बार निष्पादित करने से एक्स को फिर से वृद्धि होगी।

पुनः आरंभ करने के बाद, इस तरह का कार्यक्रम अपने काम को फिर से शुरू करता है। प्रत्येक कार्य अंतिम पंजीकृत तरीके से शुरू होता है। यदि एक ही कार्य की कई प्रतियाँ कतार में थीं, तो केवल अंतिम एक ही शुरू होती है। कुछ कार्यों में महत्वपूर्ण स्थिति नहीं होती है, और पुनरारंभ से संरक्षित नहीं होते हैं। वे बस गायब हो जाते हैं।

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

(हाइब्रिड सिम्युलेटर में एसडीएस 9300 डिजिटल कंप्यूटर और एक बेकमैन एनालॉग कंप्यूटर, एक वास्तविक एजीसी कंप्यूटर और कमांड और चंद्रमा मॉड्यूल के लिए यथार्थवादी कॉकपिट मॉडल शामिल थे।)



अपोलो की प्रारंभिक तैयारी।

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

ये कार्य कार्यकारी प्रणाली द्वारा किए गए थे यदि संसाधन समाप्त हो गए थे। यदि कार्य इस तथ्य के कारण निर्धारित नहीं किया जा सकता है कि रजिस्टर को बचाने के लिए कोई मुफ्त सरणियाँ नहीं हैं, तो कार्यकारी कोड जिसे BAILOUT के साथ त्रुटि कोड 1202 है। यदि कोई मुक्त VAC नहीं था, तो BAILOUT कोड 1201 के साथ बुलाया गया था।

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

अन्य व्यवधानों का उपयोग कोड के टुकड़ों को निष्पादित करने के लिए किया जा सकता है जो एक विशिष्ट समय पर निष्पादित होने चाहिए। इस तरह के कार्यों को कार्य कहा जाता था, और वे एक उप-समूह में अनुसूचित थे जिन्हें WAITLIST कहा जाता था। "कार्य" के लिए बहुत कम समय का नेतृत्व करना चाहिए था।

जबकि एक निश्चित प्राथमिकता के साथ निष्पादन के लिए "कार्यों" की योजना बनाई गई थी, लेकिन एक निश्चित समय में लॉन्च के लिए "कार्यों" की योजना बनाई गई थी। कार्य और कार्य अक्सर साझा किए जाते थे। कार्य को सेंसर रीडिंग को पढ़ने के लिए लॉन्च किया जा सकता है, जिसे कड़ाई से परिभाषित समय पर पढ़ा जाना चाहिए, और कार्य, बदले में, इन रीडिंग को संसाधित करने के लिए एक निश्चित प्राथमिकता के साथ एक कार्य लॉन्च किया।

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



जाइरोस्कोप की विधानसभा।

* * *

वंश के दौरान अपोलो 11 पर अलार्म के मूल कारण को समझने के लिए, कमांड मॉड्यूल के साथ सन्निकटन प्रक्रिया पर विचार करना आवश्यक है, जो चंद्र सतह से चंद्र की कक्षा तक चंद्र मॉड्यूल के उदय के बाद होता है। जिस तरह हम चंद्रमा पर उतरते समय चंद्र सतह के सापेक्ष ऊँचाई और गति को मापने के लिए एक लैंडिंग रडार का उपयोग करते हैं, उसी तरह चंद्र की कक्षा में कमांड मॉड्यूल से संपर्क करते हुए दृष्टिकोण रडार का उपयोग करके दूसरे जहाज के सापेक्ष दूरी, गति और दिशा को मापने की आवश्यकता होती है।

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

(तीन रैप्टरमेंट रडार ऑपरेटिंग मोड के नाम कुछ टिप्पणीकारों के लिए शर्मिंदगी का स्रोत थे। चालक दल के अनुरोध पर, मिशन LM-1 के बाद और चंद्रमा पर मिशन लैंडिंग से पहले पदनाम बदल दिए गए थे। अपोलो 11 जिसे LGC कहा जाता था, उसे पूर्व में AUTO कहा जाता था। वह मोड)। इसे अपोलो 11 पर ऑटो कहा जाता था, जिसे पहले MANUAL कहा जाता था। SLEW मोड का नाम अपरिवर्तित रहा। हालांकि इसने किसी भी तरह से अपोलो 11 पर समस्या का योगदान नहीं दिया, असतत चैनल 33 से संबंधित अनुभाग में आंतरिक ल्यूमिनेरी प्रलेखन, उस समय भी फिर से बुलाया गया। निकटवर्ती रडार के साथ LGC बेंचमार्क RR AUTO-POWER ON द्वारा चालू किया गया।)

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

यह पता चला कि अप्रोच रडार भी वंश के दौरान काम कर सकता है, और यह अपोलो 11 के वंश के दौरान किया गया था। चालक दल के निर्देश की आवश्यकता है कि रडार को P63 चरण की शुरुआत से तुरंत पहले चालू किया जाए और पूरे लैंडिंग पैंतरेबाज़ी के लिए SLEW या AUTO मोड में बने रहें।

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



चित्रा 7. पीजीएनएस, एटीसीए और निकटता रडार इंटरफेस

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

सालों पहले, इंटरफ़ेस कंट्रोल डॉक्यूमेंट (ICD) पर डॉक्यूमेंटेशन लिखा गया था, जो PGNS और ATCA (रवैया और ट्रांसलेशन कंट्रोल असेंबली) इलेक्ट्रॉनिक्स के बीच इलेक्ट्रिकल इंटरफेस को परिभाषित करता है, जिसे लैंडिंग मॉड्यूल बनाने वाली कंपनी ग्रुम्मन एयरोस्पेस द्वारा आपूर्ति की गई थी। आईसीडी ने निर्धारित किया कि दो प्रणालियों में 800 हर्ट्ज की आवृत्ति के साथ 28 वी बिजली आपूर्ति सर्किट को आवृत्ति में संरेखित किया जाना चाहिए, लेकिन यह नहीं लिखा है कि उन्हें चरण में सिंक्रनाइज़ किया जाना चाहिए। वास्तव में, दो सिस्टम LGC द्वारा भेजे गए "फ्रीक्वेंसी सिंक" सिग्नल के साथ संरेखित थे। उनके बीच एक निरंतर चरण संबंध था। हालांकि, दो वोल्टेज के बीच का चरण एक पूरी तरह से यादृच्छिक चर था, इस समय के आधार पर, जिस पर LGC, जिसे हमेशा ACTA के बाद संचालित किया जाता था, एक तुल्यकालन संकेत भेजने लगा। इन इंटरफेस को अंजीर में दिखाया गया है। 7।

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

अपोलो 11 पर, हालांकि, सीडीयू ने अलग तरह से काम किया। चूंकि वे अलग से उत्पन्न वोल्टेज को संदर्भ संकेत के रूप में लेते हैं, इसलिए सीडीयू द्वारा प्राप्त एंटीना कोण सेंसर संकेतों ने एक अज्ञात कोण दिखाया। त्रुटि सबसे बड़ी थी यदि चरण अंतर 90 या 270 डिग्री के करीब था, और अपोलो 11, जाहिर है, इन दिलचस्प बिंदुओं में से एक को मारा। जवाब में, सीडीयू ने लगभग निरंतर गति से एलजीसी काउंटरों को बढ़ाना या घटाना शुरू किया, प्रत्येक कोने के लिए लगभग 6400 दालें प्रति सेकंड। हर बार स्विच SLEW या AUTO मोड में होता था, भले ही निकटता रडार चालू हो।

एलजीसी में सीडीयू काउंटरों को कंप्यूटर में संसाधित किए गए बाहरी संकेतों द्वारा बढ़ाया या घटाया गया था। यह समय लेने वाला था, इस मामले में एक 11.7 each मेमोरी चक्र प्रत्येक। यदि काउंटर अधिकतम गति से बढ़े हैं, तो यह कुल समय का लगभग 15% था (यह आवारा समय TLOSS कहलाता है)। वर्तमान में हम 13% खर्च किए गए समय का एक रूढ़िवादी अनुमान प्रदान कर रहे हैं, जो कि देखे गए व्यवहार के अनुरूप है।

अपोलो 11 की उड़ान के बाद, ग्रुम्मन इंजीनियरों ने उड़ान में देखे गए कंप्यूटर व्यवहार को पुन: पेश करने के प्रयास में परीक्षण किए। उन्होंने पुष्टि की कि सबसे खराब स्थिति में भी, सीडीयू अधिकतम गति से दाल नहीं भेज सकते थे। वे इस निष्कर्ष पर पहुंचे कि इन मीटर (TLOSS) के साथ अधिकतम कंप्यूटर लोड 13.36% हो सकता है। सिमुलेशन के दौरान, उड़ान में होने वाली त्रुटियों के समान त्रुटियों को पुन: पेश किया गया था। इस प्रकार, उद्धृत TLOSS मूल्य अपोलो 11 कंप्यूटर लोड का सर्वोत्तम प्रलेखित अनुमान है। [क्लिंट टिलमैन, RR-CDU इंटरफ़ेस का अनुकरण जब RR SLEW या AUTO (LGC) मोड में FMES / FCI प्रयोगशाला में है, ”9 अगस्त। , 1969]

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



मैनुअल नियंत्रण टुकड़ा

* * *

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



अंजीर। 8: लैंडिंग के दौरान लोड (सिम्युलेटर डेटा)

इन शर्तों के तहत भी, हमने अपने कार्यक्रमों को तेज करने का प्रयास किया ताकि बड़े TLOSS के मामले में पर्याप्त समय हो। मुख्य सीमा दो-सेकंड की अवधि थी, जिसे उड़ान चरण के दौरान उपयोग किए जाने वाले "औसत-जी" कार्यक्रम में बनाया गया था। , READACCS SERVICER, , , . , , .

ब्रेकिंग चरण के दौरान, जब तक लैंडिंग रडार ने सतह को नहीं देखा, तब तक आरक्षित समय कम से कम 15% था। रडार को ऑपरेशन में डाल दिए जाने के बाद, अतिरिक्त गणना शुरू होती है, रडार के संदर्भ प्रणाली से निर्देशांक को नेविगेशन के लिए समन्वय प्रणाली से स्थानांतरित करने से जुड़ा होता है, जो मार्जिन को 13% तक कम कर देता है। जब प्रदर्शन शुरू होता है (क्रिया 16, संज्ञा 68), तो मार्जिन 10% या उससे कम हो जाता है। बाज़ एल्ड्रिन ने कहा कि जब उन्होंने संकेत दिया था 1202 के बाद, "ऐसा लगता है कि वह तब प्रकट हुए जब हमने 1668 में प्रवेश किया" [16]।

जब मार्जिन 10% और 13% निकाल लिया जाता है, तो एलजीसी के पास सभी आवश्यक कार्यों को करने के लिए पर्याप्त प्रोसेसर समय नहीं होता है। कार्यकारी डिजाइन के लचीलेपन के कारण, और कठोर वास्तुकला के साथ क्या होगा इसके विपरीत, कोई आपदा नहीं थी।

तालिका 1. चंद्रमा पर उतरते समय कार्य सक्रिय।


तालिका 1 अपोलो 11. लैंडिंग करते समय सक्रिय होने वाले कार्यों को सूचीबद्ध करता है। SERVICER की सबसे कम प्राथमिकता है, और सबसे लंबी चलती है। उच्च प्राथमिकता वाले कार्य SERVICER को रोक सकते हैं, लेकिन उनके पास अपेक्षाकृत कम समय है।

SERVICER - , - . , SERVICER , READACCS, , SERVICER . SERVICER , VAC, READACCS FINDVAC, Executive VAC SERVICER. SERVICER . VAC . Executive , BAILOUT 1201 1202.



9: SERVICER TLOSS

अंजीर।चित्र 9 दिखाता है कि SERVICER एक मजबूत TLOSS के साथ और अंजीर में कैसे व्यवहार करता है। चित्रा 10 सामान्य ऑपरेशन के दौरान और मजबूत टीएलओएस के साथ रजिस्टर और वीएसी सेट की तुलना दिखाता है, जिसके दौरान पुनरारंभ होता है।



अंजीर। 10. , TLOSS Executive Waitlist ( , P63 , [17].)

, P63, , . SERVICER, SERVICER. , , , , DELTAH ( 16, 68). , P63, « 68» « 63».

पुनरारंभ सुरक्षा प्रणाली मूल रूप से संभव हार्डवेयर विफलताओं के कारण विकसित हुई थी और एक बड़े टीएलओएस के साथ कम्प्यूटेशनल लोड में कमी प्रदान की थी। हमारे द्वारा विकसित वास्तविक समय प्रणाली कुछ स्थितियों में दोष सहिष्णु हो गई है।

P64 चरण के दौरान, स्थिति अलग थी। गति के सामान्य समीकरणों के अलावा, अतिरिक्त प्रसंस्करण को जोड़ा गया था जिसमें लैंडिंग साइट को फिर से असाइन करने की क्षमता शामिल थी। अतिरिक्त सॉफ़्टवेयर सुविधाएँ 10% से कम समय का मार्जिन छोड़ती हैं। अलार्म बजता रहा। 1201 और 1202 के तीन अलार्म 40 सेकंड के भीतर हुए। हर बार, कार्य पंक्ति को साफ़ करते हुए सॉफ़्टवेयर पुनः आरंभ हुआ, लेकिन लोड को कम नहीं कर सका।

102:43:08, , AUTO ATT HOLD , , P66, . 2 20 P66, .