CONTES DE L'ORDINATEUR DE BORD APOLLO
 J'ai lu le récit de Don Eyles, "Tales from the lunar module guidance computer", expliquant comment le guidage était fait dans le module lunaire, et c'est vraiment la chose la plus hilarante qu'il m'ait été donné de lire, une série de gags que je vais expliquer dans cet article. video. |
 Ils disent qu'ils retardent l'armement du moteur, car ils soupçonnent qu'il y a une fuite, et l'armement prématuré du moteur pourrait avoir des conséquences explosives lorsque le moteur est mis à feu. Mais cela ne résout pas le problème de la fuite: Peut-être que le moteur n'explosera pas à l'allumage, mais il pourrait exploser plus tard. |
 Ce n'est que reculer pour mieux sauter. S'ils soupçonnent une fuite, pourquoi ne réparent-ils pas simplement cette fuite? |
 Ils se plaignent que l'AGC s'est comporté de manière incorrecte parce que le moteur était plus lent à réagir qu'attendu (à cause d'un problème de pressurisation), et un paramètre n'était pas convenablement réglé parce qu'ils n'en étaient pas informés. |
 Hé, ce n'est pas leur faute, monsieur "personne ne le leur a dit"! Peut-être que celui qui aurait dû les informer dira qu'ils auraient du deviner par eux-mêmes! |
 J'aime ça: "Le programme d'ordinateur était encore assez petit pour tenir dans un seul listing"...voyez la taille du listing, LOL! |
 L'ordinateur travaillait avec le système métrique, mais les astronautes n'aimaient pas le système métrique et étaient trop paresseux pour faire l'effort de travailler avec; l'ordinateur avait donc la tâche de convertir les unités dans des unités anglo-saxonnes pour leur convenir. |
 Bien sûr, il avait plein de temps à gaspiller, il faisait plein de redémarrages pendant la descente, surtout au moment le plus crucial, parce qu'il manquait de temps pour faire son travail! |
 J'aime ça: L'ordinateur voit le radar dans une mauvaise position, mais ses interrupteurs sont dans la bonne position; alors l'équipage a du mettre les interrupteurs dans la mauvaise position de manière à faire disparaître l'alarme! |
 Armstrong a du passer le taux d'autopilote de 5 degrés/seconde à 25 degrés/seconde...Mais est-ce que l'autopilote n'est pas censé se régler lui-même? Et les données radar peuvent seulement être incorporées dans le système de guidage si les astronautes le permettent. Cela signifie qu'ils peuvent décider d'alunir sans l'utiliser! |
 Ils disent aussi que, si les données radar sont incorporées dans la navigation, elles ne l'affecteront pas de manière "adverse". Quelle serait l'utilité du radar s'il affectait le guidage de manière adverse? |
 L'ordinateur a un problème, envoie une alarme, et attend un ordre avant de continuer. Les ingénieurs sont paniqués, et ne savent comment réagir. |
 Finalement Houston prend la décision de donner le "Go" pour permettre à l'ordinateur de continuer (le "Go" est donné par un jeune héros). Mais cela prend une deme-minute, et, pendant de temps, les astronautes sont laissés dans l'incertitude. |
 J'aime ça: "Dans la transcription officielle de la communication entre le vaisseau spatial et le sol pendant la descente motorisée, ce sont les seuls points d'exclamation". Alors le transcripteur a été capable de lire des points d'exclamation dans les mots oraux d'Armstrong! Quel transcripteur! |
 Ils disent qu'ils ont bâti un système de temps réel révolutionnaire parce qu'ils lui ont donné des fonctionnalités...qui existent dans tous les systèmes de temps réel, et qui sont à la base du temps réel. |
 De plus, le minimum absolu pour un temps réel est d'avoir une pile d'appels, et l'AGC n'avait pas de telle pile. Et il n'avait pas d'instruction pour gérer le temps réel. Comment est-ce que les jobs étaient gérés sans instruction pour le faire? |
 Ce qui est hilarant est la table de tâches d'ils donnent: le job SERVICER, qui contient les tâches les plus importantes, comme le guidage, qui est essentiel et devrait tourner de manière régulière, avait la priorité la plus basse. |
 D'un autre côté, les tâches d'interface, comme l'affichage et la gestion du clavier, sont dotées d'une priorité plus élevée que SERVICER. C'est le seul système temps réel que j'ai jamais vu dans lequel les tâches d'interface humaines reçoivent une priorité plus élevée que les tâches automatiques critiques! |
 Le mode AUTO d'Apollo 11 correspondait précédemment au mode MANUAL, alors que le mode LGC correspondait précédemment à un mode AUTO!!! Donc, lorsque les astronautes se connectaient sur AUTO, ils pouvaient avoir un doute s'ils ne se connectaient pas en fait sur MANUAL! |
 Ce diagramme est hilarant! AUTO et SLEW font exactement la même chose. Et LGC, comme AUTO et SLEW, se connecte à une référence de 28 volts et 800 Hertz; mais cette référence est déphasée par rapport à l'autre référence, et ce déphasage fait que le résolveur génère des impulsions d'angle même lorsque le radar n'est pas connecté, créant ainsi de fausses données avec lesquelles l'AGC travaille! |
 Ils parlent de ce problème qui a été "documenté mais jamais corrigé!" C'était mieux de le laisser ainsi, afin qu'il continue de créer des problèmes! |
