Skyguide Ausfall 15.06.22, Luftraum über der Schweiz gesperrt

[mds]

Quote

«Ein weiterer Ausfall zerstört diese Hoffnung, noch bevor sie zum Plan wird. Das Instrumentenlandesystem der Flughäfen Genf und Zürich meldet: ‹System unzuverlässig›.»

 

Ich dachte eigentlich, so ein ILS sei ziemlich «dumm», da es im Wesentlichen aus zwei Leitstrahlen besteht. Kann jemand von Euch diese Meldungen in Genf und Zürich interpretieren?

 

Quelle: https://www.tagesanzeiger.ch/um-4-40-uhr-hiess-es-clear-the-sky-824372860746

[mountain_Andy]

vor 32 Minuten schrieb mds:

 

Ich dachte eigentlich, so ein ILS sei ziemlich «dumm», da es im Wesentlichen aus zwei Leitstrahlen besteht. Kann jemand von Euch diese Meldungen in Genf und Zürich interpretieren?

 

Quelle: https://www.tagesanzeiger.ch/um-4-40-uhr-hiess-es-clear-the-sky-824372860746

Ich denke, hier geht es um den ‚Remote Status Indicator‘ der Anlagen. Evtl. War diese Information ebenfalls nicht vorhanden…

[Frank Holly Lake]

3.55 Uhr
Dem diensthabenden Mitarbeiter wurden zwar noch die paar Flugzeuge angezeigt, die in den frühen Morgenstunden den Schweizer Luftraum durchquerten. Doch es fehlten relevante Informationen. Dazu gehörte zum Beispiel die Flughöhe, auf der ein Flugzeug in den Luftraum eintritt.

Das Management wurde aus den Betten geklingelt und sofort entschieden:
4.40 Uhr «Clear the Sky» CH

Das heißt: Alle Flugzeuge müssen den Schweizer Luftraum umgehend verlassen, Starts und Landungen sind nicht mehr möglich.
Es hatte wohl auch zu Problemen beim ILS geführt.

Bis die Techniker dem Problem auf die Spur kamen, vergingen noch weitere Stunden..

Ein digitaler Schalter (Netzwerk-Switch) hatte offenbar nicht funktioniert. Weil die Systeme das nicht erkannten, griff die in der Luftfahrt so wichtige Redundanz nicht.
Der Backup-Switch wurde nicht eingeschaltet. In der Folge kam es zu einem Datenstau und zum Versagen des Systems. Die Techniker lösten das Problem. Doch Skyguide wartete noch eine halbe Stunde, um sicherzugehen, dass alles wieder funktionierte.

In der Folge konnten die Flughäfen Genf und Zürich den Betrieb nach und nach wieder hochfahren – doch zuerst nicht bei voller Kapazität. Und der Rattenschwanz, den der Ausfall am Morgen nach sich zieht, dürfte vereinzelt noch bis ins Wochenende hineinreichen. Denn Passagiere, die anderswo landeten, oder gar nicht erst starteten, hätten vielleicht auch Anschlussflüge erwischen müssen. Für sie müssen Alternativen gefunden, Übernachtungen und Essen organisiert werden.

Quelle aerotelegraph

Grüße Frank

[Michi Moos]

vor 16 Stunden schrieb Frank Holly Lake:

Ein digitaler Schalter (Netzwerk-Switch) hatte offenbar nicht funktioniert.

Sorry, aber welcher "Experte" hat denn diese Analyse geschrieben? Ich kann mir schon grob vorstellen, was hier gelaufen ist. Nur: einen "Netzwerk-Switch" als "digitalen Schalter" zu bezeichnen, das ist nicht gerade auf Fachpresse Niveau, eher komplett planloser Kollege mit Google Translate. 

Switch (Netzwerktechnik) – Wikipedia

 

Wäre echt interessant zu wissen, was denn tatsächlich schief gelaufen ist und vor allem warum. Und dann, warum z.B. keine VFR Flüge ohne ATC mehr möglich gewesen wären.

[mds]

Journalisten schreiben üblicherweise, was ihnen Mediensprecher und andere erzählen. Darin liegt ein Problem beim heutigen Journalismus: Er besteht zum allergrössten Teil aus Verlautbarungen, die nicht geprüft, sondern verwurstet werden.

[Urs Wildermuth]

vor 5 Stunden schrieb Michi Moos:

