NASA Mission Design Process

V. Hunter Adams (vha3), MAE 4160/5160, Spring 2020

from IPython.display import Latex
from IPython.display import Image
from IPython.core.display import HTML

In this lecture . . .

1. Brief Q/A regarding syllabus
2. The phases, key decision points, and technical reviews of the space mission design process.
3. Projects overview (during (2), above)

Sources and further reading

1. https://nodis3.gsfc.nasa.gov/npg_img/N_PR_7123_001B_/N_PR_7123_001B_.pdf
2. https://www.nasa.gov/seh/3-project-life-cycle
3. https://ntrs.nasa.gov/search.jsp?R=19910008874

Brief syllabus overview/questions

1. Any questions about the grading structure?
2. If there are questions about the project, you may ask them, but I'm going to go over the project in much more detail this lecture.
3. Any questions about expectations?

Why is learning the NASA project life cycle important?

Space missions are complicated. They are complicated both technically and logistically, and there are often a huge amount of stakeholders involved (a stakeholder being any group or individual who can affect or is affected by the achievement of the mission's objectives). Complicated projects have the potential to snowball themselves, where small mistakes or miscommunications early-on manifest as massive costs later on. The more people involved, and the more complicated the objectives, the greater the risk.

In order to combat this, NASA has developed a project life cycle. That's what we're going to discuss today. You should care about this for a couple of reasons.

First of all, this class's project is modeled off of the project life cycle that I'm about to describe. So, to the extent that you care about the project, you should care about this content.

The other reason that you should care is that this process permeates the entire aerospace industry. If you go work at NASA, you'll obviously hear much of the vocabulary that we're about to go over thrown around. But, you'll also hear it if you go work for a prime contractor, or for the Air Force/Space Force, and even at sub-prime contractors. It's good to know the language of your industry. Familiarity with this process and the language used to describe it will improve your ability to communicate with your colleagues in aerospace.

Aerospace loves acronyms and initialisms, so get ready for a lot of those.

An overview of the process

The project life cycle categorizes everything that should be done to accomplish a project into distinct phases, and separates each of those phases by Key Decision Points (KDP's). Each of these KDP's is located at natural points for go/no-go decisions to be made by the decision authority. If a project passes a particular KDP, then it usually proceeds to the next one. If it does not, it may be allowed to try again after addressing deficiencies, or it may be terminated.

A project is divided into three broad stages, which are then sub-divided into phases. There is the pre-formulation stage, the formulation stage, and the implementation stage. We will walk through this process from beginning to end, and we'll take some time to go over the technical reviews associated with each phase.

Image("overview.png", width=800)

I will be spending a disproportionately large amount of time on Phases A-B, since these are the phases where the design of the spacecraft is taking place, and these are the phases that we are simulating in this class.

Program Pre-Formulation

Pre-Phase A: Concept Studies

Goals:

1. Produce a variety of ideas and alternatives from which new programs/projects can be selected.
2. Study feasibility of desired system.
3. Develop mission concepts.
4. Identify potential technology needs.

Outcomes:

1. Mission concepts
2. Draft system-level requirements.

Reviews:

1. Mission Concept Review (MCR).

MCR: The MCR affirms the mission/project need and evaluates the proposed mission's objectives and the ability of the concept to fulfill those objectives. This review is passed if the following success criteria are met:

1. Mission objectives are clearly defined and stated and are unambiguous and internally consistent.
2. The selected concept(s) satisfactorily meets the stakeholder expectations.
3. The mission is feasible. A concept has been identified that is technically feasible. A rough cost estimate is within an acceptable cost range.
4. The concept evaluation criteria to be used in candidate systems evaluation have been identified and prioritized.
5. The need for the mission has been clearly identified.
6. The cost and schedule estimates are credible and sufficient resources are available for project formulation.
7. The program/project has demonstrated compliance with applicable NASA and implementing Center requireents, standards, processes, and procedures.
8. TBD and TBR items are clearly identified with aceptable plans and schedule for their disposition
9. Alternative concepts have adequately considered the use of existing assets or proucts that could satisfy the mission or parts of the mission.
10. Technical planning is sufficient to proceed to the next phase.
11. Risk and mitigation strategies have been identified and are acceptable based on technical risk assesments.
12. Software components meet the exit criteria defined in the NASA-HDBK-2203, NASA Software engineering handbook.
13. Concurrence by the responsible center spectrum manager that RF needs have been properly identified and addressed.

Mission Concept: A mission concept is a high-level vision or idea that rationalizes and guides the rest of the architecture process. These mission concepts may sometimes be based on an analogy (e.g. crane, airbag, etc.) and it starts to define some of the design variables and technologies that will be necessary.

Program Formulation

Our class project simulates Project Formulation -- mostly Phase A and some Phase B. We assume that each mission option for the project has passed MCR.

"The program Formulation Phase establishes a cost-effective program that is demonstrably capable of meeting Agency and mission directorate goals and objectives. The program Formulation Authorization Document (FAD) authorizes a Program Manager (PM) to initiate the planning of a new program and to perform the analyses required to formulate a sound program plan. The lead systems engineer provides the technical planning and concept development or this phase of the program life cycle. Planning includes identifying the major technical reviews that are needed and associated entrance and exit criteria. Major reviews leading to approval at KDP I are the SRR, SDR, PDR, and governing Program Management Council (PMC) review. A summary of the required gate products for the program Formulation Phase can be found in the governing NASA directive (e.g., NPR 7120.5 for space flight programs, NPR 7120.7 for IT projects, NPR 7120.8 for research and technology projects). Formulation for all program types is the same, involving one or more program reviews followed by KDP I where a decision is made approving a program to begin implementation." - NASA SEH

Phase A: Concept and Technology Development

In Phase A, the proposed mission concept from the Pre-Phase A Concept Study is developed. Activities are performed to fully develop a baseline mission concept and begin or assume responsibility for the development of needed technologies. This work, along with interactions with stakeholders, matures the mission concept and project requirements.

A lot of effort in Phase A is placed on analyzing mission requirements and establishing a mission architecture. The emphasis moves away from concept design and toward concept optimization. The goals and objectives are solidified, system requirements are established, a top-level system architecture is established, and a concept of operations. In Phase A, many alternatives are considered.

Goals:

1. To determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatible with NASA's strategic plans.
2. Develop final mission concept, system-level requirements, and needed system structure technology developments
3. Initiate technology developments.

Outcomes:

1. Mission architecture and CONOPS
2. Top-level requirements
3. Work breakdown structure
4. Systems Engineering Management Plan
5. Technologies

Reviews:

1. System Requirements Review (SRR), halfway through
2. Mission/System Definition Review (MDR/SDR)

SRR: The SRR evaluates whether the functional and performance requirements defined for the system are responsive to the program's requirements and ensures the preliminary project plan and requirements will satisfy the mission. The SRR Review is passed if the following criteria are met:

1. The functional and performance requirements defined for the system are responsive to the parent requirements and represent achievable capabilities.
2. The maturity of the requirements definition and associated plans is sufficient to begin Phase B.
3. The project utilizes a sound process for the allocation and control of requirements throughout all levels, and a plan has been defined to complete the requirements definition at lower levels within schedule constraints.
4. Interfaces with external entities and between major internal elements have been identified.
5. Preliminary approaches have been determined for how requirements will be verified and validated.
6. Major risks have been identified and technically assessed, and viable mitigation strategies have been defined.
7. The program/project has demonstrated compliance with applicable NASA and implementing Center requirements, standards, processes, and procedures.
8. TBD and TBR items are clearly identified with acceptable plans and schedule for their disposition.
9. Software components meet the exit criteria defined in NASA-HDBK-2203, NASA Software Engineering Handbook.
10. Concurrence by the responsible Center spectrum manager that the program/project has provided requisite RF system data.

How to think about a spacecraft at the SRR level of abstraction

When you're assembling an SRR document, remember that the spacecraft does not exist yet, even in your mind. At this point in the design process, you should not yet have an image in your mind of what the spacecraft looks like. As we discussed briefly last time, every aspect of the spacecraft will be designed such that it meets the requirements that you're laying out in this document. For now, you should think of the spacecraft purely as a blackbox system that contains the usual subsystems, and which is tasked with accomplishing some task. By reading your SRR document, I should be able to learn the answers to the following questions:

In short: What does the spacecraft need to do?

1. What is required for full mission success?
2. What is required for partial mission success?
3. What is required for minimal mission success?
4. What are the system-level requirements (functional, performance, and external)?
5. What is required of the propulsion subsystem?
6. What is required of the CDH subsystem?
7. What is required of the thermal subsystem?
8. What is required of the attitude determination and control subsystem?
9. What is required of the telemetry and command subsystem?
10. What is required of the structure subsystem?
11. What is required of the power subsystem?
12. What is required of any other relevant subsystems (EDL, ECLSS, payload, etc.)?
13. The key trade studies to be investigated before PDR
14. The major risks and preliminary mitigation strageties

Here are some examples of systems-level SRR-type requirements for the Huygens probe, from the Phase A report for Cassini/Huygens:

Image("probe.png", width=800)

At SRR, the spacecraft is the set of requirements. We are going to spend next lecture talking about how to write these requirements. The CONOPS is coming into focus, and is used to inform your requirements.

CONOPS: Describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time sequenced manner. It describes the system from an operational perspective and helps facilitate an understanding of the system goals. It stimulates the development of the requirements and architecture related to the user elements of the system. It serves as the basis for subsequent definition documents and provides the foundation for the long-range operational planning activities. This is the mission narrative, and includes the various spacecraft modes and mission phases.

SDR: The MDR/SDR evaluates whether the proposed mission/system architecture is responsive to the program mission/system functional and performance requirements and requirements have been allocated to all functional elements of the mission/system. The SDR Review is passed if the following criteria are met:

1. The proposed mission/system architecture is credible and responsive to program requirements and constraints, including resources.
2. The mission can likely be achieved within available resources with acceptable risk.
3. The project's mission/system definition and associated plans are sufficiently mature to begin Phase B.
4. All technical requirements are allocated to the architectural elements.
5. The architecture tradeoffs are completed, and those planned for Phase B adequately address the option space.
6. Significant development, mission, and health and safety risks are identified and technically assessed, and a process and resources exist to manage the risks.
7. Adequate planning exists for the development of any enabling new technology.
8. The operations concept is consistent with proposed design concept(s) and is in alignment with the mission requirements.
9. The program/project has demonstrated compliance with applicable NASA and implementing Center requirements, standards, processes, and procedures.
10. TBD and TBR items are clearly identified with acceptable plans and schedule for their disposition.
11. Software components meet the exit criteria defined in NASA-HDBK-2203, NASA Software Engineering Handbook.
12. Concurrence by the responsible Center spectrum manager that RF spectrum considerations have been addressed.

Please see NASA-TM-103374, "CASSINI. Report on the Phase A study: Saturn Orbiter and Titan probe" for an example of an (abridged) Phase A study. I will also be providing good examples from previous years (different projects) for you all to see.

How to think about a spacecraft at the SDR level of abstraction

By SDR, there should be a coherent mission architecture, and the spacecraft system architecture should be established. This means that the specific actuators/sensors/processors/etc that compose each particular subsystem have been chosen, after conducting trade studies, in order to satisfy the requirements from the SRR. Let's define a few more terms.

Mission Architecture: This is the description of the high-level function and components of the system as well as the relationships between them. The major functions of a space mission will include the primary functions (acquiring, storing, and sending mission data), and the support functions (propelling, powering, controlling positin and attitude, supporting loads, controlling thermal state, acquiring/storing/sending telemetry, etc.). The major components include payload, bus, ground stations, launch vehicles, and orbits. See below, from SMAD:

Image("smad.png", width=600)

At this point in the design process, you should be able to construct a functional block diagram of the entire spacecraft, like the example below from Cassini's Phase A report. The general architecture of the spacecraft should be established.

Image("block.png", width=500)

Image("cassini.png", width=500)

At SDR, the spacecraft is a functional block diagram and associated preliminary architecture. The mission architecture and concept of operations are baselined.

Phase B: Preliminary Design and Technology Completion

Phase B is the last phase before the project is approved for implementation. In this phase, activities are performed to create a formal flow down of the project-level performance requirements to a complete set of system and subsystem design specifications for both flight and ground elements and corresponding preliminary designs. At this point, the technical requirements should be sufficiently detailed to establish firm schedule and cost estimates for the project.

This phase culminates in a series of Preliminary Design Reviews (PDR's), both system-level and for lower level end items as appropriate. These PDR's represent the successive refinement of requirements into designs. From this point on, nearly all changes to the baseline are expected to represent successive refinements, not fundamental changes. Significant design changes beyond this phase are increasingly expensive.

Goals:

1. To define the project in enough detail to establish an initial baseline capable of meeting mission needs.
2. Develop system structure and end product (and enabling product) requirements.
3. Generate a preliminary design for each system structure end product.
4. Finalize technology development

Outcomes:

1. Baseline design
2. Interface Control Documents
3. Updated requirements
4. Science/operations plan
5. Technologies

Reviews:

1. Preliminary Design Review (PDR)

PDR: The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. This review is passed when the following criteria are met:

1. The top-level requirements, including mission success criteria, TPMs, and any sponsor-imposed constraints are agreed upon, finalized, stated clearly, and consistent with the preliminary design.
2. The flow down of verifiable requirements is complete and proper or, if not, an adequate plan exists for timely resolution of open items. Requirements are traceable to mission goals and objectives.
3. The program cost, schedule, and JCL analysis (when required) are credible and within program constraints and ready for NASA commitment.
4. The preliminary design is expected to meet the requirements at an acceptable level of risk.
5. Definition of the technical interfaces (both external entities and between internal elements) is consistent with the overall technical maturity and provides an acceptable level of risk.
6. Any required new technology has been developed to an adequate state of readiness, or backup options exist and are supported to make them viable alternatives.
7. The project risks are understood and have been credibly assessed, and plans, a process, and resources exist to effectively manage them.
8. Safety and mission assurance (e.g., safety, reliability, maintainability, quality, and Electrical, Electronic, and Electromechanical (EEE) parts) have been adequately addressed in preliminary designs and any applicable SandMA products (e.g., PRA, system safety analysis, and failure modes and effects analysis) meet requirements, are at the appropriate maturity level for this phase of the program's life cycle, and indicate that the program safety/reliability residual risks will be at an acceptable level.
9. Adequate technical and programmatic margins (e.g., mass, power, memory) and resources exist to complete the development within budget, schedule, and known risks.
10. The operational concept is technically sound, includes (where appropriate) human systems, and includes the flow down of requirements for its execution.
11. Technical trade studies are mostly complete to sufficient detail and remaining trade studies are identified, plans exist for their closure, and potential impacts are understood.
12. The program/project has demonstrated compliance with applicable NASA and implementing Center requirements, standards, processes, and procedures.
13. TBD and TBR items are clearly identified with acceptable plans and schedule for their disposition.
14. Preliminary analysis of the primary subsystems has been completed and summarized, highlighting performance and design margin challenges.
15. Appropriate modeling and analytical results are available and have been considered in the design.
16. Heritage designs have been suitably assessed for applicability and appropriateness.
17. Manufacturability has been adequately included in design.
18. Software components meet the exit criteria defined in NASA-HDBK-2203, NASA Software Engineering Handbook.
19. Concurrence by the responsible Center spectrum manager that the program/project has provided requisite RF system data.

How to think about a spacecraft at the PDR level of abstraction

At PDR, a design for the spacecraft is baselined. This means that the functional block diagram from SDR is translated into a baseline design for the spacecraft, with interface control documentation for the interactions among all of the subsystems. PDR updates and adds detail to the architecture established at SDR.

(Brief Aside) - Projects Overview

At this point, I'd like to pause for a moment to introduce the project options and discuss other details of the project. I'm doing this now because each of your project options comes in the form of a mission concept that is assumed to have passed the Mission Concept Review. Throughout the semester, you will be tasked with generating the documentation associated with the SRR, SDR, and (kind of) PDR reviews. Now that we know what those are, we can introduce the project options so that you all can make informed decisions.

Artificial Reef on Titan

It is dangerous to make any assumptions about alien life, particularly life as alien as may be found in Titan's lakes, but perhaps there are a few that are reasonable. For example, it is likely safe to assume that life in Titan's lakes is the result of an evolutionary process, and it's likely safe to assume that the evolutionary process on Titan also produced predators and prey. If there are predators pursuing prey in Titan's lakes, then it is certainly the case that there are prey evading predators. On Earth, this means finding hiding places. It probably means the same thing on Titan.

You are tasked with designing a mission which places infrastructure in which Titanic prey species may hide into the mare, and then detecting the presence and properties of organisms using that infrastructure. Much like we put infrastructure in the Earth's oceans to seed coral growth and attract sealife, you will put infrastructure in the mare to seed and attract whatever lives there. You are also expected to relay basic information about the chemistry of the mare.

Mission Objectives:

1. Place a 1x1 m, 150 kg artificial reef on the bottom of Kraken Mare (unknown depth, 2-15 meters) on Titan.
2. Communicate data from the sensors (cameras and chemistry sensors) on the reef to operators on Earth for a duration of not less than 4 weeks.

Key concepts:

1. Entry, descent, and landing
2. Interplanetary trajectory design
3. Novel communications design

Image("reef.jpg", width=500)

A Mysterious Startup

You've been approached by a startup that is developing a constellation of low-Earth spacecraft for tracking and gathering information about objects moving quickly through the Earth's atmosphere (jets, missiles, etc.). They won't tell you precisely what payload they're carrying, but they tell you that they need to be able to keep the boresight of an instrument trained on planes as fast as an SR-71 Blackbird. They want the constellation to provide persistent coverage of the entire globe, for aircraft at any altitude up to 26 km.

Mission Objectives:

1. Design a spacecraft which can track an SR-71 Blackbird (i.e. keep the boresight of an instrument pointed at it).
2. Design a constellation of such spacecraft to provide persistent global coverage for altitudes up to 26 km.

Key Concepts:

1. Agility/pointing
2. Remote sensing

Image("blackbird.jpg", width=500)

Car Collector

On Feb. 6, 2018, SpaceX performed their first test of the Falcon Heavy. As a test payload, they carried a Tesla Roadster. That Roadster is now orbiting the Sun on a trajectory that carries it from approximately 1AU to beyond Mars orbit.

You've been approached by a very wealthy car collector that would like to add that particular Roadster to his collection. You are tasked with rendesvousing with the Roadster and returning it to the Earth. This mission may take as long as 30 years, but you may not damage the Roadster.

Mission Objectives:

1. Return the Tesla Roadster to the surface of the Earth without damaging it in 30 years or less.

Key concepts:

1. Deep space rendesvous
2. Entry, descent, and landing
3. Space robotics

Image("starman.jpg", width=500)

Lunar Termites

Kirstin Petersen's lab at Cornell (the Collective Embodied Intelligence Lab) builds robots that perform collective construction. Much like termites, which collectively build mound structures without any central control, Prof. Petersen's robots collectively build user-specified structures without a central controller.

Let us suppose that Prof. Petersen and her students have designed a collection of small robots that will build structures from lunar regolith (runways, habitats, etc.). If we get them to the right place on the Moon and we let them go, then we can leave them alone and they will begin building structures.

You are tasked with doing exactly that. You must land a mothership containing 100 of Prof. Petersen's robots (TERMES) at a particular location on the Moon, and you must do so softly enough that none of them break. Then, you must relay information about their progress.

Mission Objectives:

1. Place 100 of Prof. Petersen's robots on the surface of the Moon without damaging them (assume fragility equivalent to Mars Exploration Rovers).
2. Communicate sufficient information to ground operators to maintain knowledge of each robot's health and status, and their collective construction progress for not less than 1 year. This includes health and status information from each robot, and at least 10 4k photos of construction progress each day.

Key concepts:

1. Entry, descent, and landing
2. Novel communications
3. Lunar trajectory design

Image("mound.jpg", width=500)

Martian Positioning System

You are tasked with designing a martian positioning system. From any location on the surface of Mars, a receiver must be able to deduce its location to the same accuracy/precision as GPS on Earth. You may assume access to Superheavy/Starship/SLS.

Mission Objectives:

1. Create a martian positioning system that enables receivers anywhere on the surface of the Moon to determine position/velocity at any time with accuracy/precision equal to that of GPS.
2. Design the system such that the receivers are of equivalent size/power draw used for Earth's global positioning system.

Key concepts:

1. Constellation design
2. Interplanetary trajectory design

Image("mars.jpeg", width=500)

How to be successful in this project

One week from today, your project preference is due. You're asked to please submit your project preferences ranked 1-5 (1 means you most prefer that project, 5 means you least prefer that project) and a list of up to 3 other students that you would like to work with.

The schedule for this class (see the syllabus) was put together strategically. You'll notice that the SRR document is due a couple weeks after we finish covering the the mission design process, trades, and requirements. And you'll notice that the SDR document is due 1 week after we've finished covering all of the major subsystems in the spacecraft.

Please set aside a 1-2 hours each week to meet with your group, starting next week. At each of your weekly meetings, use the material that we've covered that week to put together the relevant sections for your SRR or SDR documents. This is the best way to learn this material, and it will make your life so much easier at the end of the semester. Commit to a schedule now, early in the semester, and do not schedule other obligations on top of your weekly meeting with your group.

(Back to the NASA project life cycle) - Program Implementation

In this stage, the objective is to execute the program and constituent projects and ensure that the program continues to contribute to Agency goals and objectives within funding constraints.

Note: This class focuses on spacecraft design, which takes place largely in Phases A-B. So, while we'll cover the remaining phases for completeness, they do not factor in to this course as much as the previous phases.

Phase C: Final design and fabrication

Goals:

1. Complete and document the detailed design of the system that meets the detailed requirements to fabricate, code, or otherwise realize the products.
2. Generate final designs for each system structure end product
3. Fabricate hardware
4. Code software
5. Plan integration and testing.

Outcomes:

1. Finalized designs and components
2. Integration plan and procedures
3. Verification and validation procedures
4. Operations plan

Reviews:

1. Critical Design Review (CDR)
2. System Integration Review (SIR)

CDR: The CDR demonstrates that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test. CDR determines that the technical effort is on track to complete the system development, meeting performance requirements within the identified cost and schedule constraints. This review is passed if the following criteria are met:

1. The detailed design is expected to meet the requirements with adequate margins.
2. Interface control documents are sufficiently mature to proceed with fabrication, assembly, integration, and test, and plans are in place to manage any open items.
3. The program cost and schedule estimates are credible and within program constraints.
4. High confidence exists in the product baseline, and adequate documentation exists or will exist in a timely manner to allow proceeding with fabrication, assembly, integration, and test.
5. The product verification and product validation requirements and plans are complete.
6. The testing approach is comprehensive, and the planning for system assembly, integration, test, and launch site and mission operations is sufficient to progress into the next phase.
7. Adequate technical and programmatic margins (e.g., mass, power, memory) and resources exist to complete the development within budget, schedule, and known risks.
8. Risks to mission success are understood and credibly assessed, and plans and resources exist to effectively manage them.
9. Safety and mission assurance (e.g., safety, reliability, maintainability, quality, and EEE parts) have been adequately addressed in system and operational designs, and any applicable SandMA products (e.g., PRA, system safety analysis, and failure modes and effects analysis) meet requirements, are at the appropriate maturity level for this phase of the program's life cycle, and indicate that the program safety/reliability residual risks will be at an acceptable level.
10. The program/project has demonstrated compliance with applicable NASA and implementing Center requirements, standards, processes, and procedures.
11. TBD and TBR items are clearly identified with acceptable plans and schedule for their disposition.
12. Engineering test units, life test units, and/or modeling and simulations have been developed and tested per plan.
13. Material properties tests are completed along with analyses of loads, stress, fracture control, contamination generation, etc.
14. EEE parts have been selected, and planned testing and delivery will support build schedules.
15. The operational concept has matured, is at a CDR level of detail, and has been considered in test planning.
16. Manufacturability has been adequately included in design.
17. Software components meet the exit criteria defined in NASA-HDBK-2203, NASA Software Engineering Handbook.
18. Concurrence by the responsible Center spectrum manager that the program/project has provided requisite RF system data.

How to think about a spacecraft at the CDR level of abstraction

At CDR, the design is complete enough that you could handoff the documents to somebody else and they could build the entire system. Furthermore, that system would function and would meet all of the requirements from previous phases. The spacecraft is finished, but not yet built/tested. At this point, the spacecraft "looks" exactly like the spacecraft will look when it is built. There is no more abstraction.

SIR: An SIR ensures segments, components, and subsystems are on schedule to be integrated into the system, and integration facilities, support personnel, and integration plans and procedures are on schedule to support integration.

Phase D: System Assembly, Integration and Test, Launch

Goals:

1. To assemble and integrate the products to create the system, while developing confidence that it will meet system requirements.
2. Put the system in launch/flight configuration
3. Launch and prepare for operations.
4. Perform system end product implementation, assembly, integration, and test. Transition to use.

Outcomes:

1. Integrated and validated system
2. Operation procedures

Reviews:

1. Test Readiness Reviews (TRRs)
2. System Acceptance Review (SAR) or pre-Ship Review
3. Operational Readiness Review (ORR)
4. Flight Readiness Review (FRR)

TRR: A TRR for each planned test or series of tests ensures that the test article (hardware/software), test facility, support personnel, and test procedures are ready for testing and data acquisition, reduction, and control.

SAR: The SAR verifies the completeness of the specific end products in relation to their expected maturity level, assesses compliance to stakeholder expectations, and ensures that the system has sufficient technical maturity to authorize its shipment to the designated operational facility or launch site.

ORR: The ORR ensures that all system and support (flight and ground) hardware, software, personnel, procedures, and user documentation accurately reflect the deployed state of the system and are operationally ready.

FRR: The FRR examines tests, demonstrations, analyses, and audits that determine the system's readiness for a safe and successful flight or launch and for subsequent flight operations. The FRR also ensures that all flight and ground hardware, software, personnel, and procedures are operationally ready.

Phase E: Operations and Sustainment

Goals:

1. To conduct the mission and meet the initially defined need.
2. Maintain support for that need.
3. Implement the mission operations plan.

Outcomes:

1. Data logs, samples, ... whatever value the mission was designed to add.
2. Operations and maintenance logs.

Reviews:

1. Post-Launch Assesment Review (PLAR)
2. Critical Event Readiness Review (CERR)
3. Post-Flight Assessment Review (PFAR, humans only)

PLAR: A PLAR evaluates the readiness of the spacecraft systems to proceed with full, routine operations after post-launch deployment. The review also evaluates the status of the project plans and the capability to conduct the mission with emphasis on near-term operations and mission-critical events.

CERR: A CERR evaluates the readiness of the project and the flight system to execute the critical event during flight operation (e.g. thruster burn, changing operational phase in CONOPS)

PFAR: The PFAR evaluates how well mission objectives were met during a mission and identifies all flight and ground system anomalies that occurred during the flight and determines the actions necessary to mitigate or resolve the anomalies for future flights of the same spacecraft design.

Phase F: Closeout

Goals:

1. Implement the systems decommissioning/disposal plan developed in Phase E
2. Perform analysis on returned data/samples

Outcomes:

1. System is disposed of or in safe state.
2. Archived data.
3. Final mission report.
4. Lessons learned.

Reviews:

1. Decommissioning Review (DR)

DR: A DR confirms the decision to terminate or decommission the system and assesses the readiness of the system for the safe decommissioning and disposal of system assets.

Summary of products

The table below shows the phases at which various products are expected to be preliminary, baselined, updated, and finalized.

Image("products.png", width=800)