1. Fall ‘99 Simulation Interoperability Workshop RTI Interoperability Study Group Final Report Michael D. Myjak, Chair

2. Agenda  RTI Interoperability Participants  Problem Statement  Objectives  RTI Interoperability SG Taxonomy  RTI Interoperability Use Cases  The Solution Space  Future Plans

3. RTI Interoperability  RTI Interoperability Chartered 98f-SIW  RTI Reflector  Lots ‘o Participants (w/ usual vocal minority)  Meeting via TC bi-weekly  Fact-to-Face in Dec. at I/ITSEC  Interim Report 99S-SIW  Final Report 99F-SIW

4. Problem Statement  The purpose of the HLA is to facilitate Interoperability and reuse among simulations and components. [Draft 1516.2]  However,  RTI Interoperability is a significant future problem.  FOM reusability is a significant future Problem.  Inevitable Result - Groupings of HLA users will form that use incompatible versions of the RTI.  Thus federations that span these groupings will not be readily realizable -- limiting HLA interoperability in an open system interconnected environment.

5. Study Group Objectives (1 of 2)  Define the term ”Interoperability"  as applied to HLA interoperability and the derived issue of RTI to RTI interoperability. Provide an assessment of current RTI to RTI interoperability limitations indicating the architectural and configuration issues.  Impact Assessment  Provide an assessment of the community impacts that may result if RTI to RTI interoperability is not achieved.

6. Study Group Objectives (2 of 2)  Establish the requirements for RTI to RTI interoperability through community discussion and input.  Examine and evaluate the benefits and impacts of possible approaches to achieving RTI to RTI interoperability.  Recommend an approach that will support an appropriate and necessary level of interoperability between RTI implementations.

7. RTI Interoperability SG Taxonomy (1 of 6)  Community  Is a combination of federations and RTIs working together to achieve a common goal. There are 4 combinations of homogeneous and heterogeneous federations/FOMs and RTI.  Homogeneous Federation  A named set of federates communicating using a common Federation Object Model (FOM).

8. RTI Interoperability SG Taxonomy (2 of 5) Duncan Clark  Heterogeneous Federations  Named sets of federates, within a community, that use multiple FOMs. There are three classes:  Hierarchical Federations: One federation appears as a federate or federate component of another federation.  Intersecting Federations: A federation that shares some common objects and/or interactions with another federation.  Adjacent Federation: Where two or more federations have similar objects and/or interactions, but are defined differently.

9. RTI Interoperability SG Taxonomy (3 of 5) Duncan Clark  Communication Architectures  The main architectures used to provide distribution of RTI state information between RTI components in an execution. There are three types (plus hybrids):  Networked – Most common type fielded to date. Typically Internet Protocol based LAN.  Shared memory – Higher performance usage, often requires custom or proprietary vendor platforms.  Scalable Parallel / MPI – Often produce the highest performance, specialized applications (e.g., hardware-in- the-loop).

10. RTI Interoperability SG Taxonomy (4 of 5) Duncan Clark  RTI:  A global collection of one or more RTI components that communicate data and control information necessary to support multiple federates in accordance with the rules and specifications of the HLA.  RTI Implementation:  An RTI from a single vendor that shares common private code and state information; RTIs that do not naturally share identical state are different implementations, even if they are from the same vendor.  RTI Component:  A component of the RTI.

11. RTI Interoperability SG Taxonomy (5 of 5) Duncan Clark  (Local or) Federate RTI component:  A component of an RTI that is installed and implements the RTI Federate Interface Specification (e.g., RTI Ambassador) to a single federate.  Heterogeneous RTI :  An RTI that includes several RTI Implementations that are not capable of directly sharing state so as to support the rules and specifications of the HLA.

12. Interoperability Definition Michael Myjak  "Interoperability means there is functional equivalence provided by interchangeable components within a system or process in order to allow its components to be able to work together with no prior agreement over an agreed upon data communications path."

13. Use Cases - Type 1 Michael O’Connor  Requirements. This is the current mechanism by which interoperability is achieved between federates using HLA. This is already producing benefits and accounts for most of the HLA applications that have been developed to date. Homogeneous FOM & Homogeneous RTI RTI