Wäre echt interessant zu wissen, was denn tatsächlich schief gelaufen ist und vor allem warum. Und dann, warum z.B. keine VFR Flüge ohne ATC mehr möglich gewesen wären.

 

Das muss in der Tat aufgeklärt werden. Die bisherigen Informationen lassen viel zu viele Fragen offen. Unter anderem, warum hier ein so absolut rabiates "Clear the Skies" ausgesprochen wurde, welches selbst VFR Flüge verboten hatte, dies bei CAVOK Wetter, unter anderem auch viele Flüge, die mit der ATC absolut nix zu tun hatten. Die Totalschliessung des gesamten Luftraums einschliesslich VFR ist wohl eine Massnahme, die wirklich nur im äussersten Notfall wie etwa Terror oder kriegerische Handlungen ausgesprochen werden sollte. Wenn der Befehl "Clear the Skies" bereits um 0440 ausgesprochen wurde, wieso konnte nicht die Luftwaffe mobilisiert werden um mindestens die anfliegenden Langstrecken auf den Final in Zürich und Genf zu führen? Oder wieso können Schweizer Flughäfen bei Radarausfall in CAVOK nicht zumindest vereinzelt Flüge nach Sicht abfertigen?

 

Weiss jemand ob es eine offizielle Untersuchung gibt? SUST? Für mich ist der Vorfall definitiv zu schwer, als dass man das einfach administrativ abhandeln kann, vor allem wenn es darum geht, für ähnliche Vorfälle in der Zukunft Prozeduren zu entwickeln, die nicht gleich den Himmel leerräumen müssen.

 

 

 

 

 

 

[bhoeneis]

Aus IT-Sicht würden mich die folgenden Fragen interessieren:

1. Warum hat es so lange gedauert, bis der Switch ausgetauscht werden konnte? Konnte man das Problem nicht schnell genug eingrenzen? Oder war kein Ersatz-Switch oder IT-Personal in der Nähe verfügbar? Der Austausch eines Switches ist in der Regel nicht eine Sache von mehreren Stunden. (Ich kenne jedoch die genauen Hintergründe in diesem Fall nicht.)
2. Sind die betroffenen Systeme und Server nicht "dual-homed", also redundant (z.B. hot standby) über verschiedene voneinander unabhängige Switches (und Netzwerkpfade) angeschlossen? Wenn nein, warum nicht? (Heutzutage kann man Redundanz sogar auf Transport-Ebene sicherstellen, ohne dass die darüber-liegende Applikation etwas davon wissen muss. Und wenn eine einzelne Komponente versagt, findet der Netzwerkverkehr sein Ziel einfach über einen anderen Weg. Natürlich gibt es Konstellationen, wo das nicht oder nicht einfach möglich ist.)

Gruss,

 Bernie

Bearbeitet 20. Juni 2022 von bhoeneis
typo

[Urs Wildermuth]

vor 3 Minuten schrieb bhoeneis:

Warum hat es so lange gedauert, bis der Switch ausgetauscht werden konnte? Konnte man das Problem nicht schnell genug eingrenzen?

Ich denke von dem was man hört, dass sie solange gebraucht haben bis sie rausgefunden haben was überhaupt los ist, bzw das der Switch die Ursache war.

[Tigerstift1]

vor 1 Stunde schrieb Urs Wildermuth:

Weiss jemand ob es eine offizielle Untersuchung gibt? SUST? Für mich ist der Vorfall definitiv zu schwer, als dass man das einfach administrativ abhandeln kann, vor allem wenn es darum geht, für ähnliche Vorfälle in der Zukunft Prozeduren zu entwickeln, die nicht gleich den Himmel leerräumen müssen.

Hallo Urs,

 

Es ist definitiv ein Reportable Event laut Annex 13 to the Convention on International Civil Aviation "Aircraft Accident and Incident Investigation". Dort ist im Attachment C dies sogar als klares Beipiel angegeben --> "Failures of more than one system in a redundancy system mandatory for flight guidance and navigation"

 

EDIT: Das gab es schon einmal, nur in kleineren Rahmen: https://www.sust.admin.ch/inhalte/pdf/Spezielle_Untersuchungen/1887_d.pdf

Bearbeitet 20. Juni 2022 von Tigerstift1
Schlussbericht Totalausfall der Darstellung der Radarluftlage

[Urs Wildermuth]

vor 39 Minuten schrieb Tigerstift1:

Es ist definitiv ein Reportable Event laut Annex 13 to the Convention on International Civil Aviation "Aircraft Accident and Incident Investigation". Dort ist im Attachment C dies sogar als klares Beipiel angegeben --> "Failures of more than one system in a redundancy system mandatory for flight guidance and navigation"

 

Denk ich mir auch. Wird wohl ein spannender Bericht werden.

 

Die Frage wird auch sein, welche Fallback Szenarien gibt es, um mit reduzierten Mitteln zumindest noch den Luftraum E und G offen halten zu können, bzw welche Möglichkeiten haben auch die Platzverkehrsleitung (Tower) um bei solchen Vorfällen noch ein Minimum abzuwickeln, vor allem bei CAVOK.

 

 

[AirBuss]

Sind die betroffenen Systeme und Server nicht "dual-homed", also redundant (z.B. hot standby) über verschiedene voneinander unabhängige Switches (und Netzwerkpfade) angeschlossen? Wenn nein, warum nicht? (Heutzutage kann man Redundanz sogar auf Transport-Ebene sicherstellen, ohne dass die darüber-liegende Applikation etwas davon wissen muss. Und wenn eine einzelne Komponente versagt, findet der Netzwerkverkehr sein Ziel einfach über einen anderen Weg. Natürlich gibt es Konstellationen, wo das nicht oder nicht einfach möglich ist.) Gruss,
 Bernie

Anscheinend hat genau dieser Failover nicht funktioniert. Bzw. hat der Switch die Pakets wieder gebounced.
Bis man dann den Fehler findet, dauert es immer ein bisschen - die Komponenten selber scheinen ja OK zu sein.


Sent from my iPhone using Tapatalk

[Maxrpm]

4 hours ago, Urs Wildermuth said:

 

Wenn der Befehl "Clear the Skies" bereits um 0440 ausgesprochen wurde, wieso konnte nicht die Luftwaffe mobilisiert werden um mindestens die anfliegenden Langstrecken auf den Final in Zürich und Genf zu führen? Oder wieso können Schweizer Flughäfen bei Radarausfall in CAVOK nicht zumindest vereinzelt Flüge nach Sicht abfertigen?

 

 

 

 

 

 

Meine Vorschriften hätten das nicht erlaubt. Ausser im visual Teil eines IFR Anfluges darf ich nicht nach Sicht fliegen. Solange ich noch einen Alternate mit IFR Verfahren habe fliege ich auch dorthin. Von eine Jagtflugzeug in Formation geführt zu werden ist ausser im Notfall nicht vorstellbar. 

 

Wolfgang 

[onLoad]

Vor Allem, was nützt mir ein Jagdflugzeug? den Weg nach Zürich hätte ich schon noch gefunden. Es gibt keinen nennenswerten Nutzen von Kampfjets als Unterstützung von modernen Airlinern

Bearbeitet 20. Juni 2022 von onLoad

[Urs Wildermuth]

vor 3 Stunden schrieb Maxrpm:

Meine Vorschriften hätten das nicht erlaubt. Ausser im visual Teil eines IFR Anfluges darf ich nicht nach Sicht fliegen. Solange ich noch einen Alternate mit IFR Verfahren habe fliege ich auch dorthin.

 

Mir ist auch schon aufgefallen, dass es Visual Approaches in Europa faktisch nicht gibt, in den USA sind sie aber gang und gäbe. Fragt sich schon, wieso das so eng gehandhabt wird. Im Luftraum E und G wären visuelle Verfahren sowieso legal, in D mit einem Tower auch.

 

Die andere Frage wäre, wieso man nicht ein IFR Verfahren unter VMC auch unkontrolliert abfliegen kann, bzw unter einer Platzverkehrsleitung, die dann die Landung freigeben kann? In den USA wäre das möglich, ebenso in anderen Ländern, wo IFR im unkontrollierten Luftraum erlaubt?

 

Vermutlich hat sich auch nie jemand ernsthaft über einen solchen Vorfall Gedanken gemacht, denn eigentlich ist es ein völliges Unding, dass sowas vorkommt. Was einen nicht hindern soll, sich Gedanken zu machen wie man das in Zukunft regeln könnte.

 

Und dazu erklärt nichts von all dem, wieso der CH Luftraum auch für VFR zu war. Im Luftraum G und E spricht eh nix dagegen ohne ATC zu fliegen. Und eigentlich würde ja der restliche Luftraum bei Ausfall der ATC technisch ebenfalls zum unkontrollierten Luftraum... und da drin gilt, der PIC macht was sicher ist.

 

 

