Avionics Processing Evolution

1
Avionics Processing Evolution Apollo to
Constellation

• Mike Aucoin
• Division Leader Guidance, Navigation and
  Control Flight Systems
• Draper Laboratory
• March 4, 2008

2
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

3
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 GNC 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.

4
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 -gt reliability no
  explicit quantitative reliability standard.
• Less rigorous testing than Apollo eight piloted
  subsonic Approach to Landing Tests
• Integrated computational requirements, e.g., for
  GNC
• 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

5
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

Power Supply voter
Power Supply voter
Power Supply voter
VME Bus
X-38 Processing Architecture
X-38 Fault-tolerant Computer
6
ISS On Orbit Operation

• Russian Service Module TC computer for GNC
  (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
7
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

8
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.