Following completion of certification testing in October 2020 of the computer system for the first launch of NASA’s Space Launch System (SLS) rocket, teams are now working on upgrades for future flights and vehicle configurations. The first SLS vehicle will be assembled at the Kennedy Space Center (KSC) in Florida later this year, and a critical set of checkouts of the new rocket with its Orion spacecraft payload will be performed to verify that Artemis 1 is ready to launch.
The SLS Program continues to test Release 14 of the vehicle’s flight software to support the upcoming Artemis 1 Integrated Test and Checkout in the Vehicle Assembly Building (VAB) at KSC, while also working on future software releases. Release 15 will support Artemis 2 and future Block 1 missions and be followed by Release 16, which will run the evolved computer architecture for the Exploration Upper Stage and the SLS Block 1B vehicle.
SLS computer testing completed for Artemis 1 flight certification
Integrated testing of the SLS computer system for the program’s first launch on the Artemis 1 lunar orbit mission was completed last October. “We completed a really significant milestone back in October which was completion of testing to support design certification in our systems lab,” Dan Mitchell, NASA’s Technical Lead for SLS avionics and software engineering, said.
“That provided the best data evidence to substantiate closure of the Integrated Avionics and Software system requirements, which are being reviewed right now as a part of the review period five series of design cert reviews. And that testing went very well.”
Certification testing involved all of the computers within the SLS Boosters and Core Stage and the flight software developed by NASA at the SLS Program’s Marshall Space Flight Center home in Huntsville, Alabama. A full set of the dozens of avionics boxes deployed through the SLS vehicle elements is set up in the Avionics and Software Systems Integration Lab (SIL) at Marshall.
Integrated testing of the vehicle’s computers for overall certification follows earlier rounds of element and subsystem computer testing all the way down to the individual avionics boxes. “There’s kind of two steps to it,” Mitchell explained.
“Each avionics box has its own specifications that it has to meet: electrical specifications, functional specifications, and environmental specifications. So the typical process is each box will go through its own set of qualification tests to show that it meets those electrical, functional, and environmental requirements.”
“But often, and typically in parallel, we’re also doing integrated testing of those boxes either as a part of the development phase or ultimately as a part of our final design certification phase. And we do that end-to-end integrated testing in the SIL,” he added.
“What we’re doing in the SIL is we’re trying to show: one, that all these avionics boxes, as integrated together, are all electrically compatible,” Mitchell said. “[Two]: when flight software is running on the flight computers and commanding and getting data from those boxes that the integrated system is performing properly, both from a nominal perspective and an off-nominal perspective.”
“[For] flight software, there’s some analogies there as well,” he added. “We do our flight software development and our flight software formal qualification testing in separate software development facility labs, and it’s in those labs where we test the flight software against all the requirements. And we can run hundreds of thousands of tests against the flight software in that environment.”
Credit: NASA.
(Photo Caption: Some of the computer labs at Marshall Space Flight Center supporting SLS avionics and software development and testing. The large, semicircle Software Integration Testing Facility rings hold separate sets of the dozens of Core Stage computers. Additional rings hold the computers that fly inside the Solid Rocket Boosters and another one will be set up to hold the avionics in the new Exploration Upper Stage.)
“So once we get it into that broader, integrated environment, you kind of neck down the flexibility of how much testing you can do. So we’re very intentional about the tests that we perform in the SIL of the integrated system. For example, in the SIL, to support all the design cert activities, we had 72 test cases that we ran that provided evidence to support closure of about 120 design verification objectives.”
After several years of development, Release 14 of the SLS flight software is the version that will fly Artemis 1.
The Core Stage Green Run design verification campaign at the Stennis Space Center provided another environment to evaluate the performance of the computer systems integrated in the SLS Program’s first working Core. A derivative of the Flight Computer Application Software (FCAS) is used in the Stennis test campaign. Called Green Run Application Software (GRAS), it accounts for the differences between in-flight navigation and control and a static firing of the stage.
“Boeing put together the whole test campaign,” Mitchell noted. “It was really an incremental approach to try to prove out the integration [and] functionality of the stage, including avionics and software. And I’ll frankly say, from an avionics and software perspective, it went very well.”
“Back in the late summer, early fall time-frame, we did uncover a couple of changes that we needed to make within the Green Run software that we’ll apply to flight, just some minor timing tweaks that need to be made. But overall, I’m very pleased with how, from an avionics and software perspective, things have performed down at Stennis.”
The Hot-Fire test that culminates the Stage’s Green Run campaign provides a very high-fidelity test of the vehicle operating under launch and flight conditions while held in place in the B-2 Test Stand at Stennis. Although the first attempt on January 16 ended early and will be repeated to satisfy more test objectives, the stage and its computer system demonstrated its independent ability to finish a launch countdown, fire its engines, and shut them down as required.
Credit: NASA/Tyler Martin.
(Photo Caption: The development ring of the SIL/Software Integration Testing Facility at Marshall Space Flight Center as configured with Core Stage avionics for integrated avionics and software verification and validation testing. “Run for record” testing was completed there last October to support the design certification of the SLS vehicle before its first launch on Artemis 1.)
“What’s interesting is that when you look at and understand all the interactions that need to happen in between the Stage Controller [ground computers] and the test stand and the Stage Controller and stage working through the Green Run Application Software to configure the stage so that it can become a self-contained entity, is how seamlessly that worked,” Mitchell said. “There’s hundreds of activities that happened during those last four minutes to get to T0, and I couldn’t be more pleased with how that whole integrated system performed.”
The SIL is continuing to provide support for the Green Run campaign until the test cases are completed, with one “ring” configured with a set of the Core Stage computers. In parallel, a full-vehicle set of SLS computers that was used to complete the integrated certification is now being set up to support final pre-launch Artemis 1 testing at the Kennedy Space Center later this year.
After the Artemis 1 vehicle is fully assembled, a detailed set of tests will be performed with the first-ever combination of an Orion spacecraft and SLS rocket. With a full Orion/SLS vehicle assembled for the first time on Mobile Launcher 1 in the VAB, the Integrated Test and Checkout (ITCO) will make sure that the different computer systems interoperate with each other and with the ground control computer system that will be in charge of launch countdown activities.
“What we’re doing right now is we’ve reconfigured the SIL to integrate with the TVC (Thrust Vector Control) lab next door, and we’re doing a series of validation tests that should wrap up in the mid- to late-February timeframe,” Mitchell said. “That’s going to provide some validation to support readiness for ITCO activities at KSC, and it’s also going to support demonstration of an important engineering test that we’ll do on the integrated vehicle.”
Mitchell noted that one of the activities during ITCO is an end-to-end polarity test. “[It tests from the] navigation sensor through flight software through avionics boxes down to the TVC actuators,” he said. “We want to assure that if the vehicle is supposed to turn right, it does turn right [and] we see the TVC actuator deflections in the appropriate direction to execute that a maneuver like that.”
The labs at Marshall are currently running through that checkout before the test on the Artemis 1 vehicle in the VAB. To do this, separate units of the stage’s redundant inertial navigation unit (RINU) and rate gyroscope assemblies (RGA) were mounted to a movable platform in the computer lab. “We’ve installed a small tilt table in the lab so we can physically rotate and move the RINU and the RGA and see those physical motions, how they propagate through the software and the avionics, and to both Booster and Core Stage TVC actuators in the lab next door,” Mitchell noted.
SLS’s flight software steers the Solid Rocket Boosters and four RS-25 to maintain the proper launch trajectory and pitch profile during the initial phase of flight of Artemis 1. (Credit: Mack Crawford for NSF/L2)
For the vehicle on the launch platform in the VAB, the gyroscopes and navigation unit will sense the Earth’s rotation. “We will allow the rocket to sense Earth rate, you know just moving along with the Earth, and as the RINU senses that motion, you’ll start seeing movement on the TVC actuators,” Mitchell said.
“That gives you a good indication that you’ve got everything wired up on the rocket correctly, right? You want to make sure when the rocket physically senses the motion, it tries to correct that error or motion by moving the TVC actuators in the right direction.”
Artemis 2 development updates
In parallel with supporting pre-launch testing and certification for Artemis 1, the SLS program has started working on updates to the launch vehicle’s flight software for Artemis 2, which will be the first SLS launch with a crew. For Artemis 2, the SLS flight software moves to Release 15.
“We’re going to do three sub-releases within Release 15, and we’re working on that first release right now which will be 15.0,” Mitchell explained. “We are on track to have it complete approximately in the May timeframe.” In addition to updating the vehicle flight software, the software that runs the test and simulation environment is also being updated in parallel.
Not to be confused with the overall Artemis Program, simulation software called “Advanced Real-Time Environment for Modeling, Integration, and Simulation,” or ARTEMIS, stands in for the rest of the rocket systems from engines to tanks to sensors. The ARTEMIS software also emulates environmental factors that play roles in launches, like gravity, wind, and temperature.
“We’re in the process of also updating ARTEMIS to be consistent with a few changes that are happening between Artemis 1 and Artemis 2,” Mitchell said. The ARTEMIS updates will allow a new set of SLS emulators to be released for the independent software development of the other Exploration Systems Development division programs, Exploration Ground Systems (EGS) and Orion.
Credit: Philip Sloss for NSF.
(Photo Caption: Units of the three primary SLS flight computers and the RINU in the SIL at Marshall. For the first three SLS launches, the units are positioned around the top of the Core Stage; however, when the vehicle evolves to its Block 1B configuration, these units will move up and fly with the Exploration Upper Stage to perform a longer mission profile.)
“We’ll be providing them our first set of Artemis 2 releases early this summer to support their activities,” Mitchell noted. Other groups, such as the Flight Operations Directorate, need updated emulators as they gear up to begin training flight control teams and eventually the Artemis 2 flight crew before the mission.
Subsequent Release 15 version updates will follow version 15.0. “And then we’ll quickly follow-on with the second release,” Mitchell said. “Some of the key things that we’ll do there is, we should integrate with the Vehicle Management folks.”
“I think [that release has] the near-final set of GN&C (Guidance Navigation & Control) algorithms and parameters for Artemis 2 [and] will include some tweaks to abort logic and abort triggers. We’ve learned some lessons going through the Artemis 1 activity that we’re going to take advantage of in Artemis 2.”
“And then we have a third software release to catch any final GN&C updates. But also importantly, that’s the release that we can take advantage of any lessons learned and tweaks that we need to make based on the results of the Artemis 1 flight,” he added.
Software architectural design and development for Block 1B/EUS
Groundwork for Release 16 is also underway, which will see SLS avionics and software expand to include the in-house Exploration Upper Stage (EUS) that will fly with the Block 1B configuration. “For Block 1B, Artemis 4, which will be Release 16, the team is in the software architecture development phase,” Mitchell said.
The upper stage for the first three SLS launches is a commercial, off-the-shelf rocket provided and modified by United Launch Alliance for NASA. The Interim Cryogenic Propulsion Stage (ICPS) used in the SLS Block 1 configuration is a slightly-modified Delta IV upper stage that operates much like a payload, with independent computers, navigation, and software.
Larger than a baseball infield and powered by locomotive engines, the massive crawlers have carried rockets and spacecraft to the launch pad at @NASAKennedy for more than 50 years. Soon, one will carry the #Artemis I SLS and @NASA_Orion too. LISTEN >> https://t.co/67ZQt1H0bP pic.twitter.com/dyC1yHD9Cc
— NASA_SLS (@NASA_SLS) February 4, 2021
All the SLS computers and software ride in the Boosters and Core Stage on Block 1, but for Block 1B, the flight computers and navigation unit will move up from the top of the Core Stage onto the EUS. The flight software and computers will now have an hours long mission to command and control instead of just an eight-minute long mission.
“With moving the flight computers up into the upper stage and including the avionics components that are part of the upper stage, we’re modifying the architecture and providing the capabilities to support [Flight Operations Directorate] in mission planning and execution,” Mitchell noted.
Most of the dozens of other avionics units in the SLS Boosters and Core Stage will remain in place, but the flight computers and software will fly not just the launch and orbit insertion, but also burns to take Orion and other payloads beyond low Earth orbit.
Along with the computers moving up from the top of the Core Stage, the EUS will have its own specialized avionics. “There’s a new box that Boeing is developing specifically for upper stage MPS (Main Propulsion System) and engine control,” Mitchell said. That avionics box is called the Engine and Propulsion Integrated Controller, or EPIC.
“It’ll be the avionics component, for example, that interfaces with the RL10 engines, and it’ll be how flight software commands the engines to start and stop as well as the propellant utilization control as well.” EUS will be powered by four RL10 engines as opposed to the single RL10 that powers ICPS.
As Release 16 development and testing ramps up, additional hardware is being planned for the SIL to support eventual integrated testing of the expanded SLS computer system for Block 1B. “We’ve begun initial activities to build two rings to include the upper stage avionics so that we can do integrated testing of the upper stage and then be able to tie that upper stage ring with the Core Stage and the Boosters so that we can do end-to-end avionics and software testing for Artemis 4 as we get closer to mission time,” Mitchell said.
Lead image credit: Mack Crawford for NSF.