MS_SRD_PAA_Phase_3_D4_Ground_Test_Venue_Oct2014.pdf

FOR OFFICIAL USE ONLY

MISSILE DEFENSE AGENCY

SYSTEMS ENGINEERING DIRECTORATE (MDA/DE/E)

BALLISTIC MISSILE DEFENSE SYSTEM (BMDS)

Modeling and Simulation (M&S) System Requirements Document (SRD) PAA Phase 3 (Dec 2018) / D4 / Ground

Test Venue

22 October 2014 Prepared by:

MDA System Verification (MDA/EEV) Von Braun III

Redstone Arsenal, Huntsville, AL35801

WARNING – This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 et seq.)

or Executive Order 12470. Violators of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

The views, opinions, and findings contained in this report are those of the author(s) and should not be construed as an official Department of Defense position, policy, or decision, unless so designated by other official documentation.

Distribution authorized to U.S. Government agencies and their contractors due to this publication containing technical or operational information for official Government use only, effective 1 Oct 2010. Other requests for this document shall be referred to the Office of the Secretary of Defense, Missile Defense Agency, ATTN: Contracting Officer, 7100 Defense Pentagon, MDA/DAC, Washington, DC 20301-7100 or higher DoD authority.

DESTRUCTION NOTICE – For classified documents, follow the procedures in DoD 5220.22-M, Industrial Security Manual Section 11-19 or DoD 5200.1-R, Information Security Program Regulation, Chapter IX. For unclassified, limited documents, destroy by any method that will prevent disclosure of contents or reconstruction of the document.

This document contains information EXEMPT FROM MANDATORY DISCLOSURE under the Freedom of Information Act (5 U.S.C. Section 552).

Exemption 3 applies: "Authority to Withhold From Public Disclosure Certain Technical Data, 10 U.S.C. 130 and DoD Directive 5230.25 (references

(k) and (l))."

Modeling and Simulation (M&S) System Requirements Document (SRD) October 2014

This page intentionally left blank.

ii

FOR OFFICIAL USE ONLY

REVISION/CHANGE RECORD

Symbol Date Authorization Revision/Change Description Pages

Affected

EEV 22 Apr 2014 MDA/EEV Initial revision incorporates all recommended changes from E-tasker review All

EEV 6 May 2014 MDA/EEV Revision 2 changes for MSEWG vote on 8 May 2014 All

EEV 2 June 2014 MDA/EEV Comments from final MSEWG element inputs All

EEV 3 June 2014 MDA/EEV File updated and saved as draft for final review and SEIC brief All

EEV 6 June 2014 MDA/EEV Table C admin and readability changes C.1-2

EEV 13 June 2014 MDA/EEV Changed paragraph 1.1 IAW BMDS OTA recommendations 1

EEV 17 June 2014 MDA/EEV Added revision date NA

EEV 17 June 2014 MDA/EEV Added signature blocks iii

EEV 27 Oct 2014 MDA/EEV Corrected Comms section IAW 22 Oct 2014 ISG direction

Pgs 68 & 71 & Table D.4

TABLE OF CONTENTS

1. SCOPE

1.1 INTRODUCTION

1.2 System Definition

1.2.1 M&S Enterprise

1.2.2 BMDS Simulation Conceptual Model

1.2.3 M&S System

1.3 BMDS M&S System Description

1.3.1 BMD System Functions

1.3.1.1 Pre-Mission Planning

1.3.1.2 Sensor Acquisition

1.3.1.3 Sensor Tracking

1.3.1.4 Sensor Discrimination and Classification

1.3.1.5 Battle Manager Tracking and Discrimination

1.3.1.6 Battle Manager Engagement Planning

1.3.1.7 Interceptor Launch and Flyout

1.3.1.8 Interceptor Guidance, Navigation and Control

1.3.1.9 Interceptor Acquisition, Tracking and Discrimination

1.3.1.10 Lethal Intercept

1.3.2 Truth

1.3.3 Communications

1.3.4 Threat

1.3.5 Simulation Support Infrastructure

1.4 Approach for SRD Updates

1.5 M&S Overlay to the BMDS Technical Requirements

2. Applicable Documents

3. Requirements

3.1 PAA Phase 3 Architecture Description

3.1.1 Red Force

3.1.2 Blue Force

3.2 M&S System Level Requirements

3.2.1 M&S System Functions

3.2.1.1 Pre-Mission Planning

3.2.1.2 Sensor Acquisition

3.2.1.3 Sensor Tracking

3.2.1.4 Sensor Discrimination and Classification

3.2.1.5 Battle Manager Tracking and Discrimination

3.2.1.6 Battle Manager Engagement Planning

3.2.1.7 Interceptor Launch and Flyout

3.2.1.8 Interceptor Guidance, Navigation and Control

3.2.1.9 Interceptor Acquisition, Tracking and Discrimination

3.2.1.10 Lethal Intercept

3.2.2 Truth

3.2.2.1 Signatures

3.2.2.2 Environment

3.2.2.3 Truth Interactions

3.2.2.4 Lethality

3.2.3 Communications

3.2.3.1 Network Architecture

3.2.3.2 Nodes

3.2.3.3 Links

3.2.3.4 Information Exchange

3.2.3.5 Truth Interaction

3.2.3.6 Communications Services

3.2.4 Threat

3.2.4.1 Ballistic Missile

3.2.4.2 Aircraft

3.2.4.3 Cruise Missiles

3.2.5 Simulation Support Infrastructure

3.2.5.1 M&S Pre-Mission Planning

3.2.5.2 M&S Deployment and Installation

3.2.5.3 Mission Execution

3.2.5.4 M&S Post-mission

3.2.5.5 M&S Interoperability

3.2.5.6 M&S Management

3.3 Design and Considerations

3.4 Documentation

3.5 Logistics

3.6 Personnel and Training

3.6.1 Personnel

3.6.2 Training

