# How the AGC's Restart System Provides Fault Tolerance in Apollo 11

> Discover how the AGC's restart system provides fault tolerance for Apollo 11. Learn about its layered architecture, phase-protected copy-cycles, and deterministic recovery paths enabling seamless operation after transient faults.

- Repository: [Chris Garry/Apollo-11](https://github.com/chrislgarry/Apollo-11)
- Tags: internals
- Published: 2026-03-04

---

**The AGC's restart system provides fault tolerance through a layered architecture of restart groups, phase-protected copy-cycles, hardware flag management, and deterministic recovery paths that allow the computer to resume operation after transient faults without requiring a full power cycle.**

The Apollo Guidance Computer (AGC) aboard the Apollo 11 spacecraft relied on a sophisticated restart system to survive transient hardware glitches during crewed lunar missions. According to the chrislgarry/Apollo-11 source code, this architecture combines software-managed phase flags, copy-cycle protection, and hardware state cleanup to enable deterministic fault isolation and rapid recovery.

## Restart Groups and Phase Flags Coordinate Recovery

The AGC organizes subsystems into **restart groups**, each identified by a group number and a signed **phase** value stored in registers like `TVCPHASE`. When a fault triggers a restart, the system sets the appropriate group bit and phase value—ranging from -2 to 3—to determine the precise recovery entry point.

These phase values map directly to specific restart handlers. For example, phase values trigger entry points such as `MRCLEAN` for full initializations or `TVCINIT4` for specific TVC (Thrust Vector Control) restart sequences. The logic that interprets these phases resides in `Comanche055/TVCRESTARTS.agc`, where comments detail how each phase value correlates with a subsystem's state.

## Phase-Protected Copy-Cycles Prevent State Corruption

Critical control loops for pitch, yaw, and roll execute as **copy-cycles** guarded by phase-point instructions. The assembly instruction `INCR TVCPHASE` marks the boundary of these protected sections, ensuring that if a restart occurs mid-cycle, the hardware completes the current cycle before transferring control to the restart entry point.

This mechanism prevents partial updates to control variables from propagating corrupted state into the resumed execution. The TVC DAP (Digital AutoPilot) copy-cycles in `Comanche055/TVCDAPS.agc` demonstrate this protection at lines 258-260, where the `PCOPY` routine increments the phase register before executing critical calculations:

```assembly
PCOPY    INCR    TVCPHASE      # restart-protect the copy-cycle (1)

         ...                   # normal pitch DAP calculations

```

Similarly, the TVC executive uses `INCR TVCEXPHS` to guard its execution phases, as detailed in the "RESTART-PROOFS THE TVC DAPS" commentary within `Comanche055/TVCEXECUTIVE.agc` and `TVCRESTARTS.agc`.

## Restart Tables and Dispatch Logic

The AGC maintains **even and odd restart tables** that store 2-address pointers (`2CADR`) and priority values (`PRDTTAB`) for jobs, wait-list calls, and long-calls. When `Luminary099/RESTARTS_ROUTINE.agc` processes a restart request starting at line 31, it retrieves the group number from `MPAC +5`, doubles it to create an index, and looks up the corresponding entry in the restart tables.

The routine then extracts the CADR and priority to dispatch the appropriate recovery task, whether a display job, a wait-list entry, or a long-call sequence. This table-driven approach allows the system to resume complex multi-tasking operations without manual state reconstruction.

## Immediate vs. Delayed Restart Handling

The restart system distinguishes between **immediate** restarts, which require instant handling of critical faults, and **delayed** restarts, which schedule resumption via the wait-list. The `TIMETEST` section in `Luminary099/RESTARTS_ROUTINE.agc` (lines 87-94) checks the `A` accumulator to determine the restart type.

If the accumulator indicates a future event, the routine calls `FINDTIME` to schedule the restart later. Otherwise, it triggers `IMEDIATE` to fire the recovery job instantly. This differentiation ensures that time-critical control loops receive immediate attention while less urgent tasks queue for the next available processing slot.

## Hardware Flag and Channel Cleanup

Before resuming normal operations, the restart system sanitizes hardware state to prevent spurious transients. Specific bits act as restart enable signals: **BIT8** (TVC enable), **BIT11** (optics-error-counter enable, set in `ENABL1`), and **CHANNEL 12** for optics hardware.

The restart package explicitly manipulates these flags using instructions like `CAF BIT8`, `AD BIT11`, and `WOR CHAN12` to establish a known safe state. Additionally, the system checks **T5 bits** (bits 15 and 14 of `FLAGWRD6`) to verify TVC readiness before re-enabling the control vector. These operations appear in `Comanche055/TVCRESTARTS.agc` at lines 61-68, ensuring hardware synchronization before software recovery proceeds.

## Specialized Recovery for Mission Scenarios

The restart logic contains dedicated paths for mission-critical edge cases. For **CSM/LM V46 switch-over** scenarios (phase -2), the system re-executes the switch-over only after the Digital AutoPilots (DAPs) reach a ready state. If a restart interrupts a **stroke test**, the `CHKSTRK` logic in `Luminary099/RESTARTS_ROUTINE.agc` (lines 12-15) terminates the test and requires a new V68 entry to restart it, preventing invalid thrust vector data.

For **Roll DAP** computations, the system simply restarts the calculations since they are non-critical for fault tolerance. These special-case handlers, documented in `TVCRESTARTS.agc` lines 80-88, demonstrate how the architecture adapts to specific subsystem requirements rather than applying a one-size-fits-all recovery.

## Code Examples

The TVC executive restart handler at `EXRSTRT` in `Comanche055/TVCRESTARTS.agc` (lines 36-39) illustrates how the system uses indexed jumps based on phase values:

```assembly
EXRSTRT  INDEX   TVCEXPHS      # go to the appropriate TVC executive restart point

         CAF     TVCEXADR
         INDEX   A
         TCF     0

```

The core dispatcher in `Luminary099/RESTARTS_ROUTINE.agc` (lines 34-56) shows how the system processes group numbers and dispatches tasks:

```assembly
RESTARTS CA      MPAC +5       # fetch group number

         DOUBLE
         TS      TEMP2G
         ...                     # determine variable vs table restart

         CA      PRIO14
         TC      FINDVAC       # dispatch display job

```

## Summary

- The AGC restart system uses **group numbers and phase flags** to select precise recovery entry points for each subsystem.
- **Phase-protected copy-cycles** ensure critical calculations complete before control transfers, preventing state corruption.
- **Restart tables** store pre-computed job addresses and priorities, enabling rapid dispatch without manual state reconstruction.
- **Hardware flag cleanup** sanitizes I/O channels and enable bits to prevent spurious outputs during recovery.
- **Specialized paths** handle edge cases like CSM/LM switch-overs and stroke-test aborts with scenario-specific logic.

## Frequently Asked Questions

### What triggers the AGC's restart system?

Transient hardware glitches, power fluctuations, or software-detected anomalies trigger the restart system. When detected, the hardware or software sets a restart request that invokes `RESTARTS_ROUTINE.agc` to begin the recovery sequence.

### How does the AGC prevent data corruption during a restart?

The system uses **phase-protected copy-cycles** marked by `INCR TVCPHASE` instructions. If a restart occurs during a protected cycle, the hardware completes the cycle before transferring control, ensuring partial calculations do not corrupt persistent state.

### What is the difference between immediate and delayed restarts?

**Immediate** restarts fire recovery jobs instantly via the `IMEDIATE` path, handling time-critical faults. **Delayed** restarts use `FINDTIME` to schedule resumption via the wait-list, suitable for non-critical background tasks. The `TIMETEST` logic in `RESTARTS_ROUTINE.agc` determines which path to take.

### How does the restart system handle CSM/LM switchovers?

For CSM/LM V46 switchovers (phase -2), the system waits until the DAPs indicate readiness before re-executing the switchover logic. This prevents thruster commands from executing while the control mode is in transition, as implemented in the phase-handling logic of `TVCRESTARTS.agc`.