By Lee Roop 

A software engineer evaluates the flight software and avionics configuration inside the Systems Integration Laboratory (SIL) at NASA’s Marshall Space Flight Center in Huntsville, Alabama. Engineers will soon begin integrated system testing in the SIL to support flight software development and mission readiness for Artemis II.

Fifty thousand lines of computer code broken down into smaller pieces or “modules” tested more than 2 million times – at last count. Tests continue daily with one mission: sending a spaceship with astronauts around the moon and back to Earth.

Fifty thousand lines might sound like a lot of code, NASA’s Dan Mitchell agreed. His team at the Marshall Space Flight Center in Huntsville, Ala., did the programming for Artemis I and is preparing this code for the Artemis II launch in November 2024.

But the preparations carry more weight this time – lives will be on the line because it’s the first mission with astronauts.

It might sound like a lot of code but today’s cars, especially self-driving ones, have “substantially more software than the Space Launch System. So do commercial airplanes and modern fighter jets,” Mitchell said in a recent interview.

“We have the advantage of a very well-defined mission,” Mitchell said of programmers. “It’s not an easy mission to execute, but it’s well-defined.”

Mitchell is the lead SLS integrated avionics and software engineer. He heads a team of 50 software and hardware experts at NASA Marshall’s Systems Integration Laboratory, also known as the SIL. The team also works with commercial partners like Boeing.

Simply put, the rocket has a lot of moving and stable parts including a propulsion system, launch abort system, cargo module, service module, guidance systems and crew capsule. “Flight software touches all of those,” Mitchell said.

NASA SIL
This test lab at NASA’s Marshall Space Flight Center in Huntsville simulations the shape and brain of the Space Launch System. It’s where experts test the rocket’s software for its mission maneuvers ahead.

Mitchell’s team just finished final testing of the software for Artemis II and is “in the middle of post-test analysis making sure it did, indeed, perform as expected.”

For team members like SLS computer engineer Hannah Hopkins, the feeling is irreplaceable. Her job is writing code for take off and landing simulations. With those skills, she could be working many places. Instead, she’s working with a simulation she said “can model about 40 hours before a flight through the entire core stage part of flying, so that’s about 10 minutes after launch to core stage disposal.”

That means thinking about what ground operators are doing, about tank fueling, about flight and about booster deployment. “We have to have this overall understanding of what the rocket should do and what it is doing,” she said. “Taking all of that into account.”

“Accomplishment and pride,” Hopkins said. That and the “community of software developers I work with” keep her at NASA-Marshall. “Just knowing that I’m a part of getting the first woman and the first person of color on the moon,” she said.

Hopkins knows that “the number of lines of code really in no way represents the complexity of something.” She doesn’t work on the flight software but feels “it’s kind of a source of pride that it’s 50,000 lines of code…. For me, what they’re able to accomplish with 50,000 lines of code ensures that the vehicle is not doing something overly complex.”

“There’s an old adage that says measuring progress on a software project by lines of code is like measuring an airplane by how much it weighs,” flight software design lead engineer for SLS Brian Day said.

The stakes were high for Artemis 1. A failure might have threatened NASA’s entire plan for the rocket and the return to the moon. “But putting people on this one raises the stakes quite a bit,” Day said.

When the software’s written and checked, the team takes it into test area of the SIL at Marshall. That’s a tall cylindrical structure where flight computers and connecting wires are mounted in a frame the size and shape of the Space Launch System rocket.

The engine software is then tested connected to the same software used for the real core stages, Orion capsule and ground system. “The test is to make that avionics and the software running in those boxes think it’s actually at Kennedy Space Center ready to launch and then is actually flying the vehicle when we launch,” Mitchell said.

The simulators can model 40 hours of flight and must be able to consider everything from what ground operators are doing to fueling to booster fire – “what the rocket should do and what it is doing,” as Hopkins put it. The goal is a test as much like a flight as possible.

For the first SLS launch, their simulations were very close. “We were very happy with how the simulation compared to actual launch performance,” Mitchell said. “That gave us a lot of confidence that, one, we had a really good test environment not only for flight software but for the integrated system,” Mitchell said,” but it gives us a lot of confidence going into Artemis II where we’re going to have crew on the vehicles. That was a big milestone and check mark for us.”

Not everything the team does is big. Programmers can scale down emulators (computers programmed to act like other computers) to emulate the SLS vehicle, the rocket and the capsule. Mitchell calls it “challenging but pretty fun.”

The team at Marshall could do pretty much anything in computing, Mitchell agreed. So why this? “Everybody has a different aspect that motivates them,” he said, “but it’s a grand activity, right? There’s still the mystique of being able to send vehicles and teams into space and do what we can to explore that frontier.

“It still is very much a frontier and we have as a human race not gotten off our planet yet,” Mitchell said. “So, I think it’s kind of the honor and mystery of being part of this.”

This post was originally published on this site