Linux for the International Space Station Program
The first element of the International Space Station (ISS) has already been launched from Baikonur, Russia. ISS is the biggest civilian endeavor ever entrusted to human science and technology. Thousands of software code lines are being, and will be, written for the station, on-ground and on-board. ISS represents a synergy among many space agencies and companies around the globe, including European Space Agency (ESA). ESA has been developing several prototype systems which will pave the technology road for the European contributions to the ISS program. Among others, ESA has chosen Linux as the operating system for two software products which will control the rendezvous and docking operations for a servicing spacecraft called ATV. This article presents an overview of these products, explaining why they run on Linux, the advantages and disadvantages of doing so and the future of Linux in the space industry.
The ESA Automatic Transfer Vehicle (ATV) is an unmanned spacecraft planned to perform regular re-boosting and re-fueling of the International Space Station. Other ATV missions will comprise payload supply and payload removal from the ISS. The ATV is an ongoing project approved in October 1995 by the Council of the European Space Agency. ATV is scheduled to be launched for the first time by an Ariane 5 rocket from Kourou, French Guyana in February 2003.
In its early configuration, ATV was designed as a cylindrical shaped spacecraft containing a cargo module (pressurized or unpressurized), a docking port and a propulsion module. Lately, ATV was modified with four solar panels added (see Figure 1).
The ATV mission profile establishes docking with the ISS in the Russian segment of the station. Rendezvous operations start at about 20km behind the station. This means that ATV will fly behind and faster than ISS, in order to catch up to the docking port of the station. The problem of the space rendezvous is the mating of two spacecraft in orbit—a small active chaser spacecraft (ATV) and a big target (ISS).
Although spacecraft rendezvous and docking may look simple, they are not. The mathematical equations governing the relative movement between chaser and target are rather complex. The onboard control of the rendezvous operations is to a large extent automatic, but not fully autonomous. Some control tasks are done from the ground control center and others onboard the station. Although the ATV onboard computer is fault tolerant, the complexity of the mission does not allow the prevention of and recovery all possible types of mission failures. Special features of the onboard system would allow detecting and forecasting failures, isolating them and proposing and executing recovery actions, but only for those types of contingencies anticipated during system design. The failure detection and recovery features are linked to both mission safety and mission success.
To overcome these and other issues, ESA built two products: GOAS and RACSI. GOAS is the Ground Operator Assistant System for the rendezvous operations of ATV. Used on ground, GOAS is a software tool to monitor the ATV mission and intervene in case of a problem. GOAS provides complex command and control capabilities to replan the entire mission if necessary. RACSI is the remote ATV control at ISS. RACSI is a laptop computer running a software package operated by an astronaut onboard the station. RACSI double monitors and checks the ATV mission and provides two simple command capabilities: temporarily interrupt the mission or command a collision-avoidance maneuver.
Currently, both the GOAS and RACSI developments run under Linux. Although GOAS was developed on Solaris (using versions 1 and 2), the software was ported to Linux without difficulties. RACSI was originally programmed entirely under Linux. For both systems, Linux was chosen as the underlying operating system because it provides four basic features required by up-to-date space applications: reliability, performance, portability and affordability. Reliability is crucial to space applications. The feature of reliability is guaranteed by the robustness of Linux: both applications run dozens of processes concurrently, using extensively shared memories and semaphores. The software never crashes or misbehaves, despite the fact that both systems were designed to run nonstop for weeks or even months.
Performance is the definitive factor in measuring real-time critical software. Although Linux is not used in real-time mode (the RT-Linux module is not loaded), the applications run in real time. That is, they receive data from the spacecraft, display it and send it back to the satellite, all in real time. Everything runs within the specified communications rate between craft.
Software portability is of vital importance for upgrades and applications enhancement. Portability among UNIX flavors can be done quickly, preserving expandability and keeping manpower costs down. This is not true for other non-UNIX operating systems. In addition, Linux is available for an enormous range of hardware platforms, making the change between platforms as simple as recompiling (in most cases).
Nowadays, space applications often lack the funds needed to buy costly licenses. Linux is a zero-cost operating system, which provides true affordability. It can be copied as many times as desired, keeping license costs and royalties low. This is true not only for the operating system but also for the tools (compilers, debuggers, editors, development environments, etc.) which come with it.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
4 hours 48 min ago
- seo services in india
9 hours 19 min ago
- For KDE install kio-mtp
9 hours 20 min ago
- Evernote is much more...
11 hours 20 min ago
- Reply to comment | Linux Journal
20 hours 6 min ago
- Dynamic DNS
20 hours 40 min ago
- Reply to comment | Linux Journal
21 hours 38 min ago
- Reply to comment | Linux Journal
22 hours 28 min ago
- Not free anymore
1 day 2 hours ago
1 day 6 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?