Draft_OneSAF_V9.0_UseCases.pdf

Use Case

1. Capability type: User Interface.

Capability name: Ability to uniquely track crew status.

2. Doctrinal references: Not applicable.

3. Data elements:

a. The following data elements are specified at run-time:

(1) Force files.

(2) Exercise terrain.

(3) LDIF.

b. The following data elements are static:

(1) Entity property data.

(2) Unit composition.

4. Authoritative data source(s): Not applicable.

5. Definition

Use case summary:

a. In the slides for the March 1, 2016 OneSAF v8.7 and 9.0 Requirements Briefing, this was listed as a CR titled “No way to uniquely identify crew”. Some OneSAF vehicles are defined as having organic crews and as such damage in health status of individuals is not tracked. As operational testing moves toward new versions of key weapons systems, the crew in simulation takes on a greater role in data to be collected for analysis. Operation of the vehicle should be decremented if the crew is injured. Crew should be capable of going into MOPP 4.

b. Capabilities.

(1) Accessible during scenario building.

(2) Crew should be capable of being damaged with impact to vehicle performance.

Scope, scalability, and cost

The scope of this effort would be focused on modifying vehicle characteristics.

The scalability is affected by the size of the event and the focus of the supported exercise.

The cost is expected to be on the medium end of requirements for the v9.0 Requirements Integration

Board (RIB) since most data is available and just needs to be modified.

Author:

Geoff Robinson

Lead Senior Modeling and Simulation SME

Test Technology Directorate (TTD)

US Army Operational Test Command (OTC)

Office: 254-289-7830

Cell: 254-289-7830

Fax: 254-618-8443 geoffrey.a.robinson3.ctr@mail.mil

2. Capability name: Changeable re-engagement criteria.

3. Doctrinal references: Not applicable.

4. Data elements:

a. The following data elements are specified at run-time:

(1) Force files.

(2) Exercise terrain.

(3) LDIF.

b. The following data elements are static:

(1) Entity property data.

(2) Unit composition.

5. Authoritative data source(s): Not applicable.

6. Definition

a. Use case summary: Currently, OneSAF entities keep firing at an opponent until the opponent dies or takes significant damage, moves out of sight or range, or the shooter runs out of ammo. This is unrealistic. A tank crew that fails to hit a target after a second round will dis-engage and check the fire control system for damage or error. They will NOT just keep banging away until they get lucky or run out of ammo. They will fire more than 2 rounds if hits on the target are detected, but only up to a point; however, the target cannot be assessed as a kill (no smoke, fire or explosions).

Changeable re-engagement criteria would allow an operator to set how many rounds to fire until hit and how many to fire until a kill. Direct fire engagements don't stop at "Firepower or Mobility

Kill", engagement stops when the target is assessed as Destroyed. Consideration should be given to also create or set a target type priority list. This function should be available to operators for units they control, to allow them to set the criteria as per their unit Standard Operating Procedure (SOP) or as specified in an Operations Order.

b. Capabilities.

(1) Accessible during scenario building.

(2) Capable of being modified while running.

Scope, scalability, and cost

The scope of this effort would be focused on modifying weapons control status data.

The scalability is affected by the size of the event and the focus of the supported exercise.

The cost is expected to be on the medium end of requirements for the v9.0 Requirements Integration

Board (RIB) since most data is available and just needs to be modified.

Author:

Gregory Stineman

Sr M&S SME/GaN Corp

TTEC OTC (254)288-7669

1. Capability type: Enhancement Request for Combined Arms Breach.

2. Doctrinal references: Not applicable.

3. Data elements:

a. The following data elements are specified at run-time:

b. The following data elements are static:

4. Authoritative data source(s): Not applicable.

5. Definition

Use case summary:

a. Enhancement Request 81684. In the combined arms breach, the unit stops moving when the lead entity reaches the end of the breach lane, therefore leaving the remaining portion of the unit in the minefield. It maybe should be when the last entity reaches that point. Maybe add a point for them to rally at and a formation. Discovered at v8.0 TRADOC Project Office Release Test Event.

1. Capability type: Direct Fire Accuracy Model without AMSAA Data.

2. Doctrinal references: Not applicable.

3. Data elements:

a. The following data elements are specified at run-time: unknown

b. The following data elements are static: unknown

4. Authoritative data source(s): Not applicable.

5. Definition

Use case summary:

a. The desire is to support a non-analytic use case requiring Direct Fire effects not specified by

AMSAA data. OneSAF current approach is a mixture of incomplete adjustments to get accuracy and vulnerability data when AMSAA data is unavailable. This effort is to develop a coherent approach for direct fire accuracy and vulnerability when AMSAA data is not available (The user sets a property to 'provide non-AMSAA DF effects'.) The solution must be very simple to change.

Such an approach can use existing data, for example, OneSAF has two classifications, TargetClass and MunitionClass. The approach could be to 1. Create a MunitionClass to dispersion mapping to provide missing munition dispersion values based on the fired munition's munitionClass. If AMSAA accuracy data is missing and the property is set, look up the munition's dispersion in the new file and continue with the algorithm; and 2. Create a two dimensional array indexed by TargetClass and MunitionClass containing references to vulnerabilityPatterns. A vulnerabilityPattern provides the data for a kill thermometer given a munition in a MunitionClass hitting a target in a TargetClass. If AMSAA vulnerability data is missing and the property is set, ca look up the kill thermometer in the new file and continue with the algorithm. Additional keys may be required.

Electronic Emissions Use Case

1. Capability type: Other.

2. Capability name: Electronic Emissions.

3. Doctrinal references: FM 3-36 Electronic Warfare in Operations

4. Data elements:

a. The following data elements are specified at run-time:

(1) Operator control of turning emitter on and off.

(2) Location of the emitter, which is the location of the transmitter source.

(3) The transmitting frequency.

b. The following data elements are static:

(1) Type of emission by the device is transmitting. i.e tracking beam, interrogation beam, phone call, etc.

(2) Number of beams (for each emitter system) for which information is being provided in the PDU.

(3) Emitter system that includes the emitter name, function of the emission system, and emitter identification number.

(4) Parametric data for the emitter system.

(5) Emission targets if applicable.

(6) Ability to change frequency in response to jamming (the receipt of a higher powered transmitter on the same frequency)

5. Authoritative data source(s): IEEE Std 1278.1a-1998 and IEEE Std 1278.1-1995(R2002) (IEEE Standard for Distributed Interactive Simulation— Application Protocols Definition), SISO-REF-010-2011Simulation Interoperability Standards Organization (SISO) Enumerations for Simulation Interoperability and the RTI- NGmatrex user ‘s guide and High Level Architecture Federation Object Model version 7.1.

6. Definition.

Use case summary: Implements the ability for OneSAF entities to transmit detectable electronic signatures distributively. The emission capability of a specific entity or type of entity should be selectable based on the scenario. Entities that have the ability to detect these emissions must be able to interactively provide feedback on the detection. Transmissions involving voice or digital traffic should be able to be intercepted for intelligence gathering purposes. Interceptable transmissions should exploitable by inserting mis-information/deception messages. Emitting systems become non-operational if a higher powered transmitter is received on the same frequency as being transmitted. This capability is necessary to meet the Advanced Concepts and Requirements (ACR) Domain requirements for intelligence gathering and electronic defense and attack. The capability needs to be distributed using the DIS and HLA simulation protocols.

a. Priority of Effort should be:

(1) Produce electromagnetic emissions from radar.

(2) Produce electronic signal emissions from radio traffic including UAS to ground station links and vehicle and lifeform based Radio transmissions.

(3) Produce transmissions from cellular systems and walkie talkies, including IED detonation systems.

(4) Detect emissions and provide operator feedback.

(5) Ability to disrupt emitters with jamming/electronic attack.

(6) Intercept and exploit transmissions/communications.

b. During composition development the technician will define the parametric data for the system based on the required entries specified in the Authoritative data sources (item 5) above.

c. Ability to assign the following parameters in an orderable behavior.

(1) Queuing schedule for systems that will transmit periodically.

(2) Turn transmitter to “always on.”

(3) Affect the transmitted frequency based on system capability

(4) Establish linkage between transmitter and receiver in the case of direct communications. i.e UAS to ground station

(5) Change transmitter/receiver linkages. I e. change UAS to ground station transmit target ID

d. Ability to accomplish the following actions through intervention.

(1) Push to talk for cell phones and walkie talky type systems. i.e. IED electronic detonation device.

(2) Turn transmitter on and off.

(3) Display detected entities.

(4) Change direction of transmitting antenna.

e. Expected results:

(1) External simulations and instantiations of OneSAF are able to receive transmissions via Electromagnetic emissions AND transmitter DIS Protocol Data Units and HLA objects.

(2) Entities that have the capability to detect transmissions in the electromagnetic spectrum will display detections to the simulation operator.

(3) If a transmitting system receives a transmission on its transmitting frequency that is of sufficient power, as determine in the composition creations, to saturate the receiver, the transmitting entity shall cease to function in its electronic role.

Behavior to control Passive Sensors on Entities

1. Capability type: Other.

2. Capability name: Passive Sensor Control.

3. Doctrinal references:

4. Data elements:

5. Authoritative data source(s): Behavioral, determined by scenario developer.

6. Definition

a. Use case summary: Provides the scenario developer with detailed control over which sensors on entities are searching at any point during execution. This could be done for various reasons, including:

limiting the impact of sensing on simulation run-time and eliminating acquisitions from sensors that would either not normally contribute to engagement or shouldn’t be acquiring due to their mission

(e.g., running to a location, digging a ditch, etc.).

b. Capabilities:

(1) Provide an orderable behavior that turns on or off a Passive Sensor on an entity

(a) Must be usable interactively by the operator of the MCT or WCT.

(b) Must be usable within the task org frame for constructive use.

(c) Must be usable within the Branch and Sequel for constructive use.

(2) Provide a changeable property on entities as part of a saved scenario that will dictate the condition of Passive Sensors at the start of a scenario.

(3) Provide an orderable behavior that limits the range and field-of-regard at which a Passive Sensor searches.

(a) Dynamically change the “operationalMaxRange” of a Passive Sensor, in addition to being able to set it from the file “maxSensorRangeOverride_KED0528.xls”.

(b) Allows the scenario developer to control the set of targets of interest or the area covered by an entity, depending on the situation and areas of responsibility.

Flexible Framework for Reactions and Decision Points

Capability type: New Flexible Reactive Behaviors for Interrupting or Following-on Existing Missions.

1. Capability name: Framework for Reactions and Decision Points

2. Doctrinal references: None

3. Data elements: Follow-on behavior(s) to be conditionally executed. Conditions or facts that would cause the currently executing behavior to be interrupted/suspended. Decision criteria for the case of multiple follow-on behaviors in reaction.

4. Authoritative data source(s): tbd

5. Definition

a. Use case summary of capability: Mission planning allows for both a primary behavior and a choice of follow-on behavioral reactions for the unit or entity being tasked.

(1) Effort is to create eight more reactive behaviors within the framework.

1. Capability type: Enhancement Request for Maneuvering Infantry.

2. Doctrinal references: Not applicable.

3. Data elements:

a. The following data elements are specified at run-time:

b. The following data elements are static:

4. Authoritative data source(s): Not applicable.

5. Definition

Use case summary:

