Scalability

1
Scalability
2
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

3
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

4
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.

5
Task Org with C4I
6
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.

7
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
• Improvements made to the MCT in Build 2 support
  up to 100,000 entities moving, articulating, and
  responsive
• 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
• Update User Interface

8
System Impacts Simcores

• Requirement provides lowest-possible resolution
  for entity
• Plan on building ULR entities based on
  requirement
• Working out characteristics

9
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

10
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