Architecture and Integration Version 2.0 Changes Session 2.2

1
Architecture and Integration Version 2.0
ChangesSession 2.2
2
Data Collection/Causal Analysis Support
3
Requirement

• RIB Requirement 54 Data Collection and
  Analysis 1. ORD Reference 6.10.2 Data
  Collection and Analysis. OneSAF will include the
  following data collection and analysis
  capabilities graphical, text, and spreadsheet
  displays exportable to standard software packages
  using multimedia capabilities reports on status
  of units and environment and detailed trace-back
  and debug histories of each major object to
  assist in determination of run-time anomalies.
  Required Functionality At a minimum, OneSAF
  will provide data collection and analysis
  capabilities graphical, text, and spreadsheet
  displays exportable to standard software packages
  using multimedia capabilities and reports on
  status of units and environment. Desired
  Functionality Desired is that OneSAF will
  include a detailed trace-back and debug histories
  of each major object to assist in determination
  of run-time anomalies.

4
Requirement

• RIB Requirement 115 Causality Tool (ACR)
  Extract of Requirement Included - File Attached
  with more detail. Requirement is not for a highly
  developed GUI, but just data available to the
  user. Should be available across the scenario and
  not limited to a particular workstation.
• Must be user selectable to capture data of any n
  number of user specified entities in any m number
  of user designated individual files
• Must be a continuous (not discrete time steps)
  capture of ALL event data occurring in the life
  history of the specified entities as they occur
  (event-stepped, not time-stepped)
• Scenario/tactical events (e.g., behaviors,
  decisions, orders, etc)
• Simulation events (e.g., models used,
  calculations produced, data selected, etc)
• Must be ordered by event occurrence, entity
  unique number/ID and time-tagged to at least the
  thousandth of a second
• When any events are scheduled to occur or are to
  be produced by two or more entities at the same
  time, the order of calculation by OneSAF takes
  priority for their ordering in the output history

5
Requirement Scope

• This effort will not be complete within FY07.
  However, we plan to produce a prototype
  implementation that converts the existing data
  collection output into a format that is
  consumable by an analysis tool (to be determined)
  currently used by ACR.
• This effort should be developed concurrently with
  RIB 115.
• Evaluation of data formats used by current tools
  in terms of input and output.
• Comparison to current AAR tools to provide
  alternatives.
• The main focus will be on the data format, type
  and instances rather than on graphical displays.
• The effort for this requirement will primarily
  look at the trace-back capability and deciding
  what framework or infrastructure changes are
  required to enable the production of this data.

6
System Impacts DCST

• Data Collection Specification Tool (DCST)
• DCST in v1.0 only supports coarse granularity
  collection
• Whatever the developer collected and presented
• Could contain significantly more information than
  what users want
• Need to allow users to select subsets of the
  presented information, and just collect the
  subsets
• Users lose perspective on organization of
  entities
• Need to allow users to create filters to only
  collect information if a collectable attribute
  satisfies certain criteria (speed gt 5 m/s)
• Need to improve registration such that behaviors
  are pre-registered with the data collector

7
System Impacts DCST

• Approach
• Improve DCST Interface
• Support fine-granularity user data selection
• Incorporate the Task Org tree into the DCST
• Support selections of classes of information in
  addition to fine-grain specific information
• E.g., allow users to select all physical models,
  just the mobility model, or just specific
  attributes out of the mobility model
• Support users adding filters to allow further
  trigger-based filtering
• E.g., collect mobility info only if speed gt 5 m/s
• Improve Data Collection registration process
• Enables users to see and select behaviors to data
  collect

8
System Impacts Data Collection Framework

• Data Collection Framework needs the following
  improvements
• Better support for registering available data to
  be collected
• Support a streamlined instrumentation approach
  for data collection
• Make it less burdensome for developers to add
  data collection to a model, service, or tool
• Enable removing data collection code clutter from
  algorithms
• Currently Data collection instrumentation nearly
  doubles the size of a models class
• Add another output format to support streaming
  out comma-separated values (csvs) instead of
  only XML

9
System Impacts Modeling Infrastructure

• Modeling Infrastructure needs Data Collection
  added to collect
• What behaviors are executing
• What the inputs are to a given behavior
• What agents/model controllers are operating
• What instructions they provided the physical
  models

10
System Impacts Models

• Behavioral models need to be setup for Data
  Collection
• Usecase supported
• Sensing to Weapon Firing
• Detonation to Battle Damage Assessment

11
RIB Item 54 Update

• Data Collection/Analysis Causality Tool
• Included in Version 2.0
• Enhanced the Data Collector (DC) framework and
  Data Collection Specification Tool (DCST)
• Modified models and behaviors to step-up to DC
  and DCST enhancements
