LONDON - Ein Dominoeffekt im Flugplansystem hat letzte Woche für erhebliche Störungen im britischen Luftverkehr gesorgt. Ryanair wirft der Flugsicherung NATS neben schweren Versäumnissen eine "inhaltlich unrichtige" und "beschönigende" Darstellung der Ereignisse vor - und fordert Schadensersatz.
Ein Systemfehler bei der britischen Flugsicherung NATS hat den britischen Luftverkehr am 28. August ins Chaos gestürzt. Die Lotsen mussten den Verkehr nach einem Ausfall des Flugplansystems - mutmaßlich verursacht durch einen einzigen falsch übermittelten Flugplan - herunterregeln.
Auch am Folgetag kam es noch zu Ausfällen und Verspätungen. Jetzt beginnt die Aufarbeitung. Und mit der ist Ryanair alles andere als zufrieden. "Der vorläufige NATS-Bericht ist inhaltlich unrichtig", machte Airlinechef Michael O'Leary seinem Ärger Luft.
So gehe NATS von 1.500 Flugausfällen am 28. August aus, "während Eurocontrol an diesem Tag über 2.000 Flüge weniger über Großbritannien registrierte". Weitere 575 Flüge starteten laut NATS mit Verspätung. "Das ist Unsinn", sagte O'Leary. Allein Ryanair habe mehr als 1.000 verspätete Abflüge verzeichnet.
"Dieser beschönigende Bericht, in dem die Zahl der Flugausfälle und -verspätungen heruntergespielt wird, erklärt nicht, warum ein einziger ungenauer Flugplan nicht nur das Flugsicherungssystem von NATS, sondern das Backup-System gleich mit zum Erliegen gebracht hat", sagte O'Leary.
Zudem sei schwer nachvollziehbar, warum über das Backup-System generell nur Flugpläne der letzten vier Stunden wiederhergestellt werden können.
Ryanair will von der Flugsicherung mindestens Hotelkosten für die Unterbringung betroffener Passagiere erstattet haben. "Das geht allein auf die Kappe von NATS".
© aero.de | Abb.: NATS | 06.09.2023 14:29
Um einen Kommentar schreiben zu können, müssen Sie sich bei aero.de
registrieren oder
einloggen.
Beitrag vom 08.09.2023 - 10:31 Uhr
@cotodoso,
bei der Datenverarbeitung werden immer Fehler gemacht. Wenn man das nicht akzeptieren kann, dann macht man sich höchstens bei den egozentischen Vorgesetzten beliebt. Entscheidend ist, dass man aus den eigenen und den bekannten Fehlern der Kollegen lernt und diese nicht wiederholt. Ich unterstelle dabei natürlich ein vernünftiges Arbeiten. Man muss zu seiner Verantwortung auch stehen können. Das bedeutet aber auch, dass man Fehler nicht unter den Teppich kehrt!
Zur Erinnerung: Flugpläne können auch in der Luft aufgegeben werden. Das sollte zwar nicht passsieren, ist aber besser als wenn z. B. ein VFR-Flug unter IFR-Bedingungen fortgeführt wird/werden muss.
Was passiert bei kurzfristigen Luftraumsperrungen? Dann sind bestimmte Navigationspunkte nicht anfliegbar.
Ohne weitere Kenntnis der Zusammenhänge lässt sich z. Z. nur sagen, dass ein Programmfehler vorlag.
Der Fehler lag nicht in den Daten.
Beitrag vom 08.09.2023 - 09:00 Uhr
Es ist egal, ob es dafür eine manuelle Eingabemöglichkeit gegeben hatte. Im fraglichen Moment war das Problem nicht ge-"root caused". Wahrscheinlich hätte es die möglichkeit des manuellen Eingriffs gegeben? Was hätte man eingeben wollen? Mit welcher Gegründung? Ich denke, das das die Gedanken des oder der Verantwortlichen waren und wahrscheinlich haben die Regeln des Betriebs ihrer oder seiner Umgebung, sie oder ihn eh dazu gezwungen, auf den manuellen Notbetrieb umzusteigen.
Zunächst einmal mag ich in diesem Zusammenhang den Begriff abgestürzt nicht, da das etwas unkontrolliertes implizieren würde. Die Verarbeitung wurde ja gerade eben kontrolliert beendet, um einen unkontrollierten Zustand zu kommen.
Und selbstverständlich muss das auch passieren, wenn man genau die gleichen Daten durch das Backupsystem laufen lässt und das Datenelement, das zur Beendigung der Verarbeitung führt, im Datenstrom lässt. Alles andere als genau die gleiche Reaktion wäre im Lichte der heutigen Informationslage ein deutlich beunruhigenderes Problem gewesen.
An einen manuellen Eingriff in ein automatisiertes System müssen zudem die gleichen Ansprüche gestellt werden, wie an eine automatische Korrektur des Fehlers. Er muss "demonstrably safe" sein. Man muss also vor der Korrektur das Problem verstanden haben, um eine Massnahme einleiten zu könnnen, denn ohne Problemverständnis ist ein manueller Eingriff im Fehlerfalle niemals "demonstrably safe". Nichts ohne Verständnis der Situation ist "demonstrably safe"
Wahrscheinlich sah der Flugplan auf dem ersten Blick gut aus, so das selbst wenn sich das jemand schnell angeguckt hat, erstmal völlig unklar war, warum das System in die Exception gelaufen ist. In einer solchen Situation macht man keinen Override,bis man das Problem völlig verstanden hat. Man arbeitet in solchen Situationen unter Zeitdruck.
Wahrscheinlich ist erst aufgefallen was da eigentlich los ist, als man nachdem erst mal mit der manuellen Notprozedur die Flugzeuge wieder fliegen konnte, sich jemand hingesetzt hat, und in aller Ruhe sich mal den Flugplan angeguckt hat, gesehen hat, das er eigentlich auf Basis der Waypoint Codes ganz gut aussehende Flugplan wegen der Duplikation der Codes völliger Quark war, dann die Entwickler gefragt hat, wie das System eigentlich darauf reagiert, die erst mal in ihre Dokumentation und ggf. in den Source Code geguckt haben, und dann vielleicht schon kurze Zeit später mit einer Antwort gekommen ist. Was genau da passiert ist, weiss ich nicht. Ich war nicht dabei. Aber in meiner Erfahrung, ist es in der Regel so.
Alles andere andere wäre von der Verantwortungslosigkeit vergleichbar, irgendwo ein kaputtes Gerät im Haushalt zu haben, weswegen die Sicherung laufend fliegt und weil nicht gleich offensichtlich bei irgendeinem Gerät ein Problem sichtbar ist, die Schmelzsicherung mit einem Zimmermannsnagel zu überbrücken.
In diesem Fall hat man das richtige gemacht: Nachdem die erste Sicherung geflogen ist (primärsystem) , hat man noch Neue neue reingedrückt (backupsystem), und nachdem die auch geflogen ist, die Batterien rausgeholt und den Gaskocher rausgeholt und auf den Elektriker gewartet, der dann letztlich festgestellt hat, das sich aus einer Lüsterklemme ein Kabel gelöst hat und über den den dafür vorgesehenen Prozess (Stromabfluss über Erde) die Sicherung geworfen hat. Danach sagt man sich immer "Verdammt, das hätte ich auch selbst sehen können, wenn ich überall die Plastiktöpfe über den Lüsterklemmen runtergezogen hätte. Nu hat mich der Elektriker 150 Euro gekostet" aber für alles praktische Belange hätte es auch etwas deutlich Problematischeres sein können. Das weiss man aber in dem Moment nicht. Hindsight ist halt 20/20.
Ich denke auch, das die die ICAO schon mehrfach gedacht hat "Verdammt, fünfstellige Waypoint Codes war nicht so eine clevere Idee", aber gleichzeitig auch mit berücksichtigt, das die Änderung von 5 auf 6 stellige Waypoints auf all den Systemen der Welt, die sie verwenden, in all den Köpfen der Welt, die mit ihnen arbeiten, wahrscheinlich mehr probleme erzeugen wird, als die gelegentlich Mishaps, die man jetzt hat. Und es dann so lässt, wie es ist und versucht so viele Failure Modes wie möglich abzufangen.
Ich erinnere mich an den Kraftakt, der dvor 25 Jahren nötig war, um flächendeckend in IT systemen Datumsfelder von 2 auf 4 Zahlen fürs Jahr hochzuziehen. Und IPv6 wurde im letzten Jahrtausend standardisiert und würde viele Probleme lösen. Und was soll ich sagen: Immer noch sind IPv4-Addressen eine begehrte Resource.
Ich bin ITler, nicht mal in der Luftfahrt. Ich interessere mich dennoch für die Luftfahrt, weil man einiges daraus lernen kann. Wenn ich eines aus der Luftfahrt abgeguckt habe, dann ist es die blameless culture. Also, das man Fehler untersucht, nicht um auf einen Verantwortlich zu zeigen und diesen zur Verantwortung und Haftung zu ziehen, sondern um die Probleme zu finden. Von daher finde ich die Reaktion des Ryanair-Chefs zwar "in character", aber nicht hilfreich, nachdem NATS da offen dargelegt hat, was eigentlich passiert ist. Man kann davon ausgehen, das da eine Menge Systemverantwortliche nach der Offenlegung erst mal ihre Leute gefragt haben, was eigentlich passiert, wenn bei ihnen der Flugplan eingespielt worden wäre und das in ihre Testharness aufgenommen haben. Und so haben wir alle was davon, auch wenn es jetzt da grosse Probleme gegeben hat. Wahrscheinlich werden sich auch viele Systemverantwortliche gedanken machen, wie sie ihre Systeme gegenüber noch unbekannten Fehlern resilienter machen können, ohne den Pfad des "demonstrably safe" zu verlassen.
Es sei mir am Ende eine etwas längere Anmerkung erlaubt: Wenn wir wollen, das es als Gesellschaft vorangeht, täten wir gut daran, uns auch als Gesellschaft eine blameless culture anzugewöhnen. Wenn nach einem Problem, die Fehlersuche alleine dazu dient, Verantwortung abzuwälzen, haftungsansprüche aufzubauen, die eigene Karriere zu befördern, oder einfach nur dem "self-aggrandizement", wird niemand mehr offen über Fehler und Probleme sprechen. Und wir lernen nichts. Und entwickeln uns nicht weiter. Wir haben immer nur neue Leute, die neue Fehler machen, weil sie nichts gelernt haben (Es gibt in meiner Branche das Bonmot Fragender: "Warum haben sie den Typen nicht gefeuert, als er Mist gebaut hat, der die Firma 400.000 Euro gekostet hat?" Chef: "Wieso? Ich habe gerade 400.000 Euro in die Ausbildung Person investiert ... ")
Ich habe die Erfahrung gemacht, das wenn ich den Leuten sage "In meinen post-mortem Reports von Eskalationen steht nicht nur drin "sie haben patch 0815 nicht eingespielt, deswegen crashte das system. Ihre Schuld", sondern auch "warum wurde der patch nicht eingespielt? ist die betriebsorganisation dazu passend? hatten sie eine chance zu erkennen, das das wichtig ist? Konnte man das wissen? trägt man als hersteller vielleicht auch eine verantwortung, weil eine notwendige information zwar dokumentiert, aber missverständlich dokumentiert war" " dann reden die Leute offener mit einem, und kann jedes Problem in einen "teachable moment" verwandeln. Das macht die Arbeit dazu zwar aufwändiger, aber meistens passiert danach der Fehler nie ein zweites mal. Und das spart mir auf Dauer viel Arbeit und Ärger und allen Leuten Geld.
Deswegen führt auch die Unart einiger Mitforisten, nachdem hier von irgendeinem Mishap anderer Piloten berichtet wird, jedes mal sinngemäss mit "war doch klar, ich hätte das besser gewusst. jeder hätte das besser gewusst" eher zu Unverständnis ob des kulturellen Verständnis des entsprechenden Mitforisten.
Das Gute ist, und man verzeihe mir den Zynismus: Im Gefüge des Grossen und Ganzen der Welt ist dieses Forum zwar interessant und ein netter Zeitvertreib, aber völlig und ganz und gar bedeutungslos. Vielleicht auch etwas was man im Hinterkopf halten sollte, wenn man sich hier wieder mal wie die Kesselflicker streitet ? Und das gilt wahrscheinlich für jedes Forum da draussen ;)
Dieser Beitrag wurde am 08.09.2023 09:04 Uhr bearbeitet.
Beitrag vom 07.09.2023 - 21:13 Uhr
Muss dafür das ganze System gestoppt werden?
Das hat sich selbst angehalten, nachdem es nach dem ersten Absturz auf den Backup umgeschaltet hat und der ebenfalls abstürzte, war halt schicht im Schacht.
Gab es keine manuelle Eingabemöglichkeit?
Aus Sicherheitsgründen vermutlich nein.
Ausserdem muss man den Fehler ja erst einmal verstehen und analysieren - also das tun, was jetzt in den letzten 2 Wochen zu diesem Report geführt hat.
Das macht keine(r) mal eben so im vorbeigehen.
Kommentare (7) Zur Startseite
Um einen Kommentar schreiben zu können, müssen Sie sich bei aero.de registrieren oder einloggen.
bei der Datenverarbeitung werden immer Fehler gemacht. Wenn man das nicht akzeptieren kann, dann macht man sich höchstens bei den egozentischen Vorgesetzten beliebt. Entscheidend ist, dass man aus den eigenen und den bekannten Fehlern der Kollegen lernt und diese nicht wiederholt. Ich unterstelle dabei natürlich ein vernünftiges Arbeiten. Man muss zu seiner Verantwortung auch stehen können. Das bedeutet aber auch, dass man Fehler nicht unter den Teppich kehrt!
Zur Erinnerung: Flugpläne können auch in der Luft aufgegeben werden. Das sollte zwar nicht passsieren, ist aber besser als wenn z. B. ein VFR-Flug unter IFR-Bedingungen fortgeführt wird/werden muss.
Was passiert bei kurzfristigen Luftraumsperrungen? Dann sind bestimmte Navigationspunkte nicht anfliegbar.
Ohne weitere Kenntnis der Zusammenhänge lässt sich z. Z. nur sagen, dass ein Programmfehler vorlag.
Der Fehler lag nicht in den Daten.
Zunächst einmal mag ich in diesem Zusammenhang den Begriff abgestürzt nicht, da das etwas unkontrolliertes implizieren würde. Die Verarbeitung wurde ja gerade eben kontrolliert beendet, um einen unkontrollierten Zustand zu kommen.
Und selbstverständlich muss das auch passieren, wenn man genau die gleichen Daten durch das Backupsystem laufen lässt und das Datenelement, das zur Beendigung der Verarbeitung führt, im Datenstrom lässt. Alles andere als genau die gleiche Reaktion wäre im Lichte der heutigen Informationslage ein deutlich beunruhigenderes Problem gewesen.
An einen manuellen Eingriff in ein automatisiertes System müssen zudem die gleichen Ansprüche gestellt werden, wie an eine automatische Korrektur des Fehlers. Er muss "demonstrably safe" sein. Man muss also vor der Korrektur das Problem verstanden haben, um eine Massnahme einleiten zu könnnen, denn ohne Problemverständnis ist ein manueller Eingriff im Fehlerfalle niemals "demonstrably safe". Nichts ohne Verständnis der Situation ist "demonstrably safe"
Wahrscheinlich sah der Flugplan auf dem ersten Blick gut aus, so das selbst wenn sich das jemand schnell angeguckt hat, erstmal völlig unklar war, warum das System in die Exception gelaufen ist. In einer solchen Situation macht man keinen Override,bis man das Problem völlig verstanden hat. Man arbeitet in solchen Situationen unter Zeitdruck.
Wahrscheinlich ist erst aufgefallen was da eigentlich los ist, als man nachdem erst mal mit der manuellen Notprozedur die Flugzeuge wieder fliegen konnte, sich jemand hingesetzt hat, und in aller Ruhe sich mal den Flugplan angeguckt hat, gesehen hat, das er eigentlich auf Basis der Waypoint Codes ganz gut aussehende Flugplan wegen der Duplikation der Codes völliger Quark war, dann die Entwickler gefragt hat, wie das System eigentlich darauf reagiert, die erst mal in ihre Dokumentation und ggf. in den Source Code geguckt haben, und dann vielleicht schon kurze Zeit später mit einer Antwort gekommen ist. Was genau da passiert ist, weiss ich nicht. Ich war nicht dabei. Aber in meiner Erfahrung, ist es in der Regel so.
Alles andere andere wäre von der Verantwortungslosigkeit vergleichbar, irgendwo ein kaputtes Gerät im Haushalt zu haben, weswegen die Sicherung laufend fliegt und weil nicht gleich offensichtlich bei irgendeinem Gerät ein Problem sichtbar ist, die Schmelzsicherung mit einem Zimmermannsnagel zu überbrücken.
In diesem Fall hat man das richtige gemacht: Nachdem die erste Sicherung geflogen ist (primärsystem) , hat man noch Neue neue reingedrückt (backupsystem), und nachdem die auch geflogen ist, die Batterien rausgeholt und den Gaskocher rausgeholt und auf den Elektriker gewartet, der dann letztlich festgestellt hat, das sich aus einer Lüsterklemme ein Kabel gelöst hat und über den den dafür vorgesehenen Prozess (Stromabfluss über Erde) die Sicherung geworfen hat. Danach sagt man sich immer "Verdammt, das hätte ich auch selbst sehen können, wenn ich überall die Plastiktöpfe über den Lüsterklemmen runtergezogen hätte. Nu hat mich der Elektriker 150 Euro gekostet" aber für alles praktische Belange hätte es auch etwas deutlich Problematischeres sein können. Das weiss man aber in dem Moment nicht. Hindsight ist halt 20/20.
Ich denke auch, das die die ICAO schon mehrfach gedacht hat "Verdammt, fünfstellige Waypoint Codes war nicht so eine clevere Idee", aber gleichzeitig auch mit berücksichtigt, das die Änderung von 5 auf 6 stellige Waypoints auf all den Systemen der Welt, die sie verwenden, in all den Köpfen der Welt, die mit ihnen arbeiten, wahrscheinlich mehr probleme erzeugen wird, als die gelegentlich Mishaps, die man jetzt hat. Und es dann so lässt, wie es ist und versucht so viele Failure Modes wie möglich abzufangen.
Ich erinnere mich an den Kraftakt, der dvor 25 Jahren nötig war, um flächendeckend in IT systemen Datumsfelder von 2 auf 4 Zahlen fürs Jahr hochzuziehen. Und IPv6 wurde im letzten Jahrtausend standardisiert und würde viele Probleme lösen. Und was soll ich sagen: Immer noch sind IPv4-Addressen eine begehrte Resource.
Ich bin ITler, nicht mal in der Luftfahrt. Ich interessere mich dennoch für die Luftfahrt, weil man einiges daraus lernen kann. Wenn ich eines aus der Luftfahrt abgeguckt habe, dann ist es die blameless culture. Also, das man Fehler untersucht, nicht um auf einen Verantwortlich zu zeigen und diesen zur Verantwortung und Haftung zu ziehen, sondern um die Probleme zu finden. Von daher finde ich die Reaktion des Ryanair-Chefs zwar "in character", aber nicht hilfreich, nachdem NATS da offen dargelegt hat, was eigentlich passiert ist. Man kann davon ausgehen, das da eine Menge Systemverantwortliche nach der Offenlegung erst mal ihre Leute gefragt haben, was eigentlich passiert, wenn bei ihnen der Flugplan eingespielt worden wäre und das in ihre Testharness aufgenommen haben. Und so haben wir alle was davon, auch wenn es jetzt da grosse Probleme gegeben hat. Wahrscheinlich werden sich auch viele Systemverantwortliche gedanken machen, wie sie ihre Systeme gegenüber noch unbekannten Fehlern resilienter machen können, ohne den Pfad des "demonstrably safe" zu verlassen.
Es sei mir am Ende eine etwas längere Anmerkung erlaubt: Wenn wir wollen, das es als Gesellschaft vorangeht, täten wir gut daran, uns auch als Gesellschaft eine blameless culture anzugewöhnen. Wenn nach einem Problem, die Fehlersuche alleine dazu dient, Verantwortung abzuwälzen, haftungsansprüche aufzubauen, die eigene Karriere zu befördern, oder einfach nur dem "self-aggrandizement", wird niemand mehr offen über Fehler und Probleme sprechen. Und wir lernen nichts. Und entwickeln uns nicht weiter. Wir haben immer nur neue Leute, die neue Fehler machen, weil sie nichts gelernt haben (Es gibt in meiner Branche das Bonmot Fragender: "Warum haben sie den Typen nicht gefeuert, als er Mist gebaut hat, der die Firma 400.000 Euro gekostet hat?" Chef: "Wieso? Ich habe gerade 400.000 Euro in die Ausbildung Person investiert ... ")
Ich habe die Erfahrung gemacht, das wenn ich den Leuten sage "In meinen post-mortem Reports von Eskalationen steht nicht nur drin "sie haben patch 0815 nicht eingespielt, deswegen crashte das system. Ihre Schuld", sondern auch "warum wurde der patch nicht eingespielt? ist die betriebsorganisation dazu passend? hatten sie eine chance zu erkennen, das das wichtig ist? Konnte man das wissen? trägt man als hersteller vielleicht auch eine verantwortung, weil eine notwendige information zwar dokumentiert, aber missverständlich dokumentiert war" " dann reden die Leute offener mit einem, und kann jedes Problem in einen "teachable moment" verwandeln. Das macht die Arbeit dazu zwar aufwändiger, aber meistens passiert danach der Fehler nie ein zweites mal. Und das spart mir auf Dauer viel Arbeit und Ärger und allen Leuten Geld.
Deswegen führt auch die Unart einiger Mitforisten, nachdem hier von irgendeinem Mishap anderer Piloten berichtet wird, jedes mal sinngemäss mit "war doch klar, ich hätte das besser gewusst. jeder hätte das besser gewusst" eher zu Unverständnis ob des kulturellen Verständnis des entsprechenden Mitforisten.
Das Gute ist, und man verzeihe mir den Zynismus: Im Gefüge des Grossen und Ganzen der Welt ist dieses Forum zwar interessant und ein netter Zeitvertreib, aber völlig und ganz und gar bedeutungslos. Vielleicht auch etwas was man im Hinterkopf halten sollte, wenn man sich hier wieder mal wie die Kesselflicker streitet ? Und das gilt wahrscheinlich für jedes Forum da draussen ;)
Dieser Beitrag wurde am 08.09.2023 09:04 Uhr bearbeitet.
Das hat sich selbst angehalten, nachdem es nach dem ersten Absturz auf den Backup umgeschaltet hat und der ebenfalls abstürzte, war halt schicht im Schacht.
Gab es keine manuelle Eingabemöglichkeit?
Aus Sicherheitsgründen vermutlich nein.
Ausserdem muss man den Fehler ja erst einmal verstehen und analysieren - also das tun, was jetzt in den letzten 2 Wochen zu diesem Report geführt hat.
Das macht keine(r) mal eben so im vorbeigehen.