Models, Gaming, and Simulation - Session 11

1. Models, Gaming, and Simulation - Session 11 The Future of Combat Modeling and Simulation

2. Topics • Issues in M&S • Hardware Improvements • Software Improvements • Implications for M&S • Distributed Simulations • History and Vision • DIS • HLA

3. Issues in Modeling and Simulation • The “Base of Sand” problem undermining DoD simulations. • Published in 1990, updated in 1991 by Rand Corp. • Led to substantial changes in DoD management of simulation • Many of the issues raised are still problems in the DoD M&S community • Interoperable and Composable Simulations - • “Impedance Mismatch”, i.e., disparity of fidelity • Algorithmic inconsistency • Violation of the “Anti-Black Box” principle of the use of models • Variable-resolution simulations • Non-Linear Nature of Combat Simulations • Small changes in input results in large, unpredictable changes in output • Mathematical chaos characterizes both combat, and simulations, even in simple models. • Thus, predicting the outcome of battle is impossible. Much analysis ignores this. • Modeling Military Operations Other Than War (OOTW) • Peacekeeping and Humanitarian Relief Operations • Stability and Support Operations • Mobilization and Deployment • Anticipating hotspots in the world

4. Issues in Modeling and Simulation • Rapid Terrain Generation • It now takes enormous effort and funding to gather terrain data and create special-purpose terrain databases for use in simulations. Much of the effort is due to the need for human assistance in the process. • In the age of computer-supported forces which are deployable anywhere in the world, terrain databases must be readily available to take advantage of automation. • The Vision: High-flying reconnaissance gathers terrain data while a quick reaction force is enroute to a military operation; The data is processed and downloaded to the force’s computers in flight, and mission rehearsal is possible in real time. • Terrain Visualization • 3D real-time visualization is important for interactive system-level simulations • Dynamic Terrain • Automatic Scenario Generation • Largely a problem of automated planning • Analyst’s Workstation • An end-to-end integrated suite of scenario development and analysis tools does not exist.

5. Issues in Modeling and Simulation • Support for Operations Planning • Simulations have been very useful in Training and Analysis, but not as much in Planning for upcoming combat operations. • Why? • Scenario-building can be done up front for training or analysis • Training objectives are defined up front; scenarios are designed to set the stage for trainees to achieve those objectives. • Study objectives are defined up front; scenarios built to evaluate whether the system under test performs adequately to meet those objectives. • But the “scenario” IS the problem in planning: • Scenarios (“courses of action”) are built and analyzed in real-time, usually under time constraints. • A primary goal is to see how a COA might play out.

6. M&S Technology Improvements REQUIREMENTS Analysis Requirements Training Requirements Army & DOD M&S Programs Software Paradigms and Capabilities CAPABILITIES Hardware Improvements

7. Technology Improvements: • Hardware improvements are driving improvements in software and hence in M&S. • Software improvements have provided new programmer paradigms and promised increases in speed and efficiency. • Object-Oriented Design and Programming • Artificial Intelligence • Parallelism • Distributed Systems • Various programs have grown out of emerging software and hardware capabilities, for example: • DIS • HLA • STOW DANGER: Are capabilities driving development or are requirements driving? • JSIM • JWARS

8. Hardware Improvements • Current Rules-of-Thumb: • Speed will double every two years (18 months?) • Storage capacity will double every two years • Moore’s Law – “data density will double about every 18 months”, expected to hold true for at least two more decades • Implications for model-building: • Vision is more important than efficiency • Old programming approaches and languages, while they may work for ad hoc models, will be replaced by more powerful ones for the future of combat modeling

9. Hardware Improvements • Implications for analysis: • Run time is becoming a relatively small part of the whole analysis life-cycle for closed models. • Scenario setup remains difficult unless partially automated. • Postprocessing becomes even more difficult since massive amounts of data can be output and stored. • Quick-turn-around "what-if" runs (sensitivity analysis) are easier to do with closed models, and this speed enhances the modelers ability to provide deeper insights. • Consideration of human factors is possible with human-in-the-loop, distributed simulation.

10. Software Improvements • Object-Oriented Design • Artificial Intelligence • Parallelism • Distributed Systems

