Предотвратила ли ошибка 1202 и связанная с ней перезагрузка катастрофу при посадке Аполлона-11?

Большинство отчетов об известной ошибке 1202, о которой сообщила AGC во время посадки LM Apollo 11, характеризуют событие как результат успешной работы AGC, сброса перегруженного компьютера с сохранением важных данных, необходимых для продолжения работы при перезапуске.

Однако пересказ Алана Клумпа описывает ситуацию, при которой перегрузка АРУ ​​может привести к катастрофе:

... команды дроссельной заслонки и рулевого управления ... часто вычислялись не полностью и ставились в очередь для последующего завершения. Любая попытка поставить команду в очередь, когда очередь уже заполнена (около пяти команд), приведет к тому, что компьютер очистит очередь и выдаст сигнал тревоги. Но когда питание радара было в фазе , стоящие в очереди команды, действительные только в какое-то отдаленное прошлое, могли быть завершены и выданы в обратном порядке, на мгновение беря на себя управление, чтобы увести LM с его нормальной посадочной траектории. Хотя команды сброса вызовут аварийные сигналы, выдача ошибочных команд не вызовет этого. Моделирование показало, что ошибочные команды могут вывести LM на аварийный курс, а наведение попытается доставить LM к месту посадки по траектории, проходящей под лунной поверхностью.

Однако неясно, когда и произошла ли эта ситуация на самом деле. Предназначен ли этот отрывок для подтверждения общей версии: поведение сброса, связанное с ошибкой 1202, предотвратило возникновение этой катастрофы. Или он говорит, что это могло происходить, когда сообщалось об ошибках 1202, или в какой-то другой момент во время миссии? (На самом деле, одна из интерпретаций состоит в том, что перегрузка по фазе, вызвавшая ошибку 1202, застраховала от такой катастрофы.)

Предотвратила ли ошибка 1202 и связанная с ней перезагрузка катастрофу при посадке Аполлона-11?

В недавней статье в WIRED wired.com/story/apollo-11-mission-out-of-control есть интересная предыстория очереди и т. д.
Я думаю, что это был Компьютер Наведения Аполлона (AGC), выдававший 1202 и 1201 во время посадки, а не Система Наведения Прерывания (AGS). Но это только то, что я думаю, я могу ошибаться!
@kruemi Действительно! (Удивительно, что это не было поймано раньше.)

Ответы (2)

Я согласен с вашим комментарием: «Неясно, когда и произошла ли эта ситуация на самом деле». Прочитав отчет Клумпа и книгу его коллеги Дона Эйлса « Солнечные лучи и светило », я не думаю, что у нас достаточно информации, чтобы знать, могла ли такая ситуация существовать на Аполлоне-11. Я думаю, мы знаем, что ее не было на Аполлоне-11, потому что радар электропитание не было в фазе, и Клампп говорит

Но когда питание радара было в фазе , стоящие в очереди команды, действительные только в какое-то отдаленное прошлое, могли быть завершены и выданы в обратном порядке, на мгновение беря на себя управление, чтобы увести LM с его нормальной посадочной траектории.

(выделено мной)

Вот отчет Эйлса о проблеме на стр. 215-216 S&L.

На заре 1970 года, когда P66 Auto был закончен и готов к предстоящей миссии, мы с Алланом нашли время, чтобы пересмотреть проблему, которая чуть не сорвала посадку «Аполлона-11» — лишение процессорного времени, которое мы назвали TLOSS, — но мы занялись этим в различные пути.

Аллан заставлял IBM 360 жужжать, запуская симуляции на веревке Apollo 13, чтобы увидеть, как она ведет себя при различных значениях TLOSS. Мы уже знали, что если количество TLOSS было в самый раз, то в период высокой активности незавершенные задания SERVICER могли накапливаться в очереди Executive. Последним, что делал СЕРВИСЕР на каждом проходе, была отправка информации на DSKY для отображения. Непосредственно перед этим он выдавал команды ориентации, а до этого — команды дроссельной заслонки. Что беспокоило Аллана, так это то, что произойдет, если работа СЕРВИСЕРА будет прервана до того, как будет отправлена ​​команда газа или ориентации. Если таких приостановленных заданий накопилось достаточно, произойдет перезапуск программного обеспечения, как это было на Apollo 11, и приостановленные задания исчезнут. Но что, если вычислительная нагрузка уменьшится до того, как они будут сброшены?

Аллан обнаружил, что может произойти то, что приостановленные рабочие места (Аллан назвал их «скрытниками») могут вернуться к жизни, не подозревая, что они были в спячке, и продолжить выдавать команду ориентации или дроссельной заслонки, применимую к более раннему моменту . траектория . Внезапно LM может сманеврировать в неправильное положение. Худшие случаи были, когда приостановленные задания, накопившиеся во время P64, выполнялись после перехода на P66.

4 марта Аллан опубликовал тщательно составленный меморандум с описанием «набора известных проявлений потери времени». Аллан описал восемь отдельных видов плохого поведения, начиная с TLOSS около 8 процентов. В качестве необычной меры предосторожности Аллан подписал меморандум и попросил Джерри Левина подписать документ, подтверждающий его одобрение.

(выделено мной)

Моя интерпретация заключается в том, что для того, чтобы проблема возникла,

  1. источник питания РЛС сближения должен быть синхронизирован
  2. должно было случиться что-то, из-за чего задания SERVICER выполнялись долго и не завершались
  3. Что бы ни вызвало 2) должно было уйти до того, как ситуация станет достаточно плохой, чтобы сбросить очередь

Мы знаем, что на «Аполлоне-11» 1) такого не было, но я не знаю, достаточно ли у нас информации, чтобы знать, произошло 2) или нет.

Этот ответ пытается объяснить часть о том, что источник питания радара не совпадает по фазе.

Отличный ответ. Так что возможно, что если бы источник питания радара рандеву был синхронизирован (1), 1202 (или 1201?) указывало бы на прерывание (во избежание аварийной посадки)?
@orome Я думаю, что вы получаете сигналы тревоги только в том случае, если компьютер действительно перезагружается. Такая промежуточная проблема, когда задания приостанавливались, а затем возобновлялись, но компьютер не перезагружался, могла привести к проблемам с траекторией без предупреждения, что действительно вызывает беспокойство. Впрочем, это все моя интерпретация.
Ах, да, я думаю, ты прав. Аварийный сигнал указывает, что все в порядке, потому что произошел перезапуск. (По сути, это способ AGS сказать, что я перегружен, и я собираюсь справиться с этим, потратив секунду на уборку и возвращение к задачам с высоким приоритетом.) Описанная ситуация с доставкой возникла бы только в отсутствие 1202 тревога.
Я думаю, вы поняли почти правильно, за исключением того, что фазы источника питания дрейфовали относительно друг друга, то есть они могли дрейфовать по фазе и не совпадать. Когда он говорит «когда источник питания радара был в фазе», он имеет в виду на мгновение в фазе, достаточно долго, чтобы позволить компьютеру наверстать упущенное. Так что это могло произойти 11.
Постоянный низкий TLOSS = номинальное поведение. Постоянный высокий (выходной) TLOSS = безопасное поведение, поскольку сброс нагрузки не позволяет очереди становиться глубокой и предотвращает смешение немедленных и поставленных в очередь задач SERVICER. Но если эта фаза колеблется, а TLOSS поднимается выше и ниже порогового значения, система может в конечном итоге возобновить довольно старую задачу. Либо этого не произошло, либо произошло, но не оказало существенного влияния на физическую стабильность системы. В любом случае, не обошлось без удачи, и это, похоже, настоящая беда Клампа. Все могло закончиться совсем плохо.
В отчете Эйлса - см. связанный ответ - не упоминается дрейф. Он говорит так, будто при включении были установлены отношения, и только некоторые из них были достаточно плохими, чтобы вызвать проблемы. Но я не могу исключить того, что вы говорите.
Я думаю, это правильно. Похоже, что соотношение фаз было установлено при включении питания (можем ли мы знать наверняка?), поэтому ситуация, упомянутая в замечании Клумпа, — это просто то, что могло произойти, и не предназначалось для описания того, что происходило во время посадки Аполлона-11.
@hobbs Читая дальше в отчете Клумпа , он пишет, что «многие команды управления были отложены; некоторые никогда не отдавались, другие отдавались не по порядку». Что говорит о том, что вы можете быть правы в том, что был дрейф?
@orome Eyles говорит: «Однако фазовый угол между двумя сигналами был совершенно случайным, в зависимости от момента, когда LGC, который всегда включался после ATCA, начал посылать первый сигнал синхронизации частоты». klabs.org/history/apollo_11_alarms/eyles_2004/eyles_2004.htm
Да, я понял, что это означает, что фазовый угол был зафиксирован случайным образом и оставался под этим углом все время (не дрейфовал). Но я не могу примириться с тем, что Клумпп «многие команды наведения были отложены в сторону; некоторые никогда не отдавались, другие отдавались не по порядку» в контексте его высказываний о том, что такое поведение имело место, когда фазовые углы уступали.
У меня есть продолжение о том, почему RR и AGC не в фазе вызывают так много прерываний.
@hobbs Насколько я помню, сигналы были синхронизированы по частоте, но не по фазе. (Проблемой было отсутствие синхронизации по фазе.) Если два сигнала синхронизированы по частоте, между ними не должно быть фазового дрейфа; если есть, они не привязаны к частоте, а просто находятся на одинаковых частотах. Я не понимаю, как вы могли иметь два сигнала на одной и той же частоте, но с разным сдвигом фазы по фазе относительно друг друга.

