Skip to main content

skip to main content

developerWorks  >  Linux | Open source  >

Open source satellite control

Where "mission critical" is more than just a buzzword

developerWorks
Document options

Document options requiring JavaScript are not displayed


My developerWorks needs you!

Connect to your technical community


Rate this page

Help us improve this content


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
Jason-1 POCC

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
JTCCS context

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.



Back to top


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
JTCCS telecommand

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.



Back to top


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)
workstation display

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."



Back to top


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


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top