STATUS OF REAL TIME PLATFORM REFERENCE FEDERATION OBJECT MODEL (RPR FOM) Peter Ryan1, Peter Ross1, Will Oliver1, and Lucien Zalcman2 1Air Operations Division, Defence Science & Technology Organisation (DSTO), 506 Lorimer St, Fishermans Bend, Melbourne, Victoria 3001. Email: [email protected] 2Zalcman Consulting. Email [email protected]

ABSTRACT Several advanced distributed simulation architectures and protocols are currently in use to provide simulation interoperability among Live, Virtual, and Constructive (LVC) simulation systems. Distributed Interactive Simulation (DIS) and High Level Architecture (HLA) are the most commonly used protocols/architectures in the simulation community. HLA is a general purpose architecture for distributed systems. To enable HLA federates to interoperate with DIS systems, the Real Time Platform Reference Federation Object Model (RPR FOM) was developed. The RPR FOM defines HLA classes, attributes and parameters that are appropriate for real-time, platform-level simulations. This paper provides a discussion of the current interoperability standards, an update on the status of the RPR FOM, and the implications for Australia.

1. INTRODUCTION Advanced Distributed Simulation (ADS) protocols and architectures were created so that various Live-Virtual- Constructive (LVC) systems could interoperate with each other in a simulated game or exercise in the same synthetic battlespace [1]. The simulation nodes may be collocated or may be geographically remote from each other.

Interoperability among such LVC systems can be improved using a specifically designed set of predefined interoperability standards. Such predefined sets of interoperability standards are commonly referred to as Modelling and Simulation Standards Profiles (such as the NATO Modelling and Simulation Standards Profile [2]).

2. US LVC ARCHITECTURE ROADMAP STUDY In the US, the LVC Architecture Roadmap (LVCAR) Study found that the principal systems in use for simulation interoperability are Distributed Interactive Simulation (DIS), Aggregate Level Simulation Protocol (ALSP), High Level Architecture (HLA), the Common Training Instrumentation Architecture (CTIA), and the Test and Training Enabling Architecture (TENA) [3]. A survey of 110 LVC US sites carried out by the US Department of Defense during the LVCAR Study indicated that DIS and HLA are the most widely used. These results are shown in Figure 1. DIS and HLA comprise about 70% of the surveyed systems. Within Australia, only DIS and HLA are commonly used to the author's knowledge with some minor use of TENA for live training range systems.

Current Status of Architectures in Use Percentage

Architecture

Figure 1: 2007 Survey of architectures used for Simulation Interoperability carried out during the LVC Study [4].

3. DISTRIBUTED INTERACTIVE SIMULATION DIS enables (real-time) interoperability among LVC systems using Protocol Data Units (PDUs) in a synthetic environment. These PDUs comprise data packets that are broadcast over the simulation network. DIS PDU standards were developed under the guidance of the Simulation Interoperability Standards Organisation (SISO) [5] and formally approved by IEEE [6-8].

The IEEE DIS standard is currently being extensively revised with balloting expected to be completed in 2012 as the IEEE P1278.1-2012 standard [9]. The IEEE DIS standard precisely defines the format of the DIS PDU data packets sent over the network and is therefore referred to as a “wire standard”. The DIS versions are summarised in Table 1.

Table 1: DIS Protocol version numbers DIS DIS Protocol Version Version 0 Other 1 DIS 1.0 (May 1992) 2 IEEE 1278-1993 3 DIS 2.0.3 (May 1993) 4 DIS 2.0.4 (March 1994) 5 IEEE 1278.1- 1995 6 IEEE 1278.1a- 1998 7 P1278.1-20XX

4. HIGH LEVEL ARCHITECTURE High Level Architecture (HLA) is a general purpose architecture for distributed computer simulation systems [10]. HLA comprises:

. Interface Specification that defines how HLA compliant simulators interact with the Run-Time Infrastructure (RTI) [11, 12]; . Object Model Template (OMT) that specifies what information is communicated between simulations and how it is documented [13, 14]; and . HLA Rules that the simulation must obey to be compliant to the standard [15, 16].

