Luftfahrt Plug-and-Play: Die Herausforderung interoperabler Software für Flugzeuge

Von Daniel Ryan * 4 min Lesedauer

Anbieter zum Thema

Der Kauf von Militärflugzeugen ist sehr kompliziert, weil die Software an Bord nicht nur nahtlos zusammenarbeiten, sondern auch zukünftige, sich ständig ändernde Anforderungen erfüllen muss. Welche Lösungen es für diese Problematik gibt, zeigt der nachfolgende Beitrag.

Die Software an Bord eines (Militär-)Flugzeugs muss nicht nur nahtlos zusammenarbeiten, sondern auch zukünftige, sich ständig ändernde Anforderungen erfüllen. (Bild:  Gorodenkoff | Shutterstock)
Die Software an Bord eines (Militär-)Flugzeugs muss nicht nur nahtlos zusammenarbeiten, sondern auch zukünftige, sich ständig ändernde Anforderungen erfüllen.
(Bild: Gorodenkoff | Shutterstock)

Die Software an Bord eines (Militär-)Flugzeugs muss nicht nur nahtlos zusammenarbeiten, sondern auch zukünftige, sich ständig ändernde Anforderungen erfüllen. Beispielsweise fordert eine Dienststelle ein Programm mit bestimmten Einsatzbereichen und Missionskriterien an. Auf Grundlage dieser Anforderungen konkurrieren mehrere Flugzeugintegratoren miteinander. Diese stehen wiederum im Wettbewerb mit verschiedenen Subunternehmern um Plattformen, Subsysteme und Anwendungen innerhalb des Programms. Wenn das Programm ausgewählt wird, beginnt die Produktion in Etappen, je nach Bedarf. Schließlich führen sich weiterentwickelnde Einsatzerfordernisse zu einer Modernisierungsinitiative oder einem neuen Flugzeugprogramm – und der gesamte Prozess beginnt von vorne.

Wohin geht die Reise in dieser Branche?

Hier ist eine andere Sichtweise: Eine Dienstleistungsabteilung benötigt ein Programm, das bestimmte Kriterien für den Einsatzbereich und die Aufgaben erfüllt. Mehrere Flugzeugintegratoren bieten Lösungen für die ausgewählten Anforderungen an. Das klingt bekannt, aber jetzt wird es spannend. Mithilfe der modellbasierten Beschaffung könnten diese Integratoren auf frühere Programme zurückgreifen, um erfolgreiche Plattformen, Subsysteme und Anwendungen zu finden. Da sie Software nur nach dem Modular Open Systems Approach (MOSA) beschaffen, wäre es möglich, ein Flugsteuerungssystem aus Programm A und ein Cockpit-Anzeigesystem aus Programm B auszuwählen und beide mit einem kürzlich entwickelten Trägheitsnavigationssystem (INS) zu kombinieren, um die neuen Missionsanforderungen zu erfüllen.

In diesem Szenario wäre die gesamte Software in einem digitalen Zwilling verfügbar, sodass die Integratoren schnell ein Modell erstellen könnten. Zum Beispiel könnten sie Komponenten aus den bestehenden digitalen Zwillingen zusammen mit dem neuen INS-Subsystemmodell importieren, was ihnen erlaubt, die Leistung, Passform und Funktion des vorgeschlagenen Designs zu bewerten. Grundsätzlich ließe sich dieses Modell verwenden, um einen Prototyp zu erstellen und die erfolgreiche Software-Integration zu überprüfen.

In Bezug auf Projektzeit und Kosten wäre das ein enormer Vorteil. Durch modellbasierte Beschaffung und digitale Arbeitsabläufe dauert dieser Prozess nur Monate statt Jahre oder Jahrzehnte. Weil das Programm bewährte Hardware mit portabler, interoperabler, handelsüblicher Software (COTS) verwendet, könnte die Produktion schnell und ohne aufwendige Entwicklung oder Umrüstung beginnen.

Von der Theorie in die Praxis

Auch wenn diese Vision schon am Horizont auftaucht, sind noch ein paar technologische Schritte nötig, bis sie Realität wird. Beispielsweise muss die modellbasierte Systemtechnik (MBSE) die Komplexität und Wartung von Modellen reduzieren, Digital Twins müssen Integrationstests und Simulationen verbessern und Software für Flugzeuge muss offene Standards nutzen, die eine schnelle Softwareintegration und -wiederverwendung ermöglichen.

