NASA ने Artemis II के लिए fault-tolerant कंप्यूटर कैसे बनाया

 (cacm.acm.org)
7 पॉइंट द्वारा GN⁺ 2026-04-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • चंद्रमा के लिए मानवयुक्त Orion अंतरिक्षयान का फ्लाइट कंप्यूटर Apollo युग की प्रणालियों की तुलना में कहीं अधिक resilient और automatic control क्षमता वाला है, और life support, power, communication जैसी सभी critical functions को संभालता है
  • चंद्र कक्षा से 2.5 लाख मील की दूरी पर भी बिना रुकावट काम करने के लिए, इसे physical और logical redundancy तथा multiple flight computers के साथ इस तरह डिज़ाइन किया गया है कि hardware faults और radiation के प्रभावों को सह सके
  • हर Flight Control Module(FCM) अपने self-checking processor pair से बना है, जिससे कुल 8 CPU parallel में चलते हैं, और fail-silent डिज़ाइन तथा priority-based output selection algorithm के जरिए faults को isolate किया जाता है
  • सिस्टम time-triggered Ethernet और deterministic architecture के जरिए पूरी तरह synchronized रहता है, और triplicated network तथा memory single-bit errors तक को अपने आप correct कर लेते हैं
  • यदि मुख्य सिस्टम पूरी तरह fail हो जाए, तो independent hardware और operating system पर आधारित Backup Flight Software नियंत्रण अपने हाथ में ले लेता है; इस संरचना को भविष्य के autonomous systems के always-on resilience model के रूप में देखा जा रहा है

NASA का Artemis II fault-tolerant कंप्यूटर डिज़ाइन

  • Artemis II का फ्लाइट कंप्यूटर Apollo युग के guidance computer की तुलना में कहीं अधिक resilient और automatic control क्षमता वाला है
    • Apollo कंप्यूटर 1MHz processor और लगभग 4KB memory का उपयोग करते थे, और मुख्य control manual switches या relay-based था
    • Artemis II का Orion capsule life support, power, communication जैसी सभी critical functions को कंप्यूटर से सीधे manage करता है
  • चंद्र कक्षा से 2.5 लाख मील दूर किसी mission failure की recovery संभव नहीं होती, इसलिए सिस्टम को space radiation, bit flip, hardware fault के बावजूद बिना रुके काम करना चाहिए
    • NASA ने hardware errors के लिए physical redundant wiring, logically redundant network planes, और multiple flight computers का उपयोग किया

  • The Power of Eight

    • Orion ने पारंपरिक triple redundancy से आगे की संरचना अपनाई है
      • दो Vehicle Management Computer(VMC) में से प्रत्येक में दो Flight Control Module(FCM) लगे हैं, यानी कुल 4 FCM
      • हर FCM self-checking processor pair से बना है, जिससे कुल 8 CPU parallel में flight software चलाते हैं
    • सिस्टम fail-silent डिज़ाइन पर आधारित है; fault आने पर CPU गलत output भेजने के बजाय तुरंत silent state में चला जाता है
    • majority voting की जगह priority-based source selection algorithm का उपयोग करके healthy channel का output चुना जाता है
    • NASA का अनुमान है कि Van Allen radiation belts से गुजरते समय temporary faults हो सकते हैं, और अधिकतम 22 सेकंड तक 3 FCM खोने पर भी mission आखिरी FCM के सहारे जारी रह सकता है
    • silent state में गया FCM reset होने के बाद दूसरे modules के साथ synchronize होकर उड़ान के दौरान फिर से शामिल हो सकता है

  • Deterministic operation बनाए रखना

    • कई independent computers को पूरी तरह synchronized lockstep state में बनाए रखने के लिए deterministic architecture लागू की गई है
    • Orion पूरे सिस्टम में समय बाँटने के लिए time-triggered Ethernet network का उपयोग करता है
      • flight software, ARINC653 scheduler द्वारा managed major frame और minor frame के भीतर चलता है
      • time और space partitioning यह सुनिश्चित करती है कि inputs और outputs network schedule के साथ पूरी तरह aligned रहें
    • हर FCM वही inputs प्राप्त करता है, वही code चलाता है, और वही outputs बनाता है
    • हर सेकंड FCM clock drift मापकर उन्हें network reference time के अनुसार recalibrate किया जाता है
    • जो applications deadline पूरी नहीं कर पातीं, वे अपने आप silent state में चली जाती हैं और फिर resynchronize होती हैं
    • hardware triple modular redundant memory(TMR) का उपयोग करता है, जो single-bit errors को अपने आप correct करती है; network interface card भी dual traffic paths की तुलना करके fault होने पर fail-silent व्यवहार अपनाता है
    • network को तीन independent planes में triplicate किया गया है, और सभी switches में self-checking capability है

  • अंतिम backup सिस्टम

    • NASA ने ऐसे common mode failure के लिए भी तैयारी की है जो एक साथ सभी मुख्य channels को प्रभावित कर सकता है
    • इसके लिए अलग से Backup Flight Software(BFS) सिस्टम लगाया गया है
      • BFS अलग hardware, अलग operating system, और स्वतंत्र रूप से विकसित simplified flight software से बना है
      • मुख्य सिस्टम fail होने पर BFS अपने आप control संभाल सकता है और mission के dynamic phase को पूरा कर सकता है
      • इसके बाद crew मुख्य FCM को restore करने की कोशिश कर सकता है
    • fail-silent logic जरूरी है, लेकिन faults बिना detect हुए न रह जाएँ, इसके लिए watchdog timers और multi-layer monitoring भी साथ में आवश्यक हैं
    • इसे पूरी power loss ("dead bus") की स्थिति में भी survive करने लायक डिज़ाइन किया गया है
      • power लौटते ही यह अपने आप safe mode में चला जाता है
      • solar panels को सूरज की दिशा में मोड़कर power recover की जाती है, फिर thermal stability के लिए spacecraft को सूरज की ओर tail-first रखा जाता है
      • इसके बाद पृथ्वी से communication दोबारा स्थापित करने की कोशिश की जाती है, और ज़रूरत पड़ने पर crew manual रूप से life support system समायोजित कर सकता है

  • विश्वसनीयता का भविष्य

    • Apollo से Artemis तक का बदलाव software complexity में बहुत बड़ी छलांग को दिखाता है
      • Apollo में mechanical backup मौजूद था, लेकिन Artemis में पूरा control software संभालता है
    • NASA full-environment simulation, Monte Carlo stress testing, और large-scale fault injection सहित आधुनिक verification workflow का उपयोग कर रहा है
      • supercomputer की मदद से पूरे flight timeline का simulation किया जाता है और यह जाँचा जाता है कि hardware fault की स्थिति में भी software fail-silent तरीके से recover कर सकता है या नहीं
    • Orion की zero-tolerance architecture को भविष्य में self-driving cars, industrial control networks जैसे क्षेत्रों में भी लागू किए जा सकने वाले always-on resilience के मॉडल के रूप में देखा जा रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-10
Hacker News की राय

  • 1989 से 95 तक Stratus में VOS और डेटाबेस परफ़ॉर्मेंस से जुड़ा काम किया था
    Stratus हार्डवेयर-आधारित fault-tolerant सिस्टम बनाने वाली कंपनी थी, जबकि प्रतिद्वंद्वी Tandem ने सॉफ़्टवेयर-आधारित तरीका अपनाया था
    Stratus का आर्किटेक्चर “pair and spare” था, जिसमें हर बोर्ड डुअल था और हर टिक पर हर pin output की तुलना की जाती थी
    Motorola 68K से Intel पर स्विच करते समय, कुछ instructions के unused pins floating हो जाने की समस्या के कारण हार्डवेयर टीम को काफ़ी दिक्कत हुई थी

  • CMU के एक शोधकर्ता की यह बात प्रभावशाली लगी कि “Agile और DevOps ने आर्किटेक्चरल अनुशासन को कमज़ोर कर दिया”
    लगता है आजकल हम deterministic systems बनाना भूल गए हैं
    Time-triggered Ethernet की सख़्त frame scheduling आज के सॉफ़्टवेयर डेवलपमेंट तरीकों से बिल्कुल अलग दुनिया जैसी लगती है

    • अब भी ऐसे लोग हैं जो real-time guarantees की ज़रूरत वाले embedded systems पर काम करते हैं
      आधुनिक डेवलपमेंट प्रैक्टिसेज़ में से कुछ, जैसे unit tests और CI, ऐसे माहौल में भी सकारात्मक असर डालती हैं
    • Apollo के दौर में रक्षा विभाग-केंद्रित रिसर्च फंडिंग की वजह से WCET(सबसे खराब निष्पादन समय) आधारित deterministic computing मुख्यधारा में था
      अब व्यावसायिक बाज़ार-केंद्रित बदलाव के साथ निवेश कम हुआ है, लेकिन फिर भी कई दिलचस्प algorithms मौजूद हैं
      Frank Mueller या Johann Blieberger के शोध को देखना उपयोगी हो सकता है
    • Time-triggered Ethernet विमान certification के लिए डेटा बस का हिस्सा है, और INRIA और Airbus ने इस पर संबंधित शोध किया था
      विमान जैसे सीमित input-output वाले वातावरण में deterministic design पूरी तरह फिट बैठता है
      व्यवहार में यह Ethernet से ज़्यादा dedicated hardware bus के क़रीब है
    • सुना है Tesla Cybertruck भी Ethernet में यह तरीका इस्तेमाल करता है
    • शायद उसका मतलब SpaceWire रहा होगा

  • Code Golf की ‘radiation hardening’ challenge को देखकर
    यह सोच रहा था कि क्या ऐसा तरीका वास्तव में उपयोगी हो सकता है
    व्यावहारिक रूप से इतने ज़्यादा स्तरों की समस्याएँ उलझी होती हैं कि यह कठिन लगता है, फिर भी विचार रोचक है

  • लेख में समझाया गया “fail-silent” design दिलचस्प लगा
    लेकिन अगर दोनों CPU एक ही समय पर ग़लत गणना करें और उनके नतीजे भी एक जैसे हों, तो उसे कैसे detect किया जाएगा, यह जिज्ञासा थी

    • radiation के कारण एक जैसे bit errors का एक ही समय पर दोनों CPU में होना बेहद कम संभावना वाला है
    • ऐसे CPU lockstep architecture में एक ही operations साथ-साथ चलाते हैं और परिणामों की तुलना करते हैं
      दोनों CPU के एक साथ वही ग़लती करने की संभावना किसी एक CPU के FIT से भी बहुत कम होती है
    • दोनों CPU में एक ही bit के साथ-साथ flip होने की संभावना तो शायद asteroid collision की संभावना से भी कम है
      फिर भी अंतरिक्ष में Murphy’s law काम करती है, इसलिए पक्का कुछ नहीं कहा जा सकता
    • वास्तव में triple modular redundancy में भी अगर दो CPU एक जैसी ग़लती करें तो वही समस्या आती है
    • अगर system 1 और 2 एक साथ ग़लत हों और बाकी 6 सामान्य हों,
      तो “25% majority vote” से ग़लत परिणाम चुना जा सकता है

  • इस सिस्टम के CPU, RAM, OS, language आदि के बारे में ठोस जानकारी जानने की उत्सुकता है
    यह भी जानना चाहूँगा कि FCM कितनी बार “fail-silent” हुआ

    • NASA cFS C में लिखा गया है और GitHub पर उपलब्ध है
      यह आम तौर पर FreeRTOS या RTEMS के ऊपर चलता है
      व्यक्तिगत रूप से मुझे इसका project structure इतना जटिल लगा कि संभालना मुश्किल था
    • BFS cFS का उपयोग करता है, और इसे YouTube वीडियो में भी देखा जा सकता है
      NASA का ज़्यादातर core code private है, लेकिन cFS क्लासिक flight software design सीखने के लिए अच्छा संसाधन है

  • लेख में वास्तविक RTOS और architecture के बारे में विवरण नहीं है
    Orion का मुख्य flight control Green Hills INTEGRITY RTOS और BAE RAD750 processor पर आधारित चार-स्तरीय redundancy संरचना है
    BFS पूरी तरह अलग LEON3 + VxWorks hardware पर चलता है और NASA के cFS framework का उपयोग करता है
    यह वही modular reusable architecture है जो James Webb telescope और Mars Rover में भी इस्तेमाल हुआ है
    इस तरह की संरचना सिर्फ़ “मुख्य सिस्टम + बैकअप” नहीं, बल्कि dissimilar redundancy की अवधारणा है
    विवरण NASA तकनीकी दस्तावेज़ 1, दस्तावेज़ 2 में देखे जा सकते हैं

    • लेकिन पूरी तरह अलग टीमें भी अगर वही textbooks या algorithm sources इस्तेमाल करें, तो एक जैसी ग़लतियाँ पैदा हो सकती हैं

  • वास्तविक निर्माण Lockheed Martin और उसके subcontractors ने किया था
    मीडिया का इसे ऐसे दिखाना कि NASA ने सब कुछ सीधे बनाया, ग़लतफ़हमी पैदा करता है

    • नहीं लगता कि Lockheed ने NASA के अनुरोध के बिना ऐसा महँगा चार-स्तरीय redundant PowerPC system बना लिया होगा
    • BFS का विकास मुख्य रूप से NASA के अंदर हुआ था (सीधे शामिल रहे एक दोस्त के अनुसार)
    • वास्तव में NASA और Lockheed के बीच करीबी सहयोग रहा होगा
    • “megacorp के बारे में सोचो” वाला मज़ाक भी आया

  • 25 साल पहले जब मैं web developer के रूप में काम करता था, तो NASA में काम कर चुके एक दोस्त से पूछा था, “तुम लोग bugs को कैसे handle करते थे?”
    वह हँसकर बोला, “bugs होते ही नहीं थे”
    आज के डेवलपर्स ऐसे माहौल के आदी हो गए हैं जहाँ असफलता पर इंसानी जान दाँव पर नहीं होती

    • हर उद्योग में “काफ़ी अच्छा” का मानदंड अलग होता है
      web services में बात revenue loss तक सीमित रहती है, लेकिन spacecraft में मानव जीवन दाँव पर होता है

  • पहले मैंने radiation-tolerant computer विकसित किया था,
    जहाँ सिर्फ़ redundancy ही नहीं बल्कि non-redundant error detection techniques भी इस्तेमाल की थीं
    इस सिस्टम में ऐसा दृष्टिकोण नज़र नहीं आता, यह थोड़ा खटकता है

    • Shuttle के दौर में 5 कंप्यूटर अलग-अलग स्थानों और दिशाओं में लगाए जाते थे, ताकि
      radiation collision cross-section को फैलाकर physical hardening भी की जा सके

  • कई redundancy structures बेहतरीन हैं, लेकिन यह जानने की जिज्ञासा है कि manual override अब भी संभव है या नहीं
    Apollo 11 और 13 की तरह ज़रूरत पड़ने पर क्या सीधे नियंत्रण लिया जा सकता है
    अब भी test pilot पृष्ठभूमि वाले astronauts इसे चलाते हैं, इसलिए लगता है कि यह संभव होगा