Voici comment fonctionnait l’ordinateur de bord du programme Apollo, l’AGC

Pourquoi l’AGC est-il emblématique

L’Apollo Guidance Computer (AGC) n’était pas seulement un ordinateur de son époque : il incarnait une philosophie de conception complète. Conçu pour un environnement où l’erreur avait un coût incalculable, où les ressources étaient limitées et où les mises à jour logicielles étaient pratiquement « gravées dans la pierre » grâce à la mémoire core rope, il imposait une discipline stricte dans la conception matérielle et logicielle. Ses principes restent d’actualité aujourd’hui dans les systèmes embarqués, la robotique, l’aérospatial et les systèmes temps réel. Dans cet article, nous examinerons en détail : le format de mot, le jeu de registres, l’organisation mémoire, la commutation de banques, les entrées/sorties et l’interface DSKY ; le planificateur Executive/Waitlist ; les fameux alarmes 1201/1202 ; et enfin une comparaison avec les montres connectées et smartphones modernes.

Exigences physiques et environnementales

L’AGC équipait à la fois le module de commande (CM) et le module lunaire (LM). Il était conçu pour résister aux conditions extrêmes de l’espace : vibrations, variations de température, vide, rayonnement et interférences électromagnétiques. L’ensemble pesait environ 30–32 kg et consommait environ 50–60 W. Sa conception modulaire, avec des cartes soudées et des connecteurs standardisés, réduisait les points de défaillance mécanique. Objectifs : compacité, gestion thermique stable, maintenance simple et diagnostic rapide.

Circuits intégrés et logique : la philosophie du « tout NOR »

Le design Block II s’appuyait sur l’utilisation massive de circuits intégrés au silicium. La logique était de type RTL (Resistor-Transistor Logic) à base de portes NOR à 3 entrées. La porte NOR est universelle : toute fonction booléenne peut être réalisée à partir d’elle. Le cœur du processeur – ALU, logique de contrôle, multiplexeurs, machines d’état – fut construit uniquement avec ce type de porte. Résultat : simplification de la production et de l’assurance qualité, fiabilité accrue, moins de soudures et de risques de panne.

Format de mot et arithmétique

L’AGC utilisait un mot de 16 bits : 15 bits de données et 1 bit de parité. Le bit de parité servait à détecter les erreurs ; l’arithmétique fonctionnait en complément à un avec bit de débordement dédié. C’était simple, déterministe et parfaitement adapté à la technologie de l’époque. Le calcul en virgule fixe évitait le besoin coûteux d’une unité de virgule flottante, les algorithmes de navigation, de contrôle et de filtrage étant conçus pour ce format.

Registres et jeu d’instructions

Registres principaux :

• A – accumulateur, registre résultat de l’ALU

• Z – compteur ordinal (PC)

• Q – reste de division / retour de saut

• LP – partie basse d’un produit de multiplication

Le jeu d’instructions était réduit (environ trois douzaines d’opcodes), mais adapté à la mission. Les instructions simples étaient rapides, celles impliquant la mémoire ou les multiplications/divisions plus lentes. Temps d’exécution : 10–100 µs, soit plusieurs dizaines de milliers d’instructions par seconde. La prévisibilité comptait plus que la vitesse brute.

Horloge et base de temps

Une référence quartz de 2,048 MHz alimentait une horloge interne quadriphase de 1,024 MHz, pilotant la logique, les accès mémoire et les interruptions. Des signaux dérivés (~100 Hz) cadencèrent les compteurs temps réel et les tâches périodiques. Cette base de temps déterministe garantissait que les boucles de GN&C (Guidance, Navigation & Control) fonctionnaient avec des délais constants.

Architecture mémoire : Core-RAM et Rope-ROM

La mémoire effaçable était du RAM à tores magnétiques, 2 048 mots (~4 kB). La mémoire fixe était le fameux Rope-ROM : environ 36 864 mots (~74 kB). Chaque bit était codé par un fil tissé à travers un tore (1) ou contournant le tore (0). Ainsi, le logiciel était « tissé » de façon permanente. Conséquence : des processus de vérification et de qualité extrêmement rigoureux, car modifier un exemplaire en vol était impossible.