3.7 Constituent Characteristics

3.7.1 Element / Component

3.7.1.1 Aegis BMD – to Include Aegis Ashore

3.7.1.2 C2BMC

3.7.1.3 External Allies – Excluded for GT venue

3.7.1.4 Ground-based Midcourse Defense (GMD)

3.7.1.5 Overhead Sensors

3.7.1.6 Overhead Sensor Ground Stations

3.7.1.7 PATRIOT

3.7.1.8 Standalone Radars

3.7.1.9 THAAD

3.7.2 Truth

3.7.2.1 Signatures

3.7.2.2 Environments

3.7.2.3 Truth Interactions

3.7.2.4 Lethality

3.7.3 Communication

3.7.3.1 Network Architecture

3.7.3.2 Nodes

3.7.3.3 Links

3.7.3.4 Information Exchange

3.7.3.5 Communications Truth Interaction – Excluded for GT venue

3.7.3.6 Communications Services

3.7.4 Threat

3.7.4.1 Ballistic Missile

3.7.5 Simulation Support Infrastructure

3.7.5.1 M&S Pre-Mission Planning

3.7.5.2 M&S Deployment and Installation

3.7.5.3 M&S Mission Execution

3.7.5.4 M&S Post-mission

3.7.5.5 M&S Interoperability

3.7.5.6 M&S Management

3.8 Precedence

4. M&S SYSTEM-LEVEL VERIFICATION

4.1. Verification Methods

4.1.1. Inspection

4.1.2. Demonstration

4.1.3. Test

4.1.4. Analysis

4.2. Integrated BMDS M&S Requirements

4.3. System Verification Process

LIST OF FIGURES

Figure 1 – BMD System – PAA Phase 3 Figure 2 – M&S Enterprise Figure 3 – BMD System Functions Figure 4 – CTM Taxonomy Tailored for PAA Phase 3 Ground Test (GT07) Figure 5 – Communications Representation Requirements Development Approach Figure 6 – Threat Requirements Development Approach Figure 7 – M&S Infrastructure Conceptualization Figure 8 – M&S System Engineering Development Process Figure 9 – Aegis Provide Sensor Track Report Demonstration Test Case Figure 10 – M&S Rain Attenuation Verification Test Scenario Figure 11 – Example Rain Attenuation Verification by Test Figure 12 – Example RCS Verification by Analysis Results Figure 13 – Integrated BMD System M&S Requirements Flow Example Figure 14 – BMD System M&S Requirements Verification Process viii

FOR OFFICIAL USE ONLY

APPENDICIES

Appendix A: Functional Data ................................................................................................. A.1-1 Table A.1: Pre-Mission Planning Data ................................................................................ A.1-1 Table A.2: Sensor Acquisition Data .................................................................................... A.2-1 Table A.3: Sensor Tracking Data......................................................................................... A.3-1 Table A.4: Sensor Discrimination Data ............................................................................... A.4-1 Table A.5: Battle Manager Track and Discrimination Data ................................................ A.5-1 Table A.6: Battle Manager Engagement Planning Data ...................................................... A.6-1 Table A.7: Interceptor Launch and Flyout Data .................................................................. A.7-1 Table A.8: Interceptor Guidance, Navigation and Control Data ......................................... A.8-1 Table A.9: Interceptor Acquisition, Track and Discrimination Data................................... A.9-1 Table A.10: Lethal Intercept Data ..................................................................................... A.10-1 Table A.11: Suitability Data .............................................................................................. A.11-1 Table A.12: Interoperability Data ...................................................................................... A.12-1

Appendix B: Environments Data .............................................................................................B.1-1 Table B.1: Environments Data..............................................................................................B.1-1

Appendix C: Tactical Messages...............................................................................................C.1-1 Table C.1: Tactical Messages ...............................................................................................C.1-1

Appendix D: Requirements, Verification and Trace .............................................................. D.1-1 Table D.1: Section 3.2 System Requirements Allocation Matrix........................................ D.1-1 Table D.2: Section 3.7 Constituent Function Allocation Matrix ......................................... D.2-1 Table D.3: Section 3.7.2 Truth Allocation Matrix............................................................... D.3-1 Table D.4: Section 3.7.3 Communications Allocation Matrix ............................................ D.4-1 Table D.5: Section 3.7.4 Threat Allocation Matrix ............................................................. D.5-1 Table D.6: Section 3.7.5 Simulation Support Allocation Matrix ........................................ D.6-1

Appendix E: Acronyms............................................................................................................E.1-1 Appendix F Classified SRD Appendix (Classified) ................................................................. F.1-1

Table F.1: M&S Representation Required for Ground Test (Classified) ............................. F.1-1 Table F.2: Threat Systems / Object Counts (Classified)....................................................... F.2-1 Table F.3: Classified SRD References (Classified) .............................................................. F.3-1

FOR OFFICIAL USE ONLY

1. SCOPE

1.1 INTRODUCTION

The Modeling and Simulation (M&S) System Requirements Document (SRD), hereafter referred to as M&S SRD, provides a top-level set of system-level M&S requirements for the Missile Defense Agency (MDA) Ground Test (GT) venue. The M&S SRD focuses on models and simulations required to support Ballistic Missile Defense System (BMDS) assessment for the Phased Adaptive Approach (PAA) Phase 3 capabilities, as it is the earliest opportunity to affect a flow down of system-level requirements covering development, integration, testing and assessment. Requirements within the M&S SRD will not change tactical element / component specifications or requirements. The objective of this M&S SRD is to translate high-level stakeholder needs, measures, and existing M&S limitations into an initial set of M&S System-level requirements for this intended use, in alignment with the BMDS Simulation Conceptual Model (SCM).

The M&S SRD follows the traditional Military Standard (MIL-STD) 490A in structure and content. MIL-STD 490A was chosen in lieu of the updated MIL-STD 961-E because the 961-E is a flat structure that does not readily support allocation from system to subsystem.

