STS-126 to debut OI-33 software upgrades to aid abort safety and RCO ability

by Chris Bergin

The latest software load for the orbiter flight computers – OI-33 (Operational Increment number 33) – will debut with Endeavour on her STS-126 flight next month.

The software upgrade includes safety modifications for engine out scenarios, External Tank separation during a RTLS (Return To Landing Site) abort, and the orbiter’s ability to return to Earth unmanned.

Upgrades to the flight software are used to fine tune safety enhancements, as seen with the previous upgrade to OI-32.

This particular increment focuses on elements that include RTLS ET Separation Enhancements, and GNC (Guidance Navigation Computer) Spec 54 Crew Bearing Display for additional crew horizontal situational awareness..

It also includes Automatic Single Engine Roll Control for 3 SSMEs (Space Shuttle Main Engines) out in Major Mode 102, ECAL (East Coast Abort Landing) Energy Compensation – which provides better energy state estimates during phugoids, and BFS (Backup Flight Software) GPS Auto Update frequency changed to be same as PASS (Primary Avionics Software System).

Further technical updates on this first flight of OI-33 includes BFS GPS Auto Update Frequency, which allows BFS nav to be updated with the selected GPS state at I-Load specified intervals when in auto mode.

Safety Upgrades:

The OI-33 RTLS ET Separation Improvements include “Several minor changes made to improve Post MECO (Main Engine Cut Off) attitude control and reduce the risk of recontact with the ET,” according to one of the series of 17 STS-126 MOD Flight Readiness Review (FRR) presentations created this week – and available on L2.

RTLS abort is a contingency used during a serious shuttle problem prior to “negative return” – with the orbiter making an attempt to return to the Kennedy Space Center (KSC) Shuttle Landing Facility (SLF).

During such an abort, the shuttle has to continue downrange in order to expend the Solid Rocket Boosters (SRBs) to their nominal time of separation. The orbiter would then attempt a maneuver to pitch around for the trip back to KSC.

The SSMEs would continue to burn until enough of the downrange energy is removed, to the point the required velocity for the orbiter to glide back to KSC is achieved, at which point the engines are shutdown and the ET jettisoned. This is where the new software modification will improve safety.

“Yaw jets used to supplement roll control. Control during severe roll off cases improved,” added the presentation as additional changes included for this scenario. “Rudder/Speedbrake deployed to 80.6 degrees at MECO Confirmed.”

A refinement from the previous OI-32 software is also included for this flight, this time for a “two engine out” scenario, where two SSMEs fail during the latter stages of ascent.

“OI-32 Workaround for Single SSME Completion. OI-32 introduced code to simplify crew task by automating throttle down for two out SSME scenario’s but had unexpected consequences,” added the presentation.

“LOCV (Loss Of Vehicle/Crew) for certain 2-out SSME scenarios that cause an unplanned re-entry shortly after OMS-1 (the burn of both OMS (Orbital Maneuvering System) engines to raise the orbiter to a predetermined elliptical orbit)).

“Incorrect flight path angle at MECO results when Ascent Guidance continues actively steering towards the altitude planar targets after SSME throttle down. Consequence is that the OMS-1 burn occurs after the optimum apogee and reentry occurs.

“Crew procedures incorporated into FDF (Flight Data File) to remedy this concern based on A/E FTP (Ascent/Entry Flight Techniques Panel) assessment. For Single SSME scenarios the Crew will select Manual throttles at 5 percent propellant remaining, minimum throttles at 2 percent propellant remaining, followed by Auto throttles.

“Crew and MCC have trained these. Flight Rules and Crew procedures in place for STS-126 and subs to alleviate this condition.”

Such scenarios are highly unlikely, with only one SSME failing during ascent over the entire history of the Space Shuttle program (STS-51F) – which led to a safe Abort To Orbit.

STS-93 with Columbia was also highly eventful, when two of three main engine controllers failed during ascent (Click here for the video edit from the L2 STS-93 MCC loop video).

AHMS upgrade:

Improvements to the already reliable engines range from the actual machinery in the powerpacks, to the monitoring of their health – the latter via the aptly named Advanced Health Management System (AHMS), which debuted on STS-116.

The AHMS is a modification of the existing main engine controller – the on-engine computer used for monitoring the health of the high-pressure fuel turbopump and the high-pressure oxidizer turbopump, which rotate at approximately 35,000 revolutions and 28,000 revolutions per minute, respectively.

The AHMS upgrade uses data from three existing sensors, or accelerometers, mounted on the high-pressure turbopumps to measure how much each pump is vibrating. The system includes the addition of advanced digital signal processors, radiation-hardened memory and new software.

With the three-flight process of adding AHMS to each of the three SSMEs proving the system’s ability to provide improved engine monitoring, engineers will now be able to gain the data while Endeavour is on orbit – as opposed to waiting until the vehicle has arrived back in her Orbiter Processing Facility (OPF).

This is thanks to the debuting of a downlink modification, which debuts with Endeavour’s SSMEs on STS-126.

“Advanced Health Management System (AHMS) Downlink. STS-126/ULF2 is first flight with new SSME controller software capability to downlink AHMS main engine controller data while on-orbit,” added one of the MOD FRR presentation. “Must be performed prior to removing power from main engine controller

“Backup capability to post-landing MADS data retrieval. Ascent Checklist update approved. Delay main engine controller power down until 25 minutes MET (Mission Elapsed Time).”

RCO Capability upgrade:

An undesirable subject for NASA is the RCO (Remote Control Orbiter) capability for the vehicles, undesirable given the scenario in which this would become an option. The unmanned capability was first published by this site.

Since Return To Flight, engineers have been refining the ability to bring home a damaged orbiter, unmanned, in the event of LON (Launch On Need) being called. The choice between a destructive tail-first re-entry and a RCO landing attempt would be based on the condition of the vehicle.

The improvement to the capability – via OI-33 – relates to the deployment of the gear and drag chute just prior to landing, previously ordered by remote command. The software upgrade now allows for these commands to be automated by the orbiter.

“Remote Control Orbiter Enhancement: Provides automatic capability to arm and deploy landing gear and drag chute if RCO is enabled and TAEM (Terminal Area of Energy Management) guidance has terminated,” added the STS-126 MOD FRR Presentation.

“Resumption of GPS navigation during rollout if RCO capability has been enabled and MLS (Microwave Landing System) is no longer available.”

Should an orbiter suffer from damage that requires the LON/Rescue vehicle to be launched, it remains the favored approach to send the damaged orbiter to a destructive re-entry.- as seen on recent FRR mission documentation. LON being called in the first place is highly unlikely regardless.

However, providing the orbiter was deemed to be in with a reasonable chance of surviving, but to the point it was too much of a risk to the crew, a successful RCO salvage of an orbiter would be useful from both an investigation (into the original damage) standpoint, as well as saving one of the esteemed vehicles from being destroyed.

The above content is taken from a couple of pages from the 63 page STS-126 MOD FRR Agenda 3 (of 17) Presentation – available to download on L2. Further articles, highlighting the FRR overview of the upcoming mission will follow over the coming days.

Related Articles