In contrast to DIS, HLA does not specify the format of the data packets sent around the network leading to interoperability issues. HLA is known as an API (Application Programmer Interface) standard in contrast to DIS which is a “wire standard”.

HLA was initially developed by the US Defense Modeling and Simulation Office (DMSO); this version is known as HLA 1.3. It was further standardised by IEEE in the early 2000s; this version is known as IEEE 1516 [15]. Dynamic Link Compatibility (DLC) was added to enable simulation developers to interchange link compatible HLA RTIs without recompiling federate source code [17, 18].

HLA has been recently revised (March 2010) with the new standard being known as HLA Evolved [16]. New features include modular Federation and Simulation Object Models, web services support through the Web Services Description Language (WSDL) API, fault tolerance support services, smart update rate reduction, and encoding helpers. A summary of HLA Evolved is provided in [19]. The versions of HLA are summarised in Table 2.

Table 2: HLA Versions HLA Version Date HLA 1.3 1998 IEEE 1516-2000 2000 HLA Evolved (IEEE 2010 1516-2010) To ensure interoperability among a federation of HLA federates requires [20]: • That each federate must use the same FOM • That each federate must either use the same HLA standard, such as HLA 1.3, IEEE 1516-2000 or HLA Evolved or provide interoperability among the different standards. • That each federate must use the same version of the same manufacturer’s RTI. RTIs from different manufactures will not be interoperable and there are also likely to be differences between RTI software releases from the same manufacturer. This paper summarises the current status of the HLA Real-time Platform Reference ROM (RPR FOM). The RPR FOM is essential for enabling interoperability with other real-time simulations in a mixed DIS/HLA environment but it can also be used to provide DIS capabilities in a pure HLA environment.

5. REAL TIME PLATFORM REFERENCE FOM 5.1 What is the RPR FOM? While the various HLA standards dictate how federates exchange data, a Federation Object Model (FOM) is required to define what information is communicated among federates within a particular federation. That is, in order to communicate, a set of federates must agree on a common FOM.

HLA does not mandate the use of any particular FOM, however, several reference FOMs have been developed to promote a-priori interoperability. Reference FOMs provide ready-made HLA constructs that are supported by a wide variety of tools and federates.

A reference FOM can be used as-is, or can be extended to add new simulation concepts that are specific to a particular federation or simulation domain.

The RPR FOM is a reference FOM that defines HLA classes, attributes and parameters that are appropriate for real-time, platform-level simulations. Applications that previously used DIS (or would have considered using DIS), often use the RPR FOM (or a derivative of it) when they interoperate in a HLA synthetic environment. The RPR FOM was developed by a SISO Product Development Group (PDG). Its goal was not to just implement the DIS PDU structures within HLA object and interaction classes, but rather to provide an intelligent translation of the concepts used in DIS to a HLA environment.

DIS concepts such as dead reckoning, the DIS geocentric coordinate system (WSG84), and standard DIS enumerations [21] are also used in RPR FOM systems.

The RPR FOM is a reference FOM that “has been specifically designed to organise the attributes and interactions of DIS into a robust HLA object hierarchy” [22]. Specifically it sets out to:

. Support transition of legacy DIS systems to HLA; . Enhance a-priori interoperability among RPR FOM users; and . Provide a reference FOM to enable interoperability among HLA and DIS LVC systems.

5.2 How Does the RPR FOM Work? .1 RPR FOM Classes Objects in the RPR FOM are organised into a four level class hierarchy. Classes are separated by logical distinctions between groups of attributes. The RPR FOM provides a mapping between DIS PDUs and their data fields, and HLA objects and interactions. DIS uses:

. State PDUs that update the state of an entity or other object. Typical state PDUs are the Entity State and Electromagnetic Emission PDUs; and . Transient PDUs that are sent once per specific event. Typical transient PDUs are the Fire and Detonation PDUs.