a. Enhancement Request 61207. This enhancement request is to increase the fidelity of reactive behaviors. While conducting an air assault during the brigade vignette, operators are encumbered by the amount of micro-management required to achieve a desired result. Specifically, problems can revolve around the maneuvering of infantry squads on approach to an objective. To optimize the behavior of entities, one has to give them the following orders in the execution matrix: 1)

Posture Change to Standing (they had been in prone to avoid being killed) 2) Infiltrate 3) Posture

Change to prone 4) Formation change to wedge 5) Support by fire on objective. Ideally, it would be better to give each squad one order. In the case above, this would be support by fire. The squad must be able to maneuver without what is effectively the company commander telling it to undertake basic protective measures (change posture and formation according to the situation).

The result of being forced to micromanage one’s force leaves one unable to focus on the big picture, often having to "get in the weeds". Discovered at v8.0 TRADOC Project Office Release

Test Event.

2. Capability name: Omni-directional Routes.

3. Doctrinal references: Not applicable.

4. Data elements:

a. The following data elements are specified at run-time:

(1) Force files.

(2) Exercise terrain.

(3) LDIF.

(4) Operational Graphics.

b. The following data elements are static:

(1) Entity property data.

(2) Unit composition.

5. Authoritative data source(s): Not applicable.

6. Definition

a. Use case summary: In the slides for the March 1, 2016 OneSAF v8.7 and 9.0 Requirements

Briefing, this was listed as part of 9.0 RPB, but not funded. The title listed was “Follow route from a point other than beginning (mid-route).” Routes need to be omni-directional, with entities/units being able to enter or exit them at the closest point to their destination. Currently, routes are uni-directional (travelling from the creation point to end point). Entities/units have to enter them at the creation point, travel to the end point, and from there to their destination. This results in wasted time and fuel and presents a non-realistic behavior. To try to present a realistic tactical operation, a route must be built twice (once in one direction, then another in reverse). Also, the route(s) must be broken into small sections. This creates excess work for the operator and introduces multiple points of possible error to orders creation (i.e.: choosing the wrong route from a very, very large selection).

b. Capabilities.

(1) Accessible during scenario building.

(2) Capable of being modified while running.

Scope, scalability, and cost

The scope of this effort would be focused on modifying the properties of operational graphics.

The scalability is affected by the size of the event and the focus of the supported exercise.

The cost is expected to be on the medium end of requirements for the v9.0 Requirements Integration

Board (RIB) since most data is available and just needs to be modified.

Author:

Gregory Stineman

Sr M&S SME/GaN Corp

TTEC OTC (254)288-7669

INDEX #

1. Capability type: Other / Physical Model

2. Capability name: Platform as a Munition vs ICs

3. Reference: TBD

4. Data elements:

a. AMSAA Standard File Format (SFF) Report(s)

5. Authoritative data sources (ADS): TBD

6. Definition:

a. Use Case Summary

PM CCWS is investigating myriad notional weapons systems to improve the effectiveness of the Soldier on the battlefield. One such system is the Loitering Miniature Aerial Munition System (LMAMS); which allows a soldier (controller) to control the flight of a munition to its target where it will detonate due to a signal from a proximity detector. The current AMSAA IC Vulnerability Model does not account for this use case because it requires a Platform->Weapon->Mount- >Munition->Target pairing to evaluate the effects. Reducing the requirement to Munition->Target pairing in instances of fully- or semi-autonomous munitions will enable users of OneSAF to more effectively and efficiently address Experiment Objectives for this type of munition.

b. Cueing OneSAF entities

[1] Operator Action: Order a Special Weapons Operator to put the Platform as a Munition in operation, control its movements via Control Measures, assign a target, and either prosecute the target or abort the mission – either of which results in the explosive catastrophic kill of the munition.

[2] Expected Result: In the event of a target prosecution, the vulnerability model will reference a parametric data file resembling the INF_PROB_INCAP_VS_RANGE_ANGLE.dat report for casualty evaluation. Data Collection Tool will credit the kill to the controller via the munition.

DRAFT: