NASA’s Big Programs

Suggested Reading

A spacecraft mission design course will prepare you for the “formulation phase” of a NASA project life cycle. The whole project life cycle gives a more informed understanding of the subsequent implementation phases that might affect the technical design outside of technical specifications, such as ease to integrate or operate. A good systems engineer considers the entire life cycle in the seemingly short window of design formulation. The figure below is comprehensive for a large spaceflight mission, but a small satellite mission may reduce the number of reviews to adjust for an abbreviated program cycle with a quicker turnaround time. The formulation phase includes Phase A: Concept and Technology Development and Phase B: Preliminary Design and Technology Completion.

From the previous EPET 301: Space Science Instrumentation course, you should be familiar with potential science missions that drive a space mission. The preliminary analysis includes defining the payload, proof of concept analyses, and “build or buy” decisions [Akin]. Pre-Phase A concept studies include a “broad spectrum of ideas and alternatives for missions [for which activities include] determining the feasibility of the desired system, developing mission concepts, drafting system-level requirements, assessing performance, cost, and schedule feasibility, and identifying potential technology needs and scope”. This phase may include a peer review, called the Mission Concept Review. Assuming the concept studies resulted in a clear set of questions, methods, and solutions within a feasible schedule and budget, we may begin Phase A: Concept and Technology Development.

Phase A should produce a fully developed baseline mission concept that responds to the program expectations, requirements, and constraints. In this planning phase, we should ensure that the “project justification and practicality are sufficient to warrant a place in NASA’s [or your targeted funding agency’s] budget”. To do so, refer to NASA’s decadal surveys, strategic plans and roadmaps, and the taxonomy report. Detailed products from this phase include a final mission concept, system-level requirements, needed system technology developments, and program/project technical management plans. Typical activities include developing baseline top-level requirements and constraints including internal and external interfaces, developing engineering units for high-risk concepts, allocating system requirements to functions and to the next lower level, validating requirements, and identifying risks. The design is peer-reviewed in separated or combined a system requirements review (SRR) and a mission design review (MDR) for compliance, which results in returning to refine the baseline concept or moving onto Phase B.

Phase B aims to “complete the technology development, engineering prototyping, heritage hardware and software assessments, and other risk-mitigation activities”. Detailed products include a system structure and preliminary designs for each system structure end product. Typical activities include identifying one or more feasible preliminary designs including internal and external interfaces, selecting a preliminary design solution, developing an operation plan on matured ConOps, improving fidelity or models and prototypes used in evaluations, and developing preliminary plans (Orbital Debris, Decommissioning, Disposal). The design is peer-reviewed in the preliminary design review (PDR), which results in a return to the preliminary design process or progression to Phase C.

Project Phase C establishes a final design for fabrication and software development. These efforts refine the preliminary design to an explicit definition of all the components with compatible internal and external interfaces. Typical activities include fully maturing preliminary designs, fully documenting the final design and developing data package, defining interfaces, developing baseline plans for later phases, and fabricating the product. The design is peer-reviewed in stages at the critical design review (CDR) and system integration review (SIR), which results in refining the design, procedures, and plans or progression to Phase D, the final phase before launch.

Cube Satellites

Cube satellite projects are smaller than typical NASA projects, require fewer team members, and follow compressed timelines. From 2011, the NASA CubeSat Launch Initiative “provides opportunities for small satellite payloads built by universities, high schools, and non-profit organizations to fly on upcoming launches” and wrote a stellar CubeSat 101 Handbook.

The CubeSat project timeline “can vary depending on the launch vehicle selected and what you are trying to accomplish with your CubeSat” but generally follows:

1. Concept Development (1–6 months)
2. Securing Funding (1–12 months)
3. Merit and Feasibility Reviews (1–2 months)
4. CubeSat Design (1–6 months)
5. Development and Submittal of Proposal in Response to CSLI Call (3–4 months)
6. Selection and Manifesting (1–36 months)
7. Mission Coordination (9–18 months) – Once this phase begins, a schedule will be provided by the integrator that will dictate hardware and documentation delivery dates, essentially providing the completion dates for the subsequent phases.
8. Licensing (4–6 months)
9. Flight-Specific Documentation Development and Submittal (10–12 months)
10. Ground Station Design, Development, and Testing (2–12 months)
11. CubeSat Hardware Fabrication and Testing (2–12 months)
12. Mission Readiness Reviews (half-day)
13. CubeSat to Dispenser Integration and Testing (1 day)
14. Dispenser to Launch Vehicle Integration (1 day)
15. Launch (1 day)
16. Mission Operations (variable, up to 20 years)\

