Runtuhnya sistem kendali lalu lintas udara Inggris

 (jameshaydon.github.io)
2 poin oleh GN⁺ 2023-09-12 | 1 komentar | Bagikan ke WhatsApp
  • Pada 28 Agustus 2023, gangguan pada FPRSA-R milik operator kendali lalu lintas udara Inggris NATS menyebabkan lebih dari 2.000 penerbangan dibatalkan, dengan biaya diperkirakan melebihi 100 juta pound
  • Rencana penerbangan yang memicu kekacauan adalah rencana yang valid dan telah diterima oleh Eurocontrol IFPS, sementara sistem NATS mencoba mencocokkan data ADEXP dan rute ICAO4444 untuk mengekstrak segmen wilayah udara Inggris
  • Penyebab langsungnya adalah dua waypoint yang berbeda secara geografis memiliki identifier yang sama, sehingga FPRSA-R salah mencocokkan identifier duplikat sebagai titik keluar dan gagal membentuk segmen Inggris yang valid
  • Sistem utama dan sistem cadangan memproses rencana penerbangan yang sama dengan logika yang sama, lalu masing-masing memunculkan critical exception dan masuk ke maintenance mode dalam 20 detik, sehingga pemrosesan otomatis berhenti
  • Pesawat tetap dikendalikan dengan aman, tetapi mode kegagalan yang membuat satu rencana penerbangan menghentikan seluruh sistem pemrosesan otomatis, kurangnya pengujian, dan prosedur pemulihan yang bergantung pada log tingkat rendah tetap menjadi masalah

Skala gangguan NATS pada 28 Agustus 2023

  • Operator kendali lalu lintas udara Inggris NATS mengalami gangguan teknis besar pada 28 Agustus 2023
  • Menurut BBC, lebih dari 2.000 penerbangan dibatalkan, dengan biaya diperkirakan melebihi 100 juta pound
  • Gangguan ini kemungkinan memengaruhi ratusan ribu orang
  • Laporan media awal membahas kemungkinan “rencana penerbangan yang salah” atau “kesalahan maskapai Prancis”, tetapi rencana penerbangan yang menyebabkan masalah sebenarnya adalah rencana penerbangan yang mematuhi ICAO4444 dan telah diterima oleh Eurocontrol IFPS
  • Penerbangan sebenarnya yang kemudian diidentifikasi sebagai pemicu gangguan adalah French Bee FBU731, penerbangan dari LAX/KLAX ke ORY/LFPO

Alur rencana penerbangan hingga mencapai NATS

  • Maskapai mengirimkan rencana penerbangan ke IFPS milik Eurocontrol
    • Jika IFPS menerima rencana penerbangan, pesawat dapat lepas landas setelah mendapat persetujuan ATC bandara keberangkatan
    • Pada tahap ini tidak diperlukan input dari NATS
  • IFPS meneruskan rencana penerbangan ke penyedia layanan navigasi udara terkait
    • NATS harus menerima rencana penerbangan setidaknya 4 jam sebelum pesawat memasuki wilayah udara Inggris
    • Jeda 4 jam ini berfungsi sebagai buffer untuk menyelesaikan masalah pemrosesan
  • Dalam operasi En-route NATS di Swanwick Centre, data diteruskan ke FPRSA-R
    • FPRSA-R mengubah data format ADEXP yang diterima dari IFPS menjadi format yang kompatibel dengan UK National Airspace System, yaitu NAS
    • NAS adalah sistem pemrosesan data penerbangan yang memuat informasi wilayah udara dan rute terkait

Perbedaan antara ICAO4444 dan ADEXP

  • Rencana penerbangan ICAO4444 adalah format yang dapat dibaca mesin dan, bila perlu, juga dapat dibaca manusia
    • Bagian rute mencakup kecepatan, ketinggian, waypoint, nama rute, dan penanda penerbangan langsung seperti DCT
    • Misalnya N0440 berarti 440 knot, dan F310 berarti Flight Level 310
  • IFPS mengonversi rencana penerbangan ICAO4444 ke format ADEXP lalu meneruskannya
    • ADEXP memuat rencana penerbangan ICAO4444 asli beserta waypoint geografis tambahan untuk rute wilayah Eropa
    • Untuk penerbangan yang tidak mendarat di Inggris tetapi melintas wilayah udara Inggris, waypoint yang dibutuhkan untuk sisa perjalanan di luar Inggris juga bisa disertakan
  • RTEPTS dalam ADEXP memuat ketinggian dan perkiraan waktu lintas setiap waypoint secara lebih rinci
    • Rute ICAO mungkin memiliki 9 waypoint, tetapi daftar ekspansi ADEXP dapat memuat 21 waypoint
    • Titik berangkat dan tujuan pada rute ICAO berada di field terpisah, sehingga tidak disertakan lagi dalam daftar rute

