Atch 1 - Statement of Work 20120223 v36.pdf

FA8307-12-R-0003 FAB-T SOW

FA8307-12-R-0003

Attachment 1

Family of Advanced Beyond Line-of-Sight Terminals

Program (FAB-T)

Statement of Work (SOW)

23 February 2012

FAB-T Program Office (HNT)

Electronic Systems Center (ESC)

Hanscom AFB, Massachusetts 01731-2100

DISTRIBUTION A: Authorized for public release.

TABLE OF CONTENTS

1 PROGRAM SCOPE AND OBJECTIVE

1.1 SCOPE

1.2 OBJECTIVE

2 REFERENCE DOCUMENTS

3 REQUIREMENTS

3.1 PROGRAM MANAGEMENT

3.1.1 Program Management Reviews

3.1.1.1 Post Award Conference

3.1.2 Quality Assurance (QA)

3.1.3 Risk Management (RM)

3.1.4 Configuration Management (CM)

3.1.4.1 Configuration Audit

3.1.4.2 Change Proposals

3.1.4.3 Request for Deviation (RFD)

3.1.4.4 Request for Waiver (RFW)

3.1.4.5 Nomenclature

3.1.4.6 Automated Computer Program Identification Number (ACPIN)

3.1.5 Cost & Schedule Performance Management

3.1.5.1 Contract Work Breakdown Structure (CWBS)

3.1.5.2 Integrated Master Schedule (IMS)

3.1.5.3 Integrated Cost Reporting

3.1.5.4 Contractor Cost Data Reporting (CCDR)

3.1.5.5 Software Resources Data Reporting (SRDR)

3.1.6 Data Management

3.1.6.1 Data Accession List (DAL)

3.1.6.2 Integrated Digital Environment (IDE) Systems

3.2 SYSTEM ENGINEERING (SE)

3.2.1 AEHF Working Groups

3.2.2 Requirements Management

3.2.2.1 Specifications

3.2.2.2 Interface Control Document

3.2.2.2.1 Interface Control Working Group

3.2.3 System Engineering Technical Reviews

3.2.4 Failure Tracking & Reporting

3.2.5 Failure Mode, Effects and Criticality Analysis Report (FMECA)

3.2.6 Deficiency Review Board (DRB)

3.2.7 Frequency Allocation Data Request

3.2.8 Human Machine Interface (HMI) Integration

3.2.8.1 Operator Interface Working Group (OIWG)

3.2.9 Safety

3.2.10 Corrosion Prevention and Control

3.2.11 Hardness Assurance Program

3.2.12 Reliability, Maintainability, and Availability (RMA) Program

3.3 INFORMATION ASSURANCE (IA)

3.3.1 Security Requirements

3.3.2 Program Protection Plan

3.3.3 Criticality Analysis

3.3.4 Supply Chain Risk Management

3.3.5 Counterfeit Parts Plan (CPP)

3.3.6 Key Loading and Initialization Facility(s)

3.4 SOFTWARE

3.4.1 Software Engineering

3.4.1.1 Software Architecture

3.4.1.2 Software Development Process

3.4.1.3 Software Reuse

3.4.1.4 Software Quality Engineering

3.4.1.5 Software Configuration Management

3.4.1.6 Government Oversight of Software Development

3.5 TEST

3.5.1 Developmental Test Program

3.5.2 Production Test Program

3.5.3 Regression Testing

3.5.4 Development Flight Test Program

3.5.4.1 Flight Test Aircraft Option

3.5.5 Contractor IOT&E Support

3.5.5.1 IOT&E Flight Test Aircraft Option

3.6 LOGISTICS

3.6.1 Maintenance Concept

3.6.2 Contractor Supported Meetings (Post CDR)

3.6.3 Repair Level Analysis (RLA)

3.6.4 Technical Manuals and Associated Documents

3.6.5 Spares and Provisioning Data

3.6.5.1 Provisioning

3.6.5.1.1 Spares

3.6.5.2 Support Equipment

3.6.5.3 Product Drawings, Engineering/Technical Data Package

3.6.5.4 Engineering Data Guidance Conference

3.6.5.5 In-Process Review (IPR)

3.6.6 Relationship of Contractor with Subcontractors/Vendors

3.6.7 Engineering Data Updates and Revision

3.6.8 Training

3.6.8.1 Computer Based Training (CBT)

3.6.8.2 Classroom Training

3.6.9 Software Transition Plan To Depot

3.7 PRE-OPERATIONAL/ INTERIM CONTRACTOR SUPPORT (ICS)

3.7.1 Hardware Pre-Operational/ Interim Contractor Support (ICS) Software

3.7.2 Interim Contractor Support (ICS)

3.7.3 Technical Support

3.7.3.1 Field Service Representatives (FSRs)

3.7.3.2 Telephonic Support

3.8 INTEGRATION AND INSTALLATION

3.8.1 Ground Command Post Terminals

3.8.1.1 HEMP Testing for Ground Installations

3.8.2 Airborne Command Post Terminals

3.9 MANUFACTURING

3.9.1 Manufacturing Readiness Assessments (MRA)

3.9.2 Manufacturing Maturation Plan

3.9.3 Production Readiness Review (PRR)

3.9.4 Managing Materials and Vendors

3.9.4.1 Government Industry Data Exchange Program (GIDEP)

4 ACRONYMS

1 PROGRAM SCOPE AND OBJECTIVE

1.1 Scope

This is the Statement of Work (SOW) for the Family of Advanced Beyond Line-of-Sight Terminals

(FAB-T) contract. The FAB-T program will develop, test, and produce the warfighters’ highest priority terminals, which are air (E-4, E-6) and ground fixed and transportable Command Post Terminals (CPT) with Presidential & National Voice Conferencing (PNVC).

1.2 Objective

The Family of Advanced Beyond Line-of-Sight Terminals (FAB-T) provides strategic nuclear and non-nuclear command and control with Extremely High Frequency (EHF), wideband, protected and survivable communications terminals for Beyond Line-of-Sight (BLOS) communications. The contractor shall deliver the first CPT with PNVC by the end of the 4 th quarter Fiscal Year (FY) 2015.

The FAB-T is part of the terminal and control segments of the Advanced EHF (AEHF) satellite system.

It is required to provide Telemetry, Tracking, and Command (TT&C) of the AEHF and Milstar satellites and to fully use the increased capacity of the AEHF constellation. The FAB-T program will develop and field airborne and ground based Military Satellite Communications (MILSATCOM) terminal capability.

FAB-T provides both wideband and survivable protected communications to the strategic and tactical warfighter. Terminals are compatible with AEHF satellites and legacy Milstar EHF satellite systems.

This FAB-T development/production program replaces and expands the capabilities of the existing ground-fixed, ground-transportable, and E-4 and E-6 airborne command post terminals. It is backward compatible to existing Milstar EHF Low Data Rate (LDR) communications, as well as AEHF Extended

Data Rate (XDR) satellite communications in support of strategic nuclear and tactical operational requirements. Ground-based fixed, airborne Command and Control (C2) and transportable FAB-T terminals will ensure that nuclear C facilities remain connected to the President of the United States

Secretary of Defense and Combatant Commanders to provide positive control and nuclear surety of

Nuclear Response forces.

2 REFERENCE DOCUMENTS

The documents listed in the table below are applicable to this SOW.

Document Title Document Number/Date

Program Documents

FAB-T Government Technical

Requirements Document (GTRD), ESC/HNT

Military Standards, Specifications, & Handbooks

Standard Practice for System Safety MIL-STD-882D, 10 Feb 2000

Human Engineering MIL-STD-1472G, 11 Jan 2012

Configuration Management Guidance MIL-HDBK-61A, 7 Feb 2001

Work Breakdown Structures for Defense

Materiel Items

MIL-STD-881C, 3 Oct 2011

Ionizing Dose and Neutron Hardness

Assurance Guidelines for Microcircuits and Semiconductor Devices

MIL-HDBK-814, 8 Feb 1994

Dose-Rate Hardness Assurance Guideline MIL-HDBK-815(1), 10 Jan 2002

Guidelines for Developing Radiation

Hardness Assurance Device

Specifications

MIL-HDBK-816 (1), 9 Apr 2002

System Development Radiation Hardness

Assurance

MIL-HDBK-817, 8 Feb 1994

Reliability Test Methods, Plans, and

Environments for Engineering

Development, Qualification, and

Production

MIL-HDBK-781A, 1 Apr 1996

Technical Reviews and Audits For

Systems, Equipments, and Computer

Software

MIL-STD-1521B, 4 Jun 1996 (Guidance)

Materials and Processes for Corrosion

Prevention and Control in Aerospace

Weapons Systems

MIL-HDBK-1568 (18Jul1996)

Performance Specification Logistics

Management Information

MIL-PRF-49506 CANX 4Aug 88

Procedures For Performing a Failure

Mode Effects and Criticality Analysis

MIL-STD-1629A

Parts Management MIL-STD-3018 (27Oct2011)

Reliability-Centered Maintenance (RCM)

Process

MIL-STD-3034 (22Jun2011)

High-Altitude Electromagnetic Pulse

(HEMP) Protection for Ground-Based

C4I Facilities Performing Critical, Time-

Urgent Missions, Part 1 and 2

MIL-STD-188-125-1

USAF & DoD Documents

Information Assurance (IA)

Implementation

DoDI 8500.2, 6 Feb 2003

Department of Defense Information

Assurance Certification and

Accreditation Process (DIACAP)

DoDI 8510.01, 28 Nov 2007

USAF Materiel Deficiency Reporting, Investigation, and Resolution

TO 00-35D-54, 1 May 2007

Program Manager’s Guide: A Modular

Open Systems Approach (MOSA) to

Acquisition, Open Systems Joint Task

Force (OSJTF)

Version 2.0, Sep 2004

DoD Technology Readiness Assessment

(TRA) Deskbook, DUSD(S&T)

May 2005

Critical Program Information (CPI)

Protection Within the DoD

DODI 5200.39, July 16, 2008

Program Protection Plan Outline &

Guidance

Version 1.0, dated July 18, 2011

Risk Management Guide for DoD

Acquisition

August 2006

Information Assurance (IA) in the

Defense Acquisition System

DODI 8580.1, dated 9 June 2004

DoD Guide to Integrated Product and

Process Development (IPPD)

Ver 1.0 5 Feb1996

Manufacturing Readiness Levels (MRL)

Deskbook

Ver 2.01 Jul 2011

Federal Information Processing Standards

Publication

(FIPS) 199

National Defense Industrial Association

Guidebook

