This is the third in a series of articles on how to go about dramatically reducing space mission cost while maintaining a high level of mission utility. This article discusses system engineering approaches to reducing space mission cost and schedule. (The related topic of mission design will be covered in a later article.)
Trading on Requirements
In the traditional requirements-driven process, we start by defining the broad requirements that a system must meet and then allocate or flow down these requirements to the various subsystems. The organization that is building the system attempts to meet these requirements with some margin and then stops, so as to minimize the cost of the system.
In general, the mission objectives are fuzzy — explore Mars or save lives after a natural or man-made disaster. However, the requirements are precise numerical values that the contractor must ultimately be able to prove that the system will meet. If the requirements are set too low, we may not achieve as good a performance as the system is capable of, and if the requirements are set too high, it may become dramatically expensive or even impossible.
Then there is the almost inevitable problem of “requirements creep,” with the inevitable result of driving up cost and schedule. If the system becomes too expensive, there is the possibility that it will be canceled and then the capability will not exist at all. This is almost certainly not in the best interests of the end user. Air Force Gen. Kevin Chilton, former commander of U.S. Strategic Command, has often discussed the difficulties that these problems create for military procurement.
As with many areas of reducing cost, the key is to try to find a reasonable balance between what can be done economically and what we would like to achieve. Let’s assume, for example, that for a ship tracking system, the goal is to achieve a geopositioning accuracy of 500 meters and that the accuracy depends primarily on the spacecraft’s attitude determination system. Further, let’s assume that Attitude System A has a cost of $400,000 and allows an overall geopositioning accuracy of 600 meters and Attitude System B has a cost $3 million but can achieve an accuracy of 400 meters. In the traditional approach, we would have no choice other than to use the more expensive option, but that may or may not be the sensible answer. If it’s a $2 billion spacecraft, an added $3 million won’t matter. If it’s a $5 million spacecraft, the $3 million matters a great deal and could cause the project to be canceled.
One solution to this problem is trading on requirements, in which we go back and determine the impact of specific choices on both cost and mission utility, discuss the options with the end users or the procuring organization or both, and then try to find an intelligent balance. It may be that 600-meter accuracy isn’t quite what we wanted, but it is better than not having ship tracking at all.
A second solution might be a multitiered requirement in which the system achieves 500-meter accuracy when it flies almost directly over the ship and achieves 800 meters when it is looking more toward the horizon. Thus, we might set up a requirement in the form of 500-meter accuracy on at least 10 percent of coverage passes and 800 meters on the rest of the passes. This strategy also prevents us from throwing away data that aren’t quite what we wanted but are available much more frequently.
The multitiered requirement suggests another alternative: a capabilities-driven system in which we look at the mission utility of a system built with existing equipment and technology, potentially at dramatically lower cost. Instead of meeting a specific set of requirements, we design the system to provide as much capability as possible within tight (but not necessarily minimum) budget constraints. This is equivalent to buying a car that meets as many of our needs as possible, rather than going out and having a car designed and built to our specifications. We may find that the former can do more than we expected. In both the car and the spacecraft, advanced computer and software technology may allow the system to do more in some areas than we had expected and to provide some elements of unexpectedly high utility.
Setting Functional Requirements and Giving Reasons for Them
Related to the process of trading on requirements is the need to set functional rather than technical requirements and to document the reason for requirements. Setting functional requirements means specifying what we want to achieve but not how to achieve it. Thus, we might set a requirement on geopositioning accuracy but leave the choice of specific spacecraft attitude and position requirements to the contractor. We also want to specify why this requirement is what it is so that other engineers can go back and ask if those same conditions still apply. If the original conditions don’t apply, we may be able to lessen the requirement without changing the level of utility that the system achieves.
Fly a New Computer Plus the One You Flew Last Time
This is an excellent technique for ensuring that you’re using the most modern technology. Computers today are both light and cheap (relative to spacecraft costs). Flying a new one ensures that you are using nearly the latest and most capable computer technology, while flying the one you used last time ensures that you have a working computer and provides a backup in case of any computer failure. Of course, this can also be applied to other components as well.
Avoid Optimization
Demanding “optimal solutions” prevents standardization, hinders the use of nonspace equipment and requires that everything be uniquely designed for each specific application. An enormous amount of money and resources is often spent on achieving the last 5 percent of performance. Yet it is almost certain that that last few percent will have essentially no impact on the overall mission utility.
Use the Existing Knowledge Base
There is a tendency within large space organizations to want to invent from scratch every new technique that is to be used. But reinventing the wheel is rarely economical, or, as NASA Nobel laureate John Mather has expressed it, “Six months in the laboratory can save you a week in the library.” Some of the most important approaches to building on existing knowledge are:
- Researching books and professional papers on reducing cost.
- Attending courses and conferences, particularly the Reinventing Space Conference in Los Angeles and the Small Satellite Conference in Logan, Utah. We want to reduce the cost on satellites of all sizes, but much of the knowledge base comes from small satellites.
- Using commercial software tools (much better than inventing your own).
- Becoming a part of the low-cost community (for example, by attending the above conferences and talking to everyone you can find).
- Taking advantage of the knowledge and experience of others. A great deal of material on the existing knowledge base is available at the Reinventing Space Project link below, including an annotated bibliography on reducing mission cost. You will certainly tailor the approaches of others to meet the needs of your organization or project, but it makes sense to understand what others have proposed or done and what has worked and not worked in practice.
In the fourth installment in this series, we will look at programmatic approaches to reducing cost.
James R. Wertz is president of Microcosm Inc. He is co-author of “Reducing Space Mission Cost,” published in 1996, and has taught a graduate course at the University of Southern California on that topic since then. If you have questions, comments or suggestions, or simply want to discuss these issues, he can be reached at jwertz@smad.com. Information on the joint Microcosm/USC Reinventing Space Project can be found at www.smad.com/reinventingspace.html.
RELATED ARTICLES
Reinventing Space: Dramatically Reducing Space Mission Cost — Attitude
