Conference 7.286::space

    The shuttle has been plagued by computer problems from the outset.
    
    Anyone else recall watching the first launch attempt of Columbia?
    "Columbia, this is Houston. We want you to try something. Press
    HALT, LOAD ADDRESS, 0, 0, 0, 0, START".....
    
    I think part of their problems stem from the fact that they are
    using very old equipment that is no longer manufactured (IBM AP-701
    avionics processors). Probably the correct decision when it was
    made in the early 70s, but now I suspect they have a hard time finding
    anyone who knows how to program them.
    
    Was STS-19 the flight where the computer wanted to shutdown a second
    engine and the pilot & capcom decided to override and continue to
    orbit?
    
    gary

    I don't doubt that there have been a number of comp-related problems.
    However, I am mildly suspicious of the stuff related in .0, since
    the incident that I remember well is not reported quite correctly
    (but the details make a difference).  As I recall, in STS-19, the
    sequence was
    
    	1.  1 of 2 thermocouples fails.  GPC rejects bad one and takes
    		good one.
    
    	2.  Second thermocouple fails.  GPC shuts down the engine.
   
    	3.  They immediately declare ABORT ATO (I heard the call...it
    		was one of the most chilling feelings in my life, but
    		that was before Jan 28, 1986).
    
    	4.  Other sensors seem to be doing odd things.  Astros tell the
    		gpc's to ignore the sensors on the remaining engines.
    

        5.  They end up in a too-low orbit and use lots of OMS fuel
    		to get close to the right place.  They are restricted
    		in OMS usage for the rest of the mission, although it
    		did run the normal length.
    
   FYI, the STS-1 problem was a synchronization issue.  I think it was
    between the GPCs and a component called the MDM
    (multiplexer/demultiplexer).  There was a timing window somewhere
    such that if you turned on the MDM during this window (back early
    in the count) then at T-31, the GPCs suddenly notice a timestamp
    skew.  This had happened once before during GPC testing, but IBM
    could never reproduce it nor figure it out.  A lot of midnight oil
    was burned between the first attempt and the second (successful)
    one to understand the problem.  They figured out that if the MDM
    was turned on at the right time, it did not pose a hazzard during
    the rest of the mission.  Thus, STS-1 flew with the bug; it was
    fixed later, after several flights.
    
    And finally, a personal note:  The failure in STS-9 was actually
    a lucky thing for me.  I was in CA (Orange County) that week on
    business, and I decided to take the day off and drive out to EAFB
    for the landing.  This was a high-inclination Spacelab mission,
    so it turned out that there were two landing opportunities that
    day.  They scrubbed the first one, which would have been on the
    ascending node of the orbit (i.e. coming from the south-west). 
    The second opportunity, which they took, was landing from the
    descending node of the orbit (from the north-west).  Because of
    the directions, energy situation, etc, they had to do nearly a 360
    around the HAC (heading alignment circle) which brought them directly
    over the parking lot where they let us civilians watch.  What a
    thrill!!  A beautiful view.  You can believe that the steep angle
    you see the shuttle diving at on TV is not a figment of camera angle
    or anything else.  That sucker is dropping!
    
    Enough rambling,
    
    Burns
    

Newsgroups: sci.space.shuttle
Path: decwrl!Angelo!labrea!rutgers!att!ihlpm!dcn
Subject: Programmers nervous during Discovery mission - IEEE Software
Posted: 30 Jan 89 19:10:19 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
 
    I just read a short article in the January 1989 issue of IEEE
Software magazine about changes in the ground software systems that
support the US Space Shuttle program.  It contains part of an
interview with Jack Munson, the vice president and general manager of
Unisys's Houston operations, which runs the ground-based software
systems of the shuttle, including telemetry and simulators.  The
software contains 14 million lines of code (not counting the OS or
compilers), which  went through 3,800 requirements changes and 900
releases, three of which were major upgrades.  The hardware systems
were also updated from 1970s technology to the 1980s.  In spite of all
these changes, only one new bug was found during the Discovery mission
last fall, a 30 second lapse in telemetry recording, which was traced
to a requirements problem.  There were other known non-critical bugs,
averaging about 1,800 (or about 1 bug per 7,700 lines) over time. 

    Dave Newkirk, att!ihlpm!dcn

    re: .2
    
    If you have watched PBS's Fronline report on the Shuttle
    (post-Challenger), the ATO sequence was caught on film (in Mission
    Control).  I don't recall seeing the launch myself, but viewing the
    tape of what happened in Mission Control and the decision that the
    Launch Director (or is it the Mission Director at that point?) had to
    make in the span of about 15 seconds was gut-wrenching.
    
    The astronauts were interviewed afterwards and discussed the abort.
    To say they felt concerned when Houston instructed them to inhibit the
    main engine overrides is one of the bigger understatements of the
    century.
    
    
    How's the song go: "on the leading edge of life"?
    
    - dave