A New Paradigm for Developing and Maintaining Scenarios for Distributed Simulation Systems

1
A New Paradigm for Developing and Maintaining
Scenarios for Distributed Simulation Systems

• 99S-SIW-179

Ken Hunt AEgis Research Corporation
Lt. Eric Harten Modeling, Analysis and Simulation
Center (MASC) Electronic Systems Center USAF
2
Agenda

• Introduction
• The MASC
• Overview
• Topical Issues
• Scenario Generation Toolset
• Status

3
The MASC

• Part of the Modeling, Simulation and Training
  Product Area Directorate (ESC/DIS) of the
  Electronic Systems Center
• Located at Hanscom AFB, Boston, MA
• The mission of the MASC is to provide a C4ISR
  analytic MS capability to support the USAF, the
  DoD, and joint programs requiring MS expertise,
  development, implementation, and/or analyses.

4
The MASC

• A state-of-the-art computer and communications
  facility
• Distributed simulation
• Heterogeneous computing platforms
• Significant inventory of simulations
• Rapid reconfiguration capability
• Core Team of Project Managers, Engineers,
  Analysts, and Security Personnel

5
Topical Issues

• The MASC has vested interests in
• Reducing the effort of initializing a network of
  heterogeneous simulations
• Automating the maintenance of scenario data
• Promoting reusability
• Supporting configuration management
• Investigating ways to exploit HLA in scenario
  development
• Leveraging off of other HLA-related activity
• Offering new tools that support the FEDEP

6
Typical Scenario Development Process

• Scenario specification developed using
  spreadsheets, diagrams and text
• Each scenario object assigned to a specific
  simulation
• Analysts construct scenario description for each
  simulation using that simulations tool

7
Desired Scenario Development Process

• Scenario specification constructed within a
  dedicated application
• Scenario objects mapped to simulations with the
  aid of automation, enabling traceability
• Simulations input files/databases populated in
  an automated fashion
• Tools/process support collaborative scenario
  development

8
Agenda

• Introduction
• The MASC
• Scenario Generation Toolset
• Scenario Generator
• Execution Planner
• Status

9
The Scenario Generation Toolset (SGT)

• The SGT divides scenario development into two
  primary tasks
• 1. Develop the scenario in the conceptual domain
  independent of the object perspective of any
  particular simulation application
• 2. Distribute modeling responsibilities for the
  scenario objects to the federations constituent
  membership

10
SGT Applications

• Scenario is composed and maintained in the
  conceptual (i.e. Real-world) domain
• Execution planning partitions the scenario as
  required for the distributed simulation system
• HLA object models provide necessary terminology
  to bridge the systems constituent applications

11
Agenda

• Introduction
• The MASC
• Scenario Generation Toolset
• Scenario Generator
• Execution Planner
• Status

12
Scenario Generator

• Intuitive interface with utilities that support
  the scenario planning process
• Object perspective adapted to conceptual model

13
Conceptual Model

• User definable
• Rational Rose via export script
• Public DIF exchange
• Long-term Custom object modeling tool
• Defines...
• Object classes -- Hierarchy and composition
• Associations
• Events

14
Adapting to the Conceptual Model

• Attribute value entry fields enforce datatypes
• User can tag special attributes
• Enforce unique
• Reference Label
• Object reference
• Cardinality rules recognized
• Required/optional entries (1, 0)
• Base event classes

15
Sample Class Adaptation
16
Scenario Object Properties
Attributes
17
Scenario Object Properties
Components
18
Scenario Object Properties
Associations
19
Scenario Object Properties
Events
20
Predefined Classes and Types

• To enable utility functions and graphic
  representation, fundamental concepts of time and
  location must be imposed
• Event classes
• Position and Object Handle datatypes
• By specifying these required datatypes in the
  conceptual model, we allow the end-user to
  extend the capabilities of the tool in a powerful
  way

21
Events
22
Event Sequencer

• Time Sequencing of Scenario Events
• Object creation
• Engagement (Launch)
• Route Start/Waypoint Arrival
• Communications
• Any custom event derived from the SGTEvent class
• Drag and drop editing

23
Other Predefined Classes and Datatypes

• Types
• SGTObjectHandle - A reference to some other
  scenario object. Used to populate selection lists
  at runtime.
• SGTPosition - A complex type that positions an
  object in space.
