Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!husc6!rice!titan!phil From: phil@titan.rice.edu (William LeFebvre) Newsgroups: sci.space.shuttle Subject: Re: ANSWERS: Reprogramming, plume, etc... Message-ID: <1952@kalliope.rice.edu> Date: 3 Oct 88 17:30:49 GMT References: <981@netxcom.UUCP> Sender: usenet@rice.edu Reply-To: phil@Rice.edu (William LeFebvre) Organization: Rice University, Houston Lines: 118 In article <981@netxcom.UUCP> ewiles@netxcom.UUCP (Edwin Wiles) writes: >Reprogramming: > Seems that flight control data is built into the program to > compensate for the expected winds, and nature simply didn't > coooperate right away. > > Why isn't it set up to read the data in? As I have said before, it's not that simple. > a) EXTREMELY LIMITED MEMORY!!! Anyone nowadays can go into > a store and purchase more computing power and memory than > all five of the Shuttle computers combined. At the time the on-board computers were designed and built, this was not the case. IC and other computer technology has literally exploded in the past 5 years. The first shuttle was launched in 1981? Right? 81 or 82. How easy was it to buy a Sun-like workstation at that point in time? Not very. How easy was it to buy 1 megabyte memory boards then? Not very. The point being that since the shuttle program "got off the ground" many advances have been made in computer-related technologies. > b) MAN RATING. Anything that changes, and has to do with > a manned space shot, must be 'man rated'. This is a very > expensive and time consuming process. Thus, if they had > changed the software, they would have had to go through > the man rating process. What is this "man rating" you are talking about? Do you mean safe enough to trust a human's life to? NASA takes that very seriously. It is extremly difficult to make any changes to the on-board flight software. Almost impossible, in fact. Would you trust *your* life to someone else's running computer program? > Why don't they upgrade? See "MAN RATING". Not to mention > the fact that all the systems are set up to work with the > existing computer design. You'd probably have to redesign > nearly everything. An upgrade is, in fact, in the works. I don't know all that it includes, but I have heard that it will include going to static RAM (and more than 208K half-words as well). >FLAME PLUME: > [Pers'naly, I'm > still suspicious, but NASA knows it's neck is on the chopping > block. One more serious screwup and we won't *have* a space > program, *at* *all*.] But NASA couldn't care less about the crew's safety, right? :-) >CANCELED HOLD AT T-31 SECS: > > Apparently the launch sequencer is set up to abort if anything > is out of parameters at T-31 seconds. The program that monitors > the cabin air pressure and O2 content showed a discrepancy in > the O2 content. The possibility of this discrepancy showing up > had been discussed quite some time before the launch. The program > had not been constructed to take the effects of the crew's pressure > suits into account. When that was confirmed as being the reason > for the potential hold, it was overriden by the controlers before > it had a chance to stop the launch. Why wasn't the program > rewritten? See "MAN RATING", above. [ Lord give me patience! ] I will try to be nice, okay? There was a great deal of discussion before launch that the O2 level in the cabin was close to the limit, but not yet over it. They discussed the problem and decided (with the crews' consent, I might add) that it was not serious enough to stop the launch. The on-board computers monitor many different discrete values, such as the air's O2 content. There are constants in the program that delineate the range in which each value should be to be considered "nominal". If one of those values goes out of range (either too high or too low), the computers issue a warning. When the ground launch sequencer takes over, if it sees such a warning, it will stop the countdown at T-31 seconds. This is what almost happened. The computers indicated (at around 70 seconds if I recall) that there was a problem, and the launch controllers anticipated a hold at T-31. So why can't these constant limits be changed? Edwin Wiles would have us believe that they were hard coded into the program and changing one would requre rewriting the program, thus requiring it to be recertified (or re-"man rated" as he puts it). This is simply not true. I wish Mr. Wiles would give the designers and programmers more credit than that. These values can be changed through something the controllers call a TMBU (I have no idea what that acronym stands for). It requires sending a command up from Mission Control in Houston. The next obvious question is then "if they knew ahead of time that the alarm might go off, then why not change the upper limit"? Well, they have done pre-launch TMBUs in the past and they have had a few (a *very* few, but a few) bad experiences with them--- that is, there was a mistake in the uplinked TMBU and it caused more problems than it fixed. During the 2.5 year hiatus, they polled all the mission control disciplines and asked "are there any pre-launch TMBUs that you really need to do"? Everyone said "No, I guess not." So they decided "no more TMBUs after a certain point in the countdown." Basically, they don't trust the procedure. That is why they did not do it this time. Yes the alarm might go off, but they already know to override it. Why take the chance on a TMBU when you don't need to? The controllers on the ground can still see the actual O2 level and they can tell if it gets way too far out of nominal (in other words, the computer warning is not the only data that the ground controllers see). > The crew boarding was delayed for aproximatly 30 Mins due to > a simple 5A fuse burning out in the Commander's suit cooling > fan. Seem's they had some trouble locating a replacement. [ Lord, I think I need some more of that patience. ] There were no available replacement fuses on the shuttle. One had to be sent up from the ground. BY DESIGN, nothing important is close to the launch pad---they probably had to send one out from the VAB, 3 miles away. They didn't necessarily have "trouble locating a replacement", they just had a long way to go to get it out to the pad. William LeFebvre Department of Computer Science Rice University