Attachment_1_PGS_Statement_of_Work_V1.pdf

DISTRIBUTION LIST STATEMENT D:

Distribution Authorized to DoD and U.S. DoD Contractors.

Statement of Work For

Prompt Gamma Simulator for White Sands Missile Range Nuclear Effects Laboratory (NEL)

Survivability, Vulnerability and Assessment Directorate

U.S. Army Program Executive Office for

Simulation, Training, and Instrumentation (PEO STRI) 12350 Research Parkway Orlando, FL 32826-3276

Engineering Prepared By: ____________________ Concurrence: ____________________ Erick Serrano, PE Derek Vick Systems Engineer, IMO Chief Engineer, PM ITTS IMO Date: _________ Date: _________

Acquisition Logistics Prepared By: ____________________ Glenn Daens Lead Acquisition Logistician, PM ITTS IMO Date: __________

Program Management Submitted By: ___________________ Approved By: ____________________ Bobby Arora Minh Vuong Assistant Project Manager, PM ITTS IMO Director, PM ITTS IMO Date: __________ Date: __________

AroraB Typewritten Text 12 Jan 2017

AroraB Typewritten Text

PlattK Typewritten Text

12JAN17

DaensG Typewritten Text 12 Jan 17

PEO-STRI-15-W001

W900KK-17-R-0003

11 January 2017

Statement of Work (SOW) Revisions

Revision Number Date Log of Changes Made and Description of

Reason Changes Approved By

1.8 28 Sep 16 Changed PEO STRI address in Section 2.8 Bob Arora

1.9 17 Nov 16 Section 3.6, Add fourth sentence to third paragraph. Erick Serrano

1.10 20 Dec 16 Added Section 3.3.2 – Government Data Acquisition System Erick Serrano

1.11 3 Jan

- Revise Section 3.7.2, Paragraph E.

- Appendix A, IRR Section, A.10 IRR Entry Criteria: Revise last sentence in paragraph

Erick Serrano

1.12 11 Jan

To Address Solicitation Review Board (SRB) Comments Prior to Final RFP Issue:

-Revise Section 3.2.5 to Integrated Digital Environment.

-Revise Title of Section 3.3 to: Building Facility Infrastructure and Data Acquisition System -Add (3) additional CDRLs to Section 3.6.11 System Safety Tasks to provide a more robust Safety Program and safety requirements per DODI 5000.02 and AR 385-10 for further Safety Requirements.

-Added to Section 3.6.13 contractor compliance as implemented by Homeland Security Presidential Directive-12 (HSPD- 12), Office of Management and Budget (OMB) guidance M-05-24, and Federal Information Processing Standards Publication (FIPS PUB) Number 201 as included in the FAR Reference 52.204-9.

-Revised Appendix A, A.1.b (7) – the word SEP to SEMP.

-Add to Section 3.6.7: Requirement for Contractor to provide executable and compiled files and CDRL (DI-IPSC-81441A)

SOFTWARE PRODUCT SPECIFICATION

(SPS)

-Add to Section 2.4: DOD Instruction 5000.02 -Add to Section 2.6: Army Regulation 385-

- Section 3.6.3, 3.6.4, 3.6.9, 3.6.9.1, 3.6.9.2, 3.6.9.3: Delete DRIP CDRL. CDRL Submittal requirements of artifacts are included in their respective CDRLs.

- Section 3.6.10: Add new CDRL requirement to the Product Definition Data

(PDD): SYSTEM/SUBSYSTEM DESIGN

DESCRIPTION (SSDD) (DI-IPSC-81432A)

Erick Serrano

- CDRL A011 has been revised from DRIP (Design Review Information Package) to System/Subsystem Design Description

(SSDD) (DI-IPSC-81432A).

- Section 3.7.5: Delete CDRLs to avoid confusion. The submittal requirement for the PDD still exists, but to avoid SOW/CDRL confusion, the respective CDRLs identify the submission requirements.

- CDRL Revisions: 1. Added the Contract Line Item to all CDRLs, 2. New CDRLs created as part of SOW Revision, 3.

Revision of CDRLs

- Section 3.2.3 Risk Management: Added Sentence that Government representatives shall be participants in the Risk Management process.

Table of Contents

1. Scope

1.1 Background

2. Applicable Documents

2.1 DOD Specifications

2.2 DOD Standards

2.3 Availability of DOD Standards

2.4 Department of Defense Instructions (DoDIs)

2.5 Availability of DoDIs

2.6 Department of Defense Directives

2.7 Other Government Documents, Drawings, and Publications

2.8 Availability of Other Government Documents and Publications

3. Requirements

3.1 General

3.2 Program Management

3.2.1 Integrated Master Schedule (IMS)

3.2.2 Financial Management

3.2.3 Risk Management

3.2.4 Quality Control

3.2.5 Integrated Digital Environment

3.2.6 Management Reviews

3.2.6.1 Post Award Conference (PAC)

3.2.6.2 Start of Work Meeting

3.2.6.3 Program Management Reviews

3.2.6.4 Technical Interchange Meetings (TIMs)

3.3 Building Facility Infrastructure and Data Acquisition System

3.3.1 Building Facility Infrastructure

3.3.1.1 PGS System and Building Facility Infrastructure Coordination

3.3.2 Data Acquisition System

3.4 Risk Management Framework (RMF) Process

3.5 Systems Security Engineering – Program Protection Plan

3.6 Systems Engineering

3.6.1 System Design

3.6.2 Systems Engineering Integration for Reliability

3.6.2.1 System Reliability Model (SRM)

3.6.2.2 Failure Modes, Effects & Criticality Analysis (FMECA)

3.6.2.3 Reliability Assessment

3.6.2.4 Failure Reporting, Analysis, and Corrective Action System

(FRACAS)

3.6.3 Preliminary Design Stage

3.6.4 Detailed Design Stage

3.6.5 Fabrication, Assembly, Integration and Test Stage

3.6.6 Standardization

3.6.7 Control Hardware/Software Development

3.6.8 Requirements Validation

3.6.9 Design Reviews

3.6.9.1 Systems Requirements Review (SRR)

3.6.9.2 Preliminary Design Review (PDR)

3.6.9.3 Critical Design Review

3.6.10 Product Definition Data (PDD)

3.6.11 System Safety Tasks

3.6.12 Anti-Terrorism (AT) Level 1 Awareness Training

3.6.13 Access and General Protection/Security Policy and Procedures. . 18

3.6.14 Threat Awareness and Reporting Program (TARP)

3.6.15 iWATCH Training

3.7 Integrated Testing

3.7.1 Developmental Tests

3.7.2 Integration Readiness Review (IRR)

3.7.3 Test Readiness Review (TRR)

3.7.4 Logistics Demonstration

3.7.4.1 Logistics Support Equipment/Structural Steel Hoist Systems

3.7.5 Government Site Acceptance Test and System Verification Review

(SVR)

3.8 Site Activation

3.8.1 Installation Tools and Test Equipment

3.8.2 Installation Spares

3.9 Training Requirements

3.9.1 On-Site Training

3.10 Logistics Requirements

3.10.1 Spare Parts List

3.10.2 Material Requirements

3.10.2.1 Item Unique Identification (IUID) of Tangible Items

3.10.3 Operations and Maintenance (O&M) Manuals

APPENDIX A – Design Review Entry and Exit Design Criteria and Data Products ..... A-1 A.1 SRR Entry Criteria ........................................................................ A-1 A.2 Exit Criteria shall include: ............................................................. A-1 A.3 SRR Products .............................................................................. A-2 A.4 PDR Entry Criteria ........................................................................ A-3 A.5 PDR Completion/Exit Criteria ....................................................... A-3 A.6 PDR Products .............................................................................. A-4

A.7 CDR Entry Criteria ....................................................................... A-4 A.8 CDR Completion/Exit Criteria ....................................................... A-5 A.9 CDR Products .............................................................................. A-6 A.10 IRR Entry Criteria ......................................................................... A-6 A.11 IRR Entry Criteria ......................................................................... A-6 A.12 IRR Completion/Exit Criteria ........................................................ A-7 A.13 IRR Products ................................................................................ A-7 A.14 TRR Entry Criteria ........................................................................ A-7 A.15 TRR Completion/Exit Criteria ....................................................... A-8 A.16 TRR Products............................................................................... A-8 A.17 SVR Entry Criteria ........................................................................ A-8 A.18 SVR Entry Criteria ........................................................................ A-8 A.19 SVR Completion/Exit Criteria ....................................................... A-8 A.20 SVR Products............................................................................... A-9 APPENDIX B – Acronyms .......................................................................................... B-10

Statement of Work For

Prompt Gamma Simulator for White Sands Test Center Nuclear Effects Laboratory (NEL)

Survivability, Vulnerability and Assessment Directorate

1. SCOPE.

This Statement of Work (SOW) defines the effort required for designing, developing, integrating, testing, managing, documenting, and delivering the Prompt Gamma Simulator (PGS) for the Nuclear Effects Laboratory (NEL) at White Sands Missile Range (WSMR) in New Mexico.

1.1 Background.

The U.S. Army Program Executive Office Simulation, Training and Instrumentation (PEO STRI), Project Manager for Instrumentation, Targets and Threat Simulators (PM ITTS), Instrumentation Management Office (IMO) has a requirement from the U.S. Army Test and Evaluation Command, Survivability, Vulnerability and Assessment Directorate (SVAD) to develop a short-pulse, high dose rate, gamma x-ray simulator to conduct testing on Circuit Card Assemblies (CCAs), Line Replaceable Units (LRUs), small test systems and light armored vehicles for Nuclear Weapons Effects survivability validation at (WSMR), New Mexico. NEL comprises a variety of laboratories and test facilities focused on the impact of nuclear effects on military equipment.

2. APPLICABLE DOCUMENTS.

The following documents of issue form a part of this SOW to the extent specified herein.

In the event of a conflict between documents referenced herein (Section 2) and the contents of this SOW (Section 3.), the contents of the SOW shall be the governing requirement.

2.1 DOD Specifications.

Not applicable.

2.2 DOD Standards.

MIL-STD-130 Identification Marking of U.S. Military Property MIL-STD-31000 Technical Data Packages MIL-STD-40051-2B Page-Based Technical Manuals MIL-STD-1629A Procedures for Performing a Failure Mode, Effects and Criticality Analysis MIL-HDBK-831 Preparation of Test Reports

2.3 Availability of DOD Standards.

Copies are available on the WWW at URL: https://assist.dla.mil/online/start/

2.4 Department of Defense Instructions (DoDIs).

DOD Instruction 5000.02, Operation of the Defense Acquisition System, January 7, 2015; http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf

2.5 Availability of DoDIs.

Copies are available on the WWW at URL:

https://www.dtic.mil/whs/directives/corres/dir.html

2.6 Department of Defense Directives.

Not applicable.

2.7 Other Government Documents, Drawings, and Publications.

PRF-PT-00659 System Performance Specification for The Prompt

Gamma Simulator for The White Sands Missile Range (WSMR) Nuclear Effects Laboratory (NEL)

Army Regulation 385-10, The Army Safety Programs, Rapid Action Revision (RAR) Issue Date: 14 June 2010; https://safety.army.mil/Portals/0/Documents/ON- DUTY/AVIATION/PUBSANDFORMS/Standard/Army_Regulation_385-10.pdf

2.8 Availability of Other Government Documents and Publications.

Copies of the above documents are available at PEO STRI, PM ITTS-IMO, ATTN:

SFAE-STRI-ITTS-I (Erick Serrano), 12350 Research Parkway, Orlando, FL 32826-3276 (erick.s.serrano.civ@mail.mil).

3. REQUIREMENTS.

3.1 General.

The Contractor shall design, develop, fabricate, integrate and test the PGS that meets performance criteria per the System Performance Specifications and in accordance with the requirements below.

The PGS shall be a standalone simulator. The government will be responsible for providing the building facility for the PGS and all required mechanical (heating, https://assist.dla.mil/online/start/ http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION/PUBSANDFORMS/Standard/Army_Regulation_385-10.pdf https://safety.army.mil/Portals/0/Documents/ON-DUTY/AVIATION/PUBSANDFORMS/Standard/Army_Regulation_385-10.pdf mailto:michael.a.hickey.civ@mail.mil ventilation and air conditioning (HVAC)), cable tray system, domestic water mains and electrical power connection points to make the PGS simulator operational.

3.2 Program Management.

The Contractor shall provide the overall management and administrative effort necessary to ensure that the requirements of this contract are accomplished.

CONTRACTOR’S PROGRESS, STATUS AND MANAGEMENT REPORT (DI-MGMT-

80227)

3.2.1 Integrated Master Schedule (IMS).

The Contractor shall develop, implement, manage, update, and maintain the contract IMS. The IMS shall address total project activities, design phases, component, subsystem and system design reviews, factory testing, integration to the facility infrastructure, site testing activities, activities performed by major subcontractors, installation and final system acceptance efforts. INTEGRATED MASTER SCHEDULE

(IMS) FORMAT 6 FROM INTEGRATED PROGRAM MANAGEMENT REPORT

(DI-MGMT-81861)

3.2.2 Financial Management.

The Contractor shall plan, budget, schedule, and control the resources allocated to meet the requirements of the contract. The Contractor shall document and track the status of all appropriated funds associated with the contract, to include payments, cancellations, and invoices against each contract line item and sub-line item. The Contractor shall document and track budgeting for the entire contract work scope.

CONTRACT INVOICING AND PAYMENT RECORD (DI-MGMT-81651), CONTRACT

FUNDS STATUS REPORT (CFSR) (DI-MGMT-81468), INTEGRATED PROGRAM

MANAGEMENT REPORT (DI-MGMT-81861) FORMAT 1, 5 & 6. Integrated Master Schedule (Format 6) to coordinate with INTEGRATED PROGRAM MANAGEMENT

REPORT (DI-MGMT-81861) FORMAT 1 & 5.

3.2.3 Risk Management.

The Contractor shall prepare, implement, and maintain a risk management process that includes identification, analysis, mitigation plan/implementation, and tracking.

Government representatives shall be active participants in this process. The Contractor’s risk management process shall measure current and future uncertainties (i.e., cost, schedule, and performance) in achieving project goals within constraints.

CONTRACTOR’S RISK MANAGEMENT PLAN (DI-MGMT-81808)

3.2.4 Quality Control.

The Contractor shall develop and maintain an effective quality control program to ensure services are performed in accordance with this SOW. The Contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The Contractor’s quality control program is the means by which the Contractor assures work complies with the requirement of the contract.

3.2.5 Integrated Digital Environment.

The Contractor shall provide an access controlled Internet based IDE to facilitate the electronic data interchange of all program data. All management, technical, cost, and schedule data (including all internal documents produced to design, develop, test and manage the program) shall be made available to all Government and contractor team members in an integrated, electronic, and query capable database, accessible via the Internet. The Contractor shall provide the capabilities for on-line review, comment, acceptance and approval of all deliverable data. The Contractor shall establish a disaster recovery process to ensure that appropriate information systems and data are available when needed after a natural or human disaster.

3.2.6 Management Reviews.

3.2.6.1 Post Award Conference (PAC).

A PAC shall be held 10 calendar days after contract award. The conference shall introduce the key Integrated Product Team (IPT) participants, identify points of contact, and discuss both parties' understanding of the scope of work and other contract issues.

The Government will produce the agenda and documentation and lead the PAC via a conference call.

3.2.6.2 Start of Work Meeting.

A Start of Work Meeting will be held within 45 calendar days after the PAC to establish the framework of the Contractor and Government interaction during the performance period of the contract. The Contractor shall present an IMS showing the critical milestones and supporting events, including logistics leading to milestones. The kickoff meeting shall include discussion of information and data relating but not limited to:

a. Introduction and contract overview.

b. Contractor SOW requirements in relation the building being provided by the Government for the PGS. Identify key coordination events, interface timelines and testing readiness.

c. Discussion and clarification of Government provided System Performance Specification and SOW requirements.

d. Systems Requirements Review

e. Presentation of a top level and realistic IMS and detailed schedule with status.

f. Systems Engineering design approach: design simulations, reliability and maintainability analysis, component, subsystem and system design, testing and acceptance approach.

g. Critical paths within the IMS.

h. Contract Data Requirements List (CDRL) delivery schedule and status.

i. Risk Management Plan.

j. IPT structure, membership, and responsibilities.

k. Action item reporting and status.

l. Long lead time item identification and status.

m. Updated team contact list (i.e., names, location, phone numbers, and email addresses).

n. Metrics collection process, analysis, and reporting.

3.2.6.3 Program Management Reviews.

The Contractor shall conduct formal Program Management Reviews at least once every six months. The Program Management Review shall provide a project overview and a detailed discussion of pre-selected topics. Program Reviews will be conducted at Contractor’s facility.

3.2.6.4 Technical Interchange Meetings (TIMs).

Subsequent to the Start of Work Meeting, the Contractor shall lead, conduct, and participate in TIMs every four weeks throughout the entire duration of the contract.

These meetings will be conducted via teleconferences. The meetings shall be co-chaired by a Government and contractor representative. The contractor must be prepared to explain the reasoning, assumption, and methodologies in arriving at particular conclusions, recommendations, or alternatives in the accomplishment of tasks required by the contract. The Contractor shall prepare drawings and other data, as required, to aid in teleconferences. The Contractor shall prepare meeting agendas and document meeting results. Except where noted herein, TIMs shall be considered fulfilled when all of the following items are completed:

Formal review teleconference meeting is conducted;

All Action Items requiring Contractor response are documented and posted; and TIM minutes are submitted.

3.3 Building Facility Infrastructure and Data Acquisition System.

3.3.1 Building Facility Infrastructure.

The Government will provide the building facility and infrastructure required to support the PGS and subsystems based on timely identification of system requirements. This infrastructure includes structural floor trenches, HVAC, electrical power connection points, domestic water connections, floor drains, cable tray systems for low voltage wiring and radiation shielding.

3.3.1.1 PGS System and Building Facility Infrastructure Coordination.

The Government will provide the Contractor with building floorplans so the Contractor can coordinate PGS layout design, subsystem coordination, serviceability and maintainability.

As part of the Preliminary Design Review (PDR) the Contractor will be required to submit PGS drawings that illustrate proposed layouts of all systems that comprise the PGS along with the facility infrastructure requirements (equipment layouts with services clearances, architectural, structural, electrical, cable trays, HVAC, plumbing, radiation patterns for shielding requirements).

As part of the Critical Design Review (CDR) the Contractor will be required to submit drawings that shows detailed layouts of all systems that comprise the PGS along with detailed facility requirements (equipment layouts with services clearances, architectural, structural, electrical, cable trays, HVAC, plumbing, radiation patterns for shielding requirements).

As part of the Integration Readiness Review (IRR) the Contractor will be required to perform a site survey to confirm facility infrastructure requirements (architectural, structural, electrical, cable trays, HVAC, plumbing, radiation shielding) are all in place to interface with the PGS systems prior to delivery of the PGS to WSMR NEL.

3.3.2 Data Acquisition System.

The Government will provide a functional data acquisition system in place at WSMR in time for the PGS Government Site Acceptance.

Contractor Factory Acceptance Test (FAT) and Contractor Site Acceptance Test (SAT) are the responsibility of the contractor. The exact nature of the measurements (direct measurements of radiation or inferred values from machine data) is not specified, but must be convincing and is subject to Government approval. The Government will conduct independent measurements using Government instrumentation to satisfy Government acceptance testing requirements.

3.4 Risk Management Framework (RMF) Process

PEO STRI’s Cyber Security Office will be have the responsibility of performing Risk Management Framework (RMF) procedures to permit the system to acquire an Authority to Operate (ATO). The Cyber Security requirements for DoD information technologies will be consistent with the principles established in NIST Special Publication (SP) 800-37 in accordance with DoD 8510.01 Risk Management Framework (RMF) for DoD Information Technology (IT). The Cyber Security team will be present during the Start of Work Meeting and throughout the duration of the project to assist the contractor with the required documentation. Because the PGS System is stand-alone system and not connected to any networks, the RFM process will be a streamlined process. The Contractor shall provide the following RMF documentation required to implement the RMF Controls for Confidentiality, Integrity and Availability Levels of Low- Low-Low:

a. Security Plan

b. Hardware / Software List

c. Continuity of Operations Plan / Contingency Plan

d. Compliance Deviation Report

The Government Cyber Security team will provide the Contractor with samples and templates of these documents. The Government will work with the Contractor to ensure that the security requirements and procedures are met in accordance with all required DoD and Army regulations per the Mission Assurance Category and Confidentiality levels agreed upon for the system. CYBERSECURITY ARTIFACTS (DI-MISC-80711A)

3.5 Systems Security Engineering – Program Protection Plan

Contractor shall conduct analysis and provide associated information in support of the Government’s Program Protection Plan. The Contractor shall:

• Perform or update a criticality analysis, vulnerability assessment, risk assessment, and countermeasure selection and implementation, with assumptions, rationale, and results, before each of the technical reviews defined for the program.

• For each level I and level II component (in accordance with Table 3.3.2), the contractor shall identify the associated logic-bearing hardware, software and firmware that implements critical functions or introduces vulnerability to the associated components (designated as "critical components”).

Table 3.3.2. Protection Failure Criticality Levels

Level I – Total Mission Failure

Program protection failure that results in total compromise of mission capability https://acc.dau.mil/dag13.3

Level II – Significant/Unacceptable Degradation

Program protection failure that results in unacceptable compromise of mission capability or significant mission degradation

Level III – Partial/Acceptable

Program protection failure that results in partial compromise of mission capability or partial mission degradation

Level IV – Negligible Program protection failure that results in little or no compromise of mission capability

• Demonstrate that the contractor has visibility into its supply chain for critical components, understands the risks to that supply chain, and has implemented or plans to implement risk mitigations to counter those risks.

• Plan for and implement countermeasures which mitigate foreign intelligence, technology exploitation, supply chain, and system vulnerabilities that result in the catastrophic (Level I) and critical (Level II) protection failures, including:

I. The application of supply chain risk management best practices, applied as appropriate to the development of the system. Supply chain risk management key practices may be found in the National Institute of Standards and Technology (NIST) Interagency Report 7622, Piloting Supply Chain Risk Management for Federal Information Systems, and the National Defense Industrial Association Guidebook, Engineering for System Assurance, both publicly available.

II. The enumeration of potential suppliers of critical components, as they are identified, 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 to be solicited.

III. The processes to control access by foreign nationals to program information, including, but not limited to, system design information, DoD-unique technology, and software or hardware used to integrate commercial technology.

IV. The processes and practices employed to ensure that genuine hardware, software and logic elements will be employed in the solution and that processes and requirements for genuine components are levied upon subcontractors.

V. The process used to protect unclassified DoD information in the development environment.

http://www.acq.osd.mil/se/docs/SA-Guidebook-v1-Oct2008.pdf http://www.acq.osd.mil/se/docs/SA-Guidebook-v1-Oct2008.pdf

• The preceding clauses shall be included in the solicitations and subcontracts for all suppliers, suitably modified to identify the parties.

• The contractor shall develop a set of secure design and coding practices to be followed for implementation of Level I and II critical components, drawing upon the “top 10 secure coding practices” (https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+ ...) and the Common Weakness Enumeration (CWE)/SysAdmin, Audit, Network, Security (SANS) top 25 most dangerous software errors (http://cwe.mitre.org/top25/index.html).

Contractor shall conduct analysis and provide associated information in support of the Government’s Program Protection Plan. PROGRAM PROTECTION

IMPLEMENTATION PLAN (PPIP) (DI-ADMN-81306)

3.6 Systems Engineering.

The Contractor shall implement a systems engineering process to transform all systems into a set of lower level performance requirements that define the system. The systems engineering effort shall integrate all elements of a multi-functional engineering effort to meet system requirements. The Contractor shall ensure the design incorporates engineering specialties, such as reliability, maintainability, logistics engineering, serviceability, safety and standardization into design, development, and manufacturing.

The Contractor shall, as part of the systems engineering effort, create and maintain the Systems Engineering Management Plan (SEMP) as a living document. The Contractor shall use the SEMP to identify and assure control of the overall technical management process. The Contractor shall coordinate the contents of the SEMP with the Government’s Systems Engineering Plan (SEP). SYSTEMS ENGINEERING

MANAGEMENT PLAN (SEMP) (DI-SESS-81785)

The Contractor shall translate the basic operational needs, requirements, objectives, interface and other design constraints including cost, into preliminary verifiable functional requirements. The Contractor shall conduct cost-benefit trades to support refinement of the preliminary functional requirements. The Contractor shall complete simulations, technology demonstrations, parts characterization, or other risk reduction steps to provide the basis for engineering and manufacturing development and verify the technology, design approach or other result can meet the system requirements.

While PGS components are possibly custom designed, they are substantially similar to components that have successfully been used in other pulsed power machines with well modeled, predictable performance and low failure rates. The Contractor shall complete the system design (balanced with respect to performance, cost, schedule, and risk) and https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices http://cwe.mitre.org/top25/index.html verify it meets the systems requirements. The Contractor shall baseline balanced life cycle verification, manufacturing, installation, training, operation, and disposal data plans and update them based on the results of both compliance verification under contract and government testing. Contract will assess proposed changes in functional architecture, physical hierarchy and baselines. Prior to approval, this assessment should objectively examine alternatives to balance performance, cost, schedule, and risk. The Contractor shall develop and complete all planned IMS tasks for each milestone.

3.6.1 System Design.

The Contractor shall use PRF-PT-00659 as the basis for development of all lower level specifications. The Contractor shall perform simulations demonstrating system performance requirements then finalize the system design. The design shall incorporate an open systems approach based on an engineering and business strategy to choose specifications and standards adopted by industry or de facto standards (set by the market place) for selected system interfaces, products, practices and tools.

Selected designs and specifications shall be based on performance, cost, industry acceptance, long-term availability, supportability, maintainability and upgrade potential.

3.6.2 Systems Engineering Integration for Reliability.

The Contractor shall:

(1) Incorporate reliability activities as an integral part of disciplined and documented systems engineering process and plan

(2) Manage and control reliability critical items

(3) Coordinate all reliability activities and findings with the system’s design team

The Contractor shall incorporate during the design phase, manufacturing phase, component and subsystem testing, integration phase, total system testing up to final government acceptance. The Contractor shall prepare and present reliability analysis(s) to Government representatives throughout the duration of this contract.

3.6.2.1 System Reliability Model (SRM)

The Contractor shall develop an SRM using reliability block diagram analysis. The SRM is a graphical depiction of the system with an underlying analysis, such as Reliability Block Diagram, Fault Tree, or Event Tree. The analysis shall identify critical weaknesses in the system design. The SRM shall include all hardware and non-hardware elements and their relationships to each other. The SRM shall become a bi-directional tool that the reliability and design teams use to influence and trace changes to the system design, operation and sustainment costs.

The SRM shall consist of the lowest identifiable functions/elements and their relationships to each other. The SRM shall encompass all hardware and non-hardware elements, including, but not limited to: Commercial Off-the-Shelf (COTS), Non- Developmental Items (NDI), software, human factors, and manufacturing. At a minimum, the SRM shall be used to:

(1) Generate and update the reliability allocations

(2) Identify critical elements in the system design

This will determine if additional design or additional testing activities are required in order to achieve the reliability requirements. Critical elements are defined as those elements whose failure impacts mission completion, essential functions, or safety; or elements whose failure rates contribute significantly to the overall system.

RELIABILITY AND MAINTAINABILITY PREDICTIONS REPORT (DI-SESS-81497a)

3.6.2.2 Failure Modes, Effects & Criticality Analysis (FMECA).

The Contractor shall develop a FMECA analysis using MIL-STD-1629A requirements as guidance. This standard establishes requirements and procedures for performing a failure mode, effects, and criticality analysis (FMECA) to systematically evaluate and document, by item failure mode analysis, the potential impact of each functional or hardware failure on mission success, personnel and system safety, system performance, maintainability, and maintenance requirements. It is a procedure by which each potential failure mode is analyzed to determine its effects on the system and then is classified according to severity. It will identify all single points of failure; that is, those points where failure of the component can cause failure of the entire system.

The FMECA procedure will contribute to improved designs for PGS and processes, resulting in higher reliability, better quality, increased safety, enhanced customer satisfaction and reduced sustainment costs. The process will establish and optimize maintenance plans for repairable systems and/or contribute to control plans and other quality assurance procedures. It will provide a knowledge base of failure mode and corrective action information that can be used as a resource in future troubleshooting efforts and as a training tool for the user. Analysis results are to be included in the Reliability and Maintainability Predictions Report as part of CDRL requirement in Section 3.6.2.3.

3.6.2.3 Reliability Assessment.

The reliability assessment is the estimation of the system’s reliability through comparable systems/elements, historical reliability, or subject matter expert engineering estimation. The reliability assessment shall be used in conjunction with the SRM to identify low, medium, and high risk critical elements.

The Contractor shall assign each element of the SRM an assessed and consistent reliability metric (e.g., mean time between failures (MTBF)). The values shall be based on one of the following methods:

(1) Reliability analysis from comparable systems/elements

(2) Historical reliability from predecessor systems/elements

(3) Documented subject matter expert engineering estimation.

The Contractor shall provide a table with all elements contributing to critical weaknesses of the SRM. Each SRM element shall include its associated reliability metric and risk criteria (low, medium, high) based upon the following guidance:

a. Low Risk – Test data or reliability analysis of comparable systems (under Operational Mode Summary/Mission Profile (OMS/MP) conditions);

b. Medium Risk – Historical reliability of systems of similar complexity, test data, or reliability analysis of comparable systems (not following OMS/MP conditions);

and

c. High Risk – Subject Matter Expert (SME) engineering estimates

The Contractor shall develop a plan to mitigate all critical elements rated as high or medium risk. Mitigation plans may include additional testing, redesign, part selection, etc. The Contractor shall provide the Government all mitigation plans upon development. Reliability assessment analysis to be included in the RELIABILITY AND MAINTAINABILITY PREDICTIONS REPORT (DI-SESS-81497a)

3.6.2.4 Failure Reporting, Analysis, and Corrective Action System (FRACAS).

The FRACAS is a closed-loop process in which failure modes are identified and corrective actions are developed, implemented, and verified. The FRACAS shall be conducted on the whole system, to include products (e.g., hardware and software and services (e.g., manufacturing and design) throughout the life cycle (from initial modeling and analysis through fielding). Failure modes shall be mitigated through one or more of the following approaches:

a. Eliminating the failure mode,

b. Reducing its frequency or probability of occurrence,

c. Incorporating redundancy, and

d. Mitigating the effects of the failure (e.g., advanced warning of failure or a degraded mode of operation).

The Contractor shall establish and utilize a closed-loop FRACAS as its mechanism for monitoring and communicating (throughout the organization) descriptions of: test and field failures, analyses of failure modes and root cause failure mechanisms, the status of design and/or process corrective actions, risk-mitigation decisions, the effectiveness of corrective actions, and lessons learned. The Contractor shall address all failure modes found on assemblies and subassemblies, to include, but not limited to, COTS, NDI, and software as applicable. The FRACAS shall include all failure modes, from initial modeling and analysis through the fielding of the system. The Contractor shall aggressively address and mitigate failure modes in a timely manner, consistent with their impact on safety, reliability, performance, and total life cycle cost. The Contractor shall mitigate failure modes to ensure that reliability requirements are met, and reliability does not degrade during production or in the field. The Contractor shall provide the

Government with failure analysis and corrective action reports. FAILURE ANALYSIS

AND CORRECTIVE ACTION REPORT (FACAR) (DI-SESS-81315B)

3.6.3 Preliminary Design Stage.

The Contractor shall initiate subsystem design and create subsystem level definition and design to baselines to guide component development. The Contractor shall ensure the design considerations include systems functional requirements, systems non-functional requirements (e.g., performance, design goals (e.g., modular open system approach (MOSA)), and human system interfaces for operation, service and repair activities of the PGS and all system components. The Contractor shall decompose identified subsystem functions into lower-level functions and allocate functional and performance requirements to component-level functional and physical architectures.

Final subsystem definition to include:

(1) Identification of recommended components and interfaces; resolution of subsystem-level risks

(2) Assessment of component risks

(3) Design for quality factors to include verifiability, usability, maintainability, serviceability, supportability, trainability and disposability Technical reviews shall be completed for each subsystem. The results of the evaluation shall be documented.

The purpose of each review is to assure:

a. The subsystem definition is sufficiently mature to meet systems engineering criteria.

b. The subsystem functional requirements and non-functional requirements (e.g., performance, design goals (e.g., modular open system approach (MOSA)) are identified in the subsystem design and are traceable to functional and non-functional requirements.

c. Component allocations and preliminary component specifications are reasonable and provide a sound subsystem concept.

d. Preliminary simulation runs to support solution.

e. Control software architecture achieves performance characteristics.

f. Subsystem risks have been assessed and mitigated to a level appropriate to continue development.

g. Trade-study data are adequate to substantiate that subsystem requirements are achievable.

h. Reliability and maintainability analysis have been performed and mitigated to support further design efforts.

i. Human system interfaces with respect to operation, maintainability, serviceability, logistics support are identified and described in the detailed design and are traceable to design requirements.

j. Decisions made in arriving at the subsystem configuration definition are supported by analysis and technical data.

3.6.4 Detailed Design Stage.

The Contractor shall complete subsystem design down to the lowest component level, create a component requirement, a verification definition, and a build-to-product baseline for each component. Final component definition shall include identification of recommended parts and interfaces; resolution of component-level risks and for each component, down to the lowest sub-component, the design for quality factors to include fabrication, verifiability, usability, supportability, serviceability, trainability, maintainability and disposability. Component reviews shall be completed at the completion of the detailed design stage. The results of the evaluation shall be documented.

The purpose of these reviews shall be to ensure that:

a. Each detailed component definition is sufficiently mature to meet performance criteria.

b. Component specifications are reasonable and provide a sound component concept.

c. Component and related life cycle process risks have been assessed and mitigated to a level appropriate to support the fabrication, assembly, integration and test phases.

d. Final simulation runs to support solution.

e. Trade-study data are adequate to substantiate that detailed component requirements are achievable.

f. Reliability and maintainability analysis have been performed and mitigated to support the design, fabrication, assembly, integration and test phases.

g. Control software architecture achieves performance characteristics.

h. Human system interfaces with respect to operation, maintainability, serviceability, logistics support are identified and described in the detailed design and are traceable to design requirements.

i. The detailed software design described in terms of the satisfaction of functional and non-functional systems requirements.

j. Decisions made in arriving at the detailed component definition configuration are supported by analysis and technical data.

k. Security engineering processes are integrated into the design to achieve an integrated secure solution.

3.6.5 Fabrication, Assembly, Integration and Test Stage.

The Contractor shall resolve product deficiencies when specifications for the system, product, subsystem, assembly, or component are not met, as determined by inspection, analysis, demonstration, or test. The Contractor shall verify that the products designed satisfy specifications.

3.6.6 Standardization.

The Contractor shall design the system to achieve maximum subsystem, component and repair parts commonality. The Contractor shall minimize equipment and parts proliferation through a standardization effort. The Contractor shall minimize the number of unique parts in the design and maximize the use of commercially available parts.

3.6.7 Control Hardware/Software Development.

Contractor shall provide control hardware, software, sensors, control devices, data acquisition systems and sequences of operation for proper integration and operation of support systems and PGS. Software shall have a graphical display and interface for system control, feedback, diagnostics and test collection data acquisition system.

The Government shall receive all source code files. The Government shall also receive compiled executable files and the common platform software runtime environment installed. Additionally, a common platform project file shall be provided, which is necessary to compile executable files by the Government. The common platform license shall be transferable to a different computer if a computer replacement is ever required. (DI-IPSC-81441A) SOFTWARE PRODUCT SPECIFICATION (SPS)

3.6.8 Requirements Validation.

The Contractor shall perform and document an analysis to verify all requirements from the Performance Specification are met and are traceable. The Contractor shall ensure there is forward and backward traceability between all requirements (i.e. specifications, test procedures, and associated design documentation).

3.6.9 Design Reviews

The Contractor shall conduct reviews, to include design reviews (system, subsystem, component, test readiness, production approval) and audits (functional and physical configuration), for the purpose of assessing technical progress. The Contractor shall document the results of the review, including any resulting action items. A design review shall be conducted at the completion of each application of the system engineering phase. Each review shall accomplish the following:

a. Assess the system requirements and allocations are unambiguous, consistent, complete, feasible, verifiable, and traceable to top-level system requirements.

b. Present reliability and maintainability assessments of components, subsystems and systems.

c. Assess the design maturity based on technical development goals, IMS events, accomplishments, and empirical analysis and test data supporting progress to date.

d. Present the risks associated with a continued development effort.

e. Assess processes and infrastructure necessary for product sustainment throughout the system life cycle.

f. Identify resources required for continued development.

g. Determine whether to proceed with the next application of the systems engineering process, or take corrective actions before proceeding.

Component, subsystem, and system design reviews shall be conducted for each level of development. Depending on the complexity of the system, lower level reviews may be needed. Trade-off analysis, simulation results and verification results shall be available during design reviews in order to substantiate design decisions. Reviews may result in the need to iterate through the system engineering process to resolve identified deficiencies before progressing further into the development activity. Component, subsystem, and system functional- and design-configuration audits shall be performed to ensure that supporting documentation has been satisfactorily completed, that qualification tests for each specification requirement have been completed and all requirements satisfied or products comply with final drawings.

3.6.9.1 Systems Requirements Review (SRR)

The SRR is a multi-disciplined product and process assessment to ensure the system performance requirements as captured in the system performance specification are consistent with the system solution and available technologies. Of critical importance to this review is the understanding of program technical risk inherent in the system performance specification. Acceptable level of risk is key to a successful review.

See Appendix A for Entry and Exit Criteria and SRR Products.

3.6.9.2 Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) is a multi-disciplined product and process assessment to ensure that the system can proceed into detailed design, and can meet the stated performance requirements within cost, schedule, risk, reliability and maintainability and other system constraints. This review will assess the system preliminary design as captured in performance specifications for each configuration item in the system (allocated baseline), and ensures that each function in the functional baseline has been allocated to one or more system configuration items. PDR determines whether the hardware, human maintainability aspect and software control preliminary designs are complete, and the IPT is prepared to start detailed design and test procedure development.

See Appendix A for Entry and Exit Criteria and PDR Products.

3.6.9.3 Critical Design Review

The Critical Design Review (CDR) is a multi-disciplined product and process assessment to ensure that the system can proceed into system fabrication, demonstration, and test, and can meet the stated performance requirements within cost, schedule, risk, reliability and maintainability and other system constraints. This review will assesses the final design as captured in product specifications for each configuration item in the system (product baseline), and ensures that product baselines have been captured in detailed design documentation. Product specifications for hardware must enable the fabrication of configuration items and shall include product definition data. Product specifications for control software must show performance requirements.

A successful review is predicated on the IPT’s determination that the subsystem requirements, subsystem detail design, results of peer reviews, and plans for testing form a satisfactory basis for proceeding into system fabrication, demonstration, and testing.

See Appendix A for Entry and Exit Criteria and CDR Products.

3.6.10 Product Definition Data (PDD).

During the systems engineering and design, and in accordance with MIL-STD-31000, the Contractor shall develop, produce, and maintain product definition data (PDD) that accurately depicts the final product. The PDD is the technical description of items adequate for supporting an acquisition strategy, production, engineering, and logistics support. The PDD shall disclose complete design, logistics, manufacturing requirements, and the means of measuring compliance with the requirements. Piece part information (drawings, computer aided design files and meta data) and associated lists shall provide design, engineering, manufacturing, and quality assurance requirements information necessary to enable the procurement or manufacture of an interchangeable item that duplicates the physical, and performance characteristics of the original product, without additional design engineering effort or recourse to the original design activity. The Contractor shall produce and maintain documentation for all electrical assemblies and subassemblies in such a manner to ensure their functional integration without recourse to special test equipment (STE) or installation of the assemblies or subassemblies into a next higher assembly. Utilizing the established logistic repair procedures, the Contractor shall identify high level components and assemblies to be repetitively procured as spare components and assemblies or which may be procured independently. For each high level component or assembly, the Contractor shall determine and document the functional requirements for the item, the environment in which it must operate, interface and interchangeability characteristics, and criteria for verifying Logistics Support criteria. The Contractor shall conduct engineering analyses to establish quantitative and qualitative supportability design guidelines. The Contractor shall conduct trade studies, evaluate design and support alternatives, and establish system supportability preliminary design configurations consistent with system readiness and availability and life cycle cost goals.

SYSTEM/SUBSYSTEM…