Attach_2_SOW_for_Amendment_1_17_Sep_15.pdf

N00024-15-R-6262

ATTACHMENT 2

STATEMENT OF WORK

FOR THE

OWNSHIP MONITORING SYSTEM (OMS)

DEVELOPMENT, PRODUCTION, AND ENGINEERING SERVICES

PREPARED BY

PROGRAM EXECUTIVE OFFICE, SUBMARINES (PEO SUB)

PMS401

17 April 2015 ii

TABLE OF CONTENTS

1.0 SCOPE

1.1 COLLABORATIVE DEVELOPMENT ENVIRONMENT

2.0 REFERENCED DOCUMENTS

2.1 ORDER OF PRECEDENCE

2.2 GOVERNMENT DOCUMENTS

2.3 NON-GOVERNMENT DOCUMENTS

3.0 REQUIREMENTS

3.1 GENERAL REQUIREMENT

3.1.1 Program Management

3.1.1.1 Contract Work Breakdown Structure (CWBS)

3.1.1.2 Integrated Program Management Report (IPMR)

3.1.1.3 Subcontract Management and Control

3.1.1.4 Program Risk Analysis

3.1.1.5 Program Management Reviews

3.1.1.6 Technical Reviews

3.1.1.7 Integrated Product Team (IPT)

3.1.1.8 Coordination

3.1.1.9 Data Management

3.1.1.9.1 Digital Data Management

3.1.1.9.2 Internal Data / Data Access

3.1.1.10 Government Furnished Information (GFI)

3.1.1.11 Government Furnished Property/Equipment/Material (GFP/E/M)

3.1.2 Systems Engineering

3.1.2.1 Systems Engineering Management

3.1.2.2 Open Systems Architecture Approach

3.1.2.3 Specification Requirement Verification Matrix (SRVM)

3.1.2.4 System Engineering and Design Analyses

3.1.2.5 Design Analysis

3.1.2.5.1 Failure Modes, Effects, and Criticality Analyses (FMECA)

3.1.2.5.2 Failure Reporting Analysis and Corrective Action System (FRACAS)

3.1.2.6 Hardware Engineering

3.1.2.6.1 COTS and NDI Requirements

3.1.2.6.2 COTS / NDI License and Modification

3.1.2.6.3 Technology Refreshment

3.1.2.6.4 Engineering Drawings

3.1.2.7 Information Assurance (IA)

3.1.2.8 Safety Program

3.1.2.9 Test and Evaluation Program Plan (TEPP)

3.1.2.10 Environmental Compliance

3.1.2.11 Integrated Logistics Support (ILS)

3.1.2.11.1 Parts Management Program

3.1.2.11.2 Reliability Centered Maintenance (RCM) Analysis and Products

3.1.2.11.3 Supportability Analysis

3.1.2.11.4 Failure Reporting

3.1.2.11.5 Supply Support

3.1.2.11.6 Provisioning Data

3.1.2.11.7 Interactive Electronic Technical Manual (IETM)

iii

3.1.2.11.8 Unique Identification (UID) Requirements

3.1.2.11.9 Radio Frequency Identification (RFID)

3.1.2.11.10 Packaging, Handling, Storage, and Transportation

3.1.2.11.11 Nomenclature

3.1.2.12 Configuration Management and Documentation

3.1.2.12.1 Product Baseline Identification

3.1.2.12.2 Configuration Control

3.1.2.12.3 Configuration Audits

3.1.2.12.4 Configuration Status Accounting

3.1.2.13 Problem Reporting System

3.1.2.14 Engineering Change Documentation

3.1.2.14.1 Engineering Change Proposal (ECP)

3.1.2.14.2 Class II ECPs, Minor RFVs

3.1.2.14.3 Request for Variation (RFV)

3.1.2.14.4 Revision to ECPs/RFVs

3.1.2.14.5 Classified Data

3.1.2.14.6 Requests for Waivers

3.1.2.14.7 Specification Change Notices (SCNs)

3.1.2.14.8 Notice of Revision (NOR)

3.1.2.14.9 Engineering Change Instruction

3.1.2.15 Quality Assurance (QA)

3.1.2.16 Installation

3.1.2.16.1 Pre-cable Kit (PCK)

3.1.2.16.2 Installation Aids

3.1.2.16.3 Installation and Checkout Kits (INCO)

3.1.2.17 Special Study/Analysis

3.1.2.18 Technical Data Package (TDP)

3.2 ENGINEERING DEVELOPMENT MODEL (EDM)

3.2.1 SSN 774 Class Submarine

3.2.2 OHIO Replacement Class Submarine

3.2.3 Software Engineering

3.2.3.1 Software Design Requirements

3.2.3.2 Interface Management and Documentation

3.2.3.3 Software Version Description (SVD)

3.2.4 Integration and Test Engineering

3.2.5 Production Readiness

3.2.5.1 Production Planning

3.2.5.2 Production Readiness Review (PRR)

3.2.6 First Article Test

3.3 PRODUCTION REQUIREMENT

3.3.1 Environmental Qualification Test

3.3.2 Factory Acceptance Test

3.4 ENGINEERING SERVICES

3.4.1 Telemetry Recorder

STATEMENT OF WORK

FOR THE

OWNSHIP MONITORING SYSTEM (OMS)

DEVELOPMENT, PRODUCTION, AND ENGINEERING SERVICES

1.0 SCOPE

This Statement of Work (SOW) defines the efforts required for the program management, engineering, development, logistics, configuration management, hardware, software development, integration,, test and evaluation, in-service support, and Information Assurance (IA), of the Ownship Monitoring System (OMS) systems.