HLA uses class objects to define state data and interaction objects to define transient events (including radio communication). Class Objects and Interaction Objects have attributes and parameters as data fields. Thus DIS State PDUs map to RPR FOM class objects and DIS Transient PDUs map to RPR FOM interaction objects.

.2 Mapping between State PDU and RPR FOM Table 3 shows the mapping between the (state) DIS Entity State PDU and the RPR FOM. The Entity State PDU fields are mapped to the BaseEntity, PhysicalEntity, EnvironmentalEntity, Sensor, Munition, and Lifeform classes in the RPR FOM. Note that the Entity State PDU fields are not listed in the order in which they appear in the DIS PDU.

Table 3: Mapping between the DIS Entity State PDU fields and HLA RPR FOM Classes

DIS Field FOM Class FOM Attributes

PDU Header N/A

Entity ID BaseEntity EntityIdentifier

Force ID PhysicalEnti ForceIdentifier ty

Number of PhysicalEnti size of Articulation ty ArticulatedParameters Parameters Array

Entity Type BaseEntity EntityType

Alternative PhysicalEnti AlternativeEntityType Entity Type ty

Entity Linear BaseEntity VelocityVector Velocity

Entity Location BaseEntity WorldLocation

Entity BaseEntity Orientation Orientation

Entity BaseEntity IsFrozen Appearance Environmen OpacityCode talEntity

PhysicalEnti DamageState, ty EngineSmokeOn, FlamesPresent, etc (following section 4.3 of the enumerations document [21])

Platform AfterburnerOn, AntiCollisionLightsOn, etc (following section 4.3 of [21])

Sensor AntennaRaised, BlackoutLightsOn, InteriorLightsOn, LightsOn, MissionKill (from [21]) DIS Field FOM Class FOM Attributes

Munition LauncherFlashPresent

CulturalFeat ExternalLightsOn, ure InternalHeatSourceOn, InternalLightsOn

Dead BaseEntity DeadReckoningAlgorit Reckoning hm Parameters (DRP): Dead Reckoning Algorithm

DRP: Entity BaseEntity AccelerationVector Linear Acceleration

DRP: BaseEntity AngularVelocityVector Parameters: Entity Angular Velocity

EntityMarkin PhysicalEnti Marking g ty

Capabilities PhysicalEnti HasAmmunitionSupply ty Cap, HasFuelSupplyCap, HasRecoveryCap, HasRepairCap

Lifeform PrimaryWeaponState, SecondaryWeaponStat e

Articulation PhysicalEnti ArticulatedParameters Parameters ty Array

.3 Mapping between Transient PDU and RPR FOM Table 4 shows the mapping between the (transient) DIS Fire PDU fields and the RPR FOM WeaponFire Interaction Class. The DIS Fire PDU is a transient PDU that is issued when a weapon is fired. For example, whereas the DIS implementation has velocity defined by three floating point values for the x, y, and z components; the RPR FOM has velocity defined by a vector: InitialVelocityVector which is defined as a type VelocityVectorStruct, a structure with three 64 bit floating point fields.

Table 4: Mapping between the DIS Fire PDU fields and HLA RPR FOM WeaponFire Classes

DIS Field FOM FOM Attributes Class PDU Header N/A Firing Entity Weapo FiringObjectIdentifier DIS Field FOM FOM Attributes Class ID nFire Target Entity Weapo TargetObjectIdentifier ID nFire Munition ID Weapo MunitionObjectIdentifier nFire Event ID Weapo EventIdentifier nFire Fire Mission Weapo FireMissionIndex Index nFire Location In Weapo FiringLocation World nFire Coordinates Burst Weapo MunitionType Descriptor: nFire Munition Burst Weapo WarheadType Descriptor: nFire Warhead Burst Weapo FuseType Descriptor: Fuse nFire Burst Weapo QuantityFired Descriptor: nFire Quantity Burst Weapo RateOfFire Descriptor: Rate nFire Velocity Weapo InitialVelocityVector nFire Range Weapo FireControlSolutionRange nFire .4 Mapping between DIS bit fields and RPR FOM Despite using the same information model to describe the synthetic battlespace, RPR FOM and DIS do not always represent information identically. Appreciating these differences is essential when implementing gateways between HLA RPR FOM based systems and DIS systems.

As shown in Table 4, the DIS Entity Appearance field, a 32-bit record defined in [21], is mapped to FOM attributes of the BaseEntity, EnvironmentalEntity, PhysicalEntity, Platform, Sensor, Munition, and CulturalFeature RPR FOM classes. For example, bit 0 in this record defines Paint Scheme; if set to 0 the entity has a uniform colour; if set to 1, the entity is camouflaged. In the RPR FOM, this feature is described by the CamouflageType attribute in the PhysicalEntity class [22].

It should be noted that whereas DIS packs this information into a single 32-bit field, HLA will generally map each single bit field or multiple bit fields to a multiple of byte fields. For example, bit 23 of the Entity Appearance field specifies whether an entity is active (bit set) or inactive (set to 0). The RPR FOM will employ an 8-bit field to represent active status.

The RPR FOM uses signed integers for storing enumeration values, whereas the DIS standard requires enumerations to be stored as unsigned integers. This creates mapping problems when enumerations are defined above the maximum signed value. For example, within the EmitterSystem class, the EmitterType field is a signed 16-bit integer (a number in the range 0 – 32767), whereas the corresponding DIS field is a 16-bit unsigned integer (a number in the range 0 – 65535). Enumerations for this field are defined well above the maximum 16-bit signed value [21]. 6. STATUS OF THE RPR FOM IN SISO

6.1 RPR FOM Standardisation RPR FOM 1.0 became a SISO Standard in 1999 with designation SISO-STD-001.1-1999 [22]. A companion document, known as the GRIM (Guidance, Rationale, and Interoperability Mappings) provides additional documentation for the RPR FOM [23].

RPR FOM 1.0 is based on the IEEE 1278.1-1995 version of the DIS Standard [7]. Thus it does not include the 1998 update and lags well behind the 2012 revision.

Following completion of RPR ROM 1.0, work commenced on developing RPR FOM 2.0 that was based on the IEEE 1278.1a-1998 addendum. It was intended that RPR FOM version 2.0 would also become a SISO standard.

6.2 Product Development Group 2009 Update In 2009 SISO announced that the Product Development Group (PDG) for RPR FOM version 2 had been cancelled. This PDG had been active for many years developing successive drafts of the revised RPR FOM. In their communication dated June 4, 2009 [24], they stated that: The Standards Activity Committee (SAC) determines that the Product Development Group is failing to make progress. This situation may be marked by a loss of leadership and the failure to replace it; a schedule slippage greater than one year; a failure to meet for two consecutive Simulation Interoperability Workshops (unless the Product Development Group (PDG) is meeting regularly in other venues); a lack of activity on the PDG's discussion; or a failure to provide feedback to the PDG's Technical Area Director. The SAC should seek all possible remedies for such PDGs. However, if the SAC and PDG are unable to identify a remedy, the SAC will recommend the PDG be dissolved. The report further noted that: . The RPR FOM PDG has a long history with SISO. It produced SISO’s first standard in 1999 (SISO-STD- 001-1999) [22] and had been working toward a second version of that standard for the past 10 years; . Considerable effort has gone into that process and 18 drafts have been produced. Draft 2.17 made it to ballot in 2005 but failed; . After the most recent ballot failure a comment resolution period commenced and a Draft 18 was started and produced over the course of several years which addressed all the comments; and . Balancing the original 2.0 ballot was difficult due to lack of contributors The report further recommended that: . Upon dissolution of the PDG the SAC will move to open a Product Support Group (PSG) to support the existing RPR FOM Standard; and . The draft work produced towards version 2.0 will be maintained by the PSG until a new PDG can be formed.

6.3 Updates from Recent Simulation Interoperability Workshops At the 2011 Spring Simulation Interoperability Workshop (SIW) held in Boston, a meeting of interested parties was held. This meeting resolved to revive the RPR FOM standardisation effort and volunteers were invited to participate.

This interest was continued at the following 2011 Fall SIW and it was proposed to create a RPR FOM Product Support Group that would lead to a RPR FOM PDG. However, it was found that the original RPR FOM PDG has never been officially dissolved and it could continue its work to standardise RPR FOM 2. The rescoped RPR FOM 2 Product Development Group will now:

. Finalise a complete and correct RPR FOM v2 that supports HLA 1.3, HLA 1516-2000 and HLA Evolved (1516-2010). RPR FOM 2.0 will then become an approved SISO standard; and . Examine developments in DIS 7 (P1278.1-20XX [9]), Link 16, and NATO Education and Training Network for their relevance to future upgrades of the RPR FOM.

6.4 What are the Implications for the Australian Defence Organisation? How will this affect the Australian simulation community, and in particular the Australian Defence Organisation (ADO)? The objective of developing RPR FOM 2 was to enable HLA developers to comply (ie interoperate appropriately) with the DIS IEEE 1278.1a-1998 interoperability standard [8]. The RPR FOM 1 standard only addresses the 1995 and earlier versions of DIS and is unable to handle features introduced into the latest 1278.1a (1998) standard. Further, during the past six years, the DIS standard has greatly evolved and is now on the verge of being balloted by IEEE as an updated (P1278.1-2012) standard. The present situation is summarised in Table 5.

Table 5: Matrix for RPR FOM version and equivalent DIS functionality

RPR DIS Features Equivalent Version

1.0 IEEE Appearance and movement of entities; weapons 1278.1- firing; detonation of ordnance; collisions; 1995 logistical resupply; voice radio and tactical data links; simulation management, electromagnetic emissions; laser interactions

2.0 IEEE Additional support for emissions, entity 1278.1a- information/interaction, underwater and mine 1998 warfare, entity management, field instrumentation, communications and 3.01 IEEE Theit new draft DIS standard includes an extensive P1278.1- revision, clearing up ambiguities and adding 200X additional capabilities for Directed Energy (draft weapons, Damage Status, Information Operations, standard) Transfer Control, Electronic Warfare, IFF, and the ability to extend existing PDUs with the new Attribute PDU.

Problems may arise if features supported by later versions of DIS are implemented as shown in Table 5. A simulator with a RPR FOM 1.0 compliant interface will be unable to communicate information concerning IFF, underwater acoustics and mine warfare information, for example, with other IEEE 1278.1a- compliant simulations that make use of these features.

Similarly the more advanced features available in the new version of DIS will be unable to be implemented in a RPR FOM 1.0 or RPR FOM 2.0 compliant simulator. Careful exercise design may be required if DIS simulations are required to interoperate with simulations that use versions of the RPR FOM that do not support the latest DIS features.

6.5 Need for a RPR FOM Version 3.0 and later Versions? When RPR FOM 2.0 is complete, does the community need to develop another version RPR FOM 3.0, to address the latest changes in DIS? A different approach may be adopted for future RPR FOM revisions that make use of new features of HLA Evolved. This revision allows for modular FOMs thus enabling new modules to be introduced into an already active federation. The process will be to decompose the existing RPR FOM into modular FOMs based on either PDU families (such as Entity Information/Interaction, Warfare, Management etc) or functional subsets such as the minimum set of PDUs required for basic interoperability (a basic set would comprise Entity State, Fire, Detonation, and Emission PDUs). All that is then needed to embrace new DIS functionality in the HLA RPR FOM environment is that a new module containing the latest changes needs to be developed. Thus, to encompass the Information Operations functionality in the RPR FOM, an IO module would need to be developed. This considerably simplifies future upgrading of the RPR FOM.

1 RPR ROM 3.0 was planned to adopt the changes introduced into t upgraded version of DIS 7. SUMMARY The RPR FOM is critical to achieving interoperability among DIS and HLA systems in a mixed protocol environment. SISO developed the original RPR FOM 1.0 in 1999 but suspended further development due to lack of contributors.

