03SSIW013 Requirements for Composing Simulations: A UseCase Approach - PowerPoint PPT Presentation

1 / 21
About This Presentation
Title:

03SSIW013 Requirements for Composing Simulations: A UseCase Approach

Description:

Addresses journaling and logging requirements in correspondence with a Save. ... Models access to common state-saving repository and common journaling functions. ... – PowerPoint PPT presentation

Number of Views:31
Avg rating:3.0/5.0
Slides: 22
Provided by: dpe93
Category:

less

Transcript and Presenter's Notes

Title: 03SSIW013 Requirements for Composing Simulations: A UseCase Approach


1
03S-SIW-013Requirements for Composing
Simulations A Use-Case Approach
  • SPRING 2003 SIW Conference

2
Simulation Composability
  • DMSO Tasking
  • Deliverable Set of Requirements, I.e., Use
    Cases that detail Composability.
  • Posture From the Warfighter Viewpoint
  • Specific Tasking
  • Survey ONESAF
  • Survey JSIMS
  • Survey Warfighter
  • Develop Use Cases Requirements
  • Present Findings

3
Simulation Composability - Background
  • DMSO Survey of Warfighter Needs
  • Multi-resolution and composable simulation
    environments
  • Ability to link to C4I systems
  • Faster, less costly database development
  • Standardized (reusable) components
  • Reduced overhead to develop and maintain MS
  • Operational data collection and incorporation
    into MS to validate and improve
  • Access to terrain for operational areas
  • Tools for operational decision making
  • Improved human performance modeling

4
Defining Composability Findings (1)
  • Composability is the capability to select and
    assemble simulation components in various
    combinations into simulation systems to satisfy
    specific user requirements.
  • Composability implies a component-based
    architecture.
  • The elements of a composable system must be
    interoperable.

5
Defining Composability Findings (2)
  • The components must be reusable.
  • Composability does not refer to systems that are
    merely modular
  • A set of components that model the same
    real-world entity is only composable if they can
    synchronize their respective views of that
    entity, even if they have different resolutions.
  • That is, composability includes the ability to
    translate object properties.

6
Use Case Approach
  • Use case analysis is a technique for deriving
    functional requirements by examining the behavior
    of a system from the point of view of its users.
  • Use case analysis begins by
  • Choose Actors
  • People or systems that interact with the system
    being described.
  • Develop Scenarios
  • Describe ways in which the actors engage the
    system and how the system responds to them.

7
Actors (1)
  • Commander
  • Represents warfighter requesting the simulation
    scenario.
  • Simulation Center
  • Translates the Commanders requests into a
    scenario and composes the simulation to execute
    the scenario.
  • Scenario Builder
  • Representing Members of the Simulation Center who
    assemble the simulation.
  • Model Controller
  • Represents members of the Simulation Center
    responsible for execution and after-action review
    data.

8
Actors (2)
  • Operational Data Sources
  • Represents data used to initialize simulation.
  • Includes software and subject matter experts.
  • Scenario Builder accesses these sources to build
    the scenario data elements.
  • Models
  • Components from which the system is built.
  • Components have requirements included in a
    composed system

9
Process Flow
10
Use Cases (1)
  • Decompose Scenario
  • Process that simulation center selects models for
    the composed simulation
  • Selects environmental services
  • Designates communication method between
    components.
  • Choices recorded in the scenario template.
  • Choose Intelligent Agents
  • Simulation center selects rule-based agents to
    supervise other models.
  • Specify Mixed-Aggregation Modeling
  • Defines the requirements for the software zoom.
  • For example A constructive model moves aircraft
    to the field following a battle plan. Pilot
    trainees can enter an ongoing simulation to fly
    high-resolution models of individual aircraft.

11
Use Cases (2)
  • Specify Multiple-Asset Simulation
  • Real-world assets are represented by more than
    one model.
  • Assets are continuously tracked by multiple
    models at different fidelities.
  • Arises by composing legacy simulations.
  • Adjust Asset List
  • Simulations are initialized with numbers and
    types of assets that are deployed in a
    geographical area.
  • Obtained from command and control systems.
  • Operational maps of the exercise area.
  • Initialize Scenario Data
  • Introduce specific asset details, such as ship
    payloads.
  • The Scenario Builder specifies mapping between
    C4I and simulation objects
  • Uses rule-based agents to check the mapping for
    completeness and consistency.

12
Use Cases (3)
  • Assemble Simulation Components
  • Components chosen in the scenario template are
    assembled
  • Components are retrieved from the repository.
  • Compose New Model
  • In this use case, there is no existing model that
    meets the requirement, but the component
    repository does contain code modules from which
    the required model can be assembled. These
    modules are retrieved and linked together.
  • Connect to Environmental Services
  • Simulation initializes with terrain and
    atmosphere data.
  • Connect to Timekeeper
  • Models accept a centralized timekeeper.

13
Use Cases (4)
  • Save Exercise State
  • Model controller saves ongoing simulation
  • Restores simulation from saves.
  • Collect After-Action Review Data
  • Addresses journaling and logging requirements in
    correspondence with a Save.
  • Models must perform under central command
  • Agree on a common journal format or subscribe to
    a common journaling service.

14
(No Transcript)
15
Derived Requirements (1)
  • 1. At least one standard form for representing
    the properties of models, services, and other
    components.
  • 2. An accessible repository from which the
    properties of all components can be retrieved.
  • 3. Scenario template able to specify multiple
    models for the same physical asset.
  • 4. Models report state to external sources and
    accept state changes from external sources.
  • 5. The repository should include components that
    can arbitrate between models.
  • 6. Models access to common state-saving
    repository and common journaling functions.

16
Derived Requirements (2)
  • 7. Models must accept timekeeping instructions
    from an external source.
  • 8. Models should be able to accept global
    information from an external source.
  • 9. The component repository should include
    connectors to operational data sources.
  • 10. Model components that can be parameterized by
    external information, such as the physical
    locations of assets.
  • 11. The repository should include translators
    from operational data to simulation data.
  • 12. Catalog descriptions of models that require
    subordinate models must specify their needs in
    standard form.

17
Recommended Functional Areas
  • Scenario Decomposition Toolkit
  • Scenario Data Toolkit
  • Simulation Toolkit
  • Run-Time Frameworks
  • HLA, DIS, ALSP
  • External Protocols TADIL J, OTHT, SIMPLE
  • Service and Model Interactions
  • Intelligent Agents

18
Translation Gateways
19
Current Approaches to Composability
  • JMASS
  • FLAMES
  • OneSAF
  • JSIMS and HLA

20
Simulation Composability - Agenda
  • Overview
  • User Base
  • Successes
  • Failures
  • Apple Question
  • If you had the chance to do it over again, what
    would you change?

21
Summary of Findings
Write a Comment
User Comments (0)
About PowerShow.com