[Lubeja]

vor 7 Stunden schrieb Urs Wildermuth:

Und dazu erklärt nichts von all dem, wieso der CH Luftraum auch für VFR zu war. Im Luftraum G und E spricht eh nix dagegen ohne ATC zu fliegen. Und eigentlich würde ja der restliche Luftraum bei Ausfall der ATC technisch ebenfalls zum unkontrollierten Luftraum... und da drin gilt, der PIC macht was sicher ist.

 

Untersuchen muss man diesen Umstand sicher, aber ich weiss jetzt nicht, ob da so viel Zündstoff dahinter ist. Vielleicht war einfach noch zu früh am morgen und der Kaffee noch zu wenig, um über das allernotwendigste hinauszudenken? Oder es hatte damit zu tun, dass die Östreicher subito und ohne gross Potential für Diskussionen dazu gebracht werden mussten, das NOTAM zu veröffentlichen, weshalb man sich so simpel wie möglich hielt, ohne die Folgen genau absehen zu können? Die spannende Frage dürfte meines Erachtens eher dahin gehen, wieso es kein pfannenfertiges Verfahren dafür gab, bzw. wieso ein vorhandenes eine so unsinnige Regel beinhaltet. 

[cosy]

15 hours ago, bhoeneis said:

Aus IT-Sicht würden mich die folgenden Fragen interessieren:

1. Warum hat es so lange gedauert, bis der Switch ausgetauscht werden konnte? Konnte man das Problem nicht schnell genug eingrenzen? Oder war kein Ersatz-Switch oder IT-Personal in der Nähe verfügbar? Der Austausch eines Switches ist in der Regel nicht eine Sache von mehreren Stunden. (Ich kenne jedoch die genauen Hintergründe in diesem Fall nicht.)
2. Sind die betroffenen Systeme und Server nicht "dual-homed", also redundant (z.B. hot standby) über verschiedene voneinander unabhängige Switches (und Netzwerkpfade) angeschlossen? Wenn nein, warum nicht? (Heutzutage kann man Redundanz sogar auf Transport-Ebene sicherstellen, ohne dass die darüber-liegende Applikation etwas davon wissen muss. Und wenn eine einzelne Komponente versagt, findet der Netzwerkverkehr sein Ziel einfach über einen anderen Weg. Natürlich gibt es Konstellationen, wo das nicht oder nicht einfach möglich ist.)

Gruss,

 Bernie

 

Mein Post hier betrifft erstens nicht die Radardaten, sondern die Flugplandaten. Zweitens basiert die Aussage auf einem Stand von 1999 (Herbst). Aber es zeigt auf, unter welchen kritischen Bedingungen die Swisscontrol arbeitete / arbeiten musste (Anmerkung: die Swisscontrol (zivile Luftraumführung) wurde dann 2001 mit der militärischen zusammengelegt und umbenannt in Skyguide).

Damals lief vom (zivilen) Flugplansystem) nur eine Unit von Drei. Eigentlich war das System so gedacht, dass

- Unit 1 hot ist (verarbeitet alle FLP-Daten und verteilt sie, managed Konflikte und aktualisiert ein Meldesystem in Baumstruktur

- Unit 2 ist hot-standby und kann innert Sekunden den Betrieb übernehmen . Die Realtime Synchronisation zwischen Datensatz zum Fail-Zeitpunkt und dem aufgestarteten System musste manuell abgearbeitet werden

- Unit 3 hatte zwei Funktionen: a) cold-standby (also vollständig redundante und funktionierende Hardware, betriebsfähige Software zumindest über Scripts installierbar

 und b) Testsystem: damit wurden neue Releases und spezifische Änderungen / Erweiterungen getestet und ausprobiert.

Eine Inbetriebnahme für den Ersatz der Unit 2 oder gar 1 benötigte aber die Präsenz und Arbeitszeit vom technischen Staff. Dadurch wäre der Aufwand bestimmt Tage und nicht Stunden.

 

Was ich antraf :

Unit 1 : running (im Einsatz)

Unit 2: ausgefallen / in Repararatur -seit Wochen

Unit 3: unvollständig, da kanibalisiert: es wurden einzelne Karten in den (Unix-basierten) Rechner-Raks entfernt, weil sie (mir nicht bekannt) entweder in Unit 1 oder Unit 2 benötigt wurden.

 

