एविएशन के बारे में प्रोग्रामर जिन गलत धारणाओं पर भरोसा करते हैं

• एविएशन डेटा में जटिल और गैर-मानकीकृत विशेषताएँ बहुत होती हैं
• फ्लाइट, एयरपोर्ट, नेविगेशन, ट्रांसपोंडर जानकारी आदि के बारे में डेवलपर अक्सर गलत अनुमान लगा लेते हैं
• वास्तविक flight tracking system को तरह-तरह की अपवाद स्थितियों और डेटा असामान्यताओं से लचीले ढंग से निपटना पड़ता है
• कई गलतफहमियाँ सॉफ़्टवेयर या ग्राहक सिस्टम में अनपेक्षित त्रुटियाँ पैदा करती हैं
• डेटा डिज़ाइन करते समय वास्तविक दुनिया की जटिलता को बारीकी से प्रतिबिंबित करने वाला दृष्टिकोण ज़रूरी है

---

अवलोकन

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

Flights (फ्लाइट जानकारी)

• यह गलतफहमी कि फ्लाइट हमेशा गेट से ही रवाना होती है, आम है, लेकिन वास्तव में वह कई बार गेट बदल सकती है, या तय समय से बहुत देर या बहुत पहले निकल सकती है
• फ्लाइट शेड्यूल या प्रस्थान/आगमन एयरपोर्ट स्पष्ट होंगे, ऐसा मानना आसान है, लेकिन हेलिकॉप्टर या सैन्य विमान एयरपोर्ट के अलावा अन्य जगहों से भी उड़ान भरते और उतरते हैं
• फ्लाइट का उड़ान समय या शेड्यूल नियमित होगा, ऐसा लग सकता है, लेकिन कई दिनों तक चलने वाली लंबी उड़ानें या अनियमित संचालन भी अक्सर होते हैं
• फ्लाइट पहचान संख्या (उदा. UAL1234) को अद्वितीय मान लेना आसान है, लेकिन वास्तव में एक विमान को कई पहचानकर्ता या नंबर दिए जा सकते हैं, और एक ही नंबर कई परिस्थितियों में इस्तेमाल हो सकता है
• ऊपर से एक जैसे दिखने वाले नंबरों में भी flight identifier, registration number और अन्य चिह्न मिलेजुले हो सकते हैं, जिससे भ्रम पैदा होता है, और टिकट, ATC, पायलट अलग-अलग पहचान जानकारी का उपयोग कर सकते हैं

Airports (एयरपोर्ट जानकारी)

• यह लग सकता है कि एयरपोर्ट का स्थान और पहचान कोड स्थिर होते हैं, लेकिन वास्तव में एयरपोर्ट बंद हो सकते हैं, स्थानांतरित या विलय हो सकते हैं, जिससे स्थान या कोड बदल जाते हैं
• टर्मिनल/गेट नंबर, रनवे आदि की नामकरण प्रणाली भी एकसमान नहीं होती और उनमें कई अपवाद नियम होते हैं
• ICAO/IATA कोड प्रणाली में भी डुप्लिकेट, कई कोड आवंटन, location code को लेकर गलतफहमी जैसी वास्तविकता-विरोधी अनेक स्थितियाँ मौजूद हैं
• किसी पहचान जानकारी (उदा. IATA code) के होने से यह ज़रूरी नहीं कि वह वास्तव में एयरपोर्ट ही हो; रेलवे स्टेशन और बस टर्मिनल को भी IATA code दिए गए मामलों का अस्तित्व है
• यहाँ तक कि कुछ ICAO code पृथ्वी के बाहर की जगहों (उदा. extraterrestrial crater) को भी आवंटित किए गए हैं

Airlines (एयरलाइन जानकारी)

• चूँकि अलग पंक्ति में कोई विशिष्ट गलत धारणाएँ नहीं दी गई थीं, इसलिए इसे छोड़ा गया है

Navigation (नेविगेशन और रूट जानकारी)

• यह गलतफहमी कि waypoint के नाम अद्वितीय होंगे, आम है, लेकिन वास्तव में उनमें डुप्लिकेट होते हैं
• एविएशन में इस्तेमाल होने वाली altitude की परिभाषा एक नहीं है, और अलग-अलग मानकों के अनुसार उसका अर्थ बदल सकता है
• यह मान लिया जाता है कि air traffic control data पूरी तरह सटीक होगा, लेकिन वास्तव में त्रुटियाँ या बदलाव अक्सर होते रहते हैं
• फ्लाइट प्लान का रद्द होना या प्लान बदलना वास्तविक उड़ान में परिलक्षित न हो, या एक ही फ्लाइट कई बार अपना गंतव्य बदल दे, ऐसा भी हो सकता है
• radar, और अलग-अलग ATC एजेंसियों के बीच डेटा असंगति, या एक साथ किए गए अवलोकनों में स्थान का अंतर भी मौजूद होता है

Transponders and ADS-B (ट्रांसपोंडर और ADS-B संबंधी जानकारी)

• यह मान लिया जाता है कि ADS-B signal केवल विमान से ही प्रसारित होता है, लेकिन एयरपोर्ट वाहन या अन्य उपकरण भी इसे भेज सकते हैं
• GPS निर्देशांकों की सटीकता और signal की विश्वसनीयता पर अति-विश्वास भी एक गलतफहमी है
• ट्रांसपोंडर registration जानकारी (पहचान संख्या, Mode S address आदि) में त्रुटि, डुप्लिकेशन, रखरखाव की चूक, format error आदि के कारण real-time data और वास्तविक जानकारी के बीच असंगति अक्सर होती है
• यह मानना आसान है कि ADS-B जानकारी जैसी की तैसी प्राप्त और संग्रहीत होती है, लेकिन transmission error, signal spoofing जैसी कई समस्याएँ उत्पन्न होती हैं
• उपकरण की खराबी, लापरवाहीपूर्ण प्रबंधन, बाहरी कारक (उदा. चूहों द्वारा केबल को नुकसान) भी वास्तविक दुनिया के चर हैं

समापन

यह सूची FlightAware और Hyperfeed विकास टीम के कई वर्षों में असंख्य वास्तविक मामलों से प्राप्त अनुभव और insight पर आधारित है, और एविएशन डेटा विश्वसनीयता की जटिलता को दिखाती है। विभिन्न त्रुटियों और गलतफहमियों को कम करने के लिए यह वास्तविक अपवाद स्थितियों को पूरी गंभीरता से ध्यान में रखकर डेटा मॉडलिंग और संचालन के महत्व पर ज़ोर देती है।

[ifmkl]

डेटा standardization इसलिए...ज़रूरी है..हाहा

[ryj0902]

मूल पाठ वाकई बहुत संक्षिप्त है, लेकिन उसमें छिपी भावना;;

[aliveornot]

सिर्फ़ इसे पढ़ने भर से ही ब्लड प्रेशर बढ़ जाता है, lol

[GN⁺]

Hacker News की राय

• विमानन क्षेत्र में समय के साथ नहीं बदलने वाला कोई एकल, वास्तव में अद्वितीय identifier नहीं होता—इस स्थिति का विवरण। हर aircraft को serial number दिया जाता है, लेकिन केवल उससे uniqueness सुनिश्चित नहीं होती—ऐसा वास्तविक अनुभव साझा किया गया। "manufacturer, model, serial number" का संयोजन किसी aircraft के पूरे जीवनकाल में अपेक्षाकृत अद्वितीय identifier बन सकता है, लेकिन यदि संरचनात्मक बदलाव से उसका type बदल जाए तो यह भी बदल सकता है। विमानन जैसे विशाल और जटिल सिस्टम में कोई अपरिवर्तनीय identifier न होना व्यक्तिगत रूप से आश्चर्यजनक लगा। aircraft registration number (tail number) कार की number plate की तरह बदल सकता है, और ICAO 24-bit identifier ADS-B उपकरण से जुड़ा होने के कारण आसानी से स्थानांतरित या बदला भी जा सकता है

  • "manufacturer, model, serial number" संयोजन का patent का विषय बन जाना दिलचस्प लगा। यह कैसे नया माना गया और patent कैसे मिल गया—इस पर जिज्ञासा व्यक्त की गई

  • इस चर्चा को 'Ship of Theseus' विरोधाभास से जोड़ते हुए, aircraft की identity और identifier के बदलने पर दार्शनिक संदर्भ साझा किया गया Ship of Theseus Wikipedia लिंक

  • ऐतिहासिक पृष्ठभूमि साझा की गई कि aviation industry अलग-अलग देशों में silo की तरह स्वतंत्र रूप से विकसित हुई, इसलिए standardization देर से आई। यह दृष्टिकोण भी रखा गया कि वैश्विक standards का ठीक से स्थापित हो जाना अपने आप में आश्चर्यजनक है। साथ ही यह विश्लेषण कि आज बड़े manufacturers की संख्या कम होकर कुछ ही रह गई है, इसलिए यह किसी हद तक संभव हो पाया

  • वास्तविक दुनिया में "सचमुच" अद्वितीय identifier की समस्या बार-बार सामने आती है—ऐसा field experience साझा किया गया। समाधान लगभग हमेशा “model, manufacturer, serial number” का संयोजन होता है, और जरूरत पड़े तो production year भी जोड़ दी जाती है। यहाँ तक कि मानव डेटा में भी भाषा (mother tongue) जैसे मानदंड के आधार पर de-duplication करने की कोशिश का उदाहरण दिया गया

  • runway number भी समय के साथ बदल सकते हैं—इसका उदाहरण देते हुए Wikipedia लेख साझा किया गया Runway Wikipedia लिंक

• यह राय दी गई कि ऐसी lists हमेशा कहीं अधिक उपयोगी होतीं यदि हर बिंदु के साथ अधिक विस्तृत explanation होती। फिर भी linked sources में काफी उपयोगी जानकारी है, जैसे ‘मंगल ग्रह के crater को ICAO airport code दिया गया था (JZRO)’ का उदाहरण Jezero crater Wikipedia लिंक, ऐसी flight का उदाहरण जो सामान्य departure के बाद 40 घंटे देर से उतरी

  • यह भी कहा गया कि सूची में दिए कई उदाहरण वास्तव में नीरस कारणों से हैं। उदाहरण के लिए, 2 हफ्ते वाली उड़ान Google Balloon थी, 40 घंटे की देरी सिर्फ खराब मौसम की वजह से थी, और ADS-B value pilot दर्ज करते हैं इसलिए उनमें अक्सर गलती हो जाती है

• यह सवाल उठाया गया कि manufacturer-model-serial number का संयोजन इतना स्वाभाविक लगता है, फिर यह patent कैसे बन गया, और क्या आज कोई इससे मुनाफा भी कमा रहा है

• flight data analysis software बनाने के अनुभव से बताया गया कि helicopter और airplane दोनों ही hospital, rooftop, parking lot, sports field, airport, golf course जैसी जगहों से takeoff और landing करते हैं, इसलिए developer को “aviation के बारे में तरह-तरह की झूठी धारणाओं” के बीच काम करना पड़ता है

• "Falsehoods..." series पढ़ते समय यह दिलचस्प लगता है कि बहुत से developers मान लेते हैं कि मानव-केंद्रित systems सख्त नियमों के अनुसार ही चलेंगे

  • developers हर चीज़ को कठोर नियमों की प्रणाली में बदलना पसंद करते हैं, लेकिन वास्तविक दुनिया ऐसी नहीं होती—इसका स्वीकार

  • यह विश्लेषण कि programming पेशे का मूल स्वभाव ही लचीले मानव systems और सख्त rule-based machines के बीच interface का काम करना है

  • programmer के नज़रिए से दुनिया को software में model करते समय कई धारणाएँ स्वाभाविक लगती हैं, लेकिन वास्तविकता में वे पूरी तरह गलत निकलती हैं—इससे पैदा होने वाली दुविधा और भ्रम साझा किया गया। उदाहरण के तौर पर, यह मान लेना कि हर flight का निश्चित departure और arrival airport होगा, जबकि वास्तविक दुनिया में ऐसा ज़रूरी नहीं

  • यह तर्क दिया गया कि software की प्रकृति ही ऐसी है कि domain modeling को अंततः किसी न किसी ruleset में बदलना पड़ता है। अगर rules ही न हों तो कोई functionality दी ही नहीं जा सकती। आम लोगों को 'leap second' जैसे अपवाद समझाए जाएँ तो वे अक्सर उसे बकवास समझ बैठते हैं; इसलिए कई बार developers ही दुनिया की जटिलता और exceptions को बेहतर समझते हैं

• "Falsehoods Programmers Believe..." series के हर item को test case की तरह देखने का तरीका सुझाया गया। इन्हें program में छिपी गलत धारणाओं की जाँच के लिए unit/integration tests तक बढ़ाया जा सकता है

  • वास्तविक अनुभव साझा किया गया कि सचमुच हर item के लिए tests बनाए गए थे, और उस समय रोज़मर्रा से लेकर बेहद extreme मामलों तक एक हज़ार से अधिक tests मौजूद थे। यह उस टीम की याद भी थी जो quality और engineering को बहुत महत्व देती थी

• "Flights airports से takeoff/landing करती हैं"—यह धारणा पहले Brazil के aviation system में बिना शर्त मौजूद थी, और इसे एक अस्थायी workaround से संभाला गया था—ऐसा उदाहरण दिया गया। "airport/runway की location या heading नहीं बदलती" जैसी धारणाओं की भी आलोचना की गई कि वे बहुत बार गलत साबित होती हैं। साथ ही यह सुझाव भी दिया गया कि एक और धारणा जोड़नी चाहिए: "aircraft केवल runway या heliport पर ही land करते हैं"

  • यह सवाल पूछा गया कि Brazil के पुराने aviation systems ने ऐसी समस्याओं को अस्थायी रूप से कैसे संभाला—इसके बारे में और विस्तार से जानना चाहेंगे

• CGP Grey का एक वीडियो साझा किया गया जो airport codes के अव्यवस्थित इतिहास को बहुत अच्छी तरह summarize करता है YouTube लिंक. इसमें system की अनोखी परिस्थितियों तक समझाई गई हैं

• इसी विषय पर FlightAware forum में हुई एक और चर्चा भी साझा की गई FlightAware forum लिंक

• programmer के नज़रिए से यह स्वीकार किया गया कि इस सूची की लगभग सभी धारणाएँ शुरू में पूरी तरह reasonable लगी थीं, लेकिन बाद में वास्तविकता समझ आने पर दिमाग फटने जैसा अनुभव हुआ। इसे शानदार summary कहा गया