 | Level: Introductory Cameron Laird (claird@phaseit.net), Vice president, Phaseit, Inc.
01 Aug 2002 How do you harness a satellite control system written in three languages, on four development platforms, and deployed to multiple client environments? With open source, naturally. When one wrong move can cost millions, rely on teamwork, smart design, and open standards to keep the project -- if not the satellite -- from going down in flames.
Suppose you're a rocket scientist, or, more precisely, a
satellite engineer with the Jet Propulsion Laboratory (JPL).
Your assignment is to get an innovative scientific satellite into
orbit on schedule, under budget, and with novel functionality
and robustness. How do you do it? Well, if you believe the Jason-1 ground-control systems team,
you do it the old-fashioned way: with disciplined teamwork (and maybe a few technical advantages). Software engineering basics
At least that's the message from the Jason Telemetry Command and
Communications System (JTCCS) team.
If you sit in on one of the project seminar video recordings (see Resources later in this article), you'll see for yourself
the JPL emphasis on project management, good development
processes, respect for individual capabilities, small-group
nimbleness, and other well-established principles for getting
the most from experienced professionals. The result: software
deliverables that may have saved hundreds of
thousands of dollars compared to the record of other teams.
NASA itself has already recognized JTCCS as a candidate for
"Software of the Year" and is considering re-use of its assets
for other ground-control jobs. The team achieved all this despite
a number of obstacles: a
Java Virtual Machine (JVM) so poorly supported by its vendor that it
had to be abandoned, complementary projects that were behind
schedule, personnel difficulties, and more. Smart use of open technology contributed to the success of the JTCCS software. Systems
Software Engineer W. John Guineau co-authored a design that
clearly supports portability and modularity. This paid off
repeatedly. Near the beginning of the project, OpenVMS, popular
throughout NASA, was the platform of choice. Inadequate JVMs
forced migration to Windows NT, with development hosted on a
mixture of UNIX and Linux, Windows, and MacOS. Porting
costs were minimal, though, because of the robustly
layered design. Guineau epitomizes the control he keeps over
platform-specific coding with his slogan, "If you feel the
need to call a WIN32 API, come talk to me." The result:
Engineers moved to new and far less expensive desktops, and
successfully picked up where they'd left off. Take a peek inside the Jason-1 control center in Figure 1. Figure 1. Project Operations Control Center (POCC) for Jason-1

While Java is often presented as a model of a portable
language, JTCCS's careful system design (shown in Figure 2)
brought portability
challenges under control for all languages, including C.
The main body of JTCCS, including ancillary utilities, is coded in around 450,000 lines of
C, C++, and Java. C and C++ generally predominate in the
interfaces to external devices, while the user interface
client and server are coded in Java. Figure 2.
JTCCS context within Jason-1 ground system

The graphical user interface (GUI) itself was nearly
a disaster. One part of the team had isolated itself
with the VisualCafé GUI-builder for two years (!)
without making significant progress on wiring
its handsome screen displays to useful functionality.
Only last-minute heroism and a remarkably potent
design were able to rescue the operators' displays
from severe delays.
Taking advantage of outside solutions
A strong design also helps keep interfaces to "foreign"
software healthy. JTCCS leverages a mixture of proprietary
and no-fee software. It relies on Talarian publish-subscribe
messaging for robust inter-process communication. As the
Talarian product itself rests on Internet protocol (IP)
standards, this means that the different
functional components of JTCCS can be fully distributed across the Internet (see Figure 3). Figure 3.
JTCCS telecommand process functions and interfaces

In contrast, communication between the user-interface client and server is done entirely by passing
serialized Java objects. This communication is also constructed as a
publish-subscribe architecture. Client
software based on at least a half-dozen different code bases,
hosted by a range of hardware including handhelds, MacOS,
Linux, UNIX, Windows, and OpenVMS, all subscribe, at different
times, to such events as "update of telemetry data catalogue"
or "satellite connection acquired." Different clients have
different "powers"; for instance, some are read-only, purely
for monitoring. Publish-subscribe gives excellent scalability
and "isolation" between all these disparate "stakeholders" in the operation of JTCCS. Another proprietary component is the NuTCRACKER commercial
UNIX emulation layer. This component has a special and narrow role. In
Guineau's words, "The only thing this is used for is to wrap
some code ... that implements the particulars of the
telecommanding protocol." The Consultative Committee for Space
Data Systems (CCSDS) telecommanding protocol and its
implementation are both international standards external to
Jason-1 and indeed to NASA. Two other pieces of JTCCS are open source. One is a Portable
Document Format (PDF) library, for generation of high-quality
printed output. The second and most dramatic inclusion in the JTCCS is its
scripting library. While the user interface is entirely written
in Java, its server side includes a Tcl/Java interpreter. This
exposes the server's Java classes as scriptable elements.
Scripting multi-million-dollar maneuvers
What's the significance of scripting? Understand first the
standard practices in satellite ground control: manageability
requirements are expressed in terms of a
conventional user interface.
To perform a specific function, the system must
enable a trained technician to point-and-click his way through a routine sequence of operations (see a sample in Figure 4). Figure 4. Complexity of a typical workstation display (don't worry -- we can't make it out either)

JTCCS does this, of course, but this model is labor intensive
and correspondingly fragile. The Tcl interface
has the power to express all operations textually. That power brings
a new level of manageability to satellite operations. Instead
of needing an expensive human executing a hand-eye exercise,
the control team can engineer a script that precisely
describes its intent. The following listing illustrates this. Listing 1. Tcl code for fragment of satellite control sequence
# procedure to translate a file
# tcfile = name of TC file to translate
# tctype = TranslateBinaryOnly | TranslateGroupOnly
# returns 1 if successful 2 for Failure, otherwise 0
proc translateCommand { tcfile tctype } {
set rc 0
# Translate the file
set tid [jtcc tc translate $tcfile $tctype]
if {$tid != "" & $tid != "0"} {
# Loop for up to 15 seconds waiting for a connection
for {set count 0} {$count < 15} {set count [expr $count + 1]} {
set tcstatus [lindex [jtcc tc xlatstatus $tid] 0]
if {$tcstatus == "Success"} {
set rc 1
break;
} else {
if {$tcstatus == "Failure"} {
logMsg -e "Failed to translate $tcfile ($tctyoe)"
set rc 2
break;
}
}
jtcc wait 1000
}
}
return $rc
}
|
This isn't the only application of scripting. Exactly the
same architecture is used elsewhere at NASA and in other
mission-critical applications to automate regression testing,
to accelerate development in comparison to what's possible
with sluggish Swing-based environments, to allow end-users
to configure personal preferences, and to script many computing
systems functions. As Guineau explains, "JPL uses Tcl
everywhere, as I suspect lots of people do." However,
use of scripting languages such as Tcl and Python is rarely
publicized. JTCCS makes use of none of these other forms of scripting
in its present application, but this seems likely to change as
JTCCS as a whole is under review for re-use on other projects.
Guineau himself is "moonlighting" on the Rover Analysis,
Modeling, and Simulation (ROAMS) project, where, among other
initiatives, he is already implementing a simplified wrapper and
interface generator (SWIG) to ease future scripting projects.
What scripting does achieve for JTCCS now, though, is the first
"lights-out," or unmanned, automatic operation of a NASA
satellite. Just before this article was published, JPL mission operators planned to conduct the first ever lights-out test of the system, which means, according to Guineau, "there will be no human operator
in the loop at all as the system connects to, communicates with,
and processes data from the satellite several times per day." A collateral benefit of scripts' readability is that
ground control sheds its esoteric qualities. More team
members can usefully read and write scripts than could
ever use the standard user interface. Rather than being
tied to special-purpose displays, ground control now
conveniently floats onto desktops and even wireless hand-held
machines. More "eyeballs" review operations, the operations
themselves become more auditable, and quality becomes more
manageable. Hand-held operation has been another JTCCS innovation,
benefitting from a highly portable and flexible design.
As Guineau explains, "since we can write automation scripts
and 'call' them from a client, we can do virtually
anything from the handheld that you can do from the
full-blown PC client. This made headlines at JPL."
Summary
If your software has a mission that is truly critical,
you probably need:
- Top-quality project management
- Experienced, honest, intelligent programmers
- Careful design, with full resources given to
documentation and other collateral services
- Coding standards that provide for easy porting
and interfacing with external libraries
- Good team dynamics
- For automation and rapid development, scripting
exposure
Those appear to be Jason-1's lessons.
Resources -
Jason-1
is the first follow-on orbital launch to the TOPEX/Poseidon
mission. Ocean
Surface Topography from Space is the scientific project
Jason-1 supports.
- The
Jet Propulsion Laboratory
is "NASA's lead center for robotic exploration of the solar
system." In particular, it's Jason-1's ground-control home. This nearly
hour-long video of a JPL presentation explains the JTCCS
team's own judgments about its achievement. The Jet Propulsion Laboratory also hosts
Long Range Science Rover (LRSR), a completely separate project.
-
Talarian Corporation's
SmartSockets product has long been popular in industrial and
aerospace circles for its high-performance, reliable messaging
services.
- NuTCRACKER is now sold as the
MKS
Toolkit for Enterprise Developers.
- SWIG, an interface
compiler, connects C and C++ programs with
Perl, Python, and Tcl/Tk scripts.
- Migrate your VisualCafé applications to WebSphere Studio by following this three-part series of articles:
- Part 1 describes general migration considerations in addition to issues specific to migrating, debugging, and deploying Web WAR applications.
- Part 2 shows how to migrate an EJB application.
- Part 3 covers in detail the WebLogic2WebSphere migration tool.
- Take our tutorial "Building dynamic Web sites with WebSphere Studio".
- Our "Tcl/Tk quick start" tutorial introduces the Tcl/Tk scripting language, providing background on its history and key features and showing a number of examples of how to use Tcl/Tk (developerWorks, October 2001).
- If you need to interface your C, Python, Tcl, or Java code with Perl, the Inline module provides a transparent way to embed other languages directly in Perl files. Read about it in "Using Inline in Perl" (developerWorks, June 2001).
- Need Java? Download an IBM Java developer kit.
- Read IBM's take on messaging middleware, WebSphere MQ, formerly MQSeries.
- Check out Cameron's "Server clinic" columns on scripting topics on developerWorks:
- Find more Linux articles in the developerWorks Linux zone.
About the author  | |  |
Cameron is a full-time consultant for Phaseit, Inc. He writes and
speaks frequently on open source and other technical topics.
You can contact him at claird@phaseit.net.
|
Rate this page
|  |