In reply to the post from Peter Ross, with thanks for that contribution.


I had noticed this combination of two enumerations from SISO-REF-010 into one for the RPR FOM too. Since it also exists in RPR FOM v1, and found exactly the same enumerators in the EBV document from 1995, I assume that the original RPR FOM PDG decided to combine these bits from the appearance field into one enumeration for RPR FOM.

It may be a good idea to spend some words in the GRIM on the usage of the attribute CamouflageType of the object class PhysicalEntity.
For this is the base class of all platform, life form, cultural feature, expendables, munition, radio, sensor, and supplies kind of entities. However, only for the GroundVehicle platform and Sensor kinds the details on the camouflage are specified in SISO-REF-010. For the majority of the other kinds the bits 17 and 18 of the appearance field are not used. And for the life forms these bits are part of the range to specify the life form state (aka stance code). So where we have capabilities with the RPR FOM to detail the type of camouflage for all these entity kinds, even for life forms, these cannot be mapped (in e.g. a gateway) to their corresponding DIS entities.
I propose that in the GRIM a table is introduced similar to the already existing one on "Platform Attributes" (currently Table 7). I will do that in my contribution to the Physical module.


This enumeration is used to distinguish the different possible content of the SpreadSpectrum attribute of the RadioTransmitter object class, by using the SpreadSpectrumVariantStruct. As such, it matches the different specifications given in SISO-REF-010 for the modulation parameters, section 9.1.7.

The enumeration from SISO-REF-010 you are referring to (uid 154) does not have an equivalent in the RPR FOM. Actually, it is not an enumeration, but a 16-bit Boolean array; thus multiple spread spectrum modulation types can be used simultaneously. As with other Boolean bit fields, this is reflected in the RPR FOM by using dedicated Boolean attributes. However, I can only find the attribute TimeHopInUse…

Maybe the assignee of the Communication module, Aaron Dubois, is able to answer why the other types, frequency hopping and pseudo-noise are not available as distinct Boolean attributes.


From the perspective of dedicated enumerations, each with their own uid, it is correct to state that the RPR FOM enumeration is a union. However, from the perspective of the Sensor Types field these distinct enumerations form in fact one big enumeration. For SISO-REF-010 also specifies that the category enumeration is detailed in bits 0-3, and the subcategory in bits 4-15. So an attribute using the MineFieldSensorTypeEnum32 can correctly represent the Sensor Types field without violating the SISO-REF-010.

However, what is quite strange is that for the RPR FOM enumeration a 32-bit enumeration has been chosen. Given the specification of this field in IEEE 1278.1a and accordingly in SISO-REF-010, a 16-bit unsigned enumeration would have been sufficient. (Maybe this was done at a time that already the issue with unsigned integers in the HLA specification had been identified, which has not been solved by using unsigned integers for all enumerations in the RPR FOM.)


It has already been identified in the post from Andy that I made a mistake here. Since the 'hull mounted masker' is a Boolean bit, it has already been correctly specified as a Boolean attribute in the RPR FOM class PropulsionNoise. This enumeration will be corrected by removing the additional enumerators.


A kind request to the reviewer of the Simulation Management module, Åsa Falkenjack, to look into the necessity to have the additional enumerator 'Standard'.


I consider it unfortunate that SISO-REF-010 does not provide for an articulated part type that cannot be specified by any of the listed types.
I agree that exchanging information about such an articulated part is typically useless for any receiving simulation, as it is unknown to which part on an entity to map this. It would then be better to agree (in a Federation Agreement Document) on a special type with an own (non-conflicting) enumerator value.
Nevertheless it would be good if such an articulated part could then also be mapped to 'Other' for federations where such an agreement does not exist. This would enable the existence of such a part to be recognized on the network without potentially using an enumerator value mapped to another type (e.g. for internal use) in a receiving federate. Hence I advise to keep this enumerator 'Other'.

It might indeed be worthwhile to contact the ENUM WG with requests from the RPR FOM PDG to modify certain enumerations. I propose that we wait with this until the RPR FOM v2 is ready for balloting.

EnvironmentDataSampleTypeEnum16 and EnvironmentModelTypeEnum8

A kind request to the reviewer of the Synthetic Environment module, Patrice Le Leydour, to find an explanation of the existence of the field SampleType in the structure GridDataStruct and the attribute ModelType of the object class EnvironmentProcess. This may explain the source of these enumerations. Should it appear that these enumerations are explicitly specified in IEEE 1278.1a, without a reference to the EBV-DOC, these enumerations are to be moved into the SE module.


Indeed the ENUM2002 document contained the enumerator 'Unused' with value 0 for the Entity Marking, as did the EBV document from 1995. Hence I am also surprised to see that the RPR FOM v1 enumeration listed this enumerator value as 'Other'.

However, the latest SISO-REF-010 does no longer contain this enumerator. This allows me to used the same argumentation as for the articulated parts type, and propose to keep the additional enumerator 'Other'.


I also had my doubts on this one. So far I felt it would be better to not specify enumerators for the ranges 1-511 and 906-1023. This would allow for federation specific enumerators, to be specified in a Federation Agreements Document, to be specified with meaningful names. Unfortunately the 'Other Attached Parts' is already present since RPR FOM v1, so maybe it is best to not remove this one.


To unsubscribe from the SAC-PDG-RPR list, click the following link: