Fr/High-Level Architecture

Version traduite le 20 décembre 2022

HLA Support

Screenshot showing HLA prototype at LOWI
Started in	05/2009
Description	Implementing support for the High Level Architecture to modularize FlightGear
Contributor(s)	Mathias Fröhlich[1][2], James Turner[3], Stuart Buchanan[4], Richard Harrison [5]
Status	stalled (active 2009-2016)
Changelog	/src/Network/HLA /simgear/hla

High-Level Architecture (HLA) est une architecture logicielle à usage général destinée aux systèmes de simulation informatique distribués.

Au lieu d'avoir toute la simulation dans un seul exécutable (architecture monolithique), la simulation est répartie en différents modules fédérés (Federate), qui interagissent les uns avec les autres par une infrastructure d'exécution RTI (Run-Time Infrastructure, un bus de messages qui gère la sérialisation des messages, des événements et des objets). Les modules fédérés sont généralement exécutés dans leurs propres threads/processus et chaque processus fédéré a accès à l'intégralité de l'espace d'adressage du processus virtuel fourni par le système d'exploitation, au lieu d'avoir à le partager avec d'autres sous-systèmes (c'est-à-dire que les plates-formes 32/64 bits peuvent utiliser la RAM virtuelle de manière optimale).

Il y a trois principaux avantages à cela par rapport à une simulation monolithique (par exemple FlightGear V3.6) :

1. Il met en oeuvre un environnement robuste pour rendre le simulateur multi-thread, en tirant parti des ordinateurs multi-cœurs, ou en exécutant différentes parties de la simulation sur différents ordinateurs (y compris sur différentes plates-formes et systèmes d'exploitation).
2. Cela permet aussi de répartir des parties du simulateur telles que l'IA (en découplant le système de trafic IA), le FDM, les scripts Nasal, le rendu des uns des autres, et des sous-systèmes moins critiques tels que la météo, afin que nous ayons un résultat cohérents (et peut-être même amélioré) des fréquences d'images (c'est-à-dire un impact réduit de Nasal GC sur la fréquence d'images).
3. Il fournit un très bon environnement pour permettre à quiconque de créer des composants qui interagissent avec FlightGear en utilisant des langages de programmation autres que C/C++ (pensez Ada, Java, Python, etc.). Ceux-ci peuvent s'exécuter dans leurs propres threads et résident dans des binaires séparés, qui seront certainement plus faciles à maintenir (pensez aux tests de régression, c'est-à-dire exécuter un sous-système autonome dans une session gdb/valgrind dédiée), sans se soucier de comment modifier/corriger et recompiler FlightGear.

Un bon aperçu du fonctionnement de l'architecture HLA est disponible ici (en anglais) : http://www.pitchtechnologies.com/wp-content/uploads/2014/04/TheHLAtutorial.pdf

Conception

La conception globale entrevue est la suivante :

• Intention d'utiliser OpenRTI comme RTI sous-jacent. Il s'agit d'un RTI standard IEEE 1516 open source, écrit par Mathias Fröhlich et disponible sur https://sourceforge.net/projects/openrti/.
• Mathias a également développé une boîte à outils open source pour agir comme une bibliothèque d'interface, avec pour nom de code SimKit. Cela se trouve au-dessus du RTI et simplifie grandement l'interfaçage avec le RTI. L'intégration Python est également excellente, ce qui facilite l'écriture de scripts pour les modules fédérés. Simkit est disponible sur : https://sourceforge.net/projects/sim-kit/

En utilisant SimKit, le point d'intégration se trouve dans le code FlightGear au lieu de SimGear), en particulier le code se trouvant dans $FG_SRC/Network/HLA.

Federate Object Model (FOM)

Un élément clé de la conception consiste à écrire le Federation Object Model (FOM), qui définit les objets et les mises à jour publiés par le RTI. Bien qu'il puisse sembler à première vue une bonne idée d'utiliser le FOM pour partager l'arbre de propriétés interne entre plusieurs modules fédérés, c'est probablement la mauvaise façon d'utiliser HLA car la granularité est trop faible et cela risque d'entraîner des problèmes de synchronisation. Au lieu de cela, nous devrons prendre des décisions explicites sur la communication des modèles de données.

Le FOM est un jeu de fichiers XML dans FGData/HLA.

Les données d'orientation dans le FOM (SGOrientationWGS84) sont des Quaternions (https://en.wikipedia.org/wiki/Quaternion), et ce sont les valeurs i,j,k. De mémoire, l'orientation est relative à un cadre centré sur la Terre, et il existe des fonctions dans SimGear pour convertir en cap/tangage/roulis en les combinant avec la position de l'objet.

Le système Emesary de Richard fonctionnerait également très bien avec le HLA FOM pour nous donner un moyen, pour les modèles, de communiquer avec d'autres modèles.

Références

Modules fédérés

Les modules fédérés peuvent être écrits dans la plupart des langages, mais SimKit a des atomes crochus pour les écrire en C++ et Python.

Pour certains sous-systèmes séparés de la source FlightGear existante, il est assez facile de créer un exécutable avec sa propre arborescence de propriétés et d'avoir du code C++ partagé pour associer les objets FOM aux valeurs de propriété. Cependant, il s'agit d'un détail d'implémentation - tout l'intérêt de HLA et du FOM est qu'il ne fait aucune hypothèse sur ce que les modules fédérés font avec les données.

En ce qui concerne la météo, dans un contexte HLA/RTI, la façon de procéder serait d'avoir un moteur météorologique en tant que module fédéré RTI. Cela exécuterait toute simulation météorologique requise et transmettrait les conditions météorologiques (très) locales à chacun des aéronefs / tours / manches à air dans la simulation, en plus de publier des informations de position sur les nuages à utiliser par les moteurs de visualisation.

Statut actuel

Dernière mise à jour (10/2022)

Stuart Buchanan a fait un travail de prototypage pour fédérer FlightGear au sein de HLA il y a quelques années, en utilisant OpenRTI et SimKit. Il devrait y avoir une référence dans les archives de la liste de diffusion si vous voulez regarder. C'est certainement possible, et un cas d'utilisation était de découpler l'IG (générateur d'images) et de permettre au travail de commencer à utiliser VSG (vulcan scene graph) tout en continuant à prendre en charge OSG.

