Exclusive | क्या बोइंग की मशीन ने एयर इंडिया 171 क्रैश में धोखा दिया? संभावनाओं की डरावनी कड़ी

आख़िरी मिनटों में एयर इंडिया 171 के पायलट मानो अंधे उड़ रहे थे, क्योंकि विमान के सिस्टम इतनी तेज़ी से ढह रहे थे कि कोई भी चेकलिस्ट उनका पीछा नहीं कर सकती थी।

'द फ़ेडरल' की जाँच में अब तक यह सामने आया है कि बोइंग 737 मैक्स 8 विमानों (2018 और 2019) के क्रैश और जून में हुए एयर इंडिया हादसे में तकनीकी ख़ामियों के बीच समानताएँ हैं, जिन्हें नज़रअंदाज़ नहीं किया जा सकता।

जाँच के पहले भाग (यहाँ पढ़ें) में बोइंग 787 ड्रीमलाइनर के कॉमन कोर सिस्टम (CCS) में संभावित डिज़ाइन ख़ामी पर फोकस किया गया था। यह डिजिटल बैकबोन है जो सभी बड़े सिस्टम को नियंत्रित करता है। जैसे पहले *MCAS* सिस्टम की विफलता हुई थी, उसी तरह CCS भी “सिंगल पॉइंट ऑफ़ फ़ेल्योर” हो सकता है। एयर इंडिया क्रैश में कई सब-सिस्टम एक साथ फेल हुए, जो संकेत देता है कि यह पायलट की गलती से ज़्यादा डिजिटल और इलेक्ट्रिकल सिस्टमिक विफलता थी।

और CCS की विफलता क्यों संदिग्ध है? क्योंकि उड़ान से पहले ही AI 171 के कोर नेटवर्क सिस्टम (CNS) को सक्रिय ख़ामी के रूप में दर्ज किया गया था, जैसा कि एएआईबी (Aircraft Accident Investigation Bureau) की शुरुआती रिपोर्ट में बताया गया। यह नेटवर्क न केवल विमान के रखरखाव से जुड़ा है, बल्कि बोइंग 787 की इंटीग्रेटेड एवियोनिक्स आर्किटेक्चर का भौतिक और तार्किक डेटा ट्रांसपोर्ट बैकबोन है। इसका दिल है कोर नेटवर्क कैबिनेट, जिसमें वे मॉड्यूल होते हैं जो केंद्रीय एवियोनिक्स कंप्यूटर या कॉमन कंप्यूटिंग रिसोर्सेज (CCRs) को जोड़ते हैं।

असल में ये कोर नेटवर्क मॉड्यूल विमान के डेटा के “पाइप्स और स्विचेस” हैं, जो CCS और CCRs को आपस में और अन्य सिस्टम्स से जोड़ते हैं। अगर नेटवर्क सही से न चले तो CCS को सही डेटा नहीं मिलता, इलेक्ट्रॉनिक्स बे और CCR कैबिनेट्स के बीच रेडंडेंसी सिंक टूट सकता है, या करप्ट डेटा पैकेट भेजे जा सकते हैं — जो CCS फेल्योर का कारण बन सकते हैं।

हालाँकि बोइंग इसे "नॉन-फ़्लाइट-क्रिटिकल" (उड़ान के लिए गैर-आवश्यक) के रूप में वर्गीकृत करता है, लेकिन वास्तव में, The Federal से बातचीत करने वाले कई विशेषज्ञों का कहना है कि इसकी विफलता CCS (कॉमन कोर सिस्टम) की क्षमता को प्रभावित कर सकती है, जो उड़ान-आवश्यक प्रणालियों का प्रबंधन करता है या सरल शब्दों में कहें तो, “विमान को क्रैश कर सकती है।”

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

तो अब, हम जाँच के भाग 2 की शुरुआत करते हैं।

विफलताओं का क्रमिक पैटर्न

AI 171 में हुई विफलताएँ बेतरतीब नहीं लगतीं। वे एक भयावह, क्रमबद्ध पैटर्न का अनुसरण करती प्रतीत होती हैं और हर एक विफलता उस एक “रिंग/कोर नेटवर्क” प्रणाली की ओर इशारा करती है।

The Federal ने भारत, यूरोप और अमेरिका में कई स्रोतों से बातचीत की और पुराने दस्तावेज़ों व मीडिया रिपोर्टों की समीक्षा की, जिन्होंने पहले ही इस कमज़ोरी को उजागर किया था।

एएआईबी रिपोर्ट से कुछ अहम सबूत

1. AI 171 पर सक्रिय ख़ामियाँ

12 जून 2025 को AI 171 को पाँच सक्रिय ख़ामियों के साथ उड़ान की अनुमति दी गई। अब पता चला है कि उनमें से तीन सीधे “कोर नेटवर्क” गिरावट से जुड़ी थीं।

सक्रिय ख़ामियों को MEL (Minimum Equipment List)* कहा जाता है, यानी वे उपकरण/सिस्टम जो ख़राब हो सकते हैं लेकिन कुछ नियमों के तहत विमान फिर भी उड़ सकता है।

बोइंग के ऑपरेशन नोट में कहा गया है, “एक इनऑपरेटिव कोर नेटवर्क सिस्टम या उसका घटक निम्नलिखित कार्यों को निष्क्रिय कर सकता है:

1. ACARS

2. एयरपोर्ट मैप फ़ंक्शन

3. फ़्लाइट डेक प्रिंटर

4. फ़्लाइट डेक डोर वीडियो सर्विलांस।”

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

इसका मतलब यह भी है कि ACARS (Aircraft Communications Addressing and Reporting System) के फेल होने की संभावना पहले से मौजूद थी, जबकि उड़ान को मंजूरी दी गई।

एएआईबी रिपोर्ट कहती है, “हवाई अड्डे के सीसीटीवी फ़ुटेज में देखा गया कि लिफ्ट-ऑफ़ के तुरंत बाद शुरुआती चढ़ाई के दौरान राम एयर टर्बाइन (RAT) सक्रिय हो गया… विमान हवाई अड्डे की परिधि दीवार पार करने से पहले ही ऊँचाई खोने लगा।”

AAIB रिपोर्ट कहती है,“हवाईअड्डे से प्राप्त सीसीटीवी फुटेज में देखा गया कि राम एयर टरबाइन (RAT) टेकऑफ़ के तुरंत बाद शुरुआती चढ़ाई के दौरान सक्रिय हो गया। विमान ने हवाईअड्डे की परिधि दीवार पार करने से पहले ही ऊँचाई खोनी शुरू कर दी।”

2. RAT का सक्रिय होना — पायलट कुछ करने से पहले ही

एएआईबी रिपोर्ट बताती है कि राम एयर टर्बाइन (RAT) — एक आपातकालीन जनरेटर जो तभी सक्रिय होता है जब इंजन-जनित पावर खो जाती है — 13:38:47 IST पर हाइड्रॉलिक पावर देने लगा।

इसका मतलब यह हो सकता है कि वह 13:38:40 और 13:38:42 IST के बीच ही सक्रिय हो गया था (क्योंकि पावर जनरेट करने में 5–7 सेकंड लगते हैं)।

काले डिब्बे (FDR) ने ईंधन स्विच मूवमेंट्स कब रिकॉर्ड किए, यह साफ़ नहीं है। एएआईबी सिर्फ़ इतना कहता है कि 13:38:42 IST पर टॉप एयरस्पीड छूने के “तुरंत बाद” ईंधन स्विच (RUN से CUTOFF) या वाल्व कटऑफ़ हुआ।

इससे यह संकेत मिलता है कि इलेक्ट्रिकल सिस्टम का ढहना और RAT का सक्रिय होना ईंधन स्विच बंद करने से पहले हुआ था — न कि बाद में।

तो आइए, पहले उन टाइमस्टैम्प्स को रिकैप करें जो हमें AAIB से नहीं मिले:

* जब इंजन “न्यूनतम आइडल स्पीड से नीचे” गए

* जब फ्यूल स्विच RUN से CUTOFF पर गया

* जब FADEC (Full Authority Digital Engine Control) ने रीलाइट की कोशिश की