The main difference between a large NASA mission and a CubeSat mission is the proposal selection for full development occurs after the spacecraft is significantly designed on paper. The NASA programs assume that a launch is secured prior to significant design work and only upon catastrophic program failure along the way, a launch is lost. Cube satellite programs, as a result, are commonly bootstrapped by self-motivated engineers and don’t always make it to launch. Some cube satellite programs are lucky enough to be funded upfront and developed in-house by NASA or have venture capital funding raised, like PlanetLabs. As of May 31st, 2018, 855 CubeSats had been launched [Villela et al.]. CSLI has launched 66 CubeSats and selected 162 CubeSats for free launches, a significant portion of all CubeSat launches [Crusan & Galicia].

The Scope of This Design Course

Most spacecraft design courses expect students to design a spacecraft from the NASA Pre-Phase A to Phase B, ending their design at a preliminary design review phase. From the CSLI phase list, the scope of most courses is to cover Steps 1 to 4. We hope to push further into aspects of NASA Phase C or CSLI Step 10 by offering hardware and software that demonstrate spacecraft functionality in verification and validation through lab modules.

The general process of designing a spacecraft from Pre-Phase A to Phase B is listed in steps [the New SMAD]:

    1. Defining Mission Objectives

In this class, we will assume that your team has come up with mission objectives. This should be the case if you took EPET 301: Space Science Instrumentation. If you haven’t come up with a mission yet, do take time to explicitly define your goals before moving on. The goal can be as simple as recreating the simplest satellite possible: Sputnik, a spacecraft that beeps in space. If you have access to space scientists, collaborate with them on a more compelling mission! In the CSLI timeline, this is the beginning of the concept development phase

2. Involving Principal Players

We will assume your principal players are with you; they are your fellow classmates (engineering and science), your faculty mentor, and interested volunteers. Be sure you define roles in your team to be explicit about responsibilities. We’ll review the role of a systems engineer and program manager in the following section.

3. Evaluating Program Timescales

From the CSLI phase timeline, the concept development and CubeSat design usually take 1-6 months for each phase but are not strictly defined, unlike the larger NASA programs. For this class at UH Manoa, we will constrain CubeSat concept development and design phases to one semester but for those at home, feel free to take your time! You won’t have to adhere to a strict timeline until after you secure a launch.

4. Estimating Preliminary Mission Needs, Requirements, and Constraints

This part of the concept development and CubeSat design is covered in the requirements and design reference mission product sections.

5. Choosing Pieces of the Mission Architecture

A section of this chapter discusses the flow down of requirements to other subsystems. The other chapters in the textbook will delve into each subsystem’s roles, designing to requirements, and choosing satisfactory components. These chapters will be particularly useful to subsystem specialists and leads.

6. Resolving Interfaces of Pieces in the Mission Architecture

The project management tools section of this chapter discusses interface control documents and system block diagrams, which assist systems engineers in ensuring a cohesive system between the subsystems. Each subsystem chapter will discuss interconnectivity between and impacts on the other subsystems.

7. Defining System Drivers and Critical Requirements

This part of the concept development and CubeSat design is specifically covered in the requirements verification matrix and managing risks section. Each subsystem chapter will expand upon specific subsystem drivers and critical requirements.

8. System Trade Studies and Performance Assessments

This part of the concept development and CubeSat design is covered in the decision analysis tools. Each subsystem chapter will expand upon specific trade studies and the rigorous analyses necessary to assess performance.

9. Evaluating Mission Utility and Figures of Merit

Outside the scope of this course, internal and external reviewers will evaluate how well the design met the mission (requirements verification matrix) and how compelling your mission is (design reviews and CSLI proposal selection). We will assist with the mission design but selling your project to CSLI is outside the scope of this course. To apply to CSLI, make sure to find a mission that contributes to NASA’s strategic plan, adhere to CSLI proposal guidelines and deadlines.

10. Defining the Baseline Mission Concepts, Revising Requirements, and Evaluating Alternatives

This final step is essentially a regathering of the design and reflection of which parts of the system design need iteration. Requirements may be revisited. Alternative components may be selected. The design process is iterative so commonly, the team will return to step 4 to reassess requirements, component selection, and reevaluate the design.