Fr/High-Level Architecture: Difference between revisions

Jump to navigation Jump to search
Traduction partielle
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 grands avantages à cela par rapport à une simulation monolithique (par exemple FlightGear V3.6) :
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.


<s>Rather than have the entire simulation within a single executable, the simulation is split into different [[Federate|Federates]], which interact with each other by a ''Run-Time Infrastructure'' (''RTI'', a message bus that handles serialization of messages, events and objects), with federates typically running in their own threads/processes and each federate process having access to the full virtual process address space provided by the OS instead of having to share it with other subsystems (i.e. 32 bit platforms may make better use of virtual RAM that way).</s>
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]


<s>There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6):</s>
==Conception==
# It provides a robust environment to make the simulator multi-threaded, taking advantage of computers with multiple cores, or indeed running different parts of the simulation on different computers (including even different platforms and operating systems).
# It allows us to split out parts of the simulator such as [[AI]] (by [[Decoupling the AI Traffic System]]), the [[FDM]], [[Nasal]] scripting <ref>http://forum.flightgear.org/viewtopic.php?p=265721#p265721</ref> and [[Supporting multiple renderers|Renderer]] from each other and less time-critical sub-systems such as [[Advanced weather|weather]] so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced [[How the Nasal GC works|Nasal GC]] impact on frame rate).
# It provides a very good framework to allow anyone to create components that interact with FlightGear using programming languages other than C/C++ (think Ada, Java, Python etc), which may be running in their own threads, and reside in separate binaries<ref>http://sourceforge.net/p/flightgear/mailman/message/34196458/</ref>, which will be also easier to debug/troubleshoot (think regression testing, i.e. running a self-contained subsystem in a dedicated gdb/valgrind session), without having to know how to modify/patch and rebuild FlightGear.
 
A good overview of how the HLA architecture works can be found here [https://pitchtechnologies.com/wp-content/uploads/2020/06/TheHLAtutorial.pdf http://www.pitchtechnologies.com/wp-content/uploads/2014/04/TheHLAtutorial.pdf]
 
==Design==


The planned overall design is as follows:
The planned overall design is as follows:
745

edits

Navigation menu