Flughafentechnik

Leserzuschriften:

Hallo Hadmut,

zu der Checkin IT kann ich ein paar Infos beisteuern falls es dich und die Leser interessiert. Ich habe meine IT Ausbildung bei einer Fluglinie an einem Internationalen Flughafen (EU) gemacht und auch ein paar Jahre in den Operations gearbeitet. Daher kenne ich beide Seiten nur zu gut. Dies war in Zeiten von Windows XP und später wurde auf Windows 7 migriert.

An jedem angeflogenen Flughafen müssen die Passagiere eingecheckt werden und die Crew benötigt ein korrektes Load & Trim Sheet zur Berechnung der Performance beim Takeoff und Landung. All dies fiel in meinen Aufgabenbereich weil es halt sehr IT-lastig war und keiner sich an diese alten Terminal (CLI) Systeme getraut hat. Als ITler hat man da weniger Hemmungen und ist mit Handbüchern so dick wie Telefonbücher per Du.

Entweder macht das handling die Fluglinie selbst oder ein (kostenpflichtiger) handling agent wird damit beauftragt. Meistens (aber nicht immer) wird dafür die Software der Fluglinie benutzt. In Ausnahmefällen kann der handling agent auch seine eigene Software einsetzen. Benötigt aber dann alle Daten des Flugzeugs (Seatmap/weight & balance) etc … Je nachdem was alles an Dienstleistungen gewünscht wird. Das eröffnet dann aber wieder eine ganze Büchse an Problemen wenn nicht alles Reibungslos klappt. Anbieter von solchen Checkin Systemen gibt es nicht viele. Gehostet werden die meistens in einem Datacenter dass sich nicht unbeding auf dem Flughafengelände oder im Hauptquartier der Fluglinie befinden muss. Kommt es da zu Pannen muss das nicht unbedingt an dem Dienstleister oder Betreiber vor Ort am Flughafen liegen. Natürlich ist dieser für seinen eigenen IT Zoo verantwortlich. Da schlampen bestimmt auch einige.

Die Flughafenbetreiber und handling agents sind oft unterschiedliche Firmen. Bei uns war es so dass die Fluglinie ebenfalls handling agent für alle anderen Fluglinien des gesamten Flughafens war. (Es war halt einfach keine andere Konkurrenz vor Ort mit Material und Personal.) Der Flughafenbetreiber kümmert sich um die IT Hardware und das ganze baggage handling usw … am Terminal. Gegebenfalls werden dann noch weitere Subunternehmen oder Zeitarbeitsfirmen für spezielle Aufgaben beauftragt. Der Flughafenbetreiber kümmert sich dann auch um die Security und arbeitet mit den Behörden zusammen. Das ganze Programm eben.

Für uns ITler:

Der Checkin Mitarbeiter sitzt meist an einer ganz normalen Windows Workstation auf der eine Kiosk Software läuft. Diese stellt die entsprechenden Checkin Anwendungen zur Verfügung die für den Checkin Schalter in dem Moment benötigt werden. Dazu gehören Thermodrucker für die Bordkarten und Gepäcklabel. Im Hintergrund wird die Anwendung in ihr jeweiliges Datacenter getunnelt. Bei uns war das SITA DCS mit Sitz in Atlanta. Wenn also in Atlanta jemand aus versehen die Stromversorgung des Datacenters mit dem Bagger kappt, (bereits passiert) dann können alle betroffenen Fluglinien weltweit nicht mehr einchecken. In dem Fall werden Bordkarten manuell per Kugelschreiber beschrieben.

Passagierlisten gab es meist im vorraus schon per Telex (Sitatex) und als Mail (Sitatex to mail). Eigentlich wurde sehr viel per Telex gemacht. Auch Sitzplatzreservierungen, Sondermenüs etc … Kommt alles per elektronischem Telex in das Checkin System. Die diensthabenden Fluglinienmitarbeiter oder handling agents vor Ort haben dann Passagierlisten und können bei Bedarf manuell einchecken per Kugelschreiber als “last resort”. Die Buchungssysteme haben das Checkin System regelmässig mit Telex gefüttert um die Passagierlisten aktuell zu halten. Da gab es meines Wissens nach keine “moderne” API. Ich gehe davon aus die Webseiten der Fluglinien und die Buchungssysteme untereinander ausgiebig mit API’s arbeiten.

