Vom Mainframe zu ML – Wie sich die Luftfahrt IT kontinuierlich neu erfindet.

Cloud-Strategie, KI/ML und Data-Driven Decisions. Auch in der Luftfahrt-Branche zählt man auf aktuelle IT-Trends – und das seit über 50 Jahren. Relikte sind bei genauem Hinsehen bis heute in Passagierservicesystemen zu finden. Die Entwicklung der Aviation IT liest sich wie eine Liste heute etablierter Architekturprinzipien und -muster. Sie dienen zur Bewältigung geschäftlicher Anforderungen sowie zur Integration neuer Konzepte in die bestehende Systemlandschaft.

Reservation Agent am Terminal IBM 2915
Reservation Agent am Terminal IBM 2915 im Line Mode ca. 1970 (Bildquelle: Courtesy of Missouri State Archives)

Bis in die 1960er Jahre waren die wichtigsten Kommunikationsmittel für Fluggesellschaften und Flughäfen das Telefon und der Fernschreiber. Nachrichten wurden auf Teletype-Geräten (mit Tastatur, Lochstreifen und Drucker) ausgetauscht und über die Netzwerke spezialisierter Provider wie ARINC und SITA versendet, Buchungen und Inventare in Papierform verwaltet.

Mit stark steigendem Passagieraufkommen starteten American Airlines und IBM das Projekt SABRE, um in der Lage zu sein, Flugbuchungen elektronisch zu verwalten. IBM konnte zu diesem Zweck zentralisierte TPF Mainframe-Systeme nutzen, die für den Bankensektor entwickelt wurden. IBM bot solche Systeme (basierend auf System/370) später unter dem Namen PARS weltweit an, es wurde z.B. von Swiss International Air Lines bis 2016 eingesetzt. Auch PARS nutzte TPF als Betriebssystem, dessen Qualitäten (hohe Verfügbarkeit und Datenintegrität) leiten sich unmittelbar aus dem zugrunde liegenden Architekturmuster ab: Transaction Processing.

Software Architecture
Pattern: Transaction Processing
Tactics: Coordinate/Manage Resources

Technologieaufkommen in der Luftfahrt
Technologieaufkommen in der Luftfahrt – Die wichtigsten Meilensteine. (Bildquelle: Eigene Darstellung)

Während der buchungsbezogene Datenaustausch an Arbeitsplätzen derselben Gesellschaft über die Mainframes erfolgte, musste mit Flughäfen und anderen Airlines weiterhin über Fernschreiber kommuniziert werden. Die Mainframe-Systeme waren inzwischen mit den Fernschreibern verbunden und im Laufe der 1970er Jahre etablierte IATA (als Dachverband der kommerziellen Luftfahrt) “Resolutions” und “Recommended Practices” für den elektronischen Austausch von Informationen. Das Passenger Services Conference Resolutions Manual umfasst heute hunderte solcher Standards. Die (weitgehend strukturierten) Formate sind so konzipiert, dass sie sowohl von Menschen verstanden werden als auch Machine-to-Machine (M2M). Das Messaging Pattern fungiert hier als Kommunikationsmuster für Enterprise Application Integration.
Die Teletype-Formate wurden Anfang der 1980er Jahre ergänzt durch den aufkommenden EDIFACT-Standard, der auf Maschinenlesbarkeit optimiert ist. Das Nachrichtenformat besteht im Nutzdatenteil aus Segmenten mit Bezeichner und Composites. Diese Segmente können hierarchisch angeordnet sein und so auch objektorientierte Datenmodelle unterstützen. Kommunikationspartner nutzten EDI-Vereinbarungen und bestehende UN-EDIFACT Codelisten (oder zusätzliche, bilateral vereinbarte) als Nachrichtenstandard, die als Vorläufer heutiger API Contracts angesehen werden können.

Enterprise Integration Architecture
Pattern: Messaging

Amadeus mit Terminal Emulator
Amadeus Altéa Plan GUI mit Terminal Emulator. Der Line Mode-Zugang aus der Terminal-Ära ist bei erfahrenen Agent*innen heute noch wegen seiner Effizienz beliebt. Jüngere Kolleg*innen nennen ihn hingegen “Cryptic Screen”. (Bildquelle: Eigene Darstellung)

In den 1990ern etablierte sich der Personal Computer an Arbeitsplätzen als Hardware-Standard und die kostspieligen Line oder Block Mode-Terminals hatten als Peripherie der Mainframe-Systeme ausgedient. Sie wurden stattdessen durch Terminal-Emulation ersetzt und an den PC angeschlossene Matrixdrucker machten nach demselben Prinzip Fernschreiber endgültig überflüssig.
Zunächst waren diese PCs entweder direkt über ein Modem an die Rechenzentren angebunden oder ein Standort mit mehreren Geräten nutzte eine gemeinsame Standleitung. TCP/IP als Internetworking Practice setzte sich erst um die Jahrtausendwende auch im Airline-Sektor durch und führte zu massiver Senkung der Anbindungskosten für die weltweit angeschlossenen Standorte.

