ब्रिटेन के एयर ट्रैफिक कंट्रोल सिस्टम का ध्वंस

 (jameshaydon.github.io)
2 पॉइंट द्वारा GN⁺ 2023-09-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 28 अगस्त 2023 को ब्रिटेन के एयर ट्रैफिक कंट्रोल ऑपरेटर NATS के FPRSA-R में खराबी के कारण 2,000 से अधिक उड़ानें रद्द हुईं, और लागत 100 मिलियन पाउंड से अधिक आंकी गई
  • अव्यवस्था शुरू करने वाला flight plan Eurocontrol IFPS द्वारा स्वीकार किया गया वैध plan था, और NATS सिस्टम ADEXP डेटा व ICAO4444 route को मिलाकर ब्रिटेन के airspace segment को निकालने की कोशिश कर रहा था
  • प्रत्यक्ष कारण यह था कि भौगोलिक रूप से अलग दो waypoints का identifier एक ही था; FPRSA-R ने गलत duplicate identifier को exit point से match किया और वैध UK segment नहीं बना पाया
  • primary system और backup system ने समान logic से उसी flight plan को process करते हुए अलग-अलग critical exception निकाला और 20 सेकंड के भीतर maintenance mode में चले गए, जिससे automatic processing रुक गई
  • aircraft को लगातार सुरक्षित रूप से control किया गया, लेकिन failure mode जिसमें एक single flight plan ने पूरे automatic processing system को रोक दिया, testing की कमी, और low-level logs पर निर्भर recovery procedure समस्याएं बनी रहीं

28 अगस्त 2023 के NATS outage का पैमाना

  • ब्रिटेन के एयर ट्रैफिक कंट्रोल ऑपरेटर NATS को 28 अगस्त 2023 को गंभीर तकनीकी खराबी का सामना करना पड़ा
  • BBC के अनुसार 2,000 से अधिक उड़ानें रद्द हुईं, और लागत 100 मिलियन पाउंड से अधिक आंकी गई
  • outage ने संभवतः लाखों लोगों को प्रभावित किया
  • शुरुआती media reports ने “गलत flight plan” या “French airline की गलती” की संभावना पर चर्चा की, लेकिन समस्या पैदा करने वाला flight plan Eurocontrol IFPS द्वारा स्वीकार किया गया ICAO4444-compliant flight plan था
  • बाद में outage trigger करने वाली वास्तविक flight French Bee FBU731 के रूप में पहचानी गई, जो LAX/KLAX से ORY/LFPO जा रही थी

flight plan NATS तक कैसे पहुंचता है

  • airline flight plan Eurocontrol के IFPS को submit करती है
    • IFPS flight plan स्वीकार कर ले, तो departure airport control clearance के बाद aircraft take off कर सकता है
    • इस stage पर NATS input की जरूरत नहीं होती
  • IFPS संबंधित air navigation service providers को flight plan forward करता है
    • NATS को aircraft के UK airspace में enter करने से कम से कम 4 घंटे पहले flight plan मिलना चाहिए
    • ये 4 घंटे processing problems हल करने के लिए buffer time की तरह काम करते हैं
  • Swanwick Centre के NATS En-route operations में data FPRSA-R को भेजा जाता है
    • FPRSA-R, IFPS से मिले ADEXP format data को UK National Airspace System, यानी NAS, के compatible format में convert करता है
    • NAS एक flight data processing system है जिसमें संबंधित airspace और route information शामिल होती है

ICAO4444 और ADEXP में अंतर

  • ICAO4444 flight plan machine-readable होता है और जरूरत पड़ने पर इंसान भी पढ़ सकता है
    • route section में speed, altitude, waypoints, route names, और DCT जैसे direct flight indicators शामिल होते हैं
    • उदाहरण के लिए N0440 का मतलब 440 knots, और F310 का मतलब Flight Level 310 है
  • IFPS, ICAO4444 flight plan को ADEXP format में convert करके भेजता है
    • ADEXP में मूल ICAO4444 flight plan के साथ European region routes के लिए अतिरिक्त geographical waypoints शामिल होते हैं
    • UK में landing किए बिना UK airspace से गुजरने वाली flights में UK के बाहर आगे की journey के लिए जरूरी waypoints भी शामिल हो सकते हैं
  • ADEXP के RTEPTS में हर waypoint की altitude और estimated crossing time ज्यादा detail में होती है
    • ICAO route में 9 waypoints हो सकते हैं, लेकिन ADEXP expanded list में 21 waypoints शामिल हो सकते हैं
    • ICAO route का origin और destination अलग fields में होते हैं, इसलिए वे route list में दोबारा शामिल नहीं होते

