Transcript RPR FOM PDG History

RPR FOM PDG History
2012 Fall SIW
• 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
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
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.
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
The Good Old Days
1996-1998
•Formation of initial proposal to create an HLA reference FOM that
represented DIS
•Started at 14th DIS workshop (shortly after introduction of HLA)
• Initial development of Reference FOM through Fall SIW 98
•SISO Standards nomination submitted June 97
•SN approved June 98
•Kickoff of RPR FOM SDG in Fall 98
1998-1999
•Final development of RPR FOM 1.0 to represent DIS 1278.1-1995
•RPR FOM 1.0 standard approved
• SISO-STD-001-1999 Guidance, Rationale, & Interoperability Modalities for
the RPR FOM (GRIM 1.0)
•SISO-STD-001.1-1999 Real-time Platform Reference Federation Object
Model (RPR FOM 1.0)
2012 Fall SIW
The Reaper Looms
1999-2004
•Development of RPR FOM 2.0 to represent DIS 1278.1a-1998
•17 Draft revisions through 2003
•2.0 Draft 17 is widely used in community
•Invitation to ballot October 2003
•Balloting opens March 2004
•Ballot fails June 2004 and enters comment resolution
2004-2010
•Comment resolution stalls with little or no progress
•Failed attempt to reactivate ballot group in 2006-2007
•Produced 2.0 Draft 18 version for re-balloting in 2007
•Failed attempt revitalize PDG by moving to conduct efforts electronically in
2008
•Motion to dissolve RPR FOM PDG submitted to SAC in September 2009
•PDG dissolution pending in 2010
2012 Fall SIW
Back from the Dead
2011Present
• Informal meetings to revive PDG held at
Spring and Euro 2011 SIW
• TOR to start new PDG submitted October
2011
• SAC determined in Dec 2012 that pending
dissolution of PDG never completed
• SAC requires PDG to update TOR and PN in
February 2012
• Product nomination sent to SAC in May 2012
• Product nomination approved by EXCOM
August 2012
2012 Fall SIW
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
RPR 1.0 Development
Continued
•
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
RPR 1.0 Development
Continued
• 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
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
Separate Attributes
vs. 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)
•
•
•
•
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
•
–
•
•
Not supported well in the current OMD
More complex to code and debug
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 EncodedAudioRadioSignal interaction
–
–
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
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
IsPartOf as Attribute
vs. 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
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)
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
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
Detailed Differences:
Synthetic Environment
•
Environmental Process, Gridded Data,
Point/Linear/Areal Object State
–
–
–
–
New object class and attributes
GriddedData
EnvironmentProcess
EnvironmentObject
•
– New interaction classes and parameters
– Supports requests to create, modify, or
delete object
– EnvironmentObjectTransaction
•
MinefieldObject
OtherArealObject
BreachableLinearObject
BreachObject
ExhaustSmokeObject
MinefieldLaneMarkerObject
OtherLinearObject
PointObject
–
–
–
–
–
–
BreachablePointObject
BurstPointObject
CraterObject
OtherPointObject
RibbonBridgeObject
StructureObject
ArealObjectTransaction
–
–
•
•
MinefieldObjectTransaction
OtherArealObjectTransaction
LinearObjectTransaction
–
–
–
–
–
LinearObject
–
–
–
–
–
•
Point/Linear/Areal Object State
ArealObject
–
–
•
•
BreachableLinearObjectTransaction
BreachObjectTransaction
ExhaustSmokeObjectTransaction
MinefieldLaneMarkerObjectTransaction
OtherLinearObjectTransaction
PointObjectTransaction
–
–
–
–
–
–
BreachablePointObjectTransaction
BurstPointObjectTransaction
CraterObjectTransaction
OtherPointObjectTransaction
RibbonBridgeObjectTransaction
StructureObjectTransaction
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