SMAD

62
Mission Evaluation
3.3
3.3 Step 8: Mission Utility 63
Fig. 3-2.
State
of Alert
Preparations
BegIn
I
I
I
I
I
O---t
-72 -48 -24
Measure of Effectiveness = Warning TIme (hours)
FIre
Hits
Forast Fire Warning TlmB for Inhabited Areas. A hypothetical measure of effectiveness
for FlreSat
Mission utility analysis also provides information that is readily usable to decision
makers. Generally those who determine funding levels or whether to build a particular
space system do not have either the time or inclination to assess detailed technical
studies. For large space programs, decisions ultimately depend on a relatively small
amount of information being assessed by individuals at a high level in industry or
government A strong utility analysis allows these high-level judgments to be more
informed and more nearly based on sound technical assessments. By providing summary
performance data in a form the decision-making audience can understand, the
mission utility analysis can make a major contribution to the technical decisionmaking
process.
Typically, the only effective way to evaluate mission utility is to use a mission
utility simulation designed specifically for this purpose. (Commercial simulators are
discussed in Sec. 3.3.3.) This is not the same as a payload simulator, which evaluates
performance parameters for various payloads. For FrreSat, a payload simulator might
compute the level of observable temperature changes or the number of acres that can
be searched per orbit pass. In contrast, the mission simulator assumes a level of
performance for the payload and assesses its ability to meet mission objectives. The
FrreSat mission simulator would determine how soon forest fires can be detected or
the amount of acreage that can be saved per year.
In principle, mission simulators are straightforward. In practice, they are expensive
and time consuming to create and are rarely as successful as we would like. Attempts
to achieve excessive fidelity tend to dramatically increase the cost and reduce the
effectiveness of most mission simulators. The goal of mission simulation is to estimate
measures of effectiveness as a function of key system parameters. We must restrict the
simulator as much as possible to achieving this goal. Overly detailed simulations
require more time and money to create and are much less useful, because computer
time and other costs keep us from running them enough for effective trade studies. The
simulator must be simple enough to allow making multiple runs, so we can collect
statistical data and explore various scenarios and design options.
The mission simulation should include parameters that directly affect utility, such
as the orbit geometry, motion or changes in the targets or background, system scheduling,
and other key issues, as shown in Fig. 3-3. The problem of excessive detail is
best solved by providing numerical models obtained from more detailed simulations
of the payload or other system components. For example, we may compute FrreSat's
capacity to detect a forest fire by modeling the detector. ~si~vity, atmospheric characteristics,
range to the fire, and the background conditions m the observed area. A
detailed payload simulation should include these parameters. After running the payload
simulator many times, we can, for example, tabulate the probability of detecting
a fire based on observation geometry and time of day. The mission simulator uses this
table to assess various scenarios and scheduling algorithms. Thus, the mission simulator
might compute the mission geometry and time of day and use the lookuIJ. table to
determine the payload effectiveness. With this method, we can dramatically reduce
repetitive computations in each mi~sion simulatm: run,. do ~ore simul~ti~ns, ~
explore more mission options than WIth a.more detailed sunulation. The JlllSSlon SllDulator
should be a collection of the results of more detailed simulations along with
unique mission parameters such as the relative geometry between the satellites i? a
constellation, variations in ground targets or background, and the system scheduling
or downlink communications. Creating sub-models also makes it easier to generate
utility simulations. We start with simple models for the individual components and
develop more realistic tables as we create and run more detailed payload or component
simulations.
Simulator &
Main Models /. Output Processors ~ PrIncipal Outpula
____________ ~ Arn~~n~
Energy
L.
Observation data
Time uIiIlzaIlon
System parameteJs
=.:;ormanca - / Energy used
Background characteristics
~_
Pointing sIatIstIcs
Time used
Data utiliza~n
Fig. 3-3.
Observation Types
(FIreSat example)
Search mode
Map mode
Are boundary mode
Temperature sensing
PrIncipal Inputs
ScenarIos
Tasking
System parameters
ConsteDalion parameters
Gap statistics
Probability of
detecllonlconlalnment
Response times
ScheduDng sIatIstIcs
Cloud cover
Are detection MoEs
Results of FlreSat AltItude Trade. See Table 3-4 and Table 7-6 In Sec. 7.4 for a list
of trade Issues. Political constraints and survivabDity were not of concem for the
FlreSat altitude trade.
Table 3-8 shows the typical sequence for simulating mission utility, including a
distinct division into data generation and output This division allows us to do various
statistical analyses on a single data set or combine the outputs from many runi; in different
ways. In a conStellation of satellites, scheduling is often a key issue in mission
utility. The constellation's utility depends largely on the system's capacity to schedule