14. Use Cases - Type 2 (1 of 2) Michael O’Connor Heterogeneous FOMs & Homogeneous RTI RTI

15. Use Cases - Type 2 (2 of 2) Michael O’Connor  Requirements: Situations have arisen where projects wish to use multiple FOMs working together to achieve their objectives. This arises from situations such as:  Use of legacy systems where it may be difficult or cost-prohibitive to develop new FOMs.  Information Security where some information needs to be filtered or declassified before passing to federates in another federation.  Differing Levels of Fidelity where objects exist in two federations but with different representations

16. Use Cases - Type 3 (1 of 2) Michael O’Connor Homogeneous FOM & Heterogeneous RTIs RTI a RTI b

17. Use Cases - Type 3 (2 of 2) Michael O’Connor  Requirements: In this situation communities have been concerned that a single RTI Implementation will not be able to meet their needs for a variety of possible reasons:  Platform Support: including hardware, operating system and language.  Communications Architecture: The means of distribution may be different in different parts of the community.  Performance: Performance needs for particular services or particular aspects may need to be optimized.  Services: There may be situations where an RTI may deliver performance in a specialist area but not deliver the necessary services.

18. Use Cases - Type 4 (1 of 2) Michael O’Connor Heterogeneous FOMs & Heterogeneous RTI RTI a RTI b

19. Use Cases - Type 4 (2 of 2) Michael O’Connor  Requirements: In a generalized community, cost-effective vendor and platform-independent solutions drive situations where both heterogeneous federations and heterogeneous RTIs are needed. This model conforms to the Open System Interconnect initiative of the International Standards Organization.

20. Distributed Simulation Interoperability Model ApplicationInteroperabilityApplicationInteroperability ModelInteroperabilityModelInteroperability ServiceInteroperabilityServiceInteroperability CommunicationInteroperabilityCommunicationInteroperability FederateApplicationFederateApplication FOMs & SOMs FOMs RTIServicesRTIServices DistributedCommunicationsDistributedCommunications

21. The Solution Space RTI a RTI b GatewayProxyBrokerWire Protocol

22. Classical Federation (Use Case 1) ABCD Federate X XXX RTI N Network FOM J Objects

23. Federate Gateway (use case 2a)  Federate Gateway Approach:  A connection point providing information connectivity and translation between two (or more) distinct heterogeneous Federations, or  A connection point providing information connectivity and translation between one or more Federations and one or more External, non-HLA Applications.  And does not use the HLA Federate Interface

24. FOM Equivalence (use case 2a Gateway) ABCD Federate X X RTI N Network FOM J Objects JC’ K JD’ Non HLA Simulation Applications

25. FOM Equivalence (use case 2b Gateway) ABCD Federate X XXX RTI N Network FOM J Objects JK K

26. Federate Proxy  Federate Proxy Approach:  A connection point providing information connectivity and translation between two (or more) distinct heterogeneous Federations  Interoperability is accomplished through the services of the Federate API. The (Federate) Proxy appears as a Federate in each RTI implementation execution.

27. Federate Proxy Solution ABCD Federate X XYY RTI NP Network FOM J Objects JK K

28. RTI Broker (use case 3)  “ Brokered” API Approach -  Interoperability is accomplished through an RTI-to-RTI API.  This approach allows heterogeneous RTI implementations to communicate directly  May also be used between homogeneous RTI components within the same RTI Implementations

29. RTI Broker (use case 3) ABCD Federate X XYY RTI NP Network FOM J Objects NP

30. Protocol Solution  Wire Protocol Approach:  “On the wire” Interoperability is accomplished by requiring RTI vendors to use a standard protocol interface for communications between local RTI components and RTI implementations. Note: this approach allows Local RTI Components to share state information directly.

31. Protocol Solution ABCD Federate X XYY RTI NP Network FOM J Objects

32. Closing comments… or Delivery model for RTIs  If interoperability is inter-RTI...  then RTI suppliers will continue to use private protocols and deliver software support for federations as a unit.  If interoperability is intra-RTI...  The local RTI API solution and is implemented by standard protocols for all federates, software support can be delivered for the individual federate or platform as a unit.  This model follows the way communications Standards and protocols are delivered for global Internet connectivity.