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 • User’s 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 > 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 > 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 (csv’s) 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. 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. Choose C4I Device

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 • “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 • 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/replacements 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.