RE: First Shot SiteManager SISO SiteManager <a href="/index.htm?LOGON=A3%3Dind9710%26L%3DZ-ARCHIVE-SIW-RFOM%26E%3Dquoted-printable%26P%3D35186%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a>
Sent From: [log in to unmask]

John, Randy; Robert, I thought developing the TOR w/ Mark Plasket was tough going, :-) but you gentlemen have presented some pretty heady thoughts. And I thought ALL we were supposed to do was answer the question: "Should SISO support and standardize Reference FOMs?" After reading your postings, I don't think I know the answer to that yet. Having had some experience with the Platform Proto-Federation (PPF) FOM-a-roma (the FOM build process as we came to know it by), the answer may be a resounding YES. Most of the PPFs preparation work was spent figuring out the FOM. We had to decide what we could not utilize between our legacy systems, and then figure out how to represent what we could use between us. Each of our four legacy systems had its own unique set of quirks. And may be the answer is that each federation is so different from any other that there is no easy answer. But what if there was a RPR Reference FOM? If such a FOM was available, could we have made use of it? Most assuredly. Even though our contribution was a SIMNET system, I think having a previously developed Reference FOM available for our review would have made live easier. But could we have adopted that FOM if it existed? Perhaps... but it is not clear whether or not that would have been possible as we did not have source code control over the SIMNET tank simulator. I feel confident that we could have started with a RPR FOM, modified it to fit the SIMNET characteristics. This would not have eliminated our multi-man-month FOM-a-roma, but it would have greatly reduced the cycle time. So I am inclined to believe that if we had a previously existing RPR FOM, we may have been able to shave a lot time and therefore cost off our own build process. Hmmm.. this seems to imply that the question is may be moot. You all have laid out some pretty convincing issues... John and Robert especially so. On one hand, if we do create Reference FOMs, then we have drawn the proverbial "line in the sand." We have identified specific content, in the Reference FOM, which federates must in that federation must adhere to. On the other hand, if we do not have standard Reference FOMs to work from, then each federation must experience their own FOM-a-Roma... and there will be no standard content in our HLA metaphor from federation to federation. So what is the alternative? To develop multiple FOMs, perhaps one for each "use case" (e.g., Federation). Can we estimate how many FOMs might be developed if the no-Reference FOM path were taken? We can postulate that many FOMs will evolve, each with slightly different adaptations of the same content... perhaps even different implementations of precisely the SAME content. Therefore it is quite reasonable to conclude that from any given collection of simulators in a given domain, one can evolve a rather large number of FOMs, each with a different combination or definition of attributes. AND that that number would double every time a new simulator is brought into the mix. Randy postulated the argument that standardizing FOMs like standardizing DIS, might cause that standard to be misused... I think the example was in reference to procurement officials. No matter... Standard developers have historically had little influence (or vision) when it comes to applying a given standard. Users on the other hand, may take a standard designed for one purpose and adapt it to suite another purpose. That is called reuse and is entirely within their right. A user may choose to take a given standard, like a RPR FOM, and extend it, evolve it, or bend it (meaning use only parts of it) to suit their purpose. As standard developers, we cannot foresee what users will do with a standard... we can only put forth the effort to create it... in the open, or not. Content free, or content sensitive, which shall it be? The lack of content in the HLA definition is the one thing that the RD&E forum is crying out for. The RTI&C forum is also concerned with this area. Consider the simple example of what describes an integer... 32-bit or 64-bit? Big endian or little? These are typically decisions influenced by architecture; choice of vendor, and software implementation designers. Therefore I conclude that within a given domain, there are certain aspects of the content, specific parts and pieces, that CAN and Should be standardized. I think I'm beginning to formulate an opinion... so here it is... I believe I've convinced myself that the community should make the ultimate decision to standardize FOMs (i.e., federation content). And we (SISO) need to recognize that need and support the standardization of Reference FOMs as SISO Standards That's my $0.02 worth... Best regards - Michael Myjak, RTI&C Forum Chair Senior Research Scientist Institute for Simulation and Training University of Central Florida * 3280 Progress Drive * Orlando, Florida 32826 email: [log in to unmask] * voice: 407.658.5043 * FAX: 407.658.5059

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