The stakeholder assessment needs allocated to this intended use drive required BMDS architecture and system-level requirements captured in this document. The detailed design to implement these requirements must continue to incorporate stakeholder needs to ensure the development of M&S that can achieve accreditation. The BMDS OTA Accreditation Plan describes the criteria necessary to achieve BMDS OTA Accreditation. The primary objectives of BMDS assessment in the GT venue are to assess interoperability and its mission impact and regression test effectiveness of the defined functional capabilities and limitations. This assessment includes tactical hardware / communications and warfighter interactions. M&S introduced for use in the GT venue will replicate the tactical functionality and be verified and validated (V&V’d) for use in BMDS assessment. Emulated or replicated tactical interoperability is the primary source for assessing system interoperability. The GT venue will also support identification of differences between the as-built and as-specified systems.

The M&S SRD defines the objective set of M&S requirements required for PAA Phase 3 assessment as well as the regression capabilities required within the M&S system. The stakeholder assessment needs and derived requirements contained in the M&S GT SRD were developed without considering the limitations of constrained resources. M&S Enterprise Management activities will prioritize development and implementation of these requirements based on funding and schedule constraints.

The data items defined within this document are based on the current baseline of the Master Measures List. The data required for assessment from the GT venue will continue to evolve to include all stakeholder measures and updated data items will be vetted within the M&S community.

1.2 System Definition

The BMDS is a joint, integrated, multi-layered, and globally deployed system-of-systems delivered to defend the United States, deployed forces, allies and friends against ballistic missiles of all ranges by engaging them in all phases of flight: boost, ascent, midcourse and terminal (Figure 1 – BMD System – PAA Phase 3, below). Modeling the BMDS at the enterprise level requires an infrastructure in place to act as the backbone (i.e., simulation support infrastructure) for the individual component models to include the elements, threats, environment models and communications. The architecture for this SRD is specifically tailored to document the requirements needed to assess the PAA Phase 3 (Dec 2018) / D4 / GT venue. The M&S SRD will speak to interface requirements of the simulation support infrastructure to support the inclusion of the external allies in the GT venue, but does not allocate requirements to those elements.

1.2.1 M&S Enterprise

Figure 1 – BMD System – PAA Phase 3

The M&S enterprise is managed as a single, synchronized program supporting multiple intended uses and venues to include digital, hardware-in-the-loop (HWIL), training / exercise capabilities, concept analysis, and system-level representations required for element M&S development.

The M&S enterprise is comprised of all resources, assets and processes necessary to simulate the BMDS to include element / component models and drivers, as well as the necessary infrastructure, hardware and facilities. Additionally, the M&S enterprise enables BMD system planning, enables assessment criteria translation into test plans and scenario development and supports the analysis of data collected from a defined venue. The M&S SRD primarily addresses the BMDS behavior (element M&S products) and the supporting simulation components (M&S simulation support infrastructure, truth, and communications) necessary to simulate the BMDS.

SBIRS

Ground Stations:

MCS

The M&S SRD does not explicitly address all enterprise products and / or processes depicted in Figure 2 that are outside the M&S System proper. The “Plan Event” step (which notionally includes activities such as the PLANEX or products like the Test Case Description Document) shown in Figure 2 – M&S Enterprise, below, is part of the M&S enterprise but not addressed in the M&S SRD. Similarly, the “Analyze Data” step is also outside the scope of the M&S SRD and Enterprise products / processes / organizations like the Missile Defense Data Center and Joint Analysis Team do not have allocated requirements.

Figure 2 – M&S Enterprise

1.2.2 BMDS Simulation Conceptual Model

The MDA/EEV organization is executing an enterprise-level M&S SE process to develop and manage the M&S System requirements that govern the translation of the physical BMDS into a virtual M&S representation per intended use. The goal of this process is to establish defendable and traceable systems-level M&S requirements that serve as the basis for incremental M&S upgrades for the elements, M&S simulation support infrastructure, threat, and core truth. SCM serves as the cornerstone of the EEV SE process. The SCM process is a collaborative effort between MDA/EEV, MDA/DES, the element Project Offices (PO), the assessment community, end-user clients, simulation developers, and subject matter experts. The SCM process provides an approach for specifying the essential BMDS system behavior and supporting simulation infrastructure necessary to meet the needs for an M&S intended use as applied to the GT venue.

This process yields a conceptual description of the virtual BMDS and the resulting artifacts form the basis of the M&S SRD development.

1.2.3 M&S System

The M&S System, as depicted in the BMDS conceptual model, represents the behavior of the physical BMDS via modeling and simulation. The M&S System supporting GT07 is an integrated architecture comprised of HWIL, tactical software, models, simulations, simulation support infrastructure, threat, core truth models and communications.

1.3 BMDS M&S System Description

1.3.1 BMD System Functions

The BMD System Functions are a construct for analyzing the operation of the BMD system versus ballistic threats from Pre-Mission through Lethal Intercept. The BMDS Capability Assessment (BCA) team developed these functions to support assessment of the BMDS. To ensure a common starting point for both BMDS assessment and M&S requirements development, the SCM team, the Integrated Master Assessment Plan (IMAP) team, and the Operational Test Agency (OTA) adopted these System Functions. Figure 3 – BMD System Functions, below, illustrates the BMD System Functions from Pre-Mission Planning through Lethal Intercept.

Figure 3 – BMD System Functions

FOR OFFICIAL USE ONLY

The SRD intent is to provide the scope of the truth stimulus, communications, threats, environments, and supporting infrastructure necessary for the element representations to execute their respective mission behavior in accordance with the tactical systems. Accordingly, the SRD facilitates the assessment of the GT07 M&S System by specifying data elements required for the generation of the defined measures.

1.3.1.1 Pre-Mission Planning

