ARTEMIS and MAESTRO
“The trick here in the lab is to make all these avionics boxes think they are actually flying a vehicle and that’s where ARTEMIS comes in,” Mitchell explained. “ARTEMIS is our real-time simulation environment.”
“It models all the environments, gravity, wind that the rocket will experience during flight. It models all the major systems and subsystems within the rocket, so obviously we don’t have actual hydrogen and oxygen tanks in here but we have models of those and they’re included in that real-time simulation environment.”
“There’s several compute platforms on the backside of the structure that again model all those environments, all the main vehicle subsystems and systems, all the tanks and feedlines,” he added. “We don’t have an engine here in the lab but it models the RS-25 engine dynamics.”
Another view of the SITF-Q ring in the SIL at Marshall in March, 2019. The black computer hardware on the far right along the back of the ring is some of the ARTEMIS simulation infrastructure. Credit: Philip Sloss for NSF/L2.
“We don’t have a real booster, but it models the thrust coming out of each of the boosters. We also have in ARTEMIS models of every single avionics component; obviously you want to maximize the testing you have with the hardware in the loop but when we’re doing some off-nominal testing models give us the best way to introduce failures and see how the system responds to failures.”
“ARTEMIS through that simulation produces on the order of about 1400 different signals that are injected into the various boxes, again to make them think they’re actually flying a rocket instead of just sitting here in the lab on this structure.”
“MAESTRO is really the user interface tool, so it’s the tool that’s used to set up your test, execute a test sequence, display the data that’s being produced during the test, so it’s really the tool to execute and monitor a test as you go,” he explained. MAESTRO stands for “Managed Automation Environment for Simulation, Test, and Real-Time Operations.”
“ARTEMIS and MAESTRO come in a pair,” Mitchell added. “As we refine and add more capability to ARTEMIS, MAESTRO comes along as a companion to reflect that capability and provide that capability to the testers.”
ARTEMIS and MAESTRO have been developed in tandem with the flight software. “When we laid out at the beginning of the program our overall software build strategy, in parallel we laid out what the build strategy is for ARTEMIS and MAESTRO and we did that in concert with basically the design and analysis cycles (DAC) that were going on with the vehicle,” Mitchell noted.
“We wanted those DAC cycles where they were designing the vehicle, designing the GNC, for ARTEMIS, MAESTRO, and flight software to parallel those as much as possible, so we incrementally matured ARTEMIS, the simulation environment, and flight software as best we could to keep up with the design maturity of the launch vehicle itself and by doing that we’ve actually been flying this vehicle with flight software since really our second build, which was in 2012 time-frame.”
Software operations
The flight software running on the flight computers manage vehicle systems, either directly during the launch and ascent sequence, or via requests from ground systems. “The flight computers are really the surrogate for executing things on the vehicle,” Mitchell noted. “When you start the power up process of the vehicle the flight computers are one of the first things that are powered up and flight software begins running at that point.”
“During that phase of operation, flight software is largely waiting to receive commands from the ground, so for example to power up all the other avionics boxes the ground sends commands through the flight computer to actually power up the RINU, to power up the CAPUC (Core Auxiliary Power Unit Controller), to power up the TVC Actuator Controllers, there’s a whole process that it goes through,” he added. “The ground commands through flight software the RINU to go into gyro compass alignment mode, which is a mode that the RINU executes to determine its position and orientation on the vehicle.”
A few ground-managed exceptions of vehicle items are the vehicle-side fill and drain valves and onboard heaters to help with environmental control of systems surrounded by cryogenic propellant ducting.
Some of the engine section avionics boxes as configured in the SIL at Marshall. The left shelf contains four Core Auxiliary Power Unit Controllers (CAPUC), two Combined Control System Electronics (CCSE) boxes, and two Data Acquisition Controller (DAC) boxes. The four TVC Actuator Controller (TAC) boxes are seen on the right. Credit: Philip Sloss for NSF/L2.
On a launch day, a “Day-of-Launch Initialization-Load Update” (DOLILU) is uploaded to the flight software.
The flight software flies an open loop guidance scheme during the “Boost” phase of ascent from liftoff through the lower-atmosphere to Solid Rocket Booster burnout and separation about two minutes later. “There’s a whole process to collect the day-of-launch winds and it goes into a process to estimate what the winds are during the ascent and they develop a table that’s uploaded to the vehicle at T-minus an hour ish,” Mitchell said.
“And that table are really the steering commands that flight software executes during ‘Boost’ phase of flight, so you’re basically operating in open loop guidance during the first phase of flight and that’s all designed to minimize the loads that are imparted on the vehicle while it’s going through the atmosphere.”
The vehicle assumes control of the launch sequence a half minute before liftoff. “The ground sends commands late in the count to finally tell flight software what the actual launch time will be and then to go into ALS mode,” Mitchell said. “ALS starts, Autonomous Launch Sequencing, starts at T-30 seconds.” The vehicle receives the planned liftoff time from the ground at T-33 seconds.
“If it does not receive a ‘go for main engine start’ command from the ground it won’t start the engines, but assuming it gets that ‘go for main engine start’ it’ll start sequencing the ignition of the engines and at that point it’s basically ‘we’re going’ unless a fault is detected primarily by the vehicle at that point,” he added.
“If the ground finds something that is not right either on the ground side or looking at telemetry coming off the vehicle it can send basically a launch halt command to the flight software. It’s also during ALS when flight software begins active LCC (Launch Commit Criteria) monitoring internal to the vehicle. So if the flight software sees something that’s not as expected it would halt the launch as well.”
A table of Boost phase events from a NASA presentation. A “Day of Launch Initialization-Load Update” (DOLILU) provides data used by the flight software Guidance Navigation and Control (GNC) to steer the vehicle through this phase of flight. Credit: NASA.
Once in flight, Mitchell said: “Its primary functions are obviously to implement and execute the Guidance Navigation and Control algorithms necessary to fly the mission, [but] we have a series of functions that all kind of fall under the umbrella of Mission and Fault Management (M&FM). M&FM provides primary mission management but it’s also constantly checking and assessing the health of the vehicle as we fly.”
“There are a few things that if a fault occurs, that the flight software will have to do some active redundancy management functions within the rocket. A lot of failures that can happen can be completely passive, there’s nothing that flight software overtly has to do, those type failures are simply voted out as part of the normal operation of the flight software.”
“We don’t need abort capability for the first flight but we are running all our abort detection algorithms, because we want to get real run-time/flight-time on those algorithms during the first mission,” he added. “You know, to check for robustness, that the trigger levels are not too tight, they’re not too wide, so it’s a good opportunity to get some real flight experience on those algorithms.”
“So obviously that would be in preparation for the first crewed flight on EM-2 (Exploration Mission-2), to make sure those are tuned properly,” he continued. “Because there’s always that balance, you don’t want to have a hair trigger on those kind of things.”
“For example back early in the development one of our [flight] crew representatives said ‘don’t make me get off of a perfectly good rocket,'” Mitchell noted. “So I said ‘yes, sir, we’re going to do our best.'”
A high-level diagram of the SLS flight control system showing the inter-relationship between the computed guidance and flight control and the sensor and steering hardware. Credit: NASA.
After the boosters separate, the “Core” phase of flight begins. “Once the boosters separate PEG starts,” Mitchell said. “PEG is the guidance scheme that’s called Powered Explicit Guidance.”
“PEG is running but at that phase it goes into closed loop form of operations. So it’s evaluating where the rocket ended up at booster separation versus where the open loop guidance predicted it would compared to where we need to get to.”
“It converges on a solution from where we are at this point and where we need to get to and it begins providing the steering commands,” he added. “That PEG software produces the steering commands that gets the rocket in a closed loop fashion from where the boosters separated to the MECO target.”
After MECO, the stage finishes safing itself while ICPS with Orion separates. “There’s a few safing functions that flight software needs to perform,” Mitchell said. “For example, it closes the prevalves, the valves that are between the tanks and the engines themselves, it’s part of safing the engines as the pumps spin down, so there’s just functions like that that are performed really for just the first few seconds after MECO.”
“There’s really nothing left to do other than it’s just continuing to coast up and we’re telemetering health and status information, navigation state information for as long as we can for as long as battery power lasts and as long as we’re in line of sight of the Bermuda station.”
Green Run Application Software, Stage Controller
The flight software is called the Flight Computer Application Software (FCAS); it’s counterpart for the Stage Green Run is called the Green Run Application Software or GRAS. “Since we’re not flying the stage, instead of having the GN&C algorithms we replace those with a Green Run subsystem and mode manager and part of what that mode manager does is it executes basically a table of predetermined thrust commands to each of the engines as well as TVC gimbal commands to the engines as well,” Mitchell explained.
“The engines will go through a thrust profile that looks similar to what you would see during an ascent but the TVC gimbal profile is coordinated to minimize the loads imparted on the stage or the test stand itself, so they’re all designed to be symmetric so to speak, so that your thrust vector goes straight up and you’re not imparting side loads on the stage. Otherwise, [the] Booster subsystem is not running, but all the other key software modules are running just like they would in flight.”
A view looking south from Level 19 on the B-2 stand at Stennis. The blue-roof Test Control Center (upper right) that would be used for SLS Stage Green Run testing would communicate with the Core Stage via Boeing’s Stage Controller avionics and software, which is installed on the test stand for checkouts. An identical Stage Controller unit is installed at Marshall for testing with the Core Stage avionics and software later this year. Credit: Philip Sloss for NSF/L2.
“We’re expecting to learn something from Green Run, so we have built into our schedule an update if necessary, and a regression test campaign after Green Run.”
The Stage Controller is a set of computer racks and software developed by Boeing to control the test campaign at Stennis. “There’s functions where it directly interfaces to the flight computers and so it becomes the primary path for sending commands to the stage, getting telemetry that comes off the stage all goes through the Stage Controller,” Mitchell explained.
“Those commands will come from the Test Control [Center], so they’ll be sending commands from there, almost the same telemetry that you would see on launch day is being produced and passed through the Stage Controller and then it’s distributed out to all the people that are on console down in the control room. It’s interfacing to the heaters that are on the stage, there’s a set of valves that are not controlled by the internal flight software or avionics, they’re controlled by the ground so it interfaces to those.”
“It also interfaces back to the main control interfaces for the test stand as well,” he added. “It’s kind of the central hub of integrating the stage to the test stand and providing the operators the capability to make sure the stage as well as the test stand are performing and executing the test as expected.”
Release 15
While all the Release 14 activities continue for EM-1, plans are to start work on Release 15 for Exploration Mission-2 (EM-2) after the formal runs for record are completed later this year. “We’re going to take some lessons learned from EM-1 and start implementing those with the first Release 15 development activity, so we’re looking for three flight software releases,” Mitchell said.
“The first will be some internal infrastructure updates and modifications. One of the things that we want to do is make some modifications, we don’t anticipate them to be significant, to be able to support a crewed or a cargo version of the Block 1. Obviously we’re thinking about a Europa mission and by making those modifications through parameters, setting parameters appropriately, you can have it fly in crewed configuration with Orion or a cargo configuration. And then the subsequent two builds will just be any modifications and enhancements necessary primarily right now to support EM-2.”
“At least for the launch vehicle for EM-2 its mission is really very much the same whether it’s EM-1, EM-2, or SM-1 (Science Mission-1 for Europa Clipper), we’re really just trying to hit a MECO target. With the crew that obviously brings in the abort detection and there’s going to be some refinement of those abort algorithms and the triggers.”
Lead image credit: Nathan Koga for NSF/L2.