• Classes
• SGTLine - A named collection of SGTPosition
  types. Used to define political boundaries.
• SGTZone - Similar to SGTLine, but for polygonal
  and circular zones.
• SGTRoute - Essentially a named collection of
  Move events

24
Features

• Imposing these few predefined classes/types
  enables features identified as required by MASC
  simulation engineers
• Motion preview
• Network and C2 planning (Association views)
• Event sequencing
• Geographic overlays

25
Data Management

• Scenario data organized as a project
• Scenario objects created in object sets
• Project contain 1 object sets
• Object set can persist as a DIF file or as Oracle
  Database entries

26
File Format Support

• Conceptual Model
• Public XML DIF format
• Maps
• DTED
• JPEG/GIF/BMP
• Icons
• JPEG/GIF/BMP
• VRML
• Scenario file
• Public XML DIF file
• Oracle Database interface
• ATO Import

27
Agenda

• Introduction
• The MASC
• Scenario Generation Toolset
• Scenario Generator
• Execution Planner
• Status

28
Execution Planner
29
Primary Functions

• Establish Modeling Responsibility for every
  scenario object
• Generate traceability reports to the
  object-instance level of detail
• Scenario object to federate
• Scenario object to FOM object
• Provide means of automating production of
  scenario input files/databases for the simulations

30
Execution Planning Steps

• Import Federation Object Model (FOM) and
  Conceptual Model (CM)
• Partition the FOM Publish/Subscribe information
  across the federates
• (Or import FEPW DIF)
• Establish Mapping Between Conceptual Model and
  FOM
• Assign Modeling Responsibilities

31
FOM Partitioning

• Specifies what parts of the FOM each federate
  produces and uses
• Capable of importing FEPW DIF

32
Establish Mapping Between Conceptual Model and FOM

• The user maps each CM class to a FOM class
• Inheritance automatically exploited to expedite
  process
• A utility to check for exhaustive CM class to FOM
  class mappings will be provided.

33
Assign Modeling Responsibilities

• Transfer(T) and Accept(A) settings identify
  potential for multiple federates.
• The Private flag issued for internally modeled
  objects (i.e. Not visible across federation).
• Can sort the Modeling Responsibilities by class
  (as shown) or by archive set.

34
Reports

• Federate Report
• For each federate in the federation, a detailed
  description of the scenario objects the federate
  is required to model
• Object Report
• Sorted by Class or by Object Set, detailed
  specification of each scenario object, ID of
  federate that will model it, and ID of FOM
  class(es) that will represent it

35
Programming API

• Execution Planner supports plug-in modules that
  can be used to extend the file formats that can
  be exported
• End users can develop plug-ins which can generate
  simulation-specific scenario input files
• Sample plug-in modules (with source code) will be
  included for EADSIM and AWSIM scenario formats

36
Agenda

• Introduction
• The MASC
• Scenario Generation Toolset
• Status
• Accomplishments
• Future direction

37
Accomplishments

• Established Software Requirements Specification
  (SRS)
• Passed Review
• SRS under Configuration Control
• Established Software Design Specification (SDS)
  for Cycle 1 delivery (Evolutionary Delivery
  Lifecycle Model)
• Cycle 1 Implementation
• Application architecture foundation
• Support for creating, loading and saving project
  files
• Support for loading conceptual model
• Basic support for creating scenario objects
• Simple 2D DTED display capability

38
Program Goals

• Complete Cycle 1 development
• Deliver to MASC for feedback -- April 15, 1999
• Develop Cycle 2
• Prioritize Cycle 2 features based on MASC
  Feedback and SRS
• Implement Cycle 2 version
• Deliver to MASC for feedback -- October 15, 1999
• Develop Cycle 3 for public beta testing
• Develop Cycle 4
• Prioritize Cycle 2 features based on MASC and
  public Feedback

39
Future Direction

• Evangelize our approach of simulation-independent
  scenario maintenance
• Lobby for and offer interface standards
• Lobby for scenario repository
• Get SGT used
• Offer to simulation labs across services
• Establish exchange repository for
  simulation-specific plug-in modules
• Encourage the use of SGT as a viable scenario
  input tool for new simulation programs, as well
  as a replacement for the scenario editor of
  older, legacy simulations
• Commercialize SGT
• Government version serves as proof-of-concept
• Commercialization insures continued evolution