Der Zusammenbruch des britischen Flugsicherungssystems

 (jameshaydon.github.io)
2 Punkte von GN⁺ 2023-09-12 | 1 Kommentare | Auf WhatsApp teilen
  • Am 28. August 2023 führte ein Ausfall von NATS FPRSA-R, dem Betreiber der britischen Flugsicherung, zur Streichung von mehr als 2.000 Flügen; die Kosten werden auf über 100 Millionen Pfund geschätzt
  • Der Flugplan, der das Chaos auslöste, war ein von Eurocontrol IFPS akzeptierter gültiger Plan, und das NATS-System versuchte, ADEXP-Daten mit einer ICAO4444-Route abzugleichen, um den Abschnitt im britischen Luftraum zu extrahieren
  • Die unmittelbare Ursache war, dass zwei geografisch unterschiedliche Wegpunkte dieselbe Kennung hatten; FPRSA-R ordnete eine falsche doppelte Kennung als Austrittspunkt zu und konnte dadurch keinen gültigen britischen Streckenabschnitt bilden
  • Hauptsystem und Backup-System verarbeiteten denselben Flugplan mit derselben Logik, warfen jeweils eine critical exception und wechselten innerhalb von 20 Sekunden in den maintenance mode, wodurch die automatische Verarbeitung gestoppt wurde
  • Die Flugzeuge wurden weiterhin sicher kontrolliert, aber der Fehlermodus, bei dem ein einzelner Flugplan das gesamte automatische Verarbeitungssystem stoppen konnte, unzureichende Tests und ein Wiederherstellungsverfahren, das auf Low-Level-Logs beruhte, blieben problematisch

Das Ausmaß des NATS-Ausfalls am 28. August 2023

  • NATS, der Betreiber der britischen Flugsicherung, erlitt am 28. August 2023 eine schwerwiegende technische Störung
  • Laut BBC wurden mehr als 2.000 Flüge gestrichen, die Kosten werden auf über 100 Millionen Pfund geschätzt
  • Der Ausfall könnte Hunderttausende Menschen betroffen haben
  • Frühe Medienberichte sprachen von einem „falschen Flugplan“ oder einem „Fehler einer französischen Fluggesellschaft“, aber der Flugplan, der das Problem auslöste, war ein von Eurocontrol IFPS akzeptierter und ICAO4444-konformer Flugplan
  • Später wurde der tatsächlich auslösende Flug als French Bee FBU731 identifiziert, ein Flug von LAX/KLAX nach ORY/LFPO

Wie der Flugplan NATS erreicht

  • Fluggesellschaften reichen Flugpläne bei Eurocontrols IFPS ein
    • Wenn IFPS einen Flugplan akzeptiert, kann das Flugzeug nach Freigabe durch die Flugsicherung am Abflugort starten
    • An diesem Punkt ist keine Eingabe von NATS erforderlich
  • IFPS leitet den Flugplan an die zuständigen Flugsicherungsdienstleister weiter
    • NATS muss den Flugplan mindestens 4 Stunden vor dem Einflug des Flugzeugs in den britischen Luftraum erhalten
    • Diese 4 Stunden dienen als Puffer, um Verarbeitungsprobleme lösen zu können
  • Im En-route-Betrieb von NATS im Swanwick Centre werden die Daten an FPRSA-R weitergegeben
    • FPRSA-R wandelt die von IFPS erhaltenen Daten im ADEXP-Format in ein mit dem UK National Airspace System, also NAS, kompatibles Format um
    • NAS ist ein System zur Verarbeitung von Flugdaten, das die relevanten Luftraum- und Routeninformationen enthält

Der Unterschied zwischen ICAO4444 und ADEXP

  • Ein ICAO4444-Flugplan ist maschinenlesbar und bei Bedarf auch für Menschen lesbar
    • Der Routenteil enthält Geschwindigkeit, Höhe, Wegpunkte, Routennamen und Angaben für Direktflüge wie DCT
    • Zum Beispiel bedeutet N0440 440 Knoten und F310 Flight Level 310
  • IFPS konvertiert ICAO4444-Flugpläne und übermittelt sie im ADEXP-Format
    • ADEXP enthält zusammen mit dem ursprünglichen ICAO4444-Flugplan zusätzliche geografische Wegpunkte für die europäische Regionalroute
    • Flüge, die nicht im Vereinigten Königreich landen, sondern nur durch den britischen Luftraum fliegen, können auch Wegpunkte für den weiteren Reiseverlauf außerhalb des Vereinigten Königreichs enthalten
  • RTEPTS in ADEXP enthält detailliertere Angaben zur Höhe und zur erwarteten Überflugzeit jedes Wegpunkts
    • Eine ICAO-Route kann 9 Wegpunkte enthalten, während die erweiterte ADEXP-Liste 21 Wegpunkte umfassen kann
    • Abflug- und Zielort der ICAO-Route stehen in separaten Feldern und werden daher nicht erneut in der Routenliste aufgeführt

Die doppelten Wegpunkte, die den Ausfall verursachten

  • In der problematischen ADEXP-Wegpunktliste hatten zwei geografisch unterschiedliche Wegpunkte denselben designator
    • ICAO und andere Organisationen arbeiten daran, nicht eindeutige Wegpunktnamen zu entfernen, doch weltweit existieren weiterhin Duplikate
    • Neuere Standards verlangen, dass Wegpunkte mit derselben Kennung geografisch weit voneinander entfernt liegen müssen
    • Die beiden Wegpunkte in diesem Fall lagen beide außerhalb des Vereinigten Königreichs, einer am Anfang und einer am Ende der Route, etwa 4.000 Seemeilen voneinander entfernt
  • Im erweiterten Flugplan des tatsächlich identifizierten Flugs FBU731 erschien der Wegpunkt DVL zweimal
    • einmal als Devil’s Lake in Wisconsin, USA
    • das andere Mal als Deauville in der Normandie, Frankreich
    • Letzterer tauchte demnach bei der Erweiterung der Flugroute UN859 im späteren Flugverlauf auf

Der Verarbeitungsablauf von FPRSA-R und die Fehlerstelle

  • FPRSA-R sucht in den ADEXP-Wegpunktdaten vom Anfang an nach dem Eintrittspunkt in den britischen Luftraum
  • Anschließend sucht es den Austrittspunkt aus dem britischen Luftraum und versucht dann, im ICAO4444-Abschnitt den entsprechenden Streckenabschnitt zu finden
  • Der Austrittspunkt des Luftraums muss in der ICAO-Route nicht zwingend enthalten sein
    • Die Software war so ausgelegt, dass sie, falls der Austrittspunkt nicht in der ICAO-Route vorkommt, stattdessen den nächstfolgenden passenden Punkt aus der ADEXP-Datei verwendet
  • In diesem Fall folgte die Software den nächsten Wegpunkten in ADEXP und fand eine doppelte Kennung, die in der ICAO-Route vorhanden war
    • Diese Kennung gehörte jedoch nicht zum tatsächlichen Wegpunkt nach dem Austritt aus dem britischen Luftraum, sondern zu einem anderen geografischen Wegpunkt am Anfang der Route
    • Dadurch waren Reihenfolge oder Abschnitt zwischen Eintritts- und Austrittspunkt ungültig, sodass der ICAO-Abschnitt für den britischen Luftraum nicht extrahiert werden konnte
  • Der NATS-Bericht bezeichnete diesen Punkt als root cause des Vorfalls und kam zu dem Schluss, dass ein Cyber-Beitrag ausgeschlossen werden könne

Warum Hauptsystem und Backup-System gleichzeitig stoppten

  • Sicherheitskritische Software ist so ausgelegt, dass sie in einen Zustand wechselt, der manuelle Eingriffe erfordert, wenn sie nicht sicher fortfahren kann
  • Das FPRSA-R-Hauptsystem entschied, dass es die Korrektheit der Flugdaten nicht garantieren könne, und löste eine critical exception aus
    • Es schrieb eine Logdatei in das Systemlog
    • Es wechselte in den maintenance mode
    • Das C&M-System erkannte, dass das Hauptsystem nicht mehr verfügbar war
  • Das Backup-System war dafür ausgelegt, bei einem Ausfall des Hauptsystems die Verarbeitung zu übernehmen
    • Es lief auf separater Hardware, mit separater Stromversorgung und separatem Daten-Feed
    • Es wandte jedoch dieselbe Logik auf denselben Flugplan an und erzeugte mit demselben Ergebnis ebenfalls eine critical exception
  • Vom Empfang der ADEXP-Nachricht bis zum Wechsel von Haupt- und Backup-System in den maintenance mode vergingen weniger als 20 Sekunden
  • Um 08:32 wurde die automatische Flugplanverarbeitung gestoppt; danach war innerhalb des 4-Stunden-Puffers die manuelle Eingabe von Flugplänen erforderlich

Wiederherstellungsverfahren und betriebliche Auswirkungen

  • Das 1st-Line-Supportteam erkannte die Störung über das dedizierte C&M-System, das zentrale C&M-System und Rückmeldungen aus dem Betrieb
  • Die erste Reaktion war das standardmäßige Wiederherstellungsverfahren, bei dem die Subsysteme über das zentrale C&M-System neu gestartet werden
    • Mehrere Wiederherstellungsversuche schlugen fehl
    • Das 2nd-Line-Engineering-Team wurde hinzugezogen und unterstützte die Techniker vor Ort per Remote-Videoverbindung
  • Als 1st Line und 2nd Line weder den Dienst wiederherstellen noch die genaue Ursache identifizieren konnten, wurden das Technical Design Team und der Support des Subsystem-Herstellers eingeschaltet
  • Der Hersteller identifizierte anhand der Analyse von Low-Level-Softwarelogs den Flugplan, der den Ausfall wahrscheinlich ausgelöst hatte
    • Nachdem dieser Flugplan verstanden war, lieferte der Hersteller das genaue Verfahren, um das System kontrolliert und sicher wiederherzustellen
  • Für Störungen waren manuelle Eingaben und manuelle Abstimmungsverfahren zwischen den Sektoren vorgesehen, aber beim Wechsel auf manuelle Verfahren mussten Beschränkungen der Flugsicherung angewandt werden, um den Verkehrsfluss im Vereinigten Königreich zu reduzieren