• Improved data collection performance
• Enhanced filtering of data collected
• Data output in user defined formats
• Implemented thread associations for causal
  analysis

12
Scalability
13
Entity Scalability Scope

• RIB Requirement 125 At least 15,000 entities
  32,000 desired (base line capability) (ACR)
  Representation lower than MR/LR that can
  stimulate Bde and below C4I devices necessary to
  develop for the CMD and Staff to see the COP
  (BLUFOR OPFOR). No weapon, single sensor,
  mobility and comm to meet COP needs. (TEMO)
• Two use cases, ACR and TEMO with some overlap
• Support 15-32,000 entities for (ACR)
• Strong Data Collection Requirements and Causal
  Analysis requirements
• No identified C4I requirements
• Support 15-32,000 entities with C4I stimulation
  necessary for Command and Staff to visualize the
  COP (TEMO)
• At a minimum, an entity has a single sensor,
  has mobility capability, can generate comms, but
  does not necessarily have a weapon
• C4I Stimulation requirement (outgoing, no
  identified incoming)
• Implies thousands of entities pushing out C4I
  messages

14
System Impacts C4I Setup/Models

• C4I
• Requirements to stimulate thousands of entities
  worth of traffic, including comms for Low or
  Ultra-Low Resource entities has implications to
  comms setup
• Models Approach
• Create low overhead C4I stimulator built with
  OneSAF Components
• Notionally this is of a service/model that is
  watching over given set of entities and
  generating traffic on their behalf
• Reuses existing initialization approach
• Should significantly reduce the overhead
  associated with message traffic systemically
• Allows maintaining existing approach for
  higher-fidelity comms
• Conceptually, this is SIMPLE implemented with
  OneSAF components for a more seamless integration
  and initialization

15
System Impacts C4I Setup/Models

• C4I
• MCT C4I Setup Approach
• Update URN specification in MCT to allow easier
  access
• Integrate functionality from the Specify C4I
  Devices dialog into the Task Organization Pane
  to ease viewing and assignment of URNs to C4I
  devices.
• Allows viewing of the task organization to easily
  find units/entities.
• Filters will allow user to only see
  units/entities with C4I devices.
• Filters will allow user to show/hide C4I devices.
• Expand search/filters to allow user to quickly
  find desired units/entities.

16
System Impacts MSDE

• Scenario Setup
• Establishing 15K-30K entity scenario implies that
  scenario generation process needs to be enhanced
• Need BOS relationship support in MSDE/MSDL to
  minimize overhead after import for comms setup
  for Fire Support/Logistics support
• Should/can any further automation occur?
• Desire enhancements to MSDE to better automate
  applying URNs from LDIF on top of Unit
  Organization

17
Task Org with C4I
18
Choose C4I Device

• The existing 'C4I Device Chooser' dialog will be
  reused when the user selects the 'Choose C4I
  device' menu item from the right click menu
  available in the URN column.

19
System Impacts

• Data Collection
• Data Collection Framework needs performance
  attention
• Must reduce memory overhead (DCDictionary)
• Must reduce CPU overhead (XML writes)
• Must improve API for developers to instrument
  their pieces of the system
• Target special instrumentation of Modeling
  Framework
• Must improve degree of coarseness presented to
  users for collection
• Must improve user interface of DCST

20
System Impacts MCT

• Capacity
• MCT needs to be able to visualize (worst case)
  32,000 entities simultaneously for the
  Battlemaster
• Memory overhead/CPU too high per entity in v1.0
• When?
• Improvements made to the MCT in Build 2 support
  up to 100,000 entities moving, articulating, and
  responsive
• Planned for integration in Build 3
• Control Strategy
• Need mechanism to control this many entities, and
  allow saving that information in scenario
• JCATS/JANUS use very low-level commands to
  control entities
• Approach
• Update existing Interventions approach
• Allow interventions to be saved on route
  waypoints on the map
• Update Interventions menu for usability
• Workstation Assignments

21
System Impacts Simcores

• Requirement provides lowest-possible resolution
  for entity
• What are the top-down performance/memory
  allocations that we need for an entity?
• If we need to fit simcores on CHP (2G), need to
  cut memory usage for entity
• If we are able to use 64-bit machines for
  simcores and larger amounts of RAM, potentially
  no changes needed
• Do we have to interop at this capacity?
• Planning to support HLA, stimulating HLA AAR
  (notionally Vision XXI, from ERF)
• Plan on building ULR entities based on
  requirement
• Working out characteristics

22
System Impacts

• Simulation
• Optimization/Performance Analysis
• Need to add benchmark scenarios that tests an
  equivalent-sized exercise with appropriate
  resource utilization entities, executing
  appropriate activities

