Space flight software is implemented to:
- Allow control of the instrument
- Monitor instrument health and safety
- Collect, process and downlink science data
- Provide remote diagnostic and software change capability
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 electrical 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:
|Processors||Leon, 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, ECSS|
Page last modified on 09 sep 11 10:36