Information_Exchange_Requirements_for_GTISS_(Draft)_Jan2017.pdf

DRAFT DOC-IER-XXX D

USE OR DISCLOSURE OF DATA

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Enterprise Engineering Integrated Product Team (EE IPT)

Information Exchange Requirements for the

Ground Test Integrated System Simulation

(GTISS)

24 Jan 2017

DOC-IER-XXX

DISTRIBUTION STATEMENT F:

Further dissemination only as directed by DoD, Missile Defense Agency, ATTN: Mr. Charles Clements, Agreement Officer MDA/DAC, 7100 Defense Pentagon, Washington DC 20301-7100, or higher authority.

WARNING

This document contains technical data whose export is restricted by the Arms Export Contract Act (22 USC 2751 et seq.), or the Export Administration Act of 1979, as amended (50 USC Appendix 2401 et seq.). Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.24.

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

i

Document Information

Document Identification

DOC-ICD-XXX

Original Release Date

Oct 7, 2015

Document Type

(ASN/ACN/ECP/DOC)

DOC

Preparing Organization

Enterprise Engineering Integrated Product Team (EE IPT)

Notes and Limitations (optional)

EE IPT Chair Date

Enterprise Cell Manager Date

DES Director Date

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

ii

Revision Record

Revision Date Change Affected Pages

Draft 0.1 Oct 7, 2015 Initial Draft All

Draft 0.2 Oct 28, 2015 Draft Updated per GM comments All

Draft 0.3 Nov 5, 2015 Initial ENV/TI, All

Draft 0.4 Dec 8, 2015 EO/IR pixelated scene/Interceptor init All

Draft 0.5 Dec 21, 2015 Element configuration info All

Draft 0.6 Jan 6, 2016 Clean up All

Draft 0.6.1 Jan 13, 2016 Clean up of text, removed shalls All

Draft 0.7 Jan 22, 2016 Reformatted RCS File section, updated requirements trace

Section 3.2, and 4

Draft 0.8 Feb 22, 2016 Modified refraction and element config IER

Draft 0.9 May 16, 2016 Included comments from PDR Review All

Draft 0.91 Nov 18, 2016 E-Tasker Version - Updated Truth Interactions

All

Draft 0.99 Jan 20, 2017 E-Tasker Comments included All

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

iii

Table of Contents

1.0 SCOPE

1.1 Document Overview

1.2 Document Structure

1.3 System Overview

2.0 REFERENCED DOCUMENTS

2.1 Government Documents

2.2 Non-Government Documents

3.0 INTERFACE EXCHANGE REQUIREMENTS

3.1 Data Exchange Model Overview

3.2 Data Exchanges by Execution Phase

3.2.1 Pre-Execution Data

3.2.1.1 Network Configuration

3.2.1.2 Site, Application, Entity ID

3.2.1.3 RF Signature File Information

3.2.1.3.1 Radar Cross Section Enhanced Statistical File

3.2.1.3.2 Radar Cross Section Signature Mapping File

3.2.1.4 Emitter Mapping File

3.2.1.5 EO/IR Signature Files

3.2.1.6 Cobra Dane Pre-scripted Input File

3.2.2 Execution Phase

3.2.2.1 Application Startup Phase Exchanges

3.2.2.1.1 Test Event Configuration IER

3.2.2.1.2 Element Configuration IER

3.2.2.1.3 Health Status and Error IER

3.2.2.2 Scenario Initialization Phase Exchanges

3.2.2.2.1 Scenario Initialization IER

3.2.2.2.2 Health Status and Error IER

3.2.2.3 Environment and Truth Interactions Initialization Phase Exchanges

3.2.2.3.1 Environment Initialization IER

3.2.2.3.2 RF Propagation Truth Interactions IERs

3.2.2.3.3 EO/IR Propagation Truth Interaction IERs

3.2.2.3.4 Health Status and Error IER

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

iv

3.2.2.4 Mission Execution Phase Exchanges

3.2.2.4.1 Start Mission IER

3.2.2.4.2 RF Sensor IERs

3.2.2.4.3 EO/IR Overhead Sensor IERs

3.2.2.4.4 Blue Force Interceptor IERs

3.2.2.4.5 Post Intercept Debris IERs

3.2.2.4.6 Communication Link Closure IERs (GBI)

3.2.2.4.7 Dynamic Triggering/Fault Injection IER

3.2.2.4.8 Dynamic Environment Updates

3.2.2.5 Mission Termination Phase Exchanges

3.2.2.5.1 Stop Mission IER

3.2.2.5.2 Stop Mission Acknowledge IER

3.2.3 Post Execution

4.0 REQUIREMENTS TRACEABILITY

SITE/APP/ENTITY ENUMERATIONS

A.1 Blue Force Site/App/Entity Enumerations

A.2 Trackable Objects Site/App/Entity Enumerations

STATISTICAL RADAR CROSS SECTION (RCS)

MODELING 57

AGGREGATE RADAR CROSS SECTION (RCS)

MODELING 60

C.1 Aggregate RCS Model Data Sources

C.2 Aggregate RCS Model Overview

C.3 Aggregate RCS Model Algorithm Details

C.4 Generate Sensor Signal from Bins

ELEMENT SPECIFIC INFORMATION

STANDARDS

E.1 Time Reference Standard

E.2 Coordinate Systems

E.3 Radar Face Coordinates

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

v

TABLES

TABLE 2.1-1 – GOVERNMENT DOCUMENTS

TABLE 2.2-1 – NON-GOVERNMENT DOCUMENTS

TABLE 3.2-1 – EXECUTION SUB PHASES

TABLE 3.2-2 – SITE/APP/ENTITY DATA TYPE DESCRIPTION

TABLE 3.2-3 – GTISS SIGNATURE FILE FORMATS BY BAND