Ceci aurait pu être évité en utilisant la même référence de 28 Volts! Ils disent aussi que le déphasage dépend du moment où le LGC est mis sous tension!! C'est tout à fait faux, il ne peut dépendre que la manière dont l'électronique est faite, et non du moment où le LGC est mis sous tension. Ils font compter les impulsions d'angles directement à l'AGC avec des instructions spéciales!!! Ces impulsions auraient du être comptées avec un compteur électronique, lu avec une opération IO. |
 Voici un exemple de compteur électronique qui peut compter des impulsions matérielles, et de tels circuits existaient au temps d'Apollo. |
 Et le compte d'impulsions peut être lu avec une opération de lecture I/O, et l'AGC avait une instruction pour le faire, et il n'avait donc pas d'excuse pour ne pas procéder ainsi. |
 Le fait de les compter avec des instructions logicielles était un gaspillage conséquent de temps de cycle, et retire inutilement du temps à l'AGC...Surtout quand l'AGC manque de temps pour exécuter ses opérations, et doit faire de fréquents redémarrages à cause de cela. |
Et l'interface radar sort un signal de fréquence fixe, qui n'est même pas modulé par les impulsions d'angle, et qui est transformé en un autre signal avec une fréquence fixe différente. Un non-sens complet! |
 George s'est précipité à Houston juste une heure avant le décollage du module lunaire depuis la lune, pour parler aux représentants du MIT de quelque chose qui volait du temps au processeur; il aurait encore eu le temps de trouver une solution pour le programme de l'AGC...Si celui-ci n'était pas déjà sur la lune! Mais les représentants du MIT avaient encore le temps de faire une prière pour les astronautes! |
 Quelque chose "volait" du temps à l'AGC, mais ils n'ont jamais trouvé ce que c'était, et ils ont donc du préserver une marge de temps pour l'AGC...Une marge qu'ils mangeaient inutilement en convertissant les unités, et en comptant des impulsions matérielles avec des instructions logicielles! |
 Le simple fait d'ajouter un affichage fait que la marge de cycle de fonctionnement tombe de 13% à 10%, provoquant davantage d'alarmes et de redémarrages de l'ordinateur! Et les astronautes passaient plus de temps à acquitter les alarmes qu'à s'occuper effectivement du guidage du vaisseau spatial! |
 Hilarant: Parce que SERVICER avait la priorité la plus basse, il était traité après tous les autres processus; mais parce qu'il accaparait de la mémoire nécessaire aux autres processus, les autres processus ne pouvaient plus tourner lorsque SERVICER avait épuisé toutes les ressources mémoire...qu'il ne pouvait pas utiliser parce que les autres processus plus prioritaires ne lui laissaient pas le temps nécessaire pour tourner! |
 C'est le serpent qui se mord la queue! |
 Le moment où l'AGC dérangeait le plus les astronautes, avec des alarmes plus fréquentes, est précisément le moment où leur attention pour le guidage aurait été la plus nécessaire! C'était manifestement un ordinateur qui avait besoin de beaucoup d'attention! |
 Les programmeurs remarquent des "oscillation de poussée", pour lesquelles ils imaginent deux origines différentes: 1) L'IMU (plateforme inertielle) serait "secouée" et perturberait la lecture des accéléromètres. 2) La commande de poussée aurait un effet un peu retardé et ne serait pas immédiatement prise en compte par le moteur. Les deux explications sont aberrantes. |
 1) L'IMU ne peut pas être secouée, car la navigation est "normalement" très régulière surtout qu'il n'y a pas de perturbations atmosphériques sur la lune, grâce au système de guidage très "fiable", et il ne pourrait pas en résulter de telles secousses sur l'IMU; si elle était vraiment secouée de cette manière, cela voudrait dire que le module lunaire a un comportement très dangereux, et a toutes les chances de s'écraser sur la lune! 2) Cela n'a pas d'importance si la commande de poussée a un effet un peu retardé sur le moteur (seulement des fractions de seconde), le système de guidage reste régulier et ne peut en aucun cas produire des oscillations de poussée (dans l'aviation aussi l'effet de la commande est un peu retardé, et cela ne crée pas d'oscillations). Les deux explications n'ont donc pas de sens, il ne peut pas y avoir d'oscillations (à moins que l'ordinateur ne déconne). |
 Alors un programmeur applique une compensation de 0,2 seconde à cause du retard entre la commande de poussée et la poussée résultante. Son supérieur lui dit que ce n'est pas suffisant et que cela devrait être 0,3 seconde. Mais le programmeur rétorque que "c'est comme la médecine, ne pas compenser plus que nécessaire". |
 Son supérieur sait que ce n'est pas "comme la médecine", et persiste à penser que la compensation est insuffisante pour corriger les oscillations, mais il laisse son subordonné faire comme il l'entend, "pour nourrir sa confiance en soi", espérant qu'il la corrigera éventuellement. Alors une bonne entente entre les programmeurs vaut mieux qu'assurer la sécurité du vaisseau spatial, n'est-ce pas? |
 Finalement, Apollo sera sauvé, parce que la performance du moteur avait été améliorée, et que la compensation à priori insuffisante suffisait à présent, et contrait correctement les oscillations. Si la compensation correcte avait été programmée, Apollo aurait pu s'écraser, juste parce que l'équipe de développement n'avait pas été informée de l'amélioration du moteur. |
 Alors la combinaison d'un supérieur tolérant et d'une documentation déficiente a sauvé Apollo! C'est un vrai scénario hollywoodien! |
 Et le plus drôle est qu'aucune compensation n'aurait dû être appliquée! |
 Quel est l'utilité de compenser le temps de réaction de 0,3 ou 0,2 seconde du moteur, alors que SERVICER ne tournait que toutes les 2 secondes (au mieux), et que SERVICER pouvait aléatoirement être interrompu par une autre tâche entre les lectures d'accéléromètres et l'application de la correction...Surtout quand aucune compensation ne peut être appliquée, comme les lectures des accéléromètres ne peuvent être prédites! |
 Nous nageons donc ici dans un océan d'absurdités! Mais la "compensation" a offert une histoire digne d'un scénario hollywoodien! |
 Ils disent aussi qu'ils ont résolu les secousses de l'IMU en retirant les variations de vélocités dues à ces secousses. C'est un non-sens total. |
 Il ne peut y avoir de secousses sur l'IMU, comme je l'ai expliqué, parce que la navigation est (normalement) régulière, et il n'y a aussi pas moyen que les variations de vélocité dues aux secousses sur l'IMU puissent être calculées! De plus, si l'IMU était vraiment sujet à des secousses, il était beaucoup plus simple de convenablement l'arrimer pour l'empêcher de bouger, que de faire des corrections de vélocité basées sur son comportement supposé (ce qu'il n'est même pas possible de faire, comme ce comportement est aléatoire). |
 Ils disent qu'ils avaient ajouté une possibilité que l'équipage puisse sélectionner le niveau de poussée désiré par le guidage!!! Mais, s'ils le sélectionnent, il n'est plus désiré par le guidage! |
 Ils disent qu'ils avaient ajouté une possibilité que les astronautes prennent le contrôle de la poussée alors que l'AGC gardait le contrôle de l'orientation du module! C'est une aberration totale, car le couple "poussée moteur/Orientation lem" ne peut être dissocié; leur association détermine la magnitude des forces horizontale et verticale créant les décélérations nécessaires; leur contrôle doit être donné à une même intelligence, et il vaut mieux que ce soit celle de l'ordinateur. |
 C'est comme le conducteur d'une voiture qui dit à son passager:" Maintenant je ferme les yeux, tu surveilles la route, mais je garde le volant"! |
 Parce que SERVICER était parfois incapable de réaliser son travail dans la période donnée de 2 secondes, causant ainsi un plantage de l'ordinateur et un redémarrage, ils imaginent à présent de lui donner une période flexible qu'il peut mesurer lui-même, de sorte qu'il ait toujours le temps de réaliser la tâche qu'il a à faire. |
 Cela peut éviter la surcharge, mais ce n'est plus du temps réel, parce que, dans le temps réel, une tâche critique doit toujours effectuer son travail dans un temps prédéterminé qu'elle ne doit pas dépasser. Il n'y a rien de tel que du temps réel "flexible". |
 Ils ont un signal parasite sur le bouton d'abort qui provoque un abort non désiré qui pourrait déranger le guidage d'Apollo. Vous pourriez alors vous attendre à ce qu'ils aient électroniquement filtré ce signal parasite pour l'empêcher de provoquer un abort? |
 Non, pas du tout, il ont imaginé une solution" Apollo", en trompant la procédure d'Abort, et lui faisant croire qu'un abort était déjà en cours de traitement. |
Parfois le système plantait parce que SERVICER avait épuisé toutes les zones VAC dont avaient besoin d'autres tâches plus prioritaires (et que SERVICER ne pouvait utiliser parce que les tâches plus prioritaires l'empêchaient de tourner), mais ils prévoyaient de gaspiller encore plus de zones VAC en y installant des bouts de code dedans; de cette manière, les alarmes et les redémarrages arriveraient encore plus souvent! |
 Donc, ce récit, que la plupart des gens pensent sérieux et très informatif, lorsqu'il est vu du point de vue d'un ingénieur, est en fait très drôle, et n'a aucune crédibilité. |
 Il n'est pas possible que ce récit puisse être sérieux, et il ne fait aucun doute pour moi que ce récit contient un message caché des ingénieurs qui ont travaillé sur l'AGC, et un acte de rébellion contre ceux qui les ont forcés à truquer le projet. |
