NASA Ames Research Center Develops Flight Software for Lunar Atmosphere Dust Environment Explorer
“Compared with using Model-Based Design, hand-coding the flight software would have taken longer and made collaboration more difficult. Managers and hardware subsystem engineers understand Simulink models, making it easy to achieve consensus because everyone knows what’s going on in the software.”
Challenge
Solution
Results
- Models reused for training and command verification
- Flight software seamlessly updated in orbit
- Formal code inspection process streamlined
NASA’s Lunar Atmosphere Dust Environment Explorer (LADEE) spacecraft was launched to gather information about the density, composition, and variability of the lunar dust environment. Onboard spectrometers and other instruments collected data and lunar dust that will help researchers understand the moon and other bodies in the solar system.
To develop the spacecraft’s flight software within project cost and time constraints, engineers at NASA Ames Research Center adopted a low-cost, rapid-prototyping approach supported by Model-Based Design.
“Modeling and simulating high-level spacecraft control functions in Simulink and then generating C code from the models minimized communication errors between algorithm designers and software developers,” says Dr. Karen Gundy-Burlet, LADEE flight software lead at NASA Ames. “Model-Based Design also enabled early prototyping of requirements, as well as validation and verification during the early stages of development.”
Challenge
LADEE faced several challenges during its design and mission life. First, LADEE had a wide range of possible launch trajectories. Second, the mission’s instruments required highly accurate pointing, and lunar environmental conditions would require the spacecraft to perform frequent rolling and flipping in orbit.
To address these challenges, NASA engineers wanted to simulate numerous mission scenarios and fault conditions early in the development process. To help satisfy NASA procedural requirements for software development, they needed to establish bidirectional traceability between requirements, models, tests, and test results.
Solution
NASA Ames developed the onboard flight software for the LADEE spacecraft using Model-Based Design with MATLAB® and Simulink®. Development was completed in a series of build cycles, each comprising modeling, simulation, code generation, and testing.
Working in Simulink, NASA Ames engineers developed models for the flight software, including separate models for attitude control, power management, thermal control, navigation, communications, and command processing. The team also developed a Simulink model of the LADEE spacecraft, including its propulsion system, environment, and gravity fields. These models ensured that the flight software could be developed rapidly and in a realistic setting.
Using Simulink Check™, the team verified that their models conformed to custom modeling guidelines that were derived from the MAAB (MathWorks Automotive Advisory Board) guidelines.
After running unit-level simulations in Simulink to verify that the subsystems met their requirements, the team used Simulink Coder™ and Embedded Coder® to generate more than 26,000 lines of C code from their Simulink controller models.
To catch any design errors, the engineers used Polyspace Bug Finder™ and Polyspace Code Prover™ to perform static analysis of the generated code.
With Simulink Coder they generated code from their plant model for processor-in-the-loop (PIL) and hardware-in-the-loop (HIL) testing. They integrated their controller code with NASA’s Core Flight Executive (cFE) and Core Flight System (cFS) software packages and deployed it to a Broad Reach PowerPC processor.
The team conducted numerous real-time, system-level PIL and HIL tests that included lunar orbit insertion, activation sequences, science operations, and fault management scenarios.
The team used Simulink Report Generator throughout the project to track requirements and test results for each requirement in accordance with NPR 7150 regulations.
They completed software development on schedule and in line with cost estimates.
Results
Models reused for training and command verification. “We used simulations derived from the Simulink models to train ourselves for mission operations,” says Gundy-Burlet. “In addition, we used simulations derived from our models to verify that command signals accomplished what they were intended to do with no negative unintended consequences before we sent them to the spacecraft.”
Flight software seamlessly updated in orbit. “During the mission we discovered problems with the spacecraft’s star tracker and some minor software issues,” says Gundy-Burlet. “We updated our state estimation model in Simulink to account for these problems, regenerated code, ran a targeted test suite on the new software, and uploaded it to the spacecraft, which flew for an additional month with no further defects identified.”
Formal code inspection process streamlined. “Polyspace Code Prover identified dead code in our generated code as well as issues in our handwritten code,” notes Gundy-Burlet. “It also identified code that was free from errors, and code that needed our close attention. The results enabled us to perform a targeted evaluation of the code during our formal inspection process.”
