Modular FOMs

1
Modular FOMs
2
Why Modular FOMs?

• Today the FOM of a federation is monolithic which
  is a limitation
• Examples of when we need Modular FOMS
• When developing and maintaining Reference FOMs to
  separate concerns
• Improved use of Reference FOMs by making
  extension FOM modules
• To support long-running federations where the
  domain capabilities expand gradually

3
About the Current Proposal

• Initial suggestions focused around the RTI and
  run-time characteristics
• Does not address how models relate to each other,
  only how they are used by the RTI
• Updated suggestion starts out with definitions,
  rules and OMT handling
• Addresses overall semantics of combining object
  models. Useful in OMT editors and other tools.
• Interface specification then builds on these
  definitions

4
Relationship between FOMs and FOM Modules
The FOM

• The FOM is defined as before.
• Now it is built from FOM modules.
• A pre-defined FOM module the Root FOM Module
  contains object roots, predefined data types, etc.

Ship
SpecialShip
Vehicle
ObjectRoot
AirCraft
Weather
Vehicle FOM Module
Root FOM Module
Ship
Vehicle
ObjectRoot
ObjectRoot
AirCraft
Special Ship FOM Module
Weather FOM Module
Ship
SpecialShip
Vehicle
ObjectRoot
ObjectRoot
Weather
5
Modular FOMs and FEDEP
Year 2 Add Special Ship
Year 1 No Special Ship
Perform FEDEP for this goal. Select federates.
Develop FOM consisting of one or more modules.
Consider reusing reference FOM modules.
Reiterate while or part of FEDEP. Federation
agreement is extended. New FOM module is added.
Result
Weather
Aircraft
Ship
6
Rules for Building a FOM from FOM Modules

• The Root FOM shall always be included
• Other FOMs are added as follows
• The following are added Object classes,
  interactions, parameters, attributes, data types,
  transportation types, synchronization points,
  more
• The following shall be identical switches, user
  defined tags, time representation, more
• Identification (metadata) is disregarded

7
Rules for Loading FOM Modules

• When the Federation Execution is created the Root
  FOM Module is loaded automatically. A Primary FOM
  shall also be provided.
• Additional FOM Modules may be loaded when the
  federation execution is created or when a
  federate joins.
• The sum of the FOM Modules that have been loaded
  at any given time is known as the Current FOM
  Subset.
• When all FOM Modules have been loaded the entire
  FOM is available. The Current FOM Subset now
  equals the FOM.
• Special rule The MOM may be extended
  (attributes, interactions, etc) by the Primary
  FOM only.

8
Standards Texts

• Note Some recent BOM-related modifications needs
  to be retrofitted.

9
Definitions

• 3.1.34 Federation Object Model (FOM) A
  specification defining the information exchanged
  at runtime to achieve a given set of federation
  objectives. This includes object classes, object
  class attributes, interaction classes,
  interaction parameters, and other relevant
  information. The FOM is specified using one or
  more FOM Modules.
• 3.1.x FOM Module A subset of the FOM. A FOM
  Module shall be complete in the sense that it
  shall contain complete or scaffolding definitions
  for all user-defined concepts (object classes,
  data types, dimensions, etc) referred to in the
  FOM Module. A concept is considered to be
  user-defined if it is not defined in the HLA Root
  FOM Module.
• 3.1.35 Federation Object Model (FOM) Document
  Data (FDD) The data and information in the FOM
  Modules that specify the FOM that is used by the
  Create Federation Execution service and
  successive Join Federation Execution to configure
  the federation execution.

10
Definitions - 2

• 3.1.89 Simulation Object Model (SOM) A
  specification of the types of information that an
  individual federate could provide to High Level
  Architecture (HLA) federations as well as the
  information that an individual federate can
  receive from other federates in HLA federations.
  The SOM is specified using one or more SOM
  Modules. The standard format in which SOMs are
  expressed facilitates determination of the
  suitability of federates for participation in a
  federation.
• 3.1.x SOM Module A subset of the SOM. A SOM
  Module shall be complete in the sense that it
  shall contain complete or scaffolding definitions
  for all user-defined concepts (object classes,
  data types, dimensions, etc) referred to in the
  SOM Module. A concept is considered to be
  user-defined if it is not defined in the HLA Root
  FOM Module.
• 3.1.x HLA Root FOM Module A FOM Module that
  contains predefined concepts as defined in the
  standard, for example HLAObjectRoot, HLA
  InteractionRoot, standardized data types,
  standardized transportation types, etc. The HLA
  Root FOM Module is defined in the HLA Interface
  Specification.

11
Definitions - 3

• 3.1.x Current FOM Subset The sum of the
  currently specified FOM Modules. This sum may
  specify a subset of the FOM.
• 3.1.x Full Definition A definition of a concept
  (object class, data type, dimension, etc) in a
  FOM Module with a name and all required
  properties as specified in the OMT standard.
• 3.1.x Repeated Definition A full definition of a
  concept (object class, data type, dimension, etc)
  in a FOM Module with a name and additional
  properties that are identical to a definition
  that is already available in the Current FOM
  Subset.
• 3.1.x Scaffolding Definition A definition of an
  object class or an interaction class in a FOM
  Module or SOM Module that has a name identical to
  a definition provided by another FOM/SOM Module
  and that provides no additional properties. The
  purpose of a scaffolding definition is to
  indicate where in the class structure that a
  subclass of the scaffolding class is located.
• 3.1.x Primary FOM Module The FOM Module that,
  together with the HLA Root FOM Module, is used to
  initialize a newly created federation execution.

12
Combining FOM Modules - 1

• An object model (FOM or SOM) is specified using
  one or more FOM or SOM Modules. Modules shall be
  combined using the following rules
• The FOM/SOM shall contain the union of all
  definitions of Object Classes, Interaction
  Classes, Attributes, Parameters, Dimensions,
  Synchronization Points, Transportation Types,
  Data Types, Notes and FOM/SOM Lexicon.
• The FOM/SOM shall contain the Time Representation
  Table, Switches Table and User Defined Tags Table
  as defined in the FOM/SOM modules.
• The FOM/SOM shall contain the HLA Root FOM
  Module, containing predefined concepts as defined
  in the standard.

13
Combining FOM Modules - 2

• The following restrictions shall apply
• All definitions of a named Object Class shall be
  identical in all Modules unless they are
  Scaffolding Definitions. At least one Module
  shall provide a full definition.
• All definitions of a named Interaction Class
  shall be identical in all Modules unless they are
  Scaffolding Definitions. At least one Module
  shall provide a full definition.
• All definitions of a named Attribute for a
  particular Object Class shall be identical in all
  Modules. The set of Attributes defined for a
  given Object Class shall be identical in all
  Modules except for MOM Classes where additional
  Attributes can be provided in the FOM Module used
  as Primary FOM Module.
• All definitions of a named Parameter for a
  particular Interaction Class shall be identical
  in all Modules. The set of Parameters defined for
  a given Interaction Class shall be identical in
  all Modules except for MOM Classes where
  additional Parameters can be provided in the FOM
  Module used as Primary FOM Module.

14
Combining FOM Modules - 3

• All definitions of a named Dimension shall be
  identical in all Modules.
• The Time Representation table shall be identical
  in all Modules.
• The User Supplied Tag table shall be identical in
  all Modules.
• All definitions of a named Synchronization Point
  shall be identical in all Modules.
• All definitions of a named Transportation Type
  shall be identical in all Modules.
• The Switches table shall be identical in all
  Modules.
• All definitions of a named Datatype shall be
  identical in all Modules.
• All definitions of a labeled Note shall be
  identical in all Modules.
• For the FOM/SOM Lexicon All definitions of a
  named Object Class, Interaction Class, Attribute
  or Parameter shall be identical in all Modules.
• Note that the Identification tables are not used
  when Modules are combined

15
Create Federation Execution

• The Create Federation Execution service shall
  create a new federation execution and add it to
  the set of supported federation executions. Each
  federation execution created by this service
  shall be independent of all other federation
  executions, and there shall be no
  intercommunication within the RTI between
  federation executions. The RTI shall
  automatically load the HLA Root FOM Module. The
  Primary FOM Module designator argument and the
  Additional FOM Module designators argument
  identify the FOM Modules that, together with the
  HLA Root FOM Module, shall furnish the FDD for
  the federation execution to be created.
• 4.2.1 Supplied argumentsa) Federation execution
  name.b) Primary FOM Module designator.c)
  Optional list of additional FOM Module
  designators.

16
Join Federation Execution

• The Join Federation Execution service shall
  affiliate the federate with a federation
  execution. Invocation of the Join Federation
  Execution service shall indicate the intention to
  participate in the specified federation. The
  federate-name argument shall be unique within a
  federation execution at any given time. It may
  however be assigned to a different federate after
  a restore operation. The federate-type argument
  shall distinguish federate categories for
  federation save-and-restore purposes. The
  returned joined federate designator shall be
  unique for the lifetime of the federation
  execution as long as a restore is not in progress
  at any federate. In addition to this the Join
  Federation Execution service may also be used to
  provide additional FOM Module designators. This
  argument identifies the FOM Modules that shall be
  added to the FDD.
• 4.4.1 Supplied argumentsa) Federate name.b)
  Federate type.c) Federation execution name.d)
  Optional list of additional FOM Module designators

17
Some Pros and Cons

• Important to meet the requirements for
  long-running and GIG-style federations for
  training and analysis
• Greatly enhances the process for developing or
  building upon Reference FOMs

• A big step, are we ready to take it now?
• Allowing to add FOM modules later may break the
  federation agreement if not FEDEPed properly