FA8307-14-R-0002-0004.pdf

SCHEDULE OF CHANGES

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

1. CONTRACT ID CODE

See Block #2

PAGE OF PAGES

2. AMENDMENT/MODIFICATION NO.

3. EFFECTIVE DATE

10 JUL 2014

4. REQUISITION/PURCHASE REQ.NO.

5. PROJECT NO. (If applicable)

6. ISSUED BY AFLCMC/HNCKA CODE FA8307 7. ADMINISTERED BY (If other than Item 6) CODE

AFLCMC/HNCK

CYBER/NETCENTRIC DIRECTORATE

230 HALL BLVD, STE 114

SAN ANTONIO, TX 78243-7007

KELLEN J. CURRY 210-925-2861

kellen.curry.1@us.af.mil

8. NAME AND ADDRESS OF CONTRACTOR (No., street, county, State and ZIP Code) (X) 9A. AMENDMENT OF SOLICITATION NO.

FA8307-14-R-0002

X

9B. DATED (SEE ITEM 11)

10A. MODIFICATION OF CONTRACT/ORDER NO.

10B. DATED (SEE ITEM 13)

CODE FACILITY CODE

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers is extended, X is not extended.

Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:

(a) By completing Items 8 and 15, and returning 0 copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER.

If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATION OF CONTRACTS/ORDERS,

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

(X )

A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: ( ) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO. ITEM

10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation data, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(b).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

1. The purpose of this amendment is to incorporate the most recent versions of the Statement of Objectives (SOO), dated 10 July 2014 and Section L, Intsructions to Offerors, dated 10 July 2014.

2. The SOO changes are as follows: Deleted para 3.1.6.11; Modified para 3.2.6.5 and para 3.3.4.5.

3. The Section L changes are as follows: Deleted para 4.7(b)(4); Modified para 2.3.9.3(b).

4. All other terms and conditions remain unchanged.

POC Kellen Curry; kellen.curry.1@us.af.mil

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print).

16A. NAME AND TITLE OF SIGNER (Type or print)

LORI A. ROBARGE

15B. CONTRACTOR/OFFEROR

15C. DATE SIGNED 16B. UNITED STATES OF AMERICA

16C. DATE SIGNED

(Signature of person authorized to sign)

BY________________________________________

(Signature of Contracting Officer)

NSN 7540-01-152-8070 30-105 STANDARD FORM 30 (REV.10-83)

PREVIOUS EDITION UNUSABLE Prescribed by GSA ConWrite Version 6.14.0 FAR (48 CFR) 53.243

Created 11 Jul 2014 2:59 PM

LIST OF ATTACHMENTS

FA8307-14-R-0002 0004

DOCUMENT PGS DATE TITLE

ATTACHMENT 3 42 10 JUL 2014 STATEMENT OF OBJECTIVES (SOO)

ATTACHMENT 13 70 10 JUL 2014 SECTION L, PROPOSAL PREPARATION

INSTRUCTIONS

FA8307-14-R-0002 ATTACHMENT 3

United States Air Force (USAF)

Mini Crypto (MC)

Statement of Objectives (SOO)

Version - 2.0

10 July 2014

DISTRIBUTION STATEMENT: Approved for public release; distribution is unlimited.

ii

THIS PAGE INTENTIONALLY LEFT BLANK

TABLE OF CONTENTS

1. BACKGROUND

2. SCOPE

3. OBJECTIVES

3.1 Engineering & Manufacturing Development (EMD)

3.1.1 Prime Mission Product

3.1.2 Test and Evaluation (T&E)

3.1.3 Systems Engineering

3.1.4 Program Management

3.1.5 Data

3.1.6 Product Support

3.1.7 Training

3.2 Low Rate Initial Production (LRIP) Objectives

3.2.1 Prime Mission Product (WBS 4.1)

3.2.2 Operational Test and Evaluation (OT&E) (WBS 4.2)

3.2.3 Systems Engineering

3.2.4 Program Management

3.2.5 Data

3.2.6 Product Support

3.2.7 Training

3.3 Full Rate Production

3.3.1 Prime Mission Product (WBS 5.1)

3.3.2 Program Management

3.3.3 Data

3.3.4 Product Support

4. ACRONYMS

1. BACKGROUND

Current combat operations have driven the transformation of war fighting techniques and the types of tools required to maintain military dominance in asymmetric warfare. Many of the devices used in the battlefield have taken advantage of advances in miniaturization of electronics resulting in equipment with low Size, Weight and Power (SWaP) parameters. These Small

Form-Factor (SFF) devices provide tactical and strategic advantages, supporting sensitive and even classified operations. It is during these operations that the data, command and control messages, and sensitive information must be protected against all adversaries. Additionally, these modern war fighting missions are dynamic, requiring a modern key management process for mission-time generation and over-the-air distribution of crypto keys to tactical devices on an as-needed basis.

The Air Force Life Cycle Management Center, COMSEC Products Branch (AFLCMC/HNCC) in collaboration with Air Force Space Command (AFSPC) Cyber Support Squadron (CYSS), the

Lead Command, identified a number of SFF tactical platforms in need of a cryptographic solution. Without a cryptographic solution in these tactical devices, communications may become increasingly vulnerable to compromise and exploitation. Additionally, analysis showed an embeddable solution does not exist to address the full set of security needs.

In order to guide the design, development, and procurement of a new cryptographic device that provides low SWaP cryptographic capabilities for tactical SFF systems, the United States Air

