Part 4: Complex Programs

< Space Transport and Engineering Methods



Introduction

In previous parts of this book we have discussed individual systems which carry out purposeful functions. In Part 4 we will consider more complex programs, which involve multiple systems. Multiple systems can exist and interact at one point in time. They can also and grow and evolve as a group over an extended time, with new systems replacing older ones.

An optimized program often results in a design with multiple systems. Reasons for this are described below. Large and complex programs can end up with a multi-level structure from the program as a whole, to individually designed systems. We commonly call a set of systems that exist together at one time under one management, and have a set common goal, a Project. When the set of systems has diverse management with shared goals, we can call each part a program Segment. When a program exists for a long time, with significant growth, evolution, and replacement of older systems with newer ones, we can call the program parts Phases. 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 duration of a large program, the principles of Systems Engineering can still be applied to optimize the overall design. When the duration is long relative to changes in technology, society, and the environment, the Systems Engineering tasks may need to done repetitively or continuously to get the most benefit.


Reasons for Multiple Systems

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. Therefore in any large or long duration 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 rocket fuel required goes as an exponential function of velocity. Therefore it often is more efficient to break up the total job into components because the sum of smaller non-linear terms is less than a larger value with an applied exponent.
  • Complex Needs - Humans have complex needs, and projects we wish to accomplish typically have multiple goals. This drives design solutions which use multiple materials, devices, fuels, etc. Therefore no single technical solution is likely to best satisfy all the needs.
  • 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 developments come along, or retrofit an improvement to just the part that needs it. Finally, with an incremental project, you can also get use out of it sooner, which can produce a higher return in the purely economic sense.

Choosing a single or multiple systems should not be done ahead of time arbitrarily. 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 national 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 and Content of Part 4

A major intent of Part 4 is to use the methods described earlier in the book to teach by example. 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 wikibook does not have to remain static, but rather can develop over time. The completed portions will show how calculations and decisions were made. There are opportunities for individuals or teams to develop 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.

The wikibook as a whole was about a 60% complete first draft as of Sep 2012. Part 4 is still incomplete, but is undergoing major revision as of the start of 2017.


Our Program Example

Our chosen example has the overall goal of upgrading civilization on Earth and expanding to more difficult environments, including all areas of the Solar System and eventually beyond. For now we will call it the Civilization Upgrade Program (CUP) or Upgrade Program for short, although a better program name is desirable. 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 therefore needs its own reason to proceed, whether economic or a more altruistic one. The program description and 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 also 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 methods for many types of systems and subsystems.
  • In the following Design Studies section (Part 5) we can teach by example, showing in some detail how the calculations and decisions are made to arrive at a design.
  • It is intended to be a realistic program proposal, incorporating the best current technology and concepts. If good enough, the proposed elements may actually be built.
  • An open-ended program using new concepts and technologies allows readers to do actual useful new 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 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 plan to use the Systems Engineering methods described in Part 1 in further developing the proposed program.


Part 4 Contents

A large and complex program naturally can't be described in a single page. So the remaining sections in Part 4 provide further information about the Upgrade Program in roughly chronological sequence, according to program phases. Design studies in Part 5, and related information elsewhere, provide more details about design choices and calculations.


  • 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 may learn from and improve upon them.
This article is issued from Wikibooks. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.