Waypoint duplikat yang menyebabkan gangguan

  • Daftar waypoint ADEXP yang bermasalah memuat dua waypoint yang berbeda secara geografis tetapi memiliki designator yang sama
    • ICAO dan organisasi lain telah berupaya menghapus nama waypoint yang tidak unik, tetapi nama duplikat masih ada di seluruh dunia
    • Standar terbaru menetapkan bahwa waypoint dengan identifier yang sama harus terpisah jauh secara geografis
    • Dalam insiden ini, kedua waypoint sama-sama berada di luar Inggris, satu di awal rute dan satu lagi di akhir rute, dengan jarak sekitar 4.000 mil laut
  • Pada rencana penerbangan yang diperluas untuk penerbangan FBU731 yang benar-benar teridentifikasi, waypoint DVL muncul dua kali
    • Satu adalah Devil’s Lake di Wisconsin, Amerika Serikat
    • Yang lain adalah Deauville di Normandy, Prancis
    • Yang terakhir dijelaskan muncul pada bagian akhir penerbangan selama proses ekspansi rute UN859

Prosedur pemrosesan FPRSA-R dan titik kegagalan

  • FPRSA-R mencari titik masuk wilayah udara Inggris dari awal data waypoint ADEXP
  • Lalu sistem mencari titik keluar wilayah udara Inggris, kemudian mencoba menemukan segmen yang sesuai dalam bagian ICAO4444
  • Rute ICAO tidak wajib memuat titik keluar wilayah udara
    • Perangkat lunak dirancang agar jika titik keluar tidak ada di rute ICAO, sistem akan mencari lagi menggunakan titik terdekat berikutnya dari file ADEXP
  • Dalam insiden ini, perangkat lunak menelusuri waypoint berikutnya dalam ADEXP dan menemukan identifier duplikat yang memang ada di rute ICAO
    • Namun identifier itu bukan waypoint nyata setelah keluar dari wilayah udara Inggris, melainkan waypoint geografis lain yang berada di awal rute
    • Akibatnya urutan atau segmen titik masuk dan titik keluar menjadi tidak valid, sehingga segmen ICAO yang sesuai dengan wilayah udara Inggris tidak dapat diekstrak
  • Laporan NATS menyebut titik ini sebagai root cause insiden dan menyimpulkan bahwa kontribusi terkait siber dapat dikesampingkan

Mengapa sistem utama dan sistem cadangan berhenti bersamaan

  • Perangkat lunak yang kritis bagi keselamatan dirancang untuk berpindah ke kondisi yang memerlukan intervensi manual bila tidak dapat melanjutkan dengan aman
  • Sistem utama FPRSA-R menilai bahwa sistem tidak dapat menjamin data rencana penerbangan yang benar, lalu memunculkan critical exception
    • Menulis file log ke system log
    • Masuk ke maintenance mode
    • Sistem C&M mendeteksi bahwa sistem utama tidak lagi tersedia
  • Sistem cadangan dirancang untuk mengambil alih pemrosesan saat sistem utama gagal
    • Berada pada hardware terpisah, catu daya terpisah, dan data feed terpisah
    • Namun sistem ini menerapkan logika yang sama pada rencana penerbangan yang sama dan menghasilkan critical exception yang sama
  • Dari penerimaan pesan ADEXP hingga sistem utama dan sistem cadangan sama-sama masuk maintenance mode, waktu yang dibutuhkan kurang dari 20 detik
  • Pada pukul 08:32 pemrosesan otomatis rencana penerbangan berhenti, dan setelah itu diperlukan input manual rencana penerbangan dalam buffer waktu 4 jam tersebut

