1. DF PDS SOW Draft Release V1.pdf

DRAGONFLY MISSION

Solicitation #:

80LARC22R0001

Draft Release Version 1

Title: Dragonfly Parachute Decelerator Subsystem – Statement of Work Page: of 50

PARACHUTE DECELERATOR SUBSYSTEM (PDS)

STATEMENT OF WORK (SOW)

SOLICITATION #: 80LARC22R0001

DRAFT RELEASE VERSION 1

Langley Research Center Hampton, Virginia

National Aeronautics and Space Administration

80LARC22R0001

Draft Release

TABLE OF CONTENTS

List of Tables

List of Figures

1 INTRODUCTION

1.1 Purpose

1.2 Background

1.3 Dragonfly System Architecture

1.3.1 Aeroshell

1.3.2 Parachute Deceleration System

1.4 EDL Concept of Operation

2 SCOPE OF WORK

2.1 Work to be Performed by the Contractor

2.2 PDS Hardware that is not Part of this SOW

3 DESCRIPTIONS OF TASKS AND REQUIREMENTS

3.1 General

3.1.1 Purpose

3.1.2 Definitions

3.1.3 Applicable Documents

3.2 Requirements

3.3 Manned Commercial Aviation Services and Unmanned Aircraft Systems

3.4 Project Management

3.4.1 Documentation Requirements

3.4.2 Project Office

3.4.3 Project Management Plan

3.4.4 Work Breakdown Structure

3.4.5 Integrated Master Schedule

3.4.6 Financial Management

3.4.7 Earned Value Management

80LARC22R0001

Draft Release

3.4.8 Contract Performance Report

3.4.9 Configuration Management

3.4.10 Risk Management

3.4.11 Reviews and Meetings

3.4.12 Government Access

4 CONTRACT LINE ITEM NUMBER (CLIN)

4.1 Project Structure

4.2 Contract Line Item Numbers (CLINs)

4.3 CLINs Descriptions

4.3.1 CLIN #1 – Phase B Data Package

4.3.2 CLIN #2 – Phase C Data Package

4.3.3 CLIN #3 – Phase D Engineering Model Delivery

4.3.4 CLIN #4 – Phase D Flight Unit Delivery

4.3.5 CLIN #5 – Phase D Data Package

5 Contractor Data Requirements List (DRL)

5.1 DRLs Descriptions

5.1.1 DRLs 1.X – Phase B

5.1.2 DRLs 2.X – Phase C

5.1.3 DRLs 3.X – Engineering Model

5.1.4 DRLs 4.X – Flight Unit

5.1.5 DRLs 5.X – Phase D

6 SCHEDULE MILESTONES

7 SYMBOLS

8 ABBREVIATIONS

9 REFERENCES

10 APPLICABLE DOCUMENTS

ATTACHMENT A: REQUIREMENTS

ATTACHMENT B: CONTRACTOR DATA REQUIREMENTS LIST / CONTRACTOR DATA

REQUIREMENTS DESCRIPTION (DRL/DRD)

80LARC22R0001

Draft Release

LIST OF TABLES

Table 1. PDS Requirement Areas

Table 2. PDS SOW Phase Key Milestones

Table 3. Contract Line Item Numbers (CLINs)

Table 4. Contract Data Requirement Lists (DRLs)

Table 5. Dragonfly Project Major Milestones with Emphasis on the PDS

Table 6. References

Table 7. Applicable Documents

LIST OF FIGURES

Figure 1. Dragonfly Flight System

Figure 2. Genesis Aeroshell Geometry

Figure 3. EDL Concept of Operation

80LARC22R0001

Draft Release

1 INTRODUCTION

1.1 Purpose

The purpose of this Statement of Work (SOW) is to define the requirements, tasks, deliverables, and services associated with NASA Langley Research Center’s (LaRC) acquisition of a Parachute Decelerator Subsystem (PDS) in support of the Dragonfly (DF) mission.

1.2 Background

NASA has selected the Dragonfly mission1 under the New Frontiers Program.2 This mission is intended to place a rotorcraft lander on the surface of Titan (Saturn’s largest moon) to study its prebiotic chemistry and habitability. Subsequently in this document the “rotorcraft lander” will be denoted simply as “lander”. Launch is scheduled for June 2027, with arrival at Titan by 2034. The mission is being led by the Johns Hopkins University Applied Physics Laboratory (APL). Other partners in this mission include Lockheed Martin Space (LMS), providing the entry aeroshell, and NASA, leading the entry, descent, and landing (EDL) system development. The EDL system includes a PDS.

1.3 Dragonfly System Architecture

As shown in Figure 1, the Dragonfly system exists in several different physical configurations depending on the mission phase. The Entry/Descent configuration consists of the EDL Assembly (EA), Lander Bus (LB), and Payload (PL). Particularly important for this SOW is the EDL Assembly element of the Dragonfly flight system. Within the EDL Assembly there are six subsystems (also shown in Figure 1):

1) a Mechanical subsystem to provide a structural aeroshell to physically encapsulate the Lander and transfer loads and mechanisms to execute the functions necessary for the various separation events in the concept of operations,

2) a Thermal subsystem including thermal paint, single-layer insulation (SLI) blankets, and accommodation of a fluid loop to maintain elements, components, and subsystems to within their allowable temperatures,

3) a Thermal Protection System (TPS) to protect the Entry Vehicle from the aerothermal environments during atmospheric entry at Titan, 1 See https://www.nasa.gov/dragonfly and https://dragonfly.jhuapl.edu for more information on the Dragonfly

Mission.

2 See https://www.nasa.gov/planetarymissions/newfrontiers.html.

80LARC22R0001

Draft Release

4) a Harness subsystem to provide and accommodate various interfaces and conduits throughout the Entry Vehicle to transmit power, data, signals, and thermal fluid between elements,