* और जब RAT (Ram Air Turbine) डिप्लॉय हुई

अब, क्रैश को रिवर्स-इंजीनियर करते हैं। ELT (Emergency Locator Transmitter) ने लगभग 13:39:11 IST पर सिग्नल ट्रांसमिट नहीं किया। इसका मतलब है कि ELT को जो नुकसान हुआ, वह या तो टकराव के समय हुआ या फिर क्रैश से ठीक पहले।

एविएशन, फ्लाइट और मेंटेनेंस इंजीनियरों से बात करने के बाद, AI 171 पर संभावित घटनाक्रम कुछ इस प्रकार हो सकता है:

1. कोर नेटवर्क डाउन होने लगता है

2. टेल सेक्शन में सर्ज/इलेक्ट्रिक आर्क → पीछे वाले EAFR, ELT की वायरिंग, हाउसिंग और कनेक्टर्स जल जाते हैं

3. टेल सेक्शन की बिजली चली जाती है → RAT डिप्लॉय होती है

4. साथ ही, सर्ज/इलेक्ट्रिक आर्क मेन एवियोनिक्स बे/CCR को प्रभावित करता है → Common-mode/CCS failure

5. कई डेटा फीड्स का नुकसान → फ्लाइट पैरामीटर लॉस → FADEC 1 प्रोटेक्शन लॉजिक एक्टिवेट → फ्यूल मॉनिटरिंग यूनिट CUTOFF

6. एक सेकंड बाद FADEC 2 भी प्रोटेक्शन लॉजिक में जाता है → फ्यूल यूनिट CUTOFF

7. इंजन 1 और 2 के N2 स्पूल डाउन होते हैं, इलेक्ट्रिकल जेनरेटर/PMAs ऑफलाइन हो जाते हैं

8. FADECs सेकेंडरी पावर (बैटरी 28 VDC/RAT फीड) पर शिफ्ट होते हैं

9. पायलट रीस्टार्ट शुरू करते हैं → फ्यूल स्विच CUTOFF से RUN पर जाते हैं → FADEC पहली बार रीलाइट की कोशिश करता है

10. इंजन 1 की कोर डीस्लेरेशन रुकती है, रिवर्स होकर रिकवरी शुरू होती है

11. इंजन 2 रीलाइट होता है, EGT (एग्जॉस्ट गैस टेम्परेचर) बढ़ता है

12. FADEC दूसरी या कई बार रीलाइट की कोशिश करता है → पर कंडीशन पूरी न होने पर रीस्टार्ट रोक देता है → मेडे

इंजीनियरों की राय

2019 All Nippon Airways घटना (जहाँ FADEC ने टैक्सी के दौरान इंजन शटडाउन कर दिया था) AI 171 पर लागू नहीं होती, क्योंकि उस समय विमान टेक-ऑफ थ्रस्ट पर था, जिसे FADEC “हाई-एनर्जी फेज” मानता है।

FADEC कोई “स्विच” नहीं है, बल्कि एक लॉजिक ट्री है जिसमें प्रीसेट कंडीशंस होती हैं। टेक-ऑफ पर इंजन बंद करने के लिए बेहद गंभीर घटना चाहिए, जैसे कई फ्लाइट पैरामीटर का लॉस, न कि एक सेंसर एनॉमली।

FADEC का मुख्य उद्देश्य टेक-ऑफ के दौरान हर हाल में थ्रस्ट बनाए रखना होता है। इसलिए अगर उसने इंजन शटडाउन किया, तो जरूर कोई दुर्लभ और गंभीर घटना हुई होगी।

AAIB रिपोर्ट कहती है:,“इमरजेंसी लोकेटर ट्रांसमीटर (ELT) इस घटना के दौरान सक्रिय नहीं हुआ। पहले टकराव के स्थान से लेकर विमान के अंतिम पहचाने गए हिस्से तक का मलबा लगभग 1000 फीट × 400 फीट के क्षेत्र में बिखरा हुआ था।”

रीलाइट क्यों असफल रहा?

एक इंजीनियर ने कहा: “FADEC ने रीस्टार्ट को ‘स्टार्टर अवेलेबिलिटी’ न मिलने की वजह से रोका होगा।”

