How not accidentally crashed "Apollo 11"

The other day, in a normal office conversation, I said: “The fact that we have a crutches warehouse here is normal, in all IT projects like this. Probably, of all the software that made mankind, only in the programs for landing on the moon everything was beautiful. ” Having said this, I climbed into the Internet to find additional facts on a brief popular science story for colleagues about computers and programs of the lunar module. But one of the first links came from which it turned out that the crutches, and, terribly to say, there were bugs in the polished software that allowed man to land on the moon. And the "Apollos" -11 and -12 were able to sit down, it turns out, only by luck.

Soft and iron

On the left - the computer, on the right - the display and keyboard

On the command and lunar modules of the Apollo were identical computers, but with a different set of programs. At the time, it was a fantastic high-tech, using integrated circuits, rather than individual diodes and transistors. The “memory cycle”, roughly corresponding to the clock frequency of modern processors, took 11.7 microseconds. But almost all operations required two cycles, so the effective clock frequency was 23.4 microseconds, or 43 kilohertz, 100,000 times slower than modern processors. Computer memory was 36 thousand 14-bit words, which roughly corresponded to 64 kilobytes.


Permanent memory on wire and ferrite cores
')
The software for the lunar module was developed by approximately 300 people for seven years. The moon landing program was called LUMINARY and was stored in permanent memory on ferrite cores, the wires through which were passed through by hand. Creating such a block of memory took several months, so the software had to be ready in advance. Over the years, "Apollo" program modified. On the Apollo 11, there was a block with program version 99, and the final version (evidently landing Apollo 17) was number 209. The main designer of the landing program was Allan Klumpp, a recent graduate of the Massachusetts Institute of Technology.

Landing procedure

Landing on the moon from the point of view of the computer took place in three stages:

Program P63 was responsible for deceleration from orbital speed.
P64 was engaged in the withdrawal of the lunar module in the landing area.
P65 was responsible for the final landing stage.

At the P64 program section, the pilot of the lunar module called the number that the computer displayed on the display. The commander mentally noted this number on the scale, which was drawn on the porthole, and received a calculated landing point.

First bike: errors 1201 and 1202

It is quite well known that when Armstrong and Aldrin began braking from the lunar orbit, their computer gave an error 1202. It was a very nervous moment, because the astronauts themselves did not know the meaning of this code. Fortunately, TsUPa specialist Steve Bales (Steve Bales) wrote a list of all the errors in advance and quickly found the transcript - the computer did not have time to cope with all the work. The Apollo computer was a real-time system, and he began to ignore some low-priority tasks, producing an error message. After another minute, a new error appeared - 1201. But she was of the same type and did not disrupt the landing.

After the landing was found the reason. As often happens in complex technical systems, the reason was a whole chain of events. First, after the start of braking, the instruction required to turn on the docking radar in case of an emergency interruption of landing. Docking radar worked from a different power source than a computer. This power supply had the same frequency, but was not synchronized in phase with the computer's power supply. Small phase shifts on the radar looked to the computer like a jitter of an immobile in reality antenna. Normally, when landing, the computer processor was loaded at ~ 85%. “Shaky Antenna” added another 13%. And when Aldrin gave the computer command to calculate the difference between the real and calculated altitude on the landing radar, the computer was in overload conditions. Later they thought that this event “stole” about a minute of CPU time, and out of 10 times per second the computer managed the stability of the lunar module 9 times. By the way, a bug with a quivering antenna was seen on testing, but it was left because it only appeared once, and replacing the equipment with a new one could create more dangerous bugs.


That same landing, video turned for ease of perception, and added a lot of useful information. The video mentions the program P66, it is an alternative version of one of the programs.

And here you can look at the landing virtually, from different sides.

Bike second, happy error optimization

As is known, the Apollos -11 and -12 boarded successfully. However, later, after the return of the astronauts, dangerous fluctuations were detected by means of telemetry in the engines of the landing stage - the thrust rose up and fell down. Fortunately, the fluctuations did not become too strong and did not cause problems with the control or engine. The investigation revealed that the cause of the fluctuations was software. Programmers had access to a special document that described the parameters and properties of the lunar module. In the section on the engine, it was stated that it has an inertia of 0.3 seconds. That is, 0.3 seconds after the command to change the thrust, he had to reach a new level. This should have been reflected in the program, so a special subroutine was written that measured the engine thrust according to the accelerometer and was performed in 0.3 seconds. But the final version of this subroutine was written by another programmer who decided to improve it and make it faster. The new version managed to execute in 0.2 seconds. She was tested on the simulator, and she showed herself well there. However, the engine developers improved it, and the delay time dropped to 0.075 seconds. And to make this change in the document for programmers simply forgot. Subsequent tests showed that if the subroutine for determining thrust worked for the initial 0.3 seconds, the system would be unstable, and the oscillations would become more and more, which would lead to jumps of the engine thrust from minimum to maximum and back; , for sure, broke landing.

Third Bike, about interpolation problems

I remind you that the P64 program aimed the lunar module at a point above the landing site. However, since high degrees polynomials were used to calculate the trajectory, the trajectory, going to the aiming point, could be under the surface of the moon. Because a high degree polynom could “jump” to the side (mathematicians and engineers know it):


The higher the degree, the more this “leap” can be, despite the fact that the graph passes through all the yellow dots.



The irony with this bug is that it did not fix it. The program did not track potentially dangerous curves. The bug did not manifest itself in real landings, but a not so impossible case could have caused it. If the lunar module had gone a little off course and turned out to be over an unrecorded deep enough crater, the computer, receiving data from the landing radar, might have thought that it was higher than the trajectory, recalculate the curve for a steeper one and direct the lunar module to the sighting point, first diving into the Moon . Separately delivers a recipe for dealing with a bug, if it were manifested - the astronauts would have to move the aiming point beyond the reach of the fuel reserves and keep it there for a while. Have you ever performed strange actions to re-direct a buggy program? You can congratulate yourself, astronauts might have to do the same ...