Interoperabilität mit offenen Standards

Zu all diesen Initiativen trägt RTI bei, allerdings fokussiert dieser Beitrag die offenen Standards, die Software-Portabilität und Interoperabilität ermöglichen. An erster Stelle steht der technische Standard „Future Airborne Capability Environment (FACE)” der Open Group. Der technische und geschäftliche Ansatz von FACE behandelt diese Themen anhand einer Reihe standardisierter Schnittstellen, Betriebsumgebungen und Geschäftspraktiken. Diese sind erforderlich, um Software-Portabilität und -Wiederverwendbarkeit über Flugplattformen hinweg zu gewährleisten. Konkret definiert FACE das Transport Services Segment (TSS). Es integriert den Datenfluss von Sensoren, E/A-Geräten oder anderen Knoten und stellt eine umfassende, eindeutige und konsistente Darstellung dieser Daten für Anwendungen bereit.

Die kommerzielle Implementierung des FACE Transport Services Segment (TSS) ist RTI Connext TSS, ein Software-Konnektivitätsframework mit zwei wichtigen Methoden für Interoperabilität:

  • Verwendung offener Standards für datenzentrierte Kommunikation und Datenübertragung über das Netzwerk.
  • Unterstützung der Verbindung von TSS-Herstellern über die FACE Transport Protocol Module (TPM)-Schnittstelle.

Offene Standards für die datenzentrierte Kommunikation und Datenübertragung

Mit Connext TSS können Entwickler von Komponenten ebenso wie Systemintegratoren sowohl den FACE Technical Standard als auch den Data-Distribution-Service-Standard ((DDS) nutzen. DDS definiert eine Schnittstelle für Publish-Subscribe-, Request-Reply- und RPC-Kommunikation und bietet eine lose gekoppelte, dezentrale Architektur mit Peer-to-Peer-Kommunikation für niedrige Latenzzeiten ohne Single Point of Failure. Es sind keine Broker oder Server erforderlich. Auf der Leitung nutzt DDS das Netzwerkprotokoll Real-Time Publish-Subscribe (RTPS), das ein Ökosystem von Implementierungen ermöglicht, die dank offener, weit verbreiteter Standards nahtlos miteinander kommunizieren.

Herstellerübergreifende TSS-Integration über die FACE-TPM-Schnittstelle

Eine konkrete Herausforderung im Zusammenhang mit dem FACE TSS ist, dass FACE die Wahl des Netzwerkprotokolls dem Software-Anbieter überlässt. Das bedeutet, dass konkurrierende TSS-Lösungen aufgrund ihrer Konzeption nicht miteinander kompatibel sind. Letztendlich hat FACE mit dem Transport Protocol Module (TPM) ein weiteres Software-Modul entwickelt, das für die Interoperabilität zwischen TSS erforderlich ist. Zum Zeitpunkt der Erstellung dieses Artikels hatten noch keine zwei Anbieter eine erfolgreiche Integration zwischen ihren TSS und TPMs demonstriert. Tatsächlich leitete RTI die Modular Open Systems Approach (MOSA) Risk Reduction Sub Task 1 (Task 3) von Advanced Technology International, die genau zu diesem Zweck die Reife des TPM-Standards bewerten sollte.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

FACE-TPM-Vision wird Realität

Im April dieses Jahres wurde zusammen mit On-Line Applications Research (OAR) eine hersteller- und protokollübergreifende Integrationslösung vorgestellt und die Unterschiede im Design zwischen TSS- und TPM-Implementierungen aufgezeigt. Diese Demonstration reduziert das Risiko für komplexe FACE-Programme, deren Design für Plattform-Upgrades oder Modernisierungen auf Basis unterschiedlicher Netzwerkprotokolle zukunftssicher sein muss, erheblich.

Es zeigt sich, dass die Implementierung offener Standards dazu beitragen kann, militärische Programme zukunftssicher zu machen. Connext TSS nutzt die Vorteile offener Standards von Grund auf und bietet jetzt zusätzlich den Vorteil einer bewährten, herstellerunabhängigen Integrationslösung mit FACE TPM. Connext TSS ist mit zertifizierter FACE-3.1-Konformität und COTS-DO-178C-DAL-A-Zertifizierung erhältlich und reduziert Kosten und Risiken für modulare, offene und sicherheitskritische Avioniksysteme. (se)

* Daniel Ryan ist Product Manager Aviation Products bei Real-Time Innovations.

(ID:50511174)