Pre-Mission Planning refers to the ability of the BMDS Warfighter to configure Blue Force assets and develop employment strategies prior to a battle. The resultant Blue Force Laydown is the basis for test case development and scenario execution. The Pre-Mission Planning effort is a part of the test campaign Planning Exercise (PLANEX) where warfighters (typically) run their planners based on the "Road to War" given as part of the PLANEX activities.

1.3.1.2 Sensor Acquisition

Acquisition refers to the process by which the BMDS detects objects and distinguishes true objects from false ones. Acquisition can be accomplished using active sensors (e.g. radar) or passive sensors (e.g. infrared imaging). BMDS radars include AN/SPY-1, AN/TPY-2 (TM and FBM), AN/MPQ 53/65, Upgraded Early Warning Radar (UEWR), COBRA DANE (CD) radar, and Sea-Based X-Band (SBX) radar. Overhead Persistent Infrared (OPIR) systems include overhead assets (Space-Based Infrared System (SBIRS), other classified OPIR systems) and Ground Processing Assets (Mission Control System (MCS), Joint Tactical Ground Station (JTAGS) and BMDS OPIR Architecture (BOA)).

1.3.1.3 Sensor Tracking

Tracking refers to the process by which the BMDS maintains tracks and develops, aggregates, and reports trajectory information.

1.3.1.4 Sensor Discrimination and Classification

Discrimination and Classification refers to the process by which the BMDS determines which object(s) among a group of objects (debris, countermeasures, etc.) is lethal. The sensor typically characterizes the objects (lethal and non-lethal) in the threat complex using algorithms.

1.3.1.5 Battle Manager Tracking and Discrimination

Battle Manager Tracking and Discrimination refers to the tracking and discrimination synthesis process by which BMDS battle managers collect, process, and manage sensor tracking and discrimination data and develop and display composite trajectory and track identification information.

1.3.1.6 Battle Manager Engagement Planning

Engagement Planning refers to the process by which BMDS battle managers plan and otherwise manage engagements using BMDS interceptors.

1.3.1.7 Interceptor Launch and Flyout

Interceptor Launch and Flyout refers to the process by which the BMDS launches the interceptor and deploys the Kill Vehicle (KV) / Kinetic Weapon (KW) to a specific insertion point.

1.3.1.8 Interceptor Guidance, Navigation and Control

Interceptor Guidance, Navigation and Control refers to the process by which the KV / KW maintains a stable attitude and diverts from the original insertion point to a point on a trajectory that will lead to a successful intercept.

1.3.1.9 Interceptor Acquisition, Tracking and Discrimination

Interceptor Acquisition, Tracking and Discrimination refer to the ability of BMDS interceptors to search for, track and identify target objects.

1.3.1.10 Lethal Intercept

Lethal Intercept refers to the process by which the BMDS selects an aim point, represents a lethal or non-lethal intercept and performs hit / kill assessment.

1.3.2 Truth

The MDA Modeling and Simulation Corrective Action Plan (CAP) defined the need for the development of requirements for common and consistent representation of the truth. In coordination with the element POs, the DE/S Core Truth Model group developed the Core Truth Models (CTM) Taxonomy as part of the Simulation Conceptual Model, to include a database of corresponding definitions and descriptions. Leveraging the physics-based CTM Taxonomy, EEV defined a requirements-focused version to frame the development of truth requirements in this M&S SRD. This version of the CTM Taxonomy, shown below in Figure 4 – CTM Taxonomy Tailored for PAA Phase 3 Ground Test (GT07), was coordinated through the MSEWG. The tailored taxonomy identifies the components of truth stimuli required across the BMDS architecture to represent Signatures, Environments, Truth Interactions and Lethality.

(Note: SRD Page a more readable copy of the Figure 4 can be found at UMKO > DE > EEV System Verification > EEV M&S System Engineering > M&S System Engineering Documents > SRD E-Tasker Documents > M&S SRD Figure 4.)

Figure 4 – CTM Taxonomy Tailored for PAA Phase 3 Ground Test (GT07)

The SCM team consulted with all elements to determine the truth touch points. This document captures the results of these discussions. If the truth component has an effect on element performance, it is allocated to that element. The BMDS weapon systems will utilize the CTM signature models to ensure common and consistent signatures. Note: for the Ground Test venue, those CTM components that are not required to support assessment objectives for PAA Phase 3 are “greyed out.”

1.3.3 Communications

System-level requirements for the communications representation are organized around two concepts: the nodes and links in a network architecture and the information exchange among nodes (see Figure 5 – Communications Representation Requirements Development Approach below). A node is a connection point in the network, and a link is the physical connection between nodes. A node can serve as an originator, a destination or a redistributor of message traffic. A link can consist of a line (e.g., copper wire, fiber-optic cable) or it can be wireless (e.g., satellite, line-of-sight). Whether the fundamental implementation of the communications representation is ultimately an actual (e.g., live, surrogate) network or a simulated (e.g., emulated) network, the purposes are the same: to address the fundamental representation of message transport and the interoperability among nodes. The communications representation requirements support the generation of data items to be collected for post-test analysis to answer the following questions:

Accountability: Did the message arrive?

Transversal: What route did the message take to its destination?

Orderliness: In a stream of messages, was the message received in the proper order?

Conformance: To what degree does the prepared message conform to the as-built system?

Correctness: To what degree does the reconstituted message clearly represent what was prepared?

Figure 5 – Communications Representation Requirements Development Approach

To support the intended uses associated with the GT venue, the anticipation is the implementation solutions to these requirements will contain a significant amount of actual tactical communication devices and real-world networks, to include limited use of live satellites and line-of-sight transport. However, it is not the intention of this document to restrict implementation to that solution set for these requirements.

1.3.4 Threat

