Transcript Document

Avionics Processing Evolution
– Apollo to Constellation
Mike Aucoin
Division Leader – Guidance, Navigation and
Control Flight Systems
Draper Laboratory
March 4, 2008
Version 1.0
1
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
Version 1.0
2
Apollo/Constellation – Same or Different?

Development of the AGC pushed/drove the state of the art.



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.


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.
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.


Version 1.0
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.
3
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.


Version 1.0
Manual switching from PFCS to BFCS
Different software load and less redundancy for on-orbit operation
4
X-38 – COTS, Dual Fault-tolerant



FCP
FCP
Parafoil
and Chute
GPS
Aerosurface
Data
Acquisition
Communication
s
Subsystem Communications/Control
Buses
Power Control Subsystem
FCC 1
FCC 2
FCC 3
FCC 4
MPCC
Analog Out
Digital I/O
MPCC
Analog Out
Experiments
Digital I/O
Digital I/O
Digital I/O
Digital I/O
Digital I/O
Digital I/O
Decomm
Digital I/O
Decomm
s
Attitude
Control
ICP
ICP
VME Bu
Deorbit
Module
ECLSS
Network
Element
Network
Element
NEFU
s

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
VME Bu

F
C
C
3
F
C
C
4
F
C
C
1
F
C
C
3
F
C
C
4
F
C
C
1
F
C
C
2
Power
Supply
voter
F
C
C
4
Power Control subsystem
F
C
C
1
F
C
C
2
F
C
C
3
Network
Element
Decomm
Digital I/O
Digital I/O
Digital I/O
Digital I/O
Analog Out
MPCC
ICP
Network
Element
ICP
FCP
X-38 Processing Architecture
Version 1.0
Network
Element
Decomm
Digital I/O
Digital I/O
Digital I/O
Digital I/O
Analog Out
MPCC
ICP
FCP
X-38 Fault-tolerant Computer
5
VME Bus
F
C
C
2
Power
Supply
voter
Power
Supply
voter
VME Bus
Power
Supply
voter
VME Bus
FTPP
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)
Version 1.0
Russian Service Module
TC Computer
6
Constellation – Trends





Size, Weight, and Power … Size,
Weight, Weight
Weight and Power … 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
Version 1.0
7
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.

Version 1.0
8