Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!elroy!jpl-devvax!beowulf!david
From: david@beowulf.JPL.NASA.GOV (David Smyth)
Newsgroups: sci.space.shuttle
Subject: Re: Shuttle computer reprogramming
Message-ID: <2994@jpl-devvax.JPL.NASA.GOV>
Date: 5 Oct 88 21:19:18 GMT
References: <6689@nsc.nsc.com> <6980@ihlpl.ATT.COM> <1938@kalliope.rice.edu> <2993@jpl-devvax.JPL.NASA.GOV>
Sender: news@jpl-devvax.JPL.NASA.GOV
Reply-To: david@beowulf.JPL.NASA.GOV (David Smyth)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 59

-In article <2993@jpl-devvax.JPL.NASA.GOV> leem@jplpro.JPL.NASA.GOV (Lee Mellinger) writes:
->In article <1938@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) writes:
->|In article <6980@ihlpl.ATT.COM> knudsen@ihlpl.ATT.COM (Knudsen) writes:
->|
->|>One of the flight crew said that every time they want to
->|>put a new capability into the computers (like yet another
->|>emergency abort scenario), something else has to be
->|>taken out.
->|
->|This is true.  The software used on ascent almost completely fills the
->|memory capacity of the computers.  To add anything requires removing
->|something else (or at least getting the memory from somewhere).
->|
->|>So I'll bet every byte of that code is hand-optimized
->|>to hell and back.  I doubt any hi-level language,
->|>or even C, got anywhere near those computers.

I am absolutely certain that the code could be re-written to free-up alot
of space.  I got the OK to re-write what I was responsible for, but it
was a HUGE hassle.  That code has NOT been hand optimized to hell and back,
it has been hand PATCHED, in machine code, to hell and back!  Why?  Because
the code has undergone lengthy, very expensive testing over the last decade
and a half, and nobody wants to give the compiler a chance to screw things
up.  Every once in a long while, a routine will be re-compiled, but only after
all attempts to just patch it are exhausted.

->|seen some of the flight software (about a page or so) and it looked a
->|whole lot like IBM assembly language.  When I saw "BAL" I knew instantly
->|what it meant.

Probably you saw the patches for existing code.  As far as I know, the initial
implementation of all routines was done in HAL/S, and modifications then done
in AP-101 machine code.

->The computers are 4Pi/AP-101's which are esentially ruggedized IBM
->360's in a small box.  That is the four prime computers, the fifth is
->a Rockwell/Autonetics machine.  All four are online during launch and
->landing on a synchronized bus.  They all vote on the solutions, and if
->one dissagrees, the others vote it out and it is taken offline.  The
->Autonetics machine is there in case there is a generic HW or SW
->failure that would take out all four prime machines.

When was this change implemented?  Originally, all 5 machines were AP-101s.
The four primaries ran IBM developed PASS Primary system, and the one
back-up was an identical AP-101 running an Intermetrics developed BFS
Backup Flight System.  All 5 online at launch on the synchronized bus,
the fifth watching for anytime the primaries disagree, and annunciating the
errors to the pilots.  The pilots can manually disable any of the 4 primaries
which are failing, but the standard procedure (was - still is?) to switch
to the BFS and abort.

The backup was an afterthought to take care of generic SW failures.  The
SW architecture of the BFS is completely different from the PASS in case
there is some bizarre architectural problem nobody found during testing:
for example, loss of synch at boot, which was only discovered (well, correctly
diagnosed) following the launch hold at T-12 minutes on the first flight!

I do not believe the backup computer is in any way different from the
primaries.