Avionics Processing Evolution – Apollo to Constellation Mike Aucoin Division Leader – Guidance, Navigation and Control Flight Systems Draper Laboratory March 4, 2008

Apollo – Design for Minimum Risk Apollo Guidance Computer relied on highly dependable single-string system with extensive ground testing followed by full scale un-crewed and then crewed flight testing. Three un-crewed suborbital tests of the Apollo Command Module (CM) and Service Module (SM) launched on Saturn I-B boosters (flights AS-201, AS-203, and AS-204). Two un-crewed Earth orbital tests of the Apollo CM and SM launched on Saturn 5 boosters and flown to high altitude enabling high energy (lunar-like) entries (Apollo 4 and Apollo 6). An un-crewed Earth orbital test of the Lunar Module (LM) launched on a Saturn I-B (Apollo 5). A piloted CM and SM test in Earth orbit launched on a Saturn I-B (Apollo 7) A piloted CM, SM, and LM test in Earth orbit launched on a Saturn 5 (Apollo 9) A piloted CM, SM, and LM test in lunar orbit launched on a Saturn 5 (Apollo 10) Contingency backup employed, e.g., use of command module flight control system during ascent to earth orbit, use of the lunar module as a life boat (a la Apollo 13). Avionics technology not as vulnerable: core memory/extremely large line widths in memory. No unexplained test failures allowed: At the electronic device level, all devices were tested and if a sample in a run proved defective the entire lot was quarantined. Failed devices went through detailed teardown failure analysis to preclude defect migration problems

Apollo/Constellation – Same or Different? Development of the AGC pushed/drove the state of the art. When the program started the embedded computer technology did not exist to perform the necessary computation. Development of the AGC helped drive the semiconductor market. The development of the GN&C and AGC proceeded in parallel – up-front requirements were not in place. It took three years for the mission requirements to be solidified. The computer went through three major redesigns, largely driven by technology (e.g., development of integrated circuits) and requirements. Commonality was a major driver. There was a great desire to use the same computer in the Command Module and Lander. There was disagreement as to whether the system should be autonomous or manually operated or remotely controlled. There was a strong emphasis on making sure there were long-term stable suppliers available. The AGC development program looked across a 10-year lifespan. During that ten year period semiconductor and computer system development technology were exploding. This put constant pressure back on the AGC development program to upgrade technology.

Shuttle – Fail Op, Fail Safe “All subsystems shall be designed to fail-op … and to fail safe … after failure of the two most critical components” Redundancy and built in test -> reliability – no explicit quantitative reliability standard. Less rigorous testing than Apollo – eight piloted subsonic Approach to Landing Tests Integrated computational requirements, e.g., for GN&C More densely packed processing – increased vulnerability to radiation Two fault tolerant power distribution system and inertial measurement system Ascent and entry employed four Primary Flight Control Systems (PFCS) computers and one Backup Flight Control System (BFCS). BFCS addressed common mode failures, had separately developed/verified software. Manual switching from PFCS to BFCS Different software load and less redundancy for on-orbit operation

X-38 – COTS, Dual Fault-tolerant Able to sustain two faults while maintaining operation Maintained processing system reliability while using COTS processor boards that were less reliable Employed redundant power supplies, cross channel data link, and voting to carry out redundant calculation and protect against Byzantine failures Had to be active during critical flight phase – reentry Designed to specific reliability requirement and to be two fault tolerant Network Element ICP VME Bus FCP Digital I/O Decomm Analog Out MPCC VME Bu s Subsystem Communications/Control Buses Power Control Subsystem FCC 1 FCC 4 FCC 3 FCC 2 NEFU Power Supply voter F C C 2 F C C 3 F C C 4 F C C 1 FTPP Power Control subsystem GPS Data Acquisition Deorbit Module Attitude Control Parafoil and Chute Aerosurface Communication s ECLSS Experiments Power Supply voter Power Supply voter Power Supply voter VME Bus X-38 Processing Architecture X-38 Fault-tolerant Computer

ISS – On Orbit Operation Russian Service Module TC computer for GN&C (thruster control) is two-fault tolerant. US Module flight processor that handles attitude control employs failover operation, but not fault tolerance All processing is on orbit, not involving critical flight phase such as ascent or reentry Russian system experienced a common mode failure on STS-117 US MDM (Flight Computer) Russian Service Module TC Computer

Constellation – Trends Size, Weight, and Power … Size, Weight and Power … Weight, Weight, Weight One fault tolerance is current design criteria A variety of flight modes being addressed, e.g., ascent, on-orbit, rendezvous, descent Ares is progressing towards some sort of voting system Orion is relying on a self-checking pair with backup

Lunar – Implications There will be continued emphasis on size, weight, and power. One fault tolerance is current design criteria. There are several flight phases requiring varying levels of necessary reliability. There are several systems involved (e.g., Orion, Altair, Ares I, Ares V, Earth Departure Stage, etc.). The processing requirements of the system of systems change with mission phase and connectivity. Reconfiguration may be desirable to maximize processing throughput and reliability. Connectivity and interoperability may drive ability to accomplish reconfiguration effectively. We should explore architectures that are insensitive (less sensitive) to common mode failures. We will need to continue to tradeoff the use of COTS with required reliability. We will need to trade off required reliability with the amount and kind of testing employed.