Jump to: navigation, search

High-Level Architecture

99 bytes removed, 21:39, 23 February 2016
Remove comments about property trees that are nothing to do with the FOM
A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updates 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 <ref></ref><ref></ref><ref></ref> and it's likely to lead to synchonization issues. Instead, we'll need to make explicit decisions about the data models to communicate.
One possibility suggested by Stuart on the devel list, would be providing certain subsystems with their own ''private'' property tree <ref>The FOM is a set of XML files in [<tree/ref>. HLA/ fgdata/HLA/]
For instance, certain subsystems are already well-behaved/encapsulated in that they're having their own dedicated branches in the property tree (e.g. think <code>/ai</code>, <code>/models</code>, <code>/canvas</code>), i.e. could be moved to a separate thread accordingly, which would be in line with similar ideas discussed in the past (see [[Property threading]]). ==Federates==
The FOM is a set of XML files Federates can be written in [https://sourceforgemost languages, but SimKit provides very good hooks for writing them in C++ and For some Subsystems split off from the existing FlightGear source it's fairly easy to create an executable with it's own property tree/and have shared C++ code to map FOM objects to property values. However, this is an implementation detail - the whole point of HLA/ fgdata/HLA/]and the FOM is that it makes no assumptions about what Federates do with the data.
==Current Status ==

Navigation menu