11. Service-Oriented Architecture (90’s – 10’s) Componentware Design (90’s - 00’s) Object-Oriented Analysis/ Design/ Programming (80’s - 90’s) Structured Analysis/ Design/ Programming (70’s) Unstructured Programming Trends in Software Engineering

12. Object-Oriented Design • What is it? A focus on data grouped into objects, and how the objects interact with each other, as opposed to processes and how they manipulate data. One definition* says that a programming language is object-oriented if it has: Objects encapsulation of attributes (data) and capabilities (procedures). Classification classes are objects which abstract things in the problem domain; instances are objects which represent actual occurrences of things. Messages Objects communicate via messages. Inheritance attributes and capabilities can be inherited from parent classes. *Coad and Yourdan, Object-Oriented Analysis, 1995

13. Object-Oriented Design • Why is it useful? • Designer and programmer can grasp the big picture (similar to the way people think) • Reusability - it is easier for a programmer to reuse someone else's code as a starting point for his project, since code is written in object-sized chunks. Note that this is only practical if code is designed with reuse in mind. • Extensibility - it is easier to extend an OO program to include more, or more complicated objects, primarily because of encapsulation and inheritance. • Are there any disadvantages? • It is often difficult to break programmers out of their process-oriented thinking. • "Legacy" code is usually written in procedural fashion; organizations are often reluctant to discard it.

14. Object-Oriented Design • How can it be useful in combat modeling? • Constructive combat models are extremely complicated programs: any method which can modularize it and let designers and programmers grasp it more easily is a big help. • Because of their complexity, it is easier to build combat models in stages, building on previous work ("rapid prototyping" is one software engineering approach). • The combat domain is readily described as groups of objects (weapons, units, operations plans). • Many objects in the combat domain are only a little different from other, similar objects, making inheritance valuable. • People in different organizations can build their own models and link them together more easily if each model is object-oriented.

15. Componentware Design • What is it? • Components are basically larger-grained objects, along with associated protocols and infrastructure to allow them to be combined easily. • Three basic technical approaches: • CORBA - Common Object Request Broker Architecture • COM/ActiveX - Microsoft’s componentware architecture for COM-based components (C++, VB, J++) • JavaBeans - Sun’s componentware architecture for Java components • Focus is on the interfaces, not the implementation of components.

16. Componentware Design • Why is it useful? • Components encapsulate bigger chunks of the domain than typical objects, so designers can think in “modules”. • Reusability - components are deliberately built with reuse in mind, unlike object classes. Choosing applicable components is easier than browsing long lists of classes, some with poorly explained interfaces. • Productivity - software engineers can produce working code much more quickly. • Are there any disadvantages? • Componentware is another paradigm shift in software engineering, requiring relearning and buy-in. • Three different component approaches (CORBA, COM, and JavaBeans) require bridges between them.

17. Componentware Design • How can it be useful in combat modeling? • Many common functions (e.g., maps, unit orders of battle) can be shared among combat models, allowing focus on specific algorithms of interest. • Work can be distributed, with some teams working on implementing components, some designing interfaces, and some implementing the highlevel application. • Productivity is essential in today’s reduced-funding environment. • This approach dovetails nicely with several DOD M&S initiatives: • HLA • Conceptual Model of the Mission Space • Composable Simulations

18. Service-Oriented Architecture • What is it? • A service-oriented architecture is a collection of services that communicate with each other. • A SOA consists of: • Services: • A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. • Connection: • Some means of connecting services to each other is needed. • Most common example: Web services - • SOAP provides the way to connect • XML provides a vocabulary for the data sent. • CORBA and DCOM were early examples of Service-Oriented Architectures

19. Service-Oriented Architecture • Why is it useful? • Services can operate independently of each other, so designers can focus on their problem only. • Legacy systems can be provided as services, so incremental adoption is possible. • Are there any disadvantages? • SOA is yet another paradigm shift in software engineering, requiring relearning and buy-in. • How can it be useful in combat modeling? • Uncertain as of yet. • SOA is thought of as an enterprise-wide architecture, so a whole simulation might be a service.

20. Artificial Intelligence • What Is It? • A combination of techniques aimed at reproducing / emulating / simulating intelligence in computers. • Three Goals of AI (most researchers adopt only one of these): 1. Make an “intelligent” computer • If intelligence is defined as the ability to process thoughts, then a computer should be able to be intelligent. • Turing Test as a measure of intelligence. 2. Study human cognitive processes • As we understand how computers can be made to emulate human intelligence, we can gain insight into human cognition. 3. Solve computationally hard problems • Use human thought processes as models of problem-solving techniques.

21. Artificial Intelligence • AI is, in one sense, another collection of tools for the modeler’s tool kit. • Major behaviors studied by AI researchers: • Problem Solving • Logical Reasoning • Expertise • Automatic Programming • Natural Language Understanding • Some of the more successful AI techniques: • Rule-based systems, including Expert Systems • Search techniques (A* search and others) • Blackboard systems • Fuzzy Logic • Neural Networks • Genetic Algorithms • Computer Vision • Machine Learning • AI Tools • Robotics

22. Artificial Intelligence • How is it useful in combat modeling? • Primarily in modeling command and control, where the essence of the problem is representing decision-making and planning • Rule-based systems offer a way to show the logical thought processes of commanders in decision-making • Automated planning is very promising, since it could reduce the load on the analyst in building scenarios and increase the ability of the model to replan, i.e., react to unforseen circumstances • Neural Nets could be used to represent intuitive decision-making, intelligence fusion and analysis, or target recognition • Fuzzy Logic could be used to represent decision-making which is based, not on Boolean logic (true/false logic), but on premises which could be weakly true, strongly true, etc., e.g., "if the enemy has quite a bit less combat power than our force,..." • Also, AI provides useful programming approaches, e.g., OOP

23. Parallelism • What is it? • Break a problem down into parts which do not depend on each other, and let several processors work on them at the same time. • Why is it useful? • It has potential to speed up the overall process • It seems like a good idea, but... • In practice it is difficult to build general-purpose parallel-processing algorithms. • However, when the problem can be constrained (e.g., because of the combat modeling domain), we can take advantage of it. • Example: Combined Theater Level Simulation (CTLS) is a research project using parallel processing. • For example, when every unit in a simulation needs to do something which no other unit can influence (e.g., acquiring targets), this can be parceled out to many processors.

24. Parallelism - Two approaches • Pessimistic Approach: • Let no process get further ahead in its processing than every process agrees to. • Optimistic Approach: • Let every process run as far as it can until some process intends to update a variable which has already been used by another process; then "roll back" all processes to the time that the update needs to occur. • Example: Time Warp Operating System (TWOS), used by CTLS • Comparison: • If many conflicts will occur, the first approach will be better; • If few conflicts will occur, the second approach will be better. • When domain knowledge allows processes to work independently, the second approach is useful.

25. Distributed Systems • CONCEPT: Run a set of processes on many computers, with potentially many users interacting. • Banking systems and airline reservations systems are examples of commercial distributed systems. • Distributed Simulation has become the single biggest initiative in Modeling and Simulation within the U.S. military.

26. Advanced Distributed Simulation • Background - Conceptual* Building Blocks: • Stand-alone Aircraft Simulators. • Developed to train pilots in flight skills and cockpit procedures • Stand-alone Tank Simulators or In-Bore Devices on Real Tanks. • Based on and motivated by flight simulators • Developed to train crews in tank gunnery drill • Initially, sights viewed a terrain mockup on which model targets were placed *Not an actual history, but a way the concept can be viewed

27. Advanced Distributed Simulation • Background - Conceptual Building Blocks: • Enhance stand-alone simulators by hooking up a graphics-generated scene to the simulator's tank sights. (For example, police hand-gun reaction courses) • Project a static target array on terrain • Next, dynamically project these scenes, allowing the crew's view to change as tank simulates moving over the terrain

28. Advanced Distributed Simulation • Background - Conceptual Building Blocks (continued): • Next, assess the results of engagements using attrition algorithms • And then, let the targets shoot back. • Also, display other friendly vehicles • Other friendly vehicles could be artificially generated • But why not let two or more crews on separate tank simulators work together opposing the same enemy force and seeing each other's tanks on their own view of the terrain. • Allow the target vehicles to move on the terrain • This generates a need for dynamic control of target vehicles • The solution is to provide a computer-based target vehicle controller • Next allow target vehicles to be controlled semi-automatically • Human users would create target objects and plot routes for targets • Target vehicles would move automatically along their routes

29. Advanced Distributed Simulation • The Vision: • The above logic arrives at a full-featured, high-resolution, interactive combat simulation where vehicles (“Live”), vehicle simulators (“Virtual”) and computer-generated vehicles (“Constructive”) interact on computer-generated terrain. • As few as one crew at a time could train, or whole platoons and companies could train, limited only by the number of simulators and controllers available. • There is no conceptual reason why all simulators and computers have to be at a single location: they could be spread world-wide (subject of course to computer network constraints) • There is no conceptual reason not to include live vehicles and other systems as long as they can communicate on the computer network. • There is no conceptual reason to limit the activity to individual vehicles: aggregated models could participate by contributing whole units. These units would be portrayed by the computer as individual vehicles for the sake of interaction with simulator vehicles.

30. Advanced Distributed Simulation Simulators, simulations, and real systems are tied together by computer: • Vehicles in the simulation are either computer-generated and controlled with input from human controllers (constructive), or represent a vehicle simulator manned by a crew (virtual), or represent a real vehicle linked into the network. • Attrition is represented by computer-based algorithms. • Target Acquisition is represented by: • Computer-based algorithms for computer-controlled vehicles. • The ability of crews to detect targets in the graphics-generated scene (some realism is sacrificed here, since the graphical targets may be easier or harder to detect than in real life). • Movement is constrained by the underlying (computer-generated) terrain. • The whole set of simulators and simulations can be distributed over a Local Area Net or a Wide-Area Net. • Disparate simulators and simulations can participate, as long as they follow the protocols for communicating on the computer network.

31. Training Simulator: real-time execution Training Simulator: real-time execution Training Simulator: real-time execution Constructive Simulation: time-stepped execution Constructive Simulation: time-stepped execution Constructive Simulation: event driven execution Constructive Simulation: event driven execution Live Component: real-time execution w/ hard deadlines Live Component: real-time execution w/ hard deadlines Live Component: real-time execution w/ hard deadlines Live Component: real-time execution w/ hard deadlines The Distributed Simulation Vision: disparate simulations participating in a unified exercise. Parallel Simulation: optimistic Time Warp execution multiprocessor

32. A Brief History of Distributed Simulation • Link Trainer - Navy * • First known simulator (“virtual”) • Cockpit mockup on a gimbaled base (not distributed) • Navy bought two in 1931 • System Training Program for SAGE (air defense system) * • First known distributed interactive simulation • 1950’s Air Force program to train radar operators and weapon controllers • Radar sites fed “tracks” into system for viewing by operators on consoles. • SIMNET(Simulator Network) - DARPA and Army program * • Development from 1982 through 1989 • Tank and aircraft simulators on a network • First major distributed simulation research program • “Battle of 73 Easting” gained support in Congress for DIS *Taken from “Virtual Combat”, David Neyland

33. A Brief History of Distributed Simulation • DIS (Distributed Interactive Simulation) * • CATT (Combined Arms Tactical Trainer) - Army training • STOW (Synthetic Theater of War) - 1994 through 1997 DARPA -> USACOM • Many other DIS exercises and sets of simulations • IEEE Standard 1278 established 1993-4 • ALSP (Aggregate-Level Simulation Protocol) ** • Used to link cross-Service constructive training models starting in 1992 • Required O(n2) interface implementations for n simulations • The Joint Training Confederation (as of 1999): • AWSIM (Air Warfare Simulation) - USAF • CBS (Corps Battle Simulation) - US Army • RESA (Research, Evaluation and System Analysis Simulation) - US Navy • MTWS (MAGTF Tactical Warfare Simulation) - USMC • CSSTSS (Combat Service Support Training Simulation System) - Army Logistics Center • JQUAD model - Joint Command and Control Warfare Center • TACSIM (Tactical Simulation) - US Army Intelligence Center • MDST (Missile Defense Space Tool) - USSPACECOM • AMP (Analysis of Mobility Platform ) *Taken from “Virtual Combat”, David Neyland ** Taken from http://alsp.ie.org/alsp/joint/

34. Objective 1 Objective 2 Objective 3 Objective 4 Objective 5 Objective 6 Develop a common technical framework for M&S Provide timely and authoritative representationsof the natural environment Provide authoritative representationsof human behavior Establish a M&S infrastructureto meetdeveloper andend-user needs Share the benefitsof M&S Provide authoritative representationsof systems A Brief History of Distributed Simulation • US Department of Defense M&S Master Plan (1995)* • HLA (High-Level Architecture) - DMSO program* • Intended to provide a common technical framework for simulations • DOD-wide requirement (1996 “Kaminski” letter) • Follow-on to DIS and ALSP • IEEE standards 1516 • Adopted Nov 11, 1999 by OMG as facility for Distributed Simulation. • Expected to be an annex to v2.0 of Joint Technical Architecture/ *Taken from http://hla.dmso.mil

35. Distributed Interactive Simulation (DIS) “The primary mission of DIS is to define an infrastructure for linking simulations of various types at multiple locations to create realistic, complex, virtual “worlds” for the simulation of highly interactive activities.” • The DIS Vision, DIS Steering Committee, 1994

36. Distributed Interactive Simulation (DIS) • What Is DIS? - It is a set of protocols specifying how simulations interact on a network. • It is not a simulation • It is not a network (Defense Simulation Internet) • HISTORY: • DARPA (Defense Advanced Research Projects Agency) and the U.S. Army have sponsored DIS research with money and focus since the late 1980's • IEEE standards were established for DIS • SIMNET is a network which was a precursor to DIS • DIS has been advocated by the combat developments community as a way to "field-test" a system before it ever gets built • The idea is to specify the system, build simulators for it, and use the simulators in a DIS environment to see how the system contributes to the overall battle. • DIS is now being merged with Defense Modeling and Simulation Office’s High Level Architecture (HLA)

37. Distributed Interactive Simulation (DIS) • How does it work: • Computers on SIMNET host vehicle entities. • An entity may represent a simulator or a computer-generated vehicle. • Semi-Automated Forces (SAFOR) computers control the activities of computer-generated vehicles • Usually SAFORs are interactive, so human controllers do most of the work. • SAFORs can also be driven by combat simulations, so the computer does the all work. • Entities communicate via "PDUs" , or "Protocol Data Units" • An entity sends a formatted PDU over the net when it has something to communicate. • The PDU is coded for the appropriate receiver(s). • Each entity repeatedly polls the net, and captures those PDUs which are addressed to it.

38. Integrated Training Program Excerpts from… DoD High Level ArchitectureOverview September 1998 Defense Modeling & Simulation Office (703) 998-0660 Fax (703) 998-0667hla@msis.dmso.mil http://www.dmso.mil/

39. DoD M&S Vision • Defense modeling and simulation will provide readily-available, operationally-valid environments for use by DoD components • To train jointly, develop doctrine and tactics,Formulate operational plans, and assess war fighting situations • As well as to support technology assessment, system upgrade, prototype and full scale development, and force structuring • Furthermore, common use of these environmentswill promote a closer interaction between the operations and acquisition communities in carrying out their respective responsibilities. To allow maximum utility and flexibility, these modeling and simulation environments will be constructed from affordable, reusable components interoperating through an open systems architecture. DoD Executive Council on Modeling and Simulation (EXCIMS), March 13, 1992

40. DoD M&S Master Plan Objective 1-1 • Objective 1-1. Establish a common high-level simulation architecture to facilitate the interoperability of all types of models and simulations among themselves and with C4I systems, as well as to facilitate the reuse of M&S components. • Simulations developed for particular DoD Components or Functional Areas must conform to the High Level Architecture • Further definition and detailed implementation of specific simulation system architectures remain the responsibility of the developing Component The Common Technical Framework, and specifically the High Level Architecture, represents the highest priority effort within the DoD modeling and simulation community.

41. Management structure in place No formal management structure Management structure stand-up How Did We Get Here?Technical progress spurs management response Technical Limited scope simulations,little interoperability prior to 1988 SIMNET DSB: Computer Applicationsto Training and Wargaming Study for CJCS High Level Architecture(HLA) begun DARPA-SACEURDistributed WargamingSystem ACE-89 DIS Standards begun ALSP:linking of Service wargames New programs (JSIMS, JWARS) HLA policy established 88 89 90 91 92 93 94 95 96 97 98 DEPSECDEF Memo:EXCIMS formedand DMSO established DoD Simulation Policy Study DoD Dir 5000.59M&S Management DoD 5000.59-PM&S Master Plan DoD VV&AInstruction DoD M&S Executive Agents All Services’M&S officesin place SBA TaskForce ArchitectureManagement Group Management HLA Transition Plan approved EXCIMSFunctional Area Councils

42. Scope of HLA High Level Architecture Major functional elements, interfaces, and design rules, applicable to all DoD simulations, and providing a common framework within which specific system architectures can be defined. • Applicable to broad range of functional areas (e.g., training, contingency planning, analysis, and acquisition) • Applicable to simulations involving pure software representations, man-in-the-loop simulators, and interfaces to live components (e.g., instrumented-weapon systems and C3 systems)

43. Role of HLA • Used by simulation system developers and policy makers • Provides systematic and consistent basis for addressing simulation system design and implementation issues • Many difficult issues still need to be resolved at system level – e.g., mechanisms for scalability, aggregation-disaggregation • Facilitates interoperability and reuse through a set of commonly applicable rules • Furnishes framework for making policy decisions (e.g., imposition of specific standards)

44. DoD HLA Policy • DoD Policy: • “Under the authority of [DoD Directive 5000.59], and as prescribedby [the DoD Modeling and Simulation Master Plan], I designatethe High Level Architecture as the standard technical architectureforall DoD simulations.” • HLA supersedes Distributed Interactive Simulation (DIS) and ALSP • “No Can” Dates • “No CanPay”- first day of FY99 • No funds for developing/modifying non-HLA-compliant simulations • “No CanPlay”- first day of FY01 • Retirement of non-HLA-compliant simulations • Waivers must be decided on a corporate basis • Dr. Paul Kaminski, USD(A&T) 10 September 1996

45. HLA applies to multiple time management schemes DIS applies to only real-time, platform level niche of M&S market HLA separates data from architecture-- evolves data as required by applications DIS embeds data in architecture causing protocols to be inflexible and ineffective HLA selectively passes data among simulations DIS uses full broadcast distribution approach Does not scale from a network or processor viewpoint HLA is built around simulation services that DIS does not possess HLA applies to multiple time management schemes ALSP applies to only discrete-event, logical-time niche of M&S market HLA new, more robust approach designed in from onset ALSP designed to accommodate legacy simulations HLA supports broad DoD user community ALSP evolution driven by Joint Training Confederation (JTC) needs How HLA Extends DIS and ALSP Capabilities HLA vs. ALSP capabilities: HLA vs. DIS capabilities:

46. Rationale for HLA Design • Basic premises: • No single, monolithic simulation can satisfy the needs of all users • All uses of simulations and useful ways of combining them cannot be anticipated in advance • Future technological capabilities and a variety of operating configurations must be accommodated • Consequence: Need composable approach to constructing simulation federations • Resulting design principles: • Federations of simulations constructed from modular components with well-defined functionality and interfaces • Specific simulation functionality separated from general purpose supporting runtime infrastructure

47. The High LevelArchitecture (HLA) • Architecture calls for a federation of simulations • Architecture specifies • Ten Rules which define relationships among federation components • An Object Model Template which specifies the formin which simulation elements are described • An Interface Specification which describes the way simulations interact during operation Live Participants Interfaces toLive Players Support Utilities Simulations Interface Runtime Infrastructure (RTI) Federation Management Declaration Management Object Management Ownership Management Time Management Data Distribution Management The HLA is not the RTI; the HLA says there will be an RTI that meets HLA requirements but it doesn’t specify a particular software implementation

48. Defining the HLA • HLA Rules. A set of rules which must be followed to achieve proper interaction of federates during a federation execution. These describe the responsibilities of federates and of the runtime infrastructure in HLA federations • Interface Specification. Definition of the interface services between the runtime infrastructure and the federates subject to the HLA • Object Model Template. The prescribed common method for recording the information contained in the required HLA Object Model for each federation and federate

49. Federation Rules 1 Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT). 2 In a federation, all representation of objects in the FOM shall be in the federates, not in the runtime infrastructure (RTI). 3 During a federation execution, all exchange of FOM data among federates shall occur via the RTI. 4 During a federation execution, federates shall interact with the runtime infrastructure (RTI) in accordance with the HLA interface specification. 5 During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.

50. Federate Rules 6 Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT). 7 Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM. 8 Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM. 9 Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of attributes of objects, as specified in their SOM. 10 Federates shall be able to manage local time in a way which will allow them to coordinate data exchange with other members of a federation.