1 / 10

Scalability

Scalability. Entity Scalability Scope.

varsha
Download Presentation

Scalability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • “server”’s are distribution of simcores updated through existing mechanisms • “client”’s are ODB clients (MCTs, AAR, Interop Adapters) that update over the network through a new mechanism

More Related