Lustig wurde es immer bei schlechtem Wetter oder anderen “Irregularitäten” bei dem ich dann manuell Passagierlisten im Notepad zusammenklauben muss. Z.b. wenn Flüge aufgeteilt werden oder Flugzeugtypen geändert werden. Reisegruppen und Familien wollen ja nicht getrennt fliegen.

Fazit:

Ich stimme dir zu dass man theoretisch das ganze Buchungssystem/Checkin/Loadplanning alles per Browser machen könnte und dann einfache Linux Kisten oder Raspberries als verdongelte clients dahin stellen kann. Das Problem sind die altmodischen Checkin Anwendungen selbst. Solange da keiner etwas browserfähiges anbietet wird alles bei Spezialsoftware bleiben. Ultra altbacken sind diese und zu meiner Zeit (Win XP/7) noch auf Terminalbasis. Da musste der Checkin agent noch Terminalbefehle einhämmern um die Kunden einzuchecken oder um extra Sitzplätze zu reservieren. Inzwischen haben sie aber auch schon eine Anwendung mit GUI (Altea DCS). Ich befürchte eine CLI könnte man der heutigen Generation nicht mehr zumuten. Da würden die Fluglinien keine Mitarbeiter mehr finden wenn man ja heute schon mit Tastatur und Maus überfordert ist …

Kannst du so veröffentlichen wenn es dir gefällt. Da gibt es keine “Geheimnisse” oder NDA’s.

Das wusste ich nicht … aber ziemlich genau so hatte ich es mir vorgestellt.

Im Prinzip braucht man nur ein extrem reduziertes Betriebssystem, das gerade den Browser starten kann, und ein paar Konfigurationseinstellungen, das alles als monolitisches System, das sich selbst aktualisiert. Genau so etwas gibt es auch schon, nennt sich ChromeOS.

Der Chrome-Browser kann auch tatsächlich auf serielle (und pseudoserielle per USB) Schnittstellen zugreifen, es gibt nämlich die Möglichkeit, ESP32-Board und ähnliche per Webbrowser mit Firmware zu bespielen. Es sollte also kein großes Kunststück sein, einem Browser noch beizubringen, Daten auf den Druckern für Gepäck, Tickets und Bordkarten auszudrucken. Das wäre doch wirklich naheliegend, und Hersteller von Thin Clients und Vorlagen (ChromeOS, Silverblue/Kinoite) gibt es auch.

Ich könnte ja noch verstehen, wenn das alles total sicherheitszertifiziert wäre und nicht angetastet werden darf. Aber gerade das kann ja nicht sein, so wie die sich anstellen.

Lieber Herr Danisch;

eigentlich ist viel zu wenig bekannt, außer dem Firmennamen Collins (die sitzen auch in Heidelberg, früher Rockwell, noch früher Teldix – zu Bundeswehr-Zeiten).

Bündnis Deutschland ist eine Quelle, der ich eher nicht vertrauen würde. Es läuft normalerweise nichts mehr auf Windows ohne Edge, der wiederum nicht auf XP läuft.

Auf Linkedin kursierte das wahrscheinlichere Gerücht, es könnten vielmehr keine ARINC-Nachrichten mehr verschickt werden (genormte Formate für Avionik und Luftverkehr im allgemeinen), weil bei Collins etwas schiefgegangen sei, angeblich mit einem J2EE-Server oder gar einer ganzen Farm. Damit sei deren ganzes Netzwerk down.

Es gibt noch den Wettbewerb in Gestalt der belgischen SITA, die unabhängig über ein eigenes Netz diese Nachrichten versenden.

However, diese ARINC-Nachrichten zwischen den Flughäfen (wieviele Gäste, wieviele Koffer, wer steigt wo aus usw) sehen ziemlich wie das alte EDIFACT aus und müssen auch in Burundi oder Malawi über eine 9600 Bd-Leitung gesendet und empfangen werden können – da wird man nicht zwingend immer die allerneueste Software vorschreiben können.

Ich finde aber noch etwas anderes bedenklich:

Hallo Hadmut!

Ich bin überrascht, dass bei der Analyse des Angriffs nicht darüber berichtet wird, dass Collins eben überwiegend Militärgüter herstellt. BER ist wohl nicht das Ziel gewesen, sondern nur ein Kollateralschaden.

Normalerweise würde ich dem nicht so viel Gewicht beimessen.

Weil aber gerade ein Flughafen nach dem anderen wegen Drohnensichtungen außer Betrieb gehen muss, könnte das doch gezielte Sabotage an Flughäfen sein.