Commutation de banques et discipline logicielle

Le champ d’adresse effectif de 12 bits nécessitait la commutation de banques pour accéder à l’espace mémoire complet. Le RAM était organisé en pages de 256 mots, le ROM en banques plus larges. Une discipline stricte de « bank hygiene » imposait conventions d’appel, sauts, retours et macros, afin de garantir que le code se trouvait toujours dans la bonne banque.

Système d’E/S et périphériques

L’AGC communiquait via des canaux d’E/S avec :

• IMU (Inertial Measurement Unit) : gyroscopes et accéléromètres avec compensation de dérive

• Radars : radar d’atterrissage et radar de rendez-vous dans le LM

• Contrôle de propulsion : moteur principal et propulseurs RCS

• Télémetrie et uplink : échange de données avec la Terre

• DSKY : Display & Keyboard, l’interface équipage

DSKY : l’interface Verbe–Nom

Le DSKY était une interface pionnière. Les commandes se donnaient en paires Verbe (action) et Nom (objet), par ex. Verbe 06 Nom 20 pour afficher un vecteur d’état. L’afficheur à trois champs électroluminescents et les voyants de statut (PROG, UPLINK ACTY, etc.) fournissaient un retour immédiat. Compacte, cohérente et mémorisable, l’interface était adaptée aux situations de stress. Le CM avait deux DSKY, le LM un.

Système d’exploitation temps réel : Executive et Waitlist

Le Executive était un ordonnanceur préemptif à priorité, cœur du logiciel. Les tâches GN&C critiques avaient la plus haute priorité, les autres étaient placées dans la Waitlist. En cas de surcharge, l’Executive écartait les tâches secondaires et assurait uniquement l’exécution des boucles vitales.

Les alarmes 1201/1202

Lors de l’alunissage d’Apollo 11, les alarmes 1201/1202 indiquèrent une surcharge de l’Executive, due à des interruptions supplémentaires du radar de rendez-vous. Le système réagit comme prévu : les boucles critiques continuèrent, les tâches secondaires furent suspendues. Les données essentielles restèrent sauvegardées. Ce n’était pas un crash, mais un comportement fail-operational voulu – un triomphe d’ingénierie.

Navigation et contrôle : fusion de capteurs, Δv, DAP

Le logiciel intégrait en continu les données de l’IMU, corrigées par modèles de dérive et alignements périodiques. Les optiques du CM donnaient des références stellaires, les radars du LM complétaient les mesures. La fusion de données se faisait en virgule fixe. Pour les corrections de trajectoire, l’AGC calculait le Δv, la durée de combustion et les profils ; le DAP (Digital AutoPilot) générait les commandes moteurs et RCS.

Lignes logicielles : Colossus et Luminary

Le CM fonctionnait avec Colossus, le LM avec Luminary. Tous deux écrits en assembleur AGC, avec des conventions strictes, beaucoup de commentaires et une structure modulaire. Le Rope-ROM avait de longs délais de fabrication : les versions étaient rares mais stables. Pas de modifications de dernière minute – la qualité préventive primait.

Développement et assurance qualité

Le code était assemblé sur mainframes, avec assembleurs et simulateurs spécifiques (IMU, DSKY). La compilation produisait une « liste de tissage » pour le Rope-ROM. Suivaient des tests électriques, fonctionnels, thermiques et vibratoires. La discipline de codage était vitale.

Performances en chiffres

• Longueur de mot : 15 bits de données + 1 parité

• RAM : 2 048 mots (~4 kB)

• ROM : ~36 864 mots (~74 kB)

• Horloge : 2,048 MHz → 1,024 MHz interne

• Temps d’instruction : 10–100 µs

• Débit : dizaines à centaines de milliers d’instructions/s

• Consommation : ~50–60 W

• Masse : ~30–32 kg

Par rapport aux standards actuels, niveau microcontrôleur – mais il pilotait la mission la plus exigeante de l’histoire.

Fiabilité et tolérance aux fautes

• Parité sur chaque mot

