The discussion has been interesting and in some ways disappointing. I was somewhat surprised to read some of the emails that at least appeared on the surface to discount RTI-RTI interoperability as a significant concern. First, for those who feel that interoperability is not the purpose of HLA I would like to refer you to the HLA Transition Report on the DMSO Website from which I quote: RATIONALE FOR HLA USE ..... Thus, for reasons of capability, timeliness and cost-effectiveness, DoD needs a flexible, composable approach to constructing synthetic environments, bringing together simulations and live players in various combinations, as user needs dictate. This means that interoperability must be "built-in" to the maximum possible extent. This need was reflected in the 1995 Chairmans Program Assessment, which noted that the "lack of M&S interoperability is our largest shortfall" and in FY 1997 Defense Planning Guidance to "restructure M&S activities for interoperability and reuse." This section further establishes the need to be able to plug and play different collections of federates together in ever changing federations connecting not only fixed simulations but also live players and ranges. While FOM & SOM transportability is important to this architectural requirement, it is not sufficient unless the one of two conditions on RTI use is met: 1) A mechanism is provided for RTI-RTI interoperability, or 2) A single RTI is used by all participants in the federation. There has been a suggestion in HLA documents and discussions to date that since FOMs are transportable between RTIs that item 2 can be easily achieved. Unfortunately, this argument will not stand much scrutiny. It implies that a single vendor will develop an RTI that will work effectively in all domains and will be adopted by all. In other words, we have to assume that some vendor achieves a marketing monopoly and a technically optimal product. This is hard to imagine considering that we have yet to even produce a single RTI that will run on all necessary platforms saying nothing about differing communications topologies, networks, and performance requirements. Given that we can't reasonably count on item 2 occurring, we as a community need to focus on ways we might support RTI - RTI interoperability. Interoperability after all is in the name of the group (SISO). As to the specifics of how to achieve interoperability amongst RTIs, I have heard a number of approaches and points that need to be considered. First of all, there has been at least one email that has indicated that universal interoperability is a pipe dream. Stating this in a slightly different manner, I think we need to consider the requirements for RTI - RTI interoperability - they may not be universal. We may find out that all services may not be required to operate between dissimilar RTIs, we may find out that certain performance requirements for real-time operation may be relaxed across such an interface, etc. etc. etc... I'm not trying to take any position on these specific points I'm just pointing out that we need to establish the requirements for interoperability. I have also heard various arguments relative to the technical approaches that might be taken to achieve interoperability. Some discussions have centered on an on-the-wire standard, others on bridging technologies. Again, I don't want to take a position here on these points but any investigation should consider the merits of all possible approaches. Finally, Randy is right (and maybe a little wrong) when he discusses timeframe issues. This is not going to be solved instantly but I think we needed to start yesterday to address the problem because it will take some time to get to a solution. It would have been great if this had been considered from the start of the HLA effort but it wasn't. Unfortunately, it doesn't do any good to grouse about the past we only can be proactive in protecting the future. To move this a step forward per Michael's suggestion I will forward the following draft TOR for discussion. Terms of Reference - Version 0.1 1. The HLA Transition Report concludes that the rationale for adoption of the HLA derives out of its ability to support the grouping of federates into "different [interoperable] combinations ("federations") to satisfy a diverse and ever-evolving set of user needs." The document goes on to further state "that interoperability must be "built-in" to the maximum possible extent." At the same time, it has been indicated through several papers and reports to SISO that the HLA's interoperability goal may not be fully achieved unless some provision for communications between dissimilar RTIs is provided. Given the focus of the Simulation Interoperability Standards Organization on promoting interoperability, an understanding of the requirements and potential solutions for RTI to RTI interoperability is required to better shape the organization's future activities. 2. In particular, the SISO CC and SAC desire the Study Group to perform the following tasks: a. Provide a cogent definition of interoperability within SISO. b. Provide an assessment of current RTI interoperability limitations indicating the architectural and configuration issues limiting interoperability today. c. Provide an assessment of the community impacts that may result if RTI to RTI interoperability is not guaranteed. d. Establish through community discussion and input the requirements for RTI to RTI interoperability. e. Examine and evaluate the possible approaches to achieving RTI to RTI interoperability. f. Recommend an approach that will support an appropriate and necessary level of interoperability amongst HLA federates. As a final point, I would like to nominate Michael to chair the study group. I think Michael's emails indicate both his concern about the issue as well as his interest in promoting an active and open debate on the subject. Keith Briggs .
To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: