A02 NGLD-M Engineering Development PWS_FINAL.docx

PROCUREMENT SENSITIVE

Next Generation Load Device – Medium (NGLD-M) Engineering Development Task Order

Performance Work Statement

For

Next Generation Load Device-Medium (NGLD-M) Engineering Development

In support of U.S. Army Program Executive Office for Command, Control, Communications – Tactical (PEO C3T) Project Manager Tactical Radios (PM TR)

Table of Contents

1.0 General Information

1.1 Contracting Officer’s Representative (COR)

a. Primary COR.

Name:

Organization:

Department of Defense Activity Address Code (DODAAC):

(refer to the DODAAC web site at https://dodaac.wpafb.af.mil for additional information)

Phone Number:

Fax Number:

E-Mail Address:

b. Alternate COR.

Name:

Organization:

Phone Number:

Fax Number:

E-Mail Address:

2.0 Task Order Title

Next Generation Load Device-Medium (NGLD-M) Engineerng Development.

2.1 Mission Context

This will be a Performance Work Statement (PWS) under the base Multiple Award IDIQ contracts consisting of Cost-Plus Fixed-Fee (CPFF) for the development of the NGLD-M.

3.0 Background

Project Manager Tactical Radios (PM TR) currently provides a product and services that provide National Security Agency (NSA) certified Cryptographic Key Load Devices including the Simple Key Loader (SKL). These devices fill, transfer, issue, and manage cryptographic keys to End-Cryptographic Units (ECUs). In 2013, the Army signed a Capabilities Production Document (CPD) for the Next Generation Load Device (NGLD) Family to replace the aging fleet of SKL devices. Program Executive Office (PEO) Command, Control, Communicate – Tactical (C3T) is the Milestone Decision Authority (MDA) for the NGLD-Medium (NGLD-M) and has delegated execution authority to PM TR as an Acquisition Category III (ACAT III) Program of Record (POR).

The NGLD-M provides the functionality of legacy fill devices while providing network connectivity to support Over the Network Key (OTNK) distribution. The NGLD-M will meet NSA certification requirements while providing a reprogrammable crypto subcomponent to meet future modernization requirements. The NGLD-M will also be capable of interfacing with the Management Client (MGC), NSA’s Key Management Infrastructure (KMI), and specific Mission Planning Management Support Systems (MPMSS). The NGLD-M is a KMI aware and Product Delivery Enclave-Enabled (PDE-Enabled) device capable of connecting and receiving key material, applications, and other cryptographic products necessary to complete required operational missions. Key distribution should be accomplished by connection to DoD networks and will contain standard interfaces including a audio fill ports, RJ45 Ethernet ports, and standard Universal Serial Bus (USB).

The NGLD-M shall be engineered, designed, tested, and certified to meet specific Army and customer requirements. These requirements are based on the 22 April 2013 Capabilities Production Document (CPD) as signed by the TRADOC Capability Manager Networks and Services (TCM N&S) and include production quantities based on the needs of the Army. Additionally, requirements from the National Security Agency (NSA) including the Technical Security Requirement Document (TSRD) and Information Assurance Security Requirements Document (IASRD), as well as others from other services including the Navy, Air Force, Other Government Agencies (OGA), and foreign military sales. OGAs include the Federal Bureau of Investigation (FBI), Department of Homeland Security (DHS), and state/local entities. The Army is the executing agent of this effort, but other participants mentioned above will be key stakeholders in the requirements generation, management, and test planning and execution.

Concurrently with the NGLD-M platform development, the government is developing NGLD-M User Application Software (UAS) through a separate effort. The contractor is encouraged to use the Government developed UAS, however, the contract has the option to develop their own UAS for the NGLD-M..

If the contractor does not opt to use the government developed UAS, the contractor will develop the NGLD-M in its entirety to include hardware, underlying software (e.g. OS, firmware etc.), and the UAS as defined in the NGLD-M requirements documents. The NGLD-M System Requirements traceability matrix allocates each requirement to either UAS, Hardware or both.

If the contractor opts to use the government developed UAS, the government will define UAS API(s) that contractor(s) shall integrate with the NGLD-M platform under multiple IDIQ contract. The contractor shall design the NGLD-M to meet the hardware requirements including underlying software (e.g. OS, firmware etc.) and integrate the government developed UAS with the contractor developed NGLD-M platform.

The REprogrammable Single Chip Universal Encryptor (RESCUE) TDP is available to industry offerors as an option to meet the crypto subcomponent requirements for the NGLD-M platform, but the Government is not requiring the use of the RESCUE. The government is not responsible for any modifications required to RESCUE to meet the NGLD-M crypto subcomponent requirements.

4.0 Objectives

The objective of this TO is the development of the NGLD-M through the DoD Systems Engineering process and completing with NSA certification, required testing, an Authority to Operate (ATO), support package development, and pre-production units (PPU). This TO includes requirements definition starting from a Government furnished Software Requirements Document (SRD) which shall be used to develop detailed, build specifications for the NGLD-M, NGLD-M UAS/hardware interface, and managed through preliminary (if required) and critical design reviews. Participation in a Government developmental/operational test events will be required utilizing Low-Rate Initial Production (LRIP) items.

5.0 Scope

The scope of this TO is to provide the development of the NGLD-M up to and including all Engineering, Testing, support elements, and certification of the NGLD-M including the Engineering Design Models (EDMs) and Pre-Production Units (PPUs). Any references to NGLD-M throughout the remainder of the documents refers to the NGLD-M hardware and UAS/hardware interface. Other requirements include but not limited to the following:

· Engineering Support Services

· Developmental Testing and Test Support

· Technical Data Package

· Provisioning and Parts Lists

· Operation and Maintenance Manuals

· New Equipment Training (NET) Package

· User and Maintenance Training

· Quality Assurance/Quality Control

· Information Assurance (IA)

· NSA Certification

· Engineering Development Models (EDMs)

· Pre-Production Units (PPUs)

· First Article Testing (FAT)

· Operational Test (OT) Support

· Safety Assessment

· Support Equipment

5.1 Applicability

This TO effort is within scope of the NGLD-M multiple Indefinite Delivery Indefinite Quantity (IDIQ) contracts.

5.2 Applicable Documents

Applicable documents are cited throughout this TO. All Data Items Descriptions (DIDs) and other necessary documents relevant to the performance of this contract are cited in this TO. The most current version of documents at the time of the TO or DO issuance will take precedence.

Table 1 - References

Reference Item

NGLD Family of Devices Capabilities Production Document (CPD)

Reference Item

Technical Security Requirement Document (TSRD)

Reference Item

NGLD-M System Requirements Document (SRD)

Reference Item

Level of Repair Analysis (LORA) Input Data Spreadsheet

Reference Item

Key and Certificate Management Plan (KCMP) Template

Reference Item

DRAFT Memorandum of Agreement (MOA) between the NSA and PEO C3T/PL Net E Concerning the NGLD-M Under the User Partnership Agreement (UPA)

Reference Item

Reprogrammable Single Chip Universal Encryptor (RESCUE) TDP

Reference Item

Incentive Calculation Worksheet

Reference Item

Technical Security Requirement Document (TSRD) (provided via NSA)

Reference Item

Information Assurance Security Requirement Document (IASRD) (provided via NSA)

https://armypubs.army.mil/

https://armypubs.army.mil/

https://armypubs.army.mil/

https://armypubs.army.mil/

https://armypubs.army.mil/

The Government reserves the right to add items not originally listed. Contract Data Requirements Listing (CDRL) will be provided as exhibits (DD 1423s). For instances where a format is not specified, the contractor shall propose a method or standard for Government approval.

6.0 Performance Requirements & Milestones

The requirements under this TO shall be separated into five (5) tasks:

· Task One Engineering, NSA Certification Preparation, and Technical Data

· Task Two: Engineering Reviews

· Task Three: Prototype Delivery including EDM, PPU

· Task Four: Test including but not limited to Developmental Test, NSA Certification, FAT, and OT Support Test Support Products

· Task Five: Product Support Each task is anticipated to contain specific deliverables and requirements as outlined in this TO but does not indicate that each task must be complete prior to the execution of the following phases. More than one task may occur at any point during the performance of this task order.

NGLD-M TASK ORDER MILESTONES

Table 2 defines the major milestones estimate that apply throughout the PoP.

Table 2 NGLD-M Milestones

6.1 Task 1 – Engineering, NSA Certification Preparation, and Technical Data

The contractor shall develop the NGLD-M using standard DoD System Engineering practices and shall also meet specific requirements outlined in this TO and the SRD. The NGLD-M System Engineering process must result in the completion of the NGLD-M PPU prototypes that successfully obtain NSA certification.

The contractor shall develop the NGLD-M in accordance with (IAW) the NGLD-M SRD, derived from the NGLD CPD. Design requirements shall be derived in subsequent lower-level documents including, but not limited to: Software Hardware Requirements Specifications (SHRS), Interface Requirements Specification (IRS), and the System Subsystem Specification (SSS). The contactor shall document and gain Government approval for the verification and validation methods for the requirements in the SSS. Additional testing to verify SHRS and IRS requirements shall be proposed by the contractor. The contractor shall define the NGLD-M UAS/hardware interface requirements for the NGLD-M

The contractor shall conduct a System Requirements Review (SRR) outlining the NGLD-M functional baseline as defined by the Government and further expanded as design concept by the contractor.

Upon final submittal of the SSS documents, the contractor shall conduct a Preliminary Design Review (PDR) outlining allocation of the specific requirements defined in the SRD, NSA TSRD, Risk Management Framework (RMF) Technical Controls, and NSA IASRD. In addition, the contractor shall support a Risk-Assessment Panel #1 (RAP) to outline the design concepts for the NGLD-M and its connectivity to required networks and systems.

The design effort shall culminate in submission of documentation in support of a Critical Design Review (CDR) outlining the final design of the NGLD-M. Prior to the conduct of the CDR, the contractor shall support RAP #2 to finalize design plans and concepts prior to review and test by the NSA. During this phase, the contractor shall execute tests as required to prove the ability of the system to meet requirements outlined in the SHRS requirements using below system-level components, models, and sub-systems as proposed by the contract. In addition the contractor shall support a final RAP #3.

6.1.1 Quality Assurance

The contractor shall maintain a quality assurance program for the supplies and services provided that meets or exceeds the requirements of the Aerospace Standard (AS9100 Rev D) Quality Management Systems-Requirements for Aviation, Space, and Defense Organizations and the International Organization for Standardization (ISO 9001:2015) quality system or a Quality Assurance Single Process Initiative that has been approved by the Defense Contract Management Agency.

The contractor shall also maintain a supplier quality assurance program that meets or exceeds the AS9100 Rev D and ISO 9001:2015 that assures the supplier focuses on the prevention and detection of discrepancies to assure delivered hardware and software satisfies the performance requirements of the program.

Quality Assurance and Inspection shall be in accordance with Federal Acquisition Regulation (FAR) 52.246-1 Contractor Inspection Requirements, and FAR 52.246-2 Inspection of Supplies. The Contractor shall maintain a corrective action and disposition system for nonconforming material.

The contractor shall be at minimum Capability Maturity Model Integration (CMMI) Level 3 certified for software development.

6.1.2 Configuration Control and Engineering Documentation Information The contractor shall conduct Configuration Control Board (CCB) meetings, as required for significant configuration changes. During the CCB meeting, the contractor shall provide the required documentation for Government review and approval prior changing the product baseline. Configuration Control and Management is referenced in the Management TO paragraph 6.1.8 along with the required deliverable DI-SESS-81875.

The contractor shall provide engineering documentation clearly documenting a repeatable, producible design of the NGLD-M. The contractor shall manage the configuration of design documentation IAW the Configuration Management Plan and follow IEEE 828-2012 - IEEE Standard for Configuration Management in Systems and Software Engineering. The engineering documentation information shall include four (4) parts:

6.1.2.1 Documentation Description Record (DDR)

The contractor shall prepare one (1) DDR for each drawing (assembly, subassembly, or part), standard, or other documents used in the fabrication or maintenance of the equipment.

6.1.2.2 Part Description Record

The contractor shall prepare one (1) Part Description Record for each assembly or part excluding any reference documentation. The record shall be prepared for reference documents.

6.1.2.3 Structure Record

The contractor shall prepare one (1) Structure Record for each application of each item used in the fabrication, operation, or maintenance of the equipment.

6.1.2.4 Manufacture’s Description Record (MDR)

The contractor shall prepare at least one (1) MDR for any part or assembly that is an altered item (TYPDWG-A in the DDR), selected item (TYPDWG-V in the DDR), source control (TYPDWG-S in the DDR), or a specification control item (TYPDWG-C in the DDR). Additionally, an MDR shall be prepared for any part or assembly that is a design control repair part (TYPDWG-D in the DDR) that has a suggested source of supply.

6.1.3 Collaboration Environment

The contractor shall establish a collaboration environment with the Government in order to share documents, codes IAW the NSA User Partnership Agreement (UPA) development environment requirements. The contractor shall receive government approval prior to implementation of the environment. If the contractor opts to use the Government developed UAS, the contractor shall be the lead document integrator for systems engineering deliverables accepting inputs from the Government concerning the UAS.

6.1.4 System/Subsystem Specification (SSS)

The contractor shall develop a System/Subsystem Specification (SSS) specifying and allocating requirements to system or subsystem and document the verification methods for each requirement. The contractor shall identify the following verification methods for each requirement: analysis, inspection, demonstration, or test. The SSS is the highest level requirements document that can either be developed as a complete, independent/stand-alone data item or it may reference and be supplemented by various IRSs, ICDs, Interface Design Document (IDDs) and other System Engineering documents. The contractor shall maintain the SSS current requirements and design updates that have been approved from the allocated baseline.

Deliverable: System/Subsystem Specification (DI-IPSC-81431A), CDRL (J001).

6.1.5 Software/Hardware Requirement Specification (SHRS)

The contractor shall develop a Software/Hardware Requirements Specification (SHRS) that outlines the physical definition of the NGLD-M system and is fully traceable to the SSS, SRD, CPD, and other relevant requirements (i.e. IASRD, TSRD, RMF, and IRS. Design constrains shall be identified, validated, and approach agreed upon between contractor and the Government, specifically the program office and NSA by the completion of the CDR. The contractor shall work with the NSA to deliver the SHRS in a form that is acceptable by the Government.

The contractor shall utilize an unlocked Microsoft Office Excel 2013 or later flat-file spreadsheet where sorting and filtering is possible. The contractor shall meet CDRL, Software Requirement Specification/System Subsystem Specification. Sub Title: Software/Hardware Requirement Specification (SHRS).

Deliverable: Software/Hardware Requirements Specification (SHRS) (DI-IPSC-82259, CDRL (J002)

6.1.6 Risk Management Framework (RMF) Requirements Derivation The contractor shall implement cybersecurity risk management guidance IAW DODI 8510.01 for the NGLD-M development. The contractor shall derive SHRS requirements specific to RMF controls. These requirements should be traceable to NIST SP-800-53, Risk Management Framework Controls. If any controls are not achievable within cost, schedule, and performance requirements, the contractor shall present these concerns to the Government for mitigation and provide rationale for each deviation/waiver through an RMF/Security Working Group meeting scheduled by the Government after contract award.

6.1.7 Software Development Process Description Document

The contractor shall document the development, modification, and management of software development processes, standards, and practices.

Deliverable: Software Development Process Description Document (SDPDD), (DI-IPSC-82208), CDRL (J003).

6.1.8 Software/Hardware Design Description (SHDD) & System/Subsystem Design Description (SSDD) The contractor shall deliver a SSDD and SHDD IAW with the CDRLs below. The contractor shall maintain the SSDD and SHDD documents for the duration of the contract.

Deliverable: System/Subsystem Design Description (SSDD) (DI-IPSC-81432A), CDRL (J004) Software/Hardware Design Description (SHDD) (DI-IPSC-82284), CDRL (J005)

6.1.9 Security Evaluation Document

The contractor shall provide a Security Evaluation Document (SED) that provides information about the architectural design of an IA product and its intended detailed implementation throughout the development/design of the NGLD-M. The SED supports NSA evaluations to ensure that system security requirements are met and is a culmination of several distinct but overlapping areas: Theory of Design and Operation (TDO), Theory of Compliance (TOC) of the security requirements, Fail-Safe Design Analysis (FSDA), QUADRANT design, and Covert Channel Analysis (CCA).

Deliverable: Security Evaluation Document (SED) (DI-MISC-81762A), CDRL (G003).

6.1.10 Interface Requirements Specification (IRS)

The contractor shall develop and maintain an IRS through system engineering cycle, culminating in final delivery based on the approved product baseline design. IRS specifies the requirements imposed on one or more systems, subsystems, Hardware Configuration Items (HWCIs), Computer Software Configuration Items (CSCIs), manual operations, external interfaces, or other system components to achieve one or more interfaces among these entities. This document can be used as a supplement to the SHRS.

Deliverable: Interface Requirements Specification (DI-IPSC-81434A), CDRL (J006)

6.1.11 Interface Design Description (IDD)

The contractor shall develop and maintain an IDD describing the interface characteristics of one or more systems, subsystems, Hardware Configuration Items (HWCIs), Computer Software Configuration Items (CSCIs), manual operations, or other system components. An IDD may describe a number of interfaces. This document may be used as a supplement to the SHDD.

The contractor shall maintain the IDD current requirements and any design updates that have been approved by the Government from the physical baseline.

Deliverable: Interface Design Description (DI-IPSC-81436A), CDRL (J007))

6.1.11.1 Interface Control Document (ICD)

The contractor shall develop and maintain an Interface Control Document (ICD) providing a record of all interface information such as drawings, diagrams, tables, and textual information generated for the NGLD-M program. It also provides access to, or delivery of, copies of the actual interface information.

The contractor shall maintain the ICD current requirements and any design updates that have been approved by the Government from the physical.

Deliverable: Interface Control Document (DI-SESS-81248B), CDRL (M003)

6.1.12 Highly Accelerated Life Testing (HALT) (Reliability Testing) The contractor shall plan, organize, and manage Highly Accelerated Life Testing (HALT) for the NGLD-M design. The contractor shall design the test to identify design weaknesses and verify that the product meets environment requirements. The contractor shall conduct the HALT using non-certified EDMs to support reliability growth estimates prior to conducting tests on end-items. HALT is implemented in lieu of legacy Reliability Development Testing (RDT) as a design verification tool to quickly detect and correct design flaws and unexpected parametric variations that might otherwise be exhibited as field failures and warranty problems. Due to accelerated environments, demonstration of specified reliability values is not a primary objective; rather, the test is designed to make informed design decision in support of a system that meets CPD and SRD requirements. The NGLD-M HALT testing shall consist of the following phases to be defined within the test plan as agreed upon with the Government: Temperature Step Stress, Rapid Temperature Transitions, Vibration Step Stress, and Combined Environment.

Deliverable: Test/Inspection Report (DI-NDTI-80809B), CDRL (H001).

Test and Inspection Plan (DI-MGMT-82062), CDRL (E016)

6.1.13 Reliability Prediction and Documentation of Supporting Data The contractor shall provide a reliability prediction document report that indicates qualitative predictions of NGLD-M reliability. The report is intended as support for feasibility evaluations, compare alternative configurations, identification of potential problems, logistics support planning, life-cycle cost studies, determination of data deficiencies, tradeoff decisions, allocation (apportionment) or performance requirements, and criteria for reliability growth or demonstration testing.

Deliverable: Reliability and Maintainability Predictions Report (DID DI-SESS-81497B), CDRL (M004).

6.1.14 INFOSEC Anonymity Plan

The contractor shall prepare and deliver INFOSEC Anonymity Plan. The contractor shall ensure that the acquisition of equipment, software, components, and parts are anonymous when acquired from outside of the United States. The contractor shall describe the methods employed to maintain anonymity.

Deliverable: Information Systems Security (INFOSEC) Anonymity Plan (IAP) (DI-MGMT-81717D), CDRL (E017)

6.1.15 Risk Management Framework (RMF)

The contractor shall provide the required documentation to support the Government’s submission for a network ATO IAW DODI 8510.01 DoD Risk Management Framework for IT. The documentation will be reviewed by the US Army’s Network Command (NETCOM), Authorizing Officer (AO) approval within PEO C3T, and any other required approval authorities. The NGLD-M is categorized as Confidentiality, Integrity, and Availability, “High, High, High.”

Deliverable: Risk Management Framework (RMF) DI-MGMT-82001A CDRL (E018)

6.1.16 In-Process Accounting Procedures Plan

The contractor shall develop and maintain the In-Process Accounting Procedures Plan IAW DoD 5220.22-S - COMSEC Supplement to Industrial Security Manual. This plan permits the Government to determine the adequacy of the In-Process Accounting Procedures proposed by the contractor for the control of COMSEC material.

Deliverable: In-Process Accounting Procedure Plan (DI-QCIC-81691A), CDRL (K001)

6.1.17 Software and Programmable Logic Evaluation Report (SPLER) The contractor shall prepare and submit Software and Programmable Logic Evaluation Report (SPLER) as described in TSRD. Pre-Report Activities that take place after CDR, on a monthly basis up to the PPU SVT, the contractor shall analyze their developed software (built-to date), using static and dynamic analysis tools. The contactor shall record and maintain the results. The contract shall provide analysis results to the Government for informal review at the contractor’s facility or via remote access.

At the completion of SVT and Physical Configuration Audit (PCA), the contractor shall deliver the as-built Source and Executable Software Code (including source code notations) IAW Software Product Specification (SPS) that represent the final signed-software. The contractor shall make available all source code that is used for the generation of the product to the Government in support of NSA certification.

Deliverable: Software and Programmable Logic Evaluation Report (SPLER) (DI-IPSC-90162), CDRL (J013)

6.1.18 Security Production Assurance Description

The contractor shall prepare and implement a Security Production Assurance (SPA) program that ensures the security integrity of the product/system through manufacturing and maintenance. The SPA shall address both the Physical Configuration and the Functional Performance of the product/system, and the SPA shall consider the complete manufacturing process, including subcontracted portions, if any, The SPA shall also identify the essential hardware, software, and programmable logic security checkpoints, making reference to the contractor's documents that provide the criteria for inspection and test which validate and protect the security integrity of the product/system. The contractor shall maintain the SPA in a current status to ensure continued approval for use of the product/system.

Deliverable: Quality Program Plan (QPP) (DI-QCIC-81722) CDRL (K002),

6.1.19 Software Product Specification (SPS)

The contractor shall develop and maintain a Software Product Specification (SPS). The SPS contains the executable software, source files, and software support information, including the “as built” design information and compilation, build, and modification procedures, for a CSCI. The contractor shall deliver the as-built Source and Executable Software Code (all source code that is used for the generation of the product shall be made available to the Government) with instructions that represent the final signed-software. All supporting data required to compile, build and install the software into the final configurations shall also be included.

Deliverable: Software Product Specification (SPS) (DI-IPSC-81441A), CDRL (J008)

6.1.20 Software Version Description

The contractor shall develop and maintain a Software Version Description (SVD). The SVD identifies and describes a software version consisting of one or more CSCIs. It is used to release, track, and control software versions.

Deliverable: Software Version Description (DI-IPSC-81442A), CDRL (J009).

6.1.21 Key and Certificate Management Plan (KCMP)

The contractor shall develop and maintain a Key and Certificate Management Plan (KCMP) as a technical report. The KCMP provides the “as to be designed and developed” product framework to accept the key and certificate material produced by the infrastructure. The KCMP also includes the annexes for key/certificate specifications. The KCMP shall include any new KCS as an annex.

Deliverable: Key and Certificate Management Plan (KCMP) (DI-MISC-81688A), CDRL (G004)

6.1.22 TDP Standards and Best Practices

The contractor shall develop a production level TDP IAW DoD adopted ASME industry standards Y14.1, Y14.5, Y14.24, Y14.34, Y14.35, Y14.38, Y14.41, Y14.100 as outlined in MIL-STD-31000. Contractor’s CAD solid modeling software application is acceptable. Government’s preference is PTC’s Pro/Engineer CAD modeling software. Version of CAD modeling software used for CAD data delivery will be agreed upon at the Kick-Off Meeting. The contractor shall verify that the TDP opens without errors before each delivery.

Deliverable: Technical Data Package (TDP); DI-SESS-80776B; CDRL (M005)

6.1.23 Product Drawings/Models and Associated Lists

Product Drawings/Models and Associated Lists provide engineering data to support competitive procurement and maintenance for items interchangeable with the original items. The data represents the highest level of design disclosure.

All contractor Product Drawings/Models and Associated Lists shall meet the requirements of MIL-DTL-31000C. The Product Drawings/Models and Associated Lists shall provide the design disclosure information necessary to enable a manufacturer of similar products at the same or similar state of art to produce and maintain quality control of item(s) so that the resulting physical and functional characteristics duplicate those of the specified item. The drawings shall (a) reflect the end product at its current level of design maturity, (b) Provide the engineering data for Logistics Support products, and (c) provide the necessary data to permit competitive acquisition of the original item(s).

Deliverable: Product Drawings/Models and Associated Lists (DI-SESS-81000F, CDRL (M006)

6.1.23.1 Special Tooling (ST) Drawings/Models and Associated Lists The contractor shall review the list of approved Army tools located at the https://www.aesip.army.mil/irj/portal and ensure that Army approved tools are required to conduct operation and maintenance of the system prior to introducing a new tool to Army inventory.

Should special tools be required, the contractor shall develop the Special Tooling (ST) Drawings/Models and Associated lists for the NGLD-M and the NGLD-M test units. The Special Tooling (ST) Drawings/Models and Associated Lists provide the data required for the limited production of ST which duplicates the physical and performance characteristics of the original ST.

Deliverable: Special Tooling Drawings/Models and Associated Lists (DI-SESS-81008F), CDRL (M007).

6.1.23.2 Special Inspection Equipment (SIE) Drawings/Models and Associated Lists The contractor shall avoid the use of Special Inspection Equipment (SIE); however, if required, the contractor shall develop the Special Inspection Equipment Drawings/Models and Associated Lists for the NGLD-M and the NGLD-M test units. The SIE Drawings/Models and Associated Lists provide the data required for the limited production of SIE which duplicates the physical and performance characteristics of the original SIE.

Deliverable: Special Inspection Equipment (SIE) Drawings/Models and Associated Lists (DI-SESS-81004F), CDRL (M008).

6.2 Task 2 Engineering Reviews

Proposed development and engineering reviews is presented in the Table 2 of this TO.

6.2.1 System Requirements Review (SRR)

The System Requirements Review (SRR) will assess whether the contractor has an adequate understanding of the system requirements as captured in the SRD and allow the contractor to ask questions and provide feedback to the document. Additionally, the contractor shall propose Technical Performance Measures (TPMs) for Government review, approval, and future programmatic tracking. At a minimum, volumetric size and Average Procurement Unit Cost (APUC) must be used. Any changes to the SRD will be captured and redistributed by the Government as a subsequent document version after the conclusion of the meeting. Some exit criteria consideration will include a review of the SRD requirements against the proposed concept to include the following:

· Can the system requirements, as disclosed, satisfy the SRD?

· Are the system requirements sufficiently detailed and understood to enable system functional definition, functional decomposition, test and evaluation?

· Can the requirements be met given the technology maturation achieved?

· Is there an approved system performance specification?

· Are adequate processes and metrics in place for the program to succeed?

· Have Human Systems Integration and sustainment requirements been reviewed and included in the overall system design?

· Are the risks known and manageable for development?

· Is the program schedule executable (technical and/or cost risks)?

· Is the program properly staffed?

· Is the program executable within the existing budget?

· Does the updated cost estimate fit within the existing budget?

· Is the software functionality in the system specification consistent with the software sizing estimates and the resource-loaded schedule?

· Did the Technology Development phase sufficiently mature all system elements to enable low risk entry into engineering and manufacturing development?

· Did the Technology Development phase sufficiently mature the critical sustainment enablers technologies required to implement the support strategy and achieve the needed materiel availability?

· Are the preliminary software development estimates established with effort, schedule, and cost analysis?

· Have programming languages and architectures, security requirements and operational and support concepts been identified?

· Have hazards been reviewed and mitigating courses of action been allocated within the overall system design?

The Government will approve the responses to the above questions and establish the functional baseline for the NGLD-M. Upon completion of the SRR, the contractor shall provide the following:

· Risk Assessment for EDM

· Systems Engineering Management Plan (SEMP) Deliverable: System Engineering Management Plan (SEMP) (DI-SESS-81785A), CDRL (M009)

6.2.2 Preliminary Design Review (PDR)

The contractor shall prepare for and present a formal Preliminary Design Review (PDR). The review shall include information from both hardware and software disciplines in order to establish system compatibility of the design approach. The preliminary Software Hardware Requirements Specification (SHRS) and Software Hardware Design Description (SHDD), among other requirements and reports will be used as the basis for the review. The PDR shall include the following:

· Integrity of the selected design approach

· Establishment of an allocated baseline to enable detailed design to proceed with proper configuration management

· Review of the program schedule

· Detail review of the reliability and maintainability of the design

· System compatibility review comparing the interface documentation to the engineering drawings for the equipment

· A risk assessment of the selected design shall be conducted. Specific risks, if any, shall be identified and analyzed to determine the impact to the program and corresponding mitigation plans The contractor shall document the PDR results in the Conference Minutes. As required, the contractor shall incorporate changes to the detail design into the final design and requirements documentation.

6.2.3 Critical Design Review (CDR)

The contractor shall prepare for and present a formal CDR. The CDR shall be held upon completion of the detailed design phase in order to ensure the design satisfies the performance requirements established by delivered requirements and specifications. The SHDD shall be used as the basis for the review and shall include the following:

· Review of the TDP against the finalized requirements

· Review of the program schedule

· Establishment of the initial Product Baseline

· Detailed review of the reliability and maintainability of the design

· A risk assessment of the detail design shall be conducted. Specific risks, if any, shall be identified and analyzed to determine the impact to the program and corresponding mitigation plans

· An update to initial production cost targets shall be presented so as to reflect the most recent component technology and market pricing that may become available in the commercial sector Upon successful completion of the CDR, the government accepts the proposed design submitted by the contractor

Deliverable: Assessment of Manufacturing Risk and Readiness (DI-SESS-81974, CDRL (M010)

6.2.4 Risk Assessment Panel (RAPs #1 #2 #3)

Following SRR, the contractor shall support an initial Risk-Assessment Panel #1 (RAP #1) to outline the security design concepts for the NGLD-M and its connectivity to required networks and systems. Prior to the conduct of the CDR, the contractor shall support the second RAP #2 to finalize security design plans and concepts prior to review and test by the NSA. During this phase, the contractor shall execute tests as required to prove the ability of the system to meet requirements outlined in the SHRS. Following CDR, the contractor shall support the third RAP #3 and deliver all required artifacts necessary for NSA certification.

6.2.5 Physical Configuration Audit (PCA) Plan and Report

The PCA is a requirement to compare the final, produced PPUs against the TDP. The contractor shall submit a PCA Plan to include custom hardware and software/firmware/hardware description language (HDL), as applicable, describing when and how the initial PCA shall be conducted. The PCA Plan must be approved by the Government prior to the actual performance of the PCA. The PCA validates the executable software/firmware/HDL file(s) and verifies the accuracy of the “as-built” configuration of the PPUs against the technical documentation package. All base line changes required, as a result of the PCA, shall have been incorporated prior to both Government approval and program office approval of the PCA report. Subsequent to the successful completion of the PCA required for certification, the executable custom software/firmware/HDL file(s), the INFOSEC boundary custom engineering drawings and the Configuration Item (CI) database shall be baselined at CDR. Once baselined, the contractor shall propose all changes to the Government for approval. Formats are per Physical Configuration Audit Plan and Report, and Configuration Audit Summary Report and Certification.

Deliverable: Physical Configuration Audit Plan (DI-SESS-81646C), CDRL (M011) Physical Configuration Audit Summary Report and Certification (DI-SESS-81022E), CDRL (M012)

6.2.6 Production Readiness Review (PRR)

The contractor shall conduct a Production Readiness Review (PRR) in support of the Government’s decision to enter into LRIP phase. The contractor shall, at minimum, present the following at PRR:

· The manufacturing readiness process

· Quality management system

· Production planning

· System requirements compliance

· Inventory management

· Supplier management

· NSA certification achieved

· Logistics Material (i.e. Training, validation of manuals, support strategy established) A successful review is predicated on the determination that the system requirements are fully met in the final production configuration and that production capability forms a satisfactory basis for proceeding into Low-Rate Initial Production (LRIP).

6.3 Task 3 - Prototype Delivery

6.3 Task 3 Prototypes

The contractor shall deliver Engineering Development Models (EDMs) in accordance with the CDR NGLD-M design. The design will then be tested IAW the SSS verification limited to Highly-Accelerated Life Test (HALT) in support of reliability growth, NSA certification testing, and tests required to verify functionality of the system against the SRD.. Any design deficiencies discovered during this phase shall be mitigated and updates to the technical data package shall be conducted. Based on the TDP, the contractor shall produce Pre-Production Units (PPUs) in support of final integration testing and NSA certification.

6.3.1 Non-Certified Engineering Development Models (EDM)

The contractor shall produce thirty (30) NGLD-M (EDMs) systems and associated accessories. These prototype systems will be used for system integration, environmental testing, EMI testing, functional testing, early TEMPEST evaluations, and ECU interoperability testing. EDMs will be non-certified systems and not production representative. Five (5) of the thirty (30) NGLD-M prototype systems and associated accessories will be delivered to the Government for evaluation purposes and shall be maintained as the NGLD-M development baseline. The remaining twenty-five (25) prototype systems shall be identified as GFE to the contractor. The contractor shall use form DD1428 for delivery of these items.

6.3.2 Certified Pre-Production Units (PPU)

The contractor shall produce forty…