23
System Impacts Distribution Capacity

• Existing distribution approach gets ALL traffic
  to every node in the distribution
• Has scalability limitations on number of nodes
  due to network loss problems
• Worse though, increases memory usage across all
  nodes, since they all know everything
• Makes long-haul challenging due to network
  latency issues
• Approach
• Adding filtering so that SORD clients register
  what objects and interactions they are interested
  in, and only get that information delivered to
  them (akin to DDM in HLA)
• Built client-server distribution approach
  augments existing
• servers are distribution of simcores updated
  through existing mechanisms
• clients are ODB clients (MCTs, AAR, Interop
  Adapters) that update over the network through a
  new mechanism
• Clients will be able to be at remote sites,

24
RIB Item Update 15k 32k Entities

• Overview
• Support 15k (threshold) to 32k (objective) entity
  exercise within OneSAF
• 1.5
• Many performance improvements to the PVD
• Simplified ability to setup URNs
• Improved AAR Data Collection performance to
  collect for 32k entities
• 2.0
• Improve control mechanism for LR entities
• LR Comms service pushes out Location Spot Rpts
• Large performance improvements for LR entities
• Improved Distribution Approach
• Improved AAR performance to support 32k replay

25
Parametric Data Loading
26
RIB 142 Classified Data Loading - Scope

• RIB Requirement 142 Tools and documented
  processes to quickly generate a new brigade-sized
  classified scenario (for example SWA 103.2 and
  SWA 110) from fundamental source(AMSAA) data A
  to include loading a classified force and
  performance database. IMPROVE THE PROCESS OF
  LOADING OF PARAMETRIC DATA AND BEHAVIOR DATA
• Usecase
• Load classified physical model data from AMSAA
  based on Standard File Formats.
• Load in behavior data from existing KAKE source
  files (currently developed formats).
• End State for 2.0
• Document
• Roadmap containing locations of data files for
  each model
• Provide process description, with examples, for
  loading classified data into the OneSAF system
• Tools
• Register new data package with the OneSAF system
  (New)
• Display roadmap of data files with file
  description (New)

27
Organize Baseline for long term Support

• Benefits
• Reduces complexity in documenting the process for
  Data Loading.
• Allows co-developers to organize their
  functionality into their own components.
• Enables users to quickly identify core
  functionality versus co-developer contributions.
• Implementation Detail
• Separate core OneSAF functionality from external
  developer software.
• Reorganize data to be co-located with Models.
• Remove redundant entity and unit compositions.

28
Data Loading - Approach

• Support direct loading of native physical data
  (e.g. APEDS) and behavior data (e.g. Excel
  spreadsheets).
• Benefits
• Documents a how-to approach on loading new data
  into native file formats.
• Enables users to quickly find data files and make
  changes.
• No data transformations necessary.
• Provides a tool for packaging new / overridden
  data.
• Implementation Detail
• Provide documentation for Data Loading
• Documents the data loading process.
• Provides a roadmap to the data (define file
  structure and location in baseline).
• Provides examples of loading data for a given
  capability or subsystem.
• Provide a Data Loading Tool
• Facilitates the importing of new data based on
  supported structure.
• Provides a description of the native files and
  their locations.

29
Data Override Support

• Provide the ability to override data
• Benefits
• Allows co-developers to track data files in their
  own locations and make updates or changes as
  necessary.
• Enables users to specify and provide data in
  their components.
• Enforces traceability for data extensions/replacem
  ents to the core data files.
• Implementation Detail
• Provide traceability / verification on
  origination of data based on a given set of
  inputs i.e. entity, weapon etc.
• Repackage data into components to enable
  traceability to data authorities.
• Implement dynamic PAIR to allow data to be loaded
  similar to (and with) software components.

30
RIB Item Updates Parametric Data Loading

• Overview
• Improve the process of loading parametric data
  into the system by converting all physical and
  behavior data to native formats and provide a
  data management tool (DMT) to import override
  data into the OneSAF system.
• 1.5
• Reorganized baseline to provide for extensions to
  enable data overrides.
• The sensor data thread has been converted to
  native file formats.
• A few additional data files have been converted
  to native file formats to show examples of
  reading AMSAA SFF and Excel spreadsheets.
• Thread test provided to show the importing of
  sensor data using a manual process and the DMT.
• User and Maintenance manual have been updated
  showing the sensing example.
• 2.0
• All other physical model data files will be
  updated to their native formats.
• Four additional threads will be documented
  direct fire for ground vehicles, indirect fire,
  vehicle ground mobility, repair.
• Majority of the behavior data files will be
  updated to their native formats.
• User and Maintenance manual will be updated based
  on any tool updates.