This is of concern for the ADO as it seeks to expand its suite of interoperable simulators either by adding interfaces or gateways to legacy simulators or by specifying simulator interoperability in the initial Project. With the revival of the standardisation effort, this situation may be ameliorated with the release of future RPR FOM SISO standards. For further upgrades of RPR FOM, features of the HLA Evolved standard will be exploited to “simplify” the standardisation process.

8. REFERENCES 1. IST (1994) DIS Vision: A Map to the Future of Distributed Simulation. Orlando, Florida, US, Institute of Simulation and Training (IST), University of Central Florida 2. NATO (2009) NATO Modelling and Simulation Standards Profile. AMSP-01(A), NATO 3. Henninger, A. (2007) LVC Architecture Roadmap (LVCAR) StudyWashington, DC, Modelling and Simulation Coordination Office 4. Richbourg, R. and Lutz, R. (2008) Live, Virtual, Constructive Architecture Roadmap (LVCAR) Comparative Analysis of the Architectures (Document 2 of 5). 5. Simulation Interoperability Standards Organization (SISO). [Accessed; Available from: www.sisostds.org. 6. IEEE (1993) IEEE Std 1278-1993: IEEE Standard for Information Technology - Protocols for Distributed Interactive Simulation Applications: Entity Information and Interaction. 7. IEEE (1996) IEEE Std 1278.1-1995: Standard for Distributed Interactive Simulation - Application Protocols. 8. IEEE (1998a) IEEE Std 1278.1a-1998: Standard for Distributed Interactive Simulation - Application Protocols. 9. IEEE (2010c) IEEE P1278.1-20XX: Standard for Distributed Interactive Simulation - Application Protocols, Draft 15. Simulation Interoperability Standards Organisation. 10. Dahmann, J. S., Fujimoto, R. M. and Weatherly, R. M. (1997) The Department of Defense High Level Architecture. In: Winter Simulation Conference, Atlanta, Georgia, US: 7-10 December 1997 11. IEEE (2001a) IEEE Std 1516.1-2000: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification. 12. IEEE (2010a) IEEE Std 1516.1-2010: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification (Revision of IEEE Std 1516-2000). 13. IEEE (2001b) IEEE Std 1516.2-2000: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification. 14. IEEE (2010b) IEEE Std 1516.2-2010: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification (Revision of IEEE Std 1516-2000). 15. IEEE (2000) IEEE Std 1516-2000: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules. 16. IEEE (2010) IEEE Std 1516-2010: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules (Revision of IEEE Std 1516-2000). 17. SISO (2004) SISO-STD-004.1-2004: Dynamic Link Compatible HLA API Standard for the HLA Interface Specification IEEE 1516.1. 18. SISO (2004) SISO-STD-004-2004: Dynamic Link Compatible HLA API Standard for the HLA Interface Specification Version 1.3. 19. Möller, B., et al. (2008) HLA Evolved – A Summary of Major Technical Improvements. In: Fall Simulation Interoperability Workshop 2008, Orlando, Florida 20. Tudor, G. and Zalcman, L. B. (2006) HLA Interoperability – An Update – SimTecT2006. In: SimTecT 2006, Melbourne, Australia: May 29 - June 1, 2006 21. SISO (2011) Enumeration and Bit Encoded Values for Use with Protocols for Distributed Interactive Simulation Applications. SISO-REF-10, Simulation Interoperability Standards Organisation 22. SISO (1999) Real-time Platform Reference Federation Object Model (RPR-FOM 1.0). In SISO-STD- 001.1-1999. Simulation Interoperability Standards Organisation. 23. SISO (1999) SISO-STD-001-1999: Guidance, Rationale, & Interoperability Modalities for the RPR FOM (GRIM 1.0) Simulation Interoperability Standards Organisation. 24. SISO. SISO RPR FOM Dissolution. (2009) [Accessed; Available from: http://discussions.sisostds.org/threadview.aspx?threadid=45989.