Linux for the International Space Station Program

Figure 2. RASCI Screenshot

RACSI runs on an IBM ThinkPad laptop. The software requires 64MB of RAM and occupies around 40MB of disk space. (See Figure 2.) This type of laptop was chosen due to the hard radiation resistance requirements on the space station. It also provides an XGA graphical screen with a resolution of 1024x756 and 64K colors, mandatory for displaying trajectories and spacecraft equipment status. RACSI uses the X Window System (X11R6) with FVWM as its window manager. The Linux distribution currently installed on the laptop is Slackware version 3.0 with kernel 2.0.30.

A desktop configuration system has been installed on a Pentium Pro, running S.u.S.E. 5.2 with kernel 2.0.33. The pointing device of the system is the laptop track ball, although a conventional mouse can also be used.

RACSI was programmed entirely in ANSI C. It uses the Moo-Tiff libraries from InfoMagic version 2.0, so all widgets are Motif type. (FVWM fulfills the complete look appeal of the application.) The system uses shared memories and the Linux file system as database storage for telemetry data coming from the spacecraft. RACSI process interfaces make use of application program interfaces (APIs). The APIs constitute an additional layer of software, which allows hiding the differences between local and remote software calls between applications. The software of RACSI is subdivided into several modules (see Figure 3) according to a modular architecture compliant with ESA software standards.

Figure 3. RACSI Architecture

Telemetry Handler: this function is a data-handling module. It receives all incoming types of data from the spacecraft and preprocesses them to generate an additional set of data valid for storage and archiving. Next, this module distributes the data to a predefined set of client applications (e.g., Mission and Vehicle Monitoring and Control).

Mission and Vehicle Monitoring: this module allows the astronaut to have an overview of the status of both the mission and the vehicle. The Mission and Vehicle Monitoring module extracts data from the Telemetry Handler function and sends it to the Information Presentation function. This function provides a set of displays showing, with different levels of detail, information related to the mission and the vehicle extracted from the telemetry or resulting from any other data processing.

Failure Detection and Assessment: this function performs the detection and identification of a failure. When a failure is detected, the astronaut is free to manually interrupt the mission (stop the spacecraft) or abort the current mission plan (give control to ground).

Display Management: the purpose of this function is to provide an on-screen data presentation to the astronaut. RACSI screens are organized in three areas (see Figure 2): mission display (with information related to mission phase, mission transitions, etc.), main display area (trajectory plotting, equipment surveillance, etc.) and messages display area (local messages and warnings).

Telecommand Handler: this module provides centralized services to send two possible orders to the spacecraft: mission interrupt or a collision-avoidance maneuver.

Figure 4. GOAS Screenshot

The native GOAS system runs on a Sun workstation, Ultra-SPARC 5, with 64MB of RAM and 300MB of hard disk space. A color monitor is mandatory. (See Figure 4.) This configuration runs under Solaris (version 2.5). It uses the X (X11R6) graphical user interface, with Sun OpenLook as the window manager.

The Linux version was developed from this initial system; the Linux GOAS runs on a 233MHz Pentium with 48MB of RAM. This system also uses X11R6, with Linux OpenLook as the window manager. The pointing device is a mouse, although using keystrokes is allowed.

GOAS was programmed in the C and C++ languages. C is used for programming the applications, C++ for programming the graphical interface. GOAS uses a collection of commercial off-the-shelf software routines (ILOG views) to build certain parts of the man-machine interface.

GOAS can run with two or three monitors at the same time, allowing the viewing of many spacecraft parameters. It is possible to configure a different monitor to display the man-machine interface of the monitoring, failure detection, replanning modules, etc. Like RACSI, the software of GOAS is subdivided into several modules (see Figure 5), according to a modular architecture compliant with ESA software standards. However, GOAS is much more complex in terms of mission planning capabilities, trajectory prediction and failure detection and recovery.

Figure 5. GOAS Architecture

The Telemetry Handler receives the data from the spacecraft, archives it in several databases and broadcasts it to the necessary clients in the system.

The Failure Assessment subsystem performs the detection and identification of a failure by running a set of automatic tests under the control of the ground operator, are implemented at the mission, guidance, navigation and control levels, and compare both the actual and predicted state with reference corridors for position, attitude, rates, etc. This module archives data in a database.

In case of problems, the Failure Assessment module decides which recovery procedure should be applied to recover the mission: the Fast Intervention module when the recovery must be immediate, the Short-Term Recovery actions or a complete Mission Replanning.

Fast Intervention: the emergency actions managed by this function allow interrupting the mission. The ground operator is confronted with a predefined set of emergency actions: stop the spacecraft, initiate a drift out of the station inhibiting the thrusters, or initiate a collision-avoidance maneuver directly controlling the spacecraft thrusters. This strategy will prevent collision with the station.

Short Term Recovery: this function is used in situations where recovery allows a period of time between 5 and 15 minutes. The goal is to stabilize the mission, and afterwards to start the Replanning function once that situation is reached. If safety is not compromised, different Short Term Recovery actions can be launched: force switching of some equipment to the redundant ones, quick study of the impact of the coming maneuvers, activation of a short sequence of maneuvers, etc.

Mission Replanning: the purpose of this function is to support the operator intervention when the mission needs to be changed. It is a feature not present in RACSI—an astronaut cannot replan a mission; only the ground control center can. The Replanning function is launched on request. It supports the ground operator in the definition of a new mission plan according to three items: replanning scenario, mission constraints and status of the chaser equipment. This function can be run in automatic mode (the computer replans a whole new mission without operator intervention), semi-automatic (the operator is asked for some parameters) or manual (the operator constructs the maneuver sequence step-by-step). Visual information is constantly displayed to the operator.