Replies

The problem with software is that if you have code to deal with unusual situations (like unusual drag on one wing), that code might not ever get exercised in real life until something goes somewhat wrong.

And if there's a bug in that section of code, it may turn a "somewhat wrong" situation into a "catastrophicly wrong" situation. I would take a good hard look at the possibility that unusual drag (or loss/corruption of sensor input) may have caused the computer to overcorrect at Mach 20 (with disasterous results).

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.

These are the ones that only manifest themselves when a rare set of circumstances combine.

I can easily see something like that happening in the Columbia disaster -- a bug or poor design decision in an ancient piece of code which never rose itself from slumber until the very first time a high-drag-on-the-left situation ever occurred.

Greetings Dan Day, FReepers, et al:

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.

Your discussion of software glitches brings to mind an often-overlooked feature of software-implemented PID controllers that occasionally is overlooked in testing. Those familiar with control theory will understand the phenomenon of integrator wind-up. Basically a very large error signal is generated and that causes the integral of E to be even larger. It is absolutely essential that there be some hard-coded feature to limit error correction under these conditions, preferably with backups, like redundant code segments and/or hardware limits. So certainly some desk-checking of the code would be a first step.

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.