Typically, flight software is both real-time and multi-tasking; and
robustness and fault tolerance are especially important because of the
remoteness of the space operating environment, and its potentially damaging
radiation environment. Also, because of the severe constraints on power and
mass, it also has to be resource efficient.
Science functionality often requires data reception and buffering,
support for multiple data processing modes, data compression, followed by
packetisation and transmission.
Engineering functionality can include commanding to provide instrument
control - both hardware (including mechanisms) and instrument modes, watchdog,
heartbeat, and regular reporting of engineering parameters (housekeeping data),
memory data downlink (memory verification/problem diagnosis) and software
uplink (new functionality/problem fixing). Autonomous control is also
supported for cases whereby human control is not possible, or cost effective.
It is when the human element is removed from the control loop.
Then the system has to provide the inputs that the human did before. There are
many reasons in space operations why human control is not possible or cost
effective. Reasons for autonomous control are listed as follow:
- Because of the great distances involved between Earth and the spacecraft, so that
simply the time required for a signal to reach the spacecraft can be several minutes
or even hours.
- Where response times need to be faster than that of a human operator.
- To keep costs down; such as those involved in providing radio dish
facilities and human operators for continuous 24 hour operations throughout a
10 year mission.
Types of autonomous control supported include:
- Maintain temperature of instrument to within fine limits.
(e.g. CCD at constant low temperature such as for XMM RGS, or telescope structure at
constant temperature for Solar-B EIS instrument)
- Follow energy response to improve energy resolution.
(e.g. giotto JPA instrument).
- Minimise spacecraft potential.
(e.g. Cluster mission).
- Operate instrument in several modes over extended periods when there is no ground contract.
(e.g. for Solar-b EIS instrument).
This software is developed in a research environment whereby the
requirements evolve during the development, although completion must be to
strict deadlines demanded by the space agency. Particular technologies used
for developing Space Flight Software at MSSL has included the following:
| Technology | Experience |
| Processors |
ADSP21020, MA31750a, Transputers (T800,T222), NSC800, 80C86, 6809, 1802 |
| Languages |
Java, C/C++, Perl, ADA, occam, assemblers |
| Development Hosts |
Sun servers, Mac Xservers, Linux servers |
| Development Systems |
Virtuoso (for ADSP21020), Tartan Ada, TDS (Transputer Development System) |
| Data Compression |
Quasi-log, SQRT (bit compression), JPEG, Wavelet (hcompress), Linear |
| Methodologies |
UML, Object orinted, functional decomposition, top down, prototyping, structured code, Hatley-Purbhai, ESA PSS05. |
|
+44 (0)1483 204100 - Copyright © 1999-2008 UCL