Models, Gaming, and Simulation Session 11

1
Models, Gaming, and Simulation - Session 11

• The Future of Combat Modeling and Simulation

2
Topics

• Issues in MS
• Hardware Improvements
• Software Improvements
• Implications for MS
• 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 MS 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 forces 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
• Analysts Workstation
• An end-to-end integrated suite of scenario
  development and analysis tools does not exist.

5
MS Technology Improvements
REQUIREMENTS
Analysis Requirements
Training Requirements

Army DOD MS Programs
Software Paradigms and Capabilities
CAPABILITIES
Hardware Improvements
6
Technology Improvements

• Hardware improvements are driving improvements in
  software and hence in MS.
• 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

7
Hardware Improvements

• Current Rules-of-Thumb
• Speed will double every two years (18 months?)
• Storage capacity will double every two years
• Moores 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

8
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.

9
Software Improvements

• Object-Oriented Design
• Artificial Intelligence
• Parallelism
• Distributed Systems

10
Trends in Software Engineering
(90s - 00s)
(80s - 90s)
(70s)
Unstructured Programming
11
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
12
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.

13
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.

14
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 - Microsofts componentware
  architecture for COM-based components (C, VB,
  J)
• JavaBeans - Suns componentware architecture for
  Java components
• Focus is on the interfaces, not the
  implementation of components.

15
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.

16
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 todays
  reduced-funding environment.
• This approach dovetails nicely with several DOD
  MS initiatives
• HLA
• Conceptual Model of the Mission Space
• Composable Simulations

17
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.

18
Artificial Intelligence

• AI is, in one sense, another collection of tools
  for the modelers 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

19
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

20
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.

21
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.

22
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.

23
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
24
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

25
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

26
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.

27
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.

28
The Distributed Simulation Vision disparate
simulations participating in a unified exercise.

Parallel Simulation optimistic Time Warp
execution
multiprocessor
29
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
• 1950s 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
30
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 -gt 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/
31
A Brief History of Distributed Simulation

• US Department of Defense MS 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
32
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

33
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 Offices High Level Architecture (HLA)

34
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.

35
Excerpts from
DoD High Level ArchitectureOverview
September 1998
Defense Modeling Simulation Office (703)
998-0660 Fax [phone]hla_at_msis.dmso.mil http
//www.dmso.mil/
36
DoD MS 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 environments
  will 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
37
DoD MS 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
  MS 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.
38
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
ALSPlinking of Service wargames
New programs (JSIMS, JWARS)
HLA policy established
88 89 90 91 92 93 94 95 96 97 98
DoD Dir 5000.59MS Management
DEPSECDEF MemoEXCIMS formedand DMSO established
DoD 5000.59-PMS Master Plan
DoD Simulation Policy Study
DoD VVAInstruction
DoD MS Executive Agents
All ServicesMS officesin place
SBA TaskForce
ArchitectureManagement Group
Management
HLA Transition Plan approved
EXCIMSFunctional Area Councils
39
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)

40
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)

41
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
  architecturefor all DoD simulations.
• HLA supersedes Distributed Interactive
  Simulation (DIS) and ALSP
• No Can Dates
• No Can Pay- first day of FY99
• No funds for developing/modifying
  non-HLA-compliant simulations
• No Can Play- first day of FY01
• Retirement of non-HLA-compliant simulations
• Waivers must be decided on a corporate basis
• Dr. Paul Kaminski, USD(AT) 10 September 1996

42
How HLA Will Extend DIS and ALSP Capabilities
HLA vs. ALSP capabilities
HLA vs. DIS capabilities

• HLA applies to multiple time management schemes
• DIS applies to only real-time, platform level
  niche of MS 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 MS 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

43
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

44
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
doesnt specify a particular software
implementation
45
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

46
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.

47
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.

48
HLA Interface Specification
49
Rationale for Object View

• Provides a convenient way to describe the real
  world
• Facilitates communication between simulation
  users and developers
• Promotes common understanding of real-world
  representations within and between simulations
• Caveat Use of object view implies nothing about
  implementation means (e.g., use of
  object-oriented programming languages)

50
HLA Object View

• Real-world entities of interest for a simulation
  are regarded as objects
• Objects have three basic characteristics
• Identity Those features (e.g., name) that
  distinguish one object from all others
• State The composite of all the static and
  dynamic properties of an object at any instant in
  time
• Behavior How an object acts and reacts in
  terms of its state changes
• The relationship of objects to one another is
  specified through
• Attributes Those state variables and other
  parameters of an object that can be accessible to
  other objects