5) an Engineering Science Investigation (ESI) subsystem to collect engineering data during Titan atmospheric entry to characterize the environments and TPS performance (the ESI is Government Furnished Equipment (GFE) which will be incorporated into the EDL Assembly according to a governing Interface Control Document (ICD), and

6) a Parachute Decelerator Subsystem (PDS) to provide the deceleration necessary to deliver the Lander to the target condition (altitude and airspeed) for transition to powered flight.

Because of their importance to this SOW, the aeroshell and PDS are described in more detail in Sections 1.3.1 and 1.3.2, respectively.

Figure 1. Dragonfly Flight System.

1.3.1 Aeroshell

In this document “aeroshell” is used to describe the structural shell associated with the EA.

Dragonfly will use an outer mold line (OML) geometry derived from that used in the Genesis mission (see Desai and Cheatwood, 2001, in Section 9 References). This geometry is shown in Figure 2. The aeroshell’s maximum diameter is 4.50 m. The two principal parts of the aeroshell are its heatshield and backshell (see Figure 2). The PDS will be attached to the rear surface of the backshell.

EDL Assembly Mechanical Thermal Thermal Protec on System (TPS) Harness En neering Science Inves ga on (ESI) Parachute Decelerator Subystem (PDS)

80LARC22R0001

Draft Release

Figure 2. Genesis Aeroshell Geometry. Dimensions for reference only; not exact OML.

1.3.2 Parachute Decelerator Subsystem

The complete PDS will consist of the following hardware components:

1.0 Drogue Parachute Component

2.0 Mortar Component (including a cover)

3.0 Drogue Parachute Release Mechanism (including any necessary pyrotechnic devices)

4.0 Main Parachute Component

5.0 Main Parachute Container Component (including a cover)

The drogue parachute will be deployed by the mortar. At a specified altitude the drogue parachute will be used to deploy the main parachute. (See the next section for the EDL Concept of Operation.) The PDS will be packaged as a single unit that can be drop-in installed on the rear surface of the backshell.

The PDS Contractor shall design and deliver the PDS components, specified in Attachment A:

Requirements (specifically, Requirement 1.1-2), of this SOW. Hardware components for which the Contractor is not responsible, and which are not part of this SOW, are listed in Section 2.2 of this SOW. Briefly, NASA LaRC, APL, or LMS will provide the parachute swivels, fasteners used to attach the PDS to the aeroshell, the TPS for the mortar and main parachute container covers (LMS will bond the TPS to the mortar cover), and any required electroexplosive devices (i.e., NASA Standard Initiators – NSIs) and their harnesses. All commands and power required to the

80LARC22R0001

Draft Release

PDS (e.g., mortar fire, drogue parachute release mechanism actuation) will be issued and powered by the Lander.

1.4 EDL Concept of Operation

The current EDL concept of operation is shown in Figure 3 (all numeric values are approximate). Prior to entry, the cruise stage separates from the aeroshell. The entry mass (including aeroshell, lander, and other systems) current best estimate is 1574 kg (not-to-exceed value is 2100 kg). Entry is ballistic. During entry, after the aeroheating and deceleration pulses are over, a drogue parachute will be deployed by a mortar. This deployment will occur at a nominal Mach number and dynamic pressure of 1.5 and 363 Pa, respectively. At present it is assumed that this drogue parachute will be a scaled version of the Viking Disk-Gap-Band (DGB) parachute with a nominal diameter of 5.4 m. To minimize interactions between the aeroshell’s aerodynamic wake and the parachute, it has been assumed that the skirt of the inflated drogue parachute will be 10 aeroshell diameters (45 m) downstream of the aeroshell’s maximum diameter. The first purpose of the drogue parachute is to stabilize and decelerate the aeroshell at supersonic, transonic, and subsonic speeds. After descending under the drogue parachute for approximately 104 minutes, at an altitude of approximately 4 km above the surface, the drogue parachute will perform its second purpose – serving as a pilot parachute for the deployment of the main parachute. This deployment will occur at a nominal airspeed and dynamic pressure of 5.8 m/s and 78.4 Pa, respectively. At present it is assumed that the main parachute will also be a Viking-scaled DGB and have a nominal diameter of 13.44 m.3 The main parachute has several purposes: 1) to provide sufficient ballistic coefficient difference for the heatshield and lander separation events, 2) to reduce the dynamic motions of the aeroshell, and 3) to deliver the lander to the desired separation airspeed of 2.9 m/s at an altitude above the surface of 1.2 km. The time from main parachute deployment to lander separation will be approximately 18 minutes.

3 A final choice of the main parachute type has not been made. The PDS contractor will be asked to select the main parachute type with NASA concurrence.

80LARC22R0001

Draft Release

Figure 3. EDL Concept of Operation.

Because of the long descent times under the drogue and main parachutes, swivels will be required to decouple the rotation of the aeroshell and parachutes. Currently APL intends to provide these swivels.

NASA has several concerns regarding the PDS. Among these concerns are the following:

1) Flight time of the drogue parachute at supersonic speeds above Mach 1.4. At present the estimated maximum drogue parachute flight time at Mach numbers above 1.4 is 10 s.

Above Mach 1.4 DGB parachutes are known to experience load oscillations. Repeated load oscillations could be detrimental to the structural integrity of the drogue parachute. These load oscillations will need to be accounted for in the design and structural strength verification of the drogue parachute.

2) Dynamic behavior of the aeroshell while under the drogue and main parachutes.

Excessive dynamics while under the drogue and main parachutes are detrimental to the operation of the EDL system, especially during key events such as heatshield separation, main parachute deployment, and lander release.

3) Deployment and inflation reliability of the main parachute. Deployment and inflation of the main parachute will occur at low airspeeds and dynamic pressures. This will yield

-49.6°

228 11.0

E+110 min

E+128 min

80LARC22R0001

