Retour au menu principal
CONTES DE L'ORDINATEUR DE BORD APOLLO
Sur Internet, on peut trouver un rapport écrit par un membre de d'équipe qui a développé l'ordinateur de bord d'Apollo.
Le lien vers celui-ci est le suivant:
http://www.doneyles.com/LM/Tales.html
Ce rapport est supposé raconter l'histoire du développement de l'ordinateur Apollo.
Un néophyte, sans connaissance technologique, pourrait s'y laisser prendre et penser qu'ils racontent un développement normal, avec simplement des touches d'humour.
Mais pour quelqu'un ayant les connaissances technologiques suffisantes (ce qui est mon cas), c'est vraiment drôle à lire, plein d'absurdités et incongruités scientifiques, et cela révèle que l'ordinateur d'Apollo n'était en fait qu'une farce.
J'ai traduit ce rapport, et j'ai rajouté des commentaires en italique blanc que j'ai rajoutés au fur et à mesure, en les imbriquant dans le texte.
Ces commentaires sont destinés à montrer ce que ce rapport contient d'absurde.
Résumé: La mission Apollo 11 a réussi à atterrir sur la lune en dépit de problèmes liés au fonctionnement de l'ordinateur qui ont affecté le module lunaire pendant la descente. Un problème non corrigé dans le radar d'atterrissage a volé approximativement 13% du temps de cycle de l'ordinateur, résultant en cinq alarmes de programme et des redémarrages logiciels, causés par des données erronées. A cause d'un problème mal maîtrisé, causé par des données erronées, la poussée du moteur de decente du lem a anormalement fluctué parce que de l'algorithme de contrôle de la manette des gaz n'était que marginalement stable. L'explication de ces problèmes fournit une opportunité de décrire le système opératoire des ordinateurs de vol d'Apollo et le logiciel de guidage d'atterrissage.
Traduire: En dépit d'un comportement erratique de l'ordinateur de bord, les astronautes ont réussi à éviter le crash du Lem en prenant le contrôle manuel des commandes.
Figure 1: The Lunar Module
LM-1, aussi connu comme Apollo 5, était une mission inhabitée de 6 heures en orbite terrestre pour le module lunaire (LM) seulement. La date fut le 22 janvier 1968. Pour ceux de nous qui avons développé le logiciel de bord pour l'ordinateur de guidage du LM (LGC), c'était notre premier vol. Un événement qui jadis semblait impossiblement distant était maintenant à notre portée.
La mission incluait deux mises à feu du système de propulsion de descente (DPS). Pour le second "allumage", Allan Klumpp, qui a programmé les équations de guidage d'atterrissage basées sur les travaux de George Cherry, avait imaginé une version d'orbite terrestre du guidage d'alunissage. Il comportait trois parties, sensées simuler la phase de freinage, la phase de visibilité, et finalement la phase finale d'atterrissage d'une descente réelle. Mais d'abord il y avait un allumage destiné à simuler la manoeuvre d'insertion dans l'orbite qui précédait l'alunissage. Ceci devait être le premier allumage en vol de la descente du lem, durant à peu près 38 secondes.
Le LGC était en Phase 9 de la mission "en boîte" LM-1, le programme pour le premier allumage DPS. (Les missions ultérieures furent organisées plus flexiblement et le premier allumage DPS fut conduit en P40.) Le LM a maneuvré jusqu'à l'attitude d'allumage. L'ordinateur a décompté jusqu'à la mise à feu. A trente secondes, un processus appelé READACCS fut exécuté pour la première fois. Il a lu les accéléromètres en unités de mesure inertielle de navigation, initié un processus appelé SERVICER à lancer immédiatement, et puis s'est programmé lui-même pour s'exécuter deux secondes plus tard. Après avoir été initialisé avec des vecteurs d'état depuis le logiciel d'intégration orbitale de bord, les équations de navigation "Moyenne-G" de SERVICER ont commencé à utiliser les données de l'accéléromètre pour mettre à jour les vecteurs de position et de vélocité. READACCS et SERVICER devaient se répéter toutes les deux secondes tout au long de la phase de vol propulsé. Sept secondes et demie avant la mise à feu un allumage"de fuite" du système de contrôle de réaction (RCS) des réacteurs débuta, pour régler le propergol dans les réservoirs du DPS. Nous nous approchâmes de l'interphone qui nous reliait au contrôle de la mission à Houston.
Nous entendîmes "Moteur allumé"...plusieurs secondes passérent..."Moteur éteint".
Nous comprîmes bientôt ce qui s'était passé. Un petit bout de code dans SERVICER appelé le "moniteur delta-V" avait conclu que le moteur était en panne, calé, et envoyé une commande d'extinction du moteur. mais pourquoi? Pour donner au moteur le temps de générer une poussée, le moniteur Delta-V attendait toujours un petit moment après l'allumage du moteur avant de commencer à le monitoriser. Mais, cette fois, à la fin de la période de grâce, le moteur ne produisait pas encore assez de poussée pour satisfaire le critére de poussée du moniteur.
Donc, parce que le moteur était détecté comme ne donnant pas suffisamment de poussée, la bonne solution a été de l'éteindre...comme cela, il ne produisait plus du tout de poussée!
Des compte-rendus publiés ont attribué la lente montée en poussée du DPS au fait que les réservoirs du LM étaient seulement partiellement pressurisés. Les investigations de l'auteur montrent que le problème était ailleurs. pour le système d'alimentation du DPS, la procédure normale était d'ouvrir la valve qui permettait au carburant d'agir sur le collecteur d'admission du propergol au moment où le moteur était armé, plusieurs secondes avant l'allumage. Mais, sur le LM-1 la valve de contrôle qui régulait le passage du carburant depuis le collecteur d'admission vers le moteur était soupçonné d'avoir une fuite. Pour prévenir ce qui pouvait l'être, une entrée prématurée du propergol hyoergolique dans le moteur (qui aurait pu avoir des conséquences explosives), la décision a été faite, peu avant le vol, de retarder l'armement du moteur jusqu'au moment de l'allumage.
Le fait de retarder l'armement du moteur ne supprimait pas le problème de la fuite; le moteur n'exploserait peut-être pas au moement de l'allumage, mais il pouvait encore exploser plus tard.
Et, s'ils suspectaient une fuite, pourquoi ne pas tout simplement réparer cette fuite?
Généralement, lorsqu'un accident survient, la fuite n'est pas connue avant l'accident.
Ce n'est qu'après l'accident, à la suite d'une enquète, que l'hypothèse de la fuite apparaît possible.
Le moteur était lent à démarrer non parce que les réservoirs étaient moins pressurisés, mais parce que le propergol avait davantage de trajet à faire pour atteindre le moteur. Il nous aurait été facile d'ajuster le paramètre qui contrôlait combien de temps le moniteur Delta-V devait attendre avant de tester le moteur — mais personne ne nous l'a dit.
Houston a envoyé un signal pour éteindre l'ordinateur de bord. Les objectifs principaux de la mission LM-1 étaient terminés depuis un contrôle terrestre. Nous, qui avons programmé l'ordinateur du LM, secouâmes nos têtes en signe de désappointement, et dûmes souffrir une réprobation publique qui ne fit pas de distinction entre une "erreur de programmation" et une "erreur de donnée". Pourtant, cela n'a pas été la dernière fois qu'un paramètre apparemment anodin, ayant une influence sur la performance du moteur de descente, ne serait pas loin de ruiner une mission.
Une "erreur d'ordinateur", c'est quand l'ordinateur s'envoie en l'air tout seul sans raison, et une "erreur de donnée", c'est quand l'ordinateur s'envoie an l'air parce qu'il a mal interprété une donnée, et "personne ne lui a dit".
* * *
La tâche de programmer le système de guidage pour la navigation Apollo fut dévolue au laboratoire d'instrumentation du MIT à Cambridge, Massachusetts . Sous la direction de son fondateur "Doc" Charles Stark Draper, le laboratoirethe Lab a joué depuis 1939 un rôle pré-éminent dans le perfectionnement des systèmes de guidage inertiels. Notre contrat pour concevoir et programmer le système primaire de contrôle de guidage et de navigation d'Apollo (PGNCS, à prononcer "pings") était le premier contrat Apollo signé. Doc s'était porté volontaire pour la mission lui-même.
(En 1970 le laboratoire d'instrumentation fut renommé le laboratoire Charles Stark Draper, et, en 1973, il devint indépendant du MIT, quoique les deux institutions gardent des contacts. le laboratoire Draper est encore étroitement lié aux programmes de vol habité de la NASA.)
Le programme de vol pour le LM-1 fut appelé SUNBURST. Au moment où le LM-1 vola, nous travaillions déjà sur le SUNDANCE, le programme qui ferait voler les la mission orbitale autour de la terre Apollo 9 . SUNDANCE évolua à son tour vers le programme LUMINARY, le programme pour Apollo 10 et les mission d'alunissage. c'est la révision 99 de LUMINARY qui contrôla la mission Apollo 11 en juillet 1969. La révision 116 contrôla Apollo 12 en décembre et ainsi de suite.
(Ce document suit la nomenclature utilisée pendant le programme Apollo. Les noms de programme, et les noms d'étiquettes et variables à l'intérieur des programmes, étaient ordinairement écrits en lettres majuscules).
Informellement, les programmes étaient appelés "cordes" à cause de la forme en dur de la mémoire en lecture seule dans laquelle elles étaient transformées pour le vol, qui ressemblait à un entrelacement de cordes de fil de cuivre tissé. Pour les missions lunaires, 36K de mots de mémoire "fixe" (en lecture seule), chaque mot consistant de 15 bits plus un bit de parité, étaient disponibles pour le programme. De plus, il y avait 2K mots de mémoire "volatile" artistiquement partagés ou mémoire RAM. Si on fait le compte pour l'ordinateur de guidage Apollo (AGC) dans le module de commande (CM), lequel contenait un programme appelé COLOSSUS, il est correct de dire que nous avons aluni avec 152 Kilo-octets de mémoire d'ordinateur de bord.
Figure 2: Le système primaire de guidage et navigation du LM Apollo (PGNS)
L'AGC était inclus dans une boîte résistante, scellée en aluminium et magnésium, anodisée en couleur or, d'épaisseur d'environ six pouces, sur un pied par deux, pesait 70 onces et consommait environ 55 watts. Sa logique était faite de 5600 portes NOR à trois entrées rassembles par deux dans des circuits intégrés. Eldon Hall, le principal concepteur de la machine, a raconté la décision hardie d'utiliser la technologie des circuits intégrés pour cet ordinateur en dépit de son immaturité au début des années 60.
Le LGC (avec l'équipement connexe) était monté derrière les astronautes à l'arrière de la cabine du LM. Devant les astronautes, il y avait une structure rigide appelée la "base Nav" qui comportait un télescope d'alignement et l'unité de mesure inertielle (IMU) en relation géomètrique fixe. l'affichage et le clavier (DSKY) étaient montés sur un pupitre entre les deux astronautes.
le IMU, intégré dans une boîte sphérique d'à peu près un pied de diamètre, était le coeur du système de guidage. Le coeur du IMU lui-même, enfermé dans trois cardans imbriqués, était le "membre stable" — une petite plateforme contenant trois gyroscopes précis et trois accéléromètres — qui pouvaient être "alignés" vers une orientation inertielle. toute déviation de l'alignement inertiel serait detectée par les gyros, et les cardans bougeraient pour la corriger, le tout se déroulant avec tant de précision que, quelque soit l'attitude (orientation), le vaisseau prendrait (presque) le membre stable bien à l'intérieur pourvu qu'il y ait une référence d'attitude fiable. Une matrice appelée REFSMMAT exprimait l'alignement du membre stable en accord avec système de référence inertielle. Les accéléromètres étaient là pour compter les incréments de vélocité durant le vol propulsé dans le système de coordonnées du membre stable.
Figure 3: Le module lunaire d'affichage et le clavier (DSKY)
Le DSKY (Figure 3) était l'interface homme-machine principal pour le LGC. Pour l'affichage, il fournissait trois registres de cinq digits signés pour un usage général, trois registres de deux digits pour indiquer la phase courante (un nombre entre 63 et 68 pour l'alunissage), et le "mot" et "groupe" courants. Les mots et groupes fournissaient un langage primitif pour la communication entre l'équipage et l'ordinateur. Les phases et les combinaisons mot/groupe étaient déterminées par le logiciel dans certains cas, et dans d'autres cas étaient entrés par l'équipage sur un clavier de 19 touches. Le contenu de trois registres à usage général dépendait du mot et groupe courants. le DSKY contenait également un ensemble d'indicateurs lumineux qui étaient sous le contrôle de l'ordinateur, et un indicateur d'activité de l'ordinateur qui s'allumait lorsque le LGC n'était pas au repos.
Les AGC dans le LM et le CM étaient programmés en deux langages. L'un était appelé "Basic", mais plus nominativement "Yul", était un langage assembleur de quelque 40 instructions conçues par Hugh Blair-Smith. "Interpretive" était un langage interpréteur (essentiellement un jeu de sous-programmes) conçu pour faciliter les calculs de guidage et de navigation mettant en jeu la double précision (flottant 30-bit) dans les vecteurs et matrices — au coût d'un temps de traitement long. L'interpéteur était écrit par Charles Muntz.
Le temps de cycle de mémoire pour l'AGC était de 11.7 microseconds. Une addition simple-précision en langage assembleur prenait deux cycles mémoire. un calcul double précision de vecteur programmé en langage interprétif prenait environ 5 millisecondes. Un des objectifs dans la programmtion de l'AGC était de jongler entre les deux langages pour obtenir le meilleur compromis entre vitesse et compacité pour la situation donnée.
Les programmes informatiques pour Apollo étaient encore assez petits pour tenir dans un seul listing — typiquement épais de six pouces sur du papier 11x15 pouces. Le listing incluait des tables de symboles qui permettaient d'avoir une trace des séquences programmées. Avec une seul listing, nous savions toujours que la réponse était là, quand nous avions à traiter une erreur, mais ce pouvait être l'enfer pour la trouver.
J'aime cela: le programme d'ordinateur était encore assez petit pour tenir dans un seul listing...De plusieurs milliers de pages!!! (Figure 4)..Pour un listing, c'est un listing! A mourir de rire!
Figure 4: Listing du programme d'ordinateur du LM LUMINARY 131
En ce qui concerne les unités, le LGC était eclectique. A l'intérieur de l'ordinateur, nous utilisions des unités métriques, au moins dans le cas de la navigation du vol propulsé et le guidage. Au niveau opérationel de la NASA, et spécialement les astronautes, les unités anglaises étaient préférées. Cela veut dire, qu'avant d'être affichées, l'altitude le te taux d'altitude (par exemple) étaient converties du système métrique utilisé par la navigation en système anglo-saxon. Cela aurait fait drôle de parler d'altitude du vaisseau en mètres, et autant la poussée que la masse étaient exprimées en livres. Puisqu'une part de ce document est de montrer comment les choses étaient appelées en cette ére de navigation, j'exprimerai usuellement les quantités dans les unités que j'aurai senti naturelles d'utiliser à l'époque.
Donc, l'ordinateur Apollo avait déjà beaucoup de difficulté à réaliser les tâches qu'il avait à faire en temps donné (au point qu'il nécessitait parfois un redémarrage), mais il devait en plus convertir des unités pour des astronautes paresseux qui ne pouvaient pas faire l'effort de travailler avec le système métrique!
* * *
A présent l'endroit du second étage de 75 Cambridge Parkway où nous contrôlions les missions a été déplacé vers un espace plus grand, mais, en juillet 69, la salle était très emcombrée en dépit des efforts pour la garder dégagée pour ceux de nous qui étaient le plus impliqués dans cette phase de la mission. Nous écoutions dans un interphone dans une pièce quelconque, tandis qu'à un quart de million de milles un vaisseau habité emergeait de derrière la lune et approchait de l'orbite basse d'à peu près 50.000 pieds au dessus de la surface lunaire, à laquelle l'allumage d'alunissage commencerait.
L'équipage rentra le mot 37 du groupe 63 pour sélectionner P63, la phase qui contrôlait les préparations pour l'initiation de la descente propulsée (PDI) et resta en contrôle jusqu'à ce que l'allumage remplisse ses premières fonctions. L'ordinateur réalisa un algorithme pour calculer le temps exact pour la mise à feu et l'altitude à laquelle le LM devrait être à ce moment. Ensuite le vaisseau maneuvra vers cette orientation. Au moment de la mise à feu, le pavillon du moteur devrait pointer juste en avant, en directe opposition de la vélocité orbitale du vaisseau.
A présent l'ordinateur produisit le code 500. il pensait que l'antenne du radar d'atterrissage était dans une position incorrecte. L'équipage vit que les commutateurs adéquats étaient déjà dans les positions correctes, mails ils les changèrent quand même et l'avertissement disparut. ceci n'eut pas de rapport avec les événements qui suivirent, mais alimenta notre suspicion de "signaux discrets", ces signaux qui rapportent à l'ordinateur des faits comme la position d'un commutateur ou d'une antenne — mais mentent parfois.
L'ordinateur pensait...mais n'était pas sûr! Et l'équipage a du mettre les interrupteurs dans la mauvaise position pour acquitter l'alarme!
Si l'ordinateur travaille avec des signaux qui "mentent", ce qulle utilité est-il? N'est il pas supposé apporter de la fiabilité?
Le contrôle fut passé à BURNBABY — le programme principal de mise à feu que nous avons écrit après le LM-1 pour économiser la mémoire en exploitant les similarités entre les phases de vol propulsé dans la période conduisant à l'allumage. Le Mot 06 Groupe 62 apparut sur le DSKY. le registre du milieu contenait un temps en minutes et secondes qui commença à décompter vers l'allumage. A 35 secondes, l'affichage disparut, et réapparut à 30 secondes. Ceci était un signal que la Moyenne-G avait commencé. A sept secondes et demie, l'allumage de fuite débuta. A cinq secondes, l'affichage clignota pour requérir un "départ" de la part de l'équipage. Buzz Aldrin, le pilote du LM, se tenant à la droite du cockpit, eut la responsabilité principale pour faire fonctionner le DSKY. A présent il rentra PROCEED.
Au temps écoulé de la mission (temps MET102:33:05), les carburants auto-allumés descendirent dans le moteur de descente et il monta à 10% d'accélération. Armstrong ne sentit même pas la poussée modeste — moins que 1/25 G. L'affichage changea au groupe 63, et les trois registres d'affichage montraient à présent une vélocité totale de 5559,7 pieds/sec, un taux d'altitude de -2.2 pieds/sec, et une altitude de 49971 pieds. Les cardans qui contrôlaient le moteur de descente se déplacérent pour aligner le vecteur de poussée avec le centre de masse du vaisseau. Puis, après 26 secondes d'allumage, le logiciel poussa le DPS jusqu'à sa poussée maximale de 9870 livres (43, 900 newtons), 94% du taux officiel du moteur de 10500 livres, et en même temps enclencha le guidage de descente.
P63 fut appelé pour la phase de freinage parce que son seul but était de réduire la vélocité horizontale. Il se terminerait environ dans huit minutes,lorsque le vaisseau atteindrait les conditions ciblées connues comme "porte haute" à une altitude d'environ 7400 pieds.
Figure 5: Les phases de l'alunissage (Chiffres approximatifs)
Au temps MET 102:36:55, Neil Armstrong, le commandant, se tenant sur le côté gauche du cockpit du LM, utilisa sa manette pour dévier le vaisseau de son axe de poussée de sorte que les hublots, qui avaient permis aux astronautes d'examiner la surface alors que les pieds étaient en avant, pointerait vers l'espace, où la terre était visible. Mais le vaisseau tournait trop lentement. Armstrong réalisa qu le bouton de taux d'autopilotage était à 5 deg/sec et le régla à 25. Juste avant que la maneuvre soit terminée, le radar d'atterrissage signala "données correctes".
Si c'est un "autopilote", pourquoi doit il être réglé? N'est il pas supposé se régler tout seul?
Le radar d'alunissages dit que les données sont "bonnes", mais qu'est ce que cela signifie, quelle données? Le radar donne simplement une indcation de la proximité du sol.
Il n'était pas possible de naviguer assez précisément pour toucher en toute sécurité le sol lunaire sans connaissance locale de sa distance ou vélocité relative. Le radar d'atterrissage fournit cette indication. En dépit du "test de raisonabilité" réalisé par le programme, les données du radar ne pouvaient être incorporées dans le vecteur d'état sans l'approbation de l'équipage (et du contrôle au sol). Donc, environ cinq minutes après l'allumage, Aldrin rentra le mot 16 Groupe 68 — une requête pour monitorer un groupe dont le troisième registre montrait la différence entre l'altitude détectée par le radar et l'altitude calculée. Ce nombre, appelé DELTAH, était d'environ -2900 pieds. C'était dans la marge d'erreur d'altitude attendue. Les données du radar pouvait graduellement être rentrées dans la navigation sans affecter contradictoirement la forme de la trajectoire.
Les données du radar ne peuvent être intégrées dans le système de guidage sans l'approbation de l'équipage? Et si l'équipage oublie de les y incorporer?
Et si le radar n'a pas d'influence sur la trajectoire, de quelle aide est-il?
Puis, nous entendîmes les mots "alarme de programme". A cambridge, nous nous regardâmes. A bord, Aldrin vit le voyant PROG s'allumer et l'affichage revenir vers le mot Verb 06 Groupe 63. Il rentra rapidement le mot 90 Groupe 50. Le code Alarme 1202 apparut sur le DSKY. Il s'agissait d'une alarme produite lorsque l'ordinateur était surchargé — quand il avait plus de travail à faire qu'il n'en avait le temps. A Cambridge l'information se propagea, "Alarme d'exécution, pas de mémoire disponible". Alors Armstrong dit, sur un ton d'agacement, "Donnez nous une lecture sur l'alarme de programme 1202".
Eh bien Aldrin réagit en tapant rapidement un mot donné d'un groupe donné; comment a t'il su qu'il devait taper ce mot donné du groupe donné lorsque il fut en face de cette situation imprévue? A t'il du apprendre tous les mots de tous les groupes à taper en réaction de diverses situations?
Le pauvre ordinateur devient bien surchargé, il ne sait pas comment continuer; par pitié, aidez moi, je suis en surcharge!
A partir de ce moment, les evénements se succédérent très vite, trop vite pour avoir un retour depuis Cambridge. C'était au contrôle de mission de Houston de jouer. L'histoire de ce qui se déroula a souvent été relatée — comment il revint à un fonctionnaire de 26 ans du contrôle de la mission du nom de Steve Bales de dire "Allez" ou "Arrêtez". Bales a participé à une révision récente des alarmes du LGC qui a attribué un "allez" au code 1202 à moins qu'il ne se produise trop souvent ou qu'il y ait une déviation de la trajectoire. Il fut appuyé par Jack Garman de la NASA et Russ Larson du MIT dans la salle du fond. Garman dit, "Allez". Larson leva le pouce. (Il dit plus tard qu'il était trop effrayé pour dire un mot) Alors Bales répondit, "Allez", Le directeur de vol Gene Krantz dit "Allez", et le communicateur de capsule Charlie Duke le passa à l'équipage. Au MIT, où nous réalisions que quelque chose de mystérieux faisait perdre du temps à l'ordinateur, nous pouvions à peine respirer.
Entre en scène le héros, un jeune homme agé de 26 ans, qui est là pour sauver la situation parce que les ingénieurs du MIT sont dépassés!
Il a toutefois eu besoin du conseil de ses supérieurs...Mais il fut sur la chaîne des "Allez" qu'il transmit après avoir reçu le feu vert du directeur de vol!
Et qu'est ce que serait passé s'ils avaient dit "Arrêtez" au lieu de "Allez"? L'ordinateur aurait fait une pause café?
Quelque chose de mystérieux volait du temps à l'ordinateur..aurait-ce pu être être un OVNI?
Une demie minute s'écoula entre l'alarme et le "allez" depuis Houston. Pendant ce temps, le contrôle de la mission approuva le DELTAH, et Aldrin rentra le mot 57 pour permettre à la navigation d'incorporer les mesures du radar d'atterrissage.
Donc, pendant une demie minute, jusqu'à ce que le "Allez" salvateur revint de Houston, l'ordinateur resta inopérationnel et ne sut que faire, n'ayant pas été donné de directive.
Pendant ce temps, le lem devait se débrouiller tout seul, il utilisait probablement l'occasion pour danser une gigue.
A la prochaine alarme 1202, le "Allez" revint plus vite, parce qu'ils avaient acquis de l'entrainement.
Figure 6: La commande (ligne pointillée) comparée à la poussée réelle (ligne pleine) pendant la descente propulsée. (données de simulation).
Au temps MET 102:39:31, l'élaborateur de meilleure confiance possible se produisit — poussée vers le bas, juste à temps. "Ah! Poussée vers le bas... mieux que le simulateur" commenta Aldrin, "Poussée vers le bas à temps!" s'exclama Armstrong, leur excitation était palpable. Dans la transcription officielle des communications entre entre le vaisseau et le sol durant la descente propulsée, ce sont les seuls points d'exclamation de la mission.
Le transcripteur fut capable de lire le point d'exclamation dans les mots parlés d'Armstrong!
Quel talent!
Le moteur de descente subissait une érosion excessive de la tuyére si utilisé dans la plage entre 65% et la poussée maximale. La poussée vers le bas se produisit lorsque la poussée requise par le guidage tomba à un niveau suffisamment en dessous de cette limite pour qu'un accroissement graduel jusqu'à la fin de la phase de freinage ne force pas à un retour vers le maximum. La poussée vers le bas était un indicateur sensitif du niveau de performance du système de guidage. Il était aussi vrai que si la poussée était poussée au maximum, une procédure d'arrêt puisse bientôt être nécessaire, parce que, dans environ 40 seconds, les équations de guidage ordonneraient au vaisseau de s'inverser.
Il semble que la procédure d'arrêt était la procédure magique pour résoudre tous les problèmes que l'AGC était incapable de gérer!
Tandis que le LM faisait encore face à la surface lunaire, Armstrong avait noté des repères qui indiquaient que le LM était plus bas que désiré. Il réalisait à présent que l'ordinateur ignorait que le système d'atterrissage allait trop loin. Autrement le moteur serait resté au maximum de poussée pour plus longtemps comme le guidage essayait de couper court.
L'AGC travaillait souvent sur la base d'informations erronnées; ce n'était donc pas sa faute qu'il prenait de mauvaises décision, non ce n'était pas sa faute, soyez sympa avec lui!
Au temps MET 102:41:32, alors que le vaisseau passait 7400 pieds, tombant à 125 pieds/sec, la porte haute fut terminée. Le guidage commença d'utiliser un nouveau jeu de cibles. The LM se projeta de sorte que la surface lunaire devienne visible. Sur le DSKY, le registre de mode changea à 64 indiquant la phase de visibilité, et le groupe 64 remplaça le groupe 63. Deux nombres de deux digits remplacérent la vélocité dans le registre du haut. l'un était un "désignateur de point d'atterrissage" (LPD), un angle qui indiquait où Armstrong devait regarder le long d'un réticule fixé sur son hublot pour voir où le LM toucherait le sol lunaire si nous étions autorisés à atterrir automatiquement. Le système de guidage contrôla le lacet pour conserver le site d'atterrissage le long de la ligne du réticule. L'équipage pouvait bouger un réglage manuel pour décaler le site. (Armstrong avait affirmé avant le vol qu'il n'avait pas l'intention d'utiliser cette fonctionnalité, mais il y avait apparemment un changement inopiné tardif dans la phase de visibilté). Le deuxième nombre donnait le temps restant pendant lequel un changement pouvait être rentré. Avec la logique de changement à présent enclenchée, ce fut le moment le plus chargé de l'atterrissage.
Donc, sur l'affichage, la vélocité était remplacée par deux nombres, l'un étant un angle, et l'autre un temps!
Les astronautes avaient intérêt à savoir quand l'affichage changeait; imaginez s'il avaient pensé que l'angle/temps était encore la vélocité!
(Ou inversement, que l'affichage montrait déjà l'angle/temps alors qu'il affichait encore la vélocité).
Au temps MET 102:42:17, une alarme 1201 se produisit. C'était une autre alarme exécutive — "Pas de zones VAC disponibles". Environ 24 secondes plus tard, il y eut un autre 1202. Juste 16 secondes plus tard, avec le système d'atterrissage à 770 pieds avec un taux de diminution de 27 pieds/sec, un autre 1202 se produisit encore. Le contrôle de mission à Houston emit un "Allez" dans chaque cas. Neil Armstrong, dont la pulsation cardiaque monta de 120 à 150 duranr cette période, s'exprima ainsi:
Normalement, à ce moment, c'est à dire depuis P64 et après, nous évaluions le site d'atterrissage et commencions l'activité LPD. Toutefois, notre souci n'était pas la zone où nous allions atterrir, mais plutôt si nous pouvions continuer. Conséquemment, notre attention était dirigée vers l'acquittement des alarmes de programme, à continuer à faire voler la machine, et à nous assurer que le contrôle pouvait se continuer sans necessiter un arrêt. La plus grande partie de notre attention était concentrée à l'intérieur du cockpit durant cette période et selon moi cela explique notre incapacité à étudier le site d'atterrissage et l'endroit final d'atterrissage durant la descente finale.
Donc, Armstrong était si occupé à acquitter les alarmes de l'ordinateur qu'il ne pouvait pas correctement choisir le site d'alunissage!
C'est un ordinateur qui avait besoin de beaucoup d'attention, il avait besoin d'amour
Néanmoins, Armstrong eut le temps de remarquer que le LPD indiquait que "nous atterrissions juste avant un cratére rocheux avec de grands rochers couvrant une grande partie de sa surface". Donc au temps MET 102:43:08 (650 pieds), après avoir décidé qu'il ne pouvait pas s'arrêter avant le cratère, Armstrong changea le mode autopilote de AUTO à ATT HOLD pour prendre le contrôle manuel de l'attitude du LEM. Il maneuvra vers le niveau zéro pour garder la vélocité horizontale et dépasser la zone rocheuse.
Armstrong prit le contrôle des commandes; J'ai le sentiment qu'il commençait à perdre confiance dans la capacité de l'AGC a faire alunir le Lem en toute sécurité. (un peu plus de données "erronées", et c'était le crash!)
(ATT HOLD était le mode dans lequel l'astronaute pouvait commander un taux d'attitude en jouant sur une manette. Après que la manette était relachée, l'autopilote annulait les taux pour maintenir l'attitude courante.)
Au temps MET 102:43:20 (430 pieds), Armstrong toucha un commutateur avec sa main gauche, se mettant en mode taux de descente (P66). A présent l'ordinateur contrôlait la poussée du vaisseau pour maintenir le taux de descente programmé par le commutateur ROD. Un tour du commutateur vers le haut ralentissait la descente d'un pied par seconde; un tour vers le bas l'augmentait du même taux. En utilisant la manette, Armstrong agit sur le LM pour annuler la vélocité horizontale et diriger le LM vers un endroit sûr pour l'alunissage. Après quelques contrôles de mouvements "possiblement spamodiques" parce que la poussière soulevée par le réacteur modifiait la perception de la velocité translationelle, au temps MET 102:45:40, Armstrong alunit en toute sécurité sur la mer de la tranquillité.
Pendant ce temps, l'ordinateur faisaint encore des calculs pour faire alunir le Lem avec autant de sécurité que possible...Personne ne lui avait dit que le Lem s'était posé!
* * *
Des années avant Apollo 11, lorsque le système de guidage commençait d'être conçu, le logiciel de bord était encore une vision lointaine — "Hal s'en occupera" était le sentiment. En fait, il finit par occuper des masses de gens, avec des centaines de plus en support, Mais c'est à Hal Laning que, dans les premiers temps, revint la tâche d'imaginer comment organiser les nombreuse fonctions du logiciel qui doivent se dérouler presque simultanément dans un ordinateur temps-réel de contrôle de vaisseau spatial — dans ca cas précis, un de taille et vitesse limitée.
Le concept de Hal évita les écueils de la conception de "wagon de marchandises", dans lesquels les calculs doivent être explicitement découpés en tranches temporelles. un concept de wagon est pénible à implémenter car les calculs doivent être séparés arbitrairement. Durant le développement, l'allocation peut avoir à être revisée lorsqu'une de ses parties est modifiée ou de nouvelles fonctionnalités sont ajoutées. Le pire pour un concept de wagon est une cassure de système durant l'opération. Cela casse complètement dès que toute fonction prend plus longtemps que le temps qui lui est alloué.
Au lieu de cela, Laning imagina un système dans lequel les fonctions de logiciel étaient allouées entre divers "processus" qui pouvaient être de toute taille et forme, comme déterminé par la nature de leur fonction. A chaque tâche était attribuée une priorité. Le système opérationel exécutait toujours la tâche avec la plus haute priorité. Ainsi, si une tâche de basse priorité était en cours d'exécution et qu'une tâche de haute priorité était démarrée, la tâche de basse priorité était suspendue pendant que la tâche de haute priorité était exécutée. ce système donnait l'illusion que les tâches était exécutées simultanément, quoique bien sûr elle tournassent à tour de rôle. Un tel système n'était pas déterministe dans le sens que ce qui était exécuté et quand pouvait être déterminé a priori, mais dans celui que son fonctionnement pouvait étre suffisamment compris et vérifié pour qu'en somme cela assure la fiabilité, la sûreté et la flexibilité d'usage,et spécialement la facilité de développement.
Eh bien ils ont révolutionné le temps réel en donnant à l'AGC des fonctionnalités...que l'on trouve ordinairement dans les systèmes temps réel!
Maintenant, je me demande comment il pouvait faire tourner l'AGC dans un environnement temps réel:
Il n'y avait même pas de fonction pour démarrer un processus dans la documentation de l'AGC, non plus que de fonction de synchronisation dont un système temps réel a besoin.
Un système temps réel nécessite un noyau temps réel, qui gére les processus, que je peine à voir dans l'AGC.
De plus, un système temps réel ne peut pas fonctionner sans pile; une pile est nécessaire pour sauvegarder les données des divers processus quand ils s'interrompent l'un l'autre.
L'AGC n'a pas de pile; un sous-programme ne peut même pas en appeler un autre, car l'adresse de retour est sauvée dans un registre unique (et en outre le contenu de l'adresse de retour est également sauvé, ce qui est aberrant).
Il est évident que l'AGC n'était absolument pas fait pour tourner dans un environnement temps réel.
Il ne peut que tourner séquentiellement, avec des interruptions de produisant soit sur un schéma périodique, ou sur l'initiation de signaux matériel.
Dans un tel concept, la fonction exécutive qui orchestrait l'exécution des processus avait à fournir à chaque processus un jeu de registres dans lequel son status pouvait être sauvé s'il était suspendu pendant l'exécution d'un processus de plus haute priorité. Le LGC contenait un tableau de huit tels "jeux de mémoire" de 12 registres chacuns, chaque registre ayant 15 bits. Un jeu de mémoire de cette taille était suffisant pour la plupart des processus, mais les processus qui utilisaient le langage interprétif pour faire des calculs de vecteurs et matrices requéraient plus d'espace mémoire. Pour de tels processus, une zone additionnelle de 43 registres étaient allouée pour la mémorisation des résultats intermédiaires. Il y avait cinq tels "Zones Accumulateur vecteur (VAC)" dans le LGC.
Allouer un jeu de mémoire donné ou une zone VAC aux processus n'a pas de sens, parce qu'un processus n'utilise pas forcément toutes les données du jeu de mémoire ou de la zone VAC; les données non utilisées seraient perdues pour un autre processus.
D'autre part, un processus peut avoir besoin de plus de données que ce que peut lui fournir un jeu de mémoire ou une zone VAC.
Les données devraient être allouées dynamiquement par le compilateur aux processus, de sorte qu'ils utilisent juste ce dont ils ont besoin, et pas plus, sans gaspillage de données non utilisées (surtout si l'AGC est limité en mémoire, pas comme les ordinateurs modernes qui en ont à revendre).
Avec un nombre limité de jeux de mémoire et de zones VAC, l'allocation des fonctions aux processus devait être faite rationellement. Les fonctions qui avaient une relation séquentielle l'une avec l'autre étaient groupées dans le même processus. Ainsi le grand processus SERVICER qui était actif durant l'alunissage (ainsi que d'autres modes de vol propulsés) réalisait d'abord la navigation Moyenne-G, puis les équations de guidage, puis la poussée et le contrôle d'altitude, et enfin la mise à jour de l'affichage — chaque partie utilisant les sorties des précédentes.
Une fonction pourrait être utilisée par plusieurs processus, avec les données de ces processus (et certaines données de processus pourraient être communes); alors pouquoi les enfermer dans un seul processus?
La disponibilité des jeux de mémoire et des zones VAC limitaient le nombre de processus qui pouvaient être en queue à tout moment à huit, dont jusqu'à cinq pouvaient requérir des zones VAC. Dans le fonctionnement normal état stable, le nombre de processus exécutés egalait le nombre de processus démarrés et donc l'usage moyen des jeux de mémoire des zones VAC était plus ou moins stable, quoique des processus qui se déclenchaient sur une base d'un coup ou asynchrones pouvait causer une fluctuation.
Limiter le nombre de processus par la disponibilité des jeux de mémoire et zones VAC n'a pas beacuoup de sens; ce qui limiterait plutôt le nombre de processus est le temps dont ils ont besoin pour s'exécuter, et la taille de la pile si l'AGC en avait une...mais il n'en a pas!
Toutefois, si plus de processus étaient démarrés que ceux en cours de terminaison, le nombre de jeux de mémoire ou zones VAC en cours d'utilisation pouvait grimper. Si le débit se prolongeait quelque peu, les ressources pouvaient s'épuiser. La requête de processus suivant pouvait ne pas être satisfaite.
Un an avant Apollo 11, alors que nous, ingénieurs informaticiens, qui pensions que nous avions déjà assez à faire, fûmes requis d'écrire le programme d'alunissage de telle sorte que l'ordinateur pouvait litéralement être coupé et rallumé sans interrompre l'alunissage ou toute autre manoeuvre vitale! Ceci était appelé "protection de redémarrage". D'autres facteurs que des problèmes d'alimentation pouvaient aussi causer des redémarrages. Un redémarrage était fait si le matériel pensait que le logiciel était entré dans une boucle infinie, ou s'il y avait une erreur de parité lors de la lecture de la mémoire programme, ou pour plusieurs autres raisons.
Comment le matériel pouvait-il savoir que le logiciel était entré dans une boucle infinie?
Et s'il y avait une erreur de parité sur la mémoire fixe, ce n'était pas le fait de redémarrer l'ordinateur qui pourrait la réparer!
A moins que l'ordinateur soit éteint et rallumé, et que le programme soit rechargé, mais, à cette époque, cela se faisait depuis une bande magnétique, et c'était un processus relativement long; pendant ce temps l'AGC serait resté inopérationnel, et le Lem livré à lui-même.
La protection de redémarrage était faite par enregistrement de points de passage en des endroits adéquats durant le fonctionnement du logiciel de tel sorte que, si le programme paraissait revenir sur le dernier point de repére, cela ne générerait pas d'erreur, comme dans l'exemple suivant:
NOUVEL_X = X + 1
point de passage
X = NOUVEL_X
Il est évident que sans le point de passage, le fait de passer par ce code une seconde fois provoquerait une nouvelle incrémentation de X.
Ces registres de "passage" sont tout à fait ridicules et absurdes; ils sont très malcommodes à utiliser; et si le processus était dans un état où, lorsque redémarré, il devait refaire l'instruction qui est après le point de passage?
Typiquement, c'est plutôt les compteurs de programme des processus, et des données essentielles qui devraient être sauvées.
Et comment ces points de passage pouvaient ils être enregistrés? une autre intelligence aurait été nécessaire pour ce faire.
A la suite d'un redémarrage, de tels calculs pouvaient être refaits. Pour chaque processus, le traitement commencerait au dernier point de repére enregistré. si des copies multiples du même processus étaient en queue, seule la plus récente était redémarrée. certains autres calculs qui n'étaient pas considérés comme vitaux n'étaient pas protégés contre un redémarrage. Ils disparaîtraient tout simplement en cas de redémarrage.
C'est plus logiquement à l'endroit du compteur de programme mémorisé que l'exécution devrait reprendre; si le programme reprend depuis le dernier point de passage, alors les données du processus devraient également être remise dans l'état dans lequel elles étaient lors de ce point de passage!
Ces copies multiples du même processus en queue? Cela n'a pas de sens, l'AGC n'est pas capable de gérer des copies multiples du même processus.
La protection de redémarrage fonctionnait assez bien. Sur le panneau de contrôle de notre simulateur hybride temps réel à Cambridge, il y avait un bouton poussoir qui provoquait le redémarrage de l'AGC. Durant les simulations, nous poussions parfois le bouton aléatoirement, espérant presque un défaut de fonctionnement qui conduirait à quelque erreur de programme. Invariablement, une fois que nous avons pu faire fonctionner le protection de redémarrage, le fonctionnement continuait de manière cohérente.
(Le simulateur hybride combinait un calculateur digital SDS 9300 et des calculateurs analogiques Beckmann avec un vrai AGC et des cockpits de LM et CM réalistes.)
La protection de redémarrage était rendue nécessaire par la possibilité que le matériel pouvait causer un redémarrage, mais le logiciel pouvait aussi initier un redémarrage s'il atteignait un point où il ne savait pas comment continuer.
Il semble que l'AGC recourait systématiquement au redémarrage comme moyen ordinaire de surmonter un problème qu'il était incapable de prendre en main.
De tout manière, pour le service qu'il rendait, cela n'avait pas beaucoup d'importance; il ne semble pas que les astronautes avaient beaucoup de confiance en lui!
Telle était l'action entreprise par le programme exécutif si les ressources étaient dépassées. Si un processus ne pouvait pas être démarré parce qu'il n'y avait pas de jeu de mémoire disponible, le processus exécutif appelait BAILOUT avec le code alarme 1202. si aucune zone VAC était disponible, BAILOUT était appelé avec un code d'alarme 1201.
Mais pour afficher l'alarme, le processus d'affichage devait être lancé...lequel avait besoin de ressource qui était précisémént épuisée!
Toutes les fonctions du LGC n'étaient pas forcément des "processus". Il y avait aussi un système d'interruptions matérielles, qui pouvaient interrompre un processus n'importe où (lorsque non explicitement lancées) pour réaliser des traitements de haute priorité. Les interruptions étaient dédiées à des traitements particuliers incluant l'autopilote digital, la remontée et descente d'informations, et la gestion du clavier.
Une autre interruption pouvait être utilisée pour exécuter toute pièce de programme qui devait être exécutée à un temps donné. De telles fonctions, appelées "tâches", étaient initiées en appelant un sous-programme WAITLIST. Une tâche devait être de très courte durée.
Alors que les processus étaient exécutés dès que démarrés à une priorité donnée, les tâches étaient programmées pour s'exécuter à un temps donné. Les tâches et les processus étaient souvent utilisés simultanément. Une tâche pouvait être programmée pour acquérir la donnée d'un capteur qui devait être lue à un temps défini, et la tâche pouvait à son tour lancer un processus avec une priorité appropriée pour réaliser un traitement basé sur la mesure.
Mais comment une interruption pouvait elle lancer un processus? Aucune fonction de l'AGC ne permet de le faire!
Ce que l'interruption aurait pu faire est mettre à jour une donnée depuis un capteur qui était utilisée par un processus en cours.
Quand Hal Laning conçut le système exécutif et de file d'attente au milieu des années 60, il le fit d'une traite sans exemples pour le guider. Le concept est encore valide aujourd'hui. L'allocation des fonctions parmi un nombre sensible de processus asynchrones, sous le contrôle d'un exécutif de gestion de partage et priorité préemptif, représente encore l'état de l'art dans les ordinateurs GN&C pour la navigation spatiale.
Cela représente encore l'état de l'art des ordinateurs fantaisistes d'Apollo, c'est sûr...mais sans successeurs!
* * *
Pour comprendre la cause originelle des alarmes sur Apollo 11 pendant la phase de descente propulsée, on doit d'abord examiner le rendez-vous avec le module de commande qui suivit la montée du LM vers l'orbite lunaire. Alors qu'il avait besoin du radar d'atterrissage pour mesurer l'altitude et la vélocité relativement a la surface lunaire pendant l'alunissage, le LM, en tant que véhicule actif pendant le rendez-vous avec le CM dans l'orbite lunaire, avait besoin du radar de rendez-vous (RR) pour mesurer la plage, le taux de plage, et la direction de l'autre vaisseau.
Le RR avait plusieurs modes opérationnels, determinés par le réglage du commutateur de mode. Dans le vol avec Apollo 11, les modes RR disponibles étaient SLEW, AUTO, et LGC. Dans les modes SLEW et AUTO, le radar opérait sous le copntrôle de l'équipage, indépendamment du LGC. C'était la méthode qui serait utilisée durant la montée et le rendez-vous si le système primaire de guidage tombait en défaut. en mode SLEW, le radar de rendez-vous pouvait être orienté manuellement, mais était stationnaire dans les autres cas. Une fois que l'antenne pointait vers la cible, me mode AUTO (traçage automatique) pouvait être utilisé pour acquèrir et suivre la cible. Dans ces cas, la plage du RR et le taux de plage, ainsi que les angles de flèche et tourillon qui définissaient vers où l'antenne RR pointait, étaient rendus disponibles pour l'affichage sur les pointeurs de croix et les métreurs du cockpit. La plage et le taux de plage étaient aussi rendus disponibles pour l'arrêt du système de guidage (AGS), un ordinateur avec seulement 6144 mots de mémoire qui était fourni par TRW comme sauvegarde à utiliser si le PGNS entrait en défaut pendant la descente ou la montée lunaire.
(Le nommage des trois modes de radar de rendez-vous a été une source de confusion pour quelques commentateurs. Sur la base du témoignage de l'équipage, le concept fut changé entre le LM-1 et les émissions d'alunissage. Le mode appelé LGC sur Apollo 11 fut d'abord appelé AUTO. Le mode appelé AUTO sur Apollo 11 fut d'abord appelée MANUEL. SLEW resta inchangé. Quoique cela ne contribua en rien au problème sur Apollo 11, de documentation interne de LUMINARY à cette époque faisait encore référence au discret sur la canal 33 qui indiquait que le radar de rendez-vous était alimenté dans le mode LGC aussi bien que dans le mode RR AUTO-POWER ON.
C'est absolument hilarant: Le mode AUTO sur Apollo 11 correspondait précédemment à un mode manuel!
Ce doit expliquer que , même dans le mode AUTO, les astronautes devaient encore faire des corrections manuelles pour l'empêcher de mettre le Lem dans une situation périlleuse!
Si le PGNS se portait bien (comme c'était toujours le cas) le radar était contrôlé par le LGC, et, dans ce cas, le commutateur de mode RR était réglé sur LGC. L'électronique d'interface RR rendait disponible au logiciel la plage et le taux plage cible mesurés par le radar, et les angles de flèche et tourillon de l'antenne RR, depuis lesquels la direction vers la cible pouvait être déterminé. Des programmes tournant sur le LGC utilisaient cette information pour guider le LM vers un rendez-vous favorable.
Il s'avéra que le radar de rendez-vous pouvait aussi être utilisé pendant la descente propulsée, et ce fut fait dans Apollo 11. Les procédures de l'équipage demandaient que le commutateur RR soit enclenché juste avant la sélection de P63, et soit maintenu sur le mode SLEW ou AUTO durant toute la manoeuvre d'alunissage.
De nombreuses explications ont été avancées à propos de la raison pour laquelle le RR était configuré de cette manière pour l'alunissage. Par exemple, un projet fantaisiste de monitorage de l'alunissage par comparaison des données du RR avec un graphe de lectures attendues peut avoit été envisagé par certaines personnes à Houston. Toutefois, une explication plus simple suffit pour expliquer les faits: Le RR n'avait pas d'autre but que d'être réveillé s'il y avait un abandon, et s'il était sur AUTO (pendant que le LM était en position de tracer le CM) or sur SLEW (dans les autres cas), simplement pour empêcher l'antenne de bouger inutilement.
Figure 7: Interfaces Among PGNS, ATCA and the Rendezvous Radar
Le schéma de la figure 7 est absolument hilarant, totalement démentiel!
D'abord on peut voir que AUTO et SLEW réalisent exactement la même fonction.
Ensuite la position LGC ne fait que relier l'interrupteur RR à une autre référence de la même tension de 28 volts oscillant à la même fréquence de 800 Hertz (qui sont des valeurs complétement fantaisistes!)
- Le resolveur d'angle (cerclé en bleu) produit des signaux d'angle qui sont convertis en pulsations d'angle in l'unité de couplage de données (CDU, cerclée en vert); mais ces pulsations d'angle sont fournies sous deux taux différents, 6400 pulsations par seconds ou 400 pulsations par seconde; pourquoi deux taux. Si le CDU peut fournir les pulsations au taux de 6400 par seconde,; alors il doit toujours les fournir à ce taux, car c'est l'intérêt du LGC de les acquérir aussi rapidement que possible; l'autre taux est seize fois plus lent que le premier, alors pourquoi offrir la possibilité de l'utiliser (et comment le LGC peut-il savoir à quel taux il reçoit ces pulsations?)
- Le LGC fournit un porteuse à 1.024MHZ; ce signal rentre dans le bloc "PCM and timing electronics", dans lequel il est modulé avec des données digitales; normalement le bloc "PCM and timing electronics" devrait sortir un signal de même fréquence (mais modulé avec les données digitales); au lieu de cela, il sort un signal qui a une fréquence de 1.6kpps (equivalent à 1.6Khz), c'est à dire un signal qui a une fréquence presque 1000 fois plus petite que la fréquence d'entrée!
Ce schéma est complétement absurde, et il est évident qu'il ne remplit aucune fonction; c'est un schéma à la shadok!
Le problème a aussi été attribué (y compris par l'auteur précédemment) à une "erreur de checklist". cette formulation n'est pas plus exacte que d'appeler la coupure prématurée du moteur par le contrôle de delta-V sur le LM-1 une "erreur de programme", quand elle fut en fait causée par une documentation défectueuse. En fait, les réglages de commutateur sur Apollo 11 ne devraient pas avoir causé de problème. Qu'ils l'ont fait peut être expliqué d'une autre manière... par une documentation défectueuse.
Une documentation défectueuse?
Comment est-il possible que, sur un projet aussi important que le projet Apollo, la documentation soit faite avec si peu d'attention?
Des années auparavant, un document de contrôle d'interface (ICD) a été écrit pour définir l'interface électrique entre le PGNS et un assemblage électronique appelé le contrôle d'attitude et de translation (ATCA) qui était fourni par Grumman Aerospace, le constructeur du système d'atterrissage. L'ICD spécifiait que les tensions de 28-volt et 800-Hz dans les deux systèmes soient "à verrouillage de fréquence", mais ne dit pas, "synchronisés en phase". De leur conception, les deux tensions étaient verrouillées en fréquence par un signal de "synchronisation de fréquence" envoyé par le LGC. Ils étaient également verrouillés dans une relation de phase constante. Toutefois, l'angle de phase entre les deux signaux était complètement aléatoire, et dépendait du moment où le LGC, qui était toujours mis en oeuvre après l'ATCA, commençait d'envoyer le premier signal de synchronisation de fréquence. Ces interfaces sont décrits dans la figure 7.
Non, c'est impossible; si les signaux étaient construits à la même fréquence avec un angle de phase constant, cet angle de phase ne dépendrait pas du moment où le LGC est activé.
L'electronique pourrait être ajustée pour déphaser plus ou moins les deux signaux, mais, pour un ajustement donné, les deux signaux seraient toujours déphasés pareillement, quelque soit le moment où le LGC serait activé.
Une absurdité de plus!
Le problème de déphasage du signal 800-Hz fut détecté pendant le test du LM-3 au site de lancement et documenté — mais il ne fut jamais corrigé. Le réultat en est que, lorsque le commutateur RR est sur le mode AUTO ou SLEW, les résolveurs de flèche et tourillon étaient excités par un signal 800 HZ en provenance de l'ATCA qui avait de grande chances d'être déphasé par rapport au signal 800 hz utilisé commé référence par les unités de couplage de données (CDUs) dont la tâche était de traiter les signaux du résolveur, et de les convertir en incréments (ou décréments) de compteurs à l'intérieur de l'ordinateur, lesquels disaient au logiciel comment l'antenne était pointée.
Une autre absurdité hilarante.
Un problème qui a été documenté et jamais corrigé!
Le projet Apollo semble avoit été conduit avec le plus grand manque de sérieux: Des problèmes documentés et non corrigés (ou parfois constatés et non documentés)!
Sur Apollo 11, toutefois, les CDUs devaient gérer une contradiction. Parce qu'ils étaient basés une tension contrôlée séparément, les signaux du résolveur, tels que reçus par les CDUs n'iindiquaient pas d'angle connu. La déconfiture des CDUs était à son summum quand l'angle de phase entre les deux signaux 800 Hz était proche de 90 ou 270 degrés — et Apollo 11 a de toute évidence rencontré l'un de ces cas extrêmes. La réponse des CDUs était d'incrémenter ou décrémenter les compteurs du LGC, de manière pratiquement constante, à un taux maximum de 6400 pulsations par seconde pour chaque angle. Ce phénomène se produisait lorsque le commutateur RR était sur SLEW ou AUTO, indépendamment du fait que le radar de rendez-vous était actif ou non.
Donc, l'AGC comptait des pulsations d'angle même lorsque le radar n'était pas connecté!
Il faisait des calculs sur des données erronnées, et il était supposé guider le Lem en toute sécurité???
Quelle plaisanterie!!!
Si la même référence de 28 vlts avait été utilisée, il n'y aurait pas eu de problème de déphasage du tout, et il n'y aurait pas eu de pulsations d'angle quand le radar n'était pas connecté.
Ils créent eux-mêmes des problèmes qui ne devraient pas exister!
Les compteurs de l'interface CDU étaient incrémentés ou décrémentés dans le LGC au moyen de commandes externes qui étaient traitées dans l'ordinateur comme des opérations d'incrémentation ou décrémentation sous le nom de PINC et MINC. Comme toutes les opérations programmables du LGC, celles-ci prenaient du temps de cycle, dans ce cas un temps de cycle mémoire de 11.7 microsecondes pour chaque pulsation. Lorsqu'ils comptaient à leur taux maximum, les compteurs du CDU consommaient approximativement 15% du temps disponible de calcul. A cette époque, conventionellement, nous avons supposé que la perte de puissance de calcul (appelée called TLOSS) était d'environ 13%, ce qui était consistant avec le comportement que nous avons observé.
Les pulsations matérielles étaient comptées par des instructions logicielles dans l'AGC!
L'AGC manquait déjà de temps pour réaliser les tâches qu'il avait à faire, et il en perdait encore plus en comptant des signaux matériels qui auraient du être comptés par de simples circuits électroniques!
En comptant les signaux matériels avec des circuits électroniques au lieu de les compter avec des instructions logicielles, ils auraient pu économiser beaucoup de temps de cycle de l'AGC, ce qui aurait réduit la chargé et aurait pu éviter les redémarrages dus à la surcharge.
Je rend hommage à l'expert de systèmes de guidage George Silver pour ses explications patientes de l'interface de radar de rendez-vous. Le rôle de Silver fut essentiel pendant la mission Apollo 11. Il fut à Cap Canaveral pour le lancement, puis vola à Boston pour se préparer à monitorer l'ascension lunaire à Cambridge. Le 20 juillet, il regarda l'alunissage chez lui à la télévision. Il entendit les alarmes, comprit que quelque chose volait du temps CPU, et se rappela du cas qu'il avait vu durant les tests des systèmes du LM-3 dans lesquels l'interface du radar de rendez-vous avait causé une activité de comptage sauvage. Après quelque analyse additionelle par l'équipe contrôlant la mission à Cambridge, Silver alla finalement voir les représentants du MIT à Houston, la matinée du 21 juillet, juste une heure avant le décollage du sol lunaire.
Alors George est allé à Houston pour expliquer comment le programme de l'AGC aurait pu être modifié s'il n'était pas présentement sur la lune!
(Il est arrivé juste à temps pour que les représentants du MIT puissent faire une prière pour les astronautes)
Je pense que je dois maintenant donner des explications sur la manière dont le guidage était fait (ou au moins devrait être fait).
Lorsque le Lem est expulsé du LCM, il a une grande vitesse horizontale, la même que celle du LCM.
Cette vitesse crée une force centrifuge qui compense l'attraction lunaire et empêche le Lem de gagner la lune.
Le Lem doit perdre de la vitesse horizontale pour deux raisons:
- De manière à décroître la force centrifuge, ce qui permettra à l'attraction lunaire d'attirer le Lem vers la lune.
- Et parce que, lorsque le Lem atteint le lune, il doit le faire avec une vitesse horizontale nulle.
Le Lem commence donc avec une orientation horizontale, et, avec son réacteur principal, il crée une force qui permet de décroître la vélocité horizontale.
Au fur et à mesure que sa vélocité horizontale décroît, il en est de même pour la force centrifuge qui s'oppose à l'attraction lunaire; le Lem commence de tomber vers la lune; il a une accélération verticale qui crée une vitesse verticale constamment en accroissement.
Le Lem doit meneuvrer pour annuler sa vélocité verticale lorsqu'il atteint la lune, et il doit également arriver vertical sur la lune, et non horizontal.
Donc, progressivement, au fur et à mesure que la vélocité horizontale décroît, le Lem pivote d'une position horizontale vers une position verticale; cela ne se fait pas d'un seul coup, mais progressivement, comme montré sur la figure 5.
Le Lem crée avec son réacteur une force qui s'oppose aux vélocités et crée des décélérations sur les deux axes.
La manière dont la poussée du réacteur est distribuée sur les deux axes dépend de l'orientation (ou attitude) du lem, comme montré sur la figure 14.
Figure 14:La manière dont la poussée du réacteur est distribuée sur les deux axes.
Remqrque: Horizontal et vertical ne veulent rien dire dans une référence; dans ce cas, "vertical" veut dire perpendiculaire à la surface de la lune, et "horizontal" veut dire tangentiel à sa surface.
Si le Lem est plus proche de l'horizontale que de la verticale, c'est la force horizontale qui recevra la plus grande part de la poussée, et vice versa.
Il est donc possible d'obtenir une poussée horizontale donnée et une poussée verticale donnée en ajustant le couple /.
Mais comment le Lem pouvait il être tourné pour obtenir l'orientation désirée (ou attitude)?
Très simplement; sur chaque côté du Lem, aux endroits que j'ai cerclés, vous pouvez voir une paire de deux réacteurs latéraux, l'un horizontal et l'autre vertical.
Pourquoi deux?
Parce que les réacteurs latéraux verticaux permettaient de tourner le Lem, et de lui donner l'attitude désirée (et ainsi d'ajuster la distribution de la poussée sur les deux axes).
Et en ce qui concerne les réacteurs latéraux horizontaux, ils permettent de déplacer le Lem latéralement, et sont utilisés lorsque le Lem est proche de la lune, à basse vitesse, pour permettre à l'équipage de choisir le site d'alunissage adéquat (et seuls eux peuvent réaliser cette maneuvre, car le Lem n'a pas d'yeux pour voir le terrain).
La poussée horizontale doit être ajustée pour annuler la vélocité horizontale lorsque le Lem atteint la lune, et, de même, la poussée verticale doit être ajustée pour annuler la vélocité verticale lorsque le Lem atteint la lune.
L'ordinateur calcule donc les décélérations horizontale et verticale que le Lem devrait avoir de manière à arriver avec des vélocités horizontale et verticale nulles sur la lune.
Il les compare avec les décélérations courantes qui sont lues sur les accéléromètres.
Le but est d'arriver à faire coïncider les décélérations désirées calculées avec les décélérations mesurées qui sont données par les accéléromètres; en différentiant les valeurs désirées avec les valeurs effectivement mesurées, l'ordinateur calcule une correction sur la poussée et l'attitude qui essaie de faire en sorte que les prochaines mesures de décélération se rapprochent des valeurs calculées.
Je dois maintenant expliquer comment le guidage des avions est ordinairement effectué; la figure 15 explique comment cela fonctionne: Le pilote veut donner à son appareil une inclinaison qu'il rentre dans l'ordinateur; l'ordinateur compare de manière continue l'inclinaison désirée avec l'inclinaison mesurée par un capteur, et calcule une commande qui essaie de compenser la différence entre les deux, et faire en sorte que la prochaine mesure se rapproche de la consigne; cela est fait de manière continue, à un intervalle régulier (qui n'a pas besoin d'être très rapide): ce système de guidage est extrêmement efficace; l'inclinaison mesurée rejoint rapidement la consigne, et la suit avec une grande régularité, en dépit de perturbations éventuelles.
Figure 15: Comment le guidage fonctionne sur un avion.
L'AGC fonctionne exactement de la même manière: Il compare les décélérations données par les accéléromètres avec les valeurs théoriques qu'il a calculées pour atteindre la lune avec des vélocités nulles, sachant que ces valeurs calculées dépendent des vélocités horizontale et verticale courante du lem, ainsi que de son altitude, que l'AGC met continuellement à jour; à partir de la différence entre les valeurs désirées et les valeurs lues, l'ordinateur calcule une correction sur la poussée et l'attitude du Lem; par exemple, si la décélération horizontale calculée est plus grande que la décélération horizontale couramment lue, et que la décélération verticale calculée est plus grande que la décélération verticale couramment lue, mais que la différence entre les décélérations verticales est plus grande que celle entre les décélérations horizontales, l'AGC sait qu'il doit augmenter la poussée, et tourner le Lem pour le rendre plus vertical.
Donc, pas à pas, les valeurs lues sur les accéléromètres vont coller de plus en plus avec les valeurs calculées qui permettent de gagner la lune avec des vélocité nulles; cela arrive assez rapidement, et, après, il n'y a que de petites corrections qui sont faites à chaque pas, qui permettent aux valeurs lues de suivre idéalement les valeurs calculées: sur la lune, différemment de la terre, il n'y a pas de perturbations atmosphériques, et donc le guidage devrait se passer avec une bonne souplesse.
En fait, les vélocités ne seront pas exactement annulées au niveau de la surface de la lune, mais un peu avant, à une altitude modérée; cette altitude permet à l'équipage de visualiser la surface de la lune, et de choisir un endroit approprié pour l'alunissage en jouant sur les réacteurs latéraux horizontaux (les réacteurs latéraux verticaux ne sont utilisés que pour changer l'attitude du Lem dans la phase précédente).
Une fois qu'ils sont au dessus d'un endroit qui leur convient (pas de trou, et pas de rocher), les astronautes descendent le Lem à vitesse modérée avec une décélération finale pour un alunissage en douceur; le radar d'atterrissage permet d'ajuster la poussée idéalement pour cet alunissage en douceur.
Ces explications sont nécessaires pour vous faire comprendre pourquoi ce qui suit est absurde.
* * *
L'alunissage fut la phase la plus active de la mission Apollo. Le guidage d'atterrissage devait atteindre des objectifs qui étaient définis en position, velocité, acceleration (de sorte que le LM se maintienne droit), plus une dimension de "secousse" (le taux de changement de l'accélération). Durant la phase de visibilité, le logiciel autorisait l'équipage a redéfinir le site d'atterrissage. La poussée devait être contrôlée de manière continue. La navigation devait incorporer les mesures du radar d'atterrissage.
Redéfinir ne signifie rien, car cela suggère que l'ordinateur aurait pu choisir un site d'alunissage de lui-même; l'ordinateur ne peut pas maîtriser l'endroit idéal d'alunissage, car il n'a pas d'yeux pour visualiser le terrain; seuls les astronautes pouvaient le faire; une fois que le guidage avait atteint un point un peu au dessus de la lune avec des vélocités nulles, les astronautes commençaient à maneuvrer le Lem avec les réacteurs horizontaux latéraux pour l'amener à l'endroit d'alunissage idéal qu'ils pouvaient voir avec leurs yeux, et qui ne représentait pas de danger pour eux.
Figure 8: Le cycle mémoire pendant la descente propulsée (Données de simulation)
Même ainsi, nous avons essayé de rendre nos programmes suffisamment rapides pour préserver quelque marge contre la perte de puissance TLOSS due à une source inconnue. La contrainte principale était la période de deux secondes qui était adoptée dans la navigation moyenne-G utilisée pendant le vol propulsé. C'était la fréquence à laquelle le processus READACCS lisait les accéléromètres et lançait le grand processus SERVICER qui utilisait ces lectures comme le point de départ pour une nouvelle étape de navigation, guidage, poussée, commande d'attitude et affichage. Durant la descente lunaire, le temps de cycle décrit le temps qui était utilisé globalement par les processus, tâches, et interruptions, durant chaque période de deux secondes.
Ils devaient préserver une marge contre la perte de temps provenant s'une source inconnue, mais ils ne se sont jamais soucié de savoir quelle était cette source "inconnue" qui volait du temps à la CPU, et pouvait ainsi mettre en danger son fonctionnement.
D'ailleurs, "source inconnue" en informatique, cela ne veut rien dire du tout: Tout ce qui tourne sur l'ordinateur a été programmé par un ingénieur, et toutes les sources sont donc forcément connues; si les ingénieurs ne se rappellent même pas ce qu'ils ont programmé, c'est plutôt inquiétant!
En outre, comme je l'ai expliqué plus haut, ils avaient fait empirer les choses, en lui faisant faire une tâche qu'il n'aurait pas du, c'est à dire compter des pulsations d'angle avec des instructions logicielles.
Durant la phase de freinage, jusqu'au moment où le radar d'atterrissage localisa la surface, la marge de temps de cycle était de plus de 15%. Après que le radar commença d'acquérir, les calculs supplémentaires nécessaires pour convertir les données du radar vers le système de coordonnées de navigation abaissèrent cette marge à peut-être 13%. Lorsqu'un affichage tel que Mot 16, Groupe 68 fut ajouté, la marge retomba à 10% ou moins. Buzz Aldrin avait du flair quand il disait qu'après la deuxième alarme 1202, "Elle paraît survenir quand nous avons un 1668".
Donc, le simple fait de rajouter un affichage faisant s'écrouler la marge de temps de cycle de 13% à 10%!
On peut s'interroger sur les performances du programme de l'AGC!
Et les astronautes semblaient avoir plus de travail à acquitter les alarmes qu'à s'occuper réellement du guidage du vaisseau!
Avec une marge de 10% et une perte de fuite de 13%, le LGC n'avait simplement pas assez de temps CPU pour réaliser toutes les fonctions qui étaient requises. Grâce la flexibilité du concept exécutif — et très différemment de ce qui serait arrivé avec une structure wagon — Il n'y eut pas d'effondrement.
Donc ils ont une perte d'une source "inconnue" dont ils ne se soucient pas de trouver l'origine, et ils font encore s'écrouler plus la marge de temps de cycle en ajoutant un affichage, dont on peut se demander comment il pouvait autant faire chuter cette marge, et cela créait une situation de surcharge qui provoquait un redémarrage!
Mais tout va bien, madame ma marquise, puisque le "redémarrage" pouvait "recréer" une situation qui n'était pas pire que celle avant le redémarrage...ce qui n'était pas très difficile, car la situation avant le redémarrage n'était pas elle-même très brillante!
Table 1: Les processus actifs pendant l'alunissage.
La table 1 liste les processus qui étaient actifs pendant la descente propulsée d'Apollo 11. SERVICER avait la priorité la plus basse, mais prenait aussi de loin le plus de temps. Les processus de haute priorité qui pouvaient interrompre SERVICER étaient de durée relativement courte.
Cette table de processus est complètement incohérente: Juste après ils disent que SERVICER a la plus basse priorité (à cause de sa taille) et donc peut être interrompu par n'importe quel autre processus.
Mais SERVICER contient des fonctions très importantes, comme le guidage, qui devraient être à un haut niveau, parce qu'elles contrôlent la navigation du vaisseau spatial.
D'un autre côté, il y a un processus pour l'affichage (display), et un processus pour la gestion du clavier (DSKY), qui sont à des priorités plus élevées que SERVICER!
C'est complètement absurde, car, dans une application temps réel, l'interface humain, comme l'affichage et la gestion du clavier, sont toujours au plus bas niveau.
Le guidage est d'un type de tâche qui devrait normalement être à un haut niveau, car il est important qu'il soit régulièrement effectué.
Et le processus pour la compensation gyro du à l'IMU n'a pas de sens, parce qu'il n'y a pas moyen de calculer une compensation pour un mouvement supposé de l'IMU.
Ayant une priorité relativement basse à cause de sa taille, SERVICER était servi le dernier en ce qui concerne le temps disponible. Avec un temps de marge négatif, ce fut SERVICER qui n'avait pas encore terminé son travail quand le READACCS suivant, tournant ponctuellement, relanca SERVICER. Parce qu'il n'avait pas terminé, le SERVICER précédent n'avait pas libéré son jeu de mémoire et sa zone VAC — et donc la fois suivante que READACCS appela FINDVAC pour lancer SERVICER, l'exécutif lui assigna un nouveau jeu de mémoire et une nouvelle zone VAC. Que SERVICER ne libéra également pas. Après une certaine répétition d'une telle opération, l'exécutif vint à bout de ses reserves de jeux de mémoire et/ou zones VAC. Lorsque la requête suivante fut faite, l'exécutif fut incapable de la satisfaire, et appela BAILOUT avec un code alarme 1201 ou 1202.
C'est hilarant:
Parce que "SERVICER" avait la priorité la plus basse, il était exécuté après tous les autres processus.
Mais, parce que SERVICER réservait des jeux de mémoire et des zones VAC à chaque fois qu'il était lancé, les autres processus qui avaient la priorité sur lui ne pouvaient fonctionner à un moment donné par faute de disponibilité des jeux de mémoire et des zones VAC que SERVICER avait épuisé...et ne libérait pas car les autres processus plus prioritaires entravaient son fonctionnement!
C'est le système temps réel le plus débile qu'il m'ait été donné de rencontrer!
Figure 9: Le fonctionnement de SERVICER, avec et sans TLOSS
La figure 9 illustre comment SERVICER se comporte en présence d'une perte TLOSS sévére, et la Figure 10 compare l'utilisation des jeux de mémoire et des zones VAC dans un cas normal, et dans cas de haute perte TLOSS dans lequel un redémarrage se produit.
Figure 10: Effet de la perte TLOSS sur l'exécutif et la file d'attente des ressources durant la descente lunaire.
L'effet imaginaire de TLOSS, avec un usage abusif du copier-coller.
ces diagrammes sont un peut trop répétitifs pour être crédibles.
Il y a une similarité entre l'usage des jeux de mémoire et les zones VAC alors que les processus qui les utilisent sont assez différents.
L'effet intéressant de cette chaine d'événements, durant P63, est que le problème s'arrangea de lui-même. Le redémarrage du logiciel reconstruisit seulement l'incarnation la plus récente de SERVICER, et vida la queue des SERVICERs non terminés qui s'étaient accumulés. De plus, le redémarrage termina aussi les fonctions qui n'étaient pas protégées contre le redémarrage parce qu'elles n'étaient pas considérées comme critiques — y compris le moniteur de DELTAH, mot 16, groupe 68. c'est pourquoi, à la suite des deux alarmes dans P63, l'affichage retourna du groupe 68 vers le groupe 63.
L'effet intéressant du redémarrage est que l'AGC était parvenu à un comportement si erratique que le redémarrage ne pouvait pas faire empirer la situation!
Ici, un système de protection de redémarrage qui était primitivement motivé par la possibilité de problèmes matériel fournit synergétiquement un moyen de desserrer l'étau de la charge de calcul en réponse à un embouteillage logiciel causé par la fuite TLOSS. Nous avions conçu un système temps réel qui, sous certaines conditions, était "tolérant contre l'erreur".
Donc, l'entrée matérielle que l'AGC était incapable c'acquérir correctement créant une situation qui se détériorait de plus en plus, et le fait de le redémarrer éliminait l'effet de la mauvaise acquisition du matériel précédente; après le redémarrage, l'AGC était à nouveau plus sain, à nouveau prêt à de détériorer à la suite d'une mauvaise acquisition du matériel!
Il était très tolérant des erreurs en effet, il pouvait redémarrer avant que l'acquisition incorrecte du matériel ne le bloque complétement!
Mais pourquoi personne n'a t'il penser à fonctionner de cette manière avant Apollo...ni après d'ailleurs?
Pendant P64, la situation était différente. En plus des équations normales de guidage, il y avait un nouveau traitement qui fournissait la possibilité de redéfinir le site d'alunissage. Avec cet ajout, l'essentiel du logiciel en lui-même laissait une marge de temps de cycle de moins de 10%. Les alarmes n'en finissaient pas d'arriver. Il y avait des alarmes 1201 et 1202 toutes les 40 secondes. A chaque fois, le redémarrage logiciel vidait la queue exécutive mais n'arrivait pas à alléger la charge.
Pendant la phase d'alunissage, qui était la phase qui requérait la plus grante attention de la part des astronautes, les alarmes de l'ordinateur se produisaient plus souvent avec redémarrage systématique et dérangeaient les astronautes au pire moment.
Au lieu d'être une aide pour l'alunissage, l'ordinateur était exactement le contraire, une nuisance.
C'est un miracle que le Lem ne se soit pas écrasé!
Au temps MET 102:43:08, prévenant l'alarme suivante, Armstrong commuta l'autopilote du mode AUTO sur le mode ATT HOLD, allégeant la charge de calcul, et entra ensuite le mode semi-manuel P66,dans le quel la charge était encore plus légère. Après 2 minutes et 20 secondes passées à maneuvrer en P66 sans alarmes, the LM alunit.
Comprenez: Armstrong a pris le contrôle manuel parce qu'il a réalisé que l'AGC allait faire le Lem s'écraser sur la lune!
Un ordinateur qui ne peut pas en faire beaucoup n'est pas très utile!
* * *
Cinq mois plus tard, Apollo 12 survécut à une décharge électrique durant la montée en puissance et réussit à alunir. Grâce en partie à un nouveau groupe (69) que nous avions défini pour permettre à l'équipage de faire des corrections de position basées sur les données de traçage au sol durant la phase de freinage, les astronautes Pete Conrad et Alan Bean purent poser le LEM à portée d'un robot Surveyor qui avait aluni en avril 1967. L'alunissage précis d'Apollo 12 pava la voie pour des alunissage en terrain plus difficike.
Donc, Apollo 12 fut sauvé parce que les programmeurs ont permis aux astronautes de prendre des décisions à la place de l'ordinateur, et de corriger les erreurs de l'ordinateur.
Peut-être que le mieux aurait été d'éteindre l'AGC; cela aurait pu être la manière dont il aurait fonctionné le mieux!
Ce fut seulement après Apollo 12 que nous commençames de comprendre l'autre problème épineux.
Cela commença lorsque Clint Tillman de Grumman Aerospace (le constructeur du module lunaire) remarqua des oscillations de poussée durant les simulations de la descente finale, de l'ordre de 5% de la poussée DPS. Cela poussa Tillman à examiner les données de télémétrie de Apollo 11 et 12, sur lesquelles il remarqua des oscillations de poussée pendant les phases finales d'alunissage qui étaient de l'ordre de 25% de pic à pic. (Voir Figure 12). Ce fut l'époque à laquelle le commandant utilisait simultanément le commutateur ROD pour contrôler le taux d'altitude, et la manette pour maneuvrer le véhicule. Parce que les tracés de ces données ressemblaient aux créneaux et aux tourelles d'un château-fort (ou une noix crénelée), ce problème resta connu sous le nom de "crénelations de poussée".
Il ne pouvait pas y avoir de telles oscillations; sans atmosphére, il n'y a pas de perturbations sur la lune, et donc le guidage avait toute raison pour rester souple et régulier, sans oscillations; et la dernière chose que l'équipage aurait du faire est de contrarier le guidage de l'ordinateur en introduisant des perturbations artificielles avec un commutateur et une manette...à moins que l'ordinateur travaille si mal (et les nombreux redémarrages n'aident pas), que l'équipage devait compenser son comportement erratique; mais, en aucune manière, l'équipage n'aurait pu faire aussi bien qu'un ordinateur fonctionnant correctement.
Figure 11: Premier rapport des crénelations de poussées.
Klumpp, à Cambridge, relia l'excitation qui causait les oscillations à un phénomène précédemment non identifié qui était connu comme "l'acoup IMU". L'IMU était localisé au dessus, et à peu-près quatre pieds devant le centre de masse du véhicule. De petites mais rapides maneuvres ponctuelles, telles que celles requises durant la descente finale, bougeaient l'IMU de telle sorte que cela était interprété par les accéléromètres comme un changement dans la vélocité verticale du véhicule. Ceci affectait en retour les calculs du taux d'altitude, et la poussée estimée.
Cette explication est totalement ridicule: Le guidage restait de toute évidence souple (en l'absence de perturbations atmosphériques sur la lune),et donc l'IMU n'avait pas de raison d'être bousculé de cette manière, et de perturber la lecture des accéléromètres.
Si cela en arrivait au point que l'IMU était effectivement bousculé de cette manière, cela voulait dire que le Lem avait un comportement très dangereux, que l'ordinateur était incapable de le guider efficacement comme il l'aurait du, et qu'il avait de grande chances de s'écraser sur la lune.
Mais cette théorie ne faisait que partiellement expliquer le comportement de poussée observé dans les données de vol.
Les moteurs de fusées dont la poussée peut être ajustée étaient et sont encore inhabituels, mais un moteur à poussée variable était une nécessité pour écrire un programme d'alunissage. Un moteur à poussée fixe et de simples équations de guidage pouvait diriger le vaisseau vers un point de la surface lunaire. Mais pour y arriver droit et lentement, avec de la visibilité et la possibilité de faire du sur-place pendant le choix d'un site d'alunissage, cela requérait un moteur qui pouvait contre-balancer la gravité lunaire en faisant varier sa poussée au fur et à mesure que la masse décroissait, alors que la composante verticale du vecteur de poussée changeait durant les maneuvres d'attitude, et alors que l'astronaute requérait des changements dans le taux de descente.
Ce n'est pas la masse du véhicule qui décroît, mais sa vélocité, sa masse reste la même.
En aucune manière l'astronaute ne doit changer le taux de descente qui est déterminé par la trajectoire calculée.
S'il le faisait, le taux de descente pourrait devenir inadéquat pour annuler les vélocités au niveau de la lune (ou un peu au dessus).
Eventuellement, l'ordinateur pourrait encore avoir le temps de corriger le taux de descente pour rattraper une trajectoire permettant d'annuler les vélocités au niveau de la lune, mais, dans certains cas, l'ordinateur pourrait ne pas avoir le temps de rattraper une telle trajectoire, et ne pourrait arriver à annuler les vélocités avant d'atteindre la lune..ce qui résulterait en un crash spendide!
A moins, bien sûr, que l'ordinateur fonctionne de manière désastreuse, et que l'équipage réalise que, s'il le laissent faire, il fera s'écraser le Lem sur la lune,et qu'il vaut encore mieux faire des corrections manuelles, même si ces corrections manuelles ne peuvent pas être aussi bonnes que celles faites par un ordinateur fonctionnant correctement.
Les équations de guidage determinaient l'accélération qui étaient requises, à la fois en grandeur et direction. L'autopilote maneuvrait le véhicule pour satisfaire la direction de poussée commandée par le guidage. C'était au programme de contrôle de la poussée de contrôler sa grandeur. Le contrôle de poussée Throttle-control commençait par calculer la masse du LEM. Connaissant la masse, il déterminait la grandeur de la correction de poussée requise pour changer l'accélération du véhicule à partir de celle mesurée par les accéléromètres à celle commandée par les équations de guidage, convertissait celle-ci en unités utilisées par le système de poussée (à peu près 2,8 livres par pulsation), et l'envoyait au matériel.
Ceci est complètement ridicule et absurde; l'ordinateur n'a pas à calculer la masse, cela n'a rien à voir avec le guidage; seules l'altitude, les vélocités, et les décélérations sont à prendre en compte; la conversion d'unités est également ridicule et inepte; le système complet peut travailler avec les mêmes unités; la conversion d'unités fait perdre inutilement du temps de calcul (et l'AGC est cruellement en manque de temps).
Les accéléromètres de l'IMU ne mesuraient pas réellement une accélération; ils comptaient simplement des incréments de vélocité depuis la dernière lecture. Parce qu'un changement de poussée commandé lors de la passe précédente de guidage arrivait quelque temps après la lecture des accéléromètres, le delta-V mesuré ne montrait pas le plein effet de l'ajustement le plus récent.
Même s'il y a un petit délai entre les lectures courantes des accéléromètres et la commande précédemment commandée de poussée, cela n'a pas beaucoup d'importance, car il y a une correction continue qui est extrêment efficace, sans qu'il soit besoin qu'elle soit très rapide, surtout en l'absence de perturbations atmosphériques sur la lune, et que, entre deux pas, les changements ne sont pas très importants.
Figure 12: Excursions de poussée durant Apollo 12
Le contrôle de poussée devait compenser cet effet. Le niveau de compensation dépendait du moment où la commande poussée était appliquée, et il dépendait aussi de la rapidité avec laquelle le moteur répondait à la commande. la documentation de l'ICD spécifiant que le délai d'application de la poussée était de 0.3 secondes.
Premièrement, il n'y avait pas moyen de compenser le temps de retard du réacteur.
"compenser" consisterait, au lieu d'utiliser les lectures courantes des accéléromètres, à utiliser à la place une prédiction de ce que seront ces lectures lorsque retardées du temps de réaction du réacteur.
Mais les lectures des accéléromètres ne peuvent pas être prédites (si c'était le cas, on n'en aurait pas besoin dans le guidage), et il n'est donc pas possible de compenser le temps de retard du réacteur.
Deuxièmement, SERVICER tournait toutes les deux secondes (cela pouvait même être plus, car parfois SERVICER n'arrivait pas à terminer son traitement dans la période requise), ce qui veut dire que la poussée du réacteur restait la même et non mise à jour par la lecture des accéléromètres, pendant deux secondes (au moins); Cela ne fait donc guère de différence si le réacteur avait un temps de retard de 0,3 secondes (et il finit même avec un temps de retard de 0,2 secondes).
Troisièmement, SERVICER pouvait être interrompu par un autre processus à tout moment (à cause de sa priorité la plus basse); cela signifie que, entre la lecture des accéléromètres et la fabrication de la correction utilisant cette lecture, un processus (ou même plusieurs) pouvait interrompre SERVICER, et créer un délai variable entre la lecture et l'utilisation de cette lecture, délai variable qui pouvait éventuellement dépasser le temps de retard du réacteur.
Si le temps de retard du réacteur devait être compensé, alors ce délai variable entre la lecture des accéléromètres et leur utilisation devait également être compensé; mais, même à supposer qu'il soit possible d'appliquer une compensation si ce délai était connu (ce qui n'est même pas le cas), ce n'est tout simplement pas possible parce que ce délai est inconnu, et variable.
Nous nageons ici dans un océan d'absurdités!
Il revint à l'auteur de programmer et tester la routine de contrôle de poussée. Sur un graphe produit par une simulation qui représentait adéquatement le DPS en utilisant un temps de réaction de 0,3 secondes, j'ai observé que l'oscillation qui se produisait dans le niveau réel de la poussée après un changement important de poussée était commandé sans compensation pour le temps de réaction. Lorsque je compensai de 0,1 seconde, je vis que l'oscillation était réduite. Lorsque je compensai de 0,2 secondes, l'oscillation apparut être virtuellement éliminée. Les choses en restérent là. Klumpp se souvient que je disais, "C'est comme la médecine, il ne faut pas lui donner plus de compensation que nécessaire".
Klumpp savait que ce n'était pas "juste comme la médecine", mais il n'insista jamais pour que je programme le nombre correct. En examinant ses motivations, 15 ans plus tard, Klumpp écrivit:
J'ai estimé qu'il était important de nourrir la confiance en soi, de laisser les décisions de collaborateurs sur de petits points prévaloir, même si ces décisions n'étaient pas optimales. Alors je gardai mon opinion pour moi, et je laissai Don décider, au moins jusqu'à ce qu'il puisse reconsidérer sa décision indépendamment.
J'aime bien comme les programmeurs différent sur le niveau de compensation, et l'un laisse l'autre programmer sa propre compensation pour "nourrir sa confiance en soi", même s'il pense que la compensation n'est pas "optimale".
Pourtant une erreur sur cette compensation pourrait avoir des conséquences sérieuses et causer un comportement dangereux du Lem (à supposer que cette compensation ait un caractére bénéfique sur le caractére oscillatoire, ce qui n'est pas le cas).
Mais une bonne entente qntre les programmeurs est plus importante, n'est-ce pas?
En examinant mes propres motivations, je crois que l'agacement que j'ai ressenti envers les termes de compensation pour bousculer ma logique de poussée peut s'être traduit en un désir de ne pas compenser plus que nécessaire. Quoiqu'il en soit, aussi bien Apollo 11 que Apollo 12 ont volé avec 0.2 secondes de compensation pour un retard de poussée de 0.3 secondes.
Ce qui est incroyable est que l'auteur semble savoir quelle compensation serait nécessaire, et il applique néanmoins moins que celle-ci!
Mais maintenant, à la fois l'analyse de Klumpp, et un rapport indépendant préparé par J. A. Sorensen à Bellcomm, ont conclu que "le caractère oscillatoire de la commande de poussée était apparemment du au fait que la constante de temps du moteur de descente était plus faible que supposé" (Sorensen). comme Klumpp en trouva l'origine. La performance du moteur de descente a été améliorée, mais la documentation n'a pas été mise à jour. Le réel temps de retard pour le moteur de descente était d'environ 0.075 seconds. Il s'avéra que nous avions surcompensé. Le résultat est que la poussée était peu stable.
L'analyse de Klumpp a eu un effet encore plus étonnant. Elle montra que si le logiciel avait compensé à 0.3 secondes sur Apollo 11, la poussée aurait été instable. Les oscillations de poussée, au lieu de diminuer, auraient augmenté. Suite à la mise au ralenti dans P63, ou peut-être dans P66 sous l'excitation de l'acoup de l'IMU, le moteur DPS aurait rapidement oscillé entre les poussées minimale et maximale. Il ne fait pas de doute que le contrôle de mission, très logiquement, aurait relié le comportement de la poussée aux alarmes 1202 qui se produisaient pour des raisons entiérement indépendantes.
Dans un projet tel que celui d'Apollo, on pourrait s'attendre à ce qu'il y ait une bonne communication entre les ingénieurs; il semble que, lorsqu'une amélioration matérielle était faite, l'équipe de développement logiciel n'était même pas informée ce cette amélioration, et continuait à programmer comme s'il n'y avait pas eu d'amélioration, avec des conséquences qui pourraient aller jusqu'à être fatales!
Cela a seulement marché parce que l'auteur avait décidé de compenser moins que nécessaire (avec la désapprobation de son supérieur).
Le plus drôle est qu'il n'était pas même possible d'appliquer une compensation!
Un arrêt aurait été inévitable. En toute modestie, cela apparaît être le cas que si l'auteur avait codé la compensation "correcte" dans la routine de contrôle de la poussée, Apollo 11 n'autait pas aluni. J'invite quelqu'un qui n'a pas d'enjeu personnel et une compétence en mathématiques de réexaminer cette théorie.
C'est vraiment hilarant; si la compensation "correcte" avait été codée, se reposant sur un état du moteur n'incorporant pas une amélioration dont l'équipe de développement n'avait pas été informée, le lem se serait écrasé sur la lune!
The lem a été sauvé pace que Klumpp n'insista pas pour que son subordonné programme la valeur correcte de manière à "nourrir sa confiance en soi".
Grosse rigolade, c'est vraiment un scénario hollywoodien!
Surtout lorsqu'en fait il n'était pas possible d'appliquer une quelconque compensation!
* * *
Nous avons réglé le probleme de l'acoup de l'IMU en retirant les changements de vélocité dus au mouvement de l'IMU des mesures d'accélérations. Nous avons corrigé le temps de retard de poussée et les simulations ont montré que cela réglait en effet le problème d'instabilité de la poussée. Il n'y eut pas de changement fait sur Apollo 13, mais cette mission ne put pas tenter un alunissage.
Et ils ont seulement réglé ce problème après plusieurs alunissages!
Curieusement, un changement fait avant le problème de poussée vint en lumière, et qui existait sur Apollo 13, aurait offert une solution de secours si la poussée automatique avait échoué. Un nouveau groupe (92) fut défini, que l'équipage pouvait sélectionner pour voir le niveau de poussée désiré par le guidage. La logique, qui aurait arrêté le guidage automatique si la poussée etait (ou apparaissait être) connectée sur MANUEL, fut supprimée. Ces changements laissaient les astronautes prendre le contrôle de la poussée pendant P63 or P64 while alors que la guidage continuait à commander l'attitude. Je ne sais pas si ces procédures difficiles furent jamais pratiquées.
Tout à fait désopilant: L'équipage pouvait sélectionner le niveau de poussée désiré par le guidage!!! C'est contradictoire, car, s'il y a un niveau de poussée désiré par le guidage, et que les astronautes le changent, cela ne sera plus le niveau désiré par le guidage!
Et laisser l'équipage prendre contrôle de la poussée pendant que l'ordinateur gardait le contrôle de l'attitude, n'a absolument pas de sens, et est totalement absurde: Le couple poussée/attitude détermine la grandeur des poussées horizontale et verticale et ne peut être séparé; le contrôle de la poussée et de l'attitude doit être donné à une même intelligence, et le mieux est de le donner à l'ordinateur (s'il fonctionne correctement).
C'est un peu comme su vous conduisiez une voiture, et que vous disiez à votre passager: "maintenant je ferme les yeux, et tu regardes la route pour moi, mais je garde le volant"!
Ce type de changement est celui qui pourrait garantir un écrasement sur la lune.
Une absurdité de plus à ajouter à la déjà longue liste!
Le problème des alarmes de surcharge de l'exécutif fut traité en plusieurs occasions.
Le mode de radar de rendez-vous fut placé sur LGC pendant la montée. Pour les futures missions, la checklist de descente fut changée. En même temps, nous avons ajouté de la logique à LUMINARY pour tester le mode du radar de rendez-vous, et, s'il n'était pas sur LGC, envoyer un signal pour remettre à zéro les compteurs du radar de rendez-vous.
Allan Klumpp a étudié le problème de l'exécutif sous un autre angle. Il découvrit que sous les conditions dans lesquelles la perte TLOSS se produisait de manière intermittente, ou lorsque le niveau de l'activité de l'ordinateur fluctuait en présence du TLOSS, il était possible pour les processus SERVICER non terminés qui avaient été interrompus pendant l'application des commandes d'attitude, mais n'avaient pas encore été nettoyés par un redémarrage logiciel, d'être repris à un temps ultérieur — avec la possibilité que des commandes d'attitude inappropriées puissent être appliquées à l'autopilote. A temps pour Apollo 13, Klumpp imagina une solution dans laquelle un processus SERVICER occasionel pourrait être complétement abandonné pour rattraper le retard, si nécessaire.
Comment pouvait t'il déterminer dans quel cas le processus SERVICER devait être entiérement jeté?
Et pourquoi ne pas plutôt purger la queue des SERVICERs qui de toute façon avait toutes chance de ne pas se vider!
Mais, pour l'avenir, aucun de ces changements n'a fourni un allégement fondamental de la contrainte de la période fixe de deux secondes du guidage. Un modèle de terrain devait être ajouté au routines du radar d'alunissage pour permettre l'alunissage sur un terrain difficile. Des modifcations de guidage étaient sur le gril. D'où viendrait le temps nécessaire?
Nous avons développé un concept que nous avons appelé "SERVICER variable", dans lequel la période de guidage pouvait s'allonger si nécessaire. La crainte que l'intervalle de deux secondes ne pouvait être changé dans le logiciel se révéla infondée. Il suffisait de mesurer l'intervalle nécessaire pour le guidage et d'utiliser cet intervalle mesuré à la place de l'intervalle de deux secondes qui était implicite d'après une estimation. Nous avons fait fonctionner le SERVICER variable dans une version hors ligne (off line) de LUMINARY, et démontré son immunité a de très hauts niveaux de perte TLOSS.
Donc, puisque le processus SERVICER pouvait s'avérer incapable de faire son traitement complet dans une période de deux secondes, ils ont imaginé une période variable mesurable au leu d'une période fixe, ce qui lui permettait de dépasser cette limite, et ainsi éviter le blocage de l'AGC.
Mais cela signifie également que le traitement qu'il faisait n'était plus effectué dans une période de temps déterminée.
C'est ce que nous pourrions appeler du temps réel "flexible"...mais ce n'est plus du temps réel par définition!
Peut-être que l'AGC pouvait éviter des redémarrages de cette manière, mais nous pouvons avoir de sérieux doutes sur son bon fonctionnement!
Une approche plus intelligente aurait été (à part de ne pas lui faire compter des impulsions matérielles avec des instructions logicielles, et ne pas lui faire faire des conversions d'unités inutiles) de séparer la partie la plus essentielle de SERVICER qui devait absolument être faite à chaque période de parties moins essentielles qui pouvaient éventuellement sauter une période (ou même davantage).
La première partie essentielle aurait été faite à chaque période, et les parties moins importantes auraient été faites alternativement.
Ce cette manière, SERVICER aurait pu garder sa période de temps determinée de deux secondes, et encore supporter la charge sans écroulement!
La libération du carcan des deux secondes a permis à d'autres idées d'être prises en compte. L'astronaute John Young a suggéré une fonctionnalité que nous avons appelée P66 LPD. A présent P66 avait évolué en un programme encore plus flexible qu'il ne l'était quand Armstrong vola sur Apollo 11. Une de ses nouvelles caractéristiques était que, si l'équipage recommutait le mode d'attitude de ATT HOLD sur AUTO, le guidage contrôlerait alors l'attitude pour annuler la vélocité horizontale. L'idée de Young était que le LGC affiche un angle LPD (comme durant la phase de visibilité) qui montrerait au commandant la place où le LM viendrait se positionner, si à cet instant l'autopilote était réglé sur AUTO.
Cela n'a absolulment pas de sens: L'astronaute met le commutateur sur AUTO, regarde si l'endroit auquel l'ordinateur fera alunir le Lem si le mode AUTO est maintenu convient, et sinon revient sur ATT-AUTO, se remet sur AUTO, regarde si l'endroit auquel l'ordinateur fera alunir le Lem si le mode AUTO est maintenu convient, et sinon revient sur ATT_AUTO...Cela peut prendre un certain temps avant que l'astronaute ne voie que l'endroit où le mode AUTO posera le Lem convient!
Déplacer le Lem vers l'endroit désiré avec les réacteurs latéraux est bien plus commode et rapide.
Une absurdité de plus à rajouter à la liste!
Pour rendre le P66 LPD efficace, le logiciel devait réagir instantanément dès que l'astronaute le mettait sur AUTO — plus rapidement que la période de deux secondes à laquelle des parties de P66 opéraient, le permettaient. Nous avons programmé une version dans laquelle un processus tournant à chaque quart de seconde réagissait au changement dans le mode de l'autopilote en envoyant immédiatement des commandes d'attitude et de poussée, et répondait de ce fait bien plus rapidement et précisément aux entrées du commutateur ROD. Dans ces simulations faites sur le simulateur de mission du LM (LMS) à Cap Canavéral, avec ses fabuleux modèles de terrain visibles sur les hublots du LM, nous avons montré que ce système facilitait des alunissages très précis.
S'ils veulent qu'il y ait une réaction immédiate à un changement du commutateur, il y a encore un moyen plus rapide: Générer une signal matériel lorsque le commutateur est tourné, lequel pourrait déclencher une interruption matérielle qui pourrait traiter immédiatement le changement du commutateur; et cela éviterait de faire tourner inutilement un processus quand il n'a rien à faire(et ainsi contribuer à la surcharge de l'AGC)!
En outre, cela n'a beaucoup pas de sens de réagir très rapidement à un changement du commutateur, car les astronautes agissent dessus à la vitesse humaine qui n'est pas très rapide!
Ni le SERVICER variable ni me P66 LDP n'ont jamais été mis effectivement en oeuvre. La NASA a pris la décision qu'Apollo 17 serait la dernière mission. Avec si peu de missions restantes, l'équipe de développement du logiciel prit la décision conservative — qu'aucun changement majeur ne serait fait au logiciel. En synchronisant les mesures du radar d'alunissage avec le moment où les accélérateurs étaient lus, Robert Covelli gagna suffisamment de temps pour affiner dans le modèle de terrain pour Apollo 15, 16, and 17.
Pour l'aide que ces "améliorations" apportaient, c'est aussi bien qu'elles ne furent jamais utilisées (les shadoks en trouveront peut-être l'usage)!
Et "synchroniser les mesures du radar d'alunissage avec le moment où les accéléromètres sont lus" ne veut rien dire du tout et n'apporte pas d'amélioration: Synchronisés ou non, le temps de lecture du radar s'ajoutera toujours au temps de lecture des accéléromètres, qu'ils se succèdent immédiatement, ou qu'ils soient séparés par un laps de temps; il n'y a donc pas de gain de temps du tout!
Apollo 14 apporta à l'auteur une brève notoriété. Le commutateur d'arrêt des opérations sur le panneau d'instrumentation envoyait un signal parasité qui aurait pu gâcher l'anulissage d'Alan Shepard et Ed Mitchell. J'ai écrit le bout de programme qui a traité ce signal. L'astuce consistait à simplement changer quelque registres, d'abord pour tromper le moniteur d'arrêt pour lui faire croire qu'un arrêt était déjà en cours, et ensuite pour l'acquitter de manière à ce que l'alunissage puisse continuer sans encombre. La procédure se généralisa et fut exécutée sans problème avec les tapes sur touches 61 DSKY. La partie la plus intéressante de l'incident d'Apollo 14 est sans doute le nombre de versions différentes qui ont été présentées à l'histoire. Mais Apollo 14 est une autre histoire.
Un bout de programme pour tromper la procédure d'arrêt et lui faire croire qu'un arrêt est déjà en cours?
Pourquoi simplement ne pas démarrer cette procédure d'arrêt en filtrant electroniquement le signal "parasité"?
Et si un arrêt était vraiment nécessaire pour une autre raison, est-ce que la procédure serait également "trompée" pour lui faire croire qu'un arrêt est déjà en cours?
Je penserais plutôt qu'Apollo 14 fut sauvé parce que l'équipage n'a pas fait confiance à l'ordinateur de bord et a pris le contrôle manuel des commandes!
En Décembre 1972, je suis allé à Cap Canavéral pour le lancement d'Apollo 17. A cette époque, la navigation spatiale était le top. L'écrivain Tom Wolfe était là avec le photographe Annie Liebowitz pour écrire l'histoire en quatre parties pour le magazine des Rolling Stones qui était le précurseur de "La juste chose" (The right stuff) . Ce fut le seul lancement d'Apollo de nuit. Le ciel embrumé de Floride avait un éclairage orangé d'horizon à horizon alors que la grande fusée Saturne V déchirait le ciel avec sa flamme d'un quart de mille qui léchait à la fin comme une flamme de flambeau.
J'ai passé quelque jours au LMS à tester quelque procédures que nous avons appelées "des programmes mémoire effaçables". C'étaient des bouts de code qui pouvaient être installés dans des zones VAC inutilisées pour gérer certains problèmes de fonctionnement — une idée dont l'origine remontait à l'incident d'Apollo 14. Puis je retournai à Cambridge pour l'alunissage lui-même.
Cest hilarant: Il y a certains cas où SERVICER épuisait les zones VAC dont auraient eu besoin les processus plus prioritaires, alors ils gaspillaient encore plus de zones VAC en installant des bouts de code dans celles-ci; de cette manière, les redémarrages se produiraient encore plus souvent pace que l'exécutif serait plus rapidement à court de zones VAC (Oh, j'oubliais le SERVICER "variable"...qui ne fut jamais installé et est une injure au temps réel!).
Puis vint le plaisir de regarder pendant que Gene Cernan and Jack Schmitt, un géologiste par formation, exploraient la lune sur la jeep lunaire, s'aventurant jusqu'à trois milles, hors de vue du vaisseau spatial. Et ce fut la dernière fois que quelqu'un a jamais marché sur la lune.
Si jamais quelqu'un a marché sur la lune; peut-être, peut-être pas, qui sait?"
Et bien, ce fut vraiment une charmante histoire..Je suis sûr qu'elle aurait plus à Lewis Caroll!
Figure 13: quelques uns des personnes impliquées.
Front Row: Vince Megna, "Doc" Charles Stark Draper, l'auteur,
Dave Moore, Tony Cook. Back Row: Phil Felleman, Larry Berman,
Allan Klumpp, Bob Werner, Robert Lones, Sam Drake.
Certains ont de grands sourires sur leur visage.
Sont-ce des sourires de satisfaction...ou de moquerie?
D'autres grimaceraient plutôt
Est-ce par modestie ou pour ne pas montrer ouvertement leur satisfaction...ou par tristesse d'avoir eu à jouer une triste comédie?
J'ai fait un peu d'humour avec des images de Apollo 11 sur le thème de ce rapport:
