Die Teile verbinden:FACE-konforme tragbare Komponente in eine Simulationsumgebung integrieren

Alles begann vor einigen Jahren, als der ständige Ausschuss des Future Airborne Capability Environment (FACE™) Integrationsworkshops das Basic Avionics Lightweight Source Archetype (BALSA)-Beispiel einer FACE-Referenzimplementierungsarchitektur veröffentlichte. BALSA ist eine Softwareanwendung, die Units of Conformance (UoCs) enthält, die auf den technischen Standard von FACE ausgerichtet sind. Sein Zweck besteht darin, potenziellen FACE-Softwarelieferanten und FACE-Softwareintegratoren ein funktionierendes Beispiel zu bieten. Es wird auch als Lehrmechanismus verwendet, wie Units of Portability (UoPs), UoCs und FACE Application Programming Interfaces (APIs) auf einem potenziellen System realisiert werden können.

BALSA hat eine eigene einfache Transport Services Interface (TSS)-Implementierung bereitgestellt. Die TSS-Implementierung funktioniert gut. Einer der Nachteile ist jedoch, dass es keine Tools gibt, die einen Einblick in das Geschehen geben – was entscheidend ist, wenn die Dinge nicht wie geplant verlaufen. Wir haben uns entschieden, zu sehen, wie einfach es wäre, das BALSA TSS durch ein auf einem Data Distribution Service (DDS) basierendes TSS zu ersetzen, insbesondere RTI Connext DDS (https://www.rti.com/industries/face).

Wir waren überrascht, wie einfach es war, die TSS-Schicht zu ersetzen. Wir haben nur wenige Stunden gebraucht, um das BALSA TSS durch das RTI TSS zu ersetzen. Dies war auch ein Beweis dafür, dass die Portabilität, die eines der Standardziele von FACE ist, gut funktioniert. Mit den aktualisierten TSS-Layern konnten wir die DDS-Tools verwenden. Darüber hinaus haben wir auch Zugang zu anderen DDS-Anwendungen erhalten, was die Integration mit anderen Komponenten vereinfacht.

Auf der BITS-Veranstaltung der FACE-Mitgliederversammlung im Juni 2017 haben fünf Unternehmen – RTI, Honeywell, TES-SAVi, Wind River und Mercury Systems – zusammengearbeitet, um die einzelnen auf FACE ausgerichteten Komponenten zu integrieren und zu kombinieren, um die Plausibilität der Vorteile der schnellen Integration der Technischer FACE-Standard 2.1. Das FACE NAVAIR TIM Paper mit dem Titel „FACE Cross-Integration Successes – Honeywell, RTI, TES-SAVi, Wind River and Mercury Systems“ teilt die Ergebnisse:(https://www.opengroup.us/face/documents.php?action =show&dcat=70&gdid=18823)

Ein weiteres Projekt war die Verwendung des RTI TSS mit Harris FliteScene. Die Harris FliteScene Digital Map ist eine leistungsstarke, kampferprobte, funktionsreiche digitale Moving-Map-Software, die ein erweitertes Situationsbewusstsein für die anspruchsvollsten Bedingungen sowohl für zivile als auch für militärische Flugbesatzungen bietet. FliteScene unterstützt erweiterte Geländeerkennungs- und Hindernisvermeidungsfunktionen, um die Sicherheit der Besatzungen während der Missionen zu gewährleisten, und die synthetischen 3D-Sichtmodi von FliteScene helfen bei der Navigation durch die schlimmsten Bedingungen. FliteScene wurde in moderne taktische Netzwerke wie Link 16 und ANW2 integriert und bietet ein vollständiges gemeinsames Betriebsbild in Echtzeit.

Dies war auch ein guter Test, um zu sehen, wie einfach es ist, eine FACE-konforme tragbare Komponente für die Verwendung des RTI TSS zu portieren. Von Harris haben wir die Objektdateien und das Datenmodell erhalten. Die Schritte zur Integration mit dem TSS umfassen:

• Erstellen Sie IDL aus DataModel-Header-Dateien
• Generieren Sie typspezifischen DDS- und TSS-Code mit RTI-Tools
• RTI-TSS-Konfigurationsdatei erstellen
• Verknüpfen Sie FliteScene-Objektdateien mit RTI TSS und typspezifischem Code

Es war überraschend einfach zu integrieren und in nur wenigen Tagen hatten wir einen Prototyp am Laufen. FliteScene hat mehrere Eingabenachrichten, von denen die meisten das Layout steuern (z. B. Zoom, Underlay, Overlay). Die Karte wird basierend auf der aktuellen Position zentriert, die durch die Positionsaktualisierungsnachricht bereitgestellt wird. Es gibt mehrere Quellen, die verwendet werden können, um Standorte bereitzustellen. Um die Kartenfunktionen einfach zu steuern, haben wir mit dem RTI DDS LabView Toolkit (https://www.rti.com/products/dds/labview) eine einfache Benutzeroberfläche in LabView erstellt. Da alles auf einem gemeinsamen Konnektivitäts-Framework, DDS, basiert, passt alles zusammen und funktioniert wie Puzzleteile.

Bei FliteScene haben wir uns angesehen, was wir verwenden können, um Eingaben in die Karte zu geben. Eine der Ideen war, es mit einer Simulationsumgebung zu kombinieren. VT MAK, ein weltweit führendes Unternehmen im Bereich Modellierung und Simulation, bietet ein Produkt (VR-Exchange) an, das Protokolltransformation und -überbrückung ermöglicht. VR-Exchange ist ein universeller Übersetzer für verteilte Simulationen und seine offene Architektur ermöglicht es Ihnen, benutzerdefinierte Broker für andere Datenstandards wie DDS zu entwickeln.

Die im technischen Standard von FACE spezifizierte Transport Services Interface unterstützt den Datentransport unter Verwendung verschiedener Industriestandards, einschließlich DDS.

Da beide Seiten DDS als Kommunikationsprotokoll unterstützen, haben wir uns entschieden, zu sehen, wie einfach es wäre, die beiden Seiten miteinander zu verbinden. Der Plan war, ein F18 HLA Federate mit FliteScene, einer FACE-konformen tragbaren Komponente, zu verbinden. Es stellte sich heraus, dass es ziemlich einfach war, dies zum Laufen zu bringen.

Die Verwendung von DDS als TSS-Transport ermöglicht nicht nur die Portabilität zwischen FACE-konformen Komponenten, sondern ermöglicht auch die Konnektivität zu anderen Anwendungen, die DDS verwenden. Für Flitescene haben wir das RTI TSS basierend auf RTI Connext (https://www.rti.com/industries/face) verwendet. Auf der HLA-Seite haben wir den DDS-Broker VR_Exchange verwendet, der Daten von der HLA-Seite auf DDS-Themen abbildet. Die FACE-Komponente verwendet ein spezifisches Datenmodell, das sich von dem unterscheidet, das von der F18-Föderation verwendet wird. Die Daten müssen zwischen den beiden Datenmodellen abgebildet werden. Zwei Ansätze sind möglich, einschließlich:

• Ändern Sie den VR-Exchange DDS-Broker, um Themen zu veröffentlichen, die von der FACE-Komponente verstanden werden.
• Lass VR-Exchange Themen basierend auf der DIS-PDU-Definition veröffentlichen und Routing-Dienste verwenden, um zwischen den Themen zu überbrücken.

Für unseren Proof of Concept haben wir den letzteren Ansatz verwendet. Der Routingdienst, der benötigt wird, um das SimpleBaseEntity-Thema mit dem von FliteScene verwendeten Standortthema zu überbrücken. Neben den unterschiedlichen Datentypen verwendeten die beiden Seiten auch unterschiedliche Formate. Die Daten von HLA waren in geozentrischen Koordinaten, während FliteScene erwartet, dass sie in Lat/Long sind. Wir haben Routing-Services konfiguriert, um die Koordinaten mit einer benutzerdefinierten Transformationsbibliothek abzubilden, die die Übersetzung zwischen den Koordinaten durchführt. Am Ende haben wir die folgende Architektur erhalten:

Für weitere Informationen zur Überbrückung von HLA und DDS kooperiert RTI mit der National Center for Simulation (NCS) veranstaltet am 10. April ein Seminar mit dem Titel „DDS for Simulation:How the Connectivity Framework is Meeting Interoperability Challenges“. Weitere Informationen, einschließlich der Anmeldung zu dieser kostenlosen Veranstaltung, finden Sie unter:https://www. simulationinformation.com/news/ncs-real-time-innovations-event-industry-10-apr-2018