Commentary | Reinventing Space: Dramatically Reducing Space Mission Cost — Programmatic Approaches
This is the fourth 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 programmatic approaches to reducing cost and schedule.
Make cost data known
One of the most obvious and simplest approaches to reducing cost, and also one of the hardest to implement, is to make cost data known. Asking engineers to reduce space mission cost without making the cost known is like saying that we would like you to reduce the cost of manufacturing a car but we’re not going to tell you what it actually costs to build a car or the cost breakdown among the various elements. Nonetheless, it is extremely difficult to get mission cost data made public. Further complicating the situation, elements of the cost are often covered by other budgets, such as the cost of government personnel, testing costs covered by another budget or organization, or cost sharing between organizations. Some elements of cost may be proprietary and, in addition, it is often not in the best interests of the program for the full cost to become widely known and discussed. If the full cost becomes known, it has the potential to increase the level of scrutiny and may increase the risk of program cancelation. Nonetheless, it is very hard to reduce cost when cost data are known, and virtually impossible when they are not.
This refers to the idea of taking a large mission and breaking it down into a number of smaller missions. There is an ongoing debate over whether this will reduce cost. After all, the original intent for aggregating multiple capabilities into a single large spacecraft was to reduce the inherent overhead, reduce the number of launches and therefore reduce system cost. Like many other approaches to cost reduction, disaggregation may or may not reduce cost, depending on how it is implemented. If we maintain all of the same rules and procedures and take a decade or more to build each of the disaggregated smallsats, then cost savings are unlikely. However, there is ample evidence in the community that smallsats can be built in a much shorter time and for dramatically lower cost than larger, traditional spacecraft. (The Microcosm/USC Reinventing Space Project is engaged in a program to quantify the extent of the cost reduction.)
Irrespective of the specific processes and rules, there are a number of inherent economic advantages to replacing a large satellite having, for example, a 15-year life with a set of smaller satellites, presumably having shorter lives:
- Large satellites are typically designed and built over a decade or more, which means that billions of dollars are spent before there is any return on investment. With a series of small satellites the expenditures are spread out over the life the program, which both delays the expenditures (inherently reducing the cost) and allows the build rate to be adjusted to the actual lifetime and needs of individual components.
- The series of smallsats can take advantage of technology advances over the course of time. New technology can both reduce cost and increase performance, just as it does in cell phones, computers and TVs.
- Similarly, a series of smallsats can respond to evolving needs. With traditional, long-lived systems we have no way of knowing in advance what region of the world will be important or what type of information will be needed. Consequently, we try to cover the entire world, all the time, with every possible sensor we might need. It would be much more economical if, at least in part, we could cover regions or events with those sensors that provided the information that was needed when it was needed.
- A launch failure of a large single satellite means that the end user will be without that capability for many years. Small satellites can be built in a much shorter time and since there may be multiple satellites on orbit or nearly ready to launch, a launch failure represents only an incremental reduction in performance and a small increase in overall mission cost. The smallsat constellation is much less “fragile” and more robust than its more traditional monolithic counterpart.
- Even if there are no launch or on-orbit failures, 15 years after the successful launch of a large satellite we have a spacecraft built with 25-year-old technology, meeting 25-year-old mission needs (when global warming wasn’t a real concern and the Soviet Union was the major adversary of the United States), and no one left who knows how to build it. A series of small satellites can support more nearly continuous production and can respond to both advancing technology and changing mission needs.
Microelectronics allows smallsats to do a great deal. Nonetheless, it is important to note that there are some missions that simply can’t be accomplished by small satellites and for which large traditional satellites will still be needed. For example, diffraction limited optics and power-aperture requirements for communications are laws of physics that we cannot avoid. Nonetheless, as we will see in the fifth article, there are ways around some of these issues as well.
Make greater use of smallsats for test and operations
In addition to performing some of the functions of traditional satellites, smallsats allow us to do some things that simply can’t economically be done with traditional large satellites. A constellation of a dozen smallsats can provide observations of an important area on the Earth every 20 minutes, 24 hours a day, at a fraction of the cost of a single large satellite that may make one observation every other day. Smallsats can also often be used for rapid test missions to validate technology that can be used to reduce the cost of larger systems.
Reduce the cost of failure
The space spiral that drives costs continuously higher is driven in large part by the fear of failure. But major breakthroughs in either performance or cost require accepting the possibility of failure, particularly during tests or in early missions. A good example of this is the early development of Soviet launch vehicles that had many initial failures followed by a truly excellent success record. To the extent that we do low-cost testing or fly more missions at much lower cost, we will reduce the inherent risk associated with the possibility of failure. Anything that helps us reduce the cost of failure will also help drive down cost.
Compress the schedule
One of the reasons that the Apollo program was done within budget is that it was done very rapidly. There are less overhead costs, less time to spend money, and less time for the “standing army” to drive up cost. Of course, schedule compression must be done with care. We must also expedite decision-making and reduce the amount of work required so as not to kill the engineers in the process. Another advantage of shorter programs is that they extend over fewer funding cycles and fewer changes of either administration or key personnel. This, in turn, means fewer changes in overall program direction and a more focused project. All of the above help to reduce cost and schedule and also reduce the potential for overruns or program cancellation.
Provide continuous, stable funding
This does not reduce cost per se, but avoids cost and schedule overruns. Stopping and starting a program dramatically drives up cost and increases schedule well beyond the length of the schedule break. When a program is stopped, the people involved go on to another program or may leave the company or the aerospace field altogether. Small companies may go out of business. When the program restarts, many of these people will not be available to come back. (Their new program or company may not be enthusiastic about letting them go and they may have become disenchanted as well.) It takes both time and money to assemble a new team.
While there is almost always an attempt to document the status of the program before it stops, this documentation is essentially never as complete as one would like and key issues, such as the reasons for specific requirements, are often never documented. The new team is left to reinvent the program and will likely need to redo many of the critical trades and design elements. This is both time-consuming and expensive and is likely to lead to somewhat different choices than those that were made previously.
Some program breaks are forced by external circumstances, such as funding being unavailable. However, there are a number of things that can be done to lessen the probability of program breaks. These include:
- Make major decisions away from funding boundaries.
- If possible, provide multiyear funding.
- Keep the program funded while decisions are being made.
The last item is particularly important because it puts pressure on the decision-making community to make decisions promptly.
We should emphasize again that there is no single solution to reducing space mission cost and schedule. It is not simply a matter of disaggregation or using smallsats or compressing the schedule. We need to use both processes and technology that are applicable to the mission, the organization, and the needs of the end user. By looking at all of these, we can find ways to both shorten the schedule and dramatically reduce mission cost.
The fifth article in this series will look at mission design approaches to reducing cost. One of the reviewers of this series has complained vociferously that it addresses almost entirely small-satellite programs. Therefore, the sixth article will break from talking about specific subject areas and address the problem of reducing cost in larger, more traditional programs.
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 email@example.com. Information on the joint Microcosm/USC Reinventing Space Project can be found at www.smad.com/reinventingspace.html.