NASA flight software for SLS navigates through clean first launch


The NASA-developed flight software for the agency’s Space Launch System (SLS) vehicle successfully flew the program’s first launch on the Artemis I mission on Nov. 16. The vehicle’s Integrated Avionics and Software conducted the final countdown and first eight minutes of launch, commanding the Core Stage, RS-25 engines, and Solid Rocket Boosters (SRB) to orbital insertion.

The launch-to-orbit insertion was nominal, and no faults were seen with vehicle hardware or software during real-time quick looks and initial post-launch data evaluation. The flight software team will incorporate any lessons learned from a longer, more detailed performance review, and the team is already testing new releases that will fly on Artemis II and eventually —with the new Block 1B vehicle — on Artemis IV.

Flight Performance Was Right Down the Middle, Looked Like a Simulation

The flight software performed nominally during the first SLS launch on Artemis I, observing the same clean behavior from the vehicle hardware during the eight-minute ride to orbit insertion early on November 16. “It performed extremely well, just as we had tested it,” Shaun Phillips, NASA’s Technical Lead for the SLS Flight Software project, said in a Nov. 30 interview with NASASpaceflight. “My team’s overall response right after we flew was it looked just like our sims (simulations), the sim data, that’s how clean it was.”

“That was a common comment from a lot of folks,” Dan Mitchell, NASA’s Technical Lead for SLS Integrated Avionics and Software, added during the interview. “It looked just like the sims, which is a good testimony to our test team because we used the data from some of our [computer lab] tests as data used during our training activities.”

“The overall performance, we couldn’t have asked for it to be cleaner,” Phillips said. “It was down the middle of the road of predictions, and even during initial data evaluation, that’s still looking just like that.”

“We do have the flight software team that is supporting the mission and monitoring telemetry throughout pre-launch and ascent. Our software didn’t pick up any avionics issues, any hardware issues during the flight.”

(Photo Caption: A graphic from a U.S. Government Accounting Office 2014 report distinguishing the new developments for the initial SLS version that first flew on Artemis I. Along with passive adapters connecting the SLS stages and Orion spacecraft, the Core Stage was the brand-new element, including new flight computers and software. The SLS Core Stage’s Design, Development, Testing, and Evaluation (DDT&E) paced the schedule in the decade-long effort to achieve the first SLS launch.)

On the Block 1 vehicle, three identical flight computers located at the top of the Core Stage run the SLS Flight Computer Application Software (FCAS).  The three computers run together as a single-fault tolerant Flight Computer Operating Group (FCOG), controlling the systems on the Core Stage and Solid Rocket Boosters.

Developed by NASA’s SLS Program at the Marshall Space Flight Center in Huntsville, Alabama, FCAS is responsible for the first few minutes of the launch from just before liftoff through Earth orbit insertion.  During the launch countdown, the flight software carries out vehicle launch preparations as commanded by the Exploration Ground Systems (EGS) Ground Launch Sequencer (GLS) software.

While the vehicle’s liquid stages were being loaded with propellant, the Day-Of-Launch I-Load Update (DOLILU) was performed based on weather data to characterize the wind vs. altitude patterns. “The DOLILU process was only partially performed for the first two attempts due to the processing delays and ultimate launch scrubs,” Mitchell noted. “The DOLILU process for the third attempt was nominal.”

See Also

Artemis 1 UpdatesSLS Forum SectionL2 SLS SectionClick here to Join L2

GLS orchestrates vehicle and ground system activities during the countdown until T-33 seconds when vehicle authority is turned over to the SLS to launch itself into orbit. At T-30 seconds, the flight software begins the Autonomous Launch Sequence (ALS).

“ALS is a mode in the flight software,” Mitchell said. “At T-33 seconds, the ground provides flight software the ‘Go for ALS’ command and as a part of that, it includes the launch time, and then flight software takes that and executes the activities from T-30 seconds down to T-0.”

“The transition from GLS to ALS was smooth, and all ALS functions were performed without issue,” he added.

In ALS, the flight software starts the remaining vehicle systems, like the SRB hydraulic power units, and enforces all vehicle Launch Commit Criteria to ensure that the vehicle systems are ready for ignition and launch. In the last few seconds of the countdown, it arms the SRB ignition systems and commands the four RS-25 engines on the Core Stage to start.

On Nov. 16, everything finally came together on Pad 39B: the Core Stage engines started nominally, and the flight software began the Artemis I mission by sending the commands to fire the twin Solid Rocket Boosters and entering into flight mode. “When flight software sends the FIRE2 command to the Boosters, that’s the definition of T-0 for the vehicle, and flight software transitions into ‘Core Stage Flight with Boosters’ mode,” Mitchell noted.

“That’s the open loop guidance phase of the flight and lasts until Booster separation, and then it transitions to ‘Core Stage Flight’ [mode]. Right after Booster separation is when PEG becomes closed-loop, it converges on a target trajectory — and that did happen shortly after Booster separation — and we used guidance to fly us to a MECO point.”

PEG stands for the Powered Explicit Guidance algorithm used as a part of the vehicle’s Guidance, Navigation, and Control (GN&C) software functionality. “And then we transition to the final phases as we go through disposal steps after MECO, we go into what’s called ‘Core Stage Disposal’ [mode],” Phillips added.

About 16 seconds after Main Engine Cutoff (MECO), the Interim Cryogenic Propulsion Stage (ICPS) second stage of SLS separates from the Core Stage and Launch Vehicle Stage Adapter (LVSA), carrying Orion with it first to a stable parking orbit and then later to the Moon.

Artemis I lifts off early on the morning of November 16. (Credit: Stephen Marr for NSF)

CPS is largely a commercial off-the-shelf (COTS) upper stage with some SLS customizations. Developed by United Launch Alliance (ULA) co-founder Boeing in the latter half of the 1990s as the upper stage for the Delta 4 launch vehicle, ICPS has its own ULA-managed flight and navigation systems and software, and after separation from the Core Stage and LVSA, ICPS was in control of Artemis I.

The Core Stage was the major new development for the SLS Program from its inception in 2011, with the rest of the SLS Block 1 vehicle using already-flown or already-upgraded Space Shuttle engines and Solid Rocket Boosters. Core Stage systems performed an eight-minute long, high-fidelity simulated flight during the Green Run Hot-Fire test in March 2021 at Stennis Space Center in Mississippi.

Performing essentially a full “duty cycle” in a static test allowed a series of stress tests to be performed on the stage’s mechanical systems during the Hot-Fire test and also allowed the flight article to be recycled by the SLS program for its first launch.

SLS development followed a more traditional process, and the vehicle design is much closer to a finished product than the other super-heavy launch vehicle system being developed, SpaceX’s Starship. The Artemis I launch was a test flight, but SLS delivered full performance to its primary payload, NASA’s Orion human-rated spacecraft; Orion required a trans-lunar trajectory in order to test all of its planned mission objectives.

The Artemis I launch was the first flight for the fully integrated vehicle; in addition to the Core Stage systems, the full vehicle incorporated SRB systems, and the launch exercised the GN&C systems and software in-flight for the first time. SLS flew its inaugural launch with Release 14.2.9 of FCAS, which Mitch noted was loaded on the flight computers in August 2021 and included three updates “based on Green Run findings, the Flight Readiness Analysis Cycle [in] summer 2021 to refine vehicle performance, and to capture the as-stacked alignment of the RINU.” The RINU is the vehicle’s Redundant Inertial Navigation Unit.

The Artemis I vehicle executes its roll program shortly after lifting off on November 16. (Credit: Stephen Marr for NSF)

“”The mission execution was nominal, and there were no fault management or fault recovering actions that flight software had to perform,” Mitchell said. “They’re still combing through the data, but all indications are based on the tools that we’re using to analyze the data was that it was a very, very nominal mission for flight software as well as all the other systems and subsystems.”

“The avionics system performed with no issues, we didn’t lose any redundancy, and there were no noted out-of-tolerance items in any of the health and status data that we collect from the various avionics components on Core Stage, Booster, or Engines,” he noted.

“We also had really good closed-loop control of the ullage pressures in the [Core Stage] LH2 and LO2 tanks,” Phillips said. “Flight software is controlling that. We pick that up late in the countdown under ALS.”

The flight software was also running its abort logic in a monitor-only mode for the first launch. “It performed very well, there was nothing even close to the limits, and they’re using that data to finalize the inputs for Artemis II,” Phillips said. “The flight software team gets the thresholds from the GN&C team as a part of their analysis, but it was very good.”

“Attitude rates are some of the key abort triggers but also health and status of some of the critical avionics components,” Mitchell added.

There were no unplanned attitude deviations noted during the ascent to orbit. As a part of its first launch, the heavily instrumented vehicle did execute a set of small magnitude “programmed test input” (PTI) maneuvers to measure the rocket’s dynamic response in flight.

“There were five planned PTIs for the mission,” Mitchell noted. “The PTI maneuver around Max-Q was removed late last year due to a structural concern with the Orion, but the other four PTIs were executed per the timeline plan, and you can definitely see that response from the vehicle looking at the data.”

“Our GN&C and structures team are looking at that data to ferret out what the overall integrated stack response to those maneuvers were, so those are details that will be coming out over the course of the next couple of months as they do that detailed analysis. PTIs introduce rate errors into the system, but they are very small and well below what our [abort] trigger thresholds are.”

Possible Fine-Tuning for Future Launches

NASA will be looking into some fine-tuning for future flights. The SRBs and Core Stage delivered almost perfect performance, with MECO of the Core Stage reaching an orbit of 30 x 1,800.1 km, versus a predicted orbit of 30 x 1805.7 km.

“We did note that MECO occurred forty-milliseconds, which is two flight software processing frames, earlier than predicted,” Mitchell said.  “The way [NASA SLS Chief Engineer Dr. John Blevins] characterized it is that MECO insertion velocity was, he says 99.974 percent accurate, which is correct. Apogee was a bit low, but even that, do the math, it was 99.64 percent accurate.”

Before launch, MECO was predicted at a Mission Elapsed Time (MET) of 8 minutes, 3 seconds; with the four RS-25 engines starting in close succession a little over six seconds before liftoff at T0, that would have given a total run-time of about 489 seconds. Under the agency’s implementation of U.S. export control regulations, NASA is keeping the actual MECO time a secret.

(Photo Caption: Circled in red, the SLS Core Stage is seen off in the distance from one of the Orion solar array wing cameras in Earth orbit on Nov. 16. The SLS Core Stage completed Earth orbit insertion and coasted up to an apogee of 1800 km along with the ICPS second stage and Orion spacecraft. ICPS made a short perigee raise maneuver burn to bring the perigee up from 30 km to 185 km, while the Core Stage remained on its planned disposal trajectory that traveled almost once around the world before re-entry and disintegration over the Pacific Ocean between Hawaii and the U.S. West Coast almost two hours after launch.)

The velocity at MECO was 2.1 meters per second (7 feet per second) lower than predicted.

As noted earlier, after SRB separation, the SLS flight control system goes to closed-loop guidance, converging on a MECO target. As the vehicle approaches MECO, the four RS-25 engines have already been throttled back to maintain maximum acceleration limits.

With velocity climbing quickly in the seconds before engine shutdown at peak acceleration, the guidance system starts to protect against oversteering.  A few seconds before MECO, the engines are commanded to their minimum throttle setting.

The GN&C routines take all of this into account in calculating the moment to send the MECO command to the Core Stage engines, including the time it takes for the tail-off in the engine thrust from the time of the command until “zero-thrust.”

The slight difference in the timing of the actual command versus the pre-flight prediction was well within margins, but it is something that will be looked at as a part of the post-flight analysis process. “They’ll look at how can we tune the trajectory, try to buy back even that small amount of error, get as close to a hundred percent on those two key items of insertion velocity and apogee,” Mitchell said.

Following ICPS separation, the Core Stage no longer has any propulsion or attitude control, but it did continue to have battery power for a few minutes and continued to downlink data to a ground station in Bermuda while within range. There were a couple of data dropouts during that post-MECO time period that interrupted some of the data transfer from the stage to the ground.

“We did experience some dropouts of data from the Bermuda ground station after MECO,” Mitchell said. “[The Bermuda ground station] had to do apparently some reconfiguration on the fly, so there were some dropouts between about T+508 seconds to T+534 seconds, and I think the longest dropout was about 15 seconds in duration.”

“That did impact some of the high downlink of some of the high-resolution imagery of ICPS and the Core Stage separation, but we did receive the low-resolution video of that separation. They’re still doing that imagery analysis, but it looks like, indications are we’ll get everything we need from the low-res imagery to validate separation clearances.”

“We had some imagery that was considered bonus imagery; we were able to get that bonus imagery, and we were able to get telemetry all the way to loss of signal with the Bermuda ground station. That was about T+789 seconds,” Mitchell added.

The Core Stage systems continued to operate as it lost contact with Bermuda; NASA did not require or have any assets downrange to extend communications for longer. “We don’t power down the vehicle, we just let it run to depletion of the battery,” Mitchell said.

“Flight software [does] monitors the voltage input to the RF transmitters, and when it gets below a certain voltage level, we will turn off those transmitters. It’s an agreement we have with the spectrum management folks; we don’t want those transmitters to start ‘babbling.’ We don’t know when that happened because we lost lock with Bermuda before it got to that point.”

The Core Stage and LVSA continued on the same trajectory as the Orion-ICPS mated stack all the way up to the 1800 km apogee about 50 minutes after liftoff; at that point, the ICPS performed a short burn to raise perigee to 185 km. They re-entered over the Pacific Ocean between Hawaii and the U.S. West Coast around 1 hour and 45 minutes after liftoff.

Future Flight Software Development/Testing

In parallel with the final preparations for launch of Artemis I in 2021 and 2022, the avionics and software groups at Marshall continue testing the version of SLS flight software that will fly on Artemis II. “We’re preparing [to test] our final version, which is 15.2.1, in the Spring,” Phillips said. “We could have some post Artemis I updates, but right now we haven’t identified anything.”

“We completed what we hope is the final code updates for Artemis II back in the Summer time-frame,” Mitchell added. “The team is right now putting together the final scope of the remaining formal qualification test activities for that flight software for Artemis II.”

Credit: Philip Sloss for NSF.

(Photo Caption: Units of the three SLS flight computers and the RINU in the Avionics and Software Systems Integration Lab at Marshall Space Flight Center. For the first three SLS launches, the units are positioned in the forward skirt at 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 command and control the entire SLS mission profile through deployment of one or more spacecraft.)

“Based on what we know of the plans in place for Artemis III right now, we don’t see the need to make any flight software changes for the Artemis III mission. There may be some parameter changes that are necessary for Artemis III, but right now we’ve not identified any code changes necessary, which would be good because that allows our team here to really get more onto the Block 1B Artemis IV effort.”

The Block 1B upgrade to the SLS combines an in-house developed Exploration Upper Stage (EUS) to the Boosters and Core Stage; the new upper stage is tailored more specifically to the SLS than the COTS ICPS, with the same 8.4-meter diameter as the Core. The SLS flight computers and flight software will now also be in command of the entire multi-hour launch through Trans-Lunar Injection and spacecraft separation, as opposed to only the eight-minute-long ascent insertion.

“We have a significantly bigger job, controlling both the Core Stage flight and then the upper stage flight; we are using the Core Stage software and modifying it as minimally as possible, but we’re having to add significant new functionality,” Phillips explained. “That build is going to be called ECAS for Exploration Computer Application Software, and there will be six development cycles for that.”

“We will also be using that to support Green Run at Stennis for [EUS].” The flight and navigation computers and software that are currently flying at the top of the Core Stage will move up to the EUS equipment shelf on the Block 1B vehicle.

(Lead image: SLS lifts off from LC-39B on Artemis I. Credit: Nathan Barker for NSF)

The post NASA flight software for SLS navigates through clean first launch appeared first on

Leave a Reply

Your email address will not be published. Required fields are marked *