Posted on 02/06/2003 9:45:33 AM PST by Zavien Doombringer
NASA investigators want to know if adjustments made to the position of the space shuttle Columbia during its last minutes by the vehicle's onboard control computers could have played a role in its breakup during re-entry Feb. 1. In a revised timeline of events released Feb. 3, Ron Dittemore, NASA's space shuttle program manager, said that at 8:59 a.m. EST, Columbia's five onboard computer systems began to detect a significant increase in drag on the vehicle's left wing and ordered two of the shuttle's four yaw jets to fire for 1.5 seconds to compensate for the change.
Investigators aren't sure yet whether the adjustments ordered by the computer played a role in the shuttle's breakup. "It was well within the flight control system's capability to handle the [maneuver]," said Dittemore. "But what is becoming interesting to us now is the rate of change."
While Dittemore acknowledged that NASA may never be able to determine the exact root cause of the crash, he said investigators are now studying all of the data from the launch process as well as the shuttle's flight control systems.
The focus on Columbia's flight control systems could be significant. On Feb. 3, Computerworld reported that Columbia and other space shuttles have a history of computer glitches that have been linked to control systems, including left-wing steering controls (see story).
Although officials said it's too early in the investigation to pin the blame for the crash on the control computers, William Readdy, deputy administrator of NASA, said officials are actively searching for any of the shuttle's five onboard computer systems. Although it's unlikely they survived the crash, he said, the computers have "memory resident in them" that could shed light on the status of the shuttle after communications were lost with ground control.
Each computer's memory stores "telemetry of thousands of parameters that affect the flight of the shuttle," Readdy said.
Columbia and other space shuttles have experienced a series of control computer failures during the past two decades, including one that had a direct link to the spacecraft's left-wing control systems. During a March 1996 return flight, NASA officials discovered a computer circuit problem that controlled steering hardware on Columbia's left wing. The computer circuit was responsible for controlling the spacecraft's left rudder, flaps and other critical landing functions.
Speaking at a news conference prior to Columbia's landing in March 1996, NASA spokesman Rob Navius downplayed the seriousness of the computer problem.
"There are three additional paths of data that are up and running in perfect shape, and there's multiple redundancy that would permit a safe landing," he said. Although Columbia landed without incident that time, NASA officials said the failure was significant enough that had it happened earlier in the flight, the agency would likely have ordered the shuttle home early.
The General Accounting Office, the investigative arm of Congress, has also criticized NASA in the past for relying on the same commercial contractors to develop, test and validate the space shuttle software (see story).
However, Donna Shirley, the former manager of NASA's Mars Exploration Program and the team that built the Sojourner Microrover, said there is no evidence yet that flaws in NASA's software-validation program had anything to do with the disaster.
Very well said. I'm a programmer, and we've had applications out in the field which suddenly turned up nasty bugs after over a DECADE of proper operation, due to what we jokingly call "the moon is full and it's a tuesday on a leap year" bugs.
This theory interleaves quite logically with some other Shuttle thread comments. Specifically where atmospheric density conditions pushed the edge of Shuttle design parameter limits.
More often in the real world of catastrophic events, computer logic is meaningless when the devices it controls have been destroyed. On a system like the Shuttle, especially after 20+ years of operation, the software is much harder than the devices it acts on. Software doesn't age. It doesn't get brittle or develop stress cracks. Software only gets better with age.
Mach 18 plays hell with mechanics while the software isn't even phased.
Your conjecture that some "low probability" event triggered an over-correction of the controls seems very, very unlikely. The astronauts spend the vast majority of their many years of training time in high-fidelity simulators with a team of engineers throwing every 'low probability' event conceivable at them. If a fatal software glitch were there, it would have been caught years ago.
I'd look first for some fatal mechanical failure as the root cause. It could be from an external event, human error or simply an age or stress related failure.
People will say, but, gee, those systems had to be checked out, both in simulations and actual tests. Well, sure, as best we can set up test conditions. But say something happened on this re-entry that triggered a portion of the controller that had heretofore gone untested. It could be any minor thing, misalignment on re-entry, a few degrees of trim and yaw not fully corrected, whatever. If those PID limits failed or were never implemented, it doesn't take much to drive the system into saturation and instability.
Yup, I have seen it many times. It usually resulted in a 99 code and total failure as well as loss of data and program lock up.
(2) the foam hit the structure that mates the shuttle to
Awesome point, given explosives involved with separation of external devices. Judging by the comments of some thread participants, chances are someone intimately understands the explosive bolt wiring harness route.
Ordinarily I would have guessed such a wiring harness is adequately shielded from such an event. However, I recall an anti-lock brake failure on my car, due to road debris striking a wiring harness.
Well, isn't that what happened? At 207,000 feet, the air is still pretty thin. The combination of speed and air density make frictional heating approach maximum load at those altitudes, but aerodynamic buffeting is not as bad as at lower altitudes, where thickening air makes mechanical shock a concern. My guess is that airframe heating combined with kinetic forces (deceleration) caused the initial large-scale breakup (although smaller sections or pieces could have peeled off earlier), with some contribution by whatever aerodynamic stresses were present at that point.
Theoretically possible I'd guess, but I would be looking elsewhere before I'd go there. I too have seen software problems appear that no one had considered before. Never a 'fatal flaw' but stuff that should not have happened. But these are on systems that haven't been exposed to the intensive V&V that NASA uses. Few if any companies have the money, manpower or luxury of time to devote to the intense simulation regime that NASA uses. That software has been through the wringer for 20 years and it just seems that if a fatal flaw were there, it would have been spotted long ago. Mechanical devices on the other hand can test perfectly today and go bad tomorrow.
It is clear that loss of control pre-dated significant burn-through. The big question is what caused the loss of control. Telemetry data to date indicates escalating port drag, which to me says there was some mighty disturbed airflow on that side relative to the other. Some even speculate that the port gear cover came off over California.
This is standard, and designed into the entry trajectory months prior to launch. What you're referring to is "energy management," which is a technique used to match up the trip from the runway to entry interface (400 kft), and the trip from deorbit burn to entry interface.
(They start with a known spot -- the runway -- and work backwards from there.)
That would be THIS.
Sounds bogus. Any buffer memory would be RAM, and unreadable by now.
Were shuttle comms in the clear? Were any hams monitoring?
LOL, OneLoyalAmerican! I'll be sure to tell my hubby that you endorse his theory of the case!
We'll have to wait for the conclusion of the investigation, and its report. I feel confident that NASA is conducting regression analyses of a variety of different scenarios, as we speak. At the end of the day, I believe we will have the truth of the matter.
Meanwhile, newbie, we're just going to have to be patient, while we wait for the jury to weigh in.
Thanks so much for writing!
That would depend on whether the capacitor was still intact on the board. Memory can be maintained for many days.
Yes, I am familiar with it. If the speed were to slow, for example, it would assume a more nose down attitude.
Actually, this Freeper hasn't settled on any one specific theory at this point. While some theories are easily discounted as hopelessly irrelevant; others, like your hubby's strut mount/wheel cover theory, could play a role. Every theory is possible until rationally eliminated.
In January 1986, this newbie was already a former MortonThiokol non-aerospace engineering employee. But more importantly, as a MTI investor, the Challenger incident was close to my heart. Back then interested parties sat around the lunch table, or upon barstools after work, as we brainstormed the Challenger accident. Today, FreeRepublic is an awesome public domain brainstorming forum, bringing untold knowledge and outside the box thinking into the intellectual pool.
The Challenger incident, like most accidents; was not just one specific causation in fact. As we know, the SRB "O-ring" seal failed. However, many seemingly benign events, combined with bad assumptions, and poor risk assessment decisions predisposed the seal failure.
More likely than not, we’ll find the Columbia incident also results from a series of likely, and some perhaps very unlikely events. Each single event on its own merit might not have doomed the mission. However, as combined, compounded and concurrent events, all become key ingredients in a recipe for disaster.
Well betty, now that the loose-foam theory has been denied,
maybe somebody would like to speculate that something went
awfully awry with the Native American piss-paint experiment:
Well, I'm speculating like everyone else. That's probably useless but sometimes it helps to talk things out. Sometimes I like to focus on technical details, otherwise the grief becomes hard to manage.
Anyway, yes, simple hardware failure should be looked at. Given their altitude, it would seem thrusters would be the mode of attitude control. If thruster control was lost or became anomalous for some reason, at those speeds, recovery would be problematic. Armstrong was able to cope with thruster failure in both Gemini 8 and the LLRV but for different reasons. The LLRV accident happened at low altitude and speed, and he had time to react. In Gemini 8 he was in a stable orbit but lost attitude control. Quite dangerous, as others have noted, but he wasn't in the re-entry phase, where being out of control in roll would have had more quickly fatal consequences. I'm wondering how a PID controller would react to a failed-open thruster. My guess is an increasing control signal, which either resulted in integrator wind-up, or failure to damp out the uncommanded movement. In either case, at that point in the flight, it would have been a near-impossible problem to work, most likely.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.