TABLE 3.2-4 – RADAR CROSS SECTION ENHANCED STATISTICAL FILE

TABLE 3.2-5 – RCS SIGNATURE MAPPING FILE FORMAT

TABLE 3.2-6 – SIMPLE SIGNATURE TABLE TYPE

TABLE 3.2-7 – ITP PROVIDED FILE BASED SIGNATURE FILE TYPE

TABLE 3.2-8 – EMITTER MAPPING FILE FORMAT

TABLE 3.2-9 – TEST EVENT CONFIGURATION IER

TABLE 3.2-10 – ELEMENT CONFIGURATION IER

TABLE 3.2-11 – HEALTH STATUS AND ERROR IER

TABLE 3.2-12 – SCENARIO INITIALIZATION IER

TABLE 3.2-13 – ENVIRONMENT INITIALIZATION IER

TABLE 3.2-14 – TROPOSPHERIC REFRACTION IER

TABLE 3.2-15 – LENS LOSS IER

TABLE 3.2-16 – ONE-WAY TROPOSPHERIC ABSORPTION LOSS IER

TABLE 3.2-17 – TROPOSPHERIC SCINTILLATION

TABLE 3.2-18 – IONOSPHERIC EFFECTS IER

TABLE 3.2-19 – START MISSION IER

TABLE 3.2-20 – SENSOR BORESIGHT IER

TABLE 3.2-21 – NEW OBJECT SIGNATURE IER

TABLE 3.2-22 – RF SENSOR SCENE UPDATE IER

TABLE 3.2-23 – OBJECT STATE IER

TABLE 3.2-24 – RF SENSOR SCENE UPDATE RATES

TABLE 3.2-25 – AGGREGATE IER

TABLE 3.2-26 – EO/IR EXTENDED PLUME FILE FORMAT

TABLE 3.2-27 – EO/IR SENSOR SCENE UPDATE IER

TABLE 3.2-28 – OBJECT STATE IER

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

vi

TABLE 3.2-29 – INTERCEPTOR INITIALIZATION IER

TABLE 3.2-30 – INTERCEPTOR EVENT IER

TABLE 3.2-31 – INTERCEPTOR STATE IER

TABLE 3.2-32 – INTERCEPTOR STATE UPDATE RATES

TABLE 3.2-33 – EO/IR SCENE REQUEST IER

TABLE 3.2-34 – KV EXTENDED SCENE EO/IR

TABLE 3.2-35 – POINT SOURCE IER

TABLE 3.2-36 – OBJECT IMPACT IER

TABLE 3.2-37 – OBJECT DEMISE IER

TABLE 3.2-38 – IN-FLIGHT TARGET UPDATE IER

TABLE 3.2-39 – IN-FLIGHT STATUS REPORT

TABLE 3.2-40 – DYNAMIC TRIGGER/FAULT INJECTION

TABLE 3.2-41 – DYNAMIC TRIGGERING ENUMERATIONS

TABLE 3.2-42 – STOP MISSION IER

TABLE 3.2-43 – STOP MISSION ACKNOWLEDGE IER

FIGURES

FIGURE 1.3-1 – OSF SIMULATION INFRASTRUCTURE

FIGURE 3.2-1 – EXECUTION PHASES

FIGURE 3.2-2 – NOTIONAL GTISS LOGICAL INTERNAL BLOCK DIAGRAM

FIGURE 3.2-3 – APPLICATION STARTUP SEQUENCE DIAGRAM

FIGURE 3.2-4 – SCENARIO INITIALIZATION SEQUENCE DIAGRAM

FIGURE 3.2-5 – ENVIRONMENT INITIALIZATION SEQUENCE DIAGRAM

FIGURE 3.2-6 – IONOSPHERIC TABLE SCALING

FIGURE 3.2-7 – MISSION EXECUTION SEQUENCE

FIGURE 3.2-8 – RADAR STIMULUS SEQUENCE

FIGURE 3.2-9 – EO/IR OVERHEAD SENSORS

FIGURE 3.2-10 – BLUE FORCE INTERCEPTOR SEQUENCE

FIGURE 3.2-11 – MISSION TERMINATION SEQUENCE

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

1.0 SCOPE

This Information Exchange Requirements (IER) Document identifies the requirements for

BMDS Modeling & Simulation (M&S) Participants to exchange data within the context of an open-architecture simulation environment. An information exchange requirement (IER) is the description, in terms of characteristics, of a requirement to transfer information between two or more participants within a simulation architecture. The characteristics described herein include source, recipients, contents, size, and timeliness. IERs are defined to be independent of the communications medium (e.g., protocol). The Objective Simulation Framework (OSF) is the

M&S Framework that provides the simulation infrastructure to link Participant Element representations in a common distributed simulation environment. This document defines the information exchange requirements to support the definition of the software and physical interfaces between Participant Element representations, including Hardware-In-The-Loop

(HWIL), within an integrated (GTI) or distributed (GTD) Ground Test environment.

1.1 Document Overview

This document specifies the OSF and BMD Element representation data exchanges, to include defined standards, data items, and sequencing information, for simulation data in support of PAA

Phase 3 Ground Test venue.

1.2 Document Structure

This section specifies the overall structure of the document:

Section 1 Specifies the Scope and System Overview of the BMDS Ground Test simulation environment.

Section 2 Identifies referenced documents.

Section 3 Provides a description of the logical interface exchange requirements between the

Participant Elements and the OSF. This section defines the simulation data exchange model that specifies the unique data elements supporting the simulation interface. This section also provides a description of specific simulation Execution phases which further organize the simulation data exchange requirements.

Section 4 Provides interface requirements traceability to the M&S Systems Requirements

Document (SRD).

Section A-G Appendices.

1.3 System Overview

The Missile Defense Agency’s (MDA) Ground Test architecture is designed to integrate BMDS

Element Representations in a distributed, real-time, battlefield environment to emulate tactical operations. Element Representations can include actual tactical elements, Digital simulation models, HWIL, or a combination thereof. HWIL Representations generally include tactical hardware and software components integrated with a simulation driver interface. This HWIL simulation interface provides the capability to operate tactical components within the simulation environment.

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

The Objective Simulation Framework (OSF) provides the mechanism that enables the BMD

M&S System to simulate missions via the production, transport, and use of information. The

OSF provides the simulation infrastructure to facilitate the Element and Truth representation interactions; and provides the overall simulation management and operation capability for the development and execution of BMDS M&S events. As noted in Figure 1.3-1 – OSF Simulation

Infrastructure, OSF maintains a series of Framework interfaces (center of graphic) to provide the simulation data exchange capability between the simulation participants. Simulation participants can include Element models, Truth models, support applications, and third-party applications.

This document defines the interface exchange requirements needed to construct the specific data exchange services implemented by the OSF to provide test and threat stimulation to the BMDS system. The Participant Elements will utilize the OSF-provided interface services to transmit and receive simulation data as part of the Ground Test event execution.

Figure 1.3-1 – OSF Simulation Infrastructure

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

2.0 REFERENCED DOCUMENTS

This section contains citations for documents relevant to this Information Exchange

Requirements (IER) Document. Unless specifically identified, the document, date, notice, and revision currently in effect is invoked throughout this document.

2.1 Government Documents

Table 2.1-1 contains the government documents referenced in this IER Document.

Table 2.1-1 – Government Documents

DOCUMENT ID DOCUMENT NAME

SRD – April 2014

Modeling and Simulation (M&S) System Requirements

Document (SRD) PAA Phase 3 (Dec 2018) / D4 / Ground Test

Venue 30 April 2014

900DSC0073D OSF Interface Control Document (ICD), Rev D

DSC0367C

Single Stimulation Framework Interface Control Document for

Distributed Interactive Simulation and Consistent Truth

Implementation Interfaces

ESP-ICD-1490-1.0

Single Stimulation Framework Interface Control Document for

Distributed Interactive Simulation and Consistent Truth

Implementation Interfaces

MDA-ESO-TXX-13

Threat Modeling and Simulation System (TMSS) Interface

Requirements Specification, Version 10.1 15 March 2014

MDA-STD-004A BMDS Position, Navigation, and Timing (PNT) Standard

MDA INSTRUCTION 3000.07-INS BMDS Ground Test Concept of Operations Mar, 2013

D742-10108-2 GFC/C-GBI Interface Design Document

900DSC1070

Interface Control Document for Single Stimulation Framework

(SSF) and Cobra Dane

NGA.STND.0036_1.0.0_WGS84

National Geospatial-Intelligence Agency (NGA) Standardization

Document, DOD World Geodetic System 1984, July 8, 2014

2.2 Non-Government Documents

Table 2.2-1 contains the Program documents referenced in this IER Document.

Table 2.2-1 – Non-Government Documents

DOCUMENT ID DOCUMENT NAME

Project Report LDS-1 Radar Signature Generation Using the Augmented Point

Scatterer Model (APSM) V3.1

SISO-REF-010-2015 Reference for Enumerations for Simulation Interoperability, V.21

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

3.0 INTERFACE EXCHANGE REQUIREMENTS

The current Ground Test Single Stimulation Framework (SSF) and Objective Simulation

Framework (OSF) implement multiple stimulation interfaces at the M&S component level. That is, for each participating simulation asset, the unique interface implementation is specified by the respective SSF and OSF interface control documentation (ICD). Conversely, the goal of this document is to identify stimulation data (not protocol) available to all GT Participant Elements within the context of a single interface requirements document. The stimulation information data exchange requirements specified herein support the stimulation data exchange between

Participant Element and Truth Representations (to include models, supporting utilities, and

HWIL driver software), and the underlying OSF service groups designed to support simulation interoperability within a distributed simulation environment. The following sections identify simulation data exchange requirements per execution phase.

While the purpose of this document is to identify the simulation data exchange requirements for

BMDS GT applications, the specific implementation of the associated interfaces is beyond the scope of this document. As the BMDS M&S Framework(s) matures, it is expected that updated

Interface Control Documents (ICDs) will be produced to specify and document the specific interface implementation as provided by the Framework. Therefore, the IER document is responsible for documenting the overall simulation data exchange model (to include specific attributes, data types, units, etc.) with the understanding that the specific implementation, to include protocol, will be defined by the Framework (e.g., OSF) ICD.

3.1 Data Exchange Model Overview

Data exchanges are intended to immerse the BMDS Participant Element Representations in a synthetic battlespace environment to stimulate tactical actions and defensive responses

(intercepts, PID, and induced battlespace environments) to incoming threats. The simulation data exchanges defined by this document are binned into categories known as service groups. The simulation service groups provide a logical grouping of exchange requirements based on the type of simulation data, and how it is utilized within the integrated environment. In addition, specific phases of simulation execution are defined to further articulate the flow of specific events. The following section provides an overview of the simulation Execution phases, as well as a brief description of the supporting simulation service groups.

3.2 Data Exchanges by Execution Phase

For the purposes of understanding the generation of simulation data exchange information and the flow of event execution, a Ground Test event can be divided into three (3) primary phases of execution:

1. Pre-Execution

2. Execution

3. Post Execution

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Figure 3.2-1 – Execution Phases

Figure 3.2-1 provides a time lapsed depiction of phases with detailed activities within each of the phases.

Pre-Execution phase describes activities that occur prior to the start of the Element

Representation application. These activities include the Blue Force laydown, their attributes, and the Integrated Data Package which includes distribution of a priori signature and threat information required by OSF and Element Representations prior to application startup. The IDP is the ITP plus scenario and interceptor information as defined in the GTISS SysML Model.

Execution phase refers to activities that occur from Element Representation application startup to their termination. Activities that occur before a wall clock start time are referred to as Pre-mission. Activities between wall clock start time and mission termination are referred to as mission time. After mission termination is referred to as post-mission. To aid in understanding the flow of information defined within the Execution phase, this document further divides the

Execution phase into 5 sub phases (Table 3.2-1):

Table 3.2-1 – Execution Sub Phases

Execution Sub Phase Description

Application Startup

Includes the test director and operator initiation of the execution of all Element Representation software and initial connectivity between participating Elements and OSF to support a test event.

Scenario Initialization Specifies the data exchanges required to the initial conditions and prescribed threat actions of the scenario for the test event.

Environment / Truth

Interaction Initialization

Describes the initialization parameters for all environment models and corresponding truth interactions used by each Element during the scenario.

Mission Execution

Describes the exchange of information that occurs when wall clock start time has been reached, signifying the execution start of the test event.

Mission Termination Exchange of information following all threat demise; or operator’s desire to terminate the test event mission execution.

Post Execution phase refers to activities that occur after Mission Termination when each

Element representation ceases to process stimulation data from the test participants in the context of the simulated scenario environment and cleanly closes all log files. This phase includes the

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

collection of recorded data, post processing of recorded data files, and other after action activities.

The individual IER functionality will be implemented by the OSF and will provide specific method/services to the participants to utilize as required by their respective level of participation.

Participants would utilize the methods/services provided by OSF to produce and consume data specific to their functionality. Participants will only be required to utilize the method/services that are applicable to their representation requirements.

Figure 3.2-2 – Notional GTISS Logical Internal Block Diagram

Figure 3.2-2 shows notional logical connectivity between GTISS components. This document focuses on data transported across the “Test and Control”, “Environment & Scenarios”, “Pre-

Execution” and “Test Setup” paths. The OSF will implement the public services that will be utilized by all external participants to support test event interoperability. The IERs defined by this document provide the basis for the public services implemented by the OSF.

3.2.1 Pre-Execution Data

Prior to the Execution phase, each participant in the architecture requires information to support interconnectivity, as well as a priori object signature and environment information. This includes information for network connectivity, entity identification, and mapping from planned scenario

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

objects to Element specific threat and blue force signatures. The following sections describe data requirements and file formats for each type of pre-execution data.

3.2.1.1 Network Configuration

Network connectivity between participating Elements and OSF will be required to facilitate the exchange of simulation information identified within this document. Information required by each Element participant to establish connectivity prior to application execution can vary depending on the selected information exchange protocol.

It is not the intent of this document to specify the design solution for the interface protocol implementation. This section exists to highlight the need to identify the interface implementation information within the OSF Interface Control Document (ICD).

3.2.1.2 Site, Application, Entity ID

The Framework implements an entity object identification scheme to support high object count requirements. This object identification scheme utilizes a Site, Application, Entity (S/A/E) combination (Table 3.2-2) similar to the Entity Id field of the Entity State PDU as specified by the Distributed Interactive Simulation, Version 6 (DIS) standard. OSF also supports the S/A/E identifiers for Blue Force Element entity state (ownship) information as identified in Appendix A of this document. Each Blue Force Element representation will be assigned an S/A/E identifier that will be used for their identification via the Test Event Configuration IER as specified in

Table 3.2-9 – Test Event Configuration IER. OSF will be required to maintain this entity assignment information for each scenario, and for each Element participant prior to execution.

Table 3.2-2 – Site/App/Entity Data Type Description

Field Description Data Type Unit

Site/App/Entity Site 16-bit Unsigned Integer Enum

App 16-bit Unsigned Integer Enum

Entity 32-bit Unsigned Integer Enum

To support threat complex, interceptor debris, and threat debris entity representation, the S/A/E identifiers will be implemented as follows:

Each individual static threat complex is assigned a unique S/A: 100/1, for threat complex 1;

100/2 for threat complex 2; etc. Post intercept debris created from the threat will be placed into the complex S/A (e.g., 100/1) of the intercepted threat. Interceptor debris fragments will be placed within the threat complex S/A (e.g., 100/1) for intercepted threat complex.

As an example, consider a static threat complex that has 10 objects (i.e., 100/1/1-10), and the planned debris generation is 200 fragments for threat and 20 fragments for interceptor. Upon first intercept of this threat, interceptor debris would be assigned S/A/E 100/1/11-30 and threat debris would be assigned S/A/E 100/1/31-230. Subsequent intercepts of objects within the 100/1 complex would begin assigning S/A/E IDs beginning at 100/1/231 using the same scheme described above

Site/App/Entity Enumerations are identified in Appendix A.

3.2.1.3 RF Signature File Information

Radio Frequency (RF) Sensor Elements to be stimulated within a test event will utilize a Radar

Cross Section (RCS) mapping file that associates numerical signature identifiers (signature ID’s)

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

to single RCS values, statistical RCS initialization values, or to files containing RCS Scattering

Center Models (SCM). RCS SCM formats can represent multiple frequency, multiple spatial dimensions, and specific polarization information.

Each of these signature IDs will map to known objects or object classes in the simulation representation, including threat, debris, and interceptors.

The RCS files, referenced in the mapping file, are distributed to the Elements as part of the

Integrated Data Package (IDP) prior to application execution within a defined directory structure.

The IDP provides various RCS file formats, depending on radar band or radar specific needs.

Table 3.2-3 indicates the specific signature file formats provided by the ITP per band, along with the corresponding Element representations that utilize them:

Table 3.2-3 – GTISS Signature File Formats by Band

Frequency Band

File Format UHF L-Band S-Band C-Band X-Band

