SOW_Rev_2.pdf
PDF 506 KB Posted
- Attached to
- Embedded Global Positioning System (GPS)/Inertial navigation System (INS) Engineering, Manufacturing, and Development (EMD) Federal contract opportunity
- Solicitation number
- FA854018R0007
View the file
Other files for this federal contract opportunity
Show all 25
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
FD2060-17-30546 For Official Use Only
REVISION 2
5 OCTOBER 2018
STATEMENT OF WORK
For the
EMBEDDED GLOBAL POSITIONING SYSTEM (GPS) / INERTIAL NAVIGATION
SYSTEM (INS) – MODERNIZED (EGI-M) ENGINEERING, MANUFACTURING AND
DEVELOPMENT (EMD) EFFORT
NORTHROP GRUMMAN CORPORATION (NGC)
PR: FD2060-17-30546
Date: 5 October 2018
Prepared by:
AFLCMC/WNY
235 Byron Street, Ste 19A
Robins Air Force Base, Georgia
Procurement Contract Officer:
Oya Harrison, AFMC AFSC/PZCA
Positioning, Navigation, & Timing Program Office (PNT PO)
Program Manager:
Mark J. Friesen, Lt Col, USAF
Phone:
Commercial: (478) 222-2981
DSN: 497-2981
Distribution Statement C: Distribution authorized to U.S. Government agencies and their Contractors (Administrative or Operational Use; 4-4-14). Other requests for this document shall be referenced to AFLCMC/WLNCC, Robins AFB, GA 31098.
EGI-M EMD Effort SOW v1.0
NGC EGI-M EMD SOW Revision History
Revision Date: Changes/Notes 0 21 Feb 2018
1 26 Mar 2018 FAR Update, Para 4.6
2 27 Apr 2018 Updated Para 3.4.7.2.3 Interlocks
3 30 Apr 2018 Changed Para 3.1.4 Took out 10 Business Day requirement for bi-weekly telecon agenda. Changed 3.4.3.6 removed PU since this effort does not support PUs
4 18 May 2018 -3.1.2 Defined immediately as “at minimum at bi-weekly teleconference” -3.2 inserted functional deleted all -3.3 updated language to reflect clarification on MIL standard usage of MIL handbook and removed statement -3.3.5.4 Removed statement and CDRL -3.3.6.3 Removed statement and CDRL -3.4.3.2 updated language to reflect clarification on MIL standard usage of MIL handbook.
-3.4.3.3 Inserted corrected unless the Government provides relief to the requirement 3.4.7.3. Third part application space language updated to clarify App developer guide -3.4.9 Deleted Para -3.4.10 Inserted Cpk= min [(USL-µ)/3σ , (µ-LSL)/3σ] ≥ 1.67 and removed at least 1.67.
-3.5.1.4, 3.5.7.6 Defined timeframe and deleted immediately -3.5.5 Inserted LRU additional language -3.5.7.7.1 Updated reference AS5553A to AS5553B -3.6.2 Inserted The CTP Cybersecurity Test(s) deleted This Test -3.6.3 Updated reference to ISO/IEC/IEEE 29119 -3.7 Updated “Flight test will” rather than “shall”.3.9.2.1 Clarified that government will provide CPINs -3.9.2.2 Updated to remove .abs format -3.11 & 3.4.1 Updated by deleting “over the period of twenty years following the completion of this EMD Effort” -3.11.4 Updated to read The End Item Data Package (EIDP) will be provided with each unit. Each item shall be delivered with appropriate condition/factory identification tags. A Bill of Material (BOM) shall be delivered once all engineering parts are complete specifying the end item and all subordinate/child components by nomenclature, NSN, PN, quantity, and any software by version, and CPIN for each configuration
5 22 May 2018 3.9.1.1 Updated to read The EDM assets designated for delivery to the Government shall be later upgraded by the Contractor to the final Production Representative Unit (PRU) under contractual direction upon Government request.
6 25 May 2018 Changed para 3.4.7.3 FACE to non-version specific
7 29 May 2018 Edited para 3.4.7.3: remove FACE ver 3.0 reference, add reqmt to conform to ARINC 653 reqmts for FACE safety operating system interface. Inserted CDRL requirement
8 6 September 2018 Split para 3.5.1 into Level 2 and Level 3 Tech Data Package. Added 3.5.1.1 & and 3.5.1.2.
9 5 October 2018 Added to 3.5.1.1& 3.5.1.2: Technical Data, as defined in the Rights in Technical Data—Non commercial Items clause of this contract, Computer Software, as defined in the Rights Noncommercial Computer Software and Noncommercial Computer Software Documentation clause of this contract
Table of Contents
1.0 SCOPE
1.1 Background
1.2 Purpose
1.3 System Description
2.0 TECHNICAL DOCUMENTS
2.1 EGI-M EMD Reference Documents
2.1.1 EGI-M Systems Requirements Document (SRD)
2.1.2 Universal ICD (IS-EGI-179)
2.1.3 EGI-M Test and Evaluation Master Plan (TEMP)
2.1.4 CI-MGUE/AV-861E
3.0 REQUIREMENTS
3.1 Program Management
3.1.1 Integrated Program Management Report
3.1.2 Monthly Status Report
3.1.3 Integrated Master Schedule
3.1.4 Bi-weekly Teleconference
3.1.5 Integrated Master Plan (IMP)
3.1.6 Cost and Analysis Reporting
3.2 Program Technical Meetings/Reviews
3.2.1 Kick-Off Meeting
3.2.2 Working Group (WG) Participation
3.2.3 Critical Design Review (CDR)
3.2.4 Test Readiness Review (TRR)
3.2.5 Production Readiness Review (PRR)
3.2.6 Functional Configuration Audit (FCA)
3.2.7 Physical Configuration Audit (PCA)
3.3 System Safety
3.3.1 System Safety Program
3.3.2 Airworthiness Certification Criteria Report
3.3.3 Failure Reporting, Analysis, and Corrective Action System
3.3.4 Interlocks and Incompatible Modes
3.3.5 DO-178C Requirements
3.3.6 DO-254
3.3.7 Automatic Dependent Surveillance Broadcast (ADS-B)
3.4 Engineering Design and Manufacturing
3.4.1 Obsolescence Mitigation
3.4.2 Notification of Revision
3.4.3 Hardware
3.4.4 Tool and Database Processes
3.4.5 Cybersecurity
3.4.6 Deviations and Waivers
3.4.7 Software
3.4.8 MSO-C145B
3.4.9 Reserved
3.4.10 Quality System
3.5 Technical Data
3.5.1 Technical Data Package
3.5.2 User Integration Guides (UIGs)
3.5.3 Data Accession List (DAL)
3.5.4 EDM Technical Drawings
3.5.5 PRU Technical Drawings
3.5.6 Technical Orders
3.5.7 Engineering Documentation
3.6 Testing
3.6.1 Test and Evaluation Strategy (TES)
3.6.2 Cybersecurity Test
3.6.3 Software Test
3.6.4 Acceptance Test
3.6.5 Environmental Test
3.6.6 Electromagnetic Interference (EMI) Test
3.6.7 Formal Qualification Test (FQT)
3.6.8 Failure Modes and Effects Critical Analysis (FMECA) & Failure Modes and Effects Testing (FMET)
3.6.9 Platform Integration Technical Support
3.6.10 Government Developmental Test & Evaluation (DT&E)
3.7 Deficiencies
3.8 Repairs
3.9 Asset Deliverables
3.9.1 Hardware Deliverables
3.9.2 Software Deliverables
3.10 Installations
3.11 Logistics
3.11.1 Configuration Management Plan
3.11.2 Packaging, Handling, Storage and Transportation
3.11.3 Item Unique Identification (IUID) and Identification Marking
3.11.4 Bill of Materials
3.11.5 Electrostatic Sensitive Materials
3.12 Reporting of Government Property
3.12.1 Records
3.12.2 Receipt and Return of GFE/GFP
3.12.3 Loss of Government Property
3.12.4 Government Systems
3.13 Travel
3.13.1 Trip Reports
4.0 GENERAL INFORMATION
4.1 Green Procurement Program (GPP)
4.2 Relationship of Contractor with Sub-Contractors/Vendors
4.3 Data and Data Rights
4.4 Procedures for Invoicing/Payment/Acceptance
4.5 Information Security
4.6 Inspection of Services Clause
4.7 //Reserved//
4.8 Continuation of Mission-Essential Services During a Crisis
4.8.1 Definition of Mission-Essential Services
4.8.2 Designation of Services as Mission-Essential
4.9 Security Requirements
4.9.1 Security Clearance
4.9.2 Government Security Regulations
4.9.3 Operations Security (OPSEC)
4.9.4 Communications Security (COMSEC)
4.9.5 Security Incident or Violation
4.9.6 Security of Contractor System(s)
4.9.7 Access to Government Facility or Military Installation
4.10 Environmental Management System
4.10.1 Location Where Services are to be performed
4.11 Affirmative Procurement Program (APP)
4.12 Safety and Health
4.12.1 Compliance
4.12.2 Updates and Revisions
4.12.3 Voluntary Protection Program (VPP)
4.12.4 Applicability to Sub-Contractors
4.13 Trafficking in Persons
4.13.1 Compliance
4.13.2 Reporting
4.14 Contractor Manpower Reporting
4.14.1 Records Keeping
4.14.2 Accounting
4.14.3 Labor Hours
4.15 Invoicing/Payment and Receipt/Acceptance
4.15.1 Electronic Submissions
4.15.2 CDRL Deliverables
4.15.3 Services
APPENDICES
APPENDIX A - ACRONYMS
APPENDIX B - REFERENCED DOCUMENTS
APPENDIX C - INCENTIVES
APPENDIX D - DELIVERABLES
FD2060-17-30546 For Official Use Only
1.0 SCOPE
1.1 Background
The Embedded Global Positioning System (GPS) / Inertial Navigation System (INS) – (EGI) system was developed approximately 20 years ago and is the navigation avionics system of choice for nearly 75% of the Department of Defense (DoD) aviation assets.
GPS Modernization and Civil Aviation advancements through the Federal Aviation Administration (FAA) NextGen Program have resulted in the need for upgrades to military aircraft in order for them to remain in compliance with applicable Civil Mandates and Public Law. Modernization of the EGI system will provide a path to meeting the Civil Mandate for adoption of Automatic Dependent Surveillance - Broadcast (ADS-B) Out and allow the DoD to remain in compliance with public law. The mandates specific to GPS M-Code and ADS-B Out are as follows:
GPS M-Code: Public Law 111-383, effective 7 January 2011, states that unless the equipment is capable of receiving military code, none of the funds authorized to appropriate for the Department of Defense may be obligated or expended to purchase user equipment for the Global Positioning System during fiscal years after fiscal year 2017.
ADS-B Out: 14 CFR §91.225 and § 91.227 direct that after January 1, 2020, and unless otherwise authorized by Air Traffic Control, no person may operate an aircraft in Class A airspace unless the aircraft has equipment installed that meets a group of requirements established by the FAA for Extended Squitter Automatic Dependence Surveillance- Broadcast (ADS-B). DoD aircraft are not exempt from this policy.
The Embedded Global Positioning System (GPS) / Inertial Navigation system (INS) – Modernized (EGI-M) will use a Precise Positioning Service (PPS) GPS as opposed to the commercial Standard Positioning Service (SPS) GPS. PPS is not available commercially and is regulated by a security device controlled by the GPS Directorate and the National Security Agency; SPS does not meet current DoD GPS requirements. In addition, modifications to the EGI-M are not of a commercial nature. The EGI-M will revolve around military applications such as: anti-jamming, weapon hand-over/interface, targeting, interface with encrypted radios, aircraft carrier alignment, gunfire vibration, electro-magnetic interference, and stricter military environmental requirements. These changes are not minor, nor do they have commercial applications.
1.2 Purpose
This Statement of Work (SOW) defines the EGI-M Engineering and Manufacturing Development (EMD) effort to Contractor activities, materials and facilities. The EMD phase builds on the work done under previous Pre-Phase I and Technology Maturation and Risk Reduction (TMRR) contracts. The EMD phase implements the five pillars of the EGI-M program as it integrates M-Code, ADS-B Out, reduces the configuration count through software modularization and common component hardware, addresses obsolescence issues and adds resiliency features to enable rapid response to evolving threats at reduced costs when compared to the current system design and architecture.
FD2060-17-30546 For Official Use Only
Designing for resiliency includes such features as use of open architectures, standard interfaces, and modular software, designing for future growth and provisions for future incorporation of alternative navigational data sources.
The purpose of the EMD effort is to develop, build, and test a product to verify that the EGI-M’s SRD requirements have been met and to support production and deployment decisions. EMD completes all needed hardware and software detailed designs, retires any open risks, builds and tests prototypes to verify compliance with capability requirements, and prepares for production. The EMD effort includes the establishment of the initial product baseline for all EGI-M targeted platform configuration items. This effort will be accomplished by Northrop Grumman Corporation (NGC), hereafter known as the Contractor for AFLCMC/WNY, hereafter known as the Government.
The EMD effort is intended to accomplish the realization of the EGI-M system as postulated in the TMRR phase, which will conclude with a Preliminary Design Review (PDR). The EMD effort will continue the realization process from that point. The requirements for the EMD effort include the engineering design of hardware and software, development of the engineering technical data package, technical support, EGI-M Flight Testing support, Critical Design Review (CDR), Test Readiness Review (TRR), Manufacturing Readiness Assessment (MRA), Functional Configuration Audit (FCA), and Physical Configuration Audit (PCA) and the production of Engineering Development Model (EDM) assets, Production Representative Units (PRU). The Contractor shall put forth a concerted effort to utilize or update/modify existing test equipment assets required to successfully test EDM and PRU units. The development of any new test equipment will require Government approval. Technical Interchange Meetings (TIMs) may also be held to resolve technical or engineering issues, but whenever possible, TIMs should be in conjunction with scheduled events such as the CDR, TRR, etc.
The Contractor is required to manufacture and deliver the EGI-M EDM and PRU assets.
The Contractor shall furnish all manpower, parts, and materials for the manufacture of the EDM and PRU assets structural mounting components, and all required hardware. The EDM and PRU assets shall be developed and manufactured by the Contractor.
Installations for platform integration and flight testing will be managed by the respective platform Program Offices.
The Contractor may be incentivized for early EDM and PRU delivery. Timing performance incentives may also apply if the Contractor can meet the requirements specified in Attachment C. See Attachment C for delivery and timing incentive details.
The Period of Performance (PoP) for this task shall be 24 months After Contract Award (ACA). There are two contract option periods of 12 months each.
1.3 System Description
The EGI-M system is a self-contained, all-attitude, tightly-coupled navigation system providing outputs of linear and angular acceleration, linear and angular velocity, position, attitude (roll, pitch, and yaw), platform azimuth, magnetic and true heading, altitude, body
FD2060-17-30546 For Official Use Only angular rates, time tags and Universal Time Coordinated (UTC) synchronized time. The EGI-M will be designed to accommodate robust certification to meet DoD mandates as well as civil statutory requirements and DO-178 and DO-254 standards. EGI-M will incorporate features such as Military Code (M-Code) and ADS-B Out. This process will be done incrementally. Initially, this contract emphasizes targeted platforms designated by the Positioning, Navigation, and Timing Program Office (PNT PO). For the EMD effort, those targeted platforms under this contract are the F-22 and E-2D aircraft platforms, but these platforms may change as platform schedules dictate. Beyond this EMD effort, the scope of EGI-M integration will expand to other aircraft platforms. The EGI-M is designed to provide maximum flexibility, to meet the most challenging military requirements, along with civil interoperability capabilities.
2.0 TECHNICAL DOCUMENTS
2.1 EGI-M EMD Reference Documents
The following technical documents will be used to identify specific requirements for the activities in developing, constructing, and testing the EDM and PRU assets as identified and specified within this EGI-M EMD effort Statement of Work. In situations where a document is still evolving or is a living document, the most current draft, or latest approved version of the document shall be used and will be identified by the Government at the time of the proposal. The most critical documents are specified in the following paragraphs; all other documents are listed throughout this SOW and enumerated with specific details of each in Appendix B, Referenced Documents.
2.1.1 EGI-M Systems Requirements Document (SRD)
The System Requirements Document (SRD) is the document for the EGI-M governing configuration (hardware to include physical and electronic, and software) functionality, system level functional, performance, and interface requirements. The SRD provides all requirements for the core EGI-M; additional requirements identifying platform specific requirements will be provided by each of the aircraft platforms via appendices that identify those unique requirements. The unique requirements may be either physical, power, messaging specific, or any combination thereof.
2.1.2 Universal ICD (IS-EGI-179)
The IS-EGI-179 document captures the EGI-M message set to the host system. It defines the Core (non-missionized) EGI-M operational messages for the MIL-STD-1553B, ARINC-429, and Ethernet system busses. The messages will be common in all EGI-M implementations.
2.1.3 EGI-M Test and Evaluation Master Plan (TEMP)
The purpose of the TEMP is to describe the Test and Evaluation strategy for the EGI-M program. The TEMP will be used to 1) Provide an overall test management plan within the program acquisition strategy 2) Document T&E schedule and resource requirements
FD2060-17-30546 For Official Use Only
3) Identify overall T&E activities by the Contractor and the Government 4) Guide the development of detailed test methodologies and test plans.
2.1.4 CI-MGUE/AV-861E
Technical Requirements Document; Military GPS User Equipment (MGUE) Aviation Form Factor Requirements.
3.0 REQUIREMENTS
3.1 Program Management
The Contractor shall manage the administrative, technical, manufacturing, and financial functions of the EGI-M EMD effort. This includes planning, organizing, staffing, controlling and directing the effort to successfully execute the program. Program management shall maintain a status of the effort towards achieving the SOW objectives, including all technical and manufacturing activities, problems or deficiencies, impacts, recommended solutions, and results of meetings and reviews. The Contractor shall establish a single person as Point of Contact (POC) to perform program management tasks, and provide a qualified, knowledgeable alternate in the POC’s absence. The Contractor shall keep the Government updated on contract status, schedules, and any issues that may arise (e.g.
circumstances that would cause delay, material shortages, etc.). For a key milestone, delivery, or Government monitored test event, in the event that a potential scheduling slip or a scheduling impact of more than ten (10) days is identified as a probability, the Contractor will immediately notify the Government of the potential schedule slip and its magnitude.
M-Code technology has not been currently cleared for foreign release, therefore, the Contractor shall not release M-Code technology to foreign customers without obtaining State Department consent. The Contractor shall comply with foreign participation policies with regards to component parts suppliers.
3.1.1 Integrated Program Management Report
The Contractor shall develop, operate and maintain a financial management tracking system. The Contractor shall provide access to supporting reports and documentation that augment the joint government/Contractor system management capability. The Contractor shall implement and maintain an Earned Value Management System (EVMS) that incorporates cost/schedule variance reporting. The EVMS shall be used in the management of cost and/or fixed-price portions of this contract. The EVMS shall track program cost and schedule against established criteria and milestones. The reporting level is defined as the cost account level. The Contractor shall develop and maintain a Work Breakdown Structure (WBS) to execute all tasks IAW the MIL-STD-881C and DoD 5000.04-M-1 or the current version at the time of Request For Proposal (RFP) release.
The Contractor shall comply with Defense Federal Acquisition Regulation Supplement (DFARS) 252.234-7001, Notice of Earned Value Management System (Apr 2008) and DFARS 252.234-7002, Earned Value Management System (May 2011). The Contractor shall prepare an Integrated Program Management Report IAW DoDI 5000.02.
FD2060-17-30546 For Official Use Only
(CDRL #A005, DI-MGMT-81861A, Integrated Program Management Report (IPMR))
3.1.2 Monthly Status Report
The Contractor shall provide Monthly Status Reports (MSR) in accordance with (IAW) the Contract Data Requirement List (CDRL), DD Form 1423-1. The report shall cover program management, engineering, and technical support activities. The Contractor shall also document CDRLs delivered for the month and include a sixty (60) day CDRL delivery forecast, task status, contract issues, and related actions implemented in order to meet objectives or overcome contractual barriers. The Contractor shall include in the MSR an overview of cost to date; this shall include funds expended by task, cumulative man-hours, percentage of work completed by task, and funds remaining on the contract. The Contractor shall also address Government approved travel (both conducted during the month and a sixty (60) day travel forecast) and travel funds expended/remaining. The Contractor shall inform the Government of problems or changes adversely affecting cost, schedule, or performance requirements at minimum during bi-weekly teleconferences.
Schedule slippage, problems or other discrepancies between planned, actual and forecasted program progress shall be analyzed and reported in the MSR through a narrative analysis of cause, effect, and proposed or accomplished corrective action. The issue(s) will be discussed between the Contractor and Government and a mutual solution agreed upon. If a solution cannot be agreed upon, the Government reserves the right to direct action if there is no agreement. The Contractor shall implement the solution and provide the Government weekly feedback on the progress and outcome until the issue has resolved.
(CDRL #A001, DI-MGMT-80368A/T, Monthly Status Report (MSR))
3.1.3 Integrated Master Schedule
The Contractor shall perform production scheduling, directing, and monitoring; and shall provide an Integrated Master Schedule (IMS) updated quarterly. In the event of any unplanned or unforeseen schedule issues that impact key milestones and that add more than ten (10) days to the schedule, the Contractor shall notify the Government PM immediately. The Contractor shall provide a change document as an attachment identifying the change in the IMS. The Contractor shall coordinate with the PNT PO to establish the necessary corrective actions required to mitigate or minimize risks or implement modifications to the EMD effort. The Contractor shall provide rationale for any scheduling changes with an impact of greater than ten (10) days and a recovery plan to ensure timely delivery of EDM/PRU assets and technical data.
(CDRL #A077, DI-MGMT-81861A/T, Integrated Master Schedule (IMS))
3.1.4 Bi-weekly Teleconference
The Contractor shall host and chair a bi-weekly teleconference at a time agreed upon at the kickoff meeting to keep stakeholders up to date on contract status and issues.
Stakeholders will be identified at the kickoff meeting. The Contractor shall be responsible for recording action items and following those action items to their conclusion. The Contractor shall provide a list of action items to the Government, and update that list
FD2060-17-30546 For Official Use Only following each teleconference. The status of action items collected in other meetings (e.g. CDR, TRR, FQT, etc.) shall be discussed in the bi-weekly teleconference. Close-out of action items shall be coordinated with the Government. The Contractor shall send minutes, which will include the action items and status, to all stakeholders within ten (10) business days following the teleconference. Presentation materials should be provided in those instances where complex issues are discussed or if the Contractor feels it is warranted.
(CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
3.1.5 Integrated Master Plan (IMP)
The Contractor shall amend the TMRR IMP and IMS so that it clearly states the plans for executing this EMD effort. The IMS shall include all Systems Engineering, Program Management, Contractor Testing, and logistics events such as CDR, TRR, PRR, and FCA/PCA. The Contractor shall execute the EMD effort events specified within the IMS IAW the IPMR. In the event of any unplanned or unforeseen schedule issues, the Contractor shall notify the Government PM early enough to allow PNT PO to establish corrective actions/mitigate risks. The Contractor shall provide a change document as an attachment identifying the change in the IPMR.
(CDRL #A005, DI-MGMT-81861A, Integrated Program Management Report (IPMR))
3.1.6 Cost and Analysis Reporting
3.1.6.1 Contract Work Breakdown Structure (CWBS) The Contractor shall develop and maintain a CWBS to execute all tasks IAW MIL-STD-881C and DoD 5000.04-M-1 or the current version at the time of RFP release. The CWBS shall encompass the total contracted effort and be extended to the lowest manageable units of work IAW the Office of the Secretary of Defense (OSD), Defense Cost and Resource Center (DCARC), Deputy Director of Cost Assessment (DDCA)-approved Cost and Software Data Reporting (CSDR) Plans. Engineering Change Proposals (ECPs) and supplemental agreements shall require the same level of detail as the basic contract. The Contractor shall use the CWBS as the framework for contract planning, budgeting, and reporting of cost, schedule, and performance. The Contractor shall align the CWBS with the IMP and
IMS.
(CDRL #A047, DI-MGMT-81334D, Contract Work Breakdown Structure (CWBS)) (CDRL #A077, DI-MGMT-81816A/T, Integrated Master Schedule (IMS))
3.1.6.2 Cost and Software Data Reporting (CSDR) The Contractor shall systematically collect and report actual contract costs in order to provide DoD cost analysts with needed data to estimate future costs. The Contractor shall establish management procedures that provide for the generation of timely and reliable information for the Contractor Cost Data Reports (CCDRs) and Software Resources Data Reports (SRDRs) required by the CCDR and SRDR data items of this contract. The Contractor shall require and levy the requirement for CSDR reporting to sub-Contractors at any tier with a subcontract that exceeds $50 million or any subcontracts valued between $20 million and $49 million that are for software efforts or designated by the Government as being high risk, high value
FD2060-17-30546 For Official Use Only or high technical interest. The Contractor shall notify the Government if any subcontract exceeds $50 million, the Contractor changes subcontractor(s) or makes new subcontract awards. The Contractor shall use the Government-approved CSDR for this contract, DD Form 2794, and the related Resource Distribution Table as the basis for reporting. The CSDR shall include cost and useful life information for support equipment with a cost equal to or greater than $100,000. The Contractor shall prepare reports IAW DFAR 252.234-7004, DoD 5000.02 and DoD 5000.04-M-1.
3.1.6.2.1 Cost and Software Data Reporting Requirements The Contractor shall provide the document requirements of DFARS 252.234-7003 (b) and the associated DFARS 252.234-7003 (c). Additional clarification is provided for item 252.234-7003 (b)(5). The CSDR included in the solicitation has been approved by the government. The Contractor may provide comments on the adequacy of the CSDR contract plan and related Resource Distribution Table. Per DoDM 5000.04, Contractors may submit proposed changes to the contract CSDR with the comments, but shall not alter the approved plan in the proposal response to the Government. Additional clarification is provided in DFARS 252.234-7003 (b)(6). The Contractor is required to submit a DD Form 1921, Cost Data Summary Report and DD Form 1921-1, Functional Cost-Hour Report with the proposal; therefore the WBS within the proposal shall conform to the CWBS and the Government-approved CSDR Plan for the contract.
(CDRL #A048, DI-FNCL-81565C, Cost Data Summary Report (DD Form 1921)) (CDRL #A049, DI-FNCL-81566C/T, Functional Cost-Hour Report (DD Form 1921-1)) (CDRL #A050, DI-FNCL-81567C, Progressive Curve Report (DD Form 1921-2)) (CDRL #A051, DI-FNCL-81765B, Contractor Business Data Report (DD Form 1921- 3)) (CDRL #A052, DI-MGMT-82035, Software Resources Data Reporting)
3.2 Program Technical Meetings/Reviews
All meetings shall be consolidated to the fullest extent to save time and travel cost.
Technical Interchange Meetings (TIMs) shall be convened to discuss technical issues impacting EMD events such as the CDR, TRR, PRR or delivery of EDM or PRU assets.
All Program/Engineering Technical Review events require the Contractor to develop and provide the CDRL deliverables indicated below. Program Management Reviews (PMRs) shall be held quarterly, and should be tied to existing events (i.e. CDR, TRR, or PRR) as practical to minimize impact to schedule and travel costs. In addition, TIMs shall be held on an as-needed basis to resolve persistent or urgent technical issues. PMRs shall include an updated program schedule, projected delivery schedule, cost status and status/description of contract modifications. Each of the Program/Engineering Technical Review events may include participation, as required, by prime integrator Contractors that directly support the Government’s targeted platforms to ensure the Contractor is provided with complete and accurate platform design, development, integration, and test requirements. The Program/Engineering Technical Review events shall be considered successfully completed when critical action items and all exit criteria are accomplished.
The Contractor shall develop and distribute an agenda, presentation materials, and minutes. Government personnel may visit the Contractor’s facilities as appropriate to monitor program activities and progress throughout the period of this contract effort.
FD2060-17-30546 For Official Use Only
Contractor formal presentations shall address functional aspects of the program progress to date. Each presentation shall summarize the efforts to date and provide a forecast of the contract estimate to completion.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
3.2.1 Kick-Off Meeting
The Contractor shall conduct a Kick-Off Meeting NLT thirty (30) calendar days after award of contract at the Contractor’s facility. The purpose of the Kick-Off Meeting is to ensure that the Contractor understands the EGI-M EMD effort requirements and to discuss their plan for contract execution. The Contractor shall prepare and submit an agenda, presentation material, and meeting minutes for the Kick-Off Meeting.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
3.2.2 Working Group (WG) Participation
The Contractor shall provide support for the EGI-M EMD effort through participation in designated Working Groups (WG). The Contractor shall provide support through attending the IS-EGI-179 Working Group, Integrated Test Team (ITT) Working Group, Third Party App Space Development, Platform Interface Control Working Group, Product Support Working Group, as well as any Security Systems Engineering (SSE) Working Groups. This support by the Contractor shall include providing technical expertise, data analysis, fault/failure analysis, and deficiency resolution. The Contractor may be required on occasion to provide briefings, which shall be coordinated with the Government, ahead of convening the working group. On occasion, the Contractor may be required to participate via teleconference to minimize costs as applicable. If the working group is convened at the Contractor facility, only CDRL #A003 is required; if the Contractor travels to a location outside their facility for Working Group participation, only CDRL #A046 is required.
(CDRL #A003, DI-ADMN-81250A/T, Minutes) (CDRL #A046, DI-MISC-80508B/T, Trip Report)
3.2.3 Critical Design Review (CDR)
The Contractor shall conduct a Critical Design Review (CDR) when the detailed design is completed. This review shall be performed to ensure that the EGI-M can proceed into fabrication, demonstration, and test phases, and can meet the stated performance requirements within cost, schedule, and risk constraints. The data to be reviewed shall consist primarily of hardware and software design data. The CDR shall also address design verification methodologies, safety and risk analyses. The Contractor shall resolve all CDR issues, subject to the approval of the Government. The Contractor shall provide the agenda for the meetings, presentation material and provide the minutes. The Contractor shall be responsible for recording action items and following them to their
FD2060-17-30546 For Official Use Only conclusion. The Contractor shall provide a list of action items to the Government, and provide updates/status as part of the bi-weekly teleconferences. Close-out of action items shall be coordinated with the Government.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
3.2.4 Test Readiness Review (TRR)
The Contractor shall conduct a Test Readiness Review (TRR) and provide assurance that the Contractor is ready to proceed to formal testing. The TRR also assesses the system under review for development maturity, cost/schedule effectiveness, and risk.
Completed and approved test plans/procedures, identification and coordination of required test resources shall be provided to the Government prior to TRR entry. Approval to proceed into formal testing is provided at the conclusion of a successful TRR. The TRR shall also determine if the identified risk level is acceptable to the program leadership. The Contractor shall be responsible for recording action items and following those action items to their conclusion/resolution. The Contractor shall provide a list of action items to the Government, and provide updates/status as part of the bi-weekly teleconferences. Close-out of action items shall be coordinated with the Government.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
3.2.5 Production Readiness Review (PRR)
The Contractor shall perform a Production Readiness Review (PRR) to demonstrate that the EGI-M is ready to proceed to production. The PRR evaluates the full production-configured system to determine if it correctly and completely implements all system requirements.
Within the PRR, the Contractor shall present a Manufacturing Readiness Assessment (MRA) to demonstrate that the Contractor and manufacturing facilities are ready for production. The MRA assesses if the Contractor has accomplished adequate production planning. The MRA will also include an inspection of processes and facilities to ensure they are adequate for production. A successful review is predicated on the determination that the production and repair capability forms a satisfactory basis for proceeding to the production phase. The Contractor shall be responsible for recording action items and following those action items to their conclusion/resolution. The Contractor shall provide a list of action items to the Government, and provide updates/status as part of the MSR and/or bi-weekly teleconferences. Close-out of action items shall be coordinated with the Government.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes) (CDRL #A004, DI-ADMN-81373, Presentation Materials)
FD2060-17-30546 For Official Use Only
3.2.6 Functional Configuration Audit (FCA)
The Contractor shall conduct a Functional Configuration Audit (FCA) that examines the functional characteristics of the PRU asset, and verifies that the product has met, via test results, the requirements specified in its functional baseline documentation approved at the CDR. FCAs shall be conducted on hardware and software products, and shall precede or be held concurrent with the Physical Configuration Audit (PCA). The FCA shall document any discrepancies that are found in the performance capabilities. The FCA/PCA minutes shall be submitted to address the status of all action items that have been identified. The Contractor shall be responsible for recording action items and following them to their conclusion. The Contractor shall provide a list of action items to the Government, and provide updates/status as part of the MSR/bi-weekly teleconferences. Close-out of action items shall be coordinated with the Government.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes)
3.2.7 Physical Configuration Audit (PCA)
The Contractor shall conduct a Physical Configuration Audit (PCA) to examine the actual configuration of the PRU. The PCA shall verify that the related design documentation matches the Configuration Item (CI) as specified in the Contractor’s engineering drawings. The FCA and PCA can be conducted concurrently, provided the intent and integrity of the FCA and PCA is maintained. The Contractor shall be responsible for recording action items and following those action items to their conclusion. The Contractor shall provide a list of action items to the Government, and provide updates/status as part of the MSR/bi-weekly telecons. Close-out of action items shall be coordinated with the Government.
(CDRL #A002, DI-ADMN-81249B, Conference Agenda) (CDRL #A003, DI-ADMN-81250B, Minutes)
3.3 System Safety
The Contractor shall develop a System Safety Program Plan (SSPP) to include a Software Safety Plan (SSP) as an appendix IAW Military Standard 882E (MIL-STD-882E) Task 102 and the Joint Software System Safety Engineering Handbook (JSSSEH). The SSPP and SSP shall include a description of the means of compliance to each of the applicable Level of Rigor (LOR) requirements and tasks in the Safety LOR Table. This SSPP and SSP shall document the system safety methodology for the identification, classification, and mitigation of safety hazards as part of the overall Systems Engineering (SE) and Software Development processes. The SSPP shall address the timeline and resources involved in executing the SSP. The SSPP shall address comprehensive software safety specific tasks and processes. The Contractor shall involve system safety in the design process to assure safety in design, manufacture, handling, testing, usage, maintenance and integration. The Contractor shall perform a Software Safety Assessment and conduct analysis IAW MIL-STD-882E to ensure safety of flight requirements associated with the MIL-HDBK-516C airworthiness requirements are met.
FD2060-17-30546 For Official Use Only
Hazards shall be reported to the Government and shall be eliminated or controlled to an acceptable level of risk as determined by the Government.
The risks associated with software-related defects shall be categorized using Table B-1 of MIL-STD-882E.
(CDRL #A054, DI-SAFT-81626, System Safety Program Plan (SSPP))
3.3.1 System Safety Program
The SSP shall draw upon industry best practices (both civil and military) and NAVAIR System Safety Program requirements. The System Safety Program shall ensure safety during system design, manufacture, handling, testing, use, maintenance and integration phases. The basis of the System Safety Program shall consist of a thorough and continuous hazard identification, assessment, and mitigation process. Hardware, software and human interfaces shall be analyzed during the hazard identification process.
The Contractor shall employ verification methods to include inspection of documentation.
Evidence of a hazard identification, control, and resolution process is verified by inspection of safety process documentation and review of safety analyses and system safety group proceedings.
3.3.1.1 Preliminary Hazard Analysis (PHA) The Contractor shall perform and document a PHA to determine initial risk assessments of identified hazards. Hazards associated with the proposed design or function shall be evaluated for severity and probability based on the best available data, including mishap data (as accessible) from similar systems, legacy systems, and other lessons learned. Provisions, alternatives, and mitigation measures to eliminate hazards or reduce associated risk shall be included.
(CDRL #A058, DI-SAFT-80101C/T System Safety Hazard Analysis Report (SSHAR))
3.3.1.2 System Safety Reporting The Contractor shall develop a Safety Assessment Report (SAR) in compliance with MIL-STD-882E TASK 301 to provide a comprehensive evaluation of the status of safety hazards and their associated risks prior to test or operation of the system. The Contractor shall perform and document an assessment to identify the status, at the time of the report, of safety hazards, associated risks, mitigation measures, and formal risk acceptance decisions. This documentation shall include hazards that were identified and eliminated, and specific procedural controls and precautions to be followed to mitigate the risks of hazards that could not be eliminated.
The SAR shall include the results of all the safety analysis tasks identified within the safety section of this SOW. The Government shall have Government purpose rights to all new supporting data.
(CDRL #A055, DI-SAFT-80102C, Safety Assessment Report (SAR))
3.3.1.3 Foreign Object Damage (FOD) Prevention The Contractor shall verify that the SSP addresses ground/industrial safety (FOD prevention); verification method includes inspection of documentation. Evidence of an established FOD prevention program is verified by review of FOD program documents and inspection of reports, or on-site certification by the Defense Contract Management Agency (DCMA) that an acceptable FOD program exists.
FD2060-17-30546 For Official Use Only
3.3.1.4 Mitigation of Mishap Risks The Contractor shall verify that the design is free from unacceptable mishap risk, including risks to third parties. Unacceptable risks to personnel or equipment shall be eliminated or controlled in accordance with MIL-STD- 882E. Mishap risk determination, including risk to third parties, reflects the current configuration and maturity of the system. The Contractor shall verify that all aspects of human factors are addressed and unacceptable human factors safety issues/risks are resolved in the design process. The Contractor shall validate that the system is manufactured such that risk reduction is ensured. The system design shall minimize risk created by human error in the operation and support of the system.
3.3.1.5 Analysis of Changes or Modifications The Contractor shall verify that a system safety change analysis is accomplished on changed or modified equipment or software. The Contractor shall verify that no changes/modifications to existing systems shall create new hazards, affect a hazard that had previously been resolved, increase the risk of any existing hazards, or adversely affect any safety-critical component.
3.3.2 Airworthiness Certification Criteria Report
The Contractor shall coordinate with PNT-PO to determine individual platform requirements for airworthiness artifacts. Artifacts will be used to develop the platform airworthiness compliance matrix. The Contractor shall produce an Airworthiness Certification Criteria Report to provide airworthiness certification criteria verification results per targeted platform.
(CDRL #A014, DI-SESS-81768, Airworthiness Certification Criteria Report)
3.3.3 Failure Reporting, Analysis, and Corrective Action System
By implementing an effective Failure Reporting, Analysis, and Corrective Action System (FRACAS), the Contractor can provide management visibility and control for reliability.
Contractor shall develop and implement a FRACAS plan IAW MIL-HDBK-2155 to provide the required methods, guidelines and the responsibilities so corrective actions can be tracked and monitored to minimize risk for this effort. A FRACAS Report IAW MIL-HDBK- 2155 shall be generated and submitted for any failures encountered during qualification testing.
(CDRL #A015, DI-MISC-80508B/T, Failure Reporting, Analysis and Corrective Action System (FRACAS))
3.3.4 Interlocks and Incompatible Modes
3.3.4.1 Interlocks The Contractor shall verify that non-operative devices/programs can be safely locked out. Verification methods include analysis, SIL tests, simulation, demonstration, inspection and review of documentation. Failure Modes and Effects Tests (FMET) cases shall introduce attempts to access non-operative devices/programs including rogue partition(s).
(CDRL #A023, DI- MISC-80508B/T, Technical Reporting)
FD2060-17-30546 For Official Use Only
3.3.4.2 Incompatible Modes The Contractor shall verify that interlocks safely preclude incompatible modes, simultaneous engagement and engagement with incompatible flight conditions or air vehicle configurations. These verification methods shall include analysis, SIL tests, simulation, inspection and review of documentation. Simulation, Failure Modes and Effects Criticality Analysis (FMECA), FMET, inspection, and SIL testing shall verify proper mode engagement/disengagement and lockouts.
(CDRL #A023, DI- MISC-80508B/T, Technical Reporting)
3.3.5 DO-178C Requirements
In addition to DoD requirements, it is incumbent upon the Contractor to ensure that all aspects of the EGI-M design meet the requirements for DO-178C Design Assurance Level (DAL) certification as stipulated in the SRD.
3.3.5.1 DO-178C Certification Plan Execution The Contractor shall conduct all required activities, to include Stages Of Involvement (SOI) audits, to achieve the required DO-178C certifications stipulated in the SRD.
3.3.5.2 DO-178C Artifacts The contractor shall develop and submit the documents listed below required for DO-178C for review and approval.
3.3.5.2.1 Plan for Software Aspects of Certification (PSAC) including tools/models qualification and validation; reference Radio Technical Commission for Aeronautics (RTCA)/DO-178C section 11.1
CDRL #A045, DI-MISC-80508B/T, PLAN FOR SOFTWARE/HARDWARE ASPECTS
OF CERTIFICATION (PSAC/PHAC))
3.3.5.2.2 Software Development Plan (SDP) (DO-178C para 11.2) including System Processing Architecture (SPA) and integration plan(s), software build plans, and software development integrity master plan (SDIMP).
3.3.5.2.3 Software Configuration Index (SCI) (DO-178C para 11.16)
(CDRL #A084, DI-MISC-80508B/T, DO-178C DO-254)
3.3.5.2.4 Software Accomplishment Summary (SAS) including documentation of flight clearance process.
(CDRL #A084, DI-MISC-80508B/T, DO-178C DO-254)
3.3.5.2.5 The contractor shall develop and have available for review the documents listed below required for DO-178C.
a. Software Verification Plan (SVP) (DO-178C para 11.3) to include both hardware & software test plans and procedures, and regression testing policy at software and system level
b. Software Configuration Management Plan (SCMP) (DO-178C para 11.4)
c. Software Quality Assurance Plan (SQAP) (DO-178C para 11.5)
FD2060-17-30546 For Official Use Only
d. Software Requirements Standards (SRS) (DO-178C para 11.6) including process guidelines such as software coding standards & prohibited coding techniques.
e. Software Design Standards (SDS) (DO-178C para 11.7)
f. Software Code Standards (SCS) (DO-178C para 11.8)
g. Hardware/Software Requirements Data, (SRD) (DO-178C para 11.9) including both hardware and software specifications
h. Software Design Description (SDD) (DO-178C para 11.10) to include System
Processing Architecture (SPA) design descriptions, drawings/diagrams, Interface Control Documents (ICDs), Hardware and software ICDs, bus ICDs, resources utilization analyses and metrics, and version description documents
i. Software Verification Cases and Procedures (SVCP) (DO-178C para 11.13) for both software and related hardware elements
j. Software Verification Results (SVR), including analysis (common mode analysis, Single Event Upset (SEU) vulnerability analysis, latency analysis, Built- In-Test (BIT) coverage analysis, interface coupling analysis, transient analysis, source data analysis, safety interlock design analysis), analysis tool reports, and ground / flight test reports
k. Software Life Cycle Environment Configuration Index (SECI) (DO-178C para 11.15)
l. Problem Reports (DO-178C para 11.17)
m. Software Configuration Management Records (DO-178C para 11.18)
n. Software Quality Assurance Records (DO-178C para 11.19) including plans and audits
o. Trace Data (DO-178C para 11.21)
In addition to the above artifacts, the Contractor shall hold in archive all generated artifacts for PECO review.
3.3.6 DO-254
3.3.6.1 DO-254 Certification Plan Execution The Contractor shall conduct all required activities to include Stages Of Involvement (SOI) audits to achieve the required DO-254 certifications stipulated in the SRD.
3.3.6.2 DO-254 Artifacts The contractor shall develop and submit the documents listed below required for DO- 254 for review and approval.
a. Plan for Hardware Aspects of Certification (PHAC) reference RTCA/DO-254 Section 10.1.1
(CDRL #A045, DI-MISC-80508B/T, PLAN FOR SOFTWARE/HARDWARE
ASPECTS OF CERTIFICATION (PSAC/PHAC))
FD2060-17-30546 For Official Use Only
b. Hardware Design Plan (HDP) reference RTCA/DO-254, section 10.1.2
(CDRL #A083, DI-MISC-80508B/T, HARDWARE DESIGN PLAN)
c. Hardware Configuration Management Records: reference RTCA/DO-254 Section 10.7
(CDRL #A084, DI-MISC-80508B/T, DO-178C DO-254)
d. Hardware Accomplishment Summary (HAS) reference DO-254 Section 10.9
(CDRL #A084, DI-MISC-80508B/T, DO-178C DO-254)
3.3.6.2.1 The contractor shall develop and have available for review the documents listed below required for DO-254 Level B.
a. Hardware Validation Plan (HVP): reference RTCA/DO-254 Section 10.1.3
b. Hardware Verification Plan (HVP): reference RTCA/DO-254 Section 10.1.4
c. Hardware Configuration Management Plan (HCMP): reference RTCA/DO-254
Section 10.1.5
d. Hardware Process Assurance Plan (HPAP):reference RTCA/DO-254 Section
10.1.6
e. Hardware Requirements Standards (HRS): reference RTCA/DO-254 Section
10.2.1
f. Hardware Design Standards (HDS): reference RTCA/DO-254 Section 10.2.2
g. Hardware Validation and Verification Standards: reference RTCA/DO-254
Section 10.2.3
h. Hardware Design Data (HDD) : reference RTCA/DO-254 Section 10.3
i. Hardware Requirements:…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it.