Sent From: [log in to unmask]

Graham Shanks wrote: >John Shockley wrote: >> ...I was going to suggest that Michael and I move our >> discussion to another reflector, since this one should >> probably be more oriented toward the business/admin sides of >> the workshop, but some fundamental issues for the SISO >> community have been raised. > >I think you should. The SIW-PRP only goes to a small number of >the whole SISO community. It seems to have moved to the RTI >reflector, which may not be much braoder. How about moving it >to the SISO-DISCUSS reflector? You would have to put out a >summary of the traffic so far for those who want to catch up. >Or at least summarising the information on SISO-DISCUSS and >pointing people to the fact that a real interesting >conversation is going on in a vociverous backwater of the >relfectors. Right after I suggested this, I became Reflector-challenged, i.e., I was dropped off several reflectors, including this one. I will try to get a message to SISO-DISCUSS to let people know that this is going on. However, if someone would like to try a digest, please be my guest. > >For the record, I support the setting up of a Study Group to >look into the subject, hold my hand up as having failed to >spot the omission by the CC, and, from my *personal* point of >view, refuse to get hung up about it at the moment. I think >that there are more pressing short term problems that we need >to solve first. For instance, I'm much more concerned about >geting an RTI (any RTI) to run on a real-time operating >systems (such as VxWorks) - until we get wider support than >the 4 workstation based OS types currently supported any >interoperability is doomed - leaving myself wide open for a >multitude of flames, but hey, Mike started it :-) > >But don't let me get in the way of anybody else worrying the >problem to death. I agree with you and Randy (and Jerry). This does seem to be a pretty big problem for a group to tackle right now. But, I have been encouraging the CC to set up a mechanism by which getting an official group going is rather straightforward; it's just more difficult to KEEP going. I.e., it's easy to get started, but the group has to produce something worthwhile to continue. In this way, the CC/SAC doesn't stand in the way of progress or innovation, but also doesn't encourage efforts that aren't fruitful. So, if a group of people are willing to look into the issue, GO FOR IT! >As for formally requests to another organisation, I think that >we should study the topic first, then consider if we should >send such a request in. I, too, think that we need to discuss this. Randy Saunders wrote: -snip- >> >>Michael obviously has a mental simulation domain in his mind that is >>homogeneous enough where it makes sense to think of them all agreeing on an >>intercommunications standard where they cannot or will not agree on a >>common RTI. I think the M&S universe is in fact so broad that it includes >>models that can not, should not and should not be made to intercommunicate >>by any language or means. Thus I get nervous when people start acting as >>if they are going to create rules and regulations to force such >>intercommunication. > >Not to put words in Michael's mouth, but I don't think he says this. >He doesn't say that all problems can be solved with one RTI, he says >that different RTIs are a good thing. He doesn't say all RTIs should >communicate among their own kind using the same technology they use >to communicate with RTIs of other kinds. He only says that we need >a standard way for RTI's to talk to dissimilar RTIs. Some sort of >Esperanto that can be used by all in cases where a federation cannot >find one RTI that fits all its needs. What I have seen in this discussion are: 1. The need for RTIs to be able to interoperate. There have been examples described that speak to this need. My initial assertion was that these examples were fairly specialized, but I will concede that they may not be as specialized as I had thought. To the extent that this issue can be studied now and there is a group willing to study it, I will support forming a group (see above). 2. The assertion that the inability of RTIs to interoperate is a fundamental failure of HLA, i.e., HLA will not facilitate interoperability. Here I disagree. HLA will "facilitate" interoperability by establishing a common framework for simulations. It creats a sort of language that enables simulations to be descibed and meaningful interoperability to be defined (SOM/FOM development process). I see these steps as critical in facilitating interoperability. In the plug-and-play world, much of the hard work was done in the begining and (hopefully) only once (DIS protocols). I see how attractive this is, and I don't believe that HLA precludes this. The RPR-FOM, whether it is a "reference," a "standard," or a "thing," it should enable those who want to plug-n-play to do so. What HLA does do, though, is make the federation developers sit down, determine how the simulations will interoperate, and determine whether this interoperability will meet their federation objectives. This is good stuff. As part of this process, I suspect that most federations will able to satisfy their objectives with a single version of the RTI. To the extent that they can't, they will (a) use a Bridge Federate, (b) find the results of this study group enlightening and very useful?, (c) redefine their objectives to match their budget, (d)? In any case interoperability will be facilitated. In my original message I claimed that HLA will facilitate interoperability for simulations; it will not guarantee it for all simulations (nor should it). I believe that there are some simulations for which interoperability simply makes no sense. We shouldn't force the issue. HLA provides for sensible interoperability. There was also an argument made earlier on this reflector that we are not the ones to decide on such issues, but we MUST be the ones to decide. We are the users and developers; we are knowledgeable ones. > >The force for universal interoperation is cost savings through reuse, >as directed in policy by Dr. Kaminski. Neither Michael of I are the >cause of these forces. The cause is DoD management. Once again, I don't believe the goal is universal interoperability (nor should it be). Just as a reminder, here is an excerpt from the Dr. Kaminski letter (from the DMSO web page): Under the authority of reference (a), and as prescribed by reference (b), I designate the High Level Architecture as the standard technical architecture for all DoD simulations. The baseline HLA is defined by three inter-related elements: HLA Rules Version 1.0 (v.1.0), HLA Interface Specification v.1.0, and HLA Object Model Template v.1.0. The evolution of the HLA will be managed by the DoD Executive Council for Modeling and Simulation (EXCIMS) through its Architecture Management Group (AMG). This structure provides a means for the DoD Components to identify and address any emergent issues in subsequent refinements to the HLA. Compliance with the HLA does not mandate the use of any particular implementation of supporting software such as the Runtime Infrastructure. John John Shockley (650) 859-4165 SRI International FAX (650) 859-5345 333 Ravenswood Ave. [log in to unmask] Menlo Park, CA 94025 >

To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: