Wikibooks

Part 4: Projects and Programs

< Space Transport and Engineering Methods



In previous parts of this book we have discussed individual systems which carry out purposeful functions. In Part 4 we will consider more complex projects and programs, which involve multiple systems. Multiple systems can exist and interact with each other at one time. They can also grow and evolve as a group over an extended time, with new systems replacing older ones. When multiple systems are directed at one or more common goals, we refer to them as a Program, such as the civil space program of the US.

 An optimized program often results in a design with multiple systems. Reasons for this are described below. For design and management purposes, a large and complex program can be organized into a multi-level structure from the program as a whole, to individually designed systems. We then need ways to describe the parts of the program. Some common descriptions include:

  • Project - A set of systems that exist together at one time under one management, and have a set common goal.
  • Segment - A set of systems within a program with diverse management and shared goals.
  • Phase - Part of a program which exists for an extended time, with significant growth, evolution, and replacement of older systems with newer ones.

 Projects, segments, phases, and other pieces are then assembled to form the larger program. The names and structure are somewhat arbitrary, and are selected according to the needs of a particular program. It is important that the selected structure cover all the work needed for the program, and that all the people working on it have a shared understanding of how the structure and its parts fit together. Despite the complexity or length of a large program, the principles of Systems Engineering can still be applied to optimize the overall design. When the program's life cycle is long relative to changes in technology, society, and the environment, the Systems Engineering tasks may be repeated, or performed continuously to get the most benefit.


Reasons for Multiple Systems

edit

In general, the more complex, or more extended in location, volume, traffic, or time a project is, the more likely it will result in multiple systems. Different environments and available resources will drive different local solutions. Changes in technology and economics over time will also guide changes in design. In any large or long-lived program, a multiple system approach should at least be considered to see if it gives a better result. Some specific reasons include:

  • Non-Linearity - A given transportation or engineering method often has a non-linear term in it's equations - at least quadratic if not an exponential. For example drag goes as the square of velocity, and the rocket equation increases mass ratio and propellant as an exponential function of velocity. It is often is more efficient to break up the total job into components because the sum of smaller non-linear terms is less than a single larger term with an applied exponent.
  • Complex Needs - People have complex needs, and projects we wish to accomplish typically have multiple goals. This drives design solutions which use multiple materials, devices, energy sources, etc. Therefore no single system or technical solution is likely to best satisfy all the desired ends.
  • Economics - A single large "all or nothing" type monolithic system, which requires a large up-front investment, often turns out to be wasteful. Aside from the non-linear effects noted above, we cannot predict future technology developments, and large projects often have long development times. If you build in smaller steps, you have the opportunity to change direction if new improvements come along, or retrofit a change to just the part that needs it. Finally, with an incremental project, you can get some use from it earlier. This can produce a higher economic rate of return.

 The choice between single or multiple systems should not be done arbitrarily ahead of time. The decision should, if possible, be made by analysis of the alternatives and choosing the best one. Sometimes the right choice may not be possible for non-engineering reasons. For example, the civilian space program in the US is operated as a whole by NASA, and funded by congressional appropriation. A single agency funded from a single source can make it more difficult to divide or set up separate systems, even if it makes sense from an engineering standpoint. The organizational structure, budget review process, and national politics tend to favor single and conservative solutions. Conversely, the historical division of US government-funded space activities between NASA, and the Defense, Commerce, and Energy departments can make it more difficult to combine projects and programs, even if they would be more economical.


Organization of Part 4

edit

A major purpose of Part 4 is to show how the various engineering processes and technologies from earlier parts of the book can be put to use. We therefore present an extended example of a long-term and complex program that involves multiple terrestrial and space systems. Unlike printed paper books, the example in this book does not have to remain static, but rather can be developed over time. The completed portions will show by example how calculations and decisions are made. There are also opportunities for individuals or teams to develop the ideas further, and practice their design skills. Their work can be recorded as design studies in Part 5, or as separate documents to be linked. The best ideas can be incorporated back into the main discussion of the book. It is hoped this approach is a useful teaching method, a way for readers to gain real design experience, and a way to make real progress in in future programs.


Status - The book as a whole is about a 65% complete first draft as of Sep 2017. Part 4 is still incomplete, but is undergoing major revision as of late 2017.


Our Program Example

edit

Our chosen example has the overall goal of upgrading and expanding civilization on Earth to more difficult environments, then to the more distant and difficult regions of the Solar System, and eventually beyond. We will leave choosing a catchy name for this multi-region effort to others, and just refer to it as "our program". The program's component parts are not intended to be under a single centralized control. This is both to illustrate the interactions between distributed program elements, and because it is impractical to run such a large program as a single entity in the real world. Each part of the program then needs its own reasons to proceed, whether they are economic have other motivations. The program's description and supporting concepts help provide these reasons, and a structure to inform and coordinate independent efforts. The various parts would then interact with each other, and with the outside world. The interacting parts, and the program as a whole, are not static, but evolve over time.

 We chose this example for several reasons:

  • As a long duration and wide ranging program it allows us to demonstrate design considerations and methods for many types of systems and subsystems.
  • In later design studies and separate documents we can teach by example, showing in some detail how the calculations and decisions are made to arrive at a design.
  • This is intended as a realistic program concept, incorporating the best current technology and ideas. If good enough, the proposed elements may actually be adopted and built.
  • An open-ended program using new concepts and technologies allows readers to do useful original work. At the same time they can gain individual design skills and experience, and practice working in diverse teams.

 The program concept is partly based on work by Dani Eder, the original author of the Canonical List from which this Wikibook originated. It also includes many new ideas not yet pursued by government or commercial programs. In its present state it is not complete or claimed to be the best possible program concept. Rather it is intended as a starting point using recent ideas for space development, from which an optimal design can evolve by the contributions of many other people. We intend to use the engineering methods described in Part 1 in further developing the proposed program.


Part 4 Contents

edit

A large and complex program naturally can't be described in a single page, or even a single book. The sections and pages in Part 4 provide an introduction to the program at the concept exploration level, in roughly chronological order, according to program phases. Design studies in Part 5, and related information elsewhere, will provide more details about design choices and calculations. Current sections and pages include:

  • Section 4.2: Phase 0 - Research & Development - identifies new or improved technologies and methods that are needed for the later program phases, and how to develop them. Such items must be developed before they can be used, so Phase 0 logically precedes the other phases. When needed items are identified, they are fed back to Phase 0 for planning and integration with other work.
  • Section 4.3: Phases 1 to 3 for Earth - summarizes improvements and expansion of civilization on Earth by means of Seed Factories. These are systems which bootstrap from a starter set and grow to whatever size is needed using smart tools, local energy and materials, and process and design knowledge. Such systems will later be used in the space parts of the program, but their application to Earth is outside the main topic of this book. Those applications and the seed factory concept in general are discussed in a separate book.
  • Section 4.4: Phase 2B - Industrial Locations for Space - describes the subset of industry on Earth needed to access and support work in space, such as rocket factories and launch pads. Other industries already exist, so the space-related ones on Earth do not have to bootstrap from starter sets. That approach is more useful in space where very little industry currently exists.
  • Section 4.5: Phase 4A - Low Orbit Development - Phase 4 in general covers orbital regions away from the Earth's surface. Phase 4A covers further development of the region between 160 and 2700 km altitude, beyond what is already there and existing projects.
  • The Table of Contents for this book lists several other pages in Part 4: Hypervelocity Launcher, Low-G Transport, Electric Propulsion, Orbital Mining (2 pages), Processing Factory, Spaceport Network, and Interplanetary Transfer. These remain from an earlier draft of the book, and will be merged into the appropriate new sections. Some other sections for additional phases will be added later, and all the sections will be renumbered.
  • Section 4.12: Phase 5A - Lunar Development - Phase 5 in general covers planetary systems and nearby orbits around them. The Moon is important enough in size and location that we place it in a separate phase at the level of the other major planetary systems. The Moon and farther regions are still in the science and exploration stage, and have yet to be developed further.
  • The Later Projects page is currently a place-holder for additional pages which will be added later.


edit
  • Section 5.1: Program Conceptual Design - This is a design study showing how the conceptual design for the Upgrade Program is developed. It is more extensive than a typical technical study final report. Final reports record the results of a study. Here we also show the logic and calculations to reach the results, so that others can learn from and improve upon them.
Retrieved from "https://en.wikibooks.org/w/index.php?title=Space_Transport_and_Engineering_Methods/Complex_Programs&oldid=4413038"