An Introduction to FOM Modules Björn Möller Pitch Technologies

What Are FOM Modules? The same FOM as before but divided into modules Support for decoupling the development process for different concerns Example: RPR platform concerns, sensor concerns, federation management concerns A way to separate standard FOM concepts from local or temporary adaptations

Object & Interaction Roots, Predefined Data Types, etc The HLAbase FOM Module Contains Root classes for Objects and Interactions Predefined data types (like HLAinteger32BE) Predefined transportation types, dimensions, etc MOM More (Identification, etc) Automatically loaded by the RTI when Create Federation Execution is called Guarantees that these concepts are correctly defined HLAbase Object & Interaction Roots, Predefined Data Types, etc

User Defined FOM Modules A user defined module can add more classes, interactions, data types, switches, synchronization points, etc Attributes and parameters can only be added to new object classes and interactions The first user defined FOM module is known as the primary FOM module (more about this later) My Object Classes, Interactions, etc HLAbase Object & Interaction Roots, Predefined Data Types, etc

Circular Dependencies Not Allowed Allowed: HLAbase:ObjectRoot - A:Vehicle – B:Aircraft Disallowed: A:Vehicle – B:Aircraft – A:FreightAirCraft The ”colon” notation is used here only for clarification

Inheritance As Usual In the FOM HLAbase:ObjectRoot(HLAbase:PrivilegeToDeleteObject) – A:Vehicle (A:Speed, A:Color) – B:Aircraft (B:Altitude) Available attributes for B:Aircraft ObjectRoot: PrivilegeToDeleteObject A:Speed A:Color B:Altitude The ”colon” notation is used here only for clarification

Some XML Code (Draft) Extension <?xml version="1.0" encoding="UTF-8"?> ... <objects> <objectClass> <name>objectRoot</name> <name>BaseEntity</name> <name>MyExtensionToRPR</name> <attribute> <name>ExtraSpatial</name> <dataType>SpatialStruct</dataType> </attribute> </objectClass> </objects> </objectModel> Extension XML Namespaces may or may not be used depending on complexity.

Impact on OMT Tools Human Italian LifeForm HLAObjectRoot Lamborghini Car Ferrari An OMT tool now needs to handle (load, save, visualize, etc) FOMs by module Example: To be useful an OMT editing tool will need to distinguish between: A) Is the user adding more items to the currently loaded FOM module, or B) Is the user adding items to a new FOM module that builds upon some currently loaded FOM module This is a practical requirement, not a direct requirement by the HLA standard

Detailed Semantics for FOM Modules HLAbase Primary FOM Module Additional FOM Module Identification Yes Items starting with HLA Not allowed Objects and Attributes Yes, subclassing Interactions and Parameters Data types Yes, adds User Supplied Tags Transportation Types Dimensions Time representations Yes (not used) Yes, decides Yes, not used Synch Points Switches Notes

How to Use FOM Modules Local RPR Extension Real Time Reference Platform (Standard) FOM My Federation Management Data Logger Control HLAbase Object & Interaction Roots, Predefined Data Types, etc A Module can add new object and interaction classes,

How NOT to Use FOM Modules My Idea About Aircrafts Your Idea About Aircrafts His Idea About Aircrafts HLAbase Object & Interaction Roots, Predefined Data Types, etc Federates still need to agree on how to model the same concept.

Interface Specification CreateFederationExecution(Name, FDDlist) Takes FDD file list HLAbase is provided by the RTI JoinFederationExecution(FedEx, Type, Name, FDD list) Causes these FOM modules to be loaded unless they already are DestroyFederationExecution() Unloads all FOM modules GetSomeHandle Can get a handle for any loaded FOM concept It is recommended to load all FOM modules that your federate refers to. Otherwise a GetHandle may fail. Handles will never become unavailable since a FOM is never unloaded

About FOM Module Loading HLAbase is loaded implicitly by the RTI This functionality is required in the RTI and no extra user action is required The HLAbase file is part of the HLA standard It is useful to have this file available when developing new FOM modules One or more FOM modules shall be loaded when the federation execution is created FOM modules shall always loaded in the specified order to guarentee that dependencies can be resolved The first module to be (explicitly) loaded is known as the primary FOM module. It provides global settings. It is a recommended practice to keep track of which your primary FOM module is, for example by providing it first in Create Federation Execution Additional modules may be loaded later by each joiing federate Duplicate load of the same module is allowed and void Modules are never unloaded within a federation execution

Backwards Compatibility If you have exactly one FOM module and load it during create then conceptual backwards compatibility is achieved. This is useful for example for older federations Some calls will still need to be modified. Newer federates can still add new FOM modules later.

Life Span of FOM Modules Once loaded a FOM module will remain available until the federation execution is destroyed time My FlightSim Create Federation Execution Local RPR Extension My Federation Management FOM RPR FOM My Fed Mgmt My Federation Management FOM Standard RPR Viewer RPR FOM HLAbase

Required MOM Extensions The FDD Attribute on ”Federation” will become a list of FDDs New MOM Interaction per federation HLAreportFOMmoduleLoaded Provides the name of the loaded module Will only be sent on load, i.e. the first time a federate joins with that module

Impact on RTIs Main impact is for the ”Join” with additional FOM modules Likely to require substantial processing on CRCs and every LRC This may happen during the main execution Synchronized startup can be used to avoid this Late joiners means problems anyway... Load of several FOM modules may be difficult to do in parallell But will be quick if the module is already loaded Use a few, large FOMs, not many small ones Loading FOM modules requires consistency checking