This effort includes exploring existing and new approaches to sensor processing and developing new or augmenting existing capabilities as required to meet the acoustic processing needs for the Navy.

The efforts defined herein, including fabrication of Engineering Development Model (EDM) for

Technology Insertion-18 (TI-18), TI-18 to TI-20 EDM Upgrade, and production of OMS systems, are applicable to SSN774 Class submarines.

The efforts defined herein, also including fabrication of Engineering Development Model (EDM) for

Technology Insertion-20 (TI-20), are applicable to OHIO Replacement Class submarines.

The efforts defined herein, including engineering and technical services on SSN688i, SSGN, SSBN Class submarines, and related trainers. These services include obsolescence and string development and integration of Noise Monitoring Hydrophone (NMH), Data Acquisition Unit (DAU), Calibrated Reference Hydrophone (CRH), and other sensors.

The Contractor shall build, test, and deliver operational OMS systems to meet all requirements specified in the “System Requirements Specification for the Ownship Monitoring System” (PMS401-OMSSpec-01). The delivery and acceptance of each production OMS system shall be contingent on successful completion of qualification and acceptance testing.

Engineering Services will be subject to specific information identified in Technical Instructions issued in accordance with the Special Contract Requirement entitled “TECHNICAL INSTRUCTIONS.”

1.1 COLLABORATIVE DEVELOPMENT ENVIRONMENT

The Contractor is required to deliver OMS Systems (TI-20) as GFE to Acoustic Rapid Commercial-off-the-shelf Insertion (A-RCI) System Integrator for system integration and shipboard installation. There are also other Industry partners whom provide engineering services and support of the A-RCI Sonar System. The Contractor shall work in a collaborative environment with a consortium of Navy, Navy laboratories, Academia, A-RCI Prime System Integrator, and other Industry partners to ensure continued success of the program. The Contractor shall identify his approach to be used to support the “Open Source Initiative” to enable third party applications and allow for the efficient integration of improvements with the Submarine Acoustic Systems. The Contractor shall leverage past experience involved in similar efforts and indicate the approach that will be used in delivering this effort.

Based on the rapid development cycle for A-RCI builds, it is highly encouraged that the Contractor maintains a constant presence at the A-RCI Prime System Integration facility to support all integration efforts, Fleet support issues, and OMS system development.

2.0 REFERENCED DOCUMENTS

The documents listed below in Sections 2.2 and 2.3 are incorporated by reference and applicable to the extent set forth in this SOW. These documents are provided as guidance when developing the documentation for the OMS system.

2.1 ORDER OF PRECEDENCE

The order of precedence shall be in accordance with FAR 52.215-8.

2.2 GOVERNMENT DOCUMENTS

PMS401-OMSSpec-01 31 Oct 2014

System Requirements Specification for the Ownship Monitoring System

MIL-HDBK-217F

thru Notice 2 28 February 1995

Reliability Prediction of Electronic Equipment

MIL-HDBK-251

19 Jan 78

Reliability/Design Thermal Applications

MIL-HDBK-470A

Thru Notice 2 31 May 2012

Designing and Developing Maintainable Products and Systems, Volume I

MIL-HDBK-502A

08 Mar 2013

Product Support Analysis

MIL-STD-3034

29 Apr 2014

Reliability-Centered Maintenance (RCM) Process

MIL-PRF-29612B

Notice 2 20 June 2011

Training Data Products

MIL-S-901D

17 Mar 1989

Shock Tests, H.I (High-Impact) Shipboard Machinery, Equipment, and Systems, Requirements For

MIL-STD-461F

10 Dec 2007

Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment

MIL-STD-881C

3 Oct 2011

Work Breakdown Structures for Defense Materiel Items

MIL-STD-882E

11 May 2012

System Safety

MIL-STD-1472G

11 Jan 2012

Human Engineering

MIL-STD-3018

w/ Change 1 27 Oct 2011

Parts Management

MIL-STD-31000A

26 Feb 2013

Technical Data Packages

NAVSEA 0924-062-0010 Rev C

Submarine Safety (SUBSAFE) Requirements Manual

NDMS-100001-000

05 Oct 2009

Technical Manual Contract Requirement (TMCR), Interactive Electronic Technical Manual (IETM) for the A-RCI Program

NAVSEA INSTRUCTION

S5510.18

SECURITY POLICY FOR STEALTH PERFORMANCE DATA

WITH ALTERNATIVE COMPENSATORY CONTROL

MEASURES (ACCMS)

NAVSEA ltr 5510, Ser/TSUB- 24 June 2005

Team Submarine Information Security Policy

NAVSEA PMS401 IUID Plan 03 May 2012

PMS401 Submarine Acoustic Program Office AN/BQQ-10(V) SONAR Set Item Unique Identification Execution Plan

NUWC-NPT Tech Memo 14-003 Rev G 13 May 2014

Acceptance Test Plan for Submarine Sonar

NUWC-NPT Tech Memo 14-059 10 September 2014

AN/BQQ-10 Sonar System Integration and Testing Process

PEO IWS / NAVSEA Technical Review Manual (TRM) Version 2.0 18 December 2009

Technical Review Manual (TRM) Program Executive Officer Integrated Warfare Systems (PEO IWS). Naval Sea Systems Command, Research & System Engineering, Warfare Systems Engineering, and Human System Integration Directorate (NAVSEA 05H).

2.3 NON-GOVERNMENT DOCUMENTS

ANSI/AIAA-R-100A

Recommended Practice for Parts Management

ANSI/EIA-632

Processes for Engineering a System

ANSI/EIA-649-B

17 Jun 2011

Configuration Management Standard

