Linux for the International Space Station Program
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.
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.
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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SourceClear Open
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide