High-Level System Models Reduce Errors

At the apogee of software challenges are the rigorous demands of robotic deep-space missions. NASA’s July 4 success in hitting a bullet with a bullet—specifically, hitting a comet nucleus with a probe about the size of a coffee table at a relative speed of 23,000 mph—updates the archive of these high-profile tests.

Ironically, such missions during the last few years have been used to argue both sides in the religious debate over use of higher-level programming languages and tools. Personally, I gravitate to the high end—but Ed Post’s canonical essay, “Real Programmers Don’t Use Pascal,” took the other side with its anecdotes of missions to outer planets.

“Allegedly, one Real Programmer managed to tuck a pattern-matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter,” Post wrote in his semiserious commentary in Datamation magazine in July 1983. Speaking of the then-prospective Galileo mission, Post described its planned gravity-assist maneuver and said, “This trajectory passes within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust a Pascal program (or Pascal programmer) for navigation to these tolerances.”

The hazards of such low-level programming were spectacularly revealed, though, in 1999 when the Mars Climate Orbiter crashed into that planet because of confusion between English and metric units of force. My first thought, on learning the cause of the crash, was: “That’s the kind of thing that Ada can prevent”—Ada being, of course, quite Pascal-like. A properly written Ada program strongly associates explicit data types, such as force_newtons or force_pounds, with any numeric values. An Ada compiler refuses to use one type where another is specified. Errors are detected, moreover, when a program is compiled, rather than surfacing at run-time.

Java can be used in the same way, and Ada source code can even be compiled to Java bytecode to run in any Java virtual machine environment—although some purists would say that neither Java nor Ada is strongly typed because both languages enable forms of type conversion within a program. Personally, as long as all conversions are explicit, I’m OK with that.

Arguably even better than a strongly typed language, though, is a high-level system model that lets designers and users reason about desired behaviors—and generate the code that actually runs the system as a side effect only after the model behaves satisfactorily. That’s what NASA did when preparing its Deep Impact comet probe for its brief burst of glory.

“You compose a block diagram to represent the system,” said Jason Ghidella, a product manager at The MathWorks. Ghidella described NASA’s use of The MathWorks’ Stateflow, a tool that has been favorably mentioned in numerous NASA research papers during the last several years. Stateflow’s not without quirks: Researcher John Rushby, at SRI International, described Stateflow as having “ghastly semantics” in his presentation to a NASA workshop in June 2003, and a research team at Carnegie Mellon has compiled a Web page to share its “firsthand trial and error” discoveries as to Stateflow’s specific behaviors. Stateflow nonetheless enjoys a growing reputation for at least elevating trial and error to higher levels of abstraction.

Because of the long delays for radio commands to reach the Deep Impact probe, more than 7 light minutes from Earth, it had to have a fair amount of autonomous fault-handling capability. “You’re able to describe that in a more natural form using finite state machines in a graphical form. You can simulate all the scenarios,” said Ghidella during our conversation a week before the July 4 climax of the Deep Impact mission. “They did a lot of testing upfront, they verified the design at the model level [and] then they were able to generate the C code directly without introducing errors by hand.”

Handcrafted charm enhances antique furniture, but it has no place in modern systems. Development teams should always be looking for higher-level tools, or the debris of their failure may someday be studied just like the debris of Deep Impact’s success.

Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.

This article was originally published on eWEEK.com.