To capture all components that make up a threat complex in a scenario from launch to intercept or demise, the community developed M&S System level threat requirements. These requirements intend to delineate “inputs” needed by CTM (lethality, signatures & environments) to produce a threat scene for all of the BMDS constituents. The threat requirements will be consumed by the truth (CTM) requirements where the effects will be produced by truth (see Figure 6 – Threat Requirements Development Approach below). Truth M&S will produce the representation of the threat characteristics, which, in turn, will be consumed by the BMDS constituents.

FOR OFFICIAL USE ONLY

Figure 6 – Threat Requirements Development Approach

1.3.5 Simulation Support Infrastructure

The outline derived from the infrastructure concept defined within the SCM formed the basis of the simulation support infrastructure requirements. The infrastructure concept provides a structure to organize the infrastructure needs provided by M&S stakeholders into logical perspectives of the M&S System based on actor-oriented perspectives. Figure 7 – M&S Infrastructure Conceptualization, below, defines the relationships between the infrastructure needs that facilitate use, operations, mechanization, and management of the M&S System, as well as the attributes and performance constraints that should characterize the M&S System.

The infrastructure needs, considering the infrastructure concept, formed the basis for the SRD infrastructure outline and is organized to allow clear definition of what capabilities the simulation infrastructure must provide in order for the M&S System to support the BMDS assessment intended use in the GT venue.

Figure 7 – M&S Infrastructure Conceptualization

1.4 Approach for SRD Updates

MDA’s Director for System Verification (MDA/EEV) updates the M&S SRD as additional information is delivered from the IMAP process, OTA issue resolution, BMDS conceptual model updates, and other stakeholder assessment need changes. MDA/EEV utilizes the M&S System Engineering Working Group (MSEWG) as the forum to coordinate, control and manage the BMDS M&S system-level products for MDA, to include the M&S SRD. All changes to the

SRD, to include the initial baseline, will be approved as defined in the MSEWG Procedures Guide.

1.5 M&S Overlay to the BMDS Technical Requirements

A disciplined System Engineering (SE) development approach governs M&S needs, SCM, system-level requirements, high-level architecture, system design, and element / component M&S specifications. This process parallels the BMDS weapon system development and provides traceable M&S requirements to guide M&S development. Figure 8 – M&S System Engineering Development Process, below, outlines the SE process that governs M&S development.

The BMDS Master Integration Plan (MIP) documents the new BMDS functions and capabilities and MDA/DE/E develops plans for assessing all emerging capabilities. The Integrated Master Assessment Plan (IMAP) provides the details for the functional and performance assessment processes of the BMDS. The IMAP identifies the assessment objectives (AOs), measures, Critical Assessment Conditions (CAC), key test parameters, test venues and other products necessary to assess the BMDS incremental delivery.

Figure 8 – M&S System Engineering Development Process

The M&S SRD establishes the M&S baseline, developed within the SE process, and will align the M&S development with the BMDS technical baseline to support an assessment of the BMDS. The M&S SRD provides a set of system-level requirements that guides high-level architecture and system-level design decisions. As high-level architecture and system design trades are made, specification level requirements are developed, and requirements are allocated to elements / components resulting in a consistent implementation across the M&S enterprise.

Traceability between BMD System Specification, through the IMAP, as well as a trace to the SCM, OTA needs and BCA needs is established and maintained in the M&S SRD.

2. APPLICABLE DOCUMENTS

This section includes those documents referenced in Sections 3, 4 and Appendices of this document. References are by document number and title, and may include specific issue or revision where necessary to control the configuration or implementation of the configuration item, material or process. For references not defined by a revision number, the SRD used the latest version. Some references include a portal site address where that reference can be located.

1. BMDS Capabilities Assessment (BCA) Team Needs for Modeling and Simulation (M&S), 24 May 2013

2. BMDS Master Integration Plan (MIP) V12.2, 20 Sep 2013

3. BMDS OTA System-level M&S Needs for PAA Phases II and III: Theater / Regional Mission 31 Oct 2013

4. BMDS Technical Core Standards, MDA Directive 4122.01, 21 Jun 2011

5. Department of Defense Instruction 5000.61 (DoD M&S VV&A), 9 Dec 2009

6. GTI-06 Part 1 Threat Baseline Version 1.00, 12 Nov 2012

7. GTI-06 Part 2 Threat Baseline Version D.05, 25 Oct 2013

8. Master Measure List, master_measures_list_10_functions_21Jan2014.xls – Classified Contents:

CMKO > DE – Director for Engineering > (DE/E) MDA System Engineer > (EEV) System Verification > (EEV) System Engineering > (EEV) System Engineering (SE) Documents > SRD E- Tasker Documents

9. MDA Integrated Master Assessment Plan (IMAP) 14.1, Release Date TBD

10. Military Standard Specification Practices, MIL-STD 490A, 4 Jun 1985

11. Modeling And Simulation (M&S), Verification, Validation, And Accreditation (VV&A), MDA Directive 8315.01 MDA 8315.01-INS 2007

12. SCM BMDS Functions Table, 20130628 – SCM Functions Table V2.2.3.xls – Classified Contents: CMKO > DE – Director for Engineering > (DE/E) MDA System Engineer > (EEV) System Verification > (EEV) System Engineering > (EEV) System Engineering (SE) Documents > SRD E-Tasker Documents

13. Simulation Conceptual Model for BMDS Assessment – Increment 1 – Classified Contents:

CMKO > DE – Director for Engineering > (DE/S) Modeling & Simulation > (DE/S) M&S Conceptual Model Tiger Team > Shared Documents > SCM Increment 1

14. Simulation Conceptual Model for BMDS Assessment – Increment 1 – Unclassified Contents:

UMKO > DE – Director for Engineering > (DE/S) Modeling & Simulation > (DE/S) M&S Conceptual Model Tiger Team > Shared Documents > SCM Increment 1

15. Simulation Conceptual Model for BMDS Assessment – Increment 2 – Classified Contents:

CMKO > DE – Director for Engineering > (DE/S) Modeling & Simulation > (DE/S) M&S Conceptual Model Tiger Team > Shared Documents > SCM Increment 2