ANSI/EIA-748-B

June 2007

Earned Value Management Systems

ANSI/EIA-STD-0007

August 2007

Logistics Product Data, Version 1.0

GEIA-STD-0007

15 October 2008

Logistics Product Data

IEEE/EIA 12207.0

Software Life Cycle Processes

IEEE/EIA 12207.1

Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.2

Software Life Cycle Processes - Implementation Considerations

NAS411 thru Rev. 2 29 April 94

Hazardous Materials Management Program

3.0 REQUIREMENTS

The work required by this Section 3.0 of the Statement of Work is applicable to all requirements under this contract.

In performing this work, the Contractor will require Secret security clearance level for need for access to classified information, require COMSEC for SIPRNET equipment, involve Foreign Government Information for data sharing, and involve NNPI for data development and information safeguarding.

This contract requires work with SSN 774 Class submarines stealth performance data that falls under the protection of Alternative Compensatory Control Measures (ACCMs). In addition to possessing SECRET security clearance, personnel accessing classified information in the performance of this contract need also possess ACCM.

Some data and associated information which may be provided by the Government as part of this contract will be subject to need-to-know validation and approval by designated Naval Sea Systems Command classification authorities. Supplemental air-gapped segregation requirements will be enforced for electronic (computer) data and networks. Hard copy (paper) data will be subject to approved physical storage segregation. Such access and approvals will be provided as appropriate upon contract award and codified by modification of Form DD254.

3.1 GENERAL REQUIREMENT

The work required by this Section 3.1 of the Statement of Work (SOW) is applicable to development, production and engineering services requirements under this SOW.

3.1.1 Program Management

The Contractor shall designate a Program Manager who shall have responsibility for all aspects of this contract and the authority to commit the Contractor to specific courses of action. The Contractor shall perform all administrative, technical, and financial management functions required to support this effort and shall maintain the status, including all technical activities, problems or deficiencies, and recommended solutions. The Contractor shall be responsible for those activities assigned to subcontractors, to ensure the delivery of all supplies and services specified in this contract. [ELIN A001, DI-MGMT-80227]

3.1.1.1 Contract Work Breakdown Structure (CWBS)

The Contractor shall develop and maintain the CWBS and CWBS dictionary using MIL-STD-881C for guidance. The CWBS shall be to the lowest level necessary to reach manageable units of functional tasks that reflect the work being performed while ensuring the correlation of these lower levels to the specification, contract line items, data items, and work statement tasks. The Contractor shall use the CWBS as the primary framework for contract planning, budgeting, and reporting of the cost, schedule and technical performance status to the Government. The Contractor shall analyze the system requirements specified in the SOW and system specification and translate them into a structure representing the products and services that comprise the entire work effort under the contract. The Contractor, if necessary, shall update the CWBS during the execution of the contract. Changes to the CWBS or associated definitions, at any reporting level, require Government approval. [ELIN A002, DI-

MGMT-81334D]

3.1.1.2 Integrated Program Management Report (IPMR)

The Contractor shall apply Earned Value Management (EVM) principles and create and maintain an IPMR.

The Contractor shall report progress on all technical performance, cost, schedule, and data delivery requirements for engineering services and logistics for the OMS system and production of the OMS system. The Contractor shall provide access to all pertinent records, data and plans, as requested by the Government or their representatives.

Integrated Master Schedule (IMS) activities shall be reported in the IPMR. [ELIN A003, DI-MGMT-81861]

The Contractor shall conduct an Integrated Baseline Review (IBR) within six months of award to assess the

Contractor’s Performance Measurement Baseline (PMB). [ELIN A004, DI-ADMN-81249A], [ELIN A005, DI- ADMN-81250A] The Contractor shall conduct an IBR for any major change to the contract, as determined by the Contracting Officer’s Representative (COR). As part of the EVM requirements for this contract, the Contractor shall generate the Contract Funds Status Report (CFSR). [ELIN A006, DI-MGMT-81468]

3.1.1.3 Subcontract Management and Control

The Contractor shall identify and monitor subcontractor technical, quality, schedule, and milestone achievement on a continuing basis, according to the Contractor’s own established subcontract management techniques.

3.1.1.4 Program Risk Analysis

The Contractor shall identify significant program issues and raise them to the Program Office so that they can be monitored and resolved. The Contractor shall perform a continuing analysis of program, technical, performance, cost, and schedule risks. The analysis shall identify the risks associated with each area, identify the impact of each risk on the overall program, and propose approaches for reducing identified risks. Risk analysis status shall be reported in the Contractor’s Progress, Status and Management Report and presented during Program Reviews. [ELIN A001, DI-MGMT-80227]

3.1.1.5 Program Management Reviews

On a quarterly basis, the Contractor shall host a one-day Program Management Review (PMR) or participate in the PMS4012 Assistant Program Manager (APM) Review. [ELIN A004, DI-ADMN-81249A], [ELIN

A005, DI-ADMN-81250A]

The Contractor shall host the PMR at the Contractor’s facility or via Contractor-hosted video teleconferencing (VTC). The APM Review will be held in Washington, DC area. Technical issues will be discussed in terms of performance goals, exit criteria, schedule progress, and cost impact. At each review, the Contractor shall, at a minimum, report the status of the following:

a. cost/schedule performance

b. design and technical issues

c. hardware and software engineering

d. risk analysis and mitigation activities

e. reliability and maintainability

f. test and integration activities, plans, results

g. development activities -- completed and planned

h. logistics development and support efforts

i. safety program requirements

j. quality program

k. configuration management activities

l. Government-Furnished Property (GFP) and Government-Furnished Information (GFI) status