Frequentis AG und FPRSA-R

  • Das FPRSA-Subsystem war bei NATS bereits viele Jahre im Einsatz; 2018 wurde das bestehende System durch neue Hardware und Software von Frequentis AG ersetzt
  • Frequentis AG ist ein österreichisches Unternehmen und einer der Anbieter von Flugsicherungssystemen
  • Die ATC-Produkte des Herstellers sind Berichten zufolge in rund 150 Ländern im Einsatz und nehmen eine weltweite Stellung bei Systemen für Luftfahrtinformationsmanagement und Nachrichtenverarbeitung ein
  • Auf der Karriereseite von Frequentis AG tauchen im Zusammenhang mit Flugsicherungssystemen Ada, C++, Java und Python auf, wobei Java am häufigsten erscheint

Softwarefehler und Testprobleme

  • FPRSA-R konnte aus einem von IFPS akzeptierten gültigen Flugplan nicht den ICAO-Abschnitt extrahieren, der dem britischen Luftraum entsprach
  • Wegpunktkennungen sind global nicht eindeutig, und das ist ein bekanntes Problem
    • Wenn doppelte Wegpunkte sehr weit voneinander entfernt liegen, können normale Flugpläne trotzdem eindeutig sein
    • Die Software hätte diese Bedingung jedoch robust behandeln müssen
  • NATS erklärte, man könne über die britische Regierung prüfen, ob die kleine Zahl doppelter Wegpunktnamen, die in diesem Vorfall aus einer von ICAO verwalteten globalen Datenbasis relevant waren, entfernt werden sollte
  • NATS-CEO Martin Rolfe sagte der BBC, die Wahrscheinlichkeit dieses Vorfalls habe bei „1 zu 15 Millionen“ gelegen
    • Er sagte, das System sei 2018 eingeführt worden und habe seither 15 Millionen Flugpläne verarbeitet
  • Bei einem sicherheitskritischen System sollten die Schritte der Flugplanverarbeitung, insbesondere wichtige Schritte wie die Extraktion des britischen Abschnitts, getestet werden
    • Tests, die doppelte Wegpunktnamen nicht berücksichtigen, hätten diesen Bug möglicherweise nicht aufgedeckt
    • Fuzzing mit großen Mengen zufälliger Flugpläne hätte helfen können, Eingaben zu finden, die das System in einen schlechten Fehlermodus versetzen

Das Problem des Fehlermodus

  • Ein einzelner Flugplan stoppte das gesamte automatische Verarbeitungssystem von FPRSA-R, sodass kein Flugplan mehr automatisch verarbeitet werden konnte
  • Ein besserer Fehlermodus wäre, den einzelnen problematischen Flugplan in eine separate langsamere Queue zu verschieben, damit ihn ein Mensch manuell bearbeiten kann
  • NATS erklärte, man habe bereits Maßnahmen umgesetzt oder in Arbeit, darunter das Hinzufügen spezieller Nachrichtenfilter im Datenfluss zwischen IFPS und FPRSA-R, um Flugpläne herauszufiltern, die den Bedingungen dieses Vorfalls entsprechen
  • Als FPRSA-R stoppte, wurde der betroffene Flugplan erst in Low-Level-Softwarelogs identifiziert
    • Wenn ein Verarbeitungsfehler eines bestimmten Flugplans im Flugplanverarbeitungssystem das Gesamtsystem stoppt, wäre es angemessener, das Monitoring-Team sofort mit einer Warnung zu informieren, die diesen Flugplan einschließt
  • NATS erklärte, man habe betriebliche Anweisungen erstellt, mit denen FPRSA-R bei einem erneuten Auftreten derselben Situation schnell wiederhergestellt werden könne, und die technischen Operatoren seien zur Durchführung der neuen Verfahren geschult worden
    • Verstärktes Monitoring und zusätzliches technisches Fachpersonal sollen die Abläufe ebenfalls überwachen