Force (USAF) established Mini Crypto (MC), an Acquisition Category III (ACAT III) Program.

The MC program received an approved Materiel Development Decision (MDD) from the

Program Executive Officer (PEO) on April 10, 2013 to develop and produce a cryptographic solution for embedment into SWaP-constrained tactical devices. The new MC device delivered by this program will meet the operational requirements of current and future tactical war fighting systems and will integrate the appropriate National Security Agency (NSA) tenets. It will allow for operational readiness and support secure information sharing with more than just Department of Defense (DoD) operations, allowing for secure communications with coalition partners and friendly forces.

2. SCOPE

This Statement of Objectives (SOO) defines the efforts to be accomplished by the Offeror. The contract scope includes Engineering and Manufacturing Development (EMD), Low Rate Initial

Production (LRIP) and Full Rate Production (FRP). The effort will include design, development, production, documentation, integration, testing, certifications, training, maintenance, and logistics of all MC Modules, including hardware and software.

3. OBJECTIVES

The primary objective of the MC program is to develop and produce a low-cost, low-SWaP, NSA Type 1 certified module that can be embedded in a variety of SFF communication devices.

This module will be capable of protecting information at the Secret and Below (SaB) level, utilize Tactical Key Management (TKM) and require Cryptographic High-Value Product

(CHVP) handling to maximize protection of and minimize the burden on the warfighter. The effort addressed by this SOO is focused on creating a complete crypto subsystem that contains all elements needed for full functionality and facilitates embedment into a host platform.

Detailed objectives are described below, with corresponding references to the Work Breakdown

Structure (WBS) elements identified in Table 3, Table 4 and Table 5.

a. EMD to be successfully accomplished within the period of performance specified in the contract; all assumptions clearly stated to achieve your proposed schedule.

b. Production of required LRIP units to be accomplished within the period of performance of LRIP option specified in the contract with all assumptions clearly stated to achieve this schedule.

c. Production of FRP units to be accomplished within the period of performance of the FRP option specified in the contract with all assumptions clearly stated to achieve this schedule.

The Offeror shall levy on proposed teammates and subcontractors the same requirements, restrictions and statutes that are levied on the Offeror by this contract. This “flow-down” shall apply to all tiers of proposed teammates and subcontractors associated with the program during both the development and production phases of the program.

3.1 ENGINEERING & MANUFACTURING DEVELOPMENT (EMD)

The Offeror should plan for seamless transition of appropriate/applicable activities and processes which begin during the EMD phase, but which must continue through FRP.

3.1.1 Prime Mission Product

The Offeror shall develop a detailed design for a cryptographic module that meets program objectives as specified in Section 3.0 above. (WBS 3.1)

3.1.1.1 The Offeror shall develop a detailed design that meets the threshold requirements identified in the MC System Requirements Document (SRD), plus all requirements specified in the Telecommunications Security Requirements Document (TSRD) and the

Information Assurance Security Requirements Directive (IASRD) for the MC program.

If the Offeror proposes to exceed any threshold requirements, they will be incorporated into the subsequent contract as the new thresholds, will be priced separately, and if Key

Performance Parameters (KPPs), the additional cost will be identified. (WBS 3.1)

3.1.1.2 The Offeror shall develop and deliver 4 each prototypes post-Preliminary Design

Review (PDR) and prior to Critical Design Review (CDR) that will demonstrate limited functional capabilities of the MC module. At minimum, the functional prototype shall be based on the allocated baseline and meet the interface requirements specifications to support early integration testing. (WBS 3.1)

3.1.1.3 The Offeror shall develop and deliver 3 each emulators, post-CDR and prior to Test

Readiness Review (TRR) that demonstrates the functionalities and interfaces of MC.

The emulator shall be a representation of the MC module to assist platform developers and integration efforts. The emulator shall also include module software loading, certificate renewal, certificate provisioning and management. (WBS 3.1)

3.1.1.4 The Offeror shall implement Government-approved subsystem detailed designs, based on the Product Baseline by developing, building and delivering 89 each Production

Representative Engineering Development Models (PREDMs). PREDMs shall be acceptance tested utilizing Government Approved Acceptance Test Plans and

Procedures prior to delivery. Offeror shall identify additional PREDMs required to support Developmental Test and Evaluation (DT&E). (WBS 3.1.1, 3.3.1)

3.1.2 Test and Evaluation (T&E)

3.1.2.1 The Offeror shall determine test asset quantities to be produced that are sufficient to provide adequate test assets to meet the test events schedule. Integrated testing will include: Developmental Test & Evaluation (DT&E); NSA Type 1 certification, (Cryptographic Verification and Security Verification); TEMPEST characterization and

Red/Black separation; Reliability; Operational Assessment (OA); and dedicated

Operational Testing. It is the objective of the Government to work closely and collaboratively with the Offeror during T&E, through formal and informal interchange meetings held at the Offeror’s facility. The Offeror shall provide a schedule of dry run qualification events and allow for Government participation. Test events will work toward reducing program risk and optimizing the number of test events to the greatest extent possible. Seamless verification activities will follow the spirit of “no secrets” testing through coordination with the system developers, users, and the program office by maintaining open book access to test data, test event observation, and continuous feedback. (WBS 3.2)

3.1.2.2 The Offeror shall develop a test allocation table that uniquely identifies test assets to test events. The Offeror shall document any assumption of variant quantity and sparing that are necessary to execute the test program (and any rework and retesting). (WBS

3.2)

3.1.2.3 The Offeror shall utilize a comprehensive Verification and Validation process that is integrated with other T&E activities and employs at minimum modeling, testing, and simulation. (WBS 3.2)

3.1.2.4 The Offeror shall provide and deliver Government-approved qualitative and quantitative verification methods for DT&E. (WBS 3.2)

3.1.2.5 The Offeror shall develop and deliver 2 each Government-approved developmental test sets that can visually demonstrate and display information through a Human Machine

Interface/Graphical User Interface (HMI/GUI) during DT&E. The Offeror shall ensure the developmental test set is not restricted to a specific operating system and allows for intuitive user interaction, prior to TRR. (WBS 3.2)

3.1.2.6 The Offeror shall support and participate in test and evaluation activities for planning and execution of DT&E, OAs, product acceptance testing, and testing that supports certification. (WBS 3.2)

3.1.2.7 The Offeror shall develop, conduct, and deliver various test plans, test procedures, and test reports throughout the EMD phase to support the development of the MC modules.

Activities include but are not limited to Integrated Test Team (ITT) meetings, test planning and test data review meetings, TRR, Government-witnessed developmental and operational test events, and module certification testing activities. (WBS 3.2)

3.1.2.8 The Offeror shall provide support for Government-conducted test events which will be held at Government and/or Offeror facilities. The Offeror shall provide a comprehensive Program Test Plan (PTP) that incorporates all required testing events

(individual plans, procedures, and reports), including NSA-mandated tests to achieve

Type 1 accreditation through Security Verification Testing (SVT). The plan shall also include developmental test and evaluation objectives, operational test and evaluation objectives, and certifications to be achieved. The PTP schedule is to be reflected in the

Integrated Master Schedule (IMS) and Integrated Master Plan (IMP). (WBS 3.2.1, 3.2.2, 3.2.3)

3.1.2.9 The Offeror shall develop and deliver TEMPEST plans and reports; and conduct

TEMPEST testing to provide the TEMPEST characterization of the final MC design.

TEMPEST characterization of the MC design supports the integration into and accreditation of host platforms. (WBS 3.2)

3.1.2.10 The Offeror shall support the MC Program Management Office (PMO) and NSA Lead

Service Provider activities leading to NSA Type 1 certification. (WBS 3.2.2)

3.1.2.11 The Offeror shall assist Lead Developmental Test Organization (LDTO) and

Operational Test Organization (OTO) test team members in identifying, documenting and resolving deficiencies in accordance with (IAW) the Offeror’s configuration and data management plans and Technical Order (TO) 00-35D-54, USAF Deficiency

Reporting, Investigation, and Resolution, 1 Nov 11. The Offeror shall participate in

Deficiency Review Boards. (WBS 3.2.1, 3.3.1)

3.1.2.12 The Offeror shall demonstrate that all critical components used in the MC system are free of intentional defects and malicious design alterations. A ‘critical’ component refers to any logic-bearing or state-holding component that can be maliciously altered to produce vulnerabilities to the end system. Reference Aerospace Standard (AS) 5553 and AS 6081, Counterfeit Parts: Avoidance, Detection, Mitigation and Disposition.

(WBS 3.2)

3.1.2.13 The Offeror shall develop, deliver, and demonstrate Acceptance Test Plans and

Procedures. Acceptance Test Plans and Procedures shall include Environmental Stress

Screening and Highly Accelerated Stress Screening. Acceptance Testing shall be used to demonstrate that items procured fulfill the product requirements and specifications.

(WBS 3.2)

3.1.2.14 The Offeror shall develop and deliver First Article Qualification Test Plans and

Procedures. First Article Qualification Test Plans and Procedures shall be used to support the assessment of production readiness prior to Full-Rate Production. (WBS

3.2)

3.1.2.15 The Offeror shall develop and deliver Highly Accelerated Life-Cycle Testing (HALT) plans, procedures, and reports; and conduct HALT to develop Highly Accelerated

Stress Screening that shall be incorporated into the manufacturing processes. The

Offeror shall conduct at minimum two HALT events, one prior to the CDR and another prior to TRR. The intent of conducting a HALT is to identify design weaknesses and manufacturing process problems and increase the margin of strength in the design.

(WBS 3.2)

3.1.2.16 The Offeror shall develop and deliver Qualification Test Plans, Procedures, and

Reports; and conduct Qualification Testing to ensure the final product meets the design requirements and specifications. (WBS 3.2)

3.1.2.17 The Offeror shall provide notifications of Government witnessed test events prior to testing. Government approval to proceed with Government witness test events is required. (WBS 3.2)

3.1.2.18 The Offeror shall develop and deliver Software Test Plans, Descriptions, Procedures, and Reports; and conduct Software Testing to ensure the software meets the design requirements prior TRR. (WBS 3.2)

3.1.3 Systems Engineering

3.1.3.1 As part of the systems engineering process, the Offeror shall plan for, schedule, and conduct technical reviews and audits appropriate to EMD including but not limited to:

Integrated Baseline Review (IBR), System Requirements Review (SRR), System

Functional Review (SFR), PDR, CDR, Developmental Test Readiness Review (DTRR), OA, Physical Configuration Audits (PCA) (to include hardware and software), LRIP

Production Readiness Review (PRR), System Verification Review (SVR) and

Functional Configuration Audit (FCA). Reviews and audits shall be event-driven and based on Government-approved entrance and exit criteria as noted in Table 1. In addition to the formal review processes, it is the objective of the Government to work closely and collaboratively (particularly on high-risk areas such as but not limited to software development/integration and testing), through frequent formal and informal technical interchange meetings held at the Offeror’s facility. (WBS 3.3)

3.1.3.2 The Offeror shall implement sound systems engineering processes to develop functional, allocated, and product baselines. (WBS 3.3)

3.1.3.3 The Offeror shall prepare and follow an effective Government-approved Systems

Engineering Management Plan (SEMP). The Offeror shall prepare required system safety related plans, analyses, and reports. (WBS 3.3)

3.1.3.4 The Offeror shall invoke a requirements management process and tool with bidirectional traceability to include but not limited to the SRD/System Specification to all decomposed requirements, design specifications, test plans/procedures/scripts, and hardware and software configuration items. The Offeror shall control all program data via the Offeror’s configuration and data management plans. The Offeror shall provide a graphical representation of their requirements management hierarchy, test plans, design, hardware and software configuration items, and how their hierarchy links to the

Government’s SRD. The Offeror shall provide a requirements traceability report with each delivery of the [Software Hardware Requirements Specification (SHRS). The

Offeror shall deliver requirements in a format capable of importing into IBM®

Rational® Dynamic Object Oriented Requirements System (DOORS®). The Offeror shall provide the traceability from the Government’s System Requirements Document

(SRD), to the Systems Specification and subsequent requirements, design and test documentation. This traceability shall be importable into DOORS 9.3 or later and be used to automate the creation of the same traceability in DOORS. The Offeror shall provide updates to this delivery as necessary to the Government. At a minimum, the delivery shall include for each requirement:

a. Decomposed requirement(s)

b. Link ID to “parent” requirement (if the parent requirement is provided by the

Government, the Link ID shall be the DOORS Absolute Number provided by the Government)

c. Test methodology

d. Link ID to the test plan/procedure/script

e. Link ID to the design/requirements/implementation specification (WBS 3.3.1)

If the Offeror uses IBM’s Dynamic Object Oriented Requirements System (DOORS), the Offeror shall use DOORS partitioning to support the requirements management process. The Government will provide the Offeror a DOORS partition to include the following:

a. DOORS [SRD] module

b. DOORS Satisfies link module

The Offeror shall use DOORS capabilities to enforce only using the DOORS linksets specified in the DOORS link modules to enforce referential integrity.

The Offeror shall provide a DOORS archive file of the projects/folders/formal modules/link modules used to maintain the requirements/testing/analysis/design at a minimum prior to every technical review and once when the Government approves the product baseline.

3.1.3.5 The Offeror shall establish a system and track maturity of the MC Program design throughout the EMD phase of the program. Meaningful metrics shall be established, tracked, and shared with the Government. (WBS 3.3.1)

3.1.3.6 As part of the systems engineering process, the Offeror shall plan for and conduct hardware and software deficiency reporting, analysis, tracking, and resolution. All critical and major deficiency reports (DRs) shall be resolved before proceeding through the next major review/audit (as specified in Table 1) after the DR was initiated. The

Offeror’s deficiency reporting system shall be compatible with the Government’s Joint

Deficiency Reporting System (JDRS) (Ref: TO 00-35D-54). (WBS 3.3)

3.1.3.7 The Offeror shall participate and provide identification, investigation, test, management, and resolution support for the Government's JDRS (USAF TO 00-35D-

54) and Government’s Configuration Control Board (CCB). The Offeror shall identify and generate DRs for any MC deficiency that impacts Operational Safety Suitability and Effectiveness and the Program Protection Implementation Plan (PPIP) of systems and their sub and/or support systems to include trainers, test, and support equipment.

(WBS 3.3)

3.1.3.8 As part of the systems engineering process, the Offeror shall plan for and conduct a trade study on the design decisions that have a significant impact on factors such as, but not limited to subsystem operational effectiveness, Reliability, Availability, and

Maintainability (RAM), certification, design to cost goals, performance, ease of integration, and life cycle costs. The Offeror shall provide a problem statement, identify constraints, identify alternatives and establish the analysis level of detail to be agreed upon by the Government. Producibility constraints shall be considered during cost and trade study. The Offeror may propose and plan additional trade studies, not to exceed 4 additional studies, to address other or partition design decisions. (WBS 3.3)

3.1.3.9 The Offeror shall provide a comprehensive Reliability Growth Plan to achieve RAM requirements. The plan shall include logical deliverables of supporting documentation on the reliability growth of the design. The approach to meet RAM requirements shall include built-in test (BIT), fault detection and isolation, elimination of false alarms, redundant/degraded system management, reliability and reliability growth models, modularity, mitigation of failure modes, manufacturing quality assurance, and as necessary maintenance procedures and training. The Offeror shall implement a reliability growth program with the focus on performing activities for identifying and eliminating failure modes. The Offeror shall use the DoD Guide for Achieving

Reliability, Availability, and Maintainability (3 Aug 05), MIL-HDBK-344A, MIL-

HDBK-2164A, and MIL-HDBK-189C. (WBS 3.3)

3.1.3.10 The Offeror shall provide a Corrective Action Plan and Failure Analysis and Corrective

Action Report resulting from test events and environmental stress screening failures.

(WBS 3.2, WBS 3.3)

3.1.3.11 The Offeror shall develop and implement stress screens based on results from the

Reliability Growth program and accelerated testing to the manufacturing processes.

(WBS 3.3)

3.1.3.12 A Failure, Mode, Effects, and Criticality Analysis (FMECA) shall be performed to identify ways in which the product can fail to identify performance consequences. The

