By George Mancuso

Boeing announced on April 6th it would fly a second uncrewed Orbital Flight Test (OFT) of its CST-100 Starliner. The flight goal is to confirm that problems encountered during last year’s OFT-1 December 20th flight have been corrected. Boeing will also absorb OFT-2 costs. Problems resulted in a truncated December OFT-1 flight with all mission objectives not being fulfilled. During OFT-1 Starliner was placed in an off-nominal orbit and was unable to rendezvous and dock with the International Space Station (ISS). A launch date for the second flight has not been announced, but it is expected to occur later this year, with crewed Starliner flights not occurring until 2021.  At this time SpaceX remains on schedule for an initial crewed Dragon 2 flight in May/June of this year, and a possible operational crewed flight later in the year.

OFT-1 problems ranged from minor to severe. Each problem has been reviewed by Boeing, an Independent Review Team (IRT) and the National Aeronautics and Space Administration (NASA), with associated corrective actions established. Presented herein is a review of what went right and what went wrong, including a summary of fixes

What Went Right

80% + of OFT-1 mission objectives were achieved. The truncated flight lasted two (2) days, followed by a nominal reentry. For the most part hardware performed to or exceeded specifications.

As a secondary issue, the out of sync Mission Elapsed Timer problem discussed below caused excessive thruster firing. This resulted in a false positive overheat alarm causing a thruster system shutdown. One thruster could not be subsequently reactivated and is being examined. Note that the thrusters are redundant and safety was not affected.

The landing itself was within 182 meters (200 yards) of the center of the landing ellipse, and landing loads were three times lower than NASA requirements.

What Went Wrong

Issue 1 – An error with the Starliner Mission Elapsed Timer (MET) incorrectly polled time from the Atlas V booster, which required correction from Mission Control (CM), and resulted in the off-nominal orbital insertion which prevented docking to the ISS.

Issue 2 – A software problem, within the Service Module (SM) Disposal Sequence, incorrectly mapped the disposal sequence into the SM Integrated Propulsion Controller (IPC). This situation was again corrected by MC.  If uncorrected, the issue might have caused the Crew and Service modules to bump once separated, resulting in possible damage to the Crew Module (CM) affecting reentry.

Issue 3 – An Intermittent Space-to-Ground (S/G) forward link hindered control of the spacecraft causing a delay when override commands were sent to correct Issue 1, affecting orbital insertion. Boeing ground teams had issues connecting with the spacecraft on more than 30 additional occasions during the two-day test flight.

Issue 4 – Numerous process escapes were encountered. Essentially, these were less serious software defects that were not detected during qualification testing.

Fixes

Issues 1 and 4 – At times problems appear disassociated but are systemic in nature, having a common root cause. For at least some of the software defects encountered the root cause was “chunk” testing. Boeing test teams broke up software qualification tests into chunks and tested each of those chunks independently. Consequently, end-to-end testing was not performed and defects encountered were related to chunk interface points.

For example, as stated by John Mulholland, Boeing VP and Commercial Crew Program Manager, “…this resulted in one chunk being the countdown and launch, stopping just after spacecraft separation from the Atlas V’s Centaur upper stage. The second chunk picked up thereafter and ran through the critical Orbit Insertion burn. The issue here is that because the countdown/launch software test chunk stopped before the Orbital Insertion burn, the test was unable to verify that the correct Mission Elapsed Time was pulled by Starliner from the Atlas V rocket.”

Issue 2 – The software error would have prevented Starliner’s Service Module being able to fire its thrusters to perform a critical evasive burn to get itself away from the Crew Module (CM) after separation. This error occurred because the emulator used to verify this part of the software code during qualification testing was legacy code from other programs and was not updated with the correct thruster mapping for Starliner. The emulator software at Mission Control was correct and enabled the problem to be detected and corrected in flight. The qualification test emulator has since been updated with the correct code.

Issue 3 – The review team is continuing its investigation of the intermittent S/G forward link that hindered the flight control team’s ability to command and control the spacecraft. The root cause is radio frequency interference with the communications system. Specific hardware improvements have been implemented and a full assessment is in process.

Overall – In the future, Boeing will run integrated end to-end software testing, including multi-day launch-to-docking and full-duration undocking-to-landing tests.  Also, in keeping with the IRT recommendations Boeing will improve System Engineering and Integration practices.