DoD Instruction 5200.39 (Reference (c)

Industry Standards & Guidance

CMMI for Development Version 1.3 CMU/SEI-2006-TR-008, Aug 2006

Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, and Disposition

SAE AS5553 Adoption (31Aug2009)

Engineering for System Assurance; and

Piloting Supply Chain Risk Management for Federal Information Systems;

NIST Interagency Report 7622, 3 REQUIREMENTS

The contractor shall design, develop, manufacture, test and deliver command post terminals that meet all requirements in the FAB-T Government Technical Requirements Document (GTRD).

3.1 Program Management

The contractor shall use the DoD Guide to Integrated Product and Process Development (IPPD) to define their management process. The contractor shall allow the Government to participate as an observer in all contractor program meetings excluding those associated with cost or subcontractor management.

3.1.1 Program Management Reviews

The contractor shall plan and conduct FAB-T quarterly Program Management Reviews (PMR) with

Government attendance at the contractor’s facility. The contractor shall prepare an agenda and record the minutes and action items of the PMRs. The contractor shall provide program and technical progress metrics and the Integrated Master Schedule (IMS) at all PMRs. The contractor shall provide the government read only access to the contractor’s real time metric data base to include weekly metrics focused on Anomaly Reports and test execution progress, and monthly program and technical progress metrics to include schedule, cost, systems engineering, software, software qualification, hardware qualification, systems integration, test, performance, quality and sustainment metrics.

3.1.1.1 Post Award Conference

The contractor shall host a Post Award Conference to include major subcontractors and TPO representatives within thirty (30) calendar days of contract award.

3.1.2 Quality Assurance (QA)

The contractor including subcontractors shall manage the program in accordance with SAE-AS9100 for manufacturers of military equipment to standardize on quality.

3.1.3 Risk Management (RM)

The contractor shall implement and maintain an active risk management program meeting the requirements of the Risk Management Guide for DoD Acquisition, throughout the FAB-T contract. The risk management process shall be executed across all Integrated Product Teams (IPT) and phases of the program and it shall address all cost, schedule, and technical risks. The contractor shall conduct monthly risk working groups and quarterly risk management board meetings. The risk management board shall coincide with the quarterly PMR.

3.1.4 Configuration Management (CM)

The contractor shall implement and maintain a CM system for the FAB-T contract IAW MIL-HDBK-

61A. The contractor shall develop, maintain, and document a configuration management approach to address configuration identification, status accounting, configuration control and reviews and audits to include the hardware and software of the system as well as test equipment and test items.

3.1.4.1 Configuration Audit

The contractor shall prepare and conduct an audit of both functional and physical configuration as a validation of a production baseline prior to completion of the development effort and the start of the production effort. (DI-CMAN-81022C/T; DI-SESS-81646/T)

3.1.4.2 Change Proposals

The contractor shall provide the data necessary to propose contract changes to contract requirements or engineering changes to the approved technical baseline. (DI-ADMN-81401B/T; DI-CMAN-80639C/T)

3.1.4.3 Request for Deviation (RFD)

The contractor shall prepare a RFD whenever a departure from the contractually specified baseline is proposed for a specific number of units or for a specific time. (DI-CMAN-80640C/T)

3.1.4.4 Request for Waiver (RFW)

The contractor shall prepare a RFW whenever a departure from the contractually-specified baseline is proposed for all units. (DI-SESS-81732)

3.1.4.5 Nomenclature

The contractor shall establish nomenclature for each system and sub-system configuration including the activities required for government acceptance of forms DD-61, Request for Nomenclature. (DI-CMAN-

81254A/T)

3.1.4.6 Automated Computer Program Identification Number (ACPIN)

The contractor shall establish an ACPIN Data and Control Record which provide the assignment of a

CPIN for embedded computer system software. The CPIN will be used for configuration management of software and to facilitate software distribution. (DI-MISC-81454B)

3.1.5 Cost & Schedule Performance Management

The contractor shall implement and maintain cost and schedule management procedures and systems.

The contractor shall format the deliverable data for electronic data interchange (EDI) in accordance with the ANSI X12 Standard.

3.1.5.1 Contract Work Breakdown Structure (CWBS)

The contractor shall develop and maintain the CWBS and dictionary using MIL-HDBK-881C for guidance. The Government provided Preliminary WBS (Atch 4) provides the basis for further extension by the Contractor to lower levels. The contractor shall extend the Preliminary WBS to the level required to provide internal management, surveillance, and performance measurement, regardless of the reporting level stipulated in the contract for Government visibility. (DI-MGMT-81334D/T)

3.1.5.2 Integrated Master Schedule (IMS)

The contractor shall prepare and maintain an IMS throughout the life of the program. The contractor shall use the IMS as a day-to-day execution tool and to periodically assess progress in meeting program requirements to include the three contractor defined Integrated Master Plan (IMP) events. The contractor shall maintain and update the IMS, when necessary, to reflect Government approved changes in the

Integrated Master Plan (IMP), or changes in the contractor’s detailed execution activities or schedule.

When revising or updating the IMS, the contractor shall ensure that any changes to the original baseline are identified and tracked to provide the Government continuous insight into deviations and changes from the original schedule baseline. The IMS shall include the activities of the prime and sub-contractors. All contractor schedule information delivered to the Government or presented at program reviews shall originate from the IMS. The contractor shall perform analyses of the IMS tasks and report potential or existing problem areas and recommend corrective actions to eliminate or reduce schedule impact. The contractor shall submit an initial IMS 30 days after contract award and then status and post the IMS in MS Project format on their Integrated Digital Environment every 2 weeks thereafter. (DI-

MGMT-81650/T)

3.1.5.3 Integrated Cost Reporting

All cost reporting, including subcontractors, shall correspond to applicable Contractor Work Breakdown

Structure (CWBS) elements within the monthly Contract Performance Report (CPR). The contractor shall flow-down CPR to subcontractors meeting applicable thresholds and/or assigned critical tasks.

(DI-MGMT-81466A/T)

3.1.5.4 Contractor Cost Data Reporting (CCDR)

The contractor shall systematically collect and report actual contract costs to provide DoD cost analysts with needed data to estimate future costs. Contractor shall prepare Contractor Cost Data Reports. (DI-

FNCL-81565C/T and DI-FNCL-81566C/T)

3.1.5.5 Software Resources Data Reporting (SRDR)

The contractor shall provide a SRDR Data Dictionary with the customized formats and data elements identified in Atch 14. (DI-MGMT-81739B/T; DI-MGMT-81740A/T)

3.1.6 Data Management

The contractor shall provide a central point of contact for data governance. The point of contact shall ensure Government personnel access and the provenance of contract data to include the appropriate version, owner, format, metadata, associated rights and purpose.

3.1.6.1 Data Accession List (DAL)

The contractor shall maintain a current listing of all non-CDRL data generated in performance of this

Statement of Work in a Data Accession List (DAL) and make the list and products available to the

Government through the IDE. (DI-MGMT-81453A/T)

3.1.6.2 Integrated Digital Environment (IDE) Systems

The contractor shall establish and maintain an Integrated Digital Environment (IDE) that ensures timely communications over the entire period of performance of the contract. The program information will include UNCLASSIFIED, For Official Use Only (FOUO), and CLASSIFIED information therefore the

IDE will need to be hosted on both classified and unclassified environments. The contractor shall ensure that the collaborative environment is accessible by members of the program (contractors, subcontractors, inter-divisional organization members, and Government members approved by the Government

Program Manager). The program IDE shall contain program information including all documentation referenced in the SOW to include meeting agendas, minutes and action items, all CDRL items, informal documentation, IPT information, the risk management information, the action item database, work-in-progress information, and other information developed under this contract. The IDE shall be set up to notify all users by email when documents are posted. The contractor shall be responsible for the protection of any CLASSIFIED, privacy related, or proprietary data.

3.2 System Engineering (SE)

The contractor shall implement comprehensive system engineering processes. The contractor shall define and report on technical performance measures (TPM) (CTRD performance requirements and engineering measures, e.g. successful start-ups, successful log-on) that provide insight into the terminal performance, its maturity and management of risks. The contractor shall execute all systems engineering, software engineering, hardware engineering, firmware engineering, and related program management processes at a level of proficiency equivalent with the Capability Maturity Model

Integration for Development (CMMI-DEV V1.3) Capability Level 3 or higher for all Level 2 and Level

3 process areas. The contractor shall support and participate in scheduled Quality Attribute Workshops

(QAW). (DI-SESS-81785)

The contractor shall support a Government CMMI Process-In-Execution Review (PIER) to assess the performance of the contractor’s execution. This support will include five days of Government on-site review. The contractor shall provide the Government access to required documentation, process descriptions, and personnel in support of the PIER.

3.2.1 AEHF Working Groups

The Contractor shall participate in AEHF Working Groups to include the EHF Protected Interface

Control Working Group (EPICWG), the AEHF System Engineering Working Group (ASEWG), the

Mission Control System to Terminal Interface Control Working Group (MTICWG), the Platform

Integration Control Working Group (PICWG)/Airborne Platform Working Group (APWG), the

Payload to Terminal Interoperable Communications Working Group (PTICWG), the Integrated

Logistics Support Working Group (ILSWG), the MILSATCOM Key Working Group

(MILKEYWG) and ad hoc working groups as they may arise, for the purpose of developing, reviewing, and assessing system interface changes.

3.2.2 Requirements Management

The contractor shall conduct requirements analysis and management using a single database to capture all requirements. The contractor shall generate requirements specifications for the system, sub-systems, and configuration items level including the functional/ performance baseline, the allocated baseline and the product baseline.

The contractor shall identify safety critical and/or security critical requirements and establish additional process controls for these requirements.

The contractor shall provide the Government with access to all requirements, requirements products, requirements metadata, and the requirements management database. The contractor shall develop and maintain a specification tree depicting all requirements products, analyses, and related products.

The contractor shall establish, collect, and report quarterly metrics at all levels (e.g. system, sub-system, configuration item, drawings) for each baseline covering requirements volatility, quality, completeness, and verification. The contractor shall ensure that all requirements are bi-directionally traceable to source documents, between levels (i.e., system to sub-system), and to verification procedures.

3.2.2.1 Specifications

The contractor shall develop FAB-T System/Subsystem Specifications. (DI-IPSC-81431A)

3.2.2.2 Interface Control Document

The contractor shall develop and document the interfaces between FAB-T and the following: Ground-

Fixed Sites, Ground Transportable Installations, E-6 Aircraft, and E-4 Aircraft. (DI-CMAN-81248A/T)

3.2.2.2.1 Interface Control Working Group

The contractor shall establish an Interface Control Working Group (ICWG) with each airborne platform.

The FAB-T Program Office will co-chair the ICWG. The contractor shall prepare an agenda and record the minutes of the Working Group. The members will consist, at a minimum, of the Defense

Information Systems Agency (DISA) and the E-4 and E-6 program offices.

3.2.3 System Engineering Technical Reviews

The contractor shall conduct System Engineering Technical Reviews to include, but not limited to, Systems Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review

(CDR), and Test Readiness Reviews (TRR). The contractor shall use the entry and exit criteria provided in Atch 3, at a minimum. SRR, PDR, and CDR shall address all Block 1 and Block 2 GTRD requirements. The contractor shall conduct a formal demonstration associated with the month 9 contractor-defined IMP event. The contractor shall define entry and exit criteria for the event and success criteria for the demonstration. The month 9 event and demonstration should achieve as many of the CDR entry and exit criteria and CDR demonstration criteria as possible. The contractor shall include all technology maturation planning in the development activities to ensure the system design will mature to a Technology Readiness Level (TRL) of 8 by Milestone C. The contractor shall support the

Government Technology Readiness Assessment (TRA) to be conducted in support of Milestone C.

3.2.4 Failure Tracking & Reporting

The contractor shall implement and maintain a Failure Reporting, Analysis, and Corrective Action

System (FRACAS) system to track and report failures of deliverable end items to build a history of faults to be used as a means of detecting failure trends, parts, and manufacturing process problems. The

Contractor shall compile and submit monthly FRACAS summary reports. The contractor shall establish and conduct a FRB to manage the disposition of failure reports. (DI-RELI-80255)

3.2.5 Failure Mode, Effects and Criticality Analysis Report (FMECA)

The contractor shall conduct and deliver a FMECA; use MIL-STD-1629A Change Notice 2 as guidance.

The FMECA shall include failure rates quantified for all identified failure modes, criticality analysis, severity rankings and a mission loss perspective. The contractor shall identify and evaluate the effects and criticality of hardware and software failures and safety hazards. The Contractor shall provide recommended actions for elimination or control of failure risks. (DI-ILSS-81495)

3.2.6 Deficiency Review Board (DRB)

The contractor shall comply with USAF T.O. 00-35D-54 for processing of Deficiency Reports. The contractor shall provide engineering support to the Deficiency Review Board (DRB) to analyze reported hardware and/or software issues and recommend corrective action to the Government.

3.2.7 Frequency Allocation Data Request

The contractor shall provide Frequency Allocation data to the Government to support Government submittals of Form 1494 for Equipment Frequency Allocation; Stage 1 conceptual, Stage 2 experimental, Stage 3 developmental (over the air), and Stage 4 operational. The contractor shall submit a site Radio Frequency Authorization request to enable over the air testing at the contractor’s facility.

3.2.8 Human Machine Interface (HMI) Integration

The contractor shall use the general human factors engineering criteria established in MIL-STD-1472F for the design, development, production and integration of FAB-T.

3.2.8.1 Operator Interface Working Group (OIWG)

The contractor shall establish and participate in an OIWG to address the human machine interface to include the tabular displays and data entry formats for performing the FAB-T mission. The members will consist of, at a minimum, the contractor, users and the Terminal Program Office. The contractor shall prepare an agenda and record the minutes of the Working Group.

3.2.9 Safety

The contractor shall establish, maintain, and implement a system safety program plan IAW MIL-STD-

882D. The contractor shall participate in the Program System Safety Working Group (SSWG). (DI-

SAFT-80101B/T; DI-SAFT-80102B)

3.2.10 Corrosion Prevention and Control

The contractor shall establish, conduct, document, and maintain corrosion prevention and control program plan using MIL-HDBK-1568 for guidance. (DI-MFFP-81403)

3.2.11 Hardness Assurance Program

The contractor shall develop a Nuclear Survivability Hardness Assurance Program, using MIL-HDBK-

423, MIL-HDBK-814, MIL-HDBK-815, MIL-HDBK-816 and MIL-HDBK-817 as guidance. The

Hardness Assurance Program shall include all nuclear effects applicable to this program including hardness assurance and hardness maintenance techniques and procedures and identification of all

Hardness Critical Items and Hardness Dedicated Items. The contractor shall provide Radiation Lot

Acceptance Test (RLAT) data and analysis with each delivered LRU to certify that the LRU meets the allocated LRU Probability of Survival (Ps) per the allocation in the Nuclear Hardness and Survivability

Design Analysis. The contractor shall provide analysis with each delivered terminal to certify it meets

Ps. (DI-NUOR-80926/T; DI- ENVR-80266)

3.2.12 Reliability, Maintainability, and Availability (RMA) Program

The contractor shall establish, develop, and maintain a comprehensive RMA Program and document it in a Reliability Program Plan IAW ANSI/GEIA-STD-0009. The contractor shall prepare and provide

RMA prediction and testability models and analyses. The contractor shall use the RMA prediction and testability models to generate and update hardware and software reliability, maintainability and testability allocations, aggregate system-level RMA based on subsystem, LRU, and software predictions, identify single points of failure, reliability-critical items, and areas where additional design or testing activities are required in order to achieve RMA and testability requirements. (ANSI/GEIA-

STD-0009/T, DI-RELI-81497/T)

3.3 Information Assurance (IA)

The contractor shall provide documentation, testing, and other necessary functions, materials, and artifacts to support a cryptographic system certification by the National Security Agency (NSA), a system security certification by the USAF, and a system security accreditation decision by the

Designated Approval Authority (DAA) prior to the first production delivery.

The FAB-T system will be independently tested by the Terminal Program Office (TPO) and submitted to the DAA for certification and accreditation (C&A) prior to operation and use.

The contractor shall support the Government IA testing and certification efforts, and the development of a system that obtains an Authority To Operate (ATO) under DoDI 8510.01, DoD Defense Information

Assurance Certification and Accreditation Process (DIACAP), or its successor guidance.

The FAB-T contractor shall provide complete test plans and packages for the NSA and the DAA, in support of Interim Approvals To Test (which includes but is not limited to Over-The-Air (OTA) testing, OTA re-keying, space-based assets testing, and backward compatibility testing with Milstar). (DI-

MISC-81762; DI-SESS-81694; DI-TMSS-81668A; DI-QCIC-81691A; DI-MISC-81688; DI-MISC-

80711A/T; DI-QCIC-81690; DI-SESS-81724; DI-QCIC-81689;DI-EMSC-81687; DI-EMCS-81684;

DI-EMCS-81683; DI-MGMT-81717C; DI – MGMT-81845/T)

3.3.1 Security Requirements

The contractor shall complete all security requirements including code reviews, certification reviews, crypto-verification/security verification (CV/SV) testing, vulnerability analysis and a delta certification for Block 2.

The contractor shall design the system to incorporate Mission Assurance Category (MAC) I levels of protection to ensure appropriate confidentiality, integrity, and availability for a system that processes, encrypts, and transmits data at the TOP SECRET (Classified) Confidentiality Level, as defined by

Department of Defense Instruction (DoDI) 8500.2, Information Assurance (IA) Implementation. The contractor shall develop a software architecture that addresses Information Assurance and Security issues IAW DODI 8580.1 and DODI 5200.39

The contractor shall establish and maintain working relationships, through the TPO, with the NSA and the DAA. The contractor shall support the removal of the cuts and jumpers within the IA boundary relative to meeting NSA certification criteria. The contractor shall support NSA certification, DAA

C&A, and any additional Authority to Connect approvals required of the terminal.

The contractor shall remove all un-used or non-operational code within the IA boundary prior to formal

Crypto Verification / Security Verification tests. The contactor shall perform regression testing with this code removed to ensure compliance of lower level tests, if required.

Cryptographic design and implementation shall minimize terminal costs related to sustainment processes, repair, upgrades, life cycle, re-certification efforts, and maintenance over the lifetime of terminal operation.

Any modifications made within the IA boundary require notification to the government , will be carefully evaluated by the Government and NSA to determine if delta re-certification efforts are necessary, and will likely result in re-evaluation (certification, TEMPEST, etc.).

The contractor shall support any NSA CDRL submission required for recertification based upon IA boundary software modification.

The contractor/subcontractor(s) shall obtain and maintain External Certificate Authority certificates for authenticating, digital signing, and/or encrypting communications that allow secure electronic transactions with the TPO at the medium hardware (HW) assurance level.

The contractor/subcontractor shall encrypt using the security controls for Federal Information Systems and Organizations (at http://csrc.nist.gov/publications/PubsSPs. html) for PPP-identified Critical

Information and government-identified FOUO Information.

The contractor shall plan, host, attend, coordinate, and support FAB-T quarterly Technical Interchange

Meetings (TIM) with the NSA at their location or other locations as designated.

The contractor shall protect unclassified DoD data in the development environment.

3.3.2 Program Protection Plan

The contractor shall participate with the Government in the development of a Program Protection Plan

(PPP) in accordance with the DASD/SE Program Protection Plan Outline & Guidance Version 1.0, July

2011, and shall also participate in determining countermeasures needed to safeguard the Critical

Program Information (CPI) throughout the acquisition process in accordance with guidance provided by

DoDI 5000.02, Operation of the Defense Acquisition System and DoDI 5200.39, Critical Program

Information Protection within the Department of Defense.

The contractor shall plan for and execute program protection in accordance with the PPP and program guidance.

The contractor shall identify all CPI to the Government for inclusion in the PPP.

The contractor shall implement security requirements listed in the PPP.

The contractor shall ensure that each contractor/subcontractor employee completes Government-furnished Program Protection Awareness training prior to performing any contract/task order work, and completes the fiscal year refresher course throughout the period of performance.

The contractor/ subcontractor(s) shall maintain a listing by name and title of each contractor/ subcontractor employee working under this contract/task order that has completed the required training.

Any revisions to this listing as a result of staffing changes shall be included with the next required technical progress report submitted.

The contractor shall assist the Government with any updates to the PPP that are required throughout the life of the FAB-T program.

3.3.3 Criticality Analysis

The contractor shall perform a Criticality Analysis in accordance with the "Program Protection Plan

Outline & Guidance", Version 1.0, dated July 18, 2011, and subsequent revisions from the Deputy

Assistant Secretary of Defense for Systems Engineering.

The contractor shall define the criticality levels by adapting the MIL-STD-882 System Safety Program definitions of criticality to mission.

http://csrc.nist.gov/publications/PubsSPs

The contractor shall identify the mission-critical functions that may result in Level I (catastrophic) or

Level II (critical) protection failures due to operational, system information, or component integrity aspects.

The contractor shall identify the associated logic-bearing system components that implement, or introduce vulnerability to these functions for each Level I and Level II mission-critical function identified.

The contractor shall plan for and implement countermeasures that mitigate foreign intelligence, technology exploitation, supply chain and battlefield threats and system vulnerabilities that result in the

Level I and Level II protection failures, including the processes and practices employed to ensure that genuine information and communications technology (ICT) will be employed in the solution and that processes and requirements for genuine ICT are levied upon subcontractors.

The contractor shall ensure that the updated Criticality Analysis assumptions, rationale, results, and

SCRM information and mitigations are made available for Government review at each System

Engineering Technical Review to include the SRR, PDR, CDR, TRR, PRR and applicable acquisition milestones.

3.3.4 Supply Chain Risk Management

The contractor shall develop and implement a Supply Chain Risk Management (SCRM) plan that implements as a minimum the control elements of SA-12 of NIST SP 800-53.

Critical elements shall be judged for their Security Category in accordance with Federal Information

Processing Standards Publication (FIPS) 199.

The contractor shall implement SCRM best practices, applied to the development of the system; key practices are found in: the National Institute of Standards and Technology (NIST) Interagency Report

7622, Piloting Supply Chain Risk Management (SCRM) for Federal Information Systems; National

Defense Industrial Association Guidebook, Engineering for System Assurance; and DoD Instruction

5200.39 (Reference (c)).

The contractor shall document the risks to the supply chain as well as the mitigation to counter those risks. (DI-SDMP-81748)

The contractor shall identify potential suppliers of critical components including cost, schedule, and performance information relevant for choice among alternates, and planned selection for the purpose of engaging with the government to develop mutually-agreeable risk management plans for the suppliers.

The contractor shall control access by foreign nationals to program information including system design information, DoD-unique technology, and SW or HW used to integrate commercial technology. The

FAB-T has been designated by the DoD as a “US-only” program. The contractor will have no foreign nationals working on FAB-T.

The contractor shall use Government-provided foreign intelligence and technology exploitation threat information, along with the traditional battlefield threat information, to inform system security engineering and systems engineering, and the procurement decisions processes. (CLIN 0001; 0003;

0004; 0005; 0020)

The contractor shall design the system to meet the availability, reliability, and supportability requirements specified herein without a supply chain disruption caused by counterfeit parts, or malicious functions in both HW and SW. SW designed and coded by unknown sources (i.e., freeware, shareware, and open source SW) shall be thoroughly analyzed and/or tested by the contractor to ensure it is safe and is free of malicious code.

3.3.5 Counterfeit Parts Plan (CPP)

The contractor shall develop and implement a counterfeit parts plan (CPP) as part of the SCRM, in accordance with MIL-STD-3018 and ISO10005, to prevent the inclusion of counterfeit parts or parts embedded with malicious logic. As part of the CPP process, the contractor shall provide certificates of conformance (CoC) and acquisition traceability for the Organizational Change Management(s) and distributers in the supply chain. Manufacturers’ CoCs shall include, at the minimum, the manufacturer’s name and address, the manufacturer or buyer’s part number and dash number, the signature or stamp with title of seller's authorized personnel signing the certificate, and batch identification for the item(s) such as date codes, lot codes, serializations, or other batch identifications. Acquisition traceability includes the name and location of all supply chain intermediaries from the part manufacturer to the direct source of the product. These forms and documentation shall be delivered alongside the end item and with each shipment.

The contractor shall alert the TPO regarding any counterfeit parts discovered. Industry and Government agencies should be informed via the Government-Industry Data Exchange Program (GIDEP). An NSA-approved trusted foundry shall be utilized for classified ICT components. The contractor shall use SAE

AS5553, “Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, and Disposition” as a guide in the development of the counterfeit parts section of the SCRM plan.

3.3.6 Key Loading and Initialization Facility(s)

The contractor shall establish, operate, support, and maintain Developmental Key Loading and

Initialization Facility(s) (DKLIF) and a KLIF, for the purpose of initialization and endorsement of crypto devices.

The contractor shall establish, operate, support, and maintain Local Key Management stations for the purpose of ordering, receiving, tracking, and distributing keying material.

The contractor shall maintain these facilities through LRIP and FRP until the AF establishes organic enterprise initialization and keying stations.

3.4 Software

The contractor shall develop and maintain software design, product documents, and specifications for the FAB-T.

3.4.1 Software Engineering

The contractor shall implement and execute a software development process using current commercial best practices. The contractor shall make current intermediate software development artifacts available in real-time for informal review by the Government. These software development artifacts shall include build results, code analysis results, test plans, test procedures, test results, source code repository, preliminary CDRL documents and data, architecture documentation including reasoning for decisions made, and process descriptions for all facets of software development. The contractor shall prepare a

Software Version Description (SVD) document for all FAB-T software releases. (DI-IPSC-81435A, DI-

IPSC-81427A/T, DI-IPSC-81441A, DI-IPSC-81433A/T, DI-IPSC-81439A, DI-IPSC-81438A, DI-

IPSC-81440A, DI-IPSC-81442A/T)

3.4.1.1 Software Architecture

The contractor shall develop and maintain a software architecture and perform activities that:

Accommodates all Block 1 and Block 2 functionality as defined in the TRD

Facilitates portability of the software from one member of a processor family to another, or to another processor family, minimizing impact to the software design

Provides for performance management consistent with terminal performance requirements including interfaces for low-impact introduction of test driver fixtures and instrumentation;

minimization of shared-state concurrency; graceful degradation/failure under excessive load;

efficient structure for input/output; system-wide instrumentation for central processing unit, memory, and bus utilization; well-defined policy for multi-processor distribution, priority assignment, scheduling and timeliness

Defines and implements a stability and reliability implementation approach consistent with the

Reliability Program Plan

Documents and measures the time constraint requirements levied on the terminal, including explicit CTRD requirements and referenced protocol ICDs and ensure they are met.

Facilitates “design for testability” and enables component level automated test

3.4.1.2 Software Development Process

The contractor shall employ software engineering processes that are equivalent to the CMMI-DEV

Level 3 or higher for all Level 2 and Level 3 process areas used on the contract. The contractor shall incrementally develop and demonstrate key software functionality. The contractor shall define and report on reliability models and metrics appropriate to the system-level reliability requirements. The contractor shall employ best practices for reliable software for fault isolation, fail-safe techniques, disciplined and document error-handling and recovery patterns. The contractor shall plan and conduct formal software qualification events, including initial, delta, and regression qualification activities to verify the software meets requirements. The contractor shall identify requirements tracing directly to the system-level, including non-functional requirements such as reliability and performance.

3.4.1.3 Software Reuse

The contractor shall identify to the Government all code with reuse or open source origins and provide a plan for its management. The contractor shall ensure that all non-proprietary software delivered to the

Government conforms to the standards of the software developed on this contract. The contractor shall ensure all proprietary software delivered to the government is Common Criteria certified.

3.4.1.4 Software Quality Engineering

The contractor shall employ industry best-practices for quality engineering at all stages of development, to include, at a minimum, peer reviews of products, static code analysis, dynamic code analysis, test coverage metrics. The contractor shall identify and report to the Government software defects and the phase of development in which the defects are inserted and discovered. The contractor shall implement improvements to defect management tools and processes to reduce overhead, manual intervention, and costly mistakes associated with inadequate defect backlog workflow.

3.4.1.5 Software Configuration Management

The contractor shall implement a software change management process and configuration control infrastructure that supports day-to-day developer activities while retaining change accountability and quality control. The contractor shall implement a process for tracking all versions of software artifacts using a formal software versioning system. Software artifacts include source code and supporting build, test, deployment, and automation that were developed or obtained for the purposes of this program.

3.4.1.6 Government Oversight of Software Development

The contractor shall provide (via the IDE) the Government with secure access to ready-to-compile software increments that are under formal configuration control as well as the results of quality engineering assessments on the increments. The contractor shall provide (via an IDE) the Government with secure access to software metrics that address software development progress within each phase

(e.g., design, coding, integration and testing), software quality (including number of defects detected and number of defects corrected over time), and performance (throughputs, response times, and software related TPMs) of the software, as well as software size (by Computer Software Configuration Item

(CSCI) and by Computer Software Configuration (CSC) at a minimum), memory use on each memory device, processor utilization on each processor, and bus utilization on each bus.

3.5 Test

The contractor shall conduct a Test and Evaluation program including support to the Government

Integrated Test Team (ITT), working groups and test events; Intersegment Systems Test (IST) Working

Groups; and AEHF enterprise level test events to address satellite testing and interoperability. The contractor shall establish and maintain a contractor System Integration Laboratory (SIL) for use in FAB-

T software and hardware development, integration, testing, certification, and production activities.

3.5.1 Developmental Test Program

The contractor shall develop a test program which will verify all GTRD requirements in accordance with Section 4 of the GTRD. The contractor shall conduct the FAB-T test program IAW the

Government approved Test and Evaluation Program Plan. The contractor shall verify and validate tools, to be approved by the Government as part of TRR, used in the verification of system level requirements.

The contractor shall include as part of the test program a Reliability Growth Test IAW MIL-HDBK-

781A.

The contractor shall build and deliver a total of 6 Engineering Development Models (EDMs) as defined in Atch 9 to the contract. The contractor shall deliver EDMs as follows: 1 st EDM two months prior to the start of Block 1 FQT; 2 nd

EDM three months prior to Development Flight Test; final 4 EDMs delivered within two months of the completion of Block 1 FQT. The contractor shall conduct Terminal Level

Acceptance Testing IAW Government approved test procedures on all EDMs.

The contractor shall plan, document, and implement a regression test program at all levels of the test pyramid (unit, component, assembly/integration, software qualification and CTRD system verification) to ensure software and hardware continue to meet requirements, function as designed, and known defects are not re-introduced. The regression program shall explicitly describe risk assessment criteria and rationale for regular schedule-driven versus event-driven regression activities. (DI-NDTI-81284;

DI-SESS-81704/T; DI-EMCS-81541B; DI-NDTI-80809B; DI-EMCS-81542B)

3.5.2 Production Test Program

The contractor shall establish and conduct a test program for the production phase. The contractor shall develop and conduct first article test procedures for the first unit of a particular type or first unit after any production break of more than six months. The contractor shall develop and conduct production acceptance test procedures, including environmental stress screening and hardness assurance, to validate functionality of each SRU and LRU. The contractor shall conduct Terminal Level Acceptance Testing on all LRIP deliveries and propose a sampling plan for production deliveries. (DI-NDTI-81284; DI-

NDTI-81307A; DI-SESS-81704/T; DI-NDTI-80809B)

3.5.3 Regression Testing

The contractor shall perform regression testing to re-qualify the system in the event of software and/or hardware design changes made in production. The contractor shall address regression testing within the

Test and Evaluation Program Plan. (DI-NDTI-80809B)

3.5.4 Development Flight Test Program

The contractor shall develop a comprehensive flight test program plan that includes verification of the

GTRD requirements, defined in Section 4 of the GTRD, and contractor support to Government flight testing. One goal of this plan is to minimize costs by integrating the contractor and Government test efforts to avoid duplication. The contractor shall support three government flight tests which consist of 6 hours of flight time per flight in addition to contractor planned flight testing. The contractor shall provide technical and maintenance support during the Government Flight Test. (DI-SESS-81704/T; DI-

NDTI-80809B)

3.5.4.1 Flight Test Aircraft Option

If the option is exercised, the contractor shall provide and operate an aircraft for required contractor and

Government development flight testing. The contractor shall perform all necessary aircraft modifications and FAA certification.

3.5.5 Contractor IOT&E Support

The contractor shall review the Government provided IOT&E plans and procedures. The contractor shall dry run the Government provided IOT&E test procedures in contractor’s SIL. The contractor shall provide technical reports to include the results of the review IOT&E test plan and the test procedure review and dry run. The contractor shall provide technical and maintenance support during IOT&E including trouble shooting and root cause analysis of issues found during IOT&E. The contractor shall review the IOT&E test report and provide a technical report to include the analysis of issues documented during IOT&E. (DI-MISC-80508B/T)

3.5.5.1 IOT&E Flight Test Aircraft Option

If the option is exercised, the contractor shall provide and operate an aircraft for government flight tests which consists of 6 hours of flight time per flight which is required for IOT&E flight testing. The contractor shall perform all necessary aircraft modifications and FAA certification.

3.6 Logistics

The contractor shall implement and maintain throughout the contract an Integrated Logistics Support

(ILS) activity to ensure that the required logistics elements, considerations, planning, and cost effectiveness are fully integrated into the system engineering process.

3.6.1 Maintenance Concept

The Integrated Logistics Support (ILS) effort provided shall support a two level maintenance concept.

The maintenance…