• Association The conceptual connection between
  objects (e.g., one object is part of a larger
  object)
• Interaction The influence of one object's
  state on the state of another object

51
HLA Object Models

• Object models describe
• The set of shared objects chosen to represent the
  real world for a planned simulation or a
  federation
• The attributes, associations, and interactions of
  these objects
• The level of detail at which these objects
  represent the real world, including spatial and
  temporal resolution
• The key models and algorithms used in
  representing the objects
• The HLA will provide a template to characterize
  the object models
• Object Model Template (OMT) specification
• Note The term object model here should not be
  identified with the term used in some texts on
  object-oriented analysis and design
  methodologies. The term is used more generally
  here.

52
HLA Object Models and Object Model Template

• Object Model Template (OMT)
• Provides a common framework for HLA object model
  documentation
• Fosters interoperability and reuse of simulations
  and simulation components via the specification
  of a common representational framework
• Federation Object Model (FOM)
• A description of all shared information (objects,
  attributes, associations, and interactions)
  essential to a particular federation
• Simulation Object Model (SOM)
• Describes objects, attributes and interactions in
  a particular simulation which can be used
  externally in a federation

53
HLA Prototype Federations

• Five prototype federations
• Platform Proto-federation
• Joint Training Proto-federation (JTFp)
• Analysis Proto-federation
• Engineering Proto-federation
• Joint Precision Strike Demonstration (JPSD)
  Experiment

54
The Prototype Runtime Infrastructure (RTI)

• Distributed operating system-like services to
  support federation runtime operations
• RTI prototype will support multiple
  proto-federations
• Phased development

55
The Platform Proto-federation

• Platform level real time simulators/simulations
• Currently use DIS 2.X
• Key issues
• performance
• transition from DIS to HLA implementation

56
The Joint Training Proto-federation

• Distributed discrete event simulations
• Key issues
• Time management
• Object ownership
• Environmental representation

57
The Analysis Proto-federation

• Faster than real time,closed form analysis
  simulation
• Key Issues
• Time management
• Data filtering
• Replicability
• Runtime efficiency

58
The Engineering Proto-federation
AFEWES
REDCAP
IADS
SBD
JMASS
ACETEF
Runtime Infrastructure
TE EW

• Networked Engineering-level simulation
  capabilities
• Validated detailed, high fidelity simulations
• DoD 5000 series-compliant acquisition supportfor
  TE and concept evaluation
• Key Issues
• Object ownership management
• Performance

59
The Joint Precision Strike Demonstration (JPSD)
HLA Experiment

• Heterogeneous mix of federates in an existing
  experimental simulation environment
• Current implementation augments DIS 2.X with
  tailored HLA-like functionality
• Key issues
• Can HLA support current functionality?(declaratio
  n management, object ownership management,
  performance)

60
Proto-federations and HLA Baseline Definition

• Proto-federation experiences support HLA
  baseline definition
• HLA Specifications Feedback in
  InterfaceSpecification, Object Model Template,
  and test procedures(through AMG working groups)
• Lessons Learned for Transition Profiles of
  federate adaptation to capture implementation
  experience
• Process of Use Generating a Federation
  Development and Execution Process based on
  composite experience

61
Interoperability

• MS Interoperability The ability of a ...
  simulation to provide services to, and accept
  services from, other ... simulations, and to
  use the services so exchanged to enable them to
  operate effectively together.
• DoDD 5000.59

62
HLA and Interoperability

• Interoperability requires the ability both to
  exchange data and to interpret it consistently
• HLA-required functionality and interfaces provide
  ability to exchange data
• Provides mechanism to establish federation of
  simulations, transfer object data among
  simulations, and coordinate simulation operations
• HLA-required federation object models facilitate
  consistent interpretation of exchanged data
• Provide information on objects, their public
  attributes, associations, interactions, level of
  resolution, and key models and algorithms used in
  their representation

63
Opportunities for Reuse
Instrumented Ranges
Weapon Systems
Simulations
IndividualCombatants
Real-world C4I
environment, military systems, doctrine
SupportUtilities
Interfaces to live players
HLA Interface Specification
Runtime Infrastructure
Communications (e.g., DSI)
64
On-Line Documentation

• Proceedings and products of the AMG appear under
  the subtopic Common Technical Framework for
  MS, under High Level Architecture. DMSO home
  page site is
• http//www.dmso.mil/
• Specific questions can be directly addressed to
  DMSO via electronic mail at
• hla_at_msis.dmso.mil