Draft Release long inflation times for the main parachute. Concerns have been raised about the reliability of the main parachute inflation over such long inflation times.

In designing, developing, and qualifying the PDS, particular attention will need to be paid to the Titan environment. The temperature at the surface of Titan is extremely low, 94 K, and can be as low as 70 K during the parachute phase. The PDS will have to operate reliably at these temperatures. It is possible that liquid methane is present in the atmosphere. The atmospheric density of Titan is very high as compared to that of Earth: 5.2 kg/m3 at an altitude of 1.2 km above the surface (i.e., 4.2X that of Earth at sea level). Finally, the surface gravity of Titan is low,

1.35 m/s2 (i.e., 14% that of Earth). All these factors will affect the PDS design and operation.

In addition, it is noted that the time from delivery of the PDS to NASA LaRC for Integration and Test (I&T) to flight on Titan is approximately 8 years – 1.6 years from PDS delivery to I&T, and another 6.5 years en route to Titan (times are approximate). During the space segment the PDS will be exposed to a deep space environment which includes vacuum and radiation (from space sources and from the Radioisotope Thermal Generator (RTG) that powers the lander). These environments and their durations will need to be considered in the design, development, and qualification of the PDS.

2 SCOPE OF WORK

2.1 Work to be Performed by the Contractor

The Contractor shall provide all resources for design, analysis, fabrication, testing, quality assurance, documentation, and delivery of a PDS as specified in this SOW. The Contractor’s scope of work shall include the general tasks listed below.

1) Design, fabricate, and deliver a PDS that meets the functional, performance, and environmental requirements. The hardware elements of the PDS to be delivered by the Contractor are specified in Attachment A: Requirements, (specifically, Requirement 1.1-2), of this SOW.

2) Create and meet the requirements of an ICD between the PDS and the EA.

3) Keep NASA LaRC4 informed of progress, problems, and plans.

4) Prepare for and attend meetings and reviews.

5) Create and deliver the specified documentation.

6) Assist in the I&T of the EA.

7) Manage the work being performed.

4 Unless otherwise indicated, the representative for NASA LaRC in this SOW will be the Dragonfly PDS

Lead Engineer.

80LARC22R0001

Draft Release

8) Meet the specified schedule milestones.

Specific requirements for these tasks are provided in the SOW sections that follow.

2.2 PDS Hardware that is not Part of this SOW

The following Hardware of an operational PDS are not the responsibility of the Contractor nor part of this statement of work:

• Any NSIs (i.e., electroexplosive devices). All NSIs needed by the contractor, for test and flight, will be provided by either LMS, APL, or NASA LaRC.

• Any harnesses (wiring) associated with NSIs. All harnesses will be provided by LMS.

• The TPS used on PDS covers. The TPS will be provided by LMS, who will also bond the TPS to the PDS covers.

• Fasteners required to attach the PDS to the aeroshell. These fasteners will be provided by LMS.

• Parachute swivels.

There will not be any electronics or software in the PDS hardware components that are provided by the Contractor (note that the NSIs and associated harnesses are not the Contractor’s responsibility).

3 DESCRIPTIONS OF TASKS AND REQUIREMENTS

3.1 General

3.1.1 Purpose

This section describes the tasks to be performed by the contractor, and the requirements that shall be met.

3.1.2 Definitions

The following definitions apply to specific terms in this SOW.

Requirement (shall): As used in this SOW “requirement” has one of two meanings: a) it specifies a function, capability, or constraint, with which the PDS design must comply, or b) it specifies a product or service that the contractor must provide (e.g., documentation). All requirements must be verified. All requirements are stated using the verb “shall.”

Goal (should): A “Goal” is a specification of a physical or behavioral characteristic that is highly desirable, but the inherent technical difficulty and/or the cost of achievement compared to

80LARC22R0001

Draft Release the value is potentially too great to make it a requirement. Therefore, Goals do not need to be formally verified, and do not need to be waived if they are not met. Nevertheless, a goal is tracked like a requirement, so that the DF project will know whether the Goal is being satisfied, and/or whether additional resources could be applied to achieve the Goal. Systems and subsystems are not to apply any additional resources towards the satisfaction of a Goal without the DF project’s approval. All goals are stated using the verb “should.”

Implementation Statement (will): An “Implementation Statement” describes a planned or intended implementation or practice; they are described by the word “will.” These statements are expected to be followed but do not require formal verification nor a waiver when not followed.

Verification: Proof of compliance with requirements. Verification may be determined by test, analysis, demonstration, inspection, or a combination thereof.

Test: The use of a realized end product to obtain detailed data to verify a requirement or validate performance or to provide sufficient information to verify a requirement or validate performance through further analysis.

Analysis: The use of mathematical modeling and analytical techniques to predict the compliance of a design to its requirements (i.e., verification) based on calculated data or data derived from lower system structure end product validations.

Demonstration: Showing that the use of an end product achieves the individual specified requirement (verification) or stakeholder expectation (validation). It is generally a basic confirmation of performance capability, differentiated from testing by the lack of detailed data gathering.

Inspection: The visual examination of a realized end product. Inspection is generally used to verify physical design feature requirements or specific manufacturer identification.

Accommodate: Provide the mechanical (mounting interface and physical space) and electrical (harness routing) interfaces for an element, component, or subsystem.

Operate: When a system or subsystem is required "to operate" during specified conditions, that system or subsystem must continue meeting all of its relevant performance requirements while those conditions are present.

Single-Point Failure: Single element, component, wiring, connector failure, software glitch, or computer failure that results in the permanent loss of the space vehicle’s ability to perform its primary mission for the intended design lifespan.

Survive: When a system or subsystem is required "to survive" specified conditions, that system or subsystem is not required to provide any level of performance while those conditions are present. However, that system or subsystem must not suffer any damage that would compromise its ability to meet its performance requirements in the future.

