745
edits
mNo edit summary |
(Traduction partielle) |
||
| Line 23: | Line 23: | ||
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 [https://fr.wikipedia.org/wiki/Thread_(informatique) 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). | 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 [https://fr.wikipedia.org/wiki/Thread_(informatique) 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 | Il y a trois principaux avantages à cela par rapport à une simulation monolithique (par exemple FlightGear V3.6) : | ||
# 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 surdifférentes plates-formes et systèmes d'exploitation). | |||
# Cela permet aussi de répartir des parties du simulateur telles que l'[[AI|IA]] (en [[Decoupling the AI traffic system|découplant le système de trafic IA]]), le [[Fr/Modèles de dynamique de vol|FDM]], les [[Nasal scripting language|scripts Nasal]]<nowiki/>n le rendu des uns des autres, et des sous-systèmes moins critiques tels que la [[Advanced weather|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 [[How the Nasal GC works|Nasal GC]] sur la fréquence d'images). | |||
# 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 à déboguer/dépanner (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) : [https://pitchtechnologies.com/wp-content/uploads/2020/06/TheHLAtutorial.pdf http://www.pitchtechnologies.com/wp-content/uploads/2014/04/TheHLAtutorial.pdf] | |||
==Conception== | |||
= | |||
The planned overall design is as follows: | The planned overall design is as follows: | ||
edits