FMECA, or equivalent, shall be documented on product hardware and software and to the indentured level consistent with the design progression. (WBS 3.3)

3.1.3.13 The Offeror shall develop, design, and produce MC devices while mitigating the growth of Metal Whiskers. The Offeror shall address in the Reliability Growth Plan, a mitigation plan for unavoidable usage of any material that can cause whisker growth and employ practices that prevent whisker formation and its effect on the reliability and maintainability of the MC devices. (Ref: JEDEC/IPC Joint publication JP002, Current

Tin Whiskers Theory and Mitigation Practices Guideline and Airworthiness Advisory, AA-05-01, 9 May 2005). (WBS 3.3.3)

3.1.3.14 The Offeror shall conduct self-assessments of manufacturing readiness throughout the period of performance specified using the definitions, criteria, and processes defined in the Manufacturing Readiness Level Deskbook and AF ManTech Manufacturing

Readiness Assessment (MRA) Questions v11.3 (available at www.dodmrl.com ) as a guide. The results of the assessments shall be provided to the Government. (WBS 3.3)

3.1.3.15 The Offeror shall specify (in an appendix to the SOW) the locations and frequencies of any assessments of manufacturing readiness, along with all the resources to perform or support these assessments. The Offeror shall identify its approach for flowing down these requirements as a function of risk. The Offeror shall address how assessments of manufacturing readiness will be executed and monitored to ensure achieving the required level in accordance with their Manufacturing Maturity Plans (MMP). (WBS

3.3)

3.1.3.16 The Offeror shall support the Government with the assessments of manufacturing readiness of the prime Offeror. The prime Offeror shall lead the assessments at the suppliers with Government participation unless clearly specified differently in the proposal. The Offeror shall address how Manufacturing Readiness Levels (MRLs) will be monitored to ensure achieving the required level in accordance with their MMP.

(WBS 3.3)

3.1.3.17 The Offeror shall develop and use a Life-Cycle Cost Model to estimate life-cycle costs based on evolving product designs and changing program assumptions. The Offeror shall deliver Design-to-Cost and Life-Cycle Cost estimates. (WBS 3.3.1)

3.1.3.18 All parts shall be procured from the original equipment manufacturer (OEM) or its franchised/authorized distributor, and shall come with an OEM certificate of compliance. In cases where a part is not available through a franchised or authorized distributor, the Offeror shall procure parts from a distributor that complies with

AS9120, the Offeror shall test the parts per AS5553 (Appendix E), and the Offeror shall notify the Government. (WBS 3.3)

3.1.3.19 The Offeror shall develop a plan for mitigating the supply chain risk to the system’s critical components, the failure of which would result in either catastrophic or critical compromise of mission capability, or in significant mission degradation. This plan shall be documented as a Microelectronics Source Protection Plan. (WBS 3.3)

3.1.3.20 The Offeror shall demonstrate visibility into its supply chain for each critical component. This visibility shall be documented in a Counterfeit Prevention Plan. (WBS

3.3.2)

3.1.3.21 The Offeror shall conduct Level of Repair Analysis (LORA) commensurate with the level of design, operation and support data available. Identify characteristics from the

LORA for those items identified as item candidates. Such characteristics shall include source of supply, level of maintenance, disposition of unserviceable items, unit cost and reliability. (WBS 3.3)

3.1.3.22 The Offeror shall implement procedures and processes for their participation, and their Team Members’ participation, in the Government-Industry Data Exchange

Program (GIDEP) program, including the submission of alerts/advisories to GIDEP http://www.dodmrl.com/ when warranted. The processes and procedures shall describe how the Offeror (a) receives alerts and advisories from GIDEP and other agencies, or internal sources, (b) determines any impact to their product design and already manufactured hardware, (c) implements corrective action procedures when design and/or produced hardware are affected, and (d) how all of the above flow down to Team Members. (WBS 3.3)

3.1.3.23 The Offeror shall reduce and control the effects of Electromagnetic Interference (EMI) on and from the MC module. (WBS 3.3)

3.1.3.24 The Offeror shall develop and deliver a Key and Certificate Management Architecture

(KCMA) to describe the overall Tactical Key Management (TKM) Architecture; and a

Key and Certificate Management Plan (KCMP) to describe the products and plans necessary to support the design.

Elliptic Curve Cryptography (ECC) is patented technology by Certicom Corporation.

For use of ECC, the Offeror shall work with the United States Government (USG), namely the National Security Agency (NSA) to obtain a patent license or sublicense agreement from Certicom Corporation. Information regarding ECC patents can be found at: http://www.nsa.gov/business/programs/quick_facts.shtml. (WBS 3.3)

3.1.3.25 The Offeror shall document the software development approach in a Software

Development Plan (SDP), shall implement the SDP requirements, and shall maintain the SDP. The SDP shall describe the Offeror’s software development and quality processes. Software processes documented in the SDP shall be integrated and consistent with the IMP and IMS. The Offeror shall address their approach and processes for the management of software risks; software activity planning and statusing; the use of software metrics; and the management of software suppliers, including flow down of performance and process requirements. The Offeror shall comply with the requirements of the SDP for all computer software to be developed, integrated, or maintained under this effort. (Ref: USAF Weapon Systems Software Management Guidebook, 15 August

2008). (WBS 3.1.2, 3.3.1)