16. Simulation Conceptual Model for BMDS Assessment – Increment 2 – Unclassified Contents:

UMKO > DE – Director for Engineering > (DE/S) Modeling & Simulation > (DE/S) M&S Conceptual Model Tiger Team > Shared Documents > SCM Increment 2

FOR OFFICIAL USE ONLY

3. REQUIREMENTS

3.1 PAA Phase 3 Architecture Description

3.1.1 Red Force

The Threat Systems Working Group – GT Subgroup, chaired by MDA Threat Systems Engineering (MDA/EIT), established threat baselines for the GTI-06 events based on MDA and BMDS OTA requirements. The latest set of threat baselines, produced by this group, includes the (a) GTI-06 Part 1 Threat Baseline Version 1.00 dtd November 12, 2012 and (b) GTI-06 Part 2 Threat Baseline Version D.05 dtd October 25, 2013. Although these documents do not specifically address the GT-07 campaign, they are the latest and most authoritative Red Force descriptions available as of the M&S SRD release. These two documents were used in the production of a classified table (Table F.2 – Threat Systems / Object Counts, found in classified Appendix F) that defines the planned Red Force lay down for this version of the SRD. When the GT07 threat baselines are produced, they will be analyzed for differences and impacts to determine if an update to the SRD is required.

3.1.2 Blue Force

The Blue Force laydown for PAA Phase 3 architecture is baselined in MDA’s Integrated Master Test Plan (IMTP). Classified Table F.1: M&S Representation Required for Ground Test (found in classified Appendix F) defines the Blue Force Laydown for the PAA Phase 3 architecture, for executing BMDS Assessment in the GT venue and defines the maximum required number of representations to adequately test the BMDS for this intended use by Mission. For the element representations utilized in the GT venue, the Blue Force should support the assessment needs aimed at this venue to include tactical hardware, where possible, tactical communications and real-time warfighter interactions. This SRD uses this architecture definition to develop and allocate requirements.

Table F.1 only addresses the number of representations required to conduct PAA Phase 3 GTs.

M&S planning should consider the total number of assets / representations required to conduct all the PAA Phase 3 testing across all venues, as defined in the IMTP.

3.2 M&S System Level Requirements

The M&S System requirements include requirements related to constituent models (BMDS elements and components), threat representations, simulation infrastructure, common truth models, and communications representations. The SCM forms the basis for the structure and decomposition of these requirements.

These M&S system-level requirements are shown at the “3.2” system-level (ref. Section 3.2) and then allocated to the “3.7” constituent-level (ref. Section 3.7). For the BMDS functions, the allocations are specific to the constituent. However, for the general truth, communications, threat and simulation support infrastructure requirements, each requirement has been allocated to the applicable constituents. Furthermore, to ensure a consistent implementation at the system-level, the allocation of the truth and threat requirements has defined which constituent will produce the data and which constituent will consume the data. The allocation is defined in the Requirements Allocation, Test, Analysis, Demonstration and Inspection (TADI) and trace matrix

FOR OFFICIAL USE ONLY

provided in Appendix D. The constituent requirements in Section 3.7 will form the basis for the GT Enterprise Engineering Teams to derive detailed specifications for design and implementation. Requirement headings that are marked “Excluded for GT venue” are unused for the M&S intended uses supported by this document and represent a placeholder for potential future additions to the SRD. For some categories of requirements marked as “Excluded for GT venue” data items and messages are nonetheless defined elsewhere in this SRD for the allocated constituent to support system-level verification. To preserve a consistent numeric structure within the SRD and between subsequent SRDs for other intended uses, requirement headings marked “N/A” indicate a category as not applicable. Section 4, System Verification, describes the verification process for all ‘shall’ statements. Desired capabilities or capabilities that are critical to the representative behaviors are written as design goals using ‘should’ statements – this was done specifically to allow for the necessary design trade space when creating the M&S Constituents of this system and to ensure this SRD does not introduce undue restrictions as to drive a specific solution or set of solutions. Note: as ‘should’ statements, there is no stipulation that these items be verified.

3.2.1 M&S System Functions

3.2.1.1 Pre-Mission Planning

3.2.1.1.1 The M&S System shall have the capability to represent BMDS Pre-Mission Planning.

3.2.1.2 Sensor Acquisition

3.2.1.2.1 The M&S System shall have the capability to represent BMDS Sensor Acquisition.

3.2.1.3 Sensor Tracking

3.2.1.3.1 The M&S System shall have the capability to represent BMDS Sensor Tracking.

3.2.1.4 Sensor Discrimination and Classification

3.2.1.4.1 The M&S System shall have the capability to represent BMDS Sensor Discrimination and Classification.

3.2.1.5 Battle Manager Tracking and Discrimination

3.2.1.5.1 The M&S System shall have the capability to represent BMDS Battle Manager Tracking and Discrimination.

3.2.1.6 Battle Manager Engagement Planning

3.2.1.6.1 The M&S System shall have the capability to represent BMDS Battle Manager Engagement Planning.

FOR OFFICIAL USE ONLY

3.2.1.7 Interceptor Launch and Flyout

3.2.1.7.1 The M&S System shall have the capability to represent BMDS Interceptor Launch and Flyout.

3.2.1.8 Interceptor Guidance, Navigation and Control

3.2.1.8.1 The M&S System shall have the capability to represent BMDS Interceptor Guidance, Navigation and Control.

3.2.1.9 Interceptor Acquisition, Tracking and Discrimination

3.2.1.9.1 The M&S System shall have the capability to represent BMDS Interceptor Acquisition, Tracking and Discrimination.

3.2.1.10 Lethal Intercept

3.2.1.10.1 The M&S System shall have the capability to represent BMDS Lethal Intercept.

3.2.2 Truth

3.2.2.1 Signatures