Ein Ausfall von Unit 1 zum Zeitpunkt meiner Visite hätte Je nach Verkehr zu ausgeprägten Holdings und Verspätungen im IFR Verkehr geführt oder zum Zusammenbruch.

In Randzeiten konnten die Controller per Telefon die FLP-Daten jeweils an die betroffenen Stellen melden. Das geht aber nur in der Nacht und bei schwachem Verkehr.

Dabei steigt die potentielle Fehlerquote und dieses Fallback-Konzept "stürzt" zuerst an den "Knoten" ab.

 

Zum Zeitpunkt wurde bereits an der Ablösung des gesamten Systems gearbeitet- aber noch nichts umgebaut. Das war konzeptionell, denn die Verträge waren noch nicht unterzeichnet. Aber die Leute wussten Alle bereits, dass das Unix-System schweizweit rausfliegt.

 

Cosy

 

[cosy]

Die deutsche Gewerkschaft für Flugsicherung hat vor einer Woche vor dem Kahlschlag unter den Mitarbeitern gewarnt (Effekt aus der "pandemischen Sanierungsaktion"):

https://webedi.gdf.de/index.php/de/presse-info/pressemitteilungen/610-gdf-fordert-einen-luftfahrtgipfel

 

Gibts da bei Skyguide wieder ein Defizit, so wie 2003 (nicht vorhandenes Know-How resp. externalisiert )?

 

cosy

[bhoeneis]

2 hours ago, cosy said:

Was ich antraf :

Unit 1 : running (im Einsatz)

Unit 2: ausgefallen / in Repararatur -seit Wochen

Unit 3: unvollständig, da kanibalisiert: es wurden einzelne Karten in den (Unix-basierten) Rechner-Raks entfernt, weil sie (mir nicht bekannt) entweder in Unit 1 oder Unit 2 benötigt wurden.

 

Ein Ausfall von Unit 1 zum Zeitpunkt meiner Visite hätte Je nach Verkehr zu ausgeprägten Holdings und Verspätungen im IFR Verkehr geführt oder zum Zusammenbruch.

Leider trifft man solcherlei auch in anderen Branchen mit Echtzeitanforderungen an. Eine Anekdote, die sich bei einem früheren Kunden aus der Telekommunikations-Branche (ITSP) zugetragen hat (Kurz-Darstellung):

• Bei Inbetriebnahme wurden die Systeme redundant ausgelegt: Zwei Server im Cluster mit automatischer Umschaltung, wenn der aktive Server taucht. Grundsätzlich ein sinnvolles Setup, obwohl auch bessere (jedoch viel aufwendigere) Lösungen denkbar waren.
• Irgendwann brauchte man Hardware (HW), die auf die Schnelle nicht geliefert werden konnte. Es wurde entschieden, den redundanten Cluster "temporär" aufzuheben und die HW des Standby-Systems anderweitig zu verwenden (bis die neue HW geliefert wird), d.h. eine "vorläufige" Aufhebung der Redundanz.
  • Da dies nur vorläufig vorgesehen war, hatte man die Netzwerk-Konfiguration auf dem verbleibenden Server nicht angepasst; diese wurde also im Cluster Mode belassen.
  • Die Redundanz wurde seither nicht wiederhergestellt und ging in Vergessenheit. Der verbleibende Server lief danach mehrere Jahre durch (d.h. ohne Reboot und ohne Updates (!) ). Dokumentiert wurde das ganze auch nicht (war ja nur temporär geplant...).
• Jahre später musste aufgrund von Problemen im Betrieb der verbleibende Server neu-gestartet werden. Normalerweise ein Standard-Eingriff, der (ausser einem kurzen Unterbruch) zu keinen Problemen führt. Aufgrund der undokumentierten Geschichte (und der nicht mehr vorhanden Redundanz) kam es dann aber zu einem längeren Totalausfall.
  • Grund: Netzwerk-Konfiguration war immer noch im Cluster-Mode und dem Server fehlte die Information, ob er nach einem Neustart aktiv gehen oder im passiven Modus verbleiben soll (weil der andere Server ja nicht mehr existierte und daher keine Antwort gab).
• Niemand der Techniker vor Ort kannte diese "History". Auch mir fehlten bei der Behebung des Problems anfänglich diese Informationen, da das ganze vor meiner Zeit geschah und auch nicht dokumentiert wurde.

So nebenbei: Der Schuldige war dann schnell gefunden: Nicht etwa die dilettantische Aktion der "temporären" Aufhebung der Redundanz, nein, der nichts-ahnende IT-Mitarbeiter, der den Server neu-starten musste, war Schuld...

Aus meiner Sicht: Sehr schlechtes IT Management. Weil die Aufhebung von Redundanz keine unmittelbaren betrieblichen Probleme verursachte, wurde diese sträflich vernachlässigt.

 

Vom Prinzip her ähnliche Konstellationen gibt es bekanntlich auch in der Aviatik, oft als "Schweizer-Käse-Scheiben-Modell" oder "Verkettung von unglücklichen Umständen" bezeichnet.
 

Gruss,

 Bernie

 

 

 

Bearbeitet 21. Juni 2022 von bhoeneis
typo / Wording

[Michi Moos]

vor 13 Stunden schrieb AirBuss:

Anscheinend hat genau dieser Failover nicht funktioniert. Bzw. hat der Switch die Pakets wieder gebounced.
Bis man dann den Fehler findet, dauert es immer ein bisschen - die Komponenten selber scheinen ja OK zu sein.

Hatte auch schon solche spassigen Geschichten in grösseren Umgebungen gesehen. Ein Beispiel war ein Hardware Defekt an einem Modul, der Switch hat das nicht erkannt und einfach alles friedlich ins grosse, schwarze Loch weiter geschickt. Sowas sauber zu diagnostizieren ist nicht ganz easy. Je komplexer und "hochverfügbarer" Umgebungen sind, desto anspruchsvoller wird es, wenn mal was schief läuft. Man erinnere sich zum Beispiel an Facebook, Whatsapp etc. welche mal für ein paar Stunden komplett vom Internet verschwunden waren. Da hilft auch redundante Hardware und ganz viel Geld nicht wirklich...

 

 

 

vor 47 Minuten schrieb cosy:

Unit 2: ausgefallen / in Repararatur -seit Wochen

hihi, das tönt so dermassen nach realem Leben, der kleine Unterschied zur Theorie aus der Schule 

 

 

vor 12 Stunden schrieb Maxrpm:

Meine Vorschriften hätten das nicht erlaubt. Ausser im visual Teil eines IFR Anfluges darf ich nicht nach Sicht fliegen.

Das Hauptproblem ist denk ich nicht mal nur in der Luft zu suchen. Grundsätzlich könntest ja komplett ohne Radar einfach ein RNP Standard Procedure fliegen und kommst gemütlich ohne Bodenunterstützung wie ILS, Radar etc. runter. Aber wer macht dann blöd gesagt den Flugplan für die gelandeten Flieger zu, Slot Coordination für Departures, Interfaces zu Ground Handling usw. - keine Ahnung über Details, hab da keinen Einblick. 

[bhoeneis]

4 minutes ago, Michi Moos said:

Hatte auch schon solche spassigen Geschichten in grösseren Umgebungen gesehen. Ein Beispiel war ein Hardware Defekt an einem Modul, der Switch hat das nicht erkannt und einfach alles friedlich ins grosse, schwarze Loch weiter geschickt. Sowas sauber zu diagnostizieren ist nicht ganz easy. Je komplexer und "hochverfügbarer" Umgebungen sind, desto anspruchsvoller wird es, wenn mal was schief läuft. Man erinnere sich zum Beispiel an Facebook, Whatsapp etc. welche mal für ein paar Stunden komplett vom Internet verschwunden waren. Da hilft auch redundante Hardware und ganz viel Geld nicht wirklich...

Kann ich weitgehend bestätigen.

 

Allerdings hapert es immer noch allzu-häufig an Punkten wie robustes Design, korrekte Umsetzung, taugliche Überwachung oder generell Life-Cycle-Management von (redundanten) Systemen. Zum Beispiel können die Auswirkungen eines Netzwerk-Switch Problems grundsätzlich mit Dual-Homing bzw. Multi-Homing und Verlagerung von "Intelligenz" von (zentralen) Netzwerk-Komponenten zu den Endpunkten, sowie konsequenter Überwachung aller relevanten Links in engen Grenzen gehalten werden. Mir ist bewusst, dass z.B. gewisse Abhängigkeiten, bestehende Systeme, Sicherheits- oder Zertifizierungs-Anforderungen den Gestaltungs-Spielraum (bezüglich Redundanz) mehr oder weniger stark einschränken können; hier kommt dann das übergeordnete Life-Cycle Management ins Spiel.

 