Flight Unit: The complete PDS intended to be installed on the spacecraft for operation on Titan.

80LARC22R0001

Draft Release

Engineering Model: A complete PDS intended to be used for Integration and Test (I&T) by LMS, but not intended to be used as a Flight Unit. The Engineering model has the same external configuration, mass properties, thermal characteristics, and electric characteristics as the Flight Unit.

Subsystem: A subsystem is composed of one or more components and represents a major product that is delivered to the Dragonfly flight system for integration. The PDS is a subsystem.

Component: A component is the next breakdown from a subsystem; it represents a stand-alone item that integrates into a subsystem (e.g., the mortar is a component of the PDS).

Element: An element is the next breakdown from a component; it represents a stand-alone item that integrates into a component (e.g., the gas generator is an element of the mortar component). Note: This definition is specific to this SOW; it is not general for Dragonfly.

Technical Interchange Meeting (TIM): A meeting between the Contractor, Government representatives, and other Dragonfly team members to discuss a process or feature. Actions may be tracked by the TIM organizer.

During SOW development TBC, TBD, TBR, and TBS are employed to indicate items that are incomplete, uncertain, or preliminary. These terms indicate the following:

TBC: To Be Confirmed; a representative value/parameter is known but not verified.

TBD: To Be Determined, no representative value/parameter has been identified.

TBR: To Be Resolved; a representative value/parameter has been identified with a known conflict.

TBS: To Be Supplied; non-technical information that needs to be supplied, such as a missing document number Curly brackets { } are used to show that a value is uncertain, followed by TBC or TBR as appropriate; for example, {15 deg/s TBC}.

3.1.3 Applicable Documents

Applicable documents are listed in Section 10.

3.2 Requirements

The PDS requirements areas are listed in Table 1; it is a “Table of Contents” for the requirements. The complete set of requirements is presented in Attachment A: Requirements.

80LARC22R0001

Draft Release

Table 1. PDS Requirements Areas.

1 ARCHITECTURE, FUNCTIONAL, AND PERFORMANCE

1.1 General

1.2 Mortar Component

1.3 Drogue Parachute Component

1.4 Drogue Parachute Release Mechanism

1.5 Main Parachute Component

1.6 Electroexplosive Devices

1.7 Environments

1.7.1 Mission Design

1.7.2 Pre-Launch Environments

1.7.3 Launch Environments

1.7.4 Cruise Environments

1.7.5 Entry and Descent Environments

1.8 Engineering Model

1.9 Special Tests

1.10 Mass Properties

1.11 Design Limit Loads, Factors of Safety, and Margins of Safety

1.12 Stiffness

2 INTERFACE CONTROL

3 PLANETARY PROTECTION

4 UNITS

5 SAFETY AND MISSION ASSURANCE

5.1 General

5.2 Configuration Management

5.3 Supplier Management

5.4 System Safety

5.5 Metrology / Calibration

5.6 Materials and Processes

5.7 Non-Conforming Materials

5.8 Government-Industry Data Exchange Program (GIDEP)

5.9 Limited Life Items

5.10 Contamination Control

5.11 Design Verification

5.12 Workmanship

5.13 Reliability

5.14 Ground Support Equipment

5.15 Component Environment

5.15.1 Test Plans

5.15.2 Test Procedures

5.15.3 Component Work Records

80LARC22R0001

Draft Release

5.15.4 Dynamic Test Requirements

5.15.5 Component Leakage Testing

5.15.6 Thermal Design and Test Requirements

6 MANAGEMENT

6.1 General

6.2 Meetings and Reviews

6.3 Access to Contractor Facilities

6.4 Access to Tests

7 GOVERNMENT-FURNISHED RESOURCES

7.1 Government-Furnished Equipment

7.2 Government-Furnished Data and Analyses Results

8 DELIVERABLES

8.1 Documentation Deliverables

8.2 End Item Data Package

8.3 Hardware Deliverables

9 INTEGRATION AND TEST

10 VERIFICATION AND VALIDATION

3.3 Manned Commercial Aviation Services and Unmanned Aircraft Systems

Manned commercial aviation services and/or unmanned aircraft systems will probably be required to verify some of the requirements in this SOW. Such manned commercial aviation services and/or unmanned aircraft systems are considered to be “Public Use” operations and are subject to the reviews and approvals described below.

“Public Use” operations as defined in Federal Aviation Administration (FAA) Advisory Circular 00-1.1B is an aircraft used only for the US Government, is not performing an operation with a commercial purpose, and has only the necessary crew onboard. For the duration of flight testing required by this SOW, the selected aircraft and flights meet the FAA definition of ‘public use’, therefore the US Government (NASA in this case) is required to conduct a review of the company, an airworthiness review of the aircraft, and a review the proposed flight test in lieu of the respective FAA review. All three reviews must be complete and approvals issued prior to first flight, and the continuous surveillance component continues throughout the entire review, approval, and flight test campaign.

NASA is required to conduct these reviews whether the company US or not, and whether the flight operations are in the US or not. If prime contractor elects to select a non-US company and/or conduct the operations outside of the US, the prime contractor shall facilitate NASA conducting these reviews with the authorities appropriate for that company and that country.

Commercial Air Services (CAS). NASA Headquarters (HQ) will conduct a review of the selected company to ascertain they meet the requirements to provide CAS aircraft and to conduct flight operations to the US Government. The Point of Contact (POC) is Jamal Abbed (jamal.s.abbed@nasa.gov). Following the HQ CAS review, LaRC Research Services Directorate

80LARC22R0001

Draft Release

(RSD) Chief of Flight Operations (CFO) will review results and determine any mitigations required to conduct the proposed test.

