High-Level Architecture: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:
|started= 05/2009
|started= 05/2009
|description = Implementing support for the High Level Architecture to modularize FlightGear
|description = Implementing support for the High Level Architecture to modularize FlightGear
|status = Under active development (2009-2013)
|status = Under active development (2009-2016)
|developers = Mathias Fröhlich, James Turner[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39693.html], Stuart Buchanan[http://sourceforge.net/p/flightgear/mailman/message/34600516/]
|developers = Mathias Fröhlich, James Turner[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39693.html], Stuart Buchanan[http://sourceforge.net/p/flightgear/mailman/message/34600516/]
| changelog =  
| changelog =  

Revision as of 14:21, 30 December 2015

HLA Support
Screenshot showing HLA prototype at LOWI
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, James Turner[1], Stuart Buchanan[2]
Status Under active development (2009-2016)
Changelog


High-Level Architecture (HLA) is a general purpose architecture for distributed computer simulation systems.

Rather than have the entire simulation within a single executable, the simulation is split into different 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).

There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6):

  1. 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).
  2. It allows us to split out parts of the simulator such as AI (by Decoupling the AI Traffic System), the FDM, Nasal scripting [1] and Renderer from each other and less time-critical sub-systems such as weather so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced Nasal GC impact on frame rate).
  3. 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[2], 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 of late 2015, Stuart has started work on re-architecting parts of FlightGear to use HLA, though this is expected to be a multi-year project. Anyone interested in the current status of development should subscribe to the Flightgear -devel mailing list.

Cquote1.png For those looking for a summary of HLA, the following PDF provides a useful overview: http://www.pitch.se/images/files/tutorial/TheHLAtutorial.pdf
— Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I'm hoping that OpenRTI will provide the infrastructure for the data sharing so I don't need to worry about shared memory etc. As I mentioned previously, I'm planning to use an IEEE 1516 standard RTI, of which OpenRTI is a conveniently free implementation. AFAICT this is one of the main standards for distributed simulation communication (the other being DIS). 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.
— Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png For now I've only added the code but not used it anywhere. This has the advantage of getting (compiler) 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).
— Erik Hofman (Dec 25th, 2015). [Flightgear-devel] (JSBSim) Standalone Properties.
(powered by Instant-Cquotes)
Cquote2.png

For additional information, please see:


External links