A 1000-year uncrewed lunar preservation facility cannot be managed by a single “superintelligent” controller. It requires a layered, conservative autonomy architecture: deterministic safety systems below, radiation-tolerant computing in the middle, and bounded AI decision support above. The governing objective is not optimisation or exploration; it is preserving stored knowledge, biological materials, machines, and the ability of future humans to recover them.
1. Mission requirements
The facility must survive:
- 1,000 years without continuous human maintenance
- Lunar vacuum, abrasive regolith, thermal cycling, micrometeoroids, solar-particle events, and galactic cosmic rays
- Long communication outages lasting months or years
- Component degradation, memory corruption, sensor failure, software obsolescence, and loss of external navigation or timing services
- Unknown future recovery conditions
The architecture should assume that most individual components will fail during the mission. Survival therefore depends on redundancy, isolation, graceful degradation, and periodic self-repair, not on any individual processor or AI model.
A practical design target is a minimum of three physically separated computing and power-control zones, with independent sensors, clocks, storage, and thermal paths. Critical records should exist in at least five geographically separated vaults, with independent error-correcting codes and at least one read-only master copy per vault.
2. Fault-tolerant computing
### 2.1 Layered architecture
The computing system should use six layers:
1. Passive preservation layer
- Mechanical safeties, pressure relief, thermal cut-outs, fuses, radiation shielding, and passive thermal regulation.
- These functions must remain safe even if every processor is off.
2. Hard real-time safety controller
- Small, formally verified processor.
- Controls power isolation, heaters, valves, fire or pressure events, vault access, and emergency shutdown.
- No machine-learning code should have authority over irreversible safety actions.
3. Redundant supervisory computers
- At least three independent channels using dissimilar hardware and separately compiled software.
- Two-out-of-three voting for ordinary control decisions.
- Four-channel voting is preferable for high-consequence functions, allowing one failed or compromised channel without losing control.
4. Fault-management layer
- Detects failed sensors, processors, memory banks, communication links, and power units.
- Reconfigures the system around failed elements.
- Maintains a signed event log and preserves the pre-failure state for later diagnosis.
5. AI planning and diagnosis layer
- Performs anomaly classification, predictive maintenance, thermal and power scheduling, and recovery planning.
- It proposes actions but cannot bypass lower-level interlocks.
6. Human-recovery interface
- Exposes system state through durable machine-readable documentation.
- Supports command protocols that can be reconstructed by humans unfamiliar with the original software.
NASA’s High Performance Spaceflight Computing programme illustrates the direction required: its 64-bit multicore system combines radiation-hardened-by-design circuitry, error detection and correction, hardware fault containment, hardware redundancy, and software-managed fault tolerance.[1][6]
### 2.2 Error detection and correction
Every critical data path should use:
- ECC memory, preferably correcting at least single-bit errors and detecting double-bit errors
- End-to-end cryptographic hashes for files and records
- Periodic full-volume scrubbing
- Independent metadata copies
- Versioned software and configuration images
- Write-once or physically immutable recovery images
- Merkle-tree or equivalent hierarchical integrity records for large archives
The controller should distinguish:
- Transient faults: retry, scrub, and continue
- Intermittent faults: isolate the component and reduce its duty cycle
- Permanent faults: mark unavailable and reconfigure
- Correlated faults: enter protected mode because a solar event, thermal excursion, or common software defect may affect multiple channels
A single checksum is insufficient. An archival record should be accepted only when its content hash, replica agreement, storage-medium health, and schema validation all pass.
### 2.3 Redundancy without common-mode failure
Triple modular redundancy is useful but not sufficient. Three identical computers running identical software can fail identically because of the same design flaw, radiation-induced instruction error, corrupted update, or bad sensor.
The facility should therefore combine:
- Hardware dissimilarity: different processor families or FPGA implementations
- Software dissimilarity: independently developed critical kernels
- Temporal redundancy: repeat a calculation after a delay
- Analytical redundancy: compare sensor data with physical models
- Physical separation: separate vaults and cable routes
- Functional diversity: use different algorithms for the same safety decision
NASA describes time-triple modular redundancy as a method for improving single-processor tolerance to single-event upsets, while hardened-core circuits can detect functional interrupts and escalate from interrupt to reset procedures.[2] These techniques should supplement, not replace, system-level replication.
3. Radiation-hardened processors
### 3.1 Threats
Lunar electronics face three principal radiation failure modes:
- Total ionizing dose (TID): cumulative degradation of transistors and insulating materials
- Single-event effects (SEE): errors caused by individual energetic particles
- Displacement damage: lattice damage that degrades semiconductor performance
Single-event effects include:
- Single-event upsets in memory or registers
- Single-event transients in logic
- Single-event functional interrupts
- Single-event latch-up, potentially causing destructive current surges
Radiation protection must therefore address both gradual aging and instantaneous faults.
### 3.2 Processor selection
NASA’s HPSC design specifies a 200 kilorad total-ionizing-dose requirement and uses radiation-hardened-by-design measures against single-event effects.[1] It also supports ECC, hardware fault containment, optional core-level redundancy, and software fault-management hooks.[1]
For a millennium installation, a 200-kilorad qualification target should be treated as a minimum component specification, not the facility-wide survival guarantee. The system should add:
- Local shielding around processors and memory
- Rad-hard SRAM or nonvolatile memory
- Current limiting and latch-up protection
- Cold-spare processors kept powered down
- Periodic processor health tests
- Radiation dosimeters beside every computing cluster
- A radiation-event mode that suspends