Version 3.0 Requirements Session 3.2 Mike Fernandes, A&I Lead Engineer

1. One Semi-Automated Force (OneSAF) Version 3.0 RequirementsSession 3.2Mike Fernandes, A&I Lead Engineer

2. Version 3.0 Requirements • Data Collection and Analysis and Causality tool • Load AMSAA Physical Performance Data. • Federate with JDLM in order to stimulate BCS3. • Load / integrate operations overlays and unit organization structures from ABCS systems. • Operate distributed over a WAN. • Target Acquisition, Acquire model update. • SIGINT, IMINT, and environmental IR sensors. • COE OPFOR behavior representation. • BLUFOR counter COE measures. • SECore / OneSAF UFR • Model FCS platforms and units with appropriate behaviors at company/battalion level and below. Cut Line Note: Red Text denotes not funded from the requirements process

3. Data Collection Requirement • Data Collection and Analysis (Scenario Outcome Data) and Causality tool: OneSAF will provide the file(s) in a format selectable by the user. Files will be collected in a central location and events will be presented in simulation time order. 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. • Causality Tool or better described as Entity History File (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. Used for debugging and tracing events. OneSAF must write out a text file of the history of events for an entity.

4. CAPABILITIES PROVIDED • This is a continuation of the previous task from v2.0. • Include the capability to merge data output files from multiple SimCores nodes. • Enhanced Data Filters • User Defined XML Output Schema

5. Parametric Data Loading • Loading AMSAA Physical Performance Data: 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 • For those functionalities which OneSAF represents it must be able to “load” AMSAA APEDS data for a new scenario, and replace the data for an existing scenario. This would include an entire new performance data set as well as selected data items. Request, in this FY, documentation for this effort. This allows deletion of index item # 135.

6. Data Loading – Capabilities Provided • Document Data Model and identify relationships between keys. Support composition based approach for data overrides and component swapping. Provide enhancements to the DMT tool to display dependencies and provide guidance on the addition of new values for keys. • Documents data relationship between behaviors, physical models, services, etc. • Upgrade all AMSAA physical models to SFF 4.0. This includes data as well as model changes.

7. Data Relationships Support • Notify users on what data files need to be updated when adding new entities, weapons etc. • Benefits • Allows switching between conflicting data sets within the same baseline. • Enables users to quickly switch out data sets that override one another. • Improves process of adding new entities, weapons etc. by identifying required data. • Implementation Detail • Provide traceability relationships between data files and entities, weapons, munitions etc. via the data model • Update the DMT to trace through the set of affected data files.

8. Federate with JDLM • The Translation Services Component shall translate supported digital communications between OneSAF and the Battle Command Sustainment Support System (BCS3). OneSAF shall federate with JDLM in order to stimulate BCS3.The NSC has no intent for a ground model to take over High Fidelity Logistics.

9. Federate with JDLM – Capabilities Provided • OneSAF shall interact with JDLM via the ERF v4 FOM by supporting the following interactions: • LogAssessmentRequest, LogEntityCreation, LogHealthUpdate, LogMaintenanceUpdate, LogMaintenanceUpdateV2, LogMaintenanceUpdateV3, LogisticsAssessment, LogisticsResupply, OrgStateInteraction. • Update OneSAF's HLA mapping to the ERF FOM. • Includes mapping to OTH enumerations to internal enumerations, as well as internal supply enumerations to what is required by JDLM. • Includes adding equivalent interactions in the SORD • Update models and BCFs to use these interactions to interface with JDLM.

10. WAN-Wide Execution(of the SCAMT) • OneSAF must have the capability to operate distributed over a WAN in a OneSAF distributed mode (OneSAF to OneSAF via WAN) as if it was operating on a LAN in a OneSAF standalone distributed mode. In order accomplish this a "Master SCAMT" from a single location needs to be able to substantiate multiple OneSAF workstations (100 - 200) across multiple sites distributing a single scenario to all sites and workstations.

11. WAN-Wide Execution(of the SCAMT) –Capabilities Provided • Update the SCAMT to support execution and control across a WAN to multiple simultaneous sites. • Support scalability assessment and improvements to allow SORD communications between up to 300 OneSAF Workstations and simulation cores. • Does NOT imply large-scale exercise support of the SORD or HLA across a WAN