3.2.2.1.1 The M&S System shall represent plume electro-optical (EO) / infrared (IR) signatures.

3.2.2.1.2 The M&S System shall represent hardbody EO / IR signatures.

3.2.2.1.3 The M&S System shall represent nearbody EO / IR signatures.

3.2.2.1.4 The M&S System shall represent plume radio frequency (RF) / radar cross section (RCS) signatures.

3.2.2.1.5 The M&S System shall represent hardbody RF / RCS signatures.

3.2.2.1.6 The M&S System shall represent nearbody RF / RCS signatures.

3.2.2.2 Environment

3.2.2.2.1 The M&S System shall represent earth reference data.

3.2.2.2.2 The M&S System shall represent the IR and RF atmospheric environment.

3.2.2.2.3 The M&S System shall represent the EO / IR and RF solar environment.

3.2.2.2.4 The M&S System shall represent the EO / IR and RF space environment.

3.2.2.3 Truth Interactions

3.2.2.3.1 The M&S System shall provide EO / IR signature propagation from source to sensor.

3.2.2.3.2 The M&S System shall provide RF propagation from source to sensor.

3.2.2.3.3 The M&S System shall provide aerodynamic propagation.

3.2.2.4 Lethality

3.2.2.4.1 The M&S System shall represent end-game geometry.

3.2.2.4.2 The M&S System shall represent the end-game lethality.

3.2.2.4.3 The M&S System shall represent the post-intercept debris (PID).

3.2.2.4.4 The M&S System shall represent the consequences of engagement (in-flight and ground).

3.2.3 Communications

3.2.3.1 Network Architecture

3.2.3.1.1 The M&S System shall be capable of representing the Blue Force network architecture.

3.2.3.2 Nodes

3.2.3.2.1 The M&S System shall be capable of representing the nodes used by the BMDS.

3.2.3.3 Links

3.2.3.3.1 The M&S System shall be capable of representing the links used by the BMDS.

3.2.3.4 Information Exchange

3.2.3.4.1 The M&S System shall exchange tactical messages in accordance with (IAW) message standards used by the BMDS.

3.2.3.5 Truth Interaction

3.2.3.5.1 The M&S System shall represent the effects of truth interactions on message transport.

3.2.3.6 Communications Services

3.2.3.6.1 The M&S System shall be capable of providing general communications services.

3.2.4 Threat

3.2.4.1 Ballistic Missile

3.2.4.1.1 The BMDS Threat Community shall provide the physical characteristics of the ballistic missile system as it is defined in the Threat System Specification

3.2.4.1.2 The BMDS Threat Community shall provide the kinematic characteristics of each modeled ballistic missile object as it is defined in the Threat System Specification

3.2.4.1.3 The BMDS Threat Community shall provide radar signature characterization for each modeled ballistic missile object based on the physical and kinematic characteristics.

3.2.4.1.4 The BMDS Threat Community shall provide EO / IR signature characterization for each modeled ballistic missile object based on the physical and kinematic characteristics.

3.2.4.2 Aircraft

3.2.4.2.1 Excluded for GT venue

3.2.4.3 Cruise Missiles

3.2.4.3.1 Excluded for GT venue

3.2.5 Simulation Support Infrastructure

3.2.5.1 M&S Pre-Mission Planning

3.2.5.1.1 The M&S System shall provide the capability to perform M&S Pre-Mission Planning.

3.2.5.2 M&S Deployment and Installation

3.2.5.2.1 The M&S System shall provide tools to aid M&S deployment and installation.

3.2.5.3 Mission Execution

3.2.5.3.1 The M&S System shall provide the capability to perform M&S mission execution.

3.2.5.4 M&S Post-mission

3.2.5.4.1 The M&S System shall provide the capability to perform M&S post-mission activities.

3.2.5.5 M&S Interoperability

3.2.5.5.1 The M&S System shall provide the capability to support M&S interoperability among the BMDS system interfaces and with defined external interfaces.

3.2.5.6 M&S Management

3.2.5.6.1 The M&S System shall provide the capability to perform M&S management.

3.3 Design and Considerations

Design solutions and specific M&S considerations are not included in this document. The decomposition of these requirements as part of the subsequent system-level architecture and system-level design steps of the GT Engineering Process will delineate specific design solutions.

3.4 Documentation

The M&S SRD feeds the GT Engineering Process (see Section 1.5) that creates a series of documents that capture the M&S architecture for GT as well as constituent-level design and requirements documents.

3.5 Logistics

Not applicable.

3.6 Personnel and Training

3.6.1 Personnel

The requirements for specific personnel will be determined during the M&S System design phase. The numbers and skill levels of personnel will be specified for each ground test instantiation and the intended duty cycles, both normal and emergency; and types and total number of personnel which may be allocated to the operation, maintenance, and control of the ground test.

3.6.2 Training

During the M&S System design phase, operational concepts and requirements will be generated for how users will be trained to use the GT venue (e.g., school, unit, or contractor training).

Training time and locations necessary for effective training programs for GT operations, maintenance, and control of the GT venue will also be specified.

FOR OFFICIAL USE ONLY

3.7 Constituent Characteristics

3.7.1 Element / Component

3.7.1.1 Aegis BMD – to Include Aegis Ashore

3.7.1.1.1 Pre-Mission Planning

3.7.1.1.1.1 The Aegis representation shall support the generation of applicable data items designated in Table A.1: Pre-Mission Planning Data.

3.7.1.1.1.2 The Aegis representation shall have the capability to utilize operational mission profiles and settings.

3.7.1.1.1.3 The communications touch points for the Aegis representation are N/A for Pre- Mission Planning.

3.7.1.1.1.4 The CTM touch points for the Aegis representation are N/A for Pre-Mission Planning.

3.7.1.1.2 Sensor Acquisition

3.7.1.1.2.1 The Aegis representation shall support the generation of applicable data items designated in Table A.2: Sensor Acquisition Data.

