SMAD

I'
66 Mission Evaluation 3.3
3.3 Step 8: Mission Utility 67
Rg. 3-4. HypotheUcaJ AnlmaUon Output for RreSat MIssIon UUJIty Slmulator. Color displays
are very valuable for animation sequences because we need to convey multiple
parameters in each frame.
best ways to develop and maintain expertise is to create your own systems and models.
Thus, organizations may want to support their own software group, particularly when
money is tight. Also, it's hard to overcome the perception that it costs less to incrementally
upgrade one's own system than to bear the cost and uncertainty of new COTS
tools. In this trade, the "home built" systems often don't include maintenance costs.
Fmally, customers often don't know which COTS tools are available. Professional
aerospace software doesn't appear in normal software outlets, advertising budgets are
smaIl, and most information is word-of-mouth through people already in the community.
Despite these substantial obstacles, many organizations are now using COTS
software in response to the strong demand to reduce cost.
In order to use COTS tools to reduce space system cost, we need to change the way
we use software. We need to adapt to software not being exactly what we want, look
for ways to make existing software satisfy the need, or modify COTS software to more
closely match requirements. This is a normal part of doing business in other fields:
Very few firms choose to write their own word processor, even though no single word
processor precisely meets all needs. Instead, they choose one that most closely
matches what they want in terms of functions, support, and ease of use. We should use
the same criteria for COTS space software. In addition, we need to set realistic
expectations concerning what COTS software can do. Clearly, we can't expect the low
prices and extensive support that buyers of globally marketed commercial software
enjoy. We have to adjust our expectations to the smaller market for space-related software,
which means costs will be much higher than for normal commercial products.
Maintenance and upgrades will ordinarily require an ongoing maintenance contract.
Within the aerospace community, a standard arrangement is for a maintenance and
upgrade contract to cost 15% of the purchase price per year.
Using COTS software and reusing existing noncommercial softWare requires a
different mindset than continuously redeveloping software. We need to understand
both the strengths and weaknesses of the relatively smaII space commercial software
industry. Because the number of copies sold is smaII, most space software companies
are cottage industries with a small staff and limited resources. We shouldn't expect
space-software developers to change their products at no cost to meet unique needs.
For example, it would be unrealistic to expect a vendor of commercial software for
low-Earth orbit spacecraft to modify the software for interplanetary missions at no
cost, because few groups will buy interplanetary software. On the other hand, the smaII
size of the industry means developers are eager to satisfy the customers' needs, so
most are williilg to work with their customer and to accept contracts to modify their
products for specific applications. This can be far less expensive than developing software
completely from scratch.
There is a hierarchy of software cost, going from using COTS software as is, to
developing an entirely new system. In order of increasing cost, the main options are
1. Use COTS software as sold
2. Use COTS software libraries
3. Modify COTS software to meet specific program needs (modification may be
done by mission developer, prime contractor, or software developer)
4. Reuse existing flight or ground software systems or modules
5. Develop new systems based largely on existing software components
6. Develop new systems from scratch using formal requirements and development
processes
This hierarchy contains several potential traps. It may seem that the most economical
approach would be for the prime contractor or end-user to modify COTS software to
meet their needs. However, it is likely that the COTS software developer is in a better
position to make modifications economically and quickly. Although the end-users are
more familiar with the objectives and the mission, the software developer is more
familiar with the organization and structure of the existing code.
Secondly, there is frequently a strong desire to reuse existing code. This will likely
be cheaper if the code was developed to be maintainable and the developers are still
avaiIable. On the other hand, for project-unique code developed with no requirement
for maintainability, it may be cheaper, more efficient, and less risky simply to discard
the old software and begin again.
Commercial mission analysis tools fall into three broad categories, each of which
is described below. Representative examples of these tools are listed in Table 3-9.
Generic Aruzlysis Systems. These are programs, such as MatLab, which are
intended to allow analysis and simulation of a wide variety of engineering and science
problems. They typically cost a few hundred to several thousand dollars and can
dramatically reduce the time needed to create simulations and analyze the results.
Because these are generic tools, specific simulation characteristics are set up by the
user, although subroutine libraries often exist. Thus, we will need to create orbit
propagators, attitude models, environment models, and whatever else the problem
dictates. We use this type of simulation principally for obtaining mathematical data
and typically not for animation.
Low-Cost Aruzlysis Programs. These are programs intended for a much wider
audience such as the amateur astronomy or space science community. However, when
carefuIly selected and used appropriately, they can provide nearly instant results at
very low cost The programs themselves cost a few hundred dollars or less, are