High-Level Architecture: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (http://sourceforge.net/p/flightgear/mailman/message/34632142/)
(Integration of relevant insta-quotes into main text and update on current status)
Line 25: Line 25:
# 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.
# 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 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.
A good overview of how the HLA architecture works can her found here http://www.pitch.se/images/files/tutorial/TheHLAtutorial.pdf.


{{FGCquote
==Design==
|1= For those looking for a summary of HLA, the following PDF provides a useful overview: http://www.pitch.se/images/files/tutorial/TheHLAtutorial.pdf
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34632214/
  | title  = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki>
  | author = <nowiki>Stuart Buchanan</nowiki>
  | date  = Nov 19th, 2015
  | added  = Nov 19th, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
The planned overall design is as follows:
|1= Depsite appearances moving the rendering to a seperate node/process is probably the easiest to implement as the inter module dependencies aren't that strong, or at least those that are strong can be shipped as a block update at the end of the simulation frame.
* 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/.
|2= {{cite web
* Mathias has also written an open source toolkit to act as an interface library, with a 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.
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34631875/
  | title = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki>
  | author = <nowiki>Richard Harrison</nowiki>
  | date  = Nov 19th, 2015
  | added  = Nov 19th, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
Using SimKit, the integration point is within the FlightGear code (rather than SimGear), in particular the code under src/Network/HLA.
|1= 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.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34632142/
  | title  = <nowiki>Re: [Flightgear-devel] HLA developments</nowiki>
  | author = <nowiki>Stuart Buchanan</nowiki>
  | date  = Nov 19th, 2015
  | added  = Nov 19th, 2015
  | script_version = 0.23
  }}
}}


{{FGCquote
==Federate Object Model==
|1= HLA is really intended to operate at a much higher level of granularity and pass objects around a distributed simulation. The use-case I'm working on at the moment passes an AI instance as an object (with position, velocity, accelerations, model to be displayed). How a HLA Federate maps that data internally is an implementation decision. There shouldn't be any race conditions because no assumptions are made about how the data is used or mapped. At present, I'm not thinking that HLA will be used as a mechanism to provide a shared property tree across multiple Federates. I think that's the wrong way to use HLA. Instead you make explicit decisions about the data models you will communicate. The other reason HLA isn't a good choice is to do with simulation clocking. I'm still getting my head around this properly, but the overall model is one where the simulation clock is advanced, and the instance the updates and publishes changes to the RTI that will be picked up by other instances at the next clock advance.
 
|2= {{cite web
A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updated that are published by the RTI. While it might at first glance seem a good 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 and it's likely to lead to synchonization issues . Instead we'll need to make explicit decisions about the data models to communicate.
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34795859/
 
  | title  = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API
The FOM is a set of XML files in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/HLA/ fgdata/HLA/]
(was Re: A FGPythonSys implementation: ...)</nowiki>
 
  | author = <nowiki>Stuart Buchanan</nowiki>
==Current Status (19/02/2016==
  | date  = Jan 26th, 2016
 
  | added  = Jan 26th, 2016
Currently there is some very old HLA support in SimGear.  This is very out of date and should be ignored.
  | script_version = 0.23
 
  }}
Stuart has HLA Support using the latest OpenRTI and SimKit working on a local build, but is waiting for Mathias to officially publish his SimKit before he pushes his changes. 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 SimKit FOM and connecting to an OpenRTI RTI.
* Instantiating MP AI objects so users can view objects published over the RTI by other Federates.  This is currently somewhat unsatisfactory as it overloads the MP code, where really these objects are more basic.
 
We currently have the following other Federates:
* fgogel - An AI model written in python the publishes 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 retrieves the closest METAR station for other published Federates and publishes the METAR for them to pick up.  This could be expanded to provide a general Weather Engine.
 
Separately Erik has been doing some preparatory work suitable for supporting HLA in JSBSim  (http://sourceforge.net/p/jsbsim/mailman/message/34720784/)


{{FGCquote
|1= 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).
|2= {{cite web
  | url    = http://sourceforge.net/p/jsbsim/mailman/message/34720784/
  | title  = <nowiki>[Flightgear-devel] (JSBSim) Standalone Properties</nowiki>
  | author = <nowiki>Erik Hofman</nowiki>
  | date  = Dec 25th, 2015
  }}
}}


For additional information, please see:
For additional information, please see:

Revision as of 17:54, 19 February 2016

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[1][2], James Turner[3], Stuart Buchanan[4], Richard Harrison [5]
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.

A good overview of how the HLA architecture works can her found here http://www.pitch.se/images/files/tutorial/TheHLAtutorial.pdf.

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 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 src/Network/HLA.

Federate Object Model

A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updated that are published by the RTI. While it might at first glance seem a good 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 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 files in fgdata/HLA/

Current Status (19/02/2016

Currently there is some very old HLA 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 local build, but is waiting for Mathias to officially publish his SimKit before he pushes his changes. 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 SimKit FOM and connecting to an OpenRTI RTI.
  • Instantiating MP AI objects so users can view objects published over the RTI by other Federates. This is currently somewhat unsatisfactory as it overloads the MP code, where really these objects are more basic.

We currently have the following other Federates:

  • fgogel - An AI model written in python the publishes 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 retrieves the closest METAR station for other published Federates and publishes the METAR for them to pick up. This could be expanded to provide a general Weather Engine.

Separately Erik has been doing some preparatory work suitable for supporting HLA in JSBSim (http://sourceforge.net/p/jsbsim/mailman/message/34720784/)


For additional information, please see:


External links