m. production readiness

n. efforts authorized under technical instructions

o. manpower utilization (actual) for preceding three-month period

p. manpower utilization (projection) for next nine months

q. data-deliverable schedule and status

r. hazardous material management efforts

s. status of action items from previous reviews

3.1.1.6 Technical Reviews

The Contractor shall host a one-day orientation meeting within 30 calendar days after initial contract award for Technology Insertion (TI-18). The Contractor shall host an additional meeting for TI-20 and this meeting will be defined in the Integrated Master Schedule (IMS) or contractor defined Program Plan. The orientation meeting will ensure that all requirements are clearly and mutually understood. Orientation meeting shall be held at the Contractor’s facility.

Technical reviews shall be held at the Contractor’s facility to discuss and evaluate design status. Technical reviews shall be conducted on a periodic basis to determine progress and resolve issues. The structure and intervals will be defined in the Integrated Master Schedule (IMS) or contractor defined Program Plan. The Contractor shall demonstrate how completion of required accomplishments associated with the event or milestone will be achieved for these reviews. As scheduled in the IMS, the Contractor shall conduct the following reviews each for TI-18 and TI-20 using ANSI/EIA-632 and/or PEO IWS / NAVSEA Technical Review Manual (TRM) as guidance.

a. System Requirements Review (SRR) / System Design Review (SDR) / Software Specification Review

(SSR). The objective of the review is to ensure that the operational requirements have been successfully represented by the system requirements, that the system design has the potential of meeting these system requirements when acceptably balanced with cost, schedule, and technical risk, and that the plans for moving ahead with system development are reasonable and of acceptable risk. It is also to determine the state of the requirements for a software configuration item (CI) and to assess whether the requirements are sufficiently mature to continue development.

b. System Functional Review (SFR)/Preliminary Design Review (PDR). The objective of the review is to review the architectural design of the CI to verify its compliance to its allocated requirements, the planned test approaches, and the overall progress being made in developing the CI, as it fits into the total system. The review is considered complete when Government has determined that progress has been sufficient for continued development.

c. Critical Design Review (CDR) / Final Design Review (FDR). The objective of the review is to provide the opportunity to assess the completeness of the detailed design and how it supports the performance requirements as well as overall progress being made in developing the system.

d. If required, Production Readiness Review (PRR). See Section 3.2.5.2 for more information.

e. Test Readiness Review (TRR). The objective of the review is for the Government to determine whether the contractor and all associated activities are mature enough and sufficient progress has been made in development and test planning to begin formal product testing with an acceptable likelihood of successfully passing formal testing.

f. Integration Readiness Review (IRR). The objective of the review is for the Government to determine whether the contractor is in fact ready to begin system integration testing with the ARCI Sonar System at the ARCI Prime System Integrator’s facility.

For each review, the Contractor shall generate and provide design review information package to the

Program Office. [ELIN A00A, DI-SESS-81757A]

For each review, the Contractor shall transcribe meeting minutes and include action items assigned. [ELIN

A004, DI-ADMN-81249A], [ELIN A005, DI-ADMN-81250A]

3.1.1.7 Integrated Product Team (IPT)

The objective of the IPT concept is to assemble all stakeholders with a particular problem or issue who will expand the principal of concurrent engineering, utilizing a systematic approach to make team decisions based on timely input from the entire team, including customers and suppliers, and third party developers. The desired expectation is to move away from a pattern of hierarchical decision-making to a process where decisions are made across organizational structures by IPTs. These IPTs will integrate cost, schedule and performance data to provide a global perspective with detailed insight into the managerial and technical aspects impacting Government and industry.

IPTs are generally made up of representatives from the Government, the Contractor, subcontractors, vendors, and other industry partners and are chaired by the Government or Government representative. The Contractor (including subcontractors and vendors as necessary) shall attend, present as necessary, and participate in IPT meetings. During Government fiscal year, a minimum of 12 and a maximum of 26 IPT meetings shall be held at either the Contractor’s facility or via the Contractor-hosted telephone conference.

As part of the IPTs, the Contractor shall have responsibility for the following functions:

a. Monitoring and reporting of Subsystem status and progress;

b. Joint identification, evaluation, management, and reporting of risk mitigation and cost reduction initiative efforts;

c. Identification, collection, analysis, and reporting of appropriate metrics for measurement of cost/schedule control, engineering and production progress;

d. Joint evaluation and management resolution of major issues associated with hardware and software engineering, production, integration, test, and INCO activities;

e. Verification that the Contractor’s ‘early and often’ design disclosure process is providing data that is current, complete and accurate to third party developers;

f. Joint evaluation and management of the ILS effort; and

g. Joint recommended approval of data items requiring approval under this contract.

3.1.1.8 Coordination

The Contractor has responsibility for the OMS performance. Accordingly, the Contractor shall:

a. Participate in meetings (including coordination thereof) for efforts relating to the system.

b. Attend other contractor’s technical reviews and invite outside activities to its reviews when appropriate.

c. Provide, receive, and/or analyze information for others, which relates to the system.

3.1.1.9 Data Management

The Contractor shall manage the development and use of data under this contract so as to afford the

Government visibility of all data.

The Contractor shall maintain Contract Data Status for recording, planning, scheduling, and reporting the status of program data requirements including electronic mail transmittals; and maintain a list of all contractor and subcontractor data generated in support of this contract. Data management shall adhere to the Team Submarine Information Security Policy provided as Government Furnished Information (GFI).

3.1.1.9.1 Digital Data Management

All data shall be developed, managed, used, and delivered/exchanged electronically to the greatest extent practical. Communication via electronic mail (E-Mail) shall not relieve the Contractor of the responsibility to meet the contract requirements or change the contract requirements until a contract modification is issued by the Contracting Officer.

3.1.1.9.2 Internal Data / Data Access

The Contractor shall establish and maintain E-Mail capability, compatible with NAVSEA PMS401 (transmit and receive). A list of files transmitted and/or to be transmitted electronically, along with any procedures necessary for accessing them, shall be included in the Contractor’s Progress, Status and Management Reports.

[ELIN A001, DI-MGMT-80227]

The Contractor shall provide program related data to the Government upon request. Data stored electronically shall be made available to the Government via practical electronic means (e.g. Internet, remote dial-in, local login, etc.). When hard copy delivery is necessary, the Contractor shall deliver data no later than (NLT) 15 calendar days following the written request. The Contractor shall identify accessible data.

3.1.1.10 Government Furnished Information (GFI)

GFI, identified in Attachment 5, shall be managed in accordance with DFARS 252.227-7025. Email verification of receipt of GFI shall be provided per the Contract Data Requirement List (CDRLs) and specified distribution lists. GFI related issues (e.g., substandard quality, tardy submission) that have or may have an adverse effect on the performance will be referred to the COR for resolution. [ELIN A007, DI-MGMT-80596]

3.1.1.11 Government Furnished Property/Equipment/Material (GFP/E/M)

GFP/E/M, identified in Attachment 6, shall be managed in accordance with FAR 52.245-2. Email verification of receipt of GFP/E/M shall be provided per the Contract Data Requirement Lists (CDRLs) and specified distribution lists. GFP/E/M related issues (e.g., substandard quality, tardy submission) that have or may have an adverse effect on the performance will be referred to the COR for resolution. [ELIN A008, DI-QCIC- 80736]

3.1.2 Systems Engineering

3.1.2.1 Systems Engineering Management

In compliance with ANSI/EIA-632, the Contractor shall establish an engineering process to support the tasks listed in this SOW. The engineering process must balance performance, risk, cost, and schedule. Further, it shall employ iterative processes for requirement analysis, functional analysis and allocation, design synthesis and verification, and system analysis and control. [ELIN A00B, DI-SESS-81785]

The engineering process shall ensure:

a. The compatibility, interoperability and integration of all functional and physical interfaces

b. That system definition and design reflect the requirements for hardware, software, facilities, people, and data

c. Technical risks are identified and managed.

3.1.2.2 Open Systems Architecture Approach

The Government intends to procure system(s) having an Open System Architecture and corresponding components. As part of this contract, the Contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The Contractor shall demonstrate compliance with open systems architecture during all technical reviews.

As part of an open system architecture approach, the Contractor shall identify to the Government all

Commercial-Off-the-Shelf/Non-Developmental Item (COTS/NDI) components, their functionality and proposed use in the system, and provide copies of license agreements related to the use of these components for Government approval prior to use.

In satisfying the Government’s requirements, the following system architecture approach characteristics shall be utilized:

a. Open Architecture - The Contractor shall develop and maintain an architecture that incorporates appropriate considerations for re-configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability.

b. Modular, Open Design – The Contractor shall develop an architecture that is layered and modular and uses COTS/NDI hardware, operating systems, and middleware that utilize non-proprietary or non-vendor-unique, key Application Programming Interfaces (APIs). The Contractor’s design approach shall be applied to all subsystems and components. The Contractor shall provide the Government (and/or Government support contractors) electronic access to its integrated development environment throughout the term of the contract.

c. Modular Open Systems Approach (MOSA) –The Contractor’s design approach shall produce a system that consists of hierarchical collections of hardware configuration items (components). These components shall be of a size that supports competitive acquisition as well as reuse. The Contractor’s design approach shall emphasize the selection of components that are available commercially or within the Department of Defense (DOD), to avoid the need to redevelop products that already exist and that can be re-used.

As part of technical reviews (refer to paragraph 3.1.1.6), the Contractor shall, at a minimum:

a. Describe how the proposed system architecture meets the modular, open design goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable.

b. Describe its rationale for the modularization choices made to generate the design.

c. Provide rationale that explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system.

d. Provide rationale for maintaining continued access to cutting edge technologies and products from multiple suppliers.

e. Describe how it will mitigate the risks associated with technology obsolescence.

f. Describe how it will avoid being locked into proprietary or vendor-unique technology and reliance on a single source of supply over the life of the system.

3.1.2.3 Specification Requirement Verification Matrix (SRVM)

The Contractor shall develop the SRVM to ensure traceability between the test requirements and the performance specification. [ELIN A00C, DI-MISC-81283]

3.1.2.4 System Engineering and Design Analyses

The Contractor shall develop System/Subsystem Design Descriptions (SSDDs) [ELIN A015, DI-IPSC- 81432A NOT 1] in accordance with ANSI/EIA-632. In addition, the requirements outlined in section 3.1.2.5 (Design Analysis) shall be included in the SSDD.

3.1.2.5 Design Analysis

The Contractor shall conduct detailed system engineering, design, interface, and requirement analyses of the proposed software and hardware system. Materials and components to be incorporated into the cabinet design shall be specified including a listing of any hazardous materials or processes incorporated or used in the fabrication.

The design analysis shall consist of detailed examinations of the design techniques and materials that the Contractor plans to use to meet the requirements of the specifications. The design analysis shall be specific on both the system and component levels. Stress levels and safety factors, as appropriate, shall be identified for all mechanical and electrical parts. In addition to the system hardware physical considerations, the design analyses shall evaluate the system concept in terms of operability, reliability, producibility, maintainability, and supportability objectives using MIL-STD-1472G and MIL-HDBK-470A as guidance. The Contractor shall examine the design details and modify them, as necessary, to ensure that the system design will conform to established Navy precepts for minimum practical personnel and training requirements.

3.1.2.5.1 Failure Modes, Effects, and Criticality Analyses (FMECA)

The Contractor shall perform FMECA to the Lowest Replaceable Unit (LRU) level. The FMECA includes software and hardware failures. All potential software and hardware failure modes shall be postulated at the LRU level. Results of FMECAs shall be documented in the Failure Modes and Effects Analysis (FMEA) Report. [ELIN

A00W, DI-SESS-80980A]

3.1.2.5.2 Failure Reporting Analysis and Corrective Action System (FRACAS)

The Contractor shall analyze failure data, addressing: historical operating time and data; determination of the cause of each failure; down to the LRU and component level; identify LRUs and components that have had more than one failure; planned corrective actions; and implementation and results of corrective actions including resultant reliability. The Contractor shall analyze the root cause for all pattern failures (more than one) and shall submit a failed item report (Failure Analysis and Corrective Action Report (FACAR)) for Government approval. If corrective actions are required, the Contractor shall prepare the FACAR report. [ELIN A00X, DI-SESS-81315B] If deemed necessary by the Government, the Government will examine at the Contractor’s facility, the data from all failure and corrective action analyses.

The Contractor shall be responsible for correcting deficiencies discovered during the reliability test and for incorporating engineering change orders into the production baseline accordingly. Throughout the Test, Analyze and Fix, and FRACAS processes the Contractor shall plot failure data on a Reliability Growth Curve to assess system reliability. The Contractor may recommend additional specific testing to assess unique system characteristics.

3.1.2.6 Hardware Engineering

The Contractor shall develop, update and maintain a hardware functional, performance and interface requirements baseline and generate program-unique specifications for the OMS hardware.

3.1.2.6.1 COTS and NDI Requirements

The Contractor shall use NDI and COTS items to meet OMS system requirements. It is the Government's intent to use COTS and NDI documentation when available to reduce developmental costs. Design documentation for COTS and NDI is not required; however, the Contractor shall include the definition of the COTS/NDI physical and functional characteristics, including interfaces, for the application in the OMS design documentation. [ELIN

A016, DI-IPSC-81436A NOT 1], [ELIN A017, DI-SESS-81003E]

3.1.2.6.2 COTS / NDI License and Modification

The Contractor shall be responsible for the procurement of all licenses for COTS/NDI components delivered in this contract including both contractor-developed and third party COTS/NDI. If the Contractor needs to obtain a license for any COTS/NDI incorporated into a deliverable under this contract, the Contractor shall notify the Government immediately in writing. NDI License requirements shall be in accordance with the Basic Contract.

This notification shall specify whether the license(s) that needs to be procured are transferable to the Government and/or any of its other contractors. The Contractor shall obtain Government approval prior to use of these components.

The Contractor shall provide copies of license agreements for Government approval prior to modification of any COTS/NDI. If approved, the Contractor shall document any modified COTS/NDI components and provide the document to the Government. [ELIN A00D, DI-MISC-80508B]

3.1.2.6.3 Technology Refreshment

The Contractor shall implement a technology refreshment program to ensure the Contractor-furnished components/units are not technologically obsolete at final acceptance of each OMS EDM and production system.

3.1.2.6.4 Engineering Drawings

The Contractor shall develop and update engineering and drawing documentation to support all requirements of the system performance specification and the contract. Documentation and drawings shall be comprised of an Interface Control Document, Interface Design Description (IDD), product drawings, commercial drawings, and installation control drawings. [ELIN A018 DI-SESS-81248B], [ELIN A016, DI-IPSC-81436A

NOT 1], [ELIN A017, DI-SESS-81003E], [ELIN A01A, DI-DRPR-81242]

The Contractor shall prepare and update final production (level three) drawings for the OMS system.

[ELIN A019, DI-SESS-81000E]

3.1.2.7 Information Assurance (IA)

The Contractor shall work with the Navy IA lead to ensure the OMS program is compliant with the DOD and Navy IA requirements. If required, the Contractor shall support the Government’s system security certification and accreditation.

3.1.2.8 Safety Program

The Contractor shall establish and maintain a system safety program in accordance with MIL-STD-882E.

The Contractor shall develop a System Safety Program Plan (SSPP). The SSPP shall describe tasks and activities of system safety management and system safety engineering. If tasked via Technical Instruction, the Contractor’s description shall include any information required to identify, evaluate and eliminate/control hazards, or reduce the associated risk to an acceptable level. The SUBSAFE requirements are not applicable to the OMS equipment.

[ELIN A00E, DI-SAFT-81626]

3.1.2.9 Test and Evaluation Program Plan (TEPP)

The Contractor shall develop, maintain and update a Test and Evaluation Program Plan (TEPP) to describe all testing planned for the OMS systems and interfaces, including an EDM. The TEPP shall define the process for integration and testing of equipment. The TEPP shall also address recent advances in Automated Test tools and techniques that can be accommodated during integration, build check out, and certification testing. [ELIN A00F, DI-NDTI-81284], [ELIN A00G, DI-NDTI-80603A]

3.1.2.10 Environmental Compliance

The Contractor shall ensure that work performed under the contract complies with National Aerospace Standard (NAS) 411. The Contractor shall eliminate, or minimize as much as possible, the usage of:

a. Hazardous materials, including those on the Environmental Protection Agency (EPA) listing of 17 toxics

b. Class I or II Stratospheric Ozone depleting substances

c. Any of DOD’s top-ten Toxics Release Inventory (TRI) Chemicals.

3.1.2.11 Integrated Logistics Support (ILS)

The Contractor shall establish an ILS program for the equipment for the system development, production, and deployment. The Contractor shall generate and deliver source logistics package, in a consistent, common format. The Contractor shall designate an ILS manager to serve as the point of contact on ILS matters as well as participate in the various IPTs. [ELIN A00Y, DI-ILSS-80095]

3.1.2.11.1 Parts Management Program

The Contractor shall maintain a Parts Management Program that ensures:

a. use of parts that meet contractual requirements

b. reduce proliferation of parts through standardization, enhancement, equipment reliability and supportability

c. proactively manage obsolescence.

Processes and procedures for identifying common hardware consistent with the overall technology insertion baseline and accepting parts at the Contractor’s facility or vendor locations shall be established prior to Preliminary Design Review (PDR). The Contractor’s Parts Management Program shall follow the guidelines described in MIL-STD-3018 w/Change 1.

3.1.2.11.2 Reliability Centered Maintenance (RCM) Analysis and Products

The Contractor shall develop, maintain, and update RCM Products. The Contractor shall establish a thorough RMA program for the equipment at the beginning of the design phase that influences design for reliability and maintainability.

The Contractor shall develop reliability predictions for equipment and software per MIL-HDBK-217F and provide maintainability predictions to the Program Office. The Contractor shall conduct reliability and maintainability analyses at LRU level throughout design, development, and production to support availability predictions. The Contractor shall use the 12 Phase RCM process in accordance with MIL-STD-3034. The Contractor shall develop Planned Maintenance System (PMS) Documentation in New PMS Editor (NPE) software format. [ELIN A00Z, DI-MNTY-80990], [ELIN A010, DI-SESS-81497A]

3.1.2.11.3 Supportability Analysis

The Contractor shall conduct Supportability Analysis as an integral part of the systems engineering process to ensure that supportability is a primary concern in system design and to demonstrate that the OMS System is cost effectively supportable. [ELIN A00W, DI-SESS-80980A] These analyses shall be performed using MIL-HDBK- 502 and GEIA-STD-0007, as guidance. At a minimum, the analyses shall include Failure Mode Effects and Criticality Analysis (FMECA) and Reliability Centered Maintenance Analysis as follows:

a. Functional Requirements Identification with appropriate feedback to the design process;

b. Testability and Diagnostic Procedure Development;

c. Maintainability Optimization to include accessibility, testing and change out of components;

d. Identification of Maintenance Assist Modules (MAMs), if required to support trouble shooting of the equipment;

e. Identification of Unique Support and Test Equipment (S&TE);

f. Reliability Block Diagram including component criticality and failure rates for input to the

Readiness Based Sparing or other Government approved sparing model(s).

3.1.2.11.4 Failure Reporting

The Contractor shall research and provide root cause of failures of parts when requested for items whose failure rates indicate flaws in the design, production or maintenance procedures. [ELIN A00D, DI-MISC-80508B]

3.1.2.11.5 Supply Support

The Contractor shall maintain a supply support program which shall provide documentation to assist the

Government in the selection of spares, repair parts, and material to properly maintain all OMS systems identified in this SOW, including bay assets. The Contractor shall maintain a supply support inventory management system and make it available for use by authorized representatives of the Government. The Contractor shall provide recommended stowage data to support installation requirements. [ELIN A009, DI-MGMT-80259]

3.1.2.11.6 Provisioning Data

The Contractor shall provide and maintain provisioning technical data (PTD). Provisioning data shall be provided and input into the Interactive Computer Aided Provisioning System (ICAPS) in a mutually agreed upon format between the Government and the Contractor. The Contractor shall generate and deliver the PTD. [ELIN

A011, DI-SESS-81716]

The Contractor shall provide reliability data on all Lowest Replaceable Units (LRUs) for use by the

Reliability, Maintainability, and Availability (RMA) Working Group (WG) in calculating recommendations on quantities of on-board repair parts (OBRPs). The Contractor shall participate in the RMA WG and provide source data as required to support Readiness Based Sparing (Tiger Model) and TRIDENT Model calculations required for OMS systems. The recommendations shall not only include necessary initial OBRPs, but also those quantities of Installation and Checkout parts needed to support installation. The Contractor shall base the recommendations on reliability data gathered during the performance of the contract.

3.1.2.11.7 Interactive Electronic Technical Manual (IETM)

The Contractor shall develop technical manual S1000D Source Data Modules that integrate into the Prime

System Integrator developed AN/BQQ-10(V) IETM that documents the OMS system. The Data Modules shall provide a system overview, system configuration, safety, and emergency shutdown procedure that will aid in troubleshooting and repairing the system. The Data Modules shall also define maintenance concepts and requirements for the life of the OMS system that includes level of repair (O level), maintenance requirements, support, and test equipment needs. [ELIN A014, Technical Manual Contract Requirement No. NDMS-100001-

000], [ELIN A01G, DI-TMSS-81814A]

3.1.2.11.8 Unique Identification (UID) Requirements

If applicable, the Contractor shall identify and mark all parts requiring UID marking in accordance with

DFARS 252.211-7003. The Contractor shall provide for the inputting of the data into the UID registry as specified in the UID plan and the updating of the drawings and firmware as necessary. [ELIN A012, DI-MGMT-81804A]

3.1.2.11.9 Radio Frequency Identification (RFID)

