NASA’s Space Launch System (SLS) Program is working through a formal test series for the software and computers that will fly the launch vehicle from the final countdown through Main Engine Cut Off (MECO). NASA developed the flight software that will run on computers in the Core Stage, working with other contractor-managed avionics boxes for different program elements.
Formal testing is being performed on the software and avionics elements separately and also integrated together in different development and testing facilities at the Marshall Space Flight Center (MSFC) in Huntsville, Alabama.
The flight vehicle is still being assembled elsewhere, so in addition to the flight software, emulation software was developed in parallel to test implemented functionality as it matures.
Release 14 of the SLS flight software is slated to be the first flight version and is currently going through the formal “run for record” testing where the software flies many simulated launches with emulators subjecting them to different scenarios of transient and hard equipment failures, varying environmental factors like temperature and wind field profiles, performance and guidance variations, and more.
Similar testing to verify the avionics meets its standalone requirements and then integrated with the software to test against those requirements are planned for the Summer and Fall.
Flight software in “run for record”
The version of the flight software that will fly on the first launch of SLS is going through formal testing at MSFC. “Where we are today is we are in the process of pushing to get through what we call the initial formal qualification test (FQT) of Release 14 and Release 14.2.3 is what we’re processing through FQT right now,” Dan Mitchell, NASA’s Technical Lead for SLS avionics and software engineering, said in a March 5 interview. “We laid out a series of four incremental tests, we’ve completed the first three of those.”
“In fact we just finished the formal testing of the third test campaign earlier this week and we’re pressing towards the fourth test campaign to kick off in the early April time-frame. Once we execute those tests, go through formal analysis, that will complete what we call the initial FQT, where we will be able to buy off the vast majority of our software requirements in a formal manner.”
“With each release we have gone through a series of tests and they’re all building up to the stage that we’re in now which is the formal call it ‘run for record’ test campaign where we’re trying to formally verify that the requirements that have been specified in the software requirements spec (specification) as implemented in flight software perform correctly,” he added. “We will complete the testing of it in May and the data analysis and formal documentation of it will be performed in June and July.”
A flight-set of three SLS flight computers in the Avionics and Software System Integration Lab at Marshall. The three units operate together in a Flight Computer Operating Group or FCOG. Another FCOG set is being used in the Software Development Facility at Marshall for the current formal qualification testing of the SLS flight software. Credit: Philip Sloss for NSF/L2.
The FQT is being performed on the flight software in the Software Development Facility (SDF) at Marshall. The software runs on three flight computers as it will on the vehicle. “We have three flight computers so that we can do that testing in what we call a fully formed FCOG, that’s a Flight Computer Operating Group, that’s all three Flight Computers operating together,” Mitchell noted.
“That’s the environment the test team does most of its testing in is in that FCOG environment, so that we get from [that] perspective the most realistic set up and configuration for doing testing of flight software.” The rest of that testing environment is emulated by another software package developed in parallel with the flight software called “Advanced Real-Time Environment for Modeling, Integration, and Simulation” or ARTEMIS.
Management of the SLS vehicle is divided into different elements; the Liquid Engines and Booster elements drew on hardware that was either flight proven in the Space Shuttle Program or well through development in the Constellation Program prior to its cancellation in 2010. Qualification testing of RS-25 avionics and Booster avionics were completed in 2017. The Core Stage (a part of the Stages element) is the primary new development for SLS and many of its subsystems are now going through qualification testing, including avionics and software.
As formal testing of the standalone subsystems continues, preparations are also continuing for formal testing of the integrated requirements when they are run together. There are dozens of avionics boxes located throughout the vehicle that need to be tested with the flight software running on the flight computers.
A graphic showing the layout of the testing “rings” in the Avionics and Software System Integration Lab at Marshall. The semicircle and circular rings on the left are being used for standalone avionics qualification testing. The two on the right are being connected to do integrated avionics and software testing. Credit: NASA.
A separate facility called the Avionics and Software System Integration Lab (SIL) is used for broader hardware-in-the-loop testing, bringing together more complete sets of Booster, Engine, and Stage avionics boxes for standalone and integrated testing. A series of test campaigns will bring together more hardware, from the computers and software to mechanical systems such as for Thrust Vector Control (TVC).
The RS-25 engine and SLS Booster avionics have been hot-fire tested with their hardware, but a full integrated test of the Core Stage avionics with a working stage will have to wait until the Stage Green Run planned for the Stennis Space Center (SSC). The Trump Administration has asked NASA to focus on the schedule for the first SLS launch, Exploration Mission-1 (EM-1), emphasizing the goal of flying in 2020.
If the Stage Green Run is deleted for maximum schedule improvement, there will be no full-length integrated Core Stage ground test; instead, the first time a Core Stage will ever go through a full exercise will be in flight during its first launch.
Avionics and software overview
In the Block 1 configuration of SLS, the flight software is in charge of the vehicle from shortly before launch until the Interim Cryogenic Propulsion Stage (ICPS) separates after MECO, running on the three flight computers located in the forward skirt of the Core Stage. “The SLS avionics architecture is designed to be single fault tolerant and to implement that we have three flight computers,” Mitchell explained.
“Each of the flight computers share data with their neighbors to make sure that as they collect data through the sensors and subsystems that each flight computer has a common and homogeneous set of data to execute the algorithms on. So data comes in, it’s actually exchanged through a cross-channel data link, and then is voted on, and then [that] is shared, so we get essentially one-hundred percent assurance that each flight computer has bit-for-bit the same information to process.”
“Once that happens, we run through the Guidance, Navigation, and Control (GNC) algorithms, we execute our Mission and Fault Management (M&FM) algorithms to make sure the system is healthy and performing as expected and once that’s all complete then we send commands out to the vehicle,” he added. “So for example engine thrust commands, TVC gimbal commands to steer the vehicle and keep it under control, and that process happens fifty times a second while we’re flying the rocket.”
An alphabet soup of the different avionics boxes distributed throughout the SLS Block 1 vehicle. The flight software runs on the three flight computers (FC) in the forward skirt of the Core Stage. The computers talk to all the avionics in the Core Stage, Boosters, and RS-25 engines, along with links to the ICPS upper stage, Orion spacecraft, and Ground Systems. Credit: NASA.
A Redundant Inertial Navigation Unit (RINU) runs alongside the flight computers to provide navigation inputs for GNC. On the ground, ARTEMIS emulates vehicle motion by working with a unit modified for testing.
“The RINU is our navigation unit and this version of the RINU is a special version that does not have gyros and accelerometers in it, because obviously we can’t rotate and translate this whole thing to make it provide inputs that the flight computers would think are real motion,” Mitchell explained.
“It has a simulation input where we have models of the gyros and accelerometers that are a part of ARTEMIS, so it takes those outputs from those models, feeds it directly into the RINU to stimulate the nav (navigation) processing software in the RINU to create a nav solution that is sent to the flight computers. So that’s one of the key inputs that the flight computers vote on and uses to determine how much additional deflection on the engines or what thrust changes are needed.”
Avionics boxes are distributed in the dry sections of the Core Stage that surround the large cryogenic propellant tanks. The Booster avionics are similarly distributed above and below the solid propellant segments in the forward and aft assemblies.
The ICPS upper stage is essentially a commercial, off the shelf unit with its own independent avionics and software that already flies on the United Launch Alliance (ULA) Delta 4 launch vehicle.
Testing campaigns
Different avionics sets are being staged in the SIL at Marshall for the next set of formal avionics and software testing. The hardware-in-the-loop lab has two semi-circle rings that approximate the Core Stage diameter and two circular rings that do the same for the Boosters.
“All the avionics is mounted as much as flight-like on the structure [as possible],” Mitchell said. “We are using flight-like cables to connect everything up so that we can replicate the timing of all the signals that flow through the system as close as we can like the vehicle, to make sure that it gives us an opportunity to do some electrical self-compatibility verification and validation testing.”
“This is the most like the vehicle obviously that we have until we actually have the Core Stage built up at MAF.”
Called Software Integration Testing Facility (SITF) rings, the Qualification ring (SITF-Q) has been used for development testing of the Core Stage avionics and software.
“Boeing is using this side of the lab to do three things,” Mitchell explained. “You see these gray racks in the middle, they are representative of their EGSE (Electrical Ground System Equipment) and they have software loads that go on these that are used down at MAF to support buildup and integration of the stage.”
The SIFT-Q ring in August, 2017. This ring holds the most complete set of Core Stage avionics boxes beyond the full set now installed on the stage in production at Michoud Assembly Facility (MAF). Credit: Philip Sloss for NSF/L2.
“They’ve developed software initially to support the forward skirt integration that happened last year, the intertank integration that happened last year, [and] they’re in the process of using it for the engine section integration right now,” he added. “Then once they get all the elements joined up there’s a load that they use with what’s called the final integrated functional test, it’s really that integrated Core Stage checkout to make sure that everything is wired up correctly and that all the boxes can communicate.”
“So Boeing verifies all that software here in this facility before they actually use it down at MAF, so that’s one use of the lab,” he continued. “The second use is now that they’ve completed that, the second use is to use the lab to verify and buy off their avionics subsystem requirements. They have a series of testing that they’ll be doing over the next two to three months to do that formal ‘run for record’ requirement buy off and make sure that the avionics are performing per its requirements.”
Core Stage Electrical Ground Support Equipment (EGSE) racks as seen in the SIL at Marshall (left image in the foreground), and with the Core Stage-1 forward skirt at MAF (right image in the left foreground). Credit: Philip Sloss for NSF/L2.
“And then the third thing is Green Run support,” he said. “Once they finish formal subsystem verification we’re going to go through a little bit of a reconfiguration here in the lab to turn it into a Green Run integrated test capability.”
“We will load the Green Run Application Software (GRAS) on the flight computers, that’s a variant of the flight software that will fly the rocket, we will integrate the Stage Controller, the Stage Controller is the system that stands between the Stage itself and the B-2 test stand, so it’s kind of the go-between and arbitrator between those two parts of the test. So we’ll test all that system here in the lab, that’s targeted to start formal testing late Summer, early Fall of this year.”
Unit 1 of the Stage Controller is deployed in an adjacent room to the SIL so that it can be tied in with the SITF-Q ring. Unit 2 is installed in the B-2 stand at Stennis. “We have a B-2 Test Stand Emulator and Core Stage Emulator installed at SSC to support Stage Controller integration,” Mitchell noted in a follow-up email.
The SITF Development ring (SIL/SITF-D) is being staged for the integrated SLS avionics and software testing. Core Stage avionics with the flight software loaded will be tied in with Booster avionics in the adjacent Hardware in the Loop (HIL) Qualification Line for that “run for record” testing later this year.
“This ring with the booster [ring] will be used to do our integrated vehicle formal test activity,” Mitchell said. “We have a set of Level 2 integrated SLS avionics and software performance requirements that we will formally test on this side and that will be going on in parallel with the Green Run [avionics] test campaign.”
SITF-D/SIL ring in the Avionics and Software Lab at Marshall in March, 2019. Additional computer hardware is being added for upcoming tests of the integrated avionics and software across the Booster, Stage, and Liquid Engines elements. Credit: Philip Sloss for NSF/L2.
“We’re in the process of doing the final procedure development to do the runs for record and we’ll start formal runs for record, right now we’re looking at Summer time-frame. We have interfaces with the ground obviously and interfaces with Orion and so those programs (Exploration Ground Systems and Orion) provide emulators of their systems that we have integrated here in the lab.”
Likewise, SLS provides emulators to Orion and Exploration Ground Systems (EGS) for their testing. Lockheed Martin’s Integrated Testing Lab (ITL) in Denver is where similar avionics and software testing is performed for the Orion Program.
“What we have in the ITL are three flight computers that could run flight software and then three racks that simulate the SLS vehicle,” Mitchell noted. “I think we’re now up to 10 emulators that we have down at KSC (Kennedy Space Center where EGS is based), they’re actually installed in the LCC (Launch Control Center) in Firing Room 3 and so that’s where they (EGS) do their testing.”
Views of the Exploration Ground Systems (EGS) emulator racks (black cabinet) and the Orion/Multi-Purpose Crew Vehicle (MPCV) emulator racks (blue cabinet) in the SIL at Marshall. Credit: Philip Sloss for NSF/L2.
SLS is also planning on integrated testing between the SIL and the TVC Test Lab next door at Marshall. “Once we finish our formal verification tests, we’ve identified a series of validation testing where they are going to hook this side, the SIL up to the both the Core Stage engine TVC actuators that are over there as well as two Booster TVC actuators,” Mitchell said. “We’re going to do a series of tests where we can see the performance of the system from the RINU sensor itself through the flight software, through all the avionics, and then actually driving TVC actuators.”
“One of the tests we’re going to do in the VAB (Vehicle Assembly Building) is an end-to-end polarity test, where we will allow the rocket to sense Earth rate, you know just moving along with the Earth, and as the RINU senses that rate, that motion, you’ll start seeing movement on the TVC actuators,” he explained. “You don’t want them moving in the wrong direction, so that’s a pretty standard functional check that’s performed on most launch vehicles.”
“We’ll do that same test here in the lab,” he added. “This RINU actually has sensors in it, so we’ll move it over here, we’re going to build a little tilt table, rotate it, and then see the TVC actuators move as expected. We call it the Earth Rate test.”
The first opportunity to fully test all the Core Stage systems together was expected to be during the Stage Green Run test campaign at Stennis; if that is cancelled, those learning experiences will occur at KSC.