Aiming Parker Solar Probe at the Sun with Simulink GNC Software
By Greg Drayer Andrade, MathWorks
On Monday, November 5, 2018, Parker Solar Probe (PSP) reached its first perihelion, passing closer to the Sun's surface than any spacecraft had done before (Figure 1). Even at a top speed of about 213,200 miles per hour, it would take the spacecraft several days to pass behind the Sun and emerge on the other side. During this time, researchers and engineers at NASA and at Johns Hopkins University Applied Physics Laboratory (JHU APL) waited anxiously for the first status beacon. On Wednesday, November 7, the signal was received: Parker Solar Probe was operating at status “A,” with all scientific instruments running and gathering data.
Figure 1. Artist’s rendition of the Parker Solar Probe approaching the Sun. Image courtesy JHU APL.
Just under two weeks later, Parker Solar Probe reestablished full contact. As each subsystem was polled for its status, the APL teams’ excitement grew. The science recorders had filled as expected, the spacecraft had maintained its attitude, and it was on the right trajectory. Over its nearly seven-year mission, Parker Solar Probe will orbit the Sun 24 times, coming gradually closer after each of seven Venus gravity-assist flybys until it passes within 3.83 million miles, close enough to fly through the Sun’s atmosphere (Figure 2).
Confirmation that Parker Solar Probe had made first contact with the Sun was especially welcome news for the guidance, navigation, and control (GNC) team at JHU APL, which was responsible for developing the spacecraft’s attitude control algorithms. Designed, implemented, and verified using Simulink®, these algorithms are mission-critical: they not only control the orientation of the spacecraft, they also keep its carbon-composite thermal protection system (TPS) pointed toward the Sun. A one- or two-degree deviation in orienting the TPS can mean the difference between a successful mission and destruction of the spacecraft.
Figure 2. Graphs showing the Parker Solar Probe mission’s planned path and solar approach distances. Image courtesy JHU APL.
Guidance and Control Design Constraints
In orbiting the Sun, Parker Solar Probe would be subjected to heat 475 times more intense than it would experience in an orbit of Earth. This meant that the attitude control system had to orient Parker Solar Probe so that it was continuously protected by the TPS.
Since the Sun is the biggest and brightest object in the solar system, at first it might seem simple to keep a spacecraft oriented toward it. In practice, however, attitude control for Parker Solar Probe is quite complex. One challenge is that near perihelion, none of the sensors that provide input data for the attitude control algorithms are actually pointed at the Sun. Instead, they are positioned behind the TPS to protect them from solar thermal radiation (Figure 3).
Figure 3. The Parker Solar Probe. Image courtesy JHU APL.
Two star trackers pointed away from the Sun can be used to gauge orientation from the positions of stars, but the design team had to plan for the possibility that these sensors would be unusable near perihelion. The spacecraft is equipped with two Digital Sun Sensors (DSS), but they can only be used far from the Sun. The Solar Limb Sensors (SLS) are designed for close-range use, but they only detect the edge of the Sun when the spacecraft begins to rotate away from its ideal attitude. To develop a single fault-tolerant system for each segment of the orbit, it was vital to ensure that sufficient hardware was placed on the vehicle and incorporated into the control algorithms.
A second challenge was that the control algorithms had to make attitude corrections using as little electric power and thruster propellant as possible. Close to the Sun, Parker Solar Probe’s solar panels remain almost entirely within the TPS shadow so that they do not melt. Extending the panels increases the pressure exerted on them, resulting in unwanted torque. Further, fuel for the spacecraft thrusters had to be used sparingly to ensure that supplies would last through the years-long mission.
Developing a Truth Model
The “truth” model for the spacecraft, built in MATLAB®, Simulink, and Simscape Multibody™, is essentially a plant model that captures orbital effects, physical interactions, and other spacecraft dynamics (Figure 4).
Figure 4. The Parker Solar Probe plant model, which consisted of nearly 1400 blocks and 1811 lines of MATLAB code.
Over time, many subsystems were incorporated into the model, including the battery subsystem, the thrusters, the star trackers, and the inertial measurement unit. The team also modeled the physical joints between the solar arrays and the main bus. As the model became more sophisticated, they were able to run increasingly accurate simulations. For example, they added a subsystem that models the effect of propellant slosh on spacecraft dynamics.
Developing GNC Flight Software
The initial attitude control system design did not include reaction wheels. Using only thrusters to manage momentum and make attitude corrections was one possible way to reduce mass and power consumption. To test the feasibility of this approach, the GNC team modeled several controller designs, including one with a pulse-width pulse-frequency modulator, and ran closed-loop simulations with the truth model. While the controller designs looked promising, there was no guarantee that the mission could be completed without the addition of reaction wheels. Fortunately, as the design matured, the team was able to make room for reaction wheels. This greatly simplified the overall design and allowed for improved accuracy and stability for scientific observations.
They created a system that non-propulsively manages momentum via the reaction wheels and fires thrusters to dump momentum when the wheels reach a specified level. They reused much of the work from the thruster-only Simulink model in the redesigned controller. Altogether, the controller model included more than 22,000 blocks and almost 1200 lines of MATLAB code (Figure 5).
Figure 5. Controller model.
Because of the unforgiving environment that Parker Solar Probe would be operating in, an unprecedented number of simulations were performed. In fact, the number of formal simulations was increased by more than an order of magnitude compared with the previous mission led by JHU APL. Simulations covered both normal operating scenarios, including momentum dumps and trajectory correction maneuvers, and fault scenarios.
Most spacecraft are designed as fault-tolerant systems, but for this mission, solar conditions were more extreme than any previous spacecraft had experienced. For example, losing a star tracker on a spacecraft is considered a serious fault, but for Parker Solar Probe, it was necessary to plan for the likelihood that not just one but both star trackers could be blinded by a solar event and that additional faults could occur at the same time.
Code Generation and Test-Bed Verification
Initial verification of the controller design was performed via closed-loop simulations in Simulink. After generating code from the controller model using Simulink Coder™, the team ran software-in-the-loop (SIL) simulations in which the control model was replaced with the generated code.
After SIL testing and code optimization, the control design was verified on the JHU APL test bed (Figure 6). For this stage, code generated from the Simulink attitude control model was handed off to the flight software group, who incorporated it into the Parker Solar Probe flight software. The team also delivered code from the truth model to the test bed group, who integrated it with the test bed that emulates Parker Solar Probe hardware. Acceptance tests of the flight software were then conducted on the test bed. Closer to launch, more of the emulated components in the test bed were replaced with actual hardware components integrated on the spacecraft; for example, emulated reaction wheels were replaced with real ones.
Figure 6. The JHU APL test bed. Image courtesy JHU APL.
Making In-Mission Adjustments
On Sunday, August 12, 2018, Parker Solar Probe was launched with a Delta IV Heavy rocket from Cape Canaveral Air Force Station, Florida (Figure 7). In addition to relaying scientific data back to Earth, the spacecraft is sending telemetry data, which our team analyzes and compares with simulation results in Simulink. They have already refined and calibrated our truth model based on these comparisons.
Figure 7. Parker Solar Probe launch. Image courtesy JHU APL.
The spacecraft, including the attitude control system, was designed to operate autonomously, in part because it can take more than 15 minutes for radio signals to reach it from Earth. Nevertheless, there are three ways to make in-mission adjustments: send commands to execute preplanned maneuvers or actions, modify flight software parameters, or update the flight software itself. Since launch, the team has performed two software updates that incorporate improvements that were verified using the updated truth model.
As the mission continues, Parker Solar Probe orbits will become tighter and the time between orbits shorter. The APL team is developing MATLAB automation tools that will enable them to rapidly analyze new data from the spacecraft and respond quickly enough to make any needed changes before the next flyby. The control software has been performing very well—in fact, it has far exceeded expectations.
Published 2020