The Contractor shall use passive RFID tags that comply with the EPC Global Generation 2, Class 1 RFID tag specifications in accordance with the Supplier Implementation Plan and the DoD Suppliers’ Passive RFID Information Guide at http://www.acq.osd.mil/log/rfid/index.htm. RFID tags shall be used in accordance with DFARS 252.211-7006 Passive Radio Frequency Identification and 211.275 Passive Radio Frequency Identification.

3.1.2.11.10 Packaging, Handling, Storage, and Transportation

The Contractor shall provide dimension (length, width, height) and weight data for the LRUs to support onboard repair part stowage estimates. [ELIN A00D, DI-MISC-80508B]

3.1.2.11.11 Nomenclature

If requested from the Government and/or the Navy Logistics Manager, the Contractor shall provide the nomenclature for the system. [ELIN A00D, DI-MISC-80508B]

3.1.2.12 Configuration Management and Documentation

3.1.2.12.1 Product Baseline Identification

The Product Baseline Configuration Items (CI) software and hardware shall be documented in the configuration item/product functional specification.

3.1.2.12.2 Configuration Control

The Contractor shall manage configuration changes in accordance with the contract and ANSI/EIA-649-B.

The Government approved product baseline and end items shall be changed only as a result of approved engineering change documentation.

3.1.2.12.3 Configuration Audits

The Contractor shall establish a configuration audit and review program that will ensure that the functional and physical characteristics meet the requirements of the OMS Performance Specification, Attachment 3.

The Contractor shall host and support the Government’s Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA) to establish the software and hardware product baseline. [ELIN A00H, DI- SESS-81022D] The FCA verifies that the system is in compliance with the performance specification. Satisfactory completion of all format and government witnessed testing as reflected in the approved SRVM and submission of the government signed test summary data sheets with the test report shall satisfy FCA requirements. The PCA shall consist of a formal examination of the “as-built” or “as-coded” configuration of all configured items of hardware, software, and firmware against their delivered design documentation (including part marking, specification, quality control records, engineering drawings, technical manuals, listings, operation and support documents, software and firmware regenerations, and other design documentation to establish the product baseline).

The Contractor shall develop a Configuration Audit Plan detailing all activities required to perform configuration audits for the items under this contract. Preparation of the plan shall be closely coordinated with the Government. It shall include, but not be limited to, the following:

a. Schedules (time and place) of all audits;

b. Persons participating (Contractor and Government) and extent of participation;

c. Identification of the configuration items to be audited;

d. Description and extent of the audit to be performed;

e. Description of Contractor’s audit support such as but not limited to personnel, equipment, facilities;

The Contractor shall provide all facilities, hardware, documentation and services necessary to conduct the

PCA.

A moratorium shall be imposed on all changes while the audit is conducted.

All changes in the process of being incorporated into the software and hardware and documentation shall be presented to the Configuration Audit Teams as the list of outstanding changes.

3.1.2.12.4 Configuration Status Accounting

The Contractor shall develop and maintain procedures that track the status of changes from the baseline, effectiveness, and status of implementation of Government approved changes. Data elements and related features used shall comply with ANSI/EIA-649. [ELIN A00J, DI-SESS-81253B]

3.1.2.13 Problem Reporting System

The Contractor shall establish a single system for the identification, tracking, and resolution of all hardware, software and baseline documentation problems identified during system development, integration and testing, and production. In addition, the system shall be used to track test documentation problems and technical manual errors. Status on problems shall be reported to the IPTs, Program Reviews, Technical Reviews, and prior to final acceptance of each OMS production system. All problems covered in this system shall be included with the Contractor’s Progress, Status and Management Report. [ELIN A001, DI-MGMT-80227]

3.1.2.14 Engineering Change Documentation

3.1.2.14.1 Engineering Change Proposal (ECP)

The Contractor shall prepare and submit Class I ECPs to the Government for approval or disapproval as required. Proposed changes that would affect the form, fit, or Government controlled baseline, shall be implemented only after a Class I ECP is approved and authorized by the Procuring Contracting Officer (PCO) via a contract modification. [ELIN A00K, DI-SESS-80639D]

The Contractor is responsible for the development of ECPs and for all aspects of the implementation of the

ECP which are required to correct deficiencies. Implementation shall include, yet not be limited to, retrofit of all configuration items and provision of support resources called for under the contract to reflect any changes to be accomplished by the ECP to the extent necessary to allow all configuration items provided under this contract to be operated and maintained with the same support resources, such as operation and maintenance manuals, provisioning technical documentation, and maintenance repair parts for such items. The Contractor may also propose changes which are solely for the benefits of the Contractor. For example, the Contractor may propose a change to an item that marginally meets baseline requirements and may require correction at greater expense later in the contract.

Changes required to correct deficiencies or which are solely for the benefits of the Contractor, if accepted by the PCO, shall only be incorporated at no change in contract price. Changes which are directed by the Government shall be incorporated in accordance with the contract “CHANGES” clauses.

The Contractor shall prepare and submit Engineering Change Proposal System Safety Report (ECPSSR) to the Government for approval. Summarized results of analyses, tests and tradeoff studies conducted on proposed engineering design changes shall be included in the ECPSSR. [ELIN A00L, DI-SAFT-80103B NOT 1]

3.1.2.14.2 Class II ECPs, Minor RFVs

Proposed changes that would not affect form, fit, or function of a configuration item identified in a

Government controlled baseline, shall be submitted to the COR as Class II ECPs and minor RFVs for concurrence in classification only. [ELIN A00K, DI-SESS-80639D], [ELIN A00M, DI-SESS-80640D]

If the COR does not notify the Contractor otherwise within fifteen (15) calendar days after submittal, concurrence may be assumed. Class II changes that receive such concurrence will be implemented by the Contractor.