1Version 1.0

Avionics Processing Evolution

– Apollo to Constellation

Mike AucoinDivision Leader – Guidance, Navigation

and Control Flight SystemsDraper Laboratory

March 4, 2008

2Version 1.0

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

3Version 1.0

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.

4Version 1.0

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

5Version 1.0

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

Subsystem Communications/Control Buses

Power Control Subsystem

FCC 1 FCC 4FCC 3FCC 2 NEFU

Power Supply voter

FCC2

FCC3

FCC4

FCC1

FCC3

FCC4

FCC1

FCC2

FCC4

FCC1

FCC2

FCC3

FTPP

Power Control subsystem

GPSData

AcquisitionDeorbit Module

Attitude Control

Parafoil and Chute

Aerosurface Communications

ECLSS

Experiments

Power Supply voter

Power Supply voter

Power Supply voter

NetworkElement

ICP VME

Bus

NetworkElement

ICP

FCP

Digital I/O

Decomm

Analog OutMPCC

Digital I/ODigital I/O

VM

E B

us

NetworkElement

ICPFCP

Decomm

Analog Out

MPCC

Digital I/O

Digital I/ODigital I/O

NetworkElement

ICP

Digital I/O

Decomm

Digital I/O

Analog Out

MPCC

Digital I/O

VM

E B

u

s

FCP

Digital I/O

NetworkElement

ICP

Digital I/ODecomm

Digital I/O

Analog OutMPCC

Digital I/O

VM

E B

u

s

FCP

Digital I/O

Digital I/ODigital I/O

VM

E B

us

X-38 Processing Architecture X-38 Fault-tolerant Computer

6Version 1.0

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

Russian Service Module TC Computer

US MDM (Flight Computer)

7Version 1.0

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

8Version 1.0

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.