3.1.3.26 The Offeror shall develop, deliver, and/or conduct the necessary activities associated with the MC TSRD to support NSA Type 1 certification. (WBS 3.1, WBS 3.3)

3.1.3.27 The Offeror shall host a Software Development Process Review for the government to review the software development processes of the Offeror and/or team members performing software development for the MC program. The review shall be held in conjunction with the Systems Functional Review. The Offeror and/or team members shall support biannual site visits demonstrating the processes are being implemented during the software development. The Offeror shall provide evidence and artifacts to substantiate the Offeror’s processes are implemented throughout the software development. (WBS 3.3.1)

3.1.4 Program Management

http://www.nsa.gov/business/programs/quick_facts.shtml

3.1.4.1 The Offeror shall conduct periodic Technical Interchange Meetings (TIMs), as required, to include technical performance measure reporting. Team member participation may be required, as agreed to by the prime Offeror and the Government. (WBS 3.3.2)

3.1.4.2 The Offeror shall conduct quarterly Program Management Reviews (PMR) with the

Government at the Offeror’s facility or by any other agreed upon method. PMR shall include resource management reporting. Team member participation may be required, as agreed to by the prime Offeror and the Government. (WBS 3.3.2)

3.1.4.3 The Offeror shall perform and participate in project management activities to ensure successful execution of program cost, schedule, and performance goals. The Offeror shall perform risk management and Earned Value Management System (EVMS) activities and conduct an Integrated Baseline Review (IBR). The Offeror shall control all program data via the Offeror’s configuration and data management plans. The

Offeror shall submit an Integrated Program Management Report (IPMR) monthly updating the status of all of these activities. The Offeror shall participate in biweekly

Integrated Product Team (IPT) meetings. (WBS 3.3.2)

3.1.4.4 The Offeror shall maintain and abide by a fully integrated Contract Work Breakdown

Structure (CWBS), CWBS Dictionary, Contract Statement of Work (CSOW), IMP, and

IMS to support the entire effort. (WBS 3.3.2)

3.1.4.5 The Offeror shall conduct a contract security program in accordance with DD-254

Contract Security Classification Specification. (WBS 3.4.4)

3.1.4.6 The Offeror shall maintain an active facility clearance of at least SECRET for the design and manufacture of equipment, as specified in the contract DD Form 254. For test and validation, the facility clearance must be to the highest level of the keys or traffic. (WBS 3.4.4)

3.1.4.7 The Offeror shall develop and maintain a Manufacturing Plan to document the approach to manufacturing and highlight important aspects of their program, such as producibility, supplier management, and quality assurance. (WBS 3.3)

3.1.4.8 The Offeror shall implement an ISO 9001: 2008-compliant quality assurance program for the EMD phase. The Offeror shall define and plan for quality assurance processes, practices, and procedures for implementation during the MC program LRIP phase.

(WBS 3.3.3)

3.1.4.9 The Offeror shall use MIL-HDBK-896 as a guide for the implementation of the

Manufacturing and Quality programs. The Offeror shall use cost, schedule, and quality metrics to monitor and improve the effectiveness of the Offeror’s manufacturing, quality, and supplier management programs. (WBS 3.3.3)

3.1.4.10 The Offeror shall identify a focal point responsible for all Supply Chain Risk

Management (SCRM) related issues and activities, including CDRL items. (WBS 3.3.2)

3.1.4.11 The Offeror shall require associated vendors, suppliers and Team Members to participate in the Offeror’s counterfeit prevention and supply chain risk mitigation activities. (WBS 3.3.1)

3.1.4.12 The Offeror shall advise the Government within 15 calendar days or at the next

Technical Interchange Meeting, whichever is earlier, in the event the Offeror becomes aware of any counterfeit component (critical or not) being introduced, successfully or not, into the supply chain. (WBS 3.3.1)

3.1.4.13 The Offeror shall utilize an Item Unique Identifier (IUID) for each critical component.

This identifier must be difficult or impossible to alter. (WBS 3.5.4)

3.1.4.14 The Offeror shall implement IUID requirements in all supplier agreements to provide traceability of components. (WBS 3.5.4)

3.1.4.15 The Offeror shall protect all MC Critical Program Information (CPI) in accordance with

DODI 5200.39. (WBS 3.3.1)

3.1.4.16 The Offeror shall establish a Software Development IPT (WBS 3.3). The IPT shall meet bi-weekly and shall be responsible to:

a. Define the software systems architecture

b. Plan the development and delivery of all software components, blocks.

c. Monitor the progress and status of all software activities

d. Manage software risks.

e. Advise the program manager in all areas relating to the acquisition and support of software.

f. Monitor compliance of the program on applicable software policies, plans, procedures, and standards.

3.1.5 Data

3.1.5.1 The Offeror shall develop, submit, and update deliverable data items as specified in the

Contract Data Requirements List (CDRL), as applicable to the EMD phase. (WBS 3.4)

3.1.5.2 The Offeror shall make available items on the Data Accession List (DAL) for all program related work products at no additional contract cost. (WBS 3.4.1)

3.1.5.3 The Offeror shall establish a document control system to track both classified and unclassified documents, to deliver CDRLs, update/track CDRL reviews, and track program review/technical interchange action items. For EVMS data the Offeror may propose providing real-time access to Offeror’s internal EVMS. (WBS 3.4.1)

3.1.5.4 The Offeror shall develop and maintain a database, using searchable database software, which identifies the source of all part numbers used in the fabrication, assembly and delivery of the final end product to the customer. Field entries for each part number shall include the name of the supplier that produces it, where they are located, the current configuration dash number, who has design control authority for the part number, and the next higher and lower assemblies (as applicable). The prime Offeror shall also work with its first and lower tier suppliers to identify the source of raw material relevant to the Specialty Metals Clause of the Buy American Act and

Commercial-Off-The-Shelf (COTS) integrated circuits which are at highest risk of exposure to counterfeit parts or lead-free solder. The Offeror shall share this database and semi-annual updates with its Government customer. (WBS 3.4.2)

3.1.5.5 The Offeror shall develop/produce/maintain a Technical Data Package (TDP) that accurately depicts the final product. The TDP shall be prepared to provide sufficient data to support the analysis of a specific design approach. Product data shall reflect the approved, tested, and accepted configuration of the defined delivered item. All engineering data, to include models and model-based definition data sets, created as a result of this contract shall be considered a part of the TDP. (MIL-STD-31000A) (WBS

3.4)

3.1.5.6 The Offeror shall provide textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. These documents shall define the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and the nature of the exchanges through use of DoDAF V2.0 compliant Operational View (OV), All View (AV), Capability View (CV), Systems/Services View (SV), Technical Standards Views (TV), and Services Viewpoint (SvcV). (WBS 3.4)

3.1.5.7 The Offeror shall support and co-chair an Engineering Data Guidance working group meeting for engineering data no later than 60 days after contract award. The working group meeting shall be convened at a site and on a date agreed upon by the Government contracting officer and the Offeror. The Offeror shall prepare an agenda and record the minutes of the Guidance working group meeting to be approved by the Government

PM. During the working group meeting the Offeror shall address, discuss, and provide status on the following:

a. Understanding of all CDRL requirements, applicable Data Item

Descriptions (DIDs), specifications and standards. TDP review requirements and schedules.

b. TDP delivery requirements and schedules.

c. Offeror’s drafting practices/procedures/TDP drawing formats.

d. The Offeror's quality assurance procedures relating to TDP documents, including quality control of proposed Team Member data.

e. The role of proposed Team Members who may deliver TDP documents under this contract.

f. The Offeror's configuration management system, including methods for releasing documents, approving documents, and incorporating changes into documents.

g. Digital TDP deliverables. (WBS 3.4.5)

Note: Engineering Data Guidance Working Group may be held in conjunction with other meetings or conferences.

3.1.5.8 The Offeror shall host, support, and co-chair an In-Process Review (IPR) of the engineering drawings and associated lists and other documentation to be included in the

TDP. The IPR shall be conducted only after the Offeror's quality assurance personnel have completely reviewed the data and determined that data are of sufficient quality that

Government time will be effectively utilized during the review. The Offeror shall notify the Government prior to the anticipated date of completion point. The Offeror shall provide the Government with drawings prior to IPR for review by the Government

Engineering Data Management Specialist (EDMS). The IPR shall focus on the

Offeror's progress in the preparation of the TDP. The Offeror shall support and provide the necessary resources (i.e., meeting agenda, conference room, applicable data, minutes, and appropriate personnel available to answer any questions) to perform the

IPR effectively. The Offeror shall correct all discrepancies identified in the IPR. All proposed Team Member data shall be made available for review. If the quantity of proposed Team Member data is of sufficient magnitude, the Government may schedule a separate IPR at the proposed Team Member’s facility. (WBS 3.4.5)

3.1.5.9 The Offeror shall levy on proposed Team Members/suppliers the same requirements for

TDPs as are levied on them by this contract. This requirement shall apply at all tiers of proposed Team Members associated with the program. (WBS 3.4)

3.1.5.10 The Offeror shall identify any hardware or software for which the Government will not or may not have full design rights due to constraints imposed by regulations or laws limiting the information the Offeror shall furnish because of proprietary or other source control considerations. Include alternatives and their cost, schedule and function impacts. (WBS 3.4)

3.1.5.11 The Offeror shall provide unlimited Data Rights for all data produced under this effort as per contract clause. The Offeror is required to notify the Government of any restrictions to rights requested under this effort by identifying the type of rights recommended (i.e. Limited Rights, Restricted Rights, etc.) and specify to which data the rights apply. (The marking of data as "Proprietary" is not authorized. The use of the appropriate terms for "Data Rights" that delineate the respective rights and obligations of the Government and the Offeror regarding the use, reproduction, and disclosure of that data shall be used.) The Government reserves the right to challenge the validity of such Limited Rights and Restricted Rights markings claims. (WBS 3.4.5)

3.1.5.12 The Contractor shall establish a cost-effective data management system and appropriate digital environment that shall allow every activity involved with the program to exchange data digitally throughout its total life cycle. The Integrated Digital

Environment (IDE) eRoom shall keep pace with evolving automation technologies to the maximum extent practicable. The Contractor shall provide controlled near-real time access to all data generated under this contract via an IDE eRoom to support the sharing of knowledge and information across functional boundaries throughout the life of the program. The IDE eRoom shall be accessible to authorized Government and associated support contractors. The IDE eRoom shall be available within 30 days of contract award. (WBS 3.4)

3.1.6 Product Support

3.1.6.1 The Offeror shall conduct quarterly Integrated Logistics Support Working Groups

(ILSWG), as required. Team Member participation may be required, as agreed to by the prime Offeror and the Government. Meetings may be held in conjunction with other meetings or conferences. (WBS 3.5.4)

