Код ошибки 1202 аполлон

Время на прочтение
5 мин

Количество просмотров 36K

На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -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 нацеливала лунный модуль в точку над местом посадки. Однако, поскольку для расчета траектории использовались полиномы высоких степеней, траектория, выходя в точку прицеливания, могла оказаться под поверхностью Луны. Потому что полином высокой степени мог «прыгнуть» в сторону (это знают математики и инженеры):

Чем выше степень, тем больше может быть этот «прыжок», несмотря на то, что график проходит через все желтые точки

Ирония с этим багом состоит в том, что его никак не исправили. Программа не отслеживала потенциально опасные кривые. Баг не проявился в реальных посадках, но его мог вызвать не такой уж невозможный случай. Если бы лунный модуль немного сбился с курса и оказался над неучтенным достаточно глубоким кратером, компьютер, получая данные от посадочного радара, мог бы подумать, что оказался выше траектории, пересчитать кривую на более крутую и направить лунный модуль к прицельной точке, нырнув сначала в Луну. Отдельно доставляет рецепт борьбы с багом, если бы он проявился — астронавтам надо было бы переместить точку прицеливания за предел досягаемости по запасам топлива и подержать ее там некоторое время. Вы когда-нибудь совершали странные действия, чтобы переупрямить глючную программу? Можете себя поздравить, астронавтам возможно пришлось бы делать то же самое…

На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -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 нацеливала лунный модуль в точку над местом посадки. Однако, поскольку для расчета траектории использовались полиномы высоких степеней, траектория, выходя в точку прицеливания, могла оказаться под поверхностью Луны. Потому что полином высокой степени мог «прыгнуть» в сторону (это знают математики и инженеры):

Чем выше степень, тем больше может быть этот «прыжок», несмотря на то, что график проходит через все желтые точки

Ирония с этим багом состоит в том, что его никак не исправили. Программа не отслеживала потенциально опасные кривые. Баг не проявился в реальных посадках, но его мог вызвать не такой уж невозможный случай. Если бы лунный модуль немного сбился с курса и оказался над неучтенным достаточно глубоким кратером, компьютер, получая данные от посадочного радара, мог бы подумать, что оказался выше траектории, пересчитать кривую на более крутую и направить лунный модуль к прицельной точке, нырнув сначала в Луну. Отдельно доставляет рецепт борьбы с багом, если бы он проявился — астронавтам надо было бы переместить точку прицеливания за предел досягаемости по запасам топлива и подержать ее там некоторое время. Вы когда-нибудь совершали странные действия, чтобы переупрямить глючную программу? Можете себя поздравить, астронавтам возможно пришлось бы делать то же самое…

16 июля 1969 года «Аполлон-11» стартовал с мыса Канаверал. На борту космического корабля находились 3 астронавта: Нил Армстронг, Майкл Коллинз и Базз Олдрин. И уже 20 июля 650 миллионов человек во всем мире увидели на своих экранах в прямом эфире первые шаги человека по поверхности спутника нашей планеты. Высадка на Луну стала одним из самых замечательных достижений нашей цивилизации. Многим показалось, что это был очень успешный полёт. Однако всем к нему причастным пришлось пережить множество тревожных минут. Разные проблемы и опасности преследовали их в течение всей этой исторической миссии. Сегодня мы расскажем о шести из них.

1. 1202

Представьте, что вы находитесь в крошечном посадочном модуле («Орёл»), до прилунения остаётся семь с половиной минут, и в это самое время компьютер сигнализирует об ошибке, код которой вам неизвестен. Неприятно, не правда ли? Армстронг уже готовился опуститься на Луну, когда компьютер, называвшийся AGC, выдал код ошибки «1202». Надо сказать, что этот агрегат для своего времени был настоящим технологическим чудом. Он был компактным, весил всего около 32 килограмм и потреблял 70 Ватт при 28 вольтах постоянного тока. От него зависело очень многое, особенно во время прилунения. Он осуществлял навигацию, отвечал за скорость и высоту посадочного модуля, сообщал о производительности двигателя. Также он должен был вернуть экипаж на орбиту, если во время спуска что-то пойдёт не так. Находившиеся внутри «Орла» Армстронг и Олдрин понятия не имели, что значит это «1202». Код ни разу не встречался им во время многочисленных тренировочных упражнений, имитировавших высадку. Командир сообщил о проблеме в Центр управления полётами, откуда ему посоветовали игнорировать ошибку и продолжать выполнять задание. AGC показал код «1202» ещё четыре раза, затем один раз «1201», и прекратил играть на нервах. Впоследствии выяснилось, что компьютер был перегружен большим количеством данных, поступающих от радаров, и ему не хватало памяти.

1. Перелёт

Где-то за 9 минут до прилунения «Аполлон-11» Армстронг осознал, что «Орёл» перемахнёт через тщательно выбиравшуюся для этой цели площадку. По его оценкам, «перелёт» должен был составить около 5 километров, но на самом деле посадочный модуль улетел ещё дальше — на шесть с половиной. Причиной проблемы было то, что во время отстыковки остаточное давление внутри туннеля, соединявшего два модуля «Аполлона», придало «Орлу» дополнительный импульс. Это был относительно слабый толчок, но в условиях невесомости его хватило, чтобы спровоцировать очень серьёзные проблемы. Поверхность Луны покрыта кратерами и скальными обнажениями. Ещё хуже было то, что посадочный модуль сжигал топливо быстрее ожидаемого. Вскоре Хьюстон предупредил Армстронга, что у него осталось горючего всего на 60 секунд. Если бы за это время командир не посадил модуль, то прилунение пришлось бы прервать. В этот момент «Орёл», накренившись, летел над поверхностью на скорости 55 километров в час. Он поднимал пыль и разглядеть, что творится внизу, было очень трудно. Первая в истории пилотируемая посадка на Луну произошла на ровной местности, когда у модуля оставался запас топлива всего на полминуты. На пульте загорелась синяя лампочка, и командир произнёс фразу, которая вошла в историю: «Хьюстон, База Спокойствия на связи. «Орёл» сел».

1. Ледяная пробка

Вскоре после прилунения у посадочного модуля возникла ещё одна проблема. Датчики зафиксировали повышение давления в топливопроводе двигателя «Аполлон-11». Это означало, что пар, образовавшийся между теплообменником и клапанами, замёрз, закупорив систему. Не остывший ещё двигатель «Орла» продолжал генерировать пар, из-за чего его могло разорвать. Специалисты НАСА заметили проблему и разработали план вентиляции. Однако прежде чем они успели передать инструкции Армстронгу и Олдрину, ледяная пробка растаяла сама по себе, выпустив скопившиеся газы.

1. Лунный грунт

До полёта «Аполлона-11» специалисты НАСА не очень хорошо себе представляли, насколько стабилен лунный грунт. Тот факт, что «Орел» прочно стал на свои опоры, не мог не радовать, но вокруг было много пыли, которая могла доставить весьма серьёзные неприятности как посадочному модулю, так и астронавтам. Несмотря на то, что на Луну заранее были посланы разведывательные аппараты «Сервейер», изучившие поверхность, лишь после исторических шагов Армстронга стало окончательно понятно, что здесь возможна запланированная «внекорабельная деятельность». Но местная пыль оказалась довольно опасна. Главным образом, из-за своей абразивности. Она накапливалась в течение миллиардов лет, по всей видимости, образуясь в результате попаданий метеоритов, но на Луне нет природных процессов, которые могли бы придать этим крошечным частичкам более гладкую форму. Все астронавты, работавшие на поверхности нашего спутника, жаловались впоследствии, что пыль проникала в посадочный модуль, заклинивала застёжки-молнии и даже просачивалась сквозь слои защитного материала скафандра.

1. Переключатель

После прилунения «Аполлон-11» внутри посадочного модуля сломался переключатель. Базз Олдрин был уверен, что это произошло вслед за тем, когда он и Армстронг вошли внутрь после пребывания на Луне. Астронавты должны были задраить люк, восстановить давление, снять ранцы и подключить шланги скафандров к системам жизнеобеспечения. Затем им следовало вновь открыть люк и выбросить в него ранцы и всё другое ненужное оборудование, тем самым уменьшая взлётную массу «Орла». Все эти действия были отработаны во время подготовки к полёту, но кто-то из двоих то ли споткнулся, то ли неловко задел приборную панель. Избавившись от балласта, Армстронг и Олдрин устроились на полу, чтобы передохнуть, и второй из них заметил среди лунной пыли, покрывшей пол модуля, чёрный рычажок. Взглянув на панель, они поняли, что он отвечал за очень важную функцию — включал двигатель модуля. Без его переключения о взлёте с Луны можно было даже не мечтать. Астронавты сообщили в ЦУП о проблеме и попытались вздремнуть, а инженеры НАСА начали искать её решение. Они размышляли несколько часов, но так и не смогли придумать, как включить двигатель без переключателя. Астронавты вновь осмотрели гнездо, откуда отломился рычажок, и заметили в отверстии небольшой обломок. Олдрину удалось поддеть его ручкой, что, в принципе, спасло и людей, и всю лунную программу США.

1. Посадка

Командный модуль, в котором находились возвращающиеся на Землю астронавты, во время приземления чуть было не попал под горящие обломки служебного модуля. Перед входом в атмосферу нашей планеты «Аполлон-11» разделился на две упомянутые части. Командный модуль расположился тепловым экраном вниз, опустился в нижние слои атмосферы, где над ним раскрылся парашют, мягко опустивший людей на поверхность Тихого океана. Служебный же модуль должен был сгореть в атмосфере. В целях предотвращения столкновения ему полагалось совершить ряд маневров и оказаться на совершенно другой траектории. По плану он вообще должен был войти в атмосферу позже командного модуля. Однако конкретно в этом случае его двигатели не сработали, и обе составляющие «Аполлона-11» начали опускаться вместе. К счастью, сгорающие обломки не задели капсулу с астронавтами, и она благополучно приводнилась. Позже выяснилось, что ошибка была допущена в настройках сброса оставшегося топлива служебного модуля.

The 50th anniversary of the historic Apollo 11 landing on the moon takes place on July 20, 2019.

You might recall the famous utterance heard worldwide that the Eagle had landed (the word “Eagle” was the name given to the lunar module aka lunar lander used in the Apollo 11 mission).

Going back in time to that incredible feat that occurred five decades ago, listen carefully to the recorded audio chatter between astronauts Neil Armstrong and Buzz Aldrin while carrying on a dialogue with the mission control center during the descent to the moon.

Unless you are a nerdish fan of computers or spaceflight, you might not have noticed that there was a subtle undercurrent of concern about some rather jarring, alarm-blaring, display-flashing error codes known as the numbers 1202 and 1201.

It’s an incredible story that the general public knows little about.

Let’s unpack the tense tale, along with considering lessons learned that can be applied to the now emerging self-driving driverless autonomous cars.

Anxious Moments During The First Landing On The Moon

The lunar module that was being piloted down to the moon surface began to report errors when the craft was just seven and a half minutes away from landing.

Think about this for a moment. I assure you that having errors crop-up while in the midst of such an already tricky and risky effort is not something you desire to occur. It was later indicated that the heart rates for both the astronauts jumped up feverishly when the errors began to appear.

Things were tense, especially since landing on the moon had never actually occurred before and had only been practiced in a simulator.

The astronauts were faced with the possibility that they might need to call off the landing if something went awry during the descent. If they didn’t land on the first try, there was no second try available and they’d have to sheepishly and disappointingly return to earth without having landed on the moon.

It would have been a crushing blow to NASA, it would have been a heart-wrenching let-down for the country, it would have potentially tarnished the image of America worldwide, along with creating an expanded window for the Russians to try and get to a moon landing before the United States did.

Everything was on the line.

Of course, worse still would have been a crash landing onto the moon, which one shudders to even contemplate.

Two obscure error codes were involved, each consisting of four digits, and represented status that there was an issue or problem occurring in their spacecraft. During the design of the system for the lunar lander, the developers had come up with a slew of error codes that could be displayed if the computer detected something amiss on the craft.

Here’s the rub. When the astronauts had done simulated landings, doing so over and over again, not all of the possible error codes were tested out, and thus there were some error codes that the astronauts had never seen or directly knew about.

As luck or unluck would have it, the two error codes of 1202 and 1201 had not been previously exhibited during their training efforts. As such, the astronauts were unaware of what those particular error codes signified. Furthermore, even most of the mission control staff monitoring the landing had not seen the 1202 and 1201 before either.

Okay, let’s try to relive history.

Put yourself into the cramped lunar module. With just minutes left to land, bells start ringing and buttons are flashing, trying to get your rapt attention. Nearly immediately, the astronauts realized they didn’t know what the error code signified, and so they (remarkedly) calmly brought it to the attention of mission control:

“It’s a 1202.”

Within mission control, there were blank stares as by-and-large no one knew what the 1202 was about. Meanwhile, Steve Bales, a guidance officer, called over to a backroom area where various engineers were stationed and ready to dig into any system related matter that might arise.

“1202. What’s that?” he reportedly asked.

John “Jack” Garman, a NASA engineer, took a look at a list he had handmade of the numerous error codes that the teams had come up with.

He realized that the 1202 was a code meaning that the guidance computer on-board the landing craft was getting overloaded with tasks. The programmers had anticipated this overloading might someday occur, and so had established a system internal aspect that would automatically do a fast reboot and then a memory restore to try and get the computer back underway.

In theory, the computer was going to be able to resolve the error, without needing any human intervention. Garman said afterward that he figured if the 1202 error code didn’t recur frequently during the rest of the descent, the astronauts were probably okay to proceed in spite of whatever was seemingly overloading the onboard computer system.

“Give us a reading on the 1202 program alarm,” Neil said.

In the recorded voice transmissions, you can hear in Neil’s voice a seriousness and sternness and exasperation that so far no one from mission control had yet told the astronauts what to do about the error.

Again, place yourself in the lunar module and imagine that you’ve got this crazy unknown 1202 error code screaming at you, you’ve never seen it before, you don’t have any procedure in-hand to deal with it, and it could be something extremely dangerous, happening in real-time, while you are aiming to hopefully safely land on the moon, and you are completely in-the-dark as to what it is and what you are supposed to be doing about it.

Each second that the 1202 remains an unknown could be another second toward your doom.

Within mission control, Darmon and Bales relayed internally that the astronauts should proceed on the landing, and so capcom Charlie Duke said to the astronauts:

“We’re go on that alarm.”

In this context, “go” means that the landing could continue to proceed unabated. Also, since no further instruction of what to do was being voiced to the astronauts, it implied that the alarm, whatever it meant, could be ignored. If you are wondering whether the astronauts might have been curious about what the 1202 represented, I believe they only cared at the moment about whether the 1202 required any action on their part.

I was fortunate to have had lunch with Buzz Aldrin during a recent visit he made to Los Angeles, and when I asked him about the 1202, he indicated indeed that once mission control essentially said to not worry about it, he let it go and didn’t put any further thought towards it.

This makes sense too, namely that no additional explanation or elaboration was particularly needed per se, plus the astronauts already had their hands full with trying to land, so they set aside worries about the 1202 and focused on the landing process.

If you listen to the remaining minutes of the recorded audio, you’ll hear that the 1202 error happened again, and again, along with a related error code of the 1201. Mission control informed the astronauts that it was considered the same type of error and implied therefore that there was no need to do anything about the alarms.

For everyone listening at the time of the actual moon landing, the chatter seemed to be the normal kind of interaction you’d expect between the astronauts and mission control, often technical in nature and you don’t really know what their jargon means or signifies.

In this case, it was a subplot of grave concern and intensity, but that millions upon millions of people listening were unaware was playing out in real-time and could have ditched the landing entirely.

That’s the story within the story about the Apollo 11 moon landing.

Lessons Learned For Self-Driving Driverless Cars

Can a systems related matter that happened some fifty years ago be of relevance today?

Absolutely.

Self-driving driverless cars are real-time based systems that need to act quickly and drive a car while the vehicle is in motion, perhaps on a freeway and barreling along at 70 miles per hour.

Onboard the autonomous car are numerous computer processors, including various electronic memory banks used to house programs that are being executed or performed to drive the car. In addition, there is a myriad of sensors on the car, such as cameras, radar, ultrasonic devices, LIDAR, and the like, all of which are collecting data during the driving act and relaying that data into the computer processors and memory banks.

In the case of the 1202 error on the Eagle, what prompted the error was (in simple terms) a faulty radar unit that was essentially bombarding the onboard computer in such a manner that the computer kept getting handed task after task, though the flooding tasks weren’t truly needed to be undertaken. The Operating System (OS) of the computer allowed the memory to fill-up, but then this meant that other legitimate tasks would not have a slot to work in.

As I had mentioned earlier, the programmers had anticipated that somehow for whatever reason there might be a time when the onboard computer might become overloaded with tasks. They had devised an internal mechanism that if something untoward led to the memory getting maxed out, the system would do a fast reboot and memory reload, which hopefully would clear out whatever was causing the initial problem.

Though this does suggest that the computer can then proceed with the high priority of running the craft, notice that it does not necessarily solve the underlying problem of the radar unit that’s pounding away at the computer. In any case, the good news is that the trick of the quick reboot was able to deal with the matter and the other precious landing subsystems were able to do their thing, meanwhile the radar was continuing to be an irritant but not so much that it led the craft astray.

How many times have you rebooted your smartphone or laptop computer and then had it clear up a problem?

I’m betting you’ve done such reboots many times.

Have you also perchance done a reboot and then later on the same problem seemed to crop-up?

That’s a somewhat similar case of the 1202, namely that the reboot temporarily “solves” the problem of letting the computer proceed, but it didn’t “solve” the root cause of the faulty radar unit aspects.

Here then are some insightful Apollo 11 lessons for AI developers, automakers, and tech firms that are creating the software and systems for driverless cars:

• Anticipate and code for wayward sensors. You cannot assume that the sensors on the driverless car will be working flawlessly. Besides the obvious aspect that the sensor might get blinded by dirt or debris, there is also the chance that the sensor could go awry due to some internal bug or issue. Make sure to code for this possibility and have some provision of what to do once the matter arises.

• Ensure that the driverless car OS is robust. Some of the operating systems being used for autonomous cars are somewhat stripped down for speed, yet they need to also be able to handle a wide variety of both known and unpredictable faults or systems issues that could happen. Make sure the OS is up to the task of supporting the systems involved in driving the car, safely so.

• Do not ignore edge cases. The focus for most driverless car efforts right now is aiming at driving during normal everyday conditions, and not dealing with unusual or infrequent kinds of driving situations (so-called “edge” aspects). This though belies the true aspects of driving which can include foul weather, bad roadways, and the like. Autonomous cars that are being tried out on our public streets need to be ready to handle edge or corner cases.

• Testing must be exhaustive. If you leave out test cases when testing a driverless car, you are setting up a potentially dangerous situation that someday in the real-world the thing you didn’t test will happen, and perhaps have quite adverse consequences. Testing needs to be as complete as feasible.

• Use reboots cautiously and only as a last resort. Imagine you are in a driverless car, zipping along on the highway, and the AI announces that it needs to do a reboot, right away. This is not the same as doing a reboot on your smartphone when you are playing a video game that froze-up the phone. Developers should consider an on-board reboot as a last resort and only invoked with great caution.

Conclusion

You’ll be happy to know that the amount of computer capability packed into a self-driving car is many magnitudes greater than the puny but valiant computers used on the Apollo 11 spacecraft.

Those programmers in 1969 could only dream of someday having access to the incredibly powerful computing that we commonly have available today. Even your smartphone is by far superior in computer power than were the lunar lander computers.

That’s though just the hardware side of things.

From a software perspective, we still today can readily have the same kinds of issues occur, including hidden bugs or suddenly appearing faults, which could have happened back in 1969. Let’s make sure that we learn the lessons of the past and therefore are extremely mindful when designing, coding, testing, and fielding autonomous cars.

Thanks go to NASA and all those involved in getting us to the moon, and hopefully, today’s driverless cars will be prepared for any 1202 or 1201 codes that might pop-up.