outage पैदा करने वाले duplicate waypoints

  • समस्या वाले ADEXP waypoint list में भौगोलिक रूप से अलग दो waypoints का designator एक ही था
    • ICAO और अन्य संस्थाएं non-unique waypoint names हटाने का काम करती रही हैं, लेकिन दुनिया भर में अब भी duplicate names मौजूद हैं
    • latest standard कहता है कि समान identifier वाले waypoints भौगोलिक रूप से काफी दूर होने चाहिए
    • इस घटना के दोनों waypoints UK के बाहर थे; एक route की शुरुआत में, दूसरा route के अंत के पास था, और दोनों करीब 4,000 nautical miles दूर थे
  • पहचानी गई flight FBU731 के expanded flight plan में DVL नाम का waypoint दो बार आया
    • एक अमेरिका के Wisconsin में Devil’s Lake
    • दूसरा France के Normandy में Deauville
    • बाद वाला UN859 airway expansion की प्रक्रिया में flight के बाद के हिस्से में आया माना गया

FPRSA-R की processing procedure और failure point

  • FPRSA-R, ADEXP waypoint data में UK airspace entry point को शुरुआत से search करके ढूंढता है
  • फिर UK airspace exit point ढूंढता है, और उसके बाद ICAO4444 section में corresponding segment खोजने की कोशिश करता है
  • ICAO route में airspace exit point का होना जरूरी नहीं है
    • software इस तरह design था कि अगर exit point ICAO route में नहीं है, तो ADEXP file के अगले नजदीकी point का इस्तेमाल करके फिर से खोजे
  • इस घटना में software ADEXP के अगले waypoints follow करते हुए ICAO route में मौजूद duplicate identifier तक पहुंचा
    • लेकिन वह identifier वास्तविक UK airspace exit के बाद का waypoint नहीं था, बल्कि route की शुरुआत में मौजूद दूसरा geographical waypoint था
    • परिणामस्वरूप entry point और exit point का order या segment valid नहीं रहा, इसलिए UK airspace से संबंधित ICAO segment extract नहीं किया जा सका
  • NATS report ने इसी point को घटना का root cause बताया और cyber-related contribution को खारिज किया जा सकता है, ऐसा निष्कर्ष दिया

primary और backup systems एक साथ क्यों रुके

  • safety-critical software को इस तरह design किया जाता है कि जब वह सुरक्षित रूप से आगे नहीं बढ़ सकता, तो manual intervention की जरूरत वाली state में चला जाए
  • FPRSA-R primary system ने माना कि वह flight plan के सही data की guarantee नहीं दे सकता, इसलिए critical exception raise किया
    • log file को system log में record किया
    • maintenance mode में चला गया
    • C&M system ने detect किया कि primary system अब usable नहीं है
  • backup system primary system failure पर processing संभालने के लिए design किया गया था
    • अलग hardware, अलग power supply, अलग data feed पर located था
    • लेकिन उसी flight plan पर वही logic apply किया और उसी result के साथ critical exception raise किया
  • ADEXP message receive होने से लेकर primary और backup दोनों systems के maintenance mode में जाने तक 20 सेकंड से कम समय लगा
  • 08:32 पर automatic flight plan processing रुक गई, और इसके बाद 4-hour buffer time के भीतर manual flight plan entry की जरूरत पड़ गई