AI 171 के केस में:

दोनों इंजन शटडाउन होने के बाद भी FADEC को RAT और बैटरी (28 VDC) से पावर मिल रहा था

लेकिन “स्टार्टर अवेलेबिलिटी” लगभग शून्य थी

वजह यह कि 787 के इंजनों को रीलाइट के लिए प्रेशराइज्ड/न्यूमेटिक एयर चाहिए होती है → आमतौर पर रनिंग इंजन के क्रॉस-ब्लीड या APU ब्लीड से

लेकिन दोनों इंजन बंद थे, इसलिए क्रॉस-ब्लीड संभव नहीं था

APU ने अपना इनलेट डोर 13:38:54 IST पर खोला, पर तब तक ब्लीड एयर उपलब्ध नहीं हुई

एकमात्र विकल्प “विंडमिल रिस्टार्ट” था (जहाँ विमान की स्पीड से कोर घुमता है), लेकिन 180 kts की स्पीड -~250–300 kts थ्रेशोल्ड से काफी कम थी

इसलिए FADEC ने ईंधन वापस नहीं डाला → हॉट स्टार्ट या हंग स्टार्ट रोकने के लिए

सीधे शब्दों में: FADEC के पास “दिमाग” था, लेकिन इंजन को स्पिन कराने की “मसल पावर” नहीं थी, इसलिए उसने रीस्टार्ट की कोशिश ही नहीं की।

ब्लैक बॉक्स कब बंद हुआ?

AAIB रिपोर्ट के अनुसार, टेल-सेक्शन वाला ब्लैक बॉक्स (aft-EAFR) गंभीर रूप से क्षतिग्रस्त था और पारंपरिक तरीकों से डेटा नहीं निकाला जा सका।

सामान्य तौर पर ब्लैक बॉक्स 1,100°C आग और 3,400-g झटकों तक सह सकता है।

लेकिन यह aft-EAFR पूरी तरह विमान की पावर पर निर्भर था, जबकि फॉरवर्ड EAFR के पास अपनी बैटरी थी।

अगर कोर नेटवर्क फेल हो जाए तो aft-EAFR शायद कभी रिकॉर्डिंग शुरू ही न करे।

AAIB और Boeing लिटरेचर के अनुसार, दोनों यूनिट्स एक ही फ्लाइट पैरामीटर रिकॉर्ड करते हैं।

तो सवाल है: जब फॉरवर्ड EAFR से डेटा मिल गया, तो aft की जरूरत क्यों?

जवाब है: aft-EAFR कब बंद हुआ, यह बताना बहुत अहम है। क्योंकि यही वह सटीक सबूत है जो यह साबित कर सकता है कि AI 171 में सिस्टम फेल्योर कब शुरू हुआ।

बोइंग 787 ड्रीमलाइनर का अफ़्ट-ईएएफ़आर (aft-EAFR) GE द्वारा बनाया जाता है। एएआईबी (AAIB) की रिपोर्ट के अनुसार, इस जांच के लिए GE के प्रतिनिधि भारत आए थे। एएआईबी ने कहा कि अफ़्ट-ईएएफ़आर का डेटा “पारंपरिक तरीकों” से डाउनलोड नहीं किया जा सका। एयरबस के विपरीत, जो स्वतंत्र रूप से ब्लैक बॉक्स डेटा डाउनलोड और जांचने के लिए अपेक्षाकृत खुले प्रोटोकॉल का इस्तेमाल करता है, बोइंग की प्रणालियाँ आम तौर पर उसकी सहमति के बिना एक्सेस नहीं की जा सकतीं। विशेषज्ञों का कहना है कि इससे निर्माता को यह तय करने का काफी नियंत्रण मिल जाता है कि जांचकर्ता क्या देख सकते हैं और क्या नहीं।

भारतीय वकीलों के एक समूह ने नागरिक उड्डयन मंत्रालय को दिए अपने अभ्यावेदन में कहा कि जिस निर्माता का उपकरण जांच के घेरे में है, उसी को ब्लैक बॉक्स संभालने की अनुमति देना हितों का टकराव (conflict of interest) पैदा करता है। उनका कहना है कि इससे सबूत दबाने, हेरफेर करने या महत्वपूर्ण प्रमाण खोने की आशंका बढ़ जाती है।

