RPR FOM Community Ballot Resolution

1
RPR FOM Community Ballot Resolution
2
Summary

• 61 comments
• 2 not applicable - comments on comment tool not
  the RPR FOM (4, 61)
• 16 editorial
• 36 minor technical
• 7 major technical

3
Reclassified comments

• 22 (was editorial now minor technical)
• 55 (was minor technical, now major technical)
• Classification of all others remain as per
  authors recommendations

4
Editorial Comments
5
Comment 4

• a) Repeat entries of continued blank fields at
  the top of each page. Provide table of contents.
• Recommendation - Reject
• Tables automatically generated by OMDT tool
• PDF bookmarks are included

6
Comment 4 (continued)

• b) Routing Space Table looks like orphan or
  mistake
• Recommendation - Reject
• The OMT specification requires a Routing Space
  Table to be present. The RPR FOM does not define
  any routine space information, therefore the
  table should be empty

7
Comment 16

• Pulse Width has units of microseconds
• Recommendation - Reject
• Conventionally Pulse Width has units of
  microseconds (should really be called Pulse
  Duration). We follow the DIS standard (and
  convention)

8
Comment 23

• FireControlSolutionRange units are spelt properly
  -) Should use American spelling
• Recommendation - Accept

9
Comment 30

• Add references to IEEE standard and enumeration
  document (these are the baseline documents)
• Recommendation - Accept

10
Comment 31

• Clarify the what type of reference FOM the RPR
  FOM is
• Recommendation - Accept

11
Comment 35

• Add note describing use of any in
  VariableDatumStruct
• Recommendation - Accept

12
Comment 36

• Add note explaining why the Value field of the
  ArticulatedPartsStruct type does not have an
  entry for units
• Recommendation - Accept

13
Comment 38

• Add note explaining why the FixedDatumValue field
  in the FixedDatumStruct does not have an entry
  for units
• Recommendation - Accept

14
Comment 43

• Remove note 1 (this refers to the Environmental
  Process objects - which were deferred to V2)
• Recommendation - Accept

15
Comments 44 45

• Remove notes 15 17 (no longer used)
• Recommendation - Accept

16
Comment 46

• Note 26 is an "orphan (this note is valid,
  although there is no obvious place to refer to
  this from)
• Recommendation - Accept
• Add note to metadata?

17
Comment 49

• Orientation is described as the yaw, pitch, and
  roll angles. Delete yaw, pitch, and roll and just
  describe the angles as rotations around the
  coordinate axis.
• Recommendation - Accept

18
Comment 50

• The names of the VelocityVectorStruct are not
  consistent with other names. Drop the word
  Magnitude from field names.
• Recommendation - Reject
• These descriptions were provided from the OMDD

19
Comment 51

• Note 38 should refer to note 44.
• Recommendation - Accept

20
Comment 57

• Add Metadata or notes "qualifiers" on RPR FOM
  usage guidance
• Recommendation - Accept (implementation TBD)
• Adding a note is easier, called up from the
  metadata

21
Minor Technical
22
Comment 1

• Lack of Datalink Parameters
• Recommendation - Postpone (Need more information)
• However, if the required enumerations are not in
  EBV 99-01 then they should not be added,
  therefore the comment should be rejected

23
Comment 2

• Command and Control Radars not fully represented
• Recommendation - Accept (in part)
• AN/TPS-75, AN/TPS-43 are listed in EBV 99-01.
  EmitterTypeEnum needs updating to EBV 99-01
  standard.
• However AN/TPS-70 is not in EBV 99-01. DIS
  enumeration CR needs to be raised.

24
Comment 9

• Move the attributes into the object classes
  indicated
• HatchState to MilitaryPlatform
• PersonStanceCode to MilitaryLifeform
• RampDeployed to MilitaryPlatform
• Recommendation - Accept
• Note - the actual disposition of these attributes
  might be effected by later comments

25
Comment 10

• Change update type of BaseEntity EntityType and
  MilitaryEntity AlternateEntityType attributes to
  static
• Recommendation - Accept ?
• In the past some implementations have changed
  their entity type enumerations during an exercise
  (e.g. from Tomahawk Booster to Tomahawk). This
  is probably no longer the case

26
Comment 11

• Change update type of Designator
  DesignatorEmissionWavelength and
  DeadReckoningAlgorithm to conditional.
• Recommendation - Accept

27
Comment 12

• Change update type of RadioReceiver
  ReceivedTransmitterIdentifier attribute to
  conditional.