3.7.1.1.2.2 The Aegis representation shall provide sensor acquisition messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.2.3 The Aegis representation shall consume truth, as designated in Table D.3: Truth Allocation Matrix, during Sensor Acquisition.

3.7.1.1.3 Sensor Tracking

3.7.1.1.3.1 The Aegis representation shall support the generation of applicable data items designated in Table A.3: Sensor Tracking Data.

3.7.1.1.3.2 The Aegis representation shall provide sensor tracking messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.3.3 The Aegis representation shall consume truth as designated in Table D.3: Truth Allocation Matrix, during Sensor Tracking.

3.7.1.1.4 Sensor Discrimination and Classification

3.7.1.1.4.1 The Aegis representation shall support the generation of applicable data items designated in Table A.4: Sensor Discrimination and Classification Data.

3.7.1.1.4.2 The Aegis representation shall provide sensor discrimination and classification messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.4.3 The Aegis representation shall consume truth as designated in Table D.3: Truth Allocation Matrix, during Sensor Discrimination and Classification.

3.7.1.1.5 Battle Manager Tracking and Discrimination

3.7.1.1.5.1 The Aegis representation shall support the generation of applicable data items designated in Table A.5: Battle Manager Track and Discrimination Data.

3.7.1.1.5.2 The Aegis representation shall provide tracking and discrimination messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.5.3 The CTM touch points for the Aegis representation are N/A for Battle Manager Tracking and Discrimination.

3.7.1.1.6 Battle Manager Engagement Planning

3.7.1.1.6.1 The Aegis representation shall support the generation of applicable data items designated in Table A.6: Battle Manager Engagement Planning Data.

3.7.1.1.6.2 The Aegis representation shall provide battle manager engagement planning messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.6.3 The CTM touch points for the Aegis representation are N/A for Battle Manager

3.7.1.1.7 Interceptor Launch and Flyout

3.7.1.1.7.1 The Aegis representation shall support the generation of applicable data items designated in Table A.7: Interceptor Launch and Flyout Data.

3.7.1.1.7.2 The Aegis representation shall process and provide interceptor launch and flyout messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.7.3 The Aegis representation shall consume truth as designated in Table D.3: Truth Allocation Matrix, during Interceptor Launch and Flyout.

3.7.1.1.8 Interceptor Guidance, Navigation and Control

3.7.1.1.8.1 The Aegis representation shall support the generation of applicable data items designated in Table A.8: Interceptor Guidance, Navigation and Control Data.

3.7.1.1.8.2 The Aegis representation shall provide interceptor guidance, navigation and control messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.1.8.3 The Aegis representation shall consume truth as designated in Table D.3: Truth Allocation Matrix, during Interceptor Guidance, Navigation and Control.

3.7.1.1.9 Interceptor Acquisition, Tracking and Discrimination – Excluded for GT venue

3.7.1.1.10 Lethal Intercept

3.7.1.1.10.1 The Aegis representation shall support the generation of applicable data items designated in Table A.10: Lethal Intercept Data.

3.7.1.1.10.2 The communications touch points for the Aegis representation are N/A for Lethal Intercept.

3.7.1.1.10.3 The Aegis representation shall consume truth as designated in Table D.3: Truth Allocation Matrix, during Lethal Intercept.

3.7.1.2 C2BMC

3.7.1.2.1 Pre-Mission Planning

3.7.1.2.1.1 C2BMC representation shall support the generation of applicable data items designated in Table A.1: Pre-Mission Planning Data.

3.7.1.2.1.2 The C2BMC representation shall have the capability to utilize operational mission profiles and settings.

3.7.1.2.1.3 The communications touch points for the C2BMC representation are N/A for Pre- Mission Planning.

3.7.1.2.1.4 The CTM touch points for the C2BMC representation are N/A for Pre-Mission Planning.

3.7.1.2.2 Sensor Acquisition

3.7.1.2.2.1 The C2BMC representation shall support the generation of applicable data items designated in Table A.2: Sensor Acquisition Data.

3.7.1.2.2.2 The C2BMC representation shall provide sensor acquisition messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.2.2.3 The CTM touch points for the C2BMC representation are N/A for Sensor Acquisition.

3.7.1.2.3 Sensor Tracking

3.7.1.2.3.1 The C2BMC representation shall support the generation of applicable data items designated in Table A.3: Sensor Tracking Data.

3.7.1.2.3.2 The C2BMC representation shall provide sensor track messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.2.3.3 The CTM touch points for the C2BMC representation are N/A for Sensor Tracking.

3.7.1.2.4 Sensor Discrimination and Classification

3.7.1.2.4.1 The C2BMC representation shall support the generation of applicable data items designated in Table A.4: Sensor Discrimination and Classification Data.

3.7.1.2.4.2 The C2BMC representation shall provide sensor discrimination and classification messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.2.4.3 The CTM touch points for the C2BMC representation are N/A for Sensor Discrimination and Classification.

FOR OFFICIAL USE ONLY

3.7.1.2.5 Battle Manager Tracking and Discrimination

3.7.1.2.5.1 The C2BMC representation shall support the generation of applicable data items designated in Table A.5: Battle Manager Track and Discrimination Data.

3.7.1.2.5.2 C2BMC shall have the capability to provide battle manager tracking and discrimination messages IAW the message allocations defined in Table C.1: Tactical Messages.

3.7.1.2.5.3 The CTM touch points for the C2BMC representation are N/A for Battle Manager Tracking and Discrimination.

3.7.1.2.6 Battle Manager Engagement Planning

3.7.1.2.6.1 The C2BMC representation shall support the generation of applicable data items designated in Table A.6: Battle Manager Engagement Planning Data.

3.7.1.2.6.2 The C2BMC representation shall have the capability to provide battle manager engagement planning messages IAW the message allocations defined in Table C.1: Tactical…