.tbl (Circular) UEWR

.cpave UEWR Patriot MPQ-65 SBX, AN/TPY-2(FBM)

.tbl3

.tbl(Linear) CD Aegis SPY-1

.rcsave Aegis SPY-1

.field .ss Aegis SPY-1 Patriot MPQ-65

.3dsc Aegis SPY-1

.sc Patriot MPQ-65

.npttbl2

SBX, AN/TPY-2(FBM),

AN/TPY-2(TM)

.apsm SBX, AN/TPY-2(FBM)

.rscv1

SBX, AN/TPY-2(FBM),

AN/TPY-2(TM)

.cors, enh_*.cors UEWR Aegis SPY-1 Patriot MPQ-65

SBX, AN/TPY-2(FBM),

AN/TPY-2(TM)

Note: Each of the file formats identified above are documented in the Threat Modeling and Simulation

System (TMSS) Interface Requirements Specification, Version 10.1 15 March 2014.

For dynamic object data generated during mission execution, such as post-intercept debris (PID), this document provides a mechanism to create new signature mappings using an Enhanced

CORS statistical representation as documented in

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Table 3.2-21 – New Object Signature IER.

3.2.1.3.1 Radar Cross Section Enhanced Statistical File

The Radar Cross Section (RCS) Enhanced Statistical file format is a proposed format that provides a Statistical Radar Cross section representation for a trackable object. This format is derived from the Enhanced CORS format documented in the Threat Modeling and Simulation

System (TMSS) Interface Requirements Specification (IRS). Whereas the TMSS version documents a single size attribute, the following version identifies both a Principal Polarization electrical length and an Orthogonal Polarization electrical length. For linear polarized sensors, only the PP attributes would be used in a standard CORS application(See appendix B for CORS

Definition).

There is one file for each threat object type that is being characterized using this statistical technique. Table 3.2-4 identifies the format for the Radar Cross Section (RCS) Enhanced

Statistical file.

Table 3.2-4 – Radar Cross Section Enhanced Statistical File

Field Description Data Type Unit

Header

Three lines of 8-bit characters terminated with a null character followed by a line feed. The first and second lines are constrained to 30 and 20 characters respectively (inclusive of the null and line feed characters). The third line is unlimited in length.

Unsigned Character (8 bit)

PP RCS Min PP minimum NB radar cross section. 32-bit Float dBsm

PP RCS Max PP maximum NB radar cross section. 32-bit Float dBsm

PP RCS Mean PP average NB radar cross section. 32-bit Float dBsm

PP RCS Sigma PP standard deviation of the NB radar cross section. 32-bit Float dBsm

PP RCS Tau PP correlation time of the RCS samples. 32-bit Float Seconds

PP RCS Bound Max change in PP NB RCS value per update. 32-bit Float dBsm

PP Elec Length PP body electrical length. 32-bit Float Meters

OP RCS Min OP minimum NB radar cross section. 32-bit Float dBsm

OP RCS Max OP maximum NB radar cross section. 32-bit Float dBsm

OP RCS Mean OP average NB radar cross section. 32-bit Float dBsm

OP RCS Sigma OP standard deviation of the NB radar cross section. 32-bit Float dBsm

OP RCS Tau OP correlation time of the RCS samples. 32-bit Float Seconds

OP RCS Bound Max change in OP RCS value per update 32-bit Float dBsm

OP Elec Length OP body electrical length. 32-bit Float Meters

3.2.1.3.2 Radar Cross Section Signature Mapping File

The Radar Cross Section (RCS) Signature Mapping file assigns a signature ID to specific a priori signature information for all applicable (e.g., threat, debris, etc.) object types included within the given scenario. Objects of the same type will reference the same signature ID. This approach provides the capability for each sensor Element Representation to pre-load the RCS information prior to mission execution allowing rapid table lookups for RCS data based on kinematic state data. Signature information can exist as simple (single RCS value), or consist of a reference to statistical or scattering center formats identified in Table 3.2-3 above. The RCS Signature

Mapping File format is specified in

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Table 3.2-5. The signature ID will be included in object state updates to associate the applicable object with a specific RCS representation. Unless otherwise specified, each field of the table represents a line in the file ending with a line feed character. The file can contain any number of signature IDs the respective signature information. Each signature ID definition starts with a table header and ends with the word “End”.

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Table 3.2-5 – RCS Signature Mapping File Format

Field Description Type Unit

Table

Header

Multiple lines of informative text, each preceded by --, to provide creation date, RCS source, classification, author, etc.

String

Signature ID

Unique signature data identifier, maps signature definition to RCS

ID in the Object State IER.

Unsigned Integer

Entity Type

Entity kind, domain, country, category, subcategory, specific and extra data elements.

Reference for Enumerations for

Simulation Interoperability, Version 21 (SISO-REF-010-2015)

Table Type Type of RCS Table can be set to simple or file based Enumeration

‘Simple’, or

‘File Based’

Simple or File Based specific format - See following sections that define the content for each

End Terminator indicates the end of a

RCS data table String

Blank line in file

If table type is set to “Simple”, the following information will precede “End”:

Table 3.2-6 – Simple Signature Table Type

Field Description Type Unit

Table Type Simple Enumeration Simple RCS Value Single RCS value (dBsm) Floating Point dBsm End Terminator indicates the end of a RCS data table String Blank line in file

If the table type is “File Based”, the following information will precede “End”:

Table 3.2-7 – ITP Provided File Based Signature File Type

Field Description Type Unit

Table Type File Based Enumeration Simple

RCS

Filename1

Relative path and Filename of signature file (Relative to scenario directory identified in scenario IER) with file type extension.

String

End Terminator indicates the end of a RCS data table String

Blank line in file

Note 1– Filename extension will define the file type. (e.g., .apsm)

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