Airworthiness. NASA’s Eastern Region Airworthiness Review Board (ER-ARB) will conduct a review of the aircraft and all proposed modifications. Any modifications to the aircraft that deviate from an FAA approved airworthiness configuration shall be reviewed and approved by the ER-ARB. The ER-ARB does have requirements and a suggested format to present material, however with prior coordination, the ER-ARB is willing to accept the company’s existing process and documentation. If the company’s normal airworthiness process is used, NASA requests the ability to participate in the review, and to be provided documentation of their meeting minutes, action items, and close out of those items. At the conclusion of the NASA airworthiness review, a NASA Statement of Airworthiness will be issued. The POCs are Brian Baxley (brian.t.baxley@nasa.gov) and Greg Slover (gregory.l.slover@nasa.gov).

Flight Release. The CFO or designee at NASA Langley Research Center will conduct a review of the proposed flight test operation. This review includes the flight test plan, test points, flight procedures, airspace, and crew qualifications. At the end of this review, the CFO (or designee) will issue a Flight Release. The POC is Taylor Thorson (taylor.n.thorson@nasa.gov).

Continuous Surveillance. The Chief of Flight Operations is required to provide continuous surveillance of any contracted NASA flight activity. The results of the reviews above will determine the level and scope of this continuous surveillance plan. Range of scope could include on site oversight of planned maintenance and flight activities.

3.4 Project Management

3.4.1 Documentation Requirements

The Contractor shall develop, deliver, and maintain all documentation required in Attachment B, Contractor Data Requirements List (DRL)/Contractor Data Requirements Description (DRD). In addition, the Contractor shall preserve all appropriate documentation required to maintain a traceable record of engineering and programmatic decisions and hardware characteristics and performance, whether formal or informal, for a period of three (3) years after acceptance of all deliverable items (see FAR 52.227-16, Additional Data Requirements). The Government reserves the right to review this documentation upon request

3.4.2 Project Office (Applicable all CLINs)

The Contractor shall maintain a project office to manage the technical activities and resources of the PDS contract. The Contractor shall appoint a dedicated Project Manager to direct and manage the effort and report on the overall technical performance, resource management, and schedule management of the contractual effort and all subcontracts.

80LARC22R0001

Draft Release

3.4.3 Project Management Plan (Applicable to all CLINs)

The Contractor shall develop and implement a Project Management Plan in accordance with

DRL/DRD PM-6.

3.4.4 Work Breakdown Structure (Applicable to all CLINs)

The Contractor shall develop and implement a PDS Contract Work Breakdown Structure (CWBS) and CWBS dictionary (DRL/DRD PM-3) to organize the project effort into manageable work elements. The CWBS shall provide a clear breakdown of the project’s work content into elements to facilitate planning and control of cost, schedule, and technical content.

3.4.5 Integrated Master Schedule (Applicable to all CLINs)

The Contractor shall establish, implement, and maintain an integrated scheduling system consistent with their institutional procedures and documented as part of the Project Management Plan. The Contractor shall provide and maintain an Integrated Master Schedule (IMS) in accordance with DRL/DRD PM-2. The Contractor shall inform the Government prior to changing the IMS baseline. The IMS should align with the product-oriented CWBS and support financial and cost management activities such as NASA Form 533 reporting. The Contractor shall provide schedule status within the Monthly Project Status Report (MPSR) (DRL/DRD PM-1).

3.4.6 Financial Management (Applicable to all CLINs)

The Contractor shall report financial status to the Government on a monthly basis in accordance with the requirements of standard NASA Form 533M Financial Reports (DRL/DRD

PM-4).

3.4.7 Earned Value Management

Earned Value Management is not required for the PDS contract. However, NASA will implement a performance measurement system to monitor variances against baseline cost and schedule objectives. Data for the baseline and variance indicators is primarily derived from NASA Form 533 reporting.

3.4.8 Contract Performance Report (Applicable to all CLINs)

A Contract Performance Report is not required for the PDS contract.

3.4.9 Configuration Management (Applicable to all CLINs)

The Contractor shall follow its internal configuration management processes to manage and control documentation, and hardware and software configuration for the entire PDS contract. The

80LARC22R0001

Draft Release

Contractor shall describe its configuration management process in accordance with DRL/DRD

PM-5.

3.4.10 Risk Management (Applicable to all CLINs)

The Contractor shall follow its internal Risk Management Process for the PDS contract.

Overall, risk management shall be used to ensure successful achievement of the mission’s objectives within the established resource, funding, and schedule constraints. The Contractor’s risk management methodology shall provide for regularly scheduled, continuous risk assessments and provide a risk summary in their MPSR. The Contractor shall describe its Risk Management Process in accordance with DRL/DRD PM-7.

3.4.11 Reviews and Meetings

The Contractor shall participate and support a variety of Government-led formal and informal reviews and meetings as set forth below.

3.4.11.1 Formal Project Lifecycle Reviews (Applicable to all CLINs)

The Government will specify Terms of Reference, set agendas, and lead Project Lifecycle Reviews. The Contractor shall prepare and present materials at the following reviews, at the specified location, in accordance with NPR 7120.5F and NPR 7123.1C.

