Finally, we must document the results of this iterative process. If we wish to go back and reexamine decisions as new data becomes available, we must clearly understand and convey to others the reasons for each decision. We need this documentation for decisions based on detailed technical analyses, and, equally important, for those based on simplicity, ease of assessment, or political considerations.

This book presents many examples from real space missions. To illustrate the mission analysis and design process without being tied to existing space systems, we invented the hypothetical FireSal space mission. Figure 1-1 shows the broad mission statement we used to begin the process of space mission design for FireSat We wish to stress that the parameters developed throughout the book are by no means the only possible set for FireSat, nor necessarily the best. To show how solutions may vary, Chap. 22 presents a very low-cost spacecraft as an alternative for FireSat. Our example system simply illustrates the iterative process of space mission analysis and design. Different assumptions, requirements, or proposed solutions may lead to dramatically different results.

FireSat Mission Statement

Because forest fires have an Increasing Impact on recreation and commerce and ever higher public visibility, the United States needs a more effective system to Identify and monitor them. In addition, It would be desirable (but not required) to monitor forest fires for other nations; collect statistical data on Are outbreaks, spread, speed, and duration; and provide other forest management data.

Ultimately, the Forest Service's fire-monitoring office and rangers In the field will use the data. Data flow and formats must meet the needs of both groups without specialized training and must allow them to respond promptly to changing conditions.

Fig. 1-1. Origin of the Hypothetical FireSat Mission. FireSat Is used as the primary example throughout this book.

To illustrate the broad process of Table 1-1, we will go through each of the top-level steps for the FireSat mission and indicate the type of information that needs to be developed:

In Step 1, we define what the mission needs to achieve. What are our qualitative goals, and why? This information should come largely from the mission statement of Fig. 1-1. We need to return to this broad goal over and over to ask whether we are doing what we set out to do.

Step 2 is significantly different It quantifies how well we wish to achieve the broad objectives, given our needs, applicable technology, and cost constraints. These quantitative requirements should be subject to trade as we go along. A major error in many space-system procurements is to set requirements in concrete at a relatively early stage. An example for FireSat might be a 100 m positioning accuracy for initial fire detection. A 100 m requirement seems to be a reasonable place to start, but compared to an accuracy of 200 m, it could add tens or even hundreds of millions of dollars to the overall system cost We might spend this extra money better in acquiring fire detection airplanes, providing more personnel on the ground, or using better fire-fighting technology. Congress, the Department of the Interior, and the Forest Service must ultimately decide how well FireSat should do and at what cost. Space mission analysis and design provides the quantitative data needed to support such decisions.

Our next step is to define and characterize a space mission to meet the objectives. Step 3 begins this process by developing alternative mission concepts. A mission concept or concept of operations is a broad statement of how the mission will work in practice. It includes issues such as how the data will be sensed and delivered to the end user, how the mission will be controlled, and the overall mission timeline. Alternative mission concepts include, for example, conceptually distinct approaches to the problem such as the very low-cost approach defined in Chap. 22. These would also include different orbits or different wavelength bands for fire detection that would require dramatically dissimilar systems.

Step 4 defines alternate combinations of mission elements or the space mission architecture to meet the requirements of the mission concept The space mission architecture is the mission concept plus a definition of each of the elements of the mission shown in Fig. 1-3 (Sec. 1.2). A good way to begin Step 4 is to look at the mission elements in Fig. 1-3 and consider what alternatives for each of them would best meet mission objectives.

In any real system, many things influence overall cost, performance, or the design of detailed components. However, these are influenced mainly by a relatively small number of key parameters or components, called drivers. Thus, there may be cost, performance, or system drivers which affect the design of the overall space system. In Step 5 we identify the principal cost and performance drivers for each alternative mission concept For most space missions, system drivers include the number of satellites, altitude, power, and instrument size and weight (Sec. 2.3 gives a more detailed list) By explicitly identifying the system drivers, we can concentrate our effort on parameters having the most impact on the design and therefore on the cost of the space mission. This method improves our chances of getting the best possible design within the available budget

Step 6 is typically the most involved in mission design because it defines in detail what the system is and does. Here we determine the power, weight and pointing budgets* and decide what to process on the ground or in space. Characterizing the mission is the most costly step because it requires the expertise of many people. Developing detail is always comforting in managing any design process but as noted earlier, we must take care not to overdo details while characterizing the mission. System-level requirements and trades must remain our primary focus.

The next step in mission analysis and design is to evaluate the systems we have defined. Having defined and characterized alternative mission concepts, we return in Step 7 to our initial quantitative requirements and identify the critical requirements,t that is, the key requirements principally responsible for determining die cost and complexity of the system. Recall that the system drivers are those defining parameters, such as altitude or payload aperture, which most strongly affect the cost performance, and system design. System drivers are not normally system requirements. However, a critical requirement for coverage or resolution may result in altitude and aperture becoming performance or system drivers. The implication of this for mission analysis and design is that we must put substantial effort into understanding the quantitative relationship between, for example, altitude, aperture, coverage, and resolution, in order to set intelligently both the requirements (coverage and resolution) and system parameters (altitude and aperture). For FireSat, the critical requirements might be fire location accuracy, resolution, coverage, or timeliness of the data. We should concentrate on these requirements to determine how firm they are, how good we should make them, and how much we will pay for them to achieve our broad objectives. Critical requirements may differ for alternative mission concepts.

* A budget is a numerical list of the components of any overall system parameter. Thus, the total spacecraft weight budget would consist of the weights assigned to the payload instruments, the various subsystems, the propellant required, and typically some margin for growth.

t In the first and second editions of this book, critical requirements were called driving requirements. We changed the terminology to avoid confusion with the system drivers of Step 5.

The above questions form the basis of mission utility analysis, Step 8, in which we quantify how well we are meeting both the requirements and the broad objectives as a function of either cost or key system-design choices. We would like to provide the decision maker a single chart of potential performance vs. cost More typically, we must settle for something less ideal, such as the percent of fires detected within 2 hours vs. the aperture of the instrument, or the delay time in detecting forest fires vs. altitude and the number of satellites in the constellation. Only the user or developer of the system can ultimately determine the goodness of these critical performance measures, called Measures of Effectiveness or Figures cfMerit. Consequently, mission definition must be to some degree a joint process between those who understand the mission analysis and design process and those who eventually must use the system or justify its cost

Having evaluated alternative designs and done a preliminary assessment of mission utility, we select one or more baseline system designs in Step 9. A baseline design is a single consistent definition of the system which meets most or all of the mission objectives. A consistent system definition is a single set of values for all of the system parameters which fit with each other—e.g., resolution and coverage rates which correspond to the assigned altitude, aperture, and resulting spacecraft weight In actually designing a space system, many parameters are being defined and changed simultaneously. The baseline provides a temporary milestone against which to measure progress. It also allows us to limit the number of options which must be evaluated. Rather than looking at all possible combinations of altitude, aperture, power, and spectral band (a nearly impossible task), it is much more feasible to look at the impact of varying each of these individually relative to one or two baseline designs. As the system design matures, the baseline becomes more firm, and eventually becomes the system design. However, we should always remember that the baseline is only a starting point for the iterative trade process and should not be regarded as an ironclad definition of mission parameters.

Because builders of a space system work from specific requirements, we must translate the broad objectives and constraints of the mission into well-defined system requirements in Step 10. In Step 11, we flow down or allocate these numerical requirements to the components of the overall space mission in the same way that a budget allocates weight and power to the spacecraft's components. The final list of detailed requirements reflects how well we have done the job of space mission analysis, design, and allocation.

1.1.1 Changes in Future Space Missions

The way we analyze and design space missions is itself continually evolving. In particular, we expect major changes in this process because of increasing technological maturity, increasing use of onboard processing, and continuing emphasis on low-cost missions.

Technological limits on space exploration are giving way to those of policies, politics, and economics. Nearly any mission is technically feasible. It is well within our technical capacity to build a lunar base, mount manned explorations to Mars or other planets, create an industrial base in space, or build networks of satellites to provide truly global communications and observations. Our activity in space depends on what we can afford to do or what we choose to do. Therefore, we must carefully analyze why we choose to use or explore space. We must select each space mission, not just to achieve something that could not have been done before, but to achieve something that should be done or is worth doing.

A major technological change in future space missions will be increased use of onboard computers. Space system developers have been very slow to use computers because of the conservative approach to spacecraft design, long lead times in spacecraft production, and very real difficulties associated with running a computer reliably in space.* The shift to increased onboard processing is moving spacecraft toward more autonomy and increased complexity in terms of the tasks they undertake. Whether this change chives space costs up or down depends upon the government and industry's approach to autonomy and software development for space. Spacecraft may follow the example of ground systems, carrying either low-cost commercial systems or vastly more expensive but more capable special purpose systems.

We anticipate continuing emphasis on low-cost spacecraft Small spacecraft will increase for future space missions. These could be either individual, single-purpose, small satellites or large constellations of small satellites used for communications, space-based radar, or tactical applications. Again, the community appears to be dividing into those who can build small, low-cost spacecraft and those who continue to build large, expensive systems. Creating LightSats represents a new ethic and a new way of doing business in space. If the space business is to grow and prosper as commercial aviation has, we must find a way to reduce the costs of using space. Lowering cost is the real challenge for space mission analysis and design, as well as the government and industrial groups which have created and used this process.

Finally, the mission concept and associated space mission architecture largely determine the cost, complexity, and efficiency of the overall system, This is compounded greatly when you begin to consider integrating the operational aspects of many different missions. For example, today within DoD, we have communication, navigation, signal intelligence, reconnaissance, and weather systems; each with their own mission concept and architecture. The upcoming challenge is to find ways for these systems to operate together to meet user needs.

The fundamental question is "Who are the customers, and what products or services do they require?" In trying to answer this we find ourselves dealing with information-related issues: What information is required, where, and in what form? Most customers don't care about the existence of communications, navigation, or weather satellites. They need specific information and are not interested in what systems provide it Today's challenge is to blend the capabilities and information available from multiple systems to meet customer needs. Military people often express this as tasking, processing, interpretation, and dissemination, whereas commercial people often express the same issues as customer requests processing, formatting, and delivery.

Figure 1-3 is divided along somewhat arbitrary, functional boundaries. We need to find ways to dissolve these artificial boundaries and create cost-effective solutions to our customer's information needs. For example, instead of trying to integrate the separate systems discussed above, we might consider having mulAmission payloads and spacecraft that have the ability to gather intelligence information, weather, and provide navigation using one payload—multimission payloads.

An alternative to creating multimission payloads is to divide the architecture differently by placing all sensors on one space asset, processing capability on another

* Space computers are far more susceptible than ground computers to single-event upsets caused by the high-radiation environment or randomly occurring cosmic rays. To protect against this damage, we must design computers specifically for use in space, as described in Chap. 16.

and using existing or proposed communications links to move the information around. A third alternative might be to use a series of low-cost LightSats each doing a separate function, but in such a way that the end results can be easily and directly integrated by the user's equipment on the ground.

These examples provide a slightly different perspective which is difficult for many organizations, both industrial and government, to adopt because we think and organize functionally—launch, spacecraft, operations, and so on. Being able to functionally decompose our missions and divide them into workable pieces has been one of the reasons, for our success. On the other hand, if we think only functionally it may cause significant problems. We must also think horizontally and create systems that can be integrated with other space and ground systems to create capabilities that are greater than the sum of their parts. As always, our goal is to meet the total user needs at minimum cost and ride.

Was this article helpful?

0 0

Post a comment