Connexion des pièces :intégration d'un composant portable conforme à FACE à un environnement de simulation

Tout a commencé il y a quelques années lorsque le comité permanent de l'atelier d'intégration de l'environnement futur des capacités aéroportées (FACE™) a publié l'exemple d'archétype de source légère d'avionique de base (BALSA) d'une architecture de mise en œuvre de référence FACE. BALSA est une application logicielle contenant des unités de conformité (UoC) alignées sur la norme technique FACE. Son objectif est de fournir un exemple de travail aux fournisseurs potentiels de logiciels FACE et aux intégrateurs de logiciels FACE. Il est également utilisé comme mécanisme d'enseignement sur la façon dont les unités de portabilité (UoP), les UoC et les interfaces de programmation d'applications (API) FACE peuvent être réalisées sur un système potentiel.

BALSA a fourni sa propre implémentation simple d'interface de services de transport (TSS). L'implémentation de TSS fonctionne bien. Cependant, l'un des inconvénients est qu'il n'y a pas d'outils disponibles qui montrent ce qui se passe - ce qui est essentiel lorsque les choses ne se passent pas comme prévu. Nous avons décidé de voir à quel point il serait facile de remplacer le TSS BALSA par un TSS basé sur le service de distribution de données (DDS), en particulier le RTI Connext DDS (https://www.rti.com/industries/face).

Nous avons été surpris de voir à quel point il était facile de remplacer la couche TSS. Il ne nous a fallu que quelques heures pour remplacer le BALSA TSS par le RTI TSS. C'était aussi la preuve que la portabilité, qui est l'un des objectifs du standard FACE, fonctionne bien. Avec les couches TSS mises à jour, nous avons pu utiliser les outils DDS. De plus, nous avons également reçu l'accès pour nous connecter à d'autres applications DDS, ce qui facilite l'intégration avec d'autres composants.

Lors de l'événement BITS de la réunion des membres de la FACE en juin 2017, cinq sociétés - RTI, Honeywell, TES-SAVi, Wind River et Mercury Systems - ont collaboré pour intégrer et combiner des composants individuels alignés sur FACE afin de démontrer la plausibilité des avantages d'une intégration rapide du Référentiel Technique FACE 2.1. L'article de FACE NAVAIR TIM intitulé « FACE Cross-Integration Successes – Honeywell, RTI, TES-SAVi, Wind River and Mercury Systems » partage les résultats :(https://www.opengroup.us/face/documents.php?action =afficher&dcat=70&gdid=18823)

Un autre projet consistait à utiliser le RTI TSS avec Harris FliteScene. La carte numérique Harris FliteScene est un logiciel de cartographie numérique mobile hautes performances, éprouvé au combat et riche en fonctionnalités qui fournit une connaissance avancée de la situation pour les conditions les plus exigeantes auxquelles sont confrontés les équipages civils et militaires. FliteScene prend en charge des fonctions avancées de détection du terrain et d'évitement d'obstacles pour assurer la sécurité des équipages pendant les missions, et les modes de vision synthétique 3D de FliteScene facilitent la navigation dans les pires conditions. FliteScene a été intégré aux réseaux tactiques modernes, tels que Link 16 et ANW2, fournissant une image opérationnelle commune en temps réel.

Ce fut également un bon test pour voir à quel point il est facile de porter un composant portable conforme à FACE pour utiliser le RTI TSS. De Harris, nous avons reçu les fichiers objets et le modèle de données. Les étapes d'intégration avec le TSS incluent :

• Créer IDL à partir des fichiers d'en-tête DataModel
• Générer du code spécifique aux types DDS et TSS à l'aide des outils RTI
• Créer un fichier de configuration RTI TSS
• Liez les fichiers objet FliteScene avec RTI TSS et tapez le code spécifique

C'était étonnamment facile à intégrer et en quelques jours seulement, nous avons eu un prototype en marche. FliteScene a plusieurs messages d'entrée, dont la plupart sont destinés à contrôler la mise en page (par exemple, zoom, sous-couche, superposition). La carte est centrée en fonction de la position actuelle qui est fournie par le message de mise à jour de position. Il existe plusieurs sources qui peuvent être utilisées pour fournir des emplacements. Pour contrôler facilement les fonctionnalités de la carte, nous avons créé une interface utilisateur simple dans LabView à l'aide de la boîte à outils RTI DDS LabView (https://www.rti.com/products/dds/labview). Comme tout est basé sur un cadre de connectivité commun, DDS, tout s'emboîte et fonctionne comme des pièces de puzzle.

Avec FliteScene, nous cherchions ce que nous pourrions utiliser pour fournir des informations sur la carte. L'une des idées était de le combiner avec un environnement de simulation. VT MAK, leader mondial de la modélisation et de la simulation, propose un produit (VR-Exchange) qui permet la transformation et le pontage de protocoles. VR-Exchange est un traducteur universel pour les simulations distribuées et son architecture ouverte signifie que vous pouvez développer des courtiers personnalisés pour d'autres normes de données telles que DDS.

L'interface de services de transport spécifiée dans la norme technique FACE prend en charge le transport de données à l'aide de différentes normes industrielles, notamment DDS.

Étant donné que les deux côtés prennent en charge DDS en tant que protocole de communication, nous avons décidé de voir à quel point il serait facile de connecter les deux côtés ensemble. Le plan était de connecter un F18 HLA Federate à FliteScene, un composant portable conforme à FACE. Il s'est avéré qu'il était assez simple de faire fonctionner cela.

L'utilisation de DDS comme transport TSS permet non seulement la portabilité entre les composants conformes à FACE, mais permet également la connectivité à d'autres applications utilisant DDS. Pour Flitescene, nous avons utilisé le RTI TSS basé sur RTI Connext (https://www.rti.com/industries/face). Du côté HLA, nous avons utilisé le courtier DDS VR_Exchange qui mappe les données du côté HLA aux sujets DDS. Le composant FACE utilise un modèle de données spécifique qui est différent de celui utilisé par le F18 Federate. Les données doivent être mappées entre les deux modèles de données. Deux approches sont possibles, notamment :

• Modifiez le courtier DDS VR-Exchange pour publier des sujets, qui seront compris par le composant FACE.
• Demandez à VR-Exchange de publier des sujets en fonction de la définition du PDU DIS et d'utiliser des services de routage pour faire le lien entre les sujets.

Pour notre preuve de concept, nous avons utilisé cette dernière approche. Service de routage nécessaire pour relier la rubrique simpleBaseEntity à la rubrique d'emplacement utilisée par FliteScene. Outre les différents types de données, les deux parties ont également utilisé des formats différents. Les données provenant de HLA étaient en coordonnées géocentriques alors que FliteScene s'attend à ce qu'elles soient en Lat/Long. Nous avons configuré les services de routage pour cartographier les coordonnées à l'aide d'une bibliothèque de transformation personnalisée qui effectue la traduction entre les coordonnées. Nous nous sommes retrouvés avec l'architecture suivante :

Pour plus d'informations sur le rapprochement HLA et DDS, RTI est en partenariat avec le National Center for Simulation (NCS) organisera un séminaire, « DDS for Simulation:How the Connectivity Framework is Meeting Interoperability Challenges », le 10 avril. Pour plus d'informations, y compris comment s'inscrire à cet événement gratuit, veuillez visiter :https://www. simulationinformation.com/news/ncs-real-time-innovations-event-industry-10-apr-2018