HLA: FOM vs SOM

Question

I'm starting to study how to implement HLA in a project that I'm developing, and there's something that I can't understand very well.

In a federation, the data that are exchanged are defined in the FOM (Federation Object Model), that contains all the necessary stuff (classes, interactions and so on). That's ok.

I've also read that every federate needs to publish its own SOM (Simulation Object Model), that's a description of data that the federate publishes and for which it's subscribed.

My questions are:

• Who needs to load the FOM file? Every federate? It must be read from the RTI Manager?
• Why a federate needs to publish a SOM if the FOM is already available? If the FOM defines all strucutres that can be exchanged, the SOM duplicates a sub-part of the FOM that's needed only by the federate?
• Who reads the SOM that's sent by a federate?
• What data are stored inside the SOM? There's a deep copy of some structure defined in the FOM, there are links to them in the FOM?
• The SOM can contain classes, interactions and so on that are not defined in the FOM?
• If every federate publish data about objects that it uses with the SOM, why we need the FOM?

Sorry if they are simple questions, but I'm new to this and even if I understand the programming aspect of HLA, the logic behind these things are a bit obscure for me (maybe my not perfect English has a part in it, too).

Answer 1

Yserbius described the difference between a FOM and a SOM.

I have added some responses to your direct questions.

• Who needs to load the FOM file? Every federate? It must be read from the RTI Manager?

The RTI uses the FOM file. It has to be provided when the federation is created. Only the first federate needs to provide it.

• Why a federate needs to publish a SOM if the FOM is already available? If the FOM defines all strucutres that can be exchanged, the SOM duplicates a sub-part of the FOM that's needed only by the federate?

The SOM is not needed at runtime, when your federates are executed. The SOM can be viewed as a document describing the capabilities of your simulator.

• Who reads the SOM that's sent by a federate?

No SOM is needed at runtime.

• What data are stored inside the SOM? There's a deep copy of some structure defined in the FOM, there are links to them in the FOM?

The SOM is a subset of the FOM.

• The SOM can contain classes, interactions and so on that are not defined in the FOM?

Yes, but they can not be used at runtime, unless they are added to the FOM.

• If every federate publish data about objects that it uses with the SOM, why we need the FOM?

Good question. It is usually the other way around, the federates provide a FOM at runtime, and no SOM exist to describe the federate.

Answer 2

I apologize for the late answer, I hope this is still applicable. I am assuming you are using HLA 1.3 or HLA 1516 because the term SOM in HLA 1516-2010/Evolved has been replaced with FOM modules.

1. The first federate to create a federation does so with a FOM file (a Lisp variant in 1.3 and XML in subsequent versions). That FOM then becomes available to every new federate that joins. The individual federates do not need to have copies of the FOM file.
2. The SOM is not actually required by any of your software. It's simply a subset of the FOM. It's main use is for compliance checking and verification, so that before a federation is deployed, its verified what objects and interactions each individual federate can and cannot use. When you're running a federation, the SOM can be ignored (unless you're running some sort of dynamic all-purpose federate whose activity can be modified without recompiling by swapping out the SOM).
3. A 1.3 and 1516 SOM cannot contain anything that's not in the FOM. 1516-2010 introduced the concept of FOM modules. Instead of one big FOM file, a federate can build a FOM with a collection of smaller files that make up the FOM. Each joining 1516-2010 federate can have their own modules to add to the FOM.