NASA Uses Stateflow and Simulink Coder to Generate Fault-Protection Code for Deep Space 1
“Until Deep Space 1, state charts and automatic code generation technology had not been used on large systems for spacecraft avionics software. MathWorks tools made this approach possible.”
Challenge
Solution
Results
- Prolific generation of reliable code
- Record-breaking operational lifespan
- Rock-solid performance
![](https://ww2.mathworks.cn/company/user_stories/nasa-uses-stateflow-and-simulink-coder-to-generate-fault-protection-code-for-deep-space-1/_jcr_content/imageEnhancedParsys/image.adapt.full.medium.jpg/1469941203395.jpg)
On October 24, 1998, NASA launched a Delta II rocket from Cape Canaveral in Florida. On board was a spacecraft named Deep Space 1 (DS1).
The DS1 mission was part of NASA’s New Millennium Program, a series of deep-space and earth-orbiting missions designed to test and validate 12 high-risk new technologies. The ultimate goal, according to Dr. Wesley Huntress, NASA’s Associate Administrator for Space Science, was to “enable these technologies to be used with greater confidence on scientific missions of the early 21st century.”
DS1 was also designed to test an unofficial “13th technology”: the model-based code generation of the spacecraft’s system-level fault-protection (FP) software. This was accomplished using MATLAB®, Stateflow® and Simulink Coder™.
Challenge
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.Solution
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.
Results
Prolific generation of reliable code. Between June 1997 and January 1999 (when the FP code was last modified), JPL automatically generated over 230,000 total lines of code using Simulink Coder. This translates to approximately 180 lines of code per day.
Record-breaking operational lifespan. DS1 flew within 26 km of Asteroid Braille on July 29, 1999. New software systems and commands were built and installed when the spacecraft was more than 300 million km from Earth. Now that the hardy spacecraft has resumed normal operations, it has added yet another record to its extensive list of accomplishments: the longest operating time for an ion propulsion system in space.
Rock-solid performance. Having completed 100% of its original testing mission, NASA has extended DS1’s mission to include an encounter with a distant comet. The spacecraft has pushed well beyond the limits of what it was designed to do, and its fault protection system continues to work, day in and day out, exactly as intended.