Da ich weder die (Netzwerk-)Architektur der Skyguide-Systeme, noch die weiteren Umstände des Ausfalls kenne, kann ich das in Bezug auf den aktuellen Fall bei Skyguide nicht beurteilen. Gut möglich, dass es in erster Linie "Pech" war.

 

Gruss,

 Bernie

[mountain_Andy]

vor 15 Stunden schrieb Urs Wildermuth:

Im Luftraum E und G wären visuelle Verfahren sowieso legal, in D mit einem Tower auch

Im Luftraum E muss IFR von IFR gestaffelt sein und es müssen Verkehrshinweise zu VFR soweit möglich erteilt werden. Somit ist es aus meiner Sicht nachvollziehbar, wenn im Luftraum E ebenfalls "clear the sky" angwendet wird, weil eben IFR/IFR nicht gestaffelt werden kann.

 

Die Luftraumstruktur in der Schweiz hilft da nun nicht weiter. Alles was über 2000ft GND ist, ist Luftraum E. Interessant in diesem Zusammenhang ist, dass gemäss  VFR Guide (RAC 4-3-4 Kap. 7) im Luftraum E erst ab 7000ft/AMSL ein Transponder betrieben werden muss. Im VFR Guide (VFR RAC 1-0-4 Kap. 1.7) steht zudem dass IFR im G auf publizierten SID/STARS (betrifft vielleicht nur LSZG wenn die RMZ aktiv ist?) gestattet ist. Auch ich kann es nicht nachvollziehen, warum der Luftraum G ebenfalls geschlossen war. Aber es ist ein Erklärungsansatz.

 

[Urs Wildermuth]

vor 6 Minuten schrieb mountain_Andy:

Die Luftraumstruktur in der Schweiz hilft da nun nicht weiter. Alles was über 2000ft GND ist, ist Luftraum E.

 

Na ja, man kann sich aber eines fragen: Was für eine Klasse ist der Luftraum wenn die ATC total weg ist? Eigentlich wird dann alles zu G.

 

Und der VFR Ban ist damit nicht erklärt. In E braucht es keine ATC für VFR, genau so wie für G.

 

So wie es aussieht ist "Clear the Sky" eine Art "Panik Modus" wenn halt keine Prozeduren zur Verfügung stehen. Wie gesagt, wir wissen ja nach wie vor nicht, was die Lotsen überhaupt noch hatten. Hat Radio funktioniert? Haben die Telefone funktioniert? oder was?

 

 

[mountain_Andy]

vor 1 Minute schrieb Urs Wildermuth:

Eigentlich wird dann alles zu G

Sehe ich auch so, mit der Konsequenz, dass jegliche Staffelung für die IFR Flüge weg ist. 

 

vor 2 Minuten schrieb Urs Wildermuth:

Und der VFR Ban ist damit nicht erklärt. In E braucht es keine ATC für VFR, genau so wie für G

Nein, der VFR Ban ist nicht erklärt. Aber ich kann es nachvollziehen, dass die IFR Flüge im E maximal geschützt werden müssen, was zu dieser Tageszeit kein Problem gewesen sein dürfte.

 

vor 5 Minuten schrieb Urs Wildermuth:

Wie gesagt, wir wissen ja nach wie vor nicht, was die Lotsen überhaupt noch hatten. Hat Radio funktioniert? Haben die Telefone funktioniert? oder was?

Ja ich hoffe, dass wir das erfahren werden.

[cosy]

23 hours ago, bhoeneis said:

Vom Prinzip her ähnliche Konstellationen gibt es bekanntlich auch in der Aviatik, oft als "Schweizer-Käse-Scheiben-Modell" oder "Verkettung von unglücklichen Umständen" bezeichnet.

Off-topic: mir missfällt dieses immer wieder zitierte "Modell".  Weil:

a) - nur wenige Schweizer Käse haben systematisch Löcher im Laib

b) - Die zufällige Verteilung der Löcher im Käse ist keinesfalls dienlich für die "Aussagen, die man mit diesem Käse belegen will"

c) - wenn man einen Käse mit Löchern* in Scheiben schneidet und nicht umsortiert, dann trifft wieder Aussage b) zu

 

*z.b. der scheusslich schmeckende Emmenthaler...

 

Cosy  (nicht gaaaanz  ernst gemeint...Sommerhitze sei Dank)

 