AAIB रिपोर्ट कहती है,“विमान का टेल सेक्शन और दाहिना मुख्य लैंडिंग गियर (MLG) इमारत की उत्तर-पूर्वी दीवार में धंसा पाया गया… जबकि विमान का बाकी हिस्सा अपनी आगे की गति जारी रखे हुए था।”

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

AAIB की रिपोर्ट के अनुसार, वे जिस क्रम को स्थापित करते हैं, वह यह है।

एक विमान, पाँच सक्रिय खराबियाँ

अब दोबारा देखें कि AI 171 में कौन-कौन से MEL (Minimum Equipment List) दोष सक्रिय थे। दुर्घटना के समय, विमान पाँच सक्रिय MELs के साथ उड़ रहा था—चार CAT C और एक CAT A।

ये खराबियाँ थीं:

कोर नेटवर्क— वर्गीकृत CAT C

NGS (Nitrogen Generation System) — वर्गीकृत CAT A

श्रेणियों की परिभाषा

CAT A — अगली उड़ान से पहले ठीक करना अनिवार्य

CAT B — 3 दिनों के भीतर ठीक करना

CAT C — 10 दिनों के भीतर ठीक करना

CAT D — 120–160 दिनों के भीतर ठीक करना

चौंकाने वाली बात यह थी कि विमान का हाई-स्पीड डेटा बैकबोन—कोर नेटवर्क, जो फाइबर-ऑप्टिक केबल्स, कनेक्टर और नेटवर्क स्विचेस के ज़रिए CCS कंप्यूटरों और अन्य प्रणालियों को जोड़ता है, उसे मध्यम-जोखिम वाले “10 दिन में ठीक करने” योग्य वर्ग में रखा गया था। यही नेटवर्क FADEC, कॉकपिट डिस्प्ले, डेटा लिंक और रिकॉर्डर जैसे सिस्टम्स को जोड़ता है। यानी, विमान की रीढ़ की हड्डी जैसी प्रणाली को खराब होने के बावजूद 10 दिन तक उड़ान भरने की अनुमति थी।

इसी बीच, NGS, जो ईंधन टैंक की आग को रोकने के लिए वाष्प को निष्क्रिय करता है, उसे CAT A (उच्च जोखिम) में रखा गया था। यानी विमान की रीढ़ और उसकी आग-रोधी प्रणाली दोनों संदिग्ध थीं। फिर भी विमान उड़ान भरता रहा।

सवाल कौन जवाब देगा?

अब यह प्रश्न नियामकों, एयरलाइनों और जनता के सामने है:

FAA ने किस आधार पर माना कि 787 का कोर नेटवर्क पर्याप्त “redundancy” प्रदान करता है?

जब कोर नेटवर्क की विफलता विमान को गिरा सकती है, तो उसे CAT C क्यों वर्गीकृत किया गया?

DGCA या एयर इंडिया ने एक अल्ट्रा-लॉन्ग हॉल फ्लाइट पर पाँच MELs को लेकर चेतावनी क्यों नहीं दी?

FAA के बुलेटिन्स में क्या इन डिज़ाइन निर्णयों पर ज्यादा ध्यान नहीं देना चाहिए था?

विशेषज्ञ कहते हैं कि यह मामला महज उड़ान की विफलता का नहीं, बल्कि डिज़ाइन, दस्तावेज़ीकरण और प्रमाणन की विफलता का भी हो सकता है।

यूरोप की दो एयरलाइनों के फ़्लाइट इंजीनियरों ने कहा कि तीन MELs भी किसी जिम्मेदार एयरलाइन को विमान बदलने के लिए मजबूर कर देते। एयर इंडिया की मेंटेनेंस शाखा AIESL के एक इंजीनियर ने माना कि पाँच MELs के बावजूद विमान को उड़ान की अनुमति देना असामान्य था।