FlightGear est régulièrement utilisé comme générateur d'images (IG) découplé pour des projets académiques et industriels, grâce aux nombreuses options d'E/S flexibles disponibles. Ils ne sont tout simplement pas très médiatisés.

Il y a eu des travaux sur la façon dont nous pourrions passer à VulkanSceneGraph, mais la dernière fois que j'ai entendu dire qu'il y avait des problèmes techniques que nous ne pouvions pas surmonter.

Stuart est prudemment optimiste et il pourrait être en mesure de fournir le début d'une mise en œuvre HLA assez rapidement, car l'un des facteurs de blocage pourrait être résolu bientôt.

Actuellement, il existe un support HLA très ancien dans SimGear. Ceci est obsolète et doit être ignoré.

Stuart prend en charge HLA en utilisant les derniers OpenRTI et SimKit travaillant sur une version locale, mais attend que Mathias publie officiellement son SimKit avant de mettre en avant ses modifications. Ainsi, tout ce qui suit est uniquement local, mais inclus ici à titre d'information.

Le noyau Flightgear prend actuellement en charge HLA comme suit.

• Intégration SimKit, lecture du SimKit FOM et connexion à un RTI OpenRTI.
• Instanciation d'objets MP AI afin que les utilisateurs puissent visualiser les objets publiés sur le RTI par d'autres modules fédérés. Ceci est actuellement quelque peu insatisfaisant car il surcharge le code MP, où en réalité ces objets sont plus basiques.
• Choisissez des objets d'environnement pour cette instance et utilisez-les pour définir la chaîne METAR locale pour la génération de la météo

voir également FGTraffic.

Nous avons actuellement les autres modules fédérés suivants :

• fgogel - Un modèle d'IA écrit en python est publié sur le RTI. Fait partie de SimKit, mais néanmoins pratique !
• fgtraffic - pour exécuter un scénario d'IA en externe au FG Core
• fgmetar - écrit en python qui identifie la station METAR la plus proche pour les autres modules fédérés publiés et distribue le METAR pour qu'ils puissent le récupérer. Cela pourrait être étendu pour fournir un moteur météorologique général.

Stuart a maintenant le IA Manager fonctionnant comme un binaire externe et publiant des mises à jour sur le RTI qui sont affichées comme MP Aircraft. Stuart a créé un petit script python qui recherche des objets dont les emplacements sont publiés sur le RTI et publie le METAR le plus proche d'eux, puis a modifié le FG pour récupérer la chaîne METAR appropriée pour cette instance et l'utiliser comme entrée en temps réel pour la génération de la météo .

Le script python pourrait être assez facilement amélioré en un moteur météorologique plus substantiel permettant d'utiliser un seul environnement météorologique cohérent tout au long de la simulation. Stuart a également commencé à modifier FGViewer pour qu'il fonctionne avec SimKit. C'est un gros problème et un travail de plomberie assez ennuyeux, mais cela nous permettrait au moins d'avoir une vue de la simulation entièrement séparée de la simulation en cours.

Par ailleurs, Erik a effectué un travail préparatoire adapté à la prise en charge de HLA dans JSBSim en adoptant ce que l'on appelle PropertyObjects pour, espérons-le, se débarrasser des propriétés liées (http://sourceforge.net/p/jsbsim/mailman/message/34720784/).

A ce propos

Pour plus d'informations, veuillez consulter :

• Technical_Reports#A_New_Architecture_for_FlightGear_Flight_Simulator
• Decoupling the AI Traffic System (actuellement en cours de réalisation, met en évidence les limites du système d'IA actuel lié à l'utilisation distribuée/multi-instance et multijoueur).
• FlightGear HLA support (High Level Architecture) (obsolète, documentant le code d'infrastructure HLA d'origine)
• FlightGear CIGI Support (Common Image Generator Interface).
• Modularizing, parallelizing and distributing FlightGear (informations de fond/discussions antérieures à l'adoption de HLA dans FlightGear)
• Distributed Interactive Simulation (Examen spécifique au DIS du système/protocole multijoueur FlightGear et de ses limites, qui peuvent être résolues via HLA)

Liens externes

• High-level architecture (simulation) sur Wikipedia