recovery procedure और operational impact

  • 1st Line support team ने dedicated C&M system, central C&M system और operations team feedback के जरिए outage को पहचाना
  • शुरुआती response central C&M system से subsystem restart करने वाली standard recovery procedure थी
    • recovery की कई attempts fail हुईं
    • 2nd Line engineering team को शामिल किया गया, जिसने on-site engineers को remote video link से support किया
  • जब 1st Line और 2nd Line service recovery या exact cause identification में fail रहे, तो Technical Design team और subsystem manufacturer support मांगा गया
  • manufacturer ने low-level software log analysis के जरिए outage पैदा करने वाले संभावित flight plan की पहचान की
    • उस flight plan को समझने के बाद, controlled और safe तरीके से system recover करने की सही procedure दी
  • outage के दौरान manual entry और sectors के बीच manual coordination procedures शामिल थे, लेकिन manual procedures पर switch करने से UK traffic flow घटाने के लिए air traffic control restrictions लागू करने पड़ते

Frequentis AG और FPRSA-R

  • FPRSA subsystem NATS में कई वर्षों से मौजूद था, और 2018 में existing system को Frequentis AG के नए hardware और software से replace किया गया
  • Frequentis AG एक Austrian company है और air traffic control system suppliers में से एक है
  • इस manufacturer के ATC products करीब 150 देशों में operate होते हैं, और इसे aeronautical information management व message processing systems के क्षेत्र में global position वाला माना जाता है
  • Frequentis AG के careers page पर air traffic control systems से संबंधित Ada, C++, Java, Python दिखाई देते हैं, और Java सबसे commonly दिखता है

software bug और testing problem

  • FPRSA-R, IFPS द्वारा स्वीकार किए गए valid flight plan से UK airspace से संबंधित ICAO segment extract नहीं कर सका
  • waypoint identifiers globally unique नहीं होते, और यह known issue है
    • अगर duplicate waypoints बहुत दूर-दूर हों, तो normal flight plan फिर भी unambiguous हो सकता है
    • लेकिन software को इस condition को robustly handle करना चाहिए था
  • NATS ने कहा कि वह UK government के जरिए ICAO-managed global dataset से इस घटना से संबंधित कुछ duplicate waypoint names हटाने के विकल्प पर विचार कर सकता है
  • NATS CEO Martin Rolfe ने BBC से कहा कि यह घटना “1 in 15 million” probability वाली थी
    • उन्होंने कहा कि system 2018 में introduce हुआ था और तब से 15 million flight plans process कर चुका है
  • safety-critical system में flight plan processing stage, खासकर UK segment extraction जैसे important stage, test होने चाहिए
    • duplicate waypoint names को consider न करने वाली testing शायद इस bug को सामने नहीं ला पाई
    • random flight plans को बड़ी मात्रा में डालने वाली fuzzing उन inputs को खोजने में मदद कर सकती थी जो system को खराब failure mode में डालते हैं

failure mode की समस्या

  • एक single flight plan ने पूरे FPRSA-R automatic processing system को रोक दिया, और इसके परिणामस्वरूप कोई भी flight plan automatically process नहीं हुआ
  • बेहतर failure mode यह होता कि problematic single flight plan को अलग slow queue में भेज दिया जाता ताकि इंसान उसे manually process करे
  • NATS ने कहा कि वह IFPS और FPRSA-R के बीच data flow में specific message filter जोड़कर, ongoing या completed actions के रूप में, घटना पैदा करने वाली condition वाले flight plans को filter करेगा
  • FPRSA-R रुकने पर संबंधित flight plan केवल low-level software logs में ही identify हुआ
    • flight plan processing system में अगर किसी specific flight plan processing error से पूरा system रुक जाए, तो उस flight plan सहित alert monitoring team तक तुरंत पहुंचना ज्यादा उपयुक्त होता
  • NATS ने कहा कि same situation repeat होने पर FPRSA-R को quickly recover करने के लिए operational guidance तैयार की गई है, और technical operators को new procedure perform करने की training दी गई है
    • enhanced monitoring और additional engineering specialist staff भी activity supervise करेंगे

formal verification की संभावना

  • इस घटना के संबंधित stage और system में formal verification इस्तेमाल होने के स्पष्ट संकेत नहीं हैं, और report में भी इसका उल्लेख नहीं है
  • formal verification या model checking इस तरह के bugs कम करने में मदद कर सकते थे
  • हालांकि large-scale systems की end-to-end formal verification अभी शुरुआती stage में है, और formal verification का कुछ इस्तेमाल हुआ हो तब भी faulty code के operational environment में पहुंचने की संभावना बनी रहती है
  • final investigation results आने पर ही यह ज्यादा पता चलेगा कि वास्तव में कौन-सी verification methods इस्तेमाल हुई थीं

