На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -11 и -12 смогли сесть, оказывается, только по счастливой случайности.
Софт и железо
Слева — компьютер, справа — дисплей и клавиатура
На командном и лунном модулях «Аполлонов» стояли идентичные компьютеры, но с разным набором программ. По тем временам это был фантастический хайтек, использовавший интегральные схемы, а не отдельные диоды и транзисторы. «Цикл памяти», примерно соответствующий тактовой частоте современных процессоров, занимал 11,7 микросекунд. Но практически все операции требовали два цикла, поэтому эффективная тактовая частота получалась равной 23,4 микросекундам, или 43 килогерцам, в 100 000 раз медленнее современных процессоров. Память компьютера составляла 36 тысяч 14-битных слов, что примерно соответствовало 64 килобайтам.
Постоянная память на проволоке и ферритовых сердечниках
Софт для лунного модуля разрабатывали примерно 300 человек в течение семи лет. Программа посадки на Луну имела название LUMINARY и хранилась в постоянной памяти на ферритовых сердечниках, провода сквозь которые продевались вручную. Создание такого блока памяти занимало несколько месяцев, поэтому софт должен был быть готов заранее. За годы «Аполлонов» программы модифицировались. На «Аполлоне-11» стоял блок с программой версии 99, а финальная версия (очевидно, посадившая Аполлон-17) имела номер 209. Главным дизайнером программы посадки был Алан Кламп (Allan Klumpp), недавний выпускник Массачусетского технологического института.
Процедура посадки
Посадка на Луну с точки зрения компьютера проходила в три этапа:
Программа P63 отвечала за торможение с орбитальной скорости.
P64 занималась выводом лунного модуля в район посадки.
P65 отвечала за финальный этап посадки.
На участке работы программы P64 пилот лунного модуля называл число, которое показывал на дисплее компьютер. Командир мысленно отмечал это число на шкале, которая была нарисована на иллюминаторе, и получал расчетную точку посадки.
Байка первая: ошибки 1201 и 1202
Довольно известен тот факт, что, когда Армстронг и Олдрин начали торможение с лунной орбиты, их компьютер выдал ошибку 1202. Это был очень нервный момент, потому что сами астронавты не знали значения этого кода. К счастью, специалист ЦУПа Стив Бейлс (Steve Bales) заранее написал список всех ошибок и быстро нашел расшифровку — компьютер не успевал справляться со всей работой. Компьютер «Аполлона» был системой реального времени, и он начал игнорировать некоторые низкоприоритетные задачи, выдавая сообщение об ошибке. Спустя еще минуту появилась новая ошибка — 1201. Но она относилась к этому же типу и не срывала посадку.
Уже после посадки была найдена причина. Как это часто бывает в сложных технических системах, причиной оказалась целая цепочка событий. Во-первых, после начала торможения инструкция требовала включить стыковочный радар на случай аварийного прерывания посадки. Стыковочный радар работал от другого источника питания, нежели компьютер. Этот источник питания имел ту же частоту, но не был синхронизирован по фазе с источником питания компьютера. Небольшие смещения фазы на радаре выглядели для компьютера как дрожания неподвижной в реальности антенны. В норме при посадке процессор компьютера был загружен на ~85%. «Дрожащая антенна» добавила еще 13%. А когда Олдрин дал команду компьютеру посчитать разницу между реальной и рассчитанной высотой по посадочному радару, компьютер оказался в условиях перегрузки. Уже потом посчитали, что это событие «украло» примерно минуту процессорного времени, а из 10 раз в секунду компьютер управлял стабильностью лунного модуля 9 раз. Кстати, баг с дрожащей антенной был замечен на тестировании, но его оставили, потому что он проявился всего один раз, а замена оборудование на новое могла создать более опасные баги.
Та самая посадка, видео повернуто для удобства восприятия, и добавлено много полезной информации. В видео упоминается программа P66, это альтернативный вариант одной из программ
Байка вторая, счастливая ошибочная оптимизация
Как известно, «Аполлоны» -11 и -12 сели успешно. Однако впоследствии, уже после возвращения астронавтов, по телеметрии в двигателях посадочной ступени обнаружились опасные колебания — тяга то поднималась вверх, то падала вниз. К счастью, колебания не стали слишком сильными и не вызвали проблем с управлением или двигателем. Расследование показало, что причиной колебаний являлось программное обеспечение. Программистам был доступен специальный документ, в котором описывались параметры и свойства лунного модуля. В разделе о двигателе было указано, что он имеет инерционность 0,3 секунды. То есть через 0,3 секунды после команды на изменение тяги он должен был выйти на новый уровень. Это надо было отразить в программе, поэтому была написана специальная подпрограмма, которая измеряла тягу двигателя по данным акселерометра и выполнялась за 0,3 секунды. Но финальная версия этой подпрограммы писалась другим программистом, который решил ее улучшить и сделать быстрее. Новая версия успевала выполниться за 0,2 секунды. Ее протестировали на симуляторе, и она показала себя там отлично. Однако разработчики двигателя улучшили его, и время задержки упало до 0,075 секунды. А внести это изменение в документ для программистов просто забыли. Последующие тесты показали, что, если бы подпрограмма определения тяги работала изначальные 0,3 секунды, то система бы оказалась нестабильной, и колебания становились бы все больше и больше, что привело бы к прыжкам тяги двигателя от минимальной до максимальной и обратно, а это бы, наверняка, сорвало высадку.
Байка третья, о проблемах интерполяции
Напоминаю, что программа P64 нацеливала лунный модуль в точку над местом посадки. Однако, поскольку для расчета траектории использовались полиномы высоких степеней, траектория, выходя в точку прицеливания, могла оказаться под поверхностью Луны. Потому что полином высокой степени мог «прыгнуть» в сторону (это знают математики и инженеры):
Чем выше степень, тем больше может быть этот «прыжок», несмотря на то, что график проходит через все желтые точки
Ирония с этим багом состоит в том, что его никак не исправили. Программа не отслеживала потенциально опасные кривые. Баг не проявился в реальных посадках, но его мог вызвать не такой уж невозможный случай. Если бы лунный модуль немного сбился с курса и оказался над неучтенным достаточно глубоким кратером, компьютер, получая данные от посадочного радара, мог бы подумать, что оказался выше траектории, пересчитать кривую на более крутую и направить лунный модуль к прицельной точке, нырнув сначала в Луну. Отдельно доставляет рецепт борьбы с багом, если бы он проявился — астронавтам надо было бы переместить точку прицеливания за предел досягаемости по запасам топлива и подержать ее там некоторое время. Вы когда-нибудь совершали странные действия, чтобы переупрямить глючную программу? Можете себя поздравить, астронавтам возможно пришлось бы делать то же самое…