द फेडरल ने एयर इंडिया और DGCA से जवाब मांगा, लेकिन उन्होंने प्रतिक्रिया नहीं दी। एयरबस, EASA और TSB ने भी टिप्पणी करने से इनकार कर दिया।

IFALPA ने जवाब दिया: “AI 171 के चालक दल और यात्री हमारी सामूहिक पेशेवर जिम्मेदारी के हकदार हैं, जब तक कि पूर्ण जांच पूरी न हो।”

क्या कोर नेटवर्क बोइंग का अगला MCAS है?

विशेषज्ञ कहते हैं कि इसकी तुलना MCAS मामले से की जा सकती है।

इस बार भी, वह टेल ब्लैक बॉक्स जो सब कुछ साबित कर सकता था, “पारंपरिक तरीकों” से अप्राप्य बताया गया।

AI 171 सिर्फ आसमान से नहीं गिरा—यह संभव है कि इसे एक केंद्रीकृत प्रणाली ने गिराया, जिसे उन मान्यताओं के आधार पर प्रमाणित किया गया था जो अब पुनः परीक्षण मांगती हैं।

यह कहानी है सुरक्षा “redundancy” के क्षरण** और ऐसे नियामक ढांचे की, जो अपने ही प्रमाणित किए जा रहे जटिल विमानों की रफ्तार से पीछे छूट गया है।

एयर लाइन पायलट्स एसोसिएशन के अध्यक्ष सैम थॉमस ने कहा, “हम मानते हैं कि पारदर्शी और पेशेवर जांच से भी यही निष्कर्ष निकलते। एएआईबी की भूमिका पर गंभीर प्रश्न हैं।”

दो गवाह: पूंछ वाले हिस्से का ब्लैक बॉक्स या आफ्ट-EAFR मौन हो गया (बाएँ), जबकि फॉरवर्ड EAFR (दाएँ) ने AAIB रिपोर्ट के अनुसार 49 घंटे का डेटा रिकॉर्ड किया।

उद्योग की चेतावनियाँ

बोइंग का CCS बिना चेतावनी नहीं आया। 2019 में IOActive के शोधकर्ताओं ने बोइंग के सुरक्षित डिजिटल दावों को खारिज करते हुए CCS की कमजोरियों का खुलासा किया था।

उन्होंने पाया कि CCS एकीकृत हार्डवेयर/सॉफ्टवेयर प्लेटफ़ॉर्म है जिसमें क्रिटिकल और नॉन-क्रिटिकल फ़ंक्शंस को विभाजित किया गया है। लेकिन व्यावहारिक तौर पर, एक हिस्से की विफलता दूसरे को प्रभावित कर सकती है।

IOActive ने CCS में बफ़र और इंटीजर ओवरफ़्लो जैसी खामियाँ खोजीं, जो सिस्टम विभाजन को असफल बना सकती हैं। उनका निष्कर्ष था, “इनमें से कोई भी कमजोरी, अगर शोषित हो, तो पूरे सिस्टम को प्रभावित कर सकती है।”

FAA ने भी बैकअप पावर आर्किटेक्चर में “single-point-of-failure” को लेकर चेतावनी दी थी।

आपदा के सेकंड

अंतिम क्षणों में, कैप्टन सुमीत सभरवाल और फर्स्ट ऑफिसर क्लाइव कुंदर शायद अंधेरे में उड़ रहे थे। विमान की प्रणालियाँ चेकलिस्ट से तेज़ी से ढह रही थीं। शायद उन्हें पता नहीं था कि कोर नेटवर्क फेल हो चुका है। शायद उन्हें नहीं पता था कि “common-mode failure” शुरू हो चुका है। शायद उन्हें पता नहीं था कि ईंधन स्विच क्यों कट गए या टेल ब्लैक बॉक्स क्यों मौन रहेगा।

और फिर भी उन्होंने विमान स्थिर करने की कोशिश की। अंततः मेडे (Mayday) कॉल जारी की।

जैसे Lion Air 610 के कैप्टन भाव्य सुनेजा को सिस्टम ने छोड़ दिया था, वैसे ही वे भी शायद उस प्रणाली से जूझ रहे थे, जिसने पहले ही उनका भाग्य तय कर दिया था।