Möglichkeit formaler Verifikation

  • Es gibt keine klaren Hinweise darauf, dass in diesem Schritt oder System formale Verifikation eingesetzt wurde, und der Bericht erwähnt sie auch nicht
  • Formale Verifikation oder Model Checking hätte helfen können, Fehler dieser Art zu reduzieren
  • Allerdings steht die End-to-End-formale Verifikation großer Systeme noch am Anfang, und selbst bei teilweisem Einsatz formaler Verifikation bleibt es möglich, dass fehlerhafter Code in die Produktionsumgebung gelangt
  • Erst der Abschluss der Untersuchung dürfte mehr darüber zeigen, welche Verifikationsmethoden tatsächlich verwendet wurden

Sicherheit und öffentlicher Bericht

  • Die Flugzeuge über dem Vereinigten Königreich blieben während des gesamten Vorfalls sicher
    • Erfahrene Fluglotsen überwachten die Flugzeuge anhand bekannter Flugpläne, Funk, Radar und Sicht
    • Das Ergebnis war kein Risiko für Menschenleben, sondern dass deutlich weniger Flüge starten konnten oder den britischen Luftraum umfliegen mussten
  • NATS ergriff Maßnahmen zur Verringerung der Flugzahlen, um die Sicherheit zu gewährleisten
  • Der veröffentlichte Bericht ist bemerkenswert transparent und detailliert; für kritische Infrastruktur sind solche Berichte wichtig
  • Ryanairs Michael O’Leary kritisierte den Bericht als „rubbish“ und sagte, er spiele die Auswirkungen auf die Luftfahrtindustrie herunter, allerdings wurde auch angemerkt, dass der Umfang des ersten Berichts nicht darin bestand, das Ausmaß des NATS-Versagens zu analysieren

Richtung für eine robustere Implementierung

  • Das Problem besteht im Umgang mit zwei Sequenzen von Wegpunkten
    • ADEXP: die vollständige Wegpunktliste
    • ICAO: eine Teilfolge der ADEXP-Wegpunkte
  • Da der ICAO-Plan Ein- und Austrittspunkte des Luftraums nicht zwingend enthalten muss, ist die Aufgabe, den kleinsten zusammenhängenden ICAO-Abschnitt zu finden, der dem britischen Luftraum entspricht, nicht trivial
  • Das Problem des fehlerhaften Algorithmus bestand darin, Pointer zu manipulieren, die gleichzeitig auf ICAO- und ADEXP-Daten zeigen, während unklare Invarianten außerhalb des Codes blieben
  • Der vorgeschlagene Ansatz besteht darin, zuerst ICAO- und ADEXP-Daten in einer gemeinsamen Flugplanstruktur Combined abzugleichen und danach den britischen Abschnitt zu extrahieren
    • Dabei werden alle möglichen Reconciliations berechnet, um mehrdeutige Fälle zu erkennen
    • Wenn es 0 Reconciliations gibt, lassen sich ICAO und ADEXP nicht abgleichen
    • Wenn es mehrere gibt, ist der Fall mehrdeutig und kann für manuelle Bearbeitung vorgesehen werden
  • Die Haskell-Beispielimplementierung behandelt die Fehler NonUkPlan, CannotReconcileIcaoAdexp und AmbiguousReconciliationsOfIcaoAdexp explizit
  • Im Beispiel liefert das System auch dann den korrekten britischen Abschnitt zurück, wenn in der ADEXP-Liste die doppelte Kennung Q vorkommt, solange sich ICAO- und ADEXP-Daten nicht mehrdeutig abgleichen lassen
  • Der vollständige Code ist unter uk-portion-of-ICAO verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-12
