The Orion Spacecraft Is Headed to the Moon, with Help from the SLS Rocket
NASA’s Artemis Program Targets a Long-Term Lunar Presence
Humans have not set foot on the moon since 1972, nearly 50 years ago. But if all goes as planned, we will be back in short order. NASA is currently developing the Artemis Program, named for the Greek goddess of the hunt and the moon. The uncrewed Artemis I mission will test a new rocket, the Space Launch System (SLS). The SLS is the most powerful rocket ever built, generating 39.1 meganewtons (8.8 million pounds) of thrust.
But the SLS is only one part of the Artemis technology story. Sitting atop the SLS, which stands more than 30 stories tall, will be Orion, capable of carrying up to six people to the moon and beyond. It is designed to protect the crew from the extremes of deep space. The SLS will put the Orion into lunar orbit.
Artemis I is an important step toward moon exploration and future construction of a lunar base camp. Artemis II will repeat the journey a year later but with astronauts aboard the Orion craft. And Artemis III will carry the first woman and first person of color to the lunar surface in 2024. Future Artemis missions will build infrastructure on the moon, enabling exploration, industry, innovation, and a demonstration of capabilities that could take us to Mars.
The Greek goddess Artemis was born just ahead of her twin brother Apollo, but NASA’s Artemis is younger—and smarter—than Apollo. The computers onboard Apollo 11, which took the first humans to the moon in 1969, had 4 kilobytes of RAM. The latest iPhones have a million times as much, and the computers used to develop and run the software for Artemis have much more. And it’s not all about memory. Engineers have new suites of tools that help them work smarter, streamlining the design process.
Under the Hood
After graduating from college, Hector Hernandez joined Lockheed Martin to work on Orion. “We’re looking to establish a long-term presence on the moon,” he says, “in order to prepare us for the bigger challenge, which is going to Mars. That’s what really interests us.”
Hernandez is the lead analyst of Orion’s power system. His team uses software to model all the hardware so they can anticipate and avoid any errors. “We’re making sure that all the components connected to the system, and the system itself, can play well together,” he says.
“We’re looking to establish a long-term presence on the Moon in order to prepare us for the bigger challenge, which is going to Mars. That’s what really interests us.”Hector Hernandez, lead analyst for the NASA Orion power system
The power system includes batteries, solar panels, computers, wires, and connections (nodes). Mission success and crew survival depend on power quality—making sure all components receive voltage in the right range and avoiding significant “ripple” in the voltage. Models help the team decide the sizes of and connections between various elements. Models also help them monitor a mission and make critical decisions. If something goes wrong on the actual spacecraft, they can simulate the fault and see how the model reacts, suggesting to mission operators whether they should abort the mission or take other steps.
Hernandez also uses Simulink®, with which he’s developed a model called Spacecraft Power Capability (SPoC). He created many of the blocks in the model using Simscape Electrical™, which models the physics of electrical systems. There are blocks for batteries, solar cells, and so on. The old way of doing things was to use Microsoft® Excel® spreadsheets. Hernandez still uses those to answer some questions quickly, but they can’t model multi-node systems, where there are several cable junctions. “When we’re trying to answer more complex questions, then SPoC comes into the picture,” he says.
And, he adds, “I personally am a picture guy.” Dragging boxes around provides an intuitive feel for how everything’s connected. Simulink avoids the need to deal with a lot of low-level code. It also makes models more understandable to others and allows creators to hide certain IP within blocks. “It just keeps a lot of the dirty stuff under the hood,” Hernandez says.
So far, SPoC has passed all of its performance reviews. Its behavior matches that of the physical Orion. And whenever the team gets actual test data from Orion, they use it to tweak their model. “My next step is to get the Artemis I mission done successfully,” he says. “Then let’s move on to Artemis II.”
Fault Management Is Mission Critical for NASA
A lot can go wrong on the way to the moon. In designing SLS, the engineers and scientists at NASA created a software model to simulate the mission-critical algorithms, which monitor the spacecraft for potential faults that could prove hazardous to the equipment and eventual crew onboard.
Reliable verification of the Mission and Fault Management (M&FM) algorithms is central to mission success, according to a paper published by scientists and engineers on the SLS team. The team described their design process in the paper, “Modeling in the Stateflow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System.”
The paper states, “Preventing errors from occurring in mission (including fault) management systems is the central theme of the M&FM test team working safety-critical system algorithms for FSW [flight software] implementation for the SLS program.”
A lot can go wrong inside a rocket, including errors that can be fatal to the vehicle or the people it carries. The Artemis M&FM team’s job is to develop software algorithms for the rocket that screen for any anomalies. Then the ground control team can decide whether to, for example, halt the launch sequence or abort the entire mission.
Instead of developing and testing the algorithms on the real rocket, the Artemis M&FM team created a software simulation of the SLS called the State Analysis Model (SAM). Once they’re satisfied with the performance of their fault-monitoring algorithms on this virtual rocket, the software development team codes them in a language that they can upload to the SLS.
The team models every single avionics component. It’s an alphabet soup of components. For instance, there’s the power distribution and control unit (PDCU), a box containing electrical switches for other units, such as the redundant inertial navigation unit; the hydraulic power unit (HPU); and the TVC actuator controllers (TACs). The TACs receive electrical power from the PDCU and, in turn, hydraulically control the thrust vector control (TVC) actuators, which aim the engines. Other units control pumps and valves for the engines.
Theoretically, the M&FM team could create a detailed physics model of the whole thing, but that would run slowly. Instead, they use a model that resembles boxes connected by lines, constructed in Stateflow®. The model is called a state machine and each box represents a potential state of some aspect of the system; one box might represent when the valve is open, and another might represent it being closed. The lines represent transitions between states, triggered by specified events. Look inside a box and you’ll see some code written in MATLAB® or a graphical model in Simulink software describing the state and passing that information on to other components.
The Stateflow diagram describes the logic of the system. Stateflow and Simulink models both resemble boxes connected by lines but act at different levels. “Let’s say you’re walking down the street and you get to an intersection,” says Ossi Saarela, the space segment manager at MathWorks. “Stateflow will decide whether you walk right or left, and Simulink will help you keep your balance.”
The team also has a physics-based model, System Integration Lab (SIL). According to the NASA paper, “The SIL is a high-fidelity testbed, integrating the actual flight software with a mix of real and simulated SLS hardware and environments.”
But the M&FM team needs both types of models. SIL has the same software and avionics boxes as the rocket and even the same cabling at the same length, so it has much higher fidelity. By comparing the models, they can use SIL’s outputs to improve SAM.
The M&FM team had to figure out the right scripts to optimize SAM for speed. They needed to decide which tests cases to try and how to determine whether the system passed. Now they can iterate so quickly on SAM that it acts as a “crystal ball,” telling them what to expect from SIL. The paper states that SAM takes approximately 120 seconds to execute a run of a candidate mission launch profile on a standard PC. After running many tests and passing several milestones, the team found that, in most cases, SAM’s results closely match SIL’s.
Another epic event was hot-fire testing, in which NASA ties the rocket to the ground and lights its engines.
“When those engines light, you can feel them from miles away,” says Saarela. “There is a tremendous amount of power being released and being able to predict the exact behavior of every component ahead of time is key.”
What the team has learned can be applied elsewhere, as there are many exciting programs on the horizon for NASA.
“New designs like Artemis’ Human Landing System or even the Mars Ascent Vehicle rocket will surely benefit from new tools and processes being used on SLS,” says Saarela. “Aerospace engineering is in a period of rapid evolution.”
Autopilot for a Spacecraft
NASA uses software models not only to test algorithms and to simulate hardware but also to generate actual code for the crew capsule. Guidance, navigation, and control (GNC) is basically the autopilot for a spacecraft, integrating sensor data and planning its trajectory. It used to be that GNC designers would write up the requirements, which software engineers would use to write final code. The new method is to use Model-Based Design. Instead of writing static specifications, the designers build an executable model, so they can test it and iterate quickly. Software then automatically translates the algorithms in that model into final code.
Orion’s GNC designers use Simulink. They can plug the Simulink model into Trick, NASA’s high-fidelity software simulation of the spacecraft and the physics that defines its movement through space. Once they’re happy with the model, Embedded Coder® produces the control code in C++, which they can also plug into Trick. MATLAB can check the Simulink model and the C++ code to make sure they do exactly the same thing. The C++ code will then be loaded onto the spacecraft.
Model-Based Design saves time because people don’t need to manually write and rewrite the code as they develop the algorithms. It also reduces low-level coding errors. And it makes the algorithms easier to inspect. Computers are now smart enough to fly rockets—and write the code that’s smart enough to fly rockets.
With Model-Based Design, instead of writing static specifications, the designers build an executable model, then software automatically translates the algorithms in that model into final code.
According to NASA, “With Artemis missions, NASA will land the first woman and first person of color on the moon, using innovative technologies to explore more of the lunar surface than ever before. We will collaborate with commercial and international partners and establish the first long-term presence on the moon. Then, we will use what we learn on and around the moon to take the next giant leap: sending the first astronauts to Mars.”
To the moon!
Published November 2022