NASA Uses Stateflow and Simulink Coder to Generate Fault-Protection Code for Deep Space 1

A robotic spacecraft like DS1 must have the intelligence and autonomy to monitor and control itself at a great distance from Earth throughout its useful life. The ever-increasing distance between the spacecraft and Earth limits the ground teams’ ability to respond quickly to changes in spacecraft conditions. FP algorithms ensure either that a mishap can be circumvented or that contact with Earth can be reestablished if it is interrupted.

Before the DS1 project, FP system software was typically hand coded by a team of software developers. The constraints of the DS1 mission design and development cycle, however, together with limited budget and resources, dictated a radical departure from past practices. A further complication was the requirement that the FP system direct postlaunch activities, a task usually handled with sequences.

DS1 was operated by the Jet Propulsion Laboratory (JPL), a division of NASA managed by the California Institute of Technology. JPL had just over one year to design and code the spacecraft’s FP system. A shortage of software engineers meant delays if traditional design-to-code methods were used. JPL had to find a faster, more efficient way—a “13th technology.”

Searching for a Better Method

Previously, the monitors for the DS1 Remote Agent Experiment had been successfully created using automatic code generation. This seemed a good possibility for the FP system, but it would be necessary to shift the design and development of the system-level FP software from lower-level, C constructs to higher-level requirements, issues, strategy, and tradeoffs.

JPL also needed a design notation that was clear enough to allow several people to follow an analysis review and concise enough to fit the tight schedule.

JPL decided to use state charts and automatic code generation. This approach would allow them to separate design and implementation concerns.

Choosing the Design Tools

After evaluating several tools, JPL chose the “one-stop” solution provided by Stateflow. Of particular importance to the JPL team was the fact that, like all MathWorks products, Stateflow is an open system. This meant that they would be able to customize both the state charts and the automatic code generation to meet the demanding requirements of the DS1 project.

JPL also knew that Stateflow would let them reuse logic from another of their FP systems, that of the Mars Pathfinder. It would also enforce standard diagrammatic conventions for representing state charts and the resulting logic and allow systems engineers, rather than software engineers, to design and implement the system.

For code generation, JPL chose Simulink Coder, primarily because the MathWorks code-generation algorithm provides an open and customizable architecture. Two further benefits impressed them: the code is isomorphic to the topology of the state chart, and code generation is driven from Abstract Syntax Trees.

Executing the Design Architecture

The JPL team based the concept of the DS1 FP system on the successful Mars Pathfinder FP system. This design follows a uniform architecture in which EVR_FAULT events map to fault-response functions and the FP system executes fault-response functions, after which all faults are cleared.

The FP system has two levels of fault-response priorities: uninterruptible (a fault response runs until completion, no matter what else happens) and interruptible (a fault response can be put on hold at specific points).

Sensor monitors extract features from raw sensor data to detect symptoms of normal and abnormal behavior. Although symptom detection is hardware-specific, the overall FP architecture views sensor monitoring as a data-flow process, performing functional transformations of monitor state and sensor data.

In addition to the FP applications, JPL used automatic code generation to produce the flight software that guided DS1 through postaunch separation and initial signal acquisition.

Controlling the Initiated Launch

The DS1 launch initiated control- and system-level activities following separation of the spacecraft from the Delta II rocket. The launch state chart is a three-level hierarchy. At the top level, there are two states: “init” and “launch.” The transition from the “init” state is predicated on the “launch” event. The FP system broadcasts this event after it receives an indication that the spacecraft has booted up and separated from the launch vehicle.

JPL used Stateflow diagrams to enable the FP system to send commands to several managers to configure the system for initial acquisition. The Stateflow diagrams also cause the FP system to command the attitude control system (ACS) to estimate the spacecraft’s attitude and point-to-sun and then wait for an acknowledgement from the ACS.

Testing the Fault-Protection System

The FP system was tested both on the ground and in space. Ground testing was conducted in three phases: unit testing, when every branch in the FP system logic is tested in a standalone environment; test-bed testing, when only the most likely fault scenarios are tested; and system testing of behaviors that use extensive software-to-hardware interfaces.

During postlaunch separation and initial signal acquisition, the DS1 FP system prevented several potentially damaging malfunctions. For example, during the second sun acquisition state, the SRU (Stellar Reference Unit) processor began producing internal checksum errors and illegal software variable values. This produced a persistent Celestial Inertial Reference Loss (CIRL) condition, and the CIRL monitor declared a fault.

The FP system then suspended the launch state chart and started the CIRL response, which power-cycled the SRU and corrected the problem after a few minutes. The SRU then reacquired the sun signal and began tracking. When the turn-to-sun was completed, the FP system reconfigured the heater states, turned on the power amplifier, and initiated the X-band downlink.