safety और public reporting

  • घटना के दौरान UK skies में aircraft सुरक्षित बने रहे
    • experienced air traffic controllers ने known flight plans, radio, radar, और visual observation के जरिए aircraft monitor किए
    • परिणाम life risk नहीं था, बल्कि यह था कि बहुत कम flights take off कर पाईं या उन्हें UK airspace से बचते हुए detour करना पड़ा
  • NATS ने flight numbers कम करने के measures लेकर safety बनाए रखी
  • published report काफी transparent और detailed है, और critical infrastructure के लिए ऐसी reporting important है
  • Ryanair के Michael O’Leary ने उस report को “rubbish” कहकर criticize किया और कहा कि यह aviation industry पर पड़े impact को कम दिखाती है, लेकिन यह assessment भी है कि initial report का scope NATS की failure extent analyze करना नहीं था

ज्यादा robust implementation की दिशा

  • problem दो sequences के waypoints से जुड़ी है
    • ADEXP: full waypoint list
    • ICAO: ADEXP waypoints की subsequence
  • ICAO plan में airspace entry/exit points का होना जरूरी नहीं है, इसलिए UK airspace से संबंधित ICAO का smallest continuous segment ढूंढना simple नहीं है
  • flawed algorithm की समस्या यह थी कि वह ICAO data और ADEXP data की ओर simultaneously pointing pointers manipulate कर रहा था, और clear invariants को code के बाहर रखता था
  • proposed approach है कि पहले ICAO और ADEXP data को एक Combined flight plan structure में align किया जाए, और फिर UK segment extract किया जाए
    • सभी possible reconciliations calculate करके ambiguous cases detect किए जाएं
    • reconciliation 0 हो तो ICAO और ADEXP को match नहीं किया जा सकता
    • multiple हों तो ambiguous है, इसलिए manual processing के लिए mark किया जा सकता है
  • Haskell example implementation NonUkPlan, CannotReconcileIcaoAdexp, AmbiguousReconciliationsOfIcaoAdexp errors को explicitly handle करता है
  • example में ADEXP list में duplicate identifier Q होने पर भी, अगर ICAO और ADEXP data unambiguously align हो जाए, तो सही UK segment return होता है
  • पूरा code uk-portion-of-ICAO में है

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

