Introducing the FOM/SOM file: Part 1

According to the Wikipedia:

For HLA 1516-2010, instead of a single FDD that describes the entire FOM, the specification describes FOM modules which are merged to form the full FOM. By default, a federation is created by merging the HLAstandardMIM.xml FOM module with the module(s) provided by the federate that creates the federation. The standard MIM (MOM and Initialization Module) contains the MOM classes and the basic default data types. Any joining federate can add one or more FOM modules to extend the existing FOM.

In principle, nothing changes for the federates. They call the same functions of the RTI as before. The difference is that elements of a FOM that are not needed do not have to be loaded and managed. In addition, if a federate joins late the additional information exchange requirements can be added when modular FOMs are used.

The FOM describes the set of object classes, attributes, and interaction classes that are shared across a federation. The SOM describes the federate in terms of the categories of object classes, attributes, and interaction classes that it can offer to federations.
You can see the Standard MOM and Initialization Module (MIM) for HLA IEEE 1516-2010 here. MOM is the Management Object Model, wich is the basic definitions of HLA objects, data types and interactions. You can use it to monitor the Federation by subscribing to it.

The first part of the file is the Model Identification. Here you will describe the details of the model.

<modelIdentification>
    <name>Sagitarii Federation FOM</name>
    <type>FOM</type>
    <version>1.0</version>
    <modificationDate>2015-11-13</modificationDate>
    <securityClassification>Unclassified</securityClassification>
    <purpose>Basic specifications to the Federation</purpose>
    <applicationDomain>Engineering</applicationDomain>
    <description>FOM for the sagitarii Federation.</description>
    <useLimitation>None</useLimitation>
    <poc>
        <pocType>Primary author</pocType>
        <pocName>Carlos Magno Abreu</pocName>
        <pocOrg>CEFET</pocOrg>
        <pocTelephone>+55 55 55 55</pocTelephone>
        <pocEmail>magno.mabreu@gmail.com</pocEmail>
    </poc>
    <reference>
        <type>Document</type>
        <identification>Sagitarii Data Science Workflow System</identification>
    </reference>
    <other></other>
    <glyph alt="Node" width="36" height="36" type="png">glyph_code</glyph>
</modelIdentification>

Next, we have the objects definitions. Objects must persist over the Federate life. If you create a Sheep Federate, you’ll need a Java class to represent a Sheep ( and maybe a List<Sheep>  to store all your sheeps ). This Java class must reflect the “objectClass” described in FOM/SOM and its attributes.

  <objects>
      <objectClass>
          <name>HLAobjectRoot</name>
    
          <objectClass>
              <name>SagitariiServer</name>
              <sharing>PublishSubscribe</sharing>
              <semantics>The Sagitarii Server</semantics>
              <attribute>
                  <name>MACAddress</name>
                  <dataType>HLAunicodeString</dataType>
                  <updateType>Static</updateType>
                  <updateCondition>NA</updateCondition>
                  <ownership>NoTransfer</ownership>
                  <sharing>PublishSubscribe</sharing>
                  <dimensions/>
                  <transportation>HLAreliable</transportation>
                  <order>Receive</order>
                  <semantics>Server MAC Address</semantics>
              </attribute>                
          </objectClass>
    
  </objectClass>
</objects>

Here, we have an object called “SagitariiServer”, wich descends from “HLAobjectRoot” ( HLAobjectRoot.SagitariiServer ). This object have just one attribute called “MACAddress”, of type “HLAunicodeString”. This attribute may not be updated ever (static) nor be transfered to anyone. Can be published and other Federates can subscribe to it.

Transportation “HLAreliable” means a TPC connection to transfer the attribute data ( guaranteed connection, but a little slower ). Transportation can be “HLABestEffort”, wich means an UDP connection ( no guaranteed delievery, but faster ).

“Order” control the data flow. Can be “Receive” ( receiving data can be in any order )  or “TimeStamp” ( receiving data must follow time order )

I will cover “Dimensions” in other post.

Now, we may have some Interactions. Interaction is a kind of command to send to Federates by other Federate. You don’t have to create Java classes to represent or store Interactions. Interactions may send things like “Start”, “Stop”, “Kill Sheep Called Bob”.

  <interactions>
      <interactionClass>
          <name>HLAinteractionRoot</name>
          
          <interactionClass>
              <name>KillSheep</name>
              <sharing>PublishSubscribe</sharing>
              <dimensions/>
              <transportation>HLAreliable</transportation>
              <order>Receive</order>
              <semantics>Command a Sheep to DIE</semantics>
              <parameter>
                  <name>SheepName</name>
                  <dataType>HLAunicodeString</dataType>
                  <semantics>The name of target sheep</semantics>
              </parameter>
          </interactionClass>
    
  </interactionClass>
</interactions>

This interaction will send a “Kill Sheep” command. It have one parameter of type “HLAunicodeString” to store the sheep’s name. The owner Federate can publish and other Federates can subscribe to it.

I’ll cover other aspects of the SOM/FOM file in other post.

 

 

Add Comment