Models, Gaming, and Simulation - Session 11

1COMBAT MODELS Session 11 pg04/21/23

Models, Gaming, and Simulation - Session 11

The Future of Combat

Modeling and Simulation


Topics

Issues in M&S

Hardware Improvements

Software Improvements

Implications for M&S

Distributed Simulations– History and Vision

– DIS

– HLA

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

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.

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.


M&S Technology Improvements


Software Paradigms and Capabilities

Army & DOD M&S Programs

AnalysisRequirements

TrainingRequirements

CAPABILITIES

REQUIREMENTS


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

– JSIM

– JWARS

DANGER: Are capabilities driving development or are requirements driving?



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



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.


Software Improvements

Object-Oriented Design

Artificial Intelligence

Parallelism

Distributed Systems


Trends in Software Engineering

Structured Analysis/ Design/ Programming

Object-Oriented Analysis/Design/ Programming

Componentware Design

Unstructured Programming

(70’s)

(80’s - 90’s)

(90’s - 00’s)

Service-Oriented Architecture(90’s – 10’s)



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



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.



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.



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.



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.




– 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


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


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.


– Uncertain as of yet.

– SOA is thought of as an enterprise-wide architecture, so a whole simulation might be a service.


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.


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


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


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.


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.


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.


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


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


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


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.


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.


Parallel Simulation:optimistic Time Warp

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

multiprocessor

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

Live Component:real-time executionw/ hard deadlines





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


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/


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/

Develop a common technical

framework for M&S

Develop a common technical

framework for M&S

Objective 1

Provide timely and authoritative representations

of the natural environment

Provide timely and authoritative representations

of the natural environment

Objective 2

Provide authoritative

representationsof systems


representationsof systems

Objective 3


representationsof human behavior


representationsof human behavior

Objective 4

Establish a M&S infrastructure

to meetdeveloper and

end-user needs

Establish a M&S infrastructure

to meetdeveloper and

end-user needs

Objective 5

Share the benefitsof M&S

Share the benefitsof M&S

Objective 6

*Taken from http://hla.dmso.mil


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


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)


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.

DoD High Level ArchitectureOverview

Defense Modeling & Simulation Office (703) 998-0660 Fax (703) [email protected]://www.dmso.mil/

Integrated Training Program

September 1998

Excerpts from…

• Defense modeling and simulation will provide readily-available, readily-available, operationally-valid environmentsoperationally-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 environmentscommon use of these environments will promote a closer interaction between the operations and acquisition communities in carrying out their respective responsibilities. To allow To allow maximum utility and flexibility, these modeling and simulation maximum utility and flexibility, these modeling and simulation environments will be constructed from environments will be constructed from affordable, reusable affordable, reusable componentscomponents interoperating through an interoperating through an open systems architectureopen systems architecture..

DoD Executive Council on Modeling and Simulation (EXCIMS), DoD Executive Council on Modeling and Simulation (EXCIMS), March 13, 1992 March 13, 1992

DoD Executive Council on Modeling and Simulation (EXCIMS), DoD Executive Council on Modeling and Simulation (EXCIMS), March 13, 1992 March 13, 1992

DoD M&S Vision

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.

The Common Technical Framework, and specifically the High Level Architecture, represents the highest priority effort within the DoD modeling and simulation community.

How Did We Get Here? Technical progress spurs management response

DoD Dir 5000.59M&S Management

88 89 90 91 92 93 94 95 96 97 98

Technical

Management

Limited scope simulations,little interoperability prior to 1988

DIS Standards begunALSP:

linking of Service wargames

DEPSECDEF Memo:EXCIMS formedand DMSO established

SIMNET

HLA policyestablishe

d

High Level Architecture(HLA) begun

DARPA-SACEURDistributed WargamingSystem ACE-89

All Services’M&S officesin place

DoD 5000.59-PM&S Master Plan

EXCIMSFunctional Area Councils

DoD M&S Executive Agents

ArchitectureManagement Group

No formal management structure Management structure stand-upManagement

structure in place

DSB: Computer Applicationsto Training and Wargaming Study for CJCS

DoD Simulation Policy Study DoD VV&AInstruction

New programs(JSIMS, JWARS)

SBA TaskForce

HLA TransitionPlan approved

Scope of HLA 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)

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.