1 टिप्पणियां

 
GN⁺ 2023-09-12
Hacker News की राय

  • लगता है flight plan query में भौगोलिक रूप से अलग scope limit जोड़ना छूट गया था। पहले flight navigation system बनाते समय मुझे इस bug के बारे में पता था, इसे असल में देखा भी था, और इस bug से बचने के लिए geofence डालने वाली specification का पालन किया था

    • अगर navigation point के नाम globally unique नहीं हैं और regions के बीच routes आम हैं, तो समझ नहीं आता कि ऐसे navigation points को GUID क्यों नहीं दिए गए
    • जिज्ञासा है कि development में कौन-सी language इस्तेमाल हुई थी
    • ICAO standard 1978 से यह तय करता है कि अगर identifiers दोहराए जाएँ, तो वे एक-दूसरे से कम से कम 600 nautical miles (690 miles, 1,100 km) दूर होने चाहिए

  • “backup system ने flight plan पर वही logic लगाया और वही result निकला” वाला हिस्सा समस्या है। software में backup system को अलग logic इस्तेमाल करना चाहिए
    पहले Boeing में 757 stabilizer trim system पर काम करते समय, trim चलाने वाली wiring से दो avionics computers जुड़े थे और comparator के जरिए connect थे। अगर दोनों boxes सहमत नहीं होते, तो दोनों का अधिकार छिन जाता था
    दोनों boxes को अलग algorithms, अलग programming languages, अलग CPUs, firewall से अलग की गई अलग team के code के साथ design किया गया था, मकसद यह था कि एक तरफ का bug दूसरी तरफ को उसी तरह खराब न कर सके

    • यह शायद ऐसा 2oo2 system रहा होगा जिसमें pilot backup होता है, लेकिन 2oo2 की availability ज्यादा नहीं होती
      air traffic control system कम से कम 2oo3[1] होना चाहिए, यानी independent रूप से developed 3 systems में से हमेशा 2 का सहमत होना जरूरी हो। इससे एक system fail हो जाए तो भी बाकी दो चलते रहें और aviation industry की availability पर असर न पड़े
      इंसान को backup के रूप में रखना staffing और complexity के कारण संभव नहीं है। air traffic control system को IFR[2] और CVFR[3] conditions में separation control दे सकना चाहिए
      [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
      [2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
      [3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
    • पढ़ते हुए मेरे मन में भी पहले यही बात आई। यह failover system software bug की बजाय hardware failure mitigation के लिए design किया गया लगता है
    • “जब safety system fail होता है, तो वह ऐसे तरीके से fail होता है जिसमें वह safely fail नहीं कर पाता”
      J. Gall
    • अलग-अलग teams भी अक्सर वही गलती करती हैं। यह perfect architecture नहीं है, लेकिन जो तरीका बताया गया है वह उचित लगता है
    • थोड़ा अलग मुद्दा है, लेकिन MAX में ऐसे approach को जानते हुए भी reuse न करना अफसोसजनक है

  • मुझे याद है कि NATS में भी एक अलग problem ने यही असर पैदा किया था। primary system गिर गया, इसलिए secondary पर switch किया गया, लेकिन secondary भी ठीक उसी वजह से गिर गया
    failover शायद तभी करना चाहिए जब पता हो कि problem primary system में ही है, software में नहीं। बस switch कर देने वाला तरीका केवल यह एहसास मजबूत करता है कि असल में क्या करना चाहिए यह तय करने लायक पर्याप्त जानकारी expose नहीं की गई थी
    और ज्यादा परेशान करने वाली बात यह है कि “ValidateFlightPlan” जैसा कोई method नहीं था, ताकि किसी भी वजह से parse न हो सके तो error throw हो, और उस error को बहुत सरल तरीके से handle करने वाला path नहीं था। external input handler देखते समय ऐसा कौन programmer होगा जो यह न सोचे कि “अगर तोड़ देने वाला खराब input आए तो क्या करेंगे?”

    • अगर primary system के non-normal state में होने की जानकारी है, तो यह उम्मीद करते हुए switch कर सकते हैं कि problem disk जलने या cosmic ray से bit flip जैसी होगी
      असली safety feature वह 4 घंटे की buffer time है, इससे पहले कि manual processing की जरूरत पड़े
      aviation में core safety control “इसे शुरू से कैसे न टूटने दें” से ज्यादा “अगर किसी भी वजह से यह टूट जाए तो क्या करेंगे” के करीब है
    • validation न होने के साथ-साथ, article में यह हिस्सा ध्यान खींचता है
      programming style बहुत imperative है, और description से लगता है कि procedure text file से parse की गई data structure के बजाय flight plan के textual representation से सीधे deal कर रहा है। अगर सच में ऐसा है तो काफी चिंता की बात है, हालांकि यह सिर्फ description के तरीके की वजह से भी हो सकता है
      इस description के हिसाब से अगर यह सिर्फ text पर regex या substring matching चला रहा हो, और classes, objects या data structures न हों, तो भी आश्चर्य नहीं होगा। यह भी ध्यान में रखना होगा कि यह दशकों पुराना C code हो सकता है, जिस पर पूरे UK aviation की निर्भरता है और जिसे फिर से लिखना या replace करना संभव नहीं
    • यह पता करने का तरीका नहीं है कि hardware कारण नहीं था, इसलिए failover अपने-आप में सही था। लेकिन second failure होने पर response बेहतर design किया जाना चाहिए था ताकि cascading effect से बचा जा सके
    • electrical terms में कहें तो fuse बदलकर फिर उसे उड़ते हुए देखने जैसा था। दुकान में अब और fuse नहीं हैं। क्या इसे progress कहेंगे?
    • Ariane 5 launch failure[1] में भी similar problem थी, और result कहीं ज्यादा नाटकीय था
      primary system integer overflow से fail हुआ, और identical secondary system भी साथ में overflow हो गया। angle of attack बढ़ा, boosters अलग हुए, और rocket explode हो गया
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • समझ नहीं आता कि सिर्फ failed flight plan को ही human review queue में डालकर बाकी flights की processing क्यों जारी नहीं रखी गई। यह बात कि वह “feature” मौजूद ही नहीं था, सबसे ज्यादा समझ से बाहर है

    • code ने उस error को “यह तो कभी होना ही नहीं चाहिए!” की category में रखा, और असल में वही हो गया। उसे “flight plan data खराब है” या “data सही है लेकिन अभी supported नहीं है” के रूप में classify नहीं किया गया
      जब “कभी होना ही नहीं चाहिए” वाला error आता है, तो system को पता नहीं होता कि क्या गलत हुआ है, उसका असर कितना बड़ा और कितना व्यापक है। इस बार शायद आगे बढ़ना ठीक होता, लेकिन software में कोई घातक नया bug आ सकता था जो चुपचाप बाकी सभी flight plans को corrupt कर दे और लोगों की जान ले ले। अगर यह पता न हो कि आगे बढ़ना safe है या नहीं, तो रुकना ही पड़ता है
    • निष्पक्ष रूप से देखें तो लेख की शुरुआत में बताया गया है कि ये flight plans कभी-कभी उन aircraft के लिए भी process होते हैं जो पहले से उड़ान में होते हैं। हालांकि वे कम-से-कम UK से 4 घंटे से ज्यादा दूर होते हैं
      अगर किसी खास problematic aircraft को take off करने से रोका जा सकता हो, तो system चालू रखना ठीक हो सकता है, लेकिन अगर वह पहले से हवा में है तो मामला अलग है
      “UK airspace में आने वाला aircraft route में है, लेकिन पता नहीं कि वह कब और कहाँ enter करेगा। उस aircraft की position पता चलने तक additional flight plans रोक देते हैं” — यह फैसला पूरी तरह अव्यावहारिक नहीं है
      अगर flight plan सच में process नहीं किया जा सकता, तो UK पहुँचने से पहले उस aircraft को divert कराकर land करवाने जैसा solution उचित हो सकता है, लेकिन ऐसी चीज़ आखिरकार manual intervention का इंतज़ार ही करती है
    • लेख और postmortem दोनों ने FPRSA-R system के खराब failure mode को मुख्य समस्या माना, और मुझे लगता है यही सबसे अहम हिस्सा है
      हर system malfunction कर सकता है, इसलिए महत्वपूर्ण यह है कि वह अच्छे तरीके से malfunction करे और जिम्मेदार लोग उस स्थिति के लिए तैयार हों
      एक single flight plan ने समस्या पैदा की और पूरा FPRSA-R system ठप हो गया, जिससे flight plans बिल्कुल process नहीं हुए। अगर किसी एक flight plan में समस्या हो, तो उसे human manual processing के लिए अलग slow queue में भेजा जाना चाहिए। NATS ने भी “पहले से किए गए या चल रहे actions” में स्वीकार किया कि वे IFPS और FPRSA-R के बीच data flow में इस condition वाले flight plans को filter करने के लिए message filter जोड़ेंगे
    • safety-critical system में “unknown error” मिलने पर मानना पड़ता है कि सभी invariants टूट गए हैं और system undefined behavior में चला गया है, इसलिए रुकना ही पड़ता है
      यह कहना सही है कि इसे known error की तरह handle किया जाना चाहिए था, लेकिन व्यापक रूप से देखें तो यह “bug-free code लिखना चाहिए था” कहने जैसा है। भले ही उसे struct में parse किया गया हो, यह वैसा ही हो सकता है जैसे code ने मान लिया कि optional key मौजूद है और अचानक KeyError आ गया
      ऐसी घटनाओं की postmortem और improvement इस premise पर होनी चाहिए कि unpredictable, unhandled unknown error कभी-न-कभी आएगा, और तब उसे बेहतर तरीके से कैसे handle किया जाए। bug का solution bug fix करना है, लेकिन बड़े outage का कारण disaster recovery plan था जिसे reasonable time में execute नहीं किया जा सकता था। चाहे कोई भी programming practice, style, language या tool इस्तेमाल हो, इसी स्तर की घटना सबसे अच्छे developers के साथ भी कभी-न-कभी probability 1 के साथ फिर होगी
    • लेख में बताया गया algorithm संभवतः input flight plan के waypoints को क्रम से follow करने वाला simple procedural code नहीं था। किसी abstraction ने शायद यह तथ्य छिपा दिया कि यह input error था
      अगर code के नजरिए से यह underlying navigation waypoint database की integrity failure जैसा दिखा हो, तो flight plan processing रोकने का फैसला कहीं ज्यादा समझ आता है
      उदाहरण के लिए, अगर code waypoint और route store से पूछता है, “मुझे वह waypoint बताओ जहाँ यह route UK airspace से बाहर निकलता है”, फिर उस waypoint को शामिल करने वाला route segment ढूँढता है, और फिर assert करता है कि वह segment UK airspace से गुजरता है—लेकिन वह assertion fail हो जाए—तो यह flight plan की समस्या नहीं, बल्कि route data में built-in assumption टूटने जैसा दिख सकता है
      एक मायने में, यह सचमुच critical bug भी हो सकता है। इस घटना ने दिखाया कि algorithm ने data के बारे में जो assumptions बनाए थे वे गलत थे, और वह potentially गलत answer return कर सकता था

  • संबंधित लेख
    संयोग से समान waypoint name के कारण UK air traffic control system भ्रमित हुआ - https://news.ycombinator.com/item?id=37430384 - सितंबर 2023, 64 comments
    खराब flight plan data ने UK air traffic control outage कराया - https://news.ycombinator.com/item?id=37402766 - सितंबर 2023, 20 comments
    NATS air traffic control incident report ने root cause और solution विस्तार से बताए - https://news.ycombinator.com/item?id=37401864 - सितंबर 2023, 19 comments
    UK air traffic control network outage - https://news.ycombinator.com/item?id=37292406 - अगस्त 2023, 23 comments

    • The Daily का हालिया US aviation industry episode सुनने के बाद मुझे यकीन हो गया कि बहुत जल्द कोई catastrophic headline देखने को मिलेगी। इस तरह आगे नहीं चल सकता
    • इस लेख का title देखकर मुझे लगा कि यह अभी हुआ नया outage है

  • यह तथ्य कि उन्होंने Eurocontrol द्वारा पहले ही accept किए जा चुके French flight plan को दोष दिया, इस बात का सबूत है कि उन्हें software कैसे काम करता है, यह ठीक से पता नहीं था। और Austrian company को भी thorough testing की कमी की कुछ जिम्मेदारी लेनी चाहिए

    • UK होने के कारण उन्होंने France को ही दोष दिया। बुरी आदतें छोड़ना मुश्किल होता है

  • शानदार लेख है। पढ़ने पर सार मुझे ऐसा लगता है:
    दुनिया भर में इस्तेमाल होने वाले waypoint के नाम unique नहीं होते, और confusion से बचने के लिए एक तरह के patch के तौर पर नया standard कहता है कि समान identifiers को भौगोलिक रूप से पर्याप्त दूरी पर रखा जाए। फिर भी किसी एक route में वही waypoint name अलग-अलग locations का मतलब हो सकता है।
    Software ने इस possibility को consider नहीं किया, route calculation fail हो गया, उसने “fatal exception” फेंका और “maintenance mode” में चला गया। यानी मर गया।
    Backup system ने take over किया, लेकिन उसी data पर वही bug लगा और वह भी मर गया, और support staff को काफी जूझना पड़ा। आखिरकार software supplier से contact करने के बाद ही वे low-level logs मिले जिनसे cause सामने आया।

    • इस level के mission-critical system में code से परिचित कोई व्यक्ति 24/7 on-call क्यों नहीं था, यह समझ नहीं आता।
    • मुख्य बात यह थी कि उचित namespace नहीं था। किसे पता था कि aerospace engineers को operating systems पढ़ने पड़ेंगे।
      मेरा एक retired Air Force pilot दोस्त Cranfield University से graduate हुआ था; यह UK का प्रमुख aerospace engineering postgraduate institution है और training व research के लिए इसका अपना airport भी है[1]। उस दोस्त ने कहा था कि उसने Cranfield में operating systems पढ़े थे; अब जाकर वजह समझ आई।
      बाकी comments देखने पर लगता है कि namespace standard पहले से है, लेकिन NATS/ATC उसे इस्तेमाल नहीं करते। उम्मीद है इस घटना के बाद वे इसे इस्तेमाल करना शुरू करेंगे। Top comment ने geofencing bug की बात की थी, लेकिन अगर NATS/ATC सही namespace इस्तेमाल कर रहे होते, तो geofencing की शायद शुरू से जरूरत ही नहीं होती।
      [1] Cranfield University:
      https://en.wikipedia.org/wiki/Cranfield_University

  • “विवरण से ऐसा लगता है कि procedure किसी text file से parsed data structure नहीं, बल्कि flight plan के text representation को सीधे handle कर रहा है। अगर सच में ऐसा है तो काफी चिंताजनक है, हालांकि यह explain करने के तरीके की वजह से भी लग सकता है।”
    Aviation industry के कामों में यह तरीका आम है। Programmers से domain model या parsing के बारे में पूछो तो अक्सर blank stare मिलता है। वे validation code पसंद करते हैं, और validation न हो तो बस give up करना पसंद करते हैं। सब कुछ dumb data pipeline है, real world में होने वाली activities को model करने वाला code बिल्कुल नहीं है।
    किसी भी system में behavior वाला “flight plan” type या waypoint types का set जैसी चीज नहीं होती। Type हो भी तो C के नजरिए से string struct होता है, और उस struct member को access करने पर हर बार, सिर्फ एक बार नहीं बल्कि हर बार, parse किया जाता है। लेख में जैसा कहा गया है, “programming style बहुत imperative लगता है” — यह सही है।

    • Validation fail होने पर give up करना, गलत interpret किए गए data को फैलाकर कहीं ज्यादा complex bugs पैदा न करने के लिए, एक standard तरीका तो है। जल्दी validate करो, सख्ती से validate करो, error report करो, और input में क्या गड़बड़ है उसे जबरन interpret करने की कोशिश मत करो। जैसे ही “smart” बनने की कोशिश करते हो, safety hole बन जाता है।
      खराब input पर मर जाना गलत है, लेकिन specification के बिना unvalidated data को interpret करने की कोशिश करना आगे चलकर understanding mismatch, compatibility issues और unexpected edge conditions ला सकता है। पूरी तरह tested all-cases handling system, invalid input simulation tools, और parser व parser result इस्तेमाल करने वाले सारे code की formal verification के लिए कोई पैसा नहीं देना चाहता।
      पहले से ही non-compliant, legacy और buggy data transmitters, interface semantics और timing complexity की वजह से बहुत समस्याएँ हैं। Format या encoding गलत वाले data पर smartly respond करने की कोशिश करना और भी खतरनाक हो जाता है।
      Specification के मुताबिक काम करने वाला system बनाना ही मुश्किल और महँगा है। Unspecified behavior को और उदारता से accept करने वाली subtle variations बनाना या तो bugs को न्योता देना है, या ऐसा और महँगा system बनाना है जो purchase price criteria से बाहर हो जाए।
    • बेहद दिलचस्प और थोड़ा डरावना भी है। अलग-अलग industries ने, किसी बहुत स्पष्ट वजह के बिना, अपनी-अपनी अलग development culture बना ली है—यह बात रोचक है।

  • “UK air traffic control: investigation कि क्या French error ने outage पैदा किया”
    जाहिर है नहीं। यह UK system है, तो French airline की गलती कैसे हुई? ऐसे system में redundancy वाला fault-tolerant architecture होना चाहिए।
    एक खराब entry हो तो उसे reject करके आगे बढ़ जाना ही काफी हो सकता था।

    • अगर इसे खास तौर पर nationalist नजरिए से देखना ही है, तो वह software Austria का बना था।

  • वह दिन याद नहीं रखना चाहता। जिस destination तक सामान्यतः 2 घंटे में पहुँचना था, वहाँ पहुँचने में 15 घंटे लगे।
    Train, bus, फिर train ली, और tickets book करने के 30 मिनट बाद दो दिनों की सारी tickets बिक चुकी थीं।

    • Airport पर 6 घंटे इंतजार करने के बाद ही पता चला कि flight cancel हो गई है, और फिर rebook करना पड़ा। मैं family से मिलने New York जा रहा था, इसलिए कोई खास alternative transport भी नहीं था।