• Recommendation - Accept

28
Comment 14

• Add Note 13 to Acknowledge, CreateEntity,
  RemoveEntity, StartResume, and StopFreeze in the
  Object Interaction table.
• Recommendation - Accept
• This may not strictly speaking be required, but
  it certainly does no harm

29
Comment 15

• Renumber and reorder notes into logical grouping.
  Fix references accordingly.
• Recommendation - Reject
• Logistics!

30
Comment 17

• a) Remove WorldLocation from RadioTransmitter.
• Recommendation - Reject
• The use of the WorldLocation attribute is an
  implementation enhancement in DIS aimed at
  simplifying the processing for radio simulations

31
Comment 17 continued

• b) If part a rejected, then add explanation to
  the GRIM
• Recommendation - Accept
• Add note to the FOM as well

32
Comment 18

• Clarify padding in VariableDatumStruct by adding
  a padding field and a note.
• Recommendation - Accept

33
Comment 19

• Remove notes 9, 10, 11, 15, and 16.
• Recommendation - Accept (in part)
• Notes 9, 10 and 11 are still used
• 15 and 16 can be removed

34
Comment 20

• Notes 5 and 24 should be combined. The text of
  note 24 needs some revision
• Recommendation - Accept

35
Comment 21

• Add the DIS time stamp tag to the Complex
  Datatypes
• Recommendation - Accept ?
• Add note explaining why this is not referenced
  from anywhere

36
Comment 24

• Federates should be required, not encouraged, to
  transmit the data valid time.
• Recommendation - Accept ?
• Not all current DIS simulations do this (although
  they should).

37
Comment 25

• Use variant enumeration struct for
  MajorRFModulationType and DetailedRFModulationType
  
• Recommendation - Accept
• Details need to be checked

38
Comment 28

• The ActionResultEnum32 and RequestStatusEnum32
  should be exchanged
• Recommendation - Accept
• The TACCSF_LOS_Reply_Type, etc., enumeration
  values should be added to RequestStatusEnum32 and
  deleted from ActionResultEnum32

39
Comment 29

• Add Dead Reckoning Other Parameters Field of 120
  bits
• Recommendation - Accept
• The DIS specification states This field shall
  specify other required dead reckoning parameters
  and shall consist of 120 bits.
• DIS simulations are allowed to use this (although
  the meaning is exercise specific)

40
Comment 29 implementation

• The new attribute should be complex data type
  (not enumeration as described)
• Must take byte alignment into account
• The attribute should be added to the BaseEntity
  object class

41
Comment 32

• Check object class names Expendables to
  Expendable
• Recommendation - Accept
• All other object class names are singular
• Supplies should stay plural because usually there
  isnt just one supply, there are multiple ones
  (e.g. 10 cases of ammunition, 200 gallons of fuel)

42
Comment 33

• Remove IR attributes from RadioSignal interaction
• Recommendation - Accept
• The radio signal interaction is intended to be an
  abstract interaction class (it has no
  parameters), so federates should not initiate or
  react to them. The subclasses are intended for
  transmission/reception

43
Comment 34

• Replace Dummy Modulation in ModulationStruct with
  CCTT SINCGARS modulation data
• Recommendation - Accept
• EBV 99-01 now contains modulation data
• Add a complex data type for the CCTT SINCGARS
  radio modulation.
• ModulationStruct contains new complex data type
  with cardinality 0-1

44
Comment 37

• Incorrect data type for Value field in
  AttributePairStruct
• Recommendation - Accept
• AttributePairStruct data type should be "any,
  cardinality 1, instead of octet, cardinality 1
• This more clearly indicates that the value field
  can be any type, simple or complex

45
Comments 39/40/41

• Postponed until after resolution of comments 5/6

46
Comment 42

• Missing enumeration values (attached parts,
  repair types repair response)
• Recommendation - Accept
• EBV 99-01 defines additional enumeration values
  not yet in the FOM

47
Comment 47

• Add note to all padding fields about setting them
  to zero
• Recommendation - Accept
• This is a DIS requirement, but has not been
  specified in the FOM

48
Comment 48

• Add note explaining "Frozen entities should not
  be dead-reckoned
• Recommendation - Accept
• This is a DIS requirement (specified in the EBV),
  but has not been specified in the FOM

49
Comment 49

• Delete yaw, pitch, and roll and just describe the
  angles as rotations around the coordinate axis.