3.2.1.4 Emitter Mapping File

The Emitter Mapping file associates an emitter ID to specific capabilities for all threat object types that are passive or active emitters within the given scenario. If the object is an emitter, then the Emitter ID in the object state IER will be a non-zero number. The sensor element will use this emitter id to determine the effects of the emitter on its sensor returns. This approach provides the capability for each sensor Element Representation to pre-load the emitter information prior to mission execution allowing rapid table lookups for emitter data.

Table 3.2-8 – Emitter Mapping File Format

Field Description Type Unit

Table

Header

Multiple lines of informative text, each preceded by --, to provide creation date, source, classification, author, etc.

String

Emitter ID Unique Emitter identifier, maps emitter definition to Emitter

ID in the Object State IER.

Integer N/A

Emitter Type Type of Emitter Enumeration TBD

Emitter

Filename2

Relative path and Filename of emitter file (Relative to scenario directory identified in scenario IER) with description of Emitter.

String

Emitter ID, Type, and filename are repeated for all Emitters in scenario.

End Terminator indicates the end of a Emitter data table. String

Blank line in file

3.2.1.5 EO/IR Signature Files

Overhead Persistent Infrared (OPIR) Element participants utilize the “ECF_AZ” file format identified in Section 6.1.3 of the TMSS Interface Requirements Specification (IRS). This file contains Boost IR Plume signature data specified as Below the Horizon (BTH), Above the

Horizon (ATH), and Medium Wave Infrared (MWIR) source intensities (KW/sr) for a given scenario as a function of time and Earth Centered, Earth Fixed (ECEF) position. IR Hard body signature data is in the Optical Signature Code (OSC) BANDSIGS output file format with a 17 column to BANDSIGS file map. The OPIR model software will replay this file in synchronized time with the OSF stimulation of other Elements.

3.2.1.6 Cobra Dane Pre-scripted Input File

The Cobra Dane radar asset does not maintain a physical interface to the OSF. It uses a pre-computed binary file that contains both environment and scenario information that is procedurally replayed by Cobra Dane software and its operators. The file format used by Cobra

Dane is documented in the Interface Control Document for Single Stimulation Framework (SSF) and Cobra Dane, 900DSC1070.

3.2.2 Execution Phase

The Execution phase refers to activities that occur from Element Representation application startup to their termination. Activities between mission start time and mission termination are referred to as mission time. The period following mission termination is referred to as post-mission. This document divides the Execution phase into 5 sub phases to aid in understanding the flow of information.

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

In addition to the IER information presented, each Execution phase section will contain a high-level sequence diagram. The purpose of the sequence diagram graphics is to show notional information exchanges arranged in time sequence. The diagrams depict the high-level M&S components with the associated sequence of messages exchanged between the components to carry out the functionality of the Execution phase.

3.2.2.1 Application Startup Phase Exchanges

The Application Startup phase refers to the action of starting the execution of Element

Representation software to support a test event (Figure 3.2-3). Within this phase, each Element

Representation will establish communications with the OSF and verify time synchronization of their internal clock via GPS time code processor source. Time synchronization can also be accomplished thru a direct IRIG-B connection from a time code processor or by Network Time

Protocol, but the time source (i.e., the time code processor) should be within 100 microseconds1 of GPS time.

Information exchanged during this phase is used to verify interconnectivity between Elements and the OSF; to support test event accounting; and to and establish Element Representation

Health and Status reporting prior to moving into the Scenario Initialization phase.

Note 1 – The NTS-6000 and NTS-6000-Dual GPS and dual NTP time servers are typically accurate to 50 microseconds.

Figure 3.2-3 – Application Startup Sequence Diagram

3.2.2.1.1 Test Event Configuration IER

Upon the establishment of network communications to the Element participant, the OSF will transmit Test Event Configuration information (Table 3.2-9). The OSF will provide a

Site/App/Entity assignment that each participant will utilize throughout the test event. This information is also used for accounting purposes for each Element to identify recorded log file information to support post execution reporting. This IER includes a health, status, and error

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

(HS&E) reporting interval that each Element will provide to OSF at the specified update rate during mission execution. The Test Event Configuration will consist of the following fields:

Table 3.2-9 – Test Event Configuration IER

Field Description Data Type Unit

Element ID2 Site 16-bit Unsigned Integer Enum

App 16-bit Unsigned Integer Enum

Entity 16-bit Unsigned Integer Enum

Test Event ID1 Venue 80 Character String ASCII Char

Event 80 Character String ASCII Char

HS&E Reporting interval

Reporting interval of HS&E during mission execution 16-bit Unsigned Integer Seconds

Note 1 – Test Event ID is used to identify the venue and event name. Venue identification provides a mapping for data collected during this event to the BMDS Assessment space identified in the Venue Allocation CONOPS.

Examples of venues could be “GTI”, “SPMT”, “FastX”, etc. The test event component provides the Event name as a descriptive character string designation for an event.

Note 2 – This is for the receiving Element. Used in future communications exchanges with the OSF.

3.2.2.1.2 Element Configuration IER

After receipt of the Test Event Configuration IER, the Element will transmit their configuration information to OSF (Table 3.2-10). All Elements will provide their software and hardware version information. Radar sensor Elements will provide pertinent (as defined) information specific to their radar. OSF will utilize this information in later phases for environment and truth interaction calculations. Elements that are not radars will initialize these fields to “0”. The

Element Configuration information consists of the following information:

Table 3.2-10 – Element Configuration IER

Field Subcomponent/Description Data Type Unit

Element ID1 Site 16-bit Unsigned Integer Enum

App 16-bit Unsigned Integer Enum

Entity 16-bit Unsigned Integer Enum

SW Version2 SW Version of element participant Char String(16) Printable ANSI ASCII

