Remotely Monitoring a Satellite Instrument

How a small aerospace company uses Linux to remotely monitor the performance of a satellite instrument.

G & A Technical Software (GATS) is a
small aerospace company located in Newport News, Virginia. Our
primary area of business is the analytical support of
satellite-based atmospheric remote-sensing projects. We started
using Linux in 1995 for software development and data processing
workstations.

NASA is funding a two-year satellite mission called TIMED
(Thermosphere Ionosphere Mesosphere Energetics and Dynamics) to
study the atmosphere. One of the experiments on the spacecraft is
called SABER, which stands for Sounding of the Atmosphere using
Broadband Emission Radiometry. SABER's mission is to make
measurements of temperature, ozone, carbon dioxide, water vapor and
other trace gases to learn more about the complex relation of
energy transfer between the upper and lower atmosphere. GATS has
been contracted by NASA to develop and operate the systems and
software that process the data from the spacecraft.

A big part of the SABER experiment is calibrating and testing
the instrument while it is on the ground. This task involves making
measurements of known sources and analyzing the results so that
data taken from orbit can be understood. Calibration of SABER is a
difficult task, because measurements need to be made at conditions
found in space. To accommodate this, SABER is calibrated in a large
chamber that is capable of cold temperatures and near vacuum
pressures. SABER and its calibration facility were built by the
Space Dynamics Laboratory (SDL) in Logan, Utah. Figure 1 is a
photograph of the actual calibration test happening in the testing
facility at SDL.

Figure 1. The high bay at SDL. The
SABER test chamber is under a clean tent on the left. To the center
and right are engineers operating the instrument during calibration
tests. The computers mentioned in this article are along the right
wall.

In this article, I will describe a Linux-based system that
allows remote monitoring of the SABER calibration tests. I will
discuss the porting of software from a Windows NT workstation to a
Linux workstation due to reliability requirements, as well as the
use of several open-source products such as the GNU C++ compiler,
CVS for configuration management, Xmgr for diagnostic plots,
PostgreSQL database, VNC for remote terminal access and Perl. Many
of the systems proven by this project can be used by other small
businesses for powerful cross-country data processing while keeping
total costs and development time low. The system is robust and
provides real-time monitoring and analysis of the SABER instrument
(located in Logan, Utah) from Newport News, Virginia. The same
system will be used for post-launch data processing.

Requirements

Big projects go through several iterations of
requirements/design/review, and SABER was no exception. When the
time came to put together a final design, the requirements for the
system were well-documented. Basically, the system needed to talk
via a socket to a computer (a Sun workstation dubbed GSE for ground
system equipment). The GSE computer provided raw data from the
SABER instrument as well as all the test equipment connected to it.
We needed to unpack the data into large staging files which could
be read by analysis programs. On top of this, the system needed to
access a PostgreSQL database on the GSE that was being populated by
the SDL test operators with information on the various tests being
run, such as times and readings from the various sensors. We had to
provide software flexible enough to quickly analyze data with
unknown quirks. This means easy debugging and code-level diagnostic
plotting capability. The system had to work 24 hours per day and
provide remote access from Virginia to Utah so that our engineers
could have timely access to the data for supporting the actual
tests. Finally, the system we developed had to be easily
reconfigurable for post-launch data processing.

Design

We began the design by using software that GATS developed for
another project. These C routines provide an interface to raw
spacecraft data in the standard spacecraft format developed by the
Consultative Committee for Space Data Systems (CCSDS). SDL
simplified the job for us by making the raw CCSDS data available
over a TCP socket, which our system already supported. We call this
stage of the processing Level 0. It takes the raw binary data in
packet form and unpacks it into ASCII files, sorted by data type.
We chose ASCII for the initial design because disk space was not an
issue (9GB total), and troubleshooting is much simpler if files are
human-readable. ASCII is also a friendly format for passing between
different systems. We wanted this stage of processing to write
across the network as well, so NFS was a must. Note that utilizing
socket calls and NFS at this stage means the physical location of
the Level 0 computer is irrelevant, as long as the Internet is
available.

The next stage of the processing is called Level 1, and its
first job is to query the PostgreSQL database for test information.
With this, the relevant data is extracted from the Level 0 files
and broken out into a single file for each test. For this part of
the design, Linux was a must. The Level 1 processing had to talk to
an NT box and a Sun workstation. We chose Linux because Samba is
easy to set up for NT file sharing, and data sharing with the Sun
is automatic via NFS. The software design called for
object-oriented programming (OOP) using C++, so that classes
writing the Level 1 files could be reused downstream to read the
data. Linux comes with GNU C++, which is extremely reliable and
easy to debug. Another reason for choosing Linux was that the
analysis tools for this project were developed in C++ on a Linux
workstation using the powerful (and freely available) display
package called Xmgr.

This design is easily modified for post-launch processing,
since the data coming from the calibration setup is in precisely
the same format as that coming from the spacecraft.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.