Space Mission Analysis and Design / Edition 3

by J.R. Wertz, Wiley J. Larson

Overview

This famous and practical handbook for Space Mission Engineering draws on leading aerospace experts to carry readers through mission design, from orbit selection to ground ops. SMAD III updates the technology, provides greater emphasis on small spacecraft design and the cost-reduction process, and includes more detail on multi-satellite manufacturing, space computers, payload design and autonomous systems.

Product Details

ISBN-13:	9780792359012
Publisher:	Springer Netherlands
Publication date:	09/30/1999
Series:	Space Technology Library , #8
Edition description:	3rd ed. 1999
Pages:	976
Product dimensions:	6.10(w) x 9.25(h) x 0.08(d)

Read an Excerpt

Chapter 2: Mission Characterization

Another problem which can arise from time to time is incompatible functions, that is, activities which do not work well together. One example would be sporadic, computationally-intensive functions which demand resources at the same time. Another example occurs when the initial processing of either spacecraft bus or payload sensors may well be an interrupt-driven activity in which the computer is spending most of its time servicing interrupts to bring in observational data. This could make it difficult for the same computer to handle computationally-intensive processing associated with higher-level activities. This can be accommodated either by having the functions handled in separate computers or using a separate 1/O processor to queue data from the process with a large number of interrupts.

Finally, we must consider the groups who oversee different activities. Integration and test of any computer and its associated software will be much more difficult if two distinct groups develop software for the same computer. In this case, significant delays and risks can occur. This does not necessarily mean, however, that elements controlled by different groups cannot be accommodated in the same computer. One approach might be to have two engineering groups be responsible for development of specifications and ultimately for testing. The detailed specifications are then handed over to a single programming group which then implements them in a single computer. This allows a single group to be responsible for control of computer resources. Thus, for example, the orbit control and attitude control functions may be specified and tested by differentanalysis groups. However, it may be reasonable to implement both functions in a single computer by a single group of programmers.

2.1.2 Tasking, Scheduling, and Control

Tasking, scheduling, and control is the other end of the data-delivery problem. If the purpose of our mission is to provide data or information, how do we decide what information to supply, whom to send it to, and which resources to obtain it from? Many of the issues are the same as in data delivery but with several key differences. Usually, tasking and control involve very low data rates and substantial decision making. Thus, we should emphasize how planning and control decisions are made rather than data management.

Tasking and scheduling typically occur in two distinct time frames. Short-term tasking addresses what the spacecraft should be doing at this moment. Should FireSat be recharging its batteries, sending data to a ground station, turning to look at a fire over Yosemite, or simply looking at the world below? In contrast, long-term planning establishes general tasks the system should do. For example, in some way the FireSat system must decide to concentrate its resources on northwestern Pacific forests for several weeks and then begin looking systematically at forests in Brazil. During concept exploration, we don't need to know precisely how these decisions are made. We simply wish to identify them and know broadly how they will take place.

On the data distribution side, direct downlink of data works well. We can process data on board, send it simultaneously to various users on the ground, and provide a low-cost, effective system. On the other hand, direct-distributed control raises serious problems of tasking, resource allocation, and responsibility. The military community particularly wants distributed control so a battlefield commander can control resources to meet mission objectives. For FireSat, this would translate into the local rangers deciding how much resource to apply to fires in a particular area, including the surveillance resources from FireSat. The two problems here are the limited availability of resources in space and broad geographic coverage. For example, FireSat may have limited power or data rates. In either case, if one regional office controls the system for a time, they may use most or all of that resource. Thus, other users would have nothing left. Also, FireSat could be in a position to see fires in Yosemite Park and Alaska at the same time. So distributed control could create conflicts.

For most space systems, some level of centralized control is probably necessary to determine how to allocate space resources among various tasks. Within this broad resource allocation, however, we may have room for distributed decisions on what data to collect and make available, as well as how to process it. For example, the remote fire station may be interested in information from a particular spectral band which could provide clues on the characteristics of a particular fire. If this is an appropriate option, the system must determine how to feed that request back to the satellite. We could use a direct command, or, more likely, send a request for specific data to mission operations which carries out the request.

Spacecraft Autonomy. Usually, high levels of autonomy and independent operations occur in the cheapest and most expensive systems. The less costly systems have minimal tasking and control simply because they cannot afford the operations cost for deciding what needs to be done. Most often, they continuously carry on one of a few activities, such as recovering and relaying radio messages or continuously transmitting an image of what is directly under the spacecraft. What is done is determined automatically on board to save money. In contrast, the most expensive systems have autonomy for technical reasons, such as the need for a very rapid response (missile detection systems), or a problem of very long command delays (interplanetary missions). Typically, autonomy of this type is extremely expensive because the system must make complex, reliable decisions and respond to change.

Autonomy can also be a critical issue for long missions and for constellations, in which cost and reliability are key considerations. For example, long-duration orbit maneuvers may use electric propulsion which is highly efficient, but slow. (See Chap. 17 for details.) Thruster firings are ordinarily controlled and monitored from the ground, but electric propulsion maneuvers may take several months. Because monitoring and controlling long thruster burns would cost too much, electric propulsion requires some autonomy.

As shown in Fig. 2-3, autonomy can add to mission reliability simply by reducing the complexity of mission operations. We may need to automate large constellations for higher reliability and lower mission-operations costs. Maintaining the relative positions between the satellites in a constellation is routine but requires many computations. Thus, onboard automation-with monitoring and operator override if necessary-will give us the best results.

With the increased level of onboard processing available, it is clearly possible to create fully autonomous satellites. The question is, should we do so or should we continue to control satellites predominantly from the ground?

Three main functions are associated with spacecraft control: controlling the payload, controlling the attitude of the spacecraft and its appendages, and controlling the spacecraft orbit. Most space payloads and bus systems do not require real-time control except for changing mode or handling anomalies. Thus, the FireSat payload will probably fly rather autonomously until a command changes a mode or an anomaly forces the payload to make a change or raise a warning. Autonomous, or at least semiautonomous payloads are reasonable for many satellites. There are, of course, exceptions such as Space Telescope, which is an ongoing series of experiments being run by different principal investigators from around the world...

Table of Contents

List of Authors. preface. 1. The Space Mission Analysis and Design Process. 2. Mission Characterization. 3. Mission Evaluation. 4. Requirements Definition. 5. Space Mission Geometry. 6. Introduction to Astrodynamics. 7. Orbit and Constellation Design. 8. The Space Environment and Survivability. 9. Space Payload Design and Sizing. 10. Spacecraft Design and Sizing. 11. Spacecraft Subsystems. 12. Space Manufacture and Test. 13. Communications Architecture. 14. Mission Operations. 15. Ground System Design and Sizing. 16. Spacecraft Computer Systems. 17. Space Propulsion Systems. 18. Launch Systems. 19. Space Manufacturing and Reliability. 20. Cost Modeling. 21. Limits on Mission Design. 22. Design of Low-Cost Spacecraft. 23. Applying the Space Mission Analysis and Design. Appendices: A: Mass Distribution for Selected Satellites. B: Astronautical and Astrophysical Data. C: Elliptical Orbit Equations. D: Spherical Geometry Formulas. E: Universal Time and Julian Dates. F: Units and Conversion Factors. Index.

Editorial Reviews

But as a reference volume for system engineers and satellite designers it would appear to be an invaluable collection of data.
The Aeronautical Journal

From the Publisher