Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G


Jump to: navigation, search

High-Level Architecture

4,522 bytes added, 20:51, 13 January 2017
{{Official Core Development Effort}}
{{infobox subsystem
|description = Implementing support for the High Level Architecture to modularize FlightGear
|status = Under active development (2009-2016)
|developers = Mathias Fröhlich[http://sourceforge.net/p/flightgear/mailman/message/23723508/][http://sourceforge.net/p/flightgear/mailman/message/22914687/], James Turner[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39693.html], Stuart Buchanan[http://sourceforge.net/p/flightgear/mailman/message/34600516/], Richard Harrison [http://sourceforge.net/p/flightgear/mailman/message/34632142/]
| changelog =
* {{Git File History|project=flightgear|path=/src/Network/HLA}}
# 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.
As A good overview of late 2015, Stuart has started work on re-architecting parts of FlightGear to use how the HLA, though this is expected to architecture works can be a multi-year projectfound here http://www. Anyone interested in the current status of development should subscribe to the Flightgear -devel mailing listpitch.se/images/files/tutorial/TheHLAtutorial.pdf.
{{FGCquote|1= For those looking for =Design== The planned overall design is as follows:* We intend to use OpenRTI as the underlying RTI. This is an open source IEEE 1516 standard RTI, written by Mathias Fröhlich and available from https://sourceforge.net/projects/openrti/.* Mathias has also written an open source toolkit to act as an interface library, with a summary working name of SimKit. This sits on top of the RTI and simplifies interfacing with the RTI massively. It also has excellent Python integration, making it very easy to write scripted Federates. Using [[SimKit]], the integration point is within the FlightGear code (rather than SimGear), in particular the code under $FG_SRC/Network/HLA. ==Federate Object Model== A key part of the design is writing the Federation Object Model (FOM), which defines the following PDF provides objects and updates that are published by the RTI. While it might at first glance seem a useful overviewgood idea to use the FOM to share the internal property tree across multiple federates, this is probably the wrong way to use HLA as the granularity is too low <ref>https: http//sourceforge.net/p/flightgear/mailman/message/34795859/</ref><ref>https://wwwsourceforge.pitchnet/p/flightgear/mailman/message/34803436/</ref><ref>https://sourceforge.senet/imagesp/flightgear/mailman/message/34794675/</ref> and it's likely to lead to synchonization issues. Instead, we'll need to make explicit decisions about the data models to communicate. The FOM is a set of XML filesin [https:/tutorial/TheHLAtutorialsourceforge.pdfnet/p/flightgear/fgdata/ci/next/tree/HLA/ fgdata/HLA/] The orientation data in the FOM (SGOrientationWGS84) are Quaternions ([https://en.wikipedia.org/wiki/Quaternion https://en.wikipedia.org/wiki/Quaternion]), and those are the i,j,k values. From memory, the orientation is relative to a earth-centered-frame, and there are functions in SimGear to convert to heading/pitch/roll in combination with the object's position.<ref> {{cite web |2url = http://forum.flightgear.org/viewtopic.php?p=280098#p280098 | title = <nowiki>Re: HLA </nowiki> | author = <nowiki>stuart</nowiki> | date = Mar 21st, 2016 | added = Mar 21st, 2016 | script_version = 0.25 }}</ref> <ref>{{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/3463221434963798/ | title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Nov 19thMar 24th, 20152016 | added = Nov 19thMar 24th, 20152016 | script_version = 0.2325
{{FGCquote|1= IRichard'm hoping that OpenRTI will provide s [[Emesary]] system would also probably work quite well with the infrastructure for the data sharing so I don't need HLA FOM to worry about shared memory etc. As I mentioned previously, I'm planning to use an IEEE 1516 standard RTI, of which OpenRTI is give us a conveniently free implementation. AFAICT this is one of the main standards way for distributed simulation communication (the models to communicate with other being DIS)models. I think that will address the communications side of the equation, and OpenRTI can work both as a local RTI and over a network. It's also got a robust logical time implementation, and the ability to clock the simulation.|2= <ref> {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/3463214234985731/ | title = <nowiki>Re: [Flightgear-devel] HLA developmentsMessage passing interface for Nasal</nowiki> | author = <nowiki>Stuart BuchananRichard Harrison</nowiki> | date = Nov 19thApr 1st, 20152016 | added = Nov 19thApr 1st, 20152016 | script_version = 0.2325
{{FGCquote==Federates==|1= HLA is really intended to operate at a much higher level of granularity Federates can be written in most languages, but SimKit provides very good hooks for writing them in C++ and pass objects around a distributed simulationPython. The use-case I'm working on at  For some Subsystems split off from the moment passes existing FlightGear source, it's fairly easy to create an AI instance as an object (executable with position, velocity, accelerations, model its own property tree<ref>https://sourceforge.net/p/flightgear/mailman/message/34632142/</ref> and have shared C++ code to be displayed)map FOM objects to property values. How a HLA Federate maps that data internally However, this is an implementation decision. There shouldn't be any race conditions because detail - the whole point of HLA and the FOM is that it makes no assumptions are made about how what Federates do with the data is used or mapped. At present Regarding weather, I'm not thinking that in a HLA will /RTI context the way to do this would be used as to have a mechanism weather engine as an RTI Federate. This would run any required weather simulation, and pass (very) local weather conditions to provide each of the aircraft/tower/windsock in the simulation, plus publish position information on clouds for use by visualiation engines.<ref>{{cite web |url = https://sourceforge.net/p/flightgear/mailman/message/35595300/ |title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a shared property tree across multiple Federatesnew Development Model for FlightGear AI Traffic </nowiki> |author = <nowiki> Stuart Buchanan </nowiki> |date = Jan 10th, 2017 |added = Jan 10th, 2017 |script_version = 0. I think 40 }}</ref> ==Current Status ==Last updated: (13/01/2017) Stuart is cautiously optimistic that's the wrong way he may be able to use provide the start of a HLA. Instead you make explicit decisions about implementation quite soon, as one of the data models you will communicateblocking factors may be resolved soon. The other reason <ref>{{cite web |url = https://sourceforge.net/p/flightgear/mailman/message/35595300/ |title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development Model for FlightGear AI Traffic </nowiki> |author = <nowiki> Stuart Buchanan </nowiki> |date = Jan 10th, 2017 |added = Jan 10th, 2017 |script_version = 0.40 }}</ref>  Currently, there is some very old HLA isn't support in SimGear. This is very out of date and should be ignored. Stuart has HLA support using the latest OpenRTI and SimKit working on a good choice local build, but is waiting for Mathias to do with simulation clockingofficially publish his SimKit before he pushes his changes. I'm still getting my head around this properly So all of the following is local-only, but included here for information. The Flightgear core currently supports HLA as follows.* SimKit integration, reading the overall model is one where SimKit FOM and connecting to an OpenRTI RTI.* Instantiating MP AI objects so users can view objects published over the simulation clock RTI by other Federates. This is advancedcurrently somewhat unsatisfactory as it overloads the MP code, where really these objects are more basic.* Pick up Environment Objects for this instance and use them to set the instance local METAR string for weather generation. {{See also|FGTraffic}}We currently have the following other Federates:* '''fgogel''' - An AI model written in python the updates and publishes changes over to the RTI . Part of SimKit, but handy nevertheless!* '''fgtraffic''' - to run an AI Scenario externally to the FG Core* '''fgmetar''' - written in python that will retrieves the closest METAR station for other published Federates and publishes the METAR for them to pick up. This could be picked expanded to provide [[FGPythonSys#Weather_Simulation|a general Weather Engine]]. Stuart now has the [[AI]] Manager working as an external binary, and publishing updates over the RTI which are displayed as MP Aircraft. Stuart has created a little python script that looks for objects with locations being published over the RTI and publishes the closest METAR to them, then modified FG to pick up by other instances the appropriate METAR string for this instance and use it as the real-time input for weather generation.  The python script could be fairly easily enhanced into a more substantial weather engine allowing a single coherent weather environment to be used across the simulation. Stuart also started work modifying [[FGViewer]] so that it works with SimKit. This is a fairly big deal and quite a bit of fairly dull plumbing work but would allow us at least have a view of the next clock advancesimulation entirely separate from the running simulation.|2= <ref> {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/3479585934877355/ | title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API (was Re: A FGPythonSys implementation: ...)HLA Status Update 23/2/2016</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Jan 26thFeb 23rd, 2016 | added = Jan 26thFeb 23rd, 2016 | script_version = 0.2325
{{FGCquote|1= For now I've only added the code but not used it anywhere. This Separately, Erik has the advantage been doing some preparatory work suitable for supporting HLA in JSBSim by adopting so called PropertyObjects to hopefully get rid of getting tied properties (compilerhttp://sourceforge.net/p/jsbsim/mailman/message/34720784/) errors early before new functionality gets added. Most of the code remains the same, even the Tie functions are still there and for stand alone programs they are perfectly fine.
But JSBSim will be used in a HLA environment soon because that's where FlightGear is heading and for that the new code is useful (accessing tied properties from multiple sources).|2= {{cite web | url = http://sourceforge.net/p/jsbsim/mailman/message/34720784/ | title = <nowiki>[Flightgear-devel] (JSBSim) Standalone Properties</nowiki> | author = <nowiki>Erik Hofman<references/nowiki> | date = Dec 25th, 2015 }}}}
== Related ==
For additional information, please see:
* [[Technical_Reports#A_New_Architecture_for_FlightGear_Flight_Simulator]]
* [[Decoupling the AI Traffic System]] (currently work-in progress, highlights the limitations of the current AI system related to distributed/multi-instance and multiplayer usage)* [[FlightGear HLA support (High Level Architecture)]](outdated, documenting the original HLA infrastructure code)
* [[FlightGear CIGI Support (Common Image Generator Interface)]].
* [[Modularizing, parallelizing and distributing FlightGear]] (background info/discussions pre-dating HLA adoption in FlightGear)* [[Distributed Interactive Simulation]] (DIS specific review of the FlightGear multiplayer system/protocol and its limitations, which can be addressed via HLA)
== External links ==

Navigation menu