В лунном модуле было два компьютера. Тревога 1202 произошла на Лунном навигационном компьютере, который выполнял много разных задач — фактически, тревога 1202 была предупреждением о том, что его многозадачная система находится под угрозой (но еще не полностью) перегрузки.

Также была система помощи при прерывании. Его компьютер и программное обеспечение имели совершенно другую конструкцию, чем LGC, разработанную другими подрядчиками. У AGS была только одна задача: вернуть LM обратно в космос, где его мог бы подобрать CSM. Он не мог быть перегружен дополнительными задачами, которые должен был выполнять LGC. Хотя AGS никогда не приходилось использовать в реальной миссии, он был тщательно протестирован, и нет причин думать, что он выйдет из строя.

Экипажи Аполлона практиковались в распознавании необходимости прерывания и активации AGS. В статье ArsTechnica, которую вы цитируете, даже говорится об этом:

И, чтобы было ясно, прерывание во время посадки не было чем-то незначительным. В этой процедуре Армстронг должен был нажать кнопку «ПРЕРЫВАНИЕ ЭТАПА» на панели LM, что привело бы к срабатыванию взрывных болтов и гильотин и отделению ступени подъема LM от ступени спуска. Затем запускался двигатель подъема, делая все возможное, чтобы вернуть скорость спускающемуся кораблю, пытаясь вернуть его на какую-то стабильную орбиту, чтобы экипаж мог найти командный модуль и встретиться с ним. Это было то, чему обучались экипажи , но это было бы нелегко. И это носило бы с собой клеймо проваленной миссии.

Выпуск 1202 не мешал управлению кораблем, поэтому экипажу было дано добро на посадку. Однако, если бы это действительно каким-то образом мешало управлению космическим кораблем, Армстронг тренировался немедленно активировать AGS. Так что никакой катастрофы бы не случилось , но возможность высадиться на Луну была бы потеряна.

Извините, это не вопрос: вопрос зависит от отношения между «командами в очереди, действительными только в какое-то отдаленное время в прошлом, которые могут быть выполнены и выполнены в обратном порядке», и какое это имеет отношение к ситуации, которая произошла (когда случилось 1202).
В очередь ставятся не данные, а задачи (как потоки процессов Unix). Исполнительная программа решает, какая задача будет выполняться следующей, в зависимости от приоритета. Во время мягкой перезагрузки очереди задач очищаются; они не портятся и не переворачиваются. Он не собирается выдавать команды рулевого управления в обратном порядке.
Согласно книге Эйлса, задачи перезапускаются, что и приводит к выдаче неверных команд. Бывает случай, когда задачи поставлены на паузу, но система восстанавливается до перезагрузки.
Если такой режим отказа был возможен, то почему он не наблюдался при моделировании?
@RussellBorogove это наблюдалось в симуляциях, проведенных в Массачусетском технологическом институте, но они тренировались «различное количество TLOSS». Чтобы попасть в этот кейс, вам нужно иметь нужное количество TLOSS. В тренажерах не было настоящих АРУ, поэтому маловероятно, что такая аппаратно-зависимая проблема будет обнаружена.
Гаа. У симуляторов не было настоящих АРУ? 😳
@RussellBorogove нет, они были слишком дорогими, и получение текущих «веревок» было проблемой. Они были эмулированы в программном обеспечении для моделирования. В тренажерах «Шаттла» были настоящие летные компьютеры, но я думаю, что это было нововведением. Симуляторы бомбардировщика B-52, над которыми я работал, также эмулировали бортовые компьютеры. Учебные тренажеры МКС также эмулировали бортовые компьютеры.
Предотвратила ли ошибка 1202 и связанная с ней перезагрузка катастрофу при посадке Аполлона-11?
СпросиСетьПолитика конфиденциальности1y, 0v