• Recommendation - Accept
• Orientation is described as the yaw, pitch, and
  roll angles. Yaw, pitch, and roll generally
  refer to angles relative to the entity. This may
  be confusing.

50
Comment 50

• Change the names of the VelocityVectorStruct
  fields. Drop the word Magnitude from field
  names.
• Recommendation - Accept
• These names were chosen for consistency with the
  OMDD, but are internally inconsistent. Internal
  consistency wins

51
Comment 52

• Add note to ArticulatedParamentersArray in
  PhysicalEntity warning about creating to many
  articulated parts (also applies to other
  unbounded classes)
• Recommendation - Accept
• The note should be about compatibility with
  existing DIS simulations, which are limited by
  the maximum PDU size

52
Comment 54

• Indicate that the unit of length in the
  SignalDataLength parameter for the
  ApplicationSpecificRadioSignal,
  EncodedAudioRadioSignal, and RawBinaryRadioSignal
  interaction classes is BITS.
• Recommendation - Accept
• Corresponds to the DIS specification

53
Comment 55

• Remove TDLMessageCount parameter from
  DatabaseIndexRadioSignal Interaction
• Recommendation - Reject
• See next slides for details

54
Comment 55 continued

• This comes from the least significant 14 bits of
  the DIS PDU encoding scheme field (IEEE spec
  5.3.8.2 d)
• equals encoding type when encoding class is
  encoded audio
• is zero when encoding class not encoded audio and
  TDL type is zero
• otherwise contains the number of TDL messages
• Thus a database index signal can contain TDL
  messages

55
Comment 58

• No support for LAN information nor for non-radio
  communications
• Recommendation - Reject
• Clarification from commentor required, but v1.0
  constrained to IEEE 1278.1-1995 implementations
  which do not support such communications

56
Comment 59

• Emitter list is incomplete and contains repeats
• Recommendation - Accept (in part)
• Emitter list is not complete (see comment 2)
• Emitters not in EBV 99-01 should not be added
• Need more information about repeats - what are
  they

57
Comment 60

• Opacity code requires spectral component
• Recommendation - Reject
• The opacity code reflects the 1278.1-1995
  environmental entity attributes.
• More comprehensive support for environmental
  processes and their attributes is provided in v2
  (or in user extensions)

58
Major Technical
59
Comment 5/6/7

• Missing Light Attributes
• a) Light attributes missing
• b) Add light attribute to currently
  attributeless leaf nodes.
• c) Move MilitaryPlatform Attributes to more
  appropriate classes
• Recommendation a) Accept
• Light attributes are in EBV 99-01 so should be
  added
• b) c) deferred to after next comment

60
Comment 56

• Move all attributes to the top of hierarchy or
  distribute according to well defined rationale
• Recommendation
• Comment 5/6 does provide a well defined rationale
  - push attributes down to leaf nodes, each leaf
  node contains the explicit attributes for its
  entity type

61
Comments 5/6/7/56 continued

• Pros
• Less confusion about whether an entity contains a
  particular attribute
• Makes translation from DIS to RPR FOM easier/more
  obvious
• Cons
• Must subscribe to leaf nodes to get all
  attributes
• Some duplication of attributes (not thought to be
  a great problem)
• Once decision taken FOM editors to distribute
  attributes according to chosen rationale

62
Comment 8

• Environmental Entity and Cultural Feature limited
• Recommendation - Reject
• Environmental entity and cultural features map
  capabilities of IEEE 1278.1-1995
• Much better support provided in v2 which maps
  IEEE 1278.1A-1998 capabilities

63
Comment 13

• Merge civil and military classes
• Recommendation none
• Reflector debate addresses this
• Opinion
• Single class would be cleaner
• Con political argument in favour of retaining
  civil classes to show support for OOTW

64
Comment 53

• There seems to be no mechanism for translating
  the minefield / mines PDU information
• Recommendation - Reject
• The mines PDUs are in IEEE 1278.1A-1998 and will
  therefore appear in v2

65
Minor Technical (Reprise)
66
Comments 39/40

• Missing attributes
• Recommendation - Accept
• Defines more missing attributes than comments 5/6
• Implementation dependent on resolution of
  comments 5/6/7/56

67
Comment 41

• Engine Smoke is not valid for Subsurface
  Platforms, Space Platforms and Cultural Features
• Recommendation - Accept
• If comment 5/6/7/56 passed then remove these
  attributes from the specified class
• Otherwise we need to add note specifying which
  attributes are valid for which entity types (see
  GRIM comment ???)