3.1.6.2 During formal design reviews, the MC module shall be reviewed and assessed for supportability and supportability related design requirements. Design reviews shall identify and discuss all pertinent aspects of the Product Support Analysis (PSA) program. Typical design review topics include:

a. Product Support Analysis conducted by activity and engineering breakdown element.

b. Supportability assessment of proposed design features including support ability, cost, and readiness drivers and new or critical product support resource requirements.

c. Progress toward establishing or achieving supportability goals.

d. PSA documentation required, completed, and scheduled.

e. Design, schedule, or analysis problems affecting supportability.

f. Identification of supportability related design recommendations to include a description of the recommendation; whether or not it has been approved or is pending; rational for approval (e.g. cost savings, supply support reductions, reliability improvements, safety or health hazard reduction, and environmental risks). (WBS 3.5.4)

3.1.6.3 The Offeror shall participate in and support provisioning (to include conduct of required provisioning guidance conferences), logistics, and sustainment planning and documentation development activities. (WBS 3.5.4)

3.1.6.4 The Offeror shall conduct and provide a product support concept analysis. (WBS 3.5.4)

3.1.6.5 The Offeror shall describe, as part of the support concept, the approach to supporting

Integrated Logistic Support Elements across the MC life-cycle. (ref. AFI 63-101/20-

101, MIL-HDBK-502A) (WBS 3.5.4)

3.1.6.6 The Offeror shall preclude the need for any Common or Peculiar Support Equipment to support MC at the Organizational level. (WBS 3.5.1, 3.5.2)

3.1.6.7 The Offeror shall establish an Obsolescence and Diminishing Manufacturing Sources and Material Shortages (DMSMS) analysis process for identifying the loss, or impending loss, of manufacturers or suppliers of components, assemblies, sub-assemblies, piece parts and material required to produce, operate, and/or maintain the

MC module. At a minimum the analysis shall address the following:

a. Means and approach for providing the Government with information regarding obsolescence and DMSMS issues.

b. Planned resolution of current obsolescence and DMSMS issues.

c. Parts list screening and monitoring, including risk mitigation of counterfeit parts.

d. Processing GIDEP Alerts

e. Predictive analysis and resolution of obsolescence and DMSMS. (WBS 3.4.2, 3.5.4)

3.1.6.8 The Offeror shall establish a Parts, Materials and Processes Control Board (PMPCB) to coordinate and manage the program’s parts, materials and processes control program.

The PMPCB shall include a Government member or designated representative. (WBS

3.5.3)

3.1.6.9 The Offeror shall develop and implement a Counterfeit Prevention Plan (CPP) in compliance with SAE AS5553 to prevent the inclusion of counterfeit parts or parts imbedded with malicious logic into products intended for sale to the Government. As part of CPP, the Offeror shall provide Certificates of Conformance (CoC) as well as acquisition traceability for Original Component Manufacturers (OCMs) and franchised/distributors in the supply chain e.g. CoC and Traceability. As an alternative to a stand-alone CPP, the elements of DI-MISC-81832 may be included in the Program

Protection Plan (PPP). (WBS 3.3.1)

3.1.6.10 The Offeror shall develop and design MC Modules and support equipment to be logistically supportable. (WBS 3.5.1)

3.1.6.11 RESERVED

3.1.6.12 The Offeror shall establish a System Safety Program with the objective that all environment, safety, and occupational health (ESOH) risks be identified, that ESOH hazards be eliminated whenever possible, and that risks be effectively managed for

ESOH hazards that cannot be eliminated. The Offeror shall implement and comply with MIL-STD-882E. (WBS 3.3.3)

3.1.6.13 The Offeror shall establish a Failure Review Board (FRB) to review and adjudicate test and screening failures. The FRB shall include a Government member or designated representative. (WBS 3.5.3)

3.1.7 Training

3.1.7.1 The Offeror shall develop and deliver all required embedment products and materials necessary for the embedment of MC into a host system. (WBS 3.4)

3.1.7.2 The Offeror shall develop and deliver as part of the embedment guide to the

Government a MC interoperability specification guide to include all necessary information for non-MC embedded platforms to interoperate with MC host platforms.

(WBS 3.4)

3.1.7.3 The Offeror shall develop and deliver to the Government an Interface and Operator’s

Guide that includes all information required for product support (e.g. Operator’s

Interface, Security Features User Guide, etc.). (WBS 3.4)

3.2 LOW RATE INITIAL PRODUCTION (LRIP) OBJECTIVES

Seamless transition from EMD to LRIP should occur for appropriate/applicable activities and processes which began during the EMD phase and which must continue during LRIP. All

SCRM activities initiated earlier shall be carried forward throughout the life of the program.

They are not separately reiterated in this section of the SOO, but may be reiterated in the

Contractor’s Statement of Work (CSOW) as necessary.

3.2.1 Prime Mission Product (WBS 4.1)

3.2.1.1 The Offeror shall produce, configure, test, and deliver, MC modules based on an approved Product Baseline in accordance with Section B of this solicitation. (WBS 4.1)

3.2.1.2 The Offeror shall perform, participate, and support production acceptance testing on

MC assets. (WBS 4.1.2)

3.2.1.3 The Offeror shall perform First Article Qualification Testing on the first production unit to support the production readiness assessment for Full Rate Production and ensure that the Offeror can furnish a product that meets the established technical criteria. (WBS

4.1.2)

3.2.2 Operational Test and Evaluation (OT&E) (WBS 4.2)

3.2.2.1 The Offeror shall participate in and support ITT meetings for planning and execution of all remaining…