• PDR (DRL 1.6) (CLIN #1) at Contractor facilities

• CDR (DRL 2.8) (CLIN #2) at Contractor facilities

• Hardware Acceptance Review (HAR) (DRL 4.1) (CLIN #4) at Contractor facilities

• Shipping Review (SR) (DRL 4.1) (CLIN #4) at Contractor facilities

• Integration Review (IR) (DRL 4.2) (CLIN #4) at Contractor facilities

The Contractor shall conduct or support the Flight Readiness Review cycle as required.

The Contractor shall support activities required to resolve Requests for Actions (RFAs) and Advisories issued at Lifecycle Reviews.

3.4.11.2 Key Decision Point Reviews (Applicable to all CLINs)

The Contractor shall support the Government by providing information used to prepare for Dragonfly project Key Decision Point (KDP) Reviews. The Government will lead these reviews and will present the material with Contractor virtual support if necessary.

3.4.11.3 Flight and Ground Safety Reviews (Applicable to all CLINs)

The Contractor shall support all Flight and Ground Safety Reviews in person or virtually as required.

The Contractor shall prepare briefing material covering safety data requirements.

80LARC22R0001

Draft Release

The Contractor shall support activities required to resolve RFAs and Advisories assigned to the Dragonfly PDS Project at Safety Reviews.

3.4.11.4 Integrated Baseline Review (Applicable to CLIN #1)

The Contractor shall conduct an Integrated Baseline Review (IBR) to verify the completeness, realism, and accuracy of the Contractor Performance Measurement Baseline (PMB). This involves verifying the technical content of the baseline and assessing the realism and accuracy of the related resources (performance budget and IMS) in accordance with DRL/DRD RE-11.

3.4.11.5 Technical Interchange Meetings (Applicable to all CLINs)

The Contractor shall conduct TIMs on an as-needed basis. The Contractor shall provide the necessary resources including the preparation of technical and programmatic data packages for distribution and presentation at the meetings. For planning purposes, the Contractor should plan on an average of one (1) meeting per year at NASA/LaRC and two (2) meetings per year at the Contractor facilities. The Contractor should plan each meeting for three working days.

3.4.11.6 Monthly Project Status Briefings (Applicable to all CLINs)

The Contractor shall participate in Monthly Project Status Briefings to discuss the content of the MPSR, DRL/DRD PM-1. It is anticipated that most briefings will be conducted via video conferences. Briefings may be conducted as face-to-face meetings - typically at the Contractor’s location - at the discretion of the Government.

3.4.11.7 Weekly Management Status Teleconferences (Applicable to all CLINs)

The Contractor shall participate in a scheduled weekly Management Status teleconference that is usually one hour in duration with the Government to communicate status, issues, and schedule progress for the contract effort

3.4.12 Government Access

3.4.12.1 Access to Controlled Facilities

The Contractor shall allow access by the Government to all Contractor facilities used during the performance of the contract.

The Contractor shall provide any required training for certifications needed for unescorted access to the Contractor buildings and escorted access to test and cleanroom facilities, GSE, and flight hardware during assembly, integration, test, characterization, and calibration activities.

3.4.12.2 On-Site Government Representatives

The Contractor shall accommodate the periodic on-site presence of Government personnel to participate in Safety and Mission Assurance activities; monitor PDS assembly, integration, and test activities; and perform other insight and oversight activities throughout the project life cycle.

While on-site, the Contractor shall provide desk space and wireless internet access.

80LARC22R0001

Draft Release

3.4.12.3 Subcontractor Visits

The Contractor shall invite the Government when the Contractor visits to Subcontractor facilities to observe Safety and Mission Assurance activities; monitor PDS assembly, integration, and test activities; and review procedures and policies.

4 CONTRACT LINE ITEM NUMBERS

4.1 Project Structure

The contractor shall provide all labor, materials, facilities, service, equipment, analysis, and management necessary to complete all tasks in this section (4). Tasks shall satisfy the requirements defined in Section 3.

This SOW is broken up into three phases:

1) Phase B – Preliminary Design and Technology Completion

2) Phase C – Final Design and Fabrication

3) Phase D – System Assembly, Integration and Test, and Launch

Each phase has a key milestone at the end. The phasing and associated task sequencing is intended to provide a logical progression in the planning, design, testing, fabrication, and delivery of the PDS. Key milestones for each Phase are summarized in Table 2.

Table 2. PDS SOW Phase Key Milestones.

Phase Phase Overview Key Milestones

B Create a preliminary design for the PDS that meets requirements. Create a draft version of the ICD. Conduct necessary analyses. Deliver required documentation.

Preliminary Design Review (PDR)

C Create a final design for the PDS that meets requirement.

Create a final version of the ICD. Conduct necessary testing and analyses. Deliver required documentation.

Critical Design Review (CDR)

D Conduct necessary testing and analyses. Deliver Engineering Model to LMS. Qualify PDS. Deliver Flight Unit to I&T.

Engineering Model Delivery.

Hardware Acceptance and

Shipping Reviews. Integration Review. Flight Unit Delivery to I&T

80LARC22R0001

Draft Release

4.2 Contract Line Item Number (CLIN)

The work described in this SOW will be considered completed when all Contract Line Item Numbers (CLINs), defined in Table 3, and all items in the Contract Data Requirements List (DRLs), as defined in Section 5, have been received and accepted by NASA LaRC.

Table 3. Contract Line Item Numbers (CLINs).

Phase Line

Item # Item Deliverable Qty.

Final Delivery Date (All items within a

CLIN)

B 1 Phase B Data Package Data Package NA 6/6/2022 C 2 Phase C Data Package Data Package NA 6/26/2023

D

Engineering Model Delivery & Inspection

Hardware and Data Package

1 TBS

4 Flight Unit Delivery Hardware and Data Package

1 12/5/2025

5 Phase D Data Package Data Package NA TBS

4.3 CLINs Descriptions

4.3.1 CLIN #1 – Phase B Data Package

The primary purpose of CLIN #1 is to create a preliminary design that passes the preliminary design review.

4.3.1.1 Kickoff Meeting and Requirements Review

The purpose of the Kickoff meeting is to confirm that all stakeholders have a common understanding of the work and their responsibilities, and to assess challenges involved in the design, fabrication, and qualification of the PDS. The purpose of the Requirements Review is to assure that there is a common understanding of the requirements, clarify requirements, and to discuss requirements that may need revision, deletion, or addition. It is intended that the Kickoff Meeting and Requirements Review be conducted back-to-back.

This sub-task will be considered complete once the agreed-to Contractor action items arising from the Kickoff Meeting and the Requirements Review have been completed.

4.3.1.2 Draft ICD

In cooperation with LMS, APL, and NASA LaRC, the Contractor shall create a draft ICD.

This sub-task will be considered complete when a draft ICD has been written, agreed to, and delivered to NASA LaRC. Agreement on this draft ICD has to include the PDS Contractor, LMS, APL, and NASA LaRC.

80LARC22R0001

Draft Release

4.3.1.3 Draft Analysis Plan

The Contractor shall create a draft analysis plan to verify that the PDS will meet requirements.

This sub-task will be considered complete once the draft Analysis Plan has been received and approved by NASA LaRC.

4.3.1.4 Draft Test Plan

The Contractor shall create a draft test plan for the element, component, and subsystem level testing required to verify that the PDS will meet requirements.

This sub-task will be considered complete once the draft Test Plan has been received and approved by NASA LaRC.

4.3.1.5 Preliminary Material Identification and Usage List (MIUL)

The Contractor shall generate a draft Material Identification and Usage List (MIUL) spreadsheet in the specified format based on the PDS preliminary design.

This sub-task will be considered complete once the draft MIUL has been received and approved by the Dragonfly Materials and Processes Lead Engineer (APL).

4.3.1.6 Preliminary Design

The Contractor shall create a preliminary design for the PDS that meets requirements. This preliminary design shall be documented in a report and a presentation. The Contractor shall present the PDS preliminary design at the PDS Preliminary Design Review. After the PDS Preliminary Design Review the contractor shall take the necessary actions requested by Requests for Action (RFAs).

This sub-task will be considered complete once the PDS Preliminary Design Review has been passed successfully, all RFAs have been addressed, and NASA LaRC has accepted the PDS preliminary design.

4.3.2 CLIN #2 – Phase C Data Package

The primary purpose of CLIN #2 is to create a detailed design that passes the preliminary design review, and to perform and document the analyses and tests that support the detailed design.

4.3.2.1 Updated ICD

In cooperation with LMS, APL, and NASA LaRC, the Contractor shall create an updated ICD.

It is understood that the ICD is a living document and may be revised after the delivery specified in this sub-task. A revision history shall be part of this document.

This sub-task will be considered complete when the updated ICD has been written, agreed to, and delivered to NASA LaRC. Agreement on this updated ICD has to include the PDS Contractor, LMS, APL, and NASA LaRC.

80LARC22R0001

Draft Release

4.3.2.2 Updated Analysis Plan

The Contractor shall create an updated analysis plan to verify that the PDS will meet requirements.

This sub-task will be considered complete once the updated Analysis Plan has been received and approved by NASA LaRC. Note: It is understood that the Analysis Plan is a living document and may be revised after the delivery specified in this sub-task. A revision history shall be part of this document.

4.3.2.3 Updated Test Plan

The Contractor shall create an updated test plan for the element, component, and subsystem level testing required to verify that the PDS will meet requirements.

This sub-task will be considered complete once the updated Test Plan has been received and approved by NASA LaRC. Note: It is understood that the Test Plan is a living document and may be revised after the delivery specified in this sub-task. A revision history shall be part of this document.

4.3.2.4 Updated Material Identification and Usage List (MIUL)

The Contractor shall generate an updated Material Identification and Usage List (MIUL) spreadsheet in the specified format based on the detailed PDS design.

This sub-task will be considered complete once the updated MIUL has been received and approved by the Dragonfly Materials and Processes Lead Engineer (APL). Note: It is understood that the MIUL is a living document and may be revised after the delivery specified in this sub-task. A revision history shall be part of this document.

4.3.2.5 Analysis Reports

The Contractor shall create reports of the various analyses performed in support of the PDS detailed design.

This sub-task will be considered complete once the analysis reports have been received and approved by NASA LaRC.

4.3.2.6 Test Reports

The Contractor shall create reports of the various tests performed in support of the PDS detailed design.

This sub-task will be considered complete once the test reports have been received and approved by NASA LaRC.

4.3.2.7 Requirement Verification Plan

The Contractor shall create a Requirement Verification Plan as described in the requirements.

This sub-task will be considered complete once the Requirement Verification Plan has been received and approved by NASA LaRC. Note: It is understood that the Requirement Verification

80LARC22R0001

Draft Release

Plan is a living document and will be revised after the delivery specified in this sub-task. A revision history shall be part of this document.

4.3.2.8 Detailed Design

The Contractor shall create a detailed design for the PDS that meets requirements. This detailed design shall be documented in a report and a presentation. The Contractor shall present the PDS detailed design at the PDS Critical Design Review. After the PDS Critical Design Review the contractor shall take the necessary actions specified by Requests for Action (RFAs).

This sub-task will be considered complete once the PDS Preliminary Design Review has been passed successfully, all RFAs have been addressed, and NASA LaRC has accepted the PDS preliminary design.

4.3.3 CLIN #3 – Engineering Model Delivery and Inspection

The primary purpose of CLIN #3 is to deliver an Engineering Model to LMS for I&T, and to inspect the Engineering Model after it has been returned by LMS upon completion of I&T.

4.3.3.1 Engineering Model Delivery

The Contractor shall deliver an Engineering Model to LMS for I&T by the specified date. This Engineering Model shall conform to the requirements specified for it in Attachment A:

Requirements, Section 1.8. The Engineering Model delivery shall be accompanied with the appropriate drawings and mass properties values as defined in the ICD.

This sub-task will be considered complete once the Engineering Model and its documentation is accepted by LMS for I&T.

4.3.3.2 Engineering Model Inspection

Once LMS has completed its I&T with the Engineering Model, it will be returned to the Contractor. The Contractor shall inspect the Engineering Model as specified in the requirements for any damage or wear. Observations from this inspection shall be documented in a report which shall be provided to NASA LaRC.

This sub-task will be considered complete once the Engineering Model inspection report is provided to, and accepted by, NASA LaRC.

4.3.4 CLIN #4 – Flight Unit Delivery

The primary purpose of CLIN #4 is to deliver the Flight Unit to I&T.

4.3.4.1 Hardware Acceptance and Shipping Reviews

The purpose of the Hardware Acceptance and Shipping Reviews is to confirm that the Flight Unit is ready to be accepted for I&T. The Contractor shall prepare documentation and a presentation for these reviews. It is intended that the Hardware Acceptance and Shipping Reviews be conducted back-to-back.

80LARC22R0001

Draft Release

This sub-task will be considered complete once the agreed-to Contractor action items arising from the Hardware Acceptance and Shipping Reviews have been completed and accepted by NASA LaRC.

4.3.4.2 Integration Review

The purpose of the Integration Review is to confirm that the Flight Unit is ready for I&T, including all processes and procedures. The Contractor shall prepare documentation and a presentation for this review.

This sub-task will be considered complete once the agreed-to Contractor action items arising from the Integration Review have been completed and accepted by NASA LaRC.

4.3.4.3 Flight Unit Delivery

The Contractor shall deliver a Flight Unit that meets all applicable requirements listed in Attachment A: Requirements. All portions of the Flight Unit, except the cover(s), shall be delivered to the Kennedy Space Center (KSC). The cover(s) shall be delivered to LMS (Colorado) for bonding of the TPS (once the TPS is bonded to the covers, LMS will ship them to KSC).

This sub-task will be considered complete once the cover(s) are accepted by LMS, and the Flight Unit is accepted by NASA LaRC.

4.3.4.4 Flight Unit I&T Support

The Contractor shall provide an on-site representative at KSC on the date that the Flight Unit is to be integrated with the aeroshell.

This sub-task will be considered complete once the Flight Unit has been integrated with the aeroshell.

4.3.5 CLIN #5 – Phase D Data Package

The primary purpose of CLIN #5 is deliver the final set of documentation on the PDS.

4.3.5.1 Final ICD

In cooperation with LMS, APL, and NASA LaRC, the Contractor shall create a final ICD.

This sub-task will be considered complete when the final ICD has been written, agreed to, and delivered to NASA LaRC. Agreement on this final ICD has to include the PDS Contractor, LMS, APL, and NASA LaRC.

4.3.5.2 Final Analysis Plan

The Contractor shall create a final analysis plan to verify that the PDS will meet requirements.

This sub-task will be considered complete once the final Analysis Plan has been received and approved by NASA LaRC.

80LARC22R0001

Draft Release

4.3.5.3 Final Test Plan

The Contractor shall create a final test plan for the element, component, and subsystem level testing required to verify that the PDS will meet requirements.

This sub-task will be considered complete once the final Test Plan has been received and approved by NASA LaRC.

4.3.5.4 Final Material Identification and Usage List (MIUL)

The Contractor shall generate a final Material Identification and Usage List (MIUL) spreadsheet in the specified format based on the detailed PDS design.

This sub-task will be considered complete once the final MIUL has been received and approved by the Dragonfly Materials and Processes Lead Engineer (APL).

4.3.5.5 Analysis Reports

The Contractor shall create written reports in contractor format of the various analyses performed in support of the PDS design and qualification.

This sub-task will be considered complete once all analysis reports (updates from previous deliveries and new deliveries) been received and approved by NASA LaRC.

4.3.5.6 Test Reports

The Contractor shall create written reports in contractor format of the various tests performed in support of the PDS design and qualification.

This sub-task will be considered complete once the test reports (updates from previous deliveries and new deliveries) have been received and approved by the NASA LaRC.

4.3.5.7 Final Requirement Verification Plan

The Contractor shall create a final Requirement Verification Plan as described in the requirements.

This sub-task will be considered complete once the final Requirement Verification Plan has been received and approved by NASA LaRC.

4.3.5.8 End Item Data Package (EIDP)

The Contractor shall create an End Item Data Package (EIDP) as described in the requirements.

This sub-task will be considered complete once the EIDP has been received and approved by NASA LaRC.

80LARC22R0001

Draft Release

5 CONTRACTOR DATA REQUIREMENTS LIST (DRL)

The Contractor shall submit the following Contract Data Requirement List (DRL) documents.

Table 4 lists the DRLs to be delivered during the period of performance of the contract. Additional data descriptions follow the table. The numbering system of the DRLs are parallel to those of the CLINs. The formats and drawing standards used shall be those normally used by the Contractor unless specified otherwise.

Approvals are required on all DRL items listed in Table 4. The specified approver will have thirty (30) working days to review, comment, and provide approval. Approval/disapproval will be contractually communicated through the NASA LaRC Contract Administrator. Necessary updates are to be incorporated into the updated deliverables and re-submitted to NASA LaRC within thirty

(30) working days of receipt of comments. It is recommended that DRLs be pre-coordinated with NASA LaRC to minimize iterations. Lack of response to DRLs from the specified approver does not constitute approval. All DRL deliverables shall be in electronic form.

80LARC22R0001

Draft Release

Table 4. Contract Data Requirement Lists (DRLs).

Associated

CLIN

DRL # DRL Title Delivery Date

Phase B

CLIN #1

DRL 1.1 Kickoff Meeting and Requirements Review At least 1 day prior to reviews

DRL 1.2 Draft ICD At least 1 week prior to PDR

DRL 1.3 Draft Analysis Plan At least 1 week prior to PDR

DRL 1.4 Draft Test Plan At least 1 week prior to PDR

DRL 1.5

Preliminary Materials Identification and Usage List

(MIUL)

At least 1 week prior to PDR

DRL 1.6 Preliminary Design At least 1 week prior to PDR

Phase C

CLIN #2

DRL 2.1 Updated ICD At least 1 week prior to CDR

DRL 2.2 Updated Analysis Plan At least 1 week prior to CDR

DRL 2.3 Updated…