Prosedur pemulihan dan dampak operasional

  • Tim dukungan 1st Line menyadari gangguan melalui sistem C&M khusus, sistem C&M pusat, dan umpan balik dari tim operasi
  • Respons awal adalah prosedur pemulihan standar berupa restart subsistem dari sistem C&M pusat
    • Beberapa upaya pemulihan gagal
    • Tim engineering 2nd Line dikerahkan untuk mendukung engineer di lokasi melalui video link jarak jauh
  • Setelah 1st Line dan 2nd Line gagal memulihkan layanan atau mengidentifikasi penyebab yang tepat, tim Technical Design dan dukungan dari vendor subsistem diminta membantu
  • Vendor mengidentifikasi rencana penerbangan yang tampaknya menyebabkan gangguan melalui analisis log perangkat lunak tingkat rendah
    • Setelah memahami rencana penerbangan tersebut, vendor memberikan prosedur yang tepat untuk memulihkan sistem dengan cara yang terkendali dan aman
  • Saat terjadi gangguan, prosedur input manual dan koordinasi manual antar sektor memang tersedia, tetapi beralih ke prosedur manual berarti pembatasan ATC harus diterapkan untuk mengurangi arus lalu lintas Inggris

Frequentis AG dan FPRSA-R

  • Subsistem FPRSA telah lama ada di NATS, dan pada 2018 sistem lama diganti dengan hardware dan software baru dari Frequentis AG
  • Frequentis AG adalah perusahaan Austria dan salah satu pemasok sistem kendali lalu lintas udara
  • Produk ATC vendor tersebut diketahui beroperasi di sekitar 150 negara, dan dianggap memiliki posisi global dalam bidang manajemen informasi aeronautika dan sistem pemrosesan pesan
  • Pada halaman lowongan Frequentis AG, Ada, C++, Java, Python muncul terkait sistem kendali lalu lintas udara, dan Java tampak paling sering muncul

Bug perangkat lunak dan masalah pengujian

  • FPRSA-R gagal mengekstrak segmen ICAO yang sesuai dengan wilayah udara Inggris dari rencana penerbangan valid yang telah diterima IFPS
  • Identifier waypoint tidak unik secara global, dan ini adalah masalah yang sudah diketahui
    • Jika waypoint duplikat terpisah sangat jauh, rencana penerbangan normal masih bisa tetap tidak ambigu
    • Namun perangkat lunak seharusnya menangani kondisi ini dengan andal
  • NATS menyatakan dapat meninjau, melalui pemerintah Inggris, cara menghapus sejumlah kecil nama waypoint duplikat dalam dataset global yang dikelola ICAO dan terkait dengan insiden ini
  • CEO NATS Martin Rolfe mengatakan kepada BBC bahwa insiden ini memiliki kemungkinan “1 banding 15 juta”
    • Ia mengatakan sistem tersebut diperkenalkan pada 2018 dan telah memproses 15 juta rencana penerbangan sejak saat itu
  • Untuk sistem yang kritis bagi keselamatan, tahap pemrosesan rencana penerbangan, khususnya tahap penting seperti ekstraksi segmen Inggris, seharusnya diuji
    • Pengujian yang tidak mempertimbangkan nama waypoint duplikat mungkin gagal mengungkap bug ini
    • Fuzzing dengan memasukkan rencana penerbangan acak dalam jumlah besar mungkin dapat membantu menemukan input yang membuat sistem masuk ke mode kegagalan yang buruk

Masalah pada mode kegagalan

  • Satu rencana penerbangan menghentikan seluruh sistem pemrosesan otomatis FPRSA-R, sehingga tidak ada rencana penerbangan apa pun yang dapat diproses secara otomatis
  • Mode kegagalan yang lebih baik adalah mengirim satu rencana penerbangan yang bermasalah ke antrean lambat terpisah agar diproses manual oleh manusia
  • NATS menyatakan bahwa sebagai langkah yang sudah berjalan atau telah selesai, mereka akan menambahkan filter pesan tertentu pada aliran data antara IFPS dan FPRSA-R untuk menyaring rencana penerbangan yang sesuai dengan kondisi penyebab insiden
  • Saat FPRSA-R berhenti, rencana penerbangan terkait baru dapat diidentifikasi dari log perangkat lunak tingkat rendah
    • Jika kesalahan pemrosesan rencana penerbangan tertentu dalam sistem pemrosesan rencana penerbangan menghentikan seluruh sistem, akan lebih tepat bila peringatan yang menyertakan rencana penerbangan tersebut langsung dikirim ke tim pemantauan
  • NATS menyatakan telah menyiapkan panduan operasional agar FPRSA-R dapat dipulihkan dengan cepat jika situasi yang sama terulang, dan operator teknis telah dilatih untuk menjalankan prosedur baru
    • Pemantauan yang diperkuat dan tambahan personel engineering spesialis juga akan mengawasi operasi

