Shuttle Launch Delayed Again, Possibly Until December

An anonymous reader writes "NASA engineers worked overnight trying to fix the electrical problem that forced the launch of space shuttle Discovery to be delayed again. Mission managers will meet later Wednesday to figure out if a launch on Thursday is even possible. The tentative plan is to have Discovery lift off Thursday at 3:29pm. If that does not happen it would be rescheduled for Sunday. If it cannot launch Sunday then it will have to wait until December. NASA engineers have a lot of work on their hands Wednesday morning. Discovery has an electrical issue that forced officials to postpone its liftoff, which had been rescheduled for Wednesday afternoon."

Comments

Troubleshooting

[Anonymous Coward]

Did they check if it's plugged in?

Have they tried turning it off and on?

The Problem Casuing the Delay

[BJ_Covert_Action]

This article contains some more specifics regarding the problem. Apparently one of the main engine controller computers (the computers that regulate main engine gimbaling and throttle control) failed to power up properly. There was a short time period where a low-voltage occurred which flagged a boot-up sequence issue. Engineers are trying to figure out what caused the voltage drop and, thus, triggered the error in the processor initialization. More information regarding the SSME controllers can be found here.

Apparently the breaker that controls the processor was cycled five times over night. Engineers are guessing that the cycling caused some funny transient anomalies in the circuit which caused the fault. Despite the fault, the main events controller for the shuttle system was brought to full power and is operating nominally, so it's not like the whole computer is crap. NASA just wants to be sure that, a) the fault was actually caused by the breaker cycling and b) the fault won't cause further glitches in any of the other controller systems on the shuttle.

Interesting stuff indeed. It's probably a good thing that NASA is demanding certainty from it's engineers before clearing Discovery for launch.

Re:The Problem Casuing the Delay

[0123456]

And part of the reason I don't trust private sector space exploration at this stage of space exploration..

Any private launch company who killed its passengers one time in fifty would be out of business very fast. As far as I remember Branson is planning over a hundred test flights before putting passengers on SS2.

And the main reason this is an issue is because a failure which caused an engine shutdown early in the flight would require an RTLS abort which is probably unsurvivable, and a failure later in the launch would require an ATO abort which would prevent them from getting to ISS.

Re:The Problem Casuing the Delay

[Thud457]

Technically correct, most computer problems are at one level, electrical problems.

I'll have to remember that one for the excuse list...

Re:The Problem Casuing the Delay

[BJ_Covert_Action]

Well, believe it or not, the type of data that reflects this particular fault would need to be gathered just to allow the engine controllers to function properly. In other words, the redundancy that is built into such a two channel system is in-built so that both processors can check one another in order to have one more reference input to their feedback loop. If I have controller 1's best estimate of the current system state, and I have controller 2's best estimate of the system state, and I have a third estimate of the system state uploaded to the launch vehicle through telemetry resources based on observed flight characteristics, then then I have three system states that I can compare against one another in order to develop and process a command set for the next clock cycle. This type of three-state estimation is pretty much necessary just to damp your transient responses in any highly dynamic system within a reasonable amount of time. Without such a system, your controller often cannot damp out the transient responses for any given state variable and your system decays into an unstable (exploding) mode. In other words, no steady state is achieved.

That said, in order to achieve stable flight (something already demonstrated by the space tourism industry with SS2, Falcon 1 and Falcon 9), the space tourism industry is going to have to have these checks inbuilt on their systems. They wouldn't be able to fly without them (in fact, considering the complicated geometry for SS2, I would be extraordinarily shocked if they could achieve any stable flight without at least 4 redundant state readings). Ergo, this type of pedantry is a necessity in order to have a functioning vehicle. Thus, the likelihood of the space tourism industry killing customers by skimping on these kinds of checks seems highly unlikely, if not entirely impossible, by the very nature of designing a controllable, complicated launch vehicle. Now, don't get me wrong, the space tourism industry (and NASA) very well could kill customers by various other means. I just don't think a problem like this would be the likely cause based on little more than my own experience in designing flight controller systems (as well as an undergraduate degree focused on that subject).

Of course, you might just be trying to say that, while NASA is willing to slip a launch and miss a launch window in the name of certainty, the space tourism industry might not. Many 'dotters probably feel that an industrial launch industry would say, "Waiting a day will cost us X many dollars in profits, launch anyways!" (kind of like NASA did with Challenger). Personally, I also find this highly unlikely as dead customers don't tend to be able to spend more money on your company. If Branson blows somebody up, he can't count on them to fly a second time. Combining that with the fact that any engineers involved in such a company would promptly quit (because no engineer wants a customer's death on their conscience, trust me on that), and the company would then undergo a brutal brain drain and a period of stagnation, leads me to conclude that no entrepreneur (especially one that intends to fly on his own hardware) would be willing to take that chance. As you seem to imply, companies want, more than anything else, to protect their profit. Anyone getting involved in the commercial space industry that is flying hardware would not be so dull as to think that killing their customers will increase their profits.

Saying, "Hey look, my company is flying people into space every week!" is awesome and generates a sense of pride.

Saying, "Hey look, my company has only killed five people in the last five years!" brings on epic levels of shame and thoughts of suicide.

That is just my $0.02 on the matter though.

Re:The Problem Casuing the Delay

[Animats]

require an RTLS abort which is probably unsurvivable

It's certainly untried. There's never been a successful post-launch Shuttle abort. On three occasions, there have been shutdowns on the pad after engine start. STS-51F did an abort to orbit after an unexpected shutdown of one main engine. But that's a near-normal flight diverted to a lower orbit. The Challenger disaster was the closest to a situation when an RTLS might have been attempted, but the vehicle damage was too great to even try.

Re:Why bother?

[eln]

To be fair, if the Buran design is superior it's likely because they started with the shuttle design and improved on it, whereas the shuttle was designed from the ground up. The Russians were (and are) clearly very good at designing space vehicles, but it's a lot easier to come up with a better design if you start with the design your opponent already came up with.