Hacker-News-Kommentare

  • Im Grunde wurde bei der Flugplan-Abfrage eine geografisch getrennte Bereichsbegrenzung vergessen. Ich kannte diesen Bug schon, als ich früher ein Flugnavigationssystem gebaut habe, habe ihn auch tatsächlich gesehen und mich an eine Spezifikation gehalten, die Geofences vorsah, um genau diesen Bug zu vermeiden

    • Wenn Namen von Navigationspunkten nicht global eindeutig sind und Strecken zwischen Regionen üblich sind, verstehe ich nicht, warum man solchen Navigationspunkten keine GUIDs gegeben hat
    • Ich wäre neugierig, in welcher Sprache das entwickelt wurde
    • Der ICAO-Standard legt seit 1978 fest, dass Identifikatoren, wenn sie doppelt vergeben werden, mindestens 600 Seemeilen (690 Meilen, 1.100 km) voneinander entfernt sein müssen

  • Die Stelle „das Backup-System wendete dieselbe Logik auf den Flugplan an und kam zum selben Ergebnis“ ist das Problem. In Software sollte ein Backup-System eine andere Logik verwenden
    Als ich früher bei Boeing am Stabilizer-Trim-System der 757 gearbeitet habe, waren zwei Avionik-Computer an die Verkabelung angeschlossen, die den Trim betätigte, und sie waren über einen Komparator verbunden. Wenn die beiden Boxen nicht übereinstimmten, verloren beide ihre Autorität
    Die beiden Boxen wurden mit unterschiedlichen Algorithmen, unterschiedlichen Programmiersprachen, unterschiedlichen CPUs und von durch Firewalls getrennten Teams entwickelt; die Absicht war, dass ein Bug auf einer Seite die andere nicht auf dieselbe Weise kaputtmacht

    • Das dürfte ein 2oo2-System gewesen sein, bei dem der Pilot das Backup ist; 2oo2 hat aber keine hohe Verfügbarkeit
      Ein Flugverkehrskontrollsystem sollte mindestens 2oo3[1] sein, also eine Struktur, in der immer 2 von 3 unabhängig entwickelten Systemen übereinstimmen müssen. Dann können, selbst wenn ein System ausfällt, die anderen beiden weiterlaufen, ohne die Verfügbarkeit der Luftfahrtbranche zu beeinträchtigen
      Menschen als Backup vorzusehen, ist wegen Personalbedarf und Komplexität unmöglich. Ein Flugverkehrskontrollsystem muss unter IFR-[2] und CVFR-[3]-Bedingungen Staffelungskontrolle leisten können
      [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...
    • Beim Lesen war das auch mein erster Gedanke. Dieses Failover-System scheint eher dafür entworfen worden zu sein, Hardwareausfälle abzufedern, nicht Software-Bugs
    • „Wenn ein Sicherheitssystem versagt, versagt es auf eine Weise, die nicht sicher ausfällt“
      J. Gall
    • Unterschiedliche Teams machen auch oft denselben Fehler. Das ist keine perfekte Architektur, aber der beschriebene Ansatz wirkt plausibel
    • Nebenbei: Schade, dass man bei der MAX diesen Ansatz kannte und ihn trotzdem nicht wiederverwendet hat

  • Ich erinnere mich, dass es bei NATS noch ein anderes Problem mit demselben Effekt gab. Das Primärsystem fiel um, man schaltete auf das Sekundärsystem um, und das fiel aus exakt demselben Grund ebenfalls um
    Failover sollte man wohl nur dann machen, wenn man weiß, dass das Problem im Primärsystem selbst liegt und nicht in der Software als solcher. Einfach umzuschalten verstärkt nur den Eindruck, dass nicht genug Informationen offengelegt wurden, um beurteilen zu können, was eigentlich zu tun ist
    Der unangenehmere Teil ist, dass es offenbar keine Methode wie „ValidateFlightPlan“ gab, sodass bei allem, was sich aus irgendeinem Grund nicht parsen ließ, ein Fehler geworfen wurde, und es keinen sehr einfachen Pfad gab, diesen Fehler zu behandeln. Ich frage mich, welcher Programmierer sich bei einem Handler für externe Eingaben nicht denkt: „Was machen wir, wenn kaputte, schlechte Eingaben kommen?“

    • Wenn bekannt ist, dass das Primärsystem nicht in einem normalen Zustand ist, kann man umschalten und hoffen, dass es ein Problem wie eine durchgebrannte Festplatte oder ein durch kosmische Strahlung gekipptes Bit war
      Die eigentliche Sicherheitsfunktion ist der Vier-Stunden-Puffer, bevor manuelle Bearbeitung nötig wird
      In der Luftfahrt geht es bei zentralen Sicherheitskontrollen weniger um „wie verhindern wir, dass das überhaupt kaputtgeht“, sondern eher um „was tun wir, wenn es aus irgendeinem Grund kaputtgeht“
    • Neben dem fehlenden Validierungsschritt ist mir diese Passage im Text aufgefallen
      Der Programmierstil wirkt sehr imperativ, und der Beschreibung nach klingt es, als ob die Prozedur direkt mit der Textdarstellung des Flugplans arbeitet, statt mit einer aus einer Textdatei geparsten Datenstruktur. Falls das tatsächlich so ist, wäre das ziemlich beunruhigend, es kann aber auch an der Art der Beschreibung liegen
      Nach dieser Beschreibung würde es mich nicht überraschen, wenn einfach reguläre Ausdrücke oder Teilstring-Matching über Text laufen, ohne Klassen, Objekte oder Datenstrukturen. Man muss auch die Möglichkeit in Betracht ziehen, dass es sich um jahrzehntealten C-Code handelt, von dem die gesamte britische Luftfahrt abhängt und den man nicht neu schreiben oder ersetzen kann
    • Da man nicht feststellen kann, dass Hardware nicht die Ursache war, war das Failover an sich richtig. Allerdings hätte die Reaktion auf den zweiten Ausfall besser gestaltet werden müssen, um Ketteneffekte zu vermeiden
    • Elektrisch gesehen hat man die Sicherung ersetzt und dann zugesehen, wie sie wieder durchbrennt. Im Laden gibt es keine Sicherungen mehr. Ist das Fortschritt?
    • Der Fehlschlag des Ariane-5-Starts[1] war ein ähnliches Problem, nur war das Ergebnis deutlich spektakulärer
      Das Primärsystem fiel wegen eines Integer-Overflows aus, und das identische Sekundärsystem lief ebenfalls in denselben Overflow. Der Anstellwinkel stieg, die Booster trennten sich, und die Rakete explodierte
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • Ich verstehe nicht, warum nur der fehlgeschlagene Flugplan in eine Warteschlange zur menschlichen Prüfung gestellt wurde und die übrigen Flüge nicht weiterverarbeitet werden konnten. Dass es diese „Funktion“ nicht gab, ist für mich am schwersten nachzuvollziehen.

    • Der Code hat diesen Fehler als „Das darf niemals passieren!“ klassifiziert, und genau das ist dann passiert. Er hat ihn nicht als „Flugplandaten sind fehlerhaft“ oder „Daten sind korrekt, werden aber noch nicht unterstützt“ eingeordnet.
      Wenn ein „Das darf niemals passieren“-Fehler auftritt, weiß das System nicht, was falsch ist und wie groß bzw. weitreichend die Auswirkungen sind. Vielleicht hätte man wie in diesem Fall weitermachen können, aber es könnte auch sein, dass in der Software ein neuer kritischer Bug steckt, der stillschweigend alle anderen Flugpläne kontaminiert und Menschen tötet. Wenn man nicht weiß, ob Weitermachen sicher ist, muss man anhalten.
    • Fairerweise steht am Anfang des Artikels, dass diese Flugpläne teils auch für Flugzeuge verarbeitet werden, die bereits in der Luft sind. Auch wenn sie mindestens vier Stunden von Großbritannien entfernt sind.
      Wenn man verhindern kann, dass das konkrete problematische Flugzeug abhebt, kann es in Ordnung sein, das System weiterlaufen zu lassen; wenn es aber schon in der Luft ist, ist die Lage anders.
      Die Einschätzung „Ein Flugzeug, das in den britischen Luftraum einfliegen wird, ist unterwegs, aber wir wissen nicht, wann und wo es einfliegt. Wir stoppen weitere Flugpläne, bis wir die Position dieses Flugzeugs kennen“ ist nicht völlig unvernünftig.
      Wenn der Flugplan wirklich nicht verarbeitet werden kann, könnte eine sinnvolle Lösung darin bestehen, das betreffende Flugzeug umzuleiten und landen zu lassen, bevor es Großbritannien erreicht; aber so etwas muss letztlich auf manuelles Eingreifen warten.
    • Sowohl der Artikel als auch die nachträgliche Analyse sehen den schlechten Fehlermodus des FPRSA-R-Systems als Hauptproblem, und ich halte das für den wichtigsten Punkt.
      Jedes System kann versagen; entscheidend ist, dass es auf eine gute Weise versagt und die Verantwortlichen auf diese Situation vorbereitet sind.
      Ein einzelner Flugplan verursachte ein Problem, und das gesamte FPRSA-R-System fiel aus, sodass überhaupt keine Flugpläne mehr verarbeitet wurden. Wenn ein Flugplan ein Problem hat, sollte er in eine separate, langsamere Warteschlange zur manuellen Bearbeitung verschoben werden. Auch NATS räumt unter den „bereits umgesetzten oder laufenden Maßnahmen“ ein, dass ein Nachrichtenfilter im Datenfluss zwischen IFPS und FPRSA-R hinzugefügt wird, der Flugpläne mit dieser Bedingung herausfiltert.
    • Wenn man in einem sicherheitskritischen System auf einen „unbekannten Fehler“ trifft, muss man davon ausgehen, dass alle Invarianten verletzt sind und man sich in undefiniertem Verhalten befindet; daher bleibt nur das Anhalten.
      Dass dies als bekannter Fehler hätte behandelt werden müssen, ist ein berechtigter Punkt, aber im weiteren Sinne ähnelt es der Aussage, man hätte fehlerfreien Code schreiben müssen. Selbst wenn es in eine Struktur geparst wurde, könnte es so sein, als würde in Code, der annimmt, dass ein optionaler Schlüssel vorhanden ist, plötzlich ein KeyError auftauchen.
      Die nachträgliche Analyse und Verbesserung solcher Vorfälle muss von der Annahme ausgehen, dass irgendwann ein unvorhersehbarer, unbehandelter unbekannter Fehler auftritt, und sich damit befassen, wie man dann besser damit umgeht. Die Lösung für einen Bug ist, den Bug zu beheben, aber die Ursache des Großausfalls war ein Disaster-Recovery-Plan, der sich nicht in angemessener Zeit ausführen ließ. Welche Programmierpraktiken, Stile, Sprachen oder Tools man auch verwendet: Ein Vorfall ähnlicher Größenordnung wird selbst den besten Entwicklern irgendwann mit Wahrscheinlichkeit 1 wieder passieren.
    • Der im Artikel beschriebene Algorithmus ist wahrscheinlich kein einfacher prozeduraler Code, der der Reihe nach die Wegpunkte des eingegebenen Flugplans abläuft. Eine Abstraktion könnte verschleiert haben, dass es sich um einen Eingabefehler handelt.
      Wenn es aus Sicht des Codes wie ein Integritätsfehler der zugrunde liegenden Navigations-Wegpunktdatenbank aussah, ist die Entscheidung, die Flugplanverarbeitung zu stoppen, deutlich nachvollziehbarer.
      Wenn der Code zum Beispiel den Speicher für Wegpunkte und Flugrouten fragt: „Finde mir den Wegpunkt, an dem diese Route den britischen Luftraum verlässt“, anschließend das Routensegment findet, das diesen Wegpunkt enthält, und dann behauptet, dass dieses Segment durch den britischen Luftraum führt, diese Behauptung aber fehlschlägt, wirkt das nicht wie ein Problem des Flugplans, sondern wie eine gebrochene Annahme, die in den Routendaten steckt.
      In gewisser Weise könnte es tatsächlich ein kritischer Bug sein. Der Vorfall zeigt, dass die Annahmen, die der Algorithmus über die Daten getroffen hat, falsch waren und er potenziell falsche Antworten zurückgeben kann.

  • Verwandte Beiträge
    Britisches Flugsicherungssystem durch zufällig gleiche Wegpunktnamen getäuscht - https://news.ycombinator.com/item?id=37430384 - September 2023, 64 Kommentare
    Schlechte Flugplandaten verursachten Ausfall der britischen Flugsicherung - https://news.ycombinator.com/item?id=37402766 - September 2023, 20 Kommentare
    NATS-Unfallbericht zur Flugsicherung erläutert Grundursache und Lösungen im Detail - https://news.ycombinator.com/item?id=37401864 - September 2023, 19 Kommentare
    Ausfall des britischen Flugsicherungsnetzes - https://news.ycombinator.com/item?id=37292406 - August 2023, 23 Kommentare

    • Nachdem ich die aktuelle Folge von The Daily zur US-Luftfahrtbranche gehört habe, bin ich überzeugt, dass wir in nicht allzu ferner Zukunft katastrophale Schlagzeilen sehen werden. So kann es nicht weitergehen.
    • Als ich den Titel dieses Artikels sah, dachte ich, es handle sich um einen gerade neu aufgetretenen Ausfall.

  • Die Tatsache, dass sie einen von Eurocontrol bereits akzeptierten französischen Flugplan verantwortlich machten, ist ein Beleg dafür, dass sie nicht wirklich verstanden, wie ihre Software funktioniert. Und auch das österreichische Unternehmen muss einen Teil der Verantwortung für den Mangel an intensiven Tests tragen.

    • Sie haben Frankreich nur deshalb die Schuld gegeben, weil es Großbritannien ist. Schlechte Gewohnheiten wird man nur schwer los.

  • Hervorragender Artikel. Wenn man ihn liest, ist die Kernaussage meiner Ansicht nach diese:
    Die weltweit verwendeten Wegpunktnamen sind nicht eindeutig, und als eine Art Notlösung zur Vermeidung von Verwechslungen verlangt der aktuelle Standard, identische Kennungen geografisch ausreichend weit voneinander zu trennen. Trotzdem kann derselbe Wegpunktname innerhalb einer Route unterschiedliche Orte bezeichnen.
    Die Software berücksichtigte diese Möglichkeit nicht, die Routenberechnung schlug fehl, sie warf eine „fatale Ausnahme“ und ging in den „Wartungsmodus“. Mit anderen Worten: Sie war tot.
    Das Backup-System übernahm, lief aber mit denselben Daten in denselben Bug und starb ebenfalls; das Support-Team hatte seine liebe Mühe. Letztlich fand man erst nach Kontaktaufnahme mit dem Softwareanbieter Low-Level-Logs, die die Ursache offenlegten.

    • Ich kann nicht verstehen, warum bei einem missionskritischen System dieses Niveaus nicht rund um die Uhr jemand in Rufbereitschaft ist, der mit dem Code vertraut ist.
    • Der Kernpunkt war das Fehlen eines geeigneten Namensraums. Wer hätte gedacht, dass Luft- und Raumfahrtingenieure Betriebssysteme studieren müssen.
      Ein befreundeter pensionierter Luftwaffenpilot hat an der Cranfield University graduiert; das ist eine führende britische Postgraduierten-Einrichtung für Luft- und Raumfahrttechnik und verfügt sogar über einen eigenen Flughafen für Lehre und Forschung[1]. Er sagte, er habe in Cranfield Betriebssysteme gelernt — jetzt verstehe ich, warum.
      Anderen Kommentaren zufolge gibt es bereits einen Namensraum-Standard, aber NATS/ATC scheinen ihn nicht zu verwenden. Hoffentlich fangen sie nach diesem Vorfall endlich damit an. Der Top-Kommentar sprach von einem Geofencing-Bug, aber wenn NATS/ATC den richtigen Namensraum verwendet hätten, wäre Geofencing sehr wahrscheinlich von vornherein nicht nötig gewesen.
      [1] Cranfield University:
      https://en.wikipedia.org/wiki/Cranfield_University

  • „Nach der Beschreibung klingt es so, als würde die Prozedur nicht mit einer aus einer Textdatei geparsten Datenstruktur arbeiten, sondern direkt mit der Textrepräsentation des Flugplans. Falls das tatsächlich so ist, wäre das ziemlich beunruhigend; es könnte aber auch nur an der Art der Beschreibung liegen.“
    In der Luftfahrtbranche ist diese Arbeitsweise üblich. Wenn man Programmierer nach Domänenmodellen oder Parsing fragt, erntet man oft nur leere Blicke. Sie mögen Validierungscode, und wenn etwas nicht validiert, geben sie einfach auf. Es sind alles dumme Datenpipelines, ohne jeglichen Code, der Aktivitäten in der realen Welt modelliert.
    In keinem System gibt es so etwas wie einen „Flugplan“-Typ mit Verhalten oder eine Menge von Wegpunkt-Typen. Selbst wenn es Typen gibt, sind es aus C-Sicht String-Structs, und jedes Mal, wenn auf ein Member dieser Structs zugegriffen wird, wird erneut geparst — nicht einmalig, sondern jedes einzelne Mal. Wie im Artikel steht: „Der Programmierstil wirkt sehr imperativ“ trifft es.

    • Bei fehlgeschlagener Validierung aufzugeben ist allerdings ein Standardansatz, um zu verhindern, dass falsch interpretierte Daten weiterverbreitet werden und wesentlich komplexere Bugs verursachen. Früh validieren, strikt validieren, Fehler melden und nicht versuchen, zwanghaft zu interpretieren, was an der Eingabe seltsam ist. Sobald man versucht, „clever“ zu sein, entsteht eine Sicherheitslücke.
      Bei fehlerhafter Eingabe zu sterben ist schlecht, aber unvalidierte Daten ohne Spezifikation interpretieren zu wollen, führt später leicht zu Verständnisunterschieden, Kompatibilitätsproblemen und unerwarteten Randbedingungen. Für ein vollständig getestetes System, das alle Fälle abdeckt, Tools zur Simulation fehlerhafter Eingaben sowie formale Verifikation des Parsers und des gesamten Codes, der die Parser-Ergebnisse verwendet, will niemand bezahlen.
      Schon heute gibt es genug Probleme durch nicht konforme, Legacy- und fehlerhafte Datensender sowie durch die Komplexität von Schnittstellensemantik und Timing. Wenn man versucht, auf Daten mit falschem Format oder falscher Codierung clever zu reagieren, wird es noch gefährlicher.
      Schon ein System zu bauen, das gemäß Spezifikation funktioniert, ist schwierig und teuer. Subtile Varianten, die unspezifiziertes Verhalten großzügiger akzeptieren, sind entweder eine Einladung zu Bugs oder führen zu einem teureren System, das die Kaufpreisvorgaben nicht erfüllt.
    • Sehr interessant und auch ein wenig beängstigend. Faszinierend ist, dass unterschiedliche Branchen aus nicht wirklich klaren Gründen jeweils ihre eigene Entwicklungskultur hervorgebracht haben.

  • „Britische Flugsicherung: Untersuchung, ob ein französischer Fehler die Störung ausgelöst hat“
    Natürlich nicht. Es ist ein britisches System — wie kann das die Schuld einer französischen Fluggesellschaft sein? Solche Systeme sollten eine redundante fehlertolerante Architektur haben.
    Es hätte womöglich schon gereicht, einen schlechten Eintrag abzulehnen und weiterzumachen.

    • Wenn man unbedingt nationalistisch argumentieren will: Die Software stammte aus Österreich.

  • Das war ein Tag, an den ich mich nicht erinnern möchte. Für ein Ziel, das normalerweise in 2 Stunden erreichbar ist, brauchte ich 15 Stunden.
    Ich nahm den Zug, den Bus und dann wieder den Zug; 30 Minuten nachdem ich das Ticket gebucht hatte, waren alle Verbindungen für zwei Tage ausverkauft.

    • Ich wartete 6 Stunden am Flughafen, bevor ich erfuhr, dass der Flug gestrichen war, und musste dann neu buchen. Ich war auf dem Weg nach New York, um meine Familie zu besuchen, daher gab es auch kaum alternative Verkehrsmittel.