• Watchdog/Reset avec conservation d’état

• Protection par priorité : les tâches critiques toujours exécutées

• Robustesse physique : composants qualifiés spatial

• Simplicité : petit code, peu d’opcodes

Pourquoi pas de virgule flottante ?

La plupart des calculs étaient reformulés pour le fixe, avec normalisation et échelles. La virgule flottante n’était qu’émulée au besoin, rarement.

Était-il « faible » ? – replacé dans son contexte

« Nos téléphones sont des milliers de fois plus puissants » – vrai en MIPS, mais trompeur. Les smartphones optimisent le débit et les usages multimédias ; l’AGC garantissait le temps réel déterministe. Il n’était pas plus rapide – mais prédictible, quand la vie en dépendait.

Comparaison avec les appareils modernes

Ressources brutes

• AGC : ~0,1 MIPS, ~4 kB RAM, ~74 kB ROM, ~1 MHz interne

• Montre connectée : multicœur 1–2+ GHz, 1–2 GB RAM, 8–64 GB Flash, souvent DSP/NPU

• Smartphone : big.LITTLE 3+ GHz, 6–16 GB RAM, 128 GB–1 TB stockage, GPU/NPU

Jeu d’instructions et programmabilité

AGC : petit ISA, commutation manuelle de banques, calcul fixe. Aujourd’hui : 64 bits, Out-of-Order, SIMD, JIT, haut niveau. Productivité infiniment plus grande – mais les garanties temps réel nécessitent souvent RTOS ou microcontrôleurs dédiés.

Temps réel et gigue

AGC : cadencé de manière déterministe. SoC modernes : optimisés pour la latence moyenne ; la gigue contrôlée par cœurs isolés, priorités RT ou microcontrôleurs always-on.

Énergie et chaleur

Par opération, les puces actuelles sont beaucoup plus efficaces – mais leurs tâches sont plus larges. L’AGC consommait ~50–60 W dans un profil fixe, acceptable dans l’architecture Apollo.

Fiabilité et mises à jour

Rope-ROM immuable, vérifié à l’extrême. Téléphones et montres : OTA, flexibilité, mais moins de preuve formelle. En contrepartie : corrections rapides et évolution.

Leçons d’ingénierie système

1. Priorités strictes : la boucle critique gagne toujours

2. Cadence déterministe : profils de gigue connus, fenêtres d’exécution garanties

3. Discipline mémoire : commutation de banques, frontières modulaires

4. Fail-operational : reset ≠ échec si l’état est préservé

5. Simplicité + QA : moins de portes/ICs = meilleure testabilité

Idées reçues

• « L’AGC n’était qu’une calculatrice. » Faux : faible MIPS, mais fiabilité déterministe inégalée.

• « Les alarmes 1201/1202 ont failli détruire Apollo 11. » En réalité, elles ont montré que la protection fonctionnait.

Fiche rapide

• Développeur : MIT Instrumentation Lab / Raytheon

• Architecture : logique RTL NOR, mot 16 bits (15 données + 1 parité)

• Mémoire : 2k mots RAM, ~36k mots Rope-ROM

• Horloge : 2,048 MHz → 1,024 MHz interne

• OS : Executive/Waitlist, ordonnancement temps réel préemptif

• Interface : DSKY Verbe/Nom, affichages électroluminescents, voyants

• Périphériques : IMU, radars (LM), RCS/moteurs, télémétrie, uplink

L’histoire de l’AGC ne concerne pas « combien peu il faisait », mais qu’il faisait exactement ce qu’il fallait, avec une fiabilité incroyable. Simplicité stricte, gestion disciplinée de la mémoire et du temps, tests rigoureux. Lors des alarmes 1201/1202, il ne montra pas une faiblesse mais une force : l’ordinateur fit exactement ce pour quoi il avait été conçu – protéger la mission. Aujourd’hui, nous comptons sur la puissance brute ; l’AGC nous rappelle que la bonne architecture et la discipline temps réel sont irremplaçables. Ce « moins mais sûr » a mené l’humanité sur la Lune – et distingue encore un prototype d’un système fiable.