High Level Architecture

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)

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 ArchitectureHigh Level Architecture as the standard technical architecturefor all DoD simulationsall DoD simulations.”

• HLA supersedes Distributed Interactive Simulation (DIS) and ALSP

• “No CanNo Can” Dates- “No CanNo Can PayPay”- first day of FY99

No funds for developing/modifying non-HLA-compliant simulations- “No CanNo Can PlayPlay”- 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

HLA vs. HLA vs. DISDIS capabilities: capabilities: HLA vs. HLA vs. ALSPALSP capabilities capabilities::

How HLA Extends DIS and ALSP Capabilities

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

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

LiveParticipants

The High LevelArchitecture (HLA)

• 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

Support Utilities

Interface

Interfaces toLive Players

Runtime Infrastructure (RTI)

Simulations

Federation Management Declaration ManagementObject Management Ownership ManagementTime Management Data Distribution Management

• Architecture calls for a federation of simulations

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

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

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.

Federate Rules6 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.

HLA Interface Specification

Category Functionality

Federation Management

Create and delete federation executions

Join and resign federation executions

Control checkpoint, pause, resume,restart

Declaration Management Establish intent to publish and subscribeto object attributes and interactions

Object Management

Create and delete object instances

Control attribute and interactionpublication

Create and delete object reflections

Ownership Management Transfer ownership of object attributes

Time Management Coordinate the advance of logical timeand its relationship to real time

Data Distribution Management Supports efficient routing of data

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)

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

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.

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

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

The Prototype Runtime Infrastructure (RTI)

• Distributed operating system-like services to support federation runtime operations

• RTI prototype will support multiple proto-federations

• Phased development

LiveParticipants

SupportUtilities

Interface

Interfaces to Live Players

Runtime Infrastructure

Simulations

Federation Management Declaration ManagementObject Management Ownership ManagementTime Management Data Distriibution Management

The Platform Proto-federation

• Platform level real time simulators/simulations

• Currently use DIS 2.X

• Key issues-performance- transition from DIS to HLA implementation


BFTTSystem

JTCTSPrototype

BDS-D(M1 Simulator)

CCTT(SAF)

The Joint Training Proto-federation

• Distributed discrete event simulations

• Key issues: -Time management-Object ownership-Environmental representation

JTF HQ(JSIMS JPO)

DEEMNSSEAGLENASM/AP


The Analysis Proto-federation

• Faster than real time,closed form analysis simulation

• Key Issues:-Time management-Data filtering-Replicability-Runtime efficiency

JWARS

DeploymentPrototype(MIDAS)


The Engineering Proto-federation

AFEWES REDCAP IADS SBD JMASSACETEF


T&E EW

• Networked Engineering-level simulation capabilities- Validated detailed, high fidelity simulations- DoD 5000 series-compliant acquisition supportfor T&E and concept evaluation

• Key Issues:- Object ownership management- Performance

The Joint Precision Strike Demonstration (JPSD) HLA Experiment


EAGLE ModSAF ModSAF(JSTARS)

Strike(BAT)

ASASRCW

ADOCSSimulationManager

• 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?(declaration management, object ownership management, performance)

Proto-federations and HLA Baseline Definition

• Proto-federation experiences support HLA baseline definition- HLA Specifications: Feedback in Interface

Specification, 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

Interoperability

“M&S 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

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

Opportunities for Reuse

Reusable across all DoD simulation systemsKey:

unique

Reusable across a simulation domain

HLA Interface Specification

Simulationsenvironment, military systems, doctrine


Interfacesto live

players

Weapon Systems

Real-world C4I IndividualCombatants

InstrumentedRanges

SupportUtilities

Communications (e.g., DSI)

Organizational Notes:

HLA was developed under supervision of the Defense Modeling and Simulation Office

DMSO was renamed the Modeling and Simulation Coordination Office.

The web site for M&S CO is http://www.msco.mil/. (The former web site at www.dmso.mil is no longer operational)

HLA is now defined under IEEE Standard 1516.

SISO (Simulation Interoperability Standards Organization) is now the organization responsible for HLA standards.

HLA-Evolved was approved 25 Mar 2010 as IEEE 1516-2010.

http://www.msco.mil/

http://www.dmso.mil/

Models, Gaming, and Simulation - Session 11

Documents

Transcript of Models, Gaming, and Simulation - Session 11