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