RPR FOM PDG History

1. RPR FOM PDG History 2012 Fall SIW

2. What is the RPR FOM? • History overview • Some significant technical issues • RPR 1.0 • RPR 2.0 • List of 2.0 Transformations between DIS and RPR FOM 2012 Fall SIW

3. RPR FOM Purpose • Goals: • A Reference FOM for the Real-time, Platform-level simulation community • Facilitate transition of DIS implementations to the HLA • RPR 1.0: IEEE1278.1-1995 Functionality • RPR 2.0: IEEE1278.1a-1998 Functionality • Maintain interoperability among DIS simulations once they are transitioned • Guiding Principle: • Provide an intelligent translation of DIS to a Reference FOM. Don’t try to improve DIS beyond what comes naturally from the use of HLA features. • Consists of the FOM and a guidance document 2012 Fall SIW

4. Guidance, Rationale, and Interoperability Manual (GRIM) • Adds a set of usage rules above and beyond those specified in the Object Model Template. • Mapping between RPR FOM and DIS. • Increased support for default fields. • Guidance and rational needed for extendibility. • Create meaningful rules for "compliance" and "compatibility”. • These terms have no meaning without a set of testable “shall” rules. • Of course, as a reference FOM, users are free to change theses practices to meet their own development needs. • However, deviations may not have a-priori interoperability with other systems based on the RPR FOM.

5. Contents of the GRIM • General FOM Guidance and Rational • RPR FOM Class Structure • Provides mapping from RPR FOM back to DIS • Guidance, rational, and modalities provided in text. • RPR FOM Interaction Structure • Similar in format to Class Structure sections. • Breaks down Interactions into Families for ease of description. • Mapping from DIS to the RPR FOM • Needed to support transition of legacy DIS systems to HLA

6. The Good Old Days 2012 Fall SIW

7. The Reaper Looms 2012 Fall SIW

8. Back from the Dead 2012 Fall SIW

9. RPR 1.0 Development • HLA IEEE and RPR progressed in parallel • Moving target required some adjustments • Initially DIS timestamp transported through timestamp parameter; however, changes to specification where only TSO updates delivered timestamps required timestamp to be moved into user tag • Object handle changed from simple integer data type to encapsulated class; required references to objects to switch to object name • HLA services beyond DIS functionality were not specifically addressed or guaranteed • Time Management • Ownership Management • Data Distribution Management 2012 Fall SIW

10. RPR 1.0 DevelopmentContinued • Class hierarchy • Compromised between flat (e.g. put everything into one class per PDU) and deep hierarchy (e.g., separate class for each specific entity type). • Each class represents fundamental object characteristics • Provides some general intermediate classes (e.g., BaseEntity, EmbeddedSystem) that allowed subscription to generic types of data and some leaf classes that allowed subscription to more specific classes of data (e.g., GroundVehicle, Aircraft) • No distinction between civilian and military • Requires inspection of data values (possible to use DDM for filtering) • Definition and Location of attributes • General approach was to map individual fields into attributes and parameters • Possible for fields from a single PDU to be distributed among multiple HLA classes • Again comprised between allowing generic and specific subscription. • All attributes provided in the upper level class hierarchy to support general subscribers and minimize duplication • Some attributes have no meaning for specific leaf classes (noted in attribute descriptions) • DIS Bit-Field enumerations transformed into attributes as HLA enumerations • Enumerations in HLA are part of FOM • Requires periodic update to FOM • Must also consider new bit fields may require new attributes • Since its possible that attributes are not sent, must define default values (e.g., all Boolean attributes default to false) • Followed DIS use of big endian and word alignment • Array counts derivable from data type and size of attribute data • Exceptions were elements where the size is variable; generally count transmitted as separate attribute 2012 Fall SIW

11. RPR 1.0 DevelopmentContinued • DIS Entity Identifiers • Redundant to HLA object instance handle for the purposes of identify individual objects • Retained to support legacy systems and gateway translation • Also needed to support DIS wildcard addressing scheme (e.g., setData interaction for all objects on a particular host) • Retained use of DIS Dead Reckoning • All federates maintain a dead reckoned model for both registered and discovered objects (derived from PhysicallEntity) • For registered objects, updates are sent when thresholds are exceeded between internal model and dead reckoned model (e.g. location of models differs by 1 meter in any direction) 2012 Fall SIW

12. RPR FOM 2.0 Development • Changes from RPR FOM 1.0 and RPR FOM 2.0 fall into one of the following categories, depending on the reason for the change: • Support of 1278.1a extensions resulted in new object and interaction classes, added attributes and parameters, new complex data types and enumerations • Representation of Spatial entity information was changed from separate attributes to a single attribute consisting of a variant-record • Changes to radio-related object and interaction classes were made due to community comments • Changes made to support improved performance • ModulationStruct complex data type was removed because the functionality was moved to the SpreadSpectrumStruct complex data type • Padding fields were added to complex data types to comply with the IEEE 1516.2 OMT’s default encoding specification Not included above are enumeration changes resulting from the inclusion of the current EBV

13. Separate Attributesvs. Complex Attribute • RPR FOM 1.0 was designed with 7 separate spatial attributes • Position, Orientation, Velocity, Angular Velocity, Acceleration, Dead Reckoning Algorithm, Freeze state • Saves bandwidth by sending only the information needed • Avoids using a variable data format (variant record) • Not supported well in the current OMD • More complex to code and debug • Concerns about performance for this data that accounts for 80%-90% of all entity updates • Case study FOM was created with three different ways to represent the same data • Separate attributes • Single combined attribute with fixed format • Single combined attribute with variable format • Performance tests (processing time and bandwidth) were run on each • Compared to sending a single attribute, each additional attribute adds about 7% to CPU time • 25 to 30% more CPU time for 5 RPR FOM spatial attributes • 4 to 8 more bytes per additional attribute per update when using separate attributes • 32 extra bytes of bandwidth used per update when sending all 5 RPR FOM spatial attributes • Reasons to make the change • 25% savings in CPU time and some bandwidth improvement for DR Algorithm 4 and 8 • A single attribute will force all spatial fields to be updated simultaneously • Improves correlation as attributes are needed all together in almost all cases • 2.0 already breaks interoperability with 1.0 • RPR 2.0 adopted single spatial structure with 9 variants – one for each DR algorithm type • Similar transformation was performed on the parameters of the EncodedAudioRadioSignalinteraction • Parameters only used all together • Significant performance savings versus separate parameters (audio data can account for over 50% of traffic) Designing FOMs For Performance 00F-SIW-116 2012 Fall SIW

14. StreamTag Identifier for Audio data • Problem: Association between transmitter and its transmitted signal used object name (a string) • String identifier increases the load and coding complexity of associating the transmitter and the signal data. • Problem: Object name identifier supports the association of the data stream with a single transmitter • Requires separate (but identical) data stream when multiple transmitters are carrying the same signal • Solution: Identify the audio stream independently of the transmitter using an efficient StreamTag identifier • Uniquely and efficiently identifies an encoded audio stream across the federation execution • Added to RadioTransmitter class and AudioData parameter of Signal interaction • Allows signal to be associated with multiple transmitters 2012 Fall SIW

15. IsPartOf as Attributevs. Separate Class • DIS IsPartOf PDU supported a mechanism where an entity could become part of another entity • E.g. aircraft landing on an aircraft carrier • Receiving simulation stops simulating entity • Sending simulation takes over simulation of entity • Requires handshake acknowledgement • Saves bandwidth by representing entity as an attached part • Represented by RelativeSpatial and IsPartOf attribute in BaseEntity class • Relative positioning requires no transaction between simulations • Aircraft indicates relationship with IsPartOf attribute • Aircraft updates relative position information using RelativeSpatial attribute • Aircraft continues to update normal spatial attributes for other simulations that do not need the fidelity provided with relative position • Requires additional computation to combine host entity position and relative position 2012 Fall SIW

16. Detailed Differences:Entity & Radio • Entity information/interaction • Collision-Elastic • New interaction class and parameters • Collision.Collision-Elastic • Entity State Update • No change required since selective updates already part of HLA. • Radio Communications • Intercom Control and Signal • Omitted from FOM due to lack of community support (no SME available to perform transformation into HLA and write in GRIM)

17. Detailed Differences:Distributed Emission Regeneration • Underwater Acoustic • New object classes and attributes • EmbeddedSystem.UnderWaterAcousticsEmission • ActiveSonar • AdditionalPassiveActivities • PropulsionNoise • IFF/ATC/NAVAIDS • New object classes with new attributes • EmbeddedSystem.IFF • NatoIFF • NatoIFFInterrogator • NatoIFFTransponder • SovietIFF • SovietIFFInterrogator • SovietIFFInterrogator • EmbeddedSystem.IFF.RRB • Supplemental Emission/Entity State • New attributes added to existing classes 2012 Fall SIW

18. Detailed Differences:Minefield & Entity Management • Entity Management • Aggregate State • New object class and attributes • BaseEntity.AggregateEntity • IsGroupOf • General approach of providing additional information about aggregate units not supported • RelativeSpatial attribute of BaseEntity class supports communication of relative position information • Transfer Control Request • New interaction class and parameters • TransferControl • IsPartOf • General approach of providing is-part-of relationships not supported • RelativeSpatial attribute of BaseEntity class supports communication of position composition • Minefield • Minefield State • New object class and attributes • Minefield • Minefield Query, Data, and Response NACK • New Interactions and parameters • MinefieldQuery, EmbeddedSystem.MinefieldData, & MinefieldResponseNACK

19. Detailed Differences:Synthetic Environment • Environmental Process, Gridded Data, Point/Linear/Areal Object State • New object class and attributes • GriddedData • EnvironmentProcess • EnvironmentObject • ArealObject • MinefieldObject • OtherArealObject • LinearObject • BreachableLinearObject • BreachObject • ExhaustSmokeObject • MinefieldLaneMarkerObject • OtherLinearObject • PointObject • BreachablePointObject • BurstPointObject • CraterObject • OtherPointObject • RibbonBridgeObject • StructureObject • Point/Linear/Areal Object State • New interaction classes and parameters • Supports requests to create, modify, or delete object • EnvironmentObjectTransaction • ArealObjectTransaction • MinefieldObjectTransaction • OtherArealObjectTransaction • LinearObjectTransaction • BreachableLinearObjectTransaction • BreachObjectTransaction • ExhaustSmokeObjectTransaction • MinefieldLaneMarkerObjectTransaction • OtherLinearObjectTransaction • PointObjectTransaction • BreachablePointObjectTransaction • BurstPointObjectTransaction • CraterObjectTransaction • OtherPointObjectTransaction • RibbonBridgeObjectTransaction • StructureObjectTransaction

20. Detailed Differences:Non-Real Time, Live Entity &Simulation Management w/ Reliability • Non-Real Time Protocol • Most/all functionality provided by RTI • Live Entity • TSPI, Appearance, Articulated Parts, LE Fire, LE Detonation • Mostly subsumed by RTI ability to separately update object attributes and selectively send interaction parameters • SIMAN w/Reliability • New interaction classes and parameters • “Reliable” subclass have been added to the existing SIMAN interactions • Follows the 1278.1a protocol for conducting reliable SIMAN transactions • Does not rely on nor consider HLA reliable transport • In fact, intended for best effort transmission