Kemungkinan verifikasi formal

  • Tidak ada indikasi yang jelas bahwa verifikasi formal digunakan pada tahap dan sistem yang terlibat dalam insiden ini, dan laporan juga tidak menyebutkannya
  • Verifikasi formal atau model checking mungkin dapat membantu mengurangi bug jenis ini
  • Namun verifikasi formal end-to-end untuk sistem berskala besar masih berada pada tahap awal, dan bahkan bila sebagian verifikasi formal digunakan, kemungkinan kode cacat masuk ke lingkungan operasional tetap ada
  • Hasil investigasi akhir masih diperlukan untuk mengetahui lebih jauh metode verifikasi apa yang sebenarnya digunakan

Keselamatan dan laporan terbuka

  • Pesawat di langit Inggris tetap aman sepanjang insiden
    • Pengendali lalu lintas udara yang berpengalaman memantau pesawat melalui rencana penerbangan yang diketahui, radio, radar, dan pengamatan visual
    • Hasilnya bukan risiko terhadap nyawa, melainkan situasi di mana jauh lebih sedikit penerbangan dapat lepas landas atau harus memutar untuk menghindari wilayah udara Inggris
  • NATS mengambil langkah pengurangan jumlah penerbangan untuk menjaga keselamatan
  • Laporan yang dipublikasikan cukup transparan dan rinci, dan pelaporan seperti ini penting untuk infrastruktur kritis
  • Michael O’Leary dari Ryanair mengkritik laporan tersebut sebagai “rubbish” dan mengatakan laporan itu mengecilkan dampaknya terhadap industri penerbangan, tetapi ada juga penilaian bahwa cakupan laporan awal itu memang bukan untuk menganalisis sejauh mana kegagalan NATS

Arah implementasi yang lebih tangguh

  • Masalahnya adalah menangani dua urutan waypoint
    • ADEXP: daftar waypoint lengkap
    • ICAO: subsekuens dari waypoint ADEXP
  • Karena rencana ICAO tidak wajib memuat titik masuk/keluar wilayah udara, mencari segmen kontinu terkecil dalam ICAO yang sesuai dengan wilayah udara Inggris bukanlah tugas sederhana
  • Masalah algoritme yang keliru adalah manipulasi pointer yang merujuk sekaligus ke data ICAO dan data ADEXP, sementara invariant yang tidak jelas dibiarkan berada di luar kode
  • Pendekatan yang diusulkan adalah terlebih dahulu merekonsiliasi data ICAO dan ADEXP ke dalam satu struktur rencana penerbangan Combined, lalu mengekstrak segmen Inggris setelahnya
    • Menghitung semua reconciliation yang mungkin untuk mendeteksi kasus ambigu
    • Jika reconciliation berjumlah 0, berarti ICAO dan ADEXP tidak dapat dicocokkan
    • Jika ada lebih dari satu, berarti ambigu dan dapat dijadikan target pemrosesan manual
  • Implementasi contoh dalam Haskell secara eksplisit menangani error NonUkPlan, CannotReconcileIcaoAdexp, AmbiguousReconciliationsOfIcaoAdexp
  • Dalam contoh tersebut, meskipun daftar ADEXP memiliki identifier duplikat Q, sistem tetap mengembalikan segmen Inggris yang benar jika data ICAO dan ADEXP dapat dicocokkan tanpa ambigu
  • Kode lengkap tersedia di uk-portion-of-ICAO

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-12
Opini Hacker News

  • Intinya, mereka lupa memasukkan batasan cakupan yang terpisah secara geografis dalam kueri rencana penerbangan. Dulu saat membuat sistem navigasi penerbangan, saya sudah tahu bug ini, pernah melihatnya langsung, dan pernah mengikuti spesifikasi yang meminta penambahan geofence untuk menghindari bug ini

    • Jika nama waypoint navigasi tidak unik secara global dan rute antarkawasan itu umum, saya tidak mengerti mengapa waypoint navigasi seperti ini tidak diberi GUID
    • Saya penasaran, bahasa apa yang dipakai untuk pengembangannya?
    • Standar ICAO sejak 1978 menetapkan bahwa jika identifier ingin diduplikasi, keduanya harus berjarak lebih dari 600 mil laut (690 mil, 1.100 km) satu sama lain

  • Bagian “sistem cadangan menerapkan logika yang sama pada rencana penerbangan dan menghasilkan hasil yang sama” itulah masalahnya. Dalam perangkat lunak, sistem cadangan seharusnya memakai logika yang berbeda
    Dulu saat saya menangani sistem trim stabilizer 757 di Boeing, ada dua komputer avionik yang terhubung ke kabel yang menggerakkan trim, dan keduanya tersambung melalui komparator. Jika kedua kotak itu tidak sepakat, keduanya kehilangan otoritas
    Kedua kotak itu dirancang dengan algoritme berbeda, bahasa pemrograman berbeda, CPU berbeda, dan kode dari tim berbeda yang dipisahkan firewall, dengan tujuan agar bug di satu sisi tidak merusak sisi lain dengan cara yang sama

    • Ini kemungkinan adalah sistem 2oo2 dengan pilot sebagai cadangan, tetapi 2oo2 tidak memiliki ketersediaan tinggi
      Sistem kendali lalu lintas udara setidaknya harus berupa 2oo3[1], yaitu struktur di mana 2 dari 3 sistem yang dikembangkan secara independen harus selalu sepakat. Dengan begitu, meski satu sistem gagal, dua lainnya tetap beroperasi dan tidak memengaruhi ketersediaan industri penerbangan
      Menjadikan manusia sebagai cadangan tidak mungkin karena kebutuhan personel dan kompleksitas. Sistem kendali lalu lintas udara harus mampu menyediakan layanan separasi dalam kondisi IFR[2] dan CVFR[3]
      [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...
    • Saat membacanya, saya juga langsung berpikir begitu. Sistem failover ini tampaknya dirancang untuk memitigasi kegagalan perangkat keras, bukan bug perangkat lunak
    • “Jika sistem pengaman gagal, ia gagal dengan cara yang tidak aman”
      J. Gall
    • Tim yang berbeda pun sering melakukan kesalahan yang sama. Itu bukan arsitektur yang sempurna, tetapi pendekatan yang dijelaskan tampak masuk akal
    • Sedikit di luar topik, tetapi sayang sekali pendekatan seperti itu diketahui namun tidak digunakan kembali pada MAX

  • Saya ingat pernah ada masalah lain di NATS yang menghasilkan efek yang sama. Sistem utama tumbang lalu dialihkan ke sistem sekunder, tetapi sistem sekunder juga tumbang karena alasan yang persis sama
    Failover sepertinya hanya boleh dilakukan ketika diketahui bahwa masalahnya ada pada sistem utama itu sendiri, bukan pada perangkat lunaknya. Cara yang sekadar beralih begitu saja hanya memperkuat kesan bahwa tidak cukup informasi yang diekspos untuk menilai apa yang sebenarnya harus dilakukan
    Bagian yang lebih membuat tidak nyaman adalah tidak adanya metode seperti “ValidateFlightPlan”, sehingga jika tidak bisa di-parse karena alasan apa pun, sistem melempar error, dan tidak ada jalur untuk menangani error itu dengan sangat sederhana. Saya jadi bertanya-tanya, adakah programmer yang melihat pemroses input eksternal tanpa berpikir, “kalau input buruk yang merusak datang, apa yang harus dilakukan?”

    • Jika sistem utama diketahui tidak berada dalam kondisi normal, Anda bisa saja mencoba beralih sambil berharap masalahnya seperti disk terbakar atau bit flip akibat sinar kosmik
      Fitur keselamatan yang sebenarnya adalah jeda waktu 4 jam sebelum pemrosesan manual diperlukan
      Dalam penerbangan, kontrol keselamatan inti lebih dekat ke “apa yang harus dilakukan jika ini rusak karena alasan apa pun” daripada “bagaimana caranya agar ini tidak rusak sejak awal”
    • Selain tidak adanya validasi, bagian ini menonjol bagi saya
      Gaya pemrogramannya sangat imperatif, dan dari penjelasannya saja terdengar seolah prosedurnya menangani representasi teks dari rencana penerbangan secara langsung, bukan struktur data yang di-parse dari file teks. Jika memang begitu, itu cukup mengkhawatirkan, meski bisa juga hanya karena cara penjelasannya
      Jika penjelasan ini akurat, saya tidak akan heran kalau strukturnya hanya menjalankan regex atau pencocokan substring pada teks, tanpa class, object, atau struktur data. Kita juga harus mempertimbangkan kemungkinan bahwa ini adalah kode C berusia puluhan tahun yang menjadi tumpuan seluruh penerbangan Inggris dan tidak bisa ditulis ulang atau diganti
    • Karena tidak ada cara untuk memastikan bahwa penyebabnya bukan perangkat keras, failover itu sendiri benar. Namun respons saat kegagalan kedua terjadi seharusnya dirancang lebih baik agar efek berantai bisa dihindari
    • Secara kelistrikan, ini seperti mengganti sekring lalu melihatnya putus lagi. Toko sudah tidak punya sekring lagi. Apakah ini kemajuan?
    • Kegagalan peluncuran Ariane 5[1] juga merupakan masalah serupa, dan hasilnya jauh lebih spektakuler
      Sistem utama gagal karena integer overflow, dan sistem sekunder yang identik juga ikut overflow. Sudut serang meningkat, booster terlepas, lalu roket meledak
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • Saya tidak mengerti mengapa hanya rencana penerbangan yang gagal yang dimasukkan ke antrean tinjauan manusia, sementara penerbangan lainnya tidak bisa terus diproses. Fakta bahwa “fitur” itu tidak ada adalah bagian yang paling sulit dipahami

    • Kode mengklasifikasikan kesalahan itu sebagai “ini sama sekali tidak boleh terjadi!”, dan hal itu benar-benar terjadi. Kesalahan itu tidak diklasifikasikan sebagai “data rencana penerbangan buruk” atau “datanya benar, tetapi belum didukung”
      Jika terjadi kesalahan “sama sekali tidak boleh terjadi”, sistem tidak bisa tahu apa yang salah, serta seberapa besar dan luas dampaknya. Seperti kasus ini, mungkin saja aman untuk terus berjalan, tetapi bisa juga ada bug baru yang fatal di perangkat lunak yang diam-diam mencemari semua rencana penerbangan lain dan menewaskan orang. Jika tidak tahu apakah aman untuk lanjut, sistem harus berhenti
    • Agar adil, di bagian awal tulisan disebutkan bahwa rencana penerbangan ini terkadang diproses untuk pesawat yang sudah berada di udara. Memang setidaknya masih berjarak lebih dari 4 jam dari Inggris
      Jika pesawat tertentu yang bermasalah bisa dicegah lepas landas, menjalankan sistem terus mungkin tidak apa-apa, tetapi ceritanya berbeda jika pesawat itu sudah mengudara
      Penilaian “ada pesawat yang sedang dalam rute menuju wilayah udara Inggris, tetapi kita tidak tahu kapan dan di mana akan masuk. Hentikan rencana penerbangan tambahan sampai posisi pesawat itu diketahui” tidak sepenuhnya tidak masuk akal
      Jika rencana penerbangannya benar-benar tidak bisa diproses, solusi seperti mengalihkan pesawat tersebut untuk mendarat sebelum mencapai Inggris mungkin masuk akal, tetapi hal seperti itu pada akhirnya harus menunggu intervensi manual
    • Baik tulisan maupun analisis pascainsiden melihat mode kegagalan buruk sistem FPRSA-R sebagai masalah utama, dan menurut saya ini bagian paling penting
      Semua sistem bisa mengalami malfungsi, jadi yang penting adalah malfungsi dengan cara yang baik dan para penanggung jawab siap menghadapi situasi itu
      Satu rencana penerbangan menimbulkan masalah, lalu seluruh sistem FPRSA-R mati sehingga tidak ada rencana penerbangan yang diproses sama sekali. Jika satu rencana penerbangan bermasalah, seharusnya dipindahkan ke antrean lambat terpisah untuk ditangani manual oleh manusia. NATS juga mengakui dalam “tindakan yang sudah dilakukan atau sedang berjalan” bahwa mereka akan menambahkan filter pesan pada aliran data antara IFPS dan FPRSA-R untuk menyaring rencana penerbangan dengan kondisi tersebut
    • Pada sistem yang kritikal untuk keselamatan, saat menghadapi “kesalahan tidak diketahui”, kita harus berasumsi semua invarian telah rusak dan sistem masuk ke perilaku tak terdefinisi, sehingga tidak ada pilihan selain berhenti
      Pernyataan bahwa ini seharusnya ditangani sebagai kesalahan yang sudah dikenal memang valid, tetapi secara luas itu mirip dengan mengatakan “seharusnya menulis kode tanpa bug”. Bahkan jika sudah diparsing menjadi struktur, ini bisa seperti kode yang berasumsi ada kunci pilihan lalu tiba-tiba memunculkan KeyError
      Analisis pascainsiden dan perbaikan untuk hal seperti ini harus berangkat dari asumsi bahwa kesalahan tidak diketahui yang tak tertangani dan tak bisa diprediksi suatu saat akan terjadi, lalu membahas bagaimana menanganinya dengan lebih baik saat itu terjadi. Solusi untuk bug adalah memperbaiki bug, tetapi penyebab gangguan besar ini adalah rencana pemulihan bencana yang tidak bisa dijalankan dalam waktu yang wajar. Apa pun praktik, gaya, bahasa, atau alat pemrograman yang dipakai, insiden pada tingkat serupa dengan probabilitas 1 akan terjadi lagi suatu saat, bahkan pada developer terbaik sekalipun
    • Algoritma yang dijelaskan dalam tulisan itu kemungkinan besar bukan kode prosedural sederhana yang mengikuti waypoint dalam rencana penerbangan masukan secara berurutan. Bisa jadi suatu abstraksi menutupi fakta bahwa ini adalah kesalahan input
      Jika dari sudut pandang kode hal itu tampak seperti kegagalan integritas pada basis data waypoint navigasi yang mendasarinya, keputusan untuk menghentikan pemrosesan rencana penerbangan jauh lebih bisa dipahami
      Misalnya, jika kode bertanya kepada penyimpanan waypoint dan rute, “carikan waypoint pada rute ini yang keluar dari wilayah udara Inggris”, lalu menemukan segmen rute yang berisi waypoint itu, kemudian menegaskan bahwa segmen tersebut melewati wilayah udara Inggris tetapi penegasan itu gagal, maka ini bisa tampak bukan sebagai masalah rencana penerbangan, melainkan sebagai asumsi yang tertanam dalam data rute yang telah rusak
      Dalam arti tertentu, ini sebenarnya juga bisa jadi bug fatal. Insiden ini menunjukkan bahwa asumsi yang dibuat algoritma terhadap data ternyata salah dan berpotensi mengembalikan jawaban yang keliru

  • Tulisan terkait
    Sistem ATC Inggris tertipu karena nama waypoint yang kebetulan sama - https://news.ycombinator.com/item?id=37430384 - September 2023, 64 komentar
    Data rencana penerbangan yang buruk menyebabkan gangguan ATC Inggris - https://news.ycombinator.com/item?id=37402766 - September 2023, 20 komentar
    Laporan insiden ATC NATS mengungkap akar penyebab dan solusinya secara rinci - https://news.ycombinator.com/item?id=37401864 - September 2023, 19 komentar
    Gangguan jaringan ATC Inggris - https://news.ycombinator.com/item?id=37292406 - Agustus 2023, 23 komentar

    • Setelah mendengar episode terbaru The Daily tentang industri penerbangan AS, saya yakin tidak lama lagi kita akan melihat judul berita tentang bencana besar. Cara seperti ini tidak bisa terus berlanjut
    • Melihat judul tulisan ini, saya kira ini gangguan yang baru saja terjadi

  • Fakta bahwa mereka menyalahkan rencana penerbangan Prancis yang sudah diterima Eurocontrol adalah bukti bahwa mereka tidak benar-benar memahami cara kerja perangkat lunaknya. Dan perusahaan Austria itu juga harus memikul sebagian tanggung jawab atas kurangnya pengujian intensif

    • Itu hanya karena ini Inggris, jadi mereka menyalahkan Prancis. Kebiasaan buruk sulit ditinggalkan

  • Tulisan yang bagus. Setelah dibaca, menurut saya intinya begini
    Nama waypoint yang dipakai di seluruh dunia tidak unik, dan sebagai semacam tambalan untuk menghindari kebingungan, standar terbaru menyarankan agar identifier yang sama ditempatkan cukup jauh secara geografis. Meski begitu, dalam satu rute penerbangan, nama waypoint yang sama masih bisa merujuk ke lokasi yang berbeda
    Perangkat lunaknya tidak memperhitungkan kemungkinan itu, perhitungan rute gagal, lalu melempar “fatal exception” dan masuk ke “maintenance mode”. Dengan kata lain, mati
    Sistem cadangan mengambil alih, tetapi dengan data yang sama terkena bug yang sama dan akhirnya juga mati; staf dukungan pun kerepotan. Pada akhirnya, baru setelah menghubungi pemasok perangkat lunak, mereka menemukan log level rendah yang mengungkap penyebabnya

    • Saya tidak paham mengapa untuk sistem mission-critical pada level seperti ini tidak ada orang yang paham kode yang siaga panggilan 24/7
    • Intinya adalah tidak adanya namespace yang tepat. Siapa sangka insinyur dirgantara harus belajar sistem operasi
      Teman saya, pensiunan pilot Angkatan Udara, lulus dari Cranfield University, salah satu institusi pascasarjana teknik dirgantara terkemuka di Inggris yang juga memiliki bandara sendiri untuk pendidikan dan riset[1]. Teman itu bilang ia belajar sistem operasi di Cranfield, dan sekarang saya baru mengerti alasannya
      Dari komentar lain, tampaknya standar namespace sebenarnya sudah ada, tetapi NATS/ATC tidak menggunakannya. Semoga kejadian ini membuat mereka akhirnya mulai memakainya. Komentar teratas menyebut bug geofencing, tetapi kalau NATS/ATC memakai namespace yang benar, geofencing kemungkinan besar tidak diperlukan sejak awal
      [1] Cranfield University:
      https://en.wikipedia.org/wiki/Cranfield_University

  • “Dari penjelasannya saja, prosedurnya terdengar seperti langsung menangani representasi teks dari flight plan, bukan struktur data yang diparse dari file teks. Kalau memang begitu, itu cukup mengkhawatirkan, meski bisa juga hanya karena cara penjelasannya”
    Dalam pekerjaan di industri penerbangan, cara seperti ini umum. Kalau Anda bertanya kepada programmer tentang domain model atau parsing, mereka sering hanya menatap kosong. Mereka suka kode validasi, dan kalau validasi gagal, mereka suka langsung menyerah. Semuanya pipeline data bodoh, dan sama sekali tidak ada kode yang memodelkan aktivitas yang terjadi di dunia nyata
    Di sistem mana pun tidak ada tipe “flight plan” yang punya perilaku, atau kumpulan tipe waypoint. Kalaupun ada tipe, itu adalah struct string dari sudut pandang C, dan setiap kali anggota struct itu diakses, ia diparse lagi—bukan sekali, melainkan setiap kali. Seperti yang disebutkan dalam tulisan, “gaya pemrogramannya tampak sangat imperatif” memang benar

    • Menyerah saat validasi gagal sebenarnya adalah cara standar agar data yang disalahartikan tidak menyebar dan melahirkan bug yang jauh lebih rumit. Validasi lebih awal, validasi dengan ketat, laporkan error, dan jangan mencoba memaksa menafsirkan bagian input yang aneh. Begitu mencoba bersikap “pintar”, celah keselamatan muncul
      Mati karena input buruk memang salah, tetapi mencoba menafsirkan data yang belum divalidasi tanpa spesifikasi mudah memicu ketidaksesuaian pemahaman di kemudian hari, masalah kompatibilitas, dan kondisi batas yang tak terduga. Tidak ada yang mau membayar untuk sistem yang menangani semua kasus yang telah diuji sepenuhnya, alat simulasi input salah, serta verifikasi formal untuk parser dan semua kode yang memakai hasil parser
      Sudah banyak masalah akibat pengirim data yang tidak patuh, legacy, atau bug, serta semantik antarmuka dan kompleksitas timing. Jika mencoba menangani data yang format atau encoding-nya salah secara “pintar”, risikonya jadi lebih besar
      Membuat sistem yang bekerja sesuai spesifikasi saja sudah sulit dan mahal. Variasi halus yang lebih toleran terhadap perilaku yang tidak dispesifikasikan sama saja meminta bug, atau membuat sistem yang lebih mahal dan tidak lolos kriteria harga pembelian
    • Sangat menarik dan juga agak menakutkan. Menarik melihat berbagai industri membentuk budaya pengembangan yang berbeda-beda karena alasan yang tidak terlalu jelas

  • “Pengendalian lalu lintas udara Inggris: menyelidiki apakah kesalahan Prancis menyebabkan gangguan”
    Tentu saja tidak. Ini sistem Inggris; bagaimana bisa menjadi kesalahan maskapai Prancis? Sistem seperti ini seharusnya punya arsitektur tahan-kesalahan dengan redundansi
    Mungkin cukup dengan menolak satu entri yang buruk lalu terus berjalan

    • Kalau mau diperdebatkan secara nasionalistis, perangkat lunaknya buatan Austria

  • Itu hari yang tidak ingin saya ingat. Perjalanan ke tujuan yang biasanya hanya 2 jam memakan waktu 15 jam
    Saya naik kereta, bus, lalu kereta lagi, dan 30 menit setelah saya memesan tiket, semua tiket untuk dua hari berikutnya habis terjual

    • Setelah menunggu 6 jam di bandara, baru saya tahu penerbangannya dibatalkan, dan harus memesan ulang. Saya sedang menuju New York untuk menemui keluarga, jadi tidak ada banyak pilihan transportasi pengganti