Bearbeitet 22. Juni 2022 von cosy

[reverser]

Zitat

Guten Abend allerseits ; zum Thema hier habe ich folgenden Beitrag eines Fluglotsen bei Pprune gefunden:

Er äussert selber sein Erstaunen darüber, dass ein solcher Vorfall in heutiger Zeit überhaupt noch möglich ist; wirft jedoch Presse und Medien vor, das Ereignis verkürzt zu schildern, so á la "der Bildschirm ist aus - wir sind blind und haben keine Ahnung mehr, wer da draussen rumfliegt"

Es wird auf ein backup-system ausgewichen,  jedoch muss gemäss Behörden-Vorgabe zuerst "der Himmel leer geräumt werden". Das wiederum ist eine Vorsichtsmassnahme für den Fall, dass auch das backup-system crashen sollte.

Das wird alles zwei mal jährlich am Simulator geübt, wie man untenstehend im englischsprachigen Originalbericht lesen kann, bis, als "backup zum backup" zurück zur "Steinzeit"-Methode, als die Lotsen noch mit Bleistift und Papierstreifen hantierten und die benachbarten Stationen telefonisch kontaktierten. Es soll noch Lotsen der älteren Generation geben, welche das früher noch praktizierten, und die in so einem Fall zusätzlich Hilfe leisten könnten.

Die benachbarten ausländischen Stationen haben auch Einsicht in einen guten Teil des Schweizer Luftraumes - ein Telefonat würde genügen, und der Kollege "next door" würde den Flieger schon frühzeitig, noch im Swiss Airspace, übernehmen.

Dann spricht der Lotse hier noch von einer sog. "positive control philosophy" - im besten Fall erfolgen Instruktionen und Freigaben mit dem "Hintergedanken" dass jederzeit der Bildschirm ausfallen kann. Jede Freigabe sollte dem Lotsen Raum lassen, sich von seinem Platz am Bildschirm zu entfernen, ohne dass es gleich riskant wird.  Das soll möglich sein, sonst ist es kein "positive control".

Der Lotse schliesst mit der Bemerkung, dass so ein system-crash, genauso wie System-Ausfälle bei den Piloten, immer wieder rigoros am Simulator trainiert werden - ein handling via backup kann problemlos ablaufen. Die Behörden bevorzugen es jedoch, "auf Nummer sicher" zu gehen, den Himmel leer zu räumen, so wie Skyguide es getan hat.

 

Soweit meine grob-gestrickte ,holprige Übersetzung: Untenstehend die Englische Originalversion.

Gruß Richard

 

It's an interesting topic, and rather surprising Skyguide had such a failure in the modern era, but, it is not the "screen is gone, we don't know who is out there" type of scenario that many articles would have you believe.. A backup reduced redundancy radar is available to use, in the event of main screen total failure. It is perfectly OK to use, and controllers are able to use it just fine, but in the instance of a main failure, the procedure, as approved by the regulator, is to 'clear the skies'. This is due to the fact if you are operating on a backup, and that fails, what happens then? Regulators do not have an appetite for this type of risk.

Regarding procedural control, it is true that us modern European controllers are not rated/certified in procedural control, however in our refresher training twice a year, we do train for the total failure of all radar screens, including backup, so as to use pen and paper separation. This is based on position reports relative to known waypoints/geographical locations. The controller uses their merit and experience to clear aircraft onwards onto adjacent centres and empty the airspace. Also, most adjacent centres would be able to see a good chunk into your airspace, so realistically, all goes blank, you would ring your colleague next door to ask them to point out your traffic and take them early.

Most centres would also still have some controllers of a generation that routinely used procedural separation in the past, they would be called to observe/sit in. Should we have total radar/VHF failure, we would be ringing an adjacent centre, from a mobile telephone should it be required, and asking them to pick up the last frequencies in use, in order to speak to aircraft. It should be noted that we operate on a 'positive control' philosophy, and that any clearances/instructions issued are given with the idea in the back of your mind that the screen goes dark any second. Every clearance should be safe for you to walk away from, or else that is not positive control.

System failure is one of the most trained aspects of our job, and we would be just fine to separate based on a back up system, but like I mentioned, the regulator in most cases only approves a 'clear the skies' procedure, due to the reduced redundancy of the system. I do suspect this is what Skyguide safely carried out this morning, before returning to normal operations upon restoration of main systems.