Network Architecture
Pattern: Internetworking Practice

Kabinensitzplan im Vergleich
Ein Kabinensitzplan im Vergleich, links grafisch, rechts im “cryptic” Terminal (Bildquelle: Eigene Darstellung)

Client-Server als Architekturstil wurde mit zunehmender Rechenleistung der Standard Workstations/PCs in den 2000er Jahren immer verbreiteter. Rich Clients nahmen den Backends funktionale Aufgaben ab. Die grafischen Oberflächen (GUI) erleichterten die Benutzbarkeit und verkürzten Einarbeitungszeiten für neue Mitarbeitende.

 

Software Architecture
Pattern: Distributed Computing (Client-Server)

Im direkten Kundenkontakt etablierten sich die ersten E-Commerce und Customer Servicing-Webseiten (Online Buchung/Check-in) und generierten zusätzliches Geschäft, aber auch zusätzliche Konkurrenz (z.B. im Billigflugsektor). Für Web Developer war die Kommunikation mit TPF-Mainframes ungewohnt und kompliziert. Schichtenarchitektur half, das Frontend zu entkoppeln mithilfe eines Host Abstraction Layers. Zusätzlich konnte ein Softwareanbieter nun auch unterschiedliche Backends mehrerer Gesellschaften mit derselben Frontend-Applikation verbinden.

Software Architecture
Pattern: Layers

SOA-Service von Swiss
Beispiel: Das Hub Control Center Zürich nutzt einen SOA-Service von Swiss International Air Lines, um einem zeitkritischen Transfer-Gepäckstück die “Authority-To-Load” zu entziehen. Das Connection Management-System muss dabei keine Details zum Amadeus Baggage Record kennen – die Orchestration erledigt die Middleware. (Bildquelle: Eigene Darstellung)

Aber auch die Airlines selber wollten sich unabhängiger von den grossen Aviation IT-Providern machen, um schneller auf Markttrends reagieren und kommerzielle Alleinstellungsmerkmale (USP) entwickeln zu können. Das Architekturmuster Service Oriented Architecture (SOA) hielt im Laufe der 2010er Jahre Einzug bei vielen Gesellschaften und konnte die technische Entkopplung von den monolithischen Passenger Service Backends weiter vorantreiben. Swiss International Air Lines führte z.B. im Zuge ihrer Migration von PARS auf Amadeus Altéa 2016 ein zentrales Middleware-Konzept ein mit Aurea Actional Service Broker und TIBCO EMS für Messaging.

Software Architecture
Style: Service Oriented Architecture

Die Entwicklung der letzten Jahre mündete schliesslich konsequenterweise in das Cloud Computing Modell. Neben dem Wunsch nach effizientem, skalierbarem Betrieb und langfristigen Kosteneinsparungen beim Hosting spielt auch der Wunsch nach höchstmöglicher Modularität der funktionalen Komponenten eine immer grössere Rolle. Der Provider Amadeus selber schaffte es schliesslich, die Jahrzehnte währende Abhängigkeit vom TPF Mainframe zu überwinden. Die Systeme wurden Schritt für Schritt modularisiert auf einer Linux-Cluster Infrastruktur.

Software Architecture
Style: Cloud Computing

Neuste Technologie-Trends spielen auch in der Gegenwart eine wesentliche Rolle. Dazu zählen das Datenmanagement mit Lambda-Architektur und Data-Driven Operations mit Hilfe von Machine Learning/KI (Beispiel: SWISS/Lufthansa und die Operation Decision Support Suite).
IT-Architektur unterstützt diese Entwicklung weiterhin mit Taktiken und Strategien und stellt so die effiziente Integration von Neuentwicklungen in die existierende Systemlandschaft sicher.

Beitrag teilen

Stefan Wellhöner & Markus Hüppi

Stefan Wellhöner arbeitet als Domain Architect bei Swiss International Air Lines und Markus Hüppi ist IoT Architect bei der Belimo Automation AG. Zusammen bloggen sie aus dem Unterricht des CAS Software Architecture. Das Integrieren von Legacy-System in moderne Architekturen und Systeme beschäftigt die Autoren täglich. Bei Stefan sind es Mainframes, die mit Machine Learning interagieren sollen, bei Markus geht es um die Integration von bestehenden Geräte in die IoT Umgebung. Beides impliziert interessante Anforderungen an die Architektur der Systeme.

Alle Beiträge ansehen von Stefan Wellhöner & Markus Hüppi →

Schreibe einen Kommentar