Boeing is also reviewing software issues that emerged in the analysis of the crashes of two Boeing 737 Max airplanes that killed 346 people and led to the plane’s grounding since early last year. Doug Loverro, the head of human exploration for NASA, said it was unclear if the software issues with Starliner and the 737 Max crashes were connected.
“We don’t know how many software errors we have — if we have just two or many hundreds,” Loverro said. “[The] bottom line is that the industry is very bad at doing software.” Boeing, he said, very well may have had “a good program, but it was not executed correctly,” according to the
More than one problem detected
first software issue came up shortly after Starliner launched when the capsule failed to execute an orbit-insertion burn. That issue was caused when the Starliner’s onboard “mission elapsed timer” erroneously pulled an incorrect time from the Atlas V rocket nearly 11 hours before liftoff.
The information was supposed to be retrieved during the actual countdown, before liftoff, but because it was the wrong data, Starliner’s internal clock did not have the correct time.
The second software problem was discovered before the spacecraft’s return to Earth, and it was a major problem that could have led to a collision between the Starliner’s crew module and its service module. Boeing officials described it as a “valve mapping error,” that had to do with the software that tells Starliner’s crew module and service module to separate before landing, reports
“During what we call ‘free flight,’ when the crew module is attached to the service module, there’s a certain valve mapping, and the flight computers on the crew module command all of the individual thruster firings. But after you separate the launch vehicle from the crew module, the propulsion controllers on the service module have to conduct those thruster firings to get the proper separation and disposal burn,” John Mulholland, vice president, and program manager of Boeing’s Starliner program said during the teleconference on Friday.
Thankfully, the software error was detected before the descent. “The team very quickly recoded the software, reverified it in the labs, and we were able to upload that software correction and safely complete the mission,” Mulholland said.
A third major problem that Starliner had didn’t have anything to do with its computer software. Apparently, interference disrupted communications between ground controllers and Starliner, leaving ground control unable to communicate with the spacecraft in a timely manner.
Communications between Starliner and ground control are relayed using NASA’s network of
Tracking and Data Relay Satellites, but “high noise” interfered with those signals, Mulholland said.
Loverro also pointed out that the software issues “are likely only symptoms. They are not the real problem.” He said, “The real problem is that we had numerous process escapes in the design, development and test cycle for software.,” adding, “and as we go forward that is what we’re going to be concentrating on … how do we assure ourselves that all of the software that we’ve delivered, not just the two routines that were affected by these issues, are fixed?”