HW Version3 HW version of element participant Char String(16) Printable ANSI ASCII

Element

Position

Position X in ECEF 64-bit Float meters

Position Y in ECEF 64-bit Float meters

Position Z in ECEF 64-bit Float meters

Weather

Station

Position6

Position X in ECEF 64-bit Float meters

Position Y in ECEF 64-bit Float meters

Position Z in ECEF 64-bit Float meters

Number of

Radar Faces Number of radar faces 16-bit integer >=0

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

For each radar face, radar face position, initial face boresight, and ECEF to RFC transformation matrix will be repeated…

Radar Face

Position

Position X in ECEF of center of radar face 64-bit Float meters

Position Y in ECEF of center of radar face 64-bit Float meters

Position Z in ECEF of center of radar face 64-bit Float meters

Initial Face

Boresight

Azimuth - East of North 32-bit Float . Radians

Elevation - above local horizon. 32-bit Float Radians

Clocking

Angle

Looking at the radar face, counter-clockwise rotation from the vertical component of RFC.

32-bit Float Radians

End of radar face definition

Receive

Polarization classification

Linear(Horizontal, Vertical), circular(Right, Left) 16-bit Unsigned Integer

0 – For Non Radars

1 – Linear

2 – Circular

3- Elliptical

Face Electronic

Viewing Limits

+/- Delta U 32-bit Float Radians

+/- Delta V 32-bit Float Radians

3db Beam width4

Beam Width U 32-bit Float N/A

Beam Width V 32-bit Float N/A

Frequency

Reference F0

The middle frequency for the operating frequency band of the radar Frequency Scaling

Reference

32-bit Float MHZ

Number of

Frequencies5 number of frequencies 32-bit Unsigned Integer N/A

Starting

Frequency

Starting frequency represented in first array position 32-bit Float MHZ

Frequency

Increment

The frequency increment between two adjacent frequencies

32-bit Float MHZ

Num Elevation

Angles7

Number of elevation angles in following array for Truth

Interaction tables

32-bit Integer >=0

Elevation

Angles7

Array of elevation angles to be used by Truth calculations 32-bit Float Array Radians

Num Ranges7

Number of ranges in following array for Truth Interaction tables

32-bit Integer >=0

Range7 Array of ranges to be to be used by Truth calculations 32-bit Float Array Meters

Num Azimuth7

Number of Azimuth angles in following array for Truth

Interaction tables

32-bit Integer >=0

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Azimuth7 Array of Azimuth to be to be used by Truth calculations 32-bit Float Array Radians

Note 1 – Element ID set in Test Event Configuration IER. Enumerations are identified in Appendix A.

Note 2 – Software version refers to the software build or release version number of the Element participant.

Note 3 – Hardware version refers to the hardware configuration version of the Element participant. If the Element participant does not have a specific hardware version available, this will be filled out with “N/A”.

Note 4 – Beam Width defined at the boresight.

Note 5 – The number of frequencies, starting frequency, and increment can be used to interpolate within the radar simulation a specific frequency needed.

Note 6 – Weather Station location refers to the location of measurements relative to the radar face.

Note 7 – These fields will be used by truth to calculate attenuation tables that will be provided back to the element.

See Section 3.2.2.3.

3.2.2.1.3 Health Status and Error IER

Health Status and Error IER is used by the participants to report their current status to the OSF during mission execution phase (Table 3.2-11). It is also used to indicate that the participant is ready to transition to the next phase of execution (See sequence in Error! Reference source not found.). Following receipt of the Test Event Configuration, the Element will provide a Health

Status and Error (HS&E) to OSF with the field Response Category set to “App Init” and

Component Status set to “Operational” indicating that the Element Representation is ready to transition to the next phase.

During the mission execution phase, starting when mission start time is reached, each Element will provide HS&E to the OSF at the rate specified within the Test Event Configuration IER with the Response Category set to “Mission HS&E”. The Component Status will be set to

“Operational” for the nominal case, or “Error/Issue” for the off-nominal case or if there is an error to report. The Element can provide an immediate HS&E message when an error occurs.

Health and Status information will consist of the following fields:

Table 3.2-11 – Health Status and Error IER

Field Description Data Type Unit

Element ID1 Site 16-bit Unsigned Integer Enum

App 16-bit Unsigned Integer Enum

Entity 16-bit Unsigned Integer Enum

Time of Validity GPS wall clock time 64-bit Float GPS Wall Clock Time

Response Category2 Enum 16-bit Unsigned Integer

1 – App Init, 2 – Scenario Init, 3 – Env/TI Init, 4 – Mission HS&E, 5 – Termination

Component Status Enum 16-bit Unsigned Integer

0 – Operational

1 – Sensor Error

2 – Command Control Error

3 – Launcher Error

4 – Interceptor Error

5 – Element Driver Error

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Field Description Data Type Unit

6 – Tactical Comm Error

7 – Non-Operational

8 – Operator Defined Error

Status Description3 free text 256 Char String (Null

Terminated) Text

Note 1 – Element ID set in Test Event Configuration IER. Site/App/Entity ID Enumerations are identified in

Appendix A.

Note 2 – Response category identifies the phase of execution in which the HS&E exchange occurs in.

Note 3 – Status description is a free text field the Element participant can utilize for capturing specific error condition information when the status is anything other than “0”.

3.2.2.2 Scenario Initialization Phase Exchanges

After the Element Representation establishes communications during the App Startup phase and provides an initial HS&E to the OSF, the OSF will provide the scenario information for the given event. The Scenario Initialization phase identifies the data exchanges that describe the scenario for the test event (Figure 3.2-4).

Figure 3.2-4 – Scenario Initialization Sequence Diagram

3.2.2.2.1 Scenario Initialization IER

OSF will transmit Scenario Initialization information (Table 3.2-12) to each Element

Representation after receipt of an initial Health Status and Error (HS&E) update with

“Operational” status.

This information will indicate the simulated mission time at the start of execution and the actual wall clock time of the start of execution. The phase transition to execution will be indicated by a

Start Mission IER after every participant is initialized and ready for mission execution. Time reference accuracy of the GPS set internal system clock of a participating Element will be within

3ms. This exchange will indicate the signature mapping information associated with this scenario

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

that each sensor Element should reference. The Scenario Initialization exchange will consist of the following information:

Table 3.2-12 – Scenario Initialization IER

Field Description Data Type Unit

Element ID Site 16-bit Unsigned Integer Enum

App 16-bit Unsigned Integer Enum

Entity 16-bit Unsigned Integer Enum

UTC Simulation

Time1

UTC Simulation Year 16-bit Unsigned Integer Year

UTC Simulation Day of Year 16-bit Unsigned Integer Day

UTC Simulation Time of Day 16-bit Unsigned Integer Seconds

Simulation Time Leap

Seconds 16-bit Unsigned Integer seconds

Real World Start

Time

Test Start Year

(GPS Reference) 16-bit Unsigned Integer Year

Test Start Day of Year

(GPS Reference) 16-bit Unsigned Integer Day

Test Start Time of Day

(GPS Reference) 16-bit Unsigned Integer seconds

Threat Launch

Offset Time

Time interval in milliseconds between time of first scenario threat launch and scenario mission start time

32-bit float ms

Test Scenario ID Scenario ID 16-bit Unsigned Integer N/A

Run ID (nth run of this scenario) 16-bit Unsigned Integer N/A

Receiving Entity

Location3 Position X in ECEF 64-bit Float meters

Position Y in ECEF 64-bit Float meters

Position Z in ECEF 64-bit Float meters

Receiving Entity

Boresight3

Azimuth 32-bit Float Boresight azimuth East of North. Rad

Elevation 32-bit Float Boresight elevation above local horizon. Rad

RF RCS Mapping

File2 Filename 1024 Character String N/A

EO/IR Replay File4 Filename 1024 Character String N/A

Emitter Mapping

File5 Filename 1024 Character String N/A

Note 1 – This is the simulated UTC time representation at Real World start time (See Start Mission IER) that allows test runs in the past, present and future time frames.

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Note 2 – RF Object Signature data file location is identified in the RF RCS Mapping file.

Note 3 – This provides a mechanism to assign a location and boresight to an Element that is different from their initial stated parameters. For those elements not able to be assigned a position, this will replicate the position provided in the element config IER. Elements without a boresight will be set to ‘0’.

Note 4 – EO/IR Replay File identifies pre-canned sensor inputs for OPIR sensor Elements. Ignored by non-EO/IR Sensors

Note 5 – Emitter file identifies a priori emitter information inputs sensor Elements. Ignored by non-users

3.2.2.2.2 Health Status and Error IER

When the Element Representation has verified its location, boresight and signature mapping files

(for sensor Elements), the Element Representation will issue an HS&E update with the response category set to “Scenario Init” and status set to “Operational”. If a data field within this exchange is not applicable to the receiving entity, it will set to zero. This action provides an indication to

OSF that the Element is ready to transition to the Environment and Truth Interactions phase. If the Element Representation determines that the initial configuration information is incorrect, then the Element will provide a HS&E update with status set to “Non-Operational” and provide the reason for the issue. An example of this would be that OSF provided a different location for a

THAAD emplacement than what the participating THAAD expected for its location. Matching locations should be within 1/1000th of a degree. The OSF will make the determination to proceed with the test or stop operations to correct the configuration. See Table 3.2-11 – Health Status and

Error IER.

3.2.2.3 Environment and Truth Interactions Initialization Phase Exchanges

Environment parameters are configured during the Scenario development process, and will be used as input to create the Truth Interaction (TI) calculations. Truth interactions are effects that a sensor Element will apply to create a perceived sensor return (e.g., attenuation, interference, or radiance). During this phase, the Environment parameters and corresponding Truth Interactions will be provided to the Element Representations (Table 3.2-5).

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Figure 3.2-5 – Environment Initialization Sequence Diagram

3.2.2.3.1 Environment Initialization IER

The Environment Initialization IER is used to define the initial parameters for Core Truth

Environment models, and to provide the natural conditions in which each Element representation is operating within (Table 3.2-13). The Environment Initialization IERs will be used by Core

Truth Models (CTM) for the generation of truth interaction effects that each Element will have access to during their operation. Each Element will only be required to use those parameters applicable to their operation.

Table 3.2-13 – Environment Initialization IER

Field Description Data Type Unit

Site Location1

Position X in ECEF 64-bit Float meters

Position Y in ECEF 64-bit Float meters

Position Z in ECEF 64-bit Float meters

Number of Altitudes a Used for array size of the following

Atmospheric Profile 32-bit Integer N/A

Atmospheric Profile[a]

Temperature 32-bit Float Centigrade

Pressure 32-bit Float millibars

Dew point 32-bit Float Centigrade

Speed of Sound 32-bit Float Meters/sec

Density 32-bit Float Kg/M3

Number of Wind

Measurements n

Used for array size of the following wind table 32-bit Integer N/A

<TBD>

CONTAINED ON THIS SHEET IS

SUBJECT TO THE RESTRICTION

ON THE TITLE PAGE OF THIS

DOCUMENT

FOR OFFICIAL USE ONLY

Field Description Data Type Unit

Wind Velocity[n]

Altitude - above sea level, velocity vector 32-bit Float

Altitude in meters

X_ENU – X coordinate value of the velocity in an East North Up (ENU) 32-bit Float Meters/Sec

Y_ENU – coordinate value of the velocity in an East North Up (ENU) 32-bit…