Message from [log in to unmask] sent 5/4/98 4:51 PM. >Randy et al: According to most recent interpretation by the AMG (I am >told), the reuse rationale for HLA is limited to the "reuse" of entity >presence...not the reuse of software in any sense. This sounds really >strange to me, but was provided (when challenged) by an AMG member. Tell me >I'm wrong. Please! [log in to unmask] >============================================= I'm not sure what is meant by "reuse of entity presence", but based on the definition from the HLA transition report below it would seem that federate and infrastructure reuse is the goal. If federates are generally small simulations or simulation components then this can imply a great deal. However, if JSIMS is constructed as a single federate I don't know if this buys you much. >>HLA compliance delivers new functional capabilities and allows different >>organizations to produce/maintain a diverse set of products >>(e.g., simulations, live system interfaces, utilities, runtime >>infrastructures) which can be wisely used together in different >>combinations as user needs dictate. This yields reuse of individual >>products and allows simulations to bring in new capabilities without >>having to build them. Keith Briggs -- The complete Rationale for HLA Use from the HLA Transition Report is provided below for reference. >RATIONALE FOR HLA USE > >To establish an informed perspective for dealing with HLA policy >implementation issues, the team first reviewed the rationale for >DoDs mandate of the HLA as "the standard technical architecture for all >DoD simulations." > >Advanced simulation can provide a powerful tool to help maintain >readiness, plan operational missions, make optimal investment >decisions, analyze force structure alternatives, and achieve dramatic >acquisition improvements. Simulations (a general term including >both pure-software, or "constructive," simulations and human-in-the-loop, >or "virtual," simulators) are abstractions of the real world. >Different user needs dictate different abstractions: different entities, >attributes and interactions must be represented, at different levels >of resolution and fidelity. These representations will, of necessity, be >implemented in different computing environments and run on >hardware platforms that range from personal computers to >massively-parallel, high performance computers. > >The DoD will thus need many different simulations. However, if the >Department is to use simulations cost-effectively, it needs the >flexibility to reuse simulations to the maximum possible extent, building >new representations only when existing simulations cannot >provide the needed capabilities. To get the greatest return on investment >for the simulations it does build and maintain, DoD must be >able to team these representations together in different combinations >("federations") to satisfy a diverse and ever-evolving set of user >needs. >Simulations must also be able to interoperate with various real-world, or >"live," systems, such as command and control systems, >weapon systems on instrumented ranges, and weapon system or sensor >components on test benches. This live system interoperability is >necessary to: > - facilitate test and evaluation of the live systems; > - deliver training, course of action analysis tools, and mission > rehearsal capabilities to humans operating those live > systems; and > - allow authoritative representation of the system and its > operator(s) in a simulation exercise being conducted for other > purposes. >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." >HLA compliance satisfies the most important condition for interoperability >and reuse: a common, efficient technical means to join >simulations together in federations, optionally including live players, >and exchange information in a coherent manner. However, the >HLA is not an interoperability "magic wand," that is, it will not >automatically make every simulation suitable for federating with >every other simulation nor guarantee a valid, meaningful exchange of >information across the federation. Prudent, common sense >planning is still required, but the HLA does provide the critical >technical foundation for the interoperability of simulations among >themselves, and with live systems. For this reason, the HLAs broad >adoption across DoD is essential. > >HLA compliance delivers new functional capabilities and allows different >organizations to produce/maintain a diverse set of products >(e.g., simulations, live system interfaces, utilities, runtime >infrastructures) which can be wisely used together in different >combinations as user needs dictate. This yields reuse of individual >products and allows simulations to bring in new capabilities without >having to build them. This in turn equates to reductions in time, expense, >and risk that justify the modest near-term costs of >transitioning legacy systems to the HLA. .
To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: