SMAD

26 Mission Characterization 2.1
2.1 Step 3: Identifying Alternative Mission Concepts 27
Even if we choose to process data mostly in space, the basic system design should
allow us to obtain or recreate selected raw data for analysis on the ground. A fully
automated FueSat should have some means to record or broadcast the raw imaging
data, so mission planners and analysts can evaluate how well the system is working,
fix problems, and plan alternative and better techniques for later missions.
Traditionally, space software has been much more expensive than ground software.
This suggests that processing on the ground is generally lower cost than processing on
board the spacecraft. We believe that this will change in the future and, therefore, software
cost should not be a major trade element in the space vs. ground processing trade.
The cost of software is a function of what is done and how reliable we need to make
it, rather than where it is done. We can choose to make highly reliable software as
nearly error-free as possible for our ground systems and this software will have the
high cost inherent with most previous onboard software systems. On the other hand,
simple software with many reusable components can be developed economically and
used on the spacecraft as well as on the ground.
The space vs. ground processing trade will be a key issue and probably a significant
stumbling block for most missions in the near future. For short-lived, nontime-critical
missions, it will probably be more economical to work on the ground with little automation.
For long-lived missions, or time-critical applications, we will have to
automate the processing and then do space vs. ground trades to minimize the operation
and end-user costs. In any case, we wish to use the data flow analysis to evaluate where
the data is coming from and where it will be used. If possible, we would like to minimize
the communication requirements and associate data (e.g., attach time or position
tags) as early as possible after the relevant data has been created.
For FueSat the payload sensor generates an enormous amount of data, most of
which will not be useful. One way to effectively deal with large amounts of raw data
on board the spacecraft is to compress the data (i.e., reduce the amount of data to be
stored or transmitted) prior to transmitting it to the ground. The data is then recreated
on the ground using decompression algorithms: There is a variety of methods for
compressing data, both lossless and lossy. Lossless data compresSion implies that no
information is lost due to compression while lossy compression has some "acceptable"
level of loss. Lossless compression can achieve about a 5 to 1 ratio whereas lossy
compression can achieve up to 80 to 1 reduction in data. Many of the methods of data
compression store data only when value changes. Other approaches are based on quantization
where a range of values is com~ using mathematical algorithms or
fractal mathematics. By using these methods, we can compress the data to a single
algorithm that is transmitted to the ground and the image is recreated based on the
algorithm expansion. With the use of fractals, we can even interpolate a higher resolution
solution than we started with by running the fractal for an extended period of time
[Lu, 1997]. We select a method for data compression based on its strengths and weaknesses,
the critical nature of the data, and the need to recreate it exactly [Sayood, 1996].
When we transmit housekeeping data we would generally use lossless compression
for several reasons. First, raw housekeeping data is not typically voluminous. Second,
it is important that none of the data is lost due to compression. However, when we
transmit an image we might easily use lossy compression. We could either preview the
image using lossy compression of we could say that the recovered image is "good
enough." Alternatively, a high resolution picture may have so much information that
the human eye can not assimilate the information at the level it was generated. Again,
in this case a lossy compression technique may be appropriate.
In the FrreSat example, we might use a sensor on board the spacecraft that takes a
digital image of the heat generated at various positions on the Earth. The digital image
will be represented by a matrix of numbers, where each pixel contains a value corresponding
to the heat at that point on the Earth's surface. (Of course, we will need some
method, such as GPS, for correlating the pixel in the image to .the location on the
Earth.) If we assume that the temperature at each location or pixel is represented by
3 bits, we can distinguish eight thermal levels. However, if we set a threshold such that
a '"baseline" temperature is represented with a 0, we might find that over many
portions of the Earth, without fire, the image might be up to 70% nominal or O. This
still allows for several levels of distinction for fires or other "hot spots" on the Earth.
Rather than transmit a 0 data value for each cold pixel, we can compress the data and
send only those pixel locations and values which are not O. As long as the decompression
software understands this ground rule, the image can be exactly recreated on the
ground. In this case, we can reduce our raw data volume to the number of hot spots
that occur in any given area.
Central vs. distributed processing. This is a relatively new issue, because most
prior spacecraft did not have sufficient processing capability to make this a meaningful
trade. However, as discussed above, the situation has changed. The common question
now is, "how many computers should the spacecraft have?" Typically, weight and
parts-count-conscious engineers want to avoid distributed processing. However,
centralized processing can make integration and test extremely difficult. Because
integration and test of both software and hardware may drive cost and schedule. we
must seriously consider them as part of the processing trade.
Our principal recommendations in evaluating central vs. distributed processing are:
• Group like functions together
• Group functions where timing is critical in a single computer
• Look for potentially incompatible functions before assigning multiple functio~
to one computer
• Maintain the interface between groups and areas of responsibility outside of the
computer
• Give serious consideration to integration and test before grouping multiple functions
in a single computer
Grouping like functions has substantial advantages. For example, attitude detP.nnination
and attitude control may well reside in the same computer. They use much of
the same data, share common algorithms, and may have time-critical elements.
Similarly, orbit determination and control could reasonably reside in a single navigation
computer, together with attitude determination and control. These hardware and
software elements are likely to be the responsibility of a single group and will tend to
undergo common integration and testing.
In contrast, adding payload processing to the computer doing the orbit and attitude
activities could create major problems. We can't fully integrate software and hardware
until after we have integrated the payload and spacecraft bus. In addition, two different
groups usually handle the payload and spacecraft bus activities. The design and
manufacture of hardware and software may well occur in different areas following
different approaches. Putting these functions together in a single computer greatly increases
cost and risk during the integration and test process, at a time when schedule
delays are extremely expensive.