The On-Board Data Handling (OBDH) system has two main tasks. Firstly it must carry out attitude control and housekeeping tasks for the spacecraft throughout the mission. Secondly it must perform data collection, processing and storage during the target encounter.

Spacecraft Control. For this level of study it was decided not to carry out a detailed estimate of the processing power required to carry out spacecraft control and housekeeping functions. Instead the on-board computer systems for a number of small spacecraft missions was used as a guide to the mass and power requirements of the computer system likely to be required for this mission [Wertz96]. A number of such small science missions have flown in recent years (e.g. the UoSAT series, SAMPEX, Clementine) carrying moderately powerful computers (e.g. 80186 variants) and Mbit to Gbit size solid-state data recorders for typical OBDH masses of circa 10 kg and power requirements of circa 10 W. These figures were thus taken as design baselines for the OBDH system on this mission.

Data Rate. What data rate will the probe's OBDH system and telemetry downlink have to support? As discussed in Section 9 the core payload for this mission is a CCD imaging sensor. A 1024 x 1024 pixel CCD sampled at 8-bit resolution produces a 1 MB image. The rate at which such images can be produced is limited by several factors:

• The time taken to read the data from the CCD.
• The time taken to change filter wheel settings.
• The rate at which data can be stored or processed.

The data storage constraint is not too serious, especially if solid-state storage is used. The Clementine mission used a 200 MB solid-state store capable of handling 20 Mbits/s [Wertz96] so up 2.5 images/s could be stored with such a system. Data can be clocked from a CCD at whatever rate is desired, but the higher the rate the worse the noise. CCDs used for video applications clock data at 30 frames/s whilst those used for astrophotography may be clocked at one frame in 50 s [McLean97] so a frame rate around one per second is probably practical for this application. It is also reasonable to assume that a filter wheel could be driven at at least this rate. A five-waveband image set (near IR, RGB and near UV) could thus be obtained every 5 seconds for a data rate of 8 MB/s. During the final seconds of the encounter (Section 8) the probe will be moving significantly with respect to the target in this time; as high spatial rather than spectral resolution is important during close encounter it may be appropriate to use only a single band for imaging during this phase of the mission.

Data Compression. A companion technique to error control coding (Section 12) is data compression. Compression reduces the amount of data to be sent whilst preserving its content, allowing a lower bit-rate link to be used or more data to be sent over the same link. A variety of data compression techniques have been developed, especially for image and speech compression [Bhaskaran95]. Such techniques can be divided into lossless and lossy compression. Lossless compression exploits redundancy in the data (e.g. contiguous groups of identical pixels in an image) to reduce data size. Data transmitted using lossless compression is identical to the original. Lossy compression transmits an approximate description of the original data; the received data resembles the original (e.g. for an image) but is not the same actual data. Lossy compression is thus useful where appearance is important but cannot be used where data is to be numerically analyzed. It is often possible with lossy compression to vary the compression ratio in relation to the fidelity of data transmission required. For example, Fig 13.3a-d show 4 versions of an image of asteroid Gaspra compressed to different extents via the lossy JPEG standard.

Empirical trials using JPEG-capable image processing software showed that a 256 kB image could be compressed to circa 10 kB before compression artefacts became obtrusively visible. It is thus reasonable to assume that lossy compression of images by a factor of at least 10 is practical.

Compression could be carried out either in real time or after the encounter. Real-time compression reduces the data storage requirement and allows some data to be transmitted at a low rate during the encounter. However it means that the original data is lost and requires compression at a very high rate. Post-encounter compression requires that the full data stream be recorded but allows it to be sent back in detail if required. It also reduces the rate at which data has to be compressed.

Compression via the JPEG algorithm requires that the image is broken into 8 x 8 pixel blocks which are then processed via the discrete cosine transform (DCT). An 8 x 8 DCT requires some 3200 floating point operations [Bhaskaran95] so to process one 1024 x 1024 image, comprising 16,384 such blocks, every second will required 52.5 million floating point operations per second (MFLOPS). This is beyond the processing capacity of currently available space-qualified computers [Larson92, Wertz96] but within the capabilities of dedicated hardware image-processing ICs. A number of such ICs are available, e.g. the SGS-Thomson STV3208 and Zoran ZR36020 [Bhaskaran95] capable of carrying out JPEG compression at rates of 20-40 MB/s, far above what is required for this application. Although not radiation-hardened, image-compression ICs have flown successfully on space missions such as Clementine [Wertz96].

Summary. The imaging payload will probably generate data at a rate of 8 Mbit/s during the encounter phase. Such data can be compressed using lossy data compression to an rate of approximately 800 Kbit/s without unacceptable loss of data, requiring 60 MB of storage for a 10-minute encounter. This data set could be downloaded at 1 Mbit/s (well below the estimated maximum capacity of the downlink) in under 500 s. Addition of